From huzaifas at redhat.com Tue Jan 1 07:40:13 2008 From: huzaifas at redhat.com (Huzaifa Sidhpurwala) Date: Tue, 01 Jan 2008 13:10:13 +0530 Subject: Want to maintain sshmenu Message-ID: <4779EE5D.3020108@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All, I just saw the WishList on the fedora wiki site. I was interested in the sshmenu app. I could not find anyone maintaining it for fedora. I am interested in maintaining it, if any one does not have any objections. - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) Help Desk APAC Team Lead, Research and Development Lead, Global Help Desk, Pune Phone: +617 3514 8125 (UTC +5.5) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 Visit the Help Desk portal at : http://helpdesk.corp.redhat.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHee5dzHDc8tpb2uURAnYFAJ4jC6o8lleaNEh4m9ZICY5lK2evxgCffbv4 ISxhmfjzzAkuMU1adYEcr5I= =kGpE -----END PGP SIGNATURE----- From kamisamanou at kamisamanou.net Tue Jan 1 08:31:07 2008 From: kamisamanou at kamisamanou.net (Kamisamanou Burgess) Date: Tue, 1 Jan 2008 02:31:07 -0600 Subject: Putting K3b back onto the DVDs? In-Reply-To: <34209.12.172.32.236.1198865589.squirrel@clueserver.org> References: <476ED932.2090601@poolshark.org> <20071223194719.24292e38@redhat.com> <1198604092.6197.18.camel@gibraltar.str.redhat.com> <20071225160138.11cda072@redhat.com> <539333cb0712260115q738cb7ffo5b2ba8f7a34c0f78@mail.gmail.com> <64b14b300712280959o2dedb6c9w4aaf417fd16505c1@mail.gmail.com> <37808.198.182.193.170.1198865111.squirrel@clueserver.org> <64b14b300712281009i4776832am7f9acb359ab15a8c@mail.gmail.com> <34209.12.172.32.236.1198865589.squirrel@clueserver.org> Message-ID: <5dbb83710801010031t708b42f2ibdfb58a089ccfbcb@mail.gmail.com> On Dec 28, 2007 12:13 PM, Alan wrote: > > On 12/28/07, Alan wrote: > >> > On 12/26/07, subhodip biswas wrote: > >> >> K3b though popular , may bear some space constraints in live cd 's . > >> >> But I think it can be bought back to DVD's as it was in Fedora core > 6 > >> >> and previous ... because of its popularity. > >> >> -- > >> >> Regards > >> >> Subhodip Biswas > >> >> > >> > Please consider this for Fedora 9 Live CD: > >> > https://bugzilla.redhat.com/show_bug.cgi?id=315151 > >> > >> My only concern with adding K3B is all the KDE dependencies it drags > >> along > >> with it. I like the program a lot, but how much added baggage does it > >> add? > >> > >> I wish that the Gnome CD burning software worked as easily and as well > >> as > >> K3B, but I have yet to find one that does. (They all seem to be > >> horribly > >> designed from a UI to me.) > > > > What is wrong with Brasero UI? I find it very similar UI vise when > > comparing it to k3b, still I like k3b more because it just works > > better for me. > > > > Do you have some concrete UI issues with Brasero? Have you talked with > > some Brasero devels regarding those issues? I tried Brasero. It has a good UI, but rejects every blank cd I've ever used. No, I haven't said anything to the Brasero guys. -- Sayonara, Kamisamanou Burgess http://www.kamisamanou.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From omar at linux.vnet.ibm.com Tue Jan 1 08:58:29 2008 From: omar at linux.vnet.ibm.com (Mohammed Omar) Date: Tue, 01 Jan 2008 14:28:29 +0530 Subject: Kdump on Fedora Message-ID: <1199177910.6754.1.camel@omar> Hi, Does Fedora supports kdump ? (especially F8) Regards Omar From laxathom at fedoraproject.org Tue Jan 1 12:03:57 2008 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Tue, 1 Jan 2008 13:03:57 +0100 Subject: Want to maintain sshmenu In-Reply-To: <4779EE5D.3020108@redhat.com> References: <4779EE5D.3020108@redhat.com> Message-ID: <62bc09df0801010403r1c001f91l6274d12aef9258a0@mail.gmail.com> 2008/1/1, Huzaifa Sidhpurwala : > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi All, > I just saw the WishList on the fedora wiki site. I was interested in > the sshmenu app. I could not find anyone maintaining it for fedora. > I am interested in maintaining it, if any one does not have any > objections. Matthias already take it and resquested a review. --> https://bugzilla.redhat.com/show_bug.cgi?id=426149 - -- > Regards, > Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) > Help Desk APAC Team Lead, > Research and Development Lead, > Global Help Desk, Pune > Phone: +617 3514 8125 (UTC +5.5) > > GnuPG Fingerprint: > 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 > > Visit the Help Desk portal at : http://helpdesk.corp.redhat.com > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.5 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFHee5dzHDc8tpb2uURAnYFAJ4jC6o8lleaNEh4m9ZICY5lK2evxgCffbv4 > ISxhmfjzzAkuMU1adYEcr5I= > =kGpE > -----END PGP SIGNATURE----- > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Xavier.t Lamien -- French Fedora Ambassador Fedora/EPEL Contributor | http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From buildsys at redhat.com Tue Jan 1 12:05:35 2008 From: buildsys at redhat.com (Build System) Date: Tue, 1 Jan 2008 07:05:35 -0500 Subject: rawhide report: 20080101 changes Message-ID: <200801011205.m01C5ZlP018651@porkchop.devel.redhat.com> New package nexcontrol Software to control your Celestron NexStar Telescope Updated Packages: PyOpenGL-3.0.0-0.5.b1.fc9 ------------------------- * Mon Dec 31 2007 Hans de Goede 3.0.0-0.5.b1 - New upstream release 3.0.0b1 alexandria-0.6.2-2.fc9 ---------------------- * Mon Dec 31 2007 Mamoru Tasaka - 0.6.2-2 - Trial workaround patch for bug 427070 aria2-0.12.0-2.fc9 ------------------ * Mon Dec 31 2007 Micha?? Bentkowski - 0.12.0-2 - Get rid of odd locale.alias * Mon Dec 31 2007 Micha?? Bentkowski - 0.12.0-1 - 0.12.0 audacious-plugins-1.4.3.2-1.fc9 ------------------------------- * Mon Dec 31 2007 Ralf Ertzinger 1.4.3.2-1 - Update to 1.4.3.2 blobAndConquer-0.91-5.fc9 ------------------------- * Mon Dec 31 2007 Hans de Goede 0.91-5 - Fix restoring of resolution when exiting a fullscreen game callweaver-1.2-0.4.rc5.20071230.fc9 ----------------------------------- * Mon Dec 31 2007 David Woodhouse 1.2-0.4.rc5.20071230 - Update, rebuild for deps - Disable ODBC deluge-0.5.8-1.fc9 ------------------ * Mon Dec 31 2007 Peter Gordon - 0.5.8-1 - Update to new upstream release (0.5.8) - Merge Mamoru Tasaka's no-release-notification patch into the default-prefs patch. dnsmasq-2.41-0.4.test26.fc9 --------------------------- * Mon Dec 31 2007 Patrick "Jima" Laughton 2.41-0.4.test26 - Bugfix/feature enhancement update eclipse-slide-1.3.6-3.fc9 ------------------------- * Mon Dec 31 2007 Dave Sugar - 1.3.6-3 - fixed minor problem in new module wizard firefox-3.0-0.beta2.4.fc9 ------------------------- * Mon Dec 31 2007 Christopher Aillon 3.0-0.beta2.4 - Create and own /etc/skel/.mozilla - No longer need add-gecko-provides freenx-0.7.1-4.fc9 ------------------ * Mon Dec 31 2007 Axel Thimm - 0.7.1-4 - Apply Jeffrey J. Kosowsky's patches to enable multimedia and file/print sharing support (Fedora bug #216802). - Silence %post output, when openssh's server has never been started before (Fedora bug #235592). - Add dependency on which (Fedora bug #250343). glaxium-0.5-3.fc9 ----------------- gtk-vnc-0.3.2-1.fc9 ------------------- * Mon Dec 31 2007 Daniel P. Berrange - 0.3.2-1.fc9 - Update to 0.3.2 release - Added dep on zlib-devel libertas-usb8388-firmware-2:5.110.20.p49-1.fc9 ---------------------------------------------- * Mon Dec 31 2007 Dennis Gilmore - 2:5.110.20.p49-1 - update to 5.110.20.p49 which fixes http://dev.laptop.org/ticket/5194 netpbm-10.35.36-1.fc9 --------------------- * Mon Dec 31 2007 Jindrich Novy 10.35.36-1 - update to 10.35.36 policycoreutils-2.0.34-5.fc9 ---------------------------- * Mon Dec 31 2007 Dan Walsh 2.0.34-5 - Fix roles output when creating a module * Mon Dec 31 2007 Dan Walsh 2.0.34-4 - Handle files with spaces in fixfiles python-mutagen-1.13-2.fc9 ------------------------- * Mon Dec 31 2007 Micha?? Bentkowski - 1.13-2 - Add egg-info to package * Mon Dec 31 2007 Micha?? Bentkowski - 1.13-1 - 1.13 qgit-2.1-2.fc9 -------------- * Mon Dec 31 2007 Dan Horak 2.1-2 - add missing patch * Mon Dec 31 2007 Dan Horak 2.1-1 - update to upstream version 2.1 selinux-policy-3.2.5-7.fc9 -------------------------- * Mon Dec 31 2007 Dan Walsh 3.2.5-7 - Fix munin log, - Eliminate duplicate mozilla file context - fix wpa_supplicant spec stormbaancoureur-2.0.0-1.fc9 ---------------------------- * Mon Dec 31 2007 Hans de Goede 2.0.0-1 - New upstream release 2.0.0 - Fix sound when using pulseaudio * Thu Oct 18 2007 Hans de Goede 1.5.3-1 - New upstream bugfix release 1.5.3 upx-3.02-1.fc9 -------------- * Mon Dec 31 2007 Jon Ciesla - 3.02-1 - 3.02. Broken deps for i386 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-client - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libcrypto.so.6 d4x - 2.5.7.1-3.fc7.i386 requires libssl.so.6 d4x - 2.5.7.1-3.fc7.i386 requires libcrypto.so.6 epiphany - 2.21.4-1.fc9.i386 requires libxpcom_core.so epiphany - 2.21.4-1.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.i386 requires libgtkembedmoz.so epiphany-devel - 2.21.4-1.fc9.i386 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires libgtkembedmoz.so gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.i386 requires libgtkembedmoz.so grass - 6.2.2-2.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 libopensync-plugin-synce - 0.22-4.fc8.i386 requires libopensync.so.0 liferea - 1.4.10-1.fc9.i386 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.i386 requires libgtkembedmoz.so mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libcrypto.so.6 multisync - 0.91.0-1.fc7.i386 requires libopensync.so.0 multisync - 0.91.0-1.fc7.i386 requires libosengine.so.0 multisync-gui - 0.91.0-1.fc7.i386 requires libopensync.so.0 multisync-gui - 0.91.0-1.fc7.i386 requires libosengine.so.0 php-mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 python-gammu - 0.22-3.fc8.i386 requires libGammu.so.2 xca - 0.6.4-1.fc8.i386 requires libcrypto.so.6 Broken deps for x86_64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libssl.so.6()(64bit) epiphany - 2.21.4-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.x86_64 requires libgtkembedmoz.so()(64bit) epiphany - 2.21.4-1.fc9.x86_64 requires libxpcom_core.so()(64bit) epiphany-devel - 2.21.4-1.fc9.i386 requires gecko-devel = 0:1.8.1.10 epiphany-devel - 2.21.4-1.fc9.x86_64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libssl.so.6()(64bit) kazehakase - 0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 libopensync-plugin-synce - 0.22-4.fc8.x86_64 requires libopensync.so.0()(64bit) liferea - 1.4.10-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.x86_64 requires libgtkembedmoz.so()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) multisync - 0.91.0-1.fc7.x86_64 requires libosengine.so.0()(64bit) multisync - 0.91.0-1.fc7.x86_64 requires libopensync.so.0()(64bit) multisync-gui - 0.91.0-1.fc7.x86_64 requires libopensync.so.0()(64bit) multisync-gui - 0.91.0-1.fc7.x86_64 requires libosengine.so.0()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) python-gammu - 0.22-3.fc8.x86_64 requires libGammu.so.2()(64bit) xca - 0.6.4-1.fc8.x86_64 requires libcrypto.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-client - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libcrypto.so.6 d4x - 2.5.7.1-3.fc7.ppc requires libssl.so.6 d4x - 2.5.7.1-3.fc7.ppc requires libcrypto.so.6 epiphany - 2.21.4-1.fc9.ppc requires libxpcom_core.so epiphany - 2.21.4-1.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.ppc requires libgtkembedmoz.so epiphany-devel - 2.21.4-1.fc9.ppc requires gecko-devel = 0:1.8.1.10 epiphany-devel - 2.21.4-1.fc9.ppc64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires libgtkembedmoz.so gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc requires libssl.so.6 gdal - 1.4.2-3.fc8.ppc requires libcrypto.so.6 gnome-web-photo - 0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.ppc requires libgtkembedmoz.so grass - 6.2.2-2.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 libopensync-plugin-synce - 0.22-4.fc8.ppc requires libopensync.so.0 liferea - 1.4.10-1.fc9.ppc requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc requires libgtkembedmoz.so mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libcrypto.so.6 monodevelop - 0.17-4.fc9.ppc requires boo multisync - 0.91.0-1.fc7.ppc requires libopensync.so.0 multisync - 0.91.0-1.fc7.ppc requires libosengine.so.0 multisync-gui - 0.91.0-1.fc7.ppc requires libopensync.so.0 multisync-gui - 0.91.0-1.fc7.ppc requires libosengine.so.0 php-mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 python-gammu - 0.22-3.fc8.ppc requires libGammu.so.2 revisor-cobbler - 2.0.5-14.fc9.noarch requires koan revisor-cobbler - 2.0.5-14.fc9.noarch requires cobbler xca - 0.6.4-1.fc8.ppc requires libcrypto.so.6 Broken deps for ppc64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libssl.so.6()(64bit) epiphany - 2.21.4-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.ppc64 requires libgtkembedmoz.so()(64bit) epiphany - 2.21.4-1.fc9.ppc64 requires libxpcom_core.so()(64bit) epiphany-devel - 2.21.4-1.fc9.ppc64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libssl.so.6()(64bit) kazehakase - 0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 libopensync-plugin-synce - 0.22-4.fc8.ppc64 requires libopensync.so.0()(64bit) liferea - 1.4.10-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc64 requires libgtkembedmoz.so()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) perl-Test-AutoBuild-darcs - 1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 php-mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) python-gammu - 0.22-3.fc8.ppc64 requires libGammu.so.2()(64bit) revisor-cobbler - 2.0.5-14.fc9.noarch requires koan From jkeating at redhat.com Tue Jan 1 13:12:59 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 1 Jan 2008 08:12:59 -0500 Subject: Putting K3b back onto the DVDs? In-Reply-To: <5dbb83710801010031t708b42f2ibdfb58a089ccfbcb@mail.gmail.com> References: <476ED932.2090601@poolshark.org> <20071223194719.24292e38@redhat.com> <1198604092.6197.18.camel@gibraltar.str.redhat.com> <20071225160138.11cda072@redhat.com> <539333cb0712260115q738cb7ffo5b2ba8f7a34c0f78@mail.gmail.com> <64b14b300712280959o2dedb6c9w4aaf417fd16505c1@mail.gmail.com> <37808.198.182.193.170.1198865111.squirrel@clueserver.org> <64b14b300712281009i4776832am7f9acb359ab15a8c@mail.gmail.com> <34209.12.172.32.236.1198865589.squirrel@clueserver.org> <5dbb83710801010031t708b42f2ibdfb58a089ccfbcb@mail.gmail.com> Message-ID: <20080101081259.621ee3cb@redhat.com> On Tue, 1 Jan 2008 02:31:07 -0600 "Kamisamanou Burgess" wrote: > I tried Brasero. It has a good UI, but rejects every blank cd I've > ever used. No, I haven't said anything to the Brasero guys. Were you selecting the wrong media size in the dropdown? I noticed that the drop down didn't match the media I inserted so I had to specifically choose 80minute CD before burning. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From choeger at cs.tu-berlin.de Tue Jan 1 13:22:42 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Tue, 01 Jan 2008 14:22:42 +0100 Subject: SELinux macro broken? In-Reply-To: <4779538E.9000400@redhat.com> References: <1198688969.14312.2.camel@choeger4> <4779538E.9000400@redhat.com> Message-ID: <1199193762.3225.3.camel@choeger4> Am Montag, den 31.12.2007, 15:39 -0500 schrieb Daniel J Walsh: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Christoph H?ger wrote: > > Hi, > > > > when I tried to build a custom SELinux module, this strange behavior > > occured: > > > > when I used: > > > > libs_read_lib_files(tomcat5_t) > > > > I got "read" denied source: tomcat5_t target: lib_t > > > > but using > > > > require { > > type lib_t; > > type tomcat5_t; > > class file read; > > } > > > > allow tomcat5_t lib_t:file read; > > > > worked fine. Although this should essentially be the same in my > > understanding. > > > > Any explanations for that? > > > > regards > > > > christoph > > > Please attach the compilation errors. > > > tomcat5_t is marked as a domain_type? > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkd5U44ACgkQrlYvE4MpobP9egCdG+J82YNQyTFNSKnh7uyku4Aa > iAgAoKR7A+DEWGIFNJV+48MPt+BlxIyr > =wOR2 > -----END PGP SIGNATURE----- > Hi, there were no compilation errors, but I think it had to do with libs_use_lib_files with is deprecated. I have no problems since I use libs_use_shared_libs(). You can see the complete .te file on the selinux list, which I discovered after I posted the first message (sorry for that). thank you christoph From denis at poolshark.org Tue Jan 1 14:09:46 2008 From: denis at poolshark.org (Denis Leroy) Date: Tue, 01 Jan 2008 15:09:46 +0100 Subject: Putting K3b back onto the DVDs? In-Reply-To: <20080101081259.621ee3cb@redhat.com> References: <476ED932.2090601@poolshark.org> <20071223194719.24292e38@redhat.com> <1198604092.6197.18.camel@gibraltar.str.redhat.com> <20071225160138.11cda072@redhat.com> <539333cb0712260115q738cb7ffo5b2ba8f7a34c0f78@mail.gmail.com> <64b14b300712280959o2dedb6c9w4aaf417fd16505c1@mail.gmail.com> <37808.198.182.193.170.1198865111.squirrel@clueserver.org> <64b14b300712281009i4776832am7f9acb359ab15a8c@mail.gmail.com> <34209.12.172.32.236.1198865589.squirrel@clueserver.org> <5dbb83710801010031t708b42f2ibdfb58a089ccfbcb@mail.gmail.com> <20080101081259.621ee3cb@redhat.com> Message-ID: <477A49AA.60006@poolshark.org> Jesse Keating wrote: > On Tue, 1 Jan 2008 02:31:07 -0600 > "Kamisamanou Burgess" wrote: > >> I tried Brasero. It has a good UI, but rejects every blank cd I've >> ever used. No, I haven't said anything to the Brasero guys. > > Were you selecting the wrong media size in the dropdown? I noticed > that the drop down didn't match the media I inserted so I had to > specifically choose 80minute CD before burning. Be sure to file those problems in BZ (or directly upstream). The brasero guys are usually very responsive to bug reports, and there's a 0.6 branch that will keep receiving back-ported fixes (for F-7 and F-8). From trond.danielsen at gmail.com Tue Jan 1 14:20:06 2008 From: trond.danielsen at gmail.com (Trond Danielsen) Date: Tue, 1 Jan 2008 15:20:06 +0100 Subject: GNU Radio In-Reply-To: <200712311550.41528.lowen@pari.edu> References: <3170f42f0712311228q5429c06do4e1c4f6225422284@mail.gmail.com> <200712311550.41528.lowen@pari.edu> Message-ID: <409676c70801010620l68af02ddudc0d7d0017826599@mail.gmail.com> 2007/12/31, Lamar Owen : > On Monday 31 December 2007, Debarshi 'Rishi' Ray wrote: > > > Before I go into the whole process of coming up to speed with the Fedora > > > packaging guidelines, etc, I wanted to ask here if anyone else here is > > > working on GNU Radio packages for Fedora. > > > > GNU Radio is there on the WishList: > > http://fedoraproject.org/wiki/PackageMaintainers/WishList and no one > > has claimed it there yet. > > Yeah, I saw it on the Wishlist, but didn't know if it had yet been claimed. I started working on a GNU Radio package for Fedora, but I never found the time to finish it. I do not know if you will find it useful, but I have a preliminary spec file here: http://trondd.fedorapeople.org/spec_files/ Best Regads, -- Trond Danielsen From lmacken at redhat.com Tue Jan 1 14:26:32 2008 From: lmacken at redhat.com (Luke Macken) Date: Tue, 1 Jan 2008 09:26:32 -0500 Subject: Broken deps in the stable release are not acceptable In-Reply-To: <4776875A.1000908@redhat.com> References: <1198865975.3293.41.camel@wicktop.localdomain> <62bc09df0712281125o9b9e6b3td4261a0409c95f3f@mail.gmail.com> <1198889708.3293.86.camel@wicktop.localdomain> <1198891673.3293.97.camel@wicktop.localdomain> <4775A39D.4000307@fedoraproject.org> <47765EFC.1030409@redhat.com> <477664F1.8080403@fedoraproject.org> <4776875A.1000908@redhat.com> Message-ID: <20080101142632.GA7464@crow> On Sat, Dec 29, 2007 at 06:43:54PM +0100, Christopher Aillon wrote: > On 12/29/2007 04:17 PM, Rahul Sundaram wrote: >> Christopher Aillon wrote: >>> On 12/29/2007 02:32 AM, Rahul Sundaram wrote: >>>> Christoph Wickert wrote: >>>>> I completely agree with you. Maybe we could say that updates are >>>>> allowed >>>>> to bypass testing if they fix >>>>> a) serious bugs >>>>> b) bugs marked as "urgent" >>>>> c) broken deps >>>> >>>> b) isn't a good criteria since anybody can mark any bug as urgent. If >>>> the priority field in bugzilla is restricted to package maintainers and >>>> triagers, I would agree with you. >>> >>> The same maintainer who marks "push right to stable" can tweak the field >>> before they submit the update and you won't have solved anything. >> >> Even if it had a strict set of rules and maintainers are going to abuse >> the system, > > Hey dude, I wasn't the one agreeing with a set of rules, that was you. I'm > just saying it's unwise to agree with a set of rules that can still be > worked around easily. > >> they can mark any update as a critical security update and push it through >> too but then it is much more easier to point out who is responsible >> compared to users just marking a random bug as a high priority one. > > I just noticed that nobody sent out a FESCo Meeting Summary for > 2007-09-27[1]. There, we approved > http://fedoraproject.org/wiki/LubomirKundrak/SecurityUpdateProcessDraft so > the Fedora Security Response team would have to approve it before it gets > released as a security advisory. > > [1] At least there's a log at > http://bpepple.fedorapeople.org/fesco/FESCo-2007-09-27.html > > Nobody's implemented that yet, though... Luke? This would be quite nice to > get done... :-) The code has been written and will make its way out with the next bodhi upgrade. luke From laxathom at fedoraproject.org Tue Jan 1 14:51:34 2008 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Tue, 1 Jan 2008 15:51:34 +0100 Subject: Broken deps in the stable release are not acceptable In-Reply-To: <20080101142632.GA7464@crow> References: <1198865975.3293.41.camel@wicktop.localdomain> <62bc09df0712281125o9b9e6b3td4261a0409c95f3f@mail.gmail.com> <1198889708.3293.86.camel@wicktop.localdomain> <1198891673.3293.97.camel@wicktop.localdomain> <4775A39D.4000307@fedoraproject.org> <47765EFC.1030409@redhat.com> <477664F1.8080403@fedoraproject.org> <4776875A.1000908@redhat.com> <20080101142632.GA7464@crow> Message-ID: <62bc09df0801010651j144b80a2ne0f967cf1e0308e4@mail.gmail.com> 2008/1/1, Luke Macken : > > On Sat, Dec 29, 2007 at 06:43:54PM +0100, Christopher Aillon wrote: > > On 12/29/2007 04:17 PM, Rahul Sundaram wrote: > >> Christopher Aillon wrote: > >>> On 12/29/2007 02:32 AM, Rahul Sundaram wrote: > >>>> Christoph Wickert wrote: > >>>>> I completely agree with you. Maybe we could say that updates are > >>>>> allowed > >>>>> to bypass testing if they fix > >>>>> a) serious bugs > >>>>> b) bugs marked as "urgent" > >>>>> c) broken deps > >>>> > >>>> b) isn't a good criteria since anybody can mark any bug as urgent. If > >>>> the priority field in bugzilla is restricted to package maintainers > and > >>>> triagers, I would agree with you. > >>> > >>> The same maintainer who marks "push right to stable" can tweak the > field > >>> before they submit the update and you won't have solved anything. > >> > >> Even if it had a strict set of rules and maintainers are going to abuse > >> the system, > > > > Hey dude, I wasn't the one agreeing with a set of rules, that was you. > I'm > > just saying it's unwise to agree with a set of rules that can still be > > worked around easily. > > > >> they can mark any update as a critical security update and push it > through > >> too but then it is much more easier to point out who is responsible > >> compared to users just marking a random bug as a high priority one. > > > > I just noticed that nobody sent out a FESCo Meeting Summary for > > 2007-09-27[1]. There, we approved > > http://fedoraproject.org/wiki/LubomirKundrak/SecurityUpdateProcessDraftso > > the Fedora Security Response team would have to approve it before it > gets > > released as a security advisory. > > > > [1] At least there's a log at > > http://bpepple.fedorapeople.org/fesco/FESCo-2007-09-27.html > > > > Nobody's implemented that yet, though... Luke? This would be quite nice > to > > get done... :-) > > The code has been written and will make its way out with the next bodhi > upgrade. !nice, Thx Luke luke > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Xavier.t Lamien -- French Fedora Ambassador Fedora/EPEL Contributor | http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc at mwiriadi.id.au Tue Jan 1 15:10:36 2008 From: marc at mwiriadi.id.au (Marc Wiriadisastra) Date: Wed, 02 Jan 2008 00:10:36 +0900 Subject: Media tomb Message-ID: <1199200236.4348.13.camel@localhost.localdomain> Hey all, I found on the wishlist mediatomb which I have packaged and uploaded so far. I'm chasing a sponsor for the package and any feedback on the package itself. Cheers, Marc From rdieter at math.unl.edu Tue Jan 1 18:31:48 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 01 Jan 2008 12:31:48 -0600 Subject: mysterious buildsys/mock failure (maxima) Message-ID: Any pointers on debugging why maxima fails on the buildsys: http://koji.fedoraproject.org/koji/buildinfo?buildID=29572 but succeeds on a local mock build http://kdeforge.unl.edu/apt/kde-redhat/mock/fedora-9-x86_64-kde/maxima/ On the failure, build.log only reports (mysteriously): configure: error: unable to run gcl executable "gcl". ?? -- Rex From tcallawa at redhat.com Tue Jan 1 19:05:16 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 01 Jan 2008 14:05:16 -0500 Subject: mysterious buildsys/mock failure (maxima) In-Reply-To: References: Message-ID: <1199214316.4401.18.camel@localhost.localdomain> On Tue, 2008-01-01 at 12:31 -0600, Rex Dieter wrote: > Any pointers on debugging why maxima fails on the buildsys: > http://koji.fedoraproject.org/koji/buildinfo?buildID=29572 > but succeeds on a local mock build > http://kdeforge.unl.edu/apt/kde-redhat/mock/fedora-9-x86_64-kde/maxima/ > > On the failure, build.log only reports (mysteriously): > configure: error: unable to run gcl executable "gcl". Wow. That is cryptic. I wonder if it could be possible to extend koji to look for (and copy, if found) a config.log in the toplevel builddir if the build fails? If it doesn't exist, eh, no worries, but if its there, it is almost always useful to see. ~spot From rdieter at math.unl.edu Tue Jan 1 19:10:39 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 01 Jan 2008 13:10:39 -0600 Subject: mysterious buildsys/mock failure (maxima) References: <1199214316.4401.18.camel@localhost.localdomain> Message-ID: Tom "spot" Callaway wrote: > > On Tue, 2008-01-01 at 12:31 -0600, Rex Dieter wrote: >> Any pointers on debugging why maxima fails on the buildsys: >> http://koji.fedoraproject.org/koji/buildinfo?buildID=29572 >> but succeeds on a local mock build >> http://kdeforge.unl.edu/apt/kde-redhat/mock/fedora-9-x86_64-kde/maxima/ >> >> On the failure, build.log only reports (mysteriously): >> configure: error: unable to run gcl executable "gcl". > > Wow. That is cryptic. mebrown suggested (on irc) that it may well be selinux at play here (which is disabled on my own builder atm). -- Rex From dennis at ausil.us Tue Jan 1 19:37:36 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 1 Jan 2008 13:37:36 -0600 Subject: mysterious buildsys/mock failure (maxima) In-Reply-To: References: <1199214316.4401.18.camel@localhost.localdomain> Message-ID: <200801011337.37139.dennis@ausil.us> On Tuesday 01 January 2008, Rex Dieter wrote: > Tom "spot" Callaway wrote: > > On Tue, 2008-01-01 at 12:31 -0600, Rex Dieter wrote: > >> Any pointers on debugging why maxima fails on the buildsys: > >> http://koji.fedoraproject.org/koji/buildinfo?buildID=29572 > >> but succeeds on a local mock build > >> http://kdeforge.unl.edu/apt/kde-redhat/mock/fedora-9-x86_64-kde/maxima/ > >> > >> On the failure, build.log only reports (mysteriously): > >> configure: error: unable to run gcl executable "gcl". > > > > Wow. That is cryptic. > > mebrown suggested (on irc) that it may well be selinux at play here (which > is disabled on my own builder atm). > > -- Rex Our builders have selinux disabled also Dennis From nicolas.mailhot at laposte.net Tue Jan 1 21:27:40 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 01 Jan 2008 22:27:40 +0100 Subject: hardware-support comps group Message-ID: <1199222860.6673.6.camel@rousalka.dyndns.org> Hi, (and happy new year) Would it make sense to create a comps group for packages that need to be updated regularly for fedora to have good hardware support? (kernel, sane, xorg drivers, printer drivers, dcraw, etc) And then check regularly (via a script or human auditing) none of the bits in this group are stale? Or is it something best left to the maintainers of each of those packages? -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From dtimms at iinet.net.au Wed Jan 2 04:21:00 2008 From: dtimms at iinet.net.au (David Timms) Date: Wed, 02 Jan 2008 15:21:00 +1100 Subject: Kdump on Fedora - has it been superseded ? In-Reply-To: <1199177910.6754.1.camel@omar> References: <1199177910.6754.1.camel@omar> Message-ID: <477B112C.4010402@iinet.net.au> Mohammed Omar wrote: > Does Fedora supports kdump ? (especially F8) http://www.google.com.au/search?q=fedora+8+kdump http://docs.fedoraproject.org/release-notes/f8/iso/en_US/sn-Kernel.html#sn-Kernel-Flavors http://kbase.redhat.com/faq/FAQ_105_9036.shtm From the release notes, it seems like it should be available, however, I don't see any separate kernel-kdump kernels since FC6, with the latest being: http://download.fedora.redhat.com/pub/fedora/linux/core/updates/6/i386/ kernel-kdump-2.6.20-1.2962.fc6.i686.rpm 25-Jun-2007 Following the kernel spec: http://cvs.fedoraproject.org/viewcvs/rpms/kernel/F-7/kernel-2.6.spec?rev=1.3405&view=log shows: For F8: === Revision 1.78 - (view) (download) (annotate) - [select for diffs] Fri Aug 10 06:32:43 2007 UTC (4 months, 3 weeks ago) by roland spec fix for kdump kernel === For F7: === Revision 1.3214 - (view) (download) (annotate) - [select for diffs] Tue Jun 5 04:44:46 2007 UTC (6 months, 4 weeks ago) by davej * Tue Jun 05 2007 Dave Jones - Allow kdump to read /proc/kcore. (#241362) === Revision 1.2918 - (view) (download) (annotate) - [select for diffs] Sat Feb 3 17:13:17 2007 UTC (10 months, 4 weeks ago) by davej remove last its of -kdump for 686 === Revision 1.2869 - (view) (download) (annotate) - [select for diffs] Wed Dec 13 19:34:03 2006 UTC (12 months, 2 weeks ago) by davej kill off -kdump for 686/x86-64 === It seems the capability was disabled during F7 and is no longer supported ? If this is correct - the release notes {live} need an update, along with the howto at http://fedoraproject.org/wiki/FC6KdumpKexecHowTo DaveT. From dtimms at iinet.net.au Wed Jan 2 06:30:34 2008 From: dtimms at iinet.net.au (David Timms) Date: Wed, 02 Jan 2008 17:30:34 +1100 Subject: Media tomb - bug no ? In-Reply-To: <1199200236.4348.13.camel@localhost.localdomain> References: <1199200236.4348.13.camel@localhost.localdomain> Message-ID: <477B2F8A.2080803@iinet.net.au> Marc Wiriadisastra wrote: > I found on the wishlist mediatomb which I have packaged and uploaded so > far. I'm chasing a sponsor for the package and any feedback on the > package itself. Make it easier for your potential reviewers by: - giving the description {from the .spec} - including the review bug number DaveT. From poelstra at redhat.com Wed Jan 2 06:46:08 2008 From: poelstra at redhat.com (John Poelstra) Date: Tue, 01 Jan 2008 22:46:08 -0800 Subject: FeatureDictionary patches for KDE In-Reply-To: <1198317332.5768.357.camel@Jehannum> References: <1198317332.5768.357.camel@Jehannum> Message-ID: <477B3330.1070708@redhat.com> Caolan McNamara said the following on 12/22/2007 01:55 AM Pacific Time: > On Sat, 2007-12-22 at 09:32 +0000, Kevin Kofler wrote: >> I'm working on implementing: >> http://fedoraproject.org/wiki/Releases/FeatureDictionary >> in our KDE packages. This is the current situation: >> >> * KDE 4 uses an API called Sonnet for spellchecking. Sonnet already has an >> enchant backend >> >> - legacy KSpell: That API uses command-line spellcheckers using the "ispell >> pipe interface". ... I patched it to support the hunspell command line and its >> "ispell pipe interface" (which required only minor changes): > >> - KSpell2: This is the API KDE 4's Sonnet is derived from. It uses >> spellchecking libraries and a plugin architecture. I backported Sonnet's >> enchant backend plugin from kdelibs 4 SVN to KSpell2: > > Most excellent indeed, can you edit that wiki page and put those KDE > notes in the Details page ? > > C. > Is this feature intended to be accepted by FESCo for Fedora 9? If so, all of the sections of the page should be completed and the page category changed to CategoryProposedFedora9 so that it can be accepted and added to http://fedoraproject.org/wiki/Releases/9/FeatureList John From dmc.fedora at filteredperception.org Wed Jan 2 00:48:06 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 01 Jan 2008 18:48:06 -0600 Subject: f8 gripe#2: why did f8's pm-hibernate regress? Message-ID: <477ADF46.2040108@filteredperception.org> Can someone tell me if there is anything I can do to de-regress f8's pm-hibernate? What I mean is that it seems like in f7, pm-hibernate saved the kernel buffer/filesystem caches as well as the minimal needed stuff. Now in f8, every time I resume, system performance is crap because everything needs to be read piecemeal from disk into the caches again. My analysis is pure speculation based on my understanding of how you can tune that behaviour with suspend2(tux-on-ice). But it is very noticable and very annoying and very clearly a f7->f8 change. -dmc From dmc.fedora at filteredperception.org Wed Jan 2 00:51:38 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 01 Jan 2008 18:51:38 -0600 Subject: f8 gripe #3: infamous Load_Cycle_Count started hitting my laptop, FAQ? Message-ID: <477AE01A.6060302@filteredperception.org> Last gripe for the night- The infamous ubuntu Load_Cycle_Count laptop drive killer issue started hitting me when I upgraded from F7 to F8. Google searching for a fedora specific best practice resolution to this failed me. Any pointers? Quite simply, what is the prescribed way for me to run 'hdparm -B 254 /dev/sda' upon resume from suspend and hibernate? (or a better solution than that). -dmc From marc at mwiriadi.id.au Wed Jan 2 07:06:02 2008 From: marc at mwiriadi.id.au (Marc Wiriadisastra) Date: Wed, 02 Jan 2008 16:06:02 +0900 Subject: Media tomb - bug no ? In-Reply-To: <477B2F8A.2080803@iinet.net.au> References: <1199200236.4348.13.camel@localhost.localdomain> <477B2F8A.2080803@iinet.net.au> Message-ID: <477B37DA.9080406@mwiriadi.id.au> David Timms wrote: > Marc Wiriadisastra wrote: >> I found on the wishlist mediatomb which I have packaged and uploaded so >> far. I'm chasing a sponsor for the package and any feedback on the >> package itself. > Make it easier for your potential reviewers by: > - giving the description {from the .spec} > - including the review bug number > > DaveT. > Apologies will do in the future. Cheers, Marc From hughsient at gmail.com Wed Jan 2 07:38:36 2008 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 02 Jan 2008 07:38:36 +0000 Subject: f8 gripe #3: infamous Load_Cycle_Count started hitting my laptop, FAQ? In-Reply-To: <477AE01A.6060302@filteredperception.org> References: <477AE01A.6060302@filteredperception.org> Message-ID: <1199259516.4633.0.camel@hughsie-laptop> On Tue, 2008-01-01 at 18:51 -0600, Douglas McClendon wrote: > Quite simply, what is the prescribed way for me to run 'hdparm -B 254 > /dev/sda' upon resume from suspend and hibernate? (or a better > solution > than that). Well, the standard solution is a pm-utils resume script, but why do you need to run hdparm manually? Richard. From dmc.fedora at filteredperception.org Wed Jan 2 02:56:40 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 01 Jan 2008 20:56:40 -0600 Subject: f8 gripe #3: infamous Load_Cycle_Count started hitting my laptop, FAQ? In-Reply-To: <1199259516.4633.0.camel@hughsie-laptop> References: <477AE01A.6060302@filteredperception.org> <1199259516.4633.0.camel@hughsie-laptop> Message-ID: <477AFD68.6010407@filteredperception.org> Richard Hughes wrote: > On Tue, 2008-01-01 at 18:51 -0600, Douglas McClendon wrote: >> Quite simply, what is the prescribed way for me to run 'hdparm -B 254 >> /dev/sda' upon resume from suspend and hibernate? (or a better >> solution >> than that). > > Well, the standard solution is a pm-utils resume script, but why do you > need to run hdparm manually? Ok, thanks. rpm -ql pm-utils is informative enough and I should have gotten there without help. I just saw /etc/pm/ and no obvious documentation. But the basic issue may still be relevant, which is that I don't really know why I need to run hdparm manually. And back when I read all the ubuntu stuff relating to the issue, I ignored it after happily noticing my F7 wasn't affected (smartctl -i -a /dev/sda | grep -i cycle). Now that I hit it with F8, I notice it is so annoying that a single 'hdparm -B 254 /dev/sda' in rc.local isn't sufficient, because when I resume from hibernate/suspend, it starts incrementing relatively rapidly again. Basically I'm hoping to get some authoritative solution, but frankly I don't mind at all just disabling power saving on the drive at all (for the near future). Maybe it's an issue of tweaking the drive to retain pm settings over powercycle, but thats something I've never had to do or think about before, and don't really want to start now. Unless someone says that is the obvious best answer. I just don't want to think about. Someone please tell me how to just make it stop killing my drive, or why I'm misinterpreting something. (sony vaio vgn-n250e) -dmc > > Richard. > > From j.w.r.degoede at hhs.nl Wed Jan 2 09:05:03 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 02 Jan 2008 10:05:03 +0100 Subject: Media tomb - bug no ? In-Reply-To: <477B37DA.9080406@mwiriadi.id.au> References: <1199200236.4348.13.camel@localhost.localdomain> <477B2F8A.2080803@iinet.net.au> <477B37DA.9080406@mwiriadi.id.au> Message-ID: <477B53BF.5070406@hhs.nl> Marc Wiriadisastra wrote: > David Timms wrote: >> Marc Wiriadisastra wrote: >>> I found on the wishlist mediatomb which I have packaged and uploaded so >>> far. I'm chasing a sponsor for the package and any feedback on the >>> package itself. >> Make it easier for your potential reviewers by: >> - giving the description {from the .spec} >> - including the review bug number >> >> DaveT. >> > Apologies will do in the future. > Erm, You could have done that right here and now in your reply, this thread has sparked my interest but I don't feel like looking for that proverbial needle. Eegards, Hans From caolanm at redhat.com Wed Jan 2 09:17:26 2008 From: caolanm at redhat.com (Caolan McNamara) Date: Wed, 02 Jan 2008 09:17:26 +0000 Subject: FeatureDictionary patches for KDE In-Reply-To: <477B3330.1070708@redhat.com> References: <1198317332.5768.357.camel@Jehannum> <477B3330.1070708@redhat.com> Message-ID: <1199265446.26951.102.camel@Jehannum> On Tue, 2008-01-01 at 22:46 -0800, John Poelstra wrote: > Is this feature intended to be accepted by FESCo for Fedora 9? If so, > all of the sections of the page should be completed and the page > category changed to CategoryProposedFedora9 so that it can be accepted > and added to http://fedoraproject.org/wiki/Releases/9/FeatureList Lets just call it a minor enhancement or something, unless there's a volunteer interested in figuring out the right things to do wrt. formally featurizing it. C. From ben.lewis at benl.co.uk Wed Jan 2 09:40:09 2008 From: ben.lewis at benl.co.uk (Benjamin Lewis) Date: Wed, 2 Jan 2008 09:40:09 +0000 Subject: Kdump on Fedora - has it been superseded ? In-Reply-To: <477B112C.4010402@iinet.net.au> References: <1199177910.6754.1.camel@omar> <477B112C.4010402@iinet.net.au> Message-ID: <200801020940.14102.ben.lewis@benl.co.uk> On Wednesday 02 January 2008 04:21:00 am David Timms wrote: > Mohammed Omar wrote: > > Does Fedora supports kdump ? (especially F8) > > http://www.google.com.au/search?q=fedora+8+kdump > > http://docs.fedoraproject.org/release-notes/f8/iso/en_US/sn-Kernel.html#sn- >Kernel-Flavors http://kbase.redhat.com/faq/FAQ_105_9036.shtm > > From the release notes, it seems like it should be available, however, > I don't see any separate kernel-kdump kernels since FC6, with the latest > being: > http://download.fedora.redhat.com/pub/fedora/linux/core/updates/6/i386/ > kernel-kdump-2.6.20-1.2962.fc6.i686.rpm 25-Jun-2007 > > Following the kernel spec: > http://cvs.fedoraproject.org/viewcvs/rpms/kernel/F-7/kernel-2.6.spec?rev=1. >3405&view=log > > shows: > > For F8: > === > Revision 1.78 - (view) (download) (annotate) - [select for diffs] > Fri Aug 10 06:32:43 2007 UTC (4 months, 3 weeks ago) by roland > spec fix for kdump kernel > === > > For F7: > === > Revision 1.3214 - (view) (download) (annotate) - [select for diffs] > Tue Jun 5 04:44:46 2007 UTC (6 months, 4 weeks ago) by davej > * Tue Jun 05 2007 Dave Jones > - Allow kdump to read /proc/kcore. (#241362) > === > Revision 1.2918 - (view) (download) (annotate) - [select for diffs] > Sat Feb 3 17:13:17 2007 UTC (10 months, 4 weeks ago) by davej > remove last its of -kdump for 686 > === > Revision 1.2869 - (view) (download) (annotate) - [select for diffs] > Wed Dec 13 19:34:03 2006 UTC (12 months, 2 weeks ago) by davej > kill off -kdump for 686/x86-64 > === > > It seems the capability was disabled during F7 and is no longer supported ? Correct me if I'm wrong, but I thought the default kernel now supported kdump, except on one of the PPC architectures (may be PPC64). > > If this is correct - the release notes {live} need an update, along with > the howto at http://fedoraproject.org/wiki/FC6KdumpKexecHowTo > > DaveT. -- Benjamin Lewis Fedora Ambassador ben.lewis at benl.co.uk ----------------------------------------------------------------------- http://benl.co.uk./ PGP Key: 0x647E480C "In cases of major discrepancy, it is always reality that got it wrong" -- RFC 1118 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From stransky at redhat.com Wed Jan 2 09:43:20 2008 From: stransky at redhat.com (Martin Stransky) Date: Wed, 02 Jan 2008 10:43:20 +0100 Subject: xulrunner, Miro on f8 In-Reply-To: References: Message-ID: <477B5CB8.3020401@redhat.com> It doesn't seem to be related directly to Miro, if I'm right it's a glib symbol. Anyway, Miro compiles with my minimal patch and runs so it's a regression somewhere. Neal Becker wrote: > After installing firefox-3.0-0.beta2.3.fc9.x86_64 along with deps > (xulrunner), I just tried installing Miro-1.0-4.fc9.x86. > > Any ideas on this? > > miro > /usr/lib64/xulrunner-1.9pre > Traceback (most recent call last): > File "/usr/bin/miro.real", line 123, in > startapp() > File "/usr/bin/miro.real", line 58, in startapp > import singleclick > File "/usr/lib64/python2.5/site-packages/miro/singleclick.py", line 36, in > > import app > File "/usr/lib64/python2.5/site-packages/miro/app.py", line 610, in > > import frontend > File "/usr/lib64/python2.5/site-packages/miro/frontend.py", line 50, in > > import MozillaBrowser > ImportError: /usr/lib64/xulrunner-sdk-1.9pre/lib/libxul.so: undefined > symbol: g_assertion_message > > > From kevin.kofler at chello.at Wed Jan 2 09:55:00 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 2 Jan 2008 09:55:00 +0000 (UTC) Subject: FeatureDictionary patches for KDE References: <1198317332.5768.357.camel@Jehannum> <477B3330.1070708@redhat.com> <1199265446.26951.102.camel@Jehannum> Message-ID: Caolan McNamara redhat.com> writes: > Lets just call it a minor enhancement or something, unless there's a > volunteer interested in figuring out the right things to do wrt. > formally featurizing it. I've filled in the last missing section ("Documentation") and changed the category, that should be all that's needed. Kevin Kofler From mmaslano at redhat.com Wed Jan 2 10:01:20 2008 From: mmaslano at redhat.com (Marcela Maslanova) Date: Wed, 02 Jan 2008 11:01:20 +0100 Subject: heads up: tcl and tk 8.5 Message-ID: <477B60F0.6020406@redhat.com> New tcl and tk 8.5 was released. I'd like to push it to rawhide as soon as possible. The list of dependent packages could be found in this draft: https://fedoraproject.org/wiki/MarcelaMaslanova/Draft/tcl8.5 The maintainers of dependent packages should fix them according to http://fedoraproject.org/wiki/PackagingDrafts/Tcl Marcela Maslanova From casimiro.barreto at gmail.com Wed Jan 2 10:20:34 2008 From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto) Date: Wed, 02 Jan 2008 08:20:34 -0200 Subject: Cannot upgrade from Rel 7 to Rel 8 Message-ID: <477B6572.6050602@gmail.com> Hello, Last week I tried to upgrade from Rel. 7 to Rel. 8. System got stuck while checking for dependencies. Progress bar goes almost to 100% and then freezes there (+12 hours). As the box is relatively well configured (Intel Core Duo, 2GBytes RAM) and as I don't have problems with Rel. 7, I guess it must be a scalability problem with the dependency checking in Rel. 8. If someone had the same problem and was able to fix it, please suggestions (other than simply reinstalling everything) will be really welcome. Best regards and happy 2008 for all !!! Casimiro -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at homer.se Wed Jan 2 10:25:09 2008 From: lars at homer.se (Lars E. Pettersson) Date: Wed, 02 Jan 2008 11:25:09 +0100 Subject: Cannot upgrade from Rel 7 to Rel 8 In-Reply-To: <477B6572.6050602@gmail.com> References: <477B6572.6050602@gmail.com> Message-ID: <477B6685.2040102@homer.se> On 01/02/2008 11:20 AM, Casimiro de Almeida Barreto wrote: > If someone had the same problem and was able to fix it, please > suggestions (other than simply reinstalling everything) will be > really welcome. Take a look at https://bugzilla.redhat.com/show_bug.cgi?id=372011 As can be read, the Fedoraunity re-spin did it for me... /Lars -- Lars E. Pettersson http://www.sm6rpz.se/ From caolanm at redhat.com Wed Jan 2 10:27:18 2008 From: caolanm at redhat.com (Caolan McNamara) Date: Wed, 02 Jan 2008 10:27:18 +0000 Subject: FeatureDictionary patches for KDE In-Reply-To: References: <1198317332.5768.357.camel@Jehannum> <477B3330.1070708@redhat.com> <1199265446.26951.102.camel@Jehannum> Message-ID: <1199269638.26951.107.camel@Jehannum> On Wed, 2008-01-02 at 09:55 +0000, Kevin Kofler wrote: > Caolan McNamara redhat.com> writes: > > Lets just call it a minor enhancement or something, unless there's a > > volunteer interested in figuring out the right things to do wrt. > > formally featurizing it. > > I've filled in the last missing section ("Documentation") and changed the > category, that should be all that's needed. Thanks, that's the kind of thing that'd have been a 6 week task for me and required much amounts of swearing and shaking fists at the sky :-) C. From marc at mwiriadi.id.au Wed Jan 2 10:37:17 2008 From: marc at mwiriadi.id.au (Marc Wiriadisastra) Date: Wed, 02 Jan 2008 19:37:17 +0900 Subject: Media tomb - bug no ? In-Reply-To: <477B53BF.5070406@hhs.nl> References: <1199200236.4348.13.camel@localhost.localdomain> <477B2F8A.2080803@iinet.net.au> <477B37DA.9080406@mwiriadi.id.au> <477B53BF.5070406@hhs.nl> Message-ID: <1199270237.16004.1.camel@localhost.localdomain> On Wed, 2008-01-02 at 10:05 +0100, Hans de Goede wrote: > Marc Wiriadisastra wrote: > > David Timms wrote: > >> Marc Wiriadisastra wrote: > >>> I found on the wishlist mediatomb which I have packaged and uploaded so > >>> far. I'm chasing a sponsor for the package and any feedback on the > >>> package itself. > >> Make it easier for your potential reviewers by: > >> - giving the description {from the .spec} > >> - including the review bug number > >> > >> DaveT. > >> > > Apologies will do in the future. > > > > Erm, > > You could have done that right here and now in your reply, this thread has > sparked my interest but I don't feel like looking for that proverbial needle. > > Eegards, > > Hans > https://bugzilla.redhat.com/show_bug.cgi?id=426733 The reason I didn't is because someone is sponsoring me, I didn't think anyone actually wanted to see the details still. Cheers, Marc From opensource at till.name Wed Jan 2 10:59:12 2008 From: opensource at till.name (Till Maas) Date: Wed, 02 Jan 2008 11:59:12 +0100 Subject: f8 gripe#2: why did f8's pm-hibernate regress? In-Reply-To: <477ADF46.2040108@filteredperception.org> References: <477ADF46.2040108@filteredperception.org> Message-ID: <200801021159.17964.opensource@till.name> On Mi Januar 2 2008, Douglas McClendon wrote: > Can someone tell me if there is anything I can do to de-regress f8's > pm-hibernate? pm-utils hibernation code does not differ much between f7 and f8. > My analysis is pure speculation based on my understanding of how you can > tune that behaviour with suspend2(tux-on-ice). But it is very noticable > and very annoying and very clearly a f7->f8 change. I guess it is then a change in the kernel, but afaik the f7 and f8 kernel are very similiar, too. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From opensource at till.name Wed Jan 2 11:04:28 2008 From: opensource at till.name (Till Maas) Date: Wed, 02 Jan 2008 12:04:28 +0100 Subject: f8 gripe #3: infamous Load_Cycle_Count started hitting my laptop , FAQ? In-Reply-To: <477AFD68.6010407@filteredperception.org> References: <477AE01A.6060302@filteredperception.org> <1199259516.4633.0.camel@hughsie-laptop> <477AFD68.6010407@filteredperception.org> Message-ID: <200801021204.29184.opensource@till.name> On Mi Januar 2 2008, Douglas McClendon wrote: > But the basic issue may still be relevant, which is that I don't really > know why I need to run hdparm manually. And back when I read all the > ubuntu stuff relating to the issue, I ignored it after happily noticing > my F7 wasn't affected (smartctl -i -a /dev/sda | grep -i cycle). > > Now that I hit it with F8, I notice it is so annoying that a single > 'hdparm -B 254 /dev/sda' in rc.local isn't sufficient, because when I > resume from hibernate/suspend, it starts incrementing relatively rapidly > again. Do you know how to query the value that needs to be passed to hdparm -B to keep the current situation? That would make it possible to store the value when suspending/hiberanting and restore it when resuming/thawing. But better would be imho, when the drive would not forget the setting in the first place, maybe this happens because of a change in the kernel. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From kanarip at kanarip.com Wed Jan 2 11:17:14 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 2 Jan 2008 12:17:14 +0100 (CET) Subject: Cannot upgrade from Rel 7 to Rel 8 In-Reply-To: <477B6572.6050602@gmail.com> References: <477B6572.6050602@gmail.com> Message-ID: <43710.131.211.184.75.1199272634.squirrel@mail.kanarip.com> Casimiro de Almeida Barreto wrote: > Hello, > > Last week I tried to upgrade from Rel. 7 to Rel. 8. System got stuck while checking for dependencies. Progress bar goes almost to 100% and then freezes there (+12 hours). As the box is relatively well configured (Intel Core Duo, 2GBytes RAM) and as I don't have problems with Rel. 7, I guess it must be a scalability problem with the dependency checking in Rel. 8. > > If someone had the same problem and was able to fix it, please suggestions (other than simply reinstalling everything) will be really welcome. > The Fedora Unity Re-Spin at http://spins.fedoraunity.org/spins will fix this. Mount the original DVD somewhere, and use: jigdo-lite --scan /mount/point/of/original/dvd \ http://jigdo.fedoraunity.org/templates/20071218/Fedora-Unity-20071218-8.jigdo Kind regards, Jeroen van Meeuwen -kanarip From pertusus at free.fr Wed Jan 2 11:32:00 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 2 Jan 2008 12:32:00 +0100 Subject: libdap sonames bump Message-ID: <20080102113159.GD2555@free.fr> Hello, The libdap soname changed. My guess is that a simple rebuild will be enough, since the API change are not big. I am rebuilding my packages There is also gdal-0:1.4.2-3.fc8.src And (though there is no libdap-devel BR?) octave-forge-0:20071212-5.fc9.i386 -- Pat From dmc.fedora at filteredperception.org Wed Jan 2 05:45:51 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 01 Jan 2008 23:45:51 -0600 Subject: f8 gripe #3: infamous Load_Cycle_Count started hitting my laptop , FAQ? In-Reply-To: <200801021204.29184.opensource@till.name> References: <477AE01A.6060302@filteredperception.org> <1199259516.4633.0.camel@hughsie-laptop> <477AFD68.6010407@filteredperception.org> <200801021204.29184.opensource@till.name> Message-ID: <477B250F.5040800@filteredperception.org> Till Maas wrote: > On Mi Januar 2 2008, Douglas McClendon wrote: > >> But the basic issue may still be relevant, which is that I don't really >> know why I need to run hdparm manually. And back when I read all the >> ubuntu stuff relating to the issue, I ignored it after happily noticing >> my F7 wasn't affected (smartctl -i -a /dev/sda | grep -i cycle). >> >> Now that I hit it with F8, I notice it is so annoying that a single >> 'hdparm -B 254 /dev/sda' in rc.local isn't sufficient, because when I >> resume from hibernate/suspend, it starts incrementing relatively rapidly >> again. > > Do you know how to query the value that needs to be passed to hdparm -B to > keep the current situation? Ok, hdparm -I does get it, though perhaps in drive-specific way. That would make it possible to store the value > when suspending/hiberanting and restore it when resuming/thawing. > But better would be imho, when the drive would not forget the setting in the > first place, maybe this happens because of a change in the kernel. Or maybe during the 2 days when I let vista live on the laptop between f7 and f8, it did something nasty, beyond downloading and installing 200+ updates despite explicit requests not to... Thanks, I think I'm now armed with the tools I need to solve this. I'm just a bit curious that I haven't seen anyone else run into this, since it was such a brouhaha for a while there with ubuntu. -dmc From fedora at leemhuis.info Wed Jan 2 11:51:42 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 02 Jan 2008 12:51:42 +0100 Subject: f8 gripe #3: infamous Load_Cycle_Count started hitting my laptop, FAQ? In-Reply-To: <1199259516.4633.0.camel@hughsie-laptop> References: <477AE01A.6060302@filteredperception.org> <1199259516.4633.0.camel@hughsie-laptop> Message-ID: <477B7ACE.8040202@leemhuis.info> On 02.01.2008 08:38, Richard Hughes wrote: > On Tue, 2008-01-01 at 18:51 -0600, Douglas McClendon wrote: >> Quite simply, what is the prescribed way for me to run 'hdparm -B 254 >> /dev/sda' upon resume from suspend and hibernate? (or a better >> solution >> than that). /me runs '/sbin/hdparm -B 255 /dev/sda' to disable PM for the hard disk completely, as the hard disk enters PM every few seconds otherwise and wakes up from it just a moment after > Well, the standard solution is a pm-utils resume script, but why do you > need to run hdparm manually? What about bootup? And what is about a real solution that "just works"? My current view on the whole problem is this: 1. there are some laptops out there (including my Dell Latitude D630) that have a very aggressive default setting for hard disk power management set from the BIOS by default 2. the kernel doesn't touch the PM setting for the hard disk 3. Fedora doesn't touch the PM setting for the hard disk 4. we don't care much about hard disk power management -- there are a lot of things written to disk (journal flushed, log files, ...) every few seconds 5. in combination with the aggressive BIOS default (one iirc can't modify in the BIOS Setup) that leads to a bad behavior, as the hard disk loads and unloads its heads very very often If the above is correct I'd say the best default for Fedora due to 4. and 1. (and it's effects in 5.) would be to disable hard disk power management completely by default if that doesn't do any hard to systems that don't fall in category "1.". Cu knurd From dmc.fedora at filteredperception.org Wed Jan 2 05:53:09 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 01 Jan 2008 23:53:09 -0600 Subject: f8 gripe#2: why did f8's pm-hibernate regress? In-Reply-To: <200801021159.17964.opensource@till.name> References: <477ADF46.2040108@filteredperception.org> <200801021159.17964.opensource@till.name> Message-ID: <477B26C5.2000605@filteredperception.org> Till Maas wrote: > On Mi Januar 2 2008, Douglas McClendon wrote: >> Can someone tell me if there is anything I can do to de-regress f8's >> pm-hibernate? > > pm-utils hibernation code does not differ much between f7 and f8. > >> My analysis is pure speculation based on my understanding of how you can >> tune that behaviour with suspend2(tux-on-ice). But it is very noticable >> and very annoying and very clearly a f7->f8 change. > > I guess it is then a change in the kernel, but afaik the f7 and f8 kernel are > very similiar, too. Again, mainly I posted this to see if anyone else is noticing the same thing. Basic behavior: I keep several main apps open in multiple desktops, often hotkey switching between desktops. First thing I do on resume is often cycle through my desktops (thunderbird, firefox, gnome-terminal, rhythmbox....). In F7, cycling would be as responsive after resume as immediately prior. Now with F8, it thrashes reading from disk for a couple seconds between each desktop/application switch. Very gross. And suspend2(tux-on-ice) does have an explicit config variable you can tune, if you actually want to optimize for hibernation speed rather than post-resume performance. So my reaction was that the non-user-tweakable version in fedora's suspend1 must have changed from f7-f8. Yes, kernel. But I figure I'd gripe here since I was in the mood to gripe. I'm still hoping I can get someone else here to confirm/deny the significant change in behavior, and better yet explain, and better yet, explain how to revert. -dmc From opensource at till.name Wed Jan 2 11:55:58 2008 From: opensource at till.name (Till Maas) Date: Wed, 02 Jan 2008 12:55:58 +0100 Subject: f8 gripe #3: infamous Load_Cycle_Count started hitting my laptop , FAQ? In-Reply-To: <477B250F.5040800@filteredperception.org> References: <477AE01A.6060302@filteredperception.org> <200801021204.29184.opensource@till.name> <477B250F.5040800@filteredperception.org> Message-ID: <200801021256.07299.opensource@till.name> On Mi Januar 2 2008, Douglas McClendon wrote: > Thanks, I think I'm now armed with the tools I need to solve this. I'm > just a bit curious that I haven't seen anyone else run into this, since > it was such a brouhaha for a while there with ubuntu. There is a bug report about this: https://bugzilla.redhat.com/show_bug.cgi?id=382061 Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From dmc.fedora at filteredperception.org Wed Jan 2 12:23:22 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Wed, 02 Jan 2008 06:23:22 -0600 Subject: f8 gripe #3: infamous Load_Cycle_Count started hitting my laptop, FAQ? In-Reply-To: <477B7ACE.8040202@leemhuis.info> References: <477AE01A.6060302@filteredperception.org> <1199259516.4633.0.camel@hughsie-laptop> <477B7ACE.8040202@leemhuis.info> Message-ID: <477B823A.6090701@filteredperception.org> Thorsten Leemhuis wrote: > On 02.01.2008 08:38, Richard Hughes wrote: >> On Tue, 2008-01-01 at 18:51 -0600, Douglas McClendon wrote: >>> Quite simply, what is the prescribed way for me to run 'hdparm -B 254 >>> /dev/sda' upon resume from suspend and hibernate? (or a better >>> solution >>> than that). > > /me runs '/sbin/hdparm -B 255 /dev/sda' to disable PM for the hard disk > completely, as the hard disk enters PM every few seconds otherwise and > wakes up from it just a moment after > >> Well, the standard solution is a pm-utils resume script, but why do you >> need to run hdparm manually? > > What about bootup? bootup was the easy part for me (rc.local), I needed some help finding the right hooks for post-resume. This is because, as I just verified, the setting is lost during pm-hibernate. Why this didn't seem to hit me before f7->f8, I'm at a loss. > > And what is about a real solution that "just works"? My current view on > the whole problem is this: > > 1. there are some laptops out there (including my Dell Latitude D630) > that have a very aggressive default setting for hard disk power > management set from the BIOS by default > 2. the kernel doesn't touch the PM setting for the hard disk > 3. Fedora doesn't touch the PM setting for the hard disk Something changed in fedora and/or kernel within the last 6 months. When the ubuntu brouhaha flared up, I checked, and though seeing a high number (100,000), it was not increasing at an unreasonable rate. I checked several times across a span of weeks. All of a sudden after I upgraded to f8 (and with vista in between for a couple days) I ran into the issue, as described. > 4. we don't care much about hard disk power management -- there are a > lot of things written to disk (journal flushed, log files, ...) every > few seconds > 5. in combination with the aggressive BIOS default (one iirc can't > modify in the BIOS Setup) that leads to a bad behavior, as the hard disk > loads and unloads its heads very very often Correct, on my vaio vgn-n250e, the bios has none of the typical workstation PM settings. Dumbed down just the way I like it (really, until something like this happens) > If the above is correct I'd say the best default for Fedora due to 4. > and 1. (and it's effects in 5.) would be to disable hard disk power > management completely by default if that doesn't do any hard to systems > that don't fall in category "1.". That sounds good to me for the timebeing. Of course I used to have a different laptop with a noisy drive, which I liked to leave powered on, and somehow got set up so that it would actually be spun down 95% of the time when idle. (so that it wouldn't drive me crazy when trying to sleep within earshot of it) Sigh... Maybe one answer is just wait for solid state to replace everything.... -dmc From dtimms at iinet.net.au Wed Jan 2 12:22:42 2008 From: dtimms at iinet.net.au (David Timms) Date: Wed, 02 Jan 2008 23:22:42 +1100 Subject: Kdump on Fedora - has it been superseded ? In-Reply-To: <200801020940.14102.ben.lewis@benl.co.uk> References: <1199177910.6754.1.camel@omar> <477B112C.4010402@iinet.net.au> <200801020940.14102.ben.lewis@benl.co.uk> Message-ID: <477B8212.3050801@iinet.net.au> Benjamin Lewis wrote: > On Wednesday 02 January 2008 04:21:00 am David Timms wrote: >> Mohammed Omar wrote: >>> Does Fedora supports kdump ? (especially F8) >> http://www.google.com.au/search?q=fedora+8+kdump >> >> http://docs.fedoraproject.org/release-notes/f8/iso/en_US/sn-Kernel.html#sn- >> Kernel-Flavors http://kbase.redhat.com/faq/FAQ_105_9036.shtm >> >> From the release notes, it seems like it should be available, however, >> I don't see any separate kernel-kdump kernels since FC6, with the latest >> being: >> http://download.fedora.redhat.com/pub/fedora/linux/core/updates/6/i386/ >> kernel-kdump-2.6.20-1.2962.fc6.i686.rpm 25-Jun-2007 >> >> Following the kernel spec: >> http://cvs.fedoraproject.org/viewcvs/rpms/kernel/F-7/kernel-2.6.spec?rev=1. >> 3405&view=log >> >> shows: >> >> For F8: >> === >> Revision 1.78 - (view) (download) (annotate) - [select for diffs] >> Fri Aug 10 06:32:43 2007 UTC (4 months, 3 weeks ago) by roland >> spec fix for kdump kernel >> === >> >> For F7: >> === >> Revision 1.3214 - (view) (download) (annotate) - [select for diffs] >> Tue Jun 5 04:44:46 2007 UTC (6 months, 4 weeks ago) by davej >> * Tue Jun 05 2007 Dave Jones >> - Allow kdump to read /proc/kcore. (#241362) >> === >> Revision 1.2918 - (view) (download) (annotate) - [select for diffs] >> Sat Feb 3 17:13:17 2007 UTC (10 months, 4 weeks ago) by davej >> remove last its of -kdump for 686 >> === >> Revision 1.2869 - (view) (download) (annotate) - [select for diffs] >> Wed Dec 13 19:34:03 2006 UTC (12 months, 2 weeks ago) by davej >> kill off -kdump for 686/x86-64 >> === >> >> It seems the capability was disabled during F7 and is no longer supported ? > > Correct me if I'm wrong, but I thought the default kernel now supported kdump, > except on one of the PPC architectures (may be PPC64). > >> If this is correct - the release notes {live} need an update, along with >> the howto at http://fedoraproject.org/wiki/FC6KdumpKexecHowTo You may be quite correct, and wes replied the same on the f-test list. If that is the case- how do we go about actually using it ? ie following along with the FC6KdumpKexecHowTo {where possible}: # yum install kexec-tools crash # yum --enablerepo=\*debuginfo install kernel-debuginfo - add the parameters to grub as suggested. - manually service kdump start or restart the machine since the service defaults to start. - cause a crash with the cat /proc command. Result I got was mouse stopped working, with some colour changes in the clock and my desktop background image. After 4 minutes, tried a heap of keys like ctrl-alt-f1 etc, ctrl-alt-backspace, alt-tab etc. Numlock still operational {ie led toggles}. Pressing ctrl-alt-delete did initiate a reboot. Checking in /var/crash/ showed no files. David Timms. From buildsys at redhat.com Wed Jan 2 12:33:46 2008 From: buildsys at redhat.com (Build System) Date: Wed, 2 Jan 2008 07:33:46 -0500 Subject: rawhide report: 20080102 changes Message-ID: <200801021233.m02CXkQ7021700@porkchop.devel.redhat.com> Updated Packages: anaconda-11.4.0.13-1 -------------------- * Tue Jan 01 2008 Jeremy Katz - 11.4.0.13-1 - Make it obvious which partitions are being formatted and encrypted (katzj) - Set initial sensitivity of encrypt button correctly (katzj) - Fix traceback on invalid passphrase (#426887) (katzj) - Use mkstemp() instead of tempnam() (katzj) - Don't resize filesystems which are being formatted (#426466) (katzj) - Add cracklib-dicts (#426444) (katzj) - Fix build (notting) bes-3.5.3-2.fc9 --------------- * Mon Dec 17 2007 Patrice Dumas 3.5.3-2 - update to 3.5.3 clamav-0.92-6.fc9 ----------------- * Tue Jan 01 2008 Enrico Scholz - 0.92-6 - redisabled unrar stuff completely by using clean sources - splitted -milter subpackage into pieces to allow use without sendmail (#239037) * Tue Jan 01 2008 Enrico Scholz - 0.92-5 - use a better way to disable RPATH-generation (needed for '--with unrar' builds) * Mon Dec 31 2007 Enrico Scholz - 0.92-4 - added a README.fedora to the milter package (#240610) - ship original sources again; unrar is now licensed correctly (no more stolen code put under GPL). Nevertheless, this license is not GPL compatible, and to allow libclamav to be used by GPL applications, unrar is disabled by a ./configure switch. - use pkg-config in clamav-config to emulate --cflags and --libs operations (fixes partly multilib issues) - registered some more auto-updated files and marked them as %ghost e2fsprogs-1.40.4-2.fc9 ---------------------- * Tue Jan 01 2008 Eric Sandeen 1.40.4-2 - Add new uidd files to specfile * Tue Jan 01 2008 Eric Sandeen 1.40.4-1 - New upstream version, drop several now-upstream patches. * Tue Jan 01 2008 Eric Sandeen 1.40.2-15 - Drop resize_inode removal patch from tune2fs; ostensibly was for old kernels which could not mount, but seems to be fine. - Drop pottcdate removal patch, and don't rebuild .po files, causes multilib problems and we generally shouldn't rebuild. - Drop multilib patch; wrapper header should take care of this now. - Drop ->open rename, Fedora seems ok with this now. ekg-1.7-4.fc9 ------------- * Tue Jan 01 2008 Dominik Mierzejewski 1.7-4 - use luit wrapper to work around lack of unicode support (bug #210745) - fix line endings and docs encoding in prep instead of install section * Thu Dec 06 2007 Release Engineering - 1.7-3 - Rebuild for deps * Tue Aug 28 2007 Dominik Mierzejewski 1.7-2 - rebuilt for ppc32 - update license tag guile-lib-0.1.6-1.fc9 --------------------- * Tue Jan 01 2008 Xavier Lamien - 0.1.6-1 - Updated Release. libdap-3.7.10-1.fc9 ------------------- * Mon Dec 17 2007 Patrice Dumas 3.7.10-1 - update to 3.7.10 nautilus-flac-converter-0.0.3-1.fc9 ----------------------------------- * Tue Jan 01 2008 Brian Pepple - 0.0.3-1 - Update to 0.0.3. - Bump min version of nautilus needed. - Drop extensiondir patch. fixed upstream. netembryo-0.0.5-1.fc9 --------------------- * Tue Jan 01 2008 Dominik Mierzejewski 0.0.5-1 - updated to 0.0.5 (security update) perl-Class-Factory-Util-1.7-2.fc9 --------------------------------- * Tue Jan 01 2008 Ralf Cors??pius 1.7-2 - Adjust License-tag. - BR: perl(Test::More) (BZ 419631). - BR: perl(Test::Pod), perl(Test::Pod::Coverage). perl-DateTime-Format-MySQL-0.04-5.fc9 ------------------------------------- * Tue Jan 01 2008 Ralf Cors??pius 0.04-5 - Adjust License-tag. - Add BR: perl(Test::More) (BZ 419631). - Minor spec cosmetics. perl-File-ReadBackwards-1.04-4.fc9 ---------------------------------- * Wed Jan 02 2008 Ralf Cors??pius 1.04-4 - BR: perl(Test::More) (BZ 419613). - Adjust License-tag. perl-File-Type-0.22-5.fc9 ------------------------- * Wed Jan 02 2008 Ralf Cors??pius 0.22-5 - BR: perl(Test::More) (BZ 419631). - Adjust License-tag. perl-OpenFrame-3.05-7.fc9 ------------------------- * Wed Jan 02 2008 Ralf Cors??pius 3.05-7 - BR: perl(Test::Simple) (BZ 419631). perl-Pipeline-3.12-5.fc9 ------------------------ * Wed Jan 02 2008 Ralf Cors??pius 3.12-5 - BR: perl(Test::More) (BZ 419631). - Adjust License-tag. perl-SUPER-1.16-2.fc9 --------------------- * Wed Jan 02 2008 Ralf Cors??pius 1.16-2 - Adjust License-tag. - BR: perl(Test::Simple) (BZ 419631). perl-Set-Infinite-0.61-4.fc9 ---------------------------- * Wed Jan 02 2008 Ralf Cors??pius 0.61-4 - Adjust License-tag. - BR: perl(Test::More) (BZ 419631). perl-Spiffy-0.30-8.fc9 ---------------------- * Wed Jan 02 2008 Ralf Cors??pius 0.30-8 - Adjust License-tag. - BR: perl(Test::More) (BZ 419631). pybackpack-0.5.4-2.fc9 ---------------------- * Tue Jan 01 2008 Andy Price - 0.5.4-2 - Take ownership of .egg-info file in >= Fedora 9 * Tue Jan 01 2008 Andy Price - 0.5.4-1 - Updated RPM to 0.5.4 qucs-0.0.13-1.fc9 ----------------- * Tue Jan 01 2008 Eric Tanguy - 0.0.13-1 - Update to 0.0.13 rogue-5.4.5-1.fc9 ----------------- * Tue Jan 01 2008 Wart 5.4.5-1 - Update to 5.4.5 - Drop two files that are now included in the upstream tarball roxterm-1.9.0-1.fc9 ------------------- * Tue Jan 01 2008 Sebastian Vahl - 1.9.0-1 - new upstream version: 1.9.0 scim-chewing-0.3.1-10.fc9 ------------------------- * Thu Dec 20 2007 Caius Chance 0.3.1-10.fc9 - Resolves: rhbz#237924 (Last candidate on lookup table is not a valid candidate.) <<< Refit lookup table page size for last lookup page. * Wed Jul 04 2007 Jens Petersen - remove with_libstdc_preview macro scribes-0.3.3.2-1.fc9 --------------------- * Tue Jan 01 2008 Peter Gordon - 0.3.3.2-1 - Update to new upstream release (0.3.3.2). sear-0.6.3-8.fc9 ---------------- * Tue Jan 01 2008 Wart 0.6.3-8 - Add patch to support locally installed media files from sear-media (BZ #425774) tre-0.7.5-4.fc9 --------------- * Tue Jan 01 2008 Dominik Mierzejewski 0.7.5-4 - fix build in rawhide (include python egg-info file) * Wed Oct 31 2007 Dominik Mierzejewski 0.7.5-3 - include python bindings (bug #355241) - fix chicken-and-egg problem when building python bindings * Wed Aug 29 2007 Dominik Mierzejewski 0.7.5-2 - rebuild for BuildID - update license tag twinkle-1.1-4.fc9 ----------------- * Tue Jan 01 2008 Kevin Fenzi - 1.1-4 - Add patch for message waiting bug (fixes #427068) xmlrpc-c-1.06.23-1.fc9 ---------------------- * Wed Jan 02 2008 Enrico Scholz - 1.06.23-1 - use correct pkg-config script for 'xmlrpc-config abyss-server' output (#355411) - updated to 1.06.23 (#355411) Broken deps for i386 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-client - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libcrypto.so.6 d4x - 2.5.7.1-3.fc7.i386 requires libssl.so.6 d4x - 2.5.7.1-3.fc7.i386 requires libcrypto.so.6 dap-freeform_handler - 3.7.5-2.fc8.i386 requires libdapserver.so.3 dap-freeform_handler - 3.7.5-2.fc8.i386 requires libdap.so.6 dap-hdf4_handler - 3.7.5-3.fc8.i386 requires libdapserver.so.3 dap-hdf4_handler - 3.7.5-3.fc8.i386 requires libdap.so.6 dap-netcdf_handler - 3.7.6-5.fc8.i386 requires libdapserver.so.3 dap-netcdf_handler - 3.7.6-5.fc8.i386 requires libdap.so.6 dap-server - 3.7.4-4.fc8.i386 requires libdapserver.so.3 dap-server - 3.7.4-4.fc8.i386 requires libdapclient.so.1 dap-server - 3.7.4-4.fc8.i386 requires libdap.so.6 epiphany - 2.21.4-1.fc9.i386 requires libxpcom_core.so epiphany - 2.21.4-1.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.i386 requires libgtkembedmoz.so epiphany-devel - 2.21.4-1.fc9.i386 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires libgtkembedmoz.so gdal - 1.4.2-3.fc8.i386 requires libdapserver.so.3 gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gdal - 1.4.2-3.fc8.i386 requires libdapclient.so.1 gdal - 1.4.2-3.fc8.i386 requires libdap.so.6 gnome-web-photo - 0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.i386 requires libgtkembedmoz.so grads - 1.9b4-21.fc8.i386 requires libdap.so.6 grass - 6.2.2-2.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 libnc-dap - 3.7.0-8.fc9.i386 requires libdapclient.so.1 libnc-dap - 3.7.0-8.fc9.i386 requires libdap.so.6 libopensync-plugin-synce - 0.22-4.fc8.i386 requires libopensync.so.0 liferea - 1.4.10-1.fc9.i386 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.i386 requires libgtkembedmoz.so mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libcrypto.so.6 multisync - 0.91.0-1.fc7.i386 requires libopensync.so.0 multisync - 0.91.0-1.fc7.i386 requires libosengine.so.0 multisync-gui - 0.91.0-1.fc7.i386 requires libopensync.so.0 multisync-gui - 0.91.0-1.fc7.i386 requires libosengine.so.0 octave-forge - 20071212-5.fc9.i386 requires libdapclient.so.1 octave-forge - 20071212-5.fc9.i386 requires libdap.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 python-gammu - 0.22-3.fc8.i386 requires libGammu.so.2 xca - 0.6.4-1.fc8.i386 requires libcrypto.so.6 Broken deps for x86_64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libssl.so.6()(64bit) dap-freeform_handler - 3.7.5-2.fc8.x86_64 requires libdap.so.6()(64bit) dap-freeform_handler - 3.7.5-2.fc8.x86_64 requires libdapserver.so.3()(64bit) dap-freeform_handler - 3.7.5-2.fc8.i386 requires libdapserver.so.3 dap-freeform_handler - 3.7.5-2.fc8.i386 requires libdap.so.6 dap-hdf4_handler - 3.7.5-3.fc8.x86_64 requires libdap.so.6()(64bit) dap-hdf4_handler - 3.7.5-3.fc8.x86_64 requires libdapserver.so.3()(64bit) dap-netcdf_handler - 3.7.6-5.fc8.i386 requires libdapserver.so.3 dap-netcdf_handler - 3.7.6-5.fc8.i386 requires libdap.so.6 dap-netcdf_handler - 3.7.6-5.fc8.x86_64 requires libdap.so.6()(64bit) dap-netcdf_handler - 3.7.6-5.fc8.x86_64 requires libdapserver.so.3()(64bit) dap-server - 3.7.4-4.fc8.x86_64 requires libdapclient.so.1()(64bit) dap-server - 3.7.4-4.fc8.x86_64 requires libdap.so.6()(64bit) dap-server - 3.7.4-4.fc8.x86_64 requires libdapserver.so.3()(64bit) epiphany - 2.21.4-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.x86_64 requires libgtkembedmoz.so()(64bit) epiphany - 2.21.4-1.fc9.x86_64 requires libxpcom_core.so()(64bit) epiphany-devel - 2.21.4-1.fc9.i386 requires gecko-devel = 0:1.8.1.10 epiphany-devel - 2.21.4-1.fc9.x86_64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libdapclient.so.1()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libdap.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libdapserver.so.3()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.i386 requires libdapserver.so.3 gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gdal - 1.4.2-3.fc8.i386 requires libdapclient.so.1 gdal - 1.4.2-3.fc8.i386 requires libdap.so.6 gnome-web-photo - 0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) grads - 1.9b4-21.fc8.x86_64 requires libdap.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libssl.so.6()(64bit) kazehakase - 0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 libnc-dap - 3.7.0-8.fc9.x86_64 requires libdapclient.so.1()(64bit) libnc-dap - 3.7.0-8.fc9.x86_64 requires libdap.so.6()(64bit) libnc-dap - 3.7.0-8.fc9.i386 requires libdapclient.so.1 libnc-dap - 3.7.0-8.fc9.i386 requires libdap.so.6 libopensync-plugin-synce - 0.22-4.fc8.x86_64 requires libopensync.so.0()(64bit) liferea - 1.4.10-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.x86_64 requires libgtkembedmoz.so()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) multisync - 0.91.0-1.fc7.x86_64 requires libosengine.so.0()(64bit) multisync - 0.91.0-1.fc7.x86_64 requires libopensync.so.0()(64bit) multisync-gui - 0.91.0-1.fc7.x86_64 requires libopensync.so.0()(64bit) multisync-gui - 0.91.0-1.fc7.x86_64 requires libosengine.so.0()(64bit) octave-forge - 20071212-5.fc9.x86_64 requires libdapclient.so.1()(64bit) octave-forge - 20071212-5.fc9.x86_64 requires libdap.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) python-gammu - 0.22-3.fc8.x86_64 requires libGammu.so.2()(64bit) xca - 0.6.4-1.fc8.x86_64 requires libcrypto.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-client - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libcrypto.so.6 d4x - 2.5.7.1-3.fc7.ppc requires libssl.so.6 d4x - 2.5.7.1-3.fc7.ppc requires libcrypto.so.6 dap-freeform_handler - 3.7.5-2.fc8.ppc64 requires libdap.so.6()(64bit) dap-freeform_handler - 3.7.5-2.fc8.ppc64 requires libdapserver.so.3()(64bit) dap-freeform_handler - 3.7.5-2.fc8.ppc requires libdapserver.so.3 dap-freeform_handler - 3.7.5-2.fc8.ppc requires libdap.so.6 dap-hdf4_handler - 3.7.5-3.fc8.ppc requires libdapserver.so.3 dap-hdf4_handler - 3.7.5-3.fc8.ppc requires libdap.so.6 dap-netcdf_handler - 3.7.6-5.fc8.ppc requires libdapserver.so.3 dap-netcdf_handler - 3.7.6-5.fc8.ppc requires libdap.so.6 dap-netcdf_handler - 3.7.6-5.fc8.ppc64 requires libdap.so.6()(64bit) dap-netcdf_handler - 3.7.6-5.fc8.ppc64 requires libdapserver.so.3()(64bit) dap-server - 3.7.4-4.fc8.ppc requires libdapserver.so.3 dap-server - 3.7.4-4.fc8.ppc requires libdapclient.so.1 dap-server - 3.7.4-4.fc8.ppc requires libdap.so.6 epiphany - 2.21.4-1.fc9.ppc requires libxpcom_core.so epiphany - 2.21.4-1.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.ppc requires libgtkembedmoz.so epiphany-devel - 2.21.4-1.fc9.ppc requires gecko-devel = 0:1.8.1.10 epiphany-devel - 2.21.4-1.fc9.ppc64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires libgtkembedmoz.so gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libdapclient.so.1()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libdap.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libdapserver.so.3()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc requires libdapserver.so.3 gdal - 1.4.2-3.fc8.ppc requires libssl.so.6 gdal - 1.4.2-3.fc8.ppc requires libcrypto.so.6 gdal - 1.4.2-3.fc8.ppc requires libdapclient.so.1 gdal - 1.4.2-3.fc8.ppc requires libdap.so.6 gnome-web-photo - 0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.ppc requires libgtkembedmoz.so grads - 1.9b4-21.fc8.ppc requires libdap.so.6 grass - 6.2.2-2.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 libnc-dap - 3.7.0-8.fc9.ppc64 requires libdapclient.so.1()(64bit) libnc-dap - 3.7.0-8.fc9.ppc64 requires libdap.so.6()(64bit) libnc-dap - 3.7.0-8.fc9.ppc requires libdapclient.so.1 libnc-dap - 3.7.0-8.fc9.ppc requires libdap.so.6 libopensync-plugin-synce - 0.22-4.fc8.ppc requires libopensync.so.0 liferea - 1.4.10-1.fc9.ppc requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc requires libgtkembedmoz.so mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libcrypto.so.6 monodevelop - 0.17-4.fc9.ppc requires boo multisync - 0.91.0-1.fc7.ppc requires libopensync.so.0 multisync - 0.91.0-1.fc7.ppc requires libosengine.so.0 multisync-gui - 0.91.0-1.fc7.ppc requires libopensync.so.0 multisync-gui - 0.91.0-1.fc7.ppc requires libosengine.so.0 octave-forge - 20071212-5.fc9.ppc requires libdapclient.so.1 octave-forge - 20071212-5.fc9.ppc requires libdap.so.6 php-mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 python-gammu - 0.22-3.fc8.ppc requires libGammu.so.2 revisor-cobbler - 2.0.5-14.fc9.noarch requires koan revisor-cobbler - 2.0.5-14.fc9.noarch requires cobbler xca - 0.6.4-1.fc8.ppc requires libcrypto.so.6 Broken deps for ppc64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libssl.so.6()(64bit) dap-freeform_handler - 3.7.5-2.fc8.ppc64 requires libdap.so.6()(64bit) dap-freeform_handler - 3.7.5-2.fc8.ppc64 requires libdapserver.so.3()(64bit) dap-hdf4_handler - 3.7.5-3.fc8.ppc64 requires libdap.so.6()(64bit) dap-hdf4_handler - 3.7.5-3.fc8.ppc64 requires libdapserver.so.3()(64bit) dap-netcdf_handler - 3.7.6-5.fc8.ppc64 requires libdap.so.6()(64bit) dap-netcdf_handler - 3.7.6-5.fc8.ppc64 requires libdapserver.so.3()(64bit) dap-server - 3.7.4-4.fc8.ppc64 requires libdapclient.so.1()(64bit) dap-server - 3.7.4-4.fc8.ppc64 requires libdap.so.6()(64bit) dap-server - 3.7.4-4.fc8.ppc64 requires libdapserver.so.3()(64bit) epiphany - 2.21.4-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany - 2.21.4-1.fc9.ppc64 requires libgtkembedmoz.so()(64bit) epiphany - 2.21.4-1.fc9.ppc64 requires libxpcom_core.so()(64bit) epiphany-devel - 2.21.4-1.fc9.ppc64 requires gecko-devel = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libdapclient.so.1()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libdap.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libdapserver.so.3()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) grads - 1.9b4-21.fc8.ppc64 requires libdap.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libssl.so.6()(64bit) kazehakase - 0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 libnc-dap - 3.7.0-8.fc9.ppc64 requires libdapclient.so.1()(64bit) libnc-dap - 3.7.0-8.fc9.ppc64 requires libdap.so.6()(64bit) libopensync-plugin-synce - 0.22-4.fc8.ppc64 requires libopensync.so.0()(64bit) liferea - 1.4.10-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc64 requires libgtkembedmoz.so()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) octave-forge - 20071212-5.fc9.ppc64 requires libdapclient.so.1()(64bit) octave-forge - 20071212-5.fc9.ppc64 requires libdap.so.6()(64bit) perl-Test-AutoBuild-darcs - 1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 php-mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) php-pear-DB-DataObject-FormBuilder - 1.0.0-0.5.RC7.fc7.noarch requires php-pear(HTML_Table) >= 0:1.7.5 php-pear-HTML-QuickForm-ElementGrid - 0.1.1-1.fc7.noarch requires php-pear(HTML_Table) >= 0:1.7.5 python-gammu - 0.22-3.fc8.ppc64 requires libGammu.so.2()(64bit) revisor-cobbler - 2.0.5-14.fc9.noarch requires koan From opensource at till.name Wed Jan 2 14:18:40 2008 From: opensource at till.name (Till Maas) Date: Wed, 02 Jan 2008 15:18:40 +0100 Subject: f8 gripe #3: infamous Load_Cycle_Count started hitting my laptop, FAQ? In-Reply-To: <477AE01A.6060302@filteredperception.org> References: <477AE01A.6060302@filteredperception.org> Message-ID: <200801021518.48123.opensource@till.name> On Mi Januar 2 2008, Douglas McClendon wrote: > Quite simply, what is the prescribed way for me to run 'hdparm -B 254 > /dev/sda' upon resume from suspend and hibernate? (or a better solution > than that). You can test a new hook that should restore you hd apm settings. Just copy https://cvs.fedoraproject.org/viewcvs/*checkout*/rpms/pm-utils/devel/pm-utils-99hd-apm-restore to /usr/lib/pm-utils/sleep.d/99hd-apm-restore Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From ajackson at redhat.com Wed Jan 2 15:46:30 2008 From: ajackson at redhat.com (Adam Jackson) Date: Wed, 02 Jan 2008 10:46:30 -0500 Subject: Difficulties testing the new nouveau driver In-Reply-To: <20071230121510.3396e632@alkaid.a.lan> References: <1199012599.17626.13.camel@hughsie-laptop> <20071230121510.3396e632@alkaid.a.lan> Message-ID: <1199288790.30771.420.camel@localhost.localdomain> On Sun, 2007-12-30 at 12:15 +0100, Andreas Bierfert wrote: > On Sun, 30 Dec 2007 11:03:19 +0000 > Richard Hughes wrote: > > > * Have a nouveau srpm *and* a nv srpm - they are different codebases and > > have different version numbers > > * Somehow fix the brokenness that has lead to the version number > > xorg-x11-drv-nouveau-2.1.5 being installed when actually installed was > > xorg-x11-drv-nouveau-1.2.0 > > This seems like the right thing to do. To resolve the version problems you > probably have to bump the epoch on nouveau and imho this situation is a valid > reason to do so. Fine with me. Wish I'd noticed the version number skew earlier. - ajax From bpepple at fedoraproject.org Wed Jan 2 15:23:20 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 02 Jan 2008 10:23:20 -0500 Subject: Plan for tomorrows (20080103) FESCO meeting Message-ID: <1199287400.11035.6.camel@kennedy> Hi, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 18:00 UTC in #fedora-meeting on irc.freenode.org: /topic MISC - http://fedoraproject.org/wiki/JesseKeating/PackageACLOpening - f13 /topic MISC - http://fedoraproject.org/wiki/JesseKeating/NewMaintainerContainment - f13 /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, since we have a pretty full schedule). You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From green at redhat.com Wed Jan 2 16:04:16 2008 From: green at redhat.com (Anthony Green) Date: Wed, 02 Jan 2008 11:04:16 -0500 Subject: common-lisp-controller for Fedora In-Reply-To: <47325E81.4010706@redhat.com> References: <47325E81.4010706@redhat.com> Message-ID: <1199289856.2308.15.camel@localhost.localdomain> On Wed, 2007-11-07 at 16:55 -0800, Anthony Green wrote: > I've created a draft Feature page on the wiki to copy Debian's > common-lisp-controller package and methodology for installing Common > Lisp implementations and libraries. > > http://fedoraproject.org/wiki/Features/CommonLispController > > This will require changes to all common lisp implementations in Fedora, > so I'm looking for support from those packagers (some of whom are on copy). I would still like to do this, but haven't heard from any of the lisp package maintainers (rdieter and gemi). Did you guys see this thread? Thanks, AG > > Also, this is not something I can do on my own. I'm hoping there are > like-minded people out there that are interesting in making Fedora a > great platform for deploying Lisp based infrastructure. So, are there > any willing to help over the next 6 months? > > Thanks! > > AG > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From walters at redhat.com Wed Jan 2 16:05:06 2008 From: walters at redhat.com (Colin Walters) Date: Wed, 02 Jan 2008 11:05:06 -0500 Subject: Getting GNOME settings applied for GNOME apps in KDE sessions In-Reply-To: <200712301721.09417.ville.skytta@iki.fi> References: <200712301248.31541.ville.skytta@iki.fi> <200712301721.09417.ville.skytta@iki.fi> Message-ID: <1199289906.22306.34.camel@space-ghost.verbum.private> On Sun, 2007-12-30 at 17:21 +0200, Ville Skytt? wrote: > On Sunday 30 December 2007, Kevin Kofler wrote: > > Oops, I wrote: > > > install our gtk-qt-engine theme to get it. > > > > I actually meant "install our gtk-qt-engine _package_". > > Ok, that looks useful, but helps only for a subset of the issues. For > example, it doesn't help with broken gnome-control-center icons. I think ultimately the right answer is that running gnome-control-center doesn't make sense outside of GNOME, and that you should be able to configure the important things for all applications from the KDE menus. The "proxy to xsettings" approach seems like the current solution for that. From rdieter at math.unl.edu Wed Jan 2 16:14:08 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 02 Jan 2008 10:14:08 -0600 Subject: common-lisp-controller for Fedora In-Reply-To: <1199289856.2308.15.camel@localhost.localdomain> References: <47325E81.4010706@redhat.com> <1199289856.2308.15.camel@localhost.localdomain> Message-ID: <477BB850.4020005@math.unl.edu> Anthony Green wrote: > On Wed, 2007-11-07 at 16:55 -0800, Anthony Green wrote: >> I've created a draft Feature page on the wiki to copy Debian's >> common-lisp-controller package and methodology for installing Common >> Lisp implementations and libraries. >> >> http://fedoraproject.org/wiki/Features/CommonLispController >> >> This will require changes to all common lisp implementations in Fedora, >> so I'm looking for support from those packagers (some of whom are on copy). > > I would still like to do this, but haven't heard from any of the lisp > package maintainers (rdieter and gemi). Did you guys see this thread? I'm certainly for the idea, it's a good one, but I doubt I'll personally have much time or lisp-aptitude to help much. Anthony, if you've got the lisp-mojo and interest, consider adding yourself as comaintainer for these lisp pkgs, I, for one, would welcome it. -- Rex From bpepple at fedoraproject.org Wed Jan 2 16:21:49 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 02 Jan 2008 11:21:49 -0500 Subject: Policy proposal for compatibility packages Message-ID: <1199290909.11035.20.camel@kennedy> Here's a proposal for the handling of new compat packages: http://fedoraproject.org/wiki/BrianPepple/DraftCompatPackages FESCo discussed this back at our last meeting, but before we pulled the trigger on this, I want to get feedback from the mailing list. I'm tentatively planning on having FESCo vote on this at the 2008-01-10 meeting, though that could change based on any feedback I receive. Thanks, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From green at redhat.com Wed Jan 2 16:25:14 2008 From: green at redhat.com (Anthony Green) Date: Wed, 02 Jan 2008 11:25:14 -0500 Subject: common-lisp-controller for Fedora In-Reply-To: <477BB79E.3050606@fedoraproject.org> References: <47325E81.4010706@redhat.com> <1199289856.2308.15.camel@localhost.localdomain> <477BB79E.3050606@fedoraproject.org> Message-ID: <1199291114.2308.18.camel@localhost.localdomain> On Wed, 2008-01-02 at 10:11 -0600, Rex Dieter wrote: > Anthony, if you've got the lisp-mojo and interest, consider adding > yourself as comaintainer for these lisp pkgs, I, for one, would welcome it. Thanks Rex. I've applied for comaintainership of all of the Common Lisp implementations. AG From kevin.kofler at chello.at Wed Jan 2 16:35:55 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 2 Jan 2008 16:35:55 +0000 (UTC) Subject: Cannot upgrade from Rel 7 to Rel 8 References: <477B6572.6050602@gmail.com> <477B6685.2040102@homer.se> Message-ID: Lars E. Pettersson homer.se> writes: > Take a look at > https://bugzilla.redhat.com/show_bug.cgi?id=372011 > > As can be read, the Fedoraunity re-spin did it for me... As written in that bug report too, the update image at: http://katzj.fedorapeople.org/updates-f8-yumloop.img can also be used. See: http://fedoraproject.org/wiki/Anaconda/Updates for instructions on how to use update images. The respin already incorporates this update, so it is not necessary if you use the respin. Kevin Kofler From rdieter at math.unl.edu Wed Jan 2 16:50:58 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 02 Jan 2008 10:50:58 -0600 Subject: Policy proposal for compatibility packages References: <1199290909.11035.20.camel@kennedy> Message-ID: Brian Pepple wrote: > Here's a proposal for the handling of new compat packages: > http://fedoraproject.org/wiki/BrianPepple/DraftCompatPackages > FESCo discussed this back at our last meeting, but before we pulled the > trigger on this, I want to get feedback from the mailing list. Huge heap of common sense, +1. -- Rex p.s. almost sad really, that what is, to me, just common sense even needs to be elucidated, but so be it. From fedora at leemhuis.info Wed Jan 2 16:52:27 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 02 Jan 2008 17:52:27 +0100 Subject: Policy proposal for compatibility packages In-Reply-To: <1199290909.11035.20.camel@kennedy> References: <1199290909.11035.20.camel@kennedy> Message-ID: <477BC14B.9010300@leemhuis.info> On 02.01.2008 17:21, Brian Pepple wrote: > Here's a proposal for the handling of new compat packages: > http://fedoraproject.org/wiki/BrianPepple/DraftCompatPackages Below the proposal text cut'n'pasted from the wiki for easier review and here on the list (as discussed in https://www.redhat.com/archives/fedora-devel-list/2007-December/msg01269.html and written down in http://fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines ). --- = Compatibility Packages Draft = [[TableOfContents()]] = Overview = == Problem Space == ## Describe the problem this proposal seeks to solve Compatibility packages are packages which provide a secondary (usually older) version of an API or program from the primary version packaged within Fedora. Currently, there are no formal guidelines in regards to the creation of them. == Solution Overview == ## Describe in brief the solution proposed In general, software within Fedora should be moved to run on the current version of libraries. Shipping multiple versions of libraries tends to be problematic due to a potential case where multiple versions of a library could be linked into one running process leading to unpredictable results. It also means that security changes, fixes, etc. They also take more repository space, requiring more download of package metadata, ... In cases where this isn't possible, a compatibility package _may_ be introduced if there is someone who is willing to maintain the compatibility package and the primary package maintainer is not against the idea. The reasoning for the latter is that even if the primary maintainer is not maintaining the compatibility package, chances are that they will have to be involved in the maintenance due to passing along security problems, helping out with things and redirecting misfiled bugs. If the compatibility packager and the primary package maintainer cannot come to a mutual decision, it can be escalated to FESCo to make the final decision. == Scope == ## Describe the scope of what all things will be effected by the proposal This proposal would only affect the creation of new compatibility packages. == Comments ? == ## A section provided for comments --- CU knurd From jwboyer at gmail.com Wed Jan 2 16:56:14 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 2 Jan 2008 10:56:14 -0600 Subject: Policy proposal for compatibility packages In-Reply-To: <1199290909.11035.20.camel@kennedy> References: <1199290909.11035.20.camel@kennedy> Message-ID: <20080102105614.73d4db84@vader.jdub.homelinux.org> On Wed, 02 Jan 2008 11:21:49 -0500 Brian Pepple wrote: > Here's a proposal for the handling of new compat packages: > > http://fedoraproject.org/wiki/BrianPepple/DraftCompatPackages > > FESCo discussed this back at our last meeting, but before we pulled the > trigger on this, I want to get feedback from the mailing list. I'm > tentatively planning on having FESCo vote on this at the 2008-01-10 > meeting, though that could change based on any feedback I receive. Should there be, or is there, a time limit on the life of compat packages? josh From kevin.kofler at chello.at Wed Jan 2 16:59:13 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 2 Jan 2008 16:59:13 +0000 (UTC) Subject: Policy proposal for compatibility packages References: <1199290909.11035.20.camel@kennedy> <20080102105614.73d4db84@vader.jdub.homelinux.org> Message-ID: Josh Boyer gmail.com> writes: > Should there be, or is there, a time limit on the life of compat > packages? Definitely not without exceptions! kdelibs3 will be needed for years to come. Kevin Kofler From emmanuel.seyman at club-internet.fr Wed Jan 2 17:05:51 2008 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Wed, 2 Jan 2008 18:05:51 +0100 Subject: Policy proposal for compatibility packages In-Reply-To: <1199290909.11035.20.camel@kennedy> References: <1199290909.11035.20.camel@kennedy> Message-ID: <20080102170551.GA31671@orient.maison.lan> * Brian Pepple [02/01/2008 17:59] : > > FESCo discussed this back at our last meeting, but before we pulled the > trigger on this, I want to get feedback from the mailing list. I'm > tentatively planning on having FESCo vote on this at the 2008-01-10 > meeting, though that could change based on any feedback I receive. Should upstream be informed/consulted/given-veto-power ? Emmanuel From bpepple at fedoraproject.org Wed Jan 2 17:08:59 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 02 Jan 2008 12:08:59 -0500 Subject: Policy proposal for compatibility packages In-Reply-To: <20080102105614.73d4db84@vader.jdub.homelinux.org> References: <1199290909.11035.20.camel@kennedy> <20080102105614.73d4db84@vader.jdub.homelinux.org> Message-ID: <1199293739.11035.26.camel@kennedy> On Wed, 2008-01-02 at 10:56 -0600, Josh Boyer wrote: > On Wed, 02 Jan 2008 11:21:49 -0500 > Brian Pepple wrote: > > > Here's a proposal for the handling of new compat packages: > > > > http://fedoraproject.org/wiki/BrianPepple/DraftCompatPackages > > > > FESCo discussed this back at our last meeting, but before we pulled the > > trigger on this, I want to get feedback from the mailing list. I'm > > tentatively planning on having FESCo vote on this at the 2008-01-10 > > meeting, though that could change based on any feedback I receive. > > Should there be, or is there, a time limit on the life of compat > packages? IMO, we should leave that decision to the compat packager. Also, I'd like to have the bureaucracy of the policy be fairly minimal. Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jwboyer at gmail.com Wed Jan 2 17:16:44 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 2 Jan 2008 11:16:44 -0600 Subject: Policy proposal for compatibility packages In-Reply-To: <20080102170551.GA31671@orient.maison.lan> References: <1199290909.11035.20.camel@kennedy> <20080102170551.GA31671@orient.maison.lan> Message-ID: <20080102111644.16a69950@vader.jdub.homelinux.org> On Wed, 2 Jan 2008 18:05:51 +0100 Emmanuel Seyman wrote: > * Brian Pepple [02/01/2008 17:59] : > > > > FESCo discussed this back at our last meeting, but before we pulled the > > trigger on this, I want to get feedback from the mailing list. I'm > > tentatively planning on having FESCo vote on this at the 2008-01-10 > > meeting, though that could change based on any feedback I receive. > > Should upstream be informed/consulted/given-veto-power ? Informed/consulted, yes. Veto power... I wouldn't think so. josh From bpepple at fedoraproject.org Wed Jan 2 17:14:43 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 02 Jan 2008 12:14:43 -0500 Subject: Policy proposal for compatibility packages In-Reply-To: <20080102170551.GA31671@orient.maison.lan> References: <1199290909.11035.20.camel@kennedy> <20080102170551.GA31671@orient.maison.lan> Message-ID: <1199294083.11035.31.camel@kennedy> On Wed, 2008-01-02 at 18:05 +0100, Emmanuel Seyman wrote: > * Brian Pepple [02/01/2008 17:59] : > > > > FESCo discussed this back at our last meeting, but before we pulled the > > trigger on this, I want to get feedback from the mailing list. I'm > > tentatively planning on having FESCo vote on this at the 2008-01-10 > > meeting, though that could change based on any feedback I receive. > > Should upstream be informed/consulted/given-veto-power ? I think it probably makes sense to have a good dialog with upstream (which applies with all packages, not just compat), but I'm not sure if it's necessary to formally require that upstream be consulted when proposing a compat package. /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jwboyer at gmail.com Wed Jan 2 17:17:10 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 2 Jan 2008 11:17:10 -0600 Subject: Policy proposal for compatibility packages In-Reply-To: <1199293739.11035.26.camel@kennedy> References: <1199290909.11035.20.camel@kennedy> <20080102105614.73d4db84@vader.jdub.homelinux.org> <1199293739.11035.26.camel@kennedy> Message-ID: <20080102111710.389d68a5@vader.jdub.homelinux.org> On Wed, 02 Jan 2008 12:08:59 -0500 Brian Pepple wrote: > On Wed, 2008-01-02 at 10:56 -0600, Josh Boyer wrote: > > On Wed, 02 Jan 2008 11:21:49 -0500 > > Brian Pepple wrote: > > > > > Here's a proposal for the handling of new compat packages: > > > > > > http://fedoraproject.org/wiki/BrianPepple/DraftCompatPackages > > > > > > FESCo discussed this back at our last meeting, but before we pulled the > > > trigger on this, I want to get feedback from the mailing list. I'm > > > tentatively planning on having FESCo vote on this at the 2008-01-10 > > > meeting, though that could change based on any feedback I receive. > > > > Should there be, or is there, a time limit on the life of compat > > packages? > > IMO, we should leave that decision to the compat packager. Also, I'd > like to have the bureaucracy of the policy be fairly minimal. Yes, that's true. Ignore my question, it only leads to pain. josh From kevin at scrye.com Wed Jan 2 17:22:28 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 2 Jan 2008 10:22:28 -0700 Subject: heads up: tcl and tk 8.5 In-Reply-To: <477B60F0.6020406@redhat.com> References: <477B60F0.6020406@redhat.com> Message-ID: <20080102102228.44c0d545@ghistelwchlohm.scrye.com> On Wed, 02 Jan 2008 11:01:20 +0100 mmaslano at redhat.com (Marcela Maslanova) wrote: > New tcl and tk 8.5 was released. I'd like to push it to rawhide as > soon as possible. The list of dependent packages could be found in > this draft: > https://fedoraproject.org/wiki/MarcelaMaslanova/Draft/tcl8.5 The > maintainers of dependent packages should fix them according to > http://fedoraproject.org/wiki/PackagingDrafts/Tcl Can you possibly mail directly at least the primary maintainers of these packages and let them know when you are going to push the update? Many of them might not see this post... > > Marcela Maslanova > kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Wed Jan 2 17:42:59 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 02 Jan 2008 18:42:59 +0100 Subject: Policy proposal for compatibility packages In-Reply-To: <1199290909.11035.20.camel@kennedy> References: <1199290909.11035.20.camel@kennedy> Message-ID: <477BCD23.8040206@leemhuis.info> On 02.01.2008 17:21, Brian Pepple wrote: > Here's a proposal for the handling of new compat packages: > > http://fedoraproject.org/wiki/BrianPepple/DraftCompatPackages > > FESCo discussed this back at our last meeting, but before we pulled the > trigger on this, I want to get feedback from the mailing list. My 2 cent: proprietary apps (which are not mentioned at all in the proposal) sometimes needs older libs to work (those libs of course have to be licensed as LGPL or BSD for example). We should allow compat packages for those in Fedora; the packager of those libs should not be able to block them. The proposal IMHO tries to solve the problem the wrong way. Having compat-packages in the repo is not the biggest problem -- other apps in Fedora using those compat-packages IMHO is what we should prevent. Cu knurd From alan at clueserver.org Wed Jan 2 17:54:54 2008 From: alan at clueserver.org (Alan) Date: Wed, 2 Jan 2008 09:54:54 -0800 (PST) Subject: Policy proposal for compatibility packages In-Reply-To: <477BCD23.8040206@leemhuis.info> References: <1199290909.11035.20.camel@kennedy> <477BCD23.8040206@leemhuis.info> Message-ID: <50186.198.182.194.170.1199296494.squirrel@clueserver.org> > > > On 02.01.2008 17:21, Brian Pepple wrote: >> Here's a proposal for the handling of new compat packages: >> >> http://fedoraproject.org/wiki/BrianPepple/DraftCompatPackages >> >> FESCo discussed this back at our last meeting, but before we pulled the >> trigger on this, I want to get feedback from the mailing list. > > My 2 cent: proprietary apps (which are not mentioned at all in the > proposal) sometimes needs older libs to work (those libs of course have > to be licensed as LGPL or BSD for example). We should allow compat > packages for those in Fedora; the packager of those libs should not be > able to block them. Also those of us building apps that are not in Fedora need those libraries available just to make the damn code work. (I am fighting an app that I want to get moved to current, but I am fighting just getting to work at all.) I would like to see the Berkley DB compat packages cover all the non-current versions. (That has been my biggest headache as of late.) > The proposal IMHO tries to solve the problem the wrong way. Having > compat-packages in the repo is not the biggest problem -- other apps in > Fedora using those compat-packages IMHO is what we should prevent. The other issue is overlapping compat packages. Usually it is a case where Fedora has one and a third party repository has another. (wxgtk comes to mind.) Makes it painful when you want two applications that should co-exist, but have different compat libraries that are the same thing in essence. From lowen at pari.edu Wed Jan 2 17:57:53 2008 From: lowen at pari.edu (Lamar Owen) Date: Wed, 2 Jan 2008 12:57:53 -0500 Subject: GNU Radio In-Reply-To: <409676c70801010620l68af02ddudc0d7d0017826599@mail.gmail.com> References: <3170f42f0712311228q5429c06do4e1c4f6225422284@mail.gmail.com> Message-ID: <200801021257.53442.lowen@pari.edu> On Tuesday 01 January 2008, Trond Danielsen wrote: > I started working on a GNU Radio package for Fedora, but I never found > the time to finish it. I do not know if you will find it useful, but I > have a preliminary spec file here: > http://trondd.fedorapeople.org/spec_files/ Yes, thank you Trond. Having something started is great, as that's a good part of the job, is just getting started. -- Lamar Owen Chief Information Officer Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu From sundaram at fedoraproject.org Wed Jan 2 17:52:48 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 02 Jan 2008 23:22:48 +0530 Subject: RFC: Fedora Xfce Spin Message-ID: <477BCF70.6080601@fedoraproject.org> Hi I have created a initial kickstart file for a Fedora Xfce spin available at http://sundaram.fedorapeople.org/livecd-fedora-8-xfce.ks I still have a problem in that a file called "Desktop", that is a desktop file for the liveinst command is created on the default Xfce desktop and Xfce complains about that during login. I am not sure where that is coming from. Before I submit this to release engineering, I would like to get some feedback, fixes and suggestions on any improvements possible. My intention it to do a initial release for Fedora 8 and continue with incremental improvements over the Fedora 9 development period and have a solid Xfce spin as part of the Fedora 9 release. Rahul From jkeating at redhat.com Wed Jan 2 18:11:01 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 2 Jan 2008 13:11:01 -0500 Subject: Policy proposal for compatibility packages In-Reply-To: <477BCD23.8040206@leemhuis.info> References: <1199290909.11035.20.camel@kennedy> <477BCD23.8040206@leemhuis.info> Message-ID: <20080102131101.028dd228@redhat.com> On Wed, 02 Jan 2008 18:42:59 +0100 Thorsten Leemhuis wrote: > The proposal IMHO tries to solve the problem the wrong way. Having > compat-packages in the repo is not the biggest problem -- other apps > in Fedora using those compat-packages IMHO is what we should prevent. There is a difference between compatible library packages and compatible development packages. Compatible libraries make long term sense. Compat development packages don't. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wart at kobold.org Wed Jan 2 18:20:38 2008 From: wart at kobold.org (Michael Thomas) Date: Wed, 02 Jan 2008 10:20:38 -0800 Subject: heads up: tcl and tk 8.5 In-Reply-To: <477B60F0.6020406@redhat.com> References: <477B60F0.6020406@redhat.com> Message-ID: <477BD5F6.100@kobold.org> Marcela Maslanova wrote: > New tcl and tk 8.5 was released. I'd like to push it to rawhide as soon > as possible. The list of dependent packages could be found in this > draft: https://fedoraproject.org/wiki/MarcelaMaslanova/Draft/tcl8.5 > The maintainers of dependent packages should fix them according to > http://fedoraproject.org/wiki/PackagingDrafts/Tcl One of the changes that packagers need to be aware of (also described in the proposed Tcl packaging guidelines) is that we are adding a patch to Tcl/Tk 8.5 to limit the directories where extensions can be installed. Currently Tcl allows extensions to be installed in /usr/lib and /usr/lib64, and will perform a time-consuming search through all subdirectories to find extensions. The 'restricted auto_path' patch that we are adding will limit the search to %{_libdir}/tcl8.5 and %{_datadir}/tcl8.5. This greatly improves the startup time for most Tcl applications. However, it does require that maintainers of Tcl extension packages make some changes to ensure that the extensions get installed into %{_libdir}/tcl8.5 (or %{_datadir}/tcl8.5) instead of %{_libdir} (or %{_datadir}). I will be happy to help out any maintainers that want help with this change. --Wart From fedora at leemhuis.info Wed Jan 2 18:35:23 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 02 Jan 2008 19:35:23 +0100 Subject: Policy proposal for compatibility packages In-Reply-To: <20080102131101.028dd228@redhat.com> References: <1199290909.11035.20.camel@kennedy> <477BCD23.8040206@leemhuis.info> <20080102131101.028dd228@redhat.com> Message-ID: <477BD96B.30808@leemhuis.info> On 02.01.2008 19:11, Jesse Keating wrote: > On Wed, 02 Jan 2008 18:42:59 +0100 > Thorsten Leemhuis wrote: > >> The proposal IMHO tries to solve the problem the wrong way. Having >> compat-packages in the repo is not the biggest problem -- other apps >> in Fedora using those compat-packages IMHO is what we should prevent. > There is a difference between compatible library packages and > compatible development packages. Then I suppose the proposal needs updating, as it's not obvious which of the two are meant. > Compatible libraries make long term sense. That sounds a bit different to me in the proposal: "Shipping multiple versions of libraries tends to be problematic due to a potential case where multiple versions of a library could be linked into one running process leading to unpredictable results. It also means that security changes, fixes, etc. They also take more repository space, requiring more download of package metadata, ..." > Compat development packages don't. See Alan's post. Cu knurd From kevin.kofler at chello.at Wed Jan 2 18:36:37 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 2 Jan 2008 18:36:37 +0000 (UTC) Subject: Policy proposal for compatibility packages References: <1199290909.11035.20.camel@kennedy> <477BCD23.8040206@leemhuis.info> <20080102131101.028dd228@redhat.com> Message-ID: Jesse Keating redhat.com> writes: > There is a difference between compatible library packages and > compatible development packages. Compatible libraries make long term > sense. Compat development packages don't. By shipping libraries, even compat ones, without a -devel package, we'd be advantaging proprietary apps over Free ones. :-( Kevin Kofer From lesmikesell at gmail.com Wed Jan 2 18:53:41 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 02 Jan 2008 12:53:41 -0600 Subject: Policy proposal for compatibility packages In-Reply-To: References: <1199290909.11035.20.camel@kennedy> <477BCD23.8040206@leemhuis.info> <20080102131101.028dd228@redhat.com> Message-ID: <477BDDB5.2050407@gmail.com> Kevin Kofler wrote: > Jesse Keating redhat.com> writes: >> There is a difference between compatible library packages and >> compatible development packages. Compatible libraries make long term >> sense. Compat development packages don't. > > By shipping libraries, even compat ones, without a -devel package, we'd be > advantaging proprietary apps over Free ones. :-( > Change your terminology to 'pre-compiled' and 're-compiled' because it really doesn't relate to code being proprietary or not, only when it was compiled. And then you also see why the -devel doesn't matter. -- Les Mikesell lesmikesell at gmail.com From kevin.kofler at chello.at Wed Jan 2 18:53:37 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 2 Jan 2008 18:53:37 +0000 (UTC) Subject: Policy proposal for compatibility packages References: <1199290909.11035.20.camel@kennedy> <477BCD23.8040206@leemhuis.info> <20080102131101.028dd228@redhat.com> <477BDDB5.2050407@gmail.com> Message-ID: Les Mikesell gmail.com> writes: > Change your terminology to 'pre-compiled' and 're-compiled' because it > really doesn't relate to code being proprietary or not, only when it was > compiled. And then you also see why the -devel doesn't matter. That assumes the Free programs you're rebuilding actually rebuild against the new version of the library. The #1 reason compat libraries are needed is that this is not the case (due to API changes). Kevin Kofler From nicolas.mailhot at laposte.net Wed Jan 2 19:15:48 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 02 Jan 2008 20:15:48 +0100 Subject: Policy proposal for compatibility packages In-Reply-To: <20080102105614.73d4db84@vader.jdub.homelinux.org> References: <1199290909.11035.20.camel@kennedy> <20080102105614.73d4db84@vader.jdub.homelinux.org> Message-ID: <1199301348.3483.2.camel@rousalka.dyndns.org> Le mercredi 02 janvier 2008 ? 10:56 -0600, Josh Boyer a ?crit : > On Wed, 02 Jan 2008 11:21:49 -0500 > Brian Pepple wrote: > > > Here's a proposal for the handling of new compat packages: > > > > http://fedoraproject.org/wiki/BrianPepple/DraftCompatPackages > > > > FESCo discussed this back at our last meeting, but before we pulled the > > trigger on this, I want to get feedback from the mailing list. I'm > > tentatively planning on having FESCo vote on this at the 2008-01-10 > > meeting, though that could change based on any feedback I receive. > > Should there be, or is there, a time limit on the life of compat > packages? There certainly should be an upper time limit after which the maintainer justifies why Fedora should still carry compatibility cruft. Sometimes packages (or other compatibility workarounds) get pushed release after release just because it's easier to keep them than to re-check if they can be killed at last. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From lesmikesell at gmail.com Wed Jan 2 19:21:11 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 02 Jan 2008 13:21:11 -0600 Subject: Policy proposal for compatibility packages In-Reply-To: References: <1199290909.11035.20.camel@kennedy> <477BCD23.8040206@leemhuis.info> <20080102131101.028dd228@redhat.com> <477BDDB5.2050407@gmail.com> Message-ID: <477BE427.4010202@gmail.com> Kevin Kofler wrote: > Les Mikesell gmail.com> writes: >> Change your terminology to 'pre-compiled' and 're-compiled' because it >> really doesn't relate to code being proprietary or not, only when it was >> compiled. And then you also see why the -devel doesn't matter. > > That assumes the Free programs you're rebuilding actually rebuild against the > new version of the library. The #1 reason compat libraries are needed is that > this is not the case (due to API changes). Free vs. non-free has nothing to do with the issue. It has to do with how long you want existing binaries to continue to work, and how long you want to enable/encourage people to continue to compile in a way that does not use the current API. There is never a reason to break existing binaries unless you hate your users or there is no other way to move forward. But you may want to make it obvious that things should not continue to be compiled against the deprecated API. -- Les Mikesell lesmikesell at gmail.com From sundaram at fedoraproject.org Wed Jan 2 19:17:10 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 03 Jan 2008 00:47:10 +0530 Subject: RFC: Fedora Xfce Spin In-Reply-To: <477BCF70.6080601@fedoraproject.org> References: <477BCF70.6080601@fedoraproject.org> Message-ID: <477BE336.6050203@fedoraproject.org> Rahul Sundaram wrote: > Hi > > I have created a initial kickstart file for a Fedora Xfce spin available at > > http://sundaram.fedorapeople.org/livecd-fedora-8-xfce.ks > > I still have a problem in that a file called "Desktop", that is a > desktop file for the liveinst command is created on the default Xfce > desktop and Xfce complains about that during login. I am not sure where > that is coming from. Jeremy indicated on IRC that this is because, xdg-user-dirs is not installed. I have fixed this now. Rahul From tcallawa at redhat.com Wed Jan 2 19:28:42 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 02 Jan 2008 14:28:42 -0500 Subject: Policy proposal for compatibility packages In-Reply-To: <1199301348.3483.2.camel@rousalka.dyndns.org> References: <1199290909.11035.20.camel@kennedy> <20080102105614.73d4db84@vader.jdub.homelinux.org> <1199301348.3483.2.camel@rousalka.dyndns.org> Message-ID: <477BE5EA.9020909@redhat.com> Nicolas Mailhot wrote: > There certainly should be an upper time limit after which the maintainer > justifies why Fedora should still carry compatibility cruft. Sometimes > packages (or other compatibility workarounds) get pushed release after > release just because it's easier to keep them than to re-check if they > can be killed at last. I'd originally suggested that the existence of compat-* packages should be rationalized by the maintainer as part of each release cycle. Valid rationale could be (but is certainly not limited to): - Fedora applications which are not yet ported to the new interface - Third party applications which still depend on the old interface (that the maintainer is aware of specifically, not "something might use it someday") ~spot From kevin.kofler at chello.at Wed Jan 2 19:47:57 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 2 Jan 2008 19:47:57 +0000 (UTC) Subject: Policy proposal for compatibility packages References: <1199290909.11035.20.camel@kennedy> <477BCD23.8040206@leemhuis.info> <20080102131101.028dd228@redhat.com> <477BDDB5.2050407@gmail.com> <477BE427.4010202@gmail.com> Message-ID: Les Mikesell gmail.com> writes: > Free vs. non-free has nothing to do with the issue. It has to do with > how long you want existing binaries to continue to work, and how long > you want to enable/encourage people to continue to compile in a way that > does not use the current API. There is never a reason to break existing > binaries unless you hate your users or there is no other way to move > forward. But you may want to make it obvious that things should not > continue to be compiled against the deprecated API. You are still missing my point! Proprietary software comes as a binary blob, they'll not give a rat's behind about there no longer being a -devel package for the library they're building against, they can build on another distribution, build on an old version of the distribution, build their own version of the library etc., only they need the -devel package anyway, the user only gets the readily-linked blob. They'll keep using obsolete libraries as long as they can get away with it because that way, with the same blob, they can also service ancient obsolete distributions and (most importantly to them) "enterprise" distributions, and removing the -devel package will do nothing to stop them from doing that. Free Software, on the other hand, usually comes as source code. So, if the code doesn't compile against the latest version of the library, you (the user) need the -devel package for the compat library to be able to still build that software. Now of course, you can in principle fix the Free Software to build (unlike a proprietary blob), but in practice this isn't always so easy. Kevin Kofler From bpepple at fedoraproject.org Wed Jan 2 20:11:14 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 02 Jan 2008 15:11:14 -0500 Subject: Policy proposal for compatibility packages In-Reply-To: <477BE5EA.9020909@redhat.com> References: <1199290909.11035.20.camel@kennedy> <20080102105614.73d4db84@vader.jdub.homelinux.org> <1199301348.3483.2.camel@rousalka.dyndns.org> <477BE5EA.9020909@redhat.com> Message-ID: <1199304674.16111.4.camel@kennedy> On Wed, 2008-01-02 at 14:28 -0500, Tom "spot" Callaway wrote: > > I'd originally suggested that the existence of compat-* packages should > be rationalized by the maintainer as part of each release cycle. > > Valid rationale could be (but is certainly not limited to): > > - Fedora applications which are not yet ported to the new interface > - Third party applications which still depend on the old interface (that > the maintainer is aware of specifically, not "something might use it > someday") Yeah, I was going to add this to the proposal, but held off since I was a little afraid of the added bureaucracy/madness it would bring. What's others people thoughts on this? /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From loupgaroublond at gmail.com Wed Jan 2 21:21:57 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 2 Jan 2008 16:21:57 -0500 Subject: common-lisp-controller for Fedora In-Reply-To: <477BB850.4020005@math.unl.edu> References: <47325E81.4010706@redhat.com> <1199289856.2308.15.camel@localhost.localdomain> <477BB850.4020005@math.unl.edu> Message-ID: <7f692fec0801021321x6b28c0e5rcea79ff0f10a3bfe@mail.gmail.com> On Jan 2, 2008 11:14 AM, Rex Dieter wrote: > Anthony, if you've got the lisp-mojo and interest, consider adding > yourself as comaintainer for these lisp pkgs, I, for one, would welcome it. WHere do you go for comaintainership? I am looking to do a similar thing for Haskell packages. -Yaakov From lesmikesell at gmail.com Wed Jan 2 21:42:35 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 02 Jan 2008 15:42:35 -0600 Subject: Policy proposal for compatibility packages In-Reply-To: References: <1199290909.11035.20.camel@kennedy> <477BCD23.8040206@leemhuis.info> <20080102131101.028dd228@redhat.com> <477BDDB5.2050407@gmail.com> <477BE427.4010202@gmail.com> Message-ID: <477C054B.1040705@gmail.com> Kevin Kofler wrote: >> Free vs. non-free has nothing to do with the issue. It has to do with >> how long you want existing binaries to continue to work, and how long >> you want to enable/encourage people to continue to compile in a way that >> does not use the current API. There is never a reason to break existing >> binaries unless you hate your users or there is no other way to move >> forward. But you may want to make it obvious that things should not >> continue to be compiled against the deprecated API. > > You are still missing my point! And you are missing mine. It doesn't matter who does the build. > Proprietary software comes as a binary blob, they'll not give a rat's behind > about there no longer being a -devel package for the library they're building > against, they can build on another distribution, build on an old version of the > distribution, build their own version of the library etc., only they need > the -devel package anyway, the user only gets the readily-linked blob. They'll > keep using obsolete libraries as long as they can get away with it Beg your pardon? I see no reason to believe this. They used what you put in the distribution to build their binary just as I do with source builds, expecting the binary to continue to work. If you are going to break an interface you need to provide some lead time with an appropriate way to fix it. > because that > way, with the same blob, they can also service ancient obsolete distributions > and (most importantly to them) "enterprise" distributions, and removing > the -devel package will do nothing to stop them from doing that. Why do you think that it is any more important to a vendor than it is to me to be able to run the same binary across different Linux distributions? If I wanted to recompile everything on every machine, I'd be using gentoo exclusively. > Free Software, on the other hand, usually comes as source code. So, if the code > doesn't compile against the latest version of the library, you (the user) need > the -devel package for the compat library to be able to still build that > software. Now of course, you can in principle fix the Free Software to build > (unlike a proprietary blob), but in practice this isn't always so easy. The question is, do you want to support running existing binaries for a different length of time than building new binaries with a deprecated API? Personally I see no reason to ever break an existing binary if there is any possible choice and don't object to keeping the -devel's too, but I can see where you might want to phase out the use of the old API in new builds. -- Les Mikesell lesmikesell at gmail.com From rdieter at math.unl.edu Wed Jan 2 21:45:17 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 02 Jan 2008 15:45:17 -0600 Subject: comaintainership requests References: <47325E81.4010706@redhat.com> <1199289856.2308.15.camel@localhost.localdomain> <477BB850.4020005@math.unl.edu> <7f692fec0801021321x6b28c0e5rcea79ff0f10a3bfe@mail.gmail.com> Message-ID: Yaakov Nemoy wrote: > WHere do you go for comaintainership? I am looking to do a similar > thing for Haskell packages. http://admin.fedoraproject.org/pkgdb/ -- Rex From pertusus at free.fr Wed Jan 2 21:50:10 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 2 Jan 2008 22:50:10 +0100 Subject: Policy proposal for compatibility packages In-Reply-To: <477BE5EA.9020909@redhat.com> References: <1199290909.11035.20.camel@kennedy> <20080102105614.73d4db84@vader.jdub.homelinux.org> <1199301348.3483.2.camel@rousalka.dyndns.org> <477BE5EA.9020909@redhat.com> Message-ID: <20080102215010.GD2661@free.fr> On Wed, Jan 02, 2008 at 02:28:42PM -0500, Tom spot Callaway wrote: > - Third party applications which still depend on the old interface (that > the maintainer is aware of specifically, not "something might use it > someday") That seems to me to be a perfect reason. Please don't try to force packagers to do something without reason. If a packager wants to invest time to maintain a compat package, let him do. -- Pat From nicolas.mailhot at laposte.net Wed Jan 2 21:55:24 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 02 Jan 2008 22:55:24 +0100 Subject: Policy proposal for compatibility packages In-Reply-To: <1199304674.16111.4.camel@kennedy> References: <1199290909.11035.20.camel@kennedy> <20080102105614.73d4db84@vader.jdub.homelinux.org> <1199301348.3483.2.camel@rousalka.dyndns.org> <477BE5EA.9020909@redhat.com> <1199304674.16111.4.camel@kennedy> Message-ID: <1199310924.5546.6.camel@rousalka.dyndns.org> Le mercredi 02 janvier 2008 ? 15:11 -0500, Brian Pepple a ?crit : > On Wed, 2008-01-02 at 14:28 -0500, Tom "spot" Callaway wrote: > > > > I'd originally suggested that the existence of compat-* packages should > > be rationalized by the maintainer as part of each release cycle. > > > > Valid rationale could be (but is certainly not limited to): > > > > - Fedora applications which are not yet ported to the new interface > > - Third party applications which still depend on the old interface (that > > the maintainer is aware of specifically, not "something might use it > > someday") > > Yeah, I was going to add this to the proposal, but held off since I was > a little afraid of the added bureaucracy/madness it would bring. What's > others people thoughts on this? It's going to be a bureaucratic PITA but otherwise the path of least resistance for maintainers will be to push the same compat libs forever (and then upstreams will never move to new APIs because compat packages are always there) Would something like auto-generating a table of compat packages in the wiki around the second test release, with one column for justification, and then kill every package its packager didn't bother justifying before release time be acceptable? -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From pertusus at free.fr Wed Jan 2 21:58:08 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 2 Jan 2008 22:58:08 +0100 Subject: Policy proposal for compatibility packages In-Reply-To: <1199310924.5546.6.camel@rousalka.dyndns.org> References: <1199290909.11035.20.camel@kennedy> <20080102105614.73d4db84@vader.jdub.homelinux.org> <1199301348.3483.2.camel@rousalka.dyndns.org> <477BE5EA.9020909@redhat.com> <1199304674.16111.4.camel@kennedy> <1199310924.5546.6.camel@rousalka.dyndns.org> Message-ID: <20080102215808.GE2661@free.fr> On Wed, Jan 02, 2008 at 10:55:24PM +0100, Nicolas Mailhot wrote: > > Would something like auto-generating a table of compat packages in the > wiki around the second test release, with one column for justification, > and then kill every package its packager didn't bother justifying before > release time be acceptable? No, please don't add more things to look at without need. We are old enough to know if we want to carry over a compat package. -- Pat From pertusus at free.fr Wed Jan 2 22:03:58 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 2 Jan 2008 23:03:58 +0100 Subject: Policy proposal for compatibility packages In-Reply-To: <1199290909.11035.20.camel@kennedy> References: <1199290909.11035.20.camel@kennedy> Message-ID: <20080102220358.GF2661@free.fr> On Wed, Jan 02, 2008 at 11:21:49AM -0500, Brian Pepple wrote: > Here's a proposal for the handling of new compat packages: > > http://fedoraproject.org/wiki/BrianPepple/DraftCompatPackages > > FESCo discussed this back at our last meeting, but before we pulled the > trigger on this, I want to get feedback from the mailing list. I'm > tentatively planning on having FESCo vote on this at the 2008-01-10 > meeting, though that could change based on any feedback I receive. I am against the veto of primary package maintainer for a compat package. "chances are that they will have to be involved in the maintenance due to passing along security problems, helping out with things and redirecting misfiled bugs." is not a good reason to block a package if the package follow the guidelines in my opinion. Now the primary maintainer can raise concerns and escalate to the mailing list and to fesco if he dislikes the compat package, but like any other contributor, no need for a specific policy. The only policy should be that the compat package maintainer has to notice the primary package maintainer and let him time to comment. -- Pat From loupgaroublond at gmail.com Wed Jan 2 22:04:47 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 2 Jan 2008 17:04:47 -0500 Subject: comaintainership requests In-Reply-To: References: <47325E81.4010706@redhat.com> <1199289856.2308.15.camel@localhost.localdomain> <477BB850.4020005@math.unl.edu> <7f692fec0801021321x6b28c0e5rcea79ff0f10a3bfe@mail.gmail.com> Message-ID: <7f692fec0801021404l530acca3sec5beb5e66aa28a9@mail.gmail.com> Thanks :) On Jan 2, 2008 4:45 PM, Rex Dieter wrote: > Yaakov Nemoy wrote: > > > WHere do you go for comaintainership? I am looking to do a similar > > thing for Haskell packages. > > http://admin.fedoraproject.org/pkgdb/ > > -- Rex > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From qspencer at ieee.org Wed Jan 2 22:26:32 2008 From: qspencer at ieee.org (Quentin Spencer) Date: Wed, 02 Jan 2008 16:26:32 -0600 Subject: libdap sonames bump In-Reply-To: <20080102113159.GD2555@free.fr> References: <20080102113159.GD2555@free.fr> Message-ID: <477C0F98.80303@ieee.org> Patrice Dumas wrote: > The libdap soname changed. My guess is that a simple rebuild will be > enough, since the API change are not big. I am rebuilding my packages > There is also > > gdal-0:1.4.2-3.fc8.src > > And (though there is no libdap-devel BR?) > octave-forge-0:20071212-5.fc9.i386 > octave-forge depends indirectly on libdap-devel via libnc-dap-devel. I have rebuilt it successfully. Quentin From tcallawa at redhat.com Wed Jan 2 22:27:51 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 02 Jan 2008 17:27:51 -0500 Subject: Policy proposal for compatibility packages In-Reply-To: <20080102215010.GD2661@free.fr> References: <1199290909.11035.20.camel@kennedy> <20080102105614.73d4db84@vader.jdub.homelinux.org> <1199301348.3483.2.camel@rousalka.dyndns.org> <477BE5EA.9020909@redhat.com> <20080102215010.GD2661@free.fr> Message-ID: <477C0FE7.60105@redhat.com> Patrice Dumas wrote: > On Wed, Jan 02, 2008 at 02:28:42PM -0500, Tom spot Callaway wrote: >> - Third party applications which still depend on the old interface (that >> the maintainer is aware of specifically, not "something might use it >> someday") > > That seems to me to be a perfect reason. Please don't try to force > packagers to do something without reason. If a packager wants to invest > time to maintain a compat package, let him do. Well, one of the reasons we're making hoops for people to jump through is that we don't want to clutter the distribution with compat packages. This encourages upstream (and package maintainers) to just continue using the compat packages, rather than porting to the new, improved ones. This is why I think that this is a valid reason: * Adobe ProprietaryDocumentFormat Reader needs this library to run. And this is not: * Something might use this old library someday, but I can't cite any example. ~spot From wart at kobold.org Wed Jan 2 22:39:06 2008 From: wart at kobold.org (Michael Thomas) Date: Wed, 02 Jan 2008 14:39:06 -0800 Subject: heads up: tcl and tk 8.5 In-Reply-To: <477C080C.2000701@comcast.net> References: <477C080C.2000701@comcast.net> Message-ID: <477C128A.3010402@kobold.org> John Ellson wrote: >> The 'restricted auto_path' patch that we are adding will limit the >> search to %{_libdir}/tcl8.5 and %{_datadir}/tcl8.5. This greatly >> improves the startup time for most Tcl applications. However, it does >> require that maintainers of Tcl extension packages make some changes to >> ensure that the extensions get installed into %{_libdir}/tcl8.5 (or >> %{_datadir}/tcl8.5) instead of %{_libdir} (or %{_datadir}). I will be >> happy to help out any maintainers that want help with this change. > > > Will this information be available from some kind of introspection from > running tclsh ? Yes. You can start tclsh and run 'set auto_path'. This will print out a list of the directories that will be searched for packages. > Has this change been accepted upstream so that it can be relied on on > other platforms? I had a discussion with upstream about this, and they blamed the problem on the distributions installing Tcl and the extensions into too-generic directories. Unfortunately, most extensions were developed to be installed directly into /usr/lib and /usr/share, and now need to be patched to be installed elsewhere. In any case, you can always look at the contents of the auto_path variable on any platform in Tcl to see where extensions are looked for. --Mike From lordmorgul at gmail.com Wed Jan 2 22:42:43 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 02 Jan 2008 14:42:43 -0800 Subject: Policy proposal for compatibility packages In-Reply-To: <20080102215010.GD2661@free.fr> References: <1199290909.11035.20.camel@kennedy> <20080102105614.73d4db84@vader.jdub.homelinux.org> <1199301348.3483.2.camel@rousalka.dyndns.org> <477BE5EA.9020909@redhat.com> <20080102215010.GD2661@free.fr> Message-ID: <477C1363.3000006@gmail.com> Patrice Dumas wrote: > On Wed, Jan 02, 2008 at 02:28:42PM -0500, Tom spot Callaway wrote: >> - Third party applications which still depend on the old interface (that >> the maintainer is aware of specifically, not "something might use it >> someday") > > That seems to me to be a perfect reason. Please don't try to force > packagers to do something without reason. If a packager wants to invest > time to maintain a compat package, let him do. It seems to me that a minimal good reason' policy will at least make sure the packager really is maintaining the compat package, not just building it blindly and pushing it to a next release just because it didn't cause problems or fail to build. If the packager is going to maintain something that has some use, then more power to them. If its just there because it can be then it shouldn't be. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From pertusus at free.fr Wed Jan 2 22:48:37 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 2 Jan 2008 23:48:37 +0100 Subject: libdap sonames bump In-Reply-To: <477C0F98.80303@ieee.org> References: <20080102113159.GD2555@free.fr> <477C0F98.80303@ieee.org> Message-ID: <20080102224837.GI2661@free.fr> On Wed, Jan 02, 2008 at 04:26:32PM -0600, Quentin Spencer wrote: > > octave-forge depends indirectly on libdap-devel via libnc-dap-devel. I have > rebuilt it successfully. It couldn't fail, the libnc-dap interface didn't changed. With the next libnc-dap upstream release the dependency on libdap should be gone (this dependency is unuseful). -- Pat From pertusus at free.fr Wed Jan 2 22:53:03 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 2 Jan 2008 23:53:03 +0100 Subject: Policy proposal for compatibility packages In-Reply-To: <477C0FE7.60105@redhat.com> References: <1199290909.11035.20.camel@kennedy> <20080102105614.73d4db84@vader.jdub.homelinux.org> <1199301348.3483.2.camel@rousalka.dyndns.org> <477BE5EA.9020909@redhat.com> <20080102215010.GD2661@free.fr> <477C0FE7.60105@redhat.com> Message-ID: <20080102225303.GJ2661@free.fr> On Wed, Jan 02, 2008 at 05:27:51PM -0500, Tom spot Callaway wrote: > > Well, one of the reasons we're making hoops for people to jump through > is that we don't want to clutter the distribution with compat packages. > This encourages upstream (and package maintainers) to just continue > using the compat packages, rather than porting to the new, improved ones. Your point is moot since it is a valid reason when upstream still uses an old API. So this cannot be the reason for this unneeded bureaucracy and this lack of confidence on the packager. And in any case it is not a good idea to deter by bureaucracy. We don't want to clutter the distribution with compat packages but we should rely on packagers to do the right decision about whether a compat package is useful or not without having to resort to bureaucratic rules. Anybody can already raise his concerns about a compat package, why more procedures and such a veto power for a particular packager? -- Pat From wart at kobold.org Wed Jan 2 23:00:59 2008 From: wart at kobold.org (Michael Thomas) Date: Wed, 02 Jan 2008 15:00:59 -0800 Subject: heads up: tcl and tk 8.5 In-Reply-To: <477C16BD.4060805@comcast.net> References: <477C080C.2000701@comcast.net> <477C128A.3010402@kobold.org> <477C16BD.4060805@comcast.net> Message-ID: <477C17AB.4010104@kobold.org> John Ellson wrote: > Michael Thomas wrote: >> John Ellson wrote: >> >>>> The 'restricted auto_path' patch that we are adding will limit the >>>> search to %{_libdir}/tcl8.5 and %{_datadir}/tcl8.5. This greatly >>>> improves the startup time for most Tcl applications. However, it does >>>> require that maintainers of Tcl extension packages make some changes to >>>> ensure that the extensions get installed into %{_libdir}/tcl8.5 (or >>>> %{_datadir}/tcl8.5) instead of %{_libdir} (or %{_datadir}). I will be >>>> happy to help out any maintainers that want help with this change. >>>> >>> Will this information be available from some kind of introspection from >>> running tclsh ? >>> >> >> Yes. You can start tclsh and run 'set auto_path'. This will print out >> a list of the directories that will be searched for packages. >> >> >>> Has this change been accepted upstream so that it can be relied on on >>> other platforms? >>> >> >> I had a discussion with upstream about this, and they blamed the problem >> on the distributions installing Tcl and the extensions into too-generic >> directories. Unfortunately, most extensions were developed to be >> installed directly into /usr/lib and /usr/share, and now need to be >> patched to be installed elsewhere. >> >> In any case, you can always look at the contents of the auto_path >> variable on any platform in Tcl to see where extensions are looked for. >> >> --Mike >> >> > A bit more clarification please. > > This is not about where to look, its about where to install, so it must > resolve to a single value. In that case, no, there is no introspection in Tcl to get this information. This is because the choice of the directory in which to install depends on whether you are installing an arch-specific or a noarch package. But the rule is simple: noarch packages should get installed into %{_datadir}/tcl8.5/%{name}-%{version} arch-specific packages should get installed into %{_libdir}/tcl8.5/%{name}-%{version} The proposed Tcl packaging guidelines[1] have some scriptlets that you can use at the top of your spec file to set the installation directory: %{!?tcl_version: %define tcl_version %(echo 'puts $tcl_version' | tclsh)} %{!?tcl_sitelib: %define tcl_sitelib %{_datadir}/tcl%{tcl_version}} %{!?tcl_sitearch: %define tcl_sitearch %{_libdir}/tcl%{tcl_version}} Use %{tcl_sitearch} as the base directory for arch-specific packages, and %{tcl_sitelib} for noarch packages. > Using a vanilla upstream build of tcl8.5 I get: > % set auto_path > /usr/local/lib/tcl8.5 /usr/local/lib > > Should I always install in the first member of the list? (which would > be /usr/lib/tcl8.5 normally) > > And under that, I presumably install in a package-specific subdirectory? > Such as: /usr/lib/tcl8.5/graphviz/ Correct. You could add %{version} to the package-specific subdirectory name so that it's possible to have multiple versions installed at the same time, but that's not a requirement. --Wart [1] http://fedoraproject.org/wiki/PackagingDrafts/Tcl From wart at kobold.org Wed Jan 2 23:29:12 2008 From: wart at kobold.org (Michael Thomas) Date: Wed, 02 Jan 2008 15:29:12 -0800 Subject: heads up: tcl and tk 8.5 In-Reply-To: <477C1E4B.1060507@comcast.net> References: <477C080C.2000701@comcast.net> <477C128A.3010402@kobold.org> <477C16BD.4060805@comcast.net> <477C17AB.4010104@kobold.org> <477C1E4B.1060507@comcast.net> Message-ID: <477C1E48.1020608@kobold.org> John Ellson wrote: > Michael Thomas wrote: >> John Ellson wrote: >> >>> Michael Thomas wrote: >>> >>>> John Ellson wrote: >>>> >>>> >>>>>> The 'restricted auto_path' patch that we are adding will limit the >>>>>> search to %{_libdir}/tcl8.5 and %{_datadir}/tcl8.5. This greatly >>>>>> improves the startup time for most Tcl applications. However, it >>>>>> does >>>>>> require that maintainers of Tcl extension packages make some >>>>>> changes to >>>>>> ensure that the extensions get installed into %{_libdir}/tcl8.5 (or >>>>>> %{_datadir}/tcl8.5) instead of %{_libdir} (or %{_datadir}). I >>>>>> will be >>>>>> happy to help out any maintainers that want help with this change. >>>>>> >>>>> Will this information be available from some kind of introspection >>>>> from >>>>> running tclsh ? >>>>> >>>> Yes. You can start tclsh and run 'set auto_path'. This will print out >>>> a list of the directories that will be searched for packages. >>>> >>>> >>>> >>>>> Has this change been accepted upstream so that it can be relied on on >>>>> other platforms? >>>>> >>>> I had a discussion with upstream about this, and they blamed the >>>> problem >>>> on the distributions installing Tcl and the extensions into too-generic >>>> directories. Unfortunately, most extensions were developed to be >>>> installed directly into /usr/lib and /usr/share, and now need to be >>>> patched to be installed elsewhere. >>>> >>>> In any case, you can always look at the contents of the auto_path >>>> variable on any platform in Tcl to see where extensions are looked for. >>>> >>>> --Mike >>>> >>>> >>> A bit more clarification please. >>> >>> This is not about where to look, its about where to install, so it must >>> resolve to a single value. >>> >> >> In that case, no, there is no introspection in Tcl to get this >> information. This is because the choice of the directory in which to >> install depends on whether you are installing an arch-specific or a >> noarch package. But the rule is simple: >> >> noarch packages should get installed into >> %{_datadir}/tcl8.5/%{name}-%{version} >> >> arch-specific packages should get installed into >> %{_libdir}/tcl8.5/%{name}-%{version} >> >> The proposed Tcl packaging guidelines[1] have some scriptlets that you >> can use at the top of your spec file to set the installation directory: >> >> %{!?tcl_version: %define tcl_version %(echo 'puts $tcl_version' | tclsh)} >> %{!?tcl_sitelib: %define tcl_sitelib %{_datadir}/tcl%{tcl_version}} >> %{!?tcl_sitearch: %define tcl_sitearch %{_libdir}/tcl%{tcl_version}} >> >> Use %{tcl_sitearch} as the base directory for arch-specific packages, >> and %{tcl_sitelib} for noarch packages. >> >> >>> Using a vanilla upstream build of tcl8.5 I get: >>> % set auto_path >>> /usr/local/lib/tcl8.5 /usr/local/lib >>> >>> Should I always install in the first member of the list? (which would >>> be /usr/lib/tcl8.5 normally) >>> >>> And under that, I presumably install in a package-specific subdirectory? >>> Such as: /usr/lib/tcl8.5/graphviz/ >>> >> >> Correct. You could add %{version} to the package-specific subdirectory >> name so that it's possible to have multiple versions installed at the >> same time, but that's not a requirement. >> >> --Wart >> [1] http://fedoraproject.org/wiki/PackagingDrafts/Tcl >> >> > > Will tclConfig.sh remain in %{_libdir}/tclConfig.sh, or will it now be > in %{_libdir}/tclsh8.5/tclConfig.sh ? > > (I think some other distros must do this already, since I already test > for this in graphviz.) tclConfig.sh will remain in %{_libdir}/tclConfig.sh. --Wart From bpepple at fedoraproject.org Wed Jan 2 23:32:03 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 02 Jan 2008 18:32:03 -0500 Subject: Policy proposal for compatibility packages In-Reply-To: <20080102225303.GJ2661@free.fr> References: <1199290909.11035.20.camel@kennedy> <20080102105614.73d4db84@vader.jdub.homelinux.org> <1199301348.3483.2.camel@rousalka.dyndns.org> <477BE5EA.9020909@redhat.com> <20080102215010.GD2661@free.fr> <477C0FE7.60105@redhat.com> <20080102225303.GJ2661@free.fr> Message-ID: <1199316723.24135.2.camel@nixon> On Wed, 2008-01-02 at 23:53 +0100, Patrice Dumas wrote: > Anybody can already raise his concerns about a compat package, why more > procedures and such a veto power for a particular packager? For the reasons spelled out in the proposal: 'The reasoning for the latter is that even if the primary maintainer is not maintaining the compatibility package, chances are that they will have to be involved in the maintenance due to passing along security problems, helping out with things and redirecting misfiled bugs.' /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pertusus at free.fr Wed Jan 2 23:36:19 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 3 Jan 2008 00:36:19 +0100 Subject: Policy proposal for compatibility packages In-Reply-To: <1199316723.24135.2.camel@nixon> References: <1199290909.11035.20.camel@kennedy> <20080102105614.73d4db84@vader.jdub.homelinux.org> <1199301348.3483.2.camel@rousalka.dyndns.org> <477BE5EA.9020909@redhat.com> <20080102215010.GD2661@free.fr> <477C0FE7.60105@redhat.com> <20080102225303.GJ2661@free.fr> <1199316723.24135.2.camel@nixon> Message-ID: <20080102233619.GM2661@free.fr> On Wed, Jan 02, 2008 at 06:32:03PM -0500, Brian Pepple wrote: > On Wed, 2008-01-02 at 23:53 +0100, Patrice Dumas wrote: > > Anybody can already raise his concerns about a compat package, why more > > procedures and such a veto power for a particular packager? > > For the reasons spelled out in the proposal: 'The reasoning for the > latter is that even if the primary maintainer is not maintaining the > compatibility package, chances are that they will have to be involved in > the maintenance due to passing along security problems, helping out with > things and redirecting misfiled bugs.' If a particular maintainer has those concerns he can raise them without having this veto power. This makes an unneeded assymetry between a primary maintainer and somebody who would like to do a compat package. There is no reason why a primary maintainer would be smarter than somebody wanting a compat package. -- Pat From dmc.fedora at filteredperception.org Wed Jan 2 23:43:12 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Wed, 02 Jan 2008 17:43:12 -0600 Subject: f8 gripe #3: infamous Load_Cycle_Count started hitting my laptop, FAQ? In-Reply-To: <200801021518.48123.opensource@till.name> References: <477AE01A.6060302@filteredperception.org> <200801021518.48123.opensource@till.name> Message-ID: <477C2190.7000608@filteredperception.org> Till Maas wrote: > On Mi Januar 2 2008, Douglas McClendon wrote: > >> Quite simply, what is the prescribed way for me to run 'hdparm -B 254 >> /dev/sda' upon resume from suspend and hibernate? (or a better solution >> than that). > > You can test a new hook that should restore you hd apm settings. Just copy > https://cvs.fedoraproject.org/viewcvs/*checkout*/rpms/pm-utils/devel/pm-utils-99hd-apm-restore > to /usr/lib/pm-utils/sleep.d/99hd-apm-restore Thanks, that looks like it will work for me. Just for complete reference, here is an ubuntu bug, in which it is mentioned that for some reason 255 doesn't work for everyone (thus _maybe_ 254 is a better default) https://wiki.ubuntu.com/DanielHahler/Bug59695 Thanks, -dmc > > Regards, > Till > From cebbert at redhat.com Wed Jan 2 23:51:47 2008 From: cebbert at redhat.com (Chuck Ebbert) Date: Wed, 02 Jan 2008 18:51:47 -0500 Subject: Vanilla kernel RPM? In-Reply-To: <1198356237.15145.3.camel@rousalka.dyndns.org> References: <1198351701.3594.23.camel@vincent52.localdomain> <20071222133345.49eea037@hansolo.jdub.homelinux.org> <1198352393.14553.2.camel@rousalka.dyndns.org> <20071222141049.359b1931@hansolo.jdub.homelinux.org> <1198356237.15145.3.camel@rousalka.dyndns.org> Message-ID: <477C2393.3020303@redhat.com> On 12/22/2007 03:43 PM, Nicolas Mailhot wrote: > Le samedi 22 d?cembre 2007 ? 14:10 -0600, Josh Boyer a ?crit : >> On Sat, 22 Dec 2007 20:39:52 +0100 >> Nicolas Mailhot wrote: >> >>> Le samedi 22 d?cembre 2007 ? 13:33 -0600, Josh Boyer a ?crit : >>>> On Sat, 22 Dec 2007 19:28:21 +0000 >>>> Matthew Saltzman wrote: >>>> The specfile in rawhide has a vanilla option. All you have to do is >>>> run: >>>> >>>> make vanilla-$TARGET >>>> >>>> And it will build a vanilla kernel (with only patches for the config >>>> mechanisms IIRC). >>> Does it really work? I know I had to move the oldconfig patch when I >>> adapted the specfile to mm kernels (patch already posted, can rebase and >>> re-post if someone wants to add mm build capabilities to fedora spec) >> It worked for me a while ago. Though I wasn't adding patches. I was >> just building what was in CVS without the extra patches. > > IIRC the spec logic relies on a special make oldconfig target which is > only available if the non-interactive oldconfig patch is applied on the > kernel. Which means this particular patch can not be skipped even in the > vanilla case. > That is what is does when you build a vanilla kernel from the fedora spec file -- it only applies the oldconfig patch and any needed official kernel updates. (-rcX and -gitY for rawhide, stable updates for release kernels.) From bpepple at fedoraproject.org Wed Jan 2 23:52:26 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 02 Jan 2008 18:52:26 -0500 Subject: Policy proposal for compatibility packages In-Reply-To: <20080102233619.GM2661@free.fr> References: <1199290909.11035.20.camel@kennedy> <20080102105614.73d4db84@vader.jdub.homelinux.org> <1199301348.3483.2.camel@rousalka.dyndns.org> <477BE5EA.9020909@redhat.com> <20080102215010.GD2661@free.fr> <477C0FE7.60105@redhat.com> <20080102225303.GJ2661@free.fr> <1199316723.24135.2.camel@nixon> <20080102233619.GM2661@free.fr> Message-ID: <1199317946.24135.14.camel@nixon> On Thu, 2008-01-03 at 00:36 +0100, Patrice Dumas wrote: > On Wed, Jan 02, 2008 at 06:32:03PM -0500, Brian Pepple wrote: > > On Wed, 2008-01-02 at 23:53 +0100, Patrice Dumas wrote: > > > Anybody can already raise his concerns about a compat package, why more > > > procedures and such a veto power for a particular packager? > > > > For the reasons spelled out in the proposal: 'The reasoning for the > > latter is that even if the primary maintainer is not maintaining the > > compatibility package, chances are that they will have to be involved in > > the maintenance due to passing along security problems, helping out with > > things and redirecting misfiled bugs.' > > If a particular maintainer has those concerns he can raise them without > having this veto power. This makes an unneeded assymetry between a > primary maintainer and somebody who would like to do a compat package. > There is no reason why a primary maintainer would be smarter than > somebody wanting a compat package. I think we're going to have to agree to disagree on this point, since I feel pretty strongly that the primary maintainer should have a voice in this process since it could affect their workload. Regardless, as the proposal states, if the compat maintainer and the primary maintainer cannot come to a mutual decision, it can be escalated to FESCo to make the final decision. Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pertusus at free.fr Wed Jan 2 23:55:17 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 3 Jan 2008 00:55:17 +0100 Subject: Policy proposal for compatibility packages In-Reply-To: <1199317946.24135.14.camel@nixon> References: <1199290909.11035.20.camel@kennedy> <20080102105614.73d4db84@vader.jdub.homelinux.org> <1199301348.3483.2.camel@rousalka.dyndns.org> <477BE5EA.9020909@redhat.com> <20080102215010.GD2661@free.fr> <477C0FE7.60105@redhat.com> <20080102225303.GJ2661@free.fr> <1199316723.24135.2.camel@nixon> <20080102233619.GM2661@free.fr> <1199317946.24135.14.camel@nixon> Message-ID: <20080102235517.GN2661@free.fr> On Wed, Jan 02, 2008 at 06:52:26PM -0500, Brian Pepple wrote: > > > > If a particular maintainer has those concerns he can raise them without > > having this veto power. This makes an unneeded assymetry between a > > primary maintainer and somebody who would like to do a compat package. > > There is no reason why a primary maintainer would be smarter than > > somebody wanting a compat package. > > I think we're going to have to agree to disagree on this point, since I > feel pretty strongly that the primary maintainer should have a voice in > this process since it could affect their workload. > > Regardless, as the proposal states, if the compat maintainer and the > primary maintainer cannot come to a mutual decision, it can be escalated > to FESCo to make the final decision. So this is not needed to * add yet more rules * show a preference for the primary maintainer since the same rules as always can simply apply. -- Pat From dmc.fedora at filteredperception.org Thu Jan 3 00:17:33 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Wed, 02 Jan 2008 18:17:33 -0600 Subject: f8 gripe#2: why did f8's pm-hibernate regress? In-Reply-To: <200801021159.17964.opensource@till.name> References: <477ADF46.2040108@filteredperception.org> <200801021159.17964.opensource@till.name> Message-ID: <477C299D.2060400@filteredperception.org> Till Maas wrote: > On Mi Januar 2 2008, Douglas McClendon wrote: >> Can someone tell me if there is anything I can do to de-regress f8's >> pm-hibernate? > > pm-utils hibernation code does not differ much between f7 and f8. > >> My analysis is pure speculation based on my understanding of how you can >> tune that behaviour with suspend2(tux-on-ice). But it is very noticable >> and very annoying and very clearly a f7->f8 change. > > I guess it is then a change in the kernel, but afaik the f7 and f8 kernel are > very similiar, too. http://lwn.net/Articles/153203/ Just for the benefit of future web searchers with the same question, here is an interesting thread covering the specific issue. My real curiosity is still why the performance I see regressed so badly when I upgraded to F8. The thread leads me to believe that the the F7 swsusp1 did not save caches. Hmm... I have been enjoying the convenience of fedora's suspend-works-out-of-the-box for awhile now, but I think it might be time for me to go back to tux-on-ice. I truly am disgusted by having to suffer through 5-15 seconds of thrashing while changing desktops after resume. I would much rather the resume take 20 seconds longer, and present me with a good user experience. (yes, I am one of those people that thinks that offering early login while the system finishes booting is a really stupid thing). -dmc From ngaywood at une.edu.au Thu Jan 3 00:40:09 2008 From: ngaywood at une.edu.au (Norman Gaywood) Date: Thu, 3 Jan 2008 11:40:09 +1100 Subject: What needs to be done to get LTSP 5 into Fedora? Message-ID: <20080103004009.GA19625@turing.une.edu.au> On 2007-05-24 in https://bugzilla.redhat.com/show_bug.cgi?id=234048 (LTSP 5 support needed), Jesse Keating suggests: > Please start a conversation on fedora-devel-list at redhat.com so that more > interested parties can chime in and start fleshing out what it is that > is needed of Fedora. I didn't notice that conversation being started, so I thought I would give it a go. I'm quite keen to get LTSP 5 going and would like to use Fedora but I'm having trouble finding anything to test. -- Norman Gaywood, Systems Administrator University of New England, Armidale, NSW 2351, Australia ngaywood at une.edu.au Phone: +61 (0)2 6773 3337 http://mcs.une.edu.au/~norm Fax: +61 (0)2 6773 3312 Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From pertusus at free.fr Thu Jan 3 00:54:14 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 3 Jan 2008 01:54:14 +0100 Subject: What needs to be done to get LTSP 5 into Fedora? In-Reply-To: <20080103004009.GA19625@turing.une.edu.au> References: <20080103004009.GA19625@turing.une.edu.au> Message-ID: <20080103005414.GO2661@free.fr> On Thu, Jan 03, 2008 at 11:40:09AM +1100, Norman Gaywood wrote: > On 2007-05-24 in https://bugzilla.redhat.com/show_bug.cgi?id=234048 > (LTSP 5 support needed), Jesse Keating suggests: > > Please start a conversation on fedora-devel-list at redhat.com so that more > > interested parties can chime in and start fleshing out what it is that > > is needed of Fedora. > > I didn't notice that conversation being started, so I thought I would > give it a go. > > I'm quite keen to get LTSP 5 going and would like to use Fedora but I'm > having trouble finding anything to test. There has been some work. There is a tracker bug https://bugzilla.redhat.com/show_bug.cgi?id=188611 But I don't know what the status is right now. First K12LTSP packages were to be included, things begun a bit hastily, then stopped half-way. It seems that now the developpement should happen at https://launchpad.net/~ltsp-drivers but I don't know where fedora stuff is in it. Warren Togami and Eric Harrison were the one who lead the ltsp inclusion. -- Pat From jwboyer at gmail.com Thu Jan 3 01:11:48 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 2 Jan 2008 19:11:48 -0600 Subject: Policy proposal for compatibility packages In-Reply-To: <20080102220358.GF2661@free.fr> References: <1199290909.11035.20.camel@kennedy> <20080102220358.GF2661@free.fr> Message-ID: <20080102191148.2371ae8c@vader.jdub.homelinux.org> On Wed, 2 Jan 2008 23:03:58 +0100 Patrice Dumas wrote: > On Wed, Jan 02, 2008 at 11:21:49AM -0500, Brian Pepple wrote: > > Here's a proposal for the handling of new compat packages: > > > > http://fedoraproject.org/wiki/BrianPepple/DraftCompatPackages > > > > FESCo discussed this back at our last meeting, but before we pulled the > > trigger on this, I want to get feedback from the mailing list. I'm > > tentatively planning on having FESCo vote on this at the 2008-01-10 > > meeting, though that could change based on any feedback I receive. > > I am against the veto of primary package maintainer for a compat > package. "chances are that they will have to be involved in the > maintenance due to passing along security problems, helping out with > things and redirecting misfiled bugs." is not a good reason to block a > package if the package follow the guidelines in my opinion. Now the > primary maintainer can raise concerns and escalate to the mailing list > and to fesco if he dislikes the compat package, but like any other > contributor, no need for a specific policy. The only policy should be > that the compat package maintainer has to notice the primary package > maintainer and let him time to comment. That's what the proposal says, only in reverse. The compat package maintainer can escalate to FESCo if he doesn't agree with the primary packager's veto. Either way it ends up the same. Escalate to FESCo. josh From poelstra at redhat.com Thu Jan 3 01:30:15 2008 From: poelstra at redhat.com (John Poelstra) Date: Wed, 02 Jan 2008 17:30:15 -0800 Subject: GPG Keysigning at FUDCon In-Reply-To: <20071212214010.GA20896@auslistsprd01.us.dell.com> References: <20071212214010.GA20896@auslistsprd01.us.dell.com> Message-ID: <477C3AA7.9010700@redhat.com> Matt Domsch said the following on 12/12/2007 01:40 PM Pacific Time: > I'm volunteering to run a GPG keysigning party at the FUDCon in > Raleigh in January. Keysignings are good ways to get to meet people > face-to-face (with a government-issued photo ID to boot!), and serves > to extend the GPG Web of Trust. > > See > http://barcamp.org/FUDConRaleigh2008 > > for details on how to send me your keys beforehand. > > hanks, > Matt > My key has expired and it is also associated with my Fedora account which raises a few questions to get straightened out before FUDCon: 1) Do I need to revoke my expired key? I'm not even sure if this can be done or matters. 2) Once I generate a new key, I assume I should add its fingerprint to my Fedora account--removing the existing one? 3) Do most people create keys that expire or is it okay to create one that does not? Thanks, John From jwboyer at gmail.com Thu Jan 3 01:43:52 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 2 Jan 2008 19:43:52 -0600 Subject: Policy proposal for compatibility packages In-Reply-To: <20080102235517.GN2661@free.fr> References: <1199290909.11035.20.camel@kennedy> <20080102105614.73d4db84@vader.jdub.homelinux.org> <1199301348.3483.2.camel@rousalka.dyndns.org> <477BE5EA.9020909@redhat.com> <20080102215010.GD2661@free.fr> <477C0FE7.60105@redhat.com> <20080102225303.GJ2661@free.fr> <1199316723.24135.2.camel@nixon> <20080102233619.GM2661@free.fr> <1199317946.24135.14.camel@nixon> <20080102235517.GN2661@free.fr> Message-ID: <20080102194352.5e0d5bd5@vader.jdub.homelinux.org> On Thu, 3 Jan 2008 00:55:17 +0100 Patrice Dumas wrote: > On Wed, Jan 02, 2008 at 06:52:26PM -0500, Brian Pepple wrote: > > > > > > If a particular maintainer has those concerns he can raise them without > > > having this veto power. This makes an unneeded assymetry between a > > > primary maintainer and somebody who would like to do a compat package. > > > There is no reason why a primary maintainer would be smarter than > > > somebody wanting a compat package. > > > > I think we're going to have to agree to disagree on this point, since I > > feel pretty strongly that the primary maintainer should have a voice in > > this process since it could affect their workload. > > > > Regardless, as the proposal states, if the compat maintainer and the > > primary maintainer cannot come to a mutual decision, it can be escalated > > to FESCo to make the final decision. > > So this is not needed to > * add yet more rules > * show a preference for the primary maintainer > since the same rules as always can simply apply. Entirely too large of a deal is being made on this "veto" power. It's not really a "veto", as they have no mechanism to enforce it anyway. The proposal doesn't even have the word "veto" in it. Just change this: "...and the primary package maintainer is not against the idea." to this: "...and there are no objections from the primary packager (or any other packager knowledgeable about the package)." and it's fine. Escalations all go to FESCo, regardless. You are both saying the same thing, just with different flavors. Realize this, and move on. josh From mattdm at mattdm.org Thu Jan 3 01:48:12 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 2 Jan 2008 20:48:12 -0500 Subject: RFC: Fedora Xfce Spin In-Reply-To: <477BCF70.6080601@fedoraproject.org> References: <477BCF70.6080601@fedoraproject.org> Message-ID: <20080103014812.GA7617@jadzia.bu.edu> On Wed, Jan 02, 2008 at 11:22:48PM +0530, Rahul Sundaram wrote: > feedback, fixes and suggestions on any improvements possible. My > intention it to do a initial release for Fedora 8 and continue with > incremental improvements over the Fedora 9 development period and have a > solid Xfce spin as part of the Fedora 9 release. Cool. I'll look at it when I get out of this snowstorm and back to Boston. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From tmz at pobox.com Thu Jan 3 02:10:49 2008 From: tmz at pobox.com (Todd Zullinger) Date: Wed, 2 Jan 2008 21:10:49 -0500 Subject: GPG Keysigning at FUDCon In-Reply-To: <477C3AA7.9010700@redhat.com> References: <20071212214010.GA20896@auslistsprd01.us.dell.com> <477C3AA7.9010700@redhat.com> Message-ID: <20080103021049.GK8896@inocybe.teonanacatl.org> John Poelstra wrote: > My key has expired and it is also associated with my Fedora account > which raises a few questions to get straightened out before FUDCon: > > 1) Do I need to revoke my expired key? No, you don't have to revoke it. In fact, you can remove or extend the expiration date and continue using your current key if you like. > I'm not even sure if this can be done or matters. Yes, it can be done (as long as you still have the private key, of course). > 2) Once I generate a new key, I assume I should add its fingerprint > to my Fedora account--removing the existing one? (I'll defer to someone that has more of a clue about the fedora account system. :) > 3) Do most people create keys that expire or is it okay to create > one that does not? I don't know about most people, but I think it's okay to not have an expiration date on a key. You can also add one later if you change your mind. I have no expiration date on my primary key, but I do have one on the encryption subkey. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Some people are like Slinkies... not really good for anything, but you still can't help but smile when you see one tumble down the stairs. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From dcantrell at redhat.com Thu Jan 3 02:10:32 2008 From: dcantrell at redhat.com (David Cantrell) Date: Wed, 2 Jan 2008 16:10:32 -1000 Subject: parted license change to GPLv3+ Message-ID: <20080102161032.6ec08e00.dcantrell@redhat.com> FYI I am upgrading the parted package in Fedora to the latest upstream version. Among other things, the license for parted is now GPLv3 or any later version. I've checked everything in Fedora that uses parted and all things that are currently using it are [now] compatible with the license, but new components that want to use libparted will need to make sure the license is compatible. If you have any questions, feel free to post here or email me directly. Thanks, -- David Cantrell Red Hat / Honolulu, HI -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From tmz at pobox.com Thu Jan 3 02:44:23 2008 From: tmz at pobox.com (Todd Zullinger) Date: Wed, 2 Jan 2008 21:44:23 -0500 Subject: GPG Keysigning at FUDCon In-Reply-To: <20071212214010.GA20896@auslistsprd01.us.dell.com> References: <20071212214010.GA20896@auslistsprd01.us.dell.com> Message-ID: <20080103024423.GL8896@inocybe.teonanacatl.org> Matt Domsch wrote: > I'm volunteering to run a GPG keysigning party at the FUDCon in > Raleigh in January. And thank you for that Matt. It should be fun. > Keysignings are good ways to get to meet people face-to-face (with a > government-issued photo ID to boot!), and serves to extend the GPG > Web of Trust. > > http://barcamp.org/FUDConRaleigh2008 > > for details on how to send me your keys beforehand. Do you want folks to send you their keys or just their key info (the output of gpg --fingerprint)? The wiki says send your key, but the command used won't send the key, just the key info. If you haven't seen it before, I'd recommend giving a look at the "Efficient Group Key Signing Method" by Len Sassaman and Phil Zimmermann, documented at http://sion.quickie.net/keysigning.txt It cuts a lot of the tediousness out of a key signing involving more than just a few people. I'd be glad to offer any help you might want in preparing for this. I've only helped organize a few key signings, but I've been using and following PGP for what seems like ages. :) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For a list of all the ways technology has failed to improve the quality of life, please press three. -- Alice Kahn, writer -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From loupgaroublond at gmail.com Thu Jan 3 02:59:59 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 2 Jan 2008 21:59:59 -0500 Subject: Haskell SIG and Haskell Support Message-ID: <7f692fec0801021859n2f83b6f0n20b82182c273bc05@mail.gmail.com> Hi List, I've taken the time to work on packaging up some Haskell bits for Fedora. I would like to introduce good Haskell support as a Fedora 9 feature. There are a large number of libraries that could be easily packaged, and I've been trying to get the hard bits down. I put together some packaging guidelines that need to be filled out by experts all around, and a feature proposal. http://fedoraproject.org/wiki/Features/GoodHaskellSupport http://fedoraproject.org/wiki/PackagingDrafts/Haskell http://fedoraproject.org/wiki/SIGs/Haskell Fortunately, FudCon is coming up, so if anyone is interested in putting in a bit of input, we can coordinate then. Cheers, Yaakov From Matt_Domsch at dell.com Thu Jan 3 03:13:32 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 2 Jan 2008 21:13:32 -0600 Subject: GPG Keysigning at FUDCon In-Reply-To: <20080103024423.GL8896@inocybe.teonanacatl.org> References: <20071212214010.GA20896@auslistsprd01.us.dell.com> <20080103024423.GL8896@inocybe.teonanacatl.org> Message-ID: <20080103031332.GA13994@auslistsprd01.us.dell.com> On Wed, Jan 02, 2008 at 09:44:23PM -0500, Todd Zullinger wrote: > Matt Domsch wrote: > > I'm volunteering to run a GPG keysigning party at the FUDCon in > > Raleigh in January. > > And thank you for that Matt. It should be fun. > > > Keysignings are good ways to get to meet people face-to-face (with a > > government-issued photo ID to boot!), and serves to extend the GPG > > Web of Trust. > > > > http://barcamp.org/FUDConRaleigh2008 > > > > for details on how to send me your keys beforehand. > > Do you want folks to send you their keys or just their key info (the > output of gpg --fingerprint)? The wiki says send your key, but the > command used won't send the key, just the key info. gpg --fingerprint is fine - I'm pulling the keys themselves from the public keyservers based on the fingerprint. This makes sure the keys get published at least once to the keyservers (and of course, to be of benefit after the keysigning, they'll have to be published again.) > If you haven't seen it before, I'd recommend giving a look at the > "Efficient Group Key Signing Method" by Len Sassaman and Phil > Zimmermann, documented at http://sion.quickie.net/keysigning.txt > > It cuts a lot of the tediousness out of a key signing involving more > than just a few people. yep. That's basically my plan. So far only ~14 people have sent me keys, so even bicycle chain won't take but a few minutes. I'll email everyone who has sent keys, and fedora-devel, the instructions early next week for getting the plaintext list of keys, the keyring I've compiled from the sent fingerprints, the SHAx sums and the rest. > I'd be glad to offer any help you might want in preparing for this. > I've only helped organize a few key signings, but I've been using and > following PGP for what seems like ages. :) You bet - please keep me honest too. :-) -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From josef at toxicpanda.com Thu Jan 3 03:50:06 2008 From: josef at toxicpanda.com (Josef Bacik) Date: Wed, 2 Jan 2008 22:50:06 -0500 Subject: FUDCon Hackfests Message-ID: <1b7401870801021950n286bb3bdxb1bc7e32b4bf45de@mail.gmail.com> Hello, Just curious about what exactly is entailed in a hackfest? For example I plan on going to the kernel hackfest, do I need my laptop for actual "hacking" or is it more of a bird of a feather type thing like at OLS? Thanks much, Josef From skvidal at fedoraproject.org Thu Jan 3 03:51:49 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 02 Jan 2008 22:51:49 -0500 Subject: FUDCon Hackfests In-Reply-To: <1b7401870801021950n286bb3bdxb1bc7e32b4bf45de@mail.gmail.com> References: <1b7401870801021950n286bb3bdxb1bc7e32b4bf45de@mail.gmail.com> Message-ID: <1199332309.3921.57.camel@cutter> On Wed, 2008-01-02 at 22:50 -0500, Josef Bacik wrote: > Hello, > > Just curious about what exactly is entailed in a hackfest? For > example I plan on going to the kernel hackfest, do I need my laptop > for actual "hacking" or is it more of a bird of a feather type thing > like at OLS? Thanks much, hackfest: sit in a room with a bunch of other people and actually work on code. -sv From jkeating at redhat.com Thu Jan 3 04:22:37 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 2 Jan 2008 23:22:37 -0500 Subject: GPG Keysigning at FUDCon In-Reply-To: <477C3AA7.9010700@redhat.com> References: <20071212214010.GA20896@auslistsprd01.us.dell.com> <477C3AA7.9010700@redhat.com> Message-ID: <20080102232237.2080ac1d@redhat.com> On Wed, 02 Jan 2008 17:30:15 -0800 John Poelstra wrote: > 3) Do most people create keys that expire or is it okay to create one > that does not? I've heard that a good strategy if you're going to generate a non-expiring key is to generate the revocation key at the same time, and replicate that in even more places, so in the event that you lose your private key you can revoke it instead of waiting for it to expire. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From roopesh.majeti at gmail.com Thu Jan 3 04:57:55 2008 From: roopesh.majeti at gmail.com (roopesh majeti) Date: Thu, 3 Jan 2008 10:27:55 +0530 Subject: FUDCon Hackfests In-Reply-To: <1199332309.3921.57.camel@cutter> References: <1b7401870801021950n286bb3bdxb1bc7e32b4bf45de@mail.gmail.com> <1199332309.3921.57.camel@cutter> Message-ID: <599059470801022057v4b278fabl2c8fafbaf53ffe7a@mail.gmail.com> Sorry to spam. But just want to know when and where is this hackfest ? Is it online or offline in USA ? On Jan 3, 2008 9:21 AM, seth vidal wrote: > > On Wed, 2008-01-02 at 22:50 -0500, Josef Bacik wrote: > > Hello, > > > > Just curious about what exactly is entailed in a hackfest? For > > example I plan on going to the kernel hackfest, do I need my laptop > > for actual "hacking" or is it more of a bird of a feather type thing > > like at OLS? Thanks much, > > hackfest: sit in a room with a bunch of other people and actually work > on code. > > -sv > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmz at pobox.com Thu Jan 3 05:06:33 2008 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 3 Jan 2008 00:06:33 -0500 Subject: GPG Keysigning at FUDCon In-Reply-To: <20080102232237.2080ac1d@redhat.com> References: <20071212214010.GA20896@auslistsprd01.us.dell.com> <477C3AA7.9010700@redhat.com> <20080102232237.2080ac1d@redhat.com> Message-ID: <20080103050633.GM8896@inocybe.teonanacatl.org> Jesse Keating wrote: > I've heard that a good strategy if you're going to generate a > non-expiring key is to generate the revocation key at the same time, > and replicate that in even more places, so in the event that you > lose your private key you can revoke it instead of waiting for it to > expire. I'd say that generating a revocation cert is always the first thing to do after creating a new key, whether it expires or not. You always want to be able to revoke a key if you get into a pinch for whatever reason. Just peruse the archives of the pgp and gnupg lists and notice how often someone shows up with the "I uploaded a key to the keyserver and now I've lost the key because {my hard drive died,my dog ate it,etc}, so how do I delete the key from the keyservers?" problem. :) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Tact is just a mutual agreement to be full of shit. -- Spider Robinson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From poelstra at redhat.com Thu Jan 3 05:19:09 2008 From: poelstra at redhat.com (John Poelstra) Date: Wed, 02 Jan 2008 21:19:09 -0800 Subject: FUDCon Hackfests In-Reply-To: <599059470801022057v4b278fabl2c8fafbaf53ffe7a@mail.gmail.com> References: <1b7401870801021950n286bb3bdxb1bc7e32b4bf45de@mail.gmail.com> <1199332309.3921.57.camel@cutter> <599059470801022057v4b278fabl2c8fafbaf53ffe7a@mail.gmail.com> Message-ID: <477C704D.5030206@redhat.com> roopesh majeti said the following on 01/02/2008 08:57 PM Pacific Time: > > Sorry to spam. > But just want to know when and where is this hackfest ? > Is it online or offline in USA ? > http://barcamp.pbwiki.com/FUDConRaleigh2008 From dmc.fedora at filteredperception.org Thu Jan 3 08:03:04 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Thu, 03 Jan 2008 02:03:04 -0600 Subject: f8 gripe#2: why did f8's pm-hibernate regress? In-Reply-To: <477C299D.2060400@filteredperception.org> References: <477ADF46.2040108@filteredperception.org> <200801021159.17964.opensource@till.name> <477C299D.2060400@filteredperception.org> Message-ID: <477C96B8.6040903@filteredperception.org> Douglas McClendon wrote: [ pro-tux-on-ice rant snipped ] > might be time for me to go back to tux-on-ice. I truly am disgusted by > having to suffer through 5-15 seconds of thrashing while changing > desktops after resume. I would much rather the resume take 20 seconds > longer, and present me with a good user experience. (yes, I am one of > those people that thinks that offering early login while the system > finishes booting is a really stupid thing). To clarify this harsh, theoretically offensive statement- Early login done _right_ would be fine. Doing it the incomplete way, such as the vista experience, is IMO a regression, not a feature. I.e. it boggles my mind that fast boot-to-login time is perceived as so valuable, that the implementers will let a user's first experience with the system be at its absolute valley(anti-peak) responsiveness phase. I guess for early login this isn't so bad, as people just learn that the fast boot time is an illusion and that it's better to sit back and let the system IO settle before using it. But what started my rant was the swsusp choice, which is not workaroundable by just letting the system IO settle. and the 5-15 seconds was a bit of an exageration, more like 5-10. But still, evocative of winblowz 3.1 swap thrashing.... -dmc From pertusus at free.fr Thu Jan 3 08:35:18 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 3 Jan 2008 09:35:18 +0100 Subject: Policy proposal for compatibility packages In-Reply-To: <20080102194352.5e0d5bd5@vader.jdub.homelinux.org> References: <1199301348.3483.2.camel@rousalka.dyndns.org> <477BE5EA.9020909@redhat.com> <20080102215010.GD2661@free.fr> <477C0FE7.60105@redhat.com> <20080102225303.GJ2661@free.fr> <1199316723.24135.2.camel@nixon> <20080102233619.GM2661@free.fr> <1199317946.24135.14.camel@nixon> <20080102235517.GN2661@free.fr> <20080102194352.5e0d5bd5@vader.jdub.homelinux.org> Message-ID: <20080103083518.GB2572@free.fr> On Wed, Jan 02, 2008 at 07:43:52PM -0600, Josh Boyer wrote: > > Entirely too large of a deal is being made on this "veto" power. It's > not really a "veto", as they have no mechanism to enforce it anyway. That'ds true for all the guidelines. No packager has special power to enforce anything (there are the acl, but it may only be for his own package). But guidelines are still giving more power to those who ask other packagers to comply. > The proposal doesn't even have the word "veto" in it. It has: "and the primary package maintainer is not against the idea" which is essentially the same. > Just change this: > > "...and the primary package maintainer is not against the idea." > > to this: > > "...and there are no objections from the primary packager (or any > other packager knowledgeable about the package)." Not exactly. For all the packages this clause is also here (every packager can 'block' a review and escalate to FESCo if another packager is ready to accept the package), but it doesn't need to be stated. In my opinion it would be much better to say something along (it is not much shorter, but at least it doesn't appear special anymore): In cases where this isn't possible, a compatibility package _may_ be introduced if there is someone who is willing to maintain the compatibility package. Other packagers, especially the primary maintainer, should have time to express their dissent about adding the package (just like in any other review). The primary maintainers should be especially cautious, since even if they are not maintaining the compatibility package, chances are that they will have to be involved in the maintenance due to passing along security problems, helping out with things and redirecting misfiled bugs. > and it's fine. Escalations all go to FESCo, regardless. Indeed, so this part is not needed. > You are both saying the same thing, just with different flavors. > Realize this, and move on. Maybe. But it is nevertheless important to avoid unneeded guidelines and added bureaucracy, even if the end result is the same. The guidelines are already very big. -- Pat From cra at WPI.EDU Thu Jan 3 09:45:47 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 3 Jan 2008 04:45:47 -0500 Subject: Fedora 9 Feature Status In-Reply-To: <477C915E.4080402@redhat.com> References: <477C915E.4080402@redhat.com> Message-ID: <20080103094547.GA8487@angus.ind.WPI.EDU> On Wed, Jan 02, 2008 at 11:40:14PM -0800, John Poelstra wrote: > I've updated http://fedoraproject.org/wiki/Features/Dashboard to reflect > the latest proposed features. This appears to be missing from the Dashboard but nice progress is being made in anaconda: http://fedoraproject.org/wiki/Releases/FeatureEncryptedFilesystems I hope this gets targetted for Fedora 9 and voted on by FESco. From nicolas.mailhot at laposte.net Thu Jan 3 09:53:03 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 03 Jan 2008 10:53:03 +0100 Subject: GPG Keysigning at FUDCon In-Reply-To: <477C3AA7.9010700@redhat.com> References: <20071212214010.GA20896@auslistsprd01.us.dell.com> <477C3AA7.9010700@redhat.com> Message-ID: <1199353983.13378.1.camel@rousalka.dyndns.org> Le mercredi 02 janvier 2008 ? 17:30 -0800, John Poelstra a ?crit : > My key has expired and it is also associated with my Fedora account > which raises a few questions You can easily extend the validity of a key which has expired. This way you get the security of a key that does hara-kiri after a while if you lose it, and the convenience of a stable long-term key. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Thu Jan 3 10:17:42 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 03 Jan 2008 11:17:42 +0100 Subject: Vanilla kernel RPM? In-Reply-To: <477C2393.3020303@redhat.com> References: <1198351701.3594.23.camel@vincent52.localdomain> <20071222133345.49eea037@hansolo.jdub.homelinux.org> <1198352393.14553.2.camel@rousalka.dyndns.org> <20071222141049.359b1931@hansolo.jdub.homelinux.org> <1198356237.15145.3.camel@rousalka.dyndns.org> <477C2393.3020303@redhat.com> Message-ID: <1199355462.13378.8.camel@rousalka.dyndns.org> Le mercredi 02 janvier 2008 ? 18:51 -0500, Chuck Ebbert a ?crit : > On 12/22/2007 03:43 PM, Nicolas Mailhot wrote: > > IIRC the spec logic relies on a special make oldconfig target which is > > only available if the non-interactive oldconfig patch is applied on the > > kernel. Which means this particular patch can not be skipped even in the > > vanilla case. > > > > That is what is does when you build a vanilla kernel from the fedora > spec file Nope. That's what it does if you rebuild from a non-vanilla srpm. Since this patch is in the %if !%{nopatches} like the others, it won't be included in a vanilla srpm and won't build in mock (at least it was when I posted the original message but I see someone just fixed it in cvs without tracing the change in the log) Anyway for people interested a can-build-mm patch for the latest cvs spec is attached. Probably works for everything but the few mm kernels released for a vanilla .0 version -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: build-mm.patch Type: text/x-patch Size: 5425 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From pvrabec at redhat.com Thu Jan 3 10:39:24 2008 From: pvrabec at redhat.com (Peter Vrabec) Date: Thu, 3 Jan 2008 11:39:24 +0100 Subject: security audit tool - announce Message-ID: <200801031139.25030.pvrabec@redhat.com> Hi folks, I'd like to announce new project we started to work on. It's security audit scanner implemented in python. Our goal is to create modern engine for the tests, which perform audit of the system. Tests supposed to be easy to write in any script language. You can give it a try. There is already a demo available at: $ git clone git://git.fedorahosted.org/git/sectool.git/ sectool $ cd sectool # make install # sectool-gui Your feedback is appreciated. Homepage: https://hosted.fedoraproject.org/sectool From mmaslano at redhat.com Thu Jan 3 11:04:00 2008 From: mmaslano at redhat.com (Marcela Maslanova) Date: Thu, 03 Jan 2008 12:04:00 +0100 Subject: heads up: tcl and tk 8.5 In-Reply-To: <20080102102228.44c0d545@ghistelwchlohm.scrye.com> References: <477B60F0.6020406@redhat.com> <20080102102228.44c0d545@ghistelwchlohm.scrye.com> Message-ID: <477CC120.6000706@redhat.com> Kevin Fenzi wrote: > On Wed, 02 Jan 2008 11:01:20 +0100 > mmaslano at redhat.com (Marcela Maslanova) wrote: > > >> New tcl and tk 8.5 was released. I'd like to push it to rawhide as >> soon as possible. The list of dependent packages could be found in >> this draft: >> https://fedoraproject.org/wiki/MarcelaMaslanova/Draft/tcl8.5 The >> maintainers of dependent packages should fix them according to >> http://fedoraproject.org/wiki/PackagingDrafts/Tcl >> > > Can you possibly mail directly at least the primary maintainers of > these packages and let them know when you are going to push the update? > > Who are the primary maintainers? I look at the list of maintainers and most packages owns wart, who is helping me with new tcl. The tcl8.5 is already in devel repository. From jakub at redhat.com Thu Jan 3 12:02:42 2008 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 3 Jan 2008 07:02:42 -0500 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 Message-ID: <20080103120242.GZ20451@devserv.devel.redhat.com> Hi! I've rebuilt 5118 rawhide-20071220 src.rpms on x86_64 in mock buildroots which contained rawhide-20071220 except {gcc,lib}*-4.1.2-36.*.rpm, with additional gcc-4.3.0-0.4 (available from koji, dist-f9-gcc43 component), compat-libgfortran-41 (available from http://people.redhat.com/jakub/gcc/compat-libgfortran-41-4.1.2-36.src.rpm ) and later on also with gettext subpackages just rebuilt with gcc-4.3.0-0.4. Out of those 5118 src.rpms 1054 were failed builds. For those that failed to build, I have retried with stock rawhide-20071220 mock buildroots (i.e. gcc-4.1.2-36). 547 failed builds failed even with 4.1.2-36 (this count includes even ExclusiveArched rpms etc.), logs for those are at http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/fails-even-with-41/ and generally don't interest me, as this is not a regression introduced by 4.3.0-0.4. The remaining 507 failures only fail with gcc-4.3.0-0.4 and not with gcc-4.1.2-36, though most of them are just C++ being stricter, something that ought to be fixed in the packages. I've tried to quickly grep through the failed logs and categorize them: # of bugs URL with logs 269 http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/header-dep/ libstdc++ header dependencies have been streamlined, reducing unnecessary includes and pre-processed bloat. The STL headers have been cleaned up, so that the headers don't drag in unnecessary dependencies which aren't requested by the standard. E.g. no longer includes , etc. Most of these bugs will be fixed just by including the proper headers, , , are the most common ones I guess. 88 http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/unsorted/ Unsorted, package maintainers please check this out, if you believe there is a GCC bug rather than package bug, get in touch with me with additional details. 36 http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/changesmeaning/ See C++ section of http://gcc.gnu.org/gcc-4.3/changes.html, particularly where it talks about "changes meaning of" error 36 http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/multipledef/ When compiling with -std=c99 or -std=gnu99, inline keyword changes meaning, in 4.3+ it by defaults conforms to ISO C99 where extern inline is very different thing than the GNU extern inline extension. If you want the GNU extern inline behavior, you can use extern inline __attribute__((__gnu_inline__)) (the attribute can be guarded by #ifdef __GNUC_STDC_INLINE__ which is a macro which is defined when inline has the ISO C99 behavior), or compile with -fgnu89-inline option. 24 http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/redefined/ The C++ preprocessor now emits errors by default for certain non-conformant code and for -pedantic, following the default behaviour of the C++ front-end. As a result, some warnings, such as "extra tokens at end of #endif directive", are now hard errors. 17 http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/Werror/ Packages compiled with -Werror where some new warnings appeared. By using -Werror you need to be prepared to fix or workaround new warnings from time to time. 9 http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/libtool/ Failures because some libtool scripts have hardcoded /.../gcc/.../4.1.2/ paths in it, will be fixed after dependencies are rebuilt with gcc 4.3 I guess. 7 http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/multipleparm/ G++ now errors when multiple parameters of a function/method have the same names, even if just in prototypes. Should be easy to fix. 6 http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/rootlog/ These packages failed to build because they need whole dependency chain built with gcc 4.3 first (gcj non-BC-ABI packages - libgcj.so.8rh has been removed, libgcj.so.9 is now used; BC-ABI (-findirect-dispatch, what most packages use, are unaffected). 6 http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/java1.2/ Seems gcj in 4.3.0 no longer supports java 1.2 compilation, only 1.3 through 1.6. 4 http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/ice/ Internal compiler errors, these are GCC bugs. tinyfugue ICE tracked at http://gcc.gnu.org/PR34648, tog-pegassus ICE tracked at http://gcc.gnu.org/PR31081, eclipse-gef and icu4j I believe are the same gcj ICE, so far given to Andrew Haley for investigation. 3 http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/auto_ptr/ std::auto_ptr is no longer in , I belive unique_ptr should be used instead, or there is . Benjamin can tell more. 2 http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/main/ G++ now errors when arguments to main have wrong types, e.g. unsigned int argc is wrong. For testing you can use e.g. koji --scratch builds into dist-f9-gcc43 target. I hope we can switch to gcc-4.3.0-0.* in dist-f9 soon. Below just so that all package maintainers don't have to go to the above www site to check for logs if their package is affected. Prepend http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/ to each line below to get at the log file. Werror/NetworkManager-0.7.0-0.8.svn3181.fc9.log Werror/anaconda-11.4.0.11-1.log Werror/dhcp-3.1.0-12.fc9.log Werror/elfutils-0.131-1.fc9.log Werror/evolution-exchange-2.21.4-1.fc9.log Werror/gdb-6.7.1-6.fc9.log Werror/grub-0.97-19.log Werror/libcmpiutil-0.1-6.fc9.log Werror/libflaim-4.9.989-18.fc9.log Werror/libpfm-3.2-0.071017.1.fc9.log Werror/linphone-1.7.1-4.fc8.log Werror/mkinitrd-6.0.24-1.fc9.log Werror/nc-1.84-14.fc9.log Werror/openhpi-2.10.1-1.fc9.log Werror/parted-1.8.6-13.fc9.log Werror/trousers-0.3.1-5.fc9.log Werror/xulrunner-1.9-0.beta2.1.fc9.log auto_ptr/linuxdcpp-1.0.0-4.fc9.log auto_ptr/spr-07.00.00-1.fc8.log auto_ptr/syncevolution-0.6-2.fc8.log changesmeaning/agave-0.4.2-5.fc8.log changesmeaning/bakery-2.4.2-1.fc9.log changesmeaning/bitgtkmm-0.4.0-2.fc7.log changesmeaning/bmpx-0.40.13-6.fc9.log changesmeaning/conexusmm-0.5.0-3.fc7.log changesmeaning/deluge-0.5.7.1-2.fc9.log changesmeaning/gconfmm26-2.20.0-1.fc8.log changesmeaning/glom-1.6.4-1.fc9.log changesmeaning/gnome-system-monitor-2.21.4-1.fc9.log changesmeaning/gnome-vfsmm26-2.20.0-1.fc8.log changesmeaning/goocanvasmm-0.4.0-2.fc9.log changesmeaning/gparted-0.3.3-14.fc9.log changesmeaning/granule-1.2.4-2.fc7.log changesmeaning/gtkglextmm-1.2.0-5.fc6.log changesmeaning/gtkmm24-2.12.3-1.fc9.log changesmeaning/libgdamm-2.9.8-1.fc8.log changesmeaning/libglademm24-2.6.4-1.fc8.log changesmeaning/libgnomecanvasmm26-2.20.0-1.fc8.log changesmeaning/libgnomedbmm-2.9.5-2.fc9.log changesmeaning/libgnomemm26-2.20.0-1.log changesmeaning/libpanelappletmm-2.6.0-2.fc8.log changesmeaning/libsexymm-0.1.9-4.fc8.log changesmeaning/libsigc++20-2.0.18-1.log changesmeaning/libtorrent-0.11.8-2.fc9.log changesmeaning/net6-1.3.5-2.fc8.log changesmeaning/obby-0.4.4-2.fc8.log changesmeaning/paman-0.9.4-1.fc9.log changesmeaning/pavucontrol-0.9.5-1.fc9.log changesmeaning/pavumeter-0.9.3-1.fc9.log changesmeaning/pinot-0.81-2.fc9.log changesmeaning/plotmm-0.1.2-5.fc6.log changesmeaning/regexxer-0.9-2.fc8.log changesmeaning/rtorrent-0.7.8-1.fc8.log changesmeaning/sobby-0.4.4-1.fc8.log changesmeaning/vegastrike-0.4.3-7.fc8.log changesmeaning/wp_tray-0.5.3-6.fc9.log header-dep/8Kingdoms-1.1.0-2.fc9.log header-dep/CCfits-1.8-1.fc9.log header-dep/CTL-1.4.1-3.fc9.log header-dep/ClanLib-0.8.0-7.fc9.log header-dep/ClanLib06-0.6.5-9.fc9.log header-dep/CriticalMass-1.0.2-2.fc9.log header-dep/FlightGear-0.9.11-0.4.pre1.fc8.log header-dep/GraphicsMagick-1.1.8-3.fc8.log header-dep/HippoDraw-1.21.1-2.fc8.log header-dep/MyPasswordSafe-0.6.7-1.20061216.fc8.log header-dep/OpenEXR-1.6.0-5.fc8.log header-dep/OpenSceneGraph-2.2.0-3.fc9.log header-dep/PerceptualDiff-1.0.1-6.fc8.log header-dep/Ri-li-2.0.1-1.fc9.log header-dep/SimGear-0.3.11-0.3.pre1.fc8.2.log header-dep/SteGUI-0.0.1-12.fc8.log header-dep/WebKit-1.0.0-0.3.svn28482.fc9.log header-dep/acpitool-0.4.7-2.fc9.log header-dep/adanaxisgpl-1.2.4-1.fc9.log header-dep/adplug-2.1-2.fc8.log header-dep/agistudio-1.2.3-4.fc8.log header-dep/aiksaurus-1.2.1-15.fc6.log header-dep/akode-2.0.1-9.fc8.log header-dep/amarok-1.4.7-14.fc9.log header-dep/animorph-0.2-2.fc8.log header-dep/antlr-2.7.7-1jpp.6.fc8.log header-dep/apt-0.5.15lorg3.93-4.fc9.log header-dep/aqsis-1.2.0-6.fc8.log header-dep/ardour-2.1-3.fc8.log header-dep/aria2-0.11.3-1.fc8.log header-dep/armacycles-ad-0.2.8.2.1-5.fc8.log header-dep/arts-1.5.8-4.fc8.log header-dep/asio-0.3.8-7.fc9.log header-dep/astyle-1.21-6.fc8.log header-dep/asymptote-1.33-2.fc8.log header-dep/audacious-plugins-1.4.2-1.fc9.log header-dep/audacity-1.3.2-17.fc9.log header-dep/ballbuster-1.0-3.fc8.log header-dep/basket-1.0.2-3.fc9.log header-dep/bbkeys-0.9.0-9.log header-dep/bes-3.5.1-4.fc9.log header-dep/blackbox-0.70.1-9.log header-dep/blender-2.45-4.fc8.log header-dep/bonnie++-1.03a-7.fc8.log header-dep/boolstuff-0.1.11-3.fc9.log header-dep/bzflag-2.0.10-2.fc9.log header-dep/cal3d-0.11.0-4.fc7.log header-dep/ccrtp-1.5.1-1.fc7.log header-dep/cdrdao-1.2.2-3.log header-dep/celestia-1.4.1-7.fc7.log header-dep/commoncpp2-1.5.0-1.fc7.log header-dep/cone-0.74-1.fc9.log header-dep/coolkey-1.1.0-5.fc8.log header-dep/crack-attack-1.1.14-10.fc8.log header-dep/cyphesis-0.5.15-2.fc9.log header-dep/dap-freeform_handler-3.7.5-2.fc8.log header-dep/dar-2.3.6-3.fc9.log header-dep/dasher-4.7.0-1.fc9.log header-dep/dirac-0.8.0-2.fc8.log header-dep/dosbox-0.72-1.fc8.log header-dep/drgeo-1.1.0-11.fc8.log header-dep/ds9-5.0-6.fc9.log header-dep/dssi-0.9.1-11.fc8.log header-dep/dvgrab-3.1-1.fc9.log header-dep/easytag-2.1-3.fc8.log header-dep/ecl-0.9i-3.fc6.log header-dep/ed2k_hash-0.4.0-5.fc9.log header-dep/eiciel-0.9.5-1.fc9.log header-dep/eris-1.3.13-1.fc9.log header-dep/escape-200704130-7.fc9.log header-dep/exempi-1.99.5-1.fc9.log header-dep/exiv2-0.16-0.3.pre1.fc9.log header-dep/farsight-0.1.25-1.fc8.log header-dep/fbdesk-1.4.0-3.fc8.log header-dep/fgfs-Atlas-0.3.1-5.fc8.log header-dep/fillets-ng-0.7.4-3.fc8.log header-dep/fityk-0.8.1-10.fc8.log header-dep/flac-1.2.1-1.fc8.log header-dep/fluxbox-1.0.0-1.fc8.log header-dep/freehdl-0.0.4-4.fc8.log header-dep/fuse-encfs-1.3.2-2.fc9.log header-dep/fwbuilder-2.1.14-1.fc8.log header-dep/gcdmaster-1.2.2-2.fc8.log header-dep/gchempaint-0.8.4-1.fc9.log header-dep/gdl-0.9-0.pre6.fc9.log header-dep/gds2pov-0.20070815-1.fc8.log header-dep/gengetopt-2.21-3.fc8.log header-dep/gimmage-0.2.3-1.fc8.log header-dep/gle-4.0.12a-2.fc8.log header-dep/glest-2.0.1-5.fc9.log header-dep/glibmm24-2.14.2-1.fc9.log header-dep/glimmer-3.02-2.fc8.log header-dep/gmrun-0.9.2-10.fc8.log header-dep/gnome-chemistry-utils-0.8.4-2.fc9.log header-dep/gnome-commander-1.2.4-4.fc8.log header-dep/gnome-games-2.21.4-1.fc9.log header-dep/gnucap-0.35-2.fc8.log header-dep/gobby-0.4.5-1.fc8.log header-dep/google-perftools-0.93-1.fc8.log header-dep/gpsdrive-2.09-4.fc8.log header-dep/gpsim-0.22.0-5.fc8.log header-dep/graphviz-2.14.1-3.fc8.log header-dep/grhino-0.16.0-2.fc8.log header-dep/hackedbox-0.8.5-3.fc8.log header-dep/hal-0.5.10-3.fc9.log header-dep/hdf5-1.6.6-3.fc9.log header-dep/highlight-2.6.6-1.fc9.log header-dep/hugin-0.6.1-11.fc9.log header-dep/hydrogen-0.9.3-9.fc8.log header-dep/ice-3.2.1-14.fc9.log header-dep/id3v2-0.1.11-5.fc8.log header-dep/incron-0.5.5-1.fc7.log header-dep/inkscape-0.45.1-5.fc9.log header-dep/ipe-6.0-0.22.pre28.fc9.log header-dep/iptstate-2.2.1-1.fc8.log header-dep/itpp-4.0.0-2.fc9.log header-dep/jd-1.9.8-0.4.beta071218.fc9.log header-dep/jigdo-0.7.3-4.fc8.log header-dep/jrtplib-3.7.1-2.fc8.log header-dep/k3d-0.6.7.0-4.fc8.log header-dep/kasumi-2.3-1.fc9.log header-dep/kbilliards-0.8.7b-5.fc9.log header-dep/keepassx-0.2.2-4.fc8.log header-dep/kid3-0.10-2.fc9.log header-dep/klamav-0.41.1-7.fc9.log header-dep/ksirk-1.7-4.fc9.log header-dep/lagan-2.0-1.fc8.log header-dep/libEMF-1.0.3-5.fc9.log header-dep/libassa-3.4.2-4.log header-dep/libcdio-0.78.2-3.fc8.log header-dep/libchmxx-0.1-5.fc6.log header-dep/libdap-3.7.8-3.fc9.log header-dep/libebml-0.7.7-3.fc8.log header-dep/libextractor-0.5.18a-1.fc8.log header-dep/libfac-3.0.3-1.fc9.log header-dep/libfreebob-1.0.3-1.fc7.log header-dep/libfwbuilder-2.1.14-1.fc8.log header-dep/libgda-3.0.1-6.fc9.log header-dep/libgnomeuimm26-2.20.0-1.fc8.log header-dep/libgtksourceviewmm-0.3.1-1.fc8.log header-dep/libjingle-0.3.11-5.fc9.log header-dep/libmatroska-0.8.1-2.fc8.log header-dep/libmusicbrainz-2.1.5-3.fc9.log header-dep/libnc-dap-3.7.0-8.fc9.log header-dep/libofa-0.9.3-10.fc8.log header-dep/libofx-0.8.3-4.log header-dep/libpqxx-2.6.8-7.fc8.log header-dep/libqalculate-0.9.6-2.fc8.log header-dep/libsmbios-0.13.13-1.fc9.log header-dep/libsynaptics-0.14.6c-2.fc8.log header-dep/libwvstreams-4.4.1-3.fc9.log header-dep/lineak-defaultplugin-0.9-2.fc6.log header-dep/lineak-xosdplugin-0.9-2.fc6.log header-dep/lineakd-0.9-5.fc6.log header-dep/linkage-0.1.4-4.fc8.log header-dep/loki-lib-0.1.6-4.fc8.1.log header-dep/lostirc-0.4.6-3.fc8.log header-dep/lshw-B.02.12.01-1.fc9.log header-dep/lzma-4.32.2-2.fc9.log header-dep/makehuman-0.9-3.fc8.log header-dep/manaworld-0.0.23-1.fc8.log header-dep/mimetic-0.9.3-2.fc8.log header-dep/muParser-1.28-2.fc8.log header-dep/multiget-1.1.4-7.fc8.log header-dep/museek+-0.1.13-1.fc8.log header-dep/mysql++-2.3.2-2.fc8.log header-dep/nco-3.9.1-1.fc8.log header-dep/newscache-1.2-0.4.rc6.fc6.log header-dep/nget-0.27.1-7.fc8.log header-dep/notecase-1.6.1-2.fc8.log header-dep/nx-2.1.0-22.fc7.log header-dep/ochusha-0.5.99.66-0.3.cvs070110.fc9.log header-dep/ois-1.0-2.fc8.log header-dep/openmsx-0.6.2-4.fc8.log header-dep/openoffice.org-2.3.1-9.9.fc9.log header-dep/openvrml-0.17.0-2.fc9.log header-dep/oprofile-0.9.3-7.fc9.log header-dep/osgcal-0.1.46-3.fc9.log header-dep/pan-0.132-2.fc8.log header-dep/paprefs-0.9.6-1.fc9.log header-dep/paraview-3.2.1-2.fc9.log header-dep/pdfedit-0.3.2-2.fc8.log header-dep/pdns-2.9.21-3.fc9.log header-dep/pdns-recursor-3.1.4-4.fc7.log header-dep/pekwm-0.1.5-5.fc7.log header-dep/pingus-0.7.2-1.fc9.log header-dep/plplot-5.8.0-4.fc9.log header-dep/poker3d-1.1.36-7.fc9.log header-dep/ppl-0.9-16.fc8.log header-dep/pstoedit-3.45-1.fc8.log header-dep/qcad-2.0.5.0-5.fc6.log header-dep/qgo-1.5.2-1.fc6.log header-dep/qlandkarte-0.5.3-4.fc9.log header-dep/qt-3.3.8-11.fc9.log header-dep/qtiplot-0.9-8.fc9.log header-dep/qtpfsgui-1.9.0-1.fc9.log header-dep/rafkill-1.2.2-5.fc8.log header-dep/ragel-5.24-1.fc8.log header-dep/rb_libtorrent-0.12-2.fc8.log header-dep/referencer-1.0.4-5.fc8.log header-dep/rlog-1.3.7-3.fc6.log header-dep/rss-glx-0.8.1.p-17.fc9.log header-dep/rudeconfig-5.0.5-1.fc7.log header-dep/sblim-wbemcli-1.5.1-5.fc7.log header-dep/scim-anthy-1.2.4-2.fc8.log header-dep/scim-array-0.0.2-2.fc9.log header-dep/scim-bridge-0.4.13-6.fc9.log header-dep/scim-chewing-0.3.1-9.fc7.log header-dep/scim-fcitx-3.1.1-7.fc8.log header-dep/scim-hangul-0.3.1-1.fc7.log header-dep/scim-m17n-0.2.2-2.fc8.log header-dep/scim-pinyin-0.5.91-23.fc9.log header-dep/scim-skk-0.5.2-8.fc6.log header-dep/scim-tables-0.5.7-3.fc7.log header-dep/scim-tomoe-0.6.0-2.fc8.log header-dep/scorched3d-41.1-1.fc9.log header-dep/sear-0.6.3-7.fc9.log header-dep/seq24-0.8.7-8.fc8.log header-dep/skstream-0.3.6-2.fc8.log header-dep/slim-1.3.0-1.fc8.log header-dep/smb4k-0.8.7-3.fc9.log header-dep/soundtouch-1.3.1-8.fc8.log header-dep/srecord-1.36-1.fc8.log header-dep/stardict-3.0.1-1.fc9.log header-dep/steghide-0.5.1-7.fc8.log header-dep/stellarium-0.9.0-6.fc9.log header-dep/stormbaancoureur-1.5.1-2.fc8.log header-dep/stratagus-2.2.4-1.fc8.log header-dep/strigi-0.5.7-2.fc9.log header-dep/subcommander-1.2.2-9.fc9.log header-dep/supertux-0.3.0-3.fc9.log header-dep/supertuxkart-0.3-2.fc8.log header-dep/sword-1.5.10-1.fc9.log header-dep/synaptic-0.57.2-14.fc9.log header-dep/synergy-1.3.1-5.fc8.log header-dep/systemtap-0.6-1.fc9.log header-dep/teckit-2.2.1-2.fc8.log header-dep/telescope-server-0-0.2.20070315.fc8.log header-dep/ttmkfdir-3.0.9-24.fc7.log header-dep/uim-1.4.1-8.fc8.log header-dep/ultimatestunts-0.7.3-4.fc9.log header-dep/usbsink-0.3.2-1.fc8.log header-dep/varconf-0.6.5-2.fc8.log header-dep/vdccm-0.9.3-1.fc7.log header-dep/vdr-subtitles-0.5.0-2.fc8.log header-dep/vdr-text2skin-1.1-20.20051217cvs.fc8.log header-dep/verbiste-0.1.21-1.fc8.log header-dep/widelands-0-0.7.build11.fc8.log header-dep/workrave-1.8.4-4.fc8.log header-dep/wpa_supplicant-0.5.7-18.fc9.log header-dep/wv2-0.2.3-3.fc8.log header-dep/wvdial-1.60-3.fc9.log header-dep/xalan-c-1.10.0-2.fc9.log header-dep/xapian-core-1.0.4-1.fc9.log header-dep/xarchon-0.50-5.fc8.log header-dep/xbase-2.0.0-8.fc9.log header-dep/xbsql-0.11-9.fc8.log header-dep/xdrawchem-1.9.9-6.fc8.log header-dep/xmlrpc-c-1.06.18-1.fc8.log header-dep/xmms-adplug-1.2-5.fc8.log header-dep/xmms-modplug-2.05-11.fc8.log header-dep/xmoto-0.3.4-1.fc9.log header-dep/xplanet-1.2.0-2.1.fc8.2.log header-dep/xprobe2-0.3-9.fc8.log header-dep/xqilla10-1.0.2-2.fc9.log header-dep/xu4-1.1-0.2.cvs20070510.fc8.log header-dep/yafray-0.0.9-5.fc9.log header-dep/zhcon-0.2.6-5.fc7.log header-dep/zidrav-1.2.0-3.fc8.log ice/eclipse-gef-3.3.0-1.fc8.log ice/icu4j-3.6.1-1jpp.6.fc9.log ice/tinyfugue-5.0-0.7.b8.fc9.log ice/tog-pegasus-2.7.0-3.fc9.log java1.2/ant-1.7.0-1jpp.2.fc8.log java1.2/bea-stax-1.2.0-0.1.rc1.2jpp.1.fc7.log java1.2/log4j-1.2.14-3jpp.1.fc8.log java1.2/msv-1.2-0.1.20050722.3jpp.3.fc8.log java1.2/xmlrpc-2.0.1-3jpp.2.log java1.2/xpp3-1.1.3.8-1jpp.1.fc7.log libtool/anjuta-2.2.0-4.fc9.log libtool/aplus-fsf-4.20.2-22.fc8.log libtool/aqbanking-2.3.2-4.fc9.log libtool/atlascpp-0.6.1-2.fc9.log libtool/bochs-2.3.5-1.fc8.log libtool/cegui-0.5.0b-6.fc8.log libtool/lftp-3.5.14-3.fc9.log libtool/rapidsvn-0.9.4-7.fc9.log libtool/uuid-1.6.0-2.fc8.log main/Inventor-2.1.5-30.fc9.1.log main/cpuspeed-1.2.1-3.fc8.log multipledef/Io-language-20071010-1.fc9.log multipledef/asunder-1.0-1.fc9.log multipledef/autogen-5.8.9-1.fc7.log multipledef/avahi-0.6.22-4.fc9.log multipledef/cpio-2.9-5.fc9.log multipledef/dates-0.4.5-1.fc9.log multipledef/g-wrap-1.9.9-4.fc8.log multipledef/gnome-python2-2.21.0-1.fc9.log multipledef/gnome-vfs2-2.20.1-4.fc9.log multipledef/gnome-vfs2-obexftp-0.4-5.fc9.log multipledef/gshutdown-0.2-2.fc8.log multipledef/gstreamer-plugins-farsight-0.12.5-1.fc8.log multipledef/gtk-vnc-0.3.1-1.fc9.log multipledef/guile-gnome-platform-2.15.93-6.fc8.log multipledef/gxine-0.5.11-14.fc9.log multipledef/isomaster-1.3-1.fc9.log multipledef/libglade2-2.6.2-3.fc8.log multipledef/libtelepathy-0.3.1-2.fc9.log multipledef/mc-4.6.1a-50.20070604cvs.fc9.log multipledef/nspluginwrapper-0.9.91.5-16.fc9.log multipledef/pguiman-0.0.1-3.fc8.log multipledef/pidgin-guifications-2.14-2.fc7.log multipledef/pygobject2-2.14.0-2.fc9.log multipledef/pygoocanvas-0.9.0-2.fc8.log multipledef/pygtk2-2.12.0-3.fc9.log multipledef/pyorbit-2.14.3-1.fc8.log multipledef/swfdec-0.5.5-2.fc9.log multipledef/tar-1.19-1.fc9.log multipledef/telepathy-gabble-0.6.1-1.fc9.log multipledef/telepathy-glib-0.7.0-1.fc9.log multipledef/telepathy-haze-0.1.4-2.fc9.log multipledef/telepathy-idle-0.1.2-2.fc9.log multipledef/telepathy-salut-0.2.0-1.fc9.log multipledef/telepathy-stream-engine-0.3.25-2.fc8.log multipledef/vips-7.12.5-3.fc9.log multipledef/xchat-gnome-0.18-7.fc9.log multipleparm/alsa-tools-1.0.12-4.fc7.log multipleparm/aspell-0.60.5-3.fc7.log multipleparm/bsd-games-2.17-22.fc9.log multipleparm/kmymoney2-0.8.8-1.fc9.log multipleparm/mercator-0.2.5-3.fc9.log multipleparm/xchm-1.13-1.fc8.log multipleparm/zoneminder-1.22.3-10.fc9.log redefined/Macaulay2-0.9.95-9.fc9.log redefined/blam-1.8.3-13.fc9.log redefined/chmsee-1.0.0-1.34.fc9.log redefined/cinepaint-0.22.1-5.fc8.log redefined/csmash-0.6.6-17.log redefined/devhelp-0.16.1-4.fc9.log redefined/digikam-0.9.3-0.5.rc1.fc9.log redefined/dx-4.4.4-4.fc8.log redefined/geos-2.2.3-1.fc7.log redefined/groff-1.18.1.4-10.fc8.log redefined/gtkmozembedmm-1.4.2.cvs20060817-17.fc9.log redefined/kasablanca-0.4.0.2-11.fc9.log redefined/kdebase3-3.5.8-24.fc9.log redefined/kdelibs3-3.5.8-20.fc9.log redefined/kdewebdev-3.5.8-4.fc9.log redefined/kismet-0.0.2007.10.R1-2.fc9.log redefined/koffice-1.6.3-12.fc8.log redefined/lyx-1.5.3-1.fc9.log redefined/njam-1.25-6.fc8.log redefined/pachi-1.0-3.fc8.log redefined/perl-Perlbal-XS-HTTPHeaders-0.19-2.fc8.log redefined/rxvt-unicode-8.8-1.fc9.log redefined/smartmontools-5.37-8.3.fc9.log redefined/yelp-2.21.1-2.fc9.log rootlog/azureus-3.0.3.4-3.fc9.log rootlog/cairo-java-1.0.5-7.fc7.log rootlog/frysk-0.0.1.2007.10.17-1.fc8.log rootlog/libglade-java-2.12.5-6.fc7.log rootlog/libgnome-java-2.12.4-6.fc7.log rootlog/libvte-java-0.12.1-10.fc9.log unsorted/TnL-071111-1.fc9.log unsorted/abiword-2.4.6-6.fc8.log unsorted/amoebax-0.2.0-1.fc9.log unsorted/asc-2.0.1.0-1.fc9.log unsorted/astromenace-1.2-6.fc9.log unsorted/bit-0.4.1-1.fc7.log unsorted/blitz-0.9-3.fc8.log unsorted/blobby-0.6-0.7.a.fc8.log unsorted/boswars-2.4.1-3.fc9.log unsorted/brutus-keyring-0.9.0-6.fc8.log unsorted/cernlib-2006-20.fc9.log unsorted/checkstyle-4.1-4jpp.2.fc8.log unsorted/clipsmm-0.0.7-1.fc7.log unsorted/cln-1.1.13-4.fc8.log unsorted/compat-erlang-R10B-11.9.fc9.log unsorted/compiz-fusion-0.6.0-7.fc9.log unsorted/compiz-fusion-extras-0.6.0-1.fc9.log unsorted/compizconfig-backend-gconf-0.6.0-1.fc9.log unsorted/dbmail-2.2.7-2.fc9.log unsorted/dsniff-2.4-0.1.b1.fc9.log unsorted/duel3-0.1-0.4.20060225.fc8.log unsorted/eclipse-3.3.1.1-14.fc9.log unsorted/ekg2-0.1.1-2.fc9.log unsorted/emerald-0.5.2-2.fc8.log unsorted/enblend-3.0-6.fc8.log unsorted/enigma-1.01-3.1.log unsorted/erlang-R12B-0.1.fc9.log unsorted/espeak-1.28-1.fc8.log unsorted/extrema-4.2.10-3.fc9.log unsorted/factory-3.0.3-1.fc9.log unsorted/festival-1.96-2.fc9.log unsorted/fontforge-20071110-1.fc9.log unsorted/galeon-2.0.3-17.fc9.log unsorted/ghdl-0.25-0.89svn.6.fc8.log unsorted/glob2-0.9.1-2.fc8.log unsorted/gprolog-1.3.0-11.fc8.log unsorted/hdf-4.2r2-4.fc9.log unsorted/hedgewars-0.9.0-4.fc9.log unsorted/id3lib-3.8.3-18.fc9.log unsorted/idioskopos-0.4.1-1.fc7.log unsorted/inotify-tools-3.11-1.fc8.log unsorted/kdebluetooth-1.0-0.39.beta8.fc9.log unsorted/kernel-xen-2.6-2.6.21.7-2890.fc9.log unsorted/krusader-1.80.0-4.fc9.log unsorted/lam-7.1.2-10.fc7.log unsorted/libcompizconfig-0.6.0-3.fc9.log unsorted/libsidplay-1.36.57-15.log unsorted/libxml++-2.20.0-1.fc8.log unsorted/lilypond-2.10.33-1.fc8.log unsorted/mecab-0.96-2.fc9.1.log unsorted/methane-1.4.7-3.fc8.log unsorted/mkvtoolnix-2.1.0-1.fc8.log unsorted/mysql-gui-tools-5.0r12-5.fc9.log unsorted/ncarg-4.4.2-4.fc8.log unsorted/netpanzer-0.8.2-1.fc8.log unsorted/netpbm-10.35.35-1.fc9.log unsorted/nss-3.11.99.2b-2.fc9.log unsorted/ogre-1.4.5-3.fc9.log unsorted/osgal-0.6.1-2.fc9.log unsorted/ovaldi-5.3-1.fc9.log unsorted/papyrus-0.7.1-1.fc7.log unsorted/perl-5.8.8-31.fc9.log unsorted/perl-Cache-2.04-2.fc8.2.log unsorted/perl-Glib-1.162-1.fc9.log unsorted/poker-network-1.2.0-4.fc9.log unsorted/poker2d-1.2.0-3.fc9.log unsorted/qfaxreader-0.3.1-8.fc8.1.log unsorted/qps-1.9.19-0.2.b.fc7.log unsorted/recode-3.6-24.fc8.log unsorted/rpm-4.4.2.2-11.fc9.log unsorted/scim-qtimm-0.9.4-8.fc8.log unsorted/scorchwentbonkers-1.1-4.fc8.log unsorted/scrip-1.4-9.fc8.log unsorted/scummvm-0.10.0-2.fc8.log unsorted/seamonkey-1.1.7-3.fc9.log unsorted/setools-3.3.2-1.fc9.log unsorted/smarteiffel-2.2-6.fc6.log unsorted/source-highlight-2.8-1.fc9.log unsorted/starplot-0.95.4-3.fc9.log unsorted/taskjuggler-2.4.0-4.fc8.log unsorted/thunderbird-2.0.0.9-2.fc9.log unsorted/torcs-1.3.0-3.fc8.log unsorted/trackballs-1.1.4-3.fc8.log unsorted/twinkle-1.1-3.fc8.log unsorted/vavoom-1.25-1.fc9.log unsorted/vym-1.10.0-1.fc9.log unsorted/wesnoth-1.2.8-3.fc9.log unsorted/wormux-0.7.9-5.fc8.log fails-even-with-41/Django-0.96.1-1.fc9.log fails-even-with-41/HelixPlayer-1.0.9-1.fc8.log fails-even-with-41/LabPlot-1.5.1.6-4.fc8.log fails-even-with-41/Miro-1.0-2.fc9.log fails-even-with-41/NetworkManager-openvpn-0.7.0-3.svn3047.fc9.log fails-even-with-41/PyRTF-0.45-5.fc8.log fails-even-with-41/PySolFC-1.1-4.fc9.log fails-even-with-41/PyX-0.9-5.fc8.log fails-even-with-41/PythonCAD-0.1.36-2.fc8.log fails-even-with-41/QuantLib-0.8.1-4.fc9.log fails-even-with-41/R-waveslim-1.6-4.fc8.log fails-even-with-41/SOAPpy-0.11.6-6.fc7.log fails-even-with-41/ScientificPython-2.6-10.fc8.log fails-even-with-41/aasaver-0.3.2-1.fc8.log fails-even-with-41/airsnort-0.2.7e-11.fc7.log fails-even-with-41/alex-2.1.0-5.fc8.log fails-even-with-41/alliance-5.0-10.20070718snap.fc8.log fails-even-with-41/amarokFS-0.5-1.fc7.log fails-even-with-41/amsn-0.96-7.fc7.log fails-even-with-41/apmd-3.2.2-6.log fails-even-with-41/apmud-1.0.0-8.fc8.log fails-even-with-41/archmage-0.1.9-1.fc8.log fails-even-with-41/arm-gp2x-linux-glibc-2.3.6-4.fc8.log fails-even-with-41/athcool-0.3.11-5.fc6.log fails-even-with-41/atitvout-0.4-7.log fails-even-with-41/atlas-3.6.0-12.fc8.log fails-even-with-41/audit-1.6.2-4.fc8.log fails-even-with-41/avr-libc-1.4.6-4.fc8.log fails-even-with-41/awesfx-0.5.0d-4.fc7.log fails-even-with-41/bacula-2.0.3-11.fc8.log fails-even-with-41/bcfg2-0.9.5.2-1.fc9.log fails-even-with-41/bibletime-1.6.5-1.fc9.log fails-even-with-41/bitbake-1.8.8-1.fc8.log fails-even-with-41/bittorrent-4.4.0-5.fc7.log fails-even-with-41/blogtk-1.1-8.fc7.log fails-even-with-41/bluecurve-kde-theme-1.0.0-1.fc8.log fails-even-with-41/bluecurve-kwin-theme-1.0.0-1.fc8.log fails-even-with-41/brltty-3.8-1.fc8.log fails-even-with-41/buildbot-0.7.6-1.fc8.log fails-even-with-41/callweaver-1.2-0.3.rc4.20070822.log fails-even-with-41/camstream-0.26.3-12.fc8.log fails-even-with-41/castor-0.9.5-1jpp.7.log fails-even-with-41/chkfontpath-1.10.1-2.fc8.log fails-even-with-41/clips-6.24-22.fc7.log fails-even-with-41/cmucl-19d-5.fc8.log fails-even-with-41/cobbler-0.6.4-2.fc9.log fails-even-with-41/compat-gcc-296-2.96-139.log fails-even-with-41/compat-guile-16-1.6.7-7.fc8.log fails-even-with-41/compiz-0.6.2-4.fc9.log fails-even-with-41/compizconfig-backend-kconfig-0.6.0-1.fc9.log fails-even-with-41/conexus-0.5.3-2.fc8.log fails-even-with-41/cryptix-asn1-20011119-7jpp.2.log fails-even-with-41/crystal-1.0.5-1.fc8.log fails-even-with-41/csound-5.03.0-13.fc7.log fails-even-with-41/d3lphin-0.9.2-2.fc8.log fails-even-with-41/d4x-2.5.7.1-3.fc7.log fails-even-with-41/dap-hdf4_handler-3.7.5-3.fc8.log fails-even-with-41/darcs-1.0.9-6.fc8.log fails-even-with-41/dekorator-0.3-3.fc7.log fails-even-with-41/denyhosts-2.6-7.fc8.log fails-even-with-41/digikam-doc-0.9.3-0.1.beta3.fc9.log fails-even-with-41/dogtail-0.6.1-1.fc7.log fails-even-with-41/driconf-0.9.1-6.fc8.log fails-even-with-41/duplicity-0.4.3-1.fc8.log fails-even-with-41/eclipse-emf-2.2.2-1.fc7.log fails-even-with-41/ekg-1.7-3.fc9.log fails-even-with-41/elilo-3.6-2.log fails-even-with-41/epiphany-2.21.4-1.fc9.log fails-even-with-41/epiphany-extensions-2.20.1-3.fc9.log fails-even-with-41/epydoc-2.1-8.fc8.log fails-even-with-41/epylog-1.0.3-5.fc7.log fails-even-with-41/esc-1.0.1-7.fc8.log fails-even-with-41/evolution-brutus-1.1.28.7-2.fc8.log fails-even-with-41/filelight-1.0-9.fc6.log fails-even-with-41/flagpoll-0.9.1-1.fc8.log fails-even-with-41/fluxstyle-1.0.1-2.fc7.log fails-even-with-41/fonttools-2.0-0.11.20060223cvs.fc7.log fails-even-with-41/fontypython-0.2.0-6.fc7.log fails-even-with-41/fpc-2.2.0-10.fc8.log fails-even-with-41/freetennis-0.4.8-6.fc7.log fails-even-with-41/func-0.13-3.fc9.log fails-even-with-41/fusion-icon-0-0.2.20071206git.fc9.log fails-even-with-41/fwfstab-0.02-2.fc9.log fails-even-with-41/galternatives-0.13.4-4.fc7.log fails-even-with-41/gambas-1.0.19-3.fc8.log fails-even-with-41/gazpacho-0.7.2-2.fc8.log fails-even-with-41/gcl-2.6.7-15.fc8.log fails-even-with-41/gdal-1.4.2-3.fc8.log fails-even-with-41/gdmap-0.7.5-6.fc6.log fails-even-with-41/gedit-plugins-2.18.0-2.fc7.log fails-even-with-41/getmail-4.7.7-2.fc9.log fails-even-with-41/gfa-0.4.1-4.fc7.log fails-even-with-41/gjots2-2.3.4-7.fc7.log fails-even-with-41/glipper-0.95.1-2.fc7.log fails-even-with-41/gnash-0.8.1-6.fc9.log fails-even-with-41/gnofract4d-3.6-4.fc7.log fails-even-with-41/gnome-applet-vm-0.1.2-2.fc7.log fails-even-with-41/gnome-device-manager-0.2-2.fc9.log fails-even-with-41/gnome-media-2.20.1-7.fc9.log fails-even-with-41/gnome-packagekit-0.1.4-1.fc9.log fails-even-with-41/gnome-python2-desktop-2.21.1-1.fc9.log fails-even-with-41/gnome-scan-0.5.3-0.1.20071030svn.fc9.log fails-even-with-41/gnome-specimen-0.3-1.fc8.log fails-even-with-41/gnome-web-photo-0.3-8.fc9.log fails-even-with-41/gnomesword-2.3.1-3.fc9.log fails-even-with-41/gourmet-0.13.4-1.fc8.log fails-even-with-41/gpart-0.1h-8.fc9.log fails-even-with-41/gpgme-1.1.5-4.fc8.log fails-even-with-41/gquilt-0.20-1.fc7.log fails-even-with-41/grass-6.2.2-2.fc8.log fails-even-with-41/gresistor-0.0.1-11.fc8.log fails-even-with-41/gstm-1.2-6.fc7.log fails-even-with-41/gstreamer-plugins-good-0.10.6-6.fc8.log fails-even-with-41/gtk-sharp-1.0.10-12.fc7.log fails-even-with-41/gtkmathview-0.7.6-5.fc6.log fails-even-with-41/gwenview-1.4.2-1.fc9.log fails-even-with-41/gwget-0.99-3.fc8.log fails-even-with-41/haddock-0.8-1.fc7.log fails-even-with-41/happy-1.16-2.fc7.log fails-even-with-41/hotwire-0.620-1.fc9.log fails-even-with-41/ht2html-2.0-5.fc6.log fails-even-with-41/htop-0.6.5-1.fc7.log fails-even-with-41/hunspell-ar-0.20060208-1.fc8.log fails-even-with-41/i8kutils-1.25-13.log fails-even-with-41/icecream-0.8.0-6.20071101svn.fc9.log fails-even-with-41/ikarus-0.0.1-4.fc9.log fails-even-with-41/ip-sentinel-0.12-10.fc7.log fails-even-with-41/iproute-2.6.23-1.fc9.log fails-even-with-41/iprutils-2.2.8-1.fc9.log fails-even-with-41/iverilog-0.9.20070608-1.fc8.log fails-even-with-41/java-1.5.0-gcj-1.5.0.0-17.fc8.log fails-even-with-41/java-1.7.0-icedtea-1.7.0.0-0.22.b23.snapshot.fc9.log fails-even-with-41/jgroups-2.2.9.2-3jpp.2.log fails-even-with-41/jokosher-1.0-0.1.20070929svn.fc8.log fails-even-with-41/kaffeine-0.8.5-5.fc8.log fails-even-with-41/kalgebra-0.5-4.fc8.log fails-even-with-41/kannel-1.4.1-5.log fails-even-with-41/katapult-0.3.2.1-2.fc8.log fails-even-with-41/kazehakase-0.5.0-1.fc9.2.log fails-even-with-41/kbackup-0.5.2-1.fc8.log fails-even-with-41/kbibtex-0.1.5.52-10.fc7.log fails-even-with-41/kbiof-0.3-1.fc8.log fails-even-with-41/kcemirror-0.1.5-1.fc7.log fails-even-with-41/kchmviewer-3.0-2.fc7.log fails-even-with-41/kcometen3-1.1-5.fc8.log fails-even-with-41/kdbg-2.0.5-2.fc7.log fails-even-with-41/kde-i18n-3.5.8-1.fc8.log fails-even-with-41/kdebindings-3.97.0-6.fc9.log fails-even-with-41/kdetv-0.8.9-8.fc9.log fails-even-with-41/kdirstat-2.5.3-6.fc8.log fails-even-with-41/kdissert-1.0.7-1.fc7.log fails-even-with-41/kdmtheme-1.2.1-1.fc9.log fails-even-with-41/keurocalc-0.9.7-3.fc8.log fails-even-with-41/kexec-tools-1.102pre-2.fc8.log fails-even-with-41/kflickr-0.9-1.fc8.log fails-even-with-41/kgtk-0.8-2.fc7.log fails-even-with-41/kicker-compiz-3.5.4-4.fc8.log fails-even-with-41/kile-2.0-1.fc9.log fails-even-with-41/kio_p7zip-0.3.1-5.fc8.log fails-even-with-41/kio_resources-0.2-3.fc8.log fails-even-with-41/kio_sword-0.3-4.fc9.log fails-even-with-41/kiosktool-1.0-8.fc8.log fails-even-with-41/kleansweep-0.2.9-5.fc8.log fails-even-with-41/klear-0.6.1-1.fc8.log fails-even-with-41/klibido-0.2.5-8.fc8.log fails-even-with-41/kmobiletools-0.4.3.3-3.fc6.log fails-even-with-41/knemo-0.4.7-1.fc7.log fails-even-with-41/knetstats-1.6.1-4.fc8.log fails-even-with-41/koan-0.6.3-3.fc9.log fails-even-with-41/koffice-langpack-1.6.3-1.fc8.log fails-even-with-41/kompose-0.5.3-8.fc8.log fails-even-with-41/konversation-1.0.1-3.fc8.log fails-even-with-41/kooldock-0.4.6-2.fc8.log fails-even-with-41/kover-3-2.log fails-even-with-41/koverartist-0.5-8.fc8.log fails-even-with-41/kphotobymail-0.4.1-1.fc7.log fails-even-with-41/kpolynome-0.1.2-10.fc8.log fails-even-with-41/kpowersave-0.7.3-1.fc9.log fails-even-with-41/krecipes-0.9.1-6.fc8.log fails-even-with-41/krename-3.0.14-2.fc8.log fails-even-with-41/ksensors-0.7.3-14.fc9.log fails-even-with-41/kshutdown-1.0.1-1.fc8.log fails-even-with-41/ksplash-engine-moodin-0.4.2-4.fc7.log fails-even-with-41/ksshaskpass-0.3-3.fc8.log fails-even-with-41/ksynaptics-0.3.3-2.fc8.log fails-even-with-41/ktechlab-0.3.69-5.fc8.log fails-even-with-41/kyum-0.7.5-9.fc8.log fails-even-with-41/ladspa-1.12-8.fc7.log fails-even-with-41/ldapjdk-4.17-1jpp.7.log fails-even-with-41/libchewing-0.3.0-8.fc8.log fails-even-with-41/libevent-1.3b-1.fc7.log fails-even-with-41/libgconf-java-2.12.4-8.fc7.log fails-even-with-41/libgtk-java-2.8.7-4.fc7.log fails-even-with-41/libieee1284-0.2.11-1.fc8.log fails-even-with-41/libkexif-0.2.5-2.fc8.log fails-even-with-41/libkexiv2-0.1.6-2.fc9.log fails-even-with-41/libkipi-0.1.5-2.fc8.log fails-even-with-41/libprelude-0.9.13-1.fc7.log fails-even-with-41/librtas-1.3.3-2.fc9.log fails-even-with-41/libtommath-0.41-7.fc9.log fails-even-with-41/libtunepimp-0.5.3-9.fc8.log fails-even-with-41/libusb-0.1.12-12.fc9.log fails-even-with-41/libzzub-0.2.3-10.fc9.log fails-even-with-41/licq-1.3.4-10.fc9.log fails-even-with-41/liferea-1.4.10-1.fc9.log fails-even-with-41/lightning-1.2-11.fc8.log fails-even-with-41/lilypond-doc-2.10.13-1.fc7.log fails-even-with-41/lineak-kdeplugins-0.9-2.fc6.log fails-even-with-41/linkchecker-4.7-10.fc8.log fails-even-with-41/londonlaw-0.2.1-2.fc8.log fails-even-with-41/lrmi-0.10-3.fc8.log fails-even-with-41/ltrace-0.5-9.45svn.fc8.log fails-even-with-41/lybniz-1.3.1-1.fc9.log fails-even-with-41/m2crypto-0.18.2-2.log fails-even-with-41/machineball-1.0-4.fc8.log fails-even-with-41/mapserver-4.10.3-2.fc8.log fails-even-with-41/mash-0.2.10-1.fc9.log fails-even-with-41/maven-wagon-1.0-0.1.a5.3jpp.1.fc7.log fails-even-with-41/mbuffer-20070502-1.fc7.log fails-even-with-41/metamonitor-0.4.5-3.fc6.log fails-even-with-41/mirage-0.9-2.fc9.log fails-even-with-41/mod_python-3.3.1-5.log fails-even-with-41/module-init-tools-3.4-2.fc8.log fails-even-with-41/moin-1.5.8-2.fc8.log fails-even-with-41/monodevelop-0.17-4.fc9.log fails-even-with-41/monotone-0.37-3.fc9.log fails-even-with-41/mosml-2.01-9.fc7.log fails-even-with-41/moto4lin-0.3-6.fc7.log fails-even-with-41/mugshot-1.1.56-1.fc8.log fails-even-with-41/muine-scrobbler-0.1.8-2.fc8.log fails-even-with-41/mx-2.0.6-3.log fails-even-with-41/mx4j-3.0.1-6jpp.4.log fails-even-with-41/nemiver-0.4.0-1.fc8.log fails-even-with-41/netcdf-3.6.2-4.fc8.log fails-even-with-41/netlabel_tools-0.17-5.fc6.log fails-even-with-41/ntfs-config-1.0-0.5.rc5.fc8.log fails-even-with-41/numpy-1.0.3.1-1.fc8.log fails-even-with-41/obexftp-0.22-0.5.rc7.fc8.log fails-even-with-41/obmenu-1.0-5.fc8.log fails-even-with-41/offlineimap-5.99.4-1.fc9.log fails-even-with-41/oggconvert-0.3.0-14.fc9.log fails-even-with-41/oooqs2-1.0-3.fc6.log fails-even-with-41/oorexx-3.2.0-2.fc9.log fails-even-with-41/openais-0.80.1-6.log fails-even-with-41/openbabel-2.1.1-2.fc9.log fails-even-with-41/orpie-1.4.3-5.fc6.log fails-even-with-41/ots-0.4.2-11.fc7.log fails-even-with-41/pam_abl-0.2.3-3.fc7.log fails-even-with-41/pari-2.3.0-5.fc7.log fails-even-with-41/pcapy-0.10.5-1.fc9.log fails-even-with-41/pcmanx-gtk2-0.3.5-9.336svn.fc7.log fails-even-with-41/perl-CGI-Ajax-0.701-2.fc7.log fails-even-with-41/perl-CGI-Session-4.20-2.fc7.log fails-even-with-41/perl-Class-Factory-Util-1.7-1.fc7.log fails-even-with-41/perl-Class-Observable-1.04-2.fc7.log fails-even-with-41/perl-Class-Std-0.0.8-1.fc7.log fails-even-with-41/perl-Data-Password-1.07-1.fc7.log fails-even-with-41/perl-DateTime-Event-ICal-0.09-3.fc7.log fails-even-with-41/perl-DateTime-Event-Recurrence-0.16-4.fc7.log fails-even-with-41/perl-DateTime-Format-ICal-0.08-4.fc7.log fails-even-with-41/perl-DateTime-Format-MySQL-0.04-4.fc6.log fails-even-with-41/perl-DateTime-Format-Strptime-1.0700-3.fc7.log fails-even-with-41/perl-DateTime-Format-W3CDTF-0.04-2.fc7.log fails-even-with-41/perl-DateTime-Set-0.25-4.fc7.log fails-even-with-41/perl-Devel-Caller-0.11-1.fc7.log fails-even-with-41/perl-Email-Date-1.102-3.fc8.log fails-even-with-41/perl-Email-Reply-1.202-1.fc8.log fails-even-with-41/perl-Exception-Class-1.23-3.fc7.log fails-even-with-41/perl-File-ReadBackwards-1.04-3.fc7.log fails-even-with-41/perl-File-Type-0.22-4.fc7.log fails-even-with-41/perl-HTML-Template-Expr-0.07-4.fc7.log fails-even-with-41/perl-IO-All-0.38-1.fc7.log fails-even-with-41/perl-IPC-Shareable-0.60-3.fc6.log fails-even-with-41/perl-Kwiki-0.39-1.fc7.log fails-even-with-41/perl-Kwiki-Archive-Rcs-0.15-6.fc7.log fails-even-with-41/perl-Kwiki-Attachments-0.18-3.fc7.log fails-even-with-41/perl-Kwiki-Diff-0.03-4.fc7.log fails-even-with-41/perl-Kwiki-ModPerl-0.09-4.fc7.log fails-even-with-41/perl-Kwiki-NewPage-0.12-5.fc7.log fails-even-with-41/perl-Kwiki-Raw-0.02-4.fc7.log fails-even-with-41/perl-Kwiki-RecentChanges-0.14-3.fc7.log fails-even-with-41/perl-Kwiki-Revisions-0.15-5.fc7.log fails-even-with-41/perl-Kwiki-Search-0.12-5.fc7.log fails-even-with-41/perl-Kwiki-UserName-0.14-5.fc7.log fails-even-with-41/perl-Kwiki-UserPreferences-0.13-5.fc7.log fails-even-with-41/perl-Kwiki-Users-Remote-0.04-4.fc7.log fails-even-with-41/perl-Log-Message-0.01-3.fc7.log fails-even-with-41/perl-Log-Message-Simple-0.02-1.fc8.log fails-even-with-41/perl-Math-Vec-0.04-2.fc7.log fails-even-with-41/perl-Module-Build-0.2808-1.fc8.log fails-even-with-41/perl-Module-Install-0.67-1.fc8.log fails-even-with-41/perl-Module-Loaded-0.01-3.fc7.log fails-even-with-41/perl-Module-Pluggable-3.60-1.fc7.log fails-even-with-41/perl-MooseX-Getopt-0.05-1.fc8.log fails-even-with-41/perl-Net-CUPS-0.51-2.fc7.log fails-even-with-41/perl-Net-XMPP-1.02-2.fc7.log fails-even-with-41/perl-Object-Accessor-0.32-2.fc7.log fails-even-with-41/perl-OpenFrame-3.05-6.fc7.log fails-even-with-41/perl-PDL-2.4.3-4.fc8.log fails-even-with-41/perl-POE-API-Peek-1.0802-1.fc7.log fails-even-with-41/perl-POE-Component-Child-1.39-2.fc6.log fails-even-with-41/perl-POE-Component-Client-LDAP-0.04-3.fc6.log fails-even-with-41/perl-POE-Component-SNMP-1.07-1.fc6.log fails-even-with-41/perl-POE-Component-Server-HTTP-0.09-3.fc6.log fails-even-with-41/perl-POE-Component-Server-SOAP-1.11-1.fc8.log fails-even-with-41/perl-POE-Component-SimpleLog-1.04-1.fc6.log fails-even-with-41/perl-POE-Wheel-Null-0.01-2.fc6.log fails-even-with-41/perl-PPI-Tester-0.06-2.fc6.log fails-even-with-41/perl-Package-Constants-0.01-3.fc7.log fails-even-with-41/perl-Params-Check-0.26-1.fc7.log fails-even-with-41/perl-Parse-CPAN-Packages-2.26-4.fc7.log fails-even-with-41/perl-Perl-Critic-1.053-1.fc8.log fails-even-with-41/perl-Perl-MinimumVersion-0.15-1.fc9.log fails-even-with-41/perl-Perl6-Bible-0.30-3.fc7.log fails-even-with-41/perl-Pipeline-3.12-4.fc7.log fails-even-with-41/perl-RRD-Simple-1.43-1.fc7.log fails-even-with-41/perl-SUPER-1.16-1.fc7.log fails-even-with-41/perl-Set-Infinite-0.61-3.fc7.log fails-even-with-41/perl-Spiffy-0.30-7.fc7.log fails-even-with-41/perl-Spreadsheet-ParseExcel-0.3200-1.fc8.log fails-even-with-41/perl-Sys-SigAction-0.10-1.fc7.log fails-even-with-41/perl-Sys-Virt-0.1.1-9.fc7.log fails-even-with-41/perl-TermReadKey-2.30-3.fc9.log fails-even-with-41/perl-Test-Portability-Files-0.05-4.fc7.log fails-even-with-41/perl-Text-Levenshtein-0.05-4.fc7.log fails-even-with-41/perl-XML-Filter-BufferText-1.01-2.fc7.log fails-even-with-41/perl-XML-SAX-Writer-0.50-2.fc7.log fails-even-with-41/perl-XML-Validator-Schema-1.08-1.fc7.log fails-even-with-41/perl-YAML-Parser-Syck-0.01-8.fc7.log fails-even-with-41/pexpect-2.1-5.fc8.log fails-even-with-41/pida-0.5.1-5.fc9.log fails-even-with-41/pikdev-0.9.2-3.fc8.log fails-even-with-41/piklab-0.15.0-1.fc9.log fails-even-with-41/pikloops-0.2.5-1.fc9.log fails-even-with-41/plague-0.4.4.1-4.fc7.log fails-even-with-41/planet-2.0-4.fc8.log fails-even-with-41/polyester-1.0.2-1.fc8.log fails-even-with-41/postr-0.9-1.fc8.log fails-even-with-41/powerpc-utils-1.0.6-2.fc9.log fails-even-with-41/powerpc-utils-papr-1.0.4-2.fc9.log fails-even-with-41/ppc64-utils-0.14-1.fc9.log fails-even-with-41/prctl-1.5-2.log fails-even-with-41/prelink-0.4.0-1.log fails-even-with-41/prewikka-0.9.8-1.fc7.log fails-even-with-41/ps3pf-utils-2.1-1.fc9.log fails-even-with-41/pyOpenSSL-0.6-2.p24.9.log fails-even-with-41/pybackpack-0.5.1-2.fc8.log fails-even-with-41/pychart-1.39-6.fc8.log fails-even-with-41/pychecker-0.8.17-2.log fails-even-with-41/pygame-1.7.1-14.fc7.log fails-even-with-41/pygpgme-0.1-6.fc8.log fails-even-with-41/pygsl-0.9.1-6.fc8.log fails-even-with-41/pylibacl-0.2.2-1.fc8.log fails-even-with-41/pylint-0.13.1-1.fc7.log fails-even-with-41/pyparsing-1.4.7-1.fc8.log fails-even-with-41/pyscript-0.6.1-1.fc8.log fails-even-with-41/python-4Suite-XML-1.0.2-1.log fails-even-with-41/python-GeoIP-1.2.1-9.fc8.log fails-even-with-41/python-GnuPGInterface-0.3.2-2.fc8.log fails-even-with-41/python-alsa-1.0.15-1.fc8.log fails-even-with-41/python-basemap-0.9.5-3.fc8.log fails-even-with-41/python-bibtex-1.2.4-2.fc8.log fails-even-with-41/python-cerealizer-0.6-2.fc9.log fails-even-with-41/python-cherrypy-2.2.1-7.fc9.log fails-even-with-41/python-cherrytemplate-1.0.0-5.fc7.log fails-even-with-41/python-chm-0.8.4-1.fc7.log fails-even-with-41/python-configobj-4.4.0-2.fc8.log fails-even-with-41/python-cpio-0.1-4.fc8.log fails-even-with-41/python-crypto-2.0.1-9.1.log fails-even-with-41/python-dateutil-1.2-1.fc8.log fails-even-with-41/python-dialog-2.7-7.fc8.log fails-even-with-41/python-docs-2.5.1-1.fc8.log fails-even-with-41/python-durus-3.5-3.fc7.log fails-even-with-41/python-exif-1.0.5-1.fc9.log fails-even-with-41/python-fpconst-0.7.3-1.fc8.log fails-even-with-41/python-gammu-0.22-3.fc8.log fails-even-with-41/python-gdata-1.0.9-1.fc9.log fails-even-with-41/python-imaging-1.1.6-4.fc8.log fails-even-with-41/python-irclib-0.4.6-3.fc7.log fails-even-with-41/python-kiwi-1.9.16-1.fc8.log fails-even-with-41/python-lirc-0.0.5-5.log fails-even-with-41/python-logilab-astng-0.17.0-1.fc7.log fails-even-with-41/python-logilab-common-0.21.2-1.fc7.log fails-even-with-41/python-matplotlib-0.90.1-2.fc8.log fails-even-with-41/python-mecab-0.96-2.fc9.1.log fails-even-with-41/python-meld3-0.6-2.fc7.1.log fails-even-with-41/python-memcached-1.39-1.fc8.log fails-even-with-41/python-metar-1.3.0-2.fc7.log fails-even-with-41/python-musicbrainz2-0.5.0-1.fc9.log fails-even-with-41/python-mutagen-1.12-1.fc8.log fails-even-with-41/python-nltk-0.9-0.2.b2.fc8.log fails-even-with-41/python-nltk_lite-0.9-0.1.b2.fc8.log fails-even-with-41/python-numarray-1.5.2-4.fc8.log fails-even-with-41/python-ogg-1.3-7.log fails-even-with-41/python-psyco-1.5.1-5.fc7.log fails-even-with-41/python-psycopg2-2.0.6-2.fc8.log fails-even-with-41/python-pycurl-7.16.4-1.fc8.log fails-even-with-41/python-pydns-2.3.0-5.fc7.log fails-even-with-41/python-pyspf-2.0.3-1.fc8.log fails-even-with-41/python-quixote-2.4-5.fc7.log fails-even-with-41/python-reportlab-2.1-1.fc8.log fails-even-with-41/python-simpletal-4.1-5.fc7.log fails-even-with-41/python-simpy-1.8-1.fc7.log fails-even-with-41/python-smbpasswd-1.0.1-6.fc8.log fails-even-with-41/python-sqlite2-2.3.3-1.fc7.log fails-even-with-41/python-sqlobject-0.9.2-1.fc9.log fails-even-with-41/python-tag-0.91-5.log fails-even-with-41/python-telepathy-0.14.0-4.fc9.log fails-even-with-41/python-tpg-3.1.0-4.fc7.log fails-even-with-41/python-twisted-conch-0.8.0-1.fc8.log fails-even-with-41/python-twisted-core-2.5.0-2.fc8.log fails-even-with-41/python-twisted-lore-0.2.0-4.fc7.log fails-even-with-41/python-twisted-mail-0.4.0-1.fc8.log fails-even-with-41/python-twisted-names-0.4.0-1.fc8.log fails-even-with-41/python-twisted-news-0.3.0-1.fc8.log fails-even-with-41/python-twisted-runner-0.2.0-4.fc7.log fails-even-with-41/python-twisted-web-0.7.0-1.fc8.log fails-even-with-41/python-twisted-words-0.5.0-1.fc8.log fails-even-with-41/python-urlgrabber-3.0.0-3.fc8.log fails-even-with-41/python-urljr-1.0.1-1.fc7.log fails-even-with-41/python-virtinst-0.300.1-3.fc8.log fails-even-with-41/python-vorbis-1.5-0.2.a.log fails-even-with-41/python-which-1.1.0-2.fc9.log fails-even-with-41/python-xmpp-0.4.0-2.fc7.log fails-even-with-41/python-zope-interface-3.0.1-8.fc8.log fails-even-with-41/pytz-2006p-2.fc7.log fails-even-with-41/pyxattr-0.2.2-1.fc8.log fails-even-with-41/pyxdg-0.15-5.fc8.1.log fails-even-with-41/pyxf86config-0.3.34-1.fc8.log fails-even-with-41/pyxmms-2.06-4.fc7.log fails-even-with-41/pyzor-0.4.0-11.fc7.log fails-even-with-41/q-7.8-1.fc9.log fails-even-with-41/qa-assistant-0.4.90.5-2.fc6.log fails-even-with-41/qalculate-kde-0.9.6-2.fc8.log fails-even-with-41/qgis-0.9.0-2.fc8.log fails-even-with-41/qpidc-0.2-5.fc7.log fails-even-with-41/quadkonsole-2.0.2-1.fc7.log fails-even-with-41/rdiff-backup-1.0.5-5.fc8.log fails-even-with-41/rekall-2.4.5-6.fc8.1.log fails-even-with-41/repoman-0.9-3.fc8.log fails-even-with-41/rhm-0.1-3.fc7.log fails-even-with-41/rhythmbox-0.11.3-9.fc9.log fails-even-with-41/rkward-0.4.8-2.fc9.log fails-even-with-41/rosegarden4-1.6.0-1.fc7.log fails-even-with-41/rrdtool-1.3-0.2.beta2.fc9.log fails-even-with-41/ruby-bdb-0.6.0-1.fc7.log fails-even-with-41/ruby-gnome2-0.16.0-19.fc9.log fails-even-with-41/s390utils-1.5.4-4.fc7.log fails-even-with-41/s3switch-0.0-9.20020912.fc6.log fails-even-with-41/salinfo-0.5-1.14.1.fc6.log fails-even-with-41/sblim-cmpi-base-1.5.4-7.fc7.log fails-even-with-41/scipy-0.6.0-3.fc8.log fails-even-with-41/scons-0.97-2.fc8.log fails-even-with-41/sdcc-2.6.0-10.fc7.log fails-even-with-41/selinux-doc-1.26-1.1.log fails-even-with-41/showimg-0.9.5-13.fc8.log fails-even-with-41/six-0.5.3-6.fc8.log fails-even-with-41/smart-0.52-52.fc9.log fails-even-with-41/snake-0.9-0.5git.fc9.log fails-even-with-41/sos-1.6-5.fc8.log fails-even-with-41/specto-0.2.0-4.fc8.log fails-even-with-41/spicctrl-1.9-5.fc7.log fails-even-with-41/straw-0.27-12.fc9.log fails-even-with-41/supervisor-2.1-3.fc7.log fails-even-with-41/svnmailer-1.0.8-3.fc7.log fails-even-with-41/syck-0.61-3.fc9.log fails-even-with-41/synce-kde-0.9.1-1.fc7.log fails-even-with-41/syslog-ng-2.0.5-1.fc8.log fails-even-with-41/tailor-0.9.29-1.fc9.log fails-even-with-41/tastymenu-0.8.2-2.fc8.log fails-even-with-41/tclabc-1.0.9-1.fc7.log fails-even-with-41/tecnoballz-0.91-6.fc8.log fails-even-with-41/testoob-1.13-4.fc8.log fails-even-with-41/tetex-tex4ht-1.0.2007_11_19_2329-1.fc9.log fails-even-with-41/tinyerp-4.2.0-1.fc9.log fails-even-with-41/totem-2.21.5-3.fc9.log fails-even-with-41/trac-0.10.4-1.fc7.log fails-even-with-41/translate-toolkit-0.10.1-4.fc7.log fails-even-with-41/unison-2.13.16-3.fc6.log fails-even-with-41/ustr-1.0.2-4.fc9.log fails-even-with-41/veusz-0.10-16.fc8.log fails-even-with-41/vim-7.1.159-1.fc9.log fails-even-with-41/vnc-4.1.2-23.fc9.log fails-even-with-41/vtk-5.0.3-20.fc8.log fails-even-with-41/wammu-0.19-3.fc8.log fails-even-with-41/warzone2100-2.0.8-2.fc9.log fails-even-with-41/wdm-1.28-8.fc8.log fails-even-with-41/wine-0.9.49-2.fc9.log fails-even-with-41/wine-docs-0.9.49-1.fc9.log fails-even-with-41/wlassistant-0.5.7-4.fc8.log fails-even-with-41/wordtrans-1.1-0.2.pre13.fc7.log fails-even-with-41/wuja-0.0.8-2.fc8.log fails-even-with-41/wxPython-2.8.4.0-2.fc8.log fails-even-with-41/xaos-3.2.3-1.fc7.log fails-even-with-41/xca-0.6.4-1.fc8.log fails-even-with-41/xdaliclock-2.23-3.fc6.log fails-even-with-41/xen-3.1.2-2.fc9.log fails-even-with-41/xeuphoric-0.18.2-9.fc8.log fails-even-with-41/xfce4-battery-plugin-0.5.0-2.fc7.log fails-even-with-41/xferstats-2.16-14.1.log fails-even-with-41/xml-commons-resolver-1.1-1jpp.12.log fails-even-with-41/xmlunit-1.0-4jpp.1.fc7.log fails-even-with-41/xorg-x11-drv-acecad-1.1.0-5.fc8.log fails-even-with-41/xorg-x11-drv-amd-0.0-22.20070625.fc8.log fails-even-with-41/xorg-x11-drv-apm-1.1.1-7.fc8.log fails-even-with-41/xorg-x11-drv-ark-0.6.0-6.fc8.log fails-even-with-41/xorg-x11-drv-ast-0.81.0-6.fc8.log fails-even-with-41/xorg-x11-drv-calcomp-1.1.0-4.fc8.log fails-even-with-41/xorg-x11-drv-chips-1.1.1-5.fc8.log fails-even-with-41/xorg-x11-drv-cirrus-1.1.0-5.fc8.log fails-even-with-41/xorg-x11-drv-citron-2.2.0-2.fc7.log fails-even-with-41/xorg-x11-drv-cyrix-1.1.0-5.fc8.log fails-even-with-41/xorg-x11-drv-dmc-1.1.0-3.fc7.log fails-even-with-41/xorg-x11-drv-dynapro-1.1.0-3.fc7.log fails-even-with-41/xorg-x11-drv-glint-1.1.1-7.fc8.log fails-even-with-41/xorg-x11-drv-i128-1.2.1-1.fc8.log fails-even-with-41/xorg-x11-drv-i740-1.1.0-5.fc8.log fails-even-with-41/xorg-x11-drv-i810-2.2.0-2.fc9.log fails-even-with-41/xorg-x11-drv-magellan-1.1.0-4.fc8.log fails-even-with-41/xorg-x11-drv-mga-1.4.6.1-6.fc8.log fails-even-with-41/xorg-x11-drv-microtouch-1.1.0-2.fc7.log fails-even-with-41/xorg-x11-drv-neomagic-1.1.1-4.fc8.log fails-even-with-41/xorg-x11-drv-nsc-2.8.1-4.fc8.log fails-even-with-41/xorg-x11-drv-nv-2.1.6-2.fc9.log fails-even-with-41/xorg-x11-drv-penmount-1.1.0-3.fc7.log fails-even-with-41/xorg-x11-drv-rendition-4.1.3-5.fc8.log fails-even-with-41/xorg-x11-drv-s3-0.5.0-5.fc8.log fails-even-with-41/xorg-x11-drv-s3virge-1.9.1-5.fc8.log fails-even-with-41/xorg-x11-drv-savage-2.1.3-99.20071210.fc9.log fails-even-with-41/xorg-x11-drv-siliconmotion-1.5.1-3.fc8.log fails-even-with-41/xorg-x11-drv-sis-0.9.3-4.fc8.log fails-even-with-41/xorg-x11-drv-spaceorb-1.1.0-4.fc8.log fails-even-with-41/xorg-x11-drv-tdfx-1.3.0-6.fc8.log fails-even-with-41/xorg-x11-drv-trident-1.2.3-6.fc8.log fails-even-with-41/xorg-x11-drv-tseng-1.1.0-7.fc8.log fails-even-with-41/xorg-x11-drv-vermilion-1.0.0-2.fc8.log fails-even-with-41/xorg-x11-drv-vga-4.1.0-5.fc8.log fails-even-with-41/xorg-x11-drv-via-0.2.2-4.fc8.log fails-even-with-41/xorg-x11-drv-vmware-10.15.2-1.fc8.log fails-even-with-41/xorg-x11-drv-voodoo-1.1.1-1.fc8.log fails-even-with-41/xtide-2.9.5-1.fc9.log fails-even-with-41/yaboot-1.3.13-8.fc9.log fails-even-with-41/yakuake-2.7.5-4.fc7.log fails-even-with-41/yum-metadata-parser-1.1.2-2.fc9.log fails-even-with-41/zaptel-1.4.6-1.fc9.log fails-even-with-41/zeroinstall-injector-0.30-2.fc8.log fails-even-with-41/zsh-4.3.4-5.fc9.log Jakub From denis at poolshark.org Thu Jan 3 12:03:53 2008 From: denis at poolshark.org (Denis Leroy) Date: Thu, 03 Jan 2008 13:03:53 +0100 Subject: Policy proposal for compatibility packages In-Reply-To: <20080102131101.028dd228@redhat.com> References: <1199290909.11035.20.camel@kennedy> <477BCD23.8040206@leemhuis.info> <20080102131101.028dd228@redhat.com> Message-ID: <477CCF29.80709@poolshark.org> Jesse Keating wrote: > On Wed, 02 Jan 2008 18:42:59 +0100 > Thorsten Leemhuis wrote: > >> The proposal IMHO tries to solve the problem the wrong way. Having >> compat-packages in the repo is not the biggest problem -- other apps >> in Fedora using those compat-packages IMHO is what we should prevent. > > There is a difference between compatible library packages and > compatible development packages. Compatible libraries make long term > sense. Compat development packages don't. I have to disagree here, you can't possible think about all the use cases out there. For example, we ship compat-libstdc++-33.i386, which allows us to run an old legacy C++ executable that requires libstdc++.so.5. Unfortunately, if you have an old legacy library that requires libstdc++.so.5, no luck there, you'll need g++ 3.2 to link with it, i.e. compat-gcc-32-c++ which we no longer ship for Fedora (replaced by the less useful compat-gcc-34-c++). This is an example of a compat development package that would be really useful. Now can I package it and submit it for review ? From twaugh at redhat.com Thu Jan 3 12:07:27 2008 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 03 Jan 2008 12:07:27 +0000 Subject: ConsoleKit vs udev, ACLs getting lost Message-ID: <1199362047.3744.32.camel@cyberelk.elk> The problem I'm trying to solve is described in bug #424331: https://bugzilla.redhat.com/show_bug.cgi?id=424331 The background is that HPLIP uses libusb to communicate with HP USB printers, and both the printing system (running in group 'lp') and the current console user (or uses) need access in that way. The console user needs this access for ink-level checking and other status functions provided by the hp-toolbox program, and potentially for using the in-built scanner with libsane. When the printer is plugged in, the device node that libusb uses for it is in /dev/bus/usb/.../... and we want it to have group read/write access for 'lp', and user read/write access for each console user. The intention is to have udev rules set the group ownership to 'lp', and to grant group read/write permissions, and to have the HAL rules grant a 'rw' ACL for each console user. I originally described this approach here: http://cyberelk.net/tim/2007/10/04/hplip-device-permissions-with-consolekit/ It worked well, but a recent kernel update seems to have revealed a race condition. The ACL is granted (by hal-acl-tool) before the 'MODE=...' udev rule is applied, and this ordering messes up the ACL permissions (either the ACL mask or the group permissions end up being restricted). The problem boils down to this: How can I ensure that the ACL is granted *after* the mode permissions have been set, i.e. after the udev rules have completed, not before? Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pertusus at free.fr Thu Jan 3 12:12:47 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 3 Jan 2008 13:12:47 +0100 Subject: Policy proposal for compatibility packages In-Reply-To: <477CCF29.80709@poolshark.org> References: <1199290909.11035.20.camel@kennedy> <477BCD23.8040206@leemhuis.info> <20080102131101.028dd228@redhat.com> <477CCF29.80709@poolshark.org> Message-ID: <20080103121247.GE2572@free.fr> On Thu, Jan 03, 2008 at 01:03:53PM +0100, Denis Leroy wrote: > useful compat-gcc-34-c++). This is an example of a compat development > package that would be really useful. Now can I package it and submit it for > review ? Yes, you can. Why not? -- Pat From poelstra at redhat.com Thu Jan 3 07:40:14 2008 From: poelstra at redhat.com (John Poelstra) Date: Wed, 02 Jan 2008 23:40:14 -0800 Subject: Fedora 9 Feature Status Message-ID: <477C915E.4080402@redhat.com> Happy New Year! I've updated http://fedoraproject.org/wiki/Features/Dashboard to reflect the latest proposed features. Lots of good things are happening. I've added a new section for features I've found on the wiki that say that they are targeted for Fedora 9, yet haven't been brought forward for official acceptance. In many cases the feature pages are really close, yet some sections are still blank. In order to have your feature accepted for Fedora 9 it does not have to be fully complete at this time. A completed feature page (all sections--including "not applicable" as necessary) is needed by so that FESCo has all the information it needs for consideration. The accepted feature page for Fedora 9 continues to grow here: http://fedoraproject.org/wiki/Releases/9/FeatureList Thank you feature page owners and Fedora innovators! John _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From jkeating at redhat.com Thu Jan 3 12:25:54 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 3 Jan 2008 07:25:54 -0500 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080103120242.GZ20451@devserv.devel.redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> Message-ID: <20080103072554.5eb9c4b1@redhat.com> On Thu, 3 Jan 2008 07:02:42 -0500 Jakub Jelinek wrote: > The remaining 507 failures only fail with gcc-4.3.0-0.4 and not with > gcc-4.1.2-36, though most of them are just C++ being stricter, > something that ought to be fixed in the packages. > > I've tried to quickly grep through the failed logs and categorize > them: Thanks for this awesome work Jakub! Do you think it's worth creating a gcc4.3 tracking bug and then filing individual bugs against all these failures and attach them to the tracker? I think it can be done pretty easily with Will's python-bugzilla. That should give us some visibility in bugzilla for the feature and help us track progress of getting these fixed. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From andreas.bierfert at lowlatency.de Thu Jan 3 12:30:59 2008 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Thu, 3 Jan 2008 13:30:59 +0100 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080103072554.5eb9c4b1@redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <20080103072554.5eb9c4b1@redhat.com> Message-ID: <20080103133059.2e00c618@alkaid.a.lan> On Thu, 3 Jan 2008 07:25:54 -0500 Jesse Keating wrote: > Thanks for this awesome work Jakub! Do you think it's worth creating a > gcc4.3 tracking bug and then filing individual bugs against all these > failures and attach them to the tracker? I think it can be done pretty > easily with Will's python-bugzilla. That should give us some > visibility in bugzilla for the feature and help us track progress of > getting these fixed. +1 - Andreas -- Andreas Bierfert, B.Sc. | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From denis at poolshark.org Thu Jan 3 12:33:00 2008 From: denis at poolshark.org (Denis Leroy) Date: Thu, 03 Jan 2008 13:33:00 +0100 Subject: Policy proposal for compatibility packages In-Reply-To: <20080103121247.GE2572@free.fr> References: <1199290909.11035.20.camel@kennedy> <477BCD23.8040206@leemhuis.info> <20080102131101.028dd228@redhat.com> <477CCF29.80709@poolshark.org> <20080103121247.GE2572@free.fr> Message-ID: <477CD5FC.5010100@poolshark.org> Patrice Dumas wrote: > On Thu, Jan 03, 2008 at 01:03:53PM +0100, Denis Leroy wrote: >> useful compat-gcc-34-c++). This is an example of a compat development >> package that would be really useful. Now can I package it and submit it for >> review ? > > Yes, you can. Why not? Well Jakub isn't thrilled about the idea (he maintains compat-libstdc++-33, built from the same gcc 3.2 tarball), and his package obsoletes compat-gcc-32-c++. I guess I need to try harder to sway his opinion. Sorry this is getting off-topic. -denis From drago01 at gmail.com Thu Jan 3 12:36:00 2008 From: drago01 at gmail.com (drago01) Date: Thu, 03 Jan 2008 13:36:00 +0100 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080103120242.GZ20451@devserv.devel.redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> Message-ID: <477CD6B0.7090203@gmail.com> Jakub Jelinek wrote: > Hi! > > Hi, thx for doing this! > I've rebuilt 5118 rawhide-20071220 src.rpms on x86_64 in mock buildroots which > contained rawhide-20071220 except {gcc,lib}*-4.1.2-36.*.rpm, with additional > gcc-4.3.0-0.4 (available from koji, dist-f9-gcc43 component), > compat-libgfortran-41 (available from > http://people.redhat.com/jakub/gcc/compat-libgfortran-41-4.1.2-36.src.rpm ) > and later on also with gettext subpackages just rebuilt with gcc-4.3.0-0.4. > > Out of those 5118 src.rpms 1054 were failed builds. For those that failed > to build, I have retried with stock rawhide-20071220 mock buildroots (i.e. > gcc-4.1.2-36). 547 failed builds failed even with 4.1.2-36 (this count > includes even ExclusiveArched rpms etc.), logs for those are at > http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/fails-even-with-41/ > and generally don't interest me, as this is not a regression introduced by > 4.3.0-0.4. > > The remaining 507 failures only fail with gcc-4.3.0-0.4 and not with > gcc-4.1.2-36, though most of them are just C++ being stricter, something > that ought to be fixed in the packages. > > I've tried to quickly grep through the failed logs and categorize them: > [...] > 88 http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/unsorted/ > Unsorted, package maintainers please check this out, if you > believe there is a GCC bug rather than package bug, get in > touch with me with additional details. > Two of my packages are in this category: http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/unsorted/compiz-fusion-0.6.0-7.fc9.log and http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/unsorted/compiz-fusion-extras-0.6.0-1.fc9.log both fail with "checking how to run the C++ preprocessor... /lib/cpp configure: error: C++ preprocessor "/lib/cpp" fails sanity check See `config.log' for more details." But I don't have access to the config.log to see whats going on. I talked with upstream on IRC and they told me that for them it builds with "gcc (SUSE Linux) 4.3.0 20071129 (experimental) [trunk revision 130511]" So this might be a gcc bug. Any ideas? From pertusus at free.fr Thu Jan 3 12:36:22 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 3 Jan 2008 13:36:22 +0100 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080103120242.GZ20451@devserv.devel.redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> Message-ID: <20080103123622.GF2572@free.fr> On Thu, Jan 03, 2008 at 07:02:42AM -0500, Jakub Jelinek wrote: > Hi! > > Could you please redo the same, but with the package maintainer name somewhere on the log line. > Werror/NetworkManager-0.7.0-0.8.svn3181.fc9.log ... Thanks for your work on that. -- Pat From jakub at redhat.com Thu Jan 3 12:37:25 2008 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 3 Jan 2008 07:37:25 -0500 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080103120242.GZ20451@devserv.devel.redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> Message-ID: <20080103123725.GA20451@devserv.devel.redhat.com> On Thu, Jan 03, 2008 at 07:02:42AM -0500, Jakub Jelinek wrote: > 3 http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/auto_ptr/ > std::auto_ptr is no longer in , I belive unique_ptr > should be used instead, or there is . > Benjamin can tell more. Small correction here, std::auto_ptr is still in in -std=c++98 mode, it has been deprecated just in -std=c++0x mode from what I see. So the above 3 failures are something else, perhaps some header which unintentionally included no longer does or something. Jakub From buildsys at redhat.com Thu Jan 3 12:54:37 2008 From: buildsys at redhat.com (Build System) Date: Thu, 3 Jan 2008 07:54:37 -0500 Subject: rawhide report: 20080103 changes Message-ID: <200801031254.m03CsbAF032597@porkchop.devel.redhat.com> New package gtkimageview Simple image viewer widget New package libopensync-plugin-sunbird Mozilla Calendar / Sunbird Synchronization Plug-In for OpenSync New package perl-XML-Merge Flexibly merge XML documents Updated Packages: animorph-0.3-1.fc9 ------------------ asterisk-1.4.17-1.fc9 --------------------- * Wed Jan 02 2008 Jeffrey C. Ollie - 1.4.17-1 - Update to 1.4.17 to fix AST-2008-001. audacious-plugins-1.4.4-1.fc9 ----------------------------- * Wed Jan 02 2008 Ralf Ertzinger 1.4.4-1 - Update to 1.4.4 azureus-3.0.3.4-5.fc9 --------------------- * Wed Jan 02 2008 Lillian Angel - 3.0.3.4-5 - Updated script to set version. - Updated release. - Added new patch. - Resolves: rhbz#427257 bes-3.5.3-3.fc9 --------------- * Wed Jan 02 2008 Patrice Dumas 3.5.3-3 - Add Requires openssl-devel and zlib-devel since it is in bes-config --libs bibletime-1.6.5-2.fc9 --------------------- * Wed Jan 02 2008 David Anderson 1.6.5-2 - BR kdelibs3-devel booty-0.95-1.fc9 ---------------- * Wed Jan 02 2008 Chris Lumens - 0.94-1 - Write out initrd= in /etc/aboot.conf (#427112). dap-freeform_handler-3.7.7-2.fc9 -------------------------------- * Mon Dec 17 2007 Patrice Dumas 3.7.7-2 - update to 3.7.7 dap-hdf4_handler-3.7.7-3.fc9 ---------------------------- * Mon Dec 17 2007 Patrice Dumas 3.7.7-3 - update to 3.7.7 dap-netcdf_handler-3.7.8-2.fc9 ------------------------------ * Mon Dec 17 2007 Patrice Dumas 3.7.8-2 - update to 3.7.8 dap-server-3.8.4-2.fc9 ---------------------- * Mon Dec 17 2007 Patrice Dumas 3.8.4-2 - update to 3.8.4 * Wed Jul 04 2007 Patrice Dumas 3.8.2-1 - update to 3.8.2 - remove upstreamed security patch diffutils-2.8.1-20.fc9 ---------------------- * Wed Jan 02 2008 Tim Waugh 2.8.1-20 - Converted spec file to UTF-8 (bug #225696). - Fixed summary (bug #225696). - Fixed PreReq (bug #225696). - Removed Prefix (bug #225696). - Fixed build root (bug #225696). - Avoid %makeinstall (bug #225696). - Fixed license tag (bug #225696). epiphany-2.21.5-0.1.svn7844.fc9 ------------------------------- * Wed Jan 02 2008 Christopher Aillon - 2.21.5-0.1.svn7844 - Update to svn to build against xulrunner 1.9 * Mon Dec 17 2007 Christopher Aillon - 2.21.4-1 - Update to 2.21.4 * Thu Nov 29 2007 Martin Stransky - Polished the wrapper patch fedora-ds-base-1.1.0-4.fc9 -------------------------- * Thu Dec 20 2007 Rich Megginson - 1.1.0-4 - This is the GA release of Fedora DS 1.1 - Removed version numbers for BuildRequires and Requires - Added full URL to source tarball firefox-3.0-0.beta2.5.fc9 ------------------------- * Wed Jan 02 2008 Martin Stransky 3.0-0.beta2.5 - added default fedora homepage - updated a language pack (#427182) firstboot-1.91-1.fc9 -------------------- * Wed Jan 02 2008 Chris Lumens 1.91-1 - Reorganize to provide a python module. - Provide real help output for the firstboot program. freealut-1.1.0-5.fc9 -------------------- * Wed Jan 02 2008 Andreas Bierfert - 1.1.0-5 - fix #341161 multiarch conflicts glpk-4.25-1.fc9 --------------- * Wed Jan 02 2008 Quentin Spencer 4.25-1 - Update to release 4.25. gtkwave-3.1.2-1.fc9 ------------------- * Wed Jan 02 2008 Paul Howarth 3.1.2-1 - update to 3.1.2 jabbim-0.3-0.58.20080103svn.fc9 ------------------------------- * Thu Jan 03 2008 Michal Schmidt - 0.3-0.58.20080103svn - Upstream SVN revision 1684. - notable fixes: chat focus stealing, blank XHTML messages from Pidgin. kdelibs-6:3.97.0-10.fc9 ----------------------- * Wed Jan 02 2008 Kevin Kofler 3.97.0-10 - apply patch by Alex Merry to support FLAC 1.1.3+ in FindFlac.cmake * Sat Dec 22 2007 Kevin Kofler 3.97.0-9 - drop BR aspell-devel on F9+, use only enchant (FeatureDictionary) * Tue Dec 18 2007 Kevin Kofler 3.97.0-8 - don't put binaries into kdelibs-common, they drag in kdelibs (#417251) kdemultimedia-6:3.97.0-4.fc9 ---------------------------- * Wed Jan 02 2008 Kevin Kofler 3.97.0-4 - don't mention kaudiocreator in description, it's not actually there - apply patch by Alex Merry to support FLAC 1.1.3+ in kio_audiocd - apply patch by Allen Winter to fix cdparanoia detection - list audiocdencoder.h in file list (-devel) kernel-2.6.24-0.133.rc6.git8.fc9 -------------------------------- * Wed Jan 02 2008 Kyle McMartin - Un-disabled -doc builds. * Wed Jan 02 2008 Kyle McMartin - Temporarily disable -doc builds in hopes of getting new rpms into rawhide until koji is fixed. * Wed Jan 02 2008 Kyle McMartin - 2.6.24-rc6-git8 kio_sword-0.3-5.fc9 ------------------- * Wed Jan 02 2008 David Anderson 0.3-5 - BR kdelibs3-devel krb5-1.6.3-4.fc9 ---------------- * Wed Jan 02 2008 Nalin Dahyabhai 1.6.3-4 - some init script cleanups - drop unquoted check and silent exit for "$NETWORKING" (#426852, #242500) - krb524: don't barf on missing database if it looks like we're using kldap, same as for kadmin - return non-zero status for missing files which cause startup to fail * Tue Dec 18 2007 Nalin Dahyabhai 1.6.3-3 - allocate space for the nul-terminator in the local pathname when looking up a file context, and properly free a previous context (Jose Plans, #426085) * Wed Dec 05 2007 Nalin Dahyabhai 1.6.3-2 - rebuild libcdio-0.79-1.fc9 ------------------ * Wed Jan 02 2008 Adrian Reber - 0.79-1 - updated to 0.79 - fixes #427197 (Long Joliet file name overflows cdio's buffer) - fixes #341981 (multiarch conflicts in libcdio) libdap-3.7.10-2.fc9 ------------------- * Wed Jan 02 2008 Patrice Dumas 3.7.10-2 - use pkg-config in dap-config libnc-dap-3.7.0-9.fc9 --------------------- * Mon Dec 17 2007 Patrice Dumas 3.7.0-9 - rebuild against newer libdap libvirt-0.4.0-2.fc9 ------------------- * Wed Jan 02 2008 Daniel P. Berrange - 0.4.0-2.fc9 - Fix reading large config files (rhbz #426425) - Fix crash when connecting to a PolicyKit enabled server with not auth callback (rhbz #427107) linuxwacom-0.7.9.4-1.fc9 ------------------------ * Wed Jan 02 2008 Jeremy Katz - 0.7.9.4-1 - Update to 0.7.9-4 logwatch-7.3.6-15.fc9 --------------------- * Wed Jan 02 2008 Ivana Varekova 7.3.6-15 - Resolves: #424171 logwatch doesn't recognize dovecot starting up message .. * Wed Jan 02 2008 Ivana Varekova 7.3.6-14 - Resolves: #426857 is report cdrom "disk full" necessary maxima-5.14.0-4.fc9 ------------------- * Wed Jan 02 2008 Rex Dieter 5.14.0-4 - x86_64: --disable-gcl (#427250) - --disable-gcl (f9+, temporary, until broken deps fixed) * Tue Jan 01 2008 Rex Dieter 5.14.0-3 - (re)enable gcl mkinitrd-6.0.27-1.fc9 --------------------- * Wed Jan 02 2008 Peter Jones - 6.0.27-1 - Fix merge error that caused 6.0.25-1's change to be reverted. * Wed Jan 02 2008 Peter Jones - 6.0.26-1 - Update copyright and license info - Add support for loading all available drivers. mythes-de-0.20080102-1.fc9 -------------------------- * Wed Jan 02 2008 Caolan McNamara - 0.20080102-1 - latest version notify-python-0.1.1-1.fc9 ------------------------- * Wed Jan 02 2008 John Dennis - 0.1.1-1 - upgrade to current upstream - no longer remove package config file (notify-python.pc), resolves bug #427001 octave-forge-20071212-6.fc9 --------------------------- * Wed Jan 02 2008 Quentin Spencer 20071212-6 - Rebuild for libdap API change. pam-0.99.8.1-13.fc9 ------------------- * Wed Jan 02 2008 Tomas Mraz 0.99.8.1-13 - wildcard match support in pam_tty_audit (by Miloslav Trma??) * Thu Nov 29 2007 Tomas Mraz 0.99.8.1-12 - add pam_tty_audit module (#244352) - written by Miloslav Trma?? * Wed Nov 07 2007 Tomas Mraz 0.99.8.1-11 - add substack support parted-1.8.8-1.fc9 ------------------ * Wed Jan 02 2008 David Cantrell - 1.8.8-1 - Upgraded to GNU parted-1.8.8 - License for GNU parted is now GPLv3+ perl-DateTime-Event-ICal-0.09-4.fc9 ----------------------------------- * Thu Jan 03 2008 Ralf Cors??pius 0.09-4 - Adjust License-tag. - BR: perl(Test::More) (BZ 419631). perl-DateTime-Event-Recurrence-0.16-5.fc9 ----------------------------------------- * Thu Jan 03 2008 Ralf Cors??pius 0.16-5 - Adjust License-tag. - BR: perl(Test::More) (BZ 419631). perl-DateTime-Format-ICal-0.08-5.fc9 ------------------------------------ * Thu Jan 03 2008 Ralf Cors??pius 0.08-5 - Adjust License-tag. - BR: perl(Test::More) (BZ 419631). perl-DateTime-Format-W3CDTF-0.04-3.fc9 -------------------------------------- perl-Devel-Caller-2.02-1.fc9 ---------------------------- perl-GDTextUtil-0.86-9.fc9 -------------------------- * Wed Jan 02 2008 Ralf Cors??pius - 0.86-9 - Add BR: perl(Test::More) (BZ 419631). perl-HTML-Template-Expr-0.07-5.fc9 ---------------------------------- * Wed Jan 02 2008 Ralf Cors??pius 0.07-5 - Adjust License-tag. - BR: perl(Test::More) (BZ 419631). perl-Net-XMPP-1.02-3.fc9 ------------------------ * Wed Jan 02 2008 Ralf Cors??pius 1.02-3 - BR: perl(Test::More) (BZ 419631). - Spec file cleanup. perl-Object-Accessor-0.32-3.fc9 ------------------------------- * Wed Jan 02 2008 Ralf Cors??pius 0.32-3 - Adjust License-tag. - BR: perl(Test::More) (BZ 419631). perl-POE-API-Peek-1.0802-2.fc9 ------------------------------ * Wed Jan 02 2008 Ralf Cors??pius 1.0802-2 - Add BR: perl(Test::More) (BZ 419631). perl-Test-Inline-2.208-1.fc9 ---------------------------- * Wed Jan 02 2008 Ralf Cors??pius - 2.208-1 - Upstream update. - Update build deps. - Re-enable AUTOMATED_TESTING. perl-Text-Levenshtein-0.05-5.fc9 -------------------------------- * Wed Jan 02 2008 Ralf Cors??pius 0.05-5 - Adjust License-tag. - Add BR: perl(Test::More) (BZ 419631). perl-Tk-804.028-1.fc9 --------------------- * Wed Jan 02 2008 Andreas Bierfert - 804.028-1 - version upgrade - fix #210718 SIGSEGV on exit from texdoctk - fix #234404 Cannot manage big listboxes - fix #235666 Segfault occurs when using Perl-Tk on FC6 perl-UNIVERSAL-isa-0.06-4.fc9 ----------------------------- * Wed Jan 02 2008 Ralf Cors??pius - 0.06-4 - Update License-tag. perl-Want-0.16-1.fc9 -------------------- * Wed Jan 02 2008 Ralf Cors??pius - 0.16-1 - Upstream update. php-pear-Log-1.9.14-1.fc9 ------------------------- * Wed Jan 02 2008 Remi Collet 1.9.14-1 - update to 1.9.14 pm-utils-0.99.4-10.fc9 ---------------------- * Wed Jan 02 2008 Till Maas - 0.99.4-10 - enhance hd-apm-restore and add a config file - fix source-definition for hd-apm-restore - add hook suffix for hook script * Wed Jan 02 2008 Till Maas - 0.99.4-9 - restore hd apm level (RH #382061) - Add hdparm requires for new hook * Mon Dec 31 2007 Till Maas - 0.99.4-8 - Add documentation to %doc polyml-5.1-3.fc9 ---------------- * Wed Jan 02 2008 Gerard Milmeister - 5.1-3 - Exclude arch ppc64 pungi-1.2.6-1.fc9 ----------------- * Wed Jan 02 2008 jkeating 1.2.6-1 - Update the url field for new hosted urls. - Add k3b to the Fedora manifest. * Mon Dec 10 2007 Jesse Keating 1.2.4-1 - Remove extra files from tarball * Mon Dec 10 2007 Jesse Keating 1.2.3-1 - Use a repoview cache. - Use a createrepo cache. - Change path to isomd5sum - Add egg file to spec pyparted-1.8.9-4.fc9 -------------------- * Wed Jan 02 2008 David Cantrell - 1.8.9-4 - Rebuild rrdtool-1.3-0.4.beta3.fc9 ------------------------- * Wed Jan 02 2008 Jarod Wilson 1.3.0-0.4.beta3 - Add newly built python egg to %files * Wed Jan 02 2008 Jarod Wilson 1.3.0-0.3.beta3 - Update to rrdtool 1.3 beta3 - Return properly from errors in RRDp.pm (Resolves: #427040) - Requires: dejavu-lgc-fonts (Resolves: #426935) * Thu Dec 06 2007 Jarod Wilson 1.3.0-0.2.beta2 - Update to rrdtool 1.3 beta2 rsyslog-1.21.2-1.fc9 -------------------- * Wed Jan 02 2008 Peter Vrabec 1.21.2-1 - new upstream release ruby-libvirt-0.0.2-3.fc9 ------------------------ * Wed Jan 02 2008 David Lutterkort - 0.0.2-3 - Make _libvirt.so stripable by changing permissions to +x streamtuner-0.99.99-16.1.fc7 ---------------------------- * Fri Dec 14 2007 Matthias Haase - 0.99.99-16.1 - broken live365 plugin disabled tcl-1:8.5.0-1.fc9.1 ------------------- * Wed Jan 02 2008 Marcela Maslanova - 1:8.5.0-1 - upgrade on the new whole version 8.5.0 - thank you for patches and clean spec to wart (at kobold) * Fri Nov 16 2007 Marcela Maslanova - 1:8.4.15-6 - CVE-2007-4772 NFA optimization cause hang in loop. Back ported patch from upstream development version. * Wed Sep 26 2007 Marcela Maslanova - 1:8.4.15-5 - fix of patch - set auto_path was broken - Resolves: rhbz#306321 tk-1:8.5.0-1.fc9 ---------------- * Wed Jan 02 2008 Marcela Maslanova - 1:8.5.0-1 - upgrade on the 8.5.0 * Mon Sep 17 2007 Marcela Maslanova - 1:8.4.15-5 - CVE-2007-4851 Tk GIF processing buffer overflow - Resolves: rhbz#290991 * Fri Aug 31 2007 Jeremy Katz - 1:8.4.15-4 - BR gawk to unbreak things ufraw-0.13-3.fc9 ---------------- * Wed Jan 02 2008 Nils Philippsen - 0.13-3 - build against gtkimageview, drop scrollable-preview patch (#427028) util-linux-ng-2.13.1-2.fc9 -------------------------- * Wed Jan 02 2008 Karel Zak 2.13.1-2 - update to upstream 2.13.1-rc2 * Wed Dec 12 2007 Dan Walsh 2.13.1-1 - Fix pam files so that pam_keyinit happens after pam_selinux.so * Wed Dec 12 2007 Karel Zak 2.13.1-0.2 - remove viwp and vigr (in favour of shadow-utils) xfce-utils-4.4.2-2.fc9 ---------------------- * Wed Jan 02 2008 Kevin Fenzi - 4.4.2-2 - Add patch to start pulseaudio if installed xorg-x11-drv-ati-6.7.196-5.fc9 ------------------------------ * Wed Jan 02 2008 Adam Jackson 6.7.196-5 - r128-6.7.196-pciaccess.patch: Fix some preprocessor dumbness. * Wed Jan 02 2008 Adam Jackson 6.7.196-4 - r128-6.7.196-pciaccess.patch: Port r128 to libpciaccess. xorg-x11-drv-mga-1.4.7-0.20080102.fc9 ------------------------------------- * Wed Jan 02 2008 Adam Jackson 1.4.7-0.20080102 - Today's git snapshot for pciaccess goodness. - mga-1.4.7-death-to-cfb.patch: Remove what little cfb support there was. - mga-1.4.7-alloca.patch: Fix ALLOCATE_LOCAL references. xorg-x11-drv-openchrome-0.2.901-1.fc9 ------------------------------------- * Wed Jan 02 2008 Xavier Bachelot - 0.2.901-1 - Update to 0.2.901. - Remove obsoleted patches. - Update libpciaccess patch. xorg-x11-drv-vmmouse-12.4.3-3.fc9 --------------------------------- * Wed Jan 02 2008 Jeremy Katz - 12.4.3-3 - Add workaround for xserver not calling convert_proc in input drivers anymore (patch from Joerg Platte on debian xmaint list) xpdf-1:3.02-5.fc9 ----------------- * Wed Jan 02 2008 Tom "spot" Callaway 1:3.02-5 - use xdg-utils instead of htmlview (bz 313311) Broken deps for i386 ---------------------------------------------------------- 8Kingdoms - 1.1.0-2.fc9.i386 requires libtcl8.4.so R - 2.6.1-1.fc9.i386 requires libtcl8.4.so R - 2.6.1-1.fc9.i386 requires libtk8.4.so amsn - 0.97-1.fc9.i386 requires tcl(abi) = 0:8.4 bacula-client - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-client - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bwidget - 1.8.0-2.fc8.noarch requires tcl(abi) = 0:8.4 climm - 0.6.1-1.fc9.i386 requires libtcl8.4.so csound-tk - 5.03.0-13.fc7.i386 requires libtk8.4.so csound-tk - 5.03.0-13.fc7.i386 requires libtcl8.4.so d4x - 2.5.7.1-3.fc7.i386 requires libssl.so.6 d4x - 2.5.7.1-3.fc7.i386 requires libcrypto.so.6 ds9 - 5.0-6.fc9.i386 requires libtk8.4.so ds9 - 5.0-6.fc9.i386 requires libtcl8.4.so eggdrop - 1.6.18-12.fc9.i386 requires libtcl8.4.so environment-modules - 3.2.6-1.fc9.i386 requires libtcl8.4.so epiphany-extensions - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires libgtkembedmoz.so expect - 5.43.0-9.fc8.i386 requires libtcl8.4.so expectk - 5.43.0-9.fc8.i386 requires libtk8.4.so expectk - 5.43.0-9.fc8.i386 requires libtcl8.4.so funtools - 1.4.0-4.fc9.i386 requires libtcl8.4.so funtools-libs - 1.4.0-4.fc9.i386 requires libtcl8.4.so gcl - 2.6.7-15.fc8.i386 requires libtcl8.4.so gcl - 2.6.7-15.fc8.i386 requires libtk8.4.so gdal - 1.4.2-3.fc8.i386 requires libdapserver.so.3 gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gdal - 1.4.2-3.fc8.i386 requires libdapclient.so.1 gdal - 1.4.2-3.fc8.i386 requires libdap.so.6 gnome-web-photo - 0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.i386 requires libgtkembedmoz.so gnu-smalltalk - 2.3.6-7.fc9.i386 requires libtcl8.4.so gnu-smalltalk - 2.3.6-7.fc9.i386 requires libtk8.4.so gparted - 0.3.3-14.fc9.i386 requires libparted-1.8.so.6 grads - 1.9b4-21.fc8.i386 requires libdap.so.6 graphviz-tcl - 2.14.1-3.fc8.i386 requires libtk8.4.so grass - 6.2.2-2.fc8.i386 requires libcrypto.so.6 grass - 6.2.2-2.fc8.i386 requires libtk8.4.so grass - 6.2.2-2.fc8.i386 requires libtcl8.4.so grass - 6.2.2-2.fc8.i386 requires libssl.so.6 hamlib-tcl - 1.2.6.2-5.fc9.i386 requires libtcl8.4.so hfsutils - 3.2.6-11.fc8.i386 requires libtcl8.4.so hfsutils-x11 - 3.2.6-11.fc8.i386 requires libtcl8.4.so hfsutils-x11 - 3.2.6-11.fc8.i386 requires libtk8.4.so hping3 - 0.0.20051105-7.fc7.i386 requires libtcl8.4.so irsim - 9.7.50-1.fc8.i386 requires libtcl8.4.so irsim - 9.7.50-1.fc8.i386 requires libtk8.4.so isdn4k-utils-vboxgetty - 3.2-55.fc8.i386 requires libtcl8.4.so kannel - 1.4.1-5.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 libopensync-plugin-sunbird - 0.22-3.fc7.i386 requires libneon.so.25 libopensync-plugin-sunbird - 0.22-3.fc7.i386 requires libopensync.so.0 libopensync-plugin-sunbird - 0.22-3.fc7.i386 requires libssl.so.6 libopensync-plugin-sunbird - 0.22-3.fc7.i386 requires libcrypto.so.6 libopensync-plugin-synce - 0.22-4.fc8.i386 requires libopensync.so.0 libpurple-tcl - 2.3.1-1.fc9.i386 requires libtk8.4.so libpurple-tcl - 2.3.1-1.fc9.i386 requires libtcl8.4.so liferea - 1.4.10-1.fc9.i386 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.i386 requires libgtkembedmoz.so magic - 7.4.35-6.fc8.i386 requires libtcl8.4.so magic - 7.4.35-6.fc8.i386 requires libtk8.4.so mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.i386 requires libcrypto.so.6 mkinitrd - 6.0.27-1.fc9.i386 requires libparted-1.8.so.6 multisync - 0.91.0-1.fc7.i386 requires libopensync.so.0 multisync - 0.91.0-1.fc7.i386 requires libosengine.so.0 multisync-gui - 0.91.0-1.fc7.i386 requires libopensync.so.0 multisync-gui - 0.91.0-1.fc7.i386 requires libosengine.so.0 nash - 6.0.27-1.fc9.i386 requires libparted-1.8.so.6 netgen - 1.3.7-13.fc9.i386 requires libtcl8.4.so netgen - 1.3.7-13.fc9.i386 requires libtk8.4.so ocaml-labltk - 3.10.0-7.fc8.i386 requires libtk8.4.so ocaml-labltk - 3.10.0-7.fc8.i386 requires libtcl8.4.so ogdi-tcl - 3.2.0-0.5.beta1.fc7.i386 requires libtcl8.4.so openmsx - 0.6.2-4.fc8.i386 requires libtcl8.4.so php-mapserver - 4.10.3-2.fc8.i386 requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.i386 requires libcrypto.so.6 plplot - 5.8.0-5.fc9.i386 requires libtcl8.4.so plplot - 5.8.0-5.fc9.i386 requires libtk8.4.so plplot-tk - 5.8.0-5.fc9.i386 requires libtk8.4.so plplot-tk - 5.8.0-5.fc9.i386 requires libtcl8.4.so postgresql-pltcl - 8.2.5-2.fc9.i386 requires libtcl8.4.so ppracer - 0.3.1-13.fc8.i386 requires libtcl8.4.so pvm-gui - 3.4.5-7.fc6.1.i386 requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.i386 requires libtcl8.4.so python-gammu - 0.22-3.fc8.i386 requires libGammu.so.2 python-imaging-tk - 1.1.6-4.fc8.i386 requires libtk8.4.so python-imaging-tk - 1.1.6-4.fc8.i386 requires libtcl8.4.so python-matplotlib-tk - 0.90.1-2.fc8.i386 requires libtk8.4.so python-matplotlib-tk - 0.90.1-2.fc8.i386 requires libtcl8.4.so q - 7.10-1.fc9.i386 requires libtcl8.4.so q - 7.10-1.fc9.i386 requires libtk8.4.so qtparted - 0.4.5-15.fc8.i386 requires libparted-1.8.so.6 ruby-tcltk - 1.8.6.111-4.fc9.i386 requires libtk8.4.so ruby-tcltk - 1.8.6.111-4.fc9.i386 requires libtcl8.4.so skencil - 0.6.17-15.20070606svn.fc8.i386 requires libtk8.4.so skencil - 0.6.17-15.20070606svn.fc8.i386 requires libtcl8.4.so tbcload - 1.4-5.20061030cvs.fc8.i386 requires tcl(abi) = 0:8.4 tcl-brlapi - 0.5.0-1.fc8.i386 requires libtcl8.4.so tcl-tcldict - 8.5.2-2.fc8.i386 requires tcl(abi) = 0:8.4 tclchecker - 1.4-3.20061030cvs.fc8.noarch requires tcl(abi) = 0:8.4 tclcompiler - 1.5-3.20061030cvs.fc8.i386 requires tcl(abi) = 0:8.4 tcldebugger - 1.4-5.20061030cvs.fc8.noarch requires tcl(abi) = 0:8.4 tcldom - 3.1-10.fc7.i386 requires tcl(abi) = 0:8.4 tclhttpd - 3.5.1-15.fc8.i386 requires tcl(abi) = 0:8.4 tclpro - 1.5.0-10.20061030cvs.fc9.noarch requires tcl(abi) = 0:8.4 tk-tktreectrl - 2.2.3-2.fc8.i386 requires tcl(abi) = 0:8.4 tkimg - 1.3-0.6.20071018svn.fc9.i386 requires tcl(abi) = 0:8.4 tkinter - 2.5.1-18.fc9.i386 requires libtk8.4.so tkinter - 2.5.1-18.fc9.i386 requires libtcl8.4.so torque-client - 2.1.10-1.fc9.i386 requires libtk8.4.so torque-client - 2.1.10-1.fc9.i386 requires libtcl8.4.so torque-gui - 2.1.10-1.fc9.i386 requires libtk8.4.so torque-gui - 2.1.10-1.fc9.i386 requires libtcl8.4.so torque-gui - 2.1.10-1.fc9.i386 requires /usr/bin/wish8.4 uudeview - 0.5.20-13.i386 requires libtk8.4.so uudeview - 0.5.20-13.i386 requires libtcl8.4.so vkeybd - 0.1.17a-5.fc8.i386 requires tk < 1:8.5 vkeybd - 0.1.17a-5.fc8.i386 requires libtk8.4.so vkeybd - 0.1.17a-5.fc8.i386 requires libtcl8.4.so vtk - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtcl8.4.so xca - 0.6.4-1.fc8.i386 requires libcrypto.so.6 xchat-tcl - 1:2.8.4-9.fc9.i386 requires libtcl8.4.so xcircuit - 3.4.27-1.fc9.i386 requires libtk8.4.so xcircuit - 3.4.27-1.fc9.i386 requires libtcl8.4.so xpa-tcl - 2.1.8-3.fc9.i386 requires libtcl8.4.so Broken deps for x86_64 ---------------------------------------------------------- 8Kingdoms - 1.1.0-2.fc9.x86_64 requires libtcl8.4.so()(64bit) R - 2.6.1-1.fc9.i386 requires libtcl8.4.so R - 2.6.1-1.fc9.i386 requires libtk8.4.so R - 2.6.1-1.fc9.x86_64 requires libtk8.4.so()(64bit) R - 2.6.1-1.fc9.x86_64 requires libtcl8.4.so()(64bit) amsn - 0.97-1.fc9.x86_64 requires tcl(abi) = 0:8.4 bacula-client - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bwidget - 1.8.0-2.fc8.noarch requires tcl(abi) = 0:8.4 climm - 0.6.1-1.fc9.x86_64 requires libtcl8.4.so()(64bit) csound-tk - 5.03.0-13.fc7.x86_64 requires libtk8.4.so()(64bit) csound-tk - 5.03.0-13.fc7.x86_64 requires libtcl8.4.so()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libssl.so.6()(64bit) ds9 - 5.0-6.fc9.x86_64 requires libtk8.4.so()(64bit) ds9 - 5.0-6.fc9.x86_64 requires libtcl8.4.so()(64bit) eggdrop - 1.6.18-12.fc9.x86_64 requires libtcl8.4.so()(64bit) environment-modules - 3.2.6-1.fc9.x86_64 requires libtcl8.4.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) expect - 5.43.0-9.fc8.x86_64 requires libtcl8.4.so()(64bit) expect - 5.43.0-9.fc8.i386 requires libtcl8.4.so expectk - 5.43.0-9.fc8.x86_64 requires libtk8.4.so()(64bit) expectk - 5.43.0-9.fc8.x86_64 requires libtcl8.4.so()(64bit) funtools-libs - 1.4.0-4.fc9.i386 requires libtcl8.4.so funtools-libs - 1.4.0-4.fc9.x86_64 requires libtcl8.4.so()(64bit) gcl - 2.6.7-15.fc8.x86_64 requires libtcl8.4.so()(64bit) gcl - 2.6.7-15.fc8.x86_64 requires libtk8.4.so()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libdapclient.so.1()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libdap.so.6()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libdapserver.so.3()(64bit) gdal - 1.4.2-3.fc8.x86_64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.i386 requires libdapserver.so.3 gdal - 1.4.2-3.fc8.i386 requires libssl.so.6 gdal - 1.4.2-3.fc8.i386 requires libcrypto.so.6 gdal - 1.4.2-3.fc8.i386 requires libdapclient.so.1 gdal - 1.4.2-3.fc8.i386 requires libdap.so.6 gnome-web-photo - 0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) gnu-smalltalk - 2.3.6-7.fc9.i386 requires libtcl8.4.so gnu-smalltalk - 2.3.6-7.fc9.i386 requires libtk8.4.so gnu-smalltalk - 2.3.6-7.fc9.x86_64 requires libtk8.4.so()(64bit) gnu-smalltalk - 2.3.6-7.fc9.x86_64 requires libtcl8.4.so()(64bit) gparted - 0.3.3-14.fc9.x86_64 requires libparted-1.8.so.6()(64bit) grads - 1.9b4-21.fc8.x86_64 requires libdap.so.6()(64bit) graphviz-tcl - 2.14.1-3.fc8.x86_64 requires libtk8.4.so()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libssl.so.6()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libtk8.4.so()(64bit) grass - 6.2.2-2.fc8.x86_64 requires libtcl8.4.so()(64bit) hamlib-tcl - 1.2.6.2-5.fc9.x86_64 requires libtcl8.4.so()(64bit) hfsutils - 3.2.6-11.fc8.x86_64 requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-11.fc8.x86_64 requires libtk8.4.so()(64bit) hfsutils-x11 - 3.2.6-11.fc8.x86_64 requires libtcl8.4.so()(64bit) hping3 - 0.0.20051105-7.fc7.x86_64 requires libtcl8.4.so()(64bit) isdn4k-utils-vboxgetty - 3.2-55.fc8.x86_64 requires libtcl8.4.so()(64bit) kazehakase - 0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 libopensync-plugin-sunbird - 0.22-3.fc7.x86_64 requires libssl.so.6()(64bit) libopensync-plugin-sunbird - 0.22-3.fc7.x86_64 requires libneon.so.25()(64bit) libopensync-plugin-sunbird - 0.22-3.fc7.x86_64 requires libcrypto.so.6()(64bit) libopensync-plugin-sunbird - 0.22-3.fc7.x86_64 requires libopensync.so.0()(64bit) libopensync-plugin-synce - 0.22-4.fc8.x86_64 requires libopensync.so.0()(64bit) libpurple-tcl - 2.3.1-1.fc9.x86_64 requires libtk8.4.so()(64bit) libpurple-tcl - 2.3.1-1.fc9.x86_64 requires libtcl8.4.so()(64bit) liferea - 1.4.10-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.x86_64 requires libgtkembedmoz.so()(64bit) magic - 7.4.35-6.fc8.x86_64 requires libtcl8.4.so()(64bit) magic - 7.4.35-6.fc8.x86_64 requires libtk8.4.so()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) mkinitrd - 6.0.27-1.fc9.x86_64 requires libparted-1.8.so.6()(64bit) multisync - 0.91.0-1.fc7.x86_64 requires libosengine.so.0()(64bit) multisync - 0.91.0-1.fc7.x86_64 requires libopensync.so.0()(64bit) multisync-gui - 0.91.0-1.fc7.x86_64 requires libopensync.so.0()(64bit) multisync-gui - 0.91.0-1.fc7.x86_64 requires libosengine.so.0()(64bit) nash - 6.0.27-1.fc9.x86_64 requires libparted-1.8.so.6()(64bit) nash - 6.0.27-1.fc9.i386 requires libparted-1.8.so.6 netgen - 1.3.7-13.fc9.x86_64 requires libtcl8.4.so()(64bit) netgen - 1.3.7-13.fc9.x86_64 requires libtk8.4.so()(64bit) ocaml-labltk - 3.10.0-7.fc8.x86_64 requires libtcl8.4.so()(64bit) ocaml-labltk - 3.10.0-7.fc8.x86_64 requires libtk8.4.so()(64bit) ogdi-tcl - 3.2.0-0.5.beta1.fc7.x86_64 requires libtcl8.4.so()(64bit) openmsx - 0.6.2-4.fc8.x86_64 requires libtcl8.4.so()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.x86_64 requires libssl.so.6()(64bit) plplot - 5.8.0-5.fc9.x86_64 requires libtk8.4.so()(64bit) plplot - 5.8.0-5.fc9.x86_64 requires libtcl8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.x86_64 requires libtk8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.x86_64 requires libtcl8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.i386 requires libtk8.4.so plplot-tk - 5.8.0-5.fc9.i386 requires libtcl8.4.so postgresql-pltcl - 8.2.5-2.fc9.x86_64 requires libtcl8.4.so()(64bit) ppracer - 0.3.1-13.fc8.x86_64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.x86_64 requires libtk8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.x86_64 requires libtcl8.4.so()(64bit) python-gammu - 0.22-3.fc8.x86_64 requires libGammu.so.2()(64bit) python-imaging-tk - 1.1.6-4.fc8.x86_64 requires libtk8.4.so()(64bit) python-imaging-tk - 1.1.6-4.fc8.x86_64 requires libtcl8.4.so()(64bit) python-matplotlib-tk - 0.90.1-2.fc8.x86_64 requires libtcl8.4.so()(64bit) python-matplotlib-tk - 0.90.1-2.fc8.x86_64 requires libtk8.4.so()(64bit) q - 7.10-1.fc9.i386 requires libtcl8.4.so q - 7.10-1.fc9.i386 requires libtk8.4.so qtparted - 0.4.5-15.fc8.x86_64 requires libparted-1.8.so.6()(64bit) ruby-tcltk - 1.8.6.111-4.fc9.x86_64 requires libtk8.4.so()(64bit) ruby-tcltk - 1.8.6.111-4.fc9.x86_64 requires libtcl8.4.so()(64bit) skencil - 0.6.17-15.20070606svn.fc8.x86_64 requires libtcl8.4.so()(64bit) skencil - 0.6.17-15.20070606svn.fc8.x86_64 requires libtk8.4.so()(64bit) tbcload - 1.4-5.20061030cvs.fc8.x86_64 requires tcl(abi) = 0:8.4 tcl-brlapi - 0.5.0-1.fc8.x86_64 requires libtcl8.4.so()(64bit) tcl-tcldict - 8.5.2-2.fc8.x86_64 requires tcl(abi) = 0:8.4 tclchecker - 1.4-3.20061030cvs.fc8.noarch requires tcl(abi) = 0:8.4 tclcompiler - 1.5-3.20061030cvs.fc8.x86_64 requires tcl(abi) = 0:8.4 tcldebugger - 1.4-5.20061030cvs.fc8.noarch requires tcl(abi) = 0:8.4 tcldom - 3.1-10.fc7.x86_64 requires tcl(abi) = 0:8.4 tclhttpd - 3.5.1-15.fc8.x86_64 requires tcl(abi) = 0:8.4 tclpro - 1.5.0-10.20061030cvs.fc9.noarch requires tcl(abi) = 0:8.4 tk-tktreectrl - 2.2.3-2.fc8.x86_64 requires tcl(abi) = 0:8.4 tkimg - 1.3-0.6.20071018svn.fc9.x86_64 requires tcl(abi) = 0:8.4 tkimg - 1.3-0.6.20071018svn.fc9.i386 requires tcl(abi) = 0:8.4 tkinter - 2.5.1-18.fc9.x86_64 requires libtk8.4.so()(64bit) tkinter - 2.5.1-18.fc9.x86_64 requires libtcl8.4.so()(64bit) torque-client - 2.1.10-1.fc9.x86_64 requires libtk8.4.so()(64bit) torque-client - 2.1.10-1.fc9.x86_64 requires libtcl8.4.so()(64bit) torque-gui - 2.1.10-1.fc9.x86_64 requires libtk8.4.so()(64bit) torque-gui - 2.1.10-1.fc9.x86_64 requires /usr/bin/wish8.4 torque-gui - 2.1.10-1.fc9.x86_64 requires libtcl8.4.so()(64bit) uudeview - 0.5.20-13.x86_64 requires libtk8.4.so()(64bit) uudeview - 0.5.20-13.x86_64 requires libtcl8.4.so()(64bit) vkeybd - 0.1.17a-5.fc8.x86_64 requires libtcl8.4.so()(64bit) vkeybd - 0.1.17a-5.fc8.x86_64 requires libtk8.4.so()(64bit) vkeybd - 0.1.17a-5.fc8.x86_64 requires tk < 1:8.5 vtk - 5.0.3-20.fc8.x86_64 requires libtk8.4.so()(64bit) vtk - 5.0.3-20.fc8.x86_64 requires libtcl8.4.so()(64bit) vtk - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-python - 5.0.3-20.fc8.x86_64 requires libtk8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.x86_64 requires libtcl8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.x86_64 requires libtk8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.x86_64 requires libtcl8.4.so()(64bit) xca - 0.6.4-1.fc8.x86_64 requires libcrypto.so.6()(64bit) xchat-tcl - 1:2.8.4-9.fc9.x86_64 requires libtcl8.4.so()(64bit) xcircuit - 3.4.27-1.fc9.x86_64 requires libtk8.4.so()(64bit) xcircuit - 3.4.27-1.fc9.x86_64 requires libtcl8.4.so()(64bit) xpa-tcl - 2.1.8-3.fc9.x86_64 requires libtcl8.4.so()(64bit) xpa-tcl - 2.1.8-3.fc9.i386 requires libtcl8.4.so Broken deps for ppc ---------------------------------------------------------- 8Kingdoms - 1.1.0-2.fc9.ppc requires libtcl8.4.so R - 2.6.1-1.fc9.ppc64 requires libtk8.4.so()(64bit) R - 2.6.1-1.fc9.ppc64 requires libtcl8.4.so()(64bit) R - 2.6.1-1.fc9.ppc requires libtcl8.4.so R - 2.6.1-1.fc9.ppc requires libtk8.4.so amsn - 0.97-1.fc9.ppc requires tcl(abi) = 0:8.4 bacula-client - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-client - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bwidget - 1.8.0-2.fc8.noarch requires tcl(abi) = 0:8.4 climm - 0.6.1-1.fc9.ppc requires libtcl8.4.so csound-tk - 5.03.0-13.fc7.ppc requires libtk8.4.so csound-tk - 5.03.0-13.fc7.ppc requires libtcl8.4.so d4x - 2.5.7.1-3.fc7.ppc requires libssl.so.6 d4x - 2.5.7.1-3.fc7.ppc requires libcrypto.so.6 ds9 - 5.0-6.fc9.ppc requires libtk8.4.so ds9 - 5.0-6.fc9.ppc requires libtcl8.4.so eggdrop - 1.6.18-12.fc9.ppc requires libtcl8.4.so environment-modules - 3.2.6-1.fc9.ppc requires libtcl8.4.so epiphany-extensions - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires libgtkembedmoz.so expect - 5.43.0-9.fc8.ppc64 requires libtcl8.4.so()(64bit) expect - 5.43.0-9.fc8.ppc requires libtcl8.4.so expectk - 5.43.0-9.fc8.ppc requires libtk8.4.so expectk - 5.43.0-9.fc8.ppc requires libtcl8.4.so funtools-libs - 1.4.0-4.fc9.ppc requires libtcl8.4.so funtools-libs - 1.4.0-4.fc9.ppc64 requires libtcl8.4.so()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libdapclient.so.1()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libdap.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libdapserver.so.3()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc requires libdapserver.so.3 gdal - 1.4.2-3.fc8.ppc requires libssl.so.6 gdal - 1.4.2-3.fc8.ppc requires libcrypto.so.6 gdal - 1.4.2-3.fc8.ppc requires libdapclient.so.1 gdal - 1.4.2-3.fc8.ppc requires libdap.so.6 gnome-web-photo - 0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.ppc requires libgtkembedmoz.so gnu-smalltalk - 2.3.6-7.fc9.ppc requires libtcl8.4.so gnu-smalltalk - 2.3.6-7.fc9.ppc requires libtk8.4.so gparted - 0.3.3-14.fc9.ppc requires libparted-1.8.so.6 grads - 1.9b4-21.fc8.ppc requires libdap.so.6 graphviz-tcl - 2.14.1-3.fc8.ppc requires libtk8.4.so grass - 6.2.2-2.fc8.ppc requires libcrypto.so.6 grass - 6.2.2-2.fc8.ppc requires libtk8.4.so grass - 6.2.2-2.fc8.ppc requires libtcl8.4.so grass - 6.2.2-2.fc8.ppc requires libssl.so.6 hamlib-tcl - 1.2.6.2-5.fc9.ppc requires libtcl8.4.so hfsutils - 3.2.6-11.fc8.ppc requires libtcl8.4.so hfsutils-x11 - 3.2.6-11.fc8.ppc requires libtcl8.4.so hfsutils-x11 - 3.2.6-11.fc8.ppc requires libtk8.4.so hping3 - 0.0.20051105-7.fc7.ppc requires libtcl8.4.so irsim - 9.7.50-1.fc8.ppc requires libtcl8.4.so irsim - 9.7.50-1.fc8.ppc requires libtk8.4.so isdn4k-utils-vboxgetty - 3.2-55.fc8.ppc requires libtcl8.4.so kannel - 1.4.1-5.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 libopensync-plugin-sunbird - 0.22-3.fc7.ppc requires libneon.so.25 libopensync-plugin-sunbird - 0.22-3.fc7.ppc requires libopensync.so.0 libopensync-plugin-sunbird - 0.22-3.fc7.ppc requires libssl.so.6 libopensync-plugin-sunbird - 0.22-3.fc7.ppc requires libcrypto.so.6 libopensync-plugin-synce - 0.22-4.fc8.ppc requires libopensync.so.0 libpurple-tcl - 2.3.1-1.fc9.ppc requires libtk8.4.so libpurple-tcl - 2.3.1-1.fc9.ppc requires libtcl8.4.so liferea - 1.4.10-1.fc9.ppc requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc requires libgtkembedmoz.so magic - 7.4.35-6.fc8.ppc requires libtcl8.4.so magic - 7.4.35-6.fc8.ppc requires libtk8.4.so mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-perl - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libssl.so.6 mapserver-python - 4.10.3-2.fc8.ppc requires libcrypto.so.6 mkinitrd - 6.0.27-1.fc9.ppc requires libparted-1.8.so.6 monodevelop - 0.17-4.fc9.ppc requires boo multisync - 0.91.0-1.fc7.ppc requires libopensync.so.0 multisync - 0.91.0-1.fc7.ppc requires libosengine.so.0 multisync-gui - 0.91.0-1.fc7.ppc requires libopensync.so.0 multisync-gui - 0.91.0-1.fc7.ppc requires libosengine.so.0 nash - 6.0.27-1.fc9.ppc64 requires libparted-1.8.so.6()(64bit) nash - 6.0.27-1.fc9.ppc requires libparted-1.8.so.6 netgen - 1.3.7-13.fc9.ppc requires libtcl8.4.so netgen - 1.3.7-13.fc9.ppc requires libtk8.4.so ocaml-labltk - 3.10.0-7.fc8.ppc requires libtk8.4.so ocaml-labltk - 3.10.0-7.fc8.ppc requires libtcl8.4.so ogdi-tcl - 3.2.0-0.5.beta1.fc7.ppc requires libtcl8.4.so openmsx - 0.6.2-4.fc8.ppc requires libtcl8.4.so php-mapserver - 4.10.3-2.fc8.ppc requires libssl.so.6 php-mapserver - 4.10.3-2.fc8.ppc requires libcrypto.so.6 plplot - 5.8.0-5.fc9.ppc requires libtcl8.4.so plplot - 5.8.0-5.fc9.ppc requires libtk8.4.so plplot-tk - 5.8.0-5.fc9.ppc64 requires libtk8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.ppc64 requires libtcl8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.ppc requires libtk8.4.so plplot-tk - 5.8.0-5.fc9.ppc requires libtcl8.4.so postgresql-pltcl - 8.2.5-2.fc9.ppc requires libtcl8.4.so ppracer - 0.3.1-13.fc8.ppc requires libtcl8.4.so pvm-gui - 3.4.5-7.fc6.1.ppc requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.ppc requires libtcl8.4.so python-gammu - 0.22-3.fc8.ppc requires libGammu.so.2 python-imaging-tk - 1.1.6-4.fc8.ppc requires libtk8.4.so python-imaging-tk - 1.1.6-4.fc8.ppc requires libtcl8.4.so python-matplotlib-tk - 0.90.1-2.fc8.ppc requires libtk8.4.so python-matplotlib-tk - 0.90.1-2.fc8.ppc requires libtcl8.4.so q - 7.10-1.fc9.ppc requires libtcl8.4.so q - 7.10-1.fc9.ppc requires libtk8.4.so q - 7.10-1.fc9.ppc64 requires libtcl8.4.so()(64bit) q - 7.10-1.fc9.ppc64 requires libtk8.4.so()(64bit) qtparted - 0.4.5-15.fc8.ppc requires libparted-1.8.so.6 revisor-cobbler - 2.0.5-14.fc9.noarch requires koan revisor-cobbler - 2.0.5-14.fc9.noarch requires cobbler ruby-tcltk - 1.8.6.111-4.fc9.ppc requires libtk8.4.so ruby-tcltk - 1.8.6.111-4.fc9.ppc requires libtcl8.4.so skencil - 0.6.17-15.20070606svn.fc8.ppc requires libtk8.4.so skencil - 0.6.17-15.20070606svn.fc8.ppc requires libtcl8.4.so tbcload - 1.4-5.20061030cvs.fc8.ppc requires tcl(abi) = 0:8.4 tcl-brlapi - 0.5.0-1.fc8.ppc requires libtcl8.4.so tcl-tcldict - 8.5.2-2.fc8.ppc requires tcl(abi) = 0:8.4 tclchecker - 1.4-3.20061030cvs.fc8.noarch requires tcl(abi) = 0:8.4 tclcompiler - 1.5-3.20061030cvs.fc8.ppc requires tcl(abi) = 0:8.4 tcldebugger - 1.4-5.20061030cvs.fc8.noarch requires tcl(abi) = 0:8.4 tcldom - 3.1-10.fc7.ppc requires tcl(abi) = 0:8.4 tclhttpd - 3.5.1-15.fc8.ppc requires tcl(abi) = 0:8.4 tclpro - 1.5.0-10.20061030cvs.fc9.noarch requires tcl(abi) = 0:8.4 tk-tktreectrl - 2.2.3-2.fc8.ppc requires tcl(abi) = 0:8.4 tkimg - 1.3-0.6.20071018svn.fc9.ppc64 requires tcl(abi) = 0:8.4 tkimg - 1.3-0.6.20071018svn.fc9.ppc requires tcl(abi) = 0:8.4 tkinter - 2.5.1-18.fc9.ppc requires libtk8.4.so tkinter - 2.5.1-18.fc9.ppc requires libtcl8.4.so torque-client - 2.1.10-1.fc9.ppc requires libtk8.4.so torque-client - 2.1.10-1.fc9.ppc requires libtcl8.4.so torque-gui - 2.1.10-1.fc9.ppc requires libtk8.4.so torque-gui - 2.1.10-1.fc9.ppc requires libtcl8.4.so torque-gui - 2.1.10-1.fc9.ppc requires /usr/bin/wish8.4 uudeview - 0.5.20-13.ppc requires libtk8.4.so uudeview - 0.5.20-13.ppc requires libtcl8.4.so vkeybd - 0.1.17a-5.fc8.ppc requires libtk8.4.so vkeybd - 0.1.17a-5.fc8.ppc requires libtcl8.4.so vkeybd - 0.1.17a-5.fc8.ppc requires tk < 1:8.5 vtk - 5.0.3-20.fc8.ppc requires libtcl8.4.so vtk - 5.0.3-20.fc8.ppc requires libtk8.4.so vtk - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc requires libtk8.4.so vtk-python - 5.0.3-20.fc8.ppc requires libtcl8.4.so vtk-python - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc requires libtk8.4.so vtk-tcl - 5.0.3-20.fc8.ppc requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) xca - 0.6.4-1.fc8.ppc requires libcrypto.so.6 xchat-tcl - 1:2.8.4-9.fc9.ppc requires libtcl8.4.so xcircuit - 3.4.27-1.fc9.ppc requires libtk8.4.so xcircuit - 3.4.27-1.fc9.ppc requires libtcl8.4.so xpa-tcl - 2.1.8-3.fc9.ppc requires libtcl8.4.so xpa-tcl - 2.1.8-3.fc9.ppc64 requires libtcl8.4.so()(64bit) Broken deps for ppc64 ---------------------------------------------------------- 8Kingdoms - 1.1.0-2.fc9.ppc64 requires libtcl8.4.so()(64bit) R - 2.6.1-1.fc9.ppc64 requires libtk8.4.so()(64bit) R - 2.6.1-1.fc9.ppc64 requires libtcl8.4.so()(64bit) amsn - 0.97-1.fc9.ppc64 requires tcl(abi) = 0:8.4 bacula-client - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bwidget - 1.8.0-2.fc8.noarch requires tcl(abi) = 0:8.4 climm - 0.6.1-1.fc9.ppc64 requires libtcl8.4.so()(64bit) csound-tk - 5.03.0-13.fc7.ppc64 requires libtk8.4.so()(64bit) csound-tk - 5.03.0-13.fc7.ppc64 requires libtcl8.4.so()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libssl.so.6()(64bit) ds9 - 5.0-6.fc9.ppc64 requires libtk8.4.so()(64bit) ds9 - 5.0-6.fc9.ppc64 requires libtcl8.4.so()(64bit) eggdrop - 1.6.18-12.fc9.ppc64 requires libtcl8.4.so()(64bit) environment-modules - 3.2.6-1.fc9.ppc64 requires libtcl8.4.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) expect - 5.43.0-9.fc8.ppc64 requires libtcl8.4.so()(64bit) expectk - 5.43.0-9.fc8.ppc64 requires libtk8.4.so()(64bit) expectk - 5.43.0-9.fc8.ppc64 requires libtcl8.4.so()(64bit) funtools-libs - 1.4.0-4.fc9.ppc64 requires libtcl8.4.so()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libcrypto.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libdapclient.so.1()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libdap.so.6()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libdapserver.so.3()(64bit) gdal - 1.4.2-3.fc8.ppc64 requires libssl.so.6()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) gparted - 0.3.3-14.fc9.ppc64 requires libparted-1.8.so.6()(64bit) grads - 1.9b4-21.fc8.ppc64 requires libdap.so.6()(64bit) graphviz-tcl - 2.14.1-3.fc8.ppc64 requires libtk8.4.so()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libcrypto.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libssl.so.6()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libtk8.4.so()(64bit) grass - 6.2.2-2.fc8.ppc64 requires libtcl8.4.so()(64bit) hamlib-tcl - 1.2.6.2-5.fc9.ppc64 requires libtcl8.4.so()(64bit) hfsutils - 3.2.6-11.fc8.ppc64 requires libtcl8.4.so()(64bit) hfsutils-x11 - 3.2.6-11.fc8.ppc64 requires libtk8.4.so()(64bit) hfsutils-x11 - 3.2.6-11.fc8.ppc64 requires libtcl8.4.so()(64bit) hping3 - 0.0.20051105-7.fc7.ppc64 requires libtcl8.4.so()(64bit) isdn4k-utils-vboxgetty - 3.2-55.fc8.ppc64 requires libtcl8.4.so()(64bit) kazehakase - 0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 libopensync-plugin-sunbird - 0.22-3.fc7.ppc64 requires libssl.so.6()(64bit) libopensync-plugin-sunbird - 0.22-3.fc7.ppc64 requires libneon.so.25()(64bit) libopensync-plugin-sunbird - 0.22-3.fc7.ppc64 requires libcrypto.so.6()(64bit) libopensync-plugin-sunbird - 0.22-3.fc7.ppc64 requires libopensync.so.0()(64bit) libopensync-plugin-synce - 0.22-4.fc8.ppc64 requires libopensync.so.0()(64bit) libpurple-tcl - 2.3.1-1.fc9.ppc64 requires libtk8.4.so()(64bit) libpurple-tcl - 2.3.1-1.fc9.ppc64 requires libtcl8.4.so()(64bit) liferea - 1.4.10-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc64 requires libgtkembedmoz.so()(64bit) magic - 7.4.35-6.fc8.ppc64 requires libtcl8.4.so()(64bit) magic - 7.4.35-6.fc8.ppc64 requires libtk8.4.so()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-perl - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) mapserver-python - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) mkinitrd - 6.0.27-1.fc9.ppc64 requires libparted-1.8.so.6()(64bit) nash - 6.0.27-1.fc9.ppc64 requires libparted-1.8.so.6()(64bit) netgen - 1.3.7-13.fc9.ppc64 requires libtcl8.4.so()(64bit) netgen - 1.3.7-13.fc9.ppc64 requires libtk8.4.so()(64bit) ogdi-tcl - 3.2.0-0.5.beta1.fc7.ppc64 requires libtcl8.4.so()(64bit) openmsx - 0.6.2-4.fc8.ppc64 requires libtcl8.4.so()(64bit) perl-Test-AutoBuild-darcs - 1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 php-mapserver - 4.10.3-2.fc8.ppc64 requires libcrypto.so.6()(64bit) php-mapserver - 4.10.3-2.fc8.ppc64 requires libssl.so.6()(64bit) plplot - 5.8.0-5.fc9.ppc64 requires libtk8.4.so()(64bit) plplot - 5.8.0-5.fc9.ppc64 requires libtcl8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.ppc64 requires libtk8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.ppc64 requires libtcl8.4.so()(64bit) postgresql-pltcl - 8.2.5-2.fc9.ppc64 requires libtcl8.4.so()(64bit) ppracer - 0.3.1-13.fc8.ppc64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ppc64 requires libtk8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ppc64 requires libtcl8.4.so()(64bit) python-gammu - 0.22-3.fc8.ppc64 requires libGammu.so.2()(64bit) python-imaging-tk - 1.1.6-4.fc8.ppc64 requires libtk8.4.so()(64bit) python-imaging-tk - 1.1.6-4.fc8.ppc64 requires libtcl8.4.so()(64bit) python-matplotlib-tk - 0.90.1-2.fc8.ppc64 requires libtcl8.4.so()(64bit) python-matplotlib-tk - 0.90.1-2.fc8.ppc64 requires libtk8.4.so()(64bit) q - 7.10-1.fc9.ppc64 requires libtcl8.4.so()(64bit) q - 7.10-1.fc9.ppc64 requires libtk8.4.so()(64bit) qtparted - 0.4.5-15.fc8.ppc64 requires libparted-1.8.so.6()(64bit) revisor-cobbler - 2.0.5-14.fc9.noarch requires koan ruby-tcltk - 1.8.6.111-4.fc9.ppc64 requires libtk8.4.so()(64bit) ruby-tcltk - 1.8.6.111-4.fc9.ppc64 requires libtcl8.4.so()(64bit) skencil - 0.6.17-15.20070606svn.fc8.ppc64 requires libtcl8.4.so()(64bit) skencil - 0.6.17-15.20070606svn.fc8.ppc64 requires libtk8.4.so()(64bit) tbcload - 1.4-5.20061030cvs.fc8.ppc64 requires tcl(abi) = 0:8.4 tcl-brlapi - 0.5.0-1.fc8.ppc64 requires libtcl8.4.so()(64bit) tcl-tcldict - 8.5.2-2.fc8.ppc64 requires tcl(abi) = 0:8.4 tclchecker - 1.4-3.20061030cvs.fc8.noarch requires tcl(abi) = 0:8.4 tclcompiler - 1.5-3.20061030cvs.fc8.ppc64 requires tcl(abi) = 0:8.4 tcldebugger - 1.4-5.20061030cvs.fc8.noarch requires tcl(abi) = 0:8.4 tcldom - 3.1-10.fc7.ppc64 requires tcl(abi) = 0:8.4 tclhttpd - 3.5.1-15.fc8.ppc64 requires tcl(abi) = 0:8.4 tclpro - 1.5.0-10.20061030cvs.fc9.noarch requires tcl(abi) = 0:8.4 tk-tktreectrl - 2.2.3-2.fc8.ppc64 requires tcl(abi) = 0:8.4 tkimg - 1.3-0.6.20071018svn.fc9.ppc64 requires tcl(abi) = 0:8.4 tkinter - 2.5.1-18.fc9.ppc64 requires libtk8.4.so()(64bit) tkinter - 2.5.1-18.fc9.ppc64 requires libtcl8.4.so()(64bit) torque-client - 2.1.10-1.fc9.ppc64 requires libtk8.4.so()(64bit) torque-client - 2.1.10-1.fc9.ppc64 requires libtcl8.4.so()(64bit) torque-gui - 2.1.10-1.fc9.ppc64 requires libtk8.4.so()(64bit) torque-gui - 2.1.10-1.fc9.ppc64 requires /usr/bin/wish8.4 torque-gui - 2.1.10-1.fc9.ppc64 requires libtcl8.4.so()(64bit) uudeview - 0.5.20-13.ppc64 requires libtk8.4.so()(64bit) uudeview - 0.5.20-13.ppc64 requires libtcl8.4.so()(64bit) vkeybd - 0.1.17a-5.fc8.ppc64 requires tk < 1:8.5 vkeybd - 0.1.17a-5.fc8.ppc64 requires libtk8.4.so()(64bit) vkeybd - 0.1.17a-5.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) xchat-tcl - 1:2.8.4-9.fc9.ppc64 requires libtcl8.4.so()(64bit) xcircuit - 3.4.27-1.fc9.ppc64 requires libtk8.4.so()(64bit) xcircuit - 3.4.27-1.fc9.ppc64 requires libtcl8.4.so()(64bit) xpa-tcl - 2.1.8-3.fc9.ppc64 requires libtcl8.4.so()(64bit) From jakub at redhat.com Thu Jan 3 13:01:38 2008 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 3 Jan 2008 08:01:38 -0500 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <477CD6B0.7090203@gmail.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <477CD6B0.7090203@gmail.com> Message-ID: <20080103130138.GB20451@devserv.devel.redhat.com> On Thu, Jan 03, 2008 at 01:36:00PM +0100, drago01 wrote: > Two of my packages are in this category: > http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/unsorted/compiz-fusion-0.6.0-7.fc9.log > and > http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/unsorted/compiz-fusion-extras-0.6.0-1.fc9.log > both fail with > "checking how to run the C++ preprocessor... /lib/cpp > > configure: error: C++ preprocessor "/lib/cpp" fails sanity check > See `config.log' for more details." configure:6351: checking whether g++ accepts -g configure:6381: g++ -c -g conftest.cpp >&5 conftest.cpp:9:1: error: "VERSION" redefined conftest.cpp:7:1: error: this is the location of the previous definition configure:6387: $? = 1 configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "compiz-fusion-plugins-main" | #define PACKAGE_TARNAME "compiz-fusion-plugins-main" | #define PACKAGE_VERSION "0.6.0" | #define PACKAGE_STRING "compiz-fusion-plugins-main 0.6.0" | #define PACKAGE_BUGREPORT "maniac at opencompositing.org" | #define VERSION "" | #define PACKAGE "compiz-fusion-plugins-main" | #define VERSION "0.6.0" | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_DLFCN_H 1 | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:6419: g++ -c conftest.cpp >&5 conftest.cpp:9:1: error: "VERSION" redefined conftest.cpp:7:1: error: this is the location of the previous definition etc. In C and with g++ <= 4.2 also C++ this yielded just warnings, which configure ignored. Now in C++ it is a hard error unless -fpermissive. Better fix the configury not to define VERSION twice. The same for the other package. Jakub From jwboyer at gmail.com Thu Jan 3 13:11:33 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 3 Jan 2008 07:11:33 -0600 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080103120242.GZ20451@devserv.devel.redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> Message-ID: <20080103071133.1952dece@hansolo.jdub.homelinux.org> On Thu, 3 Jan 2008 07:02:42 -0500 Jakub Jelinek wrote: > fails-even-with-41/powerpc-utils-1.0.6-2.fc9.log > fails-even-with-41/powerpc-utils-papr-1.0.4-2.fc9.log > fails-even-with-41/ppc64-utils-0.14-1.fc9.log > fails-even-with-41/ps3pf-utils-2.1-1.fc9.log These seem like bogus results. Looking at the logs, you might have hit some mock/builder problems that were being seen a while ago. I wonder how many other packages are in the same category. josh From jakub at redhat.com Thu Jan 3 13:23:48 2008 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 3 Jan 2008 08:23:48 -0500 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080103123725.GA20451@devserv.devel.redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <20080103123725.GA20451@devserv.devel.redhat.com> Message-ID: <20080103132348.GC20451@devserv.devel.redhat.com> On Thu, Jan 03, 2008 at 07:37:25AM -0500, Jakub Jelinek wrote: > On Thu, Jan 03, 2008 at 07:02:42AM -0500, Jakub Jelinek wrote: > > 3 http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/auto_ptr/ > > std::auto_ptr is no longer in , I belive unique_ptr > > should be used instead, or there is . > > Benjamin can tell more. > > Small correction here, std::auto_ptr is still in in -std=c++98 > mode, it has been deprecated just in -std=c++0x mode from what I see. > So the above 3 failures are something else, perhaps some header which > unintentionally included no longer does or something. Yes, e.g. included indirectly and no longer does, similarly no longer includes , nor . >From the above failures, two of them include but not , one includes but not . So all these 3 fall into header-dep category... Jakub From jakub at redhat.com Thu Jan 3 13:30:14 2008 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 3 Jan 2008 08:30:14 -0500 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080103071133.1952dece@hansolo.jdub.homelinux.org> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <20080103071133.1952dece@hansolo.jdub.homelinux.org> Message-ID: <20080103133014.GD20451@devserv.devel.redhat.com> On Thu, Jan 03, 2008 at 07:11:33AM -0600, Josh Boyer wrote: > On Thu, 3 Jan 2008 07:02:42 -0500 > Jakub Jelinek wrote: > > > > fails-even-with-41/powerpc-utils-1.0.6-2.fc9.log error: Architecture is not included: x86_64 > > fails-even-with-41/powerpc-utils-papr-1.0.4-2.fc9.log DEBUG util.py:260: No Package Found for librtas-devel (but has ExclusiveArch: ppc ppc64 anyway, so even if librtas-devel was included, it would fail to build anyway). > > fails-even-with-41/ppc64-utils-0.14-1.fc9.log error: Architecture is not included: x86_64 > > fails-even-with-41/ps3pf-utils-2.1-1.fc9.log error: Architecture is not included: x86_64 > These seem like bogus results. Looking at the logs, you might have hit > some mock/builder problems that were being seen a while ago. I said that fails-even-with-41 includes even ExcludeArched packages and that the build was on x86_64. As for me fails-even-with-41 category is DONTCARE, I haven't spent time to categorize them further. Jakub From fedora at camperquake.de Thu Jan 3 13:29:56 2008 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 3 Jan 2008 14:29:56 +0100 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080103120242.GZ20451@devserv.devel.redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> Message-ID: <20080103142956.0ad46f22@dhcp03.addix.net> Hi. On Thu, 3 Jan 2008 07:02:42 -0500, Jakub Jelinek wrote: > The remaining 507 failures only fail with gcc-4.3.0-0.4 and not with > gcc-4.1.2-36, though most of them are just C++ being stricter, > something that ought to be fixed in the packages. How do I test if a fix for a problem outlined below works? Is that possible without installing 4.3 (which I'd rather avoid)? From fedora at leemhuis.info Thu Jan 3 13:42:05 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 03 Jan 2008 14:42:05 +0100 Subject: list of failed packages with owners (was: Re: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220) In-Reply-To: <20080103120242.GZ20451@devserv.devel.redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> Message-ID: <477CE62D.7020208@leemhuis.info> On 03.01.2008 13:02, Jakub Jelinek wrote: > I've rebuilt 5118 rawhide-20071220 src.rpms on x86_64 in mock buildroots which > contained rawhide-20071220 except {gcc,lib}*-4.1.2-36.*.rpm, with additional > gcc-4.3.0-0.4 (available from koji, dist-f9-gcc43 component), > compat-libgfortran-41 (available from > http://people.redhat.com/jakub/gcc/compat-libgfortran-41-4.1.2-36.src.rpm ) > and later on also with gettext subpackages just rebuilt with gcc-4.3.0-0.4. > [...] FYI, below the list with owner information in front of it and sorted by owners: abompard changesmeaning/agave-0.4.2-5.fc8.log abompard fails-even-with-41/gwenview-1.4.2-1.fc9.log abompard fails-even-with-41/HelixPlayer-1.0.9-1.fc8.log abompard fails-even-with-41/ksshaskpass-0.3-3.fc8.log abompard fails-even-with-41/libkexif-0.2.5-2.fc8.log abompard fails-even-with-41/libkipi-0.1.5-2.fc8.log abompard fails-even-with-41/python-dialog-2.7-7.fc8.log abompard fails-even-with-41/showimg-0.9.5-13.fc8.log abompard header-dep/amarok-1.4.7-14.fc9.log abompard header-dep/basket-1.0.2-3.fc9.log abompard header-dep/glest-2.0.1-5.fc9.log abompard header-dep/keepassx-0.2.2-4.fc8.log abompard unsorted/blobby-0.6-0.7.a.fc8.log aconway fails-even-with-41/qpidc-0.2-5.fc7.log aconway fails-even-with-41/rhm-0.1-3.fc7.log adalloz fails-even-with-41/mbuffer-20070502-1.fc7.log adalloz fails-even-with-41/pam_abl-0.2.3-3.fc7.log adalloz header-dep/pan-0.132-2.fc8.log addutko header-dep/astyle-1.21-6.fc8.log adrian fails-even-with-41/kover-3-2.log adrian header-dep/libcdio-0.78.2-3.fc8.log adrian unsorted/source-highlight-2.8-1.fc9.log afb header-dep/slim-1.3.0-1.fc8.log agoode header-dep/escape-200704130-7.fc9.log agoode multipledef/vips-7.12.5-3.fc9.log ajax fails-even-with-41/gstreamer-plugins-good-0.10.6-6.fc8.log ajax fails-even-with-41/pyxf86config-0.3.34-1.fc8.log akahl changesmeaning/bmpx-0.40.13-6.fc9.log akahl fails-even-with-41/libzzub-0.2.3-10.fc9.log alexl multipledef/gnome-vfs2-2.20.1-4.fc9.log allisson fails-even-with-41/ruby-gnome2-0.16.0-19.fc9.log allisson header-dep/multiget-1.1.4-7.fc8.log anaconda-maint Werror/anaconda-11.4.0.11-1.log anderson fails-even-with-41/bibletime-1.6.5-1.fc9.log anderson fails-even-with-41/kio_sword-0.3-4.fc9.log andriy fails-even-with-41/python-alsa-1.0.15-1.fc8.log andriy header-dep/klamav-0.41.1-7.fc9.log andyp fails-even-with-41/pybackpack-0.5.1-2.fc8.log athimm fails-even-with-41/smart-0.52-52.fc9.log athimm fails-even-with-41/vtk-5.0.3-20.fc8.log athimm header-dep/apt-0.5.15lorg3.93-4.fc9.log athimm header-dep/nx-2.1.0-22.fc7.log athimm header-dep/synaptic-0.57.2-14.fc9.log atkac fails-even-with-41/vnc-4.1.2-23.fc9.log ausil fails-even-with-41/kmobiletools-0.4.3.3-3.fc6.log ausil fails-even-with-41/konversation-1.0.1-3.fc8.log ausil fails-even-with-41/kpowersave-0.7.3-1.fc9.log ausil fails-even-with-41/krecipes-0.9.1-6.fc8.log ausil fails-even-with-41/oooqs2-1.0-3.fc6.log ausil unsorted/mysql-gui-tools-5.0r12-5.fc9.log awjb fails-even-with-41/airsnort-0.2.7e-11.fc7.log awjb fails-even-with-41/atitvout-0.4-7.log awjb fails-even-with-41/kcemirror-0.1.5-1.fc7.log awjb fails-even-with-41/koffice-langpack-1.6.3-1.fc8.log awjb fails-even-with-41/synce-kde-0.9.1-1.fc7.log awjb fails-even-with-41/wine-0.9.49-2.fc9.log awjb fails-even-with-41/wine-docs-0.9.49-1.fc9.log awjb header-dep/dosbox-0.72-1.fc8.log awjb header-dep/fbdesk-1.4.0-3.fc8.log awjb header-dep/fluxbox-1.0.0-1.fc8.log awjb header-dep/libpqxx-2.6.8-7.fc8.log awjb header-dep/vdccm-0.9.3-1.fc7.log awjb header-dep/wv2-0.2.3-3.fc8.log awjb redefined/koffice-1.6.3-12.fc8.log awjb redefined/rxvt-unicode-8.8-1.fc9.log bagnara header-dep/ppl-0.9-16.fc8.log bbbush redefined/chmsee-1.0.0-1.34.fc9.log belegdol header-dep/gchempaint-0.8.4-1.fc9.log belegdol header-dep/gnome-chemistry-utils-0.8.4-2.fc9.log belegdol header-dep/museek+-0.1.13-1.fc8.log bellet header-dep/fgfs-Atlas-0.3.1-5.fc8.log bellet header-dep/FlightGear-0.9.11-0.4.pre1.fc8.log berrange fails-even-with-41/python-virtinst-0.300.1-3.fc8.log berrange multipledef/gtk-vnc-0.3.1-1.fc9.log bjohnson header-dep/pdfedit-0.3.2-2.fc8.log bjohnson multipledef/pygoocanvas-0.9.0-2.fc8.log bjohnson unsorted/dbmail-2.2.7-2.fc9.log bos fails-even-with-41/alex-2.1.0-5.fc8.log bos fails-even-with-41/happy-1.16-2.fc7.log bpepple fails-even-with-41/evolution-brutus-1.1.28.7-2.fc8.log bpepple fails-even-with-41/liferea-1.4.10-1.fc9.log bpepple fails-even-with-41/python-reportlab-2.1-1.fc8.log bpepple fails-even-with-41/python-telepathy-0.14.0-4.fc9.log bpepple header-dep/farsight-0.1.25-1.fc8.log bpepple header-dep/libjingle-0.3.11-5.fc9.log bpepple multipledef/gstreamer-plugins-farsight-0.12.5-1.fc8.log bpepple multipledef/libtelepathy-0.3.1-2.fc9.log bpepple multipledef/swfdec-0.5.5-2.fc9.log bpepple multipledef/telepathy-gabble-0.6.1-1.fc9.log bpepple multipledef/telepathy-glib-0.7.0-1.fc9.log bpepple multipledef/telepathy-idle-0.1.2-2.fc9.log bpepple multipledef/telepathy-salut-0.2.0-1.fc9.log bpepple multipledef/telepathy-stream-engine-0.3.25-2.fc8.log bpepple multipledef/xchat-gnome-0.18-7.fc9.log bpepple unsorted/brutus-keyring-0.9.0-6.fc8.log bpepple unsorted/wesnoth-1.2.8-3.fc9.log bpostle header-dep/hugin-0.6.1-11.fc9.log bpostle unsorted/enblend-3.0-6.fc8.log braden header-dep/openvrml-0.17.0-2.fc9.log buc header-dep/newscache-1.2-0.4.rc6.fc6.log c4chris header-dep/glimmer-3.02-2.fc8.log c4chris header-dep/lagan-2.0-1.fc8.log cagney rootlog/frysk-0.0.1.2007.10.17-1.fc8.log caillon fails-even-with-41/epiphany-extensions-2.20.1-3.fc9.log caolanm header-dep/openoffice.org-2.3.1-9.9.fc9.log cbalint fails-even-with-41/gdal-1.4.2-3.fc8.log cbalint fails-even-with-41/grass-6.2.2-2.fc8.log cbalint fails-even-with-41/iverilog-0.9.20070608-1.fc8.log cbalint fails-even-with-41/mapserver-4.10.3-2.fc8.log cchance fails-even-with-41/libchewing-0.3.0-8.fc8.log cchance header-dep/scim-chewing-0.3.1-9.fc7.log cchance header-dep/scim-tables-0.5.7-3.fc7.log chabotc changesmeaning/libtorrent-0.11.8-2.fc9.log chabotc changesmeaning/rtorrent-0.7.8-1.fc8.log chitlesh fails-even-with-41/alliance-5.0-10.20070718snap.fc8.log chitlesh fails-even-with-41/crystal-1.0.5-1.fc8.log chitlesh fails-even-with-41/d3lphin-0.9.2-2.fc8.log chitlesh fails-even-with-41/gresistor-0.0.1-11.fc8.log chitlesh fails-even-with-41/kalgebra-0.5-4.fc8.log chitlesh fails-even-with-41/katapult-0.3.2.1-2.fc8.log chitlesh fails-even-with-41/kdirstat-2.5.3-6.fc8.log chitlesh fails-even-with-41/kdmtheme-1.2.1-1.fc9.log chitlesh fails-even-with-41/keurocalc-0.9.7-3.fc8.log chitlesh fails-even-with-41/kio_resources-0.2-3.fc8.log chitlesh fails-even-with-41/kleansweep-0.2.9-5.fc8.log chitlesh fails-even-with-41/knetstats-1.6.1-4.fc8.log chitlesh fails-even-with-41/kpolynome-0.1.2-10.fc8.log chitlesh fails-even-with-41/kshutdown-1.0.1-1.fc8.log chitlesh fails-even-with-41/ktechlab-0.3.69-5.fc8.log chitlesh fails-even-with-41/LabPlot-1.5.1.6-4.fc8.log chitlesh fails-even-with-41/piklab-0.15.0-1.fc9.log chitlesh header-dep/gds2pov-0.20070815-1.fc8.log clumens fails-even-with-41/elilo-3.6-2.log corsepiu fails-even-with-41/perl-Perl-MinimumVersion-0.15-1.fc9.log corsepiu header-dep/OpenSceneGraph-2.2.0-3.fc9.log corsepiu main/Inventor-2.1.5-30.fc9.1.log cr33dog fails-even-with-41/fontypython-0.2.0-6.fc7.log cweyl fails-even-with-41/perl-CGI-Ajax-0.701-2.fc7.log cweyl fails-even-with-41/perl-Class-Factory-Util-1.7-1.fc7.log cweyl fails-even-with-41/perl-DateTime-Format-MySQL-0.04-4.fc6.log cweyl fails-even-with-41/perl-MooseX-Getopt-0.05-1.fc8.log cweyl fails-even-with-41/perl-Net-CUPS-0.51-2.fc7.log cweyl fails-even-with-41/perl-Net-XMPP-1.02-2.fc7.log cweyl fails-even-with-41/perl-Perl-Critic-1.053-1.fc8.log cweyl fails-even-with-41/perl-POE-API-Peek-1.0802-1.fc7.log cweyl fails-even-with-41/perl-POE-Component-Child-1.39-2.fc6.log cweyl fails-even-with-41/perl-POE-Component-Client-LDAP-0.04-3.fc6.log cweyl fails-even-with-41/perl-POE-Component-Server-HTTP-0.09-3.fc6.log cweyl fails-even-with-41/perl-POE-Component-Server-SOAP-1.11-1.fc8.log cweyl fails-even-with-41/perl-POE-Component-SimpleLog-1.04-1.fc6.log cweyl fails-even-with-41/perl-POE-Component-SNMP-1.07-1.fc6.log cweyl fails-even-with-41/perl-POE-Wheel-Null-0.01-2.fc6.log cweyl fails-even-with-41/perl-RRD-Simple-1.43-1.fc7.log cweyl fails-even-with-41/perl-SUPER-1.16-1.fc7.log cweyl header-dep/eiciel-0.9.5-1.fc9.log cwickert changesmeaning/regexxer-0.9-2.fc8.log cwickert fails-even-with-41/gwget-0.99-3.fc8.log cwickert fails-even-with-41/xfce4-battery-plugin-0.5.0-2.fc7.log danken fails-even-with-41/hunspell-ar-0.20060208-1.fc8.log danms Werror/libcmpiutil-0.1-6.fc9.log davidz fails-even-with-41/gnome-device-manager-0.2-2.fc9.log davidz header-dep/dasher-4.7.0-1.fc9.log davidz header-dep/hal-0.5.10-3.fc9.log davidz unsorted/festival-1.96-2.fc9.log dbhole header-dep/antlr-2.7.7-1jpp.6.fc8.log dcantrel fails-even-with-41/gpart-0.1h-8.fc9.log dcantrel fails-even-with-41/iprutils-2.2.8-1.fc9.log dcantrel fails-even-with-41/librtas-1.3.3-2.fc9.log dcantrel fails-even-with-41/ppc64-utils-0.14-1.fc9.log dcantrel fails-even-with-41/repoman-0.9-3.fc8.log dcantrel fails-even-with-41/yaboot-1.3.13-8.fc9.log dcantrel Werror/dhcp-3.1.0-12.fc9.log dcantrel Werror/parted-1.8.6-13.fc9.log dcbw fails-even-with-41/csound-5.03.0-13.fc7.log dcbw fails-even-with-41/plague-0.4.4.1-4.fc7.log dcbw header-dep/wpa_supplicant-0.5.7-18.fc9.log dcbw Werror/NetworkManager-0.7.0-0.8.svn3181.fc9.log dchen header-dep/scim-array-0.0.2-2.fc9.log deji changesmeaning/gparted-0.3.3-14.fc9.log deji fails-even-with-41/flagpoll-0.9.1-1.fc8.log deji fails-even-with-41/galternatives-0.13.4-4.fc7.log deji fails-even-with-41/gnome-scan-0.5.3-0.1.20071030svn.fc9.log deji fails-even-with-41/gnomesword-2.3.1-3.fc9.log deji fails-even-with-41/qalculate-kde-0.9.6-2.fc8.log deji header-dep/exempi-1.99.5-1.fc9.log deji header-dep/libqalculate-0.9.6-2.fc8.log deji header-dep/referencer-1.0.4-5.fc8.log deji header-dep/strigi-0.5.7-2.fc9.log deji header-dep/sword-1.5.10-1.fc9.log denis changesmeaning/bakery-2.4.2-1.fc9.log denis changesmeaning/gconfmm26-2.20.0-1.fc8.log denis changesmeaning/glom-1.6.4-1.fc9.log denis changesmeaning/gnome-vfsmm26-2.20.0-1.fc8.log denis changesmeaning/goocanvasmm-0.4.0-2.fc9.log denis changesmeaning/gtkmm24-2.12.3-1.fc9.log denis changesmeaning/libglademm24-2.6.4-1.fc8.log denis changesmeaning/libgnomecanvasmm26-2.20.0-1.fc8.log denis changesmeaning/libgnomedbmm-2.9.5-2.fc9.log denis changesmeaning/libgnomemm26-2.20.0-1.log denis changesmeaning/libpanelappletmm-2.6.0-2.fc8.log denis changesmeaning/libsigc++20-2.0.18-1.log denis changesmeaning/wp_tray-0.5.3-6.fc9.log denis header-dep/gcdmaster-1.2.2-2.fc8.log denis header-dep/gimmage-0.2.3-1.fc8.log denis header-dep/glibmm24-2.14.2-1.fc9.log denis header-dep/inkscape-0.45.1-5.fc9.log denis header-dep/k3d-0.6.7.0-4.fc8.log denis header-dep/libgnomeuimm26-2.20.0-1.fc8.log denis header-dep/pstoedit-3.45-1.fc8.log denis unsorted/galeon-2.0.3-17.fc9.log devrim fails-even-with-41/python-psycopg2-2.0.6-2.fc8.log dgoodwin fails-even-with-41/testoob-1.13-4.fc8.log dgoodwin fails-even-with-41/wuja-0.0.8-2.fc8.log dionysos fails-even-with-41/kbackup-0.5.2-1.fc8.log dionysos fails-even-with-41/pikdev-0.9.2-3.fc8.log dionysos fails-even-with-41/pikloops-0.2.5-1.fc9.log dionysos header-dep/gpsim-0.22.0-5.fc8.log dledford unsorted/lam-7.1.2-10.fc7.log drago01 changesmeaning/pinot-0.81-2.fc9.log drago01 header-dep/linkage-0.1.4-4.fc8.log drago01 unsorted/compiz-fusion-0.6.0-7.fc9.log drago01 unsorted/compiz-fusion-extras-0.6.0-1.fc9.log dwalsh fails-even-with-41/selinux-doc-1.26-1.1.log dwmw2 fails-even-with-41/apmud-1.0.0-8.fc8.log dwmw2 fails-even-with-41/callweaver-1.2-0.3.rc4.20070822.log dwmw2 fails-even-with-41/powerpc-utils-1.0.6-2.fc9.log dwmw2 fails-even-with-41/powerpc-utils-papr-1.0.4-2.fc9.log dwmw2 fails-even-with-41/ps3pf-utils-2.1-1.fc9.log ecik fails-even-with-41/kooldock-0.4.6-2.fc8.log ecik fails-even-with-41/krename-3.0.14-2.fc8.log ecik fails-even-with-41/python-mutagen-1.12-1.fc8.log ecik header-dep/aria2-0.11.3-1.fc8.log edhill fails-even-with-41/netcdf-3.6.2-4.fc8.log edhill header-dep/itpp-4.0.0-2.fc9.log edhill header-dep/nco-3.9.1-1.fc8.log edhill unsorted/scrip-1.4-9.fc8.log eitch fails-even-with-41/metamonitor-0.4.5-3.fc6.log emoret header-dep/paprefs-0.9.6-1.fc9.log ensc fails-even-with-41/ip-sentinel-0.12-10.fc7.log ensc fails-even-with-41/xca-0.6.4-1.fc8.log ensc header-dep/libextractor-0.5.18a-1.fc8.log ensc header-dep/mimetic-0.9.3-2.fc8.log ensc header-dep/xmlrpc-c-1.06.18-1.fc8.log ensc redefined/kismet-0.0.2007.10.R1-2.fc9.log errr fails-even-with-41/fluxstyle-1.0.1-2.fc7.log errr fails-even-with-41/ruby-bdb-0.6.0-1.fc7.log errr header-dep/pekwm-0.1.5-5.fc7.log ertzing header-dep/audacious-plugins-1.4.2-1.fc9.log ertzing header-dep/fwbuilder-2.1.14-1.fc8.log ertzing header-dep/libfwbuilder-2.1.14-1.fc8.log ertzing header-dep/MyPasswordSafe-0.6.7-1.20061216.fc8.log faucamp fails-even-with-41/amarokFS-0.5-1.fc7.log faucamp fails-even-with-41/dekorator-0.3-3.fc7.log faucamp fails-even-with-41/kgtk-0.8-2.fc7.log faucamp fails-even-with-41/klibido-0.2.5-8.fc8.log faucamp fails-even-with-41/knemo-0.4.7-1.fc7.log faucamp unsorted/espeak-1.28-1.fc8.log fche header-dep/systemtap-0.6-1.fc9.log firewing fails-even-with-41/fwfstab-0.02-2.fc9.log firewing fails-even-with-41/gnofract4d-3.6-4.fc7.log firewing fails-even-with-41/lybniz-1.3.1-1.fc9.log firewing fails-even-with-41/PySolFC-1.1-4.fc9.log fnasser fails-even-with-41/mx4j-3.0.1-6jpp.4.log fnasser fails-even-with-41/xml-commons-resolver-1.1-1jpp.12.log fnasser ice/icu4j-3.6.1-1jpp.6.fc9.log frankb header-dep/muParser-1.28-2.fc8.log frankb header-dep/qtiplot-0.9-8.fc9.log gajownik fails-even-with-41/athcool-0.3.11-5.fc6.log gajownik fails-even-with-41/htop-0.6.5-1.fc7.log gajownik fails-even-with-41/python-sqlite2-2.3.3-1.fc7.log gajownik fails-even-with-41/yakuake-2.7.5-4.fc7.log gajownik unsorted/inotify-tools-3.11-1.fc8.log gajownik unsorted/qps-1.9.19-0.2.b.fc7.log gecko-maint fails-even-with-41/epiphany-2.21.4-1.fc9.log gecko-maint unsorted/seamonkey-1.1.7-3.fc9.log gecko-maint unsorted/thunderbird-2.0.0.9-2.fc9.log gecko-maint Werror/xulrunner-1.9-0.beta2.1.fc9.log gemi fails-even-with-41/gcl-2.6.7-15.fc8.log gemi fails-even-with-41/mosml-2.01-9.fc7.log gemi fails-even-with-41/oorexx-3.2.0-2.fc9.log gemi fails-even-with-41/pari-2.3.0-5.fc7.log gemi fails-even-with-41/q-7.8-1.fc9.log gemi fails-even-with-41/scons-0.97-2.fc8.log gemi fails-even-with-41/tclabc-1.0.9-1.fc7.log gemi fails-even-with-41/unison-2.13.16-3.fc6.log gemi fails-even-with-41/xaos-3.2.3-1.fc7.log gemi header-dep/audacity-1.3.2-17.fc9.log gemi header-dep/ecl-0.9i-3.fc6.log gemi header-dep/qcad-2.0.5.0-5.fc6.log gemi unsorted/smarteiffel-2.2-6.fc6.log ghenry fails-even-with-41/rdiff-backup-1.0.5-5.fc8.log giallu fails-even-with-41/buildbot-0.7.6-1.fc8.log gilboa header-dep/gmrun-0.9.2-10.fc8.log gilboa unsorted/kdebluetooth-1.0-0.39.beta8.fc9.log green header-dep/ardour-2.1-3.fc8.log green header-dep/dssi-0.9.1-11.fc8.log green header-dep/hydrogen-0.9.3-9.fc8.log green header-dep/libfreebob-1.0.3-1.fc7.log green header-dep/seq24-0.8.7-8.fc8.log hadess fails-even-with-41/gnome-media-2.20.1-7.fc9.log hadess fails-even-with-41/gnome-web-photo-0.3-8.fc9.log hadess fails-even-with-41/python-gdata-1.0.9-1.fc9.log hadess fails-even-with-41/rhythmbox-0.11.3-9.fc9.log hadess fails-even-with-41/totem-2.21.5-3.fc9.log hadess header-dep/libmusicbrainz-2.1.5-3.fc9.log hadess multipledef/gnome-vfs2-obexftp-0.4-5.fc9.log hamzy fails-even-with-41/sblim-cmpi-base-1.5.4-7.fc7.log hamzy header-dep/sblim-wbemcli-1.5.1-5.fc7.log harald header-dep/cdrdao-1.2.2-3.log hguemar changesmeaning/libsexymm-0.1.9-4.fc8.log hguemar changesmeaning/plotmm-0.1.2-5.fc6.log hguemar redefined/gtkmozembedmm-1.4.2.cvs20060817-17.fc9.log homeless header-dep/rudeconfig-5.0.5-1.fc7.log iburrell header-dep/jigdo-0.7.3-4.fc8.log icon fails-even-with-41/epylog-1.0.3-5.fc7.log icon fails-even-with-41/gazpacho-0.7.2-2.fc8.log icon fails-even-with-41/kdissert-1.0.7-1.fc7.log icon fails-even-with-41/pylint-0.13.1-1.fc7.log icon fails-even-with-41/python-kiwi-1.9.16-1.fc8.log icon fails-even-with-41/python-logilab-astng-0.17.0-1.fc7.log icon fails-even-with-41/python-logilab-common-0.21.2-1.fc7.log icon header-dep/verbiste-0.1.21-1.fc8.log icon unsorted/libxml++-2.20.0-1.fc8.log ifoox fails-even-with-41/ht2html-2.0-5.fc6.log ixs fails-even-with-41/bacula-2.0.3-11.fc8.log ixs fails-even-with-41/bitbake-1.8.8-1.fc8.log ixs fails-even-with-41/perl-CGI-Session-4.20-2.fc7.log ixs fails-even-with-41/perl-Class-Observable-1.04-2.fc7.log ixs fails-even-with-41/perl-Class-Std-0.0.8-1.fc7.log ixs fails-even-with-41/perl-Data-Password-1.07-1.fc7.log ixs fails-even-with-41/perl-Sys-SigAction-0.10-1.fc7.log ixs fails-even-with-41/perl-XML-Filter-BufferText-1.01-2.fc7.log ixs fails-even-with-41/perl-XML-SAX-Writer-0.50-2.fc7.log ixs fails-even-with-41/perl-XML-Validator-Schema-1.08-1.fc7.log ixs fails-even-with-41/pyzor-0.4.0-11.fc7.log ixs header-dep/ccrtp-1.5.1-1.fc7.log ixs header-dep/commoncpp2-1.5.0-1.fc7.log ixs header-dep/GraphicsMagick-1.1.8-3.fc8.log izhar fails-even-with-41/compizconfig-backend-kconfig-0.6.0-1.fc9.log izhar unsorted/compizconfig-backend-gconf-0.6.0-1.fc9.log izhar unsorted/libcompizconfig-0.6.0-3.fc9.log jafo fails-even-with-41/moto4lin-0.3-6.fc7.log jafo fails-even-with-41/python-memcached-1.39-1.fc8.log jafo fails-even-with-41/python-pydns-2.3.0-5.fc7.log jafo fails-even-with-41/python-pyspf-2.0.3-1.fc8.log jaile changesmeaning/gtkglextmm-1.2.0-5.fc6.log jakub fails-even-with-41/prelink-0.4.0-1.log jamatos fails-even-with-41/pygsl-0.9.1-6.fc8.log jamatos fails-even-with-41/pyparsing-1.4.7-1.fc8.log jamatos fails-even-with-41/PyRTF-0.45-5.fc8.log jamatos fails-even-with-41/python-cpio-0.1-4.fc8.log jamatos fails-even-with-41/python-imaging-1.1.6-4.fc8.log jamatos fails-even-with-41/PyX-0.9-5.fc8.log jamatos fails-even-with-41/R-waveslim-1.6-4.fc8.log james fails-even-with-41/python-4Suite-XML-1.0.2-1.log james fails-even-with-41/python-docs-2.5.1-1.fc8.log james fails-even-with-41/ustr-1.0.2-4.fc9.log james fails-even-with-41/zsh-4.3.4-5.fc9.log jcm fails-even-with-41/module-init-tools-3.4-2.fc8.log jcollie fails-even-with-41/bcfg2-0.9.5.2-1.fc9.log jcollie fails-even-with-41/python-musicbrainz2-0.5.0-1.fc9.log jcollie fails-even-with-41/python-pycurl-7.16.4-1.fc8.log jcollie fails-even-with-41/python-urljr-1.0.1-1.fc7.log jcollie fails-even-with-41/python-xmpp-0.4.0-2.fc7.log jcollie fails-even-with-41/trac-0.10.4-1.fc7.log jcollie fails-even-with-41/zaptel-1.4.6-1.fc9.log jcollie header-dep/jrtplib-3.7.1-2.fc8.log jcollie Werror/linphone-1.7.1-4.fc8.log jima header-dep/graphviz-2.14.1-3.fc8.log jjh fails-even-with-41/darcs-1.0.9-6.fc8.log jjh fails-even-with-41/libtommath-0.41-7.fc9.log jjh header-dep/ragel-5.24-1.fc8.log jkeating fails-even-with-41/salinfo-0.5-1.14.1.fc6.log jkeating multipledef/dates-0.4.5-1.fc9.log jkratoch Werror/gdb-6.7.1-6.fc9.log jlaska fails-even-with-41/snake-0.9-0.5git.fc9.log jmagne fails-even-with-41/esc-1.0.1-7.fc8.log jmoskovc fails-even-with-41/licq-1.3.4-10.fc9.log jnovy fails-even-with-41/libusb-0.1.12-12.fc9.log jnovy header-dep/teckit-2.2.1-2.fc8.log jnovy multipledef/mc-4.6.1a-50.20070604cvs.fc9.log jnovy unsorted/netpbm-10.35.35-1.fc9.log joost fails-even-with-41/fpc-2.2.0-10.fc8.log jorton fails-even-with-41/mod_python-3.3.1-5.log jpye header-dep/fityk-0.8.1-10.fc8.log jsafrane Werror/nc-1.84-14.fc9.log jsanders fails-even-with-41/veusz-0.10-16.fc8.log jspaleta fails-even-with-41/gourmet-0.13.4-1.fc8.log jspaleta fails-even-with-41/pyscript-0.6.1-1.fc8.log jspaleta fails-even-with-41/python-basemap-0.9.5-3.fc8.log jspaleta fails-even-with-41/python-dateutil-1.2-1.fc8.log jspaleta fails-even-with-41/python-matplotlib-0.90.1-2.fc8.log jspaleta fails-even-with-41/pytz-2006p-2.fc7.log jspaleta fails-even-with-41/ScientificPython-2.6-10.fc8.log jspaleta fails-even-with-41/scipy-0.6.0-3.fc8.log jspaleta header-dep/telescope-server-0-0.2.20070315.fc8.log jspaleta header-dep/usbsink-0.3.2-1.fc8.log jwboyer fails-even-with-41/gquilt-0.20-1.fc7.log jwilson fails-even-with-41/numpy-1.0.3.1-1.fc8.log jwilson fails-even-with-41/rrdtool-1.3-0.2.beta2.fc9.log jwilson header-dep/dvgrab-3.1-1.fc9.log jwilson main/cpuspeed-1.2.1-3.fc8.log jwilson unsorted/emerald-0.5.2-2.fc8.log jwrdegoede changesmeaning/vegastrike-0.4.3-7.fc8.log jwrdegoede fails-even-with-41/arm-gp2x-linux-glibc-2.3.6-4.fc8.log jwrdegoede fails-even-with-41/avr-libc-1.4.6-4.fc8.log jwrdegoede fails-even-with-41/ksensors-0.7.3-14.fc9.log jwrdegoede fails-even-with-41/londonlaw-0.2.1-2.fc8.log jwrdegoede fails-even-with-41/machineball-1.0-4.fc8.log jwrdegoede header-dep/8Kingdoms-1.1.0-2.fc9.log jwrdegoede header-dep/ballbuster-1.0-3.fc8.log jwrdegoede header-dep/ClanLib06-0.6.5-9.fc9.log jwrdegoede header-dep/ClanLib-0.8.0-7.fc9.log jwrdegoede header-dep/crack-attack-1.1.14-10.fc8.log jwrdegoede header-dep/CriticalMass-1.0.2-2.fc9.log jwrdegoede header-dep/gnucap-0.35-2.fc8.log jwrdegoede header-dep/kbilliards-0.8.7b-5.fc9.log jwrdegoede header-dep/ksirk-1.7-4.fc9.log jwrdegoede header-dep/libebml-0.7.7-3.fc8.log jwrdegoede header-dep/libgda-3.0.1-6.fc9.log jwrdegoede header-dep/libmatroska-0.8.1-2.fc8.log jwrdegoede header-dep/ois-1.0-2.fc8.log jwrdegoede header-dep/pingus-0.7.2-1.fc9.log jwrdegoede header-dep/rafkill-1.2.2-5.fc8.log jwrdegoede header-dep/Ri-li-2.0.1-1.fc9.log jwrdegoede header-dep/scorched3d-41.1-1.fc9.log jwrdegoede header-dep/soundtouch-1.3.1-8.fc8.log jwrdegoede header-dep/stormbaancoureur-1.5.1-2.fc8.log jwrdegoede header-dep/supertuxkart-0.3-2.fc8.log jwrdegoede header-dep/xarchon-0.50-5.fc8.log jwrdegoede header-dep/xu4-1.1-0.2.cvs20070510.fc8.log jwrdegoede libtool/bochs-2.3.5-1.fc8.log jwrdegoede multipledef/Io-language-20071010-1.fc9.log jwrdegoede redefined/njam-1.25-6.fc8.log jwrdegoede redefined/pachi-1.0-3.fc8.log jwrdegoede unsorted/amoebax-0.2.0-1.fc9.log jwrdegoede unsorted/asc-2.0.1.0-1.fc9.log jwrdegoede unsorted/boswars-2.4.1-3.fc9.log jwrdegoede unsorted/duel3-0.1-0.4.20060225.fc8.log jwrdegoede unsorted/hedgewars-0.9.0-4.fc9.log jwrdegoede unsorted/id3lib-3.8.3-18.fc9.log jwrdegoede unsorted/methane-1.4.7-3.fc8.log jwrdegoede unsorted/ogre-1.4.5-3.fc9.log jwrdegoede unsorted/scorchwentbonkers-1.1-4.fc8.log jwrdegoede unsorted/scummvm-0.10.0-2.fc8.log jwrdegoede unsorted/TnL-071111-1.fc9.log jwrdegoede unsorted/trackballs-1.1.4-3.fc8.log jwrdegoede unsorted/vavoom-1.25-1.fc9.log kaboom fails-even-with-41/xdaliclock-2.23-3.fc6.log kaboom header-dep/qgo-1.5.2-1.fc6.log karlik fails-even-with-41/fusion-icon-0-0.2.20071206git.fc9.log karlik fails-even-with-41/warzone2100-2.0.8-2.fc9.log karlik header-dep/widelands-0-0.7.build11.fc8.log karsten fails-even-with-41/prctl-1.5-2.log karsten fails-even-with-41/vim-7.1.159-1.fc9.log kasal fails-even-with-41/libgconf-java-2.12.4-8.fc7.log kasal fails-even-with-41/libgtk-java-2.8.7-4.fc7.log kasal rootlog/cairo-java-1.0.5-7.fc7.log kasal rootlog/libglade-java-2.12.5-6.fc7.log kasal rootlog/libgnome-java-2.12.4-6.fc7.log kasal rootlog/libvte-java-0.12.1-10.fc9.log katzj fails-even-with-41/python-urlgrabber-3.0.0-3.fc8.log kengert unsorted/nss-3.11.99.2b-2.fc9.log kevin fails-even-with-41/driconf-0.9.1-6.fc8.log kevin fails-even-with-41/lrmi-0.10-3.fc8.log kevin header-dep/gpsdrive-2.09-4.fc8.log kevin unsorted/fontforge-20071110-1.fc9.log kevin unsorted/twinkle-1.1-3.fc8.log key Werror/trousers-0.3.1-5.fc9.log knol fails-even-with-41/getmail-4.7.7-2.fc9.log krh fails-even-with-41/chkfontpath-1.10.1-2.fc8.log krh fails-even-with-41/compiz-0.6.2-4.fc9.log kushal fails-even-with-41/kphotobymail-0.4.1-1.fc7.log kwizart fails-even-with-41/PythonCAD-0.1.36-2.fc8.log kwizart header-dep/animorph-0.2-2.fc8.log kwizart header-dep/aqsis-1.2.0-6.fc8.log kwizart header-dep/CTL-1.4.1-3.fc9.log kwizart header-dep/dirac-0.8.0-2.fc8.log kwizart header-dep/makehuman-0.9-3.fc8.log kwizart header-dep/PerceptualDiff-1.0.1-6.fc8.log kwizart header-dep/yafray-0.0.9-5.fc9.log kwizart redefined/cinepaint-0.22.1-5.fc8.log kzak fails-even-with-41/gnome-applet-vm-0.1.2-2.fc7.log langel rootlog/azureus-3.0.3.4-3.fc9.log laxathom fails-even-with-41/kicker-compiz-3.5.4-4.fc8.log laxathom fails-even-with-41/ntfs-config-1.0-0.5.rc5.fc8.log laxathom fails-even-with-41/python-gammu-0.22-3.fc8.log laxathom fails-even-with-41/specto-0.2.0-4.fc8.log laxathom fails-even-with-41/wammu-0.19-3.fc8.log laxathom multipledef/gshutdown-0.2-2.fc8.log laxathom multipledef/guile-gnome-platform-2.15.93-6.fc8.log laxathom multipledef/g-wrap-1.9.9-4.fc8.log lennart changesmeaning/paman-0.9.4-1.fc9.log lennart changesmeaning/pavucontrol-0.9.5-1.fc9.log lennart changesmeaning/pavumeter-0.9.3-1.fc9.log leo fails-even-with-41/pcmanx-gtk2-0.3.5-9.336svn.fc7.log limb fails-even-with-41/pcapy-0.10.5-1.fc9.log limb header-dep/agistudio-1.2.3-4.fc8.log limb header-dep/armacycles-ad-0.2.8.2.1-5.fc8.log limb header-dep/xmoto-0.3.4-1.fc9.log limb unsorted/astromenace-1.2-6.fc9.log limb unsorted/netpanzer-0.8.2-1.fc8.log limb unsorted/vym-1.10.0-1.fc9.log lizhang header-dep/ttmkfdir-3.0.9-24.fc7.log lkundrak header-dep/xalan-c-1.10.0-2.fc9.log lkundrak unsorted/ovaldi-5.3-1.fc9.log lmacken changesmeaning/net6-1.3.5-2.fc8.log lmacken changesmeaning/obby-0.4.4-2.fc8.log lmacken changesmeaning/sobby-0.4.4-1.fc8.log lmacken fails-even-with-41/python-cherrypy-2.2.1-7.fc9.log lmacken fails-even-with-41/python-cherrytemplate-1.0.0-5.fc7.log lmacken fails-even-with-41/python-configobj-4.4.0-2.fc8.log lmacken fails-even-with-41/python-irclib-0.4.6-3.fc7.log lmacken fails-even-with-41/python-sqlobject-0.9.2-1.fc9.log lmacken header-dep/gobby-0.4.5-1.fc8.log lmacken header-dep/xprobe2-0.3-9.fc8.log mattdm fails-even-with-41/wxPython-2.8.4.0-2.fc8.log mbacovsk multipledef/avahi-0.6.22-4.fc9.log mbarnes fails-even-with-41/gnome-python2-desktop-2.21.1-1.fc9.log mbarnes multipledef/gnome-python2-2.21.0-1.fc9.log mbarnes multipledef/pygobject2-2.14.0-2.fc9.log mbarnes multipledef/pygtk2-2.12.0-3.fc9.log mbarnes multipledef/pyorbit-2.14.3-1.fc8.log mbarnes redefined/devhelp-0.16.1-4.fc9.log mbarnes redefined/yelp-2.21.1-2.fc9.log mbarnes Werror/evolution-exchange-2.21.4-1.fc9.log mcepl auto_ptr/syncevolution-0.6-2.fc8.log mclasen multipledef/libglade2-2.6.2-3.fc8.log mdehaan fails-even-with-41/cobbler-0.6.4-2.fc9.log mdehaan fails-even-with-41/func-0.13-3.fc9.log mdehaan fails-even-with-41/koan-0.6.3-3.fc9.log mebourne multipleparm/zoneminder-1.22.3-10.fc9.log mebrown header-dep/libsmbios-0.13.13-1.fc9.log mef header-dep/ice-3.2.1-14.fc9.log mfleming fails-even-with-41/python-GeoIP-1.2.1-9.fc8.log mfleming fails-even-with-41/svnmailer-1.0.8-3.fc7.log mgarski auto_ptr/linuxdcpp-1.0.0-4.fc9.log mgarski fails-even-with-41/digikam-doc-0.9.3-0.1.beta3.fc9.log mgarski header-dep/smb4k-0.8.7-3.fc9.log mgarski redefined/digikam-0.9.3-0.5.rc1.fc9.log mgarski unsorted/krusader-1.80.0-4.fc9.log michich fails-even-with-41/icecream-0.8.0-6.20071101svn.fc9.log mikep fails-even-with-41/linkchecker-4.7-10.fc8.log misa fails-even-with-41/mx-2.0.6-3.log misa fails-even-with-41/pyOpenSSL-0.6-2.p24.9.log mitr fails-even-with-41/m2crypto-0.18.2-2.log mlichvar fails-even-with-41/obmenu-1.0-5.fc8.log mlichvar header-dep/flac-1.2.1-1.fc8.log mmaslano fails-even-with-41/iproute-2.6.23-1.fc9.log mmaslano redefined/groff-1.18.1.4-10.fc8.log mmcgrath fails-even-with-41/python-meld3-0.6-2.fc7.1.log mmcgrath fails-even-with-41/supervisor-2.1-3.fc7.log mnagy libtool/lftp-3.5.14-3.fc9.log mpg header-dep/xapian-core-1.0.4-1.fc9.log mschwendt unsorted/libsidplay-1.36.57-15.log mso multipledef/gxine-0.5.11-14.fc9.log mtasaka fails-even-with-41/kazehakase-0.5.0-1.fc9.2.log mtasaka fails-even-with-41/mirage-0.9-2.fc9.log mtasaka fails-even-with-41/python-mecab-0.96-2.fc9.1.log mtasaka fails-even-with-41/xtide-2.9.5-1.fc9.log mtasaka header-dep/gnome-commander-1.2.4-4.fc8.log mtasaka header-dep/jd-1.9.8-0.4.beta071218.fc9.log mtasaka header-dep/ochusha-0.5.99.66-0.3.cvs070110.fc9.log mtasaka header-dep/xplanet-1.2.0-2.1.fc8.2.log mtasaka unsorted/mecab-0.96-2.fc9.1.log musuruan fails-even-with-41/tecnoballz-0.91-6.fc8.log mwringe fails-even-with-41/maven-wagon-1.0-0.1.a5.3jpp.1.fc7.log mwringe java1.2/msv-1.2-0.1.20050722.3jpp.3.fc8.log mzazrive header-dep/xqilla10-1.0.2-2.fc9.log navid fails-even-with-41/sos-1.6-5.fc8.log nbecker fails-even-with-41/filelight-1.0-9.fc6.log nbecker fails-even-with-41/python-which-1.1.0-2.fc9.log ngompa fails-even-with-41/oggconvert-0.3.0-14.fc9.log nhorman fails-even-with-41/kexec-tools-1.102pre-2.fc8.log nixaff4 fails-even-with-41/kio_p7zip-0.3.1-5.fc8.log nixaff4 fails-even-with-41/tastymenu-0.8.2-2.fc8.log noltec fails-even-with-41/kbibtex-0.1.5.52-10.fc7.log nomis80 fails-even-with-41/camstream-0.26.3-12.fc8.log nomis80 fails-even-with-41/quadkonsole-2.0.2-1.fc7.log notting fails-even-with-41/mash-0.2.10-1.fc9.log notting header-dep/libofx-0.8.3-4.log notting libtool/aqbanking-2.3.2-4.fc9.log nphilipp header-dep/bzflag-2.0.10-2.fc9.log nphilipp header-dep/rss-glx-0.8.1.p-17.fc9.log nsantos java1.2/xpp3-1.1.3.8-1jpp.1.fc7.log nsantos unsorted/checkstyle-4.1-4jpp.2.fc8.log oddsocks fails-even-with-41/aasaver-0.3.2-1.fc8.log oddsocks fails-even-with-41/kbiof-0.3-1.fc8.log oddsocks fails-even-with-41/kcometen3-1.1-5.fc8.log oddsocks fails-even-with-41/kdetv-0.8.9-8.fc9.log oddsocks fails-even-with-41/xeuphoric-0.18.2-9.fc8.log oddsocks header-dep/openmsx-0.6.2-4.fc8.log oddsocks libtool/cegui-0.5.0b-6.fc8.log odvorace multipledef/pguiman-0.0.1-3.fc8.log oliver fails-even-with-41/syck-0.61-3.fc9.log orion fails-even-with-41/kompose-0.5.3-8.fc8.log orion fails-even-with-41/ksynaptics-0.3.3-2.fc8.log orion fails-even-with-41/python-numarray-1.5.2-4.fc8.log orion header-dep/gdl-0.9-0.pre6.fc9.log orion header-dep/hdf5-1.6.6-3.fc9.log orion header-dep/libsynaptics-0.14.6c-2.fc8.log orion header-dep/paraview-3.2.1-2.fc9.log orion header-dep/plplot-5.8.0-4.fc9.log orion unsorted/hdf-4.2r2-4.fc9.log orion unsorted/ncarg-4.4.2-4.fc8.log otaylor fails-even-with-41/mugshot-1.1.56-1.fc8.log ovasik header-dep/libwvstreams-4.4.1-3.fc9.log ovasik header-dep/wvdial-1.60-3.fc9.log ovasik unsorted/taskjuggler-2.4.0-4.fc8.log overholt fails-even-with-41/eclipse-emf-2.2.2-1.fc7.log overholt ice/eclipse-gef-3.3.0-1.fc8.log overholt unsorted/eclipse-3.3.1.1-14.fc9.log patriceb header-dep/lzma-4.32.2-2.fc9.log pcheung fails-even-with-41/castor-0.9.5-1jpp.7.log pcheung fails-even-with-41/xmlunit-1.0-4jpp.1.fc7.log pcheung java1.2/ant-1.7.0-1jpp.2.fc8.log pebenito unsorted/setools-3.3.2-1.fc9.log pertusus fails-even-with-41/archmage-0.1.9-1.fc8.log pertusus fails-even-with-41/dap-hdf4_handler-3.7.5-3.fc8.log pertusus fails-even-with-41/gnash-0.8.1-6.fc9.log pertusus fails-even-with-41/kchmviewer-3.0-2.fc7.log pertusus fails-even-with-41/python-chm-0.8.4-1.fc7.log pertusus fails-even-with-41/tetex-tex4ht-1.0.2007_11_19_2329-1.fc9.log pertusus fails-even-with-41/wdm-1.28-8.fc8.log pertusus header-dep/acpitool-0.4.7-2.fc9.log pertusus header-dep/bes-3.5.1-4.fc9.log pertusus header-dep/boolstuff-0.1.11-3.fc9.log pertusus header-dep/dap-freeform_handler-3.7.5-2.fc8.log pertusus header-dep/libchmxx-0.1-5.fc6.log pertusus header-dep/libdap-3.7.8-3.fc9.log pertusus header-dep/libnc-dap-3.7.0-8.fc9.log pertusus multipleparm/xchm-1.13-1.fc8.log pertusus unsorted/cernlib-2006-20.fc9.log pertusus unsorted/perl-Cache-2.04-2.fc8.2.log peter header-dep/fuse-encfs-1.3.2-2.fc9.log peter header-dep/rlog-1.3.7-3.fc6.log peter header-dep/stratagus-2.2.4-1.fc8.log petersen fails-even-with-41/haddock-0.8-1.fc7.log petersen header-dep/scim-fcitx-3.1.1-7.fc8.log pfj fails-even-with-41/gtk-sharp-1.0.10-12.fc7.log pfj fails-even-with-41/monodevelop-0.17-4.fc9.log pfj fails-even-with-41/pyxmms-2.06-4.fc7.log pfj multipledef/autogen-5.8.9-1.fc7.log pfkeb header-dep/HippoDraw-1.21.1-2.fc8.log pfrields fails-even-with-41/blogtk-1.1-8.fc7.log pghmcfc fails-even-with-41/bittorrent-4.4.0-5.fc7.log pghmcfc fails-even-with-41/python-zope-interface-3.0.1-8.fc8.log pgordon changesmeaning/deluge-0.5.7.1-2.fc9.log pgordon fails-even-with-41/nemiver-0.4.0-1.fc8.log pgordon fails-even-with-41/ots-0.4.2-11.fc7.log pgordon header-dep/rb_libtorrent-0.12-2.fc8.log pgordon header-dep/WebKit-1.0.0-0.3.svn28482.fc9.log pgordon multipledef/telepathy-haze-0.1.4-2.fc9.log pgordon redefined/blam-1.8.3-13.fc9.log phuang header-dep/scim-bridge-0.4.13-6.fc9.log phuang header-dep/scim-pinyin-0.5.91-23.fc9.log phuang unsorted/scim-qtimm-0.9.4-8.fc8.log pingou fails-even-with-41/rkward-0.4.8-2.fc9.log pingou header-dep/SteGUI-0.0.1-12.fc8.log pjones Werror/grub-0.97-19.log pjones Werror/mkinitrd-6.0.24-1.fc9.log pknirsch Werror/openhpi-2.10.1-1.fc9.log pmachata fails-even-with-41/ltrace-0.5-9.45svn.fc8.log pmatilai unsorted/rpm-4.4.2.2-11.fc9.log pnemade header-dep/scim-m17n-0.2.2-2.fc8.log pwouters fails-even-with-41/s3switch-0.0-9.20020912.fc6.log qspencer fails-even-with-41/atlas-3.6.0-12.fc8.log qspencer fails-even-with-41/lilypond-doc-2.10.13-1.fc7.log qspencer unsorted/cln-1.1.13-4.fc8.log qspencer unsorted/lilypond-2.10.33-1.fc8.log rafalzaq fails-even-with-41/six-0.5.3-6.fc8.log rafalzaq unsorted/glob2-0.9.1-2.fc8.log rathann fails-even-with-41/ekg-1.7-3.fc9.log rathann fails-even-with-41/obexftp-0.22-0.5.rc7.fc8.log rathann fails-even-with-41/openbabel-2.1.1-2.fc9.log rathann header-dep/ed2k_hash-0.4.0-5.fc9.log rathann header-dep/libEMF-1.0.3-5.fc9.log rathann header-dep/xdrawchem-1.9.9-6.fc8.log rathann header-dep/zidrav-1.2.0-3.fc8.log rathann redefined/dx-4.4.4-4.fc8.log rathann unsorted/ekg2-0.1.1-2.fc9.log rathann unsorted/mkvtoolnix-2.1.0-1.fc8.log rbrich multipledef/cpio-2.9-5.fc9.log rbrich multipledef/tar-1.19-1.fc9.log rdieter fails-even-with-41/cmucl-19d-5.fc8.log rdieter fails-even-with-41/gpgme-1.1.5-4.fc8.log rdieter fails-even-with-41/kaffeine-0.8.5-5.fc8.log rdieter fails-even-with-41/kile-2.0-1.fc9.log rdieter fails-even-with-41/kiosktool-1.0-8.fc8.log rdieter fails-even-with-41/libkexiv2-0.1.6-2.fc9.log rdieter fails-even-with-41/libtunepimp-0.5.3-9.fc8.log rdieter header-dep/akode-2.0.1-9.fc8.log rdieter header-dep/exiv2-0.16-0.3.pre1.fc9.log rdieter header-dep/libfac-3.0.3-1.fc9.log rdieter header-dep/libofa-0.9.3-10.fc8.log rdieter header-dep/OpenEXR-1.6.0-5.fc8.log rdieter multipleparm/kmymoney2-0.8.8-1.fc9.log rdieter redefined/kasablanca-0.4.0.2-11.fc9.log rdieter redefined/lyx-1.5.3-1.fc9.log rdieter redefined/Macaulay2-0.9.95-9.fc9.log rdieter unsorted/factory-3.0.3-1.fc9.log remi header-dep/mysql++-2.3.2-2.fc8.log richdawe fails-even-with-41/planet-2.0-4.fc8.log rineau header-dep/ipe-6.0-0.22.pre28.fc9.log rishi fails-even-with-41/pida-0.5.1-5.fc9.log rishi header-dep/gengetopt-2.21-3.fc8.log rishi header-dep/nget-0.27.1-7.fc8.log rishi libtool/anjuta-2.2.0-4.fc9.log rishi unsorted/starplot-0.95.4-3.fc9.log rjones fails-even-with-41/freetennis-0.4.8-6.fc7.log rnorwood fails-even-with-41/gnome-packagekit-0.1.4-1.fc9.log rnorwood fails-even-with-41/perl-PDL-2.4.3-4.fc8.log rnorwood fails-even-with-41/perl-TermReadKey-2.30-3.fc9.log rnorwood unsorted/perl-5.8.8-31.fc9.log robert fails-even-with-41/duplicity-0.4.3-1.fc8.log robert fails-even-with-41/pexpect-2.1-5.fc8.log robert fails-even-with-41/python-GnuPGInterface-0.3.2-2.fc8.log robert unsorted/dsniff-2.4-0.1.b1.fc9.log roland fails-even-with-41/monotone-0.37-3.fc9.log roland Werror/elfutils-0.131-1.fc9.log roozbeh fails-even-with-41/fonttools-2.0-0.11.20060223cvs.fc7.log roozbeh fails-even-with-41/perl-Math-Vec-0.04-2.fc7.log roozbeh fails-even-with-41/translate-toolkit-0.10.1-4.fc7.log rrelyea header-dep/coolkey-1.1.0-5.fc8.log rstrode fails-even-with-41/bluecurve-kde-theme-1.0.0-1.fc8.log rstrode fails-even-with-41/bluecurve-kwin-theme-1.0.0-1.fc8.log rstrode header-dep/gnome-games-2.21.4-1.fc9.log ruben header-dep/incron-0.5.5-1.fc7.log ruben header-dep/pdns-2.9.21-3.fc9.log ruben header-dep/pdns-recursor-3.1.4-4.fc7.log ruben redefined/perl-Perlbal-XS-HTTPHeaders-0.19-2.fc8.log rvinyard changesmeaning/bitgtkmm-0.4.0-2.fc7.log rvinyard changesmeaning/conexusmm-0.5.0-3.fc7.log rvinyard fails-even-with-41/clips-6.24-22.fc7.log rvinyard fails-even-with-41/conexus-0.5.3-2.fc8.log rvinyard unsorted/bit-0.4.1-1.fc7.log rvinyard unsorted/clipsmm-0.0.7-1.fc7.log rvinyard unsorted/idioskopos-0.4.1-1.fc7.log rvinyard unsorted/papyrus-0.7.1-1.fc7.log rvokal fails-even-with-41/gjots2-2.3.4-7.fc7.log rvokal multipledef/pidgin-guifications-2.14-2.fc7.log ryo header-dep/scim-skk-0.5.2-8.fc6.log ryo header-dep/scim-tomoe-0.6.0-2.fc8.log s4504kr fails-even-with-41/kyum-0.7.5-9.fc8.log s4504kr fails-even-with-41/lightning-1.2-11.fc8.log s4504kr fails-even-with-41/python-smbpasswd-1.0.1-6.fc8.log s4504kr header-dep/blender-2.45-4.fc8.log s4504kr header-dep/highlight-2.6.6-1.fc9.log s4504kr header-dep/steghide-0.5.1-7.fc8.log s4504kr header-dep/stellarium-0.9.0-6.fc9.log s4504kr header-dep/subcommander-1.2.2-9.fc9.log s4504kr libtool/aplus-fsf-4.20.2-22.fc8.log s4504kr unsorted/gprolog-1.3.0-11.fc8.log sailer unsorted/ghdl-0.25-0.89svn.6.fc8.log salimma fails-even-with-41/Django-0.96.1-1.fc9.log salimma fails-even-with-41/ikarus-0.0.1-4.fc9.log salimma fails-even-with-41/python-nltk-0.9-0.2.b2.fc8.log salimma fails-even-with-41/python-nltk_lite-0.9-0.1.b2.fc8.log salimma fails-even-with-41/spicctrl-1.9-5.fc7.log salimma fails-even-with-41/zeroinstall-injector-0.30-2.fc8.log salimma header-dep/grhino-0.16.0-2.fc8.log sarantis fails-even-with-41/python-simpy-1.8-1.fc7.log sconklin fails-even-with-41/netlabel_tools-0.17-5.fc6.log scop header-dep/id3v2-0.1.11-5.fc8.log scop header-dep/kid3-0.10-2.fc9.log scop header-dep/vdr-subtitles-0.5.0-2.fc8.log scop header-dep/vdr-text2skin-1.1-20.20051217cvs.fc8.log scop header-dep/xmms-modplug-2.05-11.fc8.log sdake fails-even-with-41/openais-0.80.1-6.log seg fails-even-with-41/rosegarden4-1.6.0-1.fc7.log seg ice/tinyfugue-5.0-0.7.b8.fc9.log sergiopr header-dep/CCfits-1.8-1.fc9.log sergiopr header-dep/ds9-5.0-6.fc9.log sergiopr header-dep/loki-lib-0.1.6-4.fc8.1.log sergiopr unsorted/blitz-0.9-3.fc8.log sgrubb fails-even-with-41/audit-1.6.2-4.fc8.log shahms fails-even-with-41/python-durus-3.5-3.fc7.log shahms fails-even-with-41/python-psyco-1.5.1-5.fc7.log shahms fails-even-with-41/python-quixote-2.4-5.fc7.log shahms fails-even-with-41/python-simpletal-4.1-5.fc7.log shahms fails-even-with-41/python-tpg-3.1.0-4.fc7.log sharkcz fails-even-with-41/tailor-0.9.29-1.fc9.log sharkcz fails-even-with-41/tinyerp-4.2.0-1.fc9.log sharkcz header-dep/ultimatestunts-0.7.3-4.fc9.log silfreed fails-even-with-41/qgis-0.9.0-2.fc8.log silfreed fails-even-with-41/syslog-ng-2.0.5-1.fc8.log silfreed header-dep/qlandkarte-0.5.3-4.fc9.log silfreed header-dep/qtpfsgui-1.9.0-1.fc9.log sindrepb fails-even-with-41/muine-scrobbler-0.1.8-2.fc8.log skvidal fails-even-with-41/yum-metadata-parser-1.1.2-2.fc9.log smccann redefined/geos-2.2.3-1.fc7.log snecker fails-even-with-41/jokosher-1.0-0.1.20070929svn.fc8.log snecker Werror/libflaim-4.9.989-18.fc9.log snirkel header-dep/adplug-2.1-2.fc8.log snirkel header-dep/xmms-adplug-1.2-5.fc8.log southa header-dep/adanaxisgpl-1.2.4-1.fc9.log splinux fails-even-with-41/gdmap-0.7.5-6.fc6.log splinux fails-even-with-41/gfa-0.4.1-4.fc7.log splinux fails-even-with-41/glipper-0.95.1-2.fc7.log splinux fails-even-with-41/gnome-specimen-0.3-1.fc8.log splinux fails-even-with-41/gstm-1.2-6.fc7.log splinux header-dep/libgtksourceviewmm-0.3.1-1.fc8.log splinux header-dep/lostirc-0.4.6-3.fc8.log splinux header-dep/notecase-1.6.1-2.fc8.log spot changesmeaning/libgdamm-2.9.8-1.fc8.log spot fails-even-with-41/gambas-1.0.19-3.fc8.log spot fails-even-with-41/perl-Email-Date-1.102-3.fc8.log spot fails-even-with-41/perl-Email-Reply-1.202-1.fc8.log spot fails-even-with-41/perl-IPC-Shareable-0.60-3.fc6.log spot fails-even-with-41/perl-PPI-Tester-0.06-2.fc6.log spot fails-even-with-41/pychart-1.39-6.fc8.log spot fails-even-with-41/python-cerealizer-0.6-2.fc9.log spot fails-even-with-41/pyxdg-0.15-5.fc8.1.log spot fails-even-with-41/QuantLib-0.8.1-4.fc9.log spot fails-even-with-41/rekall-2.4.5-6.fc8.1.log spot fails-even-with-41/wlassistant-0.5.7-4.fc8.log spot header-dep/asymptote-1.33-2.fc8.log spot header-dep/google-perftools-0.93-1.fc8.log spot header-dep/SimGear-0.3.11-0.3.pre1.fc8.2.log spot header-dep/srecord-1.36-1.fc8.log spot header-dep/xbase-2.0.0-8.fc9.log spot header-dep/xbsql-0.11-9.fc8.log spot unsorted/perl-Glib-1.162-1.fc9.log ssp changesmeaning/gnome-system-monitor-2.21.4-1.fc9.log stahnma fails-even-with-41/kflickr-0.9-1.fc8.log steved fails-even-with-41/libevent-1.3b-1.fc7.log steve fails-even-with-41/perl-DateTime-Event-ICal-0.09-3.fc7.log steve fails-even-with-41/perl-DateTime-Event-Recurrence-0.16-4.fc7.log steve fails-even-with-41/perl-DateTime-Format-ICal-0.08-4.fc7.log steve fails-even-with-41/perl-DateTime-Format-Strptime-1.0700-3.fc7.log steve fails-even-with-41/perl-DateTime-Format-W3CDTF-0.04-2.fc7.log steve fails-even-with-41/perl-DateTime-Set-0.25-4.fc7.log steve fails-even-with-41/perl-Devel-Caller-0.11-1.fc7.log steve fails-even-with-41/perl-Exception-Class-1.23-3.fc7.log steve fails-even-with-41/perl-File-ReadBackwards-1.04-3.fc7.log steve fails-even-with-41/perl-File-Type-0.22-4.fc7.log steve fails-even-with-41/perl-HTML-Template-Expr-0.07-4.fc7.log steve fails-even-with-41/perl-IO-All-0.38-1.fc7.log steve fails-even-with-41/perl-Kwiki-0.39-1.fc7.log steve fails-even-with-41/perl-Kwiki-Archive-Rcs-0.15-6.fc7.log steve fails-even-with-41/perl-Kwiki-Attachments-0.18-3.fc7.log steve fails-even-with-41/perl-Kwiki-Diff-0.03-4.fc7.log steve fails-even-with-41/perl-Kwiki-ModPerl-0.09-4.fc7.log steve fails-even-with-41/perl-Kwiki-NewPage-0.12-5.fc7.log steve fails-even-with-41/perl-Kwiki-Raw-0.02-4.fc7.log steve fails-even-with-41/perl-Kwiki-RecentChanges-0.14-3.fc7.log steve fails-even-with-41/perl-Kwiki-Revisions-0.15-5.fc7.log steve fails-even-with-41/perl-Kwiki-Search-0.12-5.fc7.log steve fails-even-with-41/perl-Kwiki-UserName-0.14-5.fc7.log steve fails-even-with-41/perl-Kwiki-UserPreferences-0.13-5.fc7.log steve fails-even-with-41/perl-Kwiki-Users-Remote-0.04-4.fc7.log steve fails-even-with-41/perl-Log-Message-0.01-3.fc7.log steve fails-even-with-41/perl-Log-Message-Simple-0.02-1.fc8.log steve fails-even-with-41/perl-Module-Build-0.2808-1.fc8.log steve fails-even-with-41/perl-Module-Install-0.67-1.fc8.log steve fails-even-with-41/perl-Module-Loaded-0.01-3.fc7.log steve fails-even-with-41/perl-Module-Pluggable-3.60-1.fc7.log steve fails-even-with-41/perl-Object-Accessor-0.32-2.fc7.log steve fails-even-with-41/perl-OpenFrame-3.05-6.fc7.log steve fails-even-with-41/perl-Package-Constants-0.01-3.fc7.log steve fails-even-with-41/perl-Params-Check-0.26-1.fc7.log steve fails-even-with-41/perl-Parse-CPAN-Packages-2.26-4.fc7.log steve fails-even-with-41/perl-Perl6-Bible-0.30-3.fc7.log steve fails-even-with-41/perl-Pipeline-3.12-4.fc7.log steve fails-even-with-41/perl-Set-Infinite-0.61-3.fc7.log steve fails-even-with-41/perl-Spiffy-0.30-7.fc7.log steve fails-even-with-41/perl-Spreadsheet-ParseExcel-0.3200-1.fc8.log steve fails-even-with-41/perl-Sys-Virt-0.1.1-9.fc7.log steve fails-even-with-41/perl-Test-Portability-Files-0.05-4.fc7.log steve fails-even-with-41/perl-Text-Levenshtein-0.05-4.fc7.log steve fails-even-with-41/perl-YAML-Parser-Syck-0.01-8.fc7.log steve header-dep/celestia-1.4.1-7.fc7.log steve header-dep/cone-0.74-1.fc9.log steve header-dep/supertux-0.3.0-3.fc9.log steve libtool/uuid-1.6.0-2.fc8.log stransky fails-even-with-41/awesfx-0.5.0d-4.fc7.log stransky multipledef/nspluginwrapper-0.9.91.5-16.fc9.log subhodip fails-even-with-41/straw-0.27-12.fc9.log svahl fails-even-with-41/koverartist-0.5-8.fc8.log svahl fails-even-with-41/polyester-1.0.2-1.fc8.log szpak fails-even-with-41/pylibacl-0.2.2-1.fc8.log szpak fails-even-with-41/pyxattr-0.2.2-1.fc8.log szpak multipledef/asunder-1.0-1.fc9.log szpak multipledef/isomaster-1.3-1.fc9.log tagoh header-dep/kasumi-2.3-1.fc9.log tagoh header-dep/scim-anthy-1.2.4-2.fc8.log tagoh header-dep/uim-1.4.1-8.fc8.log tanguy header-dep/drgeo-1.1.0-11.fc8.log tanguy header-dep/freehdl-0.0.4-4.fc8.log terjeros fails-even-with-41/python-exif-1.0.5-1.fc9.log terjeros header-dep/gle-4.0.12a-2.fc8.log terjeros unsorted/extrema-4.2.10-3.fc9.log than fails-even-with-41/kdbg-2.0.5-2.fc7.log than fails-even-with-41/kdebindings-3.97.0-6.fc9.log than fails-even-with-41/kde-i18n-3.5.8-1.fc8.log than fails-even-with-41/wordtrans-1.1-0.2.pre13.fc7.log than fails-even-with-41/xferstats-2.16-14.1.log than header-dep/arts-1.5.8-4.fc8.log than header-dep/qt-3.3.8-11.fc9.log than redefined/kdebase3-3.5.8-24.fc9.log than redefined/kdelibs3-3.5.8-20.fc9.log than redefined/kdewebdev-3.5.8-4.fc9.log thias fails-even-with-41/d4x-2.5.7.1-3.fc7.log thias fails-even-with-41/epydoc-2.1-8.fc8.log thias fails-even-with-41/i8kutils-1.25-13.log thias fails-even-with-41/kannel-1.4.1-5.log thias fails-even-with-41/moin-1.5.8-2.fc8.log thias fails-even-with-41/python-lirc-0.0.5-5.log thias fails-even-with-41/python-metar-1.3.0-2.fc7.log thias fails-even-with-41/python-ogg-1.3-7.log thias fails-even-with-41/python-tag-0.91-5.log thias fails-even-with-41/python-vorbis-1.5-0.2.a.log thias header-dep/bbkeys-0.9.0-9.log thias header-dep/blackbox-0.70.1-9.log thias header-dep/easytag-2.1-3.fc8.log thias header-dep/fillets-ng-0.7.4-3.fc8.log thias header-dep/hackedbox-0.8.5-3.fc8.log thias header-dep/synergy-1.3.1-5.fc8.log thias redefined/csmash-0.6.6-17.log thias unsorted/torcs-1.3.0-3.fc8.log thl fails-even-with-41/python-crypto-2.0.1-9.1.log thl unsorted/enigma-1.01-3.1.log thomasvs fails-even-with-41/ladspa-1.12-8.fc7.log thomasvs fails-even-with-41/python-twisted-conch-0.8.0-1.fc8.log thomasvs fails-even-with-41/python-twisted-core-2.5.0-2.fc8.log thomasvs fails-even-with-41/python-twisted-lore-0.2.0-4.fc7.log thomasvs fails-even-with-41/python-twisted-mail-0.4.0-1.fc8.log thomasvs fails-even-with-41/python-twisted-names-0.4.0-1.fc8.log thomasvs fails-even-with-41/python-twisted-news-0.3.0-1.fc8.log thomasvs fails-even-with-41/python-twisted-runner-0.2.0-4.fc7.log thomasvs fails-even-with-41/python-twisted-web-0.7.0-1.fc8.log thomasvs fails-even-with-41/python-twisted-words-0.5.0-1.fc8.log tibbs fails-even-with-41/denyhosts-2.6-7.fc8.log till fails-even-with-41/offlineimap-5.99.4-1.fc9.log timj libtool/rapidsvn-0.9.4-7.fc9.log timj multipleparm/alsa-tools-1.0.12-4.fc7.log timn fails-even-with-41/NetworkManager-openvpn-0.7.0-3.svn3047.fc9.log tjanouse fails-even-with-41/brltty-3.8-1.fc8.log tjikkun fails-even-with-41/amsn-0.96-7.fc7.log tmraz header-dep/workrave-1.8.4-4.fc8.log toshio fails-even-with-41/pygpgme-0.1-6.fc8.log toshio fails-even-with-41/qa-assistant-0.4.90.5-2.fc6.log trasher fails-even-with-41/klear-0.6.1-1.fc8.log trasher fails-even-with-41/ksplash-engine-moodin-0.4.2-4.fc7.log trondd fails-even-with-41/gedit-plugins-2.18.0-2.fc7.log trondd fails-even-with-41/postr-0.9-1.fc8.log trondd fails-even-with-41/sdcc-2.6.0-10.fc7.log tscherf fails-even-with-41/libprelude-0.9.13-1.fc7.log tscherf fails-even-with-41/Miro-1.0-2.fc9.log tscherf fails-even-with-41/prewikka-0.9.8-1.fc7.log tsmetana redefined/smartmontools-5.37-8.3.fc9.log twaugh fails-even-with-41/libieee1284-0.2.11-1.fc8.log twoerner header-dep/iptstate-2.2.1-1.fc8.log unkown fails-even-with-41/compat-gcc-296-2.96-139.log unkown fails-even-with-41/compat-guile-16-1.6.7-7.fc8.log unkown fails-even-with-41/java-1.5.0-gcj-1.5.0.0-17.fc8.log unkown fails-even-with-41/java-1.7.0-icedtea-1.7.0.0-0.22.b23.snapshot.fc9.log unkown fails-even-with-41/s390utils-1.5.4-4.fc7.log unkown header-dep/lshw-B.02.12.01-1.fc9.log unkown unsorted/compat-erlang-R10B-11.9.fc9.log unkown unsorted/erlang-R12B-0.1.fc9.log unkown unsorted/kernel-xen-2.6-2.6.21.7-2890.fc9.log uwog fails-even-with-41/gtkmathview-0.7.6-5.fc6.log uwog header-dep/aiksaurus-1.2.1-15.fc6.log uwog header-dep/asio-0.3.8-7.fc9.log uwog unsorted/abiword-2.4.6-6.fc8.log varekova multipleparm/aspell-0.60.5-3.fc7.log vcrhonek fails-even-with-41/pychecker-0.8.17-2.log vcrhonek ice/tog-pegasus-2.7.0-3.fc9.log vivekl fails-even-with-41/cryptix-asn1-20011119-7jpp.2.log vivekl fails-even-with-41/jgroups-2.2.9.2-3jpp.2.log vivekl fails-even-with-41/ldapjdk-4.17-1jpp.7.log vivekl java1.2/bea-stax-1.2.0-0.1.rc1.2jpp.1.fc7.log vivekl java1.2/log4j-1.2.14-3jpp.1.fc8.log vivekl java1.2/xmlrpc-2.0.1-3jpp.2.log vlg changesmeaning/granule-1.2.4-2.fc7.log vlg header-dep/libassa-3.4.2-4.log walters fails-even-with-41/hotwire-0.620-1.fc9.log wart auto_ptr/spr-07.00.00-1.fc8.log wart header-dep/cyphesis-0.5.15-2.fc9.log wart header-dep/eris-1.3.13-1.fc9.log wart header-dep/manaworld-0.0.23-1.fc8.log wart header-dep/sear-0.6.3-7.fc9.log wart header-dep/skstream-0.3.6-2.fc8.log wart header-dep/varconf-0.6.5-2.fc8.log wart libtool/atlascpp-0.6.1-2.fc9.log wart multipleparm/bsd-games-2.17-22.fc9.log wart multipleparm/mercator-0.2.5-3.fc9.log wart unsorted/wormux-0.7.9-5.fc8.log wcohen header-dep/oprofile-0.9.3-7.fc9.log wcohen Werror/libpfm-3.2-0.071017.1.fc9.log wolfy unsorted/qfaxreader-0.3.1-8.fc8.1.log wtogami header-dep/bonnie++-1.03a-7.fc8.log xen-maint fails-even-with-41/xen-3.1.2-2.fc9.log xgl-maint fails-even-with-41/xorg-x11-drv-acecad-1.1.0-5.fc8.log xgl-maint fails-even-with-41/xorg-x11-drv-amd-0.0-22.20070625.fc8.log xgl-maint fails-even-with-41/xorg-x11-drv-apm-1.1.1-7.fc8.log xgl-maint fails-even-with-41/xorg-x11-drv-ark-0.6.0-6.fc8.log xgl-maint fails-even-with-41/xorg-x11-drv-ast-0.81.0-6.fc8.log xgl-maint fails-even-with-41/xorg-x11-drv-calcomp-1.1.0-4.fc8.log xgl-maint fails-even-with-41/xorg-x11-drv-chips-1.1.1-5.fc8.log xgl-maint fails-even-with-41/xorg-x11-drv-cirrus-1.1.0-5.fc8.log xgl-maint fails-even-with-41/xorg-x11-drv-citron-2.2.0-2.fc7.log xgl-maint fails-even-with-41/xorg-x11-drv-cyrix-1.1.0-5.fc8.log xgl-maint fails-even-with-41/xorg-x11-drv-dmc-1.1.0-3.fc7.log xgl-maint fails-even-with-41/xorg-x11-drv-dynapro-1.1.0-3.fc7.log xgl-maint fails-even-with-41/xorg-x11-drv-glint-1.1.1-7.fc8.log xgl-maint fails-even-with-41/xorg-x11-drv-i128-1.2.1-1.fc8.log xgl-maint fails-even-with-41/xorg-x11-drv-i740-1.1.0-5.fc8.log xgl-maint fails-even-with-41/xorg-x11-drv-i810-2.2.0-2.fc9.log xgl-maint fails-even-with-41/xorg-x11-drv-magellan-1.1.0-4.fc8.log xgl-maint fails-even-with-41/xorg-x11-drv-mga-1.4.6.1-6.fc8.log xgl-maint fails-even-with-41/xorg-x11-drv-microtouch-1.1.0-2.fc7.log xgl-maint fails-even-with-41/xorg-x11-drv-neomagic-1.1.1-4.fc8.log xgl-maint fails-even-with-41/xorg-x11-drv-nsc-2.8.1-4.fc8.log xgl-maint fails-even-with-41/xorg-x11-drv-nv-2.1.6-2.fc9.log xgl-maint fails-even-with-41/xorg-x11-drv-penmount-1.1.0-3.fc7.log xgl-maint fails-even-with-41/xorg-x11-drv-rendition-4.1.3-5.fc8.log xgl-maint fails-even-with-41/xorg-x11-drv-s3-0.5.0-5.fc8.log xgl-maint fails-even-with-41/xorg-x11-drv-s3virge-1.9.1-5.fc8.log xgl-maint fails-even-with-41/xorg-x11-drv-savage-2.1.3-99.20071210.fc9.log xgl-maint fails-even-with-41/xorg-x11-drv-siliconmotion-1.5.1-3.fc8.log xgl-maint fails-even-with-41/xorg-x11-drv-sis-0.9.3-4.fc8.log xgl-maint fails-even-with-41/xorg-x11-drv-spaceorb-1.1.0-4.fc8.log xgl-maint fails-even-with-41/xorg-x11-drv-tdfx-1.3.0-6.fc8.log xgl-maint fails-even-with-41/xorg-x11-drv-trident-1.2.3-6.fc8.log xgl-maint fails-even-with-41/xorg-x11-drv-tseng-1.1.0-7.fc8.log xgl-maint fails-even-with-41/xorg-x11-drv-vermilion-1.0.0-2.fc8.log xgl-maint fails-even-with-41/xorg-x11-drv-vga-4.1.0-5.fc8.log xgl-maint fails-even-with-41/xorg-x11-drv-via-0.2.2-4.fc8.log xgl-maint fails-even-with-41/xorg-x11-drv-vmware-10.15.2-1.fc8.log xgl-maint fails-even-with-41/xorg-x11-drv-voodoo-1.1.1-1.fc8.log xris fails-even-with-41/lineak-kdeplugins-0.9-2.fc6.log xris fails-even-with-41/orpie-1.4.3-5.fc6.log xris header-dep/dar-2.3.6-3.fc9.log xris header-dep/lineakd-0.9-5.fc6.log xris header-dep/lineak-defaultplugin-0.9-2.fc6.log xris header-dep/lineak-xosdplugin-0.9-2.fc6.log xulchris fails-even-with-41/pygame-1.7.1-14.fc7.log xulchris fails-even-with-41/python-fpconst-0.7.3-1.fc8.log xulchris fails-even-with-41/SOAPpy-0.11.6-6.fc7.log xulchris header-dep/cal3d-0.11.0-4.fc7.log xulchris header-dep/osgcal-0.1.46-3.fc9.log xulchris header-dep/poker3d-1.1.36-7.fc9.log xulchris unsorted/osgal-0.6.1-2.fc9.log xulchris unsorted/poker2d-1.2.0-3.fc9.log xulchris unsorted/poker-network-1.2.0-4.fc9.log zhu header-dep/scim-hangul-0.3.1-1.fc7.log zhu header-dep/stardict-3.0.1-1.fc9.log zhu header-dep/zhcon-0.2.6-5.fc7.log zkota fails-even-with-41/python-bibtex-1.2.4-2.fc8.log zkota unsorted/recode-3.6-24.fc8.log zmc fails-even-with-41/dogtail-0.6.1-1.fc7.log zprikryl fails-even-with-41/apmd-3.2.2-6.log CU knued From wolfy at nobugconsulting.ro Thu Jan 3 13:52:04 2008 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Thu, 03 Jan 2008 15:52:04 +0200 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080103130138.GB20451@devserv.devel.redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <477CD6B0.7090203@gmail.com> <20080103130138.GB20451@devserv.devel.redhat.com> Message-ID: <477CE884.1010108@nobugconsulting.ro> One of my packages fails too: http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/unsorted/qfaxreader-0.3.1-8.fc8.1.log with: checking for QTDIR... found /usr/lib64/qt-3.3 checking QTDIR consistence... * qt.h... present (/usr/lib64/qt-3.3/include/qt.h) * libqt-mt.so... present (/usr/lib64/qt-3.3/lib/libqt-mt.so) * moc... present (/usr/lib64/qt-3.3/bin/moc) * uic... present (/usr/lib64/qt-3.3/bin/uic) checking for QT usability... not usable ******************************************************* Cannot compile a small application with qt library! Maybe qt is too old (minimum requirement is 3.x). Please check config.log for more information. ******************************************************* error: Bad exit status from /var/tmp/rpm-tmp.10621 (%build) I've just rebuilt it in mock for devel and F8/x86_64 without problems. Anything else I could do for testing except for using your gcc in order to debug the problem? Or maybe you could provide some more info,please ? From drago01 at gmail.com Thu Jan 3 13:53:12 2008 From: drago01 at gmail.com (drago01) Date: Thu, 03 Jan 2008 14:53:12 +0100 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080103130138.GB20451@devserv.devel.redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <477CD6B0.7090203@gmail.com> <20080103130138.GB20451@devserv.devel.redhat.com> Message-ID: <477CE8C8.4030907@gmail.com> Jakub Jelinek wrote: > On Thu, Jan 03, 2008 at 01:36:00PM +0100, drago01 wrote: > > >> Two of my packages are in this category: >> http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/unsorted/compiz-fusion-0.6.0-7.fc9.log >> and >> http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/unsorted/compiz-fusion-extras-0.6.0-1.fc9.log >> both fail with >> "checking how to run the C++ preprocessor... /lib/cpp >> >> configure: error: C++ preprocessor "/lib/cpp" fails sanity check >> See `config.log' for more details." >> > > [..] > etc. In C and with g++ <= 4.2 also C++ this yielded just warnings, > which configure ignored. Now in C++ it is a hard error unless -fpermissive. > Better fix the configury not to define VERSION twice. > > The same for the other package. > OK, thx. I have prepared a fix that I want to verify before sending it upstream but the build fails in a weird way: http://koji.fedoraproject.org/koji/getfile?taskID=321712&name=build.log It seems to stop before it even starts ... From j.w.r.degoede at hhs.nl Thu Jan 3 13:57:09 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 03 Jan 2008 14:57:09 +0100 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080103120242.GZ20451@devserv.devel.redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> Message-ID: <477CE9B5.6020500@hhs.nl> Jakub Jelinek wrote: > Hi! > > changesmeaning/vegastrike-0.4.3-7.fc8.log This one fails due to some errors in a boost-python header file, but boost itself isn't in the failed list?? Regards, Hans From drago01 at gmail.com Thu Jan 3 13:55:32 2008 From: drago01 at gmail.com (drago01) Date: Thu, 03 Jan 2008 14:55:32 +0100 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <477CE884.1010108@nobugconsulting.ro> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <477CD6B0.7090203@gmail.com> <20080103130138.GB20451@devserv.devel.redhat.com> <477CE884.1010108@nobugconsulting.ro> Message-ID: <477CE954.5000909@gmail.com> Manuel Wolfshant wrote: > One of my packages fails too: > > > http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/unsorted/qfaxreader-0.3.1-8.fc8.1.log > > with: > > checking for QTDIR... found /usr/lib64/qt-3.3 > checking QTDIR consistence... * qt.h... present > (/usr/lib64/qt-3.3/include/qt.h) > * libqt-mt.so... present (/usr/lib64/qt-3.3/lib/libqt-mt.so) > * moc... present (/usr/lib64/qt-3.3/bin/moc) > * uic... present (/usr/lib64/qt-3.3/bin/uic) > checking for QT usability... not usable > > ******************************************************* > Cannot compile a small application with qt library! > Maybe qt is too old (minimum requirement is 3.x). > Please check config.log for more information. > ******************************************************* > > error: Bad exit status from /var/tmp/rpm-tmp.10621 (%build) > > > I've just rebuilt it in mock for devel and F8/x86_64 without problems. > Anything else I could do for testing except for using your gcc in > order to debug the problem? Or maybe you could provide some more > info,please ? > You have to do a scratch build in dist-f9-gcc43 koji build --scratch dist-f9-gcc43 yoursrpm.rpm From drago01 at gmail.com Thu Jan 3 13:57:00 2008 From: drago01 at gmail.com (drago01) Date: Thu, 03 Jan 2008 14:57:00 +0100 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080103142956.0ad46f22@dhcp03.addix.net> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <20080103142956.0ad46f22@dhcp03.addix.net> Message-ID: <477CE9AC.8040109@gmail.com> Ralf Ertzinger wrote: > Hi. > > On Thu, 3 Jan 2008 07:02:42 -0500, Jakub Jelinek wrote: > > >> The remaining 507 failures only fail with gcc-4.3.0-0.4 and not with >> gcc-4.1.2-36, though most of them are just C++ being stricter, >> something that ought to be fixed in the packages. >> > > How do I test if a fix for a problem outlined below works? Is that > possible without installing 4.3 (which I'd rather avoid)? > > koji build --scratch dist-f9-gcc43 yoursrpm.rpm (but for me it does not work currently due to a weird bug; see my other mail) From christoph.wickert at nurfuerspam.de Thu Jan 3 14:00:07 2008 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Thu, 03 Jan 2008 15:00:07 +0100 Subject: gwget (Re: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220) In-Reply-To: <20080103120242.GZ20451@devserv.devel.redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> Message-ID: <1199368807.3673.4.camel@wicktop.localdomain> Am Donnerstag, den 03.01.2008, 07:02 -0500 schrieb Jakub Jelinek: > > Below just so that all package maintainers don't have to go to the above > www site to check for logs if their package is affected. > Prepend http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/ > to each line below to get at the log file. > ... > fails-even-with-41/gwget-0.99-3.fc8.log Thanks a lot for your work. I wonder what's wrong here: > ENTER do("bash -l -c 'rpmbuild -bs --target x86_64 --nodeps //builddir/build/SPECS/gwget.spec'", '/var/lib/mock/rawhide2/root/', 0, True, 0, , 500, 101, 'x86_64', logger=) > run cmd timeout(0): bash -l -c 'rpmbuild -bs --target x86_64 --nodeps //builddir/build/SPECS/gwget.spec' > /etc/profile: line 38: /bin/hostname: No such file or directory > Building target platforms: x86_64 > Building for target x86_64 > Wrote: /builddir/build/SRPMS/gwget-0.99-3.fc9.src.rpm > LEAVE do --> Yeah, that's all there is in http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/fails-even-with-41/gwget-0.99-3.fc8.log Ideas? Christoph From jakub at redhat.com Thu Jan 3 14:01:48 2008 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 3 Jan 2008 09:01:48 -0500 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <477CE9B5.6020500@hhs.nl> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <477CE9B5.6020500@hhs.nl> Message-ID: <20080103140148.GE20451@devserv.devel.redhat.com> On Thu, Jan 03, 2008 at 02:57:09PM +0100, Hans de Goede wrote: > Jakub Jelinek wrote: > >changesmeaning/vegastrike-0.4.3-7.fc8.log > > This one fails due to some errors in a boost-python header file, but boost > itself isn't in the failed list?? There is no boost-python, if you mean boost or python, both packages built just fine. Jakub From triad at df.lth.se Thu Jan 3 14:02:02 2008 From: triad at df.lth.se (Linus Walleij) Date: Thu, 3 Jan 2008 15:02:02 +0100 (CET) Subject: Policy proposal for compatibility packages In-Reply-To: <1199304674.16111.4.camel@kennedy> References: <1199290909.11035.20.camel@kennedy> <20080102105614.73d4db84@vader.jdub.homelinux.org> <1199301348.3483.2.camel@rousalka.dyndns.org> <477BE5EA.9020909@redhat.com> <1199304674.16111.4.camel@kennedy> Message-ID: On Wed, 2 Jan 2008, Brian Pepple wrote: >> - Third party applications which still depend on the old interface (that >> the maintainer is aware of specifically, not "something might use it >> someday") RHEL must have tons of these since that kind of stuff is what people buy it for. Perhaps someone working on it could tell us the most typical libs to crop up here, and were the RHEL work has been focused in this area? Linus From jakub at redhat.com Thu Jan 3 14:04:22 2008 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 3 Jan 2008 09:04:22 -0500 Subject: gwget (Re: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220) In-Reply-To: <1199368807.3673.4.camel@wicktop.localdomain> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <1199368807.3673.4.camel@wicktop.localdomain> Message-ID: <20080103140422.GF20451@devserv.devel.redhat.com> On Thu, Jan 03, 2008 at 03:00:07PM +0100, Christoph Wickert wrote: > > fails-even-with-41/gwget-0.99-3.fc8.log > > Thanks a lot for your work. I wonder what's wrong here: > > ENTER do("bash -l -c 'rpmbuild -bs --target x86_64 --nodeps //builddir/build/SPECS/gwget.spec'", '/var/lib/mock/rawhide2/root/', 0, True, 0, , 500, 101, 'x86_64', logger=) > > run cmd timeout(0): bash -l -c 'rpmbuild -bs --target x86_64 --nodeps //builddir/build/SPECS/gwget.spec' > > /etc/profile: line 38: /bin/hostname: No such file or directory > > Building target platforms: x86_64 > > Building for target x86_64 > > Wrote: /builddir/build/SRPMS/gwget-0.99-3.fc9.src.rpm > > LEAVE do --> > > Yeah, that's all there is in > http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/fails-even-with-41/gwget-0.99-3.fc8.log Such short build.log fails mean something went wrong already in root.log. In this case: DEBUG util.py:260: Error: Missing Dependency: gecko-devel = 1.8.1.10 is needed by package epiphany-devel DEBUG util.py:260: Error: Missing Dependency: gecko-libs = 1.8.1.10 is needed by package epiphany DEBUG util.py:260: Error: Missing Dependency: libgtkembedmoz.so()(64bit) is needed by package epiphany DEBUG util.py:260: Error: Missing Dependency: libxpcom_core.so()(64bit) is needed by package epiphany Remember this was 20071220 snapshot of rawhide, might have been fixed in later epiphany in the mean time. Jakub From triad at df.lth.se Thu Jan 3 14:16:59 2008 From: triad at df.lth.se (Linus Walleij) Date: Thu, 3 Jan 2008 15:16:59 +0100 (CET) Subject: Policy proposal for compatibility packages In-Reply-To: <1199317946.24135.14.camel@nixon> References: <1199290909.11035.20.camel@kennedy> <20080102105614.73d4db84@vader.jdub.homelinux.org> <1199301348.3483.2.camel@rousalka.dyndns.org> <477BE5EA.9020909@redhat.com> <20080102215010.GD2661@free.fr> <477C0FE7.60105@redhat.com> <20080102225303.GJ2661@free.fr> <1199316723.24135.2.camel@nixon> <20080102233619.GM2661@free.fr> <1199317946.24135.14.camel@nixon> Message-ID: I think Brians proposed policy is GOOD, and would like it approved by FESCO. Maintaining and spending endless time on compat-cruft is another thing that keep slowing down Debian/Ubuntu and is clearly a threat to Fedoras swift release-cycle. Paid support distros like RHEL can do this a lot better and have better motivation for. Linus From christoph.wickert at nurfuerspam.de Thu Jan 3 14:19:17 2008 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Thu, 03 Jan 2008 15:19:17 +0100 Subject: gwget (Re: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220) In-Reply-To: <20080103140422.GF20451@devserv.devel.redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <1199368807.3673.4.camel@wicktop.localdomain> <20080103140422.GF20451@devserv.devel.redhat.com> Message-ID: <1199369958.3673.7.camel@wicktop.localdomain> Am Donnerstag, den 03.01.2008, 09:04 -0500 schrieb Jakub Jelinek: > On Thu, Jan 03, 2008 at 03:00:07PM +0100, Christoph Wickert wrote: > > > fails-even-with-41/gwget-0.99-3.fc8.log > > > > Thanks a lot for your work. I wonder what's wrong here: > > > ENTER do("bash -l -c 'rpmbuild -bs --target x86_64 --nodeps //builddir/build/SPECS/gwget.spec'", '/var/lib/mock/rawhide2/root/', 0, True, 0, , 500, 101, 'x86_64', logger=) > > > run cmd timeout(0): bash -l -c 'rpmbuild -bs --target x86_64 --nodeps //builddir/build/SPECS/gwget.spec' > > > /etc/profile: line 38: /bin/hostname: No such file or directory > > > Building target platforms: x86_64 > > > Building for target x86_64 > > > Wrote: /builddir/build/SRPMS/gwget-0.99-3.fc9.src.rpm > > > LEAVE do --> > > > > Yeah, that's all there is in > > http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/fails-even-with-41/gwget-0.99-3.fc8.log > > Such short build.log fails mean something went wrong already > in root.log. In this case: > DEBUG util.py:260: Error: Missing Dependency: gecko-devel = 1.8.1.10 is needed by package epiphany-devel > DEBUG util.py:260: Error: Missing Dependency: gecko-libs = 1.8.1.10 is needed by package epiphany > DEBUG util.py:260: Error: Missing Dependency: libgtkembedmoz.so()(64bit) is needed by package epiphany > DEBUG util.py:260: Error: Missing Dependency: libxpcom_core.so()(64bit) is needed by package epiphany > Remember this was 20071220 snapshot of rawhide, might have been fixed in > later epiphany in the mean time. Thanks A LOT, Jakub! Will look at my two remaining packages later today Christoph From jwboyer at gmail.com Thu Jan 3 14:22:11 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 3 Jan 2008 08:22:11 -0600 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080103133014.GD20451@devserv.devel.redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <20080103071133.1952dece@hansolo.jdub.homelinux.org> <20080103133014.GD20451@devserv.devel.redhat.com> Message-ID: <20080103082211.6fe42af0@vader.jdub.homelinux.org> On Thu, 3 Jan 2008 08:30:14 -0500 Jakub Jelinek wrote: > On Thu, Jan 03, 2008 at 07:11:33AM -0600, Josh Boyer wrote: > > On Thu, 3 Jan 2008 07:02:42 -0500 > > Jakub Jelinek wrote: > > > > > > > fails-even-with-41/powerpc-utils-1.0.6-2.fc9.log > error: Architecture is not included: x86_64 > > > fails-even-with-41/powerpc-utils-papr-1.0.4-2.fc9.log > DEBUG util.py:260: No Package Found for librtas-devel > (but has ExclusiveArch: ppc ppc64 anyway, so even if librtas-devel was > included, it would fail to build anyway). > > > fails-even-with-41/ppc64-utils-0.14-1.fc9.log > error: Architecture is not included: x86_64 > > > fails-even-with-41/ps3pf-utils-2.1-1.fc9.log > error: Architecture is not included: x86_64 > > > These seem like bogus results. Looking at the logs, you might have hit > > some mock/builder problems that were being seen a while ago. > > I said that fails-even-with-41 includes even ExcludeArched packages > and that the build was on x86_64. As for me fails-even-with-41 > category is DONTCARE, I haven't spent time to categorize them further. Ok, fair enough. I just did scratch builds on the gcc43 tag for all three and they built fine. You can take them off your list. josh From drago01 at gmail.com Thu Jan 3 14:23:55 2008 From: drago01 at gmail.com (drago01) Date: Thu, 03 Jan 2008 15:23:55 +0100 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080103141558.GA27040@host0.dyn.jankratochvil.net> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <477CD6B0.7090203@gmail.com> <20080103130138.GB20451@devserv.devel.redhat.com> <477CE8C8.4030907@gmail.com> <20080103141558.GA27040@host0.dyn.jankratochvil.net> Message-ID: <477CEFFB.30406@gmail.com> Jan Kratochvil wrote: > On Thu, 03 Jan 2008 14:53:12 +0100, drago01 wrote: > ... > >> http://koji.fedoraproject.org/koji/getfile?taskID=321712&name=build.log >> It seems to stop before it even starts ... >> > > Please try there adding: > BuildRequires: net-tools > this won't help it seems to fail due to an error in root.log "Error: Missing Dependency: libgcj.so.8rh is needed by package gettext-devel" (the hostname _warnings_ do not cause the build to fail.) but thx anyway. From jkeating at redhat.com Thu Jan 3 14:28:57 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 3 Jan 2008 09:28:57 -0500 Subject: Policy proposal for compatibility packages In-Reply-To: References: <1199290909.11035.20.camel@kennedy> <20080102105614.73d4db84@vader.jdub.homelinux.org> <1199301348.3483.2.camel@rousalka.dyndns.org> <477BE5EA.9020909@redhat.com> <1199304674.16111.4.camel@kennedy> Message-ID: <20080103092857.0db835c3@redhat.com> On Thu, 3 Jan 2008 15:02:02 +0100 (CET) Linus Walleij wrote: > RHEL must have tons of these since that kind of stuff is what people > buy it for. Perhaps someone working on it could tell us the most > typical libs to crop up here, and were the RHEL work has been focused > in this area? RHEL also grants you the right to install /any/ RHEL version with your entitlement, so if you need to run software from an older era, you can actually run the older (and still supported) RHEL release from then. All the way back to RHEL2.1. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at camperquake.de Thu Jan 3 14:42:29 2008 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 3 Jan 2008 15:42:29 +0100 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <477CE9AC.8040109@gmail.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <20080103142956.0ad46f22@dhcp03.addix.net> <477CE9AC.8040109@gmail.com> Message-ID: <20080103154229.367ef75e@dhcp03.addix.net> Hi. On Thu, 03 Jan 2008 14:57:00 +0100, drago01 wrote: > koji build --scratch dist-f9-gcc43 yoursrpm.rpm > (but for me it does not work currently due to a weird bug; see my > other mail) Thanks, will try. From pertusus at free.fr Thu Jan 3 14:42:35 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 3 Jan 2008 15:42:35 +0100 Subject: Policy proposal for compatibility packages In-Reply-To: References: <20080102105614.73d4db84@vader.jdub.homelinux.org> <1199301348.3483.2.camel@rousalka.dyndns.org> <477BE5EA.9020909@redhat.com> <20080102215010.GD2661@free.fr> <477C0FE7.60105@redhat.com> <20080102225303.GJ2661@free.fr> <1199316723.24135.2.camel@nixon> <20080102233619.GM2661@free.fr> <1199317946.24135.14.camel@nixon> Message-ID: <20080103144235.GB2713@free.fr> On Thu, Jan 03, 2008 at 03:16:59PM +0100, Linus Walleij wrote: > I think Brians proposed policy is GOOD, and would like it approved by > FESCO. > > Maintaining and spending endless time on compat-cruft is another thing that > keep slowing down Debian/Ubuntu and is clearly a threat to Fedoras swift > release-cycle. Paid support distros like RHEL can do this a lot better and > have better motivation for. Why not let the packagers decide for themselves? Packagers should decide on their own how the spend their time best. This should not be in the scope of FESCO. I can't really see how compat-packages could be a threat to Fedoras release cycles. Not trusting packagers is a threat for fedora. -- Pat From j.w.r.degoede at hhs.nl Thu Jan 3 14:45:34 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 03 Jan 2008 15:45:34 +0100 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080103140148.GE20451@devserv.devel.redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <477CE9B5.6020500@hhs.nl> <20080103140148.GE20451@devserv.devel.redhat.com> Message-ID: <477CF50E.7000408@hhs.nl> Jakub Jelinek wrote: > On Thu, Jan 03, 2008 at 02:57:09PM +0100, Hans de Goede wrote: >> Jakub Jelinek wrote: >>> changesmeaning/vegastrike-0.4.3-7.fc8.log >> This one fails due to some errors in a boost-python header file, but boost >> itself isn't in the failed list?? > > There is no boost-python, if you mean boost or python, both packages built > just fine. > I mean the pythonpbindings part of boost, sorry for being unclear, more precise the I mean /usr/lib64/libboost_python.so.3 and its headers. Those headers seem to be the problem, quoting from: http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/changesmeaning/vegastrike-0.4.3-7.fc8.log In file included from /usr/include/boost/python/class.hpp:29, from ../../../src/python/python_class.h:17, from hard_coded_scripts.cpp:9: /usr/include/boost/python/detail/def_helper.hpp:192: error: declaration of 'typename boost::python::detail::keyword_extract, const char*, void (boost::python::detail::not_specified::*)(), boost::tuples::null_type, boost::tuples::null_type> >::result_type boost::python::detail::def_helper::keywords() const' /usr/include/boost/python/args_fwd.hpp:35: error: changes meaning of 'keywords' from 'struct boost::python::detail::keywords<0ul>' I may be misinterpreting the error, but to mean it seems some conflict between a boost/python header and another boost/python header. Appearantly in a combo not used when compiling boost itself. Thanks & Regards, Hans From j.w.r.degoede at hhs.nl Thu Jan 3 14:51:16 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 03 Jan 2008 15:51:16 +0100 Subject: gwget (Re: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220) In-Reply-To: <1199369958.3673.7.camel@wicktop.localdomain> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <1199368807.3673.4.camel@wicktop.localdomain> <20080103140422.GF20451@devserv.devel.redhat.com> <1199369958.3673.7.camel@wicktop.localdomain> Message-ID: <477CF664.5070207@hhs.nl> Christoph Wickert wrote: > Am Donnerstag, den 03.01.2008, 09:04 -0500 schrieb Jakub Jelinek: >> On Thu, Jan 03, 2008 at 03:00:07PM +0100, Christoph Wickert wrote: >>>> fails-even-with-41/gwget-0.99-3.fc8.log >>> Thanks a lot for your work. I wonder what's wrong here: >>>> ENTER do("bash -l -c 'rpmbuild -bs --target x86_64 --nodeps //builddir/build/SPECS/gwget.spec'", '/var/lib/mock/rawhide2/root/', 0, True, 0, , 500, 101, 'x86_64', logger=) >>>> run cmd timeout(0): bash -l -c 'rpmbuild -bs --target x86_64 --nodeps //builddir/build/SPECS/gwget.spec' >>>> /etc/profile: line 38: /bin/hostname: No such file or directory >>>> Building target platforms: x86_64 >>>> Building for target x86_64 >>>> Wrote: /builddir/build/SRPMS/gwget-0.99-3.fc9.src.rpm >>>> LEAVE do --> >>> Yeah, that's all there is in >>> http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/fails-even-with-41/gwget-0.99-3.fc8.log >> Such short build.log fails mean something went wrong already >> in root.log. In this case: >> DEBUG util.py:260: Error: Missing Dependency: gecko-devel = 1.8.1.10 is needed by package epiphany-devel >> DEBUG util.py:260: Error: Missing Dependency: gecko-libs = 1.8.1.10 is needed by package epiphany >> DEBUG util.py:260: Error: Missing Dependency: libgtkembedmoz.so()(64bit) is needed by package epiphany >> DEBUG util.py:260: Error: Missing Dependency: libxpcom_core.so()(64bit) is needed by package epiphany >> Remember this was 20071220 snapshot of rawhide, might have been fixed in >> later epiphany in the mean time. > > Thanks A LOT, Jakub! > > Will look at my two remaining packages later today > You've only got 3 failing packages you are so lucky! I started with 45 and I'm down to 43 now, anyone care to help? Maybe we should have a session on tomorrows hackfest for fixing gcc34 related build failures? Preferably starting with mine :) Regards, Hans From jakub at redhat.com Thu Jan 3 14:50:25 2008 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 3 Jan 2008 09:50:25 -0500 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <477CE8C8.4030907@gmail.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <477CD6B0.7090203@gmail.com> <20080103130138.GB20451@devserv.devel.redhat.com> <477CE8C8.4030907@gmail.com> Message-ID: <20080103145025.GG20451@devserv.devel.redhat.com> On Thu, Jan 03, 2008 at 02:53:12PM +0100, drago01 wrote: > OK, thx. I have prepared a fix that I want to verify before sending it > upstream but the build fails in a weird way: > http://koji.fedoraproject.org/koji/getfile?taskID=321712&name=build.log > It seems to stop before it even starts ... There is also root.log, which says: DEBUG util.py:260: Error: Missing Dependency: libgcj.so.8rh is needed by package gettext-devel The rebuilds I did were also with rebuilt gettext in the buildroots, but I'm not sure what's a feasible solution for dist-f9-gcc43. Perhaps the best would be to compile/link the Java programs with -findirect-dispatch, then they will be independent from libgcj.so.* version of the day and rely on libgcj_bc.so which isn't changing. Jakub From silfreed at silfreed.net Thu Jan 3 14:50:09 2008 From: silfreed at silfreed.net (Douglas E. Warner) Date: Thu, 3 Jan 2008 09:50:09 -0500 Subject: GPG Keysigning at FUDCon In-Reply-To: <20080103024423.GL8896@inocybe.teonanacatl.org> References: <20071212214010.GA20896@auslistsprd01.us.dell.com> <20080103024423.GL8896@inocybe.teonanacatl.org> Message-ID: <200801030950.10063.silfreed@silfreed.net> On Wednesday 02 January 2008, Todd Zullinger wrote: > > I'm volunteering to run a GPG keysigning party at the FUDCon in > > Raleigh in January. > > And thank you for that Matt. ?It should be fun. Is there going to be any tequila at the keysigning? [1] -Doug [1] http://xkcd.com/364/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From jkeating at redhat.com Thu Jan 3 14:47:57 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 3 Jan 2008 09:47:57 -0500 Subject: Policy proposal for compatibility packages In-Reply-To: <20080103144235.GB2713@free.fr> References: <20080102105614.73d4db84@vader.jdub.homelinux.org> <1199301348.3483.2.camel@rousalka.dyndns.org> <477BE5EA.9020909@redhat.com> <20080102215010.GD2661@free.fr> <477C0FE7.60105@redhat.com> <20080102225303.GJ2661@free.fr> <1199316723.24135.2.camel@nixon> <20080102233619.GM2661@free.fr> <1199317946.24135.14.camel@nixon> <20080103144235.GB2713@free.fr> Message-ID: <20080103094757.68bf7955@redhat.com> On Thu, 3 Jan 2008 15:42:35 +0100 Patrice Dumas wrote: > Why not let the packagers decide for themselves? Packagers should > decide on their own how the spend their time best. This should not be > in the scope of FESCO. > > I can't really see how compat-packages could be a threat to Fedoras > release cycles. > > Not trusting packagers is a threat for fedora. When those compat packages start failing to rebuild, that slows us down. When too many of our packages rely on those compat packages, that slows us down. When the package maintainer for the non-compat package gets bogged down with bug reports and requests for assistance with the -compat package problems that slows us down. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Thu Jan 3 15:01:55 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 03 Jan 2008 16:01:55 +0100 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080103120242.GZ20451@devserv.devel.redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> Message-ID: <477CF8E3.6050907@hhs.nl> Jakub, Any chance you could explain this one to me: http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/fails-even-with-41/machineball-1.0-4.fc8.log In file included from /usr/include/allegrogl/gl_ext.h:27, from /usr/include/alleggl.h:68, from menu.cpp:12: /usr/include/allegrogl/GLext/gl_ext_api.h:1827: error: '' has incomplete type /usr/include/allegrogl/GLext/gl_ext_api.h:1827: error: invalid use of 'GLvoid' I just tried to build the rawhide machineball sources on F-8 and there they work fine. The offending line in /usr/include/allegrogl/GLext/gl_ext_api.h is: AGL_API(void, EndTransformFeedbackNV, (GLvoid)) Which basically translates to: void EndTransformFeedbackNV(GLvoid); And GLvoid is defined in: /usr/include/GL/gl.h, which gets included by /usr/include/alleggl.h before including /usr/include/allegrogl/gl_ext.h. GLvoid is defined as: typedef void GLvoid; The only reason I can see for this not working is that: /usr/include/alleggl.h Does not declare the prototypes in it and its included files as extern "C" { Could that explain this? Strange though that this breaks between gcc-4.1.2-33, and gcc-4.1.2-36 Thanks & Regards, Hans From denis at poolshark.org Thu Jan 3 15:03:39 2008 From: denis at poolshark.org (Denis Leroy) Date: Thu, 03 Jan 2008 16:03:39 +0100 Subject: Policy proposal for compatibility packages In-Reply-To: <20080103094757.68bf7955@redhat.com> References: <20080102105614.73d4db84@vader.jdub.homelinux.org> <1199301348.3483.2.camel@rousalka.dyndns.org> <477BE5EA.9020909@redhat.com> <20080102215010.GD2661@free.fr> <477C0FE7.60105@redhat.com> <20080102225303.GJ2661@free.fr> <1199316723.24135.2.camel@nixon> <20080102233619.GM2661@free.fr> <1199317946.24135.14.camel@nixon> <20080103144235.GB2713@free.fr> <20080103094757.68bf7955@redhat.com> Message-ID: <477CF94B.5090108@poolshark.org> Jesse Keating wrote: > On Thu, 3 Jan 2008 15:42:35 +0100 > Patrice Dumas wrote: > >> Why not let the packagers decide for themselves? Packagers should >> decide on their own how the spend their time best. This should not be >> in the scope of FESCO. >> >> I can't really see how compat-packages could be a threat to Fedoras >> release cycles. >> >> Not trusting packagers is a threat for fedora. > > When those compat packages start failing to rebuild, that slows us > down. When too many of our packages rely on those compat packages, > that slows us down. When the package maintainer for the non-compat > package gets bogged down with bug reports and requests for assistance > with the -compat package problems that slows us down. Well this isn't really specific to compat packages... From pertusus at free.fr Thu Jan 3 15:11:46 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 3 Jan 2008 16:11:46 +0100 Subject: Policy proposal for compatibility packages In-Reply-To: <20080103094757.68bf7955@redhat.com> References: <477BE5EA.9020909@redhat.com> <20080102215010.GD2661@free.fr> <477C0FE7.60105@redhat.com> <20080102225303.GJ2661@free.fr> <1199316723.24135.2.camel@nixon> <20080102233619.GM2661@free.fr> <1199317946.24135.14.camel@nixon> <20080103144235.GB2713@free.fr> <20080103094757.68bf7955@redhat.com> Message-ID: <20080103151146.GC2713@free.fr> On Thu, Jan 03, 2008 at 09:47:57AM -0500, Jesse Keating wrote: > On Thu, 3 Jan 2008 15:42:35 +0100 > Patrice Dumas wrote: > > > Why not let the packagers decide for themselves? Packagers should > > decide on their own how the spend their time best. This should not be > > in the scope of FESCO. > > > > I can't really see how compat-packages could be a threat to Fedoras > > release cycles. > > > > Not trusting packagers is a threat for fedora. > > When those compat packages start failing to rebuild, that slows us > down. Hopefully there are procedures to avoid being slowed down by packages that don't rebuild. I don't think that compat packages are th emain packages not rebuilding, unmaintained packages are. > When too many of our packages rely on those compat packages, That is another issue. I am all for policy that discourages shipping packages in fedora that use compat packages. > that slows us down. When the package maintainer for the non-compat > package gets bogged down with bug reports and requests for assistance > with the -compat package problems that slows us down. That is a real issue, however the compat package maintainer should take care of those bugs and the primary maintainer can, like anyone else and like any other review object to the review. -- Pat From triad at df.lth.se Thu Jan 3 15:28:10 2008 From: triad at df.lth.se (Linus Walleij) Date: Thu, 3 Jan 2008 16:28:10 +0100 (CET) Subject: Policy proposal for compatibility packages In-Reply-To: <20080103144235.GB2713@free.fr> References: <20080102105614.73d4db84@vader.jdub.homelinux.org> <1199301348.3483.2.camel@rousalka.dyndns.org> <477BE5EA.9020909@redhat.com> <20080102215010.GD2661@free.fr> <477C0FE7.60105@redhat.com> <20080102225303.GJ2661@free.fr> <1199316723.24135.2.camel@nixon> <20080102233619.GM2661@free.fr> <1199317946.24135.14.camel@nixon> <20080103144235.GB2713@free.fr> Message-ID: On Thu, 3 Jan 2008, Patrice Dumas wrote: > Why not let the packagers decide for themselves? It's just a policy, it's not Gods commandments. As a policy, we don't publish a plethora of compat-cruft. We (individual packagers) compromise any time we like as usual, and a maintainer with a soft spot for a certain compat-package can probably maintain it without problems. I see it more like a guideline to the developer who is to make a decision: must I publish a compat-package or can I just discard the old API? Given some harsh words every here and there on breaking APIs you could easily get that impression. And then s/he knows that in Fedora, we love to discard old API:s. So our community attracts people with this mindset and so forth. Linus From jakub.rusinek at gmail.com Thu Jan 3 15:28:30 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Thu, 03 Jan 2008 16:28:30 +0100 Subject: Control center idea Message-ID: <1199374110.5023.2.camel@frosty> Hi, I have written wiki draft page [1] about control center idea in Fedora. 1| http://fedoraproject.org/wiki/JakubRusinek/DRAFT%FedoraControlCenter -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? wiadomo?ci podpisana cyfrowo URL: From pertusus at free.fr Thu Jan 3 15:40:05 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 3 Jan 2008 16:40:05 +0100 Subject: Policy proposal for compatibility packages In-Reply-To: References: <477BE5EA.9020909@redhat.com> <20080102215010.GD2661@free.fr> <477C0FE7.60105@redhat.com> <20080102225303.GJ2661@free.fr> <1199316723.24135.2.camel@nixon> <20080102233619.GM2661@free.fr> <1199317946.24135.14.camel@nixon> <20080103144235.GB2713@free.fr> Message-ID: <20080103154005.GC3997@free.fr> On Thu, Jan 03, 2008 at 04:28:10PM +0100, Linus Walleij wrote: > On Thu, 3 Jan 2008, Patrice Dumas wrote: > >> Why not let the packagers decide for themselves? > > I see it more like a guideline to the developer who is to make a decision: > must I publish a compat-package or can I just discard the old API? Given > some harsh words every here and there on breaking APIs you could easily get > that impression. And then s/he knows that in Fedora, we love to discard old > API:s. I hope it is untrue. I hope everybody here dislikes breaking API and ABIs and try to push the upstreams to be responsible with API/ABI. But still, I also hope that for our packages in fedora we don't fear breaking API/ABI and prefer that to stay with old library used in our packages. But notice the difference between our packages and libraries used by our users. > So our community attracts people with this mindset and so forth. Do we really want to attract people that don't care about API/ABI compatibility? I hope not. What would be innovative in linux would be to use libraries that keep ABI and API compatibility (like how, for example, gnome and libc do very well). Also remember that fedora is also for RHEL and EPEL dowstream, so having people that care about innovation and compatibility would be even more nice. -- Pat From opensource at till.name Thu Jan 3 15:40:26 2008 From: opensource at till.name (Till Maas) Date: Thu, 03 Jan 2008 16:40:26 +0100 Subject: f8 gripe #3: infamous Load_Cycle_Count started hitting my laptop, FAQ? In-Reply-To: <477C2190.7000608@filteredperception.org> References: <477AE01A.6060302@filteredperception.org> <200801021518.48123.opensource@till.name> <477C2190.7000608@filteredperception.org> Message-ID: <200801031640.30369.opensource@till.name> On Do Januar 3 2008, Douglas McClendon wrote: > Thanks, that looks like it will work for me. Just for complete > reference, here is an ubuntu bug, in which it is mentioned that for some > reason 255 doesn't work for everyone (thus _maybe_ 254 is a better default) 255 is not a default value, but the value that is used when the script detects, that there is apm support in the hd, but it is disabled. When it is enabled it tries to get the current value and stores it, in case it cannot get a value, the user needs to define one manually in the config file. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From sundaram at fedoraproject.org Thu Jan 3 15:32:43 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 03 Jan 2008 21:02:43 +0530 Subject: Control center idea In-Reply-To: <1199374110.5023.2.camel@frosty> References: <1199374110.5023.2.camel@frosty> Message-ID: <477D001B.8090203@fedoraproject.org> Jakub 'Livio' Rusinek wrote: > Hi, > > I have written wiki draft page [1] about control center idea in Fedora. > > > > 1| http://fedoraproject.org/wiki/JakubRusinek/DRAFT%FedoraControlCenter If you are willing to maintain it, there is system-config-control available at http://www.indianoss.org/modules/wfdownloads/viewcat.php?cid=10 If you are interested in maintaining Yast, a port of it for RHEL is available at which should work on Fedora too with possibly minor changes. http://oss.oracle.com/projects/yast/ Rahul From bkoz at redhat.com Thu Jan 3 15:57:55 2008 From: bkoz at redhat.com (Benjamin Kosnik) Date: Thu, 3 Jan 2008 09:57:55 -0600 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080103123725.GA20451@devserv.devel.redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <20080103123725.GA20451@devserv.devel.redhat.com> Message-ID: <20080103095755.51bb7cb1@wabash.artheist.org> > Small correction here, std::auto_ptr is still in in > -std=c++98 mode, it has been deprecated just in -std=c++0x mode from > what I see. So the above 3 failures are something else, perhaps some > header which unintentionally included no longer does or > something. Right. I'm most interested in Pre-ISO header issues, and the dep streamlining fallout. This part seems to be actually pretty minor, which is encouraging to me. I'm going to organize some of your build info (esp changed warning/errors in compilation) with some data I have from Debian, and put it up on the gcc website in the form of a Porting to gcc-4.3 wiki page. I will send link as soon as it's up. However, I am in a bit of a transition right now WRT my physical location and may not be able to get to something coherent before Friday. Thanks again for doing this. best, benjamin From mdehaan at redhat.com Thu Jan 3 16:10:39 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 03 Jan 2008 11:10:39 -0500 Subject: FUDCon Hackfests In-Reply-To: <1199332309.3921.57.camel@cutter> References: <1b7401870801021950n286bb3bdxb1bc7e32b4bf45de@mail.gmail.com> <1199332309.3921.57.camel@cutter> Message-ID: <477D08FF.4090608@redhat.com> seth vidal wrote: > On Wed, 2008-01-02 at 22:50 -0500, Josef Bacik wrote: > >> Hello, >> >> Just curious about what exactly is entailed in a hackfest? For >> example I plan on going to the kernel hackfest, do I need my laptop >> for actual "hacking" or is it more of a bird of a feather type thing >> like at OLS? Thanks much, >> > > hackfest: sit in a room with a bunch of other people and actually work > on code. > > -sv > > > They'll be plenty of ideas/design/whiteboard kind of stuff also -- so if you prefer that (which I always do when there's a crowd), they'll be that too. --Michael From poelstra at redhat.com Thu Jan 3 17:07:18 2008 From: poelstra at redhat.com (John Poelstra) Date: Thu, 03 Jan 2008 09:07:18 -0800 Subject: GPG Keysigning at FUDCon In-Reply-To: <1199353983.13378.1.camel@rousalka.dyndns.org> References: <20071212214010.GA20896@auslistsprd01.us.dell.com> <477C3AA7.9010700@redhat.com> <1199353983.13378.1.camel@rousalka.dyndns.org> Message-ID: <477D1646.6080207@redhat.com> Nicolas Mailhot said the following on 01/03/2008 01:53 AM Pacific Time: > Le mercredi 02 janvier 2008 ? 17:30 -0800, John Poelstra a ?crit : > >> My key has expired and it is also associated with my Fedora account >> which raises a few questions > > You can easily extend the validity of a key which has expired. This way > you get the security of a key that does hara-kiri after a while if you > lose it, and the convenience of a stable long-term key. > > Regards, > > Correct :) I looked into it more and changed the expiration by: 1) gpg --edit and then option "expire" 2) gpg --keyserver pgp.mit.edu --send-keys to make change public From rjones at redhat.com Thu Jan 3 17:08:43 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 03 Jan 2008 17:08:43 +0000 Subject: rawhide report: 20080103 changes In-Reply-To: <200801031254.m03CsbAF032597@porkchop.devel.redhat.com> References: <200801031254.m03CsbAF032597@porkchop.devel.redhat.com> Message-ID: <477D169B.9000800@redhat.com> Build System wrote: > ocaml-labltk - 3.10.0-7.fc8.ppc requires libtk8.4.so > ocaml-labltk - 3.10.0-7.fc8.ppc requires libtcl8.4.so [Reminder to self to check that this package can be built with the new tcl/tk 8.5 that just went in] Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From loupgaroublond at gmail.com Thu Jan 3 17:26:24 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 3 Jan 2008 12:26:24 -0500 Subject: Fedora 9 Feature Status In-Reply-To: <477C915E.4080402@redhat.com> References: <477C915E.4080402@redhat.com> Message-ID: <7f692fec0801030926o483d1a37w3d02e30a41388dc@mail.gmail.com> On Jan 3, 2008 2:40 AM, John Poelstra wrote: > In order to have your feature accepted for Fedora 9 it does not have to > be fully complete at this time. A completed feature page (all > sections--including "not applicable" as necessary) is needed by so that > FESCo has all the information it needs for consideration. Curiously enough, you wrote that GoodHaskellSupport needs a few more sections filled in. Which sections are they? -Yaakov From mtasaka at ioa.s.u-tokyo.ac.jp Thu Jan 3 17:44:30 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Fri, 04 Jan 2008 02:44:30 +0900 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080103120242.GZ20451@devserv.devel.redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> Message-ID: <477D1EFE.9090005@ioa.s.u-tokyo.ac.jp> Hi! Jakub Jelinek wrote, at 01/03/2008 09:02 PM +9:00: > Hi! > > I've rebuilt 5118 rawhide-20071220 src.rpms on x86_64 in mock buildroots which > contained rawhide-20071220 except {gcc,lib}*-4.1.2-36.*.rpm, with additional > gcc-4.3.0-0.4 (available from koji, dist-f9-gcc43 component), > > The remaining 507 failures only fail with gcc-4.3.0-0.4 and not with > gcc-4.1.2-36, though most of them are just C++ being stricter, something > that ought to be fixed in the packages. > > I've tried to quickly grep through the failed logs and categorize them: > > 269 http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/header-dep/ > libstdc++ header dependencies have been streamlined, reducing > unnecessary includes and pre-processed bloat. > The STL headers have been cleaned up, so that the headers > don't drag in unnecessary dependencies which aren't requested > by the standard. E.g. no longer includes , > etc. Most of these bugs will be fixed just by including the > proper headers, , , are the most > common ones I guess. > > header-dep/xplanet-1.2.0-2.1.fc8.2.log I tried to fix this by including some header files, however when I add "#include " I got some strange errors. http://koji.fedoraproject.org/koji/getfile?taskID=322318&name=build.log How can I fix this? The srpm of this can be found on: http://koji.fedoraproject.org/scratch/mtasaka/task_322411/xplanet-1.2.0-3.fc9.src.rpm Regards, Mamoru From lsof at nodata.co.uk Thu Jan 3 17:45:16 2008 From: lsof at nodata.co.uk (nodata) Date: Thu, 03 Jan 2008 18:45:16 +0100 Subject: f8 gripe#2: why did f8's pm-hibernate regress? In-Reply-To: <477C96B8.6040903@filteredperception.org> References: <477ADF46.2040108@filteredperception.org> <200801021159.17964.opensource@till.name> <477C299D.2060400@filteredperception.org> <477C96B8.6040903@filteredperception.org> Message-ID: <1199382316.3261.7.camel@sb-home> Am Donnerstag, den 03.01.2008, 02:03 -0600 schrieb Douglas McClendon: > Douglas McClendon wrote: > > [ pro-tux-on-ice rant snipped ] > > > might be time for me to go back to tux-on-ice. I truly am disgusted by > > having to suffer through 5-15 seconds of thrashing while changing > > desktops after resume. I would much rather the resume take 20 seconds > > longer, and present me with a good user experience. (yes, I am one of > > those people that thinks that offering early login while the system > > finishes booting is a really stupid thing). > > To clarify this harsh, theoretically offensive statement- Early login > done _right_ would be fine. Doing it the incomplete way, such as the > vista experience, I don't know why people keep saying this. Vista boots fast and is responsive. > is IMO a regression, not a feature. I.e. it boggles > my mind that fast boot-to-login time is perceived as so valuable, that > the implementers will let a user's first experience with the system be > at its absolute valley(anti-peak) responsiveness phase. > > I guess for early login this isn't so bad, as people just learn that the > fast boot time is an illusion and that it's better to sit back and let > the system IO settle before using it. But what started my rant was the > swsusp choice, which is not workaroundable by just letting the system IO > settle. > > and the 5-15 seconds was a bit of an exageration, more like 5-10. But > still, evocative of winblowz 3.1 swap thrashing.... > > > > -dmc > From poelstra at redhat.com Thu Jan 3 17:56:36 2008 From: poelstra at redhat.com (John Poelstra) Date: Thu, 03 Jan 2008 09:56:36 -0800 Subject: Fedora 9 Feature Status In-Reply-To: <7f692fec0801030926o483d1a37w3d02e30a41388dc@mail.gmail.com> References: <477C915E.4080402@redhat.com> <7f692fec0801030926o483d1a37w3d02e30a41388dc@mail.gmail.com> Message-ID: <477D21D4.4060604@redhat.com> Yaakov Nemoy said the following on 01/03/2008 09:26 AM Pacific Time: > On Jan 3, 2008 2:40 AM, John Poelstra wrote: >> In order to have your feature accepted for Fedora 9 it does not have to >> be fully complete at this time. A completed feature page (all >> sections--including "not applicable" as necessary) is needed by so that >> FESCo has all the information it needs for consideration. > > Curiously enough, you wrote that GoodHaskellSupport needs a few more > sections filled in. Which sections are they? > > -Yaakov > "User Experience" and "Release Notes" are incomplete. John From green at redhat.com Thu Jan 3 18:05:34 2008 From: green at redhat.com (Anthony Green) Date: Thu, 03 Jan 2008 10:05:34 -0800 Subject: common-lisp-controller for Fedora In-Reply-To: <477BB850.4020005@math.unl.edu> References: <47325E81.4010706@redhat.com> <1199289856.2308.15.camel@localhost.localdomain> <477BB850.4020005@math.unl.edu> Message-ID: <477D23EE.8080204@redhat.com> Rex Dieter wrote: > I'm certainly for the idea, it's a good one, but I doubt I'll personally > have much time or lisp-aptitude to help much. I've submitted a couple of packages. I'll start modifying sbcl and friends once these are accepted. Please review if you have time... https://bugzilla.redhat.com/show_bug.cgi?id=427411 Thanks, AG From green at redhat.com Thu Jan 3 18:07:55 2008 From: green at redhat.com (Anthony Green) Date: Thu, 03 Jan 2008 10:07:55 -0800 Subject: common-lisp-controller for Fedora In-Reply-To: <7f692fec0801021321x6b28c0e5rcea79ff0f10a3bfe@mail.gmail.com> References: <47325E81.4010706@redhat.com> <1199289856.2308.15.camel@localhost.localdomain> <477BB850.4020005@math.unl.edu> <7f692fec0801021321x6b28c0e5rcea79ff0f10a3bfe@mail.gmail.com> Message-ID: <477D247B.4090406@redhat.com> Yaakov Nemoy wrote: > WHere do you go for comaintainership? I am looking to do a similar > thing for Haskell packages. I just applied for all of the available rights on the package db. https://admin.fedoraproject.org/pkgdb/ AG From tibbs at math.uh.edu Thu Jan 3 18:11:25 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 03 Jan 2008 12:11:25 -0600 Subject: Fedora 9 Feature Status In-Reply-To: <7f692fec0801030926o483d1a37w3d02e30a41388dc@mail.gmail.com> References: <477C915E.4080402@redhat.com> <7f692fec0801030926o483d1a37w3d02e30a41388dc@mail.gmail.com> Message-ID: >>>>> "YN" == Yaakov Nemoy writes: YN> Curiously enough, you wrote that GoodHaskellSupport needs a few YN> more sections filled in. Which sections are they? Personally I'd like to see "Packaging Guidelines" moved up from "Dependencies" to an actual action item. Because it's really a prerequisite to actually moving forward with all of the reviews that need doing. - J< From tcallawa at redhat.com Thu Jan 3 18:15:43 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 03 Jan 2008 13:15:43 -0500 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080103120242.GZ20451@devserv.devel.redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> Message-ID: <477D264F.3030907@redhat.com> On 01/03/2008 Jakub Jelinek wrote: > 36 http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/changesmeaning/ > See C++ section of http://gcc.gnu.org/gcc-4.3/changes.html, > particularly where it talks about "changes meaning of" error Looking at these items: All of these items (except for deluge and vegastrike) are failing because of libsigc++20. I took a look at why libsigc++20 is failing, and sure enough, it just needs a new compiler test macro to enable an existing conditional (previously, only Sun Forte triggered this failure in libsigc++20). I've committed the changes to rawhide and rebuilt: libsigc++20-2.0.18-2.fc9. That should knock 33 other items off the list. :) ~spot From kevin.kofler at chello.at Thu Jan 3 18:22:57 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 3 Jan 2008 18:22:57 +0000 (UTC) Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 References: <20080103120242.GZ20451@devserv.devel.redhat.com> Message-ID: Jakub Jelinek redhat.com> writes: > fails-even-with-41/kde-i18n-3.5.8-1.fc8.log > fails-even-with-41/kile-2.0-1.fc9.log These had BR kdelibs-devel instead of kdelibs3-devel, fixed these. (kde-i18n was already fixed in CVS, but not built.) > fails-even-with-41/kdebindings-3.97.0-6.fc9.log Do you have the log with 4.1? The errors in the above log are: /usr/include/python2.5/pyconfig-64.h:944:1: error: "_XOPEN_SOURCE" redefined : error: this is the location of the previous definition which would put it in the "redefined" category. Kevin Kofler From jkeating at redhat.com Thu Jan 3 18:23:36 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 3 Jan 2008 13:23:36 -0500 Subject: f8 gripe#2: why did f8's pm-hibernate regress? In-Reply-To: <1199382316.3261.7.camel@sb-home> References: <477ADF46.2040108@filteredperception.org> <200801021159.17964.opensource@till.name> <477C299D.2060400@filteredperception.org> <477C96B8.6040903@filteredperception.org> <1199382316.3261.7.camel@sb-home> Message-ID: <20080103132336.02d95812@redhat.com> On Thu, 03 Jan 2008 18:45:16 +0100 nodata wrote: > I don't know why people keep saying this. Vista boots fast and is > responsive. Not on my brand new shiny Dell M1330. 2 gigs of ram, a fast core2duo cpu, and Vista was very slow to boot up (win2k speeds...) and once booted and I logged in it was another long wait for everything to settle down. Even then it was pretty unresponsive. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From david at fubar.dk Thu Jan 3 18:34:43 2008 From: david at fubar.dk (David Zeuthen) Date: Thu, 03 Jan 2008 13:34:43 -0500 Subject: kernels won't boot In-Reply-To: <200712220828.48202.sgrubb@redhat.com> References: <200712221216.lBMCGW8U004528@porkchop.devel.redhat.com> <200712220828.48202.sgrubb@redhat.com> Message-ID: <1199385283.2850.1.camel@oneill.fubar.dk> On Sat, 2007-12-22 at 08:28 -0500, Steve Grubb wrote: > On Saturday 22 December 2007 07:16:32 Build System wrote: > > kernel-2.6.24-0.123.rc6.fc9 > > --------------------------- > > * Fri Dec 21 2007 David Woodhouse > > - Disable CONFIG_PS3_USE_LPAR_ADDR to fix PS3 memory probing > > > > * Fri Dec 21 2007 John W. Linville > > - Yet another round of wireless updates... > > > > * Thu Dec 20 2007 Kyle McMartin > > - 2.6.24-rc6 > > > After build 81, I have not been able to boot any of the x86_64 rawhide > kernels. They all end with: > > Trying to resume from /sys/block/sda/sda3 > Unable to access resume device (/sys/block/sda/sda3) > Creating root device > Mounting root filesystem > mount: could not find '/dev/root' > Setting up other filesystems > Setting up new root fs > setuproot: moving /dev failed: No such file or directory > no fstab.sys, mounting internal defaults > setuproot: error mounting /proc: No such file or directory > setuproot: error mounting /sys: No such file or directory > Switching to new root and running init > unmounting old /dev > unmounting old /proc > unmounting old /sys > switchroot: mount failed: No such file or directory > Booting has failed. > > Rebooting into trusty old 2.6.24-0.81.rc4.git7.fc9 works fine. Are other > people running into this? I'm still seeing this too on all my x86 and x86_64 boxes with all kernels including todays update. Peter, Dave, any clue? David From tmz at pobox.com Thu Jan 3 18:43:54 2008 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 3 Jan 2008 13:43:54 -0500 Subject: GPG Keysigning at FUDCon In-Reply-To: <477D1646.6080207@redhat.com> References: <20071212214010.GA20896@auslistsprd01.us.dell.com> <477C3AA7.9010700@redhat.com> <1199353983.13378.1.camel@rousalka.dyndns.org> <477D1646.6080207@redhat.com> Message-ID: <20080103184354.GO8896@inocybe.teonanacatl.org> John Poelstra wrote: > I looked into it more and changed the expiration by: > > 1) gpg --edit and then option "expire" > 2) gpg --keyserver pgp.mit.edu --send-keys to make change > public FWIW, you may want to send that to subkeys.pgp.net, which is where Matt plans to pull the keys from for the key signing. This is the default keyserver in recent gnupg releases. I think that there is a sync between pgp.mit.edu and subkeys.pgp.net, but I'm not positive. The gnupg default is subkeys.pgp.net because pgp.mit.edu runs ancient keyserver software that has many known problems (it ignores photo packets, can munge up multiple subkeys, and other annoyances). -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I do nothing, granted. But I see the hours pass - which is better than trying to fill them. -- E. M. Cioran -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From devrim at CommandPrompt.com Thu Jan 3 18:51:24 2008 From: devrim at CommandPrompt.com (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=) Date: Thu, 03 Jan 2008 10:51:24 -0800 Subject: list of failed packages with owners (was: Re: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220) In-Reply-To: <477CE62D.7020208@leemhuis.info> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <477CE62D.7020208@leemhuis.info> Message-ID: <1199386284.3435.180.camel@localhost.localdomain> Hi, On Thu, 2008-01-03 at 14:42 +0100, Thorsten Leemhuis wrote: > devrim fails-even-with-41/python-psycopg2-2.0.6-2.fc8.log Fixed. Change committed to CVS, and package pushed to build. Regards, -- Devrim G?ND?Z , RHCE PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From lsof at nodata.co.uk Thu Jan 3 18:53:30 2008 From: lsof at nodata.co.uk (nodata) Date: Thu, 03 Jan 2008 19:53:30 +0100 Subject: f8 gripe#2: why did f8's pm-hibernate regress? In-Reply-To: <20080103132336.02d95812@redhat.com> References: <477ADF46.2040108@filteredperception.org> <200801021159.17964.opensource@till.name> <477C299D.2060400@filteredperception.org> <477C96B8.6040903@filteredperception.org> <1199382316.3261.7.camel@sb-home> <20080103132336.02d95812@redhat.com> Message-ID: <1199386410.3261.9.camel@sb-home> Am Donnerstag, den 03.01.2008, 13:23 -0500 schrieb Jesse Keating: > On Thu, 03 Jan 2008 18:45:16 +0100 > nodata wrote: > > > I don't know why people keep saying this. Vista boots fast and is > > responsive. > > Not on my brand new shiny Dell M1330. 2 gigs of ram, a fast core2duo > cpu, and Vista was very slow to boot up (win2k speeds...) and once > booted and I logged in it was another long wait for everything to > settle down. Even then it was pretty unresponsive. Mine boots in about 45 seconds, and then I launch putty and get on with some work. Are you running something heavyweight? From martin.sourada at seznam.cz Thu Jan 3 18:53:40 2008 From: martin.sourada at seznam.cz (Martin Sourada) Date: Thu, 03 Jan 2008 19:53:40 +0100 Subject: gxine (Re: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220) In-Reply-To: <20080103120242.GZ20451@devserv.devel.redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> Message-ID: <1199386420.6116.8.camel@pc-notebook> On Thu, 2008-01-03 at 13:02 +0100, Jakub Jelinek wrote: > Hi! > > I've rebuilt 5118 rawhide-20071220 src.rpms on x86_64 in mock buildroots which > contained rawhide-20071220 except {gcc,lib}*-4.1.2-36.*.rpm, with additional > gcc-4.3.0-0.4 (available from koji, dist-f9-gcc43 component), > compat-libgfortran-41 (available from > http://people.redhat.com/jakub/gcc/compat-libgfortran-41-4.1.2-36.src.rpm ) > and later on also with gettext subpackages just rebuilt with gcc-4.3.0-0.4. > > Out of those 5118 src.rpms 1054 were failed builds. For those that failed > to build, I have retried with stock rawhide-20071220 mock buildroots (i.e. > gcc-4.1.2-36). 547 failed builds failed even with 4.1.2-36 (this count > includes even ExclusiveArched rpms etc.), logs for those are at > http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/fails-even-with-41/ > and generally don't interest me, as this is not a regression introduced by > 4.3.0-0.4. > > The remaining 507 failures only fail with gcc-4.3.0-0.4 and not with > gcc-4.1.2-36, though most of them are just C++ being stricter, something > that ought to be fixed in the packages. > > I've tried to quickly grep through the failed logs and categorize them: > > # of bugs URL with logs > [...] > 36 http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/multipledef/ > When compiling with -std=c99 or -std=gnu99, inline keyword > changes meaning, in 4.3+ it by defaults conforms to ISO C99 > where extern inline is very different thing than the > GNU extern inline extension. If you want the GNU extern inline > behavior, you can use extern inline __attribute__((__gnu_inline__)) > (the attribute can be guarded by #ifdef __GNUC_STDC_INLINE__ > which is a macro which is defined when inline has the ISO C99 > behavior), or compile with -fgnu89-inline option. Hi, my package is listed there and look into sources showed only 'static inline' functions but none of these seems to be listed in the build log. Instead lots of (to me) confusing messages about multiple defs in glib header files like this (end of the really long list): wizards.o: In function `g_bit_storage': /usr/include/glib-2.0/glib/gutils.h:345: multiple definition of `g_bit_storage' console_output.o:/usr/include/glib-2.0/glib/gutils.h:345: first defined here xml_widgets.o: In function `g_bit_nth_lsf': /usr/include/glib-2.0/glib/gutils.h:316: multiple definition of `g_bit_nth_lsf' console_output.o:/usr/include/glib-2.0/glib/gutils.h:316: first defined here xml_widgets.o: In function `g_bit_nth_msf': /usr/include/glib-2.0/glib/gutils.h:331: multiple definition of `g_bit_nth_msf' console_output.o:/usr/include/glib-2.0/glib/gutils.h:331: first defined here xml_widgets.o: In function `g_trash_stack_push': /usr/include/glib-2.0/glib/gutils.h:365: multiple definition of `g_trash_stack_push' console_output.o:/usr/include/glib-2.0/glib/gutils.h:365: first defined here xml_widgets.o: In function `g_trash_stack_pop': /usr/include/glib-2.0/glib/gutils.h:373: multiple definition of `g_trash_stack_pop' console_output.o:/usr/include/glib-2.0/glib/gutils.h:373: first defined here xml_widgets.o: In function `g_trash_stack_peek': /usr/include/glib-2.0/glib/gutils.h:387: multiple definition of `g_trash_stack_peek' console_output.o:/usr/include/glib-2.0/glib/gutils.h:387: first defined here xml_widgets.o: In function `g_trash_stack_height': /usr/include/glib-2.0/glib/gutils.h:400: multiple definition of `g_trash_stack_height' console_output.o:/usr/include/glib-2.0/glib/gutils.h:400: first defined here xml_widgets.o: In function `g_once_init_enter': /usr/include/glib-2.0/glib/gthread.h:335: multiple definition of `g_once_init_enter' console_output.o:/usr/include/glib-2.0/glib/gthread.h:335: first defined here xml_widgets.o: In function `g_bit_storage': /usr/include/glib-2.0/glib/gutils.h:345: multiple definition of `g_bit_storage' console_output.o:/usr/include/glib-2.0/glib/gutils.h:345: first defined here collect2: ld returned 1 exit status make[1]: *** [gxine] Error 1 make[1]: Leaving directory `/builddir/build/BUILD/gxine-0.5.11/src' make: *** [all-recursive] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.37311 (%build) What can I do? I tried using '__inline__' instead of 'inline' with the same result. I noticed similar glib warnings among some of the other packages that failed due to this reason but glib itself was apparently built OK... Thanks, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ndbecker2 at gmail.com Thu Jan 3 18:54:06 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 03 Jan 2008 13:54:06 -0500 Subject: What replaces /etc/profile.d/qt.sh on F9? Message-ID: My builds of filelight fail on devel (but not on F8). I add BR qt-devel to pull in /etc/profile.d/qt.sh. This isn't working on devel: + source /etc/profile.d/qt.sh /var/tmp/rpm-tmp.19734: line 27: /etc/profile.d/qt.sh: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.19734 (%build) From pjones at redhat.com Thu Jan 3 19:03:20 2008 From: pjones at redhat.com (Peter Jones) Date: Thu, 03 Jan 2008 14:03:20 -0500 Subject: kernels won't boot In-Reply-To: <1199385283.2850.1.camel@oneill.fubar.dk> References: <200712221216.lBMCGW8U004528@porkchop.devel.redhat.com> <200712220828.48202.sgrubb@redhat.com> <1199385283.2850.1.camel@oneill.fubar.dk> Message-ID: <477D3178.9020108@redhat.com> David Zeuthen wrote: > On Sat, 2007-12-22 at 08:28 -0500, Steve Grubb wrote: >> On Saturday 22 December 2007 07:16:32 Build System wrote: >>> kernel-2.6.24-0.123.rc6.fc9 >>> --------------------------- >>> * Fri Dec 21 2007 David Woodhouse >>> - Disable CONFIG_PS3_USE_LPAR_ADDR to fix PS3 memory probing >>> >>> * Fri Dec 21 2007 John W. Linville >>> - Yet another round of wireless updates... >>> >>> * Thu Dec 20 2007 Kyle McMartin >>> - 2.6.24-rc6 >> >> After build 81, I have not been able to boot any of the x86_64 rawhide >> kernels. They all end with: >> >> Trying to resume from /sys/block/sda/sda3 >> Unable to access resume device (/sys/block/sda/sda3) >> Creating root device >> Mounting root filesystem >> mount: could not find '/dev/root' >> Setting up other filesystems >> Setting up new root fs >> setuproot: moving /dev failed: No such file or directory >> no fstab.sys, mounting internal defaults >> setuproot: error mounting /proc: No such file or directory >> setuproot: error mounting /sys: No such file or directory >> Switching to new root and running init >> unmounting old /dev >> unmounting old /proc >> unmounting old /sys >> switchroot: mount failed: No such file or directory >> Booting has failed. >> >> Rebooting into trusty old 2.6.24-0.81.rc4.git7.fc9 works fine. Are other >> people running into this? > > I'm still seeing this too on all my x86 and x86_64 boxes with all > kernels including todays update. > > Peter, Dave, any clue? Can you show me more of the log? -- Peter From jkeating at redhat.com Thu Jan 3 19:02:01 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 3 Jan 2008 14:02:01 -0500 Subject: f8 gripe#2: why did f8's pm-hibernate regress? In-Reply-To: <1199386410.3261.9.camel@sb-home> References: <477ADF46.2040108@filteredperception.org> <200801021159.17964.opensource@till.name> <477C299D.2060400@filteredperception.org> <477C96B8.6040903@filteredperception.org> <1199382316.3261.7.camel@sb-home> <20080103132336.02d95812@redhat.com> <1199386410.3261.9.camel@sb-home> Message-ID: <20080103140201.656537d6@redhat.com> On Thu, 03 Jan 2008 19:53:30 +0100 nodata wrote: > Mine boots in about 45 seconds, and then I launch putty and get on > with some work. Are you running something heavyweight? I'm not running it at all. Dell could have stuffed it full of crap, who knows. I don't use windows. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin.kofler at chello.at Thu Jan 3 19:06:28 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 3 Jan 2008 19:06:28 +0000 (UTC) Subject: What replaces /etc/profile.d/qt.sh on F9? References: Message-ID: Neal Becker gmail.com> writes: > My builds of filelight fail on devel (but not on F8). > > I add BR qt-devel to pull in /etc/profile.d/qt.sh. > > This isn't working on devel: > + source /etc/profile.d/qt.sh > /var/tmp/rpm-tmp.19734: line 27: /etc/profile.d/qt.sh: No such file or directory > error: Bad exit status from /var/tmp/rpm-tmp.19734 (%build) qt.sh is still in qt-devel where it always was. Your problem is probably that you're BRing kdelibs-devel, you have to BR kdelibs3-devel now. Adding BR qt-devel probably didn't work because qt4-devel (which is required by kdelibs-devel in Rawhide) also Provides it. It's the wrong fix anyway. Kevin Kofler From kevin.kofler at chello.at Thu Jan 3 19:08:45 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 3 Jan 2008 19:08:45 +0000 (UTC) Subject: What replaces /etc/profile.d/qt.sh on F9? References: Message-ID: Correction: > Adding BR qt-devel probably didn't work because qt4-devel (which is required > by kdelibs-devel in Rawhide) also Provides it. Actually it doesn't, so I don't know why it still wasn't found with BR qt-devel. Kevin Kofler From david at fubar.dk Thu Jan 3 19:09:06 2008 From: david at fubar.dk (David Zeuthen) Date: Thu, 03 Jan 2008 14:09:06 -0500 Subject: kernels won't boot In-Reply-To: <1199387293.3716.39.camel@localhost.localdomain> References: <200712221216.lBMCGW8U004528@porkchop.devel.redhat.com> <200712220828.48202.sgrubb@redhat.com> <1199385283.2850.1.camel@oneill.fubar.dk> <477D3178.9020108@redhat.com> <1199387293.3716.39.camel@localhost.localdomain> Message-ID: <1199387346.2850.24.camel@oneill.fubar.dk> On Thu, 2008-01-03 at 14:08 -0500, Eric Paris wrote: > > Can you show me more of the log? > > The log is more sgrubb. > I think selinux-policy is busted at the moment. depmod and mkinitrd are > having trouble in enforcing... > > rpm -e kernel-2.6.24-133-blah-blah > setenforce 0 > yum update kernel > setenforce 1 > > if that fixes it blame selinux > > Also get the same result if you don't have your storage driver > in /etc/modprobe.conf so you can look there first... I'm not running SELinux enforcing mode on any of my machines.. David From davidz at redhat.com Thu Jan 3 19:10:20 2008 From: davidz at redhat.com (David Zeuthen) Date: Thu, 03 Jan 2008 14:10:20 -0500 Subject: kernels won't boot In-Reply-To: <1199387346.2850.24.camel@oneill.fubar.dk> References: <200712221216.lBMCGW8U004528@porkchop.devel.redhat.com> <200712220828.48202.sgrubb@redhat.com> <1199385283.2850.1.camel@oneill.fubar.dk> <477D3178.9020108@redhat.com> <1199387293.3716.39.camel@localhost.localdomain> <1199387346.2850.24.camel@oneill.fubar.dk> Message-ID: <1199387420.2850.26.camel@oneill.fubar.dk> On Thu, 2008-01-03 at 14:09 -0500, David Zeuthen wrote: > On Thu, 2008-01-03 at 14:08 -0500, Eric Paris wrote: > > > Can you show me more of the log? > > > > > The log is more sgrubb. Eh.. From.. the log is from sgrubb. That's what I meant. David From ndbecker2 at gmail.com Thu Jan 3 19:11:37 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 03 Jan 2008 14:11:37 -0500 Subject: What replaces /etc/profile.d/qt.sh on F9? References: Message-ID: Kevin Kofler wrote: > Neal Becker gmail.com> writes: >> My builds of filelight fail on devel (but not on F8). >> >> I add BR qt-devel to pull in /etc/profile.d/qt.sh. >> >> This isn't working on devel: >> + source /etc/profile.d/qt.sh >> /var/tmp/rpm-tmp.19734: line 27: /etc/profile.d/qt.sh: No such file or > directory >> error: Bad exit status from /var/tmp/rpm-tmp.19734 (%build) > > qt.sh is still in qt-devel where it always was. Your problem is probably > that you're BRing kdelibs-devel, you have to BR kdelibs3-devel now. > > Adding BR qt-devel probably didn't work because qt4-devel (which is > required by kdelibs-devel in Rawhide) also Provides it. It's the wrong fix > anyway. > > Kevin Kofler I was going by this (this is on F8): rpm -q -f /etc/profile.d/qt.sh qt-devel-3.3.8-9.fc8.x86_64 From dan at danny.cz Thu Jan 3 19:16:12 2008 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Thu, 03 Jan 2008 20:16:12 +0100 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080103120242.GZ20451@devserv.devel.redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> Message-ID: <1199387772.3253.15.camel@eagle.danny.cz> > header-dep/qlandkarte-0.5.3-4.fc9.log upstream notified, patched version will be soon in devel > header-dep/ultimatestunts-0.7.3-4.fc9.log working on that > fails-even-with-41/tailor-0.9.29-1.fc9.log > fails-even-with-41/tinyerp-4.2.0-1.fc9.log it is a Python thing - setup/dist-utils are generating the Egg directory, version currently in devel should be OK Dan From jakub at redhat.com Thu Jan 3 19:21:57 2008 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 3 Jan 2008 14:21:57 -0500 Subject: gxine (Re: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220) In-Reply-To: <1199386420.6116.8.camel@pc-notebook> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <1199386420.6116.8.camel@pc-notebook> Message-ID: <20080103192157.GI20451@devserv.devel.redhat.com> On Thu, Jan 03, 2008 at 07:53:40PM +0100, Martin Sourada wrote: > my package is listed there and look into sources showed only 'static > inline' functions but none of these seems to be listed in the build log. > Instead lots of (to me) confusing messages about multiple defs in glib > header files like this (end of the really long list): > > wizards.o: In function `g_bit_storage': > /usr/include/glib-2.0/glib/gutils.h:345: multiple definition of > `g_bit_storage' > console_output.o:/usr/include/glib-2.0/glib/gutils.h:345: first defined > here The problem is on the glib2 side. Guess glib/gutils.h needs a change like: #ifdef G_IMPLEMENT_INLINES # define G_INLINE_FUNC # undef G_CAN_INLINE #elif defined (__GNUC__) # if defined (__GNUC_STDC_INLINE__) # define G_INLINE_FUNC extern inline __attribute__((__gnu_inline__)) # else # define G_INLINE_FUNC extern inline # endif #elif defined (G_CAN_INLINE) # define G_INLINE_FUNC static inline #else /* can't inline */ # define G_INLINE_FUNC #endif /* !G_INLINE_FUNC */ extern inline int foo (void) { return 1; } in ISO C99 semantics means this inline function should be also emitted out of line and exported from current CU, while in GNU inline semantics it means if this inline can be inlined, inline it, if not, use the exported function definition (typically from some other CU, shared library, ...). static inline behaves the same in both semantics. The multiple definitions linker errors are there because extern inline in ISO C99 means the function is exported, so each CU which includes glib/gutils.h defines g_bit_nth_lsf, etc. See http://gcc.gnu.org/onlinedocs/gcc/Inline.html#Inline or ISO C99 6.7.4. Jakub From loupgaroublond at gmail.com Thu Jan 3 19:29:08 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 3 Jan 2008 14:29:08 -0500 Subject: Fedora 9 Feature Status In-Reply-To: <477D21D4.4060604@redhat.com> References: <477C915E.4080402@redhat.com> <7f692fec0801030926o483d1a37w3d02e30a41388dc@mail.gmail.com> <477D21D4.4060604@redhat.com> Message-ID: <7f692fec0801031129n39a05ff6m823f52f59f20201c@mail.gmail.com> On Jan 3, 2008 12:56 PM, John Poelstra wrote: > "User Experience" and "Release Notes" are incomplete. Added. From loupgaroublond at gmail.com Thu Jan 3 19:29:32 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 3 Jan 2008 14:29:32 -0500 Subject: Fedora 9 Feature Status In-Reply-To: References: <477C915E.4080402@redhat.com> <7f692fec0801030926o483d1a37w3d02e30a41388dc@mail.gmail.com> Message-ID: <7f692fec0801031129m156ef62asc782bf0e3f7eab33@mail.gmail.com> On 03 Jan 2008 12:11:25 -0600, Jason L Tibbitts III wrote: > Personally I'd like to see "Packaging Guidelines" moved up from > "Dependencies" to an actual action item. Because it's really a > prerequisite to actually moving forward with all of the reviews that > need doing. Done. From dimi at lattica.com Thu Jan 3 19:45:22 2008 From: dimi at lattica.com (Dimi Paun) Date: Thu, 03 Jan 2008 14:45:22 -0500 Subject: kernels won't boot In-Reply-To: <1199387346.2850.24.camel@oneill.fubar.dk> References: <200712221216.lBMCGW8U004528@porkchop.devel.redhat.com> <200712220828.48202.sgrubb@redhat.com> <1199385283.2850.1.camel@oneill.fubar.dk> <477D3178.9020108@redhat.com> <1199387293.3716.39.camel@localhost.localdomain> <1199387346.2850.24.camel@oneill.fubar.dk> Message-ID: <1199389522.4670.95.camel@dimi.lattica.com> On Thu, 2008-01-03 at 14:09 -0500, David Zeuthen wrote: > I'm not running SELinux enforcing mode on any of my machines.. That's too bad -- it's hard to gage the usability of a system without it on, since it is enabled by default for most people. -- Dimi Paun Lattica, Inc. From kevin.kofler at chello.at Thu Jan 3 19:46:56 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 3 Jan 2008 19:46:56 +0000 (UTC) Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 References: <20080103120242.GZ20451@devserv.devel.redhat.com> Message-ID: I wrote: > > fails-even-with-41/kdebindings-3.97.0-6.fc9.log > > Do you have the log with 4.1? The errors in the above log are: > /usr/include/python2.5/pyconfig-64.h:944:1: error: "_XOPEN_SOURCE" redefined > : error: this is the location of the previous definition > which would put it in the "redefined" category. I reissued the build in Koji to get the log for the generic failure. It turned out to be an issue with _kde4_includedir vs. _includedir (I forget to actually issue the rebuild for the _kde4_includedir change, so this went unnoticed). This is fixed now. However, the redefinition errors with 4.3 still need fixing. Kevin Kofler From ncorrare at fedoraproject.org Thu Jan 3 21:19:29 2008 From: ncorrare at fedoraproject.org (Nicolas Antonio Corrarello) Date: Thu, 03 Jan 2008 18:19:29 -0300 Subject: New tzdata. Argentina Time Zone Message-ID: <477D5161.1040903@fedoraproject.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Everyone, Argentina is in new timezone (ARST), we now have daylight saving time. The new package is tzdata-2007k. It was already released for rhel. Any news on this one, shall I make the RPM? Who should I send it to? - -- - - -- Nicolas A. Corrarello Fedora Ambassador Argentina c: +54 (911) 5182-2245 e: ncorrare at fedoraproject.org GPG Key: DFC893EE h: fedoraproject.org/wiki/NicolasCorrarello/ GPG Fingerprint: 5C93 42DA 98E1 4EEF B24B 7F8C E145 B2F9 DFC8 93EE Import my key: $ gpg --keyserver pgp.mit.edu --recv-key 0xDFC893EE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHfVFh4UWy+d/Ik+4RAvPpAJ9SQWm8swLdcx3u1vNfmw9/o12sqACfdwYY H/T6s3N/vpQYdXtjT3Sg5TI= =537Y -----END PGP SIGNATURE----- From ndbecker2 at gmail.com Thu Jan 3 20:22:12 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 03 Jan 2008 15:22:12 -0500 Subject: Let me rephrase the question (was What replaces /etc/profile.d/qt.sh on F9?) References: Message-ID: Neal Becker wrote: > My builds of filelight fail on devel (but not on F8). > > I add BR qt-devel to pull in /etc/profile.d/qt.sh. > > This isn't working on devel: > + source /etc/profile.d/qt.sh > /var/tmp/rpm-tmp.19734: line 27: /etc/profile.d/qt.sh: No such file or > directory error: Bad exit status from /var/tmp/rpm-tmp.19734 (%build) > > So, what do I do to make this work on F8 and on F9 (hopefully these are not 2 different answers). From jakub.rusinek at gmail.com Thu Jan 3 20:18:45 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Thu, 03 Jan 2008 21:18:45 +0100 Subject: Control center idea In-Reply-To: <477D001B.8090203@fedoraproject.org> References: <1199374110.5023.2.camel@frosty> <477D001B.8090203@fedoraproject.org> Message-ID: <1199391525.7512.2.camel@frosty> Dnia 03-01-2008, czw o godzinie 21:02 +0530, Rahul Sundaram pisze: > Jakub 'Livio' Rusinek wrote: > > Hi, > > > > I have written wiki draft page [1] about control center idea in Fedora. > > > > > > > > 1| http://fedoraproject.org/wiki/JakubRusinek/DRAFT%FedoraControlCenter > > If you are willing to maintain it, there is system-config-control > available at > > http://www.indianoss.org/modules/wfdownloads/viewcat.php?cid=10 Maintain = put into repo :> ? Probably not... "January 17, 2006" - holy **it... It's old. > If you are interested in maintaining Yast, a port of it for RHEL is > available at which should work on Fedora too with possibly minor changes. > > http://oss.oracle.com/projects/yast/ > > Rahul Not sure about users opinion and OSS-environment reaction :> . -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? wiadomo?ci podpisana cyfrowo URL: From davidz at redhat.com Thu Jan 3 20:23:10 2008 From: davidz at redhat.com (David Zeuthen) Date: Thu, 03 Jan 2008 15:23:10 -0500 Subject: kernels won't boot In-Reply-To: <1199387420.2850.26.camel@oneill.fubar.dk> References: <200712221216.lBMCGW8U004528@porkchop.devel.redhat.com> <200712220828.48202.sgrubb@redhat.com> <1199385283.2850.1.camel@oneill.fubar.dk> <477D3178.9020108@redhat.com> <1199387293.3716.39.camel@localhost.localdomain> <1199387346.2850.24.camel@oneill.fubar.dk> <1199387420.2850.26.camel@oneill.fubar.dk> Message-ID: <1199391790.10354.0.camel@oneill.fubar.dk> Hi, We're now tracking this issue in ? https://bugzilla.redhat.com/show_bug.cgi?id=427439 David From caillon at redhat.com Thu Jan 3 20:27:31 2008 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 03 Jan 2008 21:27:31 +0100 Subject: New tzdata. Argentina Time Zone In-Reply-To: <477D5161.1040903@fedoraproject.org> References: <477D5161.1040903@fedoraproject.org> Message-ID: <477D4533.3050003@redhat.com> On 01/03/2008 10:19 PM, Nicolas Antonio Corrarello wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello Everyone, > Argentina is in new timezone (ARST), we now have daylight saving time. > The new package is tzdata-2007k. It was already released for rhel. Any > news on this one, shall I make the RPM? Who should I send it to? It's alreayd been built for Fedora. You can find it in koji. From j.w.r.degoede at hhs.nl Thu Jan 3 20:30:18 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 03 Jan 2008 21:30:18 +0100 Subject: Let me rephrase the question (was What replaces /etc/profile.d/qt.sh on F9?) In-Reply-To: References: Message-ID: <477D45DA.7050802@hhs.nl> Neal Becker wrote: > Neal Becker wrote: > >> My builds of filelight fail on devel (but not on F8). >> >> I add BR qt-devel to pull in /etc/profile.d/qt.sh. >> >> This isn't working on devel: >> + source /etc/profile.d/qt.sh >> /var/tmp/rpm-tmp.19734: line 27: /etc/profile.d/qt.sh: No such file or >> directory error: Bad exit status from /var/tmp/rpm-tmp.19734 (%build) >> >> > > So, what do I do to make this work on F8 and on F9 (hopefully these are not > 2 different answers). > AFAIK nothing replace it, but it you indirectly required qt through kdelibs, you need to change the BuildRequires kdelibs-devel to kdelibs3-devel, otherwise you get kdelibs-4.x and qt4 Regards, Hans From Lam at Lam.pl Thu Jan 3 20:29:23 2008 From: Lam at Lam.pl (Leszek Matok) Date: Thu, 3 Jan 2008 21:29:23 +0100 Subject: New tzdata. Argentina Time Zone In-Reply-To: <477D5161.1040903@fedoraproject.org> References: <477D5161.1040903@fedoraproject.org> Message-ID: <20080103212923.25568ae2@pensja.lam.pl> Dnia 2008-01-03, o godz. 18:19:29 Nicolas Antonio Corrarello napisa?(a): > Hello Everyone, > Argentina is in new timezone (ARST), we now have daylight saving time. > The new package is tzdata-2007k. It was already released for rhel. Any > news on this one, shall I make the RPM? Who should I send it to? https://admin.fedoraproject.org/updates/F8/pending/tzdata-2007k-1.fc8 Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From triad at df.lth.se Thu Jan 3 20:35:37 2008 From: triad at df.lth.se (Linus Walleij) Date: Thu, 3 Jan 2008 21:35:37 +0100 (CET) Subject: Policy proposal for compatibility packages In-Reply-To: <20080103154005.GC3997@free.fr> References: <477BE5EA.9020909@redhat.com> <20080102215010.GD2661@free.fr> <477C0FE7.60105@redhat.com> <20080102225303.GJ2661@free.fr> <1199316723.24135.2.camel@nixon> <20080102233619.GM2661@free.fr> <1199317946.24135.14.camel@nixon> <20080103144235.GB2713@free.fr> <20080103154005.GC3997@free.fr> Message-ID: On Thu, 3 Jan 2008, Patrice Dumas wrote: >> And then s/he knows that in Fedora, we love to discard old >> API:s. > > I hope it is untrue. I hope everybody here dislikes breaking API and > ABIs and try to push the upstreams to be responsible with API/ABI. Of course upstream is responsible, man, calm down. It seems you read me like I thought breaking API/ABI was a goal in itself, that's not what I meant. Linus From ml at deadbabylon.de Thu Jan 3 20:34:25 2008 From: ml at deadbabylon.de (Sebastian Vahl) Date: Thu, 3 Jan 2008 21:34:25 +0100 Subject: KDE-SIG weekly report (01/2008) Message-ID: <200801032134.29594.ml@deadbabylon.de> This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply ?to this email or add it to the related meeting page. ---------------------------------------------------------------------------------- = Weekly KDE Summary = Week: 01/2008 Time: 2008-01-03 16:00 UTC Meeting page: http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-01-03 Meeting log: http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-01-03?action=AttachFile&do=get&target=fedora-kde-sig-2008-01-03.txt ---------------------------------------------------------------------------------- = Participants = - KevinKofler - LukasTinkl - RexDieter - SebastianVahl ---------------------------------------------------------------------------------- = Agenda = - KDE 4 LiveCD [1] - kde-settings for kde 4 - development progress: the road to kde4 = Summary = o KDE 4 LiveCD: - According to the thread on fedora-test-list the current live image has a lot of problems. Some of them are related to kde 4 itself (and hopefully be fixed in the final), some are related to current xserver in rawhide (vesa) and should be filed as bugs - KDE-4.0.0 would propably be shipped without composite support enabled by default (which "fixes" the problem with intel graphics) - KDE-4.0.0 is scheduled to be tagged tommorrow and to be released on 2008-01-11. After the inclusion into rawhide we should get new live images online o kde-settings: - Upstream has decided to not show desktop icons by default - Besides default kickoff menu upstream will ship a "simple menu" as an alternative - Both things aren't part of current kde-3.97.0 and we should reconsider them after the final release and we see how they perform o development progress: the road to kde4: - new review requests for packages from extragear/playground: - #427185: Okteta (a replacement for khexedit which isn't ported to KDE4) [2] - other packages which aren't worked on: Wishlist [3] - konq-plugins (from extragear/base, used to be in kdeaddons) - kiconedit (from extragear/graphics, used to be in kdegraphics) - kcoloredit (from extragear/graphics, used to be in kdegraphics) - kaudiocreator (from extragear/multimedia, used to be in kdemultimedia) - kmid (from extragear/multimedia, used to be in kdemultimedia) - ksig (from extragear/pim, used to be in kdeaddons) o Other things: - xsettings-kde: This packages provides a XSettings daemon to allow XSettings aware applications (all GTK+ 2 and GNOME 2 applications) to be informed instantly of changes in KDE configuration. It currently is packaged in kde-redhat-testing repository until it is reviewed and included in fedora [4] - Review Request: kde4-decoration-native-quarticurve-kwin - Unofficial port of the Bluecurve KWin decoration to KDE 4 [5] ---------------------------------------------------------------------------------- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-01-08 ---------------------------------------------------------------------------------- = Links = [1] https://www.redhat.com/archives/fedora-test-list/2007-December/msg00494.html [2] https://bugzilla.redhat.com/show_bug.cgi?id=427185 [3] http://fedoraproject.org/wiki/SIGs/KDE/KDE4Status#head-928cc2a2c2429f8f6a343c1a88c6588adc416992 [4] http://kdeforge.unl.edu/apt/kde-redhat/SOURCES/xsettings-kde/ [5] https://bugzilla.redhat.com/show_bug.cgi?id=427185 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From sgrubb at redhat.com Thu Jan 3 20:38:16 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Thu, 3 Jan 2008 15:38:16 -0500 Subject: kernels won't boot In-Reply-To: <1199387420.2850.26.camel@oneill.fubar.dk> References: <200712221216.lBMCGW8U004528@porkchop.devel.redhat.com> <1199387346.2850.24.camel@oneill.fubar.dk> <1199387420.2850.26.camel@oneill.fubar.dk> Message-ID: <200801031538.17043.sgrubb@redhat.com> On Thursday 03 January 2008 14:10:20 David Zeuthen wrote: > > > > Can you show me more of the log? > > > > The log is more sgrubb. > > Eh.. From.. the log is from sgrubb. That's what I meant. Turns out the problem shows up on my laptop. I started to hook up a serial cable and found doesn't have a serial port. I thought it did...so no logs. -Steve From jakub.rusinek at gmail.com Thu Jan 3 20:34:53 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Thu, 03 Jan 2008 21:34:53 +0100 Subject: Control center idea In-Reply-To: <477D001B.8090203@fedoraproject.org> References: <1199374110.5023.2.camel@frosty> <477D001B.8090203@fedoraproject.org> Message-ID: <1199392493.7512.8.camel@frosty> Dnia 03-01-2008, czw o godzinie 21:02 +0530, Rahul Sundaram pisze: > If you are interested in maintaining Yast, a port of it for RHEL is > available at which should work on Fedora too with possibly minor changes. > > http://oss.oracle.com/projects/yast/ > > Rahul > No GTK support. mv YaST > /dev/null :( -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? wiadomo?ci podpisana cyfrowo URL: From david at fubar.dk Thu Jan 3 20:43:26 2008 From: david at fubar.dk (David Zeuthen) Date: Thu, 03 Jan 2008 15:43:26 -0500 Subject: selinux rant, compressed version (Was Re: kernels won't boot) In-Reply-To: <1199389522.4670.95.camel@dimi.lattica.com> References: <200712221216.lBMCGW8U004528@porkchop.devel.redhat.com> <200712220828.48202.sgrubb@redhat.com> <1199385283.2850.1.camel@oneill.fubar.dk> <477D3178.9020108@redhat.com> <1199387293.3716.39.camel@localhost.localdomain> <1199387346.2850.24.camel@oneill.fubar.dk> <1199389522.4670.95.camel@dimi.lattica.com> Message-ID: <1199393006.10354.16.camel@oneill.fubar.dk> On Thu, 2008-01-03 at 14:45 -0500, Dimi Paun wrote: > On Thu, 2008-01-03 at 14:09 -0500, David Zeuthen wrote: > > I'm not running SELinux enforcing mode on any of my machines.. > > That's too bad -- it's hard to gage the usability of a system > without it on, since it is enabled by default for most people. Well, the kernel bits of SELinux is great. The user space bits never ever worked for me; neither as a user, nor RPM package maintainer and definitely not as an upstream developer of highly modular software that is designed to be locked down (e.g. hald and it's helper processes) Some problems from a 50,000 feet point of view - the policy is way too complicated; really, I think it's kinda futile, at this point, to attempt to lock down bits that are not even network-facing. As a result someone decided "oh, we're just going to let people turn of it". And this is where we are now. Total cop out. Might as well not ship it. Seriously. Just go ahead and look at the policy. No wonder it often doesn't work given it's so complex. - the policy is centrally maintained; e.g. the maintainer of the policy for hald (Dan Walsh) and, hey, all of the policy often have to guess how to lock things down and often, despite Dan being a great engineer, these guesses are just wrong. Seriously, no one can blame Dan for this - you cannot expect a single person to know all the kinks of all the software in Fedora. -> Ideally every upstream project can maintain it's own policy. That has the nice side effect of, gosh, teaching other distributions about the benefits of MCA. -> If upstream don't want to include SELinux policy, just include it as a patch in the RPM Typical responses: - "rpm cannot handle SELinux policy": <- bullshit; it's not much different from other file meta data; do we store file modes and permissions centrally too? No. - "uh, then you would have deps on policy": Like, for example, the policy for hald would depend on the policy for, say, dbus. Not a problem, the real world contains dependencies already and most these deps are handled just fine already by the upstream projects. I'm not even going to go into the language used for defining policy. In short, SELinux just doesn't work for me. I'm not denying it may work well on a tightly-controlled servers where features never change (e.g. RHEL). David From sundaram at fedoraproject.org Thu Jan 3 20:37:24 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 04 Jan 2008 02:07:24 +0530 Subject: Control center idea In-Reply-To: <1199392493.7512.8.camel@frosty> References: <1199374110.5023.2.camel@frosty> <477D001B.8090203@fedoraproject.org> <1199392493.7512.8.camel@frosty> Message-ID: <477D4784.30000@fedoraproject.org> Jakub 'Livio' Rusinek wrote: > Dnia 03-01-2008, czw o godzinie 21:02 +0530, Rahul Sundaram pisze: >> If you are interested in maintaining Yast, a port of it for RHEL is >> available at which should work on Fedora too with possibly minor changes. >> >> http://oss.oracle.com/projects/yast/ >> >> Rahul >> > > No GTK support. > mv YaST > /dev/null :( It is not the latest version. Both the suggestions are something for you to potentially start with. You don't get anything yet that would just fit in right away. Rahul From david at fubar.dk Thu Jan 3 20:45:55 2008 From: david at fubar.dk (David Zeuthen) Date: Thu, 03 Jan 2008 15:45:55 -0500 Subject: selinux rant, compressed version (Was Re: kernels won't boot) In-Reply-To: <1199393006.10354.16.camel@oneill.fubar.dk> References: <200712221216.lBMCGW8U004528@porkchop.devel.redhat.com> <200712220828.48202.sgrubb@redhat.com> <1199385283.2850.1.camel@oneill.fubar.dk> <477D3178.9020108@redhat.com> <1199387293.3716.39.camel@localhost.localdomain> <1199387346.2850.24.camel@oneill.fubar.dk> <1199389522.4670.95.camel@dimi.lattica.com> <1199393006.10354.16.camel@oneill.fubar.dk> Message-ID: <1199393155.10354.18.camel@oneill.fubar.dk> On Thu, 2008-01-03 at 15:43 -0500, David Zeuthen wrote: > -> Ideally every upstream project can maintain it's own policy. That > has the nice side effect of, gosh, teaching other distributions > about the benefits of MCA. Eh, MAC. As in Mandatory Access Control. Guess I got too carried away in my rant. I'm OK now! David From sundaram at fedoraproject.org Thu Jan 3 20:38:32 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 04 Jan 2008 02:08:32 +0530 Subject: Control center idea In-Reply-To: <1199391525.7512.2.camel@frosty> References: <1199374110.5023.2.camel@frosty> <477D001B.8090203@fedoraproject.org> <1199391525.7512.2.camel@frosty> Message-ID: <477D47C8.2030304@fedoraproject.org> Jakub 'Livio' Rusinek wrote: >> http://www.indianoss.org/modules/wfdownloads/viewcat.php?cid=10 > > Maintain = put into repo :> ? > > Probably not... "January 17, 2006" - holy **it... It's old. It was in the repository before for sometime and you would need to update it. > Not sure about users opinion and OSS-environment reaction :> . Not sure what that means. If you are willing to maintain it, just go ahead and do it. I am sure opinions would be mixed. Rahul From jkeating at redhat.com Thu Jan 3 20:48:35 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 3 Jan 2008 15:48:35 -0500 Subject: selinux rant, compressed version (Was Re: kernels won't boot) In-Reply-To: <1199393006.10354.16.camel@oneill.fubar.dk> References: <200712221216.lBMCGW8U004528@porkchop.devel.redhat.com> <200712220828.48202.sgrubb@redhat.com> <1199385283.2850.1.camel@oneill.fubar.dk> <477D3178.9020108@redhat.com> <1199387293.3716.39.camel@localhost.localdomain> <1199387346.2850.24.camel@oneill.fubar.dk> <1199389522.4670.95.camel@dimi.lattica.com> <1199393006.10354.16.camel@oneill.fubar.dk> Message-ID: <20080103154835.7013fc06@redhat.com> On Thu, 03 Jan 2008 15:43:26 -0500 David Zeuthen wrote: > Typical responses: > - "rpm cannot handle SELinux policy": <- bullshit; it's not much > different from other file meta data; do we store file modes and > permissions centrally too? No. I don't know where you're getting this "typical" response from. The problem isn't rpm, the problem is selinux itself, not allowing rpm to write out files that have a context it doesn't know about (yet), since the context may be in the policy it's laying down. Think chroots or anaconda or livecreation. Until the selinux upstream gets a clue on this one we're stuck. It's not like people haven't been arguing this point for many many years now... -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From david at fubar.dk Thu Jan 3 20:56:22 2008 From: david at fubar.dk (David Zeuthen) Date: Thu, 03 Jan 2008 15:56:22 -0500 Subject: selinux rant, compressed version (Was Re: kernels won't boot) In-Reply-To: <20080103154835.7013fc06@redhat.com> References: <200712221216.lBMCGW8U004528@porkchop.devel.redhat.com> <200712220828.48202.sgrubb@redhat.com> <1199385283.2850.1.camel@oneill.fubar.dk> <477D3178.9020108@redhat.com> <1199387293.3716.39.camel@localhost.localdomain> <1199387346.2850.24.camel@oneill.fubar.dk> <1199389522.4670.95.camel@dimi.lattica.com> <1199393006.10354.16.camel@oneill.fubar.dk> <20080103154835.7013fc06@redhat.com> Message-ID: <1199393782.10354.23.camel@oneill.fubar.dk> On Thu, 2008-01-03 at 15:48 -0500, Jesse Keating wrote: > On Thu, 03 Jan 2008 15:43:26 -0500 > David Zeuthen wrote: > > > Typical responses: > > - "rpm cannot handle SELinux policy": <- bullshit; it's not much > > different from other file meta data; do we store file modes and > > permissions centrally too? No. > > I don't know where you're getting this "typical" response from. The > problem isn't rpm, the problem is selinux itself, not allowing rpm to > write out files that have a context it doesn't know about (yet), since > the context may be in the policy it's laying down. Think chroots or > anaconda or livecreation. Until the selinux upstream gets a clue > on this one we're stuck. It's not like people haven't been arguing > this point for many many years now... Sure, granted. I wasn't really ranting at the .rpm or .deb people here. (However, no one prevents you from using SELinux in permissive mode during installs or live cd creation and then relabel the fs at the end. Heck at least for the latter I'm pretty sure you can't even use enforcing mode because the SELinux policy is so draconian as part of it's complexity) David From jkeating at redhat.com Thu Jan 3 20:59:50 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 3 Jan 2008 15:59:50 -0500 Subject: selinux rant, compressed version (Was Re: kernels won't boot) In-Reply-To: <1199393782.10354.23.camel@oneill.fubar.dk> References: <200712221216.lBMCGW8U004528@porkchop.devel.redhat.com> <200712220828.48202.sgrubb@redhat.com> <1199385283.2850.1.camel@oneill.fubar.dk> <477D3178.9020108@redhat.com> <1199387293.3716.39.camel@localhost.localdomain> <1199387346.2850.24.camel@oneill.fubar.dk> <1199389522.4670.95.camel@dimi.lattica.com> <1199393006.10354.16.camel@oneill.fubar.dk> <20080103154835.7013fc06@redhat.com> <1199393782.10354.23.camel@oneill.fubar.dk> Message-ID: <20080103155950.357ed2d8@redhat.com> On Thu, 03 Jan 2008 15:56:22 -0500 David Zeuthen wrote: > Sure, granted. I wasn't really ranting at the .rpm or .deb people > here. > > (However, no one prevents you from using SELinux in permissive mode > during installs or live cd creation and then relabel the fs at the > end. Heck at least for the latter I'm pretty sure you can't even use > enforcing mode because the SELinux policy is so draconian as part of > it's complexity) Yeah, we have to use permissive at least, or else things fail. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From david at fubar.dk Thu Jan 3 21:01:38 2008 From: david at fubar.dk (David Zeuthen) Date: Thu, 03 Jan 2008 16:01:38 -0500 Subject: selinux rant, compressed version (Was Re: kernels won't boot) In-Reply-To: <20080103154835.7013fc06@redhat.com> References: <200712221216.lBMCGW8U004528@porkchop.devel.redhat.com> <200712220828.48202.sgrubb@redhat.com> <1199385283.2850.1.camel@oneill.fubar.dk> <477D3178.9020108@redhat.com> <1199387293.3716.39.camel@localhost.localdomain> <1199387346.2850.24.camel@oneill.fubar.dk> <1199389522.4670.95.camel@dimi.lattica.com> <1199393006.10354.16.camel@oneill.fubar.dk> <20080103154835.7013fc06@redhat.com> Message-ID: <1199394098.10354.29.camel@oneill.fubar.dk> On Thu, 2008-01-03 at 15:48 -0500, Jesse Keating wrote: > On Thu, 03 Jan 2008 15:43:26 -0500 > David Zeuthen wrote: > > > Typical responses: > > - "rpm cannot handle SELinux policy": <- bullshit; it's not much > > different from other file meta data; do we store file modes and > > permissions centrally too? No. > > I don't know where you're getting this "typical" response from. The > problem isn't rpm, the problem is selinux itself, not allowing rpm to > write out files that have a context it doesn't know about (yet), Also, one obvious solution here is to install the selinux policy before files are copied; much like you create a daemon user in %pre. Or if %pre isn't early enough, invent another tag or whatever. Point is: you can't entirely blame this on the SELinux people; getting things like rpm to work with selinux actually requires a two-way conversation - something that some companies can't figure out to make happen :-/ David From jbarnes at virtuousgeek.org Thu Jan 3 21:06:45 2008 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Thu, 3 Jan 2008 13:06:45 -0800 Subject: KDE-SIG weekly report (01/2008) In-Reply-To: <200801032134.29594.ml@deadbabylon.de> References: <200801032134.29594.ml@deadbabylon.de> Message-ID: <200801031306.45787.jbarnes@virtuousgeek.org> On Thursday, January 03, 2008 12:34 pm Sebastian Vahl wrote: > - KDE-4.0.0 would propably be shipped without composite support enabled by > default (which "fixes" the problem with intel graphics) Where can I find more info about this problem? Is it really an intel driver problem or something else? Thanks, Jesse From kevin.kofler at chello.at Thu Jan 3 21:10:55 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 3 Jan 2008 21:10:55 +0000 (UTC) Subject: What replaces /etc/profile.d/qt.sh on F9? References: Message-ID: Neal Becker gmail.com> writes: > I add BR qt-devel to pull in /etc/profile.d/qt.sh. > > This isn't working on devel: I checked your CVS commit: You didn't actually add the BR, just the changelog entry for it. ;-) So no wonder this had no effect. But again: this is the wrong fix. You have to change your BR kdelibs-devel to kdelibs3-devel and in turn that will drag in qt-devel automatically. kdelibs-devel in Rawhide is KDE 4. Kevin Kofler From kevin.kofler at chello.at Thu Jan 3 21:12:57 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 3 Jan 2008 21:12:57 +0000 (UTC) Subject: What replaces /etc/profile.d/qt.sh on F9? References: Message-ID: Oh, and I forgot: kdelibs-devel in F7 and F8 Provides: kdelibs3-devel, so BR kdelibs3-devel will work on F7/F8 too (but not in EPEL, I guess). Kevin Kofler From eswierk at arastra.com Thu Jan 3 21:29:18 2008 From: eswierk at arastra.com (Ed Swierk) Date: Thu, 3 Jan 2008 13:29:18 -0800 Subject: Another selinux rant Message-ID: Since someone asked, here's my little SELinux rant: Yesterday I set up a new server running F8. It's replacing an old server and all it does is run sshd and openvpn. I decided to give SELinux a try after many years of ignoring it. I copied user home directories, /etc/passwd, /etc/shadow, /etc/group, and ssh host keys from the old server to the new one. That was easy enough. I couldn't log into the machine using ssh public key authentication, though--ssh kept falling back to password authentication. I checked all the usual suspects like directory permissions, to no avail. I passed -v -v -v to ssh and got no useful information. After some poking around I noticed a bunch of messages in /var/log/messages along the lines of "audit denied sshd btmp" and "audit denied sshd /home/eswierk/..." blah blah blah. I figured this was due to SELinux (although heaven knows why the message doesn't contain the word "selinux"). Spent some time searching Google and came across fixfiles, so I ran "fixfiles restore /", restarted sshd, and voila, I could log in with a public key. Next I copied the openvpn configuration from the old server and tried to start it up. No joy. Having learned my lesson I headed straight to /var/log/messages and once again found messages from SELinux, like "audit denied openvpn ipp.txt". I ran "fixfiles restore /" again, but this time it didn't help. Back to Google, and dug up some mailing list messages with all sorts of stuff about updating policies. I spent about 10 minutes trying various things without really understanding them before resorting to the solution I do understand: set SELINUX=disabled in /etc/sysconfig/selinux, reboot, done. For me learning SELinux seems as pointless as trying to remember iptables commands, or AFS trivia back when I was a student--all cause me trouble just infrequently enough to ensure I have to relearn them from scratch every time. If I were a full-time sysadmin of course it would be a different story, but I really don't have the brain cycles to remember anything more complicated than chmod and chown, and I suspect a large number of accidental sysadmins feel the same. --Ed From eparis at redhat.com Thu Jan 3 21:36:57 2008 From: eparis at redhat.com (Eric Paris) Date: Thu, 03 Jan 2008 16:36:57 -0500 Subject: Another selinux rant In-Reply-To: References: Message-ID: <1199396217.3716.45.camel@localhost.localdomain> Could you explain how you 'copied' these configuration files? Is this tar/untar ? I'm trying to figure out how the labels for stuff in ~/.ssh got messed up for you. as to ipp.txt i don't know what it is so I can't even begin to guess.... -Eric On Thu, 2008-01-03 at 13:29 -0800, Ed Swierk wrote: > Since someone asked, here's my little SELinux rant: > > Yesterday I set up a new server running F8. It's replacing an old > server and all it does is run sshd and openvpn. I decided to give > SELinux a try after many years of ignoring it. > > I copied user home directories, /etc/passwd, /etc/shadow, /etc/group, > and ssh host keys from the old server to the new one. That was easy > enough. > > I couldn't log into the machine using ssh public key authentication, > though--ssh kept falling back to password authentication. I checked > all the usual suspects like directory permissions, to no avail. I > passed -v -v -v to ssh and got no useful information. > > After some poking around I noticed a bunch of messages in > /var/log/messages along the lines of "audit denied sshd btmp" and > "audit denied sshd /home/eswierk/..." blah blah blah. I figured this > was due to SELinux (although heaven knows why the message doesn't > contain the word "selinux"). Spent some time searching Google and came > across fixfiles, so I ran "fixfiles restore /", restarted sshd, and > voila, I could log in with a public key. > > Next I copied the openvpn configuration from the old server and tried > to start it up. No joy. Having learned my lesson I headed straight to > /var/log/messages and once again found messages from SELinux, like > "audit denied openvpn ipp.txt". I ran "fixfiles restore /" again, but > this time it didn't help. Back to Google, and dug up some mailing list > messages with all sorts of stuff about updating policies. I spent > about 10 minutes trying various things without really understanding > them before resorting to the solution I do understand: set > SELINUX=disabled in /etc/sysconfig/selinux, reboot, done. > > For me learning SELinux seems as pointless as trying to remember > iptables commands, or AFS trivia back when I was a student--all cause > me trouble just infrequently enough to ensure I have to relearn them > from scratch every time. If I were a full-time sysadmin of course it > would be a different story, but I really don't have the brain cycles > to remember anything more complicated than chmod and chown, and I > suspect a large number of accidental sysadmins feel the same. > > --Ed > From eswierk at arastra.com Thu Jan 3 21:49:17 2008 From: eswierk at arastra.com (Ed Swierk) Date: Thu, 3 Jan 2008 13:49:17 -0800 Subject: Another selinux rant In-Reply-To: <1199396217.3716.45.camel@localhost.localdomain> References: <1199396217.3716.45.camel@localhost.localdomain> Message-ID: On 1/3/08, Eric Paris wrote: > Could you explain how you 'copied' these configuration files? Is this > tar/untar ? I'm trying to figure out how the labels for stuff in ~/.ssh > got messed up for you. Yes, I used tar to copy /home and /etc/openvpn. Openvpn stores state for active connections in a file specified by the --ifconfig-pool-persist option. Since the openvpn configuration recipe I found online uses /etc/openvpn/ipp.txt, that's what I use. Presumably the SELinux policy wants me to store that file somewhere else? --Ed From icon at fedoraproject.org Thu Jan 3 21:55:32 2008 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Thu, 3 Jan 2008 16:55:32 -0500 Subject: Another selinux rant In-Reply-To: References: Message-ID: On Jan 3, 2008 4:29 PM, Ed Swierk wrote: > For me learning SELinux seems as pointless as trying to remember > iptables commands, or AFS trivia back when I was a student--all cause > me trouble just infrequently enough to ensure I have to relearn them > from scratch every time. If I were a full-time sysadmin of course it > would be a different story, but I really don't have the brain cycles > to remember anything more complicated than chmod and chown, and I > suspect a large number of accidental sysadmins feel the same. Well, if it's any consolation, there are those of us who really quite appreciate SELinux. It's really not that intrusive in targeted mode -- I've been running my workstations in enforcing mode for the past 2 years, and it's only fairly rarely that I find something that's not working because of SELinux. In these cases, if it's something that I have to do on a one-off basis, I just do "setenforce 0" and then "setenforce 1" when I'm done (or just leave it as is until next reboot). Yes, SELinux is very complex, but that's because what it's trying to do is also very complex. However, it's not insurmountable to learn. Take it from someone who had to write an SELinux policy -- it took me a week worth of effort to get to the point where it worked as intended, but I finally got there. Once you wrap your brain around it, it's fairly straightforward. Regards, -- Konstantin Ryabitsev Montr?al, Qu?bec From pertusus at free.fr Thu Jan 3 21:57:26 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 3 Jan 2008 22:57:26 +0100 Subject: Policy proposal for compatibility packages In-Reply-To: References: <477C0FE7.60105@redhat.com> <20080102225303.GJ2661@free.fr> <1199316723.24135.2.camel@nixon> <20080102233619.GM2661@free.fr> <1199317946.24135.14.camel@nixon> <20080103144235.GB2713@free.fr> <20080103154005.GC3997@free.fr> Message-ID: <20080103215726.GA14439@free.fr> On Thu, Jan 03, 2008 at 09:35:37PM +0100, Linus Walleij wrote: > On Thu, 3 Jan 2008, Patrice Dumas wrote: > >>> And then s/he knows that in Fedora, we love to discard old >>> API:s. >> >> I hope it is untrue. I hope everybody here dislikes breaking API and >> ABIs and try to push the upstreams to be responsible with API/ABI. > > Of course upstream is responsible, man, calm down. No, I am saying that we should push upstream to have backward compatible API, as long as it doesn't deter innovation. > It seems you read me like I thought breaking API/ABI was a goal in itself, > that's not what I meant. You also seem to say that having backward compatible API is not a goal in itself. In my opinion it is, and it is among the responsibility of distribution packagers to communicate with upstream to avoid incompatible API change, because upstream has less incentive than us to avoid API change. Of course users are the category with most need for API stability, but their only way to communicate thir concerns is to leave fedora and try a distro with less issues with broken deps in updates linked with soname bumps -- even when fedora packagers are not the culprits, and upstream is. -- Pat From ed at eh3.com Thu Jan 3 21:57:43 2008 From: ed at eh3.com (Ed Hill) Date: Thu, 3 Jan 2008 16:57:43 -0500 Subject: Another selinux rant In-Reply-To: References: Message-ID: <20080103165743.442e37bc@localhost.localdomain> On Thu, 3 Jan 2008 13:29:18 -0800 "Ed Swierk" wrote: > Since someone asked, here's my little SELinux rant: [ ...rant truncated... :-) ] > For me learning SELinux seems as pointless as trying to remember > iptables commands, or AFS trivia back when I was a student--all cause > me trouble just infrequently enough to ensure I have to relearn them > from scratch every time. If I were a full-time sysadmin of course it > would be a different story, but I really don't have the brain cycles > to remember anything more complicated than chmod and chown, and I > suspect a large number of accidental sysadmins feel the same. I run into similar problems every time I've tried to enable SELinux. I now run it in "permissive" mode on most of my machines and watch the occasional warnings appear in /var/log/messages. But I think the situation is improving since I'm seeing fewer warnings in F8 than with F7 or FC6. And you can install the "sealert" packages: setroubleshoot.noarch setroubleshoot-plugins.noarch setroubleshoot-server.noarch which provide much more detailed and helpful diagnostic messages. Ed -- Edward H. Hill III, PhD | ed at eh3.com | http://eh3.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Thu Jan 3 22:06:55 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 03 Jan 2008 23:06:55 +0100 Subject: New tcl-8.5 and 8Kingdoms Message-ID: <477D5C7F.6050708@hhs.nl> Hi all, I just tried building 8Kingdoms with the new tcl in rawhide, it builds fine, but it does not work. Any of the actions (moving a unit for example) which normally invoke a tcl script underneath now no longer work. I'm quite good in fixing C bugs but this problem lies either in the interfacing with tcl or in the tcl code itself and I'm helpless there. So I hope that someone can try running 8Kingdoms with tcl 8.5, and write a fix. Note I've also send a request upstream asking for help, I'll report back here as soon as I get response. If I don't have it fixed by F-9 then I will have to remove 8Kingdoms from Fedora's repositories (better then shipping a broken version). Thanks & Regards, Hans From dwalsh at redhat.com Thu Jan 3 22:07:33 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 03 Jan 2008 17:07:33 -0500 Subject: selinux rant, compressed version (Was Re: kernels won't boot) In-Reply-To: <1199393006.10354.16.camel@oneill.fubar.dk> References: <200712221216.lBMCGW8U004528@porkchop.devel.redhat.com> <200712220828.48202.sgrubb@redhat.com> <1199385283.2850.1.camel@oneill.fubar.dk> <477D3178.9020108@redhat.com> <1199387293.3716.39.camel@localhost.localdomain> <1199387346.2850.24.camel@oneill.fubar.dk> <1199389522.4670.95.camel@dimi.lattica.com> <1199393006.10354.16.camel@oneill.fubar.dk> Message-ID: <477D5CA5.7030401@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Zeuthen wrote: > On Thu, 2008-01-03 at 14:45 -0500, Dimi Paun wrote: >> On Thu, 2008-01-03 at 14:09 -0500, David Zeuthen wrote: >>> I'm not running SELinux enforcing mode on any of my machines.. >> That's too bad -- it's hard to gage the usability of a system >> without it on, since it is enabled by default for most people. > > Well, the kernel bits of SELinux is great. The user space bits never > ever worked for me; neither as a user, nor RPM package maintainer and > definitely not as an upstream developer of highly modular software that > is designed to be locked down (e.g. hald and it's helper processes) > > Some problems from a 50,000 feet point of view > > - the policy is way too complicated; really, I think it's kinda futile, > at this point, to attempt to lock down bits that are not even > network-facing. > > As a result someone decided "oh, we're just going to let people turn > of it". And this is where we are now. Total cop out. Might as well > not ship it. > > Seriously. Just go ahead and look at the policy. No wonder it often > doesn't work given it's so complex. > > - the policy is centrally maintained; e.g. the maintainer of the policy > for hald (Dan Walsh) and, hey, all of the policy often have to guess > how to lock things down and often, despite Dan being a great > engineer, these guesses are just wrong. Seriously, no one can blame > Dan for this - you cannot expect a single person to know all the > kinks of all the software in Fedora. > > -> Ideally every upstream project can maintain it's own policy. That > has the nice side effect of, gosh, teaching other distributions > about the benefits of MCA. > > -> If upstream don't want to include SELinux policy, just include > it as a patch in the RPM > > Typical responses: > - "rpm cannot handle SELinux policy": <- bullshit; it's not much > different from other file meta data; do we store file modes and > permissions centrally too? No. > > - "uh, then you would have deps on policy": Like, for example, the > policy for hald would depend on the policy for, say, dbus. Not > a problem, the real world contains dependencies already and most > these deps are handled just fine already by the upstream > projects. > > I'm not even going to go into the language used for defining policy. > > In short, SELinux just doesn't work for me. I'm not denying it may work > well on a tightly-controlled servers where features never change (e.g. > RHEL). > > David > > Well there are several problems with allowing the individual maintainers manage their own policy. #1 they won't. #2 when they do, they do a very bad job of it. Or basically just end up with unconfined_t. #3 The tools are too slow. Having 100 semodule -i will cause the installation to take for ever. #4 Interaction between confined domains does not work well when multiple maintainers writing policy. sendmail, procmail, spamassassin, clamav, postfix, qmail, mailserver, pyzor ... All interact in very complex ways. #5 conflicts on file_context directories/files David, You are writing an application that is trying to do things on behalf of the user as root. These activities will cause conflicts and need to be well controlled. So you are likely to run into problems with SELinux. Jesse, what problems are you seeing that needs to run in permissive mode? I know about the chroot environments and there is not a good answer to this. Placing of the file context down without loading the SELInux policy would help in this environment. But we would still have problems with applications running in post install, not getting the correct context. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkd9XKQACgkQrlYvE4MpobNNxgCg6RQ5obJYQlybtl275oLfpdD1 pkwAoKOpjXe5mubk7MsUpBRNE6k1YGzp =jfZz -----END PGP SIGNATURE----- From wart at kobold.org Thu Jan 3 22:07:03 2008 From: wart at kobold.org (Michael Thomas) Date: Thu, 03 Jan 2008 14:07:03 -0800 Subject: New tcl-8.5 and 8Kingdoms In-Reply-To: <477D5C7F.6050708@hhs.nl> References: <477D5C7F.6050708@hhs.nl> Message-ID: <477D5C87.2010106@kobold.org> Hans de Goede wrote: > Hi all, > > I just tried building 8Kingdoms with the new tcl in rawhide, it builds > fine, but it does not work. > > Any of the actions (moving a unit for example) which normally invoke a > tcl script underneath now no longer work. > > I'm quite good in fixing C bugs but this problem lies either in the > interfacing with tcl or in the tcl code itself and I'm helpless there. > So I hope that someone can try running 8Kingdoms with tcl 8.5, and write > a fix. > > Note I've also send a request upstream asking for help, I'll report back > here as soon as I get response. > > If I don't have it fixed by F-9 then I will have to remove 8Kingdoms > from Fedora's repositories (better then shipping a broken version). Did you have to make any changes to 8Kingdoms to get it to build with Tcl 8.5? If so please pass along any patches. I'll try building and running it myself to see if I can track down the problem. --Wart From j.w.r.degoede at hhs.nl Thu Jan 3 22:15:34 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 03 Jan 2008 23:15:34 +0100 Subject: New tcl-8.5 and 8Kingdoms In-Reply-To: <477D5C87.2010106@kobold.org> References: <477D5C7F.6050708@hhs.nl> <477D5C87.2010106@kobold.org> Message-ID: <477D5E86.2030004@hhs.nl> Michael Thomas wrote: > Hans de Goede wrote: >> Hi all, >> >> I just tried building 8Kingdoms with the new tcl in rawhide, it builds >> fine, but it does not work. >> >> Any of the actions (moving a unit for example) which normally invoke a >> tcl script underneath now no longer work. >> >> I'm quite good in fixing C bugs but this problem lies either in the >> interfacing with tcl or in the tcl code itself and I'm helpless there. >> So I hope that someone can try running 8Kingdoms with tcl 8.5, and write >> a fix. >> >> Note I've also send a request upstream asking for help, I'll report back >> here as soon as I get response. >> >> If I don't have it fixed by F-9 then I will have to remove 8Kingdoms >> from Fedora's repositories (better then shipping a broken version). > > Did you have to make any changes to 8Kingdoms to get it to build with > Tcl 8.5? If so please pass along any patches. I'll try building and > running it myself to see if I can track down the problem. > Nope, No changes, I also did a diff between the buildlogs, no new compiler warnings or anything like that. I did build it with gcc-4.3, as I was working on it not building with gcc-4.3 too. I've just committed my latest 8Kingdoms work to cvs, so you can get it from there, including a patch for the crash you reported (tested using tcl 8.4). Thanks, Hans From jakub.rusinek at gmail.com Thu Jan 3 22:09:35 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Thu, 03 Jan 2008 23:09:35 +0100 Subject: Control center idea In-Reply-To: <477D4784.30000@fedoraproject.org> References: <1199374110.5023.2.camel@frosty> <477D001B.8090203@fedoraproject.org> <1199392493.7512.8.camel@frosty> <477D4784.30000@fedoraproject.org> Message-ID: <1199398175.9971.0.camel@frosty> I'm not developer. I'm only end-user, who became an packager. Dnia 04-01-2008, pi? o godzinie 02:07 +0530, Rahul Sundaram pisze: > Jakub 'Livio' Rusinek wrote: > > Dnia 03-01-2008, czw o godzinie 21:02 +0530, Rahul Sundaram pisze: > >> If you are interested in maintaining Yast, a port of it for RHEL is > >> available at which should work on Fedora too with possibly minor changes. > >> > >> http://oss.oracle.com/projects/yast/ > >> > >> Rahul > >> > > > > No GTK support. > > mv YaST > /dev/null :( > > It is not the latest version. Both the suggestions are something for you > to potentially start with. You don't get anything yet that would just > fit in right away. > > Rahul > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? wiadomo?ci podpisana cyfrowo URL: From jakub.rusinek at gmail.com Thu Jan 3 22:10:49 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Thu, 03 Jan 2008 23:10:49 +0100 Subject: Control center idea In-Reply-To: <477D47C8.2030304@fedoraproject.org> References: <1199374110.5023.2.camel@frosty> <477D001B.8090203@fedoraproject.org> <1199391525.7512.2.camel@frosty> <477D47C8.2030304@fedoraproject.org> Message-ID: <1199398249.9971.2.camel@frosty> Dnia 04-01-2008, pi? o godzinie 02:08 +0530, Rahul Sundaram pisze: > Jakub 'Livio' Rusinek wrote: > > >> http://www.indianoss.org/modules/wfdownloads/viewcat.php?cid=10 > > > > Maintain = put into repo :> ? > > > > Probably not... "January 17, 2006" - holy **it... It's old. > > It was in the repository before for sometime and you would need to > update it. Program was not updated. I can't put old software into repo - isn't not my policy... > > Not sure about users opinion and OSS-environment reaction :> . > > Not sure what that means. If you are willing to maintain it, just go > ahead and do it. I am sure opinions would be mixed. You're of course right ;) . -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? wiadomo?ci podpisana cyfrowo URL: From jkeating at redhat.com Thu Jan 3 22:16:19 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 3 Jan 2008 17:16:19 -0500 Subject: selinux rant, compressed version (Was Re: kernels won't boot) In-Reply-To: <477D5CA5.7030401@redhat.com> References: <200712221216.lBMCGW8U004528@porkchop.devel.redhat.com> <200712220828.48202.sgrubb@redhat.com> <1199385283.2850.1.camel@oneill.fubar.dk> <477D3178.9020108@redhat.com> <1199387293.3716.39.camel@localhost.localdomain> <1199387346.2850.24.camel@oneill.fubar.dk> <1199389522.4670.95.camel@dimi.lattica.com> <1199393006.10354.16.camel@oneill.fubar.dk> <477D5CA5.7030401@redhat.com> Message-ID: <20080103171619.5ab2032a@redhat.com> On Thu, 03 Jan 2008 17:07:33 -0500 Daniel J Walsh wrote: > Jesse, what problems are you seeing that needs to run in permissive > mode? I know about the chroot environments and there is not a good > answer to this. Placing of the file context down without loading the > SELInux policy would help in this environment. But we would still > have problems with applications running in post install, not getting > the correct context. What I've seen is if selinux is in enforcing part of the compose process will fail in such a way that selinux will default to /off/ for the resulting composed media (funny eh?). I think it had something to do with a denial, but the memory is hazy. But since most of my composing involves A) mock for the initial compose environment (that's one chroot) and B) buildinstall itself creating an install root to populate stage1/2 contents (that's two chroots) I kind of feel I'm out in left field. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From triad at df.lth.se Thu Jan 3 22:21:06 2008 From: triad at df.lth.se (Linus Walleij) Date: Thu, 3 Jan 2008 23:21:06 +0100 (CET) Subject: Disabling selinux question Message-ID: Here's a spinoff relating to selinux from discussions around system-config-services and its UI. selinux seem to involve the following services/daemons: auditd mcstrans restorecond setroubleshoot If I use system-config-selinux or anaconda to disable SELinux altogether, then none of these are disabled accordingly. The only case seems to be that auditd is turn on if I disable them all manually and then enable SELinux. Is this a bug or is there something I don't get here? (I have a few similar issues with the services, but SELinux came up so just taking the opportunity to ask.) Linus From eparis at redhat.com Thu Jan 3 22:34:00 2008 From: eparis at redhat.com (Eric Paris) Date: Thu, 03 Jan 2008 17:34:00 -0500 Subject: Disabling selinux question In-Reply-To: References: Message-ID: <1199399640.3716.65.camel@localhost.localdomain> On Thu, 2008-01-03 at 23:21 +0100, Linus Walleij wrote: > Here's a spinoff relating to selinux from discussions around > system-config-services and its UI. selinux seem to involve the following > services/daemons: > > auditd selinux uses auditd but they are not at all closely coupled. selinux will function fine without auditd and auditd provides all of its capabilities without selinux. There is no reason these 2 should be coupled together. > mcstrans > restorecond > setroubleshoot > > If I use system-config-selinux or anaconda to disable SELinux altogether, > then none of these are disabled accordingly. The only case seems to be > that auditd is turn on if I disable them all manually and then enable > SELinux. I don't think as a general rule that we couple services ever (maybe we do and i just don't know it) but I don't think disabling your mta is going to disable webmail. I however don't think it would be unreasonable to file an anaconda bug and say that if selinux is disabled the above 3 programs shouldn't be set to automatically start. If that goes anywhere you could file against system-config-selinux (or vice versa) -Eric From jdennis at redhat.com Thu Jan 3 22:43:41 2008 From: jdennis at redhat.com (John Dennis) Date: Thu, 03 Jan 2008 17:43:41 -0500 Subject: Disabling selinux question In-Reply-To: References: Message-ID: <477D651D.2070208@redhat.com> Linus Walleij wrote: > Here's a spinoff relating to selinux from discussions around > system-config-services and its UI. selinux seem to involve the following > services/daemons: > > auditd > mcstrans > restorecond > setroubleshoot > > If I use system-config-selinux or anaconda to disable SELinux > altogether, then none of these are disabled accordingly. The only case > seems to be that auditd is turn on if I disable them all manually and > then enable SELinux. > > Is this a bug or is there something I don't get here? auditd is the general auditing facility, SELinux messages are just one of the possible auditing messages. You wouldn't want to disable auditing just because SELinux was disabled, that would disable all auditing. setroubleshootd is a diagnostic tool. If SELinux is completely disabled the daemon exits if started. Your expectation seems to be that if you disable SELinux it will chkconfig off certain daemons. There is a distinction between having a daemon started (e.g. chkconfig on) and whether it continues to run once started. Allowing the daemon to decide if it should run or exit is more robust than some utility which thinks it knows if something should be chkconfig'ed on or not because it will almost certainly get that answer wrong. -- John Dennis From david at fubar.dk Thu Jan 3 22:46:51 2008 From: david at fubar.dk (David Zeuthen) Date: Thu, 03 Jan 2008 17:46:51 -0500 Subject: selinux rant, compressed version (Was Re: kernels won't boot) In-Reply-To: <477D5CA5.7030401@redhat.com> References: <200712221216.lBMCGW8U004528@porkchop.devel.redhat.com> <200712220828.48202.sgrubb@redhat.com> <1199385283.2850.1.camel@oneill.fubar.dk> <477D3178.9020108@redhat.com> <1199387293.3716.39.camel@localhost.localdomain> <1199387346.2850.24.camel@oneill.fubar.dk> <1199389522.4670.95.camel@dimi.lattica.com> <1199393006.10354.16.camel@oneill.fubar.dk> <477D5CA5.7030401@redhat.com> Message-ID: <1199400411.3251.7.camel@oneill.fubar.dk> On Thu, 2008-01-03 at 17:07 -0500, Daniel J Walsh wrote: > Well there are several problems with allowing the individual maintainers > manage their own policy. > > #1 they won't. > #2 when they do, they do a very bad job of it. Or basically just end up > with unconfined_t. > #3 The tools are too slow. Having 100 semodule -i will cause the > installation to take for ever. > #4 Interaction between confined domains does not work well when multiple > maintainers writing policy. > sendmail, procmail, spamassassin, clamav, postfix, qmail, mailserver, > pyzor ... All interact in very complex ways. > #5 conflicts on file_context directories/files See.. cause and effect.. #1 and #2 are the effects of #3 and the fact that the policy is way too big and the whole system is way too complicated. Besides.. I have asked probably more than ten times (both electronically and in person) about maintaining the selinux policy for hal in the _upstream_ tarball but I've always been told that it's not possible or I've been told to wait. In the meantime it's business as usual; things are broken and people turn off SELinux. Here's a challenge: Send me a patch against the hal git repo and the RPM spec with the SELinux bits... Then I'll be happy to maintain it; including spending time on learning SELinux well enough to do a good job. Is this even possible? Should it be possible? > David, You are writing an application that is trying to do things on > behalf of the user as root. These activities will cause conflicts and > need to be well controlled. So you are likely to run into problems with > SELinux. Sigh. Do you really honestly think this is a good answer for upstream maintainers that are _willing_ to help? David From dmc.fedora at filteredperception.org Thu Jan 3 22:57:27 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Thu, 03 Jan 2008 16:57:27 -0600 Subject: f8 gripe#2: why did f8's pm-hibernate regress? In-Reply-To: <1199386410.3261.9.camel@sb-home> References: <477ADF46.2040108@filteredperception.org> <200801021159.17964.opensource@till.name> <477C299D.2060400@filteredperception.org> <477C96B8.6040903@filteredperception.org> <1199382316.3261.7.camel@sb-home> <20080103132336.02d95812@redhat.com> <1199386410.3261.9.camel@sb-home> Message-ID: <477D6857.3060707@filteredperception.org> nodata wrote: > Am Donnerstag, den 03.01.2008, 13:23 -0500 schrieb Jesse Keating: >> On Thu, 03 Jan 2008 18:45:16 +0100 >> nodata wrote: >> >>> I don't know why people keep saying this. Vista boots fast and is >>> responsive. lol. >> Not on my brand new shiny Dell M1330. 2 gigs of ram, a fast core2duo >> cpu, and Vista was very slow to boot up (win2k speeds...) and once >> booted and I logged in it was another long wait for everything to >> settle down. Even then it was pretty unresponsive. > > Mine boots in about 45 seconds, and then I launch putty and get on with > some work. Are you running something heavyweight? > To be completely fair to microsoft, I'll admit that my issues may also be heavily influenced by sony's participation in the spin of vista that came with my laptop. Also, my point was more about *first impressions* the user has with an OS. I imagine that once vista has had a day to churn on my laptop after fresh install/factory-recover, that it will boot much faster, and be more responsive more quickly. But when a new user buys a laptop like mine, turns it on for the first time, and logs in the first time, it quite seriously has HOURS of high IO churn that it needs to get through. As a result, a users first experience with the OS, is at its worst. Not a great design tradeoff choice IMO. Which really makes no sense, as a factory recover shouldn't need to precompute anything or build any initial databases that are going to be exactly the same on every other piece of identical hardware. But yet, that seems to be what is happening... -dmc From alexl at users.sourceforge.net Thu Jan 3 23:28:01 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Thu, 03 Jan 2008 16:28:01 -0700 Subject: Cristian Balint seems to be a non-responsive maintainer Message-ID: <7hfxxejxq6.fsf@allele2.eebweb.arizona.edu> Hi there, As per the policy[1], I'm making formal request to mark Cristian Balint as an non-responsive maintainer. Repeated attempts over the last few months via bugzilla have not been responded to, two examples: https://bugzilla.redhat.com/show_bug.cgi?id=341391 (grass) https://bugzilla.redhat.com/show_bug.cgi?id=414441 (gdal) Lack of reponse has meant that all packages related to various GIS packages such as gdal, grass, mapserver have languished with broken deps in rawhide for over a month. Also, he has not rebuilt a single package via koji since 02 August 2007 [2] and is not listed as being on vacation[3]. Before mass orphaning, at the very least, I recommend that ACLs for cvsextras members be opened up on his packages to allow rebuilds of these packages in rawhide, especially since these GIS packages aren't packages that usually ship by default on any spin and are very much leaf packages. Alex [1] http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers [2] http://koji.fedoraproject.org/koji/userinfo?userID=303 [3] http://fedoraproject.org/wiki/Vacation From tcallawa at redhat.com Thu Jan 3 23:45:59 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 03 Jan 2008 18:45:59 -0500 Subject: Cristian Balint seems to be a non-responsive maintainer In-Reply-To: <7hfxxejxq6.fsf@allele2.eebweb.arizona.edu> References: <7hfxxejxq6.fsf@allele2.eebweb.arizona.edu> Message-ID: <477D73B7.6050202@redhat.com> Alex Lancaster wrote: > Hi there, > > As per the policy[1], I'm making formal request to mark Cristian > Balint as an non-responsive maintainer. Repeated attempts over the > last few months via bugzilla have not been responded to, two examples: > > https://bugzilla.redhat.com/show_bug.cgi?id=341391 (grass) > > https://bugzilla.redhat.com/show_bug.cgi?id=414441 (gdal) > > Lack of reponse has meant that all packages related to various GIS > packages such as gdal, grass, mapserver have languished with broken > deps in rawhide for over a month. Also, he has not rebuilt a single > package via koji since 02 August 2007 [2] and is not listed as being > on vacation[3]. > > Before mass orphaning, at the very least, I recommend that ACLs for > cvsextras members be opened up on his packages to allow rebuilds of > these packages in rawhide, especially since these GIS packages aren't > packages that usually ship by default on any spin and are very much > leaf packages. cbalint is no longer with RHAT, which may be why he has not responded to any issues. ACLs have been opened for cvsextras on: fftw2, gdal, grass, iverilog, libdap, libgeotiff, mapserver, and ogdi ~spot From pertusus at free.fr Thu Jan 3 23:57:31 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 4 Jan 2008 00:57:31 +0100 Subject: Cristian Balint seems to be a non-responsive maintainer In-Reply-To: <477D73B7.6050202@redhat.com> References: <7hfxxejxq6.fsf@allele2.eebweb.arizona.edu> <477D73B7.6050202@redhat.com> Message-ID: <20080103235731.GE14439@free.fr> On Thu, Jan 03, 2008 at 06:45:59PM -0500, Tom spot Callaway wrote: > > cbalint is no longer with RHAT, which may be why he has not responded to > any issues. > > ACLs have been opened for cvsextras on: > > fftw2, gdal, grass, iverilog, libdap, libgeotiff, mapserver, and ogdi He affirmed that he would make the backporting of libdap security patches in epel (libdap changes API about every year) :-\ It was a condition for me for inclusion of libdap in EPEL... I am not fluent enough in C++ to do that work. Anyway it is too late now, it is in EPEL, just hoping that no security issue will creep in... -- Pat From devrim at CommandPrompt.com Fri Jan 4 00:06:35 2008 From: devrim at CommandPrompt.com (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=) Date: Thu, 03 Jan 2008 16:06:35 -0800 Subject: Cristian Balint seems to be a non-responsive maintainer In-Reply-To: <477D73B7.6050202@redhat.com> References: <7hfxxejxq6.fsf@allele2.eebweb.arizona.edu> <477D73B7.6050202@redhat.com> Message-ID: <1199405195.3435.192.camel@localhost.localdomain> On Thu, 2008-01-03 at 18:45 -0500, Tom "spot" Callaway wrote: > > ACLs have been opened for cvsextras on: > > gdal, grass, mapserver I've packaged gdal, mapserver and grass for my company about a year ago. I can work on these packages it noone beats me. Regards, -- Devrim G?ND?Z , RHCE PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Fri Jan 4 00:04:34 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 04 Jan 2008 05:34:34 +0530 Subject: Potential bad dependencies: NetworkManager-gnome, totem and system-config-display Message-ID: <477D7812.9070205@fedoraproject.org> Hi While creating the Xfce spin for Fedora 8, I noticed a few packages seem to have a bad dependency list. NetworkManager-gnome has a hard dependency on things like gnome-panel and gnome-keyring. Totem has a hard dependency on gnome-desktop and gnome-themes. system-config-display has a hard dependency on metacity. Are these really required? Can we fix these? # yum install NetworkManager-gnome ============================================================================= Package Arch Version Repository Size ============================================================================= NetworkManager-gnome i386 1:0.7.0-0.6.6.svn3109.fc8 updates 235 k Installing for dependencies: PolicyKit-gnome i386 0.6-1.fc8 fedora 34 k evolution-data-server i386 1.12.2-1.fc8 updates 3.7 M fedora-gnome-theme noarch 8.0.0-1.fc8 fedora 10 k fedora-icon-theme noarch 1.0.0-1.fc8 fedora 115 k gnome-desktop i386 2.20.2-1.fc8 updates 952 k gnome-keyring i386 2.20.2-1.fc8 updates 210 k gnome-menus i386 2.20.2-1.fc8 updates 200 k gnome-mime-data noarch 2.18.0-2.fc7 fedora 724 k gnome-mount i386 0.7-1.fc8 fedora 126 k gnome-panel i386 2.20.2-1.fc8 updates 3.4 M gnome-themes noarch 2.20.2-1.fc8 updates 2.5 M gnome-vfs2 i386 2.20.1-1.fc8 updates 1.1 M libbonoboui i386 2.20.0-1.fc8 fedora 352 k libgnome i386 2.20.1-2.fc8 fedora 966 k libgnomeui i386 2.20.1.1-1.fc8 fedora 1.0 M nodoka-theme-gnome noarch 0.3.2-2.fc8 fedor 11 k # yum install totem ============================================================================= Package Arch Version Repository Size ============================================================================= PolicyKit-gnome i386 0.6-1.fc8 fedora 34 k fedora-gnome-theme noarch 8.0.0-1.fc8 fedora 10 k fedora-icon-theme noarch 1.0.0-1.fc8 fedora 115 k gnome-desktop i386 2.20.2-1.fc8 updates 952 k gnome-keyring i386 2.20.2-1.fc8 updates 210 k gnome-mime-data noarch 2.18.0-2.fc7 fedora 724 k gnome-mount i386 0.7-1.fc8 fedora 126 k gnome-themes noarch 2.20.2-1.fc8 updates 2.5 M gnome-vfs2 i386 2.20.1-1.fc8 updates 1.1 M gstreamer-plugins-base i386 0.10.15-1.fc8 updates 879 k gstreamer-plugins-good i386 0.10.6-6.fc8 fedora 835 k libbonoboui i386 2.20.0-1.fc8 fedora 352 k libgnome i386 2.20.1-2.fc8 fedora 966 k libgnomeui i386 2.20.1.1-1.fc8 fedora 1.0 M nautilus-extensions i386 2.20.0-6.fc8 fedora 41 k nodoka-theme-gnome noarch 0.3.2-2.fc8 fedora 11 k totem-plparser i386 2.20.1-2.fc8 updates 42 k # # yum install system-config-display ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: system-config-display noarch 1.0.51-4.fc8 fedora 186 k Installing for dependencies: metacity i386 2.20.1-1.fc8 updates 2.2 M nodoka-metacity-theme noarch 0.3.2-2.fc8 fedora 7.8 k Rahul From sgrubb at redhat.com Fri Jan 4 01:17:54 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Thu, 3 Jan 2008 20:17:54 -0500 Subject: selinux rant, compressed version (Was Re: kernels won't boot) In-Reply-To: <1199400411.3251.7.camel@oneill.fubar.dk> References: <200712221216.lBMCGW8U004528@porkchop.devel.redhat.com> <477D5CA5.7030401@redhat.com> <1199400411.3251.7.camel@oneill.fubar.dk> Message-ID: <200801032017.54686.sgrubb@redhat.com> On Thursday 03 January 2008 17:46:51 David Zeuthen wrote: > > #1 they won't. > > #2 when they do, they do a very bad job of it. ?Or basically just end up > > with unconfined_t. > > #3 The tools are too slow. ?Having 100 semodule -i will cause the > > installation to take for ever. > > #4 Interaction between confined domains does not work well when multiple > > ? maintainers writing policy. > > sendmail, procmail, spamassassin, clamav, postfix, qmail, mailserver, > > pyzor ... All interact in very complex ways. > > #5 conflicts on file_context directories/files > > See.. cause and effect.. #1 and #2 are the effects of #3 I don't think this is true at all. semodule being slow has nothing to do with people thinking about security. It takes time and testing a lot of variations of config options to arrive at what the application is supposed to do. Some people also may not recognize when an avc means the code needs to change instead of allowing the behavior. I think that #4 is the real killer. Dan did a major reworking of policy in F8 to merge what was the strict policy with targeted. The way that roles work was beefed up. If this had to be coordinated with every single package maintainer, it probably wouldn't have gotten done as quickly or as uniformly. > and the fact that the policy is way too big and the whole system is way too > complicated. This is more a fact of it telling you that software in general is complicated. SE Linux is describing the allowed behavior at a level that is slightly above the syscall level. If the syscalls a program makes change, the policy may need reworking. This is probably why you run into problems frequently as you are developing and testing new code (with new syscalls) that is central to many programs. I wonder if a tool could be developed to do something like nmap and compare current syscalls with an older version. It wouldn't be able to track resource usage (files/sockets), which is another thing selinux regulates, but it could tell you a little about if a new version is going to have problems. If we could simply tell that a new package required policy changes, that would be half the battle. -Steve From ivazqueznet at gmail.com Fri Jan 4 01:19:07 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Thu, 03 Jan 2008 20:19:07 -0500 Subject: Python packages in Rawhide (was: Re: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220) In-Reply-To: <20080103120242.GZ20451@devserv.devel.redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> Message-ID: <1199409547.3463.6.camel@ignacio.lan> On Thu, 2008-01-03 at 07:02 -0500, Jakub Jelinek wrote: > fails-even-with-41/python-... Note that most of these are caused by egg info now being generated but not included by the spec file. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From lordmorgul at gmail.com Fri Jan 4 01:52:56 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Thu, 03 Jan 2008 17:52:56 -0800 Subject: Another selinux rant In-Reply-To: References: Message-ID: <477D9178.6090709@gmail.com> Ed Swierk wrote: > For me learning SELinux seems as pointless as trying to remember > iptables commands, or AFS trivia back when I was a student--all cause > me trouble just infrequently enough to ensure I have to relearn them > from scratch every time. If I were a full-time sysadmin of course it > would be a different story, but I really don't have the brain cycles > to remember anything more complicated than chmod and chown, and I > suspect a large number of accidental sysadmins feel the same. Selinux is (no argument) something that takes considerable time to start figuring out... but basically you have to start by realizing nothing is going to work right if the files aren't labeled as the policy expects them to be. This is precisely the same situation you have when file permissions are wrong and nothing will work until you fix them (selinux policy is really just a more complicated permissions system for who can use files and for what purpose). When you started out with unices the permissions system probably took time but it eventually sank in -- so will selinux unless you continue to ignore it. Just food for thought... I'm sure everyone knows it takes time, the question becomes 'is it important' and alot of people feel the answer is yes. As the policies improve selinux will become hardly more complicated for general use as chmod itself is... proper policy + proper label = just works. Obviously both of those need to be in place and are in progress; so disable it when you must now but if you just ignore it long term its to your detriment. Set it permissive at minimum and keep the denial log messages for additional security review if/when you really need it. And finally, the ability to disable it is in the distro precisely so that you can (so why the rant? you want to be forced to enable it instead? you feel everyone should install without it enabled by default forever and ever? you feel that selinux should disable itself when you get denials that prevent you doing what you want? uhm that won't do). -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From katzj at redhat.com Thu Jan 3 13:03:37 2008 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 03 Jan 2008 08:03:37 -0500 Subject: Fedora 9 Feature Status In-Reply-To: <20080103094547.GA8487@angus.ind.WPI.EDU> References: <477C915E.4080402@redhat.com> <20080103094547.GA8487@angus.ind.WPI.EDU> Message-ID: <1199365417.3687.0.camel@aglarond.local> On Thu, 2008-01-03 at 04:45 -0500, Chuck Anderson wrote: > On Wed, Jan 02, 2008 at 11:40:14PM -0800, John Poelstra wrote: > > I've updated http://fedoraproject.org/wiki/Features/Dashboard to reflect > > the latest proposed features. > > This appears to be missing from the Dashboard but nice progress is > being made in anaconda: > > http://fedoraproject.org/wiki/Releases/FeatureEncryptedFilesystems > > I hope this gets targetted for Fedora 9 and voted on by FESco. I think that it was already voted on and approved... but I'm sending this while I don't have an active net connection so can't go and check Jeremy From wolfy at nobugconsulting.ro Fri Jan 4 02:09:22 2008 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Fri, 04 Jan 2008 04:09:22 +0200 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <477CE954.5000909@gmail.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <477CD6B0.7090203@gmail.com> <20080103130138.GB20451@devserv.devel.redhat.com> <477CE884.1010108@nobugconsulting.ro> <477CE954.5000909@gmail.com> Message-ID: <477D9552.3060801@nobugconsulting.ro> On 01/03/2008 03:55 PM, drago01 wrote: > Manuel Wolfshant wrote: >> One of my packages fails too: >> >> >> http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/unsorted/qfaxreader-0.3.1-8.fc8.1.log >> >> with: The software author suggested a small modification in configure which allowed the package to compile. I've added a patch to qfaxreader-0.3.1-9.fc9 and I have tested it with a [successful] koji scratch build. Of course I forgot that rebuilding in main koji is useless for the moment, since the new gcc has not been pushed... so I also did make build :) But anyway, the new src.rpm should be fine with gcc-4.3.0, whenever will it land. ... or so I hope. manuel From eswierk at arastra.com Fri Jan 4 02:33:17 2008 From: eswierk at arastra.com (Ed Swierk) Date: Thu, 3 Jan 2008 18:33:17 -0800 Subject: Another selinux rant In-Reply-To: <477D9178.6090709@gmail.com> References: <477D9178.6090709@gmail.com> Message-ID: On 1/3/08, Andrew Farris wrote: > As the policies improve selinux will become hardly more complicated for general > use as chmod itself is... proper policy + proper label = just works. Obviously > both of those need to be in place and are in progress; so disable it when you > must now but if you just ignore it long term its to your detriment. Set it > permissive at minimum and keep the denial log messages for additional security > review if/when you really need it. And finally, the ability to disable it is in > the distro precisely so that you can (so why the rant? you want to be forced to > enable it instead? you feel everyone should install without it enabled by > default forever and ever? you feel that selinux should disable itself when you > get denials that prevent you doing what you want? uhm that won't do). No, no and no. Dimi raised the issue of gauging the usability of SELinux, and the only point of my rant was to convey the experience that led me to disable it. --Ed From lordmorgul at gmail.com Fri Jan 4 03:05:21 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Thu, 03 Jan 2008 19:05:21 -0800 Subject: Another selinux rant In-Reply-To: References: <477D9178.6090709@gmail.com> Message-ID: <477DA271.6070208@gmail.com> Ed Swierk wrote: > On 1/3/08, Andrew Farris wrote: >> As the policies improve selinux will become hardly more complicated for general >> use as chmod itself is... proper policy + proper label = just works. Obviously >> both of those need to be in place and are in progress; so disable it when you >> must now but if you just ignore it long term its to your detriment. Set it >> permissive at minimum and keep the denial log messages for additional security >> review if/when you really need it. And finally, the ability to disable it is in >> the distro precisely so that you can (so why the rant? you want to be forced to >> enable it instead? you feel everyone should install without it enabled by >> default forever and ever? you feel that selinux should disable itself when you >> get denials that prevent you doing what you want? uhm that won't do). > > No, no and no. Dimi raised the issue of gauging the usability of > SELinux, and the only point of my rant was to convey the experience > that led me to disable it. > > --Ed Ok I understand then, however I'd just comment that as a gauge of usability I think your situation (moving configurations across platforms, from no selinux to selinux) is somewhat of a fringe case. I realize that MANY admins would be doing just that in the process of adopting selinux since rewriting configurations is a major pain, but its still something that can almost be expected to cause headache (and requires labeling). Just my 2c on usability, it still seems to work best when you start out from install with selinux enabled and avoid deliberately circumventing it. Would you say that documentation on that specific issue (migrating configurations) needs more attention? The big thing is any file moved has to get labeled. Your openvpn issue looks like it might be a real policy problem. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From lordmorgul at gmail.com Fri Jan 4 03:28:21 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Thu, 03 Jan 2008 19:28:21 -0800 Subject: selinux rant, compressed version (Was Re: kernels won't boot) In-Reply-To: <200801032017.54686.sgrubb@redhat.com> References: <200712221216.lBMCGW8U004528@porkchop.devel.redhat.com> <477D5CA5.7030401@redhat.com> <1199400411.3251.7.camel@oneill.fubar.dk> <200801032017.54686.sgrubb@redhat.com> Message-ID: <477DA7D5.9070209@gmail.com> Steve Grubb wrote: > I wonder if a tool could be developed to do something like nmap and compare > current syscalls with an older version. It wouldn't be able to track resource > usage (files/sockets), which is another thing selinux regulates, but it could > tell you a little about if a new version is going to have problems. If we > could simply tell that a new package required policy changes, that would be > half the battle. I don't know if that would be possible, but I think that would be beneficial and expedite getting the correct policy changes in place for testing updates as well as new packages. One major issue with testing these packages with enforced selinux is that you often cannot get the program to operate even enough to 'test' it, and it can take quite awhile to get the policy change so you can then continue trying enforcing mode. That tiring cycle is probably why so many testers just toggle it off, and then it just takes longer to find all the denials for test packages. I suppose the maintainer just doing a cursory selinux test of their own before getting package builds dropped into rawhide might help... I'm sure many do but it would seem that some don't. Just getting a BZ filed with the denials asap is important. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From poelstra at redhat.com Fri Jan 4 05:04:28 2008 From: poelstra at redhat.com (John Poelstra) Date: Thu, 03 Jan 2008 21:04:28 -0800 Subject: Fedora 9 Feature Status In-Reply-To: <1199365417.3687.0.camel@aglarond.local> References: <477C915E.4080402@redhat.com> <20080103094547.GA8487@angus.ind.WPI.EDU> <1199365417.3687.0.camel@aglarond.local> Message-ID: <477DBE5C.9050705@redhat.com> Jeremy Katz said the following on 01/03/2008 05:03 AM Pacific Time: > On Thu, 2008-01-03 at 04:45 -0500, Chuck Anderson wrote: >> On Wed, Jan 02, 2008 at 11:40:14PM -0800, John Poelstra wrote: >>> I've updated http://fedoraproject.org/wiki/Features/Dashboard to reflect >>> the latest proposed features. >> This appears to be missing from the Dashboard but nice progress is >> being made in anaconda: >> >> http://fedoraproject.org/wiki/Releases/FeatureEncryptedFilesystems >> >> I hope this gets targetted for Fedora 9 and voted on by FESco. > > I think that it was already voted on and approved... but I'm sending > this while I don't have an active net connection so can't go and check > > Jeremy > Nope. It hasn't been updated since August 2007 doesn't follow the current feature template. John From braden at endoframe.com Fri Jan 4 06:58:46 2008 From: braden at endoframe.com (Braden McDaniel) Date: Fri, 04 Jan 2008 01:58:46 -0500 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <477CF8E3.6050907@hhs.nl> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <477CF8E3.6050907@hhs.nl> Message-ID: <1199429926.5278.38.camel@hinge.endoframe.net> On Thu, 2008-01-03 at 16:01 +0100, Hans de Goede wrote: > Jakub, > > Any chance you could explain this one to me: > http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/fails-even-with-41/machineball-1.0-4.fc8.log > > In file included from /usr/include/allegrogl/gl_ext.h:27, > from /usr/include/alleggl.h:68, > from menu.cpp:12: > /usr/include/allegrogl/GLext/gl_ext_api.h:1827: error: '' has > incomplete type > /usr/include/allegrogl/GLext/gl_ext_api.h:1827: error: invalid use of 'GLvoid' > > I just tried to build the rawhide machineball sources on F-8 and there they > work fine. The offending line in /usr/include/allegrogl/GLext/gl_ext_api.h is: > AGL_API(void, EndTransformFeedbackNV, (GLvoid)) > > Which basically translates to: > void EndTransformFeedbackNV(GLvoid); > > And GLvoid is defined in: > /usr/include/GL/gl.h, which gets included by /usr/include/alleggl.h before > including /usr/include/allegrogl/gl_ext.h. > > GLvoid is defined as: > typedef void GLvoid; > > The only reason I can see for this not working is that: > /usr/include/alleggl.h > > Does not declare the prototypes in it and its included files as > extern "C" { > > Could that explain this? I don't think so. openvrml has the same failure; and in this case the code is in an 'extern "C"' block. I've recently had a user report this same problem with gcc 4.2. > Strange though that this breaks between gcc-4.1.2-33, and > gcc-4.1.2-36 I think you misunderstood. This problem occurs in gcc 4.3.0-0.4; not in 4.1.2-36. I'd like to know more about this, too. Currently I'm not convinced it isn't a gcc bug. Can someone with gcc 4.3 installed try compiling a few brief C++ programs with g++? For starters: typedef void void_t; int f(void_t) { return 0; } int main() { f(); } If that works, try this one: extern "C" { typedef void void_t; int f(void_t) { return 0; } } int main() { f(); } And finally: typedef void void_t; extern "C" { int f(void_t) { return 0; } } int main() { f(); } If any of these fails, I'd sure like to know why. If they succeed, I'd sure like to know what's special about GLvoid. -- Braden McDaniel e-mail: Jabber: From rhallyx at mindspring.com Fri Jan 4 07:20:20 2008 From: rhallyx at mindspring.com (Richard Hally) Date: Fri, 04 Jan 2008 02:20:20 -0500 Subject: mkinitrd nash parted update problem Message-ID: <477DDE34.5070301@mindspring.com> What is the solution for the problem below? [root at localhost ~]# yum --exclude=xorg-x11\* --exclude=linuxwacom update Excluding Packages in global exclude list Finished Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package kernel.i686 0:2.6.24-0.133.rc6.git8.fc9 set to be installed --> Processing Dependency: mkinitrd >= 6.0.9-7 for package: kernel --> Running transaction check ---> Package mkinitrd.i386 0:6.0.27-1.fc9 set to be updated --> Processing Dependency: libnash.so.6.0.27 for package: mkinitrd --> Processing Dependency: nash = 6.0.27-1.fc9 for package: mkinitrd --> Processing Dependency: libparted-1.8.so.6 for package: mkinitrd --> Processing Dependency: libbdevid.so.6.0.27 for package: mkinitrd --> Running transaction check ---> Package mkinitrd.i386 0:6.0.27-1.fc9 set to be updated --> Processing Dependency: libparted-1.8.so.6 for package: mkinitrd ---> Package nash.i386 0:6.0.27-1.fc9 set to be updated --> Processing Dependency: libparted-1.8.so.6 for package: nash --> Processing Dependency: parted for package: nash --> Running transaction check ---> Package parted.i386 0:1.8.8-1.fc9 set to be updated ---> Package mkinitrd.i386 0:6.0.27-1.fc9 set to be updated --> Processing Dependency: libparted-1.8.so.6 for package: mkinitrd ---> Package nash.i386 0:6.0.27-1.fc9 set to be updated --> Processing Dependency: libparted-1.8.so.6 for package: nash --> Finished Dependency Resolution Error: Missing Dependency: libparted-1.8.so.6 is needed by package mkinitrd Error: Missing Dependency: libparted-1.8.so.6 is needed by package nash [root at localhost ~]# this is running rawhide. Thanks for any help. Richard From tromey at redhat.com Fri Jan 4 07:09:45 2008 From: tromey at redhat.com (Tom Tromey) Date: Fri, 04 Jan 2008 00:09:45 -0700 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <1199429926.5278.38.camel@hinge.endoframe.net> (Braden McDaniel's message of "Fri\, 04 Jan 2008 01\:58\:46 -0500") References: <20080103120242.GZ20451@devserv.devel.redhat.com> <477CF8E3.6050907@hhs.nl> <1199429926.5278.38.camel@hinge.endoframe.net> Message-ID: >>>>> "Braden" == Braden McDaniel writes: Braden> typedef void void_t; Braden> int f(void_t) { return 0; } Braden> int main() { f(); } I think this is not valid C++ -- you can't use a typedef to void here. See: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_closed.html#18 and also the GCC PR: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9278 Tom From alexl at users.sourceforge.net Fri Jan 4 07:51:01 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Fri, 04 Jan 2008 00:51:01 -0700 Subject: mkinitrd nash parted update problem In-Reply-To: <477DDE34.5070301@mindspring.com> (Richard Hally's message of "Fri\, 04 Jan 2008 02\:20\:20 -0500") References: <477DDE34.5070301@mindspring.com> Message-ID: >>>>> "RH" == Richard Hally writes: RH> What is the solution for the problem below? [root at localhost ~]# RH> yum --exclude=xorg-x11\* --exclude=linuxwacom update Excluding [...] Wait for the next rawhide to generate later today, I believe the dependencies have been fixed there. Alex From giallu at gmail.com Fri Jan 4 08:18:08 2008 From: giallu at gmail.com (Gianluca Sforna) Date: Fri, 4 Jan 2008 09:18:08 +0100 Subject: Python packages in Rawhide (was: Re: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220) In-Reply-To: <1199409547.3463.6.camel@ignacio.lan> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <1199409547.3463.6.camel@ignacio.lan> Message-ID: On Jan 4, 2008 2:19 AM, Ignacio Vazquez-Abrams wrote: > On Thu, 2008-01-03 at 07:02 -0500, Jakub Jelinek wrote: > > fails-even-with-41/python-... > > Note that most of these are caused by egg info now being generated but > not included by the spec file. > Yes, like buildbot which I just fixed :) From tomek at crocom.com.pl Fri Jan 4 08:22:24 2008 From: tomek at crocom.com.pl (Tomasz Torcz) Date: Fri, 04 Jan 2008 09:22:24 +0100 Subject: Another selinux rant In-Reply-To: References: <1199396217.3716.45.camel@localhost.localdomain> Message-ID: <1199434944.3244.7.camel@s1.crocom.com.pl> Dnia 03-01-2008, czw o godzinie 13:49 -0800, Ed Swierk pisze: > On 1/3/08, Eric Paris wrote: > > Could you explain how you 'copied' these configuration files? Is this > > tar/untar ? I'm trying to figure out how the labels for stuff in ~/.ssh > > got messed up for you. tar with "--xattrs"? > Yes, I used tar to copy /home and /etc/openvpn. Openvpn stores state > for active connections in a file specified by the > --ifconfig-pool-persist option. Since the openvpn configuration recipe > I found online uses /etc/openvpn/ipp.txt, that's what I use. > Presumably the SELinux policy wants me to store that file somewhere > else? SELinux don't care about file location. It cares about labels. Policy for *labeling* files and assorted utilities care for paths, but they are only additional utilities, not SELinux itself.. In your situation, ipp.txt must be writable by openvpn daemon. You can achieve it by labeling (man chcon) ipp.txt as openvpn_var_log_t. By default files in /etc/openvpn are labeled as openvpn_etc_t (openvpn's configuration files). Daemons cannot modify their configuration files. -- Tomasz Torcz From mmaslano at redhat.com Fri Jan 4 08:25:27 2008 From: mmaslano at redhat.com (Marcela Maslanova) Date: Fri, 04 Jan 2008 09:25:27 +0100 Subject: New tcl-8.5 and 8Kingdoms In-Reply-To: <477D5E86.2030004@hhs.nl> References: <477D5C7F.6050708@hhs.nl> <477D5C87.2010106@kobold.org> <477D5E86.2030004@hhs.nl> Message-ID: <477DED77.30008@redhat.com> I had also look at it and ask upstream about help. Hans de Goede wrote: > Michael Thomas wrote: >> Hans de Goede wrote: >>> Hi all, >>> >>> I just tried building 8Kingdoms with the new tcl in rawhide, it builds >>> fine, but it does not work. >>> >>> Any of the actions (moving a unit for example) which normally invoke a >>> tcl script underneath now no longer work. >>> >>> I'm quite good in fixing C bugs but this problem lies either in the >>> interfacing with tcl or in the tcl code itself and I'm helpless there. >>> So I hope that someone can try running 8Kingdoms with tcl 8.5, and >>> write >>> a fix. >>> >>> Note I've also send a request upstream asking for help, I'll report >>> back >>> here as soon as I get response. >>> >>> If I don't have it fixed by F-9 then I will have to remove 8Kingdoms >>> from Fedora's repositories (better then shipping a broken version). >> >> Did you have to make any changes to 8Kingdoms to get it to build with >> Tcl 8.5? If so please pass along any patches. I'll try building and >> running it myself to see if I can track down the problem. >> > > Nope, > > No changes, I also did a diff between the buildlogs, no new compiler > warnings or anything like that. > > I did build it with gcc-4.3, as I was working on it not building with > gcc-4.3 too. > > I've just committed my latest 8Kingdoms work to cvs, so you can get it > from there, including a patch for the crash you reported (tested using > tcl 8.4). > > Thanks, > > Hans > From braden at endoframe.com Fri Jan 4 08:26:21 2008 From: braden at endoframe.com (Braden McDaniel) Date: Fri, 04 Jan 2008 03:26:21 -0500 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: References: <20080103120242.GZ20451@devserv.devel.redhat.com> <477CF8E3.6050907@hhs.nl> <1199429926.5278.38.camel@hinge.endoframe.net> Message-ID: <1199435181.5278.40.camel@hinge.endoframe.net> On Fri, 2008-01-04 at 00:09 -0700, Tom Tromey wrote: > >>>>> "Braden" == Braden McDaniel writes: > > Braden> typedef void void_t; > Braden> int f(void_t) { return 0; } > Braden> int main() { f(); } > > I think this is not valid C++ -- you can't use a typedef to void here. > See: > > http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_closed.html#18 > > and also the GCC PR: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9278 I'll be damned. Thanks very much. -- Braden McDaniel e-mail: Jabber: From opensource at till.name Fri Jan 4 08:36:23 2008 From: opensource at till.name (Till Maas) Date: Fri, 04 Jan 2008 09:36:23 +0100 Subject: Fedora 9 Feature Status In-Reply-To: <477DBE5C.9050705@redhat.com> References: <477C915E.4080402@redhat.com> <1199365417.3687.0.camel@aglarond.local> <477DBE5C.9050705@redhat.com> Message-ID: <200801040936.27558.opensource@till.name> On Fr Januar 4 2008, John Poelstra wrote: > Jeremy Katz said the following on 01/03/2008 05:03 AM Pacific Time: > > On Thu, 2008-01-03 at 04:45 -0500, Chuck Anderson wrote: > >> On Wed, Jan 02, 2008 at 11:40:14PM -0800, John Poelstra wrote: > >>> I've updated http://fedoraproject.org/wiki/Features/Dashboard to > >>> reflect the latest proposed features. > >> > >> This appears to be missing from the Dashboard but nice progress is > >> being made in anaconda: > >> > >> http://fedoraproject.org/wiki/Releases/FeatureEncryptedFilesystems > >> > >> I hope this gets targetted for Fedora 9 and voted on by FESco. > > > > I think that it was already voted on and approved... but I'm sending > > this while I don't have an active net connection so can't go and check > > > > Jeremy > > Nope. It hasn't been updated since August 2007 doesn't follow the > current feature template. The last update was 2007-11-12 according to http://fedoraproject.org/wiki/Releases/FeatureEncryptedFilesystems?action=info Only the date written on the page itself was not updated. Afaik this feature is already available in rawhide btw. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From ljuwaida at fedoraproject.org Fri Jan 4 08:40:16 2008 From: ljuwaida at fedoraproject.org (Laith Juwaidah) Date: Fri, 4 Jan 2008 12:40:16 +0400 Subject: Control center idea In-Reply-To: <1199398175.9971.0.camel@frosty> References: <1199374110.5023.2.camel@frosty> <477D001B.8090203@fedoraproject.org> <1199392493.7512.8.camel@frosty> <477D4784.30000@fedoraproject.org> <1199398175.9971.0.camel@frosty> Message-ID: I suggested this many times before (probably two times :P), but no one seamed excited about it, so I abandoned the idea, but now that people are interested I might work on it... It'll be a good way to learn python :) Just one question, anaconda has screens that look like some other configuration tools (pirut, selinux configuration, root password, etc), does it kinda call those apps or are they included in it? Thanks :) On Jan 4, 2008 2:09 AM, Jakub 'Livio' Rusinek wrote: > I'm not developer. I'm only end-user, who became an packager. > > Dnia 04-01-2008, pi? o godzinie 02:07 +0530, Rahul Sundaram pisze: > > Jakub 'Livio' Rusinek wrote: > > > Dnia 03-01-2008, czw o godzinie 21:02 +0530, Rahul Sundaram pisze: > > >> If you are interested in maintaining Yast, a port of it for RHEL is > > >> available at which should work on Fedora too with possibly minor > changes. > > >> > > >> http://oss.oracle.com/projects/yast/ > > >> > > >> Rahul > > >> > > > > > > No GTK support. > > > mv YaST > /dev/null :( > > > > It is not the latest version. Both the suggestions are something for you > > to potentially start with. You don't get anything yet that would just > > fit in right away. > > > > Rahul > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Laith Juwaidah http://www.ljuwaidah.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexl at users.sourceforge.net Fri Jan 4 08:52:16 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Fri, 04 Jan 2008 01:52:16 -0700 Subject: xulrunner feature (was Re: Fedora 9 Feature Status) In-Reply-To: <200801040936.27558.opensource@till.name> (Till Maas's message of "Fri\, 04 Jan 2008 09\:36\:23 +0100") References: <477C915E.4080402@redhat.com> <1199365417.3687.0.camel@aglarond.local> <477DBE5C.9050705@redhat.com> <200801040936.27558.opensource@till.name> Message-ID: <14zlvmht1b.fsf_-_@allele2.eebweb.arizona.edu> >>>>> "TM" == Till Maas writes: [...] >> Nope. It hasn't been updated since August 2007 doesn't follow the >> current feature template. TM> The last update was 2007-11-12 according to TM> http://fedoraproject.org/wiki/Releases/FeatureEncryptedFilesystems?action=info TM> Only the date written on the page itself was not updated. Afaik TM> this feature is already available in rawhide btw. It's similar with xulrunner (updated 2007-12-31): http://fedoraproject.org/wiki/Releases/FeatureXULRunner It appears to have been removed as a Fedora 9 feature, but the feature is already in rawhide. One missing item that doesn't conform to the template is that there doesn't appear to be a contingency plan, but it would be very difficult to back out the feature now as many packages have been rebuilt against xulrunner already and the old firefox-devel package has been removed. This feature should probably be reinstated. Alex From j.w.r.degoede at hhs.nl Fri Jan 4 09:07:02 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 04 Jan 2008 10:07:02 +0100 Subject: New tcl-8.5 and 8Kingdoms In-Reply-To: <477DED77.30008@redhat.com> References: <477D5C7F.6050708@hhs.nl> <477D5C87.2010106@kobold.org> <477D5E86.2030004@hhs.nl> <477DED77.30008@redhat.com> Message-ID: <477DF736.3020205@hhs.nl> Marcela Maslanova wrote: > I had also look at it and ask upstream about help. > Thanks, I assume you mean tcl upstream? I'm already in contact about this with 8Kingdoms. I've had a reply from them that the 8Kingdoms project is sort of sleeping (boh authors graduated from university and are working now, we all know whats that like), but they would try to take a look at the tcl 8.5 issue. Regards, Hans > Hans de Goede wrote: >> Michael Thomas wrote: >>> Hans de Goede wrote: >>>> Hi all, >>>> >>>> I just tried building 8Kingdoms with the new tcl in rawhide, it builds >>>> fine, but it does not work. >>>> >>>> Any of the actions (moving a unit for example) which normally invoke a >>>> tcl script underneath now no longer work. >>>> >>>> I'm quite good in fixing C bugs but this problem lies either in the >>>> interfacing with tcl or in the tcl code itself and I'm helpless there. >>>> So I hope that someone can try running 8Kingdoms with tcl 8.5, and >>>> write >>>> a fix. >>>> >>>> Note I've also send a request upstream asking for help, I'll report >>>> back >>>> here as soon as I get response. >>>> >>>> If I don't have it fixed by F-9 then I will have to remove 8Kingdoms >>>> from Fedora's repositories (better then shipping a broken version). >>> >>> Did you have to make any changes to 8Kingdoms to get it to build with >>> Tcl 8.5? If so please pass along any patches. I'll try building and >>> running it myself to see if I can track down the problem. >>> >> >> Nope, >> >> No changes, I also did a diff between the buildlogs, no new compiler >> warnings or anything like that. >> >> I did build it with gcc-4.3, as I was working on it not building with >> gcc-4.3 too. >> >> I've just committed my latest 8Kingdoms work to cvs, so you can get it >> from there, including a patch for the crash you reported (tested using >> tcl 8.4). >> >> Thanks, >> >> Hans >> > From pertusus at free.fr Fri Jan 4 09:39:49 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 4 Jan 2008 10:39:49 +0100 Subject: Another selinux rant In-Reply-To: <477D9178.6090709@gmail.com> References: <477D9178.6090709@gmail.com> Message-ID: <20080104093949.GC2572@free.fr> On Thu, Jan 03, 2008 at 05:52:56PM -0800, Andrew Farris wrote: > > must now but if you just ignore it long term its to your detriment. Set it Not necessarily. file permissions are only useful if you want privilege separation. Likewise selinux is only useful if you want fine grained file access rights. So far, I don't need the corresponding complexity, though I know tht it is at the expense of some security. -- Pat From bbbush.yuan at gmail.com Fri Jan 4 09:42:43 2008 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Fri, 4 Jan 2008 17:42:43 +0800 Subject: Wiki Migration In-Reply-To: <4762E5F5.4010206@redhat.com> References: <4762E5F5.4010206@redhat.com> Message-ID: <76e72f800801040142n2bb6950r303d45bd47c179b1@mail.gmail.com> Interesting website. When will our wiki upgrade to moinmoin 1.6? I like new link syntax, and "attachment:" can refer to attachments of other pages without any problem. http://www.wikimatrix.org/compare/DokuWiki+MediaWiki+Moinmoin From j.w.r.degoede at hhs.nl Fri Jan 4 10:13:46 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 04 Jan 2008 11:13:46 +0100 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <1199429926.5278.38.camel@hinge.endoframe.net> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <477CF8E3.6050907@hhs.nl> <1199429926.5278.38.camel@hinge.endoframe.net> Message-ID: <477E06DA.3070302@hhs.nl> Braden McDaniel wrote: > I think you misunderstood. This problem occurs in gcc 4.3.0-0.4; not in > 4.1.2-36. > Well, my failed build was in Jakub's also fails with 4.1 list, notice that Jakub used 4.1.2-36 from rawhide not 4.1.2-33 from F-8 and -36 contains some additional c++ strictness. > I'd like to know more about this, too. Currently I'm not convinced it > isn't a gcc bug. > > Can someone with gcc 4.3 installed try compiling a few brief C++ > programs with g++? > > For starters: > > typedef void void_t; > int f(void_t) { return 0; } > int main() { f(); } > > If that works, try this one: Doesn't work, as to be expected judging from Tom Troney's post: test1.c++:2: error: ?? has incomplete type test1.c++:2: error: invalid use of ?void_t? test1.c++: In function ?int main()?: test1.c++:2: error: too few arguments to function ?int f()? test1.c++:3: error: at this point in file > > extern "C" { > typedef void void_t; > int f(void_t) { return 0; } > } > int main() { f(); } > The same: test2.c++:3: error: ?? has incomplete type test2.c++:3: error: invalid use of ?void_t? test2.c++: In function ?int main()?: test2.c++:3: error: too few arguments to function ?int f()? test2.c++:5: error: at this point in file This is bad, as it breaks compatibility with including .c header files, really bad! Tom? Jakub? Regards, Hans From drago01 at gmail.com Fri Jan 4 11:14:13 2008 From: drago01 at gmail.com (drago01) Date: Fri, 04 Jan 2008 12:14:13 +0100 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080103145025.GG20451@devserv.devel.redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <477CD6B0.7090203@gmail.com> <20080103130138.GB20451@devserv.devel.redhat.com> <477CE8C8.4030907@gmail.com> <20080103145025.GG20451@devserv.devel.redhat.com> Message-ID: <477E1505.4030804@gmail.com> Jakub Jelinek wrote: > On Thu, Jan 03, 2008 at 02:53:12PM +0100, drago01 wrote: > >> OK, thx. I have prepared a fix that I want to verify before sending it >> upstream but the build fails in a weird way: >> > > >> http://koji.fedoraproject.org/koji/getfile?taskID=321712&name=build.log >> It seems to stop before it even starts ... >> > > There is also root.log, which says: > DEBUG util.py:260: Error: Missing Dependency: libgcj.so.8rh is needed by package gettext-devel > > The rebuilds I did were also with rebuilt gettext in the buildroots, but > I'm not sure what's a feasible solution for dist-f9-gcc43. Perhaps > the best would be to compile/link the Java programs with > -findirect-dispatch, then they will be independent from libgcj.so.* version > of the day and rely on libgcj_bc.so which isn't changing. > > yes we need a solution for this to be able to test all packages. I might be crazy but wouldn't it be better to throw gcc-4.3 into dist-f9 aka rawhide? This way fixing a package that has deps like sigc++ would be easy to verify. Buildroot issues like the above should not happen. But this way we end up with a broken rawhide for a while. From jakub at redhat.com Fri Jan 4 11:32:28 2008 From: jakub at redhat.com (Jakub Jelinek) Date: Fri, 4 Jan 2008 06:32:28 -0500 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <477E06DA.3070302@hhs.nl> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <477CF8E3.6050907@hhs.nl> <1199429926.5278.38.camel@hinge.endoframe.net> <477E06DA.3070302@hhs.nl> Message-ID: <20080104113228.GL20451@devserv.devel.redhat.com> On Fri, Jan 04, 2008 at 11:13:46AM +0100, Hans de Goede wrote: > This is bad, as it breaks compatibility with including .c header files, > really bad! Tom? Jakub? C and C++ are different languages, there are many things valid in C and invalid in C++ and vice versa. extern "C" is just a linkage thing, doesn't magically change the source language temporarily to C. So, if you want to include some header in C++, that header needs to be includable in C++, i.e. must use the common subset of C and C++. That includes stuff like not using C++ keywords (new, delete, ...), adding casts where C++ doesn't allow implicit casting but C does, and among yet other things for functions without arguments using type fn (); or type fn (void), but not typedef void something; ... type fn (something); in prototypes or fn definitions. Jakub From triad at df.lth.se Fri Jan 4 11:32:27 2008 From: triad at df.lth.se (Linus Walleij) Date: Fri, 4 Jan 2008 12:32:27 +0100 (CET) Subject: Disabling selinux question In-Reply-To: <1199399640.3716.65.camel@localhost.localdomain> References: <1199399640.3716.65.camel@localhost.localdomain> Message-ID: Eric and others, please be patient with me now, because I'm trying to understand our implicit rationale surrounding the selinux services here, I'm not ranting. I might very well be uneducated and stupid, but sometimes (as has been said before) it is useful to take the perspective of a newcomer to a certain system (or in my case subsystem) and try to understand why this user has problems with it. Now I have this problems with the services required by SELinux, a setting which may have been default-disabled during install. On Thu, 3 Jan 2008, Eric Paris wrote: > selinux uses auditd but they are not at all closely coupled. selinux > will function fine without auditd and auditd provides all of its > capabilities without selinux. There is no reason these 2 should be > coupled together. I get it. (Did some homework reading up on auditd here.) So every Fedora user must have these (right?): root 2219 0.0 0.0 12288 684 ? S> mcstrans >> restorecond >> setroubleshoot >> >> If I use system-config-selinux or anaconda to disable SELinux altogether, >> then none of these are disabled accordingly. The only case seems to be >> that auditd is turn on if I disable them all manually and then enable >> SELinux. > > I don't think as a general rule that we couple services ever (maybe we > do and i just don't know it) As I stated, since selinux requires auditd to be started, we already couple "auditd ON" to "selinux ON". > but I don't think disabling your mta is > going to disable webmail. ? no ? why should it? There is no golden rule here, but there are (IMHO) some cases where we could help out managing services so that the defaults in system-config-services is more understandable. > I however don't think it would be > unreasonable to file an anaconda bug and say that if selinux is disabled > the above 3 programs shouldn't be set to automatically start. If that > goes anywhere you could file against system-config-selinux (or vice > versa) Okay! https://bugzilla.redhat.com/show_bug.cgi?id=427506 (pending discussion as of whether auditd could actually be disabled too) As I understand it, disabling auditd on some configs may be more important though, because it actually sits there eating memory (well not much, admittedly), it does not exit if it's not used by the system. Linus From triad at df.lth.se Fri Jan 4 11:36:05 2008 From: triad at df.lth.se (Linus Walleij) Date: Fri, 4 Jan 2008 12:36:05 +0100 (CET) Subject: Disabling selinux question In-Reply-To: <477D651D.2070208@redhat.com> References: <477D651D.2070208@redhat.com> Message-ID: On Thu, 3 Jan 2008, John Dennis wrote: > auditd is the general auditing facility, SELinux messages are just one of the > possible auditing messages. But on a Fedora default install SELinux is the only thing using and requiring it, right? > setroubleshootd is a diagnostic tool. If SELinux is completely disabled the > daemon exits if started. OK, should it have "# hide: true" in /etc/init.d/setroubleshootd so it doesn't even turn up in system-config-services? > Allowing > the daemon to decide if it should run or exit is more robust than some > utility which thinks it knows if something should be chkconfig'ed on or not > because it will almost certainly get that answer wrong. Then all these smart daemons should have "# hide : true" in their respective /etc/init.d/foo script so avoid being managed by the smart utility system-config-services, am I right? Linus From olly at survex.com Fri Jan 4 11:50:26 2008 From: olly at survex.com (Olly Betts) Date: Fri, 4 Jan 2008 11:50:26 +0000 (UTC) Subject: xapian-core (was Re: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220) References: <20080103120242.GZ20451@devserv.devel.redhat.com> Message-ID: Jakub Jelinek writes: > header-dep/xapian-core-1.0.4-1.fc9.log The latest upstream release (1.0.5) fixes building with recent GCC 4.3 snapshots. Both Debian and SuSE have also been performing similar rebuilds of all their packages, so you'll probably find fixes have made it upstream for a number of other packages. Cheers, Olly From drago01 at gmail.com Fri Jan 4 11:55:06 2008 From: drago01 at gmail.com (drago01) Date: Fri, 04 Jan 2008 12:55:06 +0100 Subject: xapian-core (was Re: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220) In-Reply-To: References: <20080103120242.GZ20451@devserv.devel.redhat.com> Message-ID: <477E1E9A.3000708@gmail.com> Olly Betts wrote: > Jakub Jelinek writes: > >> header-dep/xapian-core-1.0.4-1.fc9.log >> > > The latest upstream release (1.0.5) fixes building with recent GCC 4.3 snapshots. > > Thx for mentioning this. 1.0.5 is already in rawhide as of 20071227 one package less to work on ;) From ndbecker2 at gmail.com Fri Jan 4 12:11:55 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 04 Jan 2008 07:11:55 -0500 Subject: tetex-fonts replacement? Message-ID: I received this message today: dblatex has broken dependencies in the development tree: On ppc: dblatex - 0.2.8-2.fc9.1.noarch requires tetex-fonts On x86_64: dblatex - 0.2.8-2.fc9.1.noarch requires tetex-fonts On i386: dblatex - 0.2.8-2.fc9.1.noarch requires tetex-fonts On ppc64: dblatex - 0.2.8-2.fc9.1.noarch requires tetex-fonts Please resolve this as soon as possible. From pertusus at free.fr Fri Jan 4 12:18:41 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 4 Jan 2008 13:18:41 +0100 Subject: tetex-fonts replacement? In-Reply-To: References: Message-ID: <20080104121841.GA10915@free.fr> On Fri, Jan 04, 2008 at 07:11:55AM -0500, Neal Becker wrote: > I received this message today: > > dblatex has broken dependencies in the development tree: > On ppc: > dblatex - 0.2.8-2.fc9.1.noarch requires tetex-fonts > On x86_64: > dblatex - 0.2.8-2.fc9.1.noarch requires tetex-fonts > On i386: > dblatex - 0.2.8-2.fc9.1.noarch requires tetex-fonts > On ppc64: > dblatex - 0.2.8-2.fc9.1.noarch requires tetex-fonts > Please resolve this as soon as possible. I just filled a bug https://bugzilla.redhat.com/show_bug.cgi?id=427521 Hopefully will be fixed soon. -- Pat From limb at jcomserv.net Fri Jan 4 12:14:25 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 4 Jan 2008 06:14:25 -0600 (CST) Subject: Python packages in Rawhide (was: Re: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220) In-Reply-To: References: <20080103120242.GZ20451@devserv.devel.redhat.com> <1199409547.3463.6.camel@ignacio.lan> Message-ID: <17283.63.85.68.164.1199448865.squirrel@mail.jcomserv.net> > On Jan 4, 2008 2:19 AM, Ignacio Vazquez-Abrams > wrote: >> On Thu, 2008-01-03 at 07:02 -0500, Jakub Jelinek wrote: >> > fails-even-with-41/python-... >> >> Note that most of these are caused by egg info now being generated but >> not included by the spec file. >> > > Yes, like buildbot which I just fixed :) And pcapy, which I just fixed. Jakub, would it be possible to have this repeated sometime between now and F9 Gold, so we can see how we're doing at getting these fixed? It'll take some time, it's a lot of packages, but it'd be nice to see what's still out there, so those of us with only a few to few can know where to start helping those with lots to fix. Thanks for the fantastic work. > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From drago01 at gmail.com Fri Jan 4 12:23:09 2008 From: drago01 at gmail.com (drago01) Date: Fri, 04 Jan 2008 13:23:09 +0100 Subject: tetex-fonts replacement? In-Reply-To: References: Message-ID: <477E252D.5050407@gmail.com> Neal Becker wrote: > I received this message today: > > dblatex has broken dependencies in the development tree: > On ppc: > dblatex - 0.2.8-2.fc9.1.noarch requires tetex-fonts > On x86_64: > dblatex - 0.2.8-2.fc9.1.noarch requires tetex-fonts > On i386: > dblatex - 0.2.8-2.fc9.1.noarch requires tetex-fonts > On ppc64: > dblatex - 0.2.8-2.fc9.1.noarch requires tetex-fonts > Please resolve this as soon as possible. > > > you will have to require texlive instead on rawhide. From poelstra at redhat.com Fri Jan 4 12:39:44 2008 From: poelstra at redhat.com (John Poelstra) Date: Fri, 04 Jan 2008 04:39:44 -0800 Subject: xulrunner feature (was Re: Fedora 9 Feature Status) In-Reply-To: <14zlvmht1b.fsf_-_@allele2.eebweb.arizona.edu> References: <477C915E.4080402@redhat.com> <1199365417.3687.0.camel@aglarond.local> <477DBE5C.9050705@redhat.com> <200801040936.27558.opensource@till.name> <14zlvmht1b.fsf_-_@allele2.eebweb.arizona.edu> Message-ID: <477E2910.9050203@redhat.com> Alex Lancaster said the following on 01/04/2008 12:52 AM Pacific Time: >>>>>> "TM" == Till Maas writes: > > [...] > >>> Nope. It hasn't been updated since August 2007 doesn't follow the >>> current feature template. > > TM> The last update was 2007-11-12 according to > TM> http://fedoraproject.org/wiki/Releases/FeatureEncryptedFilesystems?action=info > > TM> Only the date written on the page itself was not updated. Afaik > TM> this feature is already available in rawhide btw. > > It's similar with xulrunner (updated 2007-12-31): Different issues. > http://fedoraproject.org/wiki/Releases/FeatureXULRunner > > It appears to have been removed as a Fedora 9 feature, but the feature This is not true. It was never part of http://fedoraproject.org/wiki/Releases/9/FeatureList > is already in rawhide. One missing item that doesn't conform to the > template is that there doesn't appear to be a contingency plan, but it You are correct. FESCo often asks what the contingency plan is when reviewing features for acceptance. This particular feature was in CategoryProposedFedora9--meaning that it was being put forth for a FESCo vote. I sent mail to the feature owner directly and posted status here a couple weeks ago. Receiving no respose I moved it to CategoryProposedFeature. > would be very difficult to back out the feature now as many packages > have been rebuilt against xulrunner already and the old firefox-devel > package has been removed. > Nobody is calling for this :) John From poelstra at redhat.com Fri Jan 4 12:44:24 2008 From: poelstra at redhat.com (John Poelstra) Date: Fri, 04 Jan 2008 04:44:24 -0800 Subject: Fedora 9 Feature Status In-Reply-To: <200801040936.27558.opensource@till.name> References: <477C915E.4080402@redhat.com> <1199365417.3687.0.camel@aglarond.local> <477DBE5C.9050705@redhat.com> <200801040936.27558.opensource@till.name> Message-ID: <477E2A28.6040701@redhat.com> Till Maas said the following on 01/04/2008 12:36 AM Pacific Time: > The last update was 2007-11-12 according to > http://fedoraproject.org/wiki/Releases/FeatureEncryptedFilesystems?action=info > > Only the date written on the page itself was not updated. Afaik this feature > is already available in rawhide btw. > Yes, there is a difference between a feature actually being packaged and in rawhide versus being advertised as a new feature in the next release of Fedora. The process to have a feature included as part of http://fedoraproject.org/wiki/Releases/9/FeatureList calls for a completed feature page following this template http://fedoraproject.org/wiki/Features/Template to be presented to FESCo for acceptance. In most cases this is just a formality to make sure everyone is in sync. More about how the process is intended to work and the philosophy behind it is here: http://fedoraproject.org/wiki/Features/Policy I hope that helps. John From jnovy at redhat.com Fri Jan 4 12:47:18 2008 From: jnovy at redhat.com (Jindrich Novy) Date: Fri, 4 Jan 2008 13:47:18 +0100 Subject: tetex-fonts replacement? In-Reply-To: References: Message-ID: <20080104124718.GA5991@localhost.localdomain> On Fri, Jan 04, 2008 at 07:11:55AM -0500, Neal Becker wrote: > I received this message today: > > dblatex has broken dependencies in the development tree: > On ppc: > dblatex - 0.2.8-2.fc9.1.noarch requires tetex-fonts > On x86_64: > dblatex - 0.2.8-2.fc9.1.noarch requires tetex-fonts > On i386: > dblatex - 0.2.8-2.fc9.1.noarch requires tetex-fonts > On ppc64: > dblatex - 0.2.8-2.fc9.1.noarch requires tetex-fonts > Please resolve this as soon as possible. > This is caused by texlive and texlive-fonts package merge. The texlive package contains: Obsoletes: texlive-fonts < 2007-6 Provides: texlive-fonts = 2007-6 What should have fixed the missing texlive-fonts by providing it by the main texlive package. It doesn't work for some reason so will need to have a look at it. Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From jnovy at redhat.com Fri Jan 4 12:50:48 2008 From: jnovy at redhat.com (Jindrich Novy) Date: Fri, 4 Jan 2008 13:50:48 +0100 Subject: tetex-fonts replacement? In-Reply-To: <20080104124718.GA5991@localhost.localdomain> References: <20080104124718.GA5991@localhost.localdomain> Message-ID: <20080104125048.GB5991@localhost.localdomain> On Fri, Jan 04, 2008 at 01:47:18PM +0100, Jindrich Novy wrote: > On Fri, Jan 04, 2008 at 07:11:55AM -0500, Neal Becker wrote: > > I received this message today: > > > > dblatex has broken dependencies in the development tree: > > On ppc: > > dblatex - 0.2.8-2.fc9.1.noarch requires tetex-fonts > > On x86_64: > > dblatex - 0.2.8-2.fc9.1.noarch requires tetex-fonts > > On i386: > > dblatex - 0.2.8-2.fc9.1.noarch requires tetex-fonts > > On ppc64: > > dblatex - 0.2.8-2.fc9.1.noarch requires tetex-fonts > > Please resolve this as soon as possible. > > > > This is caused by texlive and texlive-fonts package merge. The texlive > package contains: > > Obsoletes: texlive-fonts < 2007-6 > Provides: texlive-fonts = 2007-6 > > What should have fixed the missing texlive-fonts by providing it by > the main texlive package. It doesn't work for some reason so will need > to have a look at it. > Ok, in case of *tetex-fonts*, to add the virtual provide for it is a trivial fix. I'll build it today. The texlive-fonts virtual provides work good as expected of course. Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From j.w.r.degoede at hhs.nl Fri Jan 4 12:56:17 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 04 Jan 2008 13:56:17 +0100 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080104113228.GL20451@devserv.devel.redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <477CF8E3.6050907@hhs.nl> <1199429926.5278.38.camel@hinge.endoframe.net> <477E06DA.3070302@hhs.nl> <20080104113228.GL20451@devserv.devel.redhat.com> Message-ID: <477E2CF1.9040109@hhs.nl> Jakub Jelinek wrote: > On Fri, Jan 04, 2008 at 11:13:46AM +0100, Hans de Goede wrote: >> This is bad, as it breaks compatibility with including .c header files, >> really bad! Tom? Jakub? > > C and C++ are different languages, there are many things valid in C and > invalid in C++ and vice versa. extern "C" is just a linkage thing, doesn't > magically change the source language temporarily to C. > > So, if you want to include some header in C++, that header needs to be > includable in C++, i.e. must use the common subset of C and C++. > That includes stuff like not using C++ keywords (new, delete, ...), > adding casts where C++ doesn't allow implicit casting but C does, > and among yet other things for functions without arguments using type fn (); > or type fn (void), but not typedef void something; ... type fn (something); > in prototypes or fn definitions. > Well, I for one consider this a bug of C++, but I guess arguing about this is useless, so I'll just go and patch alleggl to fix this. Regards, Hans From caolanm at redhat.com Fri Jan 4 13:02:48 2008 From: caolanm at redhat.com (Caolan McNamara) Date: Fri, 04 Jan 2008 13:02:48 +0000 Subject: howto package openoffice.org extensions Message-ID: <1199451768.7355.201.camel@Jehannum> I've added a little bit to http://fedoraproject.org/wiki/OpenOffice.org to document the best recipe for installing and deinstalling openoffice.org extensions to avoid some gotchas. The example taken is that of writer2latex and also shows the (submitted upstream) enhancement to register an extension by linking to an the unzipped package to avoid the vanilla behaviour of copying the package during installation. C. From drago01 at gmail.com Fri Jan 4 13:02:34 2008 From: drago01 at gmail.com (drago01) Date: Fri, 04 Jan 2008 14:02:34 +0100 Subject: gwget (Re: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220) In-Reply-To: <477CF664.5070207@hhs.nl> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <1199368807.3673.4.camel@wicktop.localdomain> <20080103140422.GF20451@devserv.devel.redhat.com> <1199369958.3673.7.camel@wicktop.localdomain> <477CF664.5070207@hhs.nl> Message-ID: <477E2E6A.60405@gmail.com> Hans de Goede wrote: > [..] > I started with 45 and I'm down to 43 now, anyone care to help? yes but you have to tell me which packages are still left to avoid duplicated work. ;) From buildsys at redhat.com Fri Jan 4 13:10:17 2008 From: buildsys at redhat.com (Build System) Date: Fri, 4 Jan 2008 08:10:17 -0500 Subject: rawhide report: 20080104 changes Message-ID: <200801041310.m04DAHG8013095@porkchop.devel.redhat.com> New package msynctool Calendar (and other PIM data) synchronization program New package python-twyt An interface to Twitter API functions for Python New package textflow TextFlow is a text editor directed toward programmers Updated Packages: 8Kingdoms-1.1.0-3.fc9 --------------------- * Thu Jan 03 2008 Hans de Goede 1.1.0-3 - Rebuild for new tcl, note: it builds but does not work with the new TCL! help fixing this asked upstream. Any help much appreciated! - Fix compiling with gcc 4.3 - Fix crash undercertain conditions (bz 425799) PythonCAD-0.1.36-3.fc9 ---------------------- * Fri Jan 04 2008 kwizart < kwizart at gmail.com > - 0.1.36-3 - Fix for egg-info R-2.6.1-2.fc9 ------------- * Tue Dec 11 2007 Tom "spot" Callaway 2.6.1-2 - based on changes from Martyn Plummer - use configure options rdocdir, rincludedir, rsharedir - use DESTDIR at installation - remove obsolete generation of packages.html - move header files and INSTALL R-devel package * Mon Nov 26 2007 Tom "spot" Callaway 2.6.1-1 - bump to 2.6.1 * Tue Oct 30 2007 Tom "spot" Callaway 2.6.0-3.1 - fix missing perl requires WindowMaker-0.92.0-16.fc9 ------------------------- * Thu Jan 03 2008 Andreas Bierfert - 0.92.0-16 - fix #427430 acpitool-0.4.7-3.fc9 -------------------- * Thu Jan 03 2008 Patrice Dumas 0.4.7-3 - fixes for gcc 4.3 agistudio-1.2.3-5.fc9 --------------------- * Thu Jan 03 2008 Jon Ciesla - 1.2.3-5 - Fixed cstdlib, string.h includes. amqp-0:1.0-3.fc9 ---------------- * Mon Nov 26 2007 Nuno Santos - 1.0-2 - Bump release for brew update amsn-0.97-2.fc9 --------------- * Thu Jan 03 2008 Sander Hoentjen - 0.97-2 - update to build against tcl/tk 8.5 anaconda-11.4.0.15-1 -------------------- * Thu Jan 03 2008 David Cantrell - 11.4.0.15-1 - Require latest libdhcp (#378641) (dcantrell) * Thu Jan 03 2008 David Cantrell - 11.4.0.14-1 - Precreate /etc/modprobe.d in installroot (jkeating) - 'import sets' in image.py (jkeating) - Fix traceback when displaying required media (clumens) archmage-0.1.9-2.fc9 -------------------- * Thu Jan 03 2008 Patrice Dumas 0.1.9-2 - ship egg asymptote-1.37-1.fc9 -------------------- * Thu Jan 03 2008 Tom "spot" Callaway - 1.37-1 - bump to 1.37 - fix gcc43 failures - drop triggers buildbot-0.7.6-2.fc9 -------------------- * Thu Jan 03 2008 Gianluca Sforna - 0.7.6-2 - pick up new .egg file climm-0.6.1-1.fc9.1 ------------------- * Thu Jan 03 2008 Jan ONDREJ (SAL) - 0.6.1-1 - Rebuild for F9 cproto-4.7f-1.fc9 ----------------- * Thu Jan 03 2008 Jindrich Novy 4.7f-1 - update to 4.7f - drop patch0, fixed upstream * Fri Oct 19 2007 Jindrich Novy 4.7e-5 - fix segfault while parsing #include directive (#315061) cwrite-0.1.24-1.fc9 ------------------- denyhosts-2.6-8.fc9 ------------------- * Thu Jan 03 2008 Jason L Tibbitts III - 2.6-8 - Include everything under to pick up any egg-info files that might be generated. - Silence file-not-utf8 rpmlint complaint. - Silence missing-mandatory-lsb-keyword rpmlint complaint. dirmngr-1.0.1-1.fc9 ------------------- * Thu Jan 03 2008 Rex Dieter 1.0.1-1 - dirmngr-1.0.1 environment-modules-3.2.6-2.fc9 ------------------------------- * Thu Jan 03 2008 - Alex Lancaster - 3.2.6-2 - Rebuild for new Tcl (8.5). exim-4.69-1.fc9 --------------- * Thu Jan 03 2008 David Woodhouse 4.69-1 - Update to 4.69 - Provide server(smtp) (#380611) exim-doc-4.69-1.fc9 ------------------- * Thu Jan 03 2008 David Woodhouse 4.69-1 - Update to 4.69 fbdesk-1.4.1-1.fc9 ------------------ * Thu Jan 03 2008 Andreas Bierfert 1.4.1-1 - version upgrade - fix rpath filelight-1.0-11.fc9 -------------------- * Thu Jan 03 2008 Neal Becker - 1.0-11 - Make that br kdelibs3-devel * Thu Jan 03 2008 Neal Becker - 1.0-9 - BR qt-devel for /etc/profile.d/qt.sh flex-2.5.33-12.fc9 ------------------ * Thu Jan 03 2008 Petr Machata - 2.5.33-12 - Run autogen.sh before the rest of the build. - Add BR autoconf automake gettext-devel. fluxbox-1.0.0-2.fc9 ------------------- * Thu Jan 03 2008 Andreas Bierfert 1.0.0-2 - add subpage -pulseaudio to fix #388971: fluxbox fails to start pulseaudio at login funtools-1.4.0-5.fc9 -------------------- * Thu Jan 03 2008 Sergio Pascual 1.4.0-5 - Rebuilt for tcl 8.5 gdal-1.4.2-7.fc9 ---------------- * Thu Jan 03 2008 Alex Lancaster - 1.4.2-7 - Re-enable grass support now that gdal has been bootstrapped * Wed Jan 02 2008 Mamoru Tasaka - 1.4.2-6 - Bootstrap 1st: disabling grass support - Workaround for hdf not supporting netcdf (bug 189337 c8) - Disabling documents creation for now. * Thu Dec 06 2007 Release Engineering - 1.4.2-5 - Rebuild for deps - Disable grass to avoid circular deps ginac-1.4.1-1.fc9 ----------------- * Thu Jan 03 2008 Quentin Spencer 1.4.1-1 - Update to 1.4.1. gle-4.1.1-0.1.S010308.fc9 ------------------------- * Thu Jan 03 2008 Terje Rosten - 4.1.1-0.1.S010308 - Update to 4.1.1-S010308 (4.1.0 + some gcc 4.3 and 64 bits fixes) - Random spec clean ups - Add man page, lib and pc file. - Create libs and devel subpackage - Add rpath flag to configure glibc-2.7.90-3 -------------- * Thu Jan 03 2008 Jakub Jelinek 2.7.90-3 - update to trunk - fix recognition of interface family (#425768) - add __THROW to __ctype_{b,tolower,toupper}_loc prototypes glpi-0.70-4.fc9 --------------- * Thu Jan 03 2008 Remi Collet - 0.70-4 - Changeset 6226 + 6228 - disable SELinux in EL-5 gnu-smalltalk-2.3.6-8.fc9 ------------------------- * Thu Jan 03 2008 Alex Lancaster 2.3.6-8 - Rebuild for Tcl 8.5 grass-6.2.2-3.fc9 ----------------- * Thu Dec 06 2007 Release Engineering - 6.2.2-3 - Rebuild for deps hamlib-1.2.6.2-6.fc9 -------------------- * Thu Jan 03 2008 - 1.2.6.2-6 - Rebuild against new Tcl 8.5 hfsutils-3.2.6-12.fc9 --------------------- * Thu Jan 03 2008 David Woodhouse 3.2.6-12 - Rebuild for tcl 8.5 * Wed Aug 22 2007 David Woodhouse 3.2.6-11 - Update licence * Wed Aug 22 2007 David Woodhouse 3.2.6-10 - Rebuild hping3-0.0.20051105-8.fc9 ------------------------- * Thu Jan 03 2008 Alex Lancaster - 0.0.20051105-8 - Rebuild against new Tcl 8.5 hunspell-1.2.1-4.fc9 -------------------- * Thu Jan 03 2008 Caolan McNamara - 1.2.1-4 - add hunspell-1.2.1-1863239.badstructs.patch hydrogen-0.9.3-11.fc9 --------------------- * Thu Jan 03 2008 Lubomir Kundrak 0.9.3-11 - Previous change was not a good idea - Adding missing includes to fix build with gcc-4.3 * Sun Oct 14 2007 Lubomir Kundrak 0.9.3-10 - Remove unneeded dependencies on desktop-file-utils java-1.7.0-icedtea-1.7.0.0-0.23.b24.snapshot.fc9 ------------------------------------------------ * Thu Jan 03 2008 Lillian Angel - 1.7.0.0-0.23.b24.snapshot - Added mercurial as a Build Requirement. - Fixed archbuild/archinstall if-block. * Thu Jan 03 2008 Lillian Angel - 1.7.0.0-0.23.b24.snapshot - Removed BuildRequirement firefox-devel - Added BuildRequirement gecko-devel - Resolves rhbz#427350 * Fri Dec 28 2007 Lillian Angel - 1.7.0.0-0.23.b24.snapshot - Updated icedtea source. - Resolves rhbz#426142 kde-i18n-1:3.5.8-3.fc9 ---------------------- * Mon Dec 10 2007 Rex Dieter 1:3.5.8-3 - License: GFDL - Provides: %name- - cosmetics (%buildroot, %defattr, extraneous %doc) - s/for KDE/for KDE3/ - document flag removal * Fri Nov 02 2007 Rex Dieter 1:3.5.8-2 - BR: kdelibs3-devel - Req: kde-filesystem * Tue Oct 16 2007 Than Ngo 1:3.5.8-1 - 3.5.8 kdebindings-3.97.0-8.fc9 ------------------------ * Thu Jan 03 2008 Kevin Kofler 3.97.0-8 - smoke.h is in %{_includedir}, not %{_kde4_includedir} * Wed Dec 12 2007 Kevin Kofler 3.97.0-7 - rebuild for changed _kde4_includedir kexec-tools-1.102pre-3.fc9 -------------------------- * Wed Jan 02 2008 Neil Horman - 1.102pre-3 - Fix ARCH placement in kdump init script (bz 427201) - Fix BuildRequires - Fix Makedumpfile to build with new libelf kile-2.0-2.fc9 -------------- * Thu Jan 03 2008 Kevin Kofler 2.0-2 - BR kdelibs3-devel (F7+, EL6+) ksensors-0.7.3-15.fc9 --------------------- * Thu Jan 03 2008 Hans de Goede 0.7.3-15 - Change BuildRequires: kdelibs-devel into kdelibs3-devel libchmxx-0.1-6.fc9 ------------------ * Thu Jan 03 2008 Patrice Dumas 0.1-6 - fix for gcc 4.3 libdhcp-1.99.4-1.fc9 -------------------- * Thu Jan 03 2008 David Cantrell - 1.99.4-1 - Upgrade to libdhcp-1.99.4, fixes problems due to libnl API change - Drop the libdhcp-static package * Wed Dec 19 2007 David Cantrell - 1.99.3-1 - Upgrade to libdhcp-1.99.3 - Rebuild for new libnl * Fri Nov 30 2007 David Cantrell - 1.99.1-1 - Upgrade to libdhcp-1.99.1 libfwbuilder-2.1.16-1.fc9 ------------------------- * Thu Jan 03 2008 Ralf Ertzinger 2.1.16-1 - Update to 2.1.16 - Add patch to enable compilation with GCC4.3 libselinux-2.0.46-3.fc9 ----------------------- * Thu Jan 03 2008 Dan Walsh - 2.0.46-3 - smp_mflag * Thu Jan 03 2008 Dan Walsh - 2.0.46-2 - Fix spec file caused by spec review libsigc++20-2.0.18-2.fc9 ------------------------ * Thu Jan 03 2008 Tom "spot" Callaway 2.0.18-2 - add test case for gcc4.3 failure conditional libsvm-2.84-9.fc9 ----------------- * Thu Dec 20 2007 Ding-Yi Chen - 2.84-9 - [Bug 254091] Comment 19 - Fix python/Makefile lilypond-doc-2.10.33-1.fc9 -------------------------- * Thu Jan 03 2008 Quentin Spencer 2.10.33-1 - Update to 2.10.33. - Compilation fails if the install section doesn't create $RPM_BUILD_ROOT. - Fix the license tag (GPLv2). - Misc changes to clean up rpmlint warnings. linux-atm-2.5.0-5 ----------------- * Thu Jan 03 2008 David Woodhouse - 2.5.0-5 - Update to 2.5.0 release londonlaw-0.2.1-3.fc9 --------------------- mapserver-4.10.3-3.fc9 ---------------------- * Thu Dec 06 2007 Release Engineering - 4.10.3-3 - Rebuild for deps mirage-0.9-3.fc9 ---------------- * Fri Jan 04 2008 Mamoru Tasaka - 0.9-3 - Support python egginfo for F-9+ mkinitrd-6.0.27-2.fc9 --------------------- * Thu Jan 03 2008 Jesse Keating - 6.0.27-2 - Rebuild for libparted soname bump. mod_fcgid-2.2-2.fc9 ------------------- * Thu Jan 03 2008 Paul Howarth 2.2-2 - Update SELinux policy to support file transition to httpd_tmp_t for temporary files ogdi-3.2.0-0.6.beta1.fc9 ------------------------ * Thu Jan 03 2008 Alex Lancaster - 3.2.0-0.6.beta1 - Rebuild for new Tcl 8.5 openssh-4.7p1-7.fc9 ------------------- * Thu Jan 03 2008 Tomas Mraz - 4.7p1-7 - fix gssapi auth with explicit selinux role requested (#427303) - patch by Nalin Dahyabhai * Tue Dec 04 2007 Tomas Mraz - 4.7p1-6 - explicitly source krb5-devel profile script ovaldi-5.3-2.fc9 ---------------- pcapy-0.10.5-2.fc9 ------------------ perl-DateTime-Format-Strptime-1.0702-1.fc9 ------------------------------------------ * Thu Jan 03 2008 Steven Pritchard 1.0702-1 - Update to 1.0702. - Drop charset patch. - Update License tag. - BR Test::More. perl-GSSAPI-0.24-3.fc9 ---------------------- * Thu Jan 03 2008 Steven Pritchard 0.24-3 - Use sysconfdir macro instead of hard-coding /etc. perl-Kwiki-0.39-2.fc9 --------------------- * Fri Jan 04 2008 Ralf Cors??pius 0.39-2 - Update License-tag. - BR: perl(Test::Memory::Cycle). - BR: perl(Test::More) (BZ 419631). * Tue Mar 13 2007 Steven Pritchard 0.39-1 - Update to 0.39. - Use fixperms macro instead of our own chmod incantation. - BR ExtUtils::MakeMaker. * Mon Sep 04 2006 Steven Pritchard 0.38-4 - Cleanup to more closely resemble current cpanspec output. - kwiki is a program, not documentation. perl-Kwiki-Archive-Rcs-0.15-7.fc9 --------------------------------- * Fri Jan 04 2008 Ralf Cors??pius 0.15-7 - Update License-tag. - BR: perl(Test::More) (BZ 419631). perl-Kwiki-Attachments-0.18-4.fc9 --------------------------------- * Fri Jan 04 2008 Ralf Cors??pius 0.18-4 - Update License-tag. - BR: perl(Test::More) (BZ 419631). perl-Kwiki-Diff-0.03-5.fc9 -------------------------- * Fri Jan 04 2008 Ralf Cors??pius 0.03-5 - Update License-tag. - BR: perl(Test::Pod::Coverage), perl(Test::Pod). - BR: perl(Test::More) (BZ 419631). ppracer-0.3.1-14.fc9 -------------------- * Thu Jan 03 2008 Nils Philippsen 0.3.1-14 - rebuild pygobject2-2.14.1-1.fc9 ----------------------- * Thu Jan 03 2008 Matthew Barnes - 2.14.1-1.fc9 - Update to 2.14.1 pygpgme-0.1-7.fc9 ----------------- * Thu Jan 03 2008 Toshio Kuratomi - 0.1-7 - Include egg-info files. pygtk2-2.12.1-1.fc9 ------------------- * Thu Jan 03 2008 Matthew Barnes - 2.12.1-1.fc9 - Update to 2.12.1 - Remove patch for RH bug #217430 (fixed upstream). - Remove patch for GNOME bug #479012 (fixed upstream). python-chm-0.8.4-3.fc9 ---------------------- * Thu Jan 03 2008 Patrice Dumas 0.8.4-3 - remove python-abi requires, it needs python in the build root - ship egg file python-exif-1.0.7-1.fc9 ----------------------- * Thu Jan 03 2008 Terje Rosten - 1.0.7-1 - 1.0.7 - Include egg info python-mecab-0.96-3.fc9.1 ------------------------- * Fri Jan 04 2008 Mamoru Tasaka - 0.96-3 - Support python egginfo for F-9+ python-psycopg2-2.0.6-3.fc9 --------------------------- * Thu Jan 03 2008 - Devrim GUNDUZ 2.0.6-3 - Rebuild for rawhide changes python-pycurl-7.16.4-2.fc9 -------------------------- * Thu Jan 03 2008 Jeffrey C. Ollie - 7.16.4-2 - BR openssl-devel python-qpid-0.2-2.fc9 --------------------- python-simpy-1.8-2.fc9 ---------------------- * Thu Jan 03 2008 Sarantis Paskalis - 1.8-2 - Account for python eggs python-xmpp-0.4.1-1.fc9 ----------------------- * Thu Jan 03 2008 Jeffrey C. Ollie - 0.4.1-1 - Update to 0.4.1. * Thu Jan 03 2008 Jeffrey C. Ollie - 0.4.0-3 - Change files section to pick up egg info files. qfaxreader-0.3.1-9.fc9 ---------------------- * Fri Jan 04 2008 manuel wolfshant - 0.3.1-9 - As recommended by the software author, add patch fixing configure in order to make it compile with gcc-4.3.0 qlandkarte-0.6.0-1.fc9 ---------------------- * Thu Jan 03 2008 Dan Horak 0.6.0-1 - upgrade to 0.6.0 - fix compile with gcc 4.3 qpidc-0.2-17.fc9 ---------------- * Thu Jan 03 2008 Nuno Santos - 0.2-17 - add missing header file SessionManager.h * Thu Jan 03 2008 Nuno Santos - 0.2-16 - limit builds to i386 and x86_64 archs * Thu Jan 03 2008 Nuno Santos - 0.2-15 - add ruby as a build dependency readline-5.2-9.fc9 ------------------ * Thu Jan 03 2008 Miroslav Lichvar 5.2-9 - include upstream patches 008-011 revisor-2.0.5-15.fc9 -------------------- * Thu Jan 03 2008 Jeroen van Meeuwen 2.0.5-15 - Let's not build revisor-cobbler on ppc/ppc64 rhm-0.2-10.fc9 -------------- * Thu Jan 03 2008 Nuno Santos - 0.2-10 - add missing dependencies on libaio, cppunit roxterm-1.9.1-1.fc9 ------------------- * Wed Jan 02 2008 Sebastian Vahl - 1.9.1-1 - new upstream version: 1.9.1 seahorse-2.21.4-1.fc9 --------------------- * Thu Jan 03 2008 Seth Vidal 2.21.4-1 - upgrade to 2.21.4 smart-0.52-53.fc9 ----------------- * Thu Jan 03 2008 Ville Skytt?? - 0.52-53 - Include possibly generated smart-*.egg-info in main package. starplot-0.95.4-4.fc9 --------------------- * Thu Jan 03 2008 Lubomir Kundrak 0.95.4-4 - Corrected Patch0 name - Adding missing includes to fix build with gcc-4.3 tcl-1:8.5.0-2.fc9 ----------------- * Thu Jan 03 2008 Marcela Maslanova - 1:8.5.0-2 - rebuilt because of nonsense in tag * Wed Jan 02 2008 Marcela Maslanova - 1:8.5.0-1 - upgrade on the new whole version 8.5.0 - thank you for patches and clean spec to wart (at kobold) * Fri Nov 16 2007 Marcela Maslanova - 1:8.4.15-6 - CVE-2007-4772 NFA optimization cause hang in loop. Back ported patch from upstream development version. tclchecker-1.4-4.20061030cvs.fc9 -------------------------------- * Thu Jan 03 2008 Wart 1.4-4.20061030cvs - Rebuild for Tcl 8.5 tcldebugger-1.4-6.20061030cvs.fc9 --------------------------------- * Thu Jan 03 2008 Wart 1.4-6.20061030cvs - Rebuild for Tcl 8.5 tcllib-1.10-2.fc9 ----------------- * Thu Jan 03 2008 Wart - 1.10-2 - Rebuild for Tcl 8.5 tclpro-1.5.0-11.20061030cvs.fc9 ------------------------------- * Sun Jan 13 2008 Wart 1.5.0-11.20061030cvs - Rebuild for Tcl 8.5 texlive-2007-6.fc9 ------------------ * Wed Jan 02 2008 Jindrich Novy - 2007-6 - unify texlive and texlive-fonts packages and obsolete texlive-fonts (related: #426388) - move subpackages versions to the top of spec file - changes from Patruce Dumas: * remove BuildRequires on texmf packages * don't create .fmt files during the build * ship the ptex.pool file texlive-texmf-2007-5.fc9 ------------------------ * Wed Jan 02 2008 Jindrich Novy - 2007-5 - remove preview, it is to be packaged separately (#425805) - add japanese ptex fmtutil configuration, thanks to Patrice Dumas - update texlive-texmf-fonts package description to reflect texlive and texlive-fonts merge (related: #426388) tkimg-1.3-0.7.20071018svn.fc9 ----------------------------- * Thu Jan 03 2008 Sergio Pascual 1.3-0.7.20071018svn - Rebuilt for tcl 8.5 tklib-0.4.1-7.fc9 ----------------- * Thu Jan 03 2008 Wart 0.4.1-7 - Rebuild for Tcl 8.5 torque-2.1.10-4.fc9 ------------------- * Thu Jan 03 2008 Garrick Staples 2.1.10-4 - correct pbs-config build typo * Thu Jan 03 2008 Garrick Staples 2.1.10-3 - rebuild because tcl was bumped * Thu Dec 13 2007 Garrick Staples 2.1.10-2 - fix multilib conflicts trac-0.10.4-2.fc9 ----------------- * Thu Jan 03 2008 Jeffrey C. Ollie - 0.10.4-2 - Simplify files section so that it picks up the egg info files. * Thu May 03 2007 Jeffrey C. Ollie - 0.10.4-1 - Update to 0.10.4 * Mon Mar 12 2007 Jeffrey C. Ollie - 0.10.3.1-2 - Switch requires back to python-sqlite trackballs-1.1.4-4.fc9 ---------------------- * Thu Jan 03 2008 Hans de Goede 1.1.4-4 - Fix black vertices on ATI cards with OSS drivers tzdata-2007k-1.fc9 ------------------ * Thu Jan 03 2008 Petr Machata - 2007k-1 - Upstream 2007k - Argentina readopted the daylight saving time uudeview-0.5.20-14 ------------------ * Thu Jan 03 2008 Adrian Reber - 0.5.20-14 - rebuilt for tcl-8.5 - added patch from debian - changed BR from tetex-latex to texlive-latex wv2-0.2.3-4.fc9 --------------- * Fri Jan 04 2008 Andreas Bierfert 0.2.3-4 - fix #343451 multiarch xchat-1:2.8.4-10.fc9 -------------------- * Thu Jan 03 2008 Christopher Aillon 1:2.8.4-10 - Rebuild * Thu Dec 20 2007 Adam Jackson 1:2.8.4-9 - xchat-2.8.4-shm-pixmaps.patch: MIT-SHM pixmaps are optional, and when using EXA they are not available. Check that the server supports them before trying to create them so we don't crash. * Wed Dec 19 2007 Kevin Kofler - 1:2.8.4-8 - apply xc284-fix-scrollbfdleak.diff from upstream xorg-x11-drv-radeonhd-1.1.0-0.3.20080103git.fc9 ----------------------------------------------- * Thu Jan 03 2008 Hans Ulrich Niedermann - 1.1.0-0.3.20080103git - New snapshot (upstream commit 4e488a349c862da2e27f6025d376fb2b63db3bf9): - Enable FB location fix for r5xx. - Fix PLLControlTableRetrieve() loop. xpa-2.1.8-4.fc9 --------------- * Thu Jan 03 2008 Sergio Pascual 2.1.8-4 - Rebuilt for tcl 8.5 xulrunner-1.9-0.beta2.6.fc9 --------------------------- * Thu Jan 03 2008 Christopher Aillon 1.9-0.beta2.6 - Re-enable camellia256 support now that NSS supports it * Thu Jan 03 2008 Martin Stransky 1.9-0.beta2.5 - updated to the latest trunk (2008-01-03) yum-utils-1.1.10-1.fc9 ---------------------- * Thu Jan 03 2008 Tim Lauridsen - mark as 1.1.10 * Wed Dec 12 2007 James Antill - Add yum-aliases plugin zoneminder-1.22.3-11.fc9 ------------------------ * Thu Jan 03 2008 Martin Ebourne - 1.22.3-11 - Fix compilation on gcc 4.3 Broken deps for i386 ---------------------------------------------------------- TeXmacs - 1.0.6.12-2.fc9.i386 requires tetex-fonts a2ps - 4.13b-69.fc8.i386 requires tetex-fonts bacula-client - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-client - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bwidget - 1.8.0-2.fc8.noarch requires tcl(abi) = 0:8.4 csound-tk - 5.03.0-13.fc7.i386 requires libtk8.4.so csound-tk - 5.03.0-13.fc7.i386 requires libtcl8.4.so d4x - 2.5.7.1-3.fc7.i386 requires libssl.so.6 d4x - 2.5.7.1-3.fc7.i386 requires libcrypto.so.6 dblatex - 0.2.8-2.fc9.1.noarch requires tetex-fonts ds9 - 5.0-6.fc9.i386 requires libtk8.4.so ds9 - 5.0-6.fc9.i386 requires libtcl8.4.so eggdrop - 1.6.18-12.fc9.i386 requires libtcl8.4.so epiphany-extensions - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires libgtkembedmoz.so expect - 5.43.0-9.fc8.i386 requires libtcl8.4.so expectk - 5.43.0-9.fc8.i386 requires libtk8.4.so expectk - 5.43.0-9.fc8.i386 requires libtcl8.4.so fwbuilder - 2.1.14-1.fc8.i386 requires libfwbuilder = 0:2.1.14 gcl - 2.6.7-15.fc8.i386 requires libtcl8.4.so gcl - 2.6.7-15.fc8.i386 requires libtk8.4.so gnome-web-photo - 0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.i386 requires libgtkembedmoz.so gparted - 0.3.3-14.fc9.i386 requires libparted-1.8.so.6 grads - 1.9b4-21.fc8.i386 requires libdap.so.6 graphviz-tcl - 2.14.1-3.fc8.i386 requires libtk8.4.so irsim - 9.7.50-1.fc8.i386 requires libtcl8.4.so irsim - 9.7.50-1.fc8.i386 requires libtk8.4.so isdn4k-utils-vboxgetty - 3.2-55.fc8.i386 requires libtcl8.4.so kannel - 1.4.1-5.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 libopensync-plugin-sunbird - 0.22-3.fc7.i386 requires libneon.so.25 libopensync-plugin-sunbird - 0.22-3.fc7.i386 requires libopensync.so.0 libopensync-plugin-sunbird - 0.22-3.fc7.i386 requires libssl.so.6 libopensync-plugin-sunbird - 0.22-3.fc7.i386 requires libcrypto.so.6 libopensync-plugin-synce - 0.22-4.fc8.i386 requires libopensync.so.0 libpurple-tcl - 2.3.1-1.fc9.i386 requires libtk8.4.so libpurple-tcl - 2.3.1-1.fc9.i386 requires libtcl8.4.so liferea - 1.4.10-1.fc9.i386 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.i386 requires libgtkembedmoz.so magic - 7.4.35-6.fc8.i386 requires libtcl8.4.so magic - 7.4.35-6.fc8.i386 requires libtk8.4.so mftrace - 1.2.14-2.fc8.i386 requires tetex-fonts multisync - 0.91.0-1.fc7.i386 requires libopensync.so.0 multisync - 0.91.0-1.fc7.i386 requires libosengine.so.0 multisync-gui - 0.91.0-1.fc7.i386 requires libopensync.so.0 multisync-gui - 0.91.0-1.fc7.i386 requires libosengine.so.0 netgen - 1.3.7-13.fc9.i386 requires libtcl8.4.so netgen - 1.3.7-13.fc9.i386 requires libtk8.4.so ocaml-labltk - 3.10.0-7.fc8.i386 requires libtk8.4.so ocaml-labltk - 3.10.0-7.fc8.i386 requires libtcl8.4.so openmsx - 0.6.2-4.fc8.i386 requires libtcl8.4.so plplot - 5.8.0-5.fc9.i386 requires libtcl8.4.so plplot - 5.8.0-5.fc9.i386 requires libtk8.4.so plplot-tk - 5.8.0-5.fc9.i386 requires libtk8.4.so plplot-tk - 5.8.0-5.fc9.i386 requires libtcl8.4.so postgresql-pltcl - 8.2.5-2.fc9.i386 requires libtcl8.4.so pvm-gui - 3.4.5-7.fc6.1.i386 requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.i386 requires libtcl8.4.so python-gammu - 0.22-3.fc8.i386 requires libGammu.so.2 python-imaging-tk - 1.1.6-4.fc8.i386 requires libtk8.4.so python-imaging-tk - 1.1.6-4.fc8.i386 requires libtcl8.4.so python-matplotlib-tk - 0.90.1-2.fc8.i386 requires libtk8.4.so python-matplotlib-tk - 0.90.1-2.fc8.i386 requires libtcl8.4.so q - 7.10-1.fc9.i386 requires libtcl8.4.so q - 7.10-1.fc9.i386 requires libtk8.4.so qtparted - 0.4.5-15.fc8.i386 requires libparted-1.8.so.6 ruby-tcltk - 1.8.6.111-4.fc9.i386 requires libtk8.4.so ruby-tcltk - 1.8.6.111-4.fc9.i386 requires libtcl8.4.so skencil - 0.6.17-15.20070606svn.fc8.i386 requires libtk8.4.so skencil - 0.6.17-15.20070606svn.fc8.i386 requires libtcl8.4.so tbcload - 1.4-5.20061030cvs.fc8.i386 requires tcl(abi) = 0:8.4 tcl-brlapi - 0.5.0-1.fc8.i386 requires libtcl8.4.so tcl-tcldict - 8.5.2-2.fc8.i386 requires tcl(abi) = 0:8.4 tclcompiler - 1.5-3.20061030cvs.fc8.i386 requires tcl(abi) = 0:8.4 tcldom - 3.1-10.fc7.i386 requires tcl(abi) = 0:8.4 tclhttpd - 3.5.1-15.fc8.i386 requires tcl(abi) = 0:8.4 tetex-font-cm-lgc - 0.5-8.fc6.noarch requires tetex-fonts tetex-font-kerkis - 2.0-13.fc6.noarch requires tetex-fonts tk-tktreectrl - 2.2.3-2.fc8.i386 requires tcl(abi) = 0:8.4 tkinter - 2.5.1-18.fc9.i386 requires libtk8.4.so tkinter - 2.5.1-18.fc9.i386 requires libtcl8.4.so vkeybd - 0.1.17a-5.fc8.i386 requires tk < 1:8.5 vkeybd - 0.1.17a-5.fc8.i386 requires libtk8.4.so vkeybd - 0.1.17a-5.fc8.i386 requires libtcl8.4.so vtk - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtcl8.4.so xca - 0.6.4-1.fc8.i386 requires libcrypto.so.6 xcircuit - 3.4.27-1.fc9.i386 requires libtk8.4.so xcircuit - 3.4.27-1.fc9.i386 requires libtcl8.4.so Broken deps for x86_64 ---------------------------------------------------------- TeXmacs - 1.0.6.12-2.fc9.x86_64 requires tetex-fonts a2ps - 4.13b-69.fc8.x86_64 requires tetex-fonts a2ps - 4.13b-69.fc8.i386 requires tetex-fonts bacula-client - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bwidget - 1.8.0-2.fc8.noarch requires tcl(abi) = 0:8.4 csound-tk - 5.03.0-13.fc7.x86_64 requires libtk8.4.so()(64bit) csound-tk - 5.03.0-13.fc7.x86_64 requires libtcl8.4.so()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libssl.so.6()(64bit) dblatex - 0.2.8-2.fc9.1.noarch requires tetex-fonts ds9 - 5.0-6.fc9.x86_64 requires libtk8.4.so()(64bit) ds9 - 5.0-6.fc9.x86_64 requires libtcl8.4.so()(64bit) eggdrop - 1.6.18-12.fc9.x86_64 requires libtcl8.4.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) expect - 5.43.0-9.fc8.x86_64 requires libtcl8.4.so()(64bit) expect - 5.43.0-9.fc8.i386 requires libtcl8.4.so expectk - 5.43.0-9.fc8.x86_64 requires libtk8.4.so()(64bit) expectk - 5.43.0-9.fc8.x86_64 requires libtcl8.4.so()(64bit) fwbuilder - 2.1.14-1.fc8.x86_64 requires libfwbuilder = 0:2.1.14 gcl - 2.6.7-15.fc8.x86_64 requires libtcl8.4.so()(64bit) gcl - 2.6.7-15.fc8.x86_64 requires libtk8.4.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) gparted - 0.3.3-14.fc9.x86_64 requires libparted-1.8.so.6()(64bit) grads - 1.9b4-21.fc8.x86_64 requires libdap.so.6()(64bit) graphviz-tcl - 2.14.1-3.fc8.x86_64 requires libtk8.4.so()(64bit) isdn4k-utils-vboxgetty - 3.2-55.fc8.x86_64 requires libtcl8.4.so()(64bit) kazehakase - 0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 libopensync-plugin-sunbird - 0.22-3.fc7.x86_64 requires libssl.so.6()(64bit) libopensync-plugin-sunbird - 0.22-3.fc7.x86_64 requires libneon.so.25()(64bit) libopensync-plugin-sunbird - 0.22-3.fc7.x86_64 requires libcrypto.so.6()(64bit) libopensync-plugin-sunbird - 0.22-3.fc7.x86_64 requires libopensync.so.0()(64bit) libopensync-plugin-synce - 0.22-4.fc8.x86_64 requires libopensync.so.0()(64bit) libpurple-tcl - 2.3.1-1.fc9.x86_64 requires libtk8.4.so()(64bit) libpurple-tcl - 2.3.1-1.fc9.x86_64 requires libtcl8.4.so()(64bit) liferea - 1.4.10-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.x86_64 requires libgtkembedmoz.so()(64bit) magic - 7.4.35-6.fc8.x86_64 requires libtcl8.4.so()(64bit) magic - 7.4.35-6.fc8.x86_64 requires libtk8.4.so()(64bit) mftrace - 1.2.14-2.fc8.x86_64 requires tetex-fonts multisync - 0.91.0-1.fc7.x86_64 requires libosengine.so.0()(64bit) multisync - 0.91.0-1.fc7.x86_64 requires libopensync.so.0()(64bit) multisync-gui - 0.91.0-1.fc7.x86_64 requires libopensync.so.0()(64bit) multisync-gui - 0.91.0-1.fc7.x86_64 requires libosengine.so.0()(64bit) netgen - 1.3.7-13.fc9.x86_64 requires libtcl8.4.so()(64bit) netgen - 1.3.7-13.fc9.x86_64 requires libtk8.4.so()(64bit) ocaml-labltk - 3.10.0-7.fc8.x86_64 requires libtcl8.4.so()(64bit) ocaml-labltk - 3.10.0-7.fc8.x86_64 requires libtk8.4.so()(64bit) openmsx - 0.6.2-4.fc8.x86_64 requires libtcl8.4.so()(64bit) plplot - 5.8.0-5.fc9.x86_64 requires libtk8.4.so()(64bit) plplot - 5.8.0-5.fc9.x86_64 requires libtcl8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.x86_64 requires libtk8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.x86_64 requires libtcl8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.i386 requires libtk8.4.so plplot-tk - 5.8.0-5.fc9.i386 requires libtcl8.4.so postgresql-pltcl - 8.2.5-2.fc9.x86_64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.x86_64 requires libtk8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.x86_64 requires libtcl8.4.so()(64bit) python-gammu - 0.22-3.fc8.x86_64 requires libGammu.so.2()(64bit) python-imaging-tk - 1.1.6-4.fc8.x86_64 requires libtk8.4.so()(64bit) python-imaging-tk - 1.1.6-4.fc8.x86_64 requires libtcl8.4.so()(64bit) python-matplotlib-tk - 0.90.1-2.fc8.x86_64 requires libtcl8.4.so()(64bit) python-matplotlib-tk - 0.90.1-2.fc8.x86_64 requires libtk8.4.so()(64bit) q - 7.10-1.fc9.i386 requires libtcl8.4.so q - 7.10-1.fc9.i386 requires libtk8.4.so qtparted - 0.4.5-15.fc8.x86_64 requires libparted-1.8.so.6()(64bit) ruby-tcltk - 1.8.6.111-4.fc9.x86_64 requires libtk8.4.so()(64bit) ruby-tcltk - 1.8.6.111-4.fc9.x86_64 requires libtcl8.4.so()(64bit) skencil - 0.6.17-15.20070606svn.fc8.x86_64 requires libtcl8.4.so()(64bit) skencil - 0.6.17-15.20070606svn.fc8.x86_64 requires libtk8.4.so()(64bit) tbcload - 1.4-5.20061030cvs.fc8.x86_64 requires tcl(abi) = 0:8.4 tcl-brlapi - 0.5.0-1.fc8.x86_64 requires libtcl8.4.so()(64bit) tcl-tcldict - 8.5.2-2.fc8.x86_64 requires tcl(abi) = 0:8.4 tclcompiler - 1.5-3.20061030cvs.fc8.x86_64 requires tcl(abi) = 0:8.4 tcldom - 3.1-10.fc7.x86_64 requires tcl(abi) = 0:8.4 tclhttpd - 3.5.1-15.fc8.x86_64 requires tcl(abi) = 0:8.4 tetex-font-cm-lgc - 0.5-8.fc6.noarch requires tetex-fonts tetex-font-kerkis - 2.0-13.fc6.noarch requires tetex-fonts tk-tktreectrl - 2.2.3-2.fc8.x86_64 requires tcl(abi) = 0:8.4 tkinter - 2.5.1-18.fc9.x86_64 requires libtk8.4.so()(64bit) tkinter - 2.5.1-18.fc9.x86_64 requires libtcl8.4.so()(64bit) vkeybd - 0.1.17a-5.fc8.x86_64 requires libtcl8.4.so()(64bit) vkeybd - 0.1.17a-5.fc8.x86_64 requires libtk8.4.so()(64bit) vkeybd - 0.1.17a-5.fc8.x86_64 requires tk < 1:8.5 vtk - 5.0.3-20.fc8.x86_64 requires libtk8.4.so()(64bit) vtk - 5.0.3-20.fc8.x86_64 requires libtcl8.4.so()(64bit) vtk - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-python - 5.0.3-20.fc8.x86_64 requires libtk8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.x86_64 requires libtcl8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.x86_64 requires libtk8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.x86_64 requires libtcl8.4.so()(64bit) xca - 0.6.4-1.fc8.x86_64 requires libcrypto.so.6()(64bit) xcircuit - 3.4.27-1.fc9.x86_64 requires libtk8.4.so()(64bit) xcircuit - 3.4.27-1.fc9.x86_64 requires libtcl8.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- TeXmacs - 1.0.6.12-2.fc9.ppc requires tetex-fonts a2ps - 4.13b-69.fc8.ppc requires tetex-fonts a2ps - 4.13b-69.fc8.ppc64 requires tetex-fonts bacula-client - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-client - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bwidget - 1.8.0-2.fc8.noarch requires tcl(abi) = 0:8.4 csound-tk - 5.03.0-13.fc7.ppc requires libtk8.4.so csound-tk - 5.03.0-13.fc7.ppc requires libtcl8.4.so d4x - 2.5.7.1-3.fc7.ppc requires libssl.so.6 d4x - 2.5.7.1-3.fc7.ppc requires libcrypto.so.6 dblatex - 0.2.8-2.fc9.1.noarch requires tetex-fonts ds9 - 5.0-6.fc9.ppc requires libtk8.4.so ds9 - 5.0-6.fc9.ppc requires libtcl8.4.so eggdrop - 1.6.18-12.fc9.ppc requires libtcl8.4.so epiphany-extensions - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires libgtkembedmoz.so expect - 5.43.0-9.fc8.ppc64 requires libtcl8.4.so()(64bit) expect - 5.43.0-9.fc8.ppc requires libtcl8.4.so expectk - 5.43.0-9.fc8.ppc requires libtk8.4.so expectk - 5.43.0-9.fc8.ppc requires libtcl8.4.so fwbuilder - 2.1.14-1.fc8.ppc requires libfwbuilder = 0:2.1.14 gnome-web-photo - 0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.ppc requires libgtkembedmoz.so gparted - 0.3.3-14.fc9.ppc requires libparted-1.8.so.6 grads - 1.9b4-21.fc8.ppc requires libdap.so.6 graphviz-tcl - 2.14.1-3.fc8.ppc requires libtk8.4.so irsim - 9.7.50-1.fc8.ppc requires libtcl8.4.so irsim - 9.7.50-1.fc8.ppc requires libtk8.4.so isdn4k-utils-vboxgetty - 3.2-55.fc8.ppc requires libtcl8.4.so kannel - 1.4.1-5.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 libopensync-plugin-sunbird - 0.22-3.fc7.ppc requires libneon.so.25 libopensync-plugin-sunbird - 0.22-3.fc7.ppc requires libopensync.so.0 libopensync-plugin-sunbird - 0.22-3.fc7.ppc requires libssl.so.6 libopensync-plugin-sunbird - 0.22-3.fc7.ppc requires libcrypto.so.6 libopensync-plugin-synce - 0.22-4.fc8.ppc requires libopensync.so.0 libpurple-tcl - 2.3.1-1.fc9.ppc requires libtk8.4.so libpurple-tcl - 2.3.1-1.fc9.ppc requires libtcl8.4.so liferea - 1.4.10-1.fc9.ppc requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc requires libgtkembedmoz.so magic - 7.4.35-6.fc8.ppc requires libtcl8.4.so magic - 7.4.35-6.fc8.ppc requires libtk8.4.so mftrace - 1.2.14-2.fc8.ppc requires tetex-fonts monodevelop - 0.17-4.fc9.ppc requires boo multisync - 0.91.0-1.fc7.ppc requires libopensync.so.0 multisync - 0.91.0-1.fc7.ppc requires libosengine.so.0 multisync-gui - 0.91.0-1.fc7.ppc requires libopensync.so.0 multisync-gui - 0.91.0-1.fc7.ppc requires libosengine.so.0 netgen - 1.3.7-13.fc9.ppc requires libtcl8.4.so netgen - 1.3.7-13.fc9.ppc requires libtk8.4.so ocaml-labltk - 3.10.0-7.fc8.ppc requires libtk8.4.so ocaml-labltk - 3.10.0-7.fc8.ppc requires libtcl8.4.so openmsx - 0.6.2-4.fc8.ppc requires libtcl8.4.so plplot - 5.8.0-5.fc9.ppc requires libtcl8.4.so plplot - 5.8.0-5.fc9.ppc requires libtk8.4.so plplot-tk - 5.8.0-5.fc9.ppc64 requires libtk8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.ppc64 requires libtcl8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.ppc requires libtk8.4.so plplot-tk - 5.8.0-5.fc9.ppc requires libtcl8.4.so postgresql-pltcl - 8.2.5-2.fc9.ppc requires libtcl8.4.so pvm-gui - 3.4.5-7.fc6.1.ppc requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.ppc requires libtcl8.4.so python-gammu - 0.22-3.fc8.ppc requires libGammu.so.2 python-imaging-tk - 1.1.6-4.fc8.ppc requires libtk8.4.so python-imaging-tk - 1.1.6-4.fc8.ppc requires libtcl8.4.so python-matplotlib-tk - 0.90.1-2.fc8.ppc requires libtk8.4.so python-matplotlib-tk - 0.90.1-2.fc8.ppc requires libtcl8.4.so q - 7.10-1.fc9.ppc requires libtcl8.4.so q - 7.10-1.fc9.ppc requires libtk8.4.so q - 7.10-1.fc9.ppc64 requires libtcl8.4.so()(64bit) q - 7.10-1.fc9.ppc64 requires libtk8.4.so()(64bit) qtparted - 0.4.5-15.fc8.ppc requires libparted-1.8.so.6 ruby-tcltk - 1.8.6.111-4.fc9.ppc requires libtk8.4.so ruby-tcltk - 1.8.6.111-4.fc9.ppc requires libtcl8.4.so skencil - 0.6.17-15.20070606svn.fc8.ppc requires libtk8.4.so skencil - 0.6.17-15.20070606svn.fc8.ppc requires libtcl8.4.so tbcload - 1.4-5.20061030cvs.fc8.ppc requires tcl(abi) = 0:8.4 tcl-brlapi - 0.5.0-1.fc8.ppc requires libtcl8.4.so tcl-tcldict - 8.5.2-2.fc8.ppc requires tcl(abi) = 0:8.4 tclcompiler - 1.5-3.20061030cvs.fc8.ppc requires tcl(abi) = 0:8.4 tcldom - 3.1-10.fc7.ppc requires tcl(abi) = 0:8.4 tclhttpd - 3.5.1-15.fc8.ppc requires tcl(abi) = 0:8.4 tetex-font-cm-lgc - 0.5-8.fc6.noarch requires tetex-fonts tetex-font-kerkis - 2.0-13.fc6.noarch requires tetex-fonts tk-tktreectrl - 2.2.3-2.fc8.ppc requires tcl(abi) = 0:8.4 tkinter - 2.5.1-18.fc9.ppc requires libtk8.4.so tkinter - 2.5.1-18.fc9.ppc requires libtcl8.4.so vkeybd - 0.1.17a-5.fc8.ppc requires libtk8.4.so vkeybd - 0.1.17a-5.fc8.ppc requires libtcl8.4.so vkeybd - 0.1.17a-5.fc8.ppc requires tk < 1:8.5 vtk - 5.0.3-20.fc8.ppc requires libtcl8.4.so vtk - 5.0.3-20.fc8.ppc requires libtk8.4.so vtk - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc requires libtk8.4.so vtk-python - 5.0.3-20.fc8.ppc requires libtcl8.4.so vtk-python - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc requires libtk8.4.so vtk-tcl - 5.0.3-20.fc8.ppc requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) xca - 0.6.4-1.fc8.ppc requires libcrypto.so.6 xcircuit - 3.4.27-1.fc9.ppc requires libtk8.4.so xcircuit - 3.4.27-1.fc9.ppc requires libtcl8.4.so Broken deps for ppc64 ---------------------------------------------------------- TeXmacs - 1.0.6.12-2.fc9.ppc64 requires tetex-fonts a2ps - 4.13b-69.fc8.ppc64 requires tetex-fonts bacula-client - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bwidget - 1.8.0-2.fc8.noarch requires tcl(abi) = 0:8.4 csound-tk - 5.03.0-13.fc7.ppc64 requires libtk8.4.so()(64bit) csound-tk - 5.03.0-13.fc7.ppc64 requires libtcl8.4.so()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libssl.so.6()(64bit) dblatex - 0.2.8-2.fc9.1.noarch requires tetex-fonts ds9 - 5.0-6.fc9.ppc64 requires libtk8.4.so()(64bit) ds9 - 5.0-6.fc9.ppc64 requires libtcl8.4.so()(64bit) eggdrop - 1.6.18-12.fc9.ppc64 requires libtcl8.4.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) expect - 5.43.0-9.fc8.ppc64 requires libtcl8.4.so()(64bit) expectk - 5.43.0-9.fc8.ppc64 requires libtk8.4.so()(64bit) expectk - 5.43.0-9.fc8.ppc64 requires libtcl8.4.so()(64bit) fwbuilder - 2.1.14-1.fc8.ppc64 requires libfwbuilder = 0:2.1.14 gnome-web-photo - 0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) gparted - 0.3.3-14.fc9.ppc64 requires libparted-1.8.so.6()(64bit) grads - 1.9b4-21.fc8.ppc64 requires libdap.so.6()(64bit) graphviz-tcl - 2.14.1-3.fc8.ppc64 requires libtk8.4.so()(64bit) isdn4k-utils-vboxgetty - 3.2-55.fc8.ppc64 requires libtcl8.4.so()(64bit) kazehakase - 0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 libopensync-plugin-sunbird - 0.22-3.fc7.ppc64 requires libssl.so.6()(64bit) libopensync-plugin-sunbird - 0.22-3.fc7.ppc64 requires libneon.so.25()(64bit) libopensync-plugin-sunbird - 0.22-3.fc7.ppc64 requires libcrypto.so.6()(64bit) libopensync-plugin-sunbird - 0.22-3.fc7.ppc64 requires libopensync.so.0()(64bit) libopensync-plugin-synce - 0.22-4.fc8.ppc64 requires libopensync.so.0()(64bit) libpurple-tcl - 2.3.1-1.fc9.ppc64 requires libtk8.4.so()(64bit) libpurple-tcl - 2.3.1-1.fc9.ppc64 requires libtcl8.4.so()(64bit) liferea - 1.4.10-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc64 requires libgtkembedmoz.so()(64bit) magic - 7.4.35-6.fc8.ppc64 requires libtcl8.4.so()(64bit) magic - 7.4.35-6.fc8.ppc64 requires libtk8.4.so()(64bit) mftrace - 1.2.14-2.fc8.ppc64 requires tetex-fonts netgen - 1.3.7-13.fc9.ppc64 requires libtcl8.4.so()(64bit) netgen - 1.3.7-13.fc9.ppc64 requires libtk8.4.so()(64bit) openmsx - 0.6.2-4.fc8.ppc64 requires libtcl8.4.so()(64bit) perl-Test-AutoBuild-darcs - 1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 plplot - 5.8.0-5.fc9.ppc64 requires libtk8.4.so()(64bit) plplot - 5.8.0-5.fc9.ppc64 requires libtcl8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.ppc64 requires libtk8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.ppc64 requires libtcl8.4.so()(64bit) postgresql-pltcl - 8.2.5-2.fc9.ppc64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ppc64 requires libtk8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ppc64 requires libtcl8.4.so()(64bit) python-gammu - 0.22-3.fc8.ppc64 requires libGammu.so.2()(64bit) python-imaging-tk - 1.1.6-4.fc8.ppc64 requires libtk8.4.so()(64bit) python-imaging-tk - 1.1.6-4.fc8.ppc64 requires libtcl8.4.so()(64bit) python-matplotlib-tk - 0.90.1-2.fc8.ppc64 requires libtcl8.4.so()(64bit) python-matplotlib-tk - 0.90.1-2.fc8.ppc64 requires libtk8.4.so()(64bit) q - 7.10-1.fc9.ppc64 requires libtcl8.4.so()(64bit) q - 7.10-1.fc9.ppc64 requires libtk8.4.so()(64bit) qtparted - 0.4.5-15.fc8.ppc64 requires libparted-1.8.so.6()(64bit) ruby-tcltk - 1.8.6.111-4.fc9.ppc64 requires libtk8.4.so()(64bit) ruby-tcltk - 1.8.6.111-4.fc9.ppc64 requires libtcl8.4.so()(64bit) skencil - 0.6.17-15.20070606svn.fc8.ppc64 requires libtcl8.4.so()(64bit) skencil - 0.6.17-15.20070606svn.fc8.ppc64 requires libtk8.4.so()(64bit) tbcload - 1.4-5.20061030cvs.fc8.ppc64 requires tcl(abi) = 0:8.4 tcl-brlapi - 0.5.0-1.fc8.ppc64 requires libtcl8.4.so()(64bit) tcl-tcldict - 8.5.2-2.fc8.ppc64 requires tcl(abi) = 0:8.4 tclcompiler - 1.5-3.20061030cvs.fc8.ppc64 requires tcl(abi) = 0:8.4 tcldom - 3.1-10.fc7.ppc64 requires tcl(abi) = 0:8.4 tclhttpd - 3.5.1-15.fc8.ppc64 requires tcl(abi) = 0:8.4 tetex-font-cm-lgc - 0.5-8.fc6.noarch requires tetex-fonts tetex-font-kerkis - 2.0-13.fc6.noarch requires tetex-fonts tk-tktreectrl - 2.2.3-2.fc8.ppc64 requires tcl(abi) = 0:8.4 tkinter - 2.5.1-18.fc9.ppc64 requires libtk8.4.so()(64bit) tkinter - 2.5.1-18.fc9.ppc64 requires libtcl8.4.so()(64bit) vkeybd - 0.1.17a-5.fc8.ppc64 requires tk < 1:8.5 vkeybd - 0.1.17a-5.fc8.ppc64 requires libtk8.4.so()(64bit) vkeybd - 0.1.17a-5.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) xcircuit - 3.4.27-1.fc9.ppc64 requires libtk8.4.so()(64bit) xcircuit - 3.4.27-1.fc9.ppc64 requires libtcl8.4.so()(64bit) From jonathan.underwood at gmail.com Fri Jan 4 13:20:48 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 4 Jan 2008 13:20:48 +0000 Subject: tetex-fonts replacement? In-Reply-To: <20080104124718.GA5991@localhost.localdomain> References: <20080104124718.GA5991@localhost.localdomain> Message-ID: <645d17210801040520xf13c48ds103efc0cfaa76eb1@mail.gmail.com> On 04/01/2008, Jindrich Novy wrote: > This is caused by texlive and texlive-fonts package merge. The texlive > package contains: > > Obsoletes: texlive-fonts < 2007-6 > Provides: texlive-fonts = 2007-6 > > What should have fixed the missing texlive-fonts by providing it by > the main texlive package. It doesn't work for some reason so will need > to have a look at it. Surely you need Obsoletes: tetex-fonts Provides: tetex-fonts (probably with some versioning) in the texlive-fonts package, rather than what you have above. J. From sgrubb at redhat.com Fri Jan 4 13:58:36 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Fri, 4 Jan 2008 08:58:36 -0500 Subject: Disabling selinux question In-Reply-To: References: <1199399640.3716.65.camel@localhost.localdomain> Message-ID: <200801040858.36273.sgrubb@redhat.com> On Friday 04 January 2008 06:32:27 Linus Walleij wrote: > So every Fedora user must have these (right?): > root 2219 0.0 0.0 12288 684 ? S root 2221 0.0 0.0 12200 708 ? S /sbin/audispd You can turn it off if you want. :) > What else, besides selinux, is using auditd in Fedora right now or in the > immediate future? (Since we're a distribution we don't count theoretical > use cases I hope...) The audit logs are the collection point for all security relevant events from failed logins, to avcs, to raw sockets being opened, to apps that segfault. It collects everything that truly matters regarding security. It also has a simple utility that gives you a quick overview of security events, aureport. For an overview since Sunday, "aureport --start this-week" Regarding the future, I have plans to add IDS/IPS plugin to audispd so that it can spot and react to suspicious events. I also plan to create a prelude plugin that can take events and send them to a prelude manager. The security audit tool that was announced yesterday will send any security issues it discovers to the audit system where it can be reported on. aide also sends a summary description of what it finds to the audit system. If auditd is not running, these events wind up in syslog. Some people do not like all these events cluttering up syslog, so its simpler to just run the audit daemon. Sooner or later people need to research something related to security and the audit system has search and reporting tools. > bash-3.2$ repoquery --whatrequires `repoquery --provides audit` > setroubleshoot-server-0:2.0.0-3.fc9.noarch > audispd-plugins-0:1.6.4-3.fc9.i386 > seedit-0:2.2.0-1.fc9.i386 > amtu-0:1.0.6-1.fc9.i386 > audit-0:1.6.4-3.fc9.i386 > > auditspd-plugins, seedit and amtu are not default-installed, so on a > Fedora default install, SELinux is really the only thing actually using > auditd, am I right? No, *everything* security related goes into the audit logs. > If I read this correctly, we must have auditd running on any Fedora box > everywhere, even without SELinux since: > > * auditspd-plugins may be installed and can monitor remote machines and > wouldn't work without auditd, so the entire network comes into the > picture here and it's hard for the UI to know what the user wants. > > * amtu may be installed, so then it is necessary to have. Technically, amtu needs audit-libs. auditd just ensures amtu events windup in audit logs rather than syslog. auditd should not be required by amtu. > As indeed if the user of system-config-services or anaconda previously > disabled auditd, then installing the amtu or auditspd-plugins RPM will > or should turn the service on again by some %post script or similar, > right? It should not. amtu is happy to send things to audit system which sees that auditd is not running and then forwards events to syslog for disposition. > If this is NOT true, then the user should NOT be allowed to disable auditd > under any circumstances, and shouldn't worry about it using a few KB of > memory, it should have "# hide: true" added to /etc/init.d/auditd > so it's not even shown in s-c-s right? > > There must be one of these things needing to have a bug filed. > > I could easily imagine things like AppArmour, TOMOYO or tripwire (not > even in-kernel!) to use it in theory, though I don't know if they do in > practice, and none of them are in Fedora, so please enlighten me if you > know further use cases. AppArmour does use the audit system. But we do not ship it. We have aide, not tripwire and it is modified. TOMOYO, I'm not familiar with, nor have they contacted me about reserving events. If you search on audit-libs, you will see the real breadth of what uses the audit system. auditdis just the collector, which may or may not be running or installed. All the apps need the audit-libs to send events to the kernel which ultimately sends events to the audit daemon. > Okay! > https://bugzilla.redhat.com/show_bug.cgi?id=427506 > (pending discussion as of whether auditd could actually be disabled too) sigh...the services should exit if selinux is disabled. Its ok for them to start up. -Steve From sundaram at fedoraproject.org Fri Jan 4 13:57:54 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 04 Jan 2008 19:27:54 +0530 Subject: Control center idea In-Reply-To: References: <1199374110.5023.2.camel@frosty> <477D001B.8090203@fedoraproject.org> <1199392493.7512.8.camel@frosty> <477D4784.30000@fedoraproject.org> <1199398175.9971.0.camel@frosty> Message-ID: <477E3B62.2040107@fedoraproject.org> Laith Juwaidah wrote: > I suggested this many times before (probably two times :P), but no one > seamed excited about it, so I abandoned the idea, but now that people > are interested I might work on it... > It'll be a good way to learn python :) > Just one question, anaconda has screens that look like some other > configuration tools (pirut, selinux configuration, root password, etc), > does it kinda call those apps or are they included in it? > Thanks :) It calls the apps. Rahul From rdieter at math.unl.edu Fri Jan 4 14:25:08 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 04 Jan 2008 08:25:08 -0600 Subject: KDE-SIG weekly report (01/2008) References: <200801032134.29594.ml@deadbabylon.de> <200801031306.45787.jbarnes@virtuousgeek.org> Message-ID: Jesse Barnes wrote: > On Thursday, January 03, 2008 12:34 pm Sebastian Vahl wrote: >> - KDE-4.0.0 would propably be shipped without composite support enabled >> by default (which "fixes" the problem with intel graphics) > > Where can I find more info about this problem? Is it really an intel > driver problem or something else? This blog prompted our sig discussion: http://rivolaks.blogspot.com/2008/01/new-year-kwin-and-other-stuff.html -- Rex From enrico.scholz at informatik.tu-chemnitz.de Fri Jan 4 14:41:58 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 04 Jan 2008 15:41:58 +0100 Subject: Disabling selinux question In-Reply-To: <200801040858.36273.sgrubb@redhat.com> (Steve Grubb's message of "Fri, 4 Jan 2008 08:58:36 -0500") References: <1199399640.3716.65.camel@localhost.localdomain> <200801040858.36273.sgrubb@redhat.com> Message-ID: <87bq817ivd.fsf@kosh.bigo.ensc.de> Steve Grubb writes: >> What else, besides selinux, is using auditd in Fedora right now or in >> the immediate future? (Since we're a distribution we don't count >> theoretical use cases I hope...) > > The audit logs are the collection point for all security relevant > events from that's a big problem with auditd: it supports only local logging and logfiles on compromised machines are worthless... As 'auditd' "removes" log messages like AVC errors from normal log sources they are not visible for syslog anymore. Hence, it's better to disable auditd and read the raw data on the remote syslog server. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From ndbecker2 at gmail.com Fri Jan 4 14:44:12 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 04 Jan 2008 09:44:12 -0500 Subject: Why does gdb now give lots of warnings? Message-ID: Here is an example: Starting program: /usr/bin/python warning: Missing the separate debug info file: /usr/lib/debug/.build-id/fa/841219472d35412ad631ad0f0fabb78e5c1957.debug warning: Missing the separate debug info file: /usr/lib/debug/.build-id/e8/abaa654dc4b17b75c06c866898a17ea06f2bcf.debug [Thread debugging using libthread_db enabled] [New process 16964] warning: Missing the separate debug info file: /usr/lib/debug/.build-id/96/c005fcc474ab8b0d1aa41267111de2f0b647b0.debug warning: Missing the separate debug info file: /usr/lib/debug/.build-id/cd/19bdc5e57f1a00b2c7b4d6c6d1e3882d199ef9.debug warning: Missing the separate debug info file: /usr/lib/debug/.build-id/72/0ad477c75be7d7cbc97c0a6f443746dda98341.debug warning: Missing the separate debug info file: /usr/lib/debug/.build-id/ea/5b2fb654311e2dc8beacf2f19c1c6d172ba93d.debug Python 2.5.1 (r251:54863, Oct 30 2007, 13:45:26) [GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2 Type "help", "copyright", "credits" or "license" for more information. [New Thread 46912496361856 (LWP 16964)] warning: Missing the separate debug info file: /usr/lib/debug/.build-id/c2/9e344ac739785880a9e002d775c40d812ce16e.debug warning: Missing the separate debug info file: /usr/lib/debug/.build-id/e0/db9d3ab515cf9c9b43b4aab98441eb0c5834f4.debug warning: Missing the separate debug info file: /usr/lib/debug/.build-id/07/4b927efdfa0dbc5902b22369afae444d4f8c4f.debug From giallu at gmail.com Fri Jan 4 14:45:50 2008 From: giallu at gmail.com (Gianluca Sforna) Date: Fri, 4 Jan 2008 15:45:50 +0100 Subject: rawhide report: 20080104 changes In-Reply-To: <200801041310.m04DAHG8013095@porkchop.devel.redhat.com> References: <200801041310.m04DAHG8013095@porkchop.devel.redhat.com> Message-ID: On Jan 4, 2008 2:10 PM, Build System wrote: > > denyhosts-2.6-8.fc9 > ------------------- > * Thu Jan 03 2008 Jason L Tibbitts III - 2.6-8 > - Include everything under to pick up any egg-info files that I assume there was something there, between "under" and "to"? From aph at redhat.com Fri Jan 4 14:52:11 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 4 Jan 2008 14:52:11 +0000 Subject: Why does gdb now give lots of warnings? In-Reply-To: References: Message-ID: <18302.18459.463805.56859@zebedee.pink> Neal Becker writes: > Here is an example: > > Starting program: /usr/bin/python > > warning: Missing the separate debug info file: /usr/lib/debug/.build-id/fa/841219472d35412ad631ad0f0fabb78e5c1957.debug You haven't installed the -debug packages for the shared libs you've loaded. Telling you this isn't a bug. What *is* a bug, IMO, is that you can't tell which shared libs it's complaining about. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From sgrubb at redhat.com Fri Jan 4 15:00:14 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Fri, 4 Jan 2008 10:00:14 -0500 Subject: Disabling selinux question In-Reply-To: <87bq817ivd.fsf@kosh.bigo.ensc.de> References: <200801040858.36273.sgrubb@redhat.com> <87bq817ivd.fsf@kosh.bigo.ensc.de> Message-ID: <200801041000.14212.sgrubb@redhat.com> On Friday 04 January 2008 09:41:58 Enrico Scholz wrote: > >> What else, besides selinux, is using auditd in Fedora right now or in > >> the immediate future? (Since we're a distribution we don't count > >> theoretical use cases I hope...) > > > > The audit logs are the collection point for all security relevant > > events from > > that's a big problem with auditd: it supports only local logging and > logfiles on compromised machines are worthless... Sure, I agree. There is a plugin for ZOS systems in rawhide that does remote logging for the IBM RACF subsystem. I have also started a plugin that transfers audit events off the machine to a central audit daemon. Its slow going, but the pace of its development should pick up now. > As 'auditd' "removes" log messages like AVC errors from normal log sources > they are not visible for syslog anymore. You can use the syslog plugin to wrap events back to syslog if you want them there as well. Enable it in /etc/audisp/plugins.d/syslog.conf > Hence, it's better to disable auditd and read the raw data on the remote > syslog server. Maybe at this point yes, but it will be changing as the plugins are developed. If you do send events across via syslog, they won't be searchable unless you duplicate a lot of ausearch/aureport from scratch. -Steve From james.antill at redhat.com Fri Jan 4 15:16:40 2008 From: james.antill at redhat.com (James Antill) Date: Fri, 04 Jan 2008 10:16:40 -0500 Subject: Disabling selinux question In-Reply-To: References: <477D651D.2070208@redhat.com> Message-ID: <1199459800.15732.42.camel@code.and.org> On Fri, 2008-01-04 at 12:36 +0100, Linus Walleij wrote: > On Thu, 3 Jan 2008, John Dennis wrote: > > > auditd is the general auditing facility, SELinux messages are just one of the > > possible auditing messages. > > But on a Fedora default install SELinux is the only thing using and > requiring it, right? No, think of it more like a different logging protocol. If you want to get rid of "Yet another daemon" the best method would be to add audit input support to the rsyslogd package. > > setroubleshootd is a diagnostic tool. If SELinux is completely disabled the > > daemon exits if started. > > OK, should it have "# hide: true" in /etc/init.d/setroubleshootd so it > doesn't even turn up in system-config-services? > > > Allowing > > the daemon to decide if it should run or exit is more robust than some > > utility which thinks it knows if something should be chkconfig'ed on or not > > because it will almost certainly get that answer wrong. > > Then all these smart daemons should have "# hide : true" in their > respective /etc/init.d/foo script so avoid being managed by the smart > utility system-config-services, am I right? This means people can't stop the service, why do you want to do that? Nothing "bad" happens if you stop any of these. -- James Antill Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From eparis at redhat.com Fri Jan 4 15:40:44 2008 From: eparis at redhat.com (Eric Paris) Date: Fri, 04 Jan 2008 10:40:44 -0500 Subject: Disabling selinux question In-Reply-To: References: <1199399640.3716.65.camel@localhost.localdomain> Message-ID: <1199461244.3716.75.camel@localhost.localdomain> On Fri, 2008-01-04 at 12:32 +0100, Linus Walleij wrote: > Eric and others, please be patient with me now, because I'm trying to > understand our implicit rationale surrounding the selinux services here, > I'm not ranting. I might very well be uneducated and stupid, but sometimes > (as has been said before) it is useful to take the perspective of a > newcomer to a certain system (or in my case subsystem) and try to > understand why this user has problems with it. Rant away, I've heard enough SELinux rants over the years *smile* I just hope that every rant I hear from now on comes from someone who tried SELinux on F8! > > On Thu, 3 Jan 2008, Eric Paris wrote: > > > selinux uses auditd but they are not at all closely coupled. selinux > > will function fine without auditd and auditd provides all of its > > capabilities without selinux. There is no reason these 2 should be > > coupled together. > > I get it. (Did some homework reading up on auditd here.) > > So every Fedora user must have these (right?): > root 2219 0.0 0.0 12288 684 ? S root 2221 0.0 0.0 12200 708 ? S > What else, besides selinux, is using auditd in Fedora right now or in the > immediate future? (Since we're a distribution we don't count theoretical > use cases I hope...) > > bash-3.2$ repoquery --whatrequires `repoquery --provides audit` > setroubleshoot-server-0:2.0.0-3.fc9.noarch > audispd-plugins-0:1.6.4-3.fc9.i386 > seedit-0:2.2.0-1.fc9.i386 > amtu-0:1.0.6-1.fc9.i386 > audit-0:1.6.4-3.fc9.i386 > you didn't talk about 'audit' the audit subsystem is a freestanding subsystem with lots of capabilities and functionality of its own. By default, without any of those packages installed audit is still going to get messages like user login, segfaulting programs, changes of nics to promiscuous, and other information. Audit can be used free standing to audit events on your system, see man auditctl There is no reason that a user cannot turn auditd off themselves (kernel just reroutes the messages to syslog rather than audit log) but audit still functions and serves a purpose all by itself. My opinion, if you disable SELinux in the installer (or s-c-selinux) it should disable those other programs you mentioned if those programs are not smart enough to not run on their own. (sounds like setroubleshoot and i'm going to guess sealert already are smart enough and anaconda/s-c-* shouldn't bother them...) -Eric From mattdm at mattdm.org Fri Jan 4 15:49:15 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 4 Jan 2008 10:49:15 -0500 Subject: Why does gdb now give lots of warnings? In-Reply-To: <18302.18459.463805.56859@zebedee.pink> References: <18302.18459.463805.56859@zebedee.pink> Message-ID: <20080104154915.GA28635@jadzia.bu.edu> On Fri, Jan 04, 2008 at 02:52:11PM +0000, Andrew Haley wrote: > > warning: Missing the separate debug info file: /usr/lib/debug/.build-id/fa/841219472d35412ad631ad0f0fabb78e5c1957.debug > You haven't installed the -debug packages for the shared libs you've > loaded. Telling you this isn't a bug. > What *is* a bug, IMO, is that you can't tell which shared libs it's > complaining about. I agree that that's annoying, but you can just enable the debuginfo repo and then yum install the given missing filename. Yum will work out which package provides it. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Fri Jan 4 15:57:20 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 4 Jan 2008 10:57:20 -0500 Subject: Why does gdb now give lots of warnings? In-Reply-To: <20080104154915.GA28635@jadzia.bu.edu> References: <18302.18459.463805.56859@zebedee.pink> <20080104154915.GA28635@jadzia.bu.edu> Message-ID: <20080104105720.1f78b9dc@redhat.com> On Fri, 4 Jan 2008 10:49:15 -0500 Matthew Miller wrote: > I agree that that's annoying, but you can just enable the debuginfo > repo and then yum install the given missing filename. Yum will work > out which package provides it. You can also just use debuginfo-install and it will enable the repo for you and track down all the needed debuginfo packages. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jan.kratochvil at redhat.com Fri Jan 4 16:12:01 2008 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Fri, 4 Jan 2008 17:12:01 +0100 Subject: Why does gdb now give lots of warnings? In-Reply-To: <20080104105720.1f78b9dc@redhat.com> References: <18302.18459.463805.56859@zebedee.pink> <20080104154915.GA28635@jadzia.bu.edu> <20080104105720.1f78b9dc@redhat.com> Message-ID: <20080104161201.GA17915@host0.dyn.jankratochvil.net> On Fri, 04 Jan 2008 16:57:20 +0100, Jesse Keating wrote: > On Fri, 4 Jan 2008 10:49:15 -0500 > Matthew Miller wrote: > > > I agree that that's annoying, but you can just enable the debuginfo > > repo and then yum install the given missing filename. Yum will work > > out which package provides it. > > You can also just use debuginfo-install and it will enable > the repo for you and track down all the needed debuginfo packages. $ ls -l /usr/lib/debug/.build-id/fa/841219472d35412ad631ad0f0fabb78e5c1957.debug lrwxrwxrwx 1 root root 27 2007-10-21 15:58 /usr/lib/debug/.build-id/fa/841219472d35412ad631ad0f0fabb78e5c1957.debug -> ../../lib64/ld-2.7.so.debug* tells the name of the already installed library missing its -debuginfo. $ repoquery -qf /usr/lib/debug/.build-id/fa/841219472d35412ad631ad0f0fabb78e5c1957.debug glibc-debuginfo-0:2.7-2.x86_64 tells the -debuginfo package name needing to be installed. # yum install /usr/lib/debug/.build-id/fa/841219472d35412ad631ad0f0fabb78e5c1957.debug installs the missing -debuginfo package. The library name was omitted intentionally there as the printed lines are already too long just to be able to provide the .debug filename required for `yum install'. People commonly try to debug with GDB without having the -debuginfo packages installed so I expected some hint may be useful there. `debuginfo-install ' may not install the matching -debuginfo version, there may be multiple simultaneous -debuginfo versions available and/or installed in the future (F9?). I am open for some more convenient interface - currently going to print also the shared library name there. (GDB cannot print anything about rpms.) Thanks, Jan From wart at kobold.org Fri Jan 4 16:12:51 2008 From: wart at kobold.org (Wart) Date: Fri, 04 Jan 2008 08:12:51 -0800 Subject: New tcl-8.5 and 8Kingdoms In-Reply-To: <477D5C87.2010106@kobold.org> References: <477D5C7F.6050708@hhs.nl> <477D5C87.2010106@kobold.org> Message-ID: <477E5B03.50101@kobold.org> Michael Thomas wrote: > Hans de Goede wrote: >> Hi all, >> >> I just tried building 8Kingdoms with the new tcl in rawhide, it builds >> fine, but it does not work. >> >> Any of the actions (moving a unit for example) which normally invoke a >> tcl script underneath now no longer work. >> >> I'm quite good in fixing C bugs but this problem lies either in the >> interfacing with tcl or in the tcl code itself and I'm helpless there. >> So I hope that someone can try running 8Kingdoms with tcl 8.5, and write >> a fix. >> >> Note I've also send a request upstream asking for help, I'll report back >> here as soon as I get response. >> >> If I don't have it fixed by F-9 then I will have to remove 8Kingdoms >> from Fedora's repositories (better then shipping a broken version). > > Did you have to make any changes to 8Kingdoms to get it to build with > Tcl 8.5? If so please pass along any patches. I'll try building and > running it myself to see if I can track down the problem. I got it built and installed, but X on my Rawhide box is busted at the moment. I'll take another look once it's working again. --Wart From aph at redhat.com Fri Jan 4 16:19:42 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 4 Jan 2008 16:19:42 +0000 Subject: Why does gdb now give lots of warnings? In-Reply-To: <20080104161201.GA17915@host0.dyn.jankratochvil.net> References: <18302.18459.463805.56859@zebedee.pink> <20080104154915.GA28635@jadzia.bu.edu> <20080104105720.1f78b9dc@redhat.com> <20080104161201.GA17915@host0.dyn.jankratochvil.net> Message-ID: <18302.23710.710664.220708@zebedee.pink> Jan Kratochvil writes: > On Fri, 04 Jan 2008 16:57:20 +0100, Jesse Keating wrote: > > On Fri, 4 Jan 2008 10:49:15 -0500 > > Matthew Miller wrote: > > > > > I agree that that's annoying, but you can just enable the debuginfo > > > repo and then yum install the given missing filename. Yum will work > > > out which package provides it. > > > > You can also just use debuginfo-install and it will enable > > the repo for you and track down all the needed debuginfo packages. > > $ ls -l /usr/lib/debug/.build-id/fa/841219472d35412ad631ad0f0fabb78e5c1957.debug > lrwxrwxrwx 1 root root 27 2007-10-21 15:58 /usr/lib/debug/.build-id/fa/841219472d35412ad631ad0f0fabb78e5c1957.debug -> ../../lib64/ld-2.7.so.debug* > tells the name of the already installed library missing its -debuginfo. > > $ repoquery -qf /usr/lib/debug/.build-id/fa/841219472d35412ad631ad0f0fabb78e5c1957.debug > glibc-debuginfo-0:2.7-2.x86_64 > tells the -debuginfo package name needing to be installed. > > # yum install /usr/lib/debug/.build-id/fa/841219472d35412ad631ad0f0fabb78e5c1957.debug > installs the missing -debuginfo package. > > The library name was omitted intentionally there as the printed lines are > already too long just to be able to provide the .debug filename required for > `yum install'. > > People commonly try to debug with GDB without having the -debuginfo packages > installed so I expected some hint may be useful there. > > `debuginfo-install ' may not install the matching -debuginfo version, > there may be multiple simultaneous -debuginfo versions available and/or > installed in the future (F9?). > > I am open for some more convenient interface - currently going to print also > the shared library name there. That would do it. Something really simple like "Missing debuginfo for shared object XXXXglibc.soXXX". > (GDB cannot print anything about rpms.) I'll take your word for that. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From eswierk at arastra.com Fri Jan 4 16:40:55 2008 From: eswierk at arastra.com (Ed Swierk) Date: Fri, 4 Jan 2008 08:40:55 -0800 Subject: Another selinux rant In-Reply-To: <1199434944.3244.7.camel@s1.crocom.com.pl> References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> Message-ID: On 1/4/08, Tomasz Torcz wrote: > tar with "--xattrs"? No, I didn't realize --xattrs existed; the tar info page doesn't mention it. Oh, there it is in the man page. Is there some reason why storing extended attributes by default would be undesirable? I normally expect tar to carry all relevant metadata with it; that's sort of the point of using tar. > SELinux don't care about file location. It cares about labels. Policy > for *labeling* files and assorted utilities care for paths, but they are > only additional utilities, not SELinux itself.. > In your situation, ipp.txt must be writable by openvpn daemon. You can > achieve it by labeling (man chcon) ipp.txt as openvpn_var_log_t. By > default files in /etc/openvpn are labeled as openvpn_etc_t (openvpn's > configuration files). Daemons cannot modify their configuration files. I see. I now notice ls has a -Z option that shows the SELinux security context. It would be nice if ls -l would show the security context by default when SELinux is enabled, as the context is apparently just as important as file permissions. People who already know about SELinux can of course just learn to type ls -l --lcontext, but showing the extra information by default would at least give clueless users like me a hint that files have these extra attributes that might somehow be relevant to those strange openvpn failures. IMHO this would be the single best usability improvement to SELinux (despite the fact that it makes the output too wide for an 80-column display). --Ed From jan.kratochvil at redhat.com Fri Jan 4 16:47:39 2008 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Fri, 4 Jan 2008 17:47:39 +0100 Subject: Why does gdb now give lots of warnings? In-Reply-To: <18302.23710.710664.220708@zebedee.pink> References: <18302.18459.463805.56859@zebedee.pink> <20080104154915.GA28635@jadzia.bu.edu> <20080104105720.1f78b9dc@redhat.com> <20080104161201.GA17915@host0.dyn.jankratochvil.net> <18302.23710.710664.220708@zebedee.pink> Message-ID: <20080104164739.GA18173@host0.dyn.jankratochvil.net> On Fri, 04 Jan 2008 17:19:42 +0100, Andrew Haley wrote: > Jan Kratochvil writes: ... > > I am open for some more convenient interface - currently going to print also > > the shared library name there. > > That would do it. Something really simple like "Missing debuginfo for > shared object XXXXglibc.soXXX". Suggesting this one? Missing debuginfo for shared object ld-linux-x86-64.so.2 There is no easy chance how to install the associated debuginfos using YUM from such messages. And `debuginfo-install ' will not work in all cases - at least not fot dlopen()ed libraries - such as the 'nss*' packages. Printing the rpm Provides keyword would make it already RPM/Fedora specific Missing debuginfo for shared object ld-linux-x86-64.so.2()(64bit) and still deriving the -debuginfo package name from it is not easy enough. Possibly printing warning: Missing the separate debug info file: /usr/lib/debug/lib64/ld-linux-x86-64.so.2.debug may be more convenient while still usable for YUM? It would still print warning: Missing the separate debug info file: /usr/lib/debug/.build-id/fa/841219472d35412ad631ad0f0fabb78e5c1957.debug if the .debug file exists but it is not matching the required version - otherwise that would contradict the purpose of the F8 `build-id' feature http://fedoraproject.org/wiki/Releases/FeatureBuildId > > (GDB cannot print anything about rpms.) > > I'll take your word for that. OK, you are right Fedora GDB could; the build-id support messages should be cross-OS ones, this loading feature is still not imported into upstream GDB and it is heading there. Thanks, Jan From aph at redhat.com Fri Jan 4 16:53:09 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 4 Jan 2008 16:53:09 +0000 Subject: Why does gdb now give lots of warnings? In-Reply-To: <20080104164739.GA18173@host0.dyn.jankratochvil.net> References: <18302.18459.463805.56859@zebedee.pink> <20080104154915.GA28635@jadzia.bu.edu> <20080104105720.1f78b9dc@redhat.com> <20080104161201.GA17915@host0.dyn.jankratochvil.net> <18302.23710.710664.220708@zebedee.pink> <20080104164739.GA18173@host0.dyn.jankratochvil.net> Message-ID: <18302.25717.629111.664840@zebedee.pink> Jan Kratochvil writes: > On Fri, 04 Jan 2008 17:19:42 +0100, Andrew Haley wrote: > > Jan Kratochvil writes: > ... > > > I am open for some more convenient interface - currently going to print also > > > the shared library name there. > > > > That would do it. Something really simple like "Missing debuginfo for > > shared object XXXXglibc.soXXX". > > Suggesting this one? > Missing debuginfo for shared object ld-linux-x86-64.so.2 > > There is no easy chance how to install the associated debuginfos using YUM from > such messages. And `debuginfo-install ' will not work in all cases > - at least not fot dlopen()ed libraries - such as the 'nss*' packages. > > Printing the rpm Provides keyword would make it already RPM/Fedora specific > Missing debuginfo for shared object ld-linux-x86-64.so.2()(64bit) > and still deriving the -debuginfo package name from it is not easy enough. > > > Possibly printing > warning: Missing the separate debug info file: /usr/lib/debug/lib64/ld-linux-x86-64.so.2.debug > may be more convenient while still usable for YUM? > > > It would still print > warning: Missing the separate debug info file: /usr/lib/debug/.build-id/fa/841219472d35412ad631ad0f0fabb78e5c1957.debug > if the .debug file exists but it is not matching the required version > - otherwise that would contradict the purpose of the F8 `build-id' feature > http://fedoraproject.org/wiki/Releases/FeatureBuildId > > > > > (GDB cannot print anything about rpms.) > > > > I'll take your word for that. > > OK, you are right Fedora GDB could; the build-id support messages should be > cross-OS ones, this loading feature is still not imported into upstream GDB and > it is heading there. Sure, but we could have a simple local message like Try "yum install /usr/lib/debug/.build-id/72/67a2ecd318b0f87a0747a6986d0d6dc01c6d8d.debug" I learnt only today that would work... Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From dcbw at redhat.com Fri Jan 4 17:05:03 2008 From: dcbw at redhat.com (Dan Williams) Date: Fri, 04 Jan 2008 12:05:03 -0500 Subject: libnl update to 1.0-pre8 Message-ID: <1199466303.19577.2.camel@localhost.localdomain> Hi, For various reasons (kernel 2.6.24 compatibility, memory leaks, knetworkmanager wants it, etc) I'm going to push libnl 1.0-pre8 to F-8. It's unfortunately got some API/ABI changes the require rebuilds and possibly source patches for packages that link to it. I'm just starting the process of rebuilding the stuff that I own, and the only other user that I could identify via repoquery was dhcp/libdhcp, for which I've coordinated with dcantrell on. Just a heads-up; I don't think anyone besides NetworkManager and libdhcp are affected though. Dan From jdennis at redhat.com Fri Jan 4 17:07:37 2008 From: jdennis at redhat.com (John Dennis) Date: Fri, 04 Jan 2008 12:07:37 -0500 Subject: Another selinux rant In-Reply-To: References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> Message-ID: <477E67D9.1060808@redhat.com> Ed Swierk wrote: > People who already know about SELinux can of course just learn to type > ls -l --lcontext, but showing the extra information by default would > at least give clueless users like me a hint that files have these > extra attributes that might somehow be relevant to those strange > openvpn failures. IMHO this would be the single best usability > improvement to SELinux Re SELinux usability issues: We wrote the setroubleshoot package precisely to help SELinux novice users so they wouldn't suffer with hidden obscure failures of the type which have frustrated you. If it had been installed you would have received notifications in real time on your desktop describing the failure and suggestions on how to fix it. -- John Dennis From jan.kratochvil at redhat.com Fri Jan 4 17:08:07 2008 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Fri, 4 Jan 2008 18:08:07 +0100 Subject: Why does gdb now give lots of warnings? In-Reply-To: <18302.25717.629111.664840@zebedee.pink> References: <18302.18459.463805.56859@zebedee.pink> <20080104154915.GA28635@jadzia.bu.edu> <20080104105720.1f78b9dc@redhat.com> <20080104161201.GA17915@host0.dyn.jankratochvil.net> <18302.23710.710664.220708@zebedee.pink> <20080104164739.GA18173@host0.dyn.jankratochvil.net> <18302.25717.629111.664840@zebedee.pink> Message-ID: <20080104170807.GA19073@host0.dyn.jankratochvil.net> On Fri, 04 Jan 2008 17:53:09 +0100, Andrew Haley wrote: > Jan Kratochvil writes: ... > > OK, you are right Fedora GDB could; the build-id support messages should be > > cross-OS ones, this loading feature is still not imported into upstream GDB and > > it is heading there. > > Sure, but we could have a simple local message like > > Try "yum install /usr/lib/debug/.build-id/72/67a2ecd318b0f87a0747a6986d0d6dc01c6d8d.debug" > > I learnt only today that would work... Such as this one - just for the first such message printed? I guess changing the `Missing ...' message itself would be already too OS-specific. Starting program: /usr/bin/python Try: yum install /usr/lib/debug/.build-id/fa/841219472d35412ad631ad0f0fabb78e5c1957.debug warning: Missing the separate debug info file: /usr/lib/debug/.build-id/fa/841219472d35412ad631ad0f0fabb78e5c1957.debug warning: Missing the separate debug info file: /usr/lib/debug/.build-id/e8/abaa654dc4b17b75c06c866898a17ea06f2bcf.debug [Thread debugging using libthread_db enabled] [New process 16964] warning: Missing the separate debug info file: /usr/lib/debug/.build-id/96/c005fcc474ab8b0d1aa41267111de2f0b647b0.debug warning: Missing the separate debug info file: /usr/lib/debug/.build-id/cd/19bdc5e57f1a00b2c7b4d6c6d1e3882d199ef9.debug warning: Missing the separate debug info file: /usr/lib/debug/.build-id/72/0ad477c75be7d7cbc97c0a6f443746dda98341.debug warning: Missing the separate debug info file: /usr/lib/debug/.build-id/ea/5b2fb654311e2dc8beacf2f19c1c6d172ba93d.debug ... Also removing the empty line (despite it may occasionally start in half of the screen) may help, I guess. Any other messaging feedback is welcome before it goes upstream. Thanks, Jan From aph at redhat.com Fri Jan 4 17:15:00 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 4 Jan 2008 17:15:00 +0000 Subject: Why does gdb now give lots of warnings? In-Reply-To: <20080104170807.GA19073@host0.dyn.jankratochvil.net> References: <18302.18459.463805.56859@zebedee.pink> <20080104154915.GA28635@jadzia.bu.edu> <20080104105720.1f78b9dc@redhat.com> <20080104161201.GA17915@host0.dyn.jankratochvil.net> <18302.23710.710664.220708@zebedee.pink> <20080104164739.GA18173@host0.dyn.jankratochvil.net> <18302.25717.629111.664840@zebedee.pink> <20080104170807.GA19073@host0.dyn.jankratochvil.net> Message-ID: <18302.27028.83536.638113@zebedee.pink> Jan Kratochvil writes: > On Fri, 04 Jan 2008 17:53:09 +0100, Andrew Haley wrote: > > Jan Kratochvil writes: > ... > > > OK, you are right Fedora GDB could; the build-id support messages should be > > > cross-OS ones, this loading feature is still not imported into upstream GDB and > > > it is heading there. > > > > Sure, but we could have a simple local message like > > > > Try "yum install /usr/lib/debug/.build-id/72/67a2ecd318b0f87a0747a6986d0d6dc01c6d8d.debug" > > > > I learnt only today that would work... > > Such as this one - just for the first such message printed? I guess changing > the `Missing ...' message itself would be already too OS-specific. Perfection would be: Missing debuginfo for /lib64/libnss_files-2.7.so Try "yum install /usr/lib/debug/.build-id/72/67a2ecd318b0f87a0747a6986d0d6dc01c6d8d.debug" If we can't do that upstream, then the closer we get, the better. Or we have a local patch. > Starting program: /usr/bin/python > > Try: yum install /usr/lib/debug/.build-id/fa/841219472d35412ad631ad0f0fabb78e5c1957.debug > warning: Missing the separate debug info file: /usr/lib/debug/.build-id/fa/841219472d35412ad631ad0f0fabb78e5c1957.debug > > warning: Missing the separate debug info file: /usr/lib/debug/.build-id/e8/abaa654dc4b17b75c06c866898a17ea06f2bcf.debug > [Thread debugging using libthread_db enabled] > [New process 16964] > > warning: Missing the separate debug info file: /usr/lib/debug/.build-id/96/c005fcc474ab8b0d1aa41267111de2f0b647b0.debug > > warning: Missing the separate debug info file: /usr/lib/debug/.build-id/cd/19bdc5e57f1a00b2c7b4d6c6d1e3882d199ef9.debug > > warning: Missing the separate debug info file: /usr/lib/debug/.build-id/72/0ad477c75be7d7cbc97c0a6f443746dda98341.debug > > warning: Missing the separate debug info file: /usr/lib/debug/.build-id/ea/5b2fb654311e2dc8beacf2f19c1c6d172ba93d.debug > > ... > > > Also removing the empty line (despite it may occasionally start in half of the > screen) may help, I guess. It would. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From dennis at ausil.us Fri Jan 4 17:15:01 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 4 Jan 2008 11:15:01 -0600 Subject: libnl update to 1.0-pre8 In-Reply-To: <1199466303.19577.2.camel@localhost.localdomain> References: <1199466303.19577.2.camel@localhost.localdomain> Message-ID: <200801041115.05112.dennis@ausil.us> On Friday 04 January 2008 11:05:03 am Dan Williams wrote: > Hi, > > For various reasons (kernel 2.6.24 compatibility, memory leaks, > knetworkmanager wants it, etc) I'm going to push libnl 1.0-pre8 to F-8. > It's unfortunately got some API/ABI changes the require rebuilds and > possibly source patches for packages that link to it. I'm just starting > the process of rebuilding the stuff that I own, and the only other user > that I could identify via repoquery was dhcp/libdhcp, for which I've > coordinated with dcantrell on. Just a heads-up; I don't think anyone > besides NetworkManager and libdhcp are affected though. > > Dan Dan, knetworkmanger needs a libnl update in F-7 not F-8 there is still no knetworkmanager for F-8 last i heard it was somewhat working but the maintainer ported to a different set of dbus bindings. Dennis From eswierk at arastra.com Fri Jan 4 17:19:03 2008 From: eswierk at arastra.com (Ed Swierk) Date: Fri, 4 Jan 2008 09:19:03 -0800 Subject: Another selinux rant In-Reply-To: <477DA271.6070208@gmail.com> References: <477D9178.6090709@gmail.com> <477DA271.6070208@gmail.com> Message-ID: On 1/3/08, Andrew Farris wrote: > Ok I understand then, however I'd just comment that as a gauge of usability I > think your situation (moving configurations across platforms, from no selinux to > selinux) is somewhat of a fringe case. I realize that MANY admins would be > doing just that in the process of adopting selinux since rewriting > configurations is a major pain, but its still something that can almost be > expected to cause headache (and requires labeling). Just my 2c on usability, it > still seems to work best when you start out from install with selinux enabled > and avoid deliberately circumventing it. Believe me, as an engineer I understand how annoying it is to learn that a user has given up in frustration after 10 minutes just because they ran into trivial issue like a bug in the installer. Unfortunately the most luxuriously smooth freeway in the world will lie unused if the on-ramps are full of land mines. :-) > Would you say that documentation on that specific issue (migrating > configurations) needs more attention? I think improving error messages and warnings and default behavior (see my earlier comments on tar and ls) is more worthwhile than writing documentation, as the latter tends not to get read. --Ed From james.antill at redhat.com Fri Jan 4 17:24:24 2008 From: james.antill at redhat.com (James Antill) Date: Fri, 04 Jan 2008 12:24:24 -0500 Subject: Another selinux rant In-Reply-To: References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> Message-ID: <1199467464.23051.4.camel@code.and.org> On Fri, 2008-01-04 at 08:40 -0800, Ed Swierk wrote: > On 1/4/08, Tomasz Torcz wrote: > > tar with "--xattrs"? > > No, I didn't realize --xattrs existed; the tar info page doesn't > mention it. Oh, there it is in the man page. If I do "info tar" on Fed-8 the second hit for a search on "selinux" gives the --selinux option and the --xattrs option is visible just below it (--xattrs includes --selinux). > Is there some reason why storing extended attributes by default would > be undesirable? I normally expect tar to carry all relevant metadata > with it; that's sort of the point of using tar. Well we didn't want to do this until the patch for xattrs/ACLs/SELinux is upstream as it changes the default tar format and GNU tars without the patch will display a bunch of annoying warnings. Esp. given how much tar is used to distribute software, where perms/xattrs aren't really wanted. -- James Antill Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From eswierk at arastra.com Fri Jan 4 17:26:47 2008 From: eswierk at arastra.com (Ed Swierk) Date: Fri, 4 Jan 2008 09:26:47 -0800 Subject: Another selinux rant In-Reply-To: <477E67D9.1060808@redhat.com> References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> Message-ID: On 1/4/08, John Dennis wrote: > Re SELinux usability issues: > > We wrote the setroubleshoot package precisely to help SELinux novice > users so they wouldn't suffer with hidden obscure failures of the type > which have frustrated you. If it had been installed you would have > received notifications in real time on your desktop describing the > failure and suggestions on how to fix it. The machine in question is a server with no graphical applications; is there a command-line version of setroubleshoot? --Ed From jan.kratochvil at redhat.com Fri Jan 4 17:31:49 2008 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Fri, 4 Jan 2008 18:31:49 +0100 Subject: Why does gdb now give lots of warnings? In-Reply-To: <18302.27028.83536.638113@zebedee.pink> References: <18302.18459.463805.56859@zebedee.pink> <20080104154915.GA28635@jadzia.bu.edu> <20080104105720.1f78b9dc@redhat.com> <20080104161201.GA17915@host0.dyn.jankratochvil.net> <18302.23710.710664.220708@zebedee.pink> <20080104164739.GA18173@host0.dyn.jankratochvil.net> <18302.25717.629111.664840@zebedee.pink> <20080104170807.GA19073@host0.dyn.jankratochvil.net> <18302.27028.83536.638113@zebedee.pink> Message-ID: <20080104173149.GA19613@host0.dyn.jankratochvil.net> On Fri, 04 Jan 2008 18:15:00 +0100, Andrew Haley wrote: ... > Perfection would be: > > Missing debuginfo for /lib64/libnss_files-2.7.so > Try "yum install /usr/lib/debug/.build-id/72/67a2ecd318b0f87a0747a6986d0d6dc01c6d8d.debug" Such two-line message for each such missing file? OK. > If we can't do that upstream, then the closer we get, the better. Or > we have a local patch. Sure `yum install' is not acceptable upstream. Local patch changing the wording a bit would be fine (configure.in detection of each specific OS/installing-tool is IMO not appropriate upstream). Accepted, F8/F9 update should be fine. Thanks, Jan From ljuwaida at fedoraproject.org Fri Jan 4 17:34:56 2008 From: ljuwaida at fedoraproject.org (Laith Juwaidah) Date: Fri, 4 Jan 2008 21:34:56 +0400 Subject: Control center idea In-Reply-To: <477E3B62.2040107@fedoraproject.org> References: <1199374110.5023.2.camel@frosty> <477E3B62.2040107@fedoraproject.org> Message-ID: <200801042134.57972.ljuwaida@fedoraproject.org> I knew it! Problem solved then, we can make a program that doesn't go through the applications as steps (like anaconda does), instead it allows the user to choose from, say, a narrow menu on the left and shows the apps in the remaining area of the window... What do you think of that? On Friday 04 January 2008 17:57:54 Rahul Sundaram wrote: > Laith Juwaidah wrote: > > I suggested this many times before (probably two times :P), but no one > > seamed excited about it, so I abandoned the idea, but now that people > > are interested I might work on it... > > It'll be a good way to learn python :) > > Just one question, anaconda has screens that look like some other > > configuration tools (pirut, selinux configuration, root password, etc), > > does it kinda call those apps or are they included in it? > > Thanks :) > > It calls the apps. > > Rahul -- Laith Juwaidah http://www.ljuwaidah.org/ From eswierk at arastra.com Fri Jan 4 17:41:24 2008 From: eswierk at arastra.com (Ed Swierk) Date: Fri, 4 Jan 2008 09:41:24 -0800 Subject: Another selinux rant In-Reply-To: <1199467464.23051.4.camel@code.and.org> References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <1199467464.23051.4.camel@code.and.org> Message-ID: On 1/4/08, James Antill wrote: > If I do "info tar" on Fed-8 the second hit for a search on "selinux" > gives the --selinux option and the --xattrs option is visible just below > it (--xattrs includes --selinux). Oh, I see. I was looking in the "All tar options" section (3.4). --Ed From pemboa at gmail.com Fri Jan 4 17:49:22 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 4 Jan 2008 11:49:22 -0600 Subject: Another selinux rant In-Reply-To: References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> Message-ID: <16de708d0801040949i63812216h8ec7909ab47477cb@mail.gmail.com> On Jan 4, 2008 11:26 AM, Ed Swierk wrote: > On 1/4/08, John Dennis wrote: > > Re SELinux usability issues: > > > > We wrote the setroubleshoot package precisely to help SELinux novice > > users so they wouldn't suffer with hidden obscure failures of the type > > which have frustrated you. If it had been installed you would have > > received notifications in real time on your desktop describing the > > failure and suggestions on how to fix it. > > The machine in question is a server with no graphical applications; is > there a command-line version of setroubleshoot? One would hope you would have installed it by now. There is a very nice command-line usage of setroubleshoot. I have never used the UI myself. Frankly, I don't know how you've been using SELinux without setroubleshoot. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From tibbs at math.uh.edu Fri Jan 4 17:54:30 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 04 Jan 2008 11:54:30 -0600 Subject: rawhide report: 20080104 changes In-Reply-To: References: <200801041310.m04DAHG8013095@porkchop.devel.redhat.com> Message-ID: >>>>> "GS" == Gianluca Sforna writes: GS> I assume there was something there, between "under" and "to"? Yeah, an unescaped '%' in %changelog. Already fixed but I don't see any reason to push a new build for it right now. - J< From tromey at redhat.com Fri Jan 4 17:26:17 2008 From: tromey at redhat.com (Tom Tromey) Date: Fri, 04 Jan 2008 10:26:17 -0700 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <477E2CF1.9040109@hhs.nl> (Hans de Goede's message of "Fri\, 04 Jan 2008 13\:56\:17 +0100") References: <20080103120242.GZ20451@devserv.devel.redhat.com> <477CF8E3.6050907@hhs.nl> <1199429926.5278.38.camel@hinge.endoframe.net> <477E06DA.3070302@hhs.nl> <20080104113228.GL20451@devserv.devel.redhat.com> <477E2CF1.9040109@hhs.nl> Message-ID: >>>>> "Hans" == Hans de Goede writes: Hans> I for one consider this a bug of C++, but I guess arguing about this Hans> is useless, so I'll just go and patch alleggl to fix this. Yeah, I think this is the kind of thing that has to be addressed by the C++ committee. This particular difference does seem gratuitous, but the trend for gcc in general has been to avoid random language extensions as much as possible; you could try filing a feature request for this, but my guess is that it would be rejected. Tom From lesmikesell at gmail.com Fri Jan 4 17:59:02 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 04 Jan 2008 11:59:02 -0600 Subject: Control center idea In-Reply-To: <200801042134.57972.ljuwaida@fedoraproject.org> References: <1199374110.5023.2.camel@frosty> <477E3B62.2040107@fedoraproject.org> <200801042134.57972.ljuwaida@fedoraproject.org> Message-ID: <477E73E6.6030700@gmail.com> Laith Juwaidah wrote: > I knew it! Problem solved then, we can make a program that doesn't go through > the applications as steps (like anaconda does), instead it allows the user to > choose from, say, a narrow menu on the left and shows the apps in the > remaining area of the window... > > What do you think of that? When I think of 'control center', I think of something that can be run over a network to control many machine remotely. Assuming the network is up, would this work reasonably well over ssh from a central machine? Would it identify itself in the window if you open many of them at once? -- Les Mikesell lesmikesell at gmail.com From eswierk at arastra.com Fri Jan 4 18:01:02 2008 From: eswierk at arastra.com (Ed Swierk) Date: Fri, 4 Jan 2008 10:01:02 -0800 Subject: Another selinux rant In-Reply-To: <16de708d0801040949i63812216h8ec7909ab47477cb@mail.gmail.com> References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <16de708d0801040949i63812216h8ec7909ab47477cb@mail.gmail.com> Message-ID: On 1/4/08, Arthur Pemberton wrote: > One would hope you would have installed it by now. There is a very > nice command-line usage of setroubleshoot. I have never used the UI > myself. Frankly, I don't know how you've been using SELinux without > setroubleshoot. It wasn't installed by default and I don't know how I should have known to look for it (again, the audit log messages don't even mention SELinux). If this is considered a key part of SELinux then Anaconda shouldn't enable SELinux without it. I assumed it was graphics-only because yum wants to drag in all sorts of gnome and gtk2-related packages when I install it. --Ed From sgrubb at redhat.com Fri Jan 4 18:01:49 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Fri, 4 Jan 2008 13:01:49 -0500 Subject: Another selinux rant In-Reply-To: <1199467464.23051.4.camel@code.and.org> References: <1199467464.23051.4.camel@code.and.org> Message-ID: <200801041301.49517.sgrubb@redhat.com> On Friday 04 January 2008 12:24:24 James Antill wrote: > > Is there some reason why storing extended attributes by default would > > be undesirable? I normally expect tar to carry all relevant metadata > > with it; that's sort of the point of using tar. > > ?Well we didn't want to do this until the patch for xattrs/ACLs/SELinux > is upstream as it changes the default tar format and GNU tars without > the patch will display a bunch of annoying warnings. And furthermore...if you tar a directory up on Fedora 8 and untar it on OpenBSD machine...its not going to know what to do with the extended attributes for SE Linux. Since open source software is used across many platforms, its wasteful to turn it on by default. -Steve From jdennis at redhat.com Fri Jan 4 18:04:25 2008 From: jdennis at redhat.com (John Dennis) Date: Fri, 04 Jan 2008 13:04:25 -0500 Subject: Another selinux rant In-Reply-To: References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> Message-ID: <477E7529.6000409@redhat.com> Ed Swierk wrote: > On 1/4/08, John Dennis wrote: >> Re SELinux usability issues: >> >> We wrote the setroubleshoot package precisely to help SELinux novice >> users so they wouldn't suffer with hidden obscure failures of the type >> which have frustrated you. If it had been installed you would have >> received notifications in real time on your desktop describing the >> failure and suggestions on how to fix it. > > The machine in question is a server with no graphical applications; is > there a command-line version of setroubleshoot? Yes, setroubleshoot-server. You have two options for receiving the alerts from the headless server. You can either run the gui on a machine with a head and point it at the headless server (requires modifying the config file to use TCP rather than the default Unix domain sockets). On the headless server edit /etc/setroubleshoot/setroubleshoot.cfg and in the listen_for_client section set the address_list parameter to {inet}server.ip.addr. Then on the GUI system do the same thing except set the address_list in the client_connect_to section. -OR- You can choose to have the headless server send you emails with the alert by editing the file /var/lib/setroubleshoot/email_alert_recipients and adding a line like this: user at example.com filter_type=after_first The filter_type specifies whether to filter the email alert, the 3 possible values are: after_first filter the email after the first notification always always filter, thus never send an email alert never never filter, thus always send an email alert -- John Dennis From jspaleta at gmail.com Fri Jan 4 18:06:18 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 4 Jan 2008 09:06:18 -0900 Subject: howto package openoffice.org extensions In-Reply-To: <1199451768.7355.201.camel@Jehannum> References: <1199451768.7355.201.camel@Jehannum> Message-ID: <604aa7910801041006r3cacf550i149948f4e5bbf64a@mail.gmail.com> On Jan 4, 2008 4:02 AM, Caolan McNamara wrote: > I've added a little bit to http://fedoraproject.org/wiki/OpenOffice.org > to document the best recipe for installing and deinstalling > openoffice.org extensions to avoid some gotchas. The example taken is > that of writer2latex and also shows the (submitted upstream) enhancement > to register an extension by linking to an the unzipped package to avoid > the vanilla behaviour of copying the package during installation. that's great guidance. can we work this into the packaging guidelines as a special case? http://fedoraproject.org/wiki/Packaging/Guidelines Section 40: Application Specific Guidelines From sundaram at fedoraproject.org Fri Jan 4 17:59:44 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 04 Jan 2008 23:29:44 +0530 Subject: Control center idea In-Reply-To: <200801042134.57972.ljuwaida@fedoraproject.org> References: <1199374110.5023.2.camel@frosty> <477E3B62.2040107@fedoraproject.org> <200801042134.57972.ljuwaida@fedoraproject.org> Message-ID: <477E7410.9030703@fedoraproject.org> Laith Juwaidah wrote: > I knew it! Problem solved then, we can make a program that doesn't go through > the applications as steps (like anaconda does), instead it allows the user to > choose from, say, a narrow menu on the left and shows the apps in the > remaining area of the window... > > What do you think of that? I have already pointed out this to you and earlier in this thread that system-config-control does something like this. So if you want this, I would suggest you take over maintenance of that and update it. In case you missed it, it is available for download at http://www.indianoss.org/modules/wfdownloads/viewcat.php?cid=10 Rahul From pemboa at gmail.com Fri Jan 4 18:11:19 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 4 Jan 2008 12:11:19 -0600 Subject: Another selinux rant In-Reply-To: References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <16de708d0801040949i63812216h8ec7909ab47477cb@mail.gmail.com> Message-ID: <16de708d0801041011l2a47872cu76bd3e4361241d1c@mail.gmail.com> On Jan 4, 2008 12:01 PM, Ed Swierk wrote: > On 1/4/08, Arthur Pemberton wrote: > > One would hope you would have installed it by now. There is a very > > nice command-line usage of setroubleshoot. I have never used the UI > > myself. Frankly, I don't know how you've been using SELinux without > > setroubleshoot. > > It wasn't installed by default and I don't know how I should have > known to look for it (again, the audit log messages don't even mention > SELinux). If this is considered a key part of SELinux then Anaconda > shouldn't enable SELinux without it. Well it's a key component to managing SELinux, it doesn't actually help SELinux to work. > I assumed it was graphics-only because yum wants to drag in all sorts > of gnome and gtk2-related packages when I install it. Yah. I'm not fond of how it is packaged myself... but since I can't do better, i don't complain about it... it really does drag in too much stuff however. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From dcbw at redhat.com Fri Jan 4 18:11:40 2008 From: dcbw at redhat.com (Dan Williams) Date: Fri, 04 Jan 2008 13:11:40 -0500 Subject: libnl update to 1.0-pre8 In-Reply-To: <200801041115.05112.dennis@ausil.us> References: <1199466303.19577.2.camel@localhost.localdomain> <200801041115.05112.dennis@ausil.us> Message-ID: <1199470300.32138.5.camel@localhost.localdomain> On Fri, 2008-01-04 at 11:15 -0600, Dennis Gilmore wrote: > On Friday 04 January 2008 11:05:03 am Dan Williams wrote: > > Hi, > > > > For various reasons (kernel 2.6.24 compatibility, memory leaks, > > knetworkmanager wants it, etc) I'm going to push libnl 1.0-pre8 to F-8. > > It's unfortunately got some API/ABI changes the require rebuilds and > > possibly source patches for packages that link to it. I'm just starting > > the process of rebuilding the stuff that I own, and the only other user > > that I could identify via repoquery was dhcp/libdhcp, for which I've > > coordinated with dcantrell on. Just a heads-up; I don't think anyone > > besides NetworkManager and libdhcp are affected though. > > > > Dan > > Dan, > > knetworkmanger needs a libnl update in F-7 not F-8 there is still no > knetworkmanager for F-8 last i heard it was somewhat working but the > maintainer ported to a different set of dbus bindings. Yeah, the problem on F-7 is that NetworkManager uses netlink to get wireless scan events and connect/disconnect events too. libnl doesn't implement those yet, and may not, so we run into the same problem as before: if we connect to netlink both manually and with NM, we run the risk of netlink PID collision, but libnl-1.0-pre8 doesn't make it easy to fix that unless you use libnl exclusively. It might be possible to use the libnl low-level send/recv APIs to get these messages and parse them manually like NM is already doing. It might also be possible to add a custom WEXT event handler to libnl. Or hack around libnl in F-7 by making NM pick a randomized netlink PID and hoping it and libnl don't collide. Thoughts? Last one is easiest. Dan From jdennis at redhat.com Fri Jan 4 18:13:22 2008 From: jdennis at redhat.com (John Dennis) Date: Fri, 04 Jan 2008 13:13:22 -0500 Subject: Another selinux rant In-Reply-To: <477E7529.6000409@redhat.com> References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <477E7529.6000409@redhat.com> Message-ID: <477E7742.8000005@redhat.com> John Dennis wrote: > You have two options for receiving the alerts from the headless server. Oh, forgot to mention, those will get you realtime alert sent to you. But you can use sealert in command line mode too. The alert will be logged to syslog with an ID, then you can: % sealert -l ID -or- You can scan the audit log file (or any other log file) with: % sealert -a logfile -- John Dennis From sundaram at fedoraproject.org Fri Jan 4 18:03:56 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 04 Jan 2008 23:33:56 +0530 Subject: Another selinux rant In-Reply-To: <16de708d0801041011l2a47872cu76bd3e4361241d1c@mail.gmail.com> References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <16de708d0801040949i63812216h8ec7909ab47477cb@mail.gmail.com> <16de708d0801041011l2a47872cu76bd3e4361241d1c@mail.gmail.com> Message-ID: <477E750C.4010704@fedoraproject.org> Arthur Pemberton wrote: > > Yah. I'm not fond of how it is packaged myself... but since I can't do > better, i don't complain about it... it really does drag in too much > stuff however. Complaining in bugzilla would be a useful contribution. Rahul From jdennis at redhat.com Fri Jan 4 18:17:56 2008 From: jdennis at redhat.com (John Dennis) Date: Fri, 04 Jan 2008 13:17:56 -0500 Subject: Another selinux rant In-Reply-To: <16de708d0801041011l2a47872cu76bd3e4361241d1c@mail.gmail.com> References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <16de708d0801040949i63812216h8ec7909ab47477cb@mail.gmail.com> <16de708d0801041011l2a47872cu76bd3e4361241d1c@mail.gmail.com> Message-ID: <477E7854.8030703@redhat.com> Arthur Pemberton wrote: > Yah. I'm not fond of how it is packaged myself... but since I can't do > better, i don't complain about it... it really does drag in too much > stuff however. That's why setroubleshoot-server is a separate package, so it doesn't drag in all the other cruft the GUI needs. -- John Dennis From james.antill at redhat.com Fri Jan 4 18:27:07 2008 From: james.antill at redhat.com (James Antill) Date: Fri, 04 Jan 2008 13:27:07 -0500 Subject: Why does gdb now give lots of warnings? In-Reply-To: <18302.27028.83536.638113@zebedee.pink> References: <18302.18459.463805.56859@zebedee.pink> <20080104154915.GA28635@jadzia.bu.edu> <20080104105720.1f78b9dc@redhat.com> <20080104161201.GA17915@host0.dyn.jankratochvil.net> <18302.23710.710664.220708@zebedee.pink> <20080104164739.GA18173@host0.dyn.jankratochvil.net> <18302.25717.629111.664840@zebedee.pink> <20080104170807.GA19073@host0.dyn.jankratochvil.net> <18302.27028.83536.638113@zebedee.pink> Message-ID: <1199471227.23051.12.camel@code.and.org> On Fri, 2008-01-04 at 17:15 +0000, Andrew Haley wrote: > Jan Kratochvil writes: > > On Fri, 04 Jan 2008 17:53:09 +0100, Andrew Haley wrote: > > > Jan Kratochvil writes: > > ... > > > > OK, you are right Fedora GDB could; the build-id support messages should be > > > > cross-OS ones, this loading feature is still not imported into upstream GDB and > > > > it is heading there. > > > > > > Sure, but we could have a simple local message like > > > > > > Try "yum install /usr/lib/debug/.build-id/72/67a2ecd318b0f87a0747a6986d0d6dc01c6d8d.debug" > > > > > > I learnt only today that would work... > > > > Such as this one - just for the first such message printed? I guess changing > > the `Missing ...' message itself would be already too OS-specific. > > Perfection would be: > > Missing debuginfo for /lib64/libnss_files-2.7.so > Try "yum install /usr/lib/debug/.build-id/72/67a2ecd318b0f87a0747a6986d0d6dc01c6d8d.debug" > > If we can't do that upstream, then the closer we get, the better. Or > we have a local patch. Well what we really want here is: Try "debuginfo-install glibc" (or "debuginfo-install python" if they are running gdb on that), but that requires some kind of integration with rpm or yum. -- James Antill Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pemboa at gmail.com Fri Jan 4 18:32:15 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 4 Jan 2008 12:32:15 -0600 Subject: Another selinux rant In-Reply-To: <477E750C.4010704@fedoraproject.org> References: <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <16de708d0801040949i63812216h8ec7909ab47477cb@mail.gmail.com> <16de708d0801041011l2a47872cu76bd3e4361241d1c@mail.gmail.com> <477E750C.4010704@fedoraproject.org> Message-ID: <16de708d0801041032j286bbf62i2c3aed68c3956648@mail.gmail.com> On Jan 4, 2008 12:03 PM, Rahul Sundaram wrote: > Arthur Pemberton wrote: > > > > Yah. I'm not fond of how it is packaged myself... but since I can't do > > better, i don't complain about it... it really does drag in too much > > stuff however. > > Complaining in bugzilla would be a useful contribution. Not a big enough deal. I'm not pulling my weight enough to be nitpicking about a few more files. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From pemboa at gmail.com Fri Jan 4 18:32:35 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 4 Jan 2008 12:32:35 -0600 Subject: Another selinux rant In-Reply-To: <477E7854.8030703@redhat.com> References: <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <16de708d0801040949i63812216h8ec7909ab47477cb@mail.gmail.com> <16de708d0801041011l2a47872cu76bd3e4361241d1c@mail.gmail.com> <477E7854.8030703@redhat.com> Message-ID: <16de708d0801041032v158193a0q69d297edce4114b@mail.gmail.com> On Jan 4, 2008 12:17 PM, John Dennis wrote: > Arthur Pemberton wrote: > > Yah. I'm not fond of how it is packaged myself... but since I can't do > > better, i don't complain about it... it really does drag in too much > > stuff however. > > That's why setroubleshoot-server is a separate package, so it doesn't > drag in all the other cruft the GUI needs. That's the point I was trying to make. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From selinux at gmail.com Fri Jan 4 18:45:04 2008 From: selinux at gmail.com (Tom London) Date: Fri, 4 Jan 2008 10:45:04 -0800 Subject: Why does gdb now give lots of warnings? In-Reply-To: <1199471227.23051.12.camel@code.and.org> References: <20080104154915.GA28635@jadzia.bu.edu> <20080104105720.1f78b9dc@redhat.com> <20080104161201.GA17915@host0.dyn.jankratochvil.net> <18302.23710.710664.220708@zebedee.pink> <20080104164739.GA18173@host0.dyn.jankratochvil.net> <18302.25717.629111.664840@zebedee.pink> <20080104170807.GA19073@host0.dyn.jankratochvil.net> <18302.27028.83536.638113@zebedee.pink> <1199471227.23051.12.camel@code.and.org> Message-ID: <4c4ba1530801041045y59d47210t63192b2e20f05b11@mail.gmail.com> On Jan 4, 2008 10:27 AM, James Antill wrote: > > On Fri, 2008-01-04 at 17:15 +0000, Andrew Haley wrote: > > Jan Kratochvil writes: > > > On Fri, 04 Jan 2008 17:53:09 +0100, Andrew Haley wrote: > > > > Jan Kratochvil writes: > > > ... > > > > > OK, you are right Fedora GDB could; the build-id support messages should be > > > > > cross-OS ones, this loading feature is still not imported into upstream GDB and > > > > > it is heading there. > > > > > > > > Sure, but we could have a simple local message like > > > > > > > > Try "yum install /usr/lib/debug/.build-id/72/67a2ecd318b0f87a0747a6986d0d6dc01c6d8d.debug" > > > > > > > > I learnt only today that would work... > > > > > > Such as this one - just for the first such message printed? I guess changing > > > the `Missing ...' message itself would be already too OS-specific. > > > > Perfection would be: > > > > Missing debuginfo for /lib64/libnss_files-2.7.so > > Try "yum install /usr/lib/debug/.build-id/72/67a2ecd318b0f87a0747a6986d0d6dc01c6d8d.debug" > > > > If we can't do that upstream, then the closer we get, the better. Or > > we have a local patch. > > Well what we really want here is: > > Try "debuginfo-install glibc" (or "debuginfo-install python" if they > are running gdb on that), but that requires some kind of integration > with rpm or yum. > Interesting..... I tried 'debuginfo-install rhythmbox' and got a list of 43 packages..... cool. However, it looks like it wants to install 3 'real' packages: Installing: GConf2-debuginfo i386 2.20.1-4.fc9 development-debuginfo 553 k ORBit2-debuginfo i386 2.14.10-2.fc8 development-debuginfo 838 k <<<<>>>> Installing for dependencies: avahi-gobject i386 0.6.22-4.fc9 development 26 k avahi-qt3 i386 0.6.22-4.fc9 development 19 k minizip i386 1.2.3-16.fc9 development 23 k That seems strange to me. Is that to be expected? tom -- Tom London From jbarnes at virtuousgeek.org Fri Jan 4 18:51:39 2008 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Fri, 4 Jan 2008 10:51:39 -0800 Subject: KDE-SIG weekly report (01/2008) In-Reply-To: References: <200801032134.29594.ml@deadbabylon.de> <200801031306.45787.jbarnes@virtuousgeek.org> Message-ID: <200801041051.39706.jbarnes@virtuousgeek.org> On Friday, January 04, 2008 6:25 Rex Dieter wrote: > Jesse Barnes wrote: > > On Thursday, January 03, 2008 12:34 pm Sebastian Vahl wrote: > >> - KDE-4.0.0 would propably be shipped without composite support > >> enabled by default (which "fixes" the problem with intel graphics) > > > > Where can I find more info about this problem? Is it really an > > intel driver problem or something else? > > This blog prompted our sig discussion: > http://rivolaks.blogspot.com/2008/01/new-year-kwin-and-other-stuff.ht >ml That looks like a general discussion of whether it should be off by default or not (sounds like it should be). AFAIK the only problem with Intel & compositing is that it's not well supported if you're using XAA (Xv and other features won't work). Unfortunately, we have some EXA performance problems, so in some configurations the alternative isn't very palatable either (though this should be fixed soon). Jesse From ljuwaida at fedoraproject.org Fri Jan 4 18:54:08 2008 From: ljuwaida at fedoraproject.org (Laith Juwaidah) Date: Fri, 4 Jan 2008 22:54:08 +0400 Subject: Control center idea In-Reply-To: <477E7410.9030703@fedoraproject.org> References: <1199374110.5023.2.camel@frosty> <200801042134.57972.ljuwaida@fedoraproject.org> <477E7410.9030703@fedoraproject.org> Message-ID: <200801042254.10646.ljuwaida@fedoraproject.org> On Friday 04 January 2008 21:59:44 Rahul Sundaram wrote: > Laith Juwaidah wrote: > > I knew it! Problem solved then, we can make a program that doesn't go > > through the applications as steps (like anaconda does), instead it allows > > the user to choose from, say, a narrow menu on the left and shows the > > apps in the remaining area of the window... > > > > What do you think of that? > > I have already pointed out this to you and earlier in this thread that > system-config-control does something like this. So if you want this, I > would suggest you take over maintenance of that and update it. In case > you missed it, it is available for download at > > http://www.indianoss.org/modules/wfdownloads/viewcat.php?cid=10 > > Rahul I did check that, it don't work like that, it has a small window with tabs on top with button arranged in the window, and when you click on the button it just "executes" the programs, they'll prbably run in another window because it's just excuting, I can't say that for sure, because when I click on a button, I either get a dialog box saying that the tool isn't installed or nothing happens... > When I think of 'control center', I think of something that can be run > over a network to control many machine remotely. ?Assuming the network > is up, would this work reasonably well over ssh from a central machine? > ? Would it identify itself in the window if you open many of them at once? Maybe later we can improve it so that it has an option to make it run in text only mode, probably using curses :) Cheers! -- Laith Juwaidah http://www.ljuwaidah.org/ From sundaram at fedoraproject.org Fri Jan 4 18:47:51 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 05 Jan 2008 00:17:51 +0530 Subject: Control center idea In-Reply-To: <200801042254.10646.ljuwaida@fedoraproject.org> References: <1199374110.5023.2.camel@frosty> <200801042134.57972.ljuwaida@fedoraproject.org> <477E7410.9030703@fedoraproject.org> <200801042254.10646.ljuwaida@fedoraproject.org> Message-ID: <477E7F57.7060103@fedoraproject.org> Laith Juwaidah wrote: > > I did check that, it don't work like that, it has a small window with tabs on > top with button arranged in the window, and when you click on the button it > just "executes" the programs, they'll prbably run in another window because > it's just excuting, I can't say that for sure, because when I click on a > button, I either get a dialog box saying that the tool isn't installed or > nothing happens... Like I said before, it is a place to start working on improve on it since we don't have anything here that does it better already. If you want to ignore it, that 's fine but it is good to look at what's already available. Rahul From caolanm at redhat.com Fri Jan 4 19:16:09 2008 From: caolanm at redhat.com (Caolan McNamara) Date: Fri, 04 Jan 2008 19:16:09 +0000 Subject: howto package openoffice.org extensions In-Reply-To: <604aa7910801041006r3cacf550i149948f4e5bbf64a@mail.gmail.com> References: <1199451768.7355.201.camel@Jehannum> <604aa7910801041006r3cacf550i149948f4e5bbf64a@mail.gmail.com> Message-ID: <1199474169.7355.264.camel@Jehannum> On Fri, 2008-01-04 at 09:06 -0900, Jeff Spaleta wrote: > On Jan 4, 2008 4:02 AM, Caolan McNamara wrote: > > I've added a little bit to http://fedoraproject.org/wiki/OpenOffice.org > > to document the best recipe for installing and deinstalling > > openoffice.org extensions > that's great guidance. can we work this into the packaging guidelines > as a special case? > http://fedoraproject.org/wiki/Packaging/Guidelines > Section 40: Application Specific Guidelines Sure, I hadn't sufficient mojo to edit that page of course, so feel free to add a link to the extensions section or whack it into whereever it should go. From sundaram at fedoraproject.org Fri Jan 4 19:10:49 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 05 Jan 2008 00:40:49 +0530 Subject: howto package openoffice.org extensions In-Reply-To: <1199474169.7355.264.camel@Jehannum> References: <1199451768.7355.201.camel@Jehannum> <604aa7910801041006r3cacf550i149948f4e5bbf64a@mail.gmail.com> <1199474169.7355.264.camel@Jehannum> Message-ID: <477E84B9.1080105@fedoraproject.org> Caolan McNamara wrote: > On Fri, 2008-01-04 at 09:06 -0900, Jeff Spaleta wrote: >> On Jan 4, 2008 4:02 AM, Caolan McNamara wrote: >>> I've added a little bit to http://fedoraproject.org/wiki/OpenOffice.org >>> to document the best recipe for installing and deinstalling >>> openoffice.org extensions > >> that's great guidance. can we work this into the packaging guidelines >> as a special case? >> http://fedoraproject.org/wiki/Packaging/Guidelines >> Section 40: Application Specific Guidelines > > Sure, I hadn't sufficient mojo to edit that page of course, so feel free > to add a link to the extensions section or whack it into whereever it > should go. Packaging Committee has instructions on changing the guidelines. http://fedoraproject.org/wiki/Packaging/Committee Rahul From rayvd at bludgeon.org Fri Jan 4 19:24:11 2008 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Fri, 4 Jan 2008 11:24:11 -0800 Subject: Another selinux rant In-Reply-To: References: <477D9178.6090709@gmail.com> <477DA271.6070208@gmail.com> Message-ID: <20080104192411.GA24776@bludgeon.org> > I think improving error messages and warnings and default behavior > (see my earlier comments on tar and ls) is more worthwhile than > writing documentation, as the latter tends not to get read. +1 for the error messages. Msot of us are used to things not always quite working in the world of Unix. We're used to just taking a look at /var/log/messages and getting a pretty good idea as to what the problem is. I guess the SELinux troubleshooter goes a long way to addressing this, so maybe there's no point to making the syslog messages a bit better for human consumption. Ray From lesmikesell at gmail.com Fri Jan 4 19:33:49 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 04 Jan 2008 13:33:49 -0600 Subject: Another selinux rant In-Reply-To: References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> Message-ID: <477E8A1D.10807@gmail.com> Ed Swierk wrote: > On 1/4/08, John Dennis wrote: >> Re SELinux usability issues: >> >> We wrote the setroubleshoot package precisely to help SELinux novice >> users so they wouldn't suffer with hidden obscure failures of the type >> which have frustrated you. If it had been installed you would have >> received notifications in real time on your desktop describing the >> failure and suggestions on how to fix it. > > The machine in question is a server with no graphical applications; is > there a command-line version of setroubleshoot? As long as you have the X client libs installed you should be able to run GUI programs with remote display if you 'ssh -Y' to the machine from a terminal window on your desktop. -- Les Mikesell lesmikesell at gmail.com From james.antill at redhat.com Fri Jan 4 19:40:18 2008 From: james.antill at redhat.com (James Antill) Date: Fri, 04 Jan 2008 14:40:18 -0500 Subject: Why does gdb now give lots of warnings? In-Reply-To: <4c4ba1530801041045y59d47210t63192b2e20f05b11@mail.gmail.com> References: <20080104154915.GA28635@jadzia.bu.edu> <20080104105720.1f78b9dc@redhat.com> <20080104161201.GA17915@host0.dyn.jankratochvil.net> <18302.23710.710664.220708@zebedee.pink> <20080104164739.GA18173@host0.dyn.jankratochvil.net> <18302.25717.629111.664840@zebedee.pink> <20080104170807.GA19073@host0.dyn.jankratochvil.net> <18302.27028.83536.638113@zebedee.pink> <1199471227.23051.12.camel@code.and.org> <4c4ba1530801041045y59d47210t63192b2e20f05b11@mail.gmail.com> Message-ID: <1199475618.23051.23.camel@code.and.org> On Fri, 2008-01-04 at 10:45 -0800, Tom London wrote: > Interesting..... > > I tried 'debuginfo-install rhythmbox' and got a list of 43 packages..... cool. > > However, it looks like it wants to install 3 'real' packages: Well yum is just following the deps, for instance for me check, check-devel and gstreamer-devel are the top three installs ... which is because gstreamer-debuginfo requires gstreamer-devel, which is obviously required by rhythmbox. I'd say it's likely that we have some unneeded deps. on some of the -devel packages (maybe should be BuildRequires?) ... on the other hand it's not something that'll affect normal[1] users. [1] If you want to use gdb, you aren't normal :). -- James Antill Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From eswierk at arastra.com Fri Jan 4 19:44:24 2008 From: eswierk at arastra.com (Ed Swierk) Date: Fri, 4 Jan 2008 11:44:24 -0800 Subject: Another selinux rant In-Reply-To: <477E7529.6000409@redhat.com> References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <477E7529.6000409@redhat.com> Message-ID: On 1/4/08, John Dennis wrote: > You have two options for receiving the alerts from the headless server. > You can either run the gui on a machine with a head and point it at the > headless server (requires modifying the config file to use TCP rather > than the default Unix domain sockets). > > [truncated] I appreciate your taking the time to explain setroubleshoot but anything that involves configuring daemons and email addresses is a usability hurdle in itself. If the mysterious audit log messages can't be made clearer, then can't we have a simple command-line tool to translate a message into a friendlier form? --Ed From icon at fedoraproject.org Fri Jan 4 19:54:09 2008 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Fri, 4 Jan 2008 14:54:09 -0500 Subject: Another selinux rant In-Reply-To: References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <477E7529.6000409@redhat.com> Message-ID: On Jan 4, 2008 2:44 PM, Ed Swierk wrote: > If the mysterious audit log messages can't be made clearer, then can't > we have a simple command-line tool to translate a message into a > friendlier form? Generally, audit2why and audit2allow are your best friends when making first inroads with SELinux. Regards, -- Konstantin Ryabitsev Montr?al, Qu?bec From jan.kratochvil at redhat.com Fri Jan 4 20:07:39 2008 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Fri, 4 Jan 2008 21:07:39 +0100 Subject: Why does gdb now give lots of warnings? In-Reply-To: <1199475618.23051.23.camel@code.and.org> References: <20080104105720.1f78b9dc@redhat.com> <20080104161201.GA17915@host0.dyn.jankratochvil.net> <18302.23710.710664.220708@zebedee.pink> <20080104164739.GA18173@host0.dyn.jankratochvil.net> <18302.25717.629111.664840@zebedee.pink> <20080104170807.GA19073@host0.dyn.jankratochvil.net> <18302.27028.83536.638113@zebedee.pink> <1199471227.23051.12.camel@code.and.org> <4c4ba1530801041045y59d47210t63192b2e20f05b11@mail.gmail.com> <1199475618.23051.23.camel@code.and.org> Message-ID: <20080104200739.GA2936@host0.dyn.jankratochvil.net> On Fri, 04 Jan 2008 20:40:18 +0100, James Antill wrote: ... > which is because gstreamer-debuginfo requires gstreamer-devel, which is > obviously required by rhythmbox. What is the reason why any *-debuginfo package requires any binary package? Sure it installs .debug files which are only partially usable (officially not usable) without their binary counterparts. But still even this dependency is currently not complete there, I am not aware which rule generates the current dependencies but it seems as useless there; going to submit the patch. Regards, Jan -------------- next part -------------- --- /usr/lib/rpm/redhat/macros-orig 2007-07-05 20:34:42.000000000 +0200 +++ /usr/lib/rpm/redhat/macros 2008-01-04 21:03:11.000000000 +0100 @@ -106,6 +106,7 @@ %package debuginfo \ Summary: Debug information for package %{name}\ Group: Development/Debug\ +AutoReq: no\ %description debuginfo\ This package provides debug information for package %{name}.\ Debug information is useful when developing applications that use this\ From jonstanley at gmail.com Fri Jan 4 20:11:51 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Fri, 4 Jan 2008 15:11:51 -0500 Subject: Fwd: closing out old bugs of unmaintained releases In-Reply-To: References: Message-ID: As part of a re-launch of the bug triage project [1,2], I believe that it would be beneficial to mass close the bugs that are for releases that are no longer maintained. Please find my proposal for this below. Sorry for cross-posting, but it's relevant across multiple communities within Fedora. I will be at FUDCon in order to discuss the very topic of the re-launch of the triage project. [1] https://www.redhat.com/archives/fedora-advisory-board/2008-January/msg00009.html [2] https://www.redhat.com/archives/fedora-marketing-list/2008-January/msg00000.html ---------- Forwarded message ---------- From: Jon Stanley Date: Jan 4, 2008 1:45 PM Subject: closing out old bugs of unmaintained releases To: fedora-advisory-board at redhat.com I can put some time this weekend into closing out old bugs, however, before doing so, I wanted to make sure that our messaging is crystal clear. What I had been doing for kernel bugs is placing them in NEEDINFO_REPORTER and asking if the problem still existed, etc after manually reviewing the bugs (some I changed to a current release because it was mentioned in comments, but not in the version metadata). However, this won't scale - there's no way that I or anybody else can reasonably review 3600 bugs for ones that are incorrectly tagged. This leaves us with ~9000 bugs (F7, F8, and rawhide) to deal with (still a monumental task). I propose doing something similar with rawhide bugs that haven't been touched in ~6 months, not sure of the number of those, haven't looked yet. Here's the proposed comment to WONTFIX these. I want to get the most input possible before doing this: Hello, Thank you for taking the time to report this bug. Unfortunately, this version of Fedora has reach end-of-life and is no longer maintained. Please refer to http://fedoraproject.org/wiki/LifeCycle for an explanation of the Fedora lifecycle policy. We therefore regret the necessity of closing this bug report WONTFIX. Please upgrade to a currently maintained release of Fedora, currently either Fedora 7 or Fedora 8, and attempt to reproduce this bug. If the bug still exists, feel free to re-open this bug report, changing the version accordingly, or file a new bug report (you can use the 'Clone as Bug' link at the top of this bug report in order to preserve the content of this bug in the new one). We regret any inconvenience that this may cause you, and thank you for your continued support of Fedora! I propose starting with FC6, since that recently reached EOL and people would be understanding about it (hopefully). Comments/thoughts/suggestions/flames welcome. -- Jon Stanley Fedora Ambassador jstanley at fedoraproject.org From david at lovesunix.net Fri Jan 4 20:12:58 2008 From: david at lovesunix.net (David Nielsen) Date: Fri, 04 Jan 2008 21:12:58 +0100 Subject: Why does gdb now give lots of warnings? In-Reply-To: <18302.18459.463805.56859@zebedee.pink> References: <18302.18459.463805.56859@zebedee.pink> Message-ID: <1199477578.3035.2.camel@watson> fre, 04 01 2008 kl. 14:52 +0000, skrev Andrew Haley: > Neal Becker writes: > > Here is an example: > > > > Starting program: /usr/bin/python > > > > warning: Missing the separate debug info file: /usr/lib/debug/.build-id/fa/841219472d35412ad631ad0f0fabb78e5c1957.debug > > You haven't installed the -debug packages for the shared libs you've > loaded. Telling you this isn't a bug. > > What *is* a bug, IMO, is that you can't tell which shared libs it's > complaining about. Sounds like a job for PackageKit, look up the path to figure out which packages we are missing and offer the user to install the missing debug symbols. - David From ljuwaida at fedoraproject.org Fri Jan 4 20:17:29 2008 From: ljuwaida at fedoraproject.org (Laith Juwaidah) Date: Sat, 5 Jan 2008 00:17:29 +0400 Subject: Control center idea In-Reply-To: <477E7F57.7060103@fedoraproject.org> References: <1199374110.5023.2.camel@frosty> <200801042254.10646.ljuwaida@fedoraproject.org> <477E7F57.7060103@fedoraproject.org> Message-ID: <200801050017.29769.ljuwaida@fedoraproject.org> I won't ignore it, I'll take some code from it, specially that I'm new to python :) On Friday 04 January 2008 22:47:51 Rahul Sundaram wrote: > Laith Juwaidah wrote: > > I did check that, it don't work like that, it has a small window with > > tabs on top with button arranged in the window, and when you click on the > > button it just "executes" the programs, they'll prbably run in another > > window because it's just excuting, I can't say that for sure, because > > when I click on a button, I either get a dialog box saying that the tool > > isn't installed or nothing happens... > > Like I said before, it is a place to start working on improve on it > since we don't have anything here that does it better already. If you > want to ignore it, that 's fine but it is good to look at what's already > available. > > Rahul -- Laith Juwaidah http://www.ljuwaidah.org/ From jdennis at redhat.com Fri Jan 4 20:19:30 2008 From: jdennis at redhat.com (John Dennis) Date: Fri, 04 Jan 2008 15:19:30 -0500 Subject: Another selinux rant In-Reply-To: References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <477E7529.6000409@redhat.com> Message-ID: <477E94D2.2070307@redhat.com> Ed Swierk wrote: > If the mysterious audit log messages can't be made clearer, then can't > we have a simple command-line tool to translate a message into a > friendlier form? % sudo sealert -a /var/log/audit/audit.log -- John Dennis From pemboa at gmail.com Fri Jan 4 20:30:52 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 4 Jan 2008 14:30:52 -0600 Subject: Another selinux rant In-Reply-To: References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <477E7529.6000409@redhat.com> Message-ID: <16de708d0801041230m3519f1ey30ebee79d0f8f76@mail.gmail.com> On Jan 4, 2008 1:44 PM, Ed Swierk wrote: > On 1/4/08, John Dennis wrote: > > You have two options for receiving the alerts from the headless server. > > You can either run the gui on a machine with a head and point it at the > > headless server (requires modifying the config file to use TCP rather > > than the default Unix domain sockets). > > > > [truncated] > > I appreciate your taking the time to explain setroubleshoot but > anything that involves configuring daemons and email addresses is a > usability hurdle in itself. > > If the mysterious audit log messages can't be made clearer, then can't > we have a simple command-line tool to translate a message into a > friendlier form? > > --Ed Please try setroubleshot. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From pemboa at gmail.com Fri Jan 4 20:32:08 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 4 Jan 2008 14:32:08 -0600 Subject: Control center idea In-Reply-To: <200801050017.29769.ljuwaida@fedoraproject.org> References: <1199374110.5023.2.camel@frosty> <200801042254.10646.ljuwaida@fedoraproject.org> <477E7F57.7060103@fedoraproject.org> <200801050017.29769.ljuwaida@fedoraproject.org> Message-ID: <16de708d0801041232h395f6a3x7d122de3678ad3fc@mail.gmail.com> On Jan 4, 2008 2:17 PM, Laith Juwaidah wrote: > I won't ignore it, I'll take some code from it, specially that I'm new to > python :) If this thread is going to get any longer, please bottom-post, thank you. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From michael.wiktowy at gmail.com Fri Jan 4 20:39:34 2008 From: michael.wiktowy at gmail.com (Michael Wiktowy) Date: Fri, 4 Jan 2008 15:39:34 -0500 Subject: Another selinux rant In-Reply-To: References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> Message-ID: <3e4ec4600801041239s44702f06j5039fb896c8cca52@mail.gmail.com> On Jan 4, 2008 11:40 AM, Ed Swierk wrote: > On 1/4/08, Tomasz Torcz wrote: > > tar with "--xattrs"? > > No, I didn't realize --xattrs existed; the tar info page doesn't > mention it. Oh, there it is in the man page. > I see. I now notice ls has a -Z option that shows the SELinux security context. > > It would be nice if ls -l would show the security context by default > when SELinux is enabled, as the context is apparently just as > important as file permissions. I started to use cp -P + rm rather than mv to shuffle around config files and files between user directories and 99% of my selinux attribute issues went away. I checked the man page for mv and didn't see anything; is there an equivalent to cp's -P parameter for mv? /Mike From pemboa at gmail.com Fri Jan 4 20:48:04 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 4 Jan 2008 14:48:04 -0600 Subject: Another selinux rant In-Reply-To: <3e4ec4600801041239s44702f06j5039fb896c8cca52@mail.gmail.com> References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <3e4ec4600801041239s44702f06j5039fb896c8cca52@mail.gmail.com> Message-ID: <16de708d0801041248v3d314bb6x11e5eadf7616606b@mail.gmail.com> On Jan 4, 2008 2:39 PM, Michael Wiktowy wrote: > On Jan 4, 2008 11:40 AM, Ed Swierk wrote: > > On 1/4/08, Tomasz Torcz wrote: > > > tar with "--xattrs"? > > > > No, I didn't realize --xattrs existed; the tar info page doesn't > > mention it. Oh, there it is in the man page. > > I see. I now notice ls has a -Z option that shows the SELinux security context. > > > > It would be nice if ls -l would show the security context by default > > when SELinux is enabled, as the context is apparently just as > > important as file permissions. > > I started to use cp -P + rm rather than mv to shuffle around config > files and files between user directories and 99% of my selinux > attribute issues went away. I checked the man page for mv and didn't > see anything; is there an equivalent to cp's -P parameter for mv? > > /Mike This has suggested before in reply to past rants. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From roland at redhat.com Fri Jan 4 20:53:15 2008 From: roland at redhat.com (Roland McGrath) Date: Fri, 4 Jan 2008 12:53:15 -0800 (PST) Subject: Why does gdb now give lots of warnings? In-Reply-To: Jan Kratochvil's message of Friday, 4 January 2008 21:07:39 +0100 <20080104200739.GA2936@host0.dyn.jankratochvil.net> References: <20080104105720.1f78b9dc@redhat.com> <20080104161201.GA17915@host0.dyn.jankratochvil.net> <18302.23710.710664.220708@zebedee.pink> <20080104164739.GA18173@host0.dyn.jankratochvil.net> <18302.25717.629111.664840@zebedee.pink> <20080104170807.GA19073@host0.dyn.jankratochvil.net> <18302.27028.83536.638113@zebedee.pink> <1199471227.23051.12.camel@code.and.org> <4c4ba1530801041045y59d47210t63192b2e20f05b11@mail.gmail.com> <1199475618.23051.23.camel@code.and.org> <20080104200739.GA2936@host0.dyn.jankratochvil.net> Message-ID: <20080104205315.AFDFE26F9A0@magilla.localdomain> > --- /usr/lib/rpm/redhat/macros-orig 2007-07-05 20:34:42.000000000 +0200 > +++ /usr/lib/rpm/redhat/macros 2008-01-04 21:03:11.000000000 +0100 /usr/lib/rpm/macros has a better definition that uses "AutoReqProv: 0". redhat-rpm-config should change to match (or better, change not to duplicate the details). (The only intended difference is "debug" vs "debuginfo", and maybe rpm can change that too.) From kevin at scrye.com Fri Jan 4 21:07:46 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Fri, 4 Jan 2008 14:07:46 -0700 Subject: Fwd: closing out old bugs of unmaintained releases In-Reply-To: References: Message-ID: <20080104140746.62518306@ghistelwchlohm.scrye.com> On Fri, 4 Jan 2008 15:11:51 -0500 jonstanley at gmail.com ("Jon Stanley") wrote: > As part of a re-launch of the bug triage project [1,2], I believe that > it would be beneficial to mass close the bugs that are for releases > that are no longer maintained. Please find my proposal for this > below. Sorry for cross-posting, but it's relevant across multiple > communities within Fedora. Do we really want to just close all those bugs? > I will be at FUDCon in order to discuss the very topic of the > re-launch of the triage project. Excellent. I think we need to address this issue... > [1] > https://www.redhat.com/archives/fedora-advisory-board/2008-January/msg00009.html > [2] > https://www.redhat.com/archives/fedora-marketing-list/2008-January/msg00000.html > > ---------- Forwarded message ---------- > From: Jon Stanley > Date: Jan 4, 2008 1:45 PM > Subject: closing out old bugs of unmaintained releases > To: fedora-advisory-board at redhat.com > > > I can put some time this weekend into closing out old bugs, however, Note that you might want to wait until after fudcon and until you have gotten input from everyone before doing anything hasty... > before doing so, I wanted to make sure that our messaging is crystal > clear. What I had been doing for kernel bugs is placing them in > NEEDINFO_REPORTER and asking if the problem still existed, etc after > manually reviewing the bugs (some I changed to a current release > because it was mentioned in comments, but not in the version > metadata). However, this won't scale - there's no way that I or > anybody else can reasonably review 3600 bugs for ones that are > incorrectly tagged. Sure, agreed 100%, but closing them makes less work for us, but makes anyone who filed them in the past where they were ignored pretty mad. See: http://www.jwz.org/doc/cadt.html How about instead we move them all up to a current release... Then, the maintainer should ping them or deal with them in some way. I'm concerned that these sort of mass closings or "clear the deck" just ends up annoying bug submitters, and doesn't really help us in the long term since it just happens again a few releases down the road... so all kinds of bugs get filed, ignored, then closed, even when they still do affect current releases. > This leaves us with ~9000 bugs (F7, F8, and > rawhide) to deal with (still a monumental task). I propose doing > something similar with rawhide bugs that haven't been touched in ~6 > months, not sure of the number of those, haven't looked yet. Here's > the proposed comment to WONTFIX these. I want to get the most input > possible before doing this: Yeah, but how many of the now closed fc6 or rawhide bugs are really still bugs? we have no idea... we should deal with the whole IMHO. > > Hello, > > Thank you for taking the time to report this bug. Unfortunately, this > version of Fedora has reach end-of-life and is no longer maintained. > Please refer to http://fedoraproject.org/wiki/LifeCycle for an > explanation of the Fedora lifecycle policy. > > We therefore regret the necessity of closing this bug report WONTFIX. > Please upgrade to a currently maintained release of Fedora, currently > either Fedora 7 or Fedora 8, and attempt to reproduce this bug. If > the bug still exists, feel free to re-open this bug report, changing > the version accordingly, or file a new bug report (you can use the > 'Clone as Bug' link at the top of this bug report in order to preserve > the content of this bug in the new one). > > We regret any inconvenience that this may cause you, and thank you for > your continued support of Fedora! > > > I propose starting with FC6, since that recently reached EOL and > people would be understanding about it (hopefully). > Comments/thoughts/suggestions/flames welcome. I agree we need to do something, but I don't think mass closing is the answer. We need to get things to where maintainers do something with their bugs, or in the cases of packages where maintainers can't possibly handle things (kernel, rpm, glibc, whatever) we need to have people helping those maintainers. I also don't think 'bug days' really help much, except as a way to possibly teach people to triage bugs. The mass of bugs is just too daunting and any single day is kind of a drop in the bucket. Perhaps one thing we could do is generate a report with packages with the most bugs, to point out where we could focus our efforts? Or we could look at oldest bugs and try and bring those up to date. Just some thoughts... kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From icon at fedoraproject.org Fri Jan 4 21:13:57 2008 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Fri, 4 Jan 2008 16:13:57 -0500 Subject: Fedora cvsextras sponsor needed for ashawley In-Reply-To: <40868.192.168.219.109.1199402222.squirrel@mail.garden.org> References: <40868.192.168.219.109.1199402222.squirrel@mail.garden.org> Message-ID: Hi, everyone: Aaron (ashawley) is taking over one of my packages that is already in CVS (diction). Since he's not submitting a new package, I'm wondering if someone can sponsor him to get CVS commit status. Cheers, Konstantin ---------- Forwarded message ---------- From: Aaron S. Hawley Date: Jan 3, 2008 6:17 PM Subject: [Fwd: Fedora cvsextras sponsor needed for ashawley] To: icon at fedoraproject.org I'm now in the system. I suppose I need you to sponsor my account. ---------------------------- Original Message ---------------------------- Subject: Fedora cvsextras sponsor needed for ashawley From: accounts at fedoraproject.org Date: Thu, January 3, 2008 5:49 pm To: cvsextras-sponsors at fedoraproject.org Cc: aaronh at garden.org -------------------------------------------------------------------------- Fedora user ashawley, aka Aaron S. Hawley has requested membership in the cvsextras group and needs a sponsor. Please go to https://admin.fedoraproject.org/accounts/groupbox.cgi?_editme=Edit&name=cvsextras to take action. -- The Fedora Account System -- National Gardening Association 1100 Dorset Street, South Burlington, VT 05403 Email: support at garden.org - Web: www.garden.org/ -- -- Konstantin Ryabitsev Montr?al, Qu?bec From mcepl at redhat.com Fri Jan 4 21:26:16 2008 From: mcepl at redhat.com (Matej Cepl) Date: Fri, 04 Jan 2008 22:26:16 +0100 Subject: Another selinux rant References: Message-ID: On 2008-01-03, 21:29 GMT, Ed Swierk wrote: > For me learning SELinux seems as pointless as trying to > remember iptables commands, or AFS trivia back when I was > a student--all cause me trouble just infrequently enough to > ensure I have to relearn them from scratch every time. If > I were a full-time sysadmin of course it would be a different > story, but I really don't have the brain cycles to remember > anything more complicated than chmod and chown, and I suspect > a large number of accidental sysadmins feel the same. When introducing SELinux on computer where it wasn't before, it is mandatory to touch /.autorelabel reboot Mat?j From david at lovesunix.net Fri Jan 4 21:32:27 2008 From: david at lovesunix.net (David Nielsen) Date: Fri, 04 Jan 2008 22:32:27 +0100 Subject: f8 gripe#2: why did f8's pm-hibernate regress? In-Reply-To: <1199382316.3261.7.camel@sb-home> References: <477ADF46.2040108@filteredperception.org> <200801021159.17964.opensource@till.name> <477C299D.2060400@filteredperception.org> <477C96B8.6040903@filteredperception.org> <1199382316.3261.7.camel@sb-home> Message-ID: <1199482347.3035.9.camel@watson> tor, 03 01 2008 kl. 18:45 +0100, skrev nodata: > Am Donnerstag, den 03.01.2008, 02:03 -0600 schrieb Douglas McClendon: > > Douglas McClendon wrote: > > > > [ pro-tux-on-ice rant snipped ] > > > > > might be time for me to go back to tux-on-ice. I truly am disgusted by > > > having to suffer through 5-15 seconds of thrashing while changing > > > desktops after resume. I would much rather the resume take 20 seconds > > > longer, and present me with a good user experience. (yes, I am one of > > > those people that thinks that offering early login while the system > > > finishes booting is a really stupid thing). > > > > To clarify this harsh, theoretically offensive statement- Early login > > done _right_ would be fine. Doing it the incomplete way, such as the > > vista experience, > > I don't know why people keep saying this. Vista boots fast and is > responsive. Wow.. can I have a puff at that crack pipe my good man? :) I install Vista on this laptop a few days ago, compared to Fedora 8 both boot time and responsiveness is much worse. Using Vista was like being waist deep in molasses - on a Core 2 Duo machine with a gig of ram. Now I think we can all do better, but to call Vista fast and responsive is in my experience just not true. Wow.. can I have a puff at that crack pipe my good man? - David From mcepl at redhat.com Fri Jan 4 21:31:35 2008 From: mcepl at redhat.com (Matej Cepl) Date: Fri, 04 Jan 2008 22:31:35 +0100 Subject: Another selinux rant References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <477E7529.6000409@redhat.com> Message-ID: On 2008-01-04, 19:44 GMT, Ed Swierk wrote: > If the mysterious audit log messages can't be made clearer, > then can't we have a simple command-line tool to translate > a message into a friendlier form? audit2why(8) From lordmorgul at gmail.com Fri Jan 4 21:49:14 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Fri, 04 Jan 2008 13:49:14 -0800 Subject: Fwd: closing out old bugs of unmaintained releases In-Reply-To: <20080104140746.62518306@ghistelwchlohm.scrye.com> References: <20080104140746.62518306@ghistelwchlohm.scrye.com> Message-ID: <477EA9DA.9040202@gmail.com> Kevin Fenzi wrote: > Note that you might want to wait until after fudcon and until you have > gotten input from everyone before doing anything hasty... Probably a good idea to not be hasty on a large step like this, but the same problem has been around since FC1 (forever?). >> before doing so, I wanted to make sure that our messaging is crystal >> clear. What I had been doing for kernel bugs is placing them in >> NEEDINFO_REPORTER and asking if the problem still existed, etc after >> manually reviewing the bugs (some I changed to a current release >> because it was mentioned in comments, but not in the version >> metadata). However, this won't scale - there's no way that I or >> anybody else can reasonably review 3600 bugs for ones that are >> incorrectly tagged. > > Sure, agreed 100%, but closing them makes less work for us, but makes > anyone who filed them in the past where they were ignored pretty mad. > > See: http://www.jwz.org/doc/cadt.html He may have a point of interest there, but like it or not new code bases get released. This is something the upstream project leads need to consider thoughtfully, not so much those working with the bugs later. > How about instead we move them all up to a current release... > Then, the maintainer should ping them or deal with them in some way. > > I'm concerned that these sort of mass closings or "clear the deck" just > ends up annoying bug submitters, and doesn't really help us in the long > term since it just happens again a few releases down the road... > so all kinds of bugs get filed, ignored, then closed, even when they > still do affect current releases. Eeww, moving bugs across releases is a worse idea than mass closing frankly. The rate that major things change in fedora is too rapid to do this and hope that the bugs can be figured out... the second you try this you've got to go back and ask 'ok which version of xx and xx and xx and xx were installed' when thats not necessarily as important if you know the release. (think changes in gcc and glibc from release to release) If you want to avoid bug reporter frustration then confusing the hell out of them is a bad idea too. It is far simpler to ask bugs to be refiled or edited to indicate they still apply to new releases after the reporter figures out that they do. Why cannot the bugs be left open and just simply filtered by non-EOL releases? This would feel a little bit less like your work as a bug reporter is being ignored (while it still is for those bugs). The maintainers would be able to look at open old bugs if they know the code base is still shared, and easily filtered if its not. But at the same time no matter what is done, those bug reporters should be upgrading and identifying if the bugs still exist in new releases, so something should be done to indicate to them that the old bugs are stale. Would it be possible to choose a preset response for these bugs now, but not apply them in mass closing... then asking bug triage to close those bugs as quickly as possible where 1) the release is EOL, 2) the component has changed major versions from that EOL release to current. Bugs that are for EOL releases but have similar component versions in new releases should be left open as they probably still apply. I suspect closing those alone would have a big impact in the number of bugs still open. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From mcepl at redhat.com Fri Jan 4 21:30:42 2008 From: mcepl at redhat.com (Matej Cepl) Date: Fri, 04 Jan 2008 22:30:42 +0100 Subject: Another selinux rant References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> Message-ID: <25l255xda9.ln2@ppp1053.in.ipex.cz> On 2008-01-04, 17:07 GMT, John Dennis wrote: > Re SELinux usability issues: > > We wrote the setroubleshoot package precisely to help SELinux novice > users so they wouldn't suffer with hidden obscure failures of the type > which have frustrated you. If it had been installed you would have > received notifications in real time on your desktop describing the > failure and suggestions on how to fix it. But you should probably emphasize more that relabel needs to be done on systems where SELinux was not used before. I know it is in man page, but apparently there are still very smart people who didn't get the memo. Mat?j From ndbecker2 at gmail.com Fri Jan 4 22:01:05 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 04 Jan 2008 17:01:05 -0500 Subject: Is anyone packaging sage? Message-ID: http://sage.math.washington.edu/sage/ From jspaleta at gmail.com Fri Jan 4 22:06:45 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 4 Jan 2008 13:06:45 -0900 Subject: Is anyone packaging sage? In-Reply-To: References: Message-ID: <604aa7910801041406x7203c9fbq6485bd4b7e481281@mail.gmail.com> On Jan 4, 2008 1:01 PM, Neal Becker wrote: > http://sage.math.washington.edu/sage/ holy crap.... that looks pretty awesome. I can't be primary maintainer for this, but if you are going to work on it I can help. -jef From triad at df.lth.se Fri Jan 4 22:06:55 2008 From: triad at df.lth.se (Linus Walleij) Date: Fri, 4 Jan 2008 23:06:55 +0100 (CET) Subject: Disabling selinux question In-Reply-To: <200801040858.36273.sgrubb@redhat.com> References: <1199399640.3716.65.camel@localhost.localdomain> <200801040858.36273.sgrubb@redhat.com> Message-ID: Thanks for the long explanation Steve, I now understand what auditd is and what interacts with it and why it should be default-enabled. > You can turn it off if you want. :) You're right, and I'm beginning to suspect that much of my bad experiences with system-config-services is that # description: foo in the /etc/init.d/foo scripts is too short and uniformative. A user that does not know what the daemons are intended for will not know for sure whether they can enable and disable it or not. Would you accept this patch to /etc/init.d/auditd: --- auditd.orig 2008-01-04 22:53:32.000000000 +0100 +++ auditd 2008-01-04 22:58:46.000000000 +0100 @@ -3,7 +3,11 @@ # auditd This starts and stops auditd # # chkconfig: 2345 11 88 -# description: This starts the Linux Auditing System Daemon +# description: This starts the Linux Auditing System Daemon, \ +# which collects security related events in a \ +# dedicated auditing log. Turning it off will not \ +# alter system functionality, security related events \ +# will then be recorded in the default system log. # # processname: /sbin/auditd # config: /etc/sysconfig/auditd I think this (if it is correct, beware) is what a user of system-config-services need to know about this particular daemon in order to make an educated choice of whether or not it should be enabled. Hm, perhaps the other SELinux related daemons will be likewise understandable if I make three more such patches... > sigh... Plese don't give up on me so easily. I have good intentions. > the services should exit if selinux is disabled. Its ok for them to > start up. Yes, certainly, but how as a user of the system-config-services interface, would I know that? s-c-s is itching me somewhere and I try to find out why and what's the remedy for. Linus From tcallawa at redhat.com Fri Jan 4 22:11:32 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 04 Jan 2008 17:11:32 -0500 Subject: Fedora cvsextras sponsor needed for ashawley In-Reply-To: References: <40868.192.168.219.109.1199402222.squirrel@mail.garden.org> Message-ID: <477EAF14.4020901@redhat.com> Konstantin Ryabitsev wrote: > Hi, everyone: > > Aaron (ashawley) is taking over one of my packages that is already in > CVS (diction). Since he's not submitting a new package, I'm wondering > if someone can sponsor him to get CVS commit status. No offense, but I'd prefer to know that he has a good grasp of packaging and the Fedora guidelines before letting him have CVS access. Simply taking over someone else's package doesn't show anything (other than willingness). If he submits a new package for review, I'd be willing to sponsor him (assuming the package is good, of course). ~spot From eswierk at arastra.com Fri Jan 4 22:24:48 2008 From: eswierk at arastra.com (Ed Swierk) Date: Fri, 4 Jan 2008 14:24:48 -0800 Subject: Another selinux rant In-Reply-To: References: Message-ID: On 1/4/08, Matej Cepl wrote: > When introducing SELinux on computer where it wasn't before, it > is mandatory to > > touch /.autorelabel > reboot ...and when copying files from another machine not running SELinux, and when copying files from a machine running SELinux without using funny tar/cp options. --Ed From triad at df.lth.se Fri Jan 4 22:30:29 2008 From: triad at df.lth.se (Linus Walleij) Date: Fri, 4 Jan 2008 23:30:29 +0100 (CET) Subject: Disabling selinux question In-Reply-To: <1199461244.3716.75.camel@localhost.localdomain> References: <1199399640.3716.65.camel@localhost.localdomain> <1199461244.3716.75.camel@localhost.localdomain> Message-ID: On Fri, 4 Jan 2008, Eric Paris wrote: > There is no reason that a user cannot turn auditd off themselves (kernel > just reroutes the messages to syslog rather than audit log) but audit > still functions and serves a purpose all by itself. Yeah turns out my big problem is likely with the # decription : provided to s-c-s through the /etc/init.d/foo files so user knows they can actually turn it off without shooting themselves in the foot. > My opinion, if you disable SELinux in the installer (or s-c-selinux) it > should disable those other programs you mentioned if those programs are > not smart enough to not run on their own. (sounds like setroubleshoot > and i'm going to guess sealert already are smart enough and > anaconda/s-c-* shouldn't bother them...) I think the best thing I can do is patch their # description : entries, so the s-c-s user knows this. If this was a major problem with s-c-s to me (not very high tech indeed) I'm bold enough to believe it's going to be to many others as well. Linus From jonathan.underwood at gmail.com Fri Jan 4 22:30:36 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 4 Jan 2008 22:30:36 +0000 Subject: Another selinux rant In-Reply-To: <477E67D9.1060808@redhat.com> References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> Message-ID: <645d17210801041430h7ab76f20qee0df7d1f295d23b@mail.gmail.com> On 04/01/2008, John Dennis wrote: > Ed Swierk wrote: > > People who already know about SELinux can of course just learn to type > > ls -l --lcontext, but showing the extra information by default would > > at least give clueless users like me a hint that files have these > > extra attributes that might somehow be relevant to those strange > > openvpn failures. IMHO this would be the single best usability > > improvement to SELinux > > Re SELinux usability issues: > > We wrote the setroubleshoot package precisely to help SELinux novice > users so they wouldn't suffer with hidden obscure failures of the type > which have frustrated you. If it had been installed you would have > received notifications in real time on your desktop describing the > failure and suggestions on how to fix it. The problem is, the notifications don't tell you much more than the obscure avc denial in most cases. But there's a bigger problem than that. Here's what happens when most people have an avc denial: 1) setroubleshoot pops up detailing the denial. The only really intelligible part of the information there to the non expert is "please file a report in bugzilla". 2) User thinks "oh, must be yet another problem with the selinux policy" and files a bug. 3) Dan or his team fix the problem with the policy extremely rapidly. New policy packages are installed. 4) Goto 1. The problem is: setroubleshoot teaches average users that avc denials come about due to bugs in selinux policy. If there was some massive security problem right now on my machine causing avc denials I'd probably react by filing a stack of bug reports. This is the fundamental problem as it stands with SElinux. If it was working, we would be in a situation where the first responce to an avc denial is "OMG there's a security issue with something running on my machine, I must fix that". From jam at zoidtechnologies.com Fri Jan 4 22:31:21 2008 From: jam at zoidtechnologies.com (jam at zoidtechnologies.com) Date: Fri, 4 Jan 2008 17:31:21 -0500 Subject: Fwd: closing out old bugs of unmaintained releases In-Reply-To: <477EA9DA.9040202@gmail.com> References: <20080104140746.62518306@ghistelwchlohm.scrye.com> <477EA9DA.9040202@gmail.com> Message-ID: <20080104223121.GG17086@zoidtechnologies.com> On Fri, Jan 04, 2008 at 01:49:14PM -0800, Andrew Farris wrote: > Kevin Fenzi wrote: > >Note that you might want to wait until after fudcon and until you have > >gotten input from everyone before doing anything hasty... > > Probably a good idea to not be hasty on a large step like this, but the > same problem has been around since FC1 (forever?). > yep. I am +1 for adding an "EOL flag" how about taking a page from the http://pear.php.net/ playbook and make some stats so *everbody* (users, maintainers, etc) can see the "average number of bugs" for a particular package. also stats like "10 open bugs, 8 closed, 2 that are EOL". the PEAR project has an irc bot that will alter /topic to indicate the total number of bugs, but it is not necessary to go that far at this point :) hmm.. maybe a credit system where there would be a penalty for open and EOL bugs vs. current ones. regards, --jeff -- http://zoidtechnologies.com/ -- websites that suck less From pemboa at gmail.com Fri Jan 4 22:47:12 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 4 Jan 2008 16:47:12 -0600 Subject: Another selinux rant In-Reply-To: <645d17210801041430h7ab76f20qee0df7d1f295d23b@mail.gmail.com> References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <645d17210801041430h7ab76f20qee0df7d1f295d23b@mail.gmail.com> Message-ID: <16de708d0801041447pa2a6486p7a1f7a15de41d867@mail.gmail.com> On Jan 4, 2008 4:30 PM, Jonathan Underwood wrote: > On 04/01/2008, John Dennis wrote: > > Ed Swierk wrote: > > > People who already know about SELinux can of course just learn to type > > > ls -l --lcontext, but showing the extra information by default would > > > at least give clueless users like me a hint that files have these > > > extra attributes that might somehow be relevant to those strange > > > openvpn failures. IMHO this would be the single best usability > > > improvement to SELinux > > > > Re SELinux usability issues: > > > > We wrote the setroubleshoot package precisely to help SELinux novice > > users so they wouldn't suffer with hidden obscure failures of the type > > which have frustrated you. If it had been installed you would have > > received notifications in real time on your desktop describing the > > failure and suggestions on how to fix it. > > The problem is, the notifications don't tell you much more than the > obscure avc denial in most cases. But there's a bigger problem than > that. Here's what happens when most people have an avc denial: > > 1) setroubleshoot pops up detailing the denial. The only really > intelligible part of the information there to the non expert is > "please file a report in bugzilla". I don't know how the GUI version works, maybe you should try the console version. > > 2) User thinks "oh, must be yet another problem with the selinux > policy" and files a bug. Why wouldn't they think "oh the program I am using and which is being denied by SELInux might have a bug" ? > 3) Dan or his team fix the problem with the policy extremely rapidly. > New policy packages are installed. Are you referring to a specific policy? > 4) Goto 1. > > The problem is: setroubleshoot teaches average users that avc denials > come about due to bugs in selinux policy. I get the feeling you're refering to some specific incident(s) as I have never had a avn denial due to a SELinux bug (as far as I can remember) > If there was some massive > security problem right now on my machine causing avc denials I'd > probably react by filing a stack of bug reports. This is the > fundamental problem as it stands with SElinux. No offence, but you _really_ should check the message before you file a bug as is often makes sense. Or has SELinux taken a nose dive in F8 that I don't know about? >If it was working, we > would be in a situation where the first responce to an avc denial is > "OMG there's a security issue with something running on my machine, I > must fix that". Again, I'm maybe missing information...but that's my first response when I see an SELinux denial, esp. after it saved me from being rooted once. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From Michael_E_Brown at Dell.com Fri Jan 4 22:49:29 2008 From: Michael_E_Brown at Dell.com (Michael_E_Brown at Dell.com) Date: Fri, 4 Jan 2008 16:49:29 -0600 Subject: mock 0.9 backport to F7/F8 -- Feb 1 Message-ID: All mock users, The mock maintainers (Clark, Jesse, me) will upgrade mock in F7/F8 to current 0.9 on/around Feb 1. The mock 0.9 branch has brewed in rawhide since early Dec, and so far it looks good. The 0.9 branch is now being used on the official build systems, so if there were any major problems, we would expect to have hit them by now. The *only* difference between 0.8. and 0.9. at this point is that we have dropped the old mock setuid wrapper and now use the consolehelper subsystem. For this, you will notice new /etc/pam.d/mock, /etc/consolehelper/mock files which configure mock. The default config is set up to operate exactly the same as the old 0.8 branch: ie. you must be a member of the 'mock' group to run mock. Additionally, with consolehelper comes one new feature: if you are not in the 'mock' group, you will be prompted to enter the root password and it will run. This means you can run mock without worrying about any pre-setup. -- Michael From lordmorgul at gmail.com Fri Jan 4 22:52:57 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Fri, 04 Jan 2008 14:52:57 -0800 Subject: Another selinux rant In-Reply-To: <645d17210801041430h7ab76f20qee0df7d1f295d23b@mail.gmail.com> References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <645d17210801041430h7ab76f20qee0df7d1f295d23b@mail.gmail.com> Message-ID: <477EB8C9.9030309@gmail.com> Jonathan Underwood wrote: > The problem is: setroubleshoot teaches average users that avc denials > come about due to bugs in selinux policy. If there was some massive > security problem right now on my machine causing avc denials I'd > probably react by filing a stack of bug reports. This is the > fundamental problem as it stands with SElinux. If it was working, we > would be in a situation where the first responce to an avc denial is > "OMG there's a security issue with something running on my machine, I > must fix that". True enough, but that (trusting denials are legitimate breaches) is a goal that is not necessarily here yet... while there are still bugs being filed in policy you (or 'average users' such as me and most rawhide testers) have very little chance of knowing which is which. That doesn't mean it is not working... a security problem thats generating denials is only a problem per se when you go and disable selinux thinking 'its just a bug I can ignore these and let it happen'. As long as a bug is filed, and your machine is still enforcing, and someone hasn't found a way around the denials, either the policy will change or Dan is going to post back to that bug report that what is happening is definitely not going to be allowed by policy. Thats when you go fishing for your security issue. Most people probably just go and disable it, assuming denials were from something they were trying to do and a bug prevented them from doing it. I think its very important that rawhide testers be using selinux though because there is no way to prevent policy bugs from getting to release (and the broad userbase from then disabling selinux...) otherwise. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From jonathan.underwood at gmail.com Fri Jan 4 22:57:38 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 4 Jan 2008 22:57:38 +0000 Subject: Another selinux rant In-Reply-To: <16de708d0801041447pa2a6486p7a1f7a15de41d867@mail.gmail.com> References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <645d17210801041430h7ab76f20qee0df7d1f295d23b@mail.gmail.com> <16de708d0801041447pa2a6486p7a1f7a15de41d867@mail.gmail.com> Message-ID: <645d17210801041457m134eb51er61cdc7aa0610a205@mail.gmail.com> On 04/01/2008, Arthur Pemberton wrote: > > 2) User thinks "oh, must be yet another problem with the selinux > > policy" and files a bug. > > Why wouldn't they think "oh the program I am using and which is being > denied by SELInux might have a bug" ? > Because most of the time it's an selinux policy bug. Granted, not always, but often enough to make ones first thought be "oh, must be an selinux problem, Ill turn it off" or "must be an selinux polciy problem I'll run audit2allow and report a bug" - both of which are suggested EVERY TIME by setroubleshoot. A naive user is then led to think that this is the right thing to do in all instances. > > 3) Dan or his team fix the problem with the policy extremely rapidly. > > New policy packages are installed. > > Are you referring to a specific policy? > Yep, the Fedora ones of the last few releases :) > > 4) Goto 1. > > > > The problem is: setroubleshoot teaches average users that avc denials > > come about due to bugs in selinux policy. > > I get the feeling you're refering to some specific incident(s) as I > have never had a avn denial due to a SELinux bug (as far as I can > remember) > > > If there was some massive > > security problem right now on my machine causing avc denials I'd > > probably react by filing a stack of bug reports. This is the > > fundamental problem as it stands with SElinux. > > No offence, but you _really_ should check the message before you file > a bug as is often makes sense. Of course, I know that. Many users may not, however. > Or has SELinux taken a nose dive in F8 > that I don't know about? > No, things are improving all the time.:) > >If it was working, we > > would be in a situation where the first responce to an avc denial is > > "OMG there's a security issue with something running on my machine, I > > must fix that". > > Again, I'm maybe missing information...but that's my first response > when I see an SELinux denial, esp. after it saved me from being rooted > once. > I fear you're in the minority of users. Look over at the users forum/lists and see how many times you see people turning off selinux... J. From jonathan.underwood at gmail.com Fri Jan 4 23:03:10 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 4 Jan 2008 23:03:10 +0000 Subject: Another selinux rant In-Reply-To: <477EB8C9.9030309@gmail.com> References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <645d17210801041430h7ab76f20qee0df7d1f295d23b@mail.gmail.com> <477EB8C9.9030309@gmail.com> Message-ID: <645d17210801041503g7dd72f16x7fd327b26ccfe989@mail.gmail.com> On 04/01/2008, Andrew Farris wrote: > Jonathan Underwood wrote: > > The problem is: setroubleshoot teaches average users that avc denials > > come about due to bugs in selinux policy. If there was some massive > > security problem right now on my machine causing avc denials I'd > > probably react by filing a stack of bug reports. This is the > > fundamental problem as it stands with SElinux. If it was working, we > > would be in a situation where the first responce to an avc denial is > > "OMG there's a security issue with something running on my machine, I > > must fix that". > > True enough, but that (trusting denials are legitimate breaches) is a goal that > is not necessarily here yet... while there are still bugs being filed in policy > you (or 'average users' such as me and most rawhide testers) have very little > chance of knowing which is which. > > That doesn't mean it is not working... a security problem thats generating > denials is only a problem per se when you go and disable selinux thinking 'its > just a bug I can ignore these and let it happen'. > > As long as a bug is filed, and your machine is still enforcing, and someone > hasn't found a way around the denials, either the policy will change or Dan is > going to post back to that bug report that what is happening is definitely not > going to be allowed by policy. Thats when you go fishing for your security issue. > Yep, exactly. And in fact that's exactly what's happening - a good example is a bug I filed against the SElinux policy which turned out to be another program leaking file descriptors. I worry though, because setroubleshoot suggests, amongst other things, running audit2allow to allow whatever behaviour prompted the avc denial. That's obviously very dangerous if you do it without knowing what you're allowing. > Most people probably just go and disable it, assuming denials were from > something they were trying to do and a bug prevented them from doing it. I > think its very important that rawhide testers be using selinux though because > there is no way to prevent policy bugs from getting to release (and the broad > userbase from then disabling selinux...) otherwise. > Agreed, certainly. j. From pemboa at gmail.com Fri Jan 4 23:03:10 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 4 Jan 2008 17:03:10 -0600 Subject: Another selinux rant In-Reply-To: <645d17210801041457m134eb51er61cdc7aa0610a205@mail.gmail.com> References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <645d17210801041430h7ab76f20qee0df7d1f295d23b@mail.gmail.com> <16de708d0801041447pa2a6486p7a1f7a15de41d867@mail.gmail.com> <645d17210801041457m134eb51er61cdc7aa0610a205@mail.gmail.com> Message-ID: <16de708d0801041503s598b5062ve669643465d29a1@mail.gmail.com> On Jan 4, 2008 4:57 PM, Jonathan Underwood wrote: > Because most of the time it's an selinux policy bug. Granted, not > always, but often enough to make ones first thought be "oh, must be an > selinux problem, Ill turn it off" or "must be an selinux polciy > problem I'll run audit2allow and report a bug" - both of which are > suggested EVERY TIME by setroubleshoot. A naive user is then led to > think that this is the right thing to do in all instances. I have to say, it appears that my experiences with SELinux have been much different from yours. I must admit however, that I do not run SELinux on my desktops, maybe that's the issue -- I don't connect my desktop directly to the internet either however, nor do I store that much data on them. > I fear you're in the minority of users. Look over at the users > forum/lists and see how many times you see people turning off > selinux... Have you considered the possibility of a large silent majority for whom it works most of the time and so need not complain? Not that valid complaints are a bad thing. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From eswierk at arastra.com Fri Jan 4 23:24:37 2008 From: eswierk at arastra.com (Ed Swierk) Date: Fri, 4 Jan 2008 15:24:37 -0800 Subject: Another selinux rant In-Reply-To: <16de708d0801041503s598b5062ve669643465d29a1@mail.gmail.com> References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <645d17210801041430h7ab76f20qee0df7d1f295d23b@mail.gmail.com> <16de708d0801041447pa2a6486p7a1f7a15de41d867@mail.gmail.com> <645d17210801041457m134eb51er61cdc7aa0610a205@mail.gmail.com> <16de708d0801041503s598b5062ve669643465d29a1@mail.gmail.com> Message-ID: On 1/4/08, Arthur Pemberton wrote: > Have you considered the possibility of a large silent majority for > whom it works most of the time and so need not complain? Not that > valid complaints are a bad thing. Without actual data it's impossible to know what the silent majority is doing (although I have my suspicions). Is this a statistic that the automatic hardware profiling whatchamacallit can help collect? --Ed From pemboa at gmail.com Fri Jan 4 23:26:33 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 4 Jan 2008 17:26:33 -0600 Subject: Another selinux rant In-Reply-To: References: <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <645d17210801041430h7ab76f20qee0df7d1f295d23b@mail.gmail.com> <16de708d0801041447pa2a6486p7a1f7a15de41d867@mail.gmail.com> <645d17210801041457m134eb51er61cdc7aa0610a205@mail.gmail.com> <16de708d0801041503s598b5062ve669643465d29a1@mail.gmail.com> Message-ID: <16de708d0801041526u4fbd8eeiea5bd1410b1ba36a@mail.gmail.com> On Jan 4, 2008 5:24 PM, Ed Swierk wrote: > On 1/4/08, Arthur Pemberton wrote: > > Have you considered the possibility of a large silent majority for > > whom it works most of the time and so need not complain? Not that > > valid complaints are a bad thing. > > Without actual data it's impossible to know what the silent majority > is doing (although I have my suspicions). Is this a statistic that the > automatic hardware profiling whatchamacallit can help collect? I don't know, just attempting to provide an alternate view point. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From pboy at barkhof.uni-bremen.de Fri Jan 4 23:39:33 2008 From: pboy at barkhof.uni-bremen.de (Peter Boy) Date: Fri, 04 Jan 2008 23:39:33 +0000 Subject: Is anyone packaging sage? In-Reply-To: <604aa7910801041406x7203c9fbq6485bd4b7e481281@mail.gmail.com> References: <604aa7910801041406x7203c9fbq6485bd4b7e481281@mail.gmail.com> Message-ID: <1199489973.2952.5.camel@shuttle.athome.de> Am Freitag, den 04.01.2008, 13:06 -0900 schrieb Jeff Spaleta: > On Jan 4, 2008 1:01 PM, Neal Becker wrote: > > http://sage.math.washington.edu/sage/ > > holy crap.... that looks pretty awesome. Just for information: what is specifically crap according to your perspective (I'm looking for open source scientific software and it's a serious question)? From jwboyer at gmail.com Fri Jan 4 23:49:04 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 4 Jan 2008 17:49:04 -0600 Subject: Is anyone packaging sage? In-Reply-To: <1199489973.2952.5.camel@shuttle.athome.de> References: <604aa7910801041406x7203c9fbq6485bd4b7e481281@mail.gmail.com> <1199489973.2952.5.camel@shuttle.athome.de> Message-ID: <20080104174904.38499014@vader.jdub.homelinux.org> On Fri, 04 Jan 2008 23:39:33 +0000 Peter Boy wrote: > Am Freitag, den 04.01.2008, 13:06 -0900 schrieb Jeff Spaleta: > > On Jan 4, 2008 1:01 PM, Neal Becker wrote: > > > http://sage.math.washington.edu/sage/ > > > > holy crap.... that looks pretty awesome. > > Just for information: what is specifically crap according to your > perspective (I'm looking for open source scientific software and it's a > serious question)? Holy crap is slang. It's akin to "Oh wow", or "Holy cow", or "Gee Wiz". Jeff wasn't saying the software was crappy. He was expressing excitement. josh From casimiro.barreto at gmail.com Fri Jan 4 23:53:00 2008 From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto) Date: Fri, 04 Jan 2008 21:53:00 -0200 Subject: Cannot upgrade from Rel 7 to Rel 8 In-Reply-To: <43710.131.211.184.75.1199272634.squirrel@mail.kanarip.com> References: <477B6572.6050602@gmail.com> <43710.131.211.184.75.1199272634.squirrel@mail.kanarip.com> Message-ID: <477EC6DC.4000703@gmail.com> Jeroen van Meeuwen escreveu: > Casimiro de Almeida Barreto wrote: > >> Hello, >> >> Last week I tried to upgrade from Rel. 7 to Rel. 8. System got stuck >> > (...) >> If someone had the same problem and was able to fix it, please >> > suggestions (other than simply reinstalling everything) will be > really welcome. > > > The Fedora Unity Re-Spin at http://spins.fedoraunity.org/spins will fix > this. > > Mount the original DVD somewhere, and use: > > jigdo-lite --scan /mount/point/of/original/dvd \ > http://jigdo.fedoraunity.org/templates/20071218/Fedora-Unity-20071218-8.jigdo > > Kind regards, > > Jeroen van Meeuwen > -kanarip > > > > > Thanks for all who helped me. And you all excuse-me for not going into bugzilla first place... After upgrading, there were a little issue with PAM. As I use encrypted fs, I had to save modified files in /etc/pam.d and restore the *.rpmsave files. Best regards, Casimiro -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.underwood at gmail.com Fri Jan 4 23:54:11 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 4 Jan 2008 23:54:11 +0000 Subject: Another selinux rant In-Reply-To: <16de708d0801041503s598b5062ve669643465d29a1@mail.gmail.com> References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <645d17210801041430h7ab76f20qee0df7d1f295d23b@mail.gmail.com> <16de708d0801041447pa2a6486p7a1f7a15de41d867@mail.gmail.com> <645d17210801041457m134eb51er61cdc7aa0610a205@mail.gmail.com> <16de708d0801041503s598b5062ve669643465d29a1@mail.gmail.com> Message-ID: <645d17210801041554x527b050g513e9ec3bdd88744@mail.gmail.com> On 04/01/2008, Arthur Pemberton wrote: > Have you considered the possibility of a large silent majority for > whom it works most of the time and so need not complain? Not that > valid complaints are a bad thing. > That could be the case. Perhaps there's something that could be added to Smolt to allow the history of avc denials to be uploaded as part of the profile - that would allow some really interesting analysis. My main point really is about the advice that setroubleshoot gives, as detailed previously. J. From jspaleta at gmail.com Fri Jan 4 23:54:15 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 4 Jan 2008 14:54:15 -0900 Subject: Is anyone packaging sage? In-Reply-To: <20080104174904.38499014@vader.jdub.homelinux.org> References: <604aa7910801041406x7203c9fbq6485bd4b7e481281@mail.gmail.com> <1199489973.2952.5.camel@shuttle.athome.de> <20080104174904.38499014@vader.jdub.homelinux.org> Message-ID: <604aa7910801041554g5023f318mabf1345ef89b0ce8@mail.gmail.com> On Jan 4, 2008 2:49 PM, Josh Boyer wrote: > Holy crap is slang. It's akin to "Oh wow", or "Holy cow", or "Gee > Wiz". Jeff wasn't saying the software was crappy. He was expressing > excitement. I'm so excited by this, that I'm contacting all the physics and math educators that I personally know and getting them to take a look at this. An open source... competitor to Maple or Mathematica with a a web browser interface is a huge huge thing. It doesn't have to be feature complete compared to the competition.. it just has to be good enough to get it in the door at schools and easy enough for teachers and studdents to use. I really want to put a few demonstrations setups of sage together as quickly as i can and have educators and students beat on it. This is a non-trivial thing. -jef From wart at kobold.org Fri Jan 4 23:51:44 2008 From: wart at kobold.org (Michael Thomas) Date: Fri, 04 Jan 2008 15:51:44 -0800 Subject: Is anyone packaging sage? In-Reply-To: References: Message-ID: <477EC690.9030904@kobold.org> Neal Becker wrote: > http://sage.math.washington.edu/sage/ Note that the name 'sage' conflicts with another package that already lives in Fedora: https://admin.fedoraproject.org/pkgdb/packages/name/sage --Wart From skvidal at fedoraproject.org Fri Jan 4 23:57:03 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 04 Jan 2008 18:57:03 -0500 Subject: Is anyone packaging sage? In-Reply-To: <477EC690.9030904@kobold.org> References: <477EC690.9030904@kobold.org> Message-ID: <1199491023.31514.9.camel@cutter> On Fri, 2008-01-04 at 15:51 -0800, Michael Thomas wrote: > Neal Becker wrote: > > http://sage.math.washington.edu/sage/ > > Note that the name 'sage' conflicts with another package that already > lives in Fedora: > > https://admin.fedoraproject.org/pkgdb/packages/name/sage then calling it sagemath solves that, right? -sv From kevin at scrye.com Sat Jan 5 00:10:08 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Fri, 4 Jan 2008 17:10:08 -0700 Subject: Fwd: closing out old bugs of unmaintained releases In-Reply-To: <477EA9DA.9040202@gmail.com> References: <20080104140746.62518306@ghistelwchlohm.scrye.com> <477EA9DA.9040202@gmail.com> Message-ID: <20080104171008.3cc6db16@ghistelwchlohm.scrye.com> On Fri, 04 Jan 2008 13:49:14 -0800 lordmorgul at gmail.com (Andrew Farris) wrote: > Kevin Fenzi wrote: > > Note that you might want to wait until after fudcon and until you > > have gotten input from everyone before doing anything hasty... > > Probably a good idea to not be hasty on a large step like this, but > the same problem has been around since FC1 (forever?). Yeah, indeed. But I think thats part of the problem.... We get backloged and the first thought is to do something about the backlog, but that doesn't really solve the problem, just keeps us in a cycle. I think we need to look at the entire problem and come up with a full solution, or at least a full attempted solution. I think there are several problems here: 1. There is a big backlog of bugs that aren't getting attention. 2. There are more bugs flowing in than maintainers are dealing with, which adds to the backlog over time. 3. Some high profile packages have so many new bugs that there is no way any single maintainer could handle them. 4. There is no flow from/to upstream projects (or very little). I know from my own Xfce bugs when something is a upstream issue, I usually file the upstream bug, follow it and then close the fedora bug when it's fixed upstream or a patch is available. Thats very very labor intensive. I think most people are concentrating on the backlog issue to the exclusion of all the other issues, and I think those need solutions before doing anything to the backlog makes sense. For issue 2 above, perhaps if we have a triage team in place that tried to triage all the incoming bugs as they were submitted it might assist with issue 3 at least, as they could close dups, gather more info or perhaps close bugs that were notabug/wontfix and save maintainer time. Packages like the kernel and rpm are going to need their own teams of people. The upstream/downstream issue might be helped by things like OpenID. For problems 2 and 3, refer to: http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus#head-181b0c70022aca0d7aa42d42f7ed12a553189882 for maintainers with the most bugs. I don't have any wonderful answers, but I think we should look at the entire picture here and come up with a way to address the inflow first, and then look at the backlog as we are more able to keep up. > > See: http://www.jwz.org/doc/cadt.html > > He may have a point of interest there, but like it or not new code > bases get released. This is something the upstream project leads > need to consider thoughtfully, not so much those working with the > bugs later. Sure it is... If the bug is reproducable, can't you check and see if it still happens in the new version? Or if not get the reporter to try? Or if the new version doesn't have that functionality, close the issue, or the like... > Eeww, moving bugs across releases is a worse idea than mass closing > frankly. The rate that major things change in fedora is too rapid to > do this and hope that the bugs can be figured out... the second you > try this you've got to go back and ask 'ok which version of xx and xx > and xx and xx were installed' when thats not necessarily as important > if you know the release. (think changes in gcc and glibc from release > to release) Sure, but if the reporter doesn't respond, or the maintainer can't reproduce on the current release, then they can close it... instead of forcing the submitter to re-open it. A lot of people will just not want to deal with the hassle. > If you want to avoid bug reporter frustration then confusing the hell > out of them is a bad idea too. It is far simpler to ask bugs to be > refiled or edited to indicate they still apply to new releases after > the reporter figures out that they do. If it's easy for them to do so. > Why cannot the bugs be left open and just simply filtered by non-EOL > releases? This would feel a little bit less like your work as a bug > reporter is being ignored (while it still is for those bugs). The > maintainers would be able to look at open old bugs if they know the > code base is still shared, and easily filtered if its not. But at > the same time no matter what is done, those bug reporters should be > upgrading and identifying if the bugs still exist in new releases, so > something should be done to indicate to them that the old bugs are > stale. Thats no good in my opinion, because then the bugs would be ignored. You might as well close them and tell the submitter for sure the bug isn't going to be dealt with. > Would it be possible to choose a preset response for these bugs now, > but not apply them in mass closing... then asking bug triage to close > those bugs as quickly as possible where 1) the release is EOL, 2) the > component has changed major versions from that EOL release to > current. Bugs that are for EOL releases but have similar component > versions in new releases should be left open as they probably still > apply. I suspect closing those alone would have a big impact in the > number of bugs still open. Perhaps. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wart at kobold.org Sat Jan 5 00:23:16 2008 From: wart at kobold.org (Michael Thomas) Date: Fri, 04 Jan 2008 16:23:16 -0800 Subject: Is anyone packaging sage? In-Reply-To: <1199491023.31514.9.camel@cutter> References: <477EC690.9030904@kobold.org> <1199491023.31514.9.camel@cutter> Message-ID: <477ECDF4.4040106@kobold.org> seth vidal wrote: > On Fri, 2008-01-04 at 15:51 -0800, Michael Thomas wrote: >> Neal Becker wrote: >>> http://sage.math.washington.edu/sage/ >> Note that the name 'sage' conflicts with another package that already >> lives in Fedora: >> >> https://admin.fedoraproject.org/pkgdb/packages/name/sage > > > then calling it sagemath solves that, right? Sure does. I just wanted to bring up the issue now before it causes problems later. --Wart From P at draigBrady.com Sat Jan 5 00:38:17 2008 From: P at draigBrady.com (=?ISO-8859-1?Q?P=E1draig_Brady?=) Date: Sat, 5 Jan 2008 00:38:17 +0000 Subject: f8 gripe #3: infamous Load_Cycle_Count started hitting my laptop, FAQ? In-Reply-To: <477AE01A.6060302@filteredperception.org> References: <477AE01A.6060302@filteredperception.org> Message-ID: <477ED179.3080304@draigBrady.com> Douglas McClendon wrote: > Last gripe for the night- > > The infamous ubuntu Load_Cycle_Count laptop drive killer issue started > hitting me when I upgraded from F7 to F8. I noticed this "issue" with FC4 and F7. After upgrading to F8 things were much better because relatime is used by default for all mounts: http://www.redhat.com/archives/fedora-devel-list/2007-October/msg02324.html http://www.pixelbeat.org/docs/hard_disk_reliability/ P?draig. From ndbecker2 at gmail.com Sat Jan 5 00:50:08 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 04 Jan 2008 19:50:08 -0500 Subject: Is anyone packaging sage? References: <604aa7910801041406x7203c9fbq6485bd4b7e481281@mail.gmail.com> Message-ID: Jeff Spaleta wrote: > On Jan 4, 2008 1:01 PM, Neal Becker wrote: >> http://sage.math.washington.edu/sage/ > > holy crap.... that looks pretty awesome. > > I can't be primary maintainer for this, but if you are going to work > on it I can help. > > -jef I'm happy to hear that others are interested in this too. Here is a link that I think will be helpful: http://wiki.sagemath.org/DebianSAGE I have just been discussing this with one of the Debian sage developers. There are several sage-related groups available through gmane (I think they are mirrors of google groups) From lkundrak at redhat.com Sat Jan 5 01:12:33 2008 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Sat, 05 Jan 2008 02:12:33 +0100 Subject: Cristian Balint seems to be a non-responsive maintainer In-Reply-To: <1199405195.3435.192.camel@localhost.localdomain> References: <7hfxxejxq6.fsf@allele2.eebweb.arizona.edu> <477D73B7.6050202@redhat.com> <1199405195.3435.192.camel@localhost.localdomain> Message-ID: <1199495553.21972.13.camel@localhost.localdomain> On Thu, 2008-01-03 at 16:06 -0800, Devrim G?ND?Z wrote: > On Thu, 2008-01-03 at 18:45 -0500, Tom "spot" Callaway wrote: > > > > ACLs have been opened for cvsextras on: > > > > gdal, grass, mapserver > > > I've packaged gdal, mapserver and grass for my company about a year ago. > I can work on these packages it noone beats me. I think that would be appreciated. -- Lubomir Kundrak (Red Hat Security Response Team) From lkundrak at redhat.com Sat Jan 5 01:14:04 2008 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Sat, 05 Jan 2008 02:14:04 +0100 Subject: Cristian Balint seems to be a non-responsive maintainer In-Reply-To: <477D73B7.6050202@redhat.com> References: <7hfxxejxq6.fsf@allele2.eebweb.arizona.edu> <477D73B7.6050202@redhat.com> Message-ID: <1199495644.21972.16.camel@localhost.localdomain> On Thu, 2008-01-03 at 18:45 -0500, Tom "spot" Callaway wrote: > Alex Lancaster wrote: > > Hi there, > > > > As per the policy[1], I'm making formal request to mark Cristian > > Balint as an non-responsive maintainer. Repeated attempts over the > > last few months via bugzilla have not been responded to, two examples: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=341391 (grass) > > > > https://bugzilla.redhat.com/show_bug.cgi?id=414441 (gdal) > > > > Lack of reponse has meant that all packages related to various GIS > > packages such as gdal, grass, mapserver have languished with broken > > deps in rawhide for over a month. Also, he has not rebuilt a single > > package via koji since 02 August 2007 [2] and is not listed as being > > on vacation[3]. > > > > Before mass orphaning, at the very least, I recommend that ACLs for > > cvsextras members be opened up on his packages to allow rebuilds of > > these packages in rawhide, especially since these GIS packages aren't > > packages that usually ship by default on any spin and are very much > > leaf packages. > > cbalint is no longer with RHAT, which may be why he has not responded to > any issues. > > ACLs have been opened for cvsextras on: > > fftw2, gdal, grass, iverilog, libdap, libgeotiff, mapserver, and ogdi I'm wondering if Christian would be willing to work on the packages anymore. I am putting him to Cc with hope that he'll respond and eventually change his FAS and Bugzilla address to point to his current e-mail address. -- Lubomir Kundrak (Red Hat Security Response Team) From lkundrak at redhat.com Sat Jan 5 01:24:21 2008 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Sat, 05 Jan 2008 02:24:21 +0100 Subject: Wiki Migration In-Reply-To: <4762E5F5.4010206@redhat.com> References: <4762E5F5.4010206@redhat.com> Message-ID: <1199496261.21972.20.camel@localhost.localdomain> On Fri, 2007-12-14 at 14:22 -0600, Mike McGrath wrote: > Ok, I'm just throwing this out there for discussion. > > We would like to migrate from Moin to another wiki. No idea if anyone already mentioned, nor if it's already pertinent to propose features now, but I would appreciate if the new wiki hand WikiRPC XML-RPC interface. And... is one enable in our moin now? Thanks, -- Lubomir Kundrak (Red Hat Security Response Team) From pboy at barkhof.uni-bremen.de Sat Jan 5 01:25:30 2008 From: pboy at barkhof.uni-bremen.de (Peter Boy) Date: Sat, 05 Jan 2008 02:25:30 +0100 Subject: Is anyone packaging sage? In-Reply-To: <604aa7910801041554g5023f318mabf1345ef89b0ce8@mail.gmail.com> References: <604aa7910801041406x7203c9fbq6485bd4b7e481281@mail.gmail.com> <1199489973.2952.5.camel@shuttle.athome.de> <20080104174904.38499014@vader.jdub.homelinux.org> <604aa7910801041554g5023f318mabf1345ef89b0ce8@mail.gmail.com> Message-ID: <1199496330.2952.16.camel@shuttle.athome.de> Am Freitag, den 04.01.2008, 14:54 -0900 schrieb Jeff Spaleta: > I'm so excited by this, that I'm contacting all the physics and math > educators that I personally know and getting them to take a look at > this. > An open source... competitor to Maple or Mathematica with a a web > browser interface is a huge huge thing. It doesn't have to be feature > complete compared to the competition.. it just has to be good enough > to get it in the door at schools and easy enough for teachers and > studdents to use. I really want to put a few demonstrations setups of > sage together as quickly as i can and have educators and students beat > on it. This is a non-trivial thing. Oh, thanks for responding. I'm a statistican in social science research and try to promote free software in my lessons and my own reseach (and didn't know about sage before). Therefore I'm very interested when you finished preparation of some demonstrations! Peter From pboy at barkhof.uni-bremen.de Sat Jan 5 01:26:52 2008 From: pboy at barkhof.uni-bremen.de (Peter Boy) Date: Sat, 05 Jan 2008 01:26:52 +0000 Subject: Is anyone packaging sage? In-Reply-To: <20080104174904.38499014@vader.jdub.homelinux.org> References: <604aa7910801041406x7203c9fbq6485bd4b7e481281@mail.gmail.com> <1199489973.2952.5.camel@shuttle.athome.de> <20080104174904.38499014@vader.jdub.homelinux.org> Message-ID: <1199496412.2952.18.camel@shuttle.athome.de> Am Freitag, den 04.01.2008, 17:49 -0600 schrieb Josh Boyer: > Holy crap is slang. It's akin to "Oh wow", or "Holy cow", or "Gee > Wiz". Jeff wasn't saying the software was crappy. He was expressing > excitement. Oh, what a misunderstanding. I'll work to improve my English language skills :-) Peter From jspaleta at gmail.com Sat Jan 5 01:39:49 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 4 Jan 2008 16:39:49 -0900 Subject: Is anyone packaging sage? In-Reply-To: <1199496330.2952.16.camel@shuttle.athome.de> References: <604aa7910801041406x7203c9fbq6485bd4b7e481281@mail.gmail.com> <1199489973.2952.5.camel@shuttle.athome.de> <20080104174904.38499014@vader.jdub.homelinux.org> <604aa7910801041554g5023f318mabf1345ef89b0ce8@mail.gmail.com> <1199496330.2952.16.camel@shuttle.athome.de> Message-ID: <604aa7910801041739n5a4301abj60f4d7cf2d4d8039@mail.gmail.com> On Jan 4, 2008 4:25 PM, Peter Boy wrote: > Oh, thanks for responding. I'm a statistican in social science research > and try to promote free software in my lessons and my own reseach (and > didn't know about sage before). Therefore I'm very interested when you > finished preparation of some demonstrations! The main sage project website has a link to a demo "Notebook" that you can register with and create worksheets. -jef From devrim at CommandPrompt.com Sat Jan 5 02:36:55 2008 From: devrim at CommandPrompt.com (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=) Date: Fri, 04 Jan 2008 18:36:55 -0800 Subject: Mapserver 5.0.0 for -devel Message-ID: <1199500615.1964.83.camel@localhost.localdomain> Hi, I'm about to push mapserver 5.0.0 for F-9. I intend to apply the attached patch to its java makefile. Is it the correct way to do that? I did the same issue for PostGIS package last month, and I want to make sure that I'm not doing something wrong. Of course, spec now buildrequires eclipse-ecj and libgcj per these changes. BTW, I just submitted mapserver 5.0.0 to koji for testing, and here is the related task: http://koji.fedoraproject.org/koji/taskinfo?taskID=326304 Regards, -- Devrim G?ND?Z , RHCE PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: mapserver-5-java-makefile.patch Type: text/x-patch Size: 382 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From michael.wiktowy at gmail.com Sat Jan 5 02:59:14 2008 From: michael.wiktowy at gmail.com (Michael Wiktowy) Date: Fri, 4 Jan 2008 21:59:14 -0500 Subject: Another selinux rant In-Reply-To: <645d17210801041554x527b050g513e9ec3bdd88744@mail.gmail.com> References: <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <645d17210801041430h7ab76f20qee0df7d1f295d23b@mail.gmail.com> <16de708d0801041447pa2a6486p7a1f7a15de41d867@mail.gmail.com> <645d17210801041457m134eb51er61cdc7aa0610a205@mail.gmail.com> <16de708d0801041503s598b5062ve669643465d29a1@mail.gmail.com> <645d17210801041554x527b050g513e9ec3bdd88744@mail.gmail.com> Message-ID: <3e4ec4600801041859g4eb4ed93md8e58770dd244da3@mail.gmail.com> On Jan 4, 2008 6:54 PM, Jonathan Underwood wrote: > That could be the case. Perhaps there's something that could be added > to Smolt to allow the history of avc denials to be uploaded as part of > the profile - that would allow some really interesting analysis. That is a great idea! Even just something that indicates the proportion of people using enforcing/permissive/disabled. That would be useful to either support or refute the periodic SELinux rant threads based on people's personal usage patterns and seem to take on a life of their own and inevitably lead to statistics being pulled out of thin air. /Mike From tibbs at math.uh.edu Sat Jan 5 03:01:24 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 04 Jan 2008 21:01:24 -0600 Subject: Cristian Balint seems to be a non-responsive maintainer In-Reply-To: <1199495644.21972.16.camel@localhost.localdomain> References: <7hfxxejxq6.fsf@allele2.eebweb.arizona.edu> <477D73B7.6050202@redhat.com> <1199495644.21972.16.camel@localhost.localdomain> Message-ID: >>>>> "LK" == Lubomir Kundrak writes: LK> I'm wondering if Christian would be willing to work on the LK> packages anymore. I am putting him to Cc with hope that he'll LK> respond and eventually change his FAS and Bugzilla address to LK> point to his current e-mail address. I note that he seems to have set up a different fedoraproject account and applied for sponsorship today: ==== Fedora user rezso, aka Balint Cristian has requested membership in the cvsextras group and needs a sponsor. ==== and someone seems to have sponsored him already. - J< From mtasaka at ioa.s.u-tokyo.ac.jp Sat Jan 5 03:55:33 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sat, 05 Jan 2008 12:55:33 +0900 Subject: Cristian Balint seems to be a non-responsive maintainer In-Reply-To: References: <7hfxxejxq6.fsf@allele2.eebweb.arizona.edu> <477D73B7.6050202@redhat.com> <1199495644.21972.16.camel@localhost.localdomain> Message-ID: <477EFFB5.2020305@ioa.s.u-tokyo.ac.jp> Jason L Tibbitts III wrote, at 01/05/2008 12:01 PM +9:00: >>>>>> "LK" == Lubomir Kundrak writes: > > LK> I'm wondering if Christian would be willing to work on the > LK> packages anymore. I am putting him to Cc with hope that he'll > LK> respond and eventually change his FAS and Bugzilla address to > LK> point to his current e-mail address. > > I note that he seems to have set up a different fedoraproject account > and applied for sponsorship today: > > ==== > Fedora user rezso, aka Balint Cristian has requested > membership in the cvsextras group and needs a sponsor. > ==== > > and someone seems to have sponsored him already. Now Jesse is sponsoring him. https://bugzilla.redhat.com/show_bug.cgi?id=414441 Regards, Mamoru From jkeating at redhat.com Sat Jan 5 04:06:17 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 4 Jan 2008 23:06:17 -0500 Subject: Cristian Balint seems to be a non-responsive maintainer In-Reply-To: <477EFFB5.2020305@ioa.s.u-tokyo.ac.jp> References: <7hfxxejxq6.fsf@allele2.eebweb.arizona.edu> <477D73B7.6050202@redhat.com> <1199495644.21972.16.camel@localhost.localdomain> <477EFFB5.2020305@ioa.s.u-tokyo.ac.jp> Message-ID: <20080104230617.160b20b8@redhat.com> On Sat, 05 Jan 2008 12:55:33 +0900 Mamoru Tasaka wrote: > > and someone seems to have sponsored him already. > > Now Jesse is sponsoring him. > https://bugzilla.redhat.com/show_bug.cgi?id=414441 Yep, I talked with Cristian today. He wishes to continue maintaining some of his packages that aren't critical to RHEL. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rezso at rdsor.ro Sat Jan 5 04:13:53 2008 From: rezso at rdsor.ro (Balint Cristian) Date: Sat, 5 Jan 2008 06:13:53 +0200 Subject: Cristian Balint seems to be a non-responsive maintainer In-Reply-To: <1199495644.21972.16.camel@localhost.localdomain> References: <7hfxxejxq6.fsf@allele2.eebweb.arizona.edu> <477D73B7.6050202@redhat.com> <1199495644.21972.16.camel@localhost.localdomain> Message-ID: >> fftw2, gdal, grass, iverilog, libdap, libgeotiff, mapserver, and ogdi > > I'm wondering if Christian would be willing to work on the packages > anymore. I am putting him to Cc with hope that he'll respond and > eventually change his FAS and Bugzilla address to point to his current > e-mail address. > > -- > Lubomir Kundrak (Red Hat Security Response Team) Yes I will do it! I allready submitted "Owner Change" request , CVS+ flag rised up, crossed fingers for cvs admins, once someone grant final ownership rezso at rdsor.ro instead of cbalint at redhat.com than I will proceeed with maintainace immediatly. I am very interested in these packages, must confess these now are part of may day-to-day life/development as the most of the most used tool. Sorry for the private duplicates of this mail, I was puzzled on how to get once more sponsorship for my outside account, thanks goes to Jesse K. for leading me on the sponsorship issue. BTW, If no one pick up fftw2+libdap let me know, i am interested to pick it, just let me know where to follow up with it. I am reasoning on the pick up idea that gdal+GIS suite use fftw2+libdap in a very intrinsic manner, but I know many other packages are olso using it. Thanks to Lubo to get this mail in my attention. ~cristian > > > From rezso at rdsor.ro Sat Jan 5 04:15:37 2008 From: rezso at rdsor.ro (Balint Cristian) Date: Sat, 5 Jan 2008 06:15:37 +0200 Subject: Cristian Balint seems to be a non-responsive maintainer In-Reply-To: <20080104230617.160b20b8@redhat.com> References: <7hfxxejxq6.fsf@allele2.eebweb.arizona.edu><477D73B7.6050202@redhat.com><1199495644.21972.16.camel@localhost.localdomain><477EFFB5.2020305@ioa.s.u-tokyo.ac.jp> <20080104230617.160b20b8@redhat.com> Message-ID: <8F7A51DD1B51485292D6333EC38E5009@Yoda> True. Thanks Jesse for headup ! ~cristian ----- Original Message ----- From: "Jesse Keating" To: Sent: Saturday, January 05, 2008 6:06 AM Subject: Re: Cristian Balint seems to be a non-responsive maintainer > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From Matt_Domsch at dell.com Sat Jan 5 04:53:10 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 4 Jan 2008 22:53:10 -0600 Subject: GPG Keysigning at FUDCon In-Reply-To: <200801030950.10063.silfreed@silfreed.net> References: <20071212214010.GA20896@auslistsprd01.us.dell.com> <20080103024423.GL8896@inocybe.teonanacatl.org> <200801030950.10063.silfreed@silfreed.net> Message-ID: <20080105045310.GD6011@auslistsprd01.us.dell.com> On Thu, Jan 03, 2008 at 09:50:09AM -0500, Douglas E. Warner wrote: > On Wednesday 02 January 2008, Todd Zullinger wrote: > > > I'm volunteering to run a GPG keysigning party at the FUDCon in > > > Raleigh in January. > > > > And thank you for that Matt. ??It should be fun. > > Is there going to be any tequila at the keysigning? [1] > > -Doug > > [1] http://xkcd.com/364/ OK, for that, yes, there will be a bottle of something on hand, most definitely. :-) -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From subhodip at fedoraproject.org Sat Jan 5 04:58:49 2008 From: subhodip at fedoraproject.org (subhodip biswas) Date: Sat, 5 Jan 2008 10:28:49 +0530 Subject: integration of LTSP 5 in fedora In-Reply-To: <539333cb0801040958r5ceb61b3t3d32b413b578d355@mail.gmail.com> References: <539333cb0801040958r5ceb61b3t3d32b413b578d355@mail.gmail.com> Message-ID: <539333cb0801042058j793f301dsfe75747094b0968@mail.gmail.com> hi all ! is anybody looking toward the integration of LTSP 5 in fedora . all i found is a bugid ##234048 . i can help if needed . -- Regards Subhodip Biswas GPG key : FAEA34AB Server : pgp.mit.edu http://subhodipbiswas.wordpress.com http:/www.fedoraproject.org/wiki/SubhodipBiswas From lists at sapience.com Sat Jan 5 05:37:27 2008 From: lists at sapience.com (Mail Lists) Date: Sat, 05 Jan 2008 00:37:27 -0500 Subject: Control center idea In-Reply-To: <16de708d0801041232h395f6a3x7d122de3678ad3fc@mail.gmail.com> References: <1199374110.5023.2.camel@frosty> <200801042254.10646.ljuwaida@fedoraproject.org> <477E7F57.7060103@fedoraproject.org> <200801050017.29769.ljuwaida@fedoraproject.org> <16de708d0801041232h395f6a3x7d122de3678ad3fc@mail.gmail.com> Message-ID: <477F1797.4020700@sapience.com> Have you looked at the KDE control center ? It may be even better place to go ... From rc040203 at freenet.de Sat Jan 5 06:33:43 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 05 Jan 2008 07:33:43 +0100 Subject: Another selinux rant In-Reply-To: <477E67D9.1060808@redhat.com> References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> Message-ID: <1199514823.6022.62.camel@beck.corsepiu.local> On Fri, 2008-01-04 at 12:07 -0500, John Dennis wrote: > Ed Swierk wrote: > > People who already know about SELinux can of course just learn to type > > ls -l --lcontext, but showing the extra information by default would > > at least give clueless users like me a hint that files have these > > extra attributes that might somehow be relevant to those strange > > openvpn failures. IMHO this would be the single best usability > > improvement to SELinux > > Re SELinux usability issues: > > We wrote the setroubleshoot package precisely to help SELinux novice > users so they wouldn't suffer with hidden obscure failures of the type > which have frustrated you. If it had been installed you would have > received notifications in real time on your desktop describing the > failure and suggestions on how to fix it. Well, honorable goal, but does it actually achieve this goal? * On one machine (FC8/x86_64), for me, all setroubleshoot does is to die shortly after bootup and first-time login (I haven't tried to investigate, but as it seems to me some serelated daemon is segfaulting). * Is it appropriate to inform arbitrary ordinary users about SELinux issues? May-be this on single user/non-networked machines, but I don't think this is the right concept for a networked environment in which "ordinary user" normally isn't the system admin. Ralf From tgl at redhat.com Sat Jan 5 06:50:16 2008 From: tgl at redhat.com (Tom Lane) Date: Sat, 05 Jan 2008 01:50:16 -0500 Subject: Another selinux rant In-Reply-To: <1199514823.6022.62.camel@beck.corsepiu.local> References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <1199514823.6022.62.camel@beck.corsepiu.local> Message-ID: <29371.1199515816@sss.pgh.pa.us> Ralf Corsepius writes: > * Is it appropriate to inform arbitrary ordinary users about SELinux > issues? That's a real good point, as are the others made in this thread. I think the bottom line here is that we are still working to get the selinux policies to the point where they work 99% for 99% of users. Once we're there we should switch over to operating behaviors that assume that most violations represent real security problems --- but for now I don't think we are there yet. What the current behaviors need to do is to encourage people to report results, so that we can collect more data about real vs phony violations. regards, tom lane From pemboa at gmail.com Sat Jan 5 07:36:22 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Sat, 5 Jan 2008 01:36:22 -0600 Subject: Another selinux rant In-Reply-To: <1199514823.6022.62.camel@beck.corsepiu.local> References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <1199514823.6022.62.camel@beck.corsepiu.local> Message-ID: <16de708d0801042336n2fe73d69o62afe39c1583eb61@mail.gmail.com> On Jan 5, 2008 12:33 AM, Ralf Corsepius wrote: > > On Fri, 2008-01-04 at 12:07 -0500, John Dennis wrote: > > Ed Swierk wrote: > > > People who already know about SELinux can of course just learn to type > > > ls -l --lcontext, but showing the extra information by default would > > > at least give clueless users like me a hint that files have these > > > extra attributes that might somehow be relevant to those strange > > > openvpn failures. IMHO this would be the single best usability > > > improvement to SELinux > > > > Re SELinux usability issues: > > > > We wrote the setroubleshoot package precisely to help SELinux novice > > users so they wouldn't suffer with hidden obscure failures of the type > > which have frustrated you. If it had been installed you would have > > received notifications in real time on your desktop describing the > > failure and suggestions on how to fix it. > Well, honorable goal, but does it actually achieve this goal? > > * On one machine (FC8/x86_64), for me, all setroubleshoot does is to die > shortly after bootup and first-time login (I haven't tried to > investigate, but as it seems to me some serelated daemon is > segfaulting). You don't possibly think that this is the regular behaviour of setroubleshoot on which you cna judge it? > * Is it appropriate to inform arbitrary ordinary users about SELinux > issues? May-be this on single user/non-networked machines, but I don't > think this is the right concept for a networked environment in which > "ordinary user" normally isn't the system admin. I'm not sure i understand the criticism here. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From pertusus at free.fr Sat Jan 5 09:30:11 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 5 Jan 2008 10:30:11 +0100 Subject: Cristian Balint seems to be a non-responsive maintainer In-Reply-To: References: <7hfxxejxq6.fsf@allele2.eebweb.arizona.edu> <477D73B7.6050202@redhat.com> <1199495644.21972.16.camel@localhost.localdomain> Message-ID: <20080105093011.GB2570@free.fr> On Sat, Jan 05, 2008 at 06:13:53AM +0200, Balint Cristian wrote: > > BTW, > If no one pick up fftw2+libdap let me know, i am interested to pick it, > just let me know where to > follow up with it. I am reasoning on the pick up idea that gdal+GIS suite > use fftw2+libdap > in a very intrinsic manner, but I know many other packages are olso using > it. That's very nice that you are still on board! -- Pat From devrim at CommandPrompt.com Sat Jan 5 09:29:26 2008 From: devrim at CommandPrompt.com (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=) Date: Sat, 05 Jan 2008 01:29:26 -0800 Subject: grass packaging (Re: Cristian Balint seems to be a non-responsive maintainer) In-Reply-To: <8F7A51DD1B51485292D6333EC38E5009@Yoda> References: <7hfxxejxq6.fsf@allele2.eebweb.arizona.edu> <477D73B7.6050202@redhat.com> <1199495644.21972.16.camel@localhost.localdomain> <477EFFB5.2020305@ioa.s.u-tokyo.ac.jp> <20080104230617.160b20b8@redhat.com> <8F7A51DD1B51485292D6333EC38E5009@Yoda> Message-ID: <1199525366.1964.89.camel@localhost.localdomain> Hi, On Sat, 2008-01-05 at 06:15 +0200, Balint Cristian wrote: > True. I updated grass to 6.2.3, just before I saw this e-mail. I did not submit it for building. Now you are back, you may want to review and submit it for building (Uploaded grass-6.2.3-fedora.tar.gz, too). BTW, I could not commit to EL-4 and EL-5 (acl) ... Oh weird, I would fix the changelog for the spec file in devel , but now it seems I cannot commit there, too (I have committed 10 mins before...) Regards, -- Devrim G?ND?Z , RHCE PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pertusus at free.fr Sat Jan 5 09:39:56 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 5 Jan 2008 10:39:56 +0100 Subject: grass packaging (Re: Cristian Balint seems to be a non-responsive maintainer) In-Reply-To: <1199525366.1964.89.camel@localhost.localdomain> References: <7hfxxejxq6.fsf@allele2.eebweb.arizona.edu> <477D73B7.6050202@redhat.com> <1199495644.21972.16.camel@localhost.localdomain> <477EFFB5.2020305@ioa.s.u-tokyo.ac.jp> <20080104230617.160b20b8@redhat.com> <8F7A51DD1B51485292D6333EC38E5009@Yoda> <1199525366.1964.89.camel@localhost.localdomain> Message-ID: <20080105093956.GC2570@free.fr> On Sat, Jan 05, 2008 at 01:29:26AM -0800, Devrim G?ND?Z wrote: > Hi, > > On Sat, 2008-01-05 at 06:15 +0200, Balint Cristian wrote: > > True. > > I updated grass to 6.2.3, just before I saw this e-mail. I did not > submit it for building. Now you are back, you may want to review and > submit it for building (Uploaded grass-6.2.3-fedora.tar.gz, too). I think it would be nice if you comaintain gdal/grass and related packages anyway, it is a big and complicated stack which could only benefit from having more comaintainers. -- Pat From pertusus at free.fr Sat Jan 5 09:44:46 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 5 Jan 2008 10:44:46 +0100 Subject: Mapserver 5.0.0 for -devel In-Reply-To: <1199500615.1964.83.camel@localhost.localdomain> References: <1199500615.1964.83.camel@localhost.localdomain> Message-ID: <20080105094446.GD2570@free.fr> On Fri, Jan 04, 2008 at 06:36:55PM -0800, Devrim G?ND?Z wrote: > Hi, > > I'm about to push mapserver 5.0.0 for F-9. I intend to apply the > attached patch to its java makefile. Is it the correct way to do that? I I am not sure that it is needed. javac and jar are certainly provided by all the java packages in fedora. In my opinion leaving jar and javac and having a BuildRequires java (or java-devel) could be enough. Does libgcj or icedtea java fail to work right? -- Pat From pertusus at free.fr Sat Jan 5 09:48:39 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 5 Jan 2008 10:48:39 +0100 Subject: integration of LTSP 5 in fedora In-Reply-To: <539333cb0801042058j793f301dsfe75747094b0968@mail.gmail.com> References: <539333cb0801040958r5ceb61b3t3d32b413b578d355@mail.gmail.com> <539333cb0801042058j793f301dsfe75747094b0968@mail.gmail.com> Message-ID: <20080105094839.GE2570@free.fr> On Sat, Jan 05, 2008 at 10:28:49AM +0530, subhodip biswas wrote: > hi all ! > > is anybody looking toward the integration of LTSP 5 in fedora . all i > found is a bugid ##234048 . i can help if needed . There has been some work. There is a tracker bug https://bugzilla.redhat.com/show_bug.cgi?id=188611 But I don't know what the status is right now. First K12LTSP packages were to be included, things begun a bit hastily, then stopped half-way. It seems that now the developpement should happen at https://launchpad.net/~ltsp-drivers but I don't know where fedora stuff is in it. Warren Togami and Eric Harrison were the one who lead the ltsp inclusion. -- Pat From alexl at users.sourceforge.net Sat Jan 5 10:10:03 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Sat, 05 Jan 2008 03:10:03 -0700 Subject: Cristian Balint seems to be a non-responsive maintainer In-Reply-To: (Balint Cristian's message of "Sat\, 5 Jan 2008 06\:13\:53 +0200") References: <7hfxxejxq6.fsf@allele2.eebweb.arizona.edu> <477D73B7.6050202@redhat.com> <1199495644.21972.16.camel@localhost.localdomain> Message-ID: >>>>> "BC" == Balint Cristian writes: [...] BC> Yes I will do it! Cristian, Good to hear that you're back! I rebuilt grass/gdal stack on rawhide in your absence. BC> I allready submitted "Owner Change" request , CVS+ flag rised up, BC> crossed fingers for cvs admins, once someone grant final ownership BC> rezso at rdsor.ro instead of cbalint at redhat.com than I will proceeed BC> with maintainace immediatly. If you've been away for a while, you may not be aware that now all package maintainer requests are now done via PackageDB: http://fedoraproject.org/wiki/PackageMaintainers/UsingPackagedb https://admin.fedoraproject.org/pkgdb/ If you have your old FAS password for cbalint, you could login and orphan the package yourself, then relogin with your new one and reclaim them. If you can't login with your old FAS password, you'll have to get an admin to orphan them manually, then you can reclaim then again with your new FAS password. BC> I am very interested in these packages, must confess these now BC> are part of may day-to-day life/development as the most of the BC> most used tool. Sorry for the private duplicates of this mail, I BC> was puzzled on how to get once more sponsorship for my outside BC> account, thanks goes to Jesse K. for leading me on the sponsorship BC> issue. Excellent, also if you could keep ACLs on your packages open (done recently by spot) (i.e. allow commits from other Fedora maintainers by keeping the "cvsextras" checkbox checked) that would be of great help. BC> BTW, If no one pick up fftw2+libdap let me know, i am interested BC> to pick it, just let me know where to follow up with it. I am BC> reasoning on the pick up idea that gdal+GIS suite use fftw2+libdap BC> in a very intrinsic manner, but I know many other packages are BC> olso using it. BC> Thanks to Lubo to get this mail in my attention. Alex From kevin.kofler at chello.at Sat Jan 5 10:29:05 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 5 Jan 2008 10:29:05 +0000 (UTC) Subject: Is anyone packaging sage? References: Message-ID: Neal Becker gmail.com> writes: > http://sage.math.washington.edu/sage/ This looks interesting, and indeed it would be nice to have this in Fedora. I don't know of any existing efforts to package it. One problem will be that they're bundling many third-party components which should be packaged separately: http://sage.math.washington.edu/sage/doc/html/inst/intro.html So the first step is to track down which of these dependencies are in Fedora already, whether they need any patches to work with SAGE, whether they are build-time (BuildRequires) dependencies, run-time (Requires) dependencies or both, whether they're required or optional and package those which are not in Fedora yet. I'd do things in the following order: 1. package required build-time dependencies 2. package required run-time dependencies 3. package as many optional build-time dependencies as possible 4. package SAGE itself 5. package optional run-time dependencies (and decide on a case by case basis whether it makes sense to add them as actual Requires: dependencies to the package or not) Please tell us of your progress and link to any review requests as you submit them. If you need help with the dependencies, please tell us that too. I think we could really use a Mathematics SIG. Count me as interested (I'm a PhD student in Mathematics). I think Rex Dieter is likely to be interested too as he's working as a sysadmin for the Department of Mathematics at UNL. (Of course we're both already very busy with KDE SIG matters though. ;-) ) And as the interest in this thread is showing, there's probably more potentially interested folks. :-) Kevin Kofler From devrim at CommandPrompt.com Sat Jan 5 10:38:10 2008 From: devrim at CommandPrompt.com (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=) Date: Sat, 05 Jan 2008 02:38:10 -0800 Subject: Mapserver 5.0.0 for -devel In-Reply-To: <20080105094446.GD2570@free.fr> References: <1199500615.1964.83.camel@localhost.localdomain> <20080105094446.GD2570@free.fr> Message-ID: <1199529490.1964.92.camel@localhost.localdomain> Hi, On Sat, 2008-01-05 at 10:44 +0100, Patrice Dumas wrote: > > I'm about to push mapserver 5.0.0 for F-9. I intend to apply the > > attached patch to its java makefile. Is it the correct way to do > > that? > > I am not sure that it is needed. javac and jar are certainly provided > by all the java packages in fedora. In my opinion leaving jar and > javac and having a BuildRequires java (or java-devel) could be enough. That's it -- I had missed to install java-1.7.0-icedtea-devel package. Thanks. Let me push mapserver 5.0.0 to -devel now (and fix PostGIS package). Regards, -- Devrim G?ND?Z , RHCE PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From andreas.bierfert at lowlatency.de Sat Jan 5 10:46:48 2008 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Sat, 5 Jan 2008 11:46:48 +0100 Subject: Is anyone packaging sage? In-Reply-To: References: Message-ID: <20080105114648.21720dac@alkaid.a.lan> On Sat, 5 Jan 2008 10:29:05 +0000 (UTC) Kevin Kofler wrote: > I'd do things in the following order: > 1. package required build-time dependencies > 2. package required run-time dependencies > 3. package as many optional build-time dependencies as possible > 4. package SAGE itself > 5. package optional run-time dependencies (and decide on a case by case basis > whether it makes sense to add them as actual Requires: dependencies to the > package or not) Sounds good to me. Would be cool to make a wiki page with these things and let people assign themselves to the packages that are not handled yet... > I think we could really use a Mathematics SIG. Count me as interested (I'm a > PhD student in Mathematics). I think Rex Dieter is likely to be interested > too as he's working as a sysadmin for the Department of Mathematics at UNL. > (Of course we're both already very busy with KDE SIG matters though. ;-) ) > And as the interest in this thread is showing, there's probably more > potentially interested folks. :-) +1 - Andreas -- Andreas Bierfert, B.Sc. | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Sat Jan 5 10:47:53 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 5 Jan 2008 11:47:53 +0100 Subject: Mapserver 5.0.0 for -devel In-Reply-To: <1199529490.1964.92.camel@localhost.localdomain> References: <1199500615.1964.83.camel@localhost.localdomain> <20080105094446.GD2570@free.fr> <1199529490.1964.92.camel@localhost.localdomain> Message-ID: <20080105104753.GH2570@free.fr> On Sat, Jan 05, 2008 at 02:38:10AM -0800, Devrim G?ND?Z wrote: > Hi, > > On Sat, 2008-01-05 at 10:44 +0100, Patrice Dumas wrote: > > > I'm about to push mapserver 5.0.0 for F-9. I intend to apply the > > > attached patch to its java makefile. Is it the correct way to do > > > that? > > > > I am not sure that it is needed. javac and jar are certainly provided > > by all the java packages in fedora. In my opinion leaving jar and > > javac and having a BuildRequires java (or java-devel) could be enough. > > That's it -- I had missed to install java-1.7.0-icedtea-devel package. I think that you should also replace java-gcj-compat-devel by java-devel (maybe above a given version if needed). -- Pat From devrim at CommandPrompt.com Sat Jan 5 10:52:55 2008 From: devrim at CommandPrompt.com (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=) Date: Sat, 05 Jan 2008 02:52:55 -0800 Subject: Cristian Balint seems to be a non-responsive maintainer In-Reply-To: References: <7hfxxejxq6.fsf@allele2.eebweb.arizona.edu> <477D73B7.6050202@redhat.com> <1199495644.21972.16.camel@localhost.localdomain> Message-ID: <1199530375.1964.94.camel@localhost.localdomain> Hi, On Sat, 2008-01-05 at 06:13 +0200, Balint Cristian wrote: > once someone grant final ownership rezso at rdsor.ro instead of > cbalint at redhat.com than I will proceeed with maintainace immediatly. ... and please change the e-mail address in pkgdb -- I'm getting a lot of bounces today ;) Regards, -- Devrim G?ND?Z , RHCE PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From devrim at CommandPrompt.com Sat Jan 5 10:56:32 2008 From: devrim at CommandPrompt.com (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=) Date: Sat, 05 Jan 2008 02:56:32 -0800 Subject: Mapserver 5.0.0 for -devel In-Reply-To: <20080105104753.GH2570@free.fr> References: <1199500615.1964.83.camel@localhost.localdomain> <20080105094446.GD2570@free.fr> <1199529490.1964.92.camel@localhost.localdomain> <20080105104753.GH2570@free.fr> Message-ID: <1199530592.1964.96.camel@localhost.localdomain> Hi, On Sat, 2008-01-05 at 11:47 +0100, Patrice Dumas wrote: > > That's it -- I had missed to install java-1.7.0-icedtea-devel > package. > > I think that you should also replace java-gcj-compat-devel by > java-devel (maybe above a given version if needed). Thanks, fixed. I'm not a java packager actually, and trying to learn... Regards, -- Devrim G?ND?Z , RHCE PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ndbecker2 at gmail.com Sat Jan 5 10:59:59 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Sat, 05 Jan 2008 05:59:59 -0500 Subject: Is anyone packaging sage? References: Message-ID: Kevin Kofler wrote: > Neal Becker gmail.com> writes: >> http://sage.math.washington.edu/sage/ > > This looks interesting, and indeed it would be nice to have this in > Fedora. I don't know of any existing efforts to package it. > > One problem will be that they're bundling many third-party components > which should be packaged separately: > http://sage.math.washington.edu/sage/doc/html/inst/intro.html > > So the first step is to track down which of these dependencies are in > Fedora already, whether they need any patches to work with SAGE, whether > they are build-time (BuildRequires) dependencies, run-time (Requires) > dependencies or both, whether they're required or optional and package > those which are not in Fedora yet. > > I'd do things in the following order: > 1. package required build-time dependencies > 2. package required run-time dependencies > 3. package as many optional build-time dependencies as possible > 4. package SAGE itself > 5. package optional run-time dependencies (and decide on a case by case > basis whether it makes sense to add them as actual Requires: dependencies > to the package or not) > > Please tell us of your progress and link to any review requests as you > submit them. If you need help with the dependencies, please tell us that > too. Here is some info on Debian's packaging effort. Looks like this would be a big effort. http://wiki.sagemath.org/days6/sprint/debian From kevin.kofler at chello.at Sat Jan 5 11:46:02 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 5 Jan 2008 11:46:02 +0000 (UTC) Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 References: <20080103120242.GZ20451@devserv.devel.redhat.com> Message-ID: > redefined/kdelibs3-3.5.8-20.fc9.log This one is caused by the --enable-final hack (which concatenates all source files in a directory into one). It doesn't appear to be fixed yet. In: http://websvn.kde.org/branches/KDE/3.5/kdelibs/khtml/misc/loader_jpeg.cpp?revision=458979&view=markup we probably need another copy of this hack: // on some systems, libjpeg installs its config.h file which causes a conflict // and makes the compiler barf with "XXX already defined". #ifdef HAVE_STDLIB_H #undef HAVE_STDLIB_H #endif at the end of the file to work around this problem. Alternatively, libjpeg could be fixed not to pollute the namespace with that HAVE_STDLIB_H definition in the installed header. > redefined/kdebase3-3.5.8-24.fc9.log This too is caused by --enable-final. There's a fix upstream: http://websvn.kde.org/?view=rev&revision=727634 > redefined/kdewebdev-3.5.8-4.fc9.log Fixed upstream in: http://websvn.kde.org/?view=rev&revision=728436 > fails-even-with-41/kdebindings-3.97.0-6.fc9.log As I said, the problem which shows up even with 4.1 is already fixed in Rawhide. The problem with _XOPEN_SOURCE being redefined probably has to be fixed in sip. sip.h needs to do something like this: #if defined(_XOPEN_SOURCE) #undef _XOPEN_SOURCE #endif before including , as krosspython's pythonconfig.h is already doing. I'll apply the kdebase3 and kdewebdev patches, hoping there aren't more errors hiding. Kevin Kofler From jamatos at fc.up.pt Sat Jan 5 11:04:45 2008 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Sat, 5 Jan 2008 11:04:45 +0000 Subject: Control center idea In-Reply-To: <477F1797.4020700@sapience.com> References: <1199374110.5023.2.camel@frosty> <16de708d0801041232h395f6a3x7d122de3678ad3fc@mail.gmail.com> <477F1797.4020700@sapience.com> Message-ID: <200801051104.45976.jamatos@fc.up.pt> On Saturday 05 January 2008 05:37:27 Mail Lists wrote: > ?Have you looked at the KDE control center ? It may be even better place > to go ... FWIW I like the kde 4 system settings approach more than the control center of kde 3. There are several discussions in the net about the reason for a more slim model. -- Jos? Ab?lio From jamatos at fc.up.pt Sat Jan 5 11:48:40 2008 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Sat, 5 Jan 2008 11:48:40 +0000 Subject: Cristian Balint seems to be a non-responsive maintainer In-Reply-To: References: <7hfxxejxq6.fsf@allele2.eebweb.arizona.edu> <1199495644.21972.16.camel@localhost.localdomain> Message-ID: <200801051148.41186.jamatos@fc.up.pt> On Saturday 05 January 2008 04:13:53 Balint Cristian wrote: > > BTW, > If no one pick up fftw2+libdap let me know, i am interested to pick it, > just let me know where to > follow up with it. I am reasoning on the pick up idea that gdal+GIS suite > use fftw2+libdap > in a very intrinsic manner, but I know many other packages are olso using > it. What is wrong with fftw2? The code is stable and I am not aware of any request other than the creation of an EPEL-5 branch (sorry spot). :-) > ~cristian -- Jos? Ab?lio From jamatos at fc.up.pt Sat Jan 5 11:53:05 2008 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Sat, 5 Jan 2008 11:53:05 +0000 Subject: Is anyone packaging sage? In-Reply-To: References: Message-ID: <200801051153.05616.jamatos@fc.up.pt> On Saturday 05 January 2008 10:59:59 Neal Becker wrote: > Here is some info on Debian's packaging effort. ?Looks like this would be a > big effort. > > http://wiki.sagemath.org/days6/sprint/debian I have sage under my radar as well and I would like to help in the (big) effort. I have been following the (recent) planet sage http://planet.sagemath.org/atom.xml and it has some interesting posts. -- Jos? Ab?lio From pertusus at free.fr Sat Jan 5 12:16:34 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 5 Jan 2008 13:16:34 +0100 Subject: call for texlive related packages maintainers Message-ID: <20080105121634.GA1756@free.fr> Hello, There are packages that are shipped part of texlive, though texlive is not the upstream for those packages. Among those, some are in fedora texlive, as an exception because they were in tetex previously. I personally don't want to maintain them since I maintain enough packages already, but I can review them. In texlive but should be separate: xdvik (xdvi) http://sourceforge.net/projects/xdvi dvpdfm http://gaspra.kettering.edu/dvipdfm/ dvipng http://savannah.nongnu.org/projects/dvipng/ Not in fedora texlive but in upstream texlive: devnag http://devnag.sarovar.org/ detex http://www.cs.purdue.edu/homes/trinkle/detex/ ttf2pt1 http://ttf2pt1.sourceforge.net/ dvi2tty http://www.mesa.nl/pub/dvi2tty/ chktex afm2pl http://tex.aanhet.net/afm2pl/ lcdf-typetools http://www.lcdf.org/type/ As a side note, dvipdfmx maybe should be packaged from the real upstream http://project.ktug.or.kr/dvipdfmx/ but it is not obvious since it is used in texlive. -- Pat From buildsys at redhat.com Sat Jan 5 12:24:14 2008 From: buildsys at redhat.com (Build System) Date: Sat, 5 Jan 2008 07:24:14 -0500 Subject: rawhide report: 20080105 changes Message-ID: <200801051224.m05COEwl021556@porkchop.devel.redhat.com> New package bless High quality, full featured hex editor New package mediatomb MediaTomb - UPnP AV Mediaserver for Linux New package mytop A top clone for MySQL New package perl-Date-Manip A Perl module containing a wide variety of date manipulation routines New package python-ZSI Zolera SOAP Infrastructure Updated Packages: 8Kingdoms-1.1.0-4.fc9 --------------------- * Fri Jan 04 2008 Hans de Goede 1.1.0-4 - Fix divide by zero abort (bz 427485) - Backport various fixes from CVS - Note this still won't work with tcl 8.5, this release is just to keep rawhide in sync with F-8 / F-7 ClanLib-0.8.0-8.fc9 ------------------- * Fri Jan 04 2008 Hans de Goede 0.8.0-8 - Fix building with gcc 4.3 * Sun Oct 21 2007 Hans de Goede 0.8.0-7 - Fix multilib conflicts in generated Reference documentation (bz 340851) * Fri Aug 03 2007 Hans de Goede 0.8.0-6 - Update License tag for new Licensing Guidelines compliance ClanLib06-0.6.5-10.fc9 ---------------------- * Fri Jan 04 2008 Hans de Goede 0.6.5-10 - Fix building with gcc 4.3 CriticalMass-1.0.2-3.fc9 ------------------------ MyPasswordSafe-0.6.7-3.20061216.fc9 ----------------------------------- NetworkManager-1:0.7.0-0.8.svn3204.fc9 -------------------------------------- * Fri Jan 04 2008 Dan Williams - 1:0.7.0-0.8.svn3204 - Fix WPA passphrase hashing on big endian (PPC, Sparc, etc) (rh #426233) * Tue Dec 18 2007 Dan Williams - 1:0.7.0-0.8.svn3181 - Fixes to work better with new libnl (rh #401761) * Tue Dec 18 2007 Dan Williams - 1:0.7.0-0.8.svn3180 - Fix WPA/WPA2 Enterprise Phase2 connections (rh #388471) NetworkManager-openvpn-1:0.7.0-6.svn3205.fc9 -------------------------------------------- * Fri Jan 04 2008 Dan Williams 1:0.7.0-6.svn3205 - Update to latest SVN * Thu Dec 13 2007 Tim Niemueller 1:0.7.0-6.svn3168 - Update to latest SVN snapshot * Thu Dec 06 2007 Dan Williams 1:0.7.0-5.svn3140 - Update to latest SVN snapshot to get stuff working NetworkManager-vpnc-1:0.7.0-0.6.7.svn3204.fc9 --------------------------------------------- * Fri Jan 04 2008 Dan Williams - 1:0.7.0-0.6.7.svn3204 - Support new vpnc 0.4 Cisco UDP Encapsulation option - Fix another crash in the properties applet - Remove upstreamed pcfimport patch alex-2.2-1.fc9 -------------- * Fri Jan 04 2008 Jens Petersen - 2.2-1 - update to 2.2 release * Fri Nov 23 2007 Bryan O'Sullivan - 2.1.0-6 - Exclude alpha * Tue Sep 25 2007 Bryan O'Sullivan - 2.1.0-5 - don't try to build on ppc64 alleggl-0.4.3-2.fc9 ------------------- * Tue Dec 04 2007 Hans de Goede 0.4.3-2 - Fix headers to allow inclusion from c++ programs compiled with gcc 4.3 apt-0.5.15lorg3.93-5.fc9 ------------------------ * Fri Jan 04 2008 Panu Matilainen 0.5.15lorg3.93-5 - fix build with gcc 4.3 ballbuster-1.0-4.fc9 -------------------- * Fri Jan 04 2008 Hans de Goede 1.0-4 - Fix building with gcc 4.3 bc-1.06-32.fc9 -------------- * Fri Jan 04 2008 Zdenek Prikryl 1.06-32 - Added Examples directory into doc - Added bc info file * Fri Dec 14 2007 Stepan Kasal 1.06-31 - Remove bc-1.06-flex.patch - do not run autofoo - fix the Licence tag * Fri Dec 07 2007 Zdenek Prikryl 1.06-30 - Package review (#225611) blitz-0.9-4.fc9 --------------- * Sat Dec 22 2007 Sergio Pascual 0.9-4 - Removed conflicting Makefiles from examples (bug #340751) - Arch dependent gnu/bzconfig.h moved to %libdir/blitz/include/blitz/gnu * Wed Oct 17 2007 Sergio Pascual 0.9-3 - Removed macro in changelog * Tue Oct 16 2007 Sergio Pascual 0.9-2 - Excluding /usr/share/info/dir blt-2.4-20.fc9 -------------- * Fri Jan 04 2008 Sergio Pascual 2.4-20 - Rebuilt for tk 8.5 (added patch) - Following PackagingDrafts/Tcl bluecurve-kde-theme-1.0.0-2.fc9 ------------------------------- boo-0.8.0.2730-8.fc9 -------------------- * Thu Jan 03 2008 Paul F. Johnson 0.8.0-2730-7 - spec fix * Wed Dec 19 2007 Paul F. Johnson 0.8.0-2730-6 - remove ppc build - fix libdir problem for pc file * Sun Dec 16 2007 Paul F. Johnson 0.8.0-2730-5 - reenable ppc boolstuff-0.1.11-4.fc9 ---------------------- * Fri Jan 04 2008 Patrice Dumas 0.1.11-4 - fix gcc 4.3 build bwidget-1.8.0-3.fc9 ------------------- * Thu Jan 03 2008 Marcela Maslanova 1.8.0-3 - rebuild with new tcl8.5, changed abi in spec bzflag-2.0.10-4.fc9 ------------------- * Fri Jan 04 2008 Nils Philippsen 2.0.10-4 - fix headers for C++ with gcc-4.3 compiz-fusion-0.6.0-12.fc9 -------------------------- * Thu Jan 03 2008 Adel Gadllah 0.6.0-12 - Fix build with gcc43 * Sun Dec 30 2007 Adel Gadllah 0.6.0-11 - Fix stupid typo in the patch * Thu Dec 27 2007 Adel Gadllah 0.6.0-10 - Plug small memory leak compiz-fusion-extras-0.6.0-2.fc9 -------------------------------- * Fri Jan 04 2008 Adel Gadllah 0.6.0-2 - Fix build with gcc43 crack-attack-1.1.14-11.fc9 -------------------------- * Thu Dec 04 2008 Hans de Goede 1.1.14-11 - Fix building with gcc 4.3 ds9-5.0-8.fc9 ------------- * Thu Jan 03 2008 Sergio Pascual 5.0-8 - Added patch to build with tcl 8.5 * Thu Jan 03 2008 Sergio Pascual 5.0-7 - Rebuilt for tcl 8.5 (failled) dssi-0.9.1-13.fc9 ----------------- * Thu Jan 03 2008 Anthony Green 0.9.1-13 - Add cstdlib patch for gcc 4.3 support. enigma-1.01-4.1 --------------- * Fri Jan 04 2008 Thorsten Leemhuis - 1.01-4.1 - add enigma-gcc-4.3-ftbfs.patch from debian package firefox-3.0-0.beta2.7.fc9 ------------------------- * Fri Jan 04 2008 Martin Stransky 3.0-0.beta2.7 - removed broken langpack - built against libxul * Thu Jan 03 2008 Martin Stransky 3.0-0.beta2.6 - updated to the latest trunk (20080103) funtools-1.4.0-6.fc9 -------------------- * Fri Jan 04 2008 Sergio Pascual 1.4.0-6 - Tcl files in a separate subpackage - Following PackagingDrafts/Tcl fwbuilder-2.1.16-1.fc9 ---------------------- * Thu Jan 03 2008 Ralf Ertzinger 2.1.16-1 - Update to 2.1.16 - Add patch to enable compilation with GCC4.3 google-perftools-0.94.1-1.fc9 ----------------------------- * Fri Jan 04 2008 Tom "spot" Callaway 0.94.1-1 - bump to 0.94.1 - fix for gcc4.3 - fix unittest link issue gparted-0.3.3-16.fc9 -------------------- * Fri Jan 04 2008 Adam Tkac - 0.3.3-16 - rebuild against new parted * Fri Dec 28 2007 Deji Akingunola - 0.3.3-15 - Explicitly require vim-common (Bug #426769) gpgme-1.1.6-1.fc9 ----------------- * Fri Jan 04 2008 Rex Dieter 1.1.6-1 - gpgme-1.1.6 - multiarch conflicts in gpgme (#341351) grads-1.9b4-22.fc9 ------------------ * Fri Jan 04 2008 Patrice Dumas 1.9b4-22 - rebuild for new libdap soname (indirect dependency through libnc-dap) graphviz-2.16-3.2.fc9 --------------------- * Thu Jan 03 2008 Patrick "Jima" Laughton 2.16-3.2 - Re-added tcl/tk 8.5 patch - Tweaked ming stuff * Thu Jan 03 2008 Alex Lancaster - 2.16-3.1 - Rebuild against new Tcl 8.5 * Wed Dec 12 2007 Patrick "Jima" Laughton 2.16-2 - What the heck? Can't BR stuff that hasn't even gotten reviewed yet. groff-1.18.1.4-11.fc9 --------------------- * Thu Jan 03 2008 Marcela Maslanova - 1.18.1.4-11 - fix for gcc4.3.0 happy-1.17-1.fc9 ---------------- * Fri Jan 04 2008 Jens Petersen - 1.17-1 - update to 1.17 release hplip-2.7.10-3.fc9 ------------------ * Fri Jan 04 2008 Tim Waugh 2.7.10-2 - Don't ship udev rules; instead, grant an ACL for group lp (bug #424331). kde-settings-4.0-7.fc9 ---------------------- * Fri Jan 04 2008 Rex Dieter 4.0-7 - omit legacy/crufy etc/skel bits - -pulseaudio: -Requires: xine-lib-extras (too buggy) kdelibs-6:3.97.0-11.fc9 ----------------------- * Fri Jan 04 2008 Kevin Kofler 3.97.0-11 - force Phonon to use the ALSA default device by default * Wed Jan 02 2008 Kevin Kofler 3.97.0-10 - apply patch by Alex Merry to support FLAC 1.1.3+ in FindFlac.cmake * Sat Dec 22 2007 Kevin Kofler 3.97.0-9 - drop BR aspell-devel on F9+, use only enchant (FeatureDictionary) less-418-1.fc9 -------------- * Fri Jan 04 2008 Zdenek Prikryl - 418-1 - Update to 418 libAfterImage-1.15-3.fc9 ------------------------ * Sat Jan 05 2008 Andreas Bierfert - 1.15-3 - fix #341871 multiarch libcdio-0.79-2.fc9 ------------------ * Fri Jan 04 2008 Adrian Reber - 0.79-2 - fixed security fix (was off by two) libchmxx-0.2-1.fc9 ------------------ * Fri Jan 04 2008 Patrice Dumas 0.2-1 - update to 0.2 libetpan-0.52-4.fc9 ------------------- * Sat Jan 05 2008 Andreas Bierfert - 0.52-4 - fix #342021 multiarch libupnp-1.6.3-3.fc9 ------------------- * Fri Jan 04 2008 Eric Tanguy - 1.6.3-3 - No more building static library libutempter-1.1.5-1.fc9 ----------------------- * Wed Nov 07 2007 Andreas Bierfert - 1.1.5-1 - version upgrade - fix #246063 linuxdoc-tools-0.9.21-14.fc9 ---------------------------- * Fri Jan 04 2008 Ondrej Vasik 0.9.21-14 - texconfig-sys rehash in postun, removal of texhash in post and postun(discussed with Jindrich Novy) * Thu Jan 03 2008 Ondrej Vasik 0.9.21-13 - running texconfig-sys rehash in post to let latex know about new style installed by linuxdoctools mailx-8.1.1-47.fc9 ------------------ * Fri Jan 04 2008 Ivana Varekova - 8.1.1-47 - close file descriptor, test mkstemp output (#427335) mantis-1.1.0-1.fc9 ------------------ * Sat Jan 05 2008 Gianluca Sforna - 1.1.0-1 - new upstream release - rediffed patches - allow local usage out of the box - remove .htaccess files - revert using embedded adodb see http://www.mantisbt.org/bugs/view.php?id=8256 for details - improve description and README.Fedora - Remove unneeded diffutils BR - Updated License field mftrace-1.2.14-3.fc9 -------------------- * Fri Jan 04 2008 Quentin Spencer 1.2.14-3 - Change tetex-fonts dependency to texlive-fonts. mod_python-3.3.1-6 ------------------ * Fri Jan 04 2008 Joe Orton 3.3.1-6 - fix rebuild failure due to new egg-info directory msynctool-0.35-3.fc9 -------------------- notify-python-0.1.1-2.fc9 ------------------------- * Fri Jan 04 2008 - 0.1.1-2 - Resolves bug# 427499: attach_to_status_icon not created force regeneration of pynotify.c ocaml-3.10.0-8.fc9 ------------------ * Fri Jan 04 2008 Gerard Milmeister - 3.10.0-8 - patch for building with tcl/tk 8.5 * Thu Sep 06 2007 Richard W.M. Jones - 3.10.0-7 - Run chrpath to delete rpaths used on some of the stublibs. - Ignore Parsetree module in dependency calculation. - Fixed ocaml-find-{requires,provides}.sh regexp calculation so it doesn't over-match module names. * Mon Sep 03 2007 Richard W.M. Jones - 3.10.0-6 - ocaml-runtime provides ocaml(runtime) = 3.10.0, and ocaml-find-requires.sh modified so that it adds this requires to other packages. Now can upgrade base ocaml packages without needing to rebuild everything else. openal-0.0.9-0.14.20060204cvs.fc9 --------------------------------- * Fri Jan 04 2008 Andreas Bierfert - 0.0.0-0.14-20060204 - fix gcc43 build orca-2.21.4-2.fc9 ----------------- * Fri Jan 04 2008 Matthias Clasen - 2.21.4-2 - Require at-spi-python (#427432) perl-Kwiki-UserName-0.14-6.fc9 ------------------------------ * Fri Jan 04 2008 Ralf Cors??pius 0.14-6 - Update License-tag. - BR: perl(Test::More) (BZ 419631). perl-Tk-804.028-2.fc9 --------------------- * Fri Jan 04 2008 Andreas Bierfert - 804.028-2 - add relevant parts of debian patch - add patch for #235666 pgadmin3-1.8.1-1.fc9 -------------------- * Fri Jan 04 2008 Devrim GUNDUZ 1.8.1-1 - Update to 1.8.1 pidgin-2.3.1-2.fc9 ------------------ * Fri Jan 04 2008 Jason L Tibbitts III - 2.3.1-2 - Bump to rebuild against new tcl. * Fri Dec 07 2007 Stu Tomlinson 2.3.1-1 - 2.3.1 Many bugfixes * Tue Nov 27 2007 Stu Tomlinson - 2.3.0-1 - Fix MSN local display name bug pilot-link-2:0.12.3-3.fc9 ------------------------- * Fri Jan 04 2008 Alex Lancaster - 2:0.12.3-3 - Synchronize with F-8 branch: add HAL, PolicyKit rules (#280251) python-2.5.1-19.fc9 ------------------- * Fri Jan 04 2008 Tom "spot" Callaway - 2.5.1-19 - rebuild for new tcl/tk in rawhide * Fri Dec 07 2007 James Antill - 2.5.1-18 - Create a python-test sub-module, over 3MB of stuff noone wants. - Don't remove egginfo files, try this see what happens ... may revert. - Resolves: rhbz#414711 * Mon Dec 03 2007 Jeremy Katz - 2.5.1-17 - rebuild for new libssl python-alsa-1.0.15-2.fc9 ------------------------ * Fri Jan 04 2008 Andy Shevchenko 1.0.15-2 - include egg-info to the files: catched from rawhide mass rebuild (http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/fails-even-with-41/python-alsa-1.0.15-1.fc8.log) python-crypto-2.0.1-11.1 ------------------------ * Fri Jan 04 2008 Thorsten Leemhuis - 2.0.1-11 - egg-info file in python_sitearch and not in python_sitelib * Fri Jan 04 2008 Thorsten Leemhuis - 2.0.1-10 - ship egg-file python-imaging-1.1.6-8.fc9 -------------------------- * Fri Jan 04 2008 Alex Lancaster - 1.1.6-8 - Egg for PIL library is already in subdirectory, and found by glob. * Fri Jan 04 2008 Alex Lancaster - 1.1.6-7 - python_sitelib -> python_sitearch * Fri Jan 04 2008 Alex Lancaster - 1.1.6-6 - Support for Python Eggs for F9+ python-matplotlib-0.90.1-5.fc9 ------------------------------ * Fri Jan 04 2008 Alex Lancaster - 0.90.1-5 - Fixed typo in spec. * Fri Jan 04 2008 Alex Lancaster - 0.90.1-4 - Support for Python Eggs for F9+ * Thu Jan 03 2008 Alex Lancaster - 0.90.1-3 - Rebuild for new Tcl 8.5 python-musicbrainz2-0.5.0-2.fc9 ------------------------------- * Fri Jan 04 2008 Jeffrey C. Ollie - 0.5.0-2 - Update to build/package egg info files. python-xmpp-0.4.1-2.fc9 ----------------------- * Thu Jan 03 2008 Jeffrey C. Ollie - 0.4.1-2 - Get eggs building correctly on F-7 and F-8. python-zope-interface-3.0.1-9.fc9 --------------------------------- * Fri Jan 04 2008 Paul Howarth 3.0.1-9 - tweak %files list to pull in egg info file when necessary - fix permissions on shared objects (silence rpmlint) rpm-4.4.2.2-12.fc9 ------------------ * Fri Jan 04 2008 Panu Matilainen 4.4.2.2-12 - fix segfault in devel symlink dependency generation from Mark Salter (#338971) - fix debugedit build with gcc 4.3 - drop popt-static build dependency * Thu Nov 15 2007 Panu Matilainen 4.4.2.2-11 - Unbreak debugedit (missing crypto initialization) * Thu Nov 15 2007 Panu Matilainen 4.4.2.2-10 - Initialize NSS as early as possible (#382091) ruby-1.8.6.111-5.fc9 -------------------- * Fri Jan 04 2008 Akira TAGOH - 1.8.6.111-5 - Rebuild. selinux-policy-3.2.5-8.fc9 -------------------------- * Wed Jan 02 2008 Dan Walsh 3.2.5-8 - Change user and staff roles to work correctly with varied perms setroubleshoot-2.0.1-1.fc9 -------------------------- * Fri Jan 04 2008 - 2.0.1-1 - make connection error message persist instead of timeout in browser - updated Brazilian Portuguese translation: Igor Pires Soares - implement uid,username checks - rpc methods now check for authenticated state - fix html handling of summary string - add 'named' messages to status bar, make sure all messages either timeout or are named - fix ordering of menus, resolves bug #427418 - add 'hide quiet' to browser view filtering, resolves bug #427421 - tweak siginfo text formatting - add logon to SECommandLine so that sealert -l works * Fri Dec 28 2007 - 2.0.0-1 - prepare for v2 test release - Completed most work for version 2 of setroubleshoot, prepare for test release - import Dan's changes from the mainline primarily allow_postfix_local_write_mail_spool plugin - escape html, fix siginfo.format_html(), siginfo.format_text() - add async-error signal - change identity to just username - make sure set_filter user validation works and reports error in browser - fix generation of line numbers and host when connected to audispd - add permissive notification, resolves bug #231334: Wording doesn't change for permissive mode - get the uid,gid when a client connects to the server - set_filter now verifies the filter is owned by the user, - resolves bug #288261: setroubleshoot lack of user authentication - remove filter options which weren't being used - change '@' in audit data hostname to '.' - remove restart dialog resolves bug #321171: sealert's dialog after update is higly confusing - fix rpc xml arg - fix handling of host value - tweak what fields are in signature - move data items which had been in 'avc' object into siginfo - clean up siginfo format - large parts of new audit data pipeline working, checkpoint - fix duplicate xml nodes when generating xml tree - audit event can now be xml serialized - switch from using int's for audit record types to strings - avoid conversion headaches and possibilty of not being able to convert a new unknown type - add logic to allow XmlSerialize to be subclassed and init_from_xml_node to be overridden - add support to xml serialize classes AuditEventID, AuditEvent, AuditRecord - use metaclass for xml class init - start adding xml support to audit data classes - Use metaclass to wrap class init - move xml serialization code from signature.py to xml_serialize.py - simplify aspect of the serialization code - add unstructured xml mapping, each xml element name has its content mapped to obj.name - modify xml serialization to be driven by xml contents - general clean up - checkpoint conversion of serialization to use metaclasses - clean up class/data specifications for XmlSerializable - add support for client rpc testing - add changelog entry - add SubProcess class to setroubleshootd in preparation to - run daemon as subprocess so we can gather results and compare them to the expected data we sent - rewrite all plugins to use new v2 audit data - add SubProcess class to setroubleshootd in preparation to run daemon as subprocess so we can gather results and compare them to the expected data we sent - add new test support: add config section 'test', add boolean 'analyze' to config test section, add class TestPluginReportReceiver which is installed if test.analyze is True, it prints analysis report. In test_setroubleshootd send AUDIT_EOE to assure sequential event processing so analysis results have same ordering as events that are sent by test_setroubleshootd - alert signatures now include host information, alerts will be grouped by host * Tue Oct 02 2007 John Dennis - 1.10.7-1 - Fix spec file requires for opening an HTML page In configure.ac search for xdg-open and htmlview in priority order, set variable html_browser_open to the one found, in spec file require xdg-utils for fedora and htmlview for RHEL. - add "Host" column in browser add "Toggle Column Visibility" menu to toggle display of any column on/off - Resolves bug #310261: setroubleshoot notifications aren't throttled - add support for AUDIT_EOE, end-of-event, if AUDIT_EOE immediately emit cached event. Disable timeouts used to flush events if AUDIT_EOE has been seen. sonata-1.3-2.fc9 ---------------- * Fri Jan 04 2008 Micha?? Bentkowski - 1.3-2 - Require python-ZSI starplot-0.95.4-5.fc9 --------------------- * Fri Jan 04 2008 Lubomir Kundrak 0.95.4-5 - Added one missing hunk to the gcc-4.3 patch stellarium-0.9.0-7.fc9 ---------------------- * Thu Jan 03 2008 Lubomir Kundrak 0.9.0-7 - Adding missing includes to fix build with gcc-4.3 - Corrected License tag of -doc subpackage tcl-thread-2.6.5-5.fc9 ---------------------- * Fri Jan 04 2008 - jwboyer at jdub.homelinux.org 2.6.5-5 - Fix build problem caused by path mismatch on 64-bit platforms tcldom-3.1-11.fc9 ----------------- * Thu Jan 03 2008 Wart - 3.1-11 - Rebuild for Tcl 8.5 - Better download URL tclhttpd-3.5.1-18.fc9 --------------------- * Fri Jan 04 2008 Wart - 3.5.1-18 - Fix build problem caused by installation path mismatch on 64-bit platforms * Fri Jan 04 2008 Wart - 3.5.1-17 - Move extensions to tcl-specific directory * Fri Jan 04 2008 Marcela Maslanova - 3.5.1-16 - rebuild for tcl8.5 tclparser-1.4-2.20061030cvs.fc9 ------------------------------- tclxml-3.1-12.fc9 ----------------- * Thu Jan 03 2008 Wart - 3.1-12 - Rebuild for Tcl 8.5 tetex-font-cm-lgc-0.5-9.fc9 --------------------------- * Fri Jan 04 2008 Sarantis Paskalis - 0.5-9 - Drop -fonts requires. tetex-font-kerkis-2.0-15.fc9 ---------------------------- * Fri Jan 04 2008 Sarantis Paskalis - 2.0-15 - Drop requirement for -fonts. - Point source URL to ctan. - Change license to LPPL. tetex-tex4ht-1.0.2007_12_19_2154-1.fc9.1 ---------------------------------------- * Mon Dec 31 2007 Patrice Dumas 1.0.2007_12_19_2154-1.1 - update to 1.0.2007_12_19_2154 - new debian patch, new literate sources - adapt for texlive texlive-2007-7.fc9 ------------------ * Fri Jan 04 2008 Jindrich Novy - 2007-7 - add tetex-fonts virtual provides to main texlive package (#427521) * Wed Jan 02 2008 Jindrich Novy - 2007-6 - unify texlive and texlive-fonts packages and obsolete texlive-fonts (related: #426388) - move subpackages versions to the top of spec file - changes from Patruce Dumas: * remove BuildRequires on texmf packages * don't create .fmt files during the build * ship the ptex.pool file * Mon Dec 17 2007 Jindrich Novy - 2007-5 - add tex virtual provide - BuildRequire texlive-fonts for kpathsea (thanks to Patrice Dumas) texlive-texmf-2007-6.fc9 ------------------------ * Fri Jan 04 2008 Jindrich Novy - 2007-6 - require tex-preview (#425805) tkimg-1.3-0.8.20071018svn.fc9 ----------------------------- * Fri Jan 04 2008 Sergio Pascual 1.3-0.8.20071018svn - Following PackagingDrafts/Tcl w3c-libwww-5.4.1-0.8.20060206cvs.fc9 ------------------------------------ * Sat Jan 05 2008 Andreas Bierfert - 5.4.1-0.8.20060206cvs - fix #343411 multiarch xalan-c-1.10.0-3.fc9 -------------------- xchm-1.13-2.fc9 --------------- * Sat Jan 05 2008 Patrice Dumas 1.13-2 - fixes for gcc 4.3 xpa-2.1.8-5.fc9 --------------- * Thu Jan 03 2008 Sergio Pascual 2.1.8-5 - Following PackagingDrafts/Tcl xplanet-1.2.0-3.fc9 ------------------- * Fri Jan 04 2008 Mamoru Tasaka - 1.2.0-3 - Some misc fixes for g++43 xterm-230-1.fc9 --------------- * Fri Jan 04 2008 Miroslav Lichvar 230-1 - update to 230 Broken deps for i386 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-client - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libcrypto.so.6 csound-tk - 5.03.0-13.fc7.i386 requires libtk8.4.so csound-tk - 5.03.0-13.fc7.i386 requires libtcl8.4.so d4x - 2.5.7.1-3.fc7.i386 requires libssl.so.6 d4x - 2.5.7.1-3.fc7.i386 requires libcrypto.so.6 eggdrop - 1.6.18-12.fc9.i386 requires libtcl8.4.so epiphany-extensions - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires libgtkembedmoz.so expect - 5.43.0-9.fc8.i386 requires libtcl8.4.so expectk - 5.43.0-9.fc8.i386 requires libtk8.4.so expectk - 5.43.0-9.fc8.i386 requires libtcl8.4.so gcl - 2.6.7-15.fc8.i386 requires libtcl8.4.so gcl - 2.6.7-15.fc8.i386 requires libtk8.4.so gnome-web-photo - 0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.i386 requires libgtkembedmoz.so irsim - 9.7.50-1.fc8.i386 requires libtcl8.4.so irsim - 9.7.50-1.fc8.i386 requires libtk8.4.so isdn4k-utils-vboxgetty - 3.2-55.fc8.i386 requires libtcl8.4.so kannel - 1.4.1-5.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 libopensync-plugin-sunbird - 0.22-3.fc7.i386 requires libneon.so.25 libopensync-plugin-sunbird - 0.22-3.fc7.i386 requires libopensync.so.0 libopensync-plugin-sunbird - 0.22-3.fc7.i386 requires libssl.so.6 libopensync-plugin-sunbird - 0.22-3.fc7.i386 requires libcrypto.so.6 libopensync-plugin-synce - 0.22-4.fc8.i386 requires libopensync.so.0 liferea - 1.4.10-1.fc9.i386 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.i386 requires libgtkembedmoz.so magic - 7.4.35-6.fc8.i386 requires libtcl8.4.so magic - 7.4.35-6.fc8.i386 requires libtk8.4.so multisync - 0.91.0-1.fc7.i386 requires libopensync.so.0 multisync - 0.91.0-1.fc7.i386 requires libosengine.so.0 multisync-gui - 0.91.0-1.fc7.i386 requires libopensync.so.0 multisync-gui - 0.91.0-1.fc7.i386 requires libosengine.so.0 netgen - 1.3.7-13.fc9.i386 requires libtcl8.4.so netgen - 1.3.7-13.fc9.i386 requires libtk8.4.so openmsx - 0.6.2-4.fc8.i386 requires libtcl8.4.so plplot - 5.8.0-5.fc9.i386 requires libtcl8.4.so plplot - 5.8.0-5.fc9.i386 requires libtk8.4.so plplot-tk - 5.8.0-5.fc9.i386 requires libtk8.4.so plplot-tk - 5.8.0-5.fc9.i386 requires libtcl8.4.so postgresql-pltcl - 8.2.5-2.fc9.i386 requires libtcl8.4.so pvm-gui - 3.4.5-7.fc6.1.i386 requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.i386 requires libtcl8.4.so python-gammu - 0.22-3.fc8.i386 requires libGammu.so.2 q - 7.10-1.fc9.i386 requires libtcl8.4.so q - 7.10-1.fc9.i386 requires libtk8.4.so qtparted - 0.4.5-15.fc8.i386 requires libparted-1.8.so.6 skencil - 0.6.17-15.20070606svn.fc8.i386 requires libtk8.4.so skencil - 0.6.17-15.20070606svn.fc8.i386 requires libtcl8.4.so tbcload - 1.4-5.20061030cvs.fc8.i386 requires tcl(abi) = 0:8.4 tcl-brlapi - 0.5.0-1.fc8.i386 requires libtcl8.4.so tcl-tcldict - 8.5.2-2.fc8.i386 requires tcl(abi) = 0:8.4 tclcompiler - 1.5-3.20061030cvs.fc8.i386 requires tcl(abi) = 0:8.4 tk-tktreectrl - 2.2.3-2.fc8.i386 requires tcl(abi) = 0:8.4 vkeybd - 0.1.17a-5.fc8.i386 requires tk < 1:8.5 vkeybd - 0.1.17a-5.fc8.i386 requires libtk8.4.so vkeybd - 0.1.17a-5.fc8.i386 requires libtcl8.4.so vtk - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtcl8.4.so xca - 0.6.4-1.fc8.i386 requires libcrypto.so.6 xcircuit - 3.4.27-1.fc9.i386 requires libtk8.4.so xcircuit - 3.4.27-1.fc9.i386 requires libtcl8.4.so Broken deps for x86_64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) csound-tk - 5.03.0-13.fc7.x86_64 requires libtk8.4.so()(64bit) csound-tk - 5.03.0-13.fc7.x86_64 requires libtcl8.4.so()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libssl.so.6()(64bit) eggdrop - 1.6.18-12.fc9.x86_64 requires libtcl8.4.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) expect - 5.43.0-9.fc8.x86_64 requires libtcl8.4.so()(64bit) expect - 5.43.0-9.fc8.i386 requires libtcl8.4.so expectk - 5.43.0-9.fc8.x86_64 requires libtk8.4.so()(64bit) expectk - 5.43.0-9.fc8.x86_64 requires libtcl8.4.so()(64bit) gcl - 2.6.7-15.fc8.x86_64 requires libtcl8.4.so()(64bit) gcl - 2.6.7-15.fc8.x86_64 requires libtk8.4.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) isdn4k-utils-vboxgetty - 3.2-55.fc8.x86_64 requires libtcl8.4.so()(64bit) kazehakase - 0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 libopensync-plugin-sunbird - 0.22-3.fc7.x86_64 requires libssl.so.6()(64bit) libopensync-plugin-sunbird - 0.22-3.fc7.x86_64 requires libneon.so.25()(64bit) libopensync-plugin-sunbird - 0.22-3.fc7.x86_64 requires libcrypto.so.6()(64bit) libopensync-plugin-sunbird - 0.22-3.fc7.x86_64 requires libopensync.so.0()(64bit) libopensync-plugin-synce - 0.22-4.fc8.x86_64 requires libopensync.so.0()(64bit) liferea - 1.4.10-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.x86_64 requires libgtkembedmoz.so()(64bit) magic - 7.4.35-6.fc8.x86_64 requires libtcl8.4.so()(64bit) magic - 7.4.35-6.fc8.x86_64 requires libtk8.4.so()(64bit) multisync - 0.91.0-1.fc7.x86_64 requires libosengine.so.0()(64bit) multisync - 0.91.0-1.fc7.x86_64 requires libopensync.so.0()(64bit) multisync-gui - 0.91.0-1.fc7.x86_64 requires libopensync.so.0()(64bit) multisync-gui - 0.91.0-1.fc7.x86_64 requires libosengine.so.0()(64bit) netgen - 1.3.7-13.fc9.x86_64 requires libtcl8.4.so()(64bit) netgen - 1.3.7-13.fc9.x86_64 requires libtk8.4.so()(64bit) openmsx - 0.6.2-4.fc8.x86_64 requires libtcl8.4.so()(64bit) plplot - 5.8.0-5.fc9.x86_64 requires libtk8.4.so()(64bit) plplot - 5.8.0-5.fc9.x86_64 requires libtcl8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.x86_64 requires libtk8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.x86_64 requires libtcl8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.i386 requires libtk8.4.so plplot-tk - 5.8.0-5.fc9.i386 requires libtcl8.4.so postgresql-pltcl - 8.2.5-2.fc9.x86_64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.x86_64 requires libtk8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.x86_64 requires libtcl8.4.so()(64bit) python-gammu - 0.22-3.fc8.x86_64 requires libGammu.so.2()(64bit) q - 7.10-1.fc9.i386 requires libtcl8.4.so q - 7.10-1.fc9.i386 requires libtk8.4.so qtparted - 0.4.5-15.fc8.x86_64 requires libparted-1.8.so.6()(64bit) skencil - 0.6.17-15.20070606svn.fc8.x86_64 requires libtcl8.4.so()(64bit) skencil - 0.6.17-15.20070606svn.fc8.x86_64 requires libtk8.4.so()(64bit) tbcload - 1.4-5.20061030cvs.fc8.x86_64 requires tcl(abi) = 0:8.4 tcl-brlapi - 0.5.0-1.fc8.x86_64 requires libtcl8.4.so()(64bit) tcl-tcldict - 8.5.2-2.fc8.x86_64 requires tcl(abi) = 0:8.4 tclcompiler - 1.5-3.20061030cvs.fc8.x86_64 requires tcl(abi) = 0:8.4 tk-tktreectrl - 2.2.3-2.fc8.x86_64 requires tcl(abi) = 0:8.4 vkeybd - 0.1.17a-5.fc8.x86_64 requires libtcl8.4.so()(64bit) vkeybd - 0.1.17a-5.fc8.x86_64 requires libtk8.4.so()(64bit) vkeybd - 0.1.17a-5.fc8.x86_64 requires tk < 1:8.5 vtk - 5.0.3-20.fc8.x86_64 requires libtk8.4.so()(64bit) vtk - 5.0.3-20.fc8.x86_64 requires libtcl8.4.so()(64bit) vtk - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-python - 5.0.3-20.fc8.x86_64 requires libtk8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.x86_64 requires libtcl8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.x86_64 requires libtk8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.x86_64 requires libtcl8.4.so()(64bit) xca - 0.6.4-1.fc8.x86_64 requires libcrypto.so.6()(64bit) xcircuit - 3.4.27-1.fc9.x86_64 requires libtk8.4.so()(64bit) xcircuit - 3.4.27-1.fc9.x86_64 requires libtcl8.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-client - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libcrypto.so.6 csound-tk - 5.03.0-13.fc7.ppc requires libtk8.4.so csound-tk - 5.03.0-13.fc7.ppc requires libtcl8.4.so d4x - 2.5.7.1-3.fc7.ppc requires libssl.so.6 d4x - 2.5.7.1-3.fc7.ppc requires libcrypto.so.6 eggdrop - 1.6.18-12.fc9.ppc requires libtcl8.4.so epiphany-extensions - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires libgtkembedmoz.so expect - 5.43.0-9.fc8.ppc64 requires libtcl8.4.so()(64bit) expect - 5.43.0-9.fc8.ppc requires libtcl8.4.so expectk - 5.43.0-9.fc8.ppc requires libtk8.4.so expectk - 5.43.0-9.fc8.ppc requires libtcl8.4.so gnome-web-photo - 0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.ppc requires libgtkembedmoz.so irsim - 9.7.50-1.fc8.ppc requires libtcl8.4.so irsim - 9.7.50-1.fc8.ppc requires libtk8.4.so isdn4k-utils-vboxgetty - 3.2-55.fc8.ppc requires libtcl8.4.so kannel - 1.4.1-5.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 libopensync-plugin-sunbird - 0.22-3.fc7.ppc requires libneon.so.25 libopensync-plugin-sunbird - 0.22-3.fc7.ppc requires libopensync.so.0 libopensync-plugin-sunbird - 0.22-3.fc7.ppc requires libssl.so.6 libopensync-plugin-sunbird - 0.22-3.fc7.ppc requires libcrypto.so.6 libopensync-plugin-synce - 0.22-4.fc8.ppc requires libopensync.so.0 liferea - 1.4.10-1.fc9.ppc requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc requires libgtkembedmoz.so magic - 7.4.35-6.fc8.ppc requires libtcl8.4.so magic - 7.4.35-6.fc8.ppc requires libtk8.4.so monodevelop - 0.17-4.fc9.ppc requires boo multisync - 0.91.0-1.fc7.ppc requires libopensync.so.0 multisync - 0.91.0-1.fc7.ppc requires libosengine.so.0 multisync-gui - 0.91.0-1.fc7.ppc requires libopensync.so.0 multisync-gui - 0.91.0-1.fc7.ppc requires libosengine.so.0 netgen - 1.3.7-13.fc9.ppc requires libtcl8.4.so netgen - 1.3.7-13.fc9.ppc requires libtk8.4.so openmsx - 0.6.2-4.fc8.ppc requires libtcl8.4.so plplot - 5.8.0-5.fc9.ppc requires libtcl8.4.so plplot - 5.8.0-5.fc9.ppc requires libtk8.4.so plplot-tk - 5.8.0-5.fc9.ppc64 requires libtk8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.ppc64 requires libtcl8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.ppc requires libtk8.4.so plplot-tk - 5.8.0-5.fc9.ppc requires libtcl8.4.so postgresql-pltcl - 8.2.5-2.fc9.ppc requires libtcl8.4.so pvm-gui - 3.4.5-7.fc6.1.ppc requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.ppc requires libtcl8.4.so python-gammu - 0.22-3.fc8.ppc requires libGammu.so.2 q - 7.10-1.fc9.ppc requires libtcl8.4.so q - 7.10-1.fc9.ppc requires libtk8.4.so q - 7.10-1.fc9.ppc64 requires libtcl8.4.so()(64bit) q - 7.10-1.fc9.ppc64 requires libtk8.4.so()(64bit) qtparted - 0.4.5-15.fc8.ppc requires libparted-1.8.so.6 skencil - 0.6.17-15.20070606svn.fc8.ppc requires libtk8.4.so skencil - 0.6.17-15.20070606svn.fc8.ppc requires libtcl8.4.so tbcload - 1.4-5.20061030cvs.fc8.ppc requires tcl(abi) = 0:8.4 tcl-brlapi - 0.5.0-1.fc8.ppc requires libtcl8.4.so tcl-tcldict - 8.5.2-2.fc8.ppc requires tcl(abi) = 0:8.4 tclcompiler - 1.5-3.20061030cvs.fc8.ppc requires tcl(abi) = 0:8.4 tk-tktreectrl - 2.2.3-2.fc8.ppc requires tcl(abi) = 0:8.4 vkeybd - 0.1.17a-5.fc8.ppc requires libtk8.4.so vkeybd - 0.1.17a-5.fc8.ppc requires libtcl8.4.so vkeybd - 0.1.17a-5.fc8.ppc requires tk < 1:8.5 vtk - 5.0.3-20.fc8.ppc requires libtcl8.4.so vtk - 5.0.3-20.fc8.ppc requires libtk8.4.so vtk - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc requires libtk8.4.so vtk-python - 5.0.3-20.fc8.ppc requires libtcl8.4.so vtk-python - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc requires libtk8.4.so vtk-tcl - 5.0.3-20.fc8.ppc requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) xca - 0.6.4-1.fc8.ppc requires libcrypto.so.6 xcircuit - 3.4.27-1.fc9.ppc requires libtk8.4.so xcircuit - 3.4.27-1.fc9.ppc requires libtcl8.4.so Broken deps for ppc64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) csound-tk - 5.03.0-13.fc7.ppc64 requires libtk8.4.so()(64bit) csound-tk - 5.03.0-13.fc7.ppc64 requires libtcl8.4.so()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libssl.so.6()(64bit) eggdrop - 1.6.18-12.fc9.ppc64 requires libtcl8.4.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) expect - 5.43.0-9.fc8.ppc64 requires libtcl8.4.so()(64bit) expectk - 5.43.0-9.fc8.ppc64 requires libtk8.4.so()(64bit) expectk - 5.43.0-9.fc8.ppc64 requires libtcl8.4.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) isdn4k-utils-vboxgetty - 3.2-55.fc8.ppc64 requires libtcl8.4.so()(64bit) kazehakase - 0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 libopensync-plugin-sunbird - 0.22-3.fc7.ppc64 requires libssl.so.6()(64bit) libopensync-plugin-sunbird - 0.22-3.fc7.ppc64 requires libneon.so.25()(64bit) libopensync-plugin-sunbird - 0.22-3.fc7.ppc64 requires libcrypto.so.6()(64bit) libopensync-plugin-sunbird - 0.22-3.fc7.ppc64 requires libopensync.so.0()(64bit) libopensync-plugin-synce - 0.22-4.fc8.ppc64 requires libopensync.so.0()(64bit) liferea - 1.4.10-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc64 requires libgtkembedmoz.so()(64bit) magic - 7.4.35-6.fc8.ppc64 requires libtcl8.4.so()(64bit) magic - 7.4.35-6.fc8.ppc64 requires libtk8.4.so()(64bit) netgen - 1.3.7-13.fc9.ppc64 requires libtcl8.4.so()(64bit) netgen - 1.3.7-13.fc9.ppc64 requires libtk8.4.so()(64bit) openmsx - 0.6.2-4.fc8.ppc64 requires libtcl8.4.so()(64bit) perl-Test-AutoBuild-darcs - 1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 plplot - 5.8.0-5.fc9.ppc64 requires libtk8.4.so()(64bit) plplot - 5.8.0-5.fc9.ppc64 requires libtcl8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.ppc64 requires libtk8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.ppc64 requires libtcl8.4.so()(64bit) postgresql-pltcl - 8.2.5-2.fc9.ppc64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ppc64 requires libtk8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ppc64 requires libtcl8.4.so()(64bit) python-gammu - 0.22-3.fc8.ppc64 requires libGammu.so.2()(64bit) q - 7.10-1.fc9.ppc64 requires libtcl8.4.so()(64bit) q - 7.10-1.fc9.ppc64 requires libtk8.4.so()(64bit) qtparted - 0.4.5-15.fc8.ppc64 requires libparted-1.8.so.6()(64bit) skencil - 0.6.17-15.20070606svn.fc8.ppc64 requires libtcl8.4.so()(64bit) skencil - 0.6.17-15.20070606svn.fc8.ppc64 requires libtk8.4.so()(64bit) tbcload - 1.4-5.20061030cvs.fc8.ppc64 requires tcl(abi) = 0:8.4 tcl-brlapi - 0.5.0-1.fc8.ppc64 requires libtcl8.4.so()(64bit) tcl-tcldict - 8.5.2-2.fc8.ppc64 requires tcl(abi) = 0:8.4 tclcompiler - 1.5-3.20061030cvs.fc8.ppc64 requires tcl(abi) = 0:8.4 tk-tktreectrl - 2.2.3-2.fc8.ppc64 requires tcl(abi) = 0:8.4 vkeybd - 0.1.17a-5.fc8.ppc64 requires tk < 1:8.5 vkeybd - 0.1.17a-5.fc8.ppc64 requires libtk8.4.so()(64bit) vkeybd - 0.1.17a-5.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) xcircuit - 3.4.27-1.fc9.ppc64 requires libtk8.4.so()(64bit) xcircuit - 3.4.27-1.fc9.ppc64 requires libtcl8.4.so()(64bit) From opensource at till.name Sat Jan 5 12:28:07 2008 From: opensource at till.name (Till Maas) Date: Sat, 05 Jan 2008 13:28:07 +0100 Subject: Fwd: closing out old bugs of unmaintained releases In-Reply-To: References: Message-ID: <200801051328.13094.opensource@till.name> On Fr Januar 4 2008, Jon Stanley wrote: > I can put some time this weekend into closing out old bugs, however, > before doing so, I wanted to make sure that our messaging is crystal > clear. What I had been doing for kernel bugs is placing them in > NEEDINFO_REPORTER and asking if the problem still existed, etc after > manually reviewing the bugs (some I changed to a current release > because it was mentioned in comments, but not in the version > metadata). However, this won't scale - there's no way that I or > anybody else can reasonably review 3600 bugs for ones that are > incorrectly tagged. This leaves us with ~9000 bugs (F7, F8, and > rawhide) to deal with (still a monumental task). I propose doing > something similar with rawhide bugs that haven't been touched in ~6 > months, not sure of the number of those, haven't looked yet. Here's > the proposed comment to WONTFIX these. I want to get the most input > possible before doing this: I would like it more when first every bug gets marked NEEDINFO_REPORTER and ask him whether or not the problem still exists and in case it does, to adjust the version of the Bug report or close it with e.g. currentrelease. In case the reporter did not respond within two weeks, ping him via bugzilla and then another two weeks later, close the bug with WONTFIX or INSUFFICANT_DATA. This is at least a little better bug reporter experience. This is more or less what I did when I started to comaintain some packages, that had several bugs and the maintainers too little time. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From jonathan.underwood at gmail.com Sat Jan 5 13:08:22 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sat, 5 Jan 2008 13:08:22 +0000 Subject: call for texlive related packages maintainers In-Reply-To: <20080105121634.GA1756@free.fr> References: <20080105121634.GA1756@free.fr> Message-ID: <645d17210801050508m393e631w5fdd0b83c00b1d77@mail.gmail.com> On 05/01/2008, Patrice Dumas wrote: > In texlive but should be separate: > xdvik (xdvi) > http://sourceforge.net/projects/xdvi > The need for this one would disappear if the evince packager would enable the dvi backend in evince (BZ #187381). From pertusus at free.fr Sat Jan 5 13:13:20 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 5 Jan 2008 14:13:20 +0100 Subject: call for texlive related packages maintainers In-Reply-To: <645d17210801050508m393e631w5fdd0b83c00b1d77@mail.gmail.com> References: <20080105121634.GA1756@free.fr> <645d17210801050508m393e631w5fdd0b83c00b1d77@mail.gmail.com> Message-ID: <20080105131320.GC1756@free.fr> On Sat, Jan 05, 2008 at 01:08:22PM +0000, Jonathan Underwood wrote: > On 05/01/2008, Patrice Dumas wrote: > > In texlive but should be separate: > > xdvik (xdvi) > > http://sourceforge.net/projects/xdvi > > > > The need for this one would disappear if the evince packager would > enable the dvi backend in evince (BZ #187381). No, the need for this would not disappear, at least for me. -- Pat From bbbush.yuan at gmail.com Sat Jan 5 13:20:07 2008 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Sat, 5 Jan 2008 21:20:07 +0800 Subject: chmsee (was: Re: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220) Message-ID: <76e72f800801050520n69a07503k2e87817dac2a828d@mail.gmail.com> 2008/1/3, Yuan Yijun : > http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/redefined/chmsee-1.0.0-1.34.fc9.log > I don't know how to fix this one. This is because something changed from warnings to errors, and those codes are in gtkembedmoz/gtkmozembed.h which is provided by xulrunner. The problem is that, gtkmozembed.h should be included before gtkmozembed_internal.h, but it will define those 3 macros which are defined in nscore.h which in turn is included by gtkmozembed_internal.h BTW, gtkmozembed.h checks for nscore_h__ but nscore.h defines nscore_h___. Does it mean I should define nscore_h__ myself so chmsee can be built? [root at mstar xulrunner-sdk-1.9pre]# grep 'nscore_h__\>' * -R gtkembedmoz/gtkmozembed.h:#ifndef nscore_h__ gtkembedmoz/gtkmozembed.h:#endif /* nscore_h__ */ stable/nsComponentManagerUtils.h:#ifndef nscore_h__ unstable/gtkmozembed.h:#ifndef nscore_h__ unstable/gtkmozembed.h:#endif /* nscore_h__ */ unstable/nsComponentManagerUtils.h:#ifndef nscore_h__ xpcom/nsComponentManagerUtils.h:#ifndef nscore_h__ -- bbbush ^_^ From jonathan.underwood at gmail.com Sat Jan 5 13:22:06 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sat, 5 Jan 2008 13:22:06 +0000 Subject: call for texlive related packages maintainers In-Reply-To: <20080105131320.GC1756@free.fr> References: <20080105121634.GA1756@free.fr> <645d17210801050508m393e631w5fdd0b83c00b1d77@mail.gmail.com> <20080105131320.GC1756@free.fr> Message-ID: <645d17210801050522m39d3ca25ibb11de4add26c649@mail.gmail.com> On 05/01/2008, Patrice Dumas wrote: > On Sat, Jan 05, 2008 at 01:08:22PM +0000, Jonathan Underwood wrote: > > On 05/01/2008, Patrice Dumas wrote: > > > In texlive but should be separate: > > > xdvik (xdvi) > > > http://sourceforge.net/projects/xdvi > > > > > > > The need for this one would disappear if the evince packager would > > enable the dvi backend in evince (BZ #187381). > > No, the need for this would not disappear, at least for me. Actually, yeah, having just done a local build of evince with the dvi backend enabled, I concur. There's some convenience issues for a start - evince still doesn't automatically reread a file when it changes on disk (which xdvi does), and there's something not working with source specials in evince as well. From sgrubb at redhat.com Sat Jan 5 13:29:11 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Sat, 5 Jan 2008 08:29:11 -0500 Subject: Disabling selinux question In-Reply-To: References: <200801040858.36273.sgrubb@redhat.com> Message-ID: <200801050829.12065.sgrubb@redhat.com> On Friday 04 January 2008 17:06:55 Linus Walleij wrote: > A user that does not know what the daemons are intended for will not know > for sure whether they can enable and disable it or not. > > Would you accept this patch to /etc/init.d/auditd: I changed some wording, but an improved description will be in the audit daemon 1.6.5 init script which should be out sometime next week. I'll push it to F8 after its been in rawhide a few days. Thanks, -Steve From kevin.kofler at chello.at Sat Jan 5 13:36:45 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 5 Jan 2008 13:36:45 +0000 (UTC) Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 References: <20080103120242.GZ20451@devserv.devel.redhat.com> Message-ID: Kevin Kofler chello.at> writes: > > redefined/kdelibs3-3.5.8-20.fc9.log > This one is caused by the --enable-final hack (which concatenates all source > files in a directory into one). It doesn't appear to be fixed yet. In: > http://websvn.kde.org/branches/KDE/3.5/kdelibs/khtml/misc/loader_jpeg.cpp?revision=458979&view=markup > we probably need another copy of this hack: > // on some systems, libjpeg installs its config.h file which causes a conflict > // and makes the compiler barf with "XXX already defined". > #ifdef HAVE_STDLIB_H > #undef HAVE_STDLIB_H > #endif > at the end of the file to work around this problem. Alternatively, libjpeg > could be fixed not to pollute the namespace with that HAVE_STDLIB_H definition > in the installed header. I filed https://bugzilla.redhat.com/show_bug.cgi?id=427616 against libjpeg. > > fails-even-with-41/kdebindings-3.97.0-6.fc9.log > As I said, the problem which shows up even with 4.1 is already fixed in > Rawhide. The problem with _XOPEN_SOURCE being redefined probably has to be > fixed in sip. sip.h needs to do something like this: > #if defined(_XOPEN_SOURCE) > #undef _XOPEN_SOURCE > #endif > before including , as krosspython's pythonconfig.h is already doing. Actually, Python.h shouldn't be redefining this in the first place (if it's already defined). I filed https://bugzilla.redhat.com/show_bug.cgi?id=427617 against python. Kevin Kofler From kevin.kofler at chello.at Sat Jan 5 13:42:31 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 5 Jan 2008 13:42:31 +0000 (UTC) Subject: chmsee (was: Re: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220) References: <76e72f800801050520n69a07503k2e87817dac2a828d@mail.gmail.com> Message-ID: Yuan Yijun gmail.com> writes: > The problem is that, gtkmozembed.h should be included before > gtkmozembed_internal.h, but it will define those 3 macros which are > defined in nscore.h which in turn is included by > gtkmozembed_internal.h Sounds like a problem in xulrunner then. File a bug against xulrunner. Kevin Kofler From mattdm at mattdm.org Sat Jan 5 13:46:27 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 5 Jan 2008 08:46:27 -0500 Subject: I'm mellllttttttinggg!!! (kernel 2.6.24-0.133.rc6.git8.fc9) Message-ID: <20080105134627.GA17509@jadzia.bu.edu> So, I came back from vacation and updated my rawhide machine to the latest. Firefox 3 is all broke for me (haven't diagnosed that yet) and not having a Firefox 2 package handy that doesn't conflict with xulrunner, I decided to build one. Core temp quickly went to 125C?+ and the computer powered itself off to avoid starting any fires. This doesn't seem to happen with kernel-2.6.24-0.83.rc5.fc9, which I had installed before the break. Oh, it gets hot, but more like 95C?. Processor is an AMD Athlon(tm) 64 Processor 3200+ but I'm running in 32-bit mode. Anyone else seeing this? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From aph at redhat.com Sat Jan 5 13:50:56 2008 From: aph at redhat.com (Andrew Haley) Date: Sat, 5 Jan 2008 13:50:56 +0000 Subject: I'm mellllttttttinggg!!! (kernel 2.6.24-0.133.rc6.git8.fc9) In-Reply-To: <20080105134627.GA17509@jadzia.bu.edu> References: <20080105134627.GA17509@jadzia.bu.edu> Message-ID: <18303.35648.235241.449822@zebedee.pink> Matthew Miller writes: > So, I came back from vacation and updated my rawhide machine to the latest. > Firefox 3 is all broke for me (haven't diagnosed that yet) and not having a > Firefox 2 package handy that doesn't conflict with xulrunner, I decided to > build one. Core temp quickly went to 125C?+ and the computer powered > itself off to avoid starting any fires. > > This doesn't seem to happen with kernel-2.6.24-0.83.rc5.fc9, which I had > installed before the break. Oh, it gets hot, but more like 95C?. Processor > is an AMD Athlon(tm) 64 Processor 3200+ but I'm running in 32-bit mode. > > Anyone else seeing this? This is a hardware problem! Even running all cores 100%, you should have sufficient cooling to prevent this from happening. Don't blame the software. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From devrim at CommandPrompt.com Sat Jan 5 13:51:10 2008 From: devrim at CommandPrompt.com (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=) Date: Sat, 05 Jan 2008 05:51:10 -0800 Subject: Mass bugfix for Tomcat5 Message-ID: <1199541070.1964.112.camel@localhost.localdomain> Hi, I tried to review all 37 open bugs for Tomcat5 tonight. Closed 27 of them, because they are either already fixed, or cannot be reproduced in the current releases. Here is the status of the remaining 10 bugs: 1 bug : needinfo (and probably will be closed) 6 bugs : Fixed in current releases and will be submitted shortly. 3 bugs : Will fix later. I will submit the packages for build in 10 minutes. I'll be happy if you test the packages and report any problems. Kind regards, -- Devrim G?ND?Z , RHCE PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From devrim at CommandPrompt.com Sat Jan 5 13:53:16 2008 From: devrim at CommandPrompt.com (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=) Date: Sat, 05 Jan 2008 05:53:16 -0800 Subject: Mass bugfix for Tomcat5 In-Reply-To: <1199541070.1964.112.camel@localhost.localdomain> References: <1199541070.1964.112.camel@localhost.localdomain> Message-ID: <1199541196.1964.114.camel@localhost.localdomain> Hi, On Sat, 2008-01-05 at 05:51 -0800, Devrim G?ND?Z wrote: > 6 bugs : Fixed in current releases and will be submitted shortly. I mean... Will be fixed in the next release... Regards, -- Devrim G?ND?Z , RHCE PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sgrubb at redhat.com Sat Jan 5 13:55:55 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Sat, 5 Jan 2008 08:55:55 -0500 Subject: I'm mellllttttttinggg!!! (kernel 2.6.24-0.133.rc6.git8.fc9) In-Reply-To: <20080105134627.GA17509@jadzia.bu.edu> References: <20080105134627.GA17509@jadzia.bu.edu> Message-ID: <200801050855.55227.sgrubb@redhat.com> On Saturday 05 January 2008 08:46:27 Matthew Miller wrote: > This doesn't seem to happen with kernel-2.6.24-0.83.rc5.fc9, which I had > installed before the break. Oh, it gets hot, but more like 95C?. Processor > is an AMD Athlon(tm) 64 Processor 3200+ but I'm running in 32-bit mode. > > Anyone else seeing this? I have a Phenom processor and it reads 40C no matter what. When I had a Brisbane processor in the same mb, it was correct. Rebooting and going into the BIOS shows the correct temperature. But # cat /proc/acpi/thermal_zone/THRM/temperature is dead wrong. Not quite the same problem, but if its not able to get the temperature right, it may not be doing other power/thermal policy things right. -Steve From jwboyer at gmail.com Sat Jan 5 13:56:19 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Sat, 5 Jan 2008 07:56:19 -0600 Subject: rawhide report: 20080105 changes In-Reply-To: <200801051224.m05COEwl021556@porkchop.devel.redhat.com> References: <200801051224.m05COEwl021556@porkchop.devel.redhat.com> Message-ID: <20080105075619.4672d078@vader.jdub.homelinux.org> On Sat, 5 Jan 2008 07:24:14 -0500 Build System wrote: > tcl-thread-2.6.5-5.fc9 > ---------------------- > * Fri Jan 04 2008 - jwboyer at jdub.homelinux.org 2.6.5-5 > - Fix build problem caused by path mismatch on 64-bit platforms Er... I'm assuming that's a copy/paste error because I certainly didn't do that and that email address doesn't exist anymore. josh From jamatos at fc.up.pt Sat Jan 5 14:05:00 2008 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Sat, 5 Jan 2008 14:05:00 +0000 Subject: Cristian Balint seems to be a non-responsive maintainer In-Reply-To: <200801051148.41186.jamatos@fc.up.pt> References: <7hfxxejxq6.fsf@allele2.eebweb.arizona.edu> <200801051148.41186.jamatos@fc.up.pt> Message-ID: <200801051405.00384.jamatos@fc.up.pt> On Saturday 05 January 2008 11:48:40 Jos? Matos wrote: > ? The code is stable and I am not aware of any request other than the > creation of an EPEL-5 branch (sorry spot). :-) That Cristian already took care of some months ago... now that I remember. :-) -- Jos? Ab?lio From alexl at users.sourceforge.net Sat Jan 5 14:14:39 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Sat, 05 Jan 2008 07:14:39 -0700 Subject: heads up: tcl and tk 8.5 In-Reply-To: <20080102102228.44c0d545@ghistelwchlohm.scrye.com> (Kevin Fenzi's message of "Wed\, 2 Jan 2008 10\:22\:28 -0700") References: <477B60F0.6020406@redhat.com> <20080102102228.44c0d545@ghistelwchlohm.scrye.com> Message-ID: >>>>> "KF" == Kevin Fenzi writes: KF> On Wed, 02 Jan 2008 11:01:20 +0100 KF> mmaslano at redhat.com (Marcela Maslanova) wrote: > New tcl and tk 8.5 was released. I'd like to push it to rawhide as >> soon as possible. The list of dependent packages could be found in >> this draft: >> https://fedoraproject.org/wiki/MarcelaMaslanova/Draft/tcl8.5 The >> maintainers of dependent packages should fix them according to >> http://fedoraproject.org/wiki/PackagingDrafts/Tcl KF> Can you possibly mail directly at least the primary maintainers of KF> these packages and let them know when you are going to push the KF> update? KF> Many of them might not see this post... Marcela, Can you also post to fedora-devel-announce to get wider distribution? Judging by the high number of broken deps still in rawhide caused by this tcl soname bump, I suspect that many maintainers may not have seen this announcement. Many only subscribe to the -announce list and not devel-list to avoid the high traffic here. (These kind of distro-wide soname bumps that affect many packages should always be posted to fedora-announce). Also, I've noticed that several packages don't rebuild with the new Tcl and have build failures with the following: /usr/include/tcl-private/generic/tclPort.h:27:28: error: tclUnixPort.h: No such file or directory (one example full log is here: http://koji.fedoraproject.org/koji/getfile?taskID=326763&name=build.log) is there any easy fix? Alex From mattdm at mattdm.org Sat Jan 5 14:43:35 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 5 Jan 2008 09:43:35 -0500 Subject: I'm mellllttttttinggg!!! (kernel 2.6.24-0.133.rc6.git8.fc9) In-Reply-To: <18303.35648.235241.449822@zebedee.pink> References: <20080105134627.GA17509@jadzia.bu.edu> <18303.35648.235241.449822@zebedee.pink> Message-ID: <20080105144335.GA21848@jadzia.bu.edu> On Sat, Jan 05, 2008 at 01:50:56PM +0000, Andrew Haley wrote: > This is a hardware problem! Even running all cores 100%, you should > have sufficient cooling to prevent this from happening. Don't blame > the software. Oh, I'm sure it is. However, it doesn't get as hot with the kernel build from a month ago, which seemed worth mentioning. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From myfedora at richip.dhs.org Sat Jan 5 15:13:12 2008 From: myfedora at richip.dhs.org (Richi Plana) Date: Sat, 05 Jan 2008 08:13:12 -0700 Subject: I'm mellllttttttinggg!!! (kernel 2.6.24-0.133.rc6.git8.fc9) In-Reply-To: <18303.35648.235241.449822@zebedee.pink> References: <20080105134627.GA17509@jadzia.bu.edu> <18303.35648.235241.449822@zebedee.pink> Message-ID: <1199545992.12421.6.camel@localhost6.localdomain6> On Sat, 2008-01-05 at 13:50 +0000, Andrew Haley wrote: > This is a hardware problem! Even running all cores 100%, you should > have sufficient cooling to prevent this from happening. Don't blame > the software. I wouldn't always assume that hardware is always protected from damage due to faulty software. There have been a lot of cases in the past where programming inadvertently damaged hardware: the recent Load_Cycle_Count kerfuffle with harddisk drives, burning-out CRT monitors with faulty Modelines, overheating laptops with covers closed and monitor and CPU not going low, etc. The fact that there was a difference indicates, at the least, seemingly more power-consumption for the same amount of work with just a different kernel. Certainly worth investigating. -- Richi Plana From caolanm at redhat.com Sat Jan 5 15:18:05 2008 From: caolanm at redhat.com (Caolan McNamara) Date: Sat, 05 Jan 2008 15:18:05 +0000 Subject: rawhide report: 20080105 changes In-Reply-To: <200801051224.m05COEwl021556@porkchop.devel.redhat.com> References: <200801051224.m05COEwl021556@porkchop.devel.redhat.com> Message-ID: <1199546285.11839.12.camel@Jehannum> FWIW I've now supplied patches to at least get these two built > d4x - 2.5.7.1-3.fc7.i386 requires libssl.so.6 > d4x - 2.5.7.1-3.fc7.i386 requires libcrypto.so.6 as rhbz#427619 > xca - 0.6.4-1.fc8.i386 requires libcrypto.so.6 as rhbz#427620 C. From rezso at rdsor.ro Sat Jan 5 15:39:54 2008 From: rezso at rdsor.ro (Balint Cristian) Date: Sat, 5 Jan 2008 17:39:54 +0200 Subject: Cristian Balint seems to be a non-responsive maintainer In-Reply-To: <1199530375.1964.94.camel@localhost.localdomain> References: <7hfxxejxq6.fsf@allele2.eebweb.arizona.edu><477D73B7.6050202@redhat.com><1199495644.21972.16.camel@localhost.localdomain> <1199530375.1964.94.camel@localhost.localdomain> Message-ID: <7B0454EEFC8048B595B3E053FE2B66FA@Yoda> Hello, pkgdb will be autogenerated once package owner will be changed. Isn't it ? My owner change request cvs+ flags are still pending, I hope it will happen soon. ~cristian ----- Original Message ----- From: "Devrim G?ND?Z" To: "Development discussions related to Fedora" Sent: Saturday, January 05, 2008 12:52 PM Subject: Re: Cristian Balint seems to be a non-responsive maintainer > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From nicolas.mailhot at laposte.net Sat Jan 5 15:41:31 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 05 Jan 2008 16:41:31 +0100 Subject: I'm mellllttttttinggg!!! (kernel 2.6.24-0.133.rc6.git8.fc9) In-Reply-To: <20080105134627.GA17509@jadzia.bu.edu> References: <20080105134627.GA17509@jadzia.bu.edu> Message-ID: <1199547691.5169.3.camel@rousalka.dyndns.org> Le samedi 05 janvier 2008 ? 08:46 -0500, Matthew Miller a ?crit : > So, I came back from vacation and updated my rawhide machine to the latest. > Core temp quickly went to 125C?+ and the computer powered > itself off to avoid starting any fires. > > This doesn't seem to happen with kernel-2.6.24-0.83.rc5.fc9, which I had > installed before the break. Oh, it gets hot, but more like 95C?. Either way that's too high (my X2 rarely goes over 50?C). Check your heatsinks, vacations have high hardware death probabilities, since the hardware is not stressed the same as the rest of the year. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From mclasen at redhat.com Sat Jan 5 15:42:35 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Sat, 05 Jan 2008 10:42:35 -0500 Subject: call for texlive related packages maintainers In-Reply-To: <645d17210801050508m393e631w5fdd0b83c00b1d77@mail.gmail.com> References: <20080105121634.GA1756@free.fr> <645d17210801050508m393e631w5fdd0b83c00b1d77@mail.gmail.com> Message-ID: <1199547755.3410.0.camel@localhost.localdomain> On Sat, 2008-01-05 at 13:08 +0000, Jonathan Underwood wrote: > On 05/01/2008, Patrice Dumas wrote: > > In texlive but should be separate: > > xdvik (xdvi) > > http://sourceforge.net/projects/xdvi > > > > The need for this one would disappear if the evince packager would > enable the dvi backend in evince (BZ #187381). > This has been enabled in rawhide for a while now. From bbbush.yuan at gmail.com Sat Jan 5 15:56:23 2008 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Sat, 5 Jan 2008 23:56:23 +0800 Subject: chmsee (was: Re: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220) In-Reply-To: References: <76e72f800801050520n69a07503k2e87817dac2a828d@mail.gmail.com> Message-ID: <76e72f800801050756o1fef1a4dxae32de25a7c1dfa3@mail.gmail.com> 2008/1/5, Kevin Kofler : > > Sounds like a problem in xulrunner then. File a bug against xulrunner. > 427622 -- bbbush ^_^ From rezso at rdsor.ro Sat Jan 5 16:02:36 2008 From: rezso at rdsor.ro (Balint Cristian) Date: Sat, 5 Jan 2008 18:02:36 +0200 Subject: Cristian Balint seems to be a non-responsive maintainer In-Reply-To: References: <7hfxxejxq6.fsf@allele2.eebweb.arizona.edu><477D73B7.6050202@redhat.com><1199495644.21972.16.camel@localhost.localdomain> Message-ID: ----- Original Message ----- From: "Alex Lancaster" To: "Development discussions related to Fedora" Sent: Saturday, January 05, 2008 12:10 PM Subject: Re: Cristian Balint seems to be a non-responsive maintainer Hello Alex, > http://fedoraproject.org/wiki/PackageMaintainers/UsingPackagedb > https://admin.fedoraproject.org/pkgdb/ > > If you have your old FAS password for cbalint, you could login and > orphan the package yourself, then relogin with your new one and > reclaim them. If you can't login with your old FAS password, you'll > have to get an admin to orphan them manually, then you can reclaim > then again with your new FAS password. Thanks to give this into my attention :) I might tryed old fashioned way with cvs+ stuff. I tryed do so, orpahaned in old account, but cant see yet tham in the new one. I wait 1h or so it might be some cronjob doing that, and i come back for advice if I lost eye over tham. Thank you, ~cristian From alan at redhat.com Sat Jan 5 16:04:39 2008 From: alan at redhat.com (Alan Cox) Date: Sat, 5 Jan 2008 11:04:39 -0500 Subject: I'm mellllttttttinggg!!! (kernel 2.6.24-0.133.rc6.git8.fc9) In-Reply-To: <1199545992.12421.6.camel@localhost6.localdomain6> References: <20080105134627.GA17509@jadzia.bu.edu> <18303.35648.235241.449822@zebedee.pink> <1199545992.12421.6.camel@localhost6.localdomain6> Message-ID: <20080105160439.GA11024@devserv.devel.redhat.com> On Sat, Jan 05, 2008 at 08:13:12AM -0700, Richi Plana wrote: > Modelines, overheating laptops with covers closed and monitor and CPU > not going low, etc. The fact that there was a difference indicates, at > the least, seemingly more power-consumption for the same amount of work > with just a different kernel. Certainly worth investigating. PC systems today are usually designed with system managed fans and a hardware cut out at the point things go 'critical'. So it is in fact possible that a kernel change caused a problem which then shut the machine down as it hit the hardware thermal limit. Unlikely but possible. Running old and new kernels will verify that after checking the fans etc are in fact working properly. If this is the case it would be very nice to know ASAP and also to let Len Brown know that you have a case where a box overheats with one kernel and not another From eric.tanguy at univ-nantes.fr Sat Jan 5 16:20:54 2008 From: eric.tanguy at univ-nantes.fr (Tanguy Eric) Date: Sat, 05 Jan 2008 17:20:54 +0100 Subject: Init : someone could comment this ? Message-ID: <1199550054.2847.1.camel@bureau.maison> I just find this http://www.pardus.org.tr/eng/projeler/comar/SpeedingUpLinuxWithPardus.html maybe it's known but someone could comment this because it seems to gain init time. Eric From jamatos at fc.up.pt Sat Jan 5 16:34:30 2008 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Sat, 5 Jan 2008 16:34:30 +0000 Subject: rpms/funtools/FC-6 .cvsignore, 1.1, NONE Makefile, 1.1, NONE branch, 1.1, NONE funtools-makefile.patch, 1.1, NONE funtools-wcs.patch, 1.1, NONE funtools.spec, 1.4, NONE sources, 1.5, NONE In-Reply-To: <200801051453.m05ErXRN032221@cvs-int.fedora.redhat.com> References: <200801051453.m05ErXRN032221@cvs-int.fedora.redhat.com> Message-ID: <200801051634.31173.jamatos@fc.up.pt> On Saturday 05 January 2008 14:53:33 Sergio Pascual wrote: > Author: sergiopr > > Update of /cvs/pkgs/rpms/funtools/FC-6 > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv32174/FC-6 > > Removed Files: > .cvsignore Makefile branch funtools-makefile.patch > funtools-wcs.patch funtools.spec sources > Log Message: > Removing old branches > > > > --- .cvsignore DELETED --- > > > --- Makefile DELETED --- > > > --- branch DELETED --- > > > --- funtools-makefile.patch DELETED --- > > > --- funtools-wcs.patch DELETED --- > > > --- funtools.spec DELETED --- > > > --- sources DELETED --- I have seen several commit like this over the last days. Why are you deleting old branches? -- Jos? Ab?lio From mschwendt.tmp0701.nospam at arcor.de Sat Jan 5 16:47:20 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 5 Jan 2008 17:47:20 +0100 Subject: Fwd: closing out old bugs of unmaintained releases In-Reply-To: <200801051328.13094.opensource@till.name> References: <200801051328.13094.opensource@till.name> Message-ID: <20080105174720.dc73725a.mschwendt.tmp0701.nospam@arcor.de> On Sat, 05 Jan 2008 13:28:07 +0100, Till Maas wrote: > I would like it more when first every bug gets marked NEEDINFO_REPORTER and > ask him whether or not the problem still exists and in case it does, to > adjust the version of the Bug report or close it with e.g. currentrelease. In > case the reporter did not respond within two weeks, ping him via bugzilla and > then another two weeks later, close the bug with WONTFIX or INSUFFICANT_DATA. > This is at least a little better bug reporter experience. Better? I doubt that. Many a bug reporter will be annoyed when after months or a year of ignoring a ticket and not fixing the bug somebody comes along and puts pressure on the reporter to allocate time for retesting. It is even more rude to close such old bugs as WONTFIX or INSUFFICIENT_DATA. When only after the EOL of a distribution version there is activity within a ticket, that is like saying "we didn't care about your bug report this time, and we don't promise either that we look into the issue this time". Actually a reporter expects a package maintainer to evaluate a new report ASAP and make use of NEEDINFO states ASAP, so _sufficient data_ could be provided while the issue is _hot_. The packager ought to tell whether the provided data are insufficient and whether the problem is reproducible. When however it takes too long for the packager to handle a bug report, that increases the risk that the reporter moves on with different sofware/release or abandoning to use the software that causes trouble. > This is more or less > what I did when I started to comaintain some packages, that had several bugs > and the maintainers too little time. Please don't forget that bug reporters have limited time only, too. Bug triagers should focus on filling a queue with tickets, where package maintainers commit to taking a serious look at those tickets. The NEEDINFO state should be used when there is committment to moving forward with a ticket, not just to give the reporter something to do after a long of no interest in the report. From mjs at CLEMSON.EDU Sat Jan 5 16:52:17 2008 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Sat, 05 Jan 2008 11:52:17 -0500 Subject: call for texlive related packages maintainers In-Reply-To: <20080105131320.GC1756@free.fr> References: <20080105121634.GA1756@free.fr> <645d17210801050508m393e631w5fdd0b83c00b1d77@mail.gmail.com> <20080105131320.GC1756@free.fr> Message-ID: <1199551937.21663.7.camel@vincent52.localdomain> On Sat, 2008-01-05 at 14:13 +0100, Patrice Dumas wrote: > On Sat, Jan 05, 2008 at 01:08:22PM +0000, Jonathan Underwood wrote: > > On 05/01/2008, Patrice Dumas wrote: > > > In texlive but should be separate: > > > xdvik (xdvi) > > > http://sourceforge.net/projects/xdvi > > > > > > > The need for this one would disappear if the evince packager would > > enable the dvi backend in evince (BZ #187381). > > No, the need for this would not disappear, at least for me. But it's still a good idea. -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From mtasaka at ioa.s.u-tokyo.ac.jp Sat Jan 5 16:55:11 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sun, 06 Jan 2008 01:55:11 +0900 Subject: call for texlive related packages maintainers In-Reply-To: <1199551937.21663.7.camel@vincent52.localdomain> References: <20080105121634.GA1756@free.fr> <645d17210801050508m393e631w5fdd0b83c00b1d77@mail.gmail.com> <20080105131320.GC1756@free.fr> <1199551937.21663.7.camel@vincent52.localdomain> Message-ID: <477FB66F.60602@ioa.s.u-tokyo.ac.jp> Matthew Saltzman wrote, at 01/06/2008 01:52 AM +9:00: > On Sat, 2008-01-05 at 14:13 +0100, Patrice Dumas wrote: >> On Sat, Jan 05, 2008 at 01:08:22PM +0000, Jonathan Underwood wrote: >>> On 05/01/2008, Patrice Dumas wrote: >>>> In texlive but should be separate: >>>> xdvik (xdvi) >>>> http://sourceforge.net/projects/xdvi >>>> >>> The need for this one would disappear if the evince packager would >>> enable the dvi backend in evince (BZ #187381). >> No, the need for this would not disappear, at least for me. > > But it's still a good idea. > pxdvi (in xdvi) is definitely needed for Japanese pTeX users. Regards, Mamoru From jonathan.underwood at gmail.com Sat Jan 5 17:01:59 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sat, 5 Jan 2008 17:01:59 +0000 Subject: call for texlive related packages maintainers In-Reply-To: <477FB66F.60602@ioa.s.u-tokyo.ac.jp> References: <20080105121634.GA1756@free.fr> <645d17210801050508m393e631w5fdd0b83c00b1d77@mail.gmail.com> <20080105131320.GC1756@free.fr> <1199551937.21663.7.camel@vincent52.localdomain> <477FB66F.60602@ioa.s.u-tokyo.ac.jp> Message-ID: <645d17210801050901p4637ee1bkf4da4e799c3456fa@mail.gmail.com> On 05/01/2008, Mamoru Tasaka wrote: > pxdvi (in xdvi) is definitely needed for Japanese pTeX users. Am in the process of hacking together a spec file for xdvi (including pxdvi) by hacking the relevant parts from the texlive SPEC. It doesn't build yet, but anyone feeling like helping can find it here: http://jgu.fedorapeople.org/xdvik.spec From rezso at rdsor.ro Sat Jan 5 17:07:25 2008 From: rezso at rdsor.ro (Balint Cristian) Date: Sat, 5 Jan 2008 19:07:25 +0200 Subject: Cristian Balint seems to be a non-responsive maintainer In-Reply-To: References: <7hfxxejxq6.fsf@allele2.eebweb.arizona.edu><477D73B7.6050202@redhat.com><1199495644.21972.16.camel@localhost.localdomain> Message-ID: <79BEEE21A3B541B494907A0837349A14@Yoda> ----- Original Message ----- From: "Balint Cristian" To: "Development discussions related to Fedora" Sent: Saturday, January 05, 2008 6:02 PM Subject: Re: Cristian Balint seems to be a non-responsive maintainer > > ----- Original Message ----- > From: "Alex Lancaster" > To: "Development discussions related to Fedora" > > Sent: Saturday, January 05, 2008 12:10 PM > Subject: Re: Cristian Balint seems to be a non-responsive maintainer > > > Hello Alex, > >> http://fedoraproject.org/wiki/PackageMaintainers/UsingPackagedb >> https://admin.fedoraproject.org/pkgdb/ >> >> If you have your old FAS password for cbalint, you could login and >> orphan the package yourself, then relogin with your new one and >> reclaim them. If you can't login with your old FAS password, you'll >> have to get an admin to orphan them manually, then you can reclaim >> then again with your new FAS password. > Ownership changed finnaly. Thanks everyone for helping me. I work now to put shape for those bz# and solve package issues. ~cristian From jonstanley at gmail.com Sat Jan 5 17:25:03 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Sat, 5 Jan 2008 12:25:03 -0500 Subject: Fwd: closing out old bugs of unmaintained releases In-Reply-To: <20080104171008.3cc6db16@ghistelwchlohm.scrye.com> References: <20080104140746.62518306@ghistelwchlohm.scrye.com> <477EA9DA.9040202@gmail.com> <20080104171008.3cc6db16@ghistelwchlohm.scrye.com> Message-ID: On Jan 4, 2008 7:10 PM, Kevin Fenzi wrote: > Yeah, indeed. But I think thats part of the problem.... We get > backloged and the first thought is to do something about the backlog, The backlog that would be eliminated by this action is about 1/3 of the currently open Fedora bugs. > but that doesn't really solve the problem, just keeps us in a cycle. > I think we need to look at the entire problem and come up with a full > solution, or at least a full attempted solution. This is why I'm going to FUDCon, to come up with a solution with the maximum amount of community input. I encourage anyone coming to FUDCon that has an opinion on this topic to show up and provide their input - without community input and buy-in, there's no way that I can be successful in this effort. > I think there are several problems here: > > 1. There is a big backlog of bugs that aren't getting attention. That's why it's necessary to "clear the deck". To give some current stats: FC1-FC6 have 3,811 in any status other than CLOSED [1] F7 has 2073 bugs open [2] F8 has 2066 bugs open [3] rawhide has 5638 bugs currently open [4] I'm looking for a way to search rawhide bugs that have not been changed since 2007-06-01, however that seems to be a bit of a tall order with the current bugziila interface - however I have a hunch that the number is probably about half of the open ones. > 2. There are more bugs flowing in than maintainers are dealing with, > which adds to the backlog over time. That's where the triage team comes in, putting sane priorities on things and managing maintainer workload. Again, this is all part of the grand effort to *build* a triage team. > 3. Some high profile packages have so many new bugs that there is no way > any single maintainer could handle them. See 2. The number of actual, unique, high-priority bugs that come in against these packages I assume is perfectly manageable. Also, keep in mind that high-profile packages generally have a team of maintainers working on them, especially the ones that we are upstream for. > 4. There is no flow from/to upstream projects (or very little). I know > from my own Xfce bugs when something is a upstream issue, I usually > file the upstream bug, follow it and then close the fedora bug when > it's fixed upstream or a patch is available. Thats very very labor > intensive. There's nothing that says a maintainer has to do this. A triager can equally well file an upstream bug - the thing is, I think at that point, it's the responsibility of the reporter to follow the upstream bug. I also think that UPSTREAM should not be a closing status - it should be rather 'this is on hold while we're waiting for upstream to do something about it, come back once they do and the Fedora maintainer can make a decision to incorporate or not' > I think most people are concentrating on the backlog issue to the > exclusion of all the other issues, and I think those need solutions > before doing anything to the backlog makes sense. +4000 > For problems 2 and 3, refer to: > http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus#head-181b0c70022aca0d7aa42d42f7ed12a553189882 > for maintainers with the most bugs. Didn't know this existed, thanks! > Sure, but if the reporter doesn't respond, or the maintainer can't > reproduce on the current release, then they can close it... instead of > forcing the submitter to re-open it. A lot of people will just not want > to deal with the hassle. How about finding a common ground? Placing them in NEEDINFO_REPORTER for a week and then auto-close those that are still in that state? > If it's easy for them to do so. It's trivial. That's why I mentioned the 'clone as bug' feature of bugzilla. My guess is that some (a lot?) of the people who would reopen a bug are not the assignee or reporter (or a triager), and thus would not have the proper bugzilla permissions to re-open. That's where the clone comes in. > Thats no good in my opinion, because then the bugs would be ignored. > You might as well close them and tell the submitter for sure the bug > isn't going to be dealt with. +20,000 [1] https://bugzilla.redhat.com/buglist.cgi?cmdtype=runnamed&namedcmd=unmaintained-open&namedowner=jonstanley%40gmail.com [2] https://bugzilla.redhat.com/buglist.cgi?cmdtype=runnamed&namedcmd=F7-open&namedowner=jonstanley%40gmail.com [3] https://bugzilla.redhat.com/buglist.cgi?cmdtype=runnamed&namedcmd=F8-open&namedowner=jonstanley%40gmail.com [4] https://bugzilla.redhat.com/buglist.cgi?cmdtype=runnamed&namedcmd=rawhide-open&namedowner=jonstanley%40gmail.com From opensource at till.name Sat Jan 5 18:03:37 2008 From: opensource at till.name (Till Maas) Date: Sat, 05 Jan 2008 19:03:37 +0100 Subject: Fwd: closing out old bugs of unmaintained releases In-Reply-To: References: <20080104171008.3cc6db16@ghistelwchlohm.scrye.com> Message-ID: <200801051903.41625.opensource@till.name> On Sat January 5 2008, Jon Stanley wrote: > How about finding a common ground? Placing them in NEEDINFO_REPORTER > for a week and then auto-close those that are still in that state? Another idea I have would be to treat bugs depending on the count of open bugs tor the component/package. E.g. there are a lot of bugs for F6 and previous for some packages (e.g. kernel, anaconda) that also have a lot of open bug reports for F7 and later. Here it is very unlikely, that the bug will be fixed soon or it is likely, that the bug is already fixed but nobody mentioned it / closed the bug. For kernel and anaconda, I guess testing whether the bug is still present, needs often special hardware or a special setup. Therefore just using needinfo and closing after a timeout may be not so bad. Unless we can find the ressources to fix the bugs. Maybe this allows to reduce the amount of open bugs to a smaller number, that allows to review them manually by a team to find out, whether they are already fixed and adjust the version. Also there are 1308 Bugs for F6 and earlier already in NEEDINFO state. Here closing all bugs that are in this state for, e.g. 3 months or longer, also sounds not so bad to me. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From lesmikesell at gmail.com Sat Jan 5 18:28:19 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sat, 05 Jan 2008 12:28:19 -0600 Subject: integration of LTSP 5 in fedora In-Reply-To: <20080105094839.GE2570@free.fr> References: <539333cb0801040958r5ceb61b3t3d32b413b578d355@mail.gmail.com> <539333cb0801042058j793f301dsfe75747094b0968@mail.gmail.com> <20080105094839.GE2570@free.fr> Message-ID: <477FCC43.1070008@gmail.com> Patrice Dumas wrote: > On Sat, Jan 05, 2008 at 10:28:49AM +0530, subhodip biswas wrote: >> hi all ! >> >> is anybody looking toward the integration of LTSP 5 in fedora . all i >> found is a bugid ##234048 . i can help if needed . > > There has been some work. There is a tracker bug > https://bugzilla.redhat.com/show_bug.cgi?id=188611 > > But I don't know what the status is right now. First K12LTSP packages > were to be included, things begun a bit hastily, then stopped half-way. > It seems that now the developpement should happen at > https://launchpad.net/~ltsp-drivers > but I don't know where fedora stuff is in it. > > Warren Togami and Eric Harrison were the one who lead the ltsp > inclusion. A bit of history for anyone who might not know: Eric Harrison has maintained the k12ltsp distribution that you can find at http://k12ltsp.org/mediawiki/index.php/Main_Page for many years. This isn't a separate distribution in the usual sense but a stock fedora or centos (depending on the version) rebuilt to include ltsp and some additional programs, plus some scripts to make it come up working as a server that will network-boot thin clients. These have been based on ltsp4. The initial work with ltsp5 has been in ubuntu/edubuntu. I believe the plan is to package ltsp5 (and perhaps some of the other k12 additions) for inclusion into the stock fedora distribution, but it hasn't happened yet. -- Les Mikesell lesmikesell at gmail.com From david at lovesunix.net Sat Jan 5 18:32:24 2008 From: david at lovesunix.net (David Nielsen) Date: Sat, 05 Jan 2008 19:32:24 +0100 Subject: Policy proposal for compatibility packages In-Reply-To: <477C0FE7.60105@redhat.com> References: <1199290909.11035.20.camel@kennedy> <20080102105614.73d4db84@vader.jdub.homelinux.org> <1199301348.3483.2.camel@rousalka.dyndns.org> <477BE5EA.9020909@redhat.com> <20080102215010.GD2661@free.fr> <477C0FE7.60105@redhat.com> Message-ID: <1199557944.4805.1.camel@localhost.localdomain> Em Qua, 2008-01-02 ?s 17:27 -0500, Tom "spot" Callaway escreveu: > Patrice Dumas wrote: > > On Wed, Jan 02, 2008 at 02:28:42PM -0500, Tom spot Callaway wrote: > >> - Third party applications which still depend on the old interface (that > >> the maintainer is aware of specifically, not "something might use it > >> someday") > > > > That seems to me to be a perfect reason. Please don't try to force > > packagers to do something without reason. If a packager wants to invest > > time to maintain a compat package, let him do. > > Well, one of the reasons we're making hoops for people to jump through > is that we don't want to clutter the distribution with compat packages. > This encourages upstream (and package maintainers) to just continue > using the compat packages, rather than porting to the new, improved ones. > > This is why I think that this is a valid reason: > > * Adobe ProprietaryDocumentFormat Reader needs this library to run. Why would that be valid.. if all that requires this there is absolutely no reason to have a -compat package. It's Adobe' problem to fix it. They don't play by the rules so no cookies for them. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Esta ? uma parte de mensagem assinada digitalmente URL: From jonathan.underwood at gmail.com Sat Jan 5 18:47:31 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sat, 5 Jan 2008 18:47:31 +0000 Subject: call for texlive related packages maintainers In-Reply-To: <1199547755.3410.0.camel@localhost.localdomain> References: <20080105121634.GA1756@free.fr> <645d17210801050508m393e631w5fdd0b83c00b1d77@mail.gmail.com> <1199547755.3410.0.camel@localhost.localdomain> Message-ID: <645d17210801051047w57a6b255y97f8c7b95e6d8ea2@mail.gmail.com> On 05/01/2008, Matthias Clasen wrote: > > On Sat, 2008-01-05 at 13:08 +0000, Jonathan Underwood wrote: > > On 05/01/2008, Patrice Dumas wrote: > > > In texlive but should be separate: > > > xdvik (xdvi) > > > http://sourceforge.net/projects/xdvi > > > > > > > The need for this one would disappear if the evince packager would > > enable the dvi backend in evince (BZ #187381). > > > > This has been enabled in rawhide for a while now. > So BZ #187381 can be closed RAWHIDE? From wolfy at nobugconsulting.ro Sat Jan 5 19:09:41 2008 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Sat, 05 Jan 2008 21:09:41 +0200 Subject: Is anyone packaging sage? In-Reply-To: <604aa7910801041406x7203c9fbq6485bd4b7e481281@mail.gmail.com> References: <604aa7910801041406x7203c9fbq6485bd4b7e481281@mail.gmail.com> Message-ID: <477FD5F5.4000004@nobugconsulting.ro> On 01/05/2008 12:06 AM, Jeff Spaleta wrote: > On Jan 4, 2008 1:01 PM, Neal Becker wrote: > >> http://sage.math.washington.edu/sage/ >> > > holy crap.... that looks pretty awesome. > > I can't be primary maintainer for this, but if you are going to work > on it I can help. > I've uploaded at http://wolfy.fedorapeople.org/sage my first attempt to create a spec for sage. I am not going to be primary maintainer either (and I do know that all the prereqs and optionals should end up in separate packages) 'cause I have no personal use for this program. However to give a kickstart. I have also included a patch which removes from the sage install script the parts which I think that are already available in rawhide. The build log for a mock build (which dies when trying to compile python_gnutls) is also there. A quick glance over it makes me think that a few prereqs could already be packaged and submitted for review Oh, and btw, I've used Jakub's new gcc-4.3.0 We do target F9, don't we ? If anyone wishes to merge the efforts with mine, please get in touch with me. manuel From caolanm at redhat.com Sat Jan 5 19:56:08 2008 From: caolanm at redhat.com (Caolan McNamara) Date: Sat, 05 Jan 2008 19:56:08 +0000 Subject: rawhide report: bacula/kannel -> mktexlsr ? In-Reply-To: <200801051224.m05COEwl021556@porkchop.devel.redhat.com> References: <200801051224.m05COEwl021556@porkchop.devel.redhat.com> Message-ID: <1199562968.11839.34.camel@Jehannum> On Sat, 2008-01-05 at 07:24 -0500, Build System wrote: > Broken deps for i386 > ---------------------------------------------------------- > bacula-* - 2.0.3-11.fc8.i386 requires libssl.so.6 > kannel - 1.4.1-5.i386 requires libssl.so.6 So, what exactly is the current problem with these two ? Is it just the mysterious failure of TeX to execute some stuff, i.e. " latex -interaction=batchmode bacula.tex This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6) %&-line parsing enabled. entering extended mode make[1]: *** [tex] Error 1 " and... " cd `dirname doc/alligata/alligata.xml` && jadetex `basename doc/alligata/alligata`.tex >/dev/null || \ ( echo Check `dirname doc/alligata/alligata.xml`/`basename doc/alligata/alligata`.log for errors && false) kpathsea: Running mktexfmt jadetex.fmt Check doc/alligata/alligata.log for errors make: *** [doc/alligata/alligata.ps] Error 1 " If so then I see (from a quick google) that locally running "mktexlsr" before trying to build them was sufficient to give me two successful builds. I can't add that to the affected .specs themselves so I suspect that some TeX package in the dependency chain should effectively run ?mktexlsr as root during install. Or something of that nature, I'm vague on the TeX world. C. From kevin.kofler at chello.at Sat Jan 5 20:38:32 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 5 Jan 2008 20:38:32 +0000 (UTC) Subject: Is anyone packaging sage? References: <604aa7910801041406x7203c9fbq6485bd4b7e481281@mail.gmail.com> <477FD5F5.4000004@nobugconsulting.ro> Message-ID: Manuel Wolfshant nobugconsulting.ro> writes: > I have also included a patch which removes from the sage install > script the parts which I think that are already available in rawhide. Still, a monolithic solution like this is not going to fly, every single of these separate projects needs to be packaged separately, usually directly from upstream, not from the bundled often outdated version in SAGE. Unfortunately, SAGE tries to be yet another program which tries to be a distro, this sucks. Out of spkg/standard/*.spkg, as a first guess, only spkg/standard/*-2.9.1.1.spkg makes sense to package as part of SAGE, that would be doc, examples, extcode, sage and sage_scripts. And these should be 5 separate packages or subpackages (e.g. sagemath, sagemath-doc, sagemath-examples, sagemath-extcode, sagemath-scripts). Moreover, at least in your build.log, it appears also to still build stuff like ATLAS and gnutls which are already in Fedora (and the gnutls build failed). Kevin Kofler From wolfy at nobugconsulting.ro Sat Jan 5 20:52:27 2008 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Sat, 05 Jan 2008 22:52:27 +0200 Subject: Is anyone packaging sage? In-Reply-To: References: <604aa7910801041406x7203c9fbq6485bd4b7e481281@mail.gmail.com> <477FD5F5.4000004@nobugconsulting.ro> Message-ID: <477FEE0B.4020103@nobugconsulting.ro> On 01/05/2008 10:38 PM, Kevin Kofler wrote: > Manuel Wolfshant nobugconsulting.ro> writes: > >> I have also included a patch which removes from the sage install >> script the parts which I think that are already available in rawhide. >> > > Still, a monolithic solution like this is not going to fly, every single of > these separate projects needs to be packaged separately, I absolutely agree with you. I have mentioned that I agree with having all prereqs as separate packages. But I wanted to see things started and to isolate the BRs > usually directly from > upstream, not from the bundled often outdated version in SAGE. agree again > Unfortunately, > SAGE tries to be yet another program which tries to be a distro, this sucks. > they just want top be sure that what they ship, works. I can understand that. That does not mean that I agree. > Out of spkg/standard/*.spkg, as a first guess, only > spkg/standard/*-2.9.1.1.spkg makes sense to package as part of SAGE, that would > be doc, examples, extcode, sage and sage_scripts. And these should be 5 > separate packages or subpackages (e.g. sagemath, sagemath-doc, > sagemath-examples, sagemath-extcode, sagemath-scripts). > > Moreover, at least in your build.log, it appears also to still build stuff like > ATLAS I have not noticed it in the repo... > and gnutls which are already in Fedora (and the gnutls build failed). > no, it's python-gnutls that failed From ivazqueznet at gmail.com Sat Jan 5 20:57:26 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sat, 05 Jan 2008 15:57:26 -0500 Subject: rawhide report: 20080105 changes In-Reply-To: <20080105075619.4672d078@vader.jdub.homelinux.org> References: <200801051224.m05COEwl021556@porkchop.devel.redhat.com> <20080105075619.4672d078@vader.jdub.homelinux.org> Message-ID: <1199566646.3463.21.camel@ignacio.lan> On Sat, 2008-01-05 at 07:56 -0600, Josh Boyer wrote: > On Sat, 5 Jan 2008 07:24:14 -0500 > Build System wrote: > > > > tcl-thread-2.6.5-5.fc9 > > ---------------------- > > * Fri Jan 04 2008 - jwboyer at jdub.homelinux.org 2.6.5-5 > > - Fix build problem caused by path mismatch on 64-bit platforms > > Er... I'm assuming that's a copy/paste error because I certainly didn't > do that and that email address doesn't exist anymore. I think someone may have used a script/target blindly without realizing what it does. Blame Michael Thomas. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jonstanley at gmail.com Sat Jan 5 21:25:53 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Sat, 5 Jan 2008 16:25:53 -0500 Subject: Fwd: closing out old bugs of unmaintained releases In-Reply-To: <20080105174720.dc73725a.mschwendt.tmp0701.nospam@arcor.de> References: <200801051328.13094.opensource@till.name> <20080105174720.dc73725a.mschwendt.tmp0701.nospam@arcor.de> Message-ID: On Jan 5, 2008 11:47 AM, Michael Schwendt wrote: > Better? I doubt that. Many a bug reporter will be annoyed when after > months or a year of ignoring a ticket and not fixing the bug somebody > comes along and puts pressure on the reporter to allocate time for > retesting. That exact phenomenon is what led me down this road (not this particular course of action, but the realization that something had to be done). [1]. I was bound and determined to end that cycle, and have more instances like [2]. > t is even more rude to close such old bugs as WONTFIX or > INSUFFICIENT_DATA. When only after the EOL of a distribution version there > is activity within a ticket, that is like saying "we didn't care about > your bug report this time, and we don't promise either that we look into > the issue this time". Is there some other reasonable course of action? I'm sure that there will be people with that perception, but I'm not sure what to do about it. I'm remembering back to my high school days now, when a teacher used to tell me (and attributed it to someone else, but I can't for the life of me remember who) "you can please some of the people all the time, you can please all of the people some of the time, but you can't please all the people all the time". > Actually a reporter expects a package maintainer to > evaluate a new report ASAP and make use of NEEDINFO states ASAP, so > _sufficient data_ could be provided while the issue is _hot_. The packager > ought to tell whether the provided data are insufficient and whether the > problem is reproducible. Either that or a triager to do the same. People do not expect their bugs to be magically fixed (some do, but those people are unreasonable IM[NS]HO). What they expect is someone to say "yes, we have received this report. Your voice is heard. Maybe I'll poke a developer about this". Part of the job of a good triage team is maintainer/developer interaction. > When however it takes too long for the packager > to handle a bug report, that increases the risk that the reporter moves on > with different sofware/release or abandoning to use the software that > causes trouble. See [1] > Please don't forget that bug reporters have limited time only, too. Agreed. Which is why mass-closing is such an appealing thing from both sides of the fence. It's been mentioned in this thread (not sure if on this list or another, I'll go back and look), that the message used to mass-close should basically admit the fact that we know that we have a problem, and that we are taking action to fix the problem in the future so that we don't get into this state again. > Bug triagers should focus on filling a queue with tickets, where package > maintainers commit to taking a serious look at those tickets. I think that one of my proposals is going to be a fedora-triage flag or something similar. Maintainers can look at that and know that the bug has been reviewed by a triager, that it's not a duplicate, and that the priority/version/component settings on the bug are sane. > The NEEDINFO > state should be used when there is committment to moving forward with a > ticket, not just to give the reporter something to do after a long of no > interest in the report. Are you saying that triagers should not use NEEDINFO for current bugs? At that point, there's not developer commitment, there is triager commitment. [1] https://bugzilla.redhat.com/show_bug.cgi?id=204883 [2] https://bugzilla.redhat.com/show_bug.cgi?id=427157 From wart at kobold.org Sat Jan 5 21:30:07 2008 From: wart at kobold.org (Wart) Date: Sat, 05 Jan 2008 13:30:07 -0800 Subject: heads up: tcl and tk 8.5 In-Reply-To: References: <477B60F0.6020406@redhat.com> <20080102102228.44c0d545@ghistelwchlohm.scrye.com> Message-ID: <477FF6DF.8010707@kobold.org> Alex Lancaster wrote: >>>>>> "KF" == Kevin Fenzi writes: > > KF> On Wed, 02 Jan 2008 11:01:20 +0100 > KF> mmaslano at redhat.com (Marcela Maslanova) wrote: > >> New tcl and tk 8.5 was released. I'd like to push it to rawhide as >>> soon as possible. The list of dependent packages could be found in >>> this draft: >>> https://fedoraproject.org/wiki/MarcelaMaslanova/Draft/tcl8.5 The >>> maintainers of dependent packages should fix them according to >>> http://fedoraproject.org/wiki/PackagingDrafts/Tcl > > KF> Can you possibly mail directly at least the primary maintainers of > KF> these packages and let them know when you are going to push the > KF> update? > > KF> Many of them might not see this post... > > Marcela, > > Can you also post to fedora-devel-announce to get wider distribution? > Judging by the high number of broken deps still in rawhide caused by > this tcl soname bump, I suspect that many maintainers may not have > seen this announcement. Many only subscribe to the -announce list and > not devel-list to avoid the high traffic here. (These kind of > distro-wide soname bumps that affect many packages should always be > posted to fedora-announce). > > Also, I've noticed that several packages don't rebuild with the new > Tcl and have build failures with the following: > > /usr/include/tcl-private/generic/tclPort.h:27:28: error: tclUnixPort.h: No such file or directory > > (one example full log is here: > http://koji.fedoraproject.org/koji/getfile?taskID=326763&name=build.log) > > is there any easy fix? "-I/usr/include/tcl-private/unix" is missing from the compile line. The tcl-devel package should probably make symlinks from the files in %{_includedir}/tcl-private/unix/*.h to %{_includedir}/tcl-private/generic/ so that the extensions don't notice that the headers moved to a different subdirectory. --Mike From wart at kobold.org Sat Jan 5 22:01:59 2008 From: wart at kobold.org (Wart) Date: Sat, 05 Jan 2008 14:01:59 -0800 Subject: rawhide report: 20080105 changes In-Reply-To: <20080105075619.4672d078@vader.jdub.homelinux.org> References: <200801051224.m05COEwl021556@porkchop.devel.redhat.com> <20080105075619.4672d078@vader.jdub.homelinux.org> Message-ID: <477FFE57.90507@kobold.org> Josh Boyer wrote: > On Sat, 5 Jan 2008 07:24:14 -0500 > Build System wrote: > > >> tcl-thread-2.6.5-5.fc9 >> ---------------------- >> * Fri Jan 04 2008 - jwboyer at jdub.homelinux.org 2.6.5-5 >> - Fix build problem caused by path mismatch on 64-bit platforms > > Er... I'm assuming that's a copy/paste error because I certainly didn't > do that and that email address doesn't exist anymore. My bad. I copied and pasted another changelog entry without changing the author. --Wart From mjs at CLEMSON.EDU Sat Jan 5 22:16:47 2008 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Sat, 05 Jan 2008 17:16:47 -0500 Subject: Policy proposal for compatibility packages In-Reply-To: <1199557944.4805.1.camel@localhost.localdomain> References: <1199290909.11035.20.camel@kennedy> <20080102105614.73d4db84@vader.jdub.homelinux.org> <1199301348.3483.2.camel@rousalka.dyndns.org> <477BE5EA.9020909@redhat.com> <20080102215010.GD2661@free.fr> <477C0FE7.60105@redhat.com> <1199557944.4805.1.camel@localhost.localdomain> Message-ID: <1199571407.14747.15.camel@vincent52.localdomain> On Sat, 2008-01-05 at 19:32 +0100, David Nielsen wrote: > Em Qua, 2008-01-02 ?s 17:27 -0500, Tom "spot" Callaway escreveu: > > Patrice Dumas wrote: > > > On Wed, Jan 02, 2008 at 02:28:42PM -0500, Tom spot Callaway wrote: > > >> - Third party applications which still depend on the old interface (that > > >> the maintainer is aware of specifically, not "something might use it > > >> someday") > > > > > > That seems to me to be a perfect reason. Please don't try to force > > > packagers to do something without reason. If a packager wants to invest > > > time to maintain a compat package, let him do. > > > > Well, one of the reasons we're making hoops for people to jump through > > is that we don't want to clutter the distribution with compat packages. > > This encourages upstream (and package maintainers) to just continue > > using the compat packages, rather than porting to the new, improved ones. > > > > This is why I think that this is a valid reason: > > > > * Adobe ProprietaryDocumentFormat Reader needs this library to run. > > Why would that be valid.. if all that requires this there is absolutely > no reason to have a -compat package. It's Adobe' problem to fix it. They > don't play by the rules so no cookies for them. What about cookies for users who need the Adobe (or whatever) package because there is no fully functional FOSS alternative? Sure, we can (and do, as much as we are able) pressure upstream to get their act together, but meanwhile--particularly if upstream is unresponsive--we still need to get our work done. I'm sure you know it's common for commercial developers to fix on a particular stable, long-lived, well-supported distribution (RHEL4, say) and support their packages only for that release of that distro for some extended period of time. Meanwhile, fast-moving distros like Fedora may advance through several incompatible library or language versions. It's generally not practical to expect Adobe (or whomever) to reply to complaints about Fedora compatibility with anything other than "use a supported distro". And please don't consign us to those supported platforms or distros. We are part of the Fedora community because we support Fedora's goals and we want to keep close to the bleeding edge. But we do still have work to do. > > - David -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From tibbs at math.uh.edu Sat Jan 5 22:24:21 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 05 Jan 2008 16:24:21 -0600 Subject: rawhide report: bacula/kannel -> mktexlsr ? In-Reply-To: <1199562968.11839.34.camel@Jehannum> References: <200801051224.m05COEwl021556@porkchop.devel.redhat.com> <1199562968.11839.34.camel@Jehannum> Message-ID: >>>>> "CM" == Caolan McNamara writes: CM> So, what exactly is the current problem with these two ? Is it CM> just the mysterious failure of TeX to execute some stuff, i.e. Yes, I debugged this the other day. The problem for bacula is that latex2html somehow does not properly run texhash in %post, so nothing can find html.sty. If you force a texhash it works. Changing the post scriptlet for latex2html to not use "/usr/bin/env - /usr/bin/texhash" but to just call texhash directly works. I don't know why. CM> " latex -interaction=batchmode bacula.tex Remove -interaction=batchmode to see errors from latex. - J< From alexl at users.sourceforge.net Sat Jan 5 23:16:09 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Sat, 05 Jan 2008 16:16:09 -0700 Subject: Cristian Balint seems to be a non-responsive maintainer In-Reply-To: <79BEEE21A3B541B494907A0837349A14@Yoda> (Balint Cristian's message of "Sat\, 5 Jan 2008 19\:07\:25 +0200") References: <7hfxxejxq6.fsf@allele2.eebweb.arizona.edu> <477D73B7.6050202@redhat.com> <1199495644.21972.16.camel@localhost.localdomain> <79BEEE21A3B541B494907A0837349A14@Yoda> Message-ID: >>>>> "BC" == Balint Cristian writes: [...] BC> Ownership changed finnaly. Thanks everyone for helping me. BC> I work now to put shape for those bz# and solve package issues. Excellent, thanks. Can you open up the ACLs for your packages to cvsextras again? e.g., check the "group members can commit?" box in: https://admin.fedoraproject.org/pkgdb/packages/name/mapserver that way others can fix your packages when necessary. spot had opened up them, but it looks like you (or perhaps the admin) has closed them up again. Also it would be good if you could approve (or otherwise) the outstanding packagedb requests for your packages. There are many "Awaiting Review" requests against your packages. Thanks, Alex From alexl at users.sourceforge.net Sat Jan 5 23:24:35 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Sat, 05 Jan 2008 16:24:35 -0700 Subject: rawhide report: bacula/kannel -> mktexlsr ? In-Reply-To: (Jason L. Tibbitts, III's message of "05 Jan 2008 16\:24\:21 -0600") References: <200801051224.m05COEwl021556@porkchop.devel.redhat.com> <1199562968.11839.34.camel@Jehannum> Message-ID: >>>>> "CM" == Caolan McNamara writes: CM> So, what exactly is the current problem with these two ? Is it CM> just the mysterious failure of TeX to execute some stuff, i.e. >>>>> "JT" == Jason L Tibbitts writes: JT> Yes, I debugged this the other day. The problem for bacula is JT> that latex2html somehow does not properly run texhash in %post, JT> so nothing can find html.sty. If you force a texhash it works. JT> Changing the post scriptlet for latex2html to not use JT> "/usr/bin/env - /usr/bin/texhash" but to just call texhash JT> directly works. I don't know why. JT> Remove -interaction=batchmode to see errors from latex. In the bacula case here is the bz (doesn't seem to be an open bug for kannel): https://bugzilla.redhat.com/show_bug.cgi?id=414381 Also, bacula has closed ACLs, so nobody can currently rebuild the package if and when this packaging issue is resolved. Can somebody please open them up? Alex From cjdahlin at ncsu.edu Sun Jan 6 00:16:03 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Sat, 05 Jan 2008 19:16:03 -0500 Subject: Init : someone could comment this ? In-Reply-To: <1199550054.2847.1.camel@bureau.maison> References: <1199550054.2847.1.camel@bureau.maison> Message-ID: <47801DC3.8010104@ncsu.edu> Tanguy Eric wrote: > I just find this > http://www.pardus.org.tr/eng/projeler/comar/SpeedingUpLinuxWithPardus.html maybe it's known but someone could comment this because it seems to gain init time. > > Eric > > > There is work being done in this area for Fedora as well. I've been working on a parallel booting system for us that also will provide dbus notifications for the starting of various services. (Hopefully I'll be leading a hackfest at FUDCon in a few days to get a few more eyes and hands on the code). We have had discussions on this in the past and had similarly decided not to replace the init daemon. We also decided that we wanted to retain compatibility with conventional sysvinit scripts. As for rewriting some of the scripts themselves in a non-bash language, there may be an advantage. I don't know if I like python in particular for this roll (maybe something like Haskell that has proven to be light and quick as well as nicer to deal with) but python is very entrenched in Fedora, and I believe RPM/YUM still depends on it, so there's a low cost to using it. Bash does a lot by running other programs, and that is a lot of extra IO. Those are what I see to be the points in the article that are relevant to Fedora. The other elements are interesting, but not directly related to the general aspect of improving boot speed. --CJD From lordmorgul at gmail.com Sun Jan 6 00:42:40 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sat, 05 Jan 2008 16:42:40 -0800 Subject: Fwd: closing out old bugs of unmaintained releases In-Reply-To: References: <20080104140746.62518306@ghistelwchlohm.scrye.com> <477EA9DA.9040202@gmail.com> <20080104171008.3cc6db16@ghistelwchlohm.scrye.com> Message-ID: <47802400.7030407@gmail.com> Jon Stanley wrote: > On Jan 4, 2008 7:10 PM, Kevin Fenzi wrote: > >> Yeah, indeed. But I think thats part of the problem.... We get >> backloged and the first thought is to do something about the backlog, > > The backlog that would be eliminated by this action is about 1/3 of > the currently open Fedora bugs. > >> but that doesn't really solve the problem, just keeps us in a cycle. >> I think we need to look at the entire problem and come up with a full >> solution, or at least a full attempted solution. > > This is why I'm going to FUDCon, to come up with a solution with the > maximum amount of community input. I encourage anyone coming to > FUDCon that has an opinion on this topic to show up and provide their > input - without community input and buy-in, there's no way that I can > be successful in this effort. > >> I think there are several problems here: >> >> 1. There is a big backlog of bugs that aren't getting attention. > > That's why it's necessary to "clear the deck". To give some current stats: > > FC1-FC6 have 3,811 in any status other than CLOSED [1] > F7 has 2073 bugs open [2] > F8 has 2066 bugs open [3] > rawhide has 5638 bugs currently open [4] > > I'm looking for a way to search rawhide bugs that have not been > changed since 2007-06-01, however that seems to be a bit of a tall > order with the current bugziila interface - however I have a hunch > that the number is probably about half of the open ones. The interesting thing here is that MANY of those rawhide bugs are in fact not for current rawhide, and that because there is a lack of rawhide versioning there are many of them that should be closed WONTFIX as well. I had one open bug myself that had been filed as rawhide but not updated since 2004 (I remedied that due to this thread). I would say that the recent change to rawhide tag rather than devel should have been more thorough and included a rawhide version (pre-F9) for instance. Getting rid of the 3 different -testX versions was good, but rawhide changes and bugs filed against it get left behind. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From jonathan.underwood at gmail.com Sun Jan 6 00:46:42 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 6 Jan 2008 00:46:42 +0000 Subject: Init : someone could comment this ? In-Reply-To: <47801DC3.8010104@ncsu.edu> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> Message-ID: <645d17210801051646p71711a7ck7d3824572fe8ed21@mail.gmail.com> On 06/01/2008, Casey Dahlin wrote: > There is work being done in this area for Fedora as well. I've been > working on a parallel booting system for us that also will provide dbus > notifications for the starting of various services. (Hopefully I'll be > leading a hackfest at FUDCon in a few days to get a few more eyes and > hands on the code). > Other than compatability with sysvinit scripts, why was upstart dismissed? From j.w.r.degoede at hhs.nl Sun Jan 6 00:48:53 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 06 Jan 2008 01:48:53 +0100 Subject: I'm mellllttttttinggg!!! (kernel 2.6.24-0.133.rc6.git8.fc9) In-Reply-To: <20080105134627.GA17509@jadzia.bu.edu> References: <20080105134627.GA17509@jadzia.bu.edu> Message-ID: <47802575.7020609@hhs.nl> Matthew Miller wrote: > So, I came back from vacation and updated my rawhide machine to the latest. > Firefox 3 is all broke for me (haven't diagnosed that yet) and not having a > Firefox 2 package handy that doesn't conflict with xulrunner, I decided to > build one. Core temp quickly went to 125C?+ and the computer powered > itself off to avoid starting any fires. > > This doesn't seem to happen with kernel-2.6.24-0.83.rc5.fc9, which I had > installed before the break. Oh, it gets hot, but more like 95C?. Processor > is an AMD Athlon(tm) 64 Processor 3200+ but I'm running in 32-bit mode. > > Anyone else seeing this? > Do you have lm_sensors configured? Perhaps a driver bug is causing your CPU fan to be stopped / to slow. Try configuring lm_sensors and take a look at your CPU fan speed with both the cool and the hot kernel. Regards, Hans From the.masch at gmail.com Sun Jan 6 01:06:40 2008 From: the.masch at gmail.com (masch) Date: Sat, 5 Jan 2008 20:06:40 -0500 Subject: Pulse Audio problem Message-ID: <93d66b780801051706s5c9e41b4mb5ba48accc2e56b6@mail.gmail.com> HI! Sometimes when I open the PulseAudio Volume Control said: Connection failed: Connection refused, and the sound in some applications doesn't work. Does anyone know how to fix this? Thanks... Salu2... From lkundrak at redhat.com Sun Jan 6 02:12:07 2008 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Sun, 06 Jan 2008 03:12:07 +0100 Subject: Pulse Audio problem In-Reply-To: <93d66b780801051706s5c9e41b4mb5ba48accc2e56b6@mail.gmail.com> References: <93d66b780801051706s5c9e41b4mb5ba48accc2e56b6@mail.gmail.com> Message-ID: <1199585527.21972.42.camel@localhost.localdomain> On Sat, 2008-01-05 at 20:06 -0500, masch wrote: > HI! > Sometimes when I open the PulseAudio Volume Control said: > Connection failed: Connection refused, and the sound in some > applications doesn't work. > Does anyone know how to fix this? File a bugzilla ticket. Your pulseaudio daemon obviously died. Please add output of "grep pulseaudio /var/log/messages" to the bugzilla ticket. -- Lubomir Kundrak (Red Hat Security Response Team) From cjdahlin at ncsu.edu Sun Jan 6 03:26:17 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Sat, 05 Jan 2008 22:26:17 -0500 Subject: Init : someone could comment this ? In-Reply-To: <645d17210801051646p71711a7ck7d3824572fe8ed21@mail.gmail.com> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <645d17210801051646p71711a7ck7d3824572fe8ed21@mail.gmail.com> Message-ID: <47804A59.6090205@ncsu.edu> Jonathan Underwood wrote: > On 06/01/2008, Casey Dahlin wrote: > >> There is work being done in this area for Fedora as well. I've been >> working on a parallel booting system for us that also will provide dbus >> notifications for the starting of various services. (Hopefully I'll be >> leading a hackfest at FUDCon in a few days to get a few more eyes and >> hands on the code). >> >> > > Other than compatability with sysvinit scripts, why was upstart dismissed? > > Many options were looked at during the last iteration of this discussion, and by my understanding prcsys was the one that won out. See here: http://fedoraproject.org/wiki/FCNewInit/RC?highlight=%28fcnewinit%29 There's a few issues with prcsys internally that make it very difficult to add the features we want (dbus etc), as well as some not-so-trivial implementation issues (use of pthreads in a circumstance under which they were a very poor choice), so Harald Hoyer and myself decided that a rewrite was in order, so I went ahead and started working on a new app (which I have titled 'rrn') which is now near feature parity with prcsys. My academic schedule has meant I haven't had enough of it done to be worth showing to anyone until very recently, so I've not been talking too much about it here, but now that its starting to come together, I'd love to start the discussion up again (and of course you can all tell me I'm crazy and to take my little program and go home :). --CJD From mschwendt.tmp0701.nospam at arcor.de Sun Jan 6 03:49:03 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 6 Jan 2008 04:49:03 +0100 Subject: Fwd: closing out old bugs of unmaintained releases In-Reply-To: References: <200801051328.13094.opensource@till.name> <20080105174720.dc73725a.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20080106044903.fd18d9b3.mschwendt.tmp0701.nospam@arcor.de> On Sat, 5 Jan 2008 16:25:53 -0500, Jon Stanley wrote: > > t is even more rude to close such old bugs as WONTFIX or > > INSUFFICIENT_DATA. When only after the EOL of a distribution version there > > is activity within a ticket, that is like saying "we didn't care about > > your bug report this time, and we don't promise either that we look into > > the issue this time". > > Is there some other reasonable course of action? Rephrase the canned response that is cut'n'pasted into the ticket. It is not very helpful IMO to point out that a dist version has reached EOL if the bug was reported while the dist was an active release. Instead, explain to the reporter *why* the ticket has not been dealt with for such a long time. This is where triagers must be very careful. The reporter might believe that the provided details are sufficient and that the problem is reproducible. It is extremely poor form to not even try whether the problem is reproducible. And *if* you ask for NEEDINFO, do tell what is missing. Another reporter may flood a bugzilla ticket with many pages of [often irrelevant] data, which increases the time it takes to wade through it. Point to a good web page that explains how to get backtraces and how to increase the quality of bug reports in general. > [...] basically admit the fact that we know that > we have a problem, and that we are taking action to fix the problem in > the future so that we don't get into this state again. If you tell reporters that there are too many bug reports and not enough people to handle them all, do it early and possibly with an automated comment, for example after a maintainer has not responded after one month. Just don't touch old tickets after several months of inactivity only because there is hope that they can be closed after two weeks of waiting in NEEDINFO. So, while F9 is being developed, a backlog of F6 tickets causes a headache? With Fedora's fast-paced development, better focus on tickets about F8 and rawhide. > > The NEEDINFO > > state should be used when there is committment to moving forward with a > > ticket, not just to give the reporter something to do after a long of no > > interest in the report. > > Are you saying that triagers should not use NEEDINFO for current bugs? > At that point, there's not developer commitment, there is triager > commitment. *What* type of activity can you guarantee after the reporter (or somebody else) has cleared the NEEDINFO state? From rc040203 at freenet.de Sun Jan 6 04:00:13 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 06 Jan 2008 05:00:13 +0100 Subject: Another selinux rant In-Reply-To: <16de708d0801042336n2fe73d69o62afe39c1583eb61@mail.gmail.com> References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <1199514823.6022.62.camel@beck.corsepiu.local> <16de708d0801042336n2fe73d69o62afe39c1583eb61@mail.gmail.com> Message-ID: <1199592013.6022.83.camel@beck.corsepiu.local> On Sat, 2008-01-05 at 01:36 -0600, Arthur Pemberton wrote: > On Jan 5, 2008 12:33 AM, Ralf Corsepius wrote: > > > > On Fri, 2008-01-04 at 12:07 -0500, John Dennis wrote: > > > Ed Swierk wrote: > > > > People who already know about SELinux can of course just learn to type > > > > ls -l --lcontext, but showing the extra information by default would > > > > at least give clueless users like me a hint that files have these > > > > extra attributes that might somehow be relevant to those strange > > > > openvpn failures. IMHO this would be the single best usability > > > > improvement to SELinux > > > > > > Re SELinux usability issues: > > > > > > We wrote the setroubleshoot package precisely to help SELinux novice > > > users so they wouldn't suffer with hidden obscure failures of the type > > > which have frustrated you. If it had been installed you would have > > > received notifications in real time on your desktop describing the > > > failure and suggestions on how to fix it. > > Well, honorable goal, but does it actually achieve this goal? > > > > * On one machine (FC8/x86_64), for me, all setroubleshoot does is to die > > shortly after bootup and first-time login (I haven't tried to > > investigate, but as it seems to me some serelated daemon is > > segfaulting). > > You don't possibly think that this is the regular behaviour of > setroubleshoot on which you cna judge it? No, I am pretty certain it's an setroubleshoot and/or its infrastructure bug. > > * Is it appropriate to inform arbitrary ordinary users about SELinux > > issues? May-be this on single user/non-networked machines, but I don't > > think this is the right concept for a networked environment in which > > "ordinary user" normally isn't the system admin. > > I'm not sure i understand the criticism here. The question behind this: To whom are SELinux messages/is setroubleshoot of interest and who is able to react upon them? In production systems, it's the system admin and nobody else. For example, think about an "ordinary (SMB) office" situation. Most of such a system's users will not administrate their machines by themselves, many of these users will be computer illiterates. All setroubleshoot offers to them is "clutter" to their desktop for issues which are "none of their business". In a "Linux-geek at home"/"personal desktop" scenario, the situation is different. IMO, this is the scenario Fedora's current setroubleshoot is appropriate for. Ralf From subhodip at fedoraproject.org Sun Jan 6 04:16:52 2008 From: subhodip at fedoraproject.org (subhodip biswas) Date: Sun, 6 Jan 2008 09:46:52 +0530 Subject: integration of LTSP 5 in fedora In-Reply-To: <477FCC43.1070008@gmail.com> References: <539333cb0801040958r5ceb61b3t3d32b413b578d355@mail.gmail.com> <539333cb0801042058j793f301dsfe75747094b0968@mail.gmail.com> <20080105094839.GE2570@free.fr> <477FCC43.1070008@gmail.com> Message-ID: <539333cb0801052016h1865b9a3o9888a1919d33fd81@mail.gmail.com> so anyone thinking on that ...or taking any initiative ??? i think are quite afew changes in upstream in between LTSP 4 and 5. -- Regards Subhodip Biswas GPG key : FAEA34AB Server : pgp.mit.edu http://subhodipbiswas.wordpress.com http:/www.fedoraproject.org/wiki/SubhodipBiswas From lordmorgul at gmail.com Sun Jan 6 05:09:20 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sat, 05 Jan 2008 21:09:20 -0800 Subject: Another selinux rant In-Reply-To: <1199592013.6022.83.camel@beck.corsepiu.local> References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <1199514823.6022.62.camel@beck.corsepiu.local> <16de708d0801042336n2fe73d69o62afe39c1583eb61@mail.gmail.com> <1199592013.6022.83.camel@beck.corsepiu.local> Message-ID: <47806280.2080101@gmail.com> Ralf Corsepius wrote: > On Sat, 2008-01-05 at 01:36 -0600, Arthur Pemberton wrote: >> On Jan 5, 2008 12:33 AM, Ralf Corsepius wrote: >>> On Fri, 2008-01-04 at 12:07 -0500, John Dennis wrote: >>>> Ed Swierk wrote: >>>>> People who already know about SELinux can of course just learn to type >>>>> ls -l --lcontext, but showing the extra information by default would >>>>> at least give clueless users like me a hint that files have these >>>>> extra attributes that might somehow be relevant to those strange >>>>> openvpn failures. IMHO this would be the single best usability >>>>> improvement to SELinux >>>> Re SELinux usability issues: >>>> >>>> We wrote the setroubleshoot package precisely to help SELinux novice >>>> users so they wouldn't suffer with hidden obscure failures of the type >>>> which have frustrated you. If it had been installed you would have >>>> received notifications in real time on your desktop describing the >>>> failure and suggestions on how to fix it. >>> Well, honorable goal, but does it actually achieve this goal? >>> >>> * On one machine (FC8/x86_64), for me, all setroubleshoot does is to die >>> shortly after bootup and first-time login (I haven't tried to >>> investigate, but as it seems to me some serelated daemon is >>> segfaulting). >> You don't possibly think that this is the regular behaviour of >> setroubleshoot on which you cna judge it? > No, I am pretty certain it's an setroubleshoot and/or its infrastructure > bug. > >>> * Is it appropriate to inform arbitrary ordinary users about SELinux >>> issues? May-be this on single user/non-networked machines, but I don't >>> think this is the right concept for a networked environment in which >>> "ordinary user" normally isn't the system admin. >> I'm not sure i understand the criticism here. > The question behind this: To whom are SELinux messages/is setroubleshoot > of interest and who is able to react upon them? > > In production systems, it's the system admin and nobody else. > > For example, think about an "ordinary (SMB) office" situation. > Most of such a system's users will not administrate their machines by > themselves, many of these users will be computer illiterates. > All setroubleshoot offers to them is "clutter" to their desktop for > issues which are "none of their business". Naturally... which is the reason those users should not have setroubleshoot available to them... the name itself should make this obvious. Its a tool made for the development phase of a technology, not for a production system in a typical office environment. > In a "Linux-geek at home"/"personal desktop" scenario, the situation is > different. IMO, this is the scenario Fedora's current setroubleshoot is > appropriate for. Yes, I've personally found it very helpful in testing rawhide in this scenario. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From dtimms at iinet.net.au Sun Jan 6 05:22:34 2008 From: dtimms at iinet.net.au (David Timms) Date: Sun, 06 Jan 2008 16:22:34 +1100 Subject: LTSP 5 on Fedora In-Reply-To: <47022DB3.30408@asic.udl.cat> References: <4700E9FE.8000409@asic.udl.cat> <4700F967.9010808@redhat.com> <47022DB3.30408@asic.udl.cat> Message-ID: <4780659A.7000602@iinet.net.au> Alexandre Magaz Gra?a wrote: >> Alexandre Magaz Gra?a wrote: >>> While searching for LTSP 5 for Fedora, I didn't find anything but >>> this bug report https://bugzilla.redhat.com/show_bug.cgi?id=234048. >>> Also, I've not found anything regarding LTSP in this list. >>> >>> So, Is someone working on LTSP 5 support for Fedora? Is there some >>> repository were pick code from or anything? Just a side note: Warren Togami's Feature overview page for a K12Linux spin is at: http://fedoraproject.org/wiki/Features/K12Linux DaveT. From loupgaroublond at gmail.com Sun Jan 6 05:29:58 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Sun, 6 Jan 2008 00:29:58 -0500 Subject: Init : someone could comment this ? In-Reply-To: <47801DC3.8010104@ncsu.edu> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> Message-ID: <7f692fec0801052129l3aabd5b8t6c1e0c9b7397dea6@mail.gmail.com> On Jan 5, 2008 7:16 PM, Casey Dahlin wrote: > there may be an advantage. I don't know if I like python in particular > for this roll (maybe something like Haskell that has proven to be light > and quick as well as nicer to deal with) but python is very entrenched +1 million :D I'm actually very interested. -Yaakov From cjdahlin at ncsu.edu Sun Jan 6 06:17:02 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Sun, 06 Jan 2008 01:17:02 -0500 Subject: Init : someone could comment this ? In-Reply-To: <7f692fec0801052129l3aabd5b8t6c1e0c9b7397dea6@mail.gmail.com> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <7f692fec0801052129l3aabd5b8t6c1e0c9b7397dea6@mail.gmail.com> Message-ID: <4780725E.1010604@ncsu.edu> Yaakov Nemoy wrote: > On Jan 5, 2008 7:16 PM, Casey Dahlin wrote: > >> there may be an advantage. I don't know if I like python in particular >> for this roll (maybe something like Haskell that has proven to be light >> and quick as well as nicer to deal with) but python is very entrenched >> > > +1 million :D > > I'm actually very interested. > > -Yaakov > > Heh. Haskell is still on my "need to learn" list. A recent glance at the programming language shootout bumped it up a bit :) Rewriting a few init scripts or adding LSB headers could be part of the hackfest. On that note, is there a packaging requirement now that any new init scripts must have LSB headers? Should there be? --CJD From dimi at lattica.com Sun Jan 6 06:20:47 2008 From: dimi at lattica.com (Dimi Paun) Date: Sun, 06 Jan 2008 01:20:47 -0500 Subject: Init : someone could comment this ? In-Reply-To: <47801DC3.8010104@ncsu.edu> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> Message-ID: <1199600447.4670.167.camel@dimi.lattica.com> On Sat, 2008-01-05 at 19:16 -0500, Casey Dahlin wrote: > As for rewriting some of the scripts themselves in a non-bash > language, there may be an advantage. I don't know if I like python in > particular for this roll (maybe something like Haskell that has proven > to be light and quick as well as nicer to deal with) but python is Oh please, I hope you're not being serious! I mean Haskell is cool and all, but it is rather obscure for the vast majority of people, and the last thing we need is yet another strange language mixed in such a critical part of the system. The entire point of having a scripting language in the init scripts is for the admins to have a chance of making small adjustments easily. If we use Haskell, we lose 99.99% of the population right there. We might as well just code them in C: that would provide for faster start-up AND it will be accessible to most people. -- Dimi Paun Lattica, Inc. From cjdahlin at ncsu.edu Sun Jan 6 06:22:58 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Sun, 06 Jan 2008 01:22:58 -0500 Subject: Init : someone could comment this ? In-Reply-To: <1199600447.4670.167.camel@dimi.lattica.com> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <1199600447.4670.167.camel@dimi.lattica.com> Message-ID: <478073C2.8020407@ncsu.edu> Dimi Paun wrote: > On Sat, 2008-01-05 at 19:16 -0500, Casey Dahlin wrote: > >> As for rewriting some of the scripts themselves in a non-bash >> language, there may be an advantage. I don't know if I like python in >> particular for this roll (maybe something like Haskell that has proven >> to be light and quick as well as nicer to deal with) but python is >> > > Oh please, I hope you're not being serious! I mean Haskell is cool > and all, but it is rather obscure for the vast majority of people, > and the last thing we need is yet another strange language mixed in > such a critical part of the system. > > The entire point of having a scripting language in the init scripts > is for the admins to have a chance of making small adjustments easily. > If we use Haskell, we lose 99.99% of the population right there. > We might as well just code them in C: that would provide for faster > start-up AND it will be accessible to most people. > > I don't know that I find Haskell to be that obscure, but point taken. --CJD From g at socallinuxexpo.org Sun Jan 6 06:36:23 2008 From: g at socallinuxexpo.org (Gareth J. Greenaway) Date: Sat, 5 Jan 2008 22:36:23 -0800 Subject: SCALE Early Bird Registration ends tonight! Message-ID: <20080105223623.0ce02d08.g@socallinuxexpo.org> If you haven't already registered for the SoCal Linux Expo, now's the time. Early Bird registration ends tonight! Fedora developers who are interested in attending SCALE can use the promotional code, FDRA and receive a 50% discount on a full access pass to the show. Thanks and we'll see you at SCALE! Gareth -- Gareth J. Greenaway Voice - 877-831-2569 x130 Southern California Linux Expo http://www.socallinuxexpo.org From wart at kobold.org Sun Jan 6 08:01:44 2008 From: wart at kobold.org (Wart) Date: Sun, 06 Jan 2008 00:01:44 -0800 Subject: New tcl-8.5 and 8Kingdoms In-Reply-To: <477D5E86.2030004@hhs.nl> References: <477D5C7F.6050708@hhs.nl> <477D5C87.2010106@kobold.org> <477D5E86.2030004@hhs.nl> Message-ID: <47808AE8.7090702@kobold.org> Hans de Goede wrote: > Michael Thomas wrote: >> Did you have to make any changes to 8Kingdoms to get it to build with >> Tcl 8.5? If so please pass along any patches. I'll try building and >> running it myself to see if I can track down the problem. >> > > Nope, > > No changes, I also did a diff between the buildlogs, no new compiler > warnings or anything like that. > > I did build it with gcc-4.3, as I was working on it not building with > gcc-4.3 too. > > I've just committed my latest 8Kingdoms work to cvs, so you can get it > from there, including a patch for the crash you reported (tested using > tcl 8.4). It looks like it's a result of the stack checking code in the Tcl library itself. Turning off the stack checking code by compiling Tcl with -DTCL_NO_STACK_CHECK=1 makes the problem in 8Kingdoms go away. With the stack checking turned on, the Tcl scripts in 8Kingdoms fail with the error "out of stack space (infinite loop?)". This error is generated by the stack checking code in tclBasic.c line 3439. I don't understand enough of this stack checking stuff to debug it any further, unfortunately. --Mike From j.w.r.degoede at hhs.nl Sun Jan 6 09:03:33 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 06 Jan 2008 10:03:33 +0100 Subject: New tcl-8.5 and 8Kingdoms In-Reply-To: <47808AE8.7090702@kobold.org> References: <477D5C7F.6050708@hhs.nl> <477D5C87.2010106@kobold.org> <477D5E86.2030004@hhs.nl> <47808AE8.7090702@kobold.org> Message-ID: <47809965.8090305@hhs.nl> Wart wrote: > Hans de Goede wrote: >> Michael Thomas wrote: >>> Did you have to make any changes to 8Kingdoms to get it to build with >>> Tcl 8.5? If so please pass along any patches. I'll try building and >>> running it myself to see if I can track down the problem. >>> >> Nope, >> >> No changes, I also did a diff between the buildlogs, no new compiler >> warnings or anything like that. >> >> I did build it with gcc-4.3, as I was working on it not building with >> gcc-4.3 too. >> >> I've just committed my latest 8Kingdoms work to cvs, so you can get it >> from there, including a patch for the crash you reported (tested using >> tcl 8.4). > > It looks like it's a result of the stack checking code in the Tcl > library itself. Turning off the stack checking code by compiling Tcl > with -DTCL_NO_STACK_CHECK=1 makes the problem in 8Kingdoms go away. > > With the stack checking turned on, the Tcl scripts in 8Kingdoms fail > with the error "out of stack space (infinite loop?)". This error is > generated by the stack checking code in tclBasic.c line 3439. > > I don't understand enough of this stack checking stuff to debug it any > further, unfortunately. > Well that looks like C-code to me, so I'll dive into it when I find the time. Regards, Hans From j.w.r.degoede at hhs.nl Sun Jan 6 09:18:30 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 06 Jan 2008 10:18:30 +0100 Subject: New tcl-8.5 and 8Kingdoms In-Reply-To: <47808AE8.7090702@kobold.org> References: <477D5C7F.6050708@hhs.nl> <477D5C87.2010106@kobold.org> <477D5E86.2030004@hhs.nl> <47808AE8.7090702@kobold.org> Message-ID: <47809CE6.2030306@hhs.nl> Wart wrote: > Hans de Goede wrote: >> Michael Thomas wrote: >>> Did you have to make any changes to 8Kingdoms to get it to build with >>> Tcl 8.5? If so please pass along any patches. I'll try building and >>> running it myself to see if I can track down the problem. >>> >> Nope, >> >> No changes, I also did a diff between the buildlogs, no new compiler >> warnings or anything like that. >> >> I did build it with gcc-4.3, as I was working on it not building with >> gcc-4.3 too. >> >> I've just committed my latest 8Kingdoms work to cvs, so you can get it >> from there, including a patch for the crash you reported (tested using >> tcl 8.4). > > It looks like it's a result of the stack checking code in the Tcl > library itself. Turning off the stack checking code by compiling Tcl > with -DTCL_NO_STACK_CHECK=1 makes the problem in 8Kingdoms go away. > > With the stack checking turned on, the Tcl scripts in 8Kingdoms fail > with the error "out of stack space (infinite loop?)". This error is > generated by the stack checking code in tclBasic.c line 3439. > > I don't understand enough of this stack checking stuff to debug it any > further, unfortunately. > This: http://www.nabble.com/--tcl-Bugs-1815573---Stack-space-check-fails-in-Linux-x86-build-td14439502.html Is very interesting in this regard, it may be a good idea to completely disable stack checking for now, but I'm a bit quick with judging this atm. I'll take a further look as time permits. Right now I first have to go fill in some Tax Forms :( Regards, Hans From j.w.r.degoede at hhs.nl Sun Jan 6 09:24:34 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 06 Jan 2008 10:24:34 +0100 Subject: New tcl-8.5 and 8Kingdoms In-Reply-To: <47808AE8.7090702@kobold.org> References: <477D5C7F.6050708@hhs.nl> <477D5C87.2010106@kobold.org> <477D5E86.2030004@hhs.nl> <47808AE8.7090702@kobold.org> Message-ID: <47809E52.5030506@hhs.nl> Wart wrote: > Hans de Goede wrote: >> Michael Thomas wrote: >>> Did you have to make any changes to 8Kingdoms to get it to build with >>> Tcl 8.5? If so please pass along any patches. I'll try building and >>> running it myself to see if I can track down the problem. >>> >> Nope, >> >> No changes, I also did a diff between the buildlogs, no new compiler >> warnings or anything like that. >> >> I did build it with gcc-4.3, as I was working on it not building with >> gcc-4.3 too. >> >> I've just committed my latest 8Kingdoms work to cvs, so you can get it >> from there, including a patch for the crash you reported (tested using >> tcl 8.4). > > It looks like it's a result of the stack checking code in the Tcl > library itself. Turning off the stack checking code by compiling Tcl > with -DTCL_NO_STACK_CHECK=1 makes the problem in 8Kingdoms go away. > > With the stack checking turned on, the Tcl scripts in 8Kingdoms fail > with the error "out of stack space (infinite loop?)". This error is > generated by the stack checking code in tclBasic.c line 3439. > > I don't understand enough of this stack checking stuff to debug it any > further, unfortunately. > And here is another program which is known to brake with stack checking: http://wiki.tcl.tk/20153 Quoting the author: "The stack checking is somewhat of a hack IMO anyway" "Unfortunately as long as the broken stack checking remains in Tcl, this must require compiling Tcl with -DTCL_NO_STACK_CHECK." So maybe it would be best to just disable it on Fedora? Regards, Hans From enrico.scholz at informatik.tu-chemnitz.de Sun Jan 6 10:36:03 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sun, 06 Jan 2008 11:36:03 +0100 Subject: Init : someone could comment this ? In-Reply-To: <47801DC3.8010104@ncsu.edu> (Casey Dahlin's message of "Sat, 05 Jan 2008 19:16:03 -0500") References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> Message-ID: <877iin6y24.fsf@kosh.bigo.ensc.de> Casey Dahlin writes: > There is work being done in this area for Fedora as well. I've been > working on a parallel booting system for us that also will provide > dbus notifications for the starting of various services. mmh... does this mean, Fedora will use its own proprietary initsystem and ignores the existing ones (initng, upstart)? > As for rewriting some of the scripts themselves in a non-bash > language, An initsystem which requires depbloat like python or perl is completely unacceptably. Enrico From nicolas.mailhot at laposte.net Sun Jan 6 10:50:18 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 06 Jan 2008 11:50:18 +0100 Subject: Init : someone could comment this ? In-Reply-To: <47804A59.6090205@ncsu.edu> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <645d17210801051646p71711a7ck7d3824572fe8ed21@mail.gmail.com> <47804A59.6090205@ncsu.edu> Message-ID: <1199616618.9194.26.camel@rousalka.dyndns.org> Le samedi 05 janvier 2008 ? 22:26 -0500, Casey Dahlin a ?crit : > There's a few issues with prcsys internally that make it very difficult > to add the features we want (dbus etc), as well as some not-so-trivial > implementation issues (use of pthreads in a circumstance under which > they were a very poor choice), so Harald Hoyer and myself decided that a > rewrite was in order, so I went ahead and started working on a new app > (which I have titled 'rrn') which is now near feature parity with > prcsys. It would be very nice if the next-gen init system didn't limit itself to the system init part but also covered session init steps. The desktop team is dead-set against system-wide daemons?, and as a result we've seen a flourishing of in-session "helpers", all launched in a more-or-less hackish, racish and unsatisfactory way: ? when the state of the art for PA is to pretend it's ESD to be launched, there are clearly huge problems in our session init handling. ? sometimes you do a ps and see stray session daemons remaining alive hours after session close ? it's not uncommon for GNOME to start doing things before initialising its settings, causing users to wonder why the theme or fonts change 3s after starting an app ? etc Session init and system init seem very similar problems to me, and if we ever want to go early login like windows, we'll need to coordinate session init steps with the system init steps not finished yet. Of course there are complications (you need to merge system presets and user preferences, take the kind of login? and DE into account) but the similarities should far outweight the differences. Regards, ? with some good and a lot of bad (IMHO) reasons ? is it so different from classical system init levels? -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From raven at themaw.net Sun Jan 6 10:54:04 2008 From: raven at themaw.net (Ian Kent) Date: Sun, 06 Jan 2008 19:54:04 +0900 Subject: Proceedure for package private branches for testing Message-ID: <1199616844.3434.7.camel@raven.themaw.net> Hi all, Sometimes when trying to solve a problem I need to add a patch to a package, say kernel, and do a build (probably a scratch build) to test and possibly have the reporter use it for testing as well. So can someone tell me what the proper procedure is for creating a private branch for a package in Fedora? Ian From cjdahlin at ncsu.edu Sun Jan 6 11:07:53 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Sun, 06 Jan 2008 06:07:53 -0500 Subject: Init : someone could comment this ? In-Reply-To: <877iin6y24.fsf@kosh.bigo.ensc.de> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> Message-ID: <4780B689.60303@ncsu.edu> Enrico Scholz wrote: > Casey Dahlin writes: > > >> There is work being done in this area for Fedora as well. I've been >> working on a parallel booting system for us that also will provide >> dbus notifications for the starting of various services. >> > > mmh... does this mean, Fedora will use its own proprietary initsystem > and ignores the existing ones (initng, upstart)? > > This has been answered here already. > >> As for rewriting some of the scripts themselves in a non-bash >> language, >> > > An initsystem which requires depbloat like python or perl is completely > unacceptably. > > Well, I'm convinced :/ > Enrico > > From cjdahlin at ncsu.edu Sun Jan 6 11:14:27 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Sun, 06 Jan 2008 06:14:27 -0500 Subject: Init : someone could comment this ? In-Reply-To: <1199616618.9194.26.camel@rousalka.dyndns.org> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <645d17210801051646p71711a7ck7d3824572fe8ed21@mail.gmail.com> <47804A59.6090205@ncsu.edu> <1199616618.9194.26.camel@rousalka.dyndns.org> Message-ID: <4780B813.1070700@ncsu.edu> Nicolas Mailhot wrote: > Le samedi 05 janvier 2008 ? 22:26 -0500, Casey Dahlin a ?crit : > > >> There's a few issues with prcsys internally that make it very difficult >> to add the features we want (dbus etc), as well as some not-so-trivial >> implementation issues (use of pthreads in a circumstance under which >> they were a very poor choice), so Harald Hoyer and myself decided that a >> rewrite was in order, so I went ahead and started working on a new app >> (which I have titled 'rrn') which is now near feature parity with >> prcsys. >> > > It would be very nice if the next-gen init system didn't limit itself to > the system init part but also covered session init steps. The desktop > team is dead-set against system-wide daemons?, and as a result we've > seen a flourishing of in-session "helpers", all launched in a > more-or-less hackish, racish and unsatisfactory way: > ? when the state of the art for PA is to pretend it's ESD to be > launched, there are clearly huge problems in our session init handling. > ? sometimes you do a ps and see stray session daemons remaining alive > hours after session close > ? it's not uncommon for GNOME to start doing things before initialising > its settings, causing users to wonder why the theme or fonts change 3s > after starting an app > ? etc > > Session init and system init seem very similar problems to me, and if we > ever want to go early login like windows, we'll need to coordinate > session init steps with the system init steps not finished yet. Of > course there are complications (you need to merge system presets and > user preferences, take the kind of login? and DE into account) but the > similarities should far outweight the differences. > > Regards, > > ? with some good and a lot of bad (IMHO) reasons > ? is it so different from classical system init levels? > > I'd be happy to take a look at this problem once we've gotten the core problem out of the way. PA in particular really could do to be a system wide service. What if we activated GDM greeter noises? --CJD From Lam at Lam.pl Sun Jan 6 11:58:08 2008 From: Lam at Lam.pl (Leszek Matok) Date: Sun, 6 Jan 2008 12:58:08 +0100 Subject: Why does gdb now give lots of warnings? In-Reply-To: <1199477578.3035.2.camel@watson> References: <18302.18459.463805.56859@zebedee.pink> <1199477578.3035.2.camel@watson> Message-ID: <20080106125808.5f5bf9c4@pensja.lam.pl> Dnia 2008-01-04, o godz. 21:12:58 David Nielsen napisa?(a): > Sounds like a job for PackageKit, look up the path to figure out which > packages we are missing and offer the user to install the missing debug > symbols. I DREAM about gdb stopping at a missing debuginfo, downloading repository meta-data, proposing downloading of 70 packages and asking me if I want to continue with the downloading and installing. Especially scripted gdb incantations will be happy (if you think you don't use any, remember bug-buddy). Please leave gdb to professionals and don't break it with your (smarter than the user) hacks. BTW: "yum install /usr/lib/debug..." won't work on the default installation. You need "yum --enablerepo={fedora|development|updates|updates-testing}-debuginfo install...". That's why debuginfo-install should be taught to understand file paths as its argument (if it doesn't already). Also, if you really want to be helpful, tell user to "add-shared-symbol-files" after he installs debuginfo packages in another shell. If that works, that is, I've never tested. Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From opensource at till.name Sun Jan 6 12:09:38 2008 From: opensource at till.name (Till Maas) Date: Sun, 06 Jan 2008 13:09:38 +0100 Subject: Proceedure for package private branches for testing In-Reply-To: <1199616844.3434.7.camel@raven.themaw.net> References: <1199616844.3434.7.camel@raven.themaw.net> Message-ID: <200801061309.43329.opensource@till.name> On Sun January 6 2008, Ian Kent wrote: > Sometimes when trying to solve a problem I need to add a patch to a > package, say kernel, and do a build (probably a scratch build) to test > and possibly have the reporter use it for testing as well. > > So can someone tell me what the proper procedure is for creating a > private branch for a package in Fedora? The easiest way I know, is to check out the branch you want to modify in a separate directory, patch, run "make srpm" and make a scratch build with "koji build --scratch dist-f9 *.src.rpm". For patching I begin to use - make prep - then go into the source directory - run a cp -a file $file.$description on files I want to patch - then edit $file - go back to the directory where the spec is in - run make patch SUFFIX=$description (or maybe mae patch SUFFIX=.$description) - add the patch to the spec with %patchXX -b .$description When the patch needs to adjusted, after running "make prep", there is already a $file.$description, and $file is patched, and a "make rediff SUFFIX=$description" keeps the comments before the first diff in the patch file. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From caolanm at redhat.com Sun Jan 6 12:14:15 2008 From: caolanm at redhat.com (Caolan McNamara) Date: Sun, 06 Jan 2008 12:14:15 +0000 Subject: rawhide report: bacula/kannel -> mktexlsr ? In-Reply-To: References: <200801051224.m05COEwl021556@porkchop.devel.redhat.com> <1199562968.11839.34.camel@Jehannum> Message-ID: <1199621655.11839.75.camel@Jehannum> On Sat, 2008-01-05 at 16:24 -0700, Alex Lancaster wrote: > In the bacula case here is the bz (doesn't seem to be an open bug for > kannel): > > https://bugzilla.redhat.com/show_bug.cgi?id=414381 > > Also, bacula has closed ACLs, so nobody can currently rebuild the > package if and when this packaging issue is resolved. Can somebody > please open them up? Well I think that anyone can run make build and get it built as rel-eng bumped the nvr of it previously and there hasn't been a successful build so if the latex2html thing is the real problem and it gets fixed and no changes to bacula are needed we can just build it post out-of-package fix. C. From raven at themaw.net Sun Jan 6 12:19:09 2008 From: raven at themaw.net (Ian Kent) Date: Sun, 06 Jan 2008 21:19:09 +0900 Subject: Proceedure for package private branches for testing In-Reply-To: <200801061309.43329.opensource@till.name> References: <1199616844.3434.7.camel@raven.themaw.net> <200801061309.43329.opensource@till.name> Message-ID: <1199621949.6782.7.camel@raven.themaw.net> On Sun, 2008-01-06 at 13:09 +0100, Till Maas wrote: > On Sun January 6 2008, Ian Kent wrote: > > > Sometimes when trying to solve a problem I need to add a patch to a > > package, say kernel, and do a build (probably a scratch build) to test > > and possibly have the reporter use it for testing as well. > > > > So can someone tell me what the proper procedure is for creating a > > private branch for a package in Fedora? > > The easiest way I know, is to check out the branch you want to modify in a > separate directory, patch, run "make srpm" and make a scratch build > with "koji build --scratch dist-f9 *.src.rpm". Yes, I got this advice on IRC and managed to get a build. It's really cumbersome though. Is it a problem to allow commits for specific named branches like private-.....-branch and ignore them for composition purposes? > > For patching I begin to use > - make prep > - then go into the source directory > - run a cp -a file $file.$description on files I want to patch > - then edit $file > - go back to the directory where the spec is in > - run make patch SUFFIX=$description (or maybe mae patch SUFFIX=.$description) > - add the patch to the spec with %patchXX -b .$description Thanks for the advice. I'm fine with the patching thing but I haven't used "make patch" before (or make rediff for that matter), interesting. Ian From triad at df.lth.se Sun Jan 6 12:19:38 2008 From: triad at df.lth.se (Linus Walleij) Date: Sun, 6 Jan 2008 13:19:38 +0100 (CET) Subject: Disabling selinux question In-Reply-To: <200801050829.12065.sgrubb@redhat.com> References: <200801040858.36273.sgrubb@redhat.com> <200801050829.12065.sgrubb@redhat.com> Message-ID: On Sat, 5 Jan 2008, Steve Grubb wrote: > I changed some wording, but an improved description will be in the audit > daemon 1.6.5 init script which should be out sometime next week. I'll push it > to F8 after its been in rawhide a few days. That's perfect Steve, thanks a lot! Linus From caolanm at redhat.com Sun Jan 6 12:24:51 2008 From: caolanm at redhat.com (Caolan McNamara) Date: Sun, 06 Jan 2008 12:24:51 +0000 Subject: mktexlsr/texhash/texconfig-sys rehash, what's the canonical %post/%postun for a TeX thing ? In-Reply-To: References: <200801051224.m05COEwl021556@porkchop.devel.redhat.com> <1199562968.11839.34.camel@Jehannum> Message-ID: <1199622291.11839.81.camel@Jehannum> On Sat, 2008-01-05 at 16:24 -0600, Jason L Tibbitts III wrote: > >>>>> "CM" == Caolan McNamara writes: > > CM> So, what exactly is the current problem with these two ? Is it > CM> just the mysterious failure of TeX to execute some stuff, i.e. > > Yes, I debugged this the other day. The problem for bacula is that > latex2html somehow does not properly run texhash in %post, so nothing > can find html.sty. If you force a texhash it works. Changing the > post scriptlet for latex2html to not use "/usr/bin/env - > /usr/bin/texhash" but to just call texhash directly works. I don't > know why. I see that another tex package e.g. jadetex has a comment about "use texconfig-sys rehash instead of texhash", and the change was... %post -/usr/bin/env - PATH=$PATH:%{TeXdir}/bin texhash > /dev/null 2>&1 +[ -x %{_bindir}/texconfig-sys ] && %{_bindir}/texconfig-sys rehash 2> /dev/null || : +%postun +[ -x %{_bindir}/texconfig-sys ] && %{_bindir}/texconfig-sys rehash 2> /dev/null || : + So maybe a determination of the right way to rehash is called for and consistent usage might clear this up ? C. From fedora at leemhuis.info Sun Jan 6 12:24:55 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 06 Jan 2008 13:24:55 +0100 Subject: EPEL report week 01/2008 Message-ID: <4780C897.90408@leemhuis.info> http://fedoraproject.org/wiki/EPEL/Reports/Week01 = Weekly EPEL Summary = Week 01/2008 == Most important happenings == * [https://www.redhat.com/archives/epel-devel-list/2008-January/msg00024.html Faster builds in plague] due to some optimizations done by Michael Schwendt (thx Michael!) * From the meeting summary: we'll do the EPEL5 moves from testing to stable around the 1st each months; the moves for epel4 are scheduled for the 15th each month == Mailing list == === Noteworthy discussions === * [https://www.redhat.com/archives/epel-devel-list/2008-January/msg00001.html Clamav-Saga continues] == Meeting == === Next Meeting === 20080116 at 18:00 UTC in #fedora-meeting. === Last weeks meeting === Attendees: * [:RobMyers:_blah_] * [:DennisGilmore:dgilmore] * [:JesseKeating:f13] * [:JeffSheltren:Jeff_S] * [:ThorstenLeemhuis:knurd] * [:MikeMcGrath:mmcgrath] * [:KevinFenzi:nirik] * [:KarstenWade:quaid] * [:MichaelStahnke:stahnma] * [:JasonTibbitts:tibbs] Summary: * next testing -> stable move | knurd | http://fedoraproject.org/wiki/EPEL/Tasks/NextTestingStableMove * we'll do the EPEL5 moves from testing to stable around the 1st each months; the moves for epel4 are scheduled for the 15th each month * knurd will write down the procedure next time , then nirik and others can help in the future * EL-updates to the buildsys | unassigned | http://fedoraproject.org/wiki/EPEL/Tasks/Misc * mmcgrath will look into how to get the updates from RHN daily into a repo which is used by mock to set up the EPEL buildroots; issue is tracked in [https://fedorahosted.org/fedora-infrastructure/ticket/327 this ticket]; see also:https://www.redhat.com/archives/epel-devel-list/2008-January/msg00038.html * RHEL MetaData | stahnma | http://fedoraproject.org/wiki/EPEL/Tasks/RhelMetaData * stahnma> | sorry , not much to update ; I am working on it and didn't have much time over the holidays am hoping for more very soon * KojiAndBodhiForEpel | mmcgrath | http://fedoraproject.org/wiki/EPEL/Tasks/KojiAndBodhiForEpel * mmcgrath> | nothing over the holidays. We're hopeful but nothing concrete yet. * Free discussion around EPEL * tibbs mentioned there was a review for an EPEL-only package (tetex-lineno, https://bugzilla.redhat.com/show_bug.cgi?id=426929 );The only real issue with that review is what to do with the devel branch. * it was agreed on that a dead.package-file should in the devel branch (that's what was done) is the best approach * fudcon? * mmcgrath, nirik and quiad will be there * nirik> | well, the one thing I can think of would be to do a 'what is epel and why I should branch my packages for it' type session... == Stats == === General === Number of EPEL Contributors: 165 We welcome 2 new contributors: michich rezso === EPEL 5 === Number of source packages: 963 Number of binary packages: 1772 There are 23 new Packages: * altermime | Alter MIME-encoded mailpacks * cernlib-g77 | General purpose CERN library * cernlib | General purpose CERN library * compface | Utilities for handling X-Faces * deltarpm | Create deltas between rpms * dosbox | x86/DOS emulator with sound and graphics * fluxbox | Window Manager based on Blackbox * glpi | Free IT asset management software * grads | Tool for easy acces, manipulation, and visualization of data * imlib2 | Image loading, saving, rendering, and manipulation library * libAfterImage | A generic image manipulation library * perl-Cache | The Cache interface * perl-File-MimeInfo | Determine file type and open application * perl-Inline-Files | Allows for multiple inline files in a single perl file * perl-Inline | Inline Perl module * perl-Net-DNS-Resolver-Programmable | Programmable DNS resolver class for offline emulation of DNS * python-xlrd | Library to extract data from Microsoft Excel (tm) spreadsheet files * rxvt | ouR XVT, a VT102 emulator for the X window system * rxvt-unicode | Rxvt-unicode is an unicode version of rxvt * tetex-tex4ht | Translates TeX and LaTeX into HTML or XML+MathML * wgrib | Manipulate, inventory and decode GRIB files * wmix | Dockapp mixer * xchm | A GUI front-end to CHMlib === EPEL 4 === Number of source packages: 577 Number of binary packages: 1096 There are 19 new Packages: * altermime | Alter MIME-encoded mailpacks * deltarpm | Create deltas between rpms * dosbox | An x86/DOS emulator with sound/graphics * glpi | Free IT asset management software * grads | Tool for easy acces, manipulation, and visualization of data * libAfterImage | A generic image manipulation library * perl-Cache | The Cache interface * perl-DBD-SQLite | Self Contained RDBMS in a DBI Driver * perl-File-DesktopEntry | Object to handle .desktop files * perl-File-MimeInfo | Determine file type and open application * perl-Inline-Files | Allows for multiple inline files in a single perl file * perl-Inline | Inline Perl module * python-xlrd | Library to extract data from Microsoft Excel (tm) spreadsheet files * rxvt | Rxvt (ouR XVT) - a VT102 emulator for the X window system * tetex-elsevier | Elsevier LaTeX style files and documentation * tetex-lineno | Add line numbers on paragraphs in LaTeX * tetex-tex4ht | Translates TeX and LaTeX into HTML or XML+MathML * wgrib | Manipulate, inventory and decode GRIB files * wmix | Dockapp mixer ---- ["CategoryEPELReports"] From Lam at Lam.pl Sun Jan 6 12:27:14 2008 From: Lam at Lam.pl (Leszek Matok) Date: Sun, 6 Jan 2008 13:27:14 +0100 Subject: Init : someone could comment this ? In-Reply-To: <47804A59.6090205@ncsu.edu> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <645d17210801051646p71711a7ck7d3824572fe8ed21@mail.gmail.com> <47804A59.6090205@ncsu.edu> Message-ID: <20080106132714.373731a2@pensja.lam.pl> Dnia 2008-01-05, o godz. 22:26:17 Casey Dahlin napisa?(a): > rewrite was in order, so I went ahead and started working on a new app > (which I have titled 'rrn') which is now near feature parity with > prcsys. "rrn" is an old fork of "rn", a usenet reader. Besides, please, don't call features which you will be advertising as breakthroughs in future Fedora versions with onomatopoeias emulating my stomach :) Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From triad at df.lth.se Sun Jan 6 12:48:50 2008 From: triad at df.lth.se (Linus Walleij) Date: Sun, 6 Jan 2008 13:48:50 +0100 (CET) Subject: Init : someone could comment this ? In-Reply-To: <1199616618.9194.26.camel@rousalka.dyndns.org> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <645d17210801051646p71711a7ck7d3824572fe8ed21@mail.gmail.com> <47804A59.6090205@ncsu.edu> <1199616618.9194.26.camel@rousalka.dyndns.org> Message-ID: On Sun, 6 Jan 2008, Nicolas Mailhot wrote: > It would be very nice if the next-gen init system didn't limit itself to > the system init part but also covered session init steps. AFAICS this is what Scott wants to do with "InitKit", briefly outlined here: http://lists.freedesktop.org/archives/initkit/2007-December/000000.html The problem is that right now this seems to be a 1-person project so let's see if it's catching on. Linus From cocobear.cn at gmail.com Sun Jan 6 13:28:21 2008 From: cocobear.cn at gmail.com (cocobear) Date: Sun, 6 Jan 2008 21:28:21 +0800 Subject: Pulse Audio problem In-Reply-To: <1199585527.21972.42.camel@localhost.localdomain> References: <93d66b780801051706s5c9e41b4mb5ba48accc2e56b6@mail.gmail.com> <1199585527.21972.42.camel@localhost.localdomain> Message-ID: <20080106212821.44ce06ea@cocobear> ? Sun, 06 Jan 2008 03:12:07 +0100 Lubomir Kundrak ??: > > On Sat, 2008-01-05 at 20:06 -0500, masch wrote: > > HI! > > Sometimes when I open the PulseAudio Volume Control said: > > Connection failed: Connection refused, and the sound in some > > applications doesn't work. > > Does anyone know how to fix this? > It seemed that it happens on F8 often. > File a bugzilla ticket. > > Your pulseaudio daemon obviously died. Please add output of "grep > pulseaudio /var/log/messages" to the bugzilla ticket. > From buildsys at redhat.com Sun Jan 6 13:41:25 2008 From: buildsys at redhat.com (Build System) Date: Sun, 6 Jan 2008 08:41:25 -0500 Subject: rawhide report: 20080106 changes Message-ID: <200801061341.m06DfP8u002765@porkchop.devel.redhat.com> New package drpython A simple Python IDE designed with teaching in mind New package dwarves Dwarf Tools New package mod_wsgi A WSGI interface for Python web applications in Apache New package python-xlrd Library to extract data from Microsoft Excel (tm) spreadsheet files New package sqliteman Manager for sqlite - Sqlite Databases Made Easy Removed package php-manual-en Updated Packages: GtkAda-2.10.0-2.fc9 ------------------- * Sat Jan 05 2008 Gerard Milmeister - 2.10.0-2 - exclude arch ppc64 * Sat Jan 05 2008 Gerard Milmeister - 2.10.0-1 - new release 2.10.0 - documentation in separate package alsa-tools-1.0.15-2.fc9 ----------------------- * Sat Jan 05 2008 Tim Jackson - 1.0.15-2 - Update License tag to GPLv2+ - ExcludeArch ppc64 (bug #219010) * Sat Jan 05 2008 Tim Jackson - 1.0.15-1 - Update to upstream 1.0.15 - Add icon for envy24control - Build echomixer blt-2.4-21.fc9 -------------- * Sat Jan 05 2008 Sergio Pascual 2.4-21 - Libraries moved to %libdir, file in ld.so.conf.d not needed - Tcl files moved to %tcl_sitelib eggdrop-1.6.18-13.fc9 --------------------- * Sat Jan 05 2008 Robert Scheck 1.6.18-13 - Rebuild for tcl 8.5 evolution-2.21.4-2.fc9 ---------------------- * Thu Jun 05 2008 Matthew Barnes - 2.21.4-2.fc9 - Add patch for GNOME bug #507311 (send Bug Buddy reports to the new BugBuddyBugs Bugzilla component). * Mon Dec 17 2007 Matthew Barnes - 2.21.4-1.fc9 - Update to 2.21.4 - Expunge unused patches. - Bump eds_version to 2.21.4 for new Camel functions. * Mon Dec 10 2007 Matthew Barnes - 2.21.3-4.fc9 - Split junk filtering plugins into evolution-bogofilter and evolution-spamassassin subpackages, each of which requires the necessary backend packages. (RH bug #377381) gle-4.1.1-2.fc9 --------------- * Sat Jan 05 2008 Terje Rosten - 4.1.1-2 - Drop libs and devel packages - Don't ship pc file * Sat Jan 05 2008 Terje Rosten - 4.1.1-1 - 4.1.1 proper * Thu Jan 03 2008 Terje Rosten - 4.1.1-0.1.S010308 - Update to 4.1.1-S010308 (4.1.0 + some gcc 4.3 and 64 bits fixes) - Random spec clean ups - Add man page, lib and pc file. - Create libs and devel subpackage - Add rpath flag to configure gtk-nodoka-engine-0.6.90.1-1.fc9 -------------------------------- * Sat Jan 05 2008 Martin Sourada - 0.6.90.1-1 - Update to 0.7 beta 1 release - Extra themes add to -extras subpackage jabbim-0.3-0.60.20080106svn.fc9 ------------------------------- * Sun Jan 06 2008 Michal Schmidt - 0.3-0.60.20080106svn - Upstream SVN revision 1721. - translation fixes, /join command in MUC, automatic download fix. * Sat Jan 05 2008 Michal Schmidt - 0.3-0.59.20080105svn - Upstream SVN revision 1695. - fixes for profiles, reconnects, logging. kadu-0.6.0-0.6.beta2.fc9 ------------------------ * Sun Jan 06 2008 Micha?? Bentkowski - 0.6.0-0.6.beta2 - Now forgot to include that one source changed its name * Sun Jan 06 2008 Micha?? Bentkowski - 0.6.0-0.5.beta2 - Forgot to upload some sources... * Sat Jan 05 2008 Micha?? Bentkowski - 0.6.0-0.4.beta2 - beta2 - Add kadu-agent kdebase3-3.5.8-28.fc9 --------------------- * Sat Jan 05 2008 Kevin Kofler - 3.5.8-28 - apply upstream build fix for GCC 4.3 (--enable-final macro redefinition) kdewebdev-6:3.5.8-6.fc9 ----------------------- * Sat Jan 05 2008 Kevin Kofler - 6:3.5.8-6 - apply upstream build fix for GCC 4.3 (IS_BLANK macro name conflict w/ libxml) kernel-2.6.24-0.136.rc6.git12.fc9 --------------------------------- * Sat Jan 05 2008 Kyle McMartin - Disable utrace until fixed (doesn't apply to git12 yet.) - Nuke linux-2.6-proc-self-maps-fix.patch, applied upstream. - Respin linux-2.6-smarter-relatime.patch. * Sat Jan 05 2008 Kyle McMartin - 2.6.24-rc6-git12 * Wed Jan 02 2008 Kyle McMartin - Un-disabled -doc builds. klamav-0.41.1-10.fc9 -------------------- * Sat Jan 05 2008 Andy Shevchenko 0.41.1-10 - fix compilation with gcc 4.3 libfprint-0.0.5-2.fc9 --------------------- * Sat Jan 05 2008 Pingou 0.0.5-2 - Change on the BuildRequires libgeotiff-1.2.4-2.fc9 ---------------------- * Sun Jan 06 2008 Balint Cristian - 1.2.4-2 - Fix multilib issue by removal of datetime in doxygen footers * Sun Jan 06 2008 Balint Cristian - 1.2.4-1 - Rebuild for final release. mapserver-5.0.0-1.fc9 --------------------- * Fri Jan 04 2008 Devrim GUNDUZ - 5.0.0-1 - Update to 5.0.0 - Removed patch0, since it is already in upstream. - Updated BRs mfiler2-4.0.6-1.fc9 ------------------- * Sun Jan 06 2008 Mamoru Tasaka - 4.0.6-1 - 4.0.6 ochusha-0.5.99.66-0.4.cvs070110.fc9 ----------------------------------- * Sun Jan 06 2008 Mamoru Tasaka 0.5.99.66-0.4.cvs070110 - Misc fixes for g++43. openmsx-0.6.2-5.fc9 ------------------- * Sat Jan 05 2008 Alex Lancaster - 0.6.2-5 - Rebuild for new Tcl 8.5 perl-MooseX-AttributeHelpers-0.07-1.fc9 --------------------------------------- * Sat Jan 05 2008 Chris Weyl 0.07-1 - update to 0.07 perl-Net-CUPS-0.55-2.fc9 ------------------------ * Wed Jan 02 2008 Ralf Cors??pius 0.55-2 - Adjust Licence-tag. - Spec file cosmetics. - BR: perl(Test::More) (BZ 419631). postgis-1.3.2-2.fc9 ------------------- * Sat Jan 05 2008 Devrim GUNDUZ - 1.3.2-2 - Various fixes from Mark Cave-Ayland - Removed patch2: template_gis is no longer built by default. - Removed patch0: Building the JDBC driver using make is now deprecated - Build JDBC driver using ant, rather than make. * Thu Dec 06 2007 Devrim GUNDUZ - 1.3.2-1 - Update to 1.3.2 - Updated patch2 * Wed Nov 21 2007 Devrim GUNDUZ - 1.3.1-2 - Move postgresql-jdbc dependency to the correct place, per Rob Nagler. postgresql-pgpool-II-2.0.1-1.fc9 -------------------------------- * Sat Jan 05 2008 Devrim Gunduz 2.0.1-1 - Update to 2.0.1 q-7.10-2.fc9 ------------ * Sat Jan 05 2008 Alex Lancaster - 7.10-2 - Rebuild for new Tcl 8.5 redhat-menus-8.9.11-2.fc9 ------------------------- * Sat Jan 05 2008 Matthew Barnes - 8.9.11-2 - Send all Evolution bugs to the new BugBuddyBugs Bugzilla component. (GNOME bug #507311) synaptic-0.57.2-15.fc9 ---------------------- * Fri Jan 04 2008 Panu Matilainen - 0.57.2-15 - fix build with gcc 4.3 (explicit includes for cstring and friends) - fix bunch of const-correctness issues causing gcc complaints * Mon Nov 26 2007 Panu Matilainen - 0.57.2-14 - remove unnecessary extra desktop categories (#283921) - rebuild (#389371) * Tue Aug 28 2007 Fedora Release Engineering - 0.57.2-13 - Rebuild for selinux ppc32 issue. t1lib-5.1.1-5.fc9 ----------------- * Sat Jan 05 2008 Patrice Dumas - 5.1.1-5 - silence t1libconfig when the directories don't exist (#183108) * Sat Jan 05 2008 Patrice Dumas - 5.1.1-4 - separate subpackage for static library - keep timestamps - add more paths to t1libconfig and use rpm macros for those paths - fix the -maxdepth position in find - put t1lib.config and FontDatabase in %{_datadir} these are not config files, they are generated - fix a segfault in t1lib with long TYPE1 lines tbcload-1.4-7.20061030cvs.fc9 ----------------------------- * Sat Jan 05 2008 Wart 1.4-7.20061030cvs - Temporary work around for build issues with Tcl 8.5 * Sat Jan 05 2008 Alex Lancaster - 1.4-6.20061030cvs - Rebuild for new Tcl 8.5 tclcompiler-1.5-6.20061030cvs.fc9 --------------------------------- * Sat Jan 05 2008 Wart 1.5-6.20061030cvs - Downgrade package version number to match tbcload and prevent errors when running 'package require ...' tclparser-1.4-3.20061030cvs.fc9 ------------------------------- tclsoap-1.6.7-5.fc9 ------------------- * Sat Jan 05 2008 Wart - 1.6.7-5 - Rebuild for Tcl 8.5 tktable-2.9-10.fc9 ------------------ * Fri Jan 04 2008 Sergio Pascual 2.9-10 - Rebuilt for tcl 8.5 - Following PackagingDrafts/Tcl tomcat5-0:5.5.25-1jpp.2.fc9 --------------------------- * Sat Jan 05 2008 Devrim GUNDUZ 0:5.5.25-2jpp.2 - Fix for bz #153187 - Fix for bz #426850 - Fix for bz #312561 - Fix init script, per bz #247077 - Fix builds on alpha, per bz #253827. - Fix init script for bz #380921 - Fix tomcat5.conf and spec file for bz #253605 transmission-1.00-1.fc9 ----------------------- * Sat Jan 05 2008 Denis Leroy - 1.00-1 - Update to upstream 1.00. New project URL vkeybd-0.1.17a-6.fc9 -------------------- * Sat Jan 05 2008 Marcela Maslanova 0.1.17a-6 - Upgrade to tcl8.5. xca-0.6.4-3.fc9 --------------- * Sat Jan 05 2008 Alex Lancaster - 0.6.4-3 - Add patch by Caolan McNamara (#427619) to build against new openssl xcircuit-3.4.27-2.fc9 --------------------- * Sat Jan 05 2008 Alex Lancaster - 3.4.27-2 - Rebuild for new Tcl 8.5 xzgv-0.9-2.fc9 -------------- * Sat Jan 05 2008 Terje Rosten - 0.9-2 - Rebuild * Sat Jan 05 2008 Terje Rosten - 0.9-1 - 0.9 - add all patches upto svn r35 fixing install and some other simple stuff - new upstream maintainer, src and url updated - drop patch now upstream - build with gtk2 (yeah!) -> update summary and desc - remove icon line from desktop file (icon gone) - add texinfo to buildreq - add patch to fix install of man and info files Broken deps for i386 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-client - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libcrypto.so.6 csound-tk - 5.03.0-13.fc7.i386 requires libtk8.4.so csound-tk - 5.03.0-13.fc7.i386 requires libtcl8.4.so d4x - 2.5.7.1-3.fc7.i386 requires libssl.so.6 d4x - 2.5.7.1-3.fc7.i386 requires libcrypto.so.6 epiphany-extensions - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires libgtkembedmoz.so expect - 5.43.0-9.fc8.i386 requires libtcl8.4.so expectk - 5.43.0-9.fc8.i386 requires libtk8.4.so expectk - 5.43.0-9.fc8.i386 requires libtcl8.4.so gcl - 2.6.7-15.fc8.i386 requires libtcl8.4.so gcl - 2.6.7-15.fc8.i386 requires libtk8.4.so gnome-web-photo - 0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.i386 requires libgtkembedmoz.so irsim - 9.7.50-1.fc8.i386 requires libtcl8.4.so irsim - 9.7.50-1.fc8.i386 requires libtk8.4.so isdn4k-utils-vboxgetty - 3.2-55.fc8.i386 requires libtcl8.4.so kannel - 1.4.1-5.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 libopensync-plugin-sunbird - 0.22-3.fc7.i386 requires libneon.so.25 libopensync-plugin-sunbird - 0.22-3.fc7.i386 requires libopensync.so.0 libopensync-plugin-sunbird - 0.22-3.fc7.i386 requires libssl.so.6 libopensync-plugin-sunbird - 0.22-3.fc7.i386 requires libcrypto.so.6 libopensync-plugin-synce - 0.22-4.fc8.i386 requires libopensync.so.0 liferea - 1.4.10-1.fc9.i386 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.i386 requires libgtkembedmoz.so magic - 7.4.35-6.fc8.i386 requires libtcl8.4.so magic - 7.4.35-6.fc8.i386 requires libtk8.4.so multisync - 0.91.0-1.fc7.i386 requires libopensync.so.0 multisync - 0.91.0-1.fc7.i386 requires libosengine.so.0 multisync-gui - 0.91.0-1.fc7.i386 requires libopensync.so.0 multisync-gui - 0.91.0-1.fc7.i386 requires libosengine.so.0 netgen - 1.3.7-13.fc9.i386 requires libtcl8.4.so netgen - 1.3.7-13.fc9.i386 requires libtk8.4.so plplot - 5.8.0-5.fc9.i386 requires libtcl8.4.so plplot - 5.8.0-5.fc9.i386 requires libtk8.4.so plplot-tk - 5.8.0-5.fc9.i386 requires libtk8.4.so plplot-tk - 5.8.0-5.fc9.i386 requires libtcl8.4.so postgresql-pltcl - 8.2.5-2.fc9.i386 requires libtcl8.4.so pvm-gui - 3.4.5-7.fc6.1.i386 requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.i386 requires libtcl8.4.so python-gammu - 0.22-3.fc8.i386 requires libGammu.so.2 qtparted - 0.4.5-15.fc8.i386 requires libparted-1.8.so.6 skencil - 0.6.17-15.20070606svn.fc8.i386 requires libtk8.4.so skencil - 0.6.17-15.20070606svn.fc8.i386 requires libtcl8.4.so tcl-brlapi - 0.5.0-1.fc8.i386 requires libtcl8.4.so tcl-tcldict - 8.5.2-2.fc8.i386 requires tcl(abi) = 0:8.4 tk-tktreectrl - 2.2.3-2.fc8.i386 requires tcl(abi) = 0:8.4 vtk - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtcl8.4.so Broken deps for x86_64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) csound-tk - 5.03.0-13.fc7.x86_64 requires libtk8.4.so()(64bit) csound-tk - 5.03.0-13.fc7.x86_64 requires libtcl8.4.so()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.x86_64 requires libssl.so.6()(64bit) epiphany-extensions - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) expect - 5.43.0-9.fc8.x86_64 requires libtcl8.4.so()(64bit) expect - 5.43.0-9.fc8.i386 requires libtcl8.4.so expectk - 5.43.0-9.fc8.x86_64 requires libtk8.4.so()(64bit) expectk - 5.43.0-9.fc8.x86_64 requires libtcl8.4.so()(64bit) gcl - 2.6.7-15.fc8.x86_64 requires libtcl8.4.so()(64bit) gcl - 2.6.7-15.fc8.x86_64 requires libtk8.4.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) isdn4k-utils-vboxgetty - 3.2-55.fc8.x86_64 requires libtcl8.4.so()(64bit) kazehakase - 0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 libopensync-plugin-sunbird - 0.22-3.fc7.x86_64 requires libssl.so.6()(64bit) libopensync-plugin-sunbird - 0.22-3.fc7.x86_64 requires libneon.so.25()(64bit) libopensync-plugin-sunbird - 0.22-3.fc7.x86_64 requires libcrypto.so.6()(64bit) libopensync-plugin-sunbird - 0.22-3.fc7.x86_64 requires libopensync.so.0()(64bit) libopensync-plugin-synce - 0.22-4.fc8.x86_64 requires libopensync.so.0()(64bit) liferea - 1.4.10-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.x86_64 requires libgtkembedmoz.so()(64bit) magic - 7.4.35-6.fc8.x86_64 requires libtcl8.4.so()(64bit) magic - 7.4.35-6.fc8.x86_64 requires libtk8.4.so()(64bit) multisync - 0.91.0-1.fc7.x86_64 requires libosengine.so.0()(64bit) multisync - 0.91.0-1.fc7.x86_64 requires libopensync.so.0()(64bit) multisync-gui - 0.91.0-1.fc7.x86_64 requires libopensync.so.0()(64bit) multisync-gui - 0.91.0-1.fc7.x86_64 requires libosengine.so.0()(64bit) netgen - 1.3.7-13.fc9.x86_64 requires libtcl8.4.so()(64bit) netgen - 1.3.7-13.fc9.x86_64 requires libtk8.4.so()(64bit) plplot - 5.8.0-5.fc9.x86_64 requires libtk8.4.so()(64bit) plplot - 5.8.0-5.fc9.x86_64 requires libtcl8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.x86_64 requires libtk8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.x86_64 requires libtcl8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.i386 requires libtk8.4.so plplot-tk - 5.8.0-5.fc9.i386 requires libtcl8.4.so postgresql-pltcl - 8.2.5-2.fc9.x86_64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.x86_64 requires libtk8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.x86_64 requires libtcl8.4.so()(64bit) python-gammu - 0.22-3.fc8.x86_64 requires libGammu.so.2()(64bit) qtparted - 0.4.5-15.fc8.x86_64 requires libparted-1.8.so.6()(64bit) skencil - 0.6.17-15.20070606svn.fc8.x86_64 requires libtcl8.4.so()(64bit) skencil - 0.6.17-15.20070606svn.fc8.x86_64 requires libtk8.4.so()(64bit) tcl-brlapi - 0.5.0-1.fc8.x86_64 requires libtcl8.4.so()(64bit) tcl-tcldict - 8.5.2-2.fc8.x86_64 requires tcl(abi) = 0:8.4 tk-tktreectrl - 2.2.3-2.fc8.x86_64 requires tcl(abi) = 0:8.4 vtk - 5.0.3-20.fc8.x86_64 requires libtk8.4.so()(64bit) vtk - 5.0.3-20.fc8.x86_64 requires libtcl8.4.so()(64bit) vtk - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-python - 5.0.3-20.fc8.x86_64 requires libtk8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.x86_64 requires libtcl8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.x86_64 requires libtk8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.x86_64 requires libtcl8.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-client - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libcrypto.so.6 csound-tk - 5.03.0-13.fc7.ppc requires libtk8.4.so csound-tk - 5.03.0-13.fc7.ppc requires libtcl8.4.so d4x - 2.5.7.1-3.fc7.ppc requires libssl.so.6 d4x - 2.5.7.1-3.fc7.ppc requires libcrypto.so.6 epiphany-extensions - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires libgtkembedmoz.so expect - 5.43.0-9.fc8.ppc64 requires libtcl8.4.so()(64bit) expect - 5.43.0-9.fc8.ppc requires libtcl8.4.so expectk - 5.43.0-9.fc8.ppc requires libtk8.4.so expectk - 5.43.0-9.fc8.ppc requires libtcl8.4.so gnome-web-photo - 0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.ppc requires libgtkembedmoz.so irsim - 9.7.50-1.fc8.ppc requires libtcl8.4.so irsim - 9.7.50-1.fc8.ppc requires libtk8.4.so isdn4k-utils-vboxgetty - 3.2-55.fc8.ppc requires libtcl8.4.so kannel - 1.4.1-5.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 libopensync-plugin-sunbird - 0.22-3.fc7.ppc requires libneon.so.25 libopensync-plugin-sunbird - 0.22-3.fc7.ppc requires libopensync.so.0 libopensync-plugin-sunbird - 0.22-3.fc7.ppc requires libssl.so.6 libopensync-plugin-sunbird - 0.22-3.fc7.ppc requires libcrypto.so.6 libopensync-plugin-synce - 0.22-4.fc8.ppc requires libopensync.so.0 liferea - 1.4.10-1.fc9.ppc requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc requires libgtkembedmoz.so magic - 7.4.35-6.fc8.ppc requires libtcl8.4.so magic - 7.4.35-6.fc8.ppc requires libtk8.4.so monodevelop - 0.17-4.fc9.ppc requires boo multisync - 0.91.0-1.fc7.ppc requires libopensync.so.0 multisync - 0.91.0-1.fc7.ppc requires libosengine.so.0 multisync-gui - 0.91.0-1.fc7.ppc requires libopensync.so.0 multisync-gui - 0.91.0-1.fc7.ppc requires libosengine.so.0 netgen - 1.3.7-13.fc9.ppc requires libtcl8.4.so netgen - 1.3.7-13.fc9.ppc requires libtk8.4.so plplot - 5.8.0-5.fc9.ppc requires libtcl8.4.so plplot - 5.8.0-5.fc9.ppc requires libtk8.4.so plplot-tk - 5.8.0-5.fc9.ppc64 requires libtk8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.ppc64 requires libtcl8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.ppc requires libtk8.4.so plplot-tk - 5.8.0-5.fc9.ppc requires libtcl8.4.so postgresql-pltcl - 8.2.5-2.fc9.ppc requires libtcl8.4.so pvm-gui - 3.4.5-7.fc6.1.ppc requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.ppc requires libtcl8.4.so python-gammu - 0.22-3.fc8.ppc requires libGammu.so.2 qtparted - 0.4.5-15.fc8.ppc requires libparted-1.8.so.6 skencil - 0.6.17-15.20070606svn.fc8.ppc requires libtk8.4.so skencil - 0.6.17-15.20070606svn.fc8.ppc requires libtcl8.4.so tcl-brlapi - 0.5.0-1.fc8.ppc requires libtcl8.4.so tcl-tcldict - 8.5.2-2.fc8.ppc requires tcl(abi) = 0:8.4 tk-tktreectrl - 2.2.3-2.fc8.ppc requires tcl(abi) = 0:8.4 vtk - 5.0.3-20.fc8.ppc requires libtcl8.4.so vtk - 5.0.3-20.fc8.ppc requires libtk8.4.so vtk - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc requires libtk8.4.so vtk-python - 5.0.3-20.fc8.ppc requires libtcl8.4.so vtk-python - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc requires libtk8.4.so vtk-tcl - 5.0.3-20.fc8.ppc requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) Broken deps for ppc64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) csound-tk - 5.03.0-13.fc7.ppc64 requires libtk8.4.so()(64bit) csound-tk - 5.03.0-13.fc7.ppc64 requires libtcl8.4.so()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libcrypto.so.6()(64bit) d4x - 2.5.7.1-3.fc7.ppc64 requires libssl.so.6()(64bit) epiphany-extensions - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) expect - 5.43.0-9.fc8.ppc64 requires libtcl8.4.so()(64bit) expectk - 5.43.0-9.fc8.ppc64 requires libtk8.4.so()(64bit) expectk - 5.43.0-9.fc8.ppc64 requires libtcl8.4.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) isdn4k-utils-vboxgetty - 3.2-55.fc8.ppc64 requires libtcl8.4.so()(64bit) kazehakase - 0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 libopensync-plugin-sunbird - 0.22-3.fc7.ppc64 requires libssl.so.6()(64bit) libopensync-plugin-sunbird - 0.22-3.fc7.ppc64 requires libneon.so.25()(64bit) libopensync-plugin-sunbird - 0.22-3.fc7.ppc64 requires libcrypto.so.6()(64bit) libopensync-plugin-sunbird - 0.22-3.fc7.ppc64 requires libopensync.so.0()(64bit) libopensync-plugin-synce - 0.22-4.fc8.ppc64 requires libopensync.so.0()(64bit) liferea - 1.4.10-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc64 requires libgtkembedmoz.so()(64bit) magic - 7.4.35-6.fc8.ppc64 requires libtcl8.4.so()(64bit) magic - 7.4.35-6.fc8.ppc64 requires libtk8.4.so()(64bit) netgen - 1.3.7-13.fc9.ppc64 requires libtcl8.4.so()(64bit) netgen - 1.3.7-13.fc9.ppc64 requires libtk8.4.so()(64bit) perl-Test-AutoBuild-darcs - 1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 plplot - 5.8.0-5.fc9.ppc64 requires libtk8.4.so()(64bit) plplot - 5.8.0-5.fc9.ppc64 requires libtcl8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.ppc64 requires libtk8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.ppc64 requires libtcl8.4.so()(64bit) postgresql-pltcl - 8.2.5-2.fc9.ppc64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ppc64 requires libtk8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ppc64 requires libtcl8.4.so()(64bit) python-gammu - 0.22-3.fc8.ppc64 requires libGammu.so.2()(64bit) qtparted - 0.4.5-15.fc8.ppc64 requires libparted-1.8.so.6()(64bit) skencil - 0.6.17-15.20070606svn.fc8.ppc64 requires libtcl8.4.so()(64bit) skencil - 0.6.17-15.20070606svn.fc8.ppc64 requires libtk8.4.so()(64bit) tcl-brlapi - 0.5.0-1.fc8.ppc64 requires libtcl8.4.so()(64bit) tcl-tcldict - 8.5.2-2.fc8.ppc64 requires tcl(abi) = 0:8.4 tk-tktreectrl - 2.2.3-2.fc8.ppc64 requires tcl(abi) = 0:8.4 vtk - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) From dominik at greysector.net Sun Jan 6 14:06:33 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 6 Jan 2008 15:06:33 +0100 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080103120242.GZ20451@devserv.devel.redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> Message-ID: <20080106140633.GB2984@ryvius.greysector.net> On Thursday, 03 January 2008 at 13:02, Jakub Jelinek wrote: [...] > For testing you can use e.g. koji --scratch builds into dist-f9-gcc43 > target. I hope we can switch to gcc-4.3.0-0.* in dist-f9 soon. What are we supposed to do after getting a failing package to build with gcc-4.3? Just commit the fix to CVS/devel or tag and build the updated package, too? If there's going to be a mass rebuild with gcc-4.3, I don't see any value in building the fixed package until gcc-4.3 hits rawhide, just wasted mirrors' bandwith. Also, I have a package whose sources are over 10MB. Using koji --scratch will take forever to upload it over my slow uplink. Is there some way to do scratch builds out of CVS that does not involve uploading the whole src.rpm? Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From mschwendt.tmp0701.nospam at arcor.de Sun Jan 6 14:11:31 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 6 Jan 2008 15:11:31 +0100 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080106140633.GB2984@ryvius.greysector.net> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <20080106140633.GB2984@ryvius.greysector.net> Message-ID: <20080106151131.3c9b7147.mschwendt.tmp0701.nospam@arcor.de> On Sun, 6 Jan 2008 15:06:33 +0100, Dominik 'Rathann' Mierzejewski wrote: > Also, I have a package whose sources are over 10MB. Using koji --scratch > will take forever to upload it over my slow uplink. Is there some way > to do scratch builds out of CVS that does not involve uploading the whole > src.rpm? give koji the cvs tag instead of the src.rpm From mschwendt.tmp0701.nospam at arcor.de Sun Jan 6 14:21:43 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 6 Jan 2008 15:21:43 +0100 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080106151131.3c9b7147.mschwendt.tmp0701.nospam@arcor.de> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <20080106140633.GB2984@ryvius.greysector.net> <20080106151131.3c9b7147.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20080106152143.40fd0b31.mschwendt.tmp0701.nospam@arcor.de> On Sun, 6 Jan 2008 15:11:31 +0100, Michael Schwendt wrote: > On Sun, 6 Jan 2008 15:06:33 +0100, Dominik 'Rathann' Mierzejewski wrote: > > > Also, I have a package whose sources are over 10MB. Using koji --scratch > > will take forever to upload it over my slow uplink. Is there some way > > to do scratch builds out of CVS that does not involve uploading the whole > > src.rpm? > > give koji the cvs tag instead of the src.rpm Ah, yes, an example: $ koji build --scratch --nowait dist-f9-gcc43 cvs://cvs.fedoraproject.org/cvs/pkgs?rpms/audacity/devel#audacity-1_3_2-18_fc9 From mschwendt.tmp0701.nospam at arcor.de Sun Jan 6 14:26:17 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 6 Jan 2008 15:26:17 +0100 Subject: Pulse Audio problem In-Reply-To: <20080106212821.44ce06ea@cocobear> References: <93d66b780801051706s5c9e41b4mb5ba48accc2e56b6@mail.gmail.com> <1199585527.21972.42.camel@localhost.localdomain> <20080106212821.44ce06ea@cocobear> Message-ID: <20080106152617.01905ffb.mschwendt.tmp0701.nospam@arcor.de> On Sun, 6 Jan 2008 21:28:21 +0800, cocobear wrote: > ? Sun, 06 Jan 2008 03:12:07 +0100 > Lubomir Kundrak ??: > > > > > On Sat, 2008-01-05 at 20:06 -0500, masch wrote: > > > HI! > > > Sometimes when I open the PulseAudio Volume Control said: > > > Connection failed: Connection refused, and the sound in some > > > applications doesn't work. > > > Does anyone know how to fix this? > > > > It seemed that it happens on F8 often. True. Recently on F8 (this is a fresh install from Dec 9th after seeing too many broken things) it fails to start for me during reboot: # grep pulse /var/log/messages Jan 6 07:20:54 faldor pulseaudio[2336]: pid.c: Daemon already running. Jan 6 07:20:54 faldor pulseaudio[2336]: main.c: pa_pid_file_create() failed. # pidof pulseaudio # ll /tmp/pulse-misc/pid -rw------- 1 misc misc 5 2008-01-06 03:18 /tmp/pulse-misc/pid # cat /tmp/pulse-misc/pid 2332 I've had to remove the pid file manually to make it work. > > File a bugzilla ticket. > > > > Your pulseaudio daemon obviously died. Please add output of "grep > > pulseaudio /var/log/messages" to the bugzilla ticket. > > > From jnovy at redhat.com Sun Jan 6 14:30:45 2008 From: jnovy at redhat.com (Jindrich Novy) Date: Sun, 6 Jan 2008 15:30:45 +0100 Subject: mktexlsr/texhash/texconfig-sys rehash, what's the canonical %post/%postun for a TeX thing ? In-Reply-To: <1199622291.11839.81.camel@Jehannum> References: <200801051224.m05COEwl021556@porkchop.devel.redhat.com> <1199562968.11839.34.camel@Jehannum> <1199622291.11839.81.camel@Jehannum> Message-ID: <20080106143045.GA18596@dhcp-lab-186.brq.redhat.com> On Sun, Jan 06, 2008 at 12:24:51PM +0000, Caolan McNamara wrote: > > On Sat, 2008-01-05 at 16:24 -0600, Jason L Tibbitts III wrote: > > >>>>> "CM" == Caolan McNamara writes: > > > > CM> So, what exactly is the current problem with these two ? Is it > > CM> just the mysterious failure of TeX to execute some stuff, i.e. > > > > Yes, I debugged this the other day. The problem for bacula is that > > latex2html somehow does not properly run texhash in %post, so nothing > > can find html.sty. If you force a texhash it works. Changing the > > post scriptlet for latex2html to not use "/usr/bin/env - > > /usr/bin/texhash" but to just call texhash directly works. I don't > > know why. > > I see that another tex package e.g. jadetex has a comment about > "use texconfig-sys rehash instead of texhash", and the change was... > > %post > -/usr/bin/env - PATH=$PATH:%{TeXdir}/bin texhash > /dev/null 2>&1 > +[ -x %{_bindir}/texconfig-sys ] && %{_bindir}/texconfig-sys rehash > 2> /dev/null || : > > +%postun > +[ -x %{_bindir}/texconfig-sys ] && %{_bindir}/texconfig-sys rehash > 2> /dev/null || : > + > > So maybe a determination of the right way to rehash is called for and > consistent usage might clear this up ? > Yes, running rehashing of the kpathsea's ls-R files via texconfig-sys as noted above shouldn't break anything and should correctly call mktexlsr to regenerate ls-Rs. I actually suggested it to Ondrej while fixing the jadetex and iproute build. Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From dwmw2 at infradead.org Sun Jan 6 14:42:59 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 06 Jan 2008 14:42:59 +0000 Subject: Proceedure for package private branches for testing In-Reply-To: <1199621949.6782.7.camel@raven.themaw.net> References: <1199616844.3434.7.camel@raven.themaw.net> <200801061309.43329.opensource@till.name> <1199621949.6782.7.camel@raven.themaw.net> Message-ID: <1199630579.4111.342.camel@shinybook.infradead.org> On Sun, 2008-01-06 at 21:19 +0900, Ian Kent wrote: > Yes, I got this advice on IRC and managed to get a build. You seemed to say something really bizarre on IRC -- that local builds of the kernel rarely worked. Can you elucidate? -- dwmw2 From mike at miketc.com Sun Jan 6 14:49:13 2008 From: mike at miketc.com (Mike Chambers) Date: Sun, 06 Jan 2008 08:49:13 -0600 Subject: X in rawhide during install Message-ID: <1199630953.2155.5.camel@scrappy.miketc.com> Last week, I said the heck with it and did a yum update to rawhide from F8+updates. It performed OK but upon boot, x didn't want to come up, and think the error messages was about version mismatches or something. Well, just now, I was going to do a fresh rawhide install on same machine (wipe out F8 completely), but when it got to starting X to perform the install, it wouldn't run, not even in vesa (from the quick msg I saw come across), so it went into text mode (which I cancelled at that time). Would it had worked if I had went ahead with the text mode install, then tried to get X configured to start post-install? So, is xorg not fully functioning as of yet, with the new compiles that went on recently and I am guessing still happening? This was on a PIV 2.8Ghz w/1G ram, and an X1300 ATI card. -- Mike Chambers Madisonville, KY "The best lil town on Earth!" From dominik at greysector.net Sun Jan 6 14:54:12 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 6 Jan 2008 15:54:12 +0100 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080106151131.3c9b7147.mschwendt.tmp0701.nospam@arcor.de> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <20080106140633.GB2984@ryvius.greysector.net> <20080106151131.3c9b7147.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20080106145412.GC2984@ryvius.greysector.net> On Sunday, 06 January 2008 at 15:11, Michael Schwendt wrote: > On Sun, 6 Jan 2008 15:06:33 +0100, Dominik 'Rathann' Mierzejewski wrote: > > > Also, I have a package whose sources are over 10MB. Using koji --scratch > > will take forever to upload it over my slow uplink. Is there some way > > to do scratch builds out of CVS that does not involve uploading the whole > > src.rpm? > > give koji the cvs tag instead of the src.rpm How? $ koji build --scratch dist-f9-gcc43 obexftp-0_22-0_6_rc9_fc9 Uploading srpm: obexftp-0_22-0_6_rc9_fc9 : [Errno 2] No such file or directory: 'obexftp-0_22-0_6_rc9_fc9' R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From jkeating at redhat.com Sun Jan 6 14:51:41 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 6 Jan 2008 09:51:41 -0500 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080106152143.40fd0b31.mschwendt.tmp0701.nospam@arcor.de> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <20080106140633.GB2984@ryvius.greysector.net> <20080106151131.3c9b7147.mschwendt.tmp0701.nospam@arcor.de> <20080106152143.40fd0b31.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20080106095141.0cf1a669@redhat.com> On Sun, 6 Jan 2008 15:21:43 +0100 Michael Schwendt wrote: > $ koji build --scratch --nowait dist-f9-gcc43 > cvs://cvs.fedoraproject.org/cvs/pkgs?rpms/audacity/devel#audacity-1_3_2-18_fc9 Or even easier: $ koji build --scratch --nowait dist-f9-gcc43 cvs://cvs.fedoraproject.org/cvs/pkgs?rpms/audacity/devel#HEAD -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dominik at greysector.net Sun Jan 6 14:57:23 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 6 Jan 2008 15:57:23 +0100 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080106095141.0cf1a669@redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <20080106140633.GB2984@ryvius.greysector.net> <20080106151131.3c9b7147.mschwendt.tmp0701.nospam@arcor.de> <20080106152143.40fd0b31.mschwendt.tmp0701.nospam@arcor.de> <20080106095141.0cf1a669@redhat.com> Message-ID: <20080106145723.GD2984@ryvius.greysector.net> On Sunday, 06 January 2008 at 15:51, Jesse Keating wrote: > On Sun, 6 Jan 2008 15:21:43 +0100 > Michael Schwendt wrote: > > > $ koji build --scratch --nowait dist-f9-gcc43 > > cvs://cvs.fedoraproject.org/cvs/pkgs?rpms/audacity/devel#audacity-1_3_2-18_fc9 > > Or even easier: > > $ koji build --scratch --nowait dist-f9-gcc43 cvs://cvs.fedoraproject.org/cvs/pkgs?rpms/audacity/devel#HEAD I see. So that's what is meant by URL in koji's help. It's kind of obvious, now that I know it. Thanks, both of you. Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From jkeating at redhat.com Sun Jan 6 14:54:09 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 6 Jan 2008 09:54:09 -0500 Subject: integration of LTSP 5 in fedora In-Reply-To: <539333cb0801052016h1865b9a3o9888a1919d33fd81@mail.gmail.com> References: <539333cb0801040958r5ceb61b3t3d32b413b578d355@mail.gmail.com> <539333cb0801042058j793f301dsfe75747094b0968@mail.gmail.com> <20080105094839.GE2570@free.fr> <477FCC43.1070008@gmail.com> <539333cb0801052016h1865b9a3o9888a1919d33fd81@mail.gmail.com> Message-ID: <20080106095409.2bbc4a72@redhat.com> On Sun, 6 Jan 2008 09:46:52 +0530 "subhodip biswas" wrote: > so anyone thinking on that ...or taking any initiative ??? i think are > quite afew changes in upstream in between LTSP 4 and 5. Warren Togami has been working quite hard on getting Fedora into a shape so that this work could be done. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dominik at greysector.net Sun Jan 6 15:08:59 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 6 Jan 2008 16:08:59 +0100 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080103120242.GZ20451@devserv.devel.redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> Message-ID: <20080106150859.GE2984@ryvius.greysector.net> On Thursday, 03 January 2008 at 13:02, Jakub Jelinek wrote: [...] > fails-even-with-41/obexftp-0.22-0.5.rc7.fc8.log This one seems bogus: ENTER do("bash -l -c 'rpmbuild -bs --target x86_64 --nodeps //builddir/build/SPECS/obexftp.spec'", '/var/lib/mock/rawhide5/root/', 0, True, 0, , 500, 101, 'x86_64', logger=) run cmd timeout(0): bash -l -c 'rpmbuild -bs --target x86_64 --nodeps //builddir/build/SPECS/obexftp.spec' /etc/profile: line 38: /bin/hostname: No such file or directory sh: /usr/bin/python: No such file or directory sh: /usr/bin/python: No such file or directory sh: /usr/bin/python: No such file or directory sh: ruby: command not found Building target platforms: x86_64 Building for target x86_64 Wrote: /builddir/build/SRPMS/obexftp-0.22-0.5.rc7.fc9.src.rpm LEAVE do --> That's the *whole* log. Nothing wrong here AFAICT (python and ruby are used to determin some paths, but it doesn't matter if they fail during rpmbuild -bs), but why it didn't build, I cannot say. It builds fine locally. Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From jonathan.underwood at gmail.com Sun Jan 6 15:09:51 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 6 Jan 2008 15:09:51 +0000 Subject: call for texlive related packages maintainers In-Reply-To: <20080105121634.GA1756@free.fr> References: <20080105121634.GA1756@free.fr> Message-ID: <645d17210801060709t558d4bafm33f82b023623aaef@mail.gmail.com> On 05/01/2008, Patrice Dumas wrote: > Hello, > > There are packages that are shipped part of texlive, though texlive is > not the upstream for those packages. Among those, some are in fedora > texlive, as an exception because they were in tetex previously. > I personally don't want to maintain them since I maintain enough > packages already, but I can review them. > > > In texlive but should be separate: > xdvik (xdvi) > http://sourceforge.net/projects/xdvi > https://bugzilla.redhat.com/show_bug.cgi?id=427667 This package builds on F8, but still needs a fair bit of work, and is not yet review ready. However, I wanted to get it out in the open early to get feedback. Would welcome all and any hep. What I have done: * Sun Jan 6 2008 Jonathan G. Underwood - 22.84.13-1 - Initial package based on the texlive.spec by Jindrich Novy - Updated to latest upstream xdvik and Japanese xdvik - Reviewed all patches relating to xdvi in texlive.spec and cherry picked those that are still needed - Reworked the patch to allow building of xdvik and pxdvik What still needs to be done: Currently this builds against the bundled kpathsea library sources in the tarball. We should be building against the kpathsea(-devel) packages instead. Lots of missing Requires and BuildRequires. Needs building in Mock for devel and rpmlint checking. And testing lots. From caolanm at redhat.com Sun Jan 6 15:17:09 2008 From: caolanm at redhat.com (Caolan McNamara) Date: Sun, 06 Jan 2008 15:17:09 +0000 Subject: mktexlsr/texhash/texconfig-sys rehash, what's the canonical %post/%postun for a TeX thing ? In-Reply-To: <20080106143045.GA18596@dhcp-lab-186.brq.redhat.com> References: <200801051224.m05COEwl021556@porkchop.devel.redhat.com> <1199562968.11839.34.camel@Jehannum> <1199622291.11839.81.camel@Jehannum> <20080106143045.GA18596@dhcp-lab-186.brq.redhat.com> Message-ID: <1199632629.11839.91.camel@Jehannum> On Sun, 2008-01-06 at 15:30 +0100, Jindrich Novy wrote: > Yes, running rehashing of the kpathsea's ls-R files via texconfig-sys > as noted above shouldn't break anything and should correctly call > mktexlsr to regenerate ls-Rs. I actually suggested it to Ondrej while > fixing the jadetex and iproute build. Sounds good, can we give this a whirl then ? Probably has to be you to do it as there's ACLs for latex2html. C. From drago01 at gmail.com Sun Jan 6 15:20:49 2008 From: drago01 at gmail.com (drago01) Date: Sun, 6 Jan 2008 16:20:49 +0100 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080106150859.GE2984@ryvius.greysector.net> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <20080106150859.GE2984@ryvius.greysector.net> Message-ID: On Jan 6, 2008 4:08 PM, Dominik 'Rathann' Mierzejewski wrote: > On Thursday, 03 January 2008 at 13:02, Jakub Jelinek wrote: > [...] > > fails-even-with-41/obexftp-0.22-0.5.rc7.fc8.log > > This one seems bogus: > > ENTER do("bash -l -c 'rpmbuild -bs --target x86_64 --nodeps //builddir/build/SPECS/obexftp.spec'", '/var/lib/mock/rawhide5/root/', 0, True, 0, , 500, 101, 'x86_64', logger=) > run cmd timeout(0): bash -l -c 'rpmbuild -bs --target x86_64 --nodeps //builddir/build/SPECS/obexftp.spec' > /etc/profile: line 38: /bin/hostname: No such file or directory > sh: /usr/bin/python: No such file or directory > sh: /usr/bin/python: No such file or directory > sh: /usr/bin/python: No such file or directory > sh: ruby: command not found > Building target platforms: x86_64 > Building for target x86_64 > Wrote: /builddir/build/SRPMS/obexftp-0.22-0.5.rc7.fc9.src.rpm > LEAVE do --> > > > That's the *whole* log. Nothing wrong here AFAICT (python and ruby are used > to determin some paths, but it doesn't matter if they fail during rpmbuild > -bs), but why it didn't build, I cannot say. It builds fine locally. are they any errors in root.log ? From pertusus at free.fr Sun Jan 6 15:29:48 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 6 Jan 2008 16:29:48 +0100 Subject: mktexlsr/texhash/texconfig-sys rehash, what's the canonical %post/%postun for a TeX thing ? In-Reply-To: <20080106143045.GA18596@dhcp-lab-186.brq.redhat.com> References: <200801051224.m05COEwl021556@porkchop.devel.redhat.com> <1199562968.11839.34.camel@Jehannum> <1199622291.11839.81.camel@Jehannum> <20080106143045.GA18596@dhcp-lab-186.brq.redhat.com> Message-ID: <20080106152948.GB2522@free.fr> On Sun, Jan 06, 2008 at 03:30:45PM +0100, Jindrich Novy wrote: > On Sun, Jan 06, 2008 at 12:24:51PM +0000, Caolan McNamara wrote: > > Yes, running rehashing of the kpathsea's ls-R files via texconfig-sys > as noted above shouldn't break anything and should correctly call > mktexlsr to regenerate ls-Rs. I actually suggested it to Ondrej while > fixing the jadetex and iproute build. Calling /usr/bin/env - /usr/bin/texhash should also do the right thing. Currently there is a bug in texhash when $HOME is empty, introduced in texlive-mktexlsr_fixes.patch. I'll see what I can do. -- Pat From foss.mailinglists at gmail.com Sun Jan 6 15:25:45 2008 From: foss.mailinglists at gmail.com (Sankarshan Mukhopadhyay) Date: Sun, 06 Jan 2008 20:55:45 +0530 Subject: integration of LTSP 5 in fedora In-Reply-To: <20080106095409.2bbc4a72@redhat.com> References: <539333cb0801040958r5ceb61b3t3d32b413b578d355@mail.gmail.com> <539333cb0801042058j793f301dsfe75747094b0968@mail.gmail.com> <20080105094839.GE2570@free.fr> <477FCC43.1070008@gmail.com> <539333cb0801052016h1865b9a3o9888a1919d33fd81@mail.gmail.com> <20080106095409.2bbc4a72@redhat.com> Message-ID: <4780F2F9.7090501@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: | Warren Togami has been working quite hard on getting Fedora into a | shape so that this work could be done. Would either Warren or Eric require someone to test out and in general be of help ? I guess that's what Subhodip is asking. His interest stems from the work being done by his local LUG in providing low cost localized education through an infrastructure of which LTSP is an integral part and they are doing it on Fedora ... ~sankarshan - -- http://www.gutenberg.net - Fine literature digitally re-published http://www.plos.org - Public Library of Science http://www.creativecommons.org - Flexible copyright for creative work -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHgPL4XQZpNTcrCzMRAqOHAKC9mZ9DFlfIVCLQWDQe6g7eZgtvjQCfe7Ft 0A/GXUL2iulwUgozUf8wVuQ= =v+OP -----END PGP SIGNATURE----- From j.w.r.degoede at hhs.nl Sun Jan 6 15:34:29 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 06 Jan 2008 16:34:29 +0100 Subject: New tcl-8.5 and 8Kingdoms In-Reply-To: <47808AE8.7090702@kobold.org> References: <477D5C7F.6050708@hhs.nl> <477D5C87.2010106@kobold.org> <477D5E86.2030004@hhs.nl> <47808AE8.7090702@kobold.org> Message-ID: <4780F505.70702@hhs.nl> Wart wrote: > Hans de Goede wrote: >> Michael Thomas wrote: >>> Did you have to make any changes to 8Kingdoms to get it to build with >>> Tcl 8.5? If so please pass along any patches. I'll try building and >>> running it myself to see if I can track down the problem. >>> >> Nope, >> >> No changes, I also did a diff between the buildlogs, no new compiler >> warnings or anything like that. >> >> I did build it with gcc-4.3, as I was working on it not building with >> gcc-4.3 too. >> >> I've just committed my latest 8Kingdoms work to cvs, so you can get it >> from there, including a patch for the crash you reported (tested using >> tcl 8.4). > > It looks like it's a result of the stack checking code in the Tcl > library itself. Turning off the stack checking code by compiling Tcl > with -DTCL_NO_STACK_CHECK=1 makes the problem in 8Kingdoms go away. > > With the stack checking turned on, the Tcl scripts in 8Kingdoms fail > with the error "out of stack space (infinite loop?)". This error is > generated by the stack checking code in tclBasic.c line 3439. > > I don't understand enough of this stack checking stuff to debug it any > further, unfortunately. > Okay, I've investigated this a bit more and the conclusion is simple, disable the completely broken stack checking please. The stack checking code works by comparing a pointer returned from malloc with that of an address from a variable in the current stack frame, assuming that if if stackaddress < heapaddress (on architectures where the stack grows down) that the stack has grown into the heap. I don't know what dinosaur wrote that code, but with things like address randomization, threads (and thus multiple stacks in one address space) etc, the assumptions of the stack checking don't hold foot. Also an any protected mode os, the os should disallow the stack to grow into already allocated memory and the check thus is useless. This will only work in things like dos / embedded systems without much of an OS. Also someone please educate upstream about the dumbness of this code. Problem solved, just disable the check, _really_ Regards, Hans From pertusus at free.fr Sun Jan 6 15:43:33 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 6 Jan 2008 16:43:33 +0100 Subject: mktexlsr/texhash/texconfig-sys rehash, what's the canonical %post/%postun for a TeX thing ? In-Reply-To: <1199622291.11839.81.camel@Jehannum> References: <200801051224.m05COEwl021556@porkchop.devel.redhat.com> <1199562968.11839.34.camel@Jehannum> <1199622291.11839.81.camel@Jehannum> Message-ID: <20080106154332.GC2522@free.fr> On Sun, Jan 06, 2008 at 12:24:51PM +0000, Caolan McNamara wrote: > > On Sat, 2008-01-05 at 16:24 -0600, Jason L Tibbitts III wrote: > > >>>>> "CM" == Caolan McNamara writes: > > > > CM> So, what exactly is the current problem with these two ? Is it > > CM> just the mysterious failure of TeX to execute some stuff, i.e. > > > > Yes, I debugged this the other day. The problem for bacula is that > > latex2html somehow does not properly run texhash in %post, so nothing > > can find html.sty. If you force a texhash it works. Changing the > > post scriptlet for latex2html to not use "/usr/bin/env - > > /usr/bin/texhash" but to just call texhash directly works. I don't > > know why. I think that the atached patch should fix that issue. -- Pat -------------- next part -------------- ? .build-2007-6.fc9.log ? .texlive.spec.swp ? fmtutil-ptex.cnf ? mendexk2.6e ? ptex-src-3.1.10 ? texlive-2007 ? texlive-mktexlsr_fixes.patch-save ? texlive.spec-font_dep ? texlive.spec-obsfonts Index: texlive-mktexlsr_fixes.patch =================================================================== RCS file: /cvs/pkgs/rpms/texlive/devel/texlive-mktexlsr_fixes.patch,v retrieving revision 1.1 diff -u -3 -p -r1.1 texlive-mktexlsr_fixes.patch --- texlive-mktexlsr_fixes.patch 2 Dec 2007 08:03:19 -0000 1.1 +++ texlive-mktexlsr_fixes.patch 6 Jan 2008 15:43:18 -0000 @@ -1,18 +1,23 @@ -## 10_mktexlsr_fixes by etc etc -## -## DP: Fixes wrong paths in various scripts to make lintian shut up. -## DP: Fix creation of ls-R in root's homedir -## DP: Also add a note to the man page of mktexlsr about the above fix - - build/source/texk/kpathsea/mktexlsr | 24 ++++++++++++------------ - texmf/doc/man/man1/mktexlsr.1 | 9 +++++++++ - 2 files changed, 21 insertions(+), 12 deletions(-) - -Index: texlive-bin-2006.svn3816/build/source/texk/kpathsea/mktexlsr -=================================================================== ---- texlive-bin-2006.svn3816.orig/build/source/texk/kpathsea/mktexlsr 2006-12-25 19:44:43.000000000 +0100 -+++ texlive-bin-2006.svn3816/build/source/texk/kpathsea/mktexlsr 2007-01-26 03:55:05.000000000 +0100 -@@ -82,6 +82,9 @@ +diff -up texlive-2007/texk/kpathsea/mktexlsr.man.mktexlsr_fixes texlive-2007/texk/kpathsea/mktexlsr.man +--- texlive-2007/texk/kpathsea/mktexlsr.man.mktexlsr_fixes 2006-01-17 22:41:51.000000000 +0100 ++++ texlive-2007/texk/kpathsea/mktexlsr.man 2008-01-06 16:13:33.000000000 +0100 +@@ -44,3 +44,12 @@ Print help message and exit. + .B --version + .rb + Print version information and exit. ++.\"===================================================================== ++.SH NOTES ++When called by root with no arguments, \fBmktexlsr\fP in Debian ignores ++TEXMF trees under \fI$HOME\fP. This is to avoid creating undesirable files ++such as \fI/root/texmf/ls-R\fP when doing usual maintainance (it is generally ++a bad idea to work with TeX as root, therefore having a file such as ++\fI/root/texmf/ls-R\fP in the first place is rather pointless). If you really ++want to update the ls-R databases for such TEXMF trees, simply list them ++explicitely on the command-line. +diff -up texlive-2007/texk/kpathsea/mktexlsr.mktexlsr_fixes texlive-2007/texk/kpathsea/mktexlsr +--- texlive-2007/texk/kpathsea/mktexlsr.mktexlsr_fixes 2006-12-25 19:44:43.000000000 +0100 ++++ texlive-2007/texk/kpathsea/mktexlsr 2008-01-06 16:37:22.000000000 +0100 +@@ -82,10 +82,21 @@ test $# = 0 && { ' set x `kpsewhich --show-path=ls-R | tr : ' ' | sort | uniq`; shift @@ -22,18 +27,19 @@ Index: texlive-bin-2006.svn3816/build/so IFS=$OIFS } -@@ -89,6 +92,10 @@ - # Prepend cwd if the directory was relative. - case "$TEXMFLS_R" in - "") continue ;; # Strictly speaking, it is an error if this case is taken. -+ $HOME/*) if test -n "$NOROOTHOME"; then + for TEXMFLS_R in "$@"; do ++ if [ "z$HOME" != 'z' ]; then ++ case "$TEXMFLS_R" in ++ $HOME/*) if test -n "$NOROOTHOME"; then + tty -s && echo "$progname: Skipping $TEXMFLS_R" >&2 + continue + fi ;; - /* | [A-z]:/*) ;; - *) TEXMFLS_R="`pwd`/$TEXMFLS_R" - esac -@@ -112,9 +119,9 @@ ++ esac ++ fi + # Prepend cwd if the directory was relative. + case "$TEXMFLS_R" in + "") continue ;; # Strictly speaking, it is an error if this case is taken. +@@ -112,9 +123,9 @@ for TEXMFLS_R in "$@"; do db_dir=`echo "$db_file" | sed 's%/[^/][^/]*$%%'` # can't rely on dirname test -d "$db_dir" || continue @@ -44,7 +50,7 @@ Index: texlive-bin-2006.svn3816/build/so cp /dev/null "$db_file" # Use same permissions as parent directory, minus x,s, or t bits. chmod `kpsestat -xst "$db_dir"` "$db_file" -@@ -128,11 +135,8 @@ +@@ -128,11 +139,8 @@ for TEXMFLS_R in "$@"; do # Skip if we cannot write the file: kpseaccess -w "$db_file" || { echo "$progname: $db_file: no write permission. Skipping..." >&2; continue; } @@ -58,7 +64,7 @@ Index: texlive-bin-2006.svn3816/build/so $verbose && echo "$progname: Updating $db_file... " >&2 echo "$ls_R_magic" >"$db_file_tmp" -@@ -152,12 +156,8 @@ +@@ -152,12 +160,8 @@ for TEXMFLS_R in "$@"; do | sed -e '/\.svn.*:$/,/^$/d' \ >>"$db_file_tmp" @@ -73,21 +79,3 @@ Index: texlive-bin-2006.svn3816/build/so done $verbose && echo "$progname: Done." >&2 exit 0 -Index: texlive-bin-2006.svn3816/texmf/doc/man/man1/mktexlsr.1 -=================================================================== ---- texlive-bin-2006.svn3816.orig/build/source/texk/kpathsea/mktexlsr.man 2007-01-14 19:01:06.000000000 +0100 -+++ texlive-bin-2006.svn3816/build/source/texk/kpathsea/mktexlsr.man 2007-01-26 03:55:05.000000000 +0100 -@@ -44,3 +44,12 @@ - .B --version - .rb - Print version information and exit. -+.\"===================================================================== -+.SH NOTES -+When called by root with no arguments, \fBmktexlsr\fP in Debian ignores -+TEXMF trees under \fI$HOME\fP. This is to avoid creating undesirable files -+such as \fI/root/texmf/ls-R\fP when doing usual maintainance (it is generally -+a bad idea to work with TeX as root, therefore having a file such as -+\fI/root/texmf/ls-R\fP in the first place is rather pointless). If you really -+want to update the ls-R databases for such TEXMF trees, simply list them -+explicitely on the command-line. - Index: texlive.spec =================================================================== RCS file: /cvs/pkgs/rpms/texlive/devel/texlive.spec,v retrieving revision 1.12 diff -u -3 -p -r1.12 texlive.spec --- texlive.spec 4 Jan 2008 13:24:51 -0000 1.12 +++ texlive.spec 6 Jan 2008 15:43:18 -0000 @@ -432,7 +432,7 @@ chmod -x texk/dvipdfm/encodings.c %patch43 -p1 -b .perl %patch100 -p3 -%patch101 -p3 +%patch101 -p1 -b .mktexlsr_fixes %patch102 -p3 %patch104 -p3 %patch105 -p3 From raven at themaw.net Sun Jan 6 15:43:59 2008 From: raven at themaw.net (Ian Kent) Date: Mon, 07 Jan 2008 00:43:59 +0900 Subject: Proceedure for package private branches for testing In-Reply-To: <1199630579.4111.342.camel@shinybook.infradead.org> References: <1199616844.3434.7.camel@raven.themaw.net> <200801061309.43329.opensource@till.name> <1199621949.6782.7.camel@raven.themaw.net> <1199630579.4111.342.camel@shinybook.infradead.org> Message-ID: <1199634239.3526.7.camel@raven.themaw.net> On Sun, 2008-01-06 at 14:42 +0000, David Woodhouse wrote: > On Sun, 2008-01-06 at 21:19 +0900, Ian Kent wrote: > > Yes, I got this advice on IRC and managed to get a build. > > You seemed to say something really bizarre on IRC -- that local builds > of the kernel rarely worked. Can you elucidate? I find that for some reason or another source rpm kernel builds fail for me a lot on my local machine. The last couple of times I've tried I've been getting an error about debugedit -b option and incorrect argument lengths. I tried to work out what the problem was last time I got it without success. Anyway, over the years, I've ended up with the feeling that kernel builds from standard Fedora source packages often don't work for me. But that may be a little hash as I always seem to have a problem when I can least afford it. Ian From loupgaroublond at gmail.com Sun Jan 6 15:44:58 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Sun, 6 Jan 2008 10:44:58 -0500 Subject: Init : someone could comment this ? In-Reply-To: <877iin6y24.fsf@kosh.bigo.ensc.de> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> Message-ID: <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> On Jan 6, 2008 5:36 AM, Enrico Scholz wrote: > An initsystem which requires depbloat like python or perl is completely > unacceptably. Bash is not depbloat, but bash + awk + grep + any other userspace tools shows alot of dep bloat. Since python is installed on most machines, and almost always putting at least some code in shared memory space, asking for Python in particular is not unreasonable. If Casey had mentioned Common Lisp, I would argue the same thing. Since depbloat should be a non-issue in this case, I think we really need to measure how many kbytes are read on startup, and how long it takes vs how long running python would take and how many kbytes that brings in. Of course a hybrid system would take twice as long, so it's a rather time consuming experiment just to shave a few seconds. -Yaakov From dominik at greysector.net Sun Jan 6 15:48:05 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 6 Jan 2008 16:48:05 +0100 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080103120242.GZ20451@devserv.devel.redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> Message-ID: <20080106154805.GF2984@ryvius.greysector.net> On Thursday, 03 January 2008 at 13:02, Jakub Jelinek wrote: [...] > header-dep/libebml-0.7.7-3.fc8.log [...] > unsorted/mkvtoolnix-2.1.0-1.fc8.log These two are probably related. mkvtoolnix has libebml-devel >= 0.7.7 in BuildRequires but the log shows: checking for libEBML headers version >= 0.7.7... no *** Your libEBML version is too old. Upgrade to at least version *** 0.7.7 and re-run configure. I can't fix it unless I see config.log. Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From pertusus at free.fr Sun Jan 6 15:49:35 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 6 Jan 2008 16:49:35 +0100 Subject: Init : someone could comment this ? In-Reply-To: <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> Message-ID: <20080106154935.GD2522@free.fr> On Sun, Jan 06, 2008 at 10:44:58AM -0500, Yaakov Nemoy wrote: > On Jan 6, 2008 5:36 AM, Enrico Scholz > wrote: > > An initsystem which requires depbloat like python or perl is completely > > unacceptably. > > Bash is not depbloat, but bash + awk + grep + any other userspace > tools shows alot of dep bloat. bash + awk + grep is very small, not to mention that it is needed by a lot of other softwares. > Since python is installed on most > machines, and almost always putting at least some code in shared > memory space, asking for Python in particular is not unreasonable. If python is not installed in chroot rpm installs (in general) and also may not be installed on servers. > Since depbloat should be a non-issue in this case, I think we really In my opinion it is an issue in some use cases, but should not prevent from using an init system written in python. In fact I think that the programming language of an init system is not an issue at all. -- Pat From dominik at greysector.net Sun Jan 6 15:50:40 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 6 Jan 2008 16:50:40 +0100 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: References: <20080103120242.GZ20451@devserv.devel.redhat.com> <20080106150859.GE2984@ryvius.greysector.net> Message-ID: <20080106155040.GG2984@ryvius.greysector.net> On Sunday, 06 January 2008 at 16:20, drago01 wrote: > On Jan 6, 2008 4:08 PM, Dominik 'Rathann' Mierzejewski > wrote: > > On Thursday, 03 January 2008 at 13:02, Jakub Jelinek wrote: > > [...] > > > fails-even-with-41/obexftp-0.22-0.5.rc7.fc8.log > > > > This one seems bogus: > > > > ENTER do("bash -l -c 'rpmbuild -bs --target x86_64 --nodeps //builddir/build/SPECS/obexftp.spec'", '/var/lib/mock/rawhide5/root/', 0, True, 0, , 500, 101, 'x86_64', logger=) > > run cmd timeout(0): bash -l -c 'rpmbuild -bs --target x86_64 --nodeps //builddir/build/SPECS/obexftp.spec' > > /etc/profile: line 38: /bin/hostname: No such file or directory > > sh: /usr/bin/python: No such file or directory > > sh: /usr/bin/python: No such file or directory > > sh: /usr/bin/python: No such file or directory > > sh: ruby: command not found > > Building target platforms: x86_64 > > Building for target x86_64 > > Wrote: /builddir/build/SRPMS/obexftp-0.22-0.5.rc7.fc9.src.rpm > > LEAVE do --> > > > > > > That's the *whole* log. Nothing wrong here AFAICT (python and ruby are used > > to determin some paths, but it doesn't matter if they fail during rpmbuild > > -bs), but why it didn't build, I cannot say. It builds fine locally. > > are they any errors in root.log ? Good call. Looks like a gettext-devel problem: DEBUG util.py:261: Error: Missing Dependency: libgcj.so.8rh is needed by package gettext-devel http://koji.fedoraproject.org/koji/getfile?taskID=328341&name=root.log Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From loupgaroublond at gmail.com Sun Jan 6 15:52:57 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Sun, 6 Jan 2008 10:52:57 -0500 Subject: Init : someone could comment this ? In-Reply-To: <1199600447.4670.167.camel@dimi.lattica.com> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <1199600447.4670.167.camel@dimi.lattica.com> Message-ID: <7f692fec0801060752g4891432dsb700a81e3b6b2d72@mail.gmail.com> On Jan 6, 2008 1:20 AM, Dimi Paun wrote: > Oh please, I hope you're not being serious! I mean Haskell is cool > and all, but it is rather obscure for the vast majority of people, > and the last thing we need is yet another strange language mixed in > such a critical part of the system. > > The entire point of having a scripting language in the init scripts > is for the admins to have a chance of making small adjustments easily. > If we use Haskell, we lose 99.99% of the population right there. > We might as well just code them in C: that would provide for faster > start-up AND it will be accessible to most people. It is obscure, and I agree it's very hard to justify putting more languages in the mix. Haskell has a few advantages over C. It's very easy to write a wrapper in Haskell that checks if file 'foo' is newer than the binary that it's trying to execute, and if so, to compile the new file, load up the new binary and keep running. You can also have it redirect any error output anywhere you like. The difference between Haskell and Python is that instead of calling an interpreter that byte-compiles a script and runs the byte-compiled code in a VM, it calls a compiler to convert the Haskell into C-- code, and then calls gcc to compile that into native code. (At least that's what GHC does.) This 'just in time' compiling is slow the first time, but cached conveniently by the file system for each subsequent run. XMonad takes full advantage of this architecture so that you can literally edit your configuration, press a key command and see your new config loaded in real time. There are other aspects to the VM vs native machine code arguement that are still important. For example, getting to a 'prompt' in the vm on top of a running process is much harder and requires more boiler plate in Haskell, whereas Python has it embedded in its standard libs. -Yaakov From mschwendt.tmp0701.nospam at arcor.de Sun Jan 6 16:07:38 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 6 Jan 2008 17:07:38 +0100 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080106154805.GF2984@ryvius.greysector.net> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <20080106154805.GF2984@ryvius.greysector.net> Message-ID: <20080106170738.5c34905f.mschwendt.tmp0701.nospam@arcor.de> On Sun, 6 Jan 2008 16:48:05 +0100, Dominik 'Rathann' Mierzejewski wrote: > On Thursday, 03 January 2008 at 13:02, Jakub Jelinek wrote: > [...] > > header-dep/libebml-0.7.7-3.fc8.log > [...] > > unsorted/mkvtoolnix-2.1.0-1.fc8.log > > These two are probably related. mkvtoolnix has libebml-devel >= 0.7.7 > in BuildRequires but the log shows: > checking for libEBML headers version >= 0.7.7... no > *** Your libEBML version is too old. Upgrade to at least version > *** 0.7.7 and re-run configure. > I can't fix it unless I see config.log. Until the buildsys does that for you, you can modify your spec and "cat config.log" when configure exits with an error. From dominik at greysector.net Sun Jan 6 16:08:49 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 6 Jan 2008 17:08:49 +0100 Subject: gxine (Re: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220) In-Reply-To: <20080103192157.GI20451@devserv.devel.redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <1199386420.6116.8.camel@pc-notebook> <20080103192157.GI20451@devserv.devel.redhat.com> Message-ID: <20080106160849.GH2984@ryvius.greysector.net> On Thursday, 03 January 2008 at 20:21, Jakub Jelinek wrote: > On Thu, Jan 03, 2008 at 07:53:40PM +0100, Martin Sourada wrote: > > my package is listed there and look into sources showed only 'static > > inline' functions but none of these seems to be listed in the build log. > > Instead lots of (to me) confusing messages about multiple defs in glib > > header files like this (end of the really long list): > > > > wizards.o: In function `g_bit_storage': > > /usr/include/glib-2.0/glib/gutils.h:345: multiple definition of > > `g_bit_storage' > > console_output.o:/usr/include/glib-2.0/glib/gutils.h:345: first defined > > here > > The problem is on the glib2 side. [...] I seem to have hit the same bug rebuilding ekg2. Martin, have you filed a bug against glib2? Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From jfontain at free.fr Sun Jan 6 16:17:16 2008 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Sun, 06 Jan 2008 17:17:16 +0100 Subject: taking over blt and tktable Message-ID: <4780FF0C.4040500@free.fr> I am very sorry but I no longer have time and resources to care for the blt and tktable (tcl libraries) packages: would anybody be interested in taking over? -- Jean-Luc Fontaine From martin.sourada at seznam.cz Sun Jan 6 16:23:19 2008 From: martin.sourada at seznam.cz (Martin Sourada) Date: Sun, 06 Jan 2008 17:23:19 +0100 Subject: gxine (Re: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220) In-Reply-To: <20080106160849.GH2984@ryvius.greysector.net> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <1199386420.6116.8.camel@pc-notebook> <20080103192157.GI20451@devserv.devel.redhat.com> <20080106160849.GH2984@ryvius.greysector.net> Message-ID: <1199636599.5090.2.camel@pc-notebook> On Sun, 2008-01-06 at 17:08 +0100, Dominik 'Rathann' Mierzejewski wrote: > On Thursday, 03 January 2008 at 20:21, Jakub Jelinek wrote: > > On Thu, Jan 03, 2008 at 07:53:40PM +0100, Martin Sourada wrote: > > > my package is listed there and look into sources showed only 'static > > > inline' functions but none of these seems to be listed in the build log. > > > Instead lots of (to me) confusing messages about multiple defs in glib > > > header files like this (end of the really long list): > > > > > > wizards.o: In function `g_bit_storage': > > > /usr/include/glib-2.0/glib/gutils.h:345: multiple definition of > > > `g_bit_storage' > > > console_output.o:/usr/include/glib-2.0/glib/gutils.h:345: first defined > > > here > > > > The problem is on the glib2 side. > [...] > > I seem to have hit the same bug rebuilding ekg2. > Martin, have you filed a bug against glib2? > Not yet, didn't have time yet... (working on nodoka gtk engine, currently in the progress of switching to different e-mail address, examination term on the university is very close...). I'd be grateful if some with this same issue reported it... > Regards, > R. > Thanks, Martin > -- > Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski > Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu > "Faith manages." > -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From selinux at gmail.com Sun Jan 6 16:47:41 2008 From: selinux at gmail.com (Tom London) Date: Sun, 6 Jan 2008 08:47:41 -0800 Subject: Pulse Audio problem In-Reply-To: <20080106152617.01905ffb.mschwendt.tmp0701.nospam@arcor.de> References: <93d66b780801051706s5c9e41b4mb5ba48accc2e56b6@mail.gmail.com> <1199585527.21972.42.camel@localhost.localdomain> <20080106212821.44ce06ea@cocobear> <20080106152617.01905ffb.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <4c4ba1530801060847n51cc009fjc90b81b0b1836387@mail.gmail.com> On Jan 6, 2008 6:26 AM, Michael Schwendt wrote: > On Sun, 6 Jan 2008 21:28:21 +0800, cocobear wrote: > > > ? Sun, 06 Jan 2008 03:12:07 +0100 > > Lubomir Kundrak ??: > > > > > > > > On Sat, 2008-01-05 at 20:06 -0500, masch wrote: > > > > HI! > > > > Sometimes when I open the PulseAudio Volume Control said: > > > > Connection failed: Connection refused, and the sound in some > > > > applications doesn't work. > > > > Does anyone know how to fix this? > > > > > > > It seemed that it happens on F8 often. > > True. Recently on F8 (this is a fresh install from Dec 9th after seeing > too many broken things) it fails to start for me during reboot: > > # grep pulse /var/log/messages > Jan 6 07:20:54 faldor pulseaudio[2336]: pid.c: Daemon already running. > Jan 6 07:20:54 faldor pulseaudio[2336]: main.c: pa_pid_file_create() failed. > # pidof pulseaudio > > # ll /tmp/pulse-misc/pid > -rw------- 1 misc misc 5 2008-01-06 03:18 /tmp/pulse-misc/pid > # cat /tmp/pulse-misc/pid > 2332 > > I've had to remove the pid file manually to make it work. > > I've seen the same, about 1 in 5 boots; same messages in /var/log/messages. Get the following in ~/.xsession-errors: process 2901: dbus_shutdown() called but connections were still live. This probably means the application did not drop all its references to bus connections. D-Bus not built with -rdynamic so unable to print a backtrace Trying to start pulseaudio manually says: [tbl at localhost ~]$ pulseaudio E: pid.c: Daemon already running. E: main.c: pa_pid_file_create() failed. process 3489: dbus_shutdown() called but connections were still live. This probably means the application did not drop all its references to bus connections. D-Bus not built with -rdynamic so unable to print a backtrace Aborted [tbl at localhost ~]$ After figuring out to run with '-v' I get this working startup (obviously, lock/pid file timed out): [tbl at localhost ~]$ pulseaudio -v I: main.c: PolicyKit grants us acquire-high-priority privilige. I: main.c: We're in the group 'pulse-rt', allowing real-time and high-priority scheduling. I: core-util.c: Successfully gained nice level -11. W: pid.c: Stale PID file, overwriting. W: main.c: setrlimit(RLIMIT_NICE, (31, 31)) failed: Operation not permitted I: main.c: Page size is 4096 bytes Something BZ'ed here: https://bugzilla.redhat.com/show_bug.cgi?id=426965 Not sure if this is the same. tom -- Tom London From enrico.scholz at informatik.tu-chemnitz.de Sun Jan 6 16:47:57 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sun, 06 Jan 2008 17:47:57 +0100 Subject: Init : someone could comment this ? In-Reply-To: <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> (Yaakov Nemoy's message of "Sun, 6 Jan 2008 10:44:58 -0500") References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> Message-ID: <873ata7veq.fsf@kosh.bigo.ensc.de> "Yaakov Nemoy" writes: >> An initsystem which requires depbloat like python or perl is completely >> unacceptably. > > Bash is not depbloat, Not so much as python, but the current bash initscript *are* bloaty (not regarding dependencies but for performance and source size[1]). > but bash + awk + grep + any other userspace tools shows alot of dep > bloat. For what do you need this combination of tools? Ideally, an initsystem does not need external tools and/or shells (and such systems exist). > Since python is installed on most machines We must have different definitions of "most". My one is ">50%" and your assumption does not hold for my machines: # LANG=C vrpm --all -- -q python 2>&1 | grep python python-2.5.1-15.fc8 <<< really needed for 'rdiff-backup' package python is not installed package python is not installed package python is not installed package python is not installed python-2.5.1-15.fc8 <<< it's an end-user system package python is not installed package python is not installed python-2.4.4-1.fc6 <<< only due to cracklib dep; fixed in F8 package python is not installed package python is not installed python-2.4.4-1.fc6 <<< only due to cracklib dep; fixed in F8 package python is not installed package python is not installed package python is not installed package python is not installed python-2.5.1-15.fc8 <<< due to broken 'policycoreutils' packaging package python is not installed package python is not installed package python is not installed package python is not installed package python is not installed package python is not installed > and almost always putting at least some code in shared memory space, > asking for Python in particular is not unreasonable. If Casey had > mentioned Common Lisp, I would argue the same thing. there is really no need to put in additional languages as 'init' dependencies. Plain C completely suffices for this task. Enrico Footnotes: [1] needing around 100 lines of code for simple tasks like starting and stopping daemons is far too much -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From rc040203 at freenet.de Sun Jan 6 16:48:26 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 06 Jan 2008 17:48:26 +0100 Subject: Init : someone could comment this ? In-Reply-To: <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> Message-ID: <1199638106.6022.88.camel@beck.corsepiu.local> On Sun, 2008-01-06 at 10:44 -0500, Yaakov Nemoy wrote: > On Jan 6, 2008 5:36 AM, Enrico Scholz > wrote: > > An initsystem which requires depbloat like python or perl is completely > > unacceptably. > > Bash is not depbloat, but bash + awk + grep + any other userspace > tools shows alot of dep bloat. You will want to make yourself familiar with POSIX. > Since python is installed on most > machines, Only because RH/Fedora's infrastructure forces users to install it. > and almost always putting at least some code in shared > memory space, asking for Python in particular is not unreasonable. I could not disagree more - To me any init-script system requiring anything outside of what POSIX requires is a mis-conception and flawed design. Ralf From lkundrak at redhat.com Sun Jan 6 17:06:41 2008 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Sun, 06 Jan 2008 18:06:41 +0100 Subject: Pulse Audio problem In-Reply-To: <20080106212821.44ce06ea@cocobear> References: <93d66b780801051706s5c9e41b4mb5ba48accc2e56b6@mail.gmail.com> <1199585527.21972.42.camel@localhost.localdomain> <20080106212821.44ce06ea@cocobear> Message-ID: <1199639201.21972.47.camel@localhost.localdomain> On Sun, 2008-01-06 at 21:28 +0800, cocobear wrote: > ? Sun, 06 Jan 2008 03:12:07 +0100 > Lubomir Kundrak ??: > > > > > On Sat, 2008-01-05 at 20:06 -0500, masch wrote: > > > HI! > > > Sometimes when I open the PulseAudio Volume Control said: > > > Connection failed: Connection refused, and the sound in some > > > applications doesn't work. > > > Does anyone know how to fix this? > > > > It seemed that it happens on F8 often. This is really not very valuable information. Would you mind helping to fix the situation? Did you report it to bugzilla? Do you care to respond with the information asked for below? > > > > File a bugzilla ticket. > > > > Your pulseaudio daemon obviously died. Please add output of "grep > > pulseaudio /var/log/messages" to the bugzilla ticket. > > -- Lubomir Kundrak (Red Hat Security Response Team) From mr.ecik at gmail.com Sun Jan 6 17:13:50 2008 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Sun, 6 Jan 2008 18:13:50 +0100 Subject: Request for remove a package from rawhide Message-ID: <668bb39a0801060913g7da50934qdac27c9e95485dee@mail.gmail.com> Hi! Some time ago I built new openarena package. Unfortunately, after some testing it turned out that package is broken and prevent players from playing multiplayer. It seems to me that package is built but it's not been pushed to repo yet. That's why I ask to remove it from rawhide. I know I could reverse all changes and bump release once again, but it will cause completely unnecessary update for some users. So since it's not in repo yet, I make a request to any admin to just preclude a package from being pushed to repo. I hope nothing stands in the way to do so. -- Micha? Bentkowski mr.ecik at gmail.com From mjs at CLEMSON.EDU Sat Jan 5 22:16:47 2008 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Sat, 05 Jan 2008 17:16:47 -0500 Subject: Policy proposal for compatibility packages In-Reply-To: <1199557944.4805.1.camel@localhost.localdomain> References: <1199290909.11035.20.camel@kennedy> <20080102105614.73d4db84@vader.jdub.homelinux.org> <1199301348.3483.2.camel@rousalka.dyndns.org> <477BE5EA.9020909@redhat.com> <20080102215010.GD2661@free.fr> <477C0FE7.60105@redhat.com> <1199557944.4805.1.camel@localhost.localdomain> Message-ID: <1199571407.14747.15.camel@vincent52.localdomain> On Sat, 2008-01-05 at 19:32 +0100, David Nielsen wrote: > Em Qua, 2008-01-02 ?s 17:27 -0500, Tom "spot" Callaway escreveu: > > Patrice Dumas wrote: > > > On Wed, Jan 02, 2008 at 02:28:42PM -0500, Tom spot Callaway wrote: > > >> - Third party applications which still depend on the old interface (that > > >> the maintainer is aware of specifically, not "something might use it > > >> someday") > > > > > > That seems to me to be a perfect reason. Please don't try to force > > > packagers to do something without reason. If a packager wants to invest > > > time to maintain a compat package, let him do. > > > > Well, one of the reasons we're making hoops for people to jump through > > is that we don't want to clutter the distribution with compat packages. > > This encourages upstream (and package maintainers) to just continue > > using the compat packages, rather than porting to the new, improved ones. > > > > This is why I think that this is a valid reason: > > > > * Adobe ProprietaryDocumentFormat Reader needs this library to run. > > Why would that be valid.. if all that requires this there is absolutely > no reason to have a -compat package. It's Adobe' problem to fix it. They > don't play by the rules so no cookies for them. What about cookies for users who need the Adobe (or whatever) package because there is no fully functional FOSS alternative? Sure, we can (and do, as much as we are able) pressure upstream to get their act together, but meanwhile--particularly if upstream is unresponsive--we still need to get our work done. I'm sure you know it's common for commercial developers to fix on a particular stable, long-lived, well-supported distribution (RHEL4, say) and support their packages only for that release of that distro for some extended period of time. Meanwhile, fast-moving distros like Fedora may advance through several incompatible library or language versions. It's generally not practical to expect Adobe (or whomever) to reply to complaints about Fedora compatibility with anything other than "use a supported distro". And please don't consign us to those supported platforms or distros. We are part of the Fedora community because we support Fedora's goals and we want to keep close to the bleeding edge. But we do still have work to do. > > - David -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From pertusus at free.fr Sun Jan 6 17:17:31 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 6 Jan 2008 18:17:31 +0100 Subject: list of failed packages with owners (was: Re: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220) In-Reply-To: <477CE62D.7020208@leemhuis.info> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <477CE62D.7020208@leemhuis.info> Message-ID: <20080106171731.GH2522@free.fr> On Thu, Jan 03, 2008 at 02:42:05PM +0100, Thorsten Leemhuis wrote: > FYI, below the list with owner information in front of it and sorted by > owners: > > pertusus fails-even-with-41/archmage-0.1.9-1.fc8.log > pertusus fails-even-with-41/dap-hdf4_handler-3.7.5-3.fc8.log > pertusus fails-even-with-41/python-chm-0.8.4-1.fc7.log > pertusus > fails-even-with-41/tetex-tex4ht-1.0.2007_11_19_2329-1.fc9.log > pertusus fails-even-with-41/wdm-1.28-8.fc8.log > pertusus header-dep/acpitool-0.4.7-2.fc9.log > pertusus header-dep/boolstuff-0.1.11-3.fc9.log > pertusus header-dep/libchmxx-0.1-5.fc6.log > pertusus multipleparm/xchm-1.13-1.fc8.log Should be fixed in rawhide. > pertusus fails-even-with-41/gnash-0.8.1-6.fc9.log > pertusus fails-even-with-41/kchmviewer-3.0-2.fc7.log Waiting a bit for kde4 support from upstream, but should certainly be easily fixed by using kde5libs-devel instead of kdelibs-devel. > pertusus header-dep/bes-3.5.1-4.fc9.log > pertusus header-dep/dap-freeform_handler-3.7.5-2.fc8.log > pertusus header-dep/libdap-3.7.8-3.fc9.log > pertusus header-dep/libnc-dap-3.7.0-8.fc9.log Reported upstream. > pertusus unsorted/perl-Cache-2.04-2.fc8.2.log test failure not reproducible > pertusus unsorted/cernlib-2006-20.fc9.log This looks like a gfortran bug. Error messages: DR=DLGAMA(Z0) 1 Error: Result of LGAMMA overflows its kind at (1) /.../c310m.F:147.16: DR=DLGAMA(-Z1) 1 Error: Result of LGAMMA overflows its kind at (1) Code looks like: IMPLICIT DOUBLE PRECISION (A-H,O-Q,S-Z) IMPLICIT REAL (R) REAL ALGAMA DOUBLE PRECISION + Z0, Z1, HF, X DR=DLGAMA(Z0) DR=DLGAMA(-Z1) Strange thing is that there is a previous DR=DLGAMA(X) which doesn't seems to be problematic. I attach the whole problematic file. If gcc goes to rawhide I could try to simplify the problematic file. -- Pat -------------- next part -------------- # 1 "/home/dumas/src/fc-write/cernlib/devel/cernlib-2006/2006/src/mathlib/gen/tests/c310m.F" # 1 "/home/dumas/src/fc-write/cernlib/devel/cernlib-2006/2006/build/mathlib/gen/tests//" # 1 "" # 1 "" # 1 "/home/dumas/src/fc-write/cernlib/devel/cernlib-2006/2006/src/mathlib/gen/tests/c310m.F" * * $Id: c310m.F,v 1.1.1.1 1996/04/01 15:01:14 mclareni Exp $ * * $Log: c310m.F,v $ * Revision 1.1.1.1 1996/04/01 15:01:14 mclareni * Mathlib gen * * # 1 "/home/dumas/src/fc-write/cernlib/devel/cernlib-2006/2006/src/mathlib/gen/gen/pilot.h" 1 # 40 "/home/dumas/src/fc-write/cernlib/devel/cernlib-2006/2006/src/mathlib/gen/gen/pilot.h" # 57 "/home/dumas/src/fc-write/cernlib/devel/cernlib-2006/2006/src/mathlib/gen/gen/pilot.h" # 10 "/home/dumas/src/fc-write/cernlib/devel/cernlib-2006/2006/src/mathlib/gen/tests/c310m.F" 2 SUBROUTINE C310M C This program tests the operation of MATHLIB subprograms C ALGAMA, DLGAMA and QLGAMA(C310) LOGICAL LTEST, LTEST1,LTEST2 COMMON /C310LT1/LTEST1 # 1 "/home/dumas/src/fc-write/cernlib/devel/cernlib-2006/2006/src/mathlib/gen/tests/iorc.inc" 1 * * $Id: iorc.inc,v 1.1.1.1 1996/04/01 15:01:31 mclareni Exp $ * * $Log: iorc.inc,v $ * Revision 1.1.1.1 1996/04/01 15:01:31 mclareni * Mathlib gen * * * * iorc.inc * COMMON/IOLUNS/LIN,LOUT COMMON/GTSTAT/NTEST,NFAIL,IRC # 20 "/home/dumas/src/fc-write/cernlib/devel/cernlib-2006/2006/src/mathlib/gen/tests/c310m.F" 2 CALL HEADER('C310',0) LTEST=.TRUE. LTEST1=.TRUE. LTEST2=.TRUE. CALL C310D LTEST=LTEST .AND. LTEST1 IRC=ITEST('C310',LTEST) CALL PAGEND('C310') RETURN END SUBROUTINE C310D # 1 "/home/dumas/src/fc-write/cernlib/devel/cernlib-2006/2006/src/mathlib/gen/tests/imp64r.inc" 1 * * $Id: imp64r.inc,v 1.1.1.1 1996/04/01 15:01:31 mclareni Exp $ * * $Log: imp64r.inc,v $ * Revision 1.1.1.1 1996/04/01 15:01:31 mclareni * Mathlib gen * * * * imp64r.inc * IMPLICIT DOUBLE PRECISION (A-H,O-Q,S-Z) IMPLICIT REAL (R) # 38 "/home/dumas/src/fc-write/cernlib/devel/cernlib-2006/2006/src/mathlib/gen/tests/c310m.F" 2 REAL ALGAMA C Set maximum error allowed for test to be considered successful DIMENSION TOL(2),TOLIBM(2) # 1 "/home/dumas/src/fc-write/cernlib/devel/cernlib-2006/2006/src/mathlib/gen/gen/def64.inc" 1 * * $Id: def64.inc,v 1.1.1.1 1996/04/01 15:02:59 mclareni Exp $ * * $Log: def64.inc,v $ * Revision 1.1.1.1 1996/04/01 15:02:59 mclareni * Mathlib gen * * * * def64.inc * DOUBLE PRECISION # 43 "/home/dumas/src/fc-write/cernlib/devel/cernlib-2006/2006/src/mathlib/gen/tests/c310m.F" 2 + Z0, Z1, HF, X PARAMETER (Z0 = 0, Z1 = 1, HF = Z1/2) LOGICAL LTEST1 C CHARACTER*6 TFUNC(2) C # 1 "/home/dumas/src/fc-write/cernlib/devel/cernlib-2006/2006/src/mathlib/gen/tests/iorc.inc" 1 * * $Id: iorc.inc,v 1.1.1.1 1996/04/01 15:01:31 mclareni Exp $ * * $Log: iorc.inc,v $ * Revision 1.1.1.1 1996/04/01 15:01:31 mclareni * Mathlib gen * * * * iorc.inc * COMMON/IOLUNS/LIN,LOUT COMMON/GTSTAT/NTEST,NFAIL,IRC # 50 "/home/dumas/src/fc-write/cernlib/devel/cernlib-2006/2006/src/mathlib/gen/tests/c310m.F" 2 DIMENSION Y(7),T(7) REAL RT(7) DATA LTEST1/.TRUE./ DATA TOL/1D-8, 5D-11/ DATA TOLIBM/1D-6, 1D-11/ DATA TFUNC/'ALGAMA','DLGAMA'/ DATA (Y(I), I=1,7) + / 0.10D-02,0.35D0, 1.00D0, 2.50D0, 8.00D0, 100.00D0, + 0.99990000000000D0/ DATA (T(I), I=1,7) + /6.90717888538385361D0,0.934581227146233540D0, + 0.000000000000000000D0,0.284682870472918514D0, + 8.52516136106527989D0,359.134205369575341D0, + 0.577297915612021598D-4 / ERRMAX=0D0 RERRMAX=0E0 NF=2 DO 1000 JF=1,NF ERRMAX= 0.0D0 IF(JF.EQ.1)WRITE(LOUT,'(/10X,''TEST FOR ALGAMA'')') IF(JF.EQ.2)WRITE(LOUT,'(/10X,''TEST FOR DLGAMA'')') WRITE(LOUT,'(/8X,''X'',14X,'' '',A,''(X)'',7X,''Rel Error'')') + TFUNC(JF) DO 1 I = 1,7 X=Y(I) IF(JF.EQ.1)THEN RX=X RT(I)=T(I) RDR=ALGAMA(RX) IF(ABS(RDR) .GT. 1E-4)RER=ABS((RDR-RT(I))/RDR) IF(ABS(RDR) .LE. 1E-4)RER=ABS((RDR-RT(I))) X=RX ERRMAX =MAX(RERRMAX,RER) WRITE(LOUT,'(1X,F10.3,1P,E27.9,E10.1)') + RX ,RDR,RER ENDIF IF(JF.EQ.2)THEN DR=DLGAMA(X) IF(ABS(DR) .GT. 1D-14) ER=ABS((DR-T(I))/DR) ERRMAX =MAX(ERRMAX,ER) WRITE(LOUT,'(1X,F10.3,1P,E27.18,E10.1)') X,DR,ER ENDIF 1 CONTINUE ETOL=TOLIBM(JF) ETOL=TOL(JF) WRITE(LOUT,'(/''LARGEST RELATIVE ERROR WAS'',1P,E10.1)') +ERRMAX LTEST1=LTEST1.AND.(ERRMAX.LE.ETOL) ERRMAX= 0D0 WRITE(LOUT,'(/''TESTING ERROR MESSAGES:'')') IF(JF.EQ.1)THEN RZ0=Z0 RZ1=Z1 DR=ALGAMA(RZ0) DR=ALGAMA(-RZ1) ENDIF IF(JF.EQ.2)THEN DR=DLGAMA(Z0) DR=DLGAMA(-Z1) ENDIF 1000 CONTINUE RETURN END From lsof at nodata.co.uk Sun Jan 6 17:18:37 2008 From: lsof at nodata.co.uk (nodata) Date: Sun, 06 Jan 2008 18:18:37 +0100 Subject: Init : someone could comment this ? In-Reply-To: <1199550054.2847.1.camel@bureau.maison> References: <1199550054.2847.1.camel@bureau.maison> Message-ID: <1199639917.2855.7.camel@sb-home> Am Samstag, den 05.01.2008, 17:20 +0100 schrieb Tanguy Eric: > I just find this > http://www.pardus.org.tr/eng/projeler/comar/SpeedingUpLinuxWithPardus.html maybe it's known but someone could comment this because it seems to gain init time. > > Eric > > This looks good, because it solves the actual problem that people are complaining about (unoptimal boot). There are other problems that people have made clear as part of the unoptimal boot discussion, but as a first step, maximising i/o usage seems like a good one :) From caillon at redhat.com Sun Jan 6 17:20:38 2008 From: caillon at redhat.com (Christopher Aillon) Date: Sun, 06 Jan 2008 18:20:38 +0100 Subject: Request for remove a package from rawhide In-Reply-To: <668bb39a0801060913g7da50934qdac27c9e95485dee@mail.gmail.com> References: <668bb39a0801060913g7da50934qdac27c9e95485dee@mail.gmail.com> Message-ID: <47810DE6.4000003@redhat.com> On 01/06/2008 06:13 PM, ? wrote: > Hi! > Some time ago I built new openarena package. Unfortunately, after some > testing it turned out that package is broken and prevent players from > playing multiplayer. It seems to me that package is built but it's not > been pushed to repo yet. That's why I ask to remove it from rawhide. > I know I could reverse all changes and bump release once again, but it > will cause completely unnecessary update for some users. > So since it's not in repo yet, I make a request to any admin to just > preclude a package from being pushed to repo. I hope nothing stands in > the way to do so. You can do this yourself, actually. koji untag-pkg dist-f9 foo-1.2-3.fc9 From jonathan.underwood at gmail.com Sun Jan 6 17:25:55 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 6 Jan 2008 17:25:55 +0000 Subject: Init : someone could comment this ? In-Reply-To: <47804A59.6090205@ncsu.edu> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <645d17210801051646p71711a7ck7d3824572fe8ed21@mail.gmail.com> <47804A59.6090205@ncsu.edu> Message-ID: <645d17210801060925w407abb85i512d9a495ea07b0a@mail.gmail.com> On 06/01/2008, Casey Dahlin wrote: > Jonathan Underwood wrote: > > On 06/01/2008, Casey Dahlin wrote: > > > >> There is work being done in this area for Fedora as well. I've been > >> working on a parallel booting system for us that also will provide dbus > >> notifications for the starting of various services. (Hopefully I'll be > >> leading a hackfest at FUDCon in a few days to get a few more eyes and > >> hands on the code). > >> > >> > > > > Other than compatability with sysvinit scripts, why was upstart dismissed? > > > > > Many options were looked at during the last iteration of this > discussion, and by my understanding prcsys was the one that won out. See > here: > http://fedoraproject.org/wiki/FCNewInit/RC?highlight=%28fcnewinit%29 That's a shame, because the roadmap for upstart includes better sysvinit compatibility, dbus support for IPC, service mangement et. See: https://lists.ubuntu.com/archives/upstart-devel/2007-October/000468.html It seems to me that many of the reasons for dismissing upstart in favour of a write-from-scratch have since disappeared. J. From mr.ecik at gmail.com Sun Jan 6 17:26:33 2008 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Sun, 6 Jan 2008 18:26:33 +0100 Subject: Request for remove a package from rawhide In-Reply-To: <47810DE6.4000003@redhat.com> References: <668bb39a0801060913g7da50934qdac27c9e95485dee@mail.gmail.com> <47810DE6.4000003@redhat.com> Message-ID: <668bb39a0801060926j3be3009cxa7a25a0833f1e211@mail.gmail.com> It seems openarena has been untagged successfully. Christopher, thanks for advice! 2008/1/6, Christopher Aillon : > On 01/06/2008 06:13 PM, ? wrote: > > Hi! > > Some time ago I built new openarena package. Unfortunately, after some > > testing it turned out that package is broken and prevent players from > > playing multiplayer. It seems to me that package is built but it's not > > been pushed to repo yet. That's why I ask to remove it from rawhide. > > I know I could reverse all changes and bump release once again, but it > > will cause completely unnecessary update for some users. > > So since it's not in repo yet, I make a request to any admin to just > > preclude a package from being pushed to repo. I hope nothing stands in > > the way to do so. > > You can do this yourself, actually. > > koji untag-pkg dist-f9 foo-1.2-3.fc9 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Micha? Bentkowski mr.ecik at gmail.com From tibbs at math.uh.edu Sun Jan 6 17:32:02 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 Jan 2008 11:32:02 -0600 Subject: rawhide report: bacula/kannel -> mktexlsr ? In-Reply-To: References: <200801051224.m05COEwl021556@porkchop.devel.redhat.com> <1199562968.11839.34.camel@Jehannum> Message-ID: >>>>> "AL" == Alex Lancaster writes: AL> Also, bacula has closed ACLs, so nobody can currently rebuild the AL> package if and when this packaging issue is resolved. Can AL> somebody please open them up? I wouldn't open them up without consulting the maintainer, but a few of us can still rebuild it if the underlying problem gets fixed. BTW, I tried manually specifying TEXINPUTS in the bacula build which I hoped would force the searching of the directory with html.sty but that didn't help and I'm not quite sure why. - J< From bruno at wolff.to Sun Jan 6 17:33:04 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Sun, 6 Jan 2008 11:33:04 -0600 Subject: Fwd: closing out old bugs of unmaintained releases In-Reply-To: References: <200801051328.13094.opensource@till.name> <20080105174720.dc73725a.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20080106173304.GA10654@wolff.to> On Sat, Jan 05, 2008 at 16:25:53 -0500, Jon Stanley wrote: > > Agreed. Which is why mass-closing is such an appealing thing from > both sides of the fence. It's been mentioned in this thread (not sure > if on this list or another, I'll go back and look), that the message > used to mass-close should basically admit the fact that we know that > we have a problem, and that we are taking action to fix the problem in > the future so that we don't get into this state again. Shouldn't the underlying problem be fixed before doing the mass close? If not there is likely to be another one down the road while tickets continue to accumalate before the fix actually happens. I don't see any rush, as tickets that were being ignored can continue to be ignored until things are fixed. From ljuwaida at fedoraproject.org Sun Jan 6 18:21:31 2008 From: ljuwaida at fedoraproject.org (Laith Juwaidah) Date: Sun, 6 Jan 2008 22:21:31 +0400 Subject: Control center idea In-Reply-To: <200801051104.45976.jamatos@fc.up.pt> References: <1199374110.5023.2.camel@frosty> <477F1797.4020700@sapience.com> <200801051104.45976.jamatos@fc.up.pt> Message-ID: <200801062221.38297.ljuwaida@fedoraproject.org> On Saturday 05 January 2008 15:04:45 Jos? Matos wrote: > On Saturday 05 January 2008 05:37:27 Mail Lists wrote: > > ?Have you looked at the KDE control center ? It may be even better place > > to go ... There was a small talk about this on #fedora-kde a few days ago... I would have gone with that, since it'll be simply creating modules for systemsettings to integrate other settings tools, but, is that OK? You know, it started as Kubuntu's configuration tool, is that OK with Redhat? How about GNOME users? > > FWIW I like the kde 4 system settings approach more than the control center > of kde 3. There are several discussions in the net about the reason for a > more slim model. I don't like it. > > -- > Jos? Ab?lio -- Laith Juwaidah http://www.ljuwaidah.org/ From opensource at till.name Sun Jan 6 18:27:40 2008 From: opensource at till.name (Till Maas) Date: Sun, 06 Jan 2008 19:27:40 +0100 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080106095141.0cf1a669@redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <20080106152143.40fd0b31.mschwendt.tmp0701.nospam@arcor.de> <20080106095141.0cf1a669@redhat.com> Message-ID: <200801061927.48926.opensource@till.name> On Sun January 6 2008, Jesse Keating wrote: > On Sun, 6 Jan 2008 15:21:43 +0100 > > Michael Schwendt wrote: > > $ koji build --scratch --nowait dist-f9-gcc43 > > cvs://cvs.fedoraproject.org/cvs/pkgs?rpms/audacity/devel#audacity-1_3_2-1 > >8_fc9 > > Or even easier: In case it is the latest cvs tag, you can also run make scratch-build TARGET=dist-f9-gcc43 But this will not use the "--nowait". To a list of more help targets, run "make help". > $ koji build --scratch --nowait dist-f9-gcc43 > cvs://cvs.fedoraproject.org/cvs/pkgs?rpms/audacity/devel#HEAD This has also the advantage, that you do not need to run a "make tag" before you can build the scratch build. With the Makefile.common Addons[1] it is also possible to use make scratch-head-build TARGET=dist-f9-gcc43 Regards, Till [1] http://fedoraproject.org/wiki/PackageMaintainers/UsefulScripts#head-74286c0a7bbaaba6f3371b4a7490c2b246e527ee -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From pemboa at gmail.com Sun Jan 6 18:33:42 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Sun, 6 Jan 2008 12:33:42 -0600 Subject: Control center idea In-Reply-To: <200801062221.38297.ljuwaida@fedoraproject.org> References: <1199374110.5023.2.camel@frosty> <477F1797.4020700@sapience.com> <200801051104.45976.jamatos@fc.up.pt> <200801062221.38297.ljuwaida@fedoraproject.org> Message-ID: <16de708d0801061033r1a1c3f00i3366a33cbb577e42@mail.gmail.com> On Jan 6, 2008 12:21 PM, Laith Juwaidah wrote: > There was a small talk about this on #fedora-kde a few days ago... > I would have gone with that, since it'll be simply creating modules for > systemsettings to integrate other settings tools, but, is that OK? You know, > it started as Kubuntu's configuration tool, is that OK with Redhat? How about > GNOME users? well it doesn't have to be okay with Redhat or Gnome guys. Although from your brief description, I don't see the point/benefit of the idea. > > FWIW I like the kde 4 system settings approach more than the control center > > of kde 3. There are several discussions in the net about the reason for a > > more slim model. > I don't like it. Any existing examples of it (screenshots) to share? -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From jkeating at redhat.com Sun Jan 6 18:33:13 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 6 Jan 2008 13:33:13 -0500 Subject: Request for remove a package from rawhide In-Reply-To: <668bb39a0801060926j3be3009cxa7a25a0833f1e211@mail.gmail.com> References: <668bb39a0801060913g7da50934qdac27c9e95485dee@mail.gmail.com> <47810DE6.4000003@redhat.com> <668bb39a0801060926j3be3009cxa7a25a0833f1e211@mail.gmail.com> Message-ID: <20080106133313.2c1c0403@redhat.com> On Sun, 6 Jan 2008 18:26:33 +0100 "Micha? Bentkowski" wrote: > It seems openarena has been untagged successfully. > Christopher, thanks for advice! Hrm. Some time ago we had agreed to not fix things by making builds disappear, even in rawhide. NVRs must always go up. Since doing this means anybody who happened to upgrade to your bad build, there is no way for them to get a fixed build unless they download the package manually and use a cryptic rpm call. The proper procedure would have been to back out the changes and bump the build so that there is an upgrade path. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From martin at marquesminen.com.ar Sun Jan 6 16:41:33 2008 From: martin at marquesminen.com.ar (Martin Marques) Date: Sun, 06 Jan 2008 14:41:33 -0200 Subject: I'm mellllttttttinggg!!! (kernel 2.6.24-0.133.rc6.git8.fc9) In-Reply-To: <20080105134627.GA17509@jadzia.bu.edu> References: <20080105134627.GA17509@jadzia.bu.edu> Message-ID: <478104BD.8030008@marquesminen.com.ar> Matthew Miller escribi?: > So, I came back from vacation and updated my rawhide machine to the latest. > Firefox 3 is all broke for me (haven't diagnosed that yet) and not having a > Firefox 2 package handy that doesn't conflict with xulrunner, I decided to > build one. Core temp quickly went to 125C?+ and the computer powered > itself off to avoid starting any fires. > > This doesn't seem to happen with kernel-2.6.24-0.83.rc5.fc9, which I had > installed before the break. Oh, it gets hot, but more like 95C?. Processor > is an AMD Athlon(tm) 64 Processor 3200+ but I'm running in 32-bit mode. Saame kernel, but with a turion 64 chip, running the x86_64 kernel and I get 50?C or 53?C. 95?C is the max temperture of this core. From caillon at redhat.com Sun Jan 6 19:04:08 2008 From: caillon at redhat.com (Christopher Aillon) Date: Sun, 06 Jan 2008 20:04:08 +0100 Subject: Request for remove a package from rawhide In-Reply-To: <20080106133313.2c1c0403@redhat.com> References: <668bb39a0801060913g7da50934qdac27c9e95485dee@mail.gmail.com> <47810DE6.4000003@redhat.com> <668bb39a0801060926j3be3009cxa7a25a0833f1e211@mail.gmail.com> <20080106133313.2c1c0403@redhat.com> Message-ID: <47812628.1020807@redhat.com> On 01/06/2008 07:33 PM, Jesse Keating wrote: > On Sun, 6 Jan 2008 18:26:33 +0100 > "Micha? Bentkowski" wrote: > >> It seems openarena has been untagged successfully. >> Christopher, thanks for advice! > > Hrm. Some time ago we had agreed to not fix things by making builds > disappear, even in rawhide. NVRs must always go up. Since doing this > means anybody who happened to upgrade to your bad build, there is no > way for them to get a fixed build unless they download the package > manually and use a cryptic rpm call. The proper procedure would have > been to back out the changes and bump the build so that there is an > upgrade path. Even if he'd *just* built it into rawhide and it wouldn't have been in a compose yet? Someone would have had to grab it out of koji and use an rpm call to install it. From ljuwaida at fedoraproject.org Sun Jan 6 19:06:40 2008 From: ljuwaida at fedoraproject.org (Laith Juwaidah) Date: Sun, 6 Jan 2008 23:06:40 +0400 Subject: Control center idea In-Reply-To: <16de708d0801061033r1a1c3f00i3366a33cbb577e42@mail.gmail.com> References: <1199374110.5023.2.camel@frosty> <200801062221.38297.ljuwaida@fedoraproject.org> <16de708d0801061033r1a1c3f00i3366a33cbb577e42@mail.gmail.com> Message-ID: <200801062306.43160.ljuwaida@fedoraproject.org> On Sunday 06 January 2008 22:33:42 Arthur Pemberton wrote: > On Jan 6, 2008 12:21 PM, Laith Juwaidah wrote: > > There was a small talk about this on #fedora-kde a few days ago... > > I would have gone with that, since it'll be simply creating modules for > > systemsettings to integrate other settings tools, but, is that OK? You > > know, it started as Kubuntu's configuration tool, is that OK with Redhat? > > How about GNOME users? > > well it doesn't have to be okay with Redhat or Gnome guys. Although > from your brief description, I don't see the point/benefit of the > idea. > Most reviews I read about F8 had a line similar to "And Fedora still doesn't have a central configuration tool". For the user it doesn't matter if we built it ourselves, or we just created modules for some other distro's configuration tool. > > > FWIW I like the kde 4 system settings approach more than the control > > > center of kde 3. There are several discussions in the net about the > > > reason for a more slim model. > > > > I don't like it. > > Any existing examples of it (screenshots) to share? > http://www.ljuwaidah.org/pictures/Screenshot3.png > -- > Fedora 7 : sipping some of that moonshine > ( www.pembo13.com ) -- Laith Juwaidah http://www.ljuwaidah.org/ From nphilipp at redhat.com Sun Jan 6 19:09:50 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Sun, 06 Jan 2008 20:09:50 +0100 Subject: Init : someone could comment this ? In-Reply-To: <7f692fec0801060752g4891432dsb700a81e3b6b2d72@mail.gmail.com> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <1199600447.4670.167.camel@dimi.lattica.com> <7f692fec0801060752g4891432dsb700a81e3b6b2d72@mail.gmail.com> Message-ID: <1199646590.14377.23.camel@gibraltar.str.redhat.com> On Sun, 2008-01-06 at 10:52 -0500, Yaakov Nemoy wrote: > It is obscure, and I agree it's very hard to justify putting more > languages in the mix. > > Haskell has a few advantages over C. It's very easy to write a > wrapper in Haskell that checks if file 'foo' is newer than the binary > that it's trying to execute, and if so, to compile the new file, load > up the new binary and keep running. You would have to have very good arguments to require a compiler collection just to boot a system. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From makghosh at gmail.com Sun Jan 6 19:22:31 2008 From: makghosh at gmail.com (Arindam Ghosh) Date: Mon, 7 Jan 2008 00:52:31 +0530 Subject: integration of LTSP 5 in fedora In-Reply-To: <4780F2F9.7090501@gmail.com> References: <539333cb0801040958r5ceb61b3t3d32b413b578d355@mail.gmail.com> <539333cb0801042058j793f301dsfe75747094b0968@mail.gmail.com> <20080105094839.GE2570@free.fr> <477FCC43.1070008@gmail.com> <539333cb0801052016h1865b9a3o9888a1919d33fd81@mail.gmail.com> <20080106095409.2bbc4a72@redhat.com> <4780F2F9.7090501@gmail.com> Message-ID: <8990327d0801061122m3ba4f6e2r63f3a17e4bff495c@mail.gmail.com> I would also like to help out in the integration of ltsp5 in fedora as such. As pointed by [http://fedoraproject.org/wiki/K12Linux], the developmental bazaar repositories of ltsp5 for fedora seems to be [https://code.launchpad.net/~ltsp-upstream]. And from the bug tracker pointed by Patrice, the package review bugs of ltsp-server[1] and ltsp-client [2] and their comment slugs are certainly good pointers. But i would certainly like to know the current status.....i mean it would be great if someone make out a rough list on what is still left to be done...or atleast point to one [1] [https://bugzilla.redhat.com/show_bug.cgi?id=331731] [2] [https://bugzilla.redhat.com/show_bug.cgi?id=336911] cheers Arindam -- GPG Key: 0EE58920 Key Server: http://pgp.mit.edu From jkeating at redhat.com Sun Jan 6 19:22:26 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 6 Jan 2008 14:22:26 -0500 Subject: Request for remove a package from rawhide In-Reply-To: <47812628.1020807@redhat.com> References: <668bb39a0801060913g7da50934qdac27c9e95485dee@mail.gmail.com> <47810DE6.4000003@redhat.com> <668bb39a0801060926j3be3009cxa7a25a0833f1e211@mail.gmail.com> <20080106133313.2c1c0403@redhat.com> <47812628.1020807@redhat.com> Message-ID: <20080106142226.29542191@redhat.com> On Sun, 06 Jan 2008 20:04:08 +0100 Christopher Aillon wrote: > Even if he'd *just* built it into rawhide and it wouldn't have been > in a compose yet? Someone would have had to grab it out of koji and > use an rpm call to install it. Sure if it hadn't made a rawhide compose yet that's one thing. However he said "some time ago" which in my mind equals more than a day ago. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nphilipp at redhat.com Sun Jan 6 19:31:49 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Sun, 06 Jan 2008 20:31:49 +0100 Subject: Init : someone could comment this ? In-Reply-To: <1199638106.6022.88.camel@beck.corsepiu.local> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <1199638106.6022.88.camel@beck.corsepiu.local> Message-ID: <1199647909.14377.37.camel@gibraltar.str.redhat.com> On Sun, 2008-01-06 at 17:48 +0100, Ralf Corsepius wrote: > On Sun, 2008-01-06 at 10:44 -0500, Yaakov Nemoy wrote: > > and almost always putting at least some code in shared > > memory space, asking for Python in particular is not unreasonable. > I could not disagree more - To me any init-script system requiring > anything outside of what POSIX requires is a mis-conception and flawed > design. How is that? I guess if we looked hard enough then we'd find that even today we use things outside of POSIX to get the machine going, things which we can't do without. Just because something is an established standard, it's not necessarily sufficient: One of the problems we have with SysV style init scripts are the numerous forks and execs which are costly. I don't see how we could solve that problem while using shell (or other tools included in POSIX). Granted, we could source the init scripts from one master script to avoid that, but then we'd be quicker in a cesspool of clashing global variables or one badly written script killing the whole boot process than we'd want to imagine. If I'm just being unimaginative, I'd be interested in how this problem can be solved while limiting oneself to what POSIX offers. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From loupgaroublond at gmail.com Sun Jan 6 19:33:39 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Sun, 6 Jan 2008 14:33:39 -0500 Subject: Init : someone could comment this ? In-Reply-To: <1199646590.14377.23.camel@gibraltar.str.redhat.com> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <1199600447.4670.167.camel@dimi.lattica.com> <7f692fec0801060752g4891432dsb700a81e3b6b2d72@mail.gmail.com> <1199646590.14377.23.camel@gibraltar.str.redhat.com> Message-ID: <7f692fec0801061133u11d6731cp783c335dbe657380@mail.gmail.com> On Jan 6, 2008 2:09 PM, Nils Philippsen wrote: > On Sun, 2008-01-06 at 10:52 -0500, Yaakov Nemoy wrote: > > Haskell has a few advantages over C. It's very easy to write a > > wrapper in Haskell that checks if file 'foo' is newer than the binary > > that it's trying to execute, and if so, to compile the new file, load > > up the new binary and keep running. > > You would have to have very good arguments to require a compiler > collection just to boot a system. Which are the same requirements you would have to propose to put a just in time compiler and virtual machine. I stated before, the only way to know if this kind of a system is ultimately faster is to actually implement it fully, and benchmark it. In this case, the argument would be to use Haskell to define init scripts, and possibly other aspects of the boot process. You gain the power Haskell provides. You lose the advantage of a well known language. -Yaakov From cjdahlin at ncsu.edu Sun Jan 6 19:34:14 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Sun, 06 Jan 2008 14:34:14 -0500 Subject: Init : someone could comment this ? In-Reply-To: <1199638106.6022.88.camel@beck.corsepiu.local> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <1199638106.6022.88.camel@beck.corsepiu.local> Message-ID: <47812D36.4030309@ncsu.edu> Ralf Corsepius wrote: > On Sun, 2008-01-06 at 10:44 -0500, Yaakov Nemoy wrote: > >> On Jan 6, 2008 5:36 AM, Enrico Scholz >> wrote: >> >>> An initsystem which requires depbloat like python or perl is completely >>> unacceptably. >>> >> Bash is not depbloat, but bash + awk + grep + any other userspace >> tools shows alot of dep bloat. >> > You will want to make yourself familiar with POSIX. > > >> Since python is installed on most >> machines, >> > Only because RH/Fedora's infrastructure forces users to install it. > > >> and almost always putting at least some code in shared >> memory space, asking for Python in particular is not unreasonable. >> > I could not disagree more - To me any init-script system requiring > anything outside of what POSIX requires is a mis-conception and flawed > design. > > Is there a reason for this? It still sounds like a whole lot of "PURGE THE IMPURE!!!" to me. --CJD From loupgaroublond at gmail.com Sun Jan 6 19:34:23 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Sun, 6 Jan 2008 14:34:23 -0500 Subject: Init : someone could comment this ? In-Reply-To: <1199647909.14377.37.camel@gibraltar.str.redhat.com> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <1199638106.6022.88.camel@beck.corsepiu.local> <1199647909.14377.37.camel@gibraltar.str.redhat.com> Message-ID: <7f692fec0801061134o56b7c591n77cc0f2a16cd9a88@mail.gmail.com> On Jan 6, 2008 2:31 PM, Nils Philippsen wrote: > On Sun, 2008-01-06 at 17:48 +0100, Ralf Corsepius wrote: > > On Sun, 2008-01-06 at 10:44 -0500, Yaakov Nemoy wrote: > > > and almost always putting at least some code in shared > > > memory space, asking for Python in particular is not unreasonable. > > I could not disagree more - To me any init-script system requiring > > anything outside of what POSIX requires is a mis-conception and flawed > > design. > > How is that? I guess if we looked hard enough then we'd find that even > today we use things outside of POSIX to get the machine going, things > which we can't do without. > > Just because something is an established standard, it's not necessarily > sufficient: One of the problems we have with SysV style init scripts are > the numerous forks and execs which are costly. I don't see how we could > solve that problem while using shell (or other tools included in POSIX). > Granted, we could source the init scripts from one master script to > avoid that, but then we'd be quicker in a cesspool of clashing global > variables or one badly written script killing the whole boot process > than we'd want to imagine. If I'm just being unimaginative, I'd be > interested in how this problem can be solved while limiting oneself to > what POSIX offers. Thanks, you said it far better than I could have :) -Yaakov From mattdm at mattdm.org Sun Jan 6 19:42:38 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 6 Jan 2008 14:42:38 -0500 Subject: Init : someone could comment this ? In-Reply-To: <873ata7veq.fsf@kosh.bigo.ensc.de> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <873ata7veq.fsf@kosh.bigo.ensc.de> Message-ID: <20080106194238.GA5456@jadzia.bu.edu> On Sun, Jan 06, 2008 at 05:47:57PM +0100, Enrico Scholz wrote: > > Since python is installed on most machines > We must have different definitions of "most". My one is ">50%" and your > assumption does not hold for my machines: Are you seriously suggesting that less than 50% of Fedora systems have yum installed? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From wart at kobold.org Sun Jan 6 19:50:21 2008 From: wart at kobold.org (Wart) Date: Sun, 06 Jan 2008 11:50:21 -0800 Subject: taking over blt and tktable In-Reply-To: <4780FF0C.4040500@free.fr> References: <4780FF0C.4040500@free.fr> Message-ID: <478130FD.2020609@kobold.org> Jean-Luc Fontaine wrote: > I am very sorry but I no longer have time and resources to care for the > blt and tktable (tcl libraries) packages: would anybody be interested in > taking over? Yes, I can take them over. Go ahead and mark them as orphan in the package database and I'll reassign them to myself. --Wart From pemboa at gmail.com Sun Jan 6 20:04:52 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Sun, 6 Jan 2008 14:04:52 -0600 Subject: Control center idea In-Reply-To: <200801062306.43160.ljuwaida@fedoraproject.org> References: <1199374110.5023.2.camel@frosty> <200801062221.38297.ljuwaida@fedoraproject.org> <16de708d0801061033r1a1c3f00i3366a33cbb577e42@mail.gmail.com> <200801062306.43160.ljuwaida@fedoraproject.org> Message-ID: <16de708d0801061204t691796aak635e4dce43be3160@mail.gmail.com> On Jan 6, 2008 1:06 PM, Laith Juwaidah wrote: > > Any existing examples of it (screenshots) to share? > > > http://www.ljuwaidah.org/pictures/Screenshot3.png This is quite nice, what distro is it from? -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From cjdahlin at ncsu.edu Sun Jan 6 20:14:30 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Sun, 06 Jan 2008 15:14:30 -0500 Subject: Init : someone could comment this ? In-Reply-To: <20080106132714.373731a2@pensja.lam.pl> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <645d17210801051646p71711a7ck7d3824572fe8ed21@mail.gmail.com> <47804A59.6090205@ncsu.edu> <20080106132714.373731a2@pensja.lam.pl> Message-ID: <478136A6.8050500@ncsu.edu> Leszek Matok wrote: > Dnia 2008-01-05, o godz. 22:26:17 Casey Dahlin napisa?(a): > > >> rewrite was in order, so I went ahead and started working on a new app >> (which I have titled 'rrn') which is now near feature parity with >> prcsys. >> > "rrn" is an old fork of "rn", a usenet reader. Besides, please, don't call > features which you will be advertising as breakthroughs in future Fedora > versions with onomatopoeias emulating my stomach :) > > Lam > It stands for "Resolve/Run/Notify" in this context, but duly noted. I will attempt to spare your usenet reader, and your abdomen, of any infringement. --CJD From enrico.scholz at informatik.tu-chemnitz.de Sun Jan 6 20:14:52 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sun, 06 Jan 2008 21:14:52 +0100 Subject: Init : someone could comment this ? In-Reply-To: <20080106194238.GA5456@jadzia.bu.edu> (Matthew Miller's message of "Sun, 6 Jan 2008 14:42:38 -0500") References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <873ata7veq.fsf@kosh.bigo.ensc.de> <20080106194238.GA5456@jadzia.bu.edu> Message-ID: <87y7b2679f.fsf@kosh.bigo.ensc.de> Matthew Miller writes: >> > Since python is installed on most machines >> We must have different definitions of "most". My one is ">50%" and your >> assumption does not hold for my machines: > > Are you seriously suggesting that less than 50% of Fedora systems have > yum installed? yes; at least on my machines there is yum only on the host while guestsystems don't need it. Ratio of physical hosts to virtual guests is something like 1:20 - 1:30. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From caillon at redhat.com Sun Jan 6 20:17:33 2008 From: caillon at redhat.com (Christopher Aillon) Date: Sun, 06 Jan 2008 21:17:33 +0100 Subject: Request for remove a package from rawhide In-Reply-To: <20080106142226.29542191@redhat.com> References: <668bb39a0801060913g7da50934qdac27c9e95485dee@mail.gmail.com> <47810DE6.4000003@redhat.com> <668bb39a0801060926j3be3009cxa7a25a0833f1e211@mail.gmail.com> <20080106133313.2c1c0403@redhat.com> <47812628.1020807@redhat.com> <20080106142226.29542191@redhat.com> Message-ID: <4781375D.4080007@redhat.com> On 01/06/2008 08:22 PM, Jesse Keating wrote: > On Sun, 06 Jan 2008 20:04:08 +0100 > Christopher Aillon wrote: > >> Even if he'd *just* built it into rawhide and it wouldn't have been >> in a compose yet? Someone would have had to grab it out of koji and >> use an rpm call to install it. > > Sure if it hadn't made a rawhide compose yet that's one thing. However > he said "some time ago" which in my mind equals more than a day ago. Yeah. I'm guessing he isn't a native speaker. FWIW, I looked to see what the latest build and builddate was before offering the advice. I probably should have also given the caveat though so others wouldn't have taken it as "the" solution. From berrange at redhat.com Sun Jan 6 20:19:50 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Sun, 6 Jan 2008 20:19:50 +0000 Subject: Init : someone could comment this ? In-Reply-To: <20080106194238.GA5456@jadzia.bu.edu> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <873ata7veq.fsf@kosh.bigo.ensc.de> <20080106194238.GA5456@jadzia.bu.edu> Message-ID: <20080106201950.GB5842@redhat.com> On Sun, Jan 06, 2008 at 02:42:38PM -0500, Matthew Miller wrote: > On Sun, Jan 06, 2008 at 05:47:57PM +0100, Enrico Scholz wrote: > > > Since python is installed on most machines > > We must have different definitions of "most". My one is ">50%" and your > > assumption does not hold for my machines: > > Are you seriously suggesting that less than 50% of Fedora systems have yum > installed? If you think of a traditional OS install then yum will be common. If you think of Fedora as a base for creating black box appliances, then yum may well not be installed at all - whole appliance upgrades are done rather than individual packages. Likewise if you deploy Fedora in 'stateless' mode, you're not upgrading packages on individual machines you are instead generating a new master image. So again yum will not be there. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From jfontain at free.fr Sun Jan 6 20:30:50 2008 From: jfontain at free.fr (Jean-Luc Fontaine) Date: Sun, 06 Jan 2008 21:30:50 +0100 Subject: taking over blt and tktable In-Reply-To: <478130FD.2020609@kobold.org> References: <4780FF0C.4040500@free.fr> <478130FD.2020609@kobold.org> Message-ID: <47813A7A.8050601@free.fr> Wart wrote: > Jean-Luc Fontaine wrote: > >> I am very sorry but I no longer have time and resources to care for the >> blt and tktable (tcl libraries) packages: would anybody be interested in >> taking over? >> > > Yes, I can take them over. Go ahead and mark them as orphan in the > package database and I'll reassign them to myself. > Done. Thank you so very much. From loupgaroublond at gmail.com Sun Jan 6 20:32:16 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Sun, 6 Jan 2008 15:32:16 -0500 Subject: Init : someone could comment this ? In-Reply-To: <20080106201950.GB5842@redhat.com> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <873ata7veq.fsf@kosh.bigo.ensc.de> <20080106194238.GA5456@jadzia.bu.edu> <20080106201950.GB5842@redhat.com> Message-ID: <7f692fec0801061232j5abaa7c9me27f1f7d0f9aadb0@mail.gmail.com> On Jan 6, 2008 3:19 PM, Daniel P. Berrange wrote: > If you think of a traditional OS install then yum will be common. If you > think of Fedora as a base for creating black box appliances, then yum may > well not be installed at all - whole appliance upgrades are done rather > than individual packages. Likewise if you deploy Fedora in 'stateless' > mode, you're not upgrading packages on individual machines you are instead > generating a new master image. So again yum will not be there. Neither will Haskell, but in building one of these appliance images, you could require Haskell as a build time requirement. Theoretically, you could require a python compiler as well, but I don't know how far those have come along. -Yaakov From wart at kobold.org Sun Jan 6 20:34:34 2008 From: wart at kobold.org (Wart) Date: Sun, 06 Jan 2008 12:34:34 -0800 Subject: taking over blt and tktable In-Reply-To: <47813A7A.8050601@free.fr> References: <4780FF0C.4040500@free.fr> <478130FD.2020609@kobold.org> <47813A7A.8050601@free.fr> Message-ID: <47813B5A.8000009@kobold.org> Jean-Luc Fontaine wrote: > Wart wrote: >> Jean-Luc Fontaine wrote: >> >>> I am very sorry but I no longer have time and resources to care for the >>> blt and tktable (tcl libraries) packages: would anybody be interested in >>> taking over? >>> >> Yes, I can take them over. Go ahead and mark them as orphan in the >> package database and I'll reassign them to myself. >> > Done. Thank you so very much. Looks like you're still listed as the owner of tktable in rawhide. --Wart From a.badger at gmail.com Sun Jan 6 20:48:37 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 06 Jan 2008 12:48:37 -0800 Subject: Init : someone could comment this ? In-Reply-To: <7f692fec0801061232j5abaa7c9me27f1f7d0f9aadb0@mail.gmail.com> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <873ata7veq.fsf@kosh.bigo.ensc.de> <20080106194238.GA5456@jadzia.bu.edu> <20080106201950.GB5842@redhat.com> <7f692fec0801061232j5abaa7c9me27f1f7d0f9aadb0@mail.gmail.com> Message-ID: <47813EA5.3070204@gmail.com> Yaakov Nemoy wrote: > On Jan 6, 2008 3:19 PM, Daniel P. Berrange wrote: >> If you think of a traditional OS install then yum will be common. If you >> think of Fedora as a base for creating black box appliances, then yum may >> well not be installed at all - whole appliance upgrades are done rather >> than individual packages. Likewise if you deploy Fedora in 'stateless' >> mode, you're not upgrading packages on individual machines you are instead >> generating a new master image. So again yum will not be there. > > Neither will Haskell, but in building one of these appliance images, > you could require Haskell as a build time requirement. Theoretically, > you could require a python compiler as well, but I don't know how far > those have come along. > pypy is doing pretty well but we're actually wandering a bit off the point. An appliance may well want to modify the initscripts of the services it starts. If you have to compile those with Haskell or gcc or python then they need to be on the appliance. A stateless box could potentially suffer from the same issue if modifying the initscripts (temporarily) is a desired ability. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From kevin.kofler at chello.at Sun Jan 6 21:32:36 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 6 Jan 2008 21:32:36 +0000 (UTC) Subject: list of failed packages with owners (was: Re: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220) References: <20080103120242.GZ20451@devserv.devel.redhat.com> <477CE62D.7020208@leemhuis.info> <20080106171731.GH2522@free.fr> Message-ID: Patrice Dumas free.fr> writes: > Waiting a bit for kde4 support from upstream, but should certainly > be easily fixed by using kde5libs-devel instead of kdelibs-devel. That would be kdelibs3-devel, not kde5libs-devel. kdelibs3-devel = KDE 3 kdelibs4-devel = KDE 4 kdelibs-devel is either KDE 3 or KDE 4 depending on what version of Fedora you're building for. There is no kdelibs5-devel or kde5libs-devel in Fedora and there won't be one before KDE 5. ;-) Kevin Kofler From kevin.kofler at chello.at Sun Jan 6 21:45:54 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 6 Jan 2008 21:45:54 +0000 (UTC) Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 References: <20080103120242.GZ20451@devserv.devel.redhat.com> <20080106140633.GB2984@ryvius.greysector.net> Message-ID: Dominik 'Rathann' Mierzejewski greysector.net> writes: > What are we supposed to do after getting a failing package to build with > gcc-4.3? Just commit the fix to CVS/devel or tag and build the updated > package, too? If there's going to be a mass rebuild with gcc-4.3, I don't > see any value in building the fixed package until gcc-4.3 hits rawhide, > just wasted mirrors' bandwith. Building the fixed package right now allows doing automated/scripted mass rebuilds, which may well be the method used when GCC 4.3 actually hits Rawhide. It is also useful for the on-the-side mass rebuilds like the one Jakub did. This is Rawhide, I think you really don't have to worry about not pushing rebuilds which aren't absolutely needed. Kevin Kofler From trond.danielsen at gmail.com Sun Jan 6 21:47:35 2008 From: trond.danielsen at gmail.com (Trond Danielsen) Date: Sun, 6 Jan 2008 22:47:35 +0100 Subject: I'm mellllttttttinggg!!! (kernel 2.6.24-0.133.rc6.git8.fc9) In-Reply-To: <200801050855.55227.sgrubb@redhat.com> References: <20080105134627.GA17509@jadzia.bu.edu> <200801050855.55227.sgrubb@redhat.com> Message-ID: <409676c70801061347k5ae3439et90d58a221e8aab30@mail.gmail.com> 2008/1/5, Steve Grubb : > On Saturday 05 January 2008 08:46:27 Matthew Miller wrote: > > This doesn't seem to happen with kernel-2.6.24-0.83.rc5.fc9, which I had > > installed before the break. Oh, it gets hot, but more like 95C?. Processor > > is an AMD Athlon(tm) 64 Processor 3200+ but I'm running in 32-bit mode. > > > > Anyone else seeing this? > > I have a Phenom processor and it reads 40C no matter what. When I had a > Brisbane processor in the same mb, it was correct. Rebooting and going into > the BIOS shows the correct temperature. But > > # cat /proc/acpi/thermal_zone/THRM/temperature > > is dead wrong. Not quite the same problem, but if its not able to get the > temperature right, it may not be doing other power/thermal policy things > right. I see the same thing on my computer (which has an AMD Athlon(tm) 64 X2 Dual Core Processor 3800+), but lm_sensors reports the correct temperature. -- Trond Danielsen From jamatos at fc.up.pt Sun Jan 6 21:37:36 2008 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Sun, 6 Jan 2008 21:37:36 +0000 Subject: Control center idea In-Reply-To: <16de708d0801061204t691796aak635e4dce43be3160@mail.gmail.com> References: <1199374110.5023.2.camel@frosty> <200801062306.43160.ljuwaida@fedoraproject.org> <16de708d0801061204t691796aak635e4dce43be3160@mail.gmail.com> Message-ID: <200801062137.37593.jamatos@fc.up.pt> On Sunday 06 January 2008 20:04:52 Arthur Pemberton wrote: > This is quite nice, what distro is it from? I get this is in rawhide. :-) -- Jos? Ab?lio From pertusus at free.fr Sun Jan 6 22:02:48 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 6 Jan 2008 23:02:48 +0100 Subject: list of failed packages with owners (was: Re: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220) In-Reply-To: References: <20080103120242.GZ20451@devserv.devel.redhat.com> <477CE62D.7020208@leemhuis.info> <20080106171731.GH2522@free.fr> Message-ID: <20080106220247.GA2554@free.fr> On Sun, Jan 06, 2008 at 09:32:36PM +0000, Kevin Kofler wrote: > Patrice Dumas free.fr> writes: > > Waiting a bit for kde4 support from upstream, but should certainly > > be easily fixed by using kde5libs-devel instead of kdelibs-devel. > > That would be kdelibs3-devel, not kde5libs-devel. > > kdelibs3-devel = KDE 3 > kdelibs4-devel = KDE 4 > kdelibs-devel is either KDE 3 or KDE 4 depending on what version of Fedora > you're building for. > There is no kdelibs5-devel or kde5libs-devel in Fedora and there won't be one > before KDE 5. ;-) My finger slipped in the future... -- Pat From paul at all-the-johnsons.co.uk Sun Jan 6 22:41:25 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 06 Jan 2008 22:41:25 +0000 Subject: Ping John Mahowald! Come in John Mahowald Message-ID: <1199659285.3520.10.camel@T7.Linux> ?Hi, Is John still around? I have a package being reviewed by him but he seems to have vanished... TTFN Paul -- Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jmorris at namei.org Sun Jan 6 22:51:08 2008 From: jmorris at namei.org (James Morris) Date: Mon, 7 Jan 2008 09:51:08 +1100 (EST) Subject: Another selinux rant In-Reply-To: <645d17210801041554x527b050g513e9ec3bdd88744@mail.gmail.com> References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <645d17210801041430h7ab76f20qee0df7d1f295d23b@mail.gmail.com> <16de708d0801041447pa2a6486p7a1f7a15de41d867@mail.gmail.com> <645d17210801041457m134eb51er61cdc7aa0610a205@mail.gmail.com> <16de708d0801041503s598b5062ve669643465d29a1@mail.gmail.com> <645d17210801041554x527b050g513e9ec3bdd88744@mail.gmail.com> Message-ID: On Fri, 4 Jan 2008, Jonathan Underwood wrote: > On 04/01/2008, Arthur Pemberton wrote: > > Have you considered the possibility of a large silent majority for > > whom it works most of the time and so need not complain? Not that > > valid complaints are a bad thing. > > > > That could be the case. Perhaps there's something that could be added > to Smolt to allow the history of avc denials to be uploaded as part of > the profile - that would allow some really interesting analysis. Smolt has been collecting this information, but it has not yet been published on the web site (hopefully soon). - James -- James Morris From loupgaroublond at gmail.com Sun Jan 6 23:05:41 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Sun, 6 Jan 2008 18:05:41 -0500 Subject: Another selinux rant In-Reply-To: References: <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <645d17210801041430h7ab76f20qee0df7d1f295d23b@mail.gmail.com> <16de708d0801041447pa2a6486p7a1f7a15de41d867@mail.gmail.com> <645d17210801041457m134eb51er61cdc7aa0610a205@mail.gmail.com> <16de708d0801041503s598b5062ve669643465d29a1@mail.gmail.com> <645d17210801041554x527b050g513e9ec3bdd88744@mail.gmail.com> Message-ID: <7f692fec0801061505wc4bb97k768b20024ced82b5@mail.gmail.com> On Jan 6, 2008 5:51 PM, James Morris wrote: > > That could be the case. Perhaps there's something that could be added > > to Smolt to allow the history of avc denials to be uploaded as part of > > the profile - that would allow some really interesting analysis. > > Smolt has been collecting this information, but it has not yet been > published on the web site (hopefully soon). Smolt doesn't collect that information, and that seems like a bad idea for something for Smolt to collect. Well, if you wanted to make something like kerneloops, but called selinuxoops, then maybe we can link Smolt information together on an opt-in basis. I'm not sure what you would gain by knowing what kind of CPU generated an SELinux error, it would be no different than diagnosing permissions problems remotely. It's all in the software. -Yaakov From dominik at greysector.net Sun Jan 6 23:17:14 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 7 Jan 2008 00:17:14 +0100 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: References: <20080103120242.GZ20451@devserv.devel.redhat.com> <20080106140633.GB2984@ryvius.greysector.net> Message-ID: <20080106231714.GJ2984@ryvius.greysector.net> On Sunday, 06 January 2008 at 22:45, Kevin Kofler wrote: > Dominik 'Rathann' Mierzejewski greysector.net> writes: > > What are we supposed to do after getting a failing package to build with > > gcc-4.3? Just commit the fix to CVS/devel or tag and build the updated > > package, too? If there's going to be a mass rebuild with gcc-4.3, I don't > > see any value in building the fixed package until gcc-4.3 hits rawhide, > > just wasted mirrors' bandwith. > > Building the fixed package right now allows doing automated/scripted mass > rebuilds, which may well be the method used when GCC 4.3 actually hits Rawhide. > It is also useful for the on-the-side mass rebuilds like the one Jakub did. > > This is Rawhide, I think you really don't have to worry about not pushing > rebuilds which aren't absolutely needed. Very well then, I'll keep that in mind in the future. Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From cjdahlin at ncsu.edu Sun Jan 6 23:18:03 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Sun, 06 Jan 2008 18:18:03 -0500 Subject: Control center idea In-Reply-To: <200801062137.37593.jamatos@fc.up.pt> References: <1199374110.5023.2.camel@frosty> <200801062306.43160.ljuwaida@fedoraproject.org> <16de708d0801061204t691796aak635e4dce43be3160@mail.gmail.com> <200801062137.37593.jamatos@fc.up.pt> Message-ID: <478161AB.2040006@ncsu.edu> Jos? Matos wrote: > On Sunday 06 January 2008 20:04:52 Arthur Pemberton wrote: > >> This is quite nice, what distro is it from? >> > > I get this is in rawhide. :-) > > God I love Fedora :D From lesmikesell at gmail.com Sun Jan 6 23:26:22 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sun, 06 Jan 2008 17:26:22 -0600 Subject: Another selinux rant In-Reply-To: References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <645d17210801041430h7ab76f20qee0df7d1f295d23b@mail.gmail.com> <16de708d0801041447pa2a6486p7a1f7a15de41d867@mail.gmail.com> <645d17210801041457m134eb51er61cdc7aa0610a205@mail.gmail.com> <16de708d0801041503s598b5062ve669643465d29a1@mail.gmail.com> <645d17210801041554x527b050g513e9ec3bdd88744@mail.gmail.com> Message-ID: <4781639E.6070708@gmail.com> James Morris wrote: > On Fri, 4 Jan 2008, Jonathan Underwood wrote: > >> On 04/01/2008, Arthur Pemberton wrote: >>> Have you considered the possibility of a large silent majority for >>> whom it works most of the time and so need not complain? Not that >>> valid complaints are a bad thing. >>> >> That could be the case. Perhaps there's something that could be added >> to Smolt to allow the history of avc denials to be uploaded as part of >> the profile - that would allow some really interesting analysis. > > Smolt has been collecting this information, but it has not yet been > published on the web site (hopefully soon). I'd expect these numbers to be overwhelmed by groups that (a) don't run any services that need special handling and (b) run 3rd party apps that aren't integrated in the policy and disable selinux so they work at all. Do you have a way to distinguish these from people running something with a fixable policy issue or account for them if you try to draw conclusions from the reported values? -- Les Mikesell lesmikesell at gmail.com From dominik at greysector.net Sun Jan 6 23:27:11 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 7 Jan 2008 00:27:11 +0100 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080103120242.GZ20451@devserv.devel.redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> Message-ID: <20080106232711.GK2984@ryvius.greysector.net> On Thursday, 03 January 2008 at 13:02, Jakub Jelinek wrote: [...] > fails-even-with-41/openbabel-2.1.1-2.fc9.log Fixed, but still fails to build on ppc64 only. Looks like a gcc bug. Filed as https://bugzilla.redhat.com/show_bug.cgi?id=427700. Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From cjdahlin at ncsu.edu Sun Jan 6 23:46:47 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Sun, 06 Jan 2008 18:46:47 -0500 Subject: Another selinux rant In-Reply-To: <477EB8C9.9030309@gmail.com> References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <645d17210801041430h7ab76f20qee0df7d1f295d23b@mail.gmail.com> <477EB8C9.9030309@gmail.com> Message-ID: <47816867.6090606@ncsu.edu> Andrew Farris wrote: > Jonathan Underwood wrote: >> The problem is: setroubleshoot teaches average users that avc denials >> come about due to bugs in selinux policy. If there was some massive >> security problem right now on my machine causing avc denials I'd >> probably react by filing a stack of bug reports. This is the >> fundamental problem as it stands with SElinux. If it was working, we >> would be in a situation where the first responce to an avc denial is >> "OMG there's a security issue with something running on my machine, I >> must fix that". > > True enough, but that (trusting denials are legitimate breaches) is a > goal that is not necessarily here yet... while there are still bugs > being filed in policy you (or 'average users' such as me and most > rawhide testers) have very little chance of knowing which is which. > > That doesn't mean it is not working... a security problem thats > generating denials is only a problem per se when you go and disable > selinux thinking 'its just a bug I can ignore these and let it happen'. > > As long as a bug is filed, and your machine is still enforcing, and > someone hasn't found a way around the denials, either the policy will > change or Dan is going to post back to that bug report that what is > happening is definitely not going to be allowed by policy. Thats when > you go fishing for your security issue. > Or instead of you going fishing, the bug is recategorized and someone else comes in to work with you on fixing the real problem (since odds are we are packaging whatever it is that does have the issue). > Most people probably just go and disable it, assuming denials were > from something they were trying to do and a bug prevented them from > doing it. I think its very important that rawhide testers be using > selinux though because there is no way to prevent policy bugs from > getting to release (and the broad userbase from then disabling > selinux...) otherwise. > I still tell new linux users to disable selinux when they install. Its just too much to explain to someone who is already in uncomfortable territory. --CJD From cjdahlin at ncsu.edu Sun Jan 6 23:49:33 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Sun, 06 Jan 2008 18:49:33 -0500 Subject: Another selinux rant In-Reply-To: <1199592013.6022.83.camel@beck.corsepiu.local> References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <1199514823.6022.62.camel@beck.corsepiu.local> <16de708d0801042336n2fe73d69o62afe39c1583eb61@mail.gmail.com> <1199592013.6022.83.camel@beck.corsepiu.local> Message-ID: <4781690D.7040802@ncsu.edu> Ralf Corsepius wrote: > On Sat, 2008-01-05 at 01:36 -0600, Arthur Pemberton wrote: > >> On Jan 5, 2008 12:33 AM, Ralf Corsepius wrote: >> >>> On Fri, 2008-01-04 at 12:07 -0500, John Dennis wrote: >>> >>>> Ed Swierk wrote: >>>> >>>>> People who already know about SELinux can of course just learn to type >>>>> ls -l --lcontext, but showing the extra information by default would >>>>> at least give clueless users like me a hint that files have these >>>>> extra attributes that might somehow be relevant to those strange >>>>> openvpn failures. IMHO this would be the single best usability >>>>> improvement to SELinux >>>>> >>>> Re SELinux usability issues: >>>> >>>> We wrote the setroubleshoot package precisely to help SELinux novice >>>> users so they wouldn't suffer with hidden obscure failures of the type >>>> which have frustrated you. If it had been installed you would have >>>> received notifications in real time on your desktop describing the >>>> failure and suggestions on how to fix it. >>>> >>> Well, honorable goal, but does it actually achieve this goal? >>> >>> * On one machine (FC8/x86_64), for me, all setroubleshoot does is to die >>> shortly after bootup and first-time login (I haven't tried to >>> investigate, but as it seems to me some serelated daemon is >>> segfaulting). >>> >> You don't possibly think that this is the regular behaviour of >> setroubleshoot on which you cna judge it? >> > No, I am pretty certain it's an setroubleshoot and/or its infrastructure > bug. > > And have you done with this bug what I'm sure we all know we are supposed to do with bugs we find? :P --CJD From eparis at redhat.com Sun Jan 6 23:54:14 2008 From: eparis at redhat.com (Eric Paris) Date: Sun, 06 Jan 2008 18:54:14 -0500 Subject: Another selinux rant In-Reply-To: <7f692fec0801061505wc4bb97k768b20024ced82b5@mail.gmail.com> References: <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <645d17210801041430h7ab76f20qee0df7d1f295d23b@mail.gmail.com> <16de708d0801041447pa2a6486p7a1f7a15de41d867@mail.gmail.com> <645d17210801041457m134eb51er61cdc7aa0610a205@mail.gmail.com> <16de708d0801041503s598b5062ve669643465d29a1@mail.gmail.com> <645d17210801041554x527b050g513e9ec3bdd88744@mail.gmail.com> <7f692fec0801061505wc4bb97k768b20024ced82b5@mail.gmail.com> Message-ID: <1199663654.3716.125.camel@localhost.localdomain> On Sun, 2008-01-06 at 18:05 -0500, Yaakov Nemoy wrote: > On Jan 6, 2008 5:51 PM, James Morris wrote: > > > That could be the case. Perhaps there's something that could be added > > > to Smolt to allow the history of avc denials to be uploaded as part of > > > the profile - that would allow some really interesting analysis. > > > > Smolt has been collecting this information, but it has not yet been > > published on the web site (hopefully soon). > > Smolt doesn't collect that information, and that seems like a bad idea > for something for Smolt to collect. Well, if you wanted to make > something like kerneloops, but called selinuxoops, then maybe we can > link Smolt information together on an opt-in basis. I'm not sure what > you would gain by knowing what kind of CPU generated an SELinux error, > it would be no different than diagnosing permissions problems > remotely. It's all in the software. I don't know all the details but I do know smolt is collecting the number of users who are leaving selinux turned on vs off. I haven't heard anything about AVC denial counts and stuff like that. Hopefully we will soon have published numbers about how many people are 'happily' running with selinux. -Eric From pemboa at gmail.com Mon Jan 7 00:43:58 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Sun, 6 Jan 2008 18:43:58 -0600 Subject: Control center idea In-Reply-To: <200801062137.37593.jamatos@fc.up.pt> References: <1199374110.5023.2.camel@frosty> <200801062306.43160.ljuwaida@fedoraproject.org> <16de708d0801061204t691796aak635e4dce43be3160@mail.gmail.com> <200801062137.37593.jamatos@fc.up.pt> Message-ID: <16de708d0801061643i357dd2f1r742e443437d561c8@mail.gmail.com> On Jan 6, 2008 3:37 PM, Jos? Matos wrote: > On Sunday 06 January 2008 20:04:52 Arthur Pemberton wrote: > > This is quite nice, what distro is it from? > > I get this is in rawhide. :-) Package name? -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From tibbs at math.uh.edu Mon Jan 7 03:19:27 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 Jan 2008 21:19:27 -0600 Subject: Init : someone could comment this ? In-Reply-To: <4780725E.1010604@ncsu.edu> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <7f692fec0801052129l3aabd5b8t6c1e0c9b7397dea6@mail.gmail.com> <4780725E.1010604@ncsu.edu> Message-ID: >>>>> "CD" == Casey Dahlin writes: CD> On that note, is there a packaging requirement now that any new CD> init scripts must have LSB headers? Not at this time. CD> Should there be? Well, a while back a pile of bugs were filed against everything with an initscript, people set out to fix their packages and found very poor documentation and weird corner cases but not a whole lot of answers to their questions. If that can be avoided, then fine. But just making up rules with nothing to back it up doesn't really work well. Not to mention that since initscripts are interdependent, there's actually an ordering that must be followed when fixing them. For example, if I require an SMTP daemon to be running before I can start, what exactly does my initscript use for Required-Start:? I can't know that until at least sendmail and preferably all of sendmail, exim and postfix are fixed first. - J< From tibbs at math.uh.edu Mon Jan 7 03:31:37 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 Jan 2008 21:31:37 -0600 Subject: Control center idea In-Reply-To: <16de708d0801061643i357dd2f1r742e443437d561c8@mail.gmail.com> References: <1199374110.5023.2.camel@frosty> <200801062306.43160.ljuwaida@fedoraproject.org> <16de708d0801061204t691796aak635e4dce43be3160@mail.gmail.com> <200801062137.37593.jamatos@fc.up.pt> <16de708d0801061643i357dd2f1r742e443437d561c8@mail.gmail.com> Message-ID: >>>>> "AP" == Arthur Pemberton writes: AP> Package name? It looks to me to be the standard KDE4 control center. - J< From cjdahlin at ncsu.edu Mon Jan 7 03:33:09 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Sun, 06 Jan 2008 22:33:09 -0500 Subject: Init : someone could comment this ? In-Reply-To: References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <7f692fec0801052129l3aabd5b8t6c1e0c9b7397dea6@mail.gmail.com> <4780725E.1010604@ncsu.edu> Message-ID: <47819D75.6010904@ncsu.edu> Jason L Tibbitts III wrote: >>>>>> "CD" == Casey Dahlin writes: >>>>>> > > CD> On that note, is there a packaging requirement now that any new > CD> init scripts must have LSB headers? > > Not at this time. > > CD> Should there be? > > Well, a while back a pile of bugs were filed against everything with > an initscript, people set out to fix their packages and found very > poor documentation and weird corner cases but not a whole lot of > answers to their questions. > > If that can be avoided, then fine. But just making up rules with > nothing to back it up doesn't really work well. Not to mention that > since initscripts are interdependent, there's actually an ordering > that must be followed when fixing them. For example, if I require an > SMTP daemon to be running before I can start, what exactly does my > initscript use for Required-Start:? I can't know that until at least > sendmail and preferably all of sendmail, exim and postfix are fixed > first. > > - J< > All very true. For packages providing anonymous services we should probably have a generic provide (such as "$syslog" for the system log, and other such services). This could be standardized before any package changes, allowing the packages to be updated in any order (at the moment the validity of these dependencies doesn't matter much, as the scripts currently shipping with Fedora attest, so if the dependencies are broken because the target service hasn't put the correct provides in place, we can survive). I'm sure there are more questions. There is a wiki page covering the specifics of how Fedora intends to implement these headers: http://fedoraproject.org/wiki/FCNewInit/Initscripts?highlight=%28fcnewinit%29 perhaps we should put effort toward maintaining it and making it unambiguous. I had some questions about the practicality of Required-Stop: myself. Should we really refuse to kill a service based on a dependency? Killing it anyway can't be worse than the angry kill -9 which inevitably follows. From rc040203 at freenet.de Mon Jan 7 03:39:27 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 07 Jan 2008 04:39:27 +0100 Subject: Another selinux rant In-Reply-To: <4781690D.7040802@ncsu.edu> References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <1199514823.6022.62.camel@beck.corsepiu.local> <16de708d0801042336n2fe73d69o62afe39c1583eb61@mail.gmail.com> <1199592013.6022.83.camel@beck.corsepiu.local> <4781690D.7040802@ncsu.edu> Message-ID: <1199677167.6022.102.camel@beck.corsepiu.local> On Sun, 2008-01-06 at 18:49 -0500, Casey Dahlin wrote: > Ralf Corsepius wrote: > > On Sat, 2008-01-05 at 01:36 -0600, Arthur Pemberton wrote: > > > >> On Jan 5, 2008 12:33 AM, Ralf Corsepius wrote: > >> > >>> On Fri, 2008-01-04 at 12:07 -0500, John Dennis wrote: > >>> > >>>> Ed Swierk wrote: > >>>> > >>>>> People who already know about SELinux can of course just learn to type > >>>>> ls -l --lcontext, but showing the extra information by default would > >>>>> at least give clueless users like me a hint that files have these > >>>>> extra attributes that might somehow be relevant to those strange > >>>>> openvpn failures. IMHO this would be the single best usability > >>>>> improvement to SELinux > >>>>> > >>>> Re SELinux usability issues: > >>>> > >>>> We wrote the setroubleshoot package precisely to help SELinux novice > >>>> users so they wouldn't suffer with hidden obscure failures of the type > >>>> which have frustrated you. If it had been installed you would have > >>>> received notifications in real time on your desktop describing the > >>>> failure and suggestions on how to fix it. > >>>> > >>> Well, honorable goal, but does it actually achieve this goal? > >>> > >>> * On one machine (FC8/x86_64), for me, all setroubleshoot does is to die > >>> shortly after bootup and first-time login (I haven't tried to > >>> investigate, but as it seems to me some serelated daemon is > >>> segfaulting). > >>> > >> You don't possibly think that this is the regular behaviour of > >> setroubleshoot on which you cna judge it? > >> > > No, I am pretty certain it's an setroubleshoot and/or its infrastructure > > bug. > > > > > And have you done with this bug what I'm sure we all know we are > supposed to do with bugs we find? :P Done right now. This morning's reboot gave me another opportunity to take a somewhat deeper look ;) https://bugzilla.redhat.com/show_bug.cgi?id=427721 Ralf From cjdahlin at ncsu.edu Mon Jan 7 03:45:16 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Sun, 06 Jan 2008 22:45:16 -0500 Subject: Init : someone could comment this ? In-Reply-To: <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> Message-ID: <4781A04C.2080506@ncsu.edu> Yaakov Nemoy wrote: > On Jan 6, 2008 5:36 AM, Enrico Scholz > wrote: > >> An initsystem which requires depbloat like python or perl is completely >> unacceptably. >> > > Bash is not depbloat, but bash + awk + grep + any other userspace > tools shows alot of dep bloat. Since python is installed on most > machines, and almost always putting at least some code in shared > memory space, asking for Python in particular is not unreasonable. If > Casey had mentioned Common Lisp, I would argue the same thing. > > Since depbloat should be a non-issue in this case, I think we really > need to measure how many kbytes are read on startup, and how long it > takes vs how long running python would take and how many kbytes that > brings in. Of course a hybrid system would take twice as long, so > it's a rather time consuming experiment just to shave a few seconds. > > -Yaakov > > What about busybox? What if we ran all the init scripts under busybox? Its a shell-type environment, its world-famous for being incredibly tiny, it could meet everything. From rdieter at math.unl.edu Mon Jan 7 03:47:30 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 06 Jan 2008 21:47:30 -0600 Subject: xsettings-kde (WAS: Getting GNOME settings applied for GNOME apps in KDE sessions) References: <200712301248.31541.ville.skytta@iki.fi> <1199062957.4326.2.camel@localhost.localdomain> Message-ID: Rex Dieter wrote: > fyi, xsettings-kde is now packaged and in the kde-redhat/testing repo, at > least until it is properly reviewed and in fedora. xsettings-kde review: http://bugzilla.redhat.com/427722 -- Rex From pemboa at gmail.com Mon Jan 7 04:00:50 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Sun, 6 Jan 2008 22:00:50 -0600 Subject: Control center idea In-Reply-To: References: <1199374110.5023.2.camel@frosty> <200801062306.43160.ljuwaida@fedoraproject.org> <16de708d0801061204t691796aak635e4dce43be3160@mail.gmail.com> <200801062137.37593.jamatos@fc.up.pt> <16de708d0801061643i357dd2f1r742e443437d561c8@mail.gmail.com> Message-ID: <16de708d0801062000u4c6c1643j261d66a11a8f31c0@mail.gmail.com> On 06 Jan 2008 21:31:37 -0600, Jason L Tibbitts III wrote: > >>>>> "AP" == Arthur Pemberton writes: > > AP> Package name? > > It looks to me to be the standard KDE4 control center. Ah. It seems modeled at MacOS X -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From braden at endoframe.com Mon Jan 7 05:15:08 2008 From: braden at endoframe.com (Braden McDaniel) Date: Mon, 07 Jan 2008 00:15:08 -0500 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080103120242.GZ20451@devserv.devel.redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> Message-ID: <1199682908.5278.135.camel@hinge.endoframe.net> On Thu, 2008-01-03 at 07:02 -0500, Jakub Jelinek wrote: > Hi! > > I've rebuilt 5118 rawhide-20071220 src.rpms on x86_64 in mock buildroots which > contained rawhide-20071220 except {gcc,lib}*-4.1.2-36.*.rpm, with additional > gcc-4.3.0-0.4 (available from koji, dist-f9-gcc43 component), > compat-libgfortran-41 (available from > http://people.redhat.com/jakub/gcc/compat-libgfortran-41-4.1.2-36.src.rpm ) > and later on also with gettext subpackages just rebuilt with gcc-4.3.0-0.4. > > Out of those 5118 src.rpms 1054 were failed builds. For those that failed > to build, I have retried with stock rawhide-20071220 mock buildroots (i.e. > gcc-4.1.2-36). 547 failed builds failed even with 4.1.2-36 (this count > includes even ExclusiveArched rpms etc.), logs for those are at > http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/fails-even-with-41/ > and generally don't interest me, as this is not a regression introduced by > 4.3.0-0.4. > > The remaining 507 failures only fail with gcc-4.3.0-0.4 and not with > gcc-4.1.2-36, though most of them are just C++ being stricter, something > that ought to be fixed in the packages. > > I've tried to quickly grep through the failed logs and categorize them: [snip] > header-dep/openvrml-0.17.0-2.fc9.log I see two problems here. First: libopenvrml-gl/openvrml/gl/viewer.cpp:1984: error: '' has incomplete type libopenvrml-gl/openvrml/gl/viewer.cpp:1984: error: invalid use of 'GLvoid' This one should be fixed by 0.17.1-1, which I've just pushed to testing. Second: In file included from /usr/include/boost/spirit/attribute/closure.hpp:24, from /usr/include/boost/spirit/attribute.hpp:36, from /usr/include/boost/spirit.hpp:70, from ../src/libopenvrml/private.h:26, from libopenvrml/openvrml/viewer.cpp:32: /usr/include/boost/spirit/phoenix/operators.hpp:355: error: 'INT_MAX' was not declared in this scope This one is a problem with boost. -- Braden McDaniel e-mail: Jabber: From kevin.kofler at chello.at Mon Jan 7 05:35:33 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 7 Jan 2008 05:35:33 +0000 (UTC) Subject: Init : someone could comment this ? References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> Message-ID: Casey Dahlin ncsu.edu> writes: > What about busybox? What if we ran all the init scripts under busybox? > Its a shell-type environment, its world-famous for being incredibly > tiny, it could meet everything. AFAIK, busybox still forks whereever a regular POSIX shell forks, so if the amount of forks is the problem, AFAICT busybox will resolve absolutely nothing. A shell which emulates POSIX process handling in-process and uses direct builtin function calls for commands like sed rather than forking a new process (even a new process of itself as busybox appears to be doing) could work, but would that be maintainable? And what about parallelism: threads? Pipes and the like would also have to be emulated by special-case code to become as efficient as a real programming language, which would drive maintainability even further down (imagine having to implement memory-to-memory, memory-to-file, file-to-memory and file-to-file versions of all tools like sed, grep etc.). Kevin Kofler From cjdahlin at ncsu.edu Mon Jan 7 05:53:56 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Mon, 07 Jan 2008 00:53:56 -0500 Subject: Init : someone could comment this ? In-Reply-To: References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> Message-ID: <4781BE74.6070702@ncsu.edu> Kevin Kofler wrote: > Casey Dahlin ncsu.edu> writes: > >> What about busybox? What if we ran all the init scripts under busybox? >> Its a shell-type environment, its world-famous for being incredibly >> tiny, it could meet everything. >> > > AFAIK, busybox still forks whereever a regular POSIX shell forks, so if the > amount of forks is the problem, AFAICT busybox will resolve absolutely nothing. > > A shell which emulates POSIX process handling in-process and uses direct > builtin function calls for commands like sed rather than forking a new process > (even a new process of itself as busybox appears to be doing) could work, but > would that be maintainable? And what about parallelism: threads? Pipes and the > like would also have to be emulated by special-case code to become as efficient > as a real programming language, which would drive maintainability even further > down (imagine having to implement memory-to-memory, memory-to-file, > file-to-memory and file-to-file versions of all tools like sed, grep etc.). > > Kevin Kofler > > I'm not certain that the fork is the issue so much as the subsequent execve. Its disk IO we're looking to reduce, and having all the commands in one process image that is loaded at script start helps a lot. --CJD From enrico.scholz at informatik.tu-chemnitz.de Mon Jan 7 07:45:31 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 07 Jan 2008 08:45:31 +0100 Subject: Init : someone could comment this ? In-Reply-To: (Kevin Kofler's message of "Mon, 7 Jan 2008 05:35:33 +0000 (UTC)") References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> Message-ID: <87prwe5bac.fsf@kosh.bigo.ensc.de> Kevin Kofler writes: > A shell which emulates POSIX process handling in-process and uses > direct builtin function calls for commands like sed [...] Pipes and > the like would also have to be emulated For what do you need 'sed' or pipes to start/stop a daemon? Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From cjdahlin at ncsu.edu Mon Jan 7 08:14:39 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Mon, 07 Jan 2008 03:14:39 -0500 Subject: Init : someone could comment this ? In-Reply-To: <87prwe5bac.fsf@kosh.bigo.ensc.de> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> <87prwe5bac.fsf@kosh.bigo.ensc.de> Message-ID: <4781DF6F.9090005@ncsu.edu> Enrico Scholz wrote: > Kevin Kofler writes: > > >> A shell which emulates POSIX process handling in-process and uses >> direct builtin function calls for commands like sed [...] Pipes and >> the like would also have to be emulated >> > > For what do you need 'sed' or pipes to start/stop a daemon? > > > > Enrico > It appears at least 13 times in our current init system. From cocobear.cn at gmail.com Mon Jan 7 05:34:07 2008 From: cocobear.cn at gmail.com (cocobear) Date: Mon, 7 Jan 2008 13:34:07 +0800 Subject: Pulse Audio problem In-Reply-To: <1199639201.21972.47.camel@localhost.localdomain> References: <93d66b780801051706s5c9e41b4mb5ba48accc2e56b6@mail.gmail.com> <1199585527.21972.42.camel@localhost.localdomain> <20080106212821.44ce06ea@cocobear> <1199639201.21972.47.camel@localhost.localdomain> Message-ID: <20080107133407.5e6e7340@cocobear> ? Sun, 06 Jan 2008 18:06:41 +0100 Lubomir Kundrak ??: > > On Sun, 2008-01-06 at 21:28 +0800, cocobear wrote: > > ? Sun, 06 Jan 2008 03:12:07 +0100 > > Lubomir Kundrak ??: > > > > > > > > On Sat, 2008-01-05 at 20:06 -0500, masch wrote: > > > > HI! > > > > Sometimes when I open the PulseAudio Volume Control said: > > > > Connection failed: Connection refused, and the sound in some > > > > applications doesn't work. > > > > Does anyone know how to fix this? > > > > > > > It seemed that it happens on F8 often. > > This is really not very valuable information. Would you mind helping > to fix the situation? Did you report it to bugzilla? Do you care to > respond with the information asked for below? > > > > > > > > File a bugzilla ticket. > > > > > > Your pulseaudio daemon obviously died. Please add output of "grep > > > pulseaudio /var/log/messages" to the bugzilla ticket. > > > here is the output of pulseaudio: Dec 3 13:20:32 cocobear pulseaudio[9727]: pid.c: Stale PID file, overwriting. Dec 3 18:16:33 cocobear pulseaudio[2057]: pid.c: Stale PID file, overwriting. Dec 3 20:09:24 cocobear pulseaudio[11474]: pid.c: Stale PID file, overwriting. Dec 3 21:49:29 cocobear pulseaudio[2063]: pid.c: Stale PID file, overwriting. Dec 3 21:49:30 cocobear pulseaudio[2063]: module-alsa-sink.c: Error opening PCM device hw:0: ?????? Dec 3 21:49:30 cocobear pulseaudio[2063]: module.c: Failed to load module "module-alsa-sink" (argument: "device=hw:0 sink_name=alsa_output.pci_1013_6003_alsa_playback_0"): initialization failed. Dec 3 21:49:30 cocobear pulseaudio[2063]: module-alsa-source.c: Error opening PCM device hw:0: ?????? Dec 3 21:49:30 cocobear pulseaudio[2063]: module.c: Failed to load module "module-alsa-source" (argument: "device=hw:0 source_name=alsa_input.pci_1013_6003_alsa_capture_0"): initialization failed. Dec 3 23:35:27 cocobear pulseaudio[2063]: module-volume-restore.c: failed to open file '(null)': ????????? Dec 4 11:22:01 cocobear pulseaudio[3668]: pid.c: Stale PID file, overwriting. Dec 4 15:35:04 cocobear pulseaudio[2649]: pid.c: Stale PID file, overwriting. Dec 4 17:11:07 cocobear pulseaudio[2649]: module-volume-restore.c: failed to open file '(null)': ????????? Dec 4 17:40:01 cocobear pulseaudio[2354]: pid.c: Stale PID file, overwriting. Dec 4 23:52:17 cocobear pulseaudio[2354]: module-volume-restore.c: failed to open file '(null)': ????????? Dec 5 23:45:46 cocobear pulseaudio[2015]: module-volume-restore.c: failed to open file '(null)': ????????? Dec 6 19:56:15 cocobear pulseaudio[2017]: pid.c: Stale PID file, overwriting. Dec 6 20:30:29 cocobear pulseaudio[2907]: pid.c: Stale PID file, overwriting. Dec 7 00:24:50 cocobear pulseaudio[2907]: module-volume-restore.c: failed to open file '(null)': ????????? Dec 7 09:39:31 cocobear pulseaudio[2020]: module-volume-restore.c: failed to open file '(null)': ????????? Dec 7 13:08:49 cocobear pulseaudio[2667]: pid.c: Stale PID file, overwriting. Dec 7 13:10:36 cocobear pulseaudio[3025]: pid.c: Stale PID file, overwriting. Dec 7 14:07:20 cocobear pulseaudio[3025]: module-volume-restore.c: failed to open file '(null)': ????????? Dec 8 23:29:58 cocobear pulseaudio[2018]: pid.c: Daemon already running. Dec 8 23:29:58 cocobear pulseaudio[2018]: main.c: pa_pid_file_create() failed. Dec 8 23:34:59 cocobear pulseaudio[2000]: pid.c: Stale PID file, overwriting. Dec 9 00:00:15 cocobear pulseaudio[2000]: module-volume-restore.c: failed to open file '(null)': ????????? Dec 9 23:44:40 cocobear pulseaudio[2011]: module-volume-restore.c: failed to open file '(null)': ????????? Dec 11 23:44:11 cocobear pulseaudio[2020]: module-volume-restore.c: failed to open file '(null)': ????????? Dec 13 23:44:08 cocobear pulseaudio[1935]: module-volume-restore.c: failed to open file '(null)': ????????? Dec 19 20:46:57 cocobear pulseaudio[2338]: pid.c: Daemon already running. Dec 19 20:46:57 cocobear pulseaudio[2338]: main.c: pa_pid_file_create() failed. Dec 20 12:27:25 cocobear pulseaudio[1946]: pid.c: Daemon already running. Dec 20 12:27:25 cocobear pulseaudio[1946]: main.c: pa_pid_file_create() failed. Dec 21 12:31:58 cocobear pulseaudio[1947]: pid.c: Stale PID file, overwriting. Dec 21 14:06:57 cocobear pulseaudio[1947]: module-volume-restore.c: failed to open file '(null)': ????????? Dec 21 23:55:08 cocobear pulseaudio[1952]: module-volume-restore.c: failed to open file '(null)': ????????? Dec 23 14:20:16 cocobear pulseaudio[1947]: module-volume-restore.c: failed to open file '(null)': ????????? Dec 24 23:53:50 cocobear pulseaudio[1940]: module-volume-restore.c: failed to open file '(null)': ????????? Dec 27 15:20:06 cocobear pulseaudio[1940]: module-volume-restore.c: failed to open file '(null)': ????????? Dec 27 23:24:40 cocobear pulseaudio[1945]: module-volume-restore.c: failed to open file '(null)': ????????? Dec 28 13:20:07 cocobear pulseaudio[1958]: module-volume-restore.c: failed to open file '(null)': ????????? Dec 30 00:02:42 cocobear pulseaudio[1958]: module-volume-restore.c: failed to open file '(null)': ????????? Dec 31 17:58:45 cocobear pulseaudio[1957]: module-volume-restore.c: failed to open file '(null)': ????????? Dec 31 22:38:28 cocobear pulseaudio[1974]: pid.c: Daemon already running. Dec 31 22:38:28 cocobear pulseaudio[1974]: main.c: pa_pid_file_create() failed. Jan 1 10:22:53 cocobear pulseaudio[1982]: pid.c: Stale PID file, overwriting. Jan 1 16:01:38 cocobear pulseaudio[1982]: module-volume-restore.c: failed to open file '(null)': ????????? Jan 3 00:12:27 cocobear pulseaudio[1984]: module-volume-restore.c: failed to open file '(null)': ????????? Jan 3 11:58:21 cocobear pulseaudio[1988]: module-volume-restore.c: failed to open file '(null)': ????????? Jan 3 20:09:49 cocobear pulseaudio[2293]: pid.c: Stale PID file, overwriting. Jan 3 23:32:42 cocobear pulseaudio[2293]: module-volume-restore.c: failed to open file '(null)': ????????? Jan 4 09:50:10 cocobear pulseaudio[4151]: pid.c: Stale PID file, overwriting. Jan 4 11:46:52 cocobear pulseaudio[1978]: pid.c: Stale PID file, overwriting. Jan 5 19:29:57 cocobear pulseaudio[1956]: module-alsa-sink.c: Error opening PCM device hw:0: ?????? Jan 5 19:29:57 cocobear pulseaudio[1956]: module.c: Failed to load module "module-alsa-sink" (argument: "device=hw:0 sink_name=alsa_output.pci_1013_6003_alsa_playback_0"): initialization failed. Jan 5 19:29:57 cocobear pulseaudio[1956]: module-alsa-source.c: Error opening PCM device hw:0: ?????? Jan 5 19:29:57 cocobear pulseaudio[1956]: module.c: Failed to load module "module-alsa-source" (argument: "device=hw:0 source_name=alsa_input.pci_1013_6003_alsa_capture_0"): initialization failed. Jan 5 19:37:06 cocobear pulseaudio[1975]: pid.c: Stale PID file, overwriting. Jan 5 20:06:30 cocobear pulseaudio[1980]: pid.c: Stale PID file, overwriting. Jan 6 00:08:44 cocobear pulseaudio[1980]: module-volume-restore.c: failed to open file '(null)': ????????? Jan 6 23:35:53 cocobear pulseaudio[2038]: module-volume-restore.c: failed to open file '(null)': ????????? Jan 8 13:27:58 cocobear pulseaudio[4795]: pid.c: Stale PID file, overwriting. From jamatos at fc.up.pt Mon Jan 7 08:34:56 2008 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Mon, 7 Jan 2008 08:34:56 +0000 Subject: Control center idea In-Reply-To: <16de708d0801061643i357dd2f1r742e443437d561c8@mail.gmail.com> References: <1199374110.5023.2.camel@frosty> <200801062137.37593.jamatos@fc.up.pt> <16de708d0801061643i357dd2f1r742e443437d561c8@mail.gmail.com> Message-ID: <200801070834.56574.jamatos@fc.up.pt> On Monday 07 January 2008 00:43:58 Arthur Pemberton wrote: > On Jan 6, 2008 3:37 PM, Jos? Matos wrote: > > On Sunday 06 January 2008 20:04:52 Arthur Pemberton wrote: > > > This is quite nice, what distro is it from? > > > > I get this is in rawhide. :-) > > Package name? $ rpm -qf /usr/bin/systemsettings kdebase-workspace-3.97.0-5.fc9 > -- > Fedora 7 : sipping some of that moonshine > ( www.pembo13.com ) -- Jos? Ab?lio From nicolas.mailhot at laposte.net Mon Jan 7 09:28:24 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 7 Jan 2008 10:28:24 +0100 (CET) Subject: Request for remove a package from rawhide In-Reply-To: <47812628.1020807@redhat.com> References: <668bb39a0801060913g7da50934qdac27c9e95485dee@mail.gmail.com> <47810DE6.4000003@redhat.com> <668bb39a0801060926j3be3009cxa7a25a0833f1e211@mail.gmail.com> <20080106133313.2c1c0403@redhat.com> <47812628.1020807@redhat.com> Message-ID: <35939.192.54.193.53.1199698104.squirrel@rousalka.dyndns.org> Le Dim 6 janvier 2008 20:04, Christopher Aillon a ?crit : > On 01/06/2008 07:33 PM, Jesse Keating wrote: >> On Sun, 6 Jan 2008 18:26:33 +0100 >> "Micha? Bentkowski" wrote: >> >>> It seems openarena has been untagged successfully. >>> Christopher, thanks for advice! >> >> Hrm. Some time ago we had agreed to not fix things by making builds >> disappear, even in rawhide. NVRs must always go up. Since doing >> this >> means anybody who happened to upgrade to your bad build, there is no >> way for them to get a fixed build unless they download the package >> manually and use a cryptic rpm call. The proper procedure would >> have >> been to back out the changes and bump the build so that there is an >> upgrade path. > > Even if he'd *just* built it into rawhide and it wouldn't have been in > a > compose yet? Someone would have had to grab it out of koji and use an > rpm call to install it. Which happens all the time. Please consider that except for scratch builds, anything done in koji will end up on unsuspecting tester systems Regards, -- Nicolas Mailhot From kevin.kofler at chello.at Mon Jan 7 09:43:09 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 7 Jan 2008 09:43:09 +0000 (UTC) Subject: Request for remove a package from rawhide References: <668bb39a0801060913g7da50934qdac27c9e95485dee@mail.gmail.com> <47810DE6.4000003@redhat.com> <668bb39a0801060926j3be3009cxa7a25a0833f1e211@mail.gmail.com> <20080106133313.2c1c0403@redhat.com> <47812628.1020807@redhat.com> <35939.192.54.193.53.1199698104.squirrel@rousalka.dyndns.org> Message-ID: Nicolas Mailhot laposte.net> writes: > Which happens all the time. Please consider that except for scratch > builds, anything done in koji will end up on unsuspecting tester > systems But if you fetch things from Koji yourself, you're responsible for the mess you're causing. I fetch things from Koji sometimes (dist-f8-updates-candidate normally, I'm not running Rawhide), but never without a reason and I can deal with reverting to the latest official update when needed. Kevin Kofler From enrico.scholz at informatik.tu-chemnitz.de Mon Jan 7 09:44:31 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 07 Jan 2008 10:44:31 +0100 Subject: Init : someone could comment this ? In-Reply-To: <4781DF6F.9090005@ncsu.edu> (Casey Dahlin's message of "Mon, 07 Jan 2008 03:14:39 -0500") References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> Message-ID: <878x32q8ao.fsf@fc5.bigo.ensc.de> Casey Dahlin writes: >>> A shell which emulates POSIX process handling in-process and uses >>> direct builtin function calls for commands like sed [...] Pipes and >>> the like would also have to be emulated >> >> For what do you need 'sed' or pipes to start/stop a daemon? >> > It appears at least 13 times in our current init system. I think, nobody doubts that current initsystem is the worst one of the major linux distributions. By changing paradigm from forking to non-forking daemon you can avoid all the complicated 'stop' code; e.g. 'start' will be | pid = fork(); | if (pid==0) { /* ... */ execve(...); } and 'stop' be | kill(pid, SIGTERM); /* wait for timeout/sigchld */ kill(pid, SIGKILL); But python or other bloaty scripting languages are not a solution and completely unacceptable at this place. Enrico From nicolas.mailhot at laposte.net Mon Jan 7 10:07:07 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 7 Jan 2008 11:07:07 +0100 (CET) Subject: Request for remove a package from rawhide In-Reply-To: References: <668bb39a0801060913g7da50934qdac27c9e95485dee@mail.gmail.com> <47810DE6.4000003@redhat.com> <668bb39a0801060926j3be3009cxa7a25a0833f1e211@mail.gmail.com> <20080106133313.2c1c0403@redhat.com> <47812628.1020807@redhat.com> <35939.192.54.193.53.1199698104.squirrel@rousalka.dyndns.org> Message-ID: <21919.192.54.193.53.1199700427.squirrel@rousalka.dyndns.org> Le Lun 7 janvier 2008 10:43, Kevin Kofler a ?crit : > Nicolas Mailhot laposte.net> writes: >> Which happens all the time. Please consider that except for scratch >> builds, anything done in koji will end up on unsuspecting tester >> systems > > But if you fetch things from Koji yourself, you're responsible for the > mess you're causing. The question is not "how can I lay the blame on someone" the question is "how can I build trust in our devel publishing system so we get more testers and hopefully identify problems before final releases". Koji is public. You can't safely doctor koji history anymore than you can doctor a public VCS. If you want to test stuff privately you have scratch builds. Otherwise fixing a bad build is just a version bump away. Blaming testers for doing badly needed testing work, and making their life harder, is not helpful. -- Nicolas Mailhot From kevin.kofler at chello.at Mon Jan 7 10:27:50 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 7 Jan 2008 10:27:50 +0000 (UTC) Subject: Request for remove a package from rawhide References: <668bb39a0801060913g7da50934qdac27c9e95485dee@mail.gmail.com> <47810DE6.4000003@redhat.com> <668bb39a0801060926j3be3009cxa7a25a0833f1e211@mail.gmail.com> <20080106133313.2c1c0403@redhat.com> <47812628.1020807@redhat.com> <35939.192.54.193.53.1199698104.squirrel@rousalka.dyndns.org> <21919.192.54.193.53.1199700427.squirrel@rousalka.dyndns.org> Message-ID: Nicolas Mailhot laposte.net> writes: > Koji is public. You can't safely doctor koji history anymore than you > can doctor a public VCS. If you want to test stuff privately you have > scratch builds. Otherwise fixing a bad build is just a version bump > away. Oh, there's a lot of doctoring which can be done. My personal favorite is "make force-tag". :-) If you screw up and the build fails, commit the fix, make force-tag, then resubmit the build in Koji and most traces of the botched build will vanish. ;-) (There'll be a hidden task somewhere in Koji and an untagged CVS commit and that's all.) Kevin Kofler From nicolas.mailhot at laposte.net Mon Jan 7 10:32:07 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 7 Jan 2008 11:32:07 +0100 (CET) Subject: Request for remove a package from rawhide In-Reply-To: References: <668bb39a0801060913g7da50934qdac27c9e95485dee@mail.gmail.com> <47810DE6.4000003@redhat.com> <668bb39a0801060926j3be3009cxa7a25a0833f1e211@mail.gmail.com> <20080106133313.2c1c0403@redhat.com> <47812628.1020807@redhat.com> <35939.192.54.193.53.1199698104.squirrel@rousalka.dyndns.org> <21919.192.54.193.53.1199700427.squirrel@rousalka.dyndns.org> Message-ID: <60289.192.54.193.53.1199701927.squirrel@rousalka.dyndns.org> Le Lun 7 janvier 2008 11:27, Kevin Kofler a ?crit : > Nicolas Mailhot laposte.net> writes: >> Koji is public. You can't safely doctor koji history anymore than >> you >> can doctor a public VCS. If you want to test stuff privately you >> have >> scratch builds. Otherwise fixing a bad build is just a version bump >> away. > > Oh, there's a lot of doctoring which can be done. My personal favorite > is "make force-tag". :-) If you screw up and the build fails, This is ugly but safe since no build was exposed to users, unlike the present case. -- Nicolas Mailhot From mmaslano at redhat.com Mon Jan 7 10:42:10 2008 From: mmaslano at redhat.com (Marcela Maslanova) Date: Mon, 07 Jan 2008 11:42:10 +0100 Subject: New tcl-8.5 and 8Kingdoms In-Reply-To: <4780F505.70702@hhs.nl> References: <477D5C7F.6050708@hhs.nl> <477D5C87.2010106@kobold.org> <477D5E86.2030004@hhs.nl> <47808AE8.7090702@kobold.org> <4780F505.70702@hhs.nl> Message-ID: <47820202.3020300@redhat.com> I've rebuilt tcl without stack checking. Please try rebuild 8Kingdoms. From nphilipp at redhat.com Mon Jan 7 10:42:58 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 07 Jan 2008 11:42:58 +0100 Subject: Init : someone could comment this ? In-Reply-To: <878x32q8ao.fsf@fc5.bigo.ensc.de> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> Message-ID: <1199702578.5761.36.camel@wombat.tiptoe.de> On Mon, 2008-01-07 at 10:44 +0100, Enrico Scholz wrote: > Casey Dahlin writes: > > >>> A shell which emulates POSIX process handling in-process and uses > >>> direct builtin function calls for commands like sed [...] Pipes and > >>> the like would also have to be emulated > >> > >> For what do you need 'sed' or pipes to start/stop a daemon? > >> > > It appears at least 13 times in our current init system. > > I think, nobody doubts that current initsystem is the worst one of > the major linux distributions. Can the hyperbole please -- we know what we have otherwise we wouldn't be having this discussion. > By changing paradigm from forking to > non-forking daemon you can avoid all the complicated 'stop' code; > e.g. 'start' will be > > | pid = fork(); > | if (pid==0) { /* ... */ execve(...); } > > and 'stop' be > > | kill(pid, SIGTERM); /* wait for timeout/sigchld */ kill(pid, SIGKILL); That'd be all fine and dandy for daemons that simply need to be started without any variable options or preparations and are obliging enough to write pid files. I don't think that e.g. the postgresql or xendomains start scripts would fit well into that scheme. > But python or other bloaty scripting languages are not a solution and > completely unacceptable at this place. "Bloaty" is something that could be solved, don't you think? If python was split up in a base package that contained the directory structure, the binaries, the (small) documentation and only basic modules (with no additional requirements) and a package containing the rest of the modules, much of the (dep-)bloat wouldn't be an issue if init scripts (ehh modules) would be limited to that basic set. With the set of modules I would choose, such a python-base package would have less dependencies than bash and only account for roughly 2.6MB on the disk as well -- bash takes up about 5.1MB. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From lkundrak at redhat.com Mon Jan 7 10:50:02 2008 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Mon, 07 Jan 2008 11:50:02 +0100 Subject: Pulse Audio problem In-Reply-To: <20080107133407.5e6e7340@cocobear> References: <93d66b780801051706s5c9e41b4mb5ba48accc2e56b6@mail.gmail.com> <1199585527.21972.42.camel@localhost.localdomain> <20080106212821.44ce06ea@cocobear> <1199639201.21972.47.camel@localhost.localdomain> <20080107133407.5e6e7340@cocobear> Message-ID: <1199703002.21972.55.camel@localhost.localdomain> On Mon, 2008-01-07 at 13:34 +0800, cocobear wrote: > ? Sun, 06 Jan 2008 18:06:41 +0100 > Lubomir Kundrak ??: > > > > > On Sun, 2008-01-06 at 21:28 +0800, cocobear wrote: > > > ? Sun, 06 Jan 2008 03:12:07 +0100 > > > Lubomir Kundrak ??: > > > > > > > > > > > On Sat, 2008-01-05 at 20:06 -0500, masch wrote: > > > > > HI! > > > > > Sometimes when I open the PulseAudio Volume Control said: > > > > > Connection failed: Connection refused, and the sound in some > > > > > applications doesn't work. > > > > > Does anyone know how to fix this? > > > > > > > > > > It seemed that it happens on F8 often. > > > > This is really not very valuable information. Would you mind helping > > to fix the situation? Did you report it to bugzilla? Do you care to > > respond with the information asked for below? > > > > > > > > > > > > File a bugzilla ticket. > > > > > > > > Your pulseaudio daemon obviously died. Please add output of "grep > > > > pulseaudio /var/log/messages" to the bugzilla ticket. > > > > > > here is the output of pulseaudio: ... > Jan 5 19:29:57 cocobear > pulseaudio[1956]: module-alsa-sink.c: Error opening PCM device hw:0: > ?????? Jan 5 19:29:57 cocobear pulseaudio[1956]: module.c: > Failed to load module "module-alsa-sink" (argument: "device=hw:0 > sink_name=alsa_output.pci_1013_6003_alsa_playback_0"): initialization > failed. Jan 5 19:29:57 cocobear pulseaudio[1956]: > module-alsa-source.c: Error opening PCM device hw:0: ?????? Jan > 5 19:29:57 cocobear pulseaudio[1956]: module.c: Failed to load module > "module-alsa-source" (argument: "device=hw:0 > source_name=alsa_input.pci_1013_6003_alsa_capture_0"): initialization > failed. Jan 5 19:37:06 cocobear pulseaudio[1975]: pid.c: Stale PID > file, overwriting. Jan 5 20:06:30 cocobear pulseaudio[1980]: pid.c: > Stale PID file, overwriting. Jan 6 00:08:44 cocobear pulseaudio[1980]: > module-volume-restore.c: failed to open file '(null)': > ????????? Jan 6 23:35:53 cocobear pulseaudio[2038]: > module-volume-restore.c: failed to open file '(null)': > ????????? Jan 8 13:27:58 cocobear pulseaudio[4795]: pid.c: > Stale PID file, overwriting. /===============================\ *** === >>> Open a Bugzilla ticket Pleeease <<< === *** \===============================/ Do _not_ use a maigling list for this. :) And when you do so, please include output of the following commands in the bug report: ls -l /dev/snd/* rpm -q kernel Thanks, -- Lubomir Kundrak (Red Hat Security Response Team) From alexl at users.sourceforge.net Mon Jan 7 11:12:55 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Mon, 07 Jan 2008 04:12:55 -0700 Subject: howto package openoffice.org extensions In-Reply-To: <477E84B9.1080105@fedoraproject.org> (Rahul Sundaram's message of "Sat\, 05 Jan 2008 00\:40\:49 +0530") References: <1199451768.7355.201.camel@Jehannum> <604aa7910801041006r3cacf550i149948f4e5bbf64a@mail.gmail.com> <1199474169.7355.264.camel@Jehannum> <477E84B9.1080105@fedoraproject.org> Message-ID: On Jan 4, 2008 4:02 AM, Caolan McNamara wrote: [...] >> http://fedoraproject.org/wiki/OpenOffice.org >>>> to document the best recipe for installing and deinstalling >>>> openoffice.org extensions [...] >>>>> "RS" == Rahul Sundaram writes: RS> Packaging Committee has instructions on changing the guidelines. RS> http://fedoraproject.org/wiki/Packaging/Committee Caolan, do you have any best practices recommendations for the naming of the openoffice.org extensions? It would be nice to add them to the guidelines (then perhaps submit them to the packaging committee) e.g., I'd like to package ooolatex: http://ooolatex.sourceforge.net/ and so should the package should (following the emacs-, python-, perl-, R- convention) be called "openoffice.org-latex"? or should be called "openoffice.org-ooolatex", or just "ooolatex"? Also, will this particular extension, which is packaged as an .oxt file, be able to be installed using the unopkg tool as suggested on that page? i.e. are .oxt files intended to be installed using the unopkg tool? Any suggestions welcomed. Alex From cocobear.cn at gmail.com Mon Jan 7 11:31:37 2008 From: cocobear.cn at gmail.com (cocobear) Date: Mon, 7 Jan 2008 19:31:37 +0800 Subject: Pulse Audio problem In-Reply-To: <1199703002.21972.55.camel@localhost.localdomain> References: <93d66b780801051706s5c9e41b4mb5ba48accc2e56b6@mail.gmail.com> <1199585527.21972.42.camel@localhost.localdomain> <20080106212821.44ce06ea@cocobear> <1199639201.21972.47.camel@localhost.localdomain> <20080107133407.5e6e7340@cocobear> <1199703002.21972.55.camel@localhost.localdomain> Message-ID: <20080107193137.4f2c4229@cocobear> ? Mon, 07 Jan 2008 11:50:02 +0100 Lubomir Kundrak ??: > > On Mon, 2008-01-07 at 13:34 +0800, cocobear wrote: > > ? Sun, 06 Jan 2008 18:06:41 +0100 > > Lubomir Kundrak ??: > > > > > > > > On Sun, 2008-01-06 at 21:28 +0800, cocobear wrote: > > > > ? Sun, 06 Jan 2008 03:12:07 +0100 > > > > Lubomir Kundrak ??: > > > > > > > > > > > > > > On Sat, 2008-01-05 at 20:06 -0500, masch wrote: > > > > > > HI! > > > > > > Sometimes when I open the PulseAudio Volume Control said: > > > > > > Connection failed: Connection refused, and the sound in > > > > > > some applications doesn't work. > > > > > > Does anyone know how to fix this? > > > > > > > > > > > > > It seemed that it happens on F8 often. > > > > > > This is really not very valuable information. Would you mind > > > helping to fix the situation? Did you report it to bugzilla? Do > > > you care to respond with the information asked for below? > > > > > > > > > > > > > > > > File a bugzilla ticket. > > > > > > > > > > Your pulseaudio daemon obviously died. Please add output of > > > > > "grep pulseaudio /var/log/messages" to the bugzilla ticket. > > > > > > > > > here is the output of pulseaudio: > > ... > > > Jan 5 19:29:57 cocobear > > pulseaudio[1956]: module-alsa-sink.c: Error opening PCM device hw:0: > > ?????? Jan 5 19:29:57 cocobear pulseaudio[1956]: module.c: > > Failed to load module "module-alsa-sink" (argument: "device=hw:0 > > sink_name=alsa_output.pci_1013_6003_alsa_playback_0"): > > initialization failed. Jan 5 19:29:57 cocobear pulseaudio[1956]: > > module-alsa-source.c: Error opening PCM device hw:0: ?????? > > Jan 5 19:29:57 cocobear pulseaudio[1956]: module.c: Failed to load > > module "module-alsa-source" (argument: "device=hw:0 > > source_name=alsa_input.pci_1013_6003_alsa_capture_0"): > > initialization failed. Jan 5 19:37:06 cocobear pulseaudio[1975]: > > pid.c: Stale PID file, overwriting. Jan 5 20:06:30 cocobear > > pulseaudio[1980]: pid.c: Stale PID file, overwriting. Jan 6 > > 00:08:44 cocobear pulseaudio[1980]: module-volume-restore.c: failed > > to open file '(null)': ????????? Jan 6 23:35:53 cocobear > > pulseaudio[2038]: module-volume-restore.c: failed to open file > > '(null)': ????????? Jan 8 13:27:58 cocobear > > pulseaudio[4795]: pid.c: Stale PID file, overwriting. > > /===============================\ > *** === >>> Open a Bugzilla ticket Pleeease <<< === *** > \===============================/ > > Do _not_ use a maigling list for this. :) > > And when you do so, please include output of the following commands in > the bug report: > > ls -l /dev/snd/* > rpm -q kernel > > Thanks, I am apologized. I report this at: https://bugzilla.redhat.com/show_bug.cgi?id=424621 I hope I have not misunderstand what's you mean. From caolanm at redhat.com Mon Jan 7 11:33:36 2008 From: caolanm at redhat.com (Caolan McNamara) Date: Mon, 07 Jan 2008 11:33:36 +0000 Subject: howto package openoffice.org extensions In-Reply-To: References: <1199451768.7355.201.camel@Jehannum> <604aa7910801041006r3cacf550i149948f4e5bbf64a@mail.gmail.com> <1199474169.7355.264.camel@Jehannum> <477E84B9.1080105@fedoraproject.org> Message-ID: <1199705616.11839.131.camel@Jehannum> On Mon, 2008-01-07 at 04:12 -0700, Alex Lancaster wrote: > Caolan, do you have any best practices recommendations for the naming > of the openoffice.org extensions? I've no real strong feelings one way or the other, I found it convenient for e.g. writer2latex which had multiple subpackages where one of them was the openoffice.org extension to call that subpackage openoffice.org-FOO, I guess just use your own judgement here. > Also, will this particular extension, which is packaged as an .oxt > file, be able to be installed using the unopkg tool as suggested on > that page? i.e. are .oxt files intended to be installed using the > unopkg tool? Oh yes, you can just do unopkg add --shared OOoLatex-4.0.0-beta-2-linux.oxt -env:JFW_PLUGIN_DO_NOT_CHECK_ACCESSIBILITY=1 or if you want to use the linking mechanism to avoid duplicating the contents of that .oxt at registration time then you can use something like %install unzip OOoLatex-4.0.0-beta-2-linux.oxt -d /usr/share/OOoLatex.uno.pkg and then have ... echo yes | unopkg add --shared --link /usr/share/OOoLatex.uno.pkg -env:JFW_PLUGIN_DO_NOT_CHECK_ACCESSIBILITY=1 and unopkg remove --shared net.sourceforge.ooolatex -env:JFW_PLUGIN_DO_NOT_CHECK_ACCESSIBILITY=1 C. From mmaslano at redhat.com Mon Jan 7 11:34:41 2008 From: mmaslano at redhat.com (Marcela Maslanova) Date: Mon, 07 Jan 2008 12:34:41 +0100 Subject: heads up: tcl and tk 8.5 In-Reply-To: References: <477B60F0.6020406@redhat.com> <20080102102228.44c0d545@ghistelwchlohm.scrye.com> Message-ID: <47820E51.8030500@redhat.com> Alex Lancaster wrote: >>>>>> "KF" == Kevin Fenzi writes: >>>>>> > > KF> On Wed, 02 Jan 2008 11:01:20 +0100 > KF> mmaslano at redhat.com (Marcela Maslanova) wrote: > > >> New tcl and tk 8.5 was released. I'd like to push it to rawhide as >> >>> soon as possible. The list of dependent packages could be found in >>> this draft: >>> https://fedoraproject.org/wiki/MarcelaMaslanova/Draft/tcl8.5 The >>> maintainers of dependent packages should fix them according to >>> http://fedoraproject.org/wiki/PackagingDrafts/Tcl >>> > > KF> Can you possibly mail directly at least the primary maintainers of > KF> these packages and let them know when you are going to push the > KF> update? > > KF> Many of them might not see this post... > > Marcela, > > Can you also post to fedora-devel-announce to get wider distribution? > Judging by the high number of broken deps still in rawhide caused by > this tcl soname bump, I suspect that many maintainers may not have > seen this announcement. Many only subscribe to the -announce list and > not devel-list to avoid the high traffic here. (These kind of > distro-wide soname bumps that affect many packages should always be > posted to fedora-announce). > > Also, I've noticed that several packages don't rebuild with the new > Tcl and have build failures with the following: > > /usr/include/tcl-private/generic/tclPort.h:27:28: error: tclUnixPort.h: No such file or directory > > (one example full log is here: > http://koji.fedoraproject.org/koji/getfile?taskID=326763&name=build.log) > > is there any easy fix? > > Alex > > Today I rebuilt tcl with patches, which fixes this issue as I hope. Please let me know, if your problem persists. From alexl at users.sourceforge.net Mon Jan 7 11:43:48 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Mon, 07 Jan 2008 04:43:48 -0700 Subject: howto package openoffice.org extensions In-Reply-To: <1199705616.11839.131.camel@Jehannum> (Caolan McNamara's message of "Mon\, 07 Jan 2008 11\:33\:36 +0000") References: <1199451768.7355.201.camel@Jehannum> <604aa7910801041006r3cacf550i149948f4e5bbf64a@mail.gmail.com> <1199474169.7355.264.camel@Jehannum> <477E84B9.1080105@fedoraproject.org> <1199705616.11839.131.camel@Jehannum> Message-ID: >>>>> "CM" == Caolan McNamara writes: CM> On Mon, 2008-01-07 at 04:12 -0700, Alex Lancaster wrote: >> Caolan, do you have any best practices recommendations for the >> naming of the openoffice.org extensions? CM> I've no real strong feelings one way or the other, I found it CM> convenient for e.g. writer2latex which had multiple subpackages CM> where one of them was the openoffice.org extension to call that CM> subpackage openoffice.org-FOO, I guess just use your own judgement CM> here. OK, I didn't realise that writer2latex had non-OOo components, but that makes sense. >> Also, will this particular extension, which is packaged as an .oxt >> file, be able to be installed using the unopkg tool as suggested on >> that page? i.e. are .oxt files intended to be installed using the >> unopkg tool? CM> Oh yes, you can just do unopkg add --shared CM> OOoLatex-4.0.0-beta-2-linux.oxt CM> -env:JFW_PLUGIN_DO_NOT_CHECK_ACCESSIBILITY=1 CM> or if you want to use the linking mechanism to avoid duplicating CM> the contents of that .oxt at registration time then you can use CM> something like CM> %install unzip OOoLatex-4.0.0-beta-2-linux.oxt -d CM> /usr/share/OOoLatex.uno.pkg CM> and then have ... CM> echo yes | unopkg add --shared --link /usr/share/OOoLatex.uno.pkg CM> -env:JFW_PLUGIN_DO_NOT_CHECK_ACCESSIBILITY=1 CM> and CM> unopkg remove --shared net.sourceforge.ooolatex CM> -env:JFW_PLUGIN_DO_NOT_CHECK_ACCESSIBILITY=1 Thanks for the suggestions. Is the "net.sourceforge.ooolatex" something you derived from the webpage, or is that somehow also in the .oxt? Also, in this case it appears that upstream insists on including some binaries in the .oxt file (they don't seem to distribute a true OS-independent source tarball) so, for example, if you run: unzip -l OOoLatex-4.0.0-beta-2-linux.oxt then you get: Length Date Time Name -------- ---- ---- ---- 931 11-03-07 09:05 AddonRegistry.xcs 1749 11-03-07 09:05 AddonRegistry.xcu 3091 10-22-07 12:17 Addons.xcu 5741 11-25-07 09:29 ChangeLogs.txt 430 11-25-07 09:38 Description.txt 754 11-28-07 13:57 description.xml 1119 11-03-07 09:00 README 1142 10-30-07 13:39 META-INF/manifest.xml 528 10-16-07 12:36 Office/UI/DrawWindowState.xcu 531 10-16-07 12:36 Office/UI/ImpressWindowState.xcu 530 10-16-07 12:36 Office/UI/WriterWindowState.xcu 2836 11-23-07 15:09 OOoLatex/OOoLatexAbout.xba 7404 11-25-07 09:30 OOoLatex/OOoLatexConfig.xba 6686 11-23-07 15:09 OOoLatex/OOoLatexConfig_Dlg.xba 14971 11-23-07 15:09 OOoLatex/OOoLatexEquation.xba 6707 11-23-07 15:09 OOoLatex/OOoLatexEquation_Dlg.xba 48258 11-28-07 13:57 OOoLatex/OOoLatexExpand.xba 6707 11-23-07 15:09 OOoLatex/OOoLatexExpand_Dlg.xba 3377 11-23-07 15:09 OOoLatex/OOoLatexPreamble_Dlg.xba 26656 11-23-07 15:09 OOoLatex/OOoLatexSysConfig.xba 11871 11-23-07 15:09 OOoLatex/OOoLatexTools.xba 2021 11-23-07 15:09 OOoLatex/OOoLatexAbout_GUI.xdl 6525 11-23-07 15:09 OOoLatex/OOoLatexConfig_GUI.xdl 5493 11-23-07 15:09 OOoLatex/OOoLatexEquation_GUI.xdl 3539 11-23-07 15:09 OOoLatex/OOoLatexExpand_GUI.xdl 729 11-23-07 15:09 OOoLatex/OOoLatexInitExpand_GUI.xdl 2393 11-23-07 15:09 OOoLatex/OOoLatexPreamble_GUI.xdl 5161 11-23-07 15:09 OOoLatex/OOoLatexSysConfig_GUI.xdl 693 11-23-07 15:09 OOoLatex/dialog.xlb 828 11-23-07 15:09 OOoLatex/script.xlb 18009 10-16-07 12:36 pkg-licence/gpl_GB.txt 21150 11-01-07 12:42 bin/Linuxi386/latex2emf 28692 11-01-07 12:43 bin/Linuxppc/latex2emf 710928 11-01-07 12:41 lib/i386/libEMF.so.1 717884 11-01-07 12:40 lib/ppc/libEMF.so.1 -------- ------- 1676064 35 files I assume the thing to do in the case is simply remove the files in bin/ and lib/ after installing them in the %install section as you describe above is the best way to deal with those? (libEMF is already in Fedora, and I'd need to package latex2emf separately). Alex From caolanm at redhat.com Mon Jan 7 11:56:00 2008 From: caolanm at redhat.com (Caolan McNamara) Date: Mon, 07 Jan 2008 11:56:00 +0000 Subject: howto package openoffice.org extensions In-Reply-To: References: <1199451768.7355.201.camel@Jehannum> <604aa7910801041006r3cacf550i149948f4e5bbf64a@mail.gmail.com> <1199474169.7355.264.camel@Jehannum> <477E84B9.1080105@fedoraproject.org> <1199705616.11839.131.camel@Jehannum> Message-ID: <1199706960.11839.139.camel@Jehannum> On Mon, 2008-01-07 at 04:43 -0700, Alex Lancaster wrote: > Thanks for the suggestions. Is the "net.sourceforge.ooolatex" > something you derived from the webpage, or is that somehow also in the > .oxt? Actually I just unopkg add'ed it and then unopkg list --shared and looked at what was the name of the extra extension listed there to figure out what OOoLaTeX called itself. I could probably have alternatively found that out by grovelling through the code. > Also, in this case it appears that upstream insists on including some > binaries in the .oxt file (they don't seem to distribute a true > OS-independent source tarball) > 21150 11-01-07 12:42 bin/Linuxi386/latex2emf > 28692 11-01-07 12:43 bin/Linuxppc/latex2emf > 710928 11-01-07 12:41 lib/i386/libEMF.so.1 > 717884 11-01-07 12:40 lib/ppc/libEMF.so.1 > -------- ------- > 1676064 35 files > > I assume the thing to do in the case is simply remove the files in > bin/ and lib/ after installing them in the %install section as you > describe above is the best way to deal with those? That should work I'd say, assuming that the package hasn't hardcoded those paths into itself somewhere, pity that the upstream doesn't have a pure source package but seeing as it just looks like a hack to have latex2emf available for execution by some starbasic code we'll probably get away with it. C. From alan at redhat.com Mon Jan 7 12:03:49 2008 From: alan at redhat.com (Alan Cox) Date: Mon, 7 Jan 2008 07:03:49 -0500 Subject: Init : someone could comment this ? In-Reply-To: References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> Message-ID: <20080107120349.GA15518@devserv.devel.redhat.com> On Mon, Jan 07, 2008 at 05:35:33AM +0000, Kevin Kofler wrote: > AFAIK, busybox still forks whereever a regular POSIX shell forks, so if the > amount of forks is the problem, AFAICT busybox will resolve absolutely nothing. Fork should be pretty cheap - although that depends how much memory is unshared by each of the resulting tasks. A smaller cleaner shell such as rc (which was designed for this job in plan 9) or ash might well perform better. I'm dubious it would be a big difference but someone can bench it. Alan From enrico.scholz at informatik.tu-chemnitz.de Mon Jan 7 12:11:46 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 07 Jan 2008 13:11:46 +0100 Subject: Init : someone could comment this ? In-Reply-To: <1199702578.5761.36.camel@wombat.tiptoe.de> (Nils Philippsen's message of "Mon, 07 Jan 2008 11:42:58 +0100") References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> Message-ID: <874pdprg1p.fsf@fc5.bigo.ensc.de> Nils Philippsen writes: >> I think, nobody doubts that current initsystem is the worst one of >> the major linux distributions. > > Can the hyperbole please -- we know what we have otherwise we wouldn't > be having this discussion. I can not remember how long there are discussions about replacing RH's initsystem (perhaps 5-6 years), and nothing happened. Other distributions implemented more (upstart, syslog-ng) or less (suse, mandriva) innovative methods in the meantime. And now, RH tries to write its own implementation by adding some d-bus features and using a bloaty scripting language around current initscripts? >> By changing paradigm from forking to non-forking daemon you can avoid >> all the complicated 'stop' code; e.g. 'start' will be >> >> | pid = fork(); >> | if (pid==0) { /* ... */ execve(...); } >> >> and 'stop' be >> >> | kill(pid, SIGTERM); /* wait for timeout/sigchld */ kill(pid, SIGKILL); > > That'd be all fine and dandy for daemons that simply need to be > started how much resp. which daemons are not in this category? > without any variable options options are trivially to solve; e.g. by an easy to parse one-option-per-line configuration file or by 'argv = --foo --bar' stylish options in the service description file. > or preparations trivially to be solved by executing helper scripts instead of the daemon itself | #!/bin/sh | ... do something ... | exec "$@" Or, by using syslog-ng ideas of scripts (which terminate) and daemons (which stay running), you can split complicated preparation code and simple startup code in a way like --- daemons/foo --- require = scripts/foo daemon = /usr/sbin/foo --- scripts/foo --- exec = /usr/libexec/foo-prepare > and are obliging enough to write pid files. pid files are an anachronism required for initsystems with forking daemons > I don't think that e.g. the postgresql works perfectly in this way; e.g. I start it with | /usr/bin/setuidgid postgres /usr/bin/postmaster -D /var/lib/pgsql/data >> But python or other bloaty scripting languages are not a solution and >> completely unacceptable at this place. > > "Bloaty" is something that could be solved, don't you think? Not with python or perl. Perhaps lua. But I really do not see why an extra scripting language is required for the initsystem. sh/bash is perfect for doing potential preparation tasks. > bash takes up about 5.1MB. you mean the 750kb sized 'bash' binary and the >4 MB documentation plus locale files? Enrico From mmaslano at redhat.com Mon Jan 7 11:33:20 2008 From: mmaslano at redhat.com (Marcela Maslanova) Date: Mon, 07 Jan 2008 12:33:20 +0100 Subject: [Fwd: heads up: tcl and tk 8.5] Message-ID: <47820E00.7010007@redhat.com> -------------- next part -------------- An embedded message was scrubbed... From: Marcela Maslanova Subject: heads up: tcl and tk 8.5 Date: Wed, 02 Jan 2008 11:01:20 +0100 Size: 3533 URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From choeger at cs.tu-berlin.de Mon Jan 7 13:07:59 2008 From: choeger at cs.tu-berlin.de (=?ISO-8859-15?Q?Christoph_H=F6ger?=) Date: Mon, 07 Jan 2008 14:07:59 +0100 Subject: autoconf driving me mad Message-ID: <4782242F.8060102@cs.tu-berlin.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hey there, i want to patch & build openccs under fedora. So I have to do the autoconf/automake chain. No problem at all, but one special thing makes me wanne cry: I see the following line in configure.in (yes its an relatively old tarball): GLOB_INCLUDE="-I${srcdir} -I${srcdir}/include" AC_SUBST(GLOB_INCLUDE) This means I have config headers in the include subdirectory, where I actually build the package. But my autoconf adds the following lines to the ./configure script: # When building in place, set srcdir=. if test "$ac_abs_confdir" = "$ac_pwd"; then srcdir=. fi How can I fix that? thank you christoph -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHgiQvhMBO4cVSGS8RAndJAKC61XYSSwvxgd1qgk2MzAkZyYjGSQCgp2fn VS5yuH5unMCEi7Jx7sucei8= =6IMK -----END PGP SIGNATURE----- From tomek at crocom.com.pl Mon Jan 7 13:19:13 2008 From: tomek at crocom.com.pl (Tomasz Torcz) Date: Mon, 07 Jan 2008 14:19:13 +0100 Subject: [OT] Re: f8 gripe#2: why did f8's pm-hibernate regress? In-Reply-To: <1199482347.3035.9.camel@watson> References: <477ADF46.2040108@filteredperception.org> <200801021159.17964.opensource@till.name> <477C299D.2060400@filteredperception.org> <477C96B8.6040903@filteredperception.org> <1199382316.3261.7.camel@sb-home> <1199482347.3035.9.camel@watson> Message-ID: <1199711953.3244.41.camel@s1.crocom.com.pl> Dnia 04-01-2008, pi? o godzinie 22:32 +0100, David Nielsen pisze: > tor, 03 01 2008 kl. 18:45 +0100, skrev nodata: > > I don't know why people keep saying this. Vista boots fast and is > > responsive. > > Wow.. can I have a puff at that crack pipe my good man? :) Sorry for offtopic. Vista needs few days (weeks?) of use to prime its readahead/preload? caches. It's slow just after install, but gets better with time. One have to give this OS time for all its tricks to show. BTW, I'm not advocating for Vista. Just be serious and don't treat Vista with prejudice. Fedora is doing readahead also, but in less sophisticated way. http://preload.sf.net seems to be dead and broken by prelink. Why not learn how others are doing similar things? ? http://en.wikipedia.org/wiki/Windows_Vista_I/O_technologies#SuperFetch -- Tomasz Torcz Crocom Computer Systems From buildsys at redhat.com Mon Jan 7 13:47:05 2008 From: buildsys at redhat.com (Build System) Date: Mon, 7 Jan 2008 08:47:05 -0500 Subject: rawhide report: 20080107 changes Message-ID: <200801071347.m07Dl50n007415@porkchop.devel.redhat.com> New package dbxml An embeddable XML database with XQuery-based access to documents New package hunspell-hi Hindi hunspell dictionaries New package hunspell-mr Marathi hunspell dictionaries New package hunspell-or Oriya hunspell dictionaries New package hunspell-pa Punjabi hunspell dictionaries New package hunspell-ta Tamil hunspell dictionaries New package moodbar Identifies the "mood" of your music files New package nvclock Utility that allows users to overclock NVIDIA based video cards Removed package libdvdread Updated Packages: R-BufferedMatrixMethods-1.3.0-1.fc8 ----------------------------------- aasaver-0.3.2-2.fc9 ------------------- adminutil-1.1.5-1.fc8 --------------------- * Thu Oct 18 2007 Rich Megginson - 1.1.5-1 - bump version to 1.1.5 - fix icu linking issue - disable libtool rpath by default - added --enable-rpath option to configure anaconda-11.4.0.16-1 -------------------- * Sun Jan 06 2008 Chris Lumens - 11.4.0.16-1 - Fix checking the timestamps on split media installs. (clumens) - Fix reference to isodir to avoid a post-install traceback. (clumens) - Use a better test when populating the URL panel in loader. (clumens) - Don't use error messages from dosfslabel as the label (#427457). (clumens) - No longer require kudzu (#427680). (clumens) blt-2.4-22.fc9 -------------- * Mon Jan 07 2008 Sergio Pascual 2.4-22 - Debug files in debug package (bug #427681) bodhi-0.4.9-1.fc9 ----------------- * Sun Jan 06 2008 Luke Macken - 0.4.9-1 - 0.4.9 compiz-fusion-0.6.0-13.fc9 -------------------------- * Sun Jan 06 2008 Adel Gadllah 0.6.0-13 - Readded accidently dropped memoryleak fix d4x-2.5.7.1-7.fc9 ----------------- * Sat Jan 05 2008 Alex Lancaster - 2.5.7.1-7 - Add patch by Caolan McNamara (#427620) to build against new openssl * Wed Dec 05 2007 Release Engineering - 2.5.7.1-6 - Rebuild for deps * Fri Aug 31 2007 Matthias Saou 2.5.7.1-5 - Rebuild for new BuildID feature. - License is still original Artistic, but this should be fixed shortly. eclipse-subclipse-1.2.4-5.fc8 ----------------------------- * Mon Nov 12 2007 Robert Marcano 1.2.4-5 - Disable ppc64 build for f9 too, build system is using fc9 as dist tag for f8 * Fri Oct 19 2007 Robert Marcano 1.2.4-3 - Disable ppc64 build for f8, see Bug #298071 * Wed Sep 19 2007 Robert Marcano 1.2.4-2 - Fix wrong applied classpath patch, fixing error: An error occurred while automatically activating bundle org.tigris.subversion.subclipse.core ed2k_hash-0.4.0-6.fc9 --------------------- * Sun Jan 06 2008 Dominik Mierzejewski 0.4.0-6 - fix compilation with gcc-4.3 ekg-1.7-5.fc9 ------------- * Sun Jan 06 2008 Dominik Mierzejewski 1.7-5 - fix parallel build * Tue Jan 01 2008 Dominik Mierzejewski 1.7-4 - use luit wrapper to work around lack of unicode support (bug #210745) - fix line endings and docs encoding in prep instead of install section * Thu Dec 06 2007 Release Engineering - 1.7-3 - Rebuild for deps extrema-4.3.1-2.fc9 ------------------- * Sun Jan 06 2008 Terje Rosten - 4.3.1-2 - rebuild fedorainfinity-kdm-theme-1.0.4-1.fc8 ------------------------------------ * Wed Oct 31 2007 Rex Dieter - 1.0.4-1 - make FedoraInfinity, FedoraInfinityKDM color scheme name = filename filezilla-3.0.2.1-2.fc8 ----------------------- * Wed Nov 07 2007 kwizart < kwizart at gmail.com > - 3.0.2.1-2 - backport fixes from 3.0.3 * Fri Oct 19 2007 kwizart < kwizart at gmail.com > - 3.0.2.1-1 - Update to 3.0.2.1 geany-0.12-4.fc8 ---------------- * Thu Oct 18 2007 Jonathan G. Underwood - 0.12-4 - Fix license tag - Package new library files - Remove static library .la files - Package new icons * Thu Oct 18 2007 Jonathan G. Underwood - 0.12-3 - Fix Version entry in .desktop file again * Thu Oct 18 2007 Jonathan G. Underwood - 0.12-2 - Add a BuildRequires for perl(XML::Parser) gramps-2.2.8-6.fc8 ------------------ * Sun Nov 11 2007 Brian Pepple - 2.2.8-6 - Add patch to fix bug w/gtkspell. (#376881) * Sun Aug 05 2007 Brian Pepple - 2.2.8-5 - Update license tag. * Sun Jun 10 2007 Brian Pepple - 2.2.8-4 - Drop requires on yelp. gtk+extra-2.1.1-6.fc8 --------------------- * Fri Oct 19 2007 Alain Portal 2.1.1-6 - Update patch to fix BZ #339611 gtkperf-0.40-7.fc8 ------------------ * Sat Oct 27 2007 Per Patrice Bouchand gmail.com> 0.40-7 - Problem with make tag, bumping * Sat Aug 11 2007 Per Patrice Bouchand gmail.com> 0.40-6 - Remove attr(755,root,root) on _bindir * Fri Aug 10 2007 Per Patrice Bouchand gmail.com> 0.40-5 - Convert ChangeLog to UTF8 - Update License tag to GPLv2 - Suppress the call of automated autoheader - Set CFLAGS in make hal-info-20071212-1.fc9 ----------------------- * Sun Jan 06 2008 Lubomir Kundrak - 20071212-1.fc9 - Update to latest upstream release - Clean buildroot in %install id3lib-3.8.3-19.fc9 ------------------- * Tue Dec 04 2007 Hans de Goede 3.8.3-19 - Fix building of id3lib and programs using it with gcc34 - Drop prebuild doxygen docs, now that doxygen is fixed to not cause multilib conflicts - Convert some docs to UTF-8 jabbim-0.3-0.61.20080106svn.fc9 ------------------------------- * Sun Jan 06 2008 Michal Schmidt - 0.3-0.61.20080106svn - Upstream SVN revision 1766. - changes: self-contact menu, file transfer in MUC, translations. - Change in packaging - Don't upload every new upstream SVN snapshot to the lookaside cache. That seems too wasteful. Have a patch in CVS instead. jetty-5.1.12-1jpp.8.fc8 ----------------------- * Tue Nov 20 2007 Jeff Johnston 5.1.12-1jpp.8 - Resolves #393071 - Rename jettyrc back to .jettyrc as this file is needed when starting jetty via /etc/init.d/jetty start - Resolves #262221 kbackup-0.5.3-1.fc8 ------------------- * Thu Oct 18 2007 Alain Portal 0.5.3-1 - New upstream version - Update patch 0 - Remove patch 1 that is no more needed kbibtex-0.2-13.fc8 ------------------ * Tue Jan 01 2008 Christian Nolte - 0.2-13 - Updated to latest upstream version 0.2 - Desktop-File kbibtex_part.desktop patched: Type is Application now * Mon Jul 09 2007 Christian Nolte - 0.1.5.52-11 - Updated to latest upstream version * Wed Mar 21 2007 Christian Nolte - 0.1.5-8 - latest patches (storesearchurls, webquerypubmedmultiplequeries, xslhtmlexport) kbiof-0.3-2.fc9 --------------- kcometen3-1.1-6.fc9 ------------------- * Sun Jan 06 2008 Ian Chapman 1.1-6 - Use kdelibs3-devel now instead of kdelibs-devel - Source qt.sh kdetv-0.8.9-9.fc9 ----------------- * Sun Jan 06 2008 Ian Chapman 0.8.9-9 - Use kdelibs3-devel now instead of kdelibs-devel kernel-2.6.24-0.138.rc7.fc9 --------------------------- * Sun Jan 06 2008 Roland McGrath - Reenable utrace after pulling current patches that already applied fine. * Sun Jan 06 2008 Kyle McMartin - 2.6.24-rc7 knetworkmanager-0.2-0.7.fc8 --------------------------- * Tue Nov 06 2007 Rex Dieter - 0.2-0.7 - omit knetworkmanager-autostart, so nm-applet doesn't start twice (#367711) - omit needless (icon) scriptlets koffice-1.6.3-13.fc8 -------------------- * Fri Nov 09 2007 Rex Dieter 1.6.3-13 - CVE-2007-4352 CVE-2007-5392 CVE-2007-5393 (#372611) kyum-0.7.5-10.fc9 ----------------- * Sun Jan 06 2008 Jochen Schmitt 0.7.5-10 - Add autoconf as BR to solve build issues libEMF-1.0.3-6.fc9 ------------------ * Sun Jan 06 2008 Dominik 'Rathann' Mierzejewski 1.0.3-6 - fixed compilation with gcc-4.3 libdsk-1.2.0-1.fc9 ------------------ * Sun Jan 06 2008 Ian Chapman 1.2.0-1 - Upgrade to 1.2.0 - Dropped open() patch, fixed upstream * Wed Aug 22 2007 Ian Chapman 1.1.14-2 - Release bump for F8 mass rebuild - Corrected license * Fri Aug 10 2007 Ian Chapman 1.1.14-1 - Upgrade to 1.1.14 - Updated license field due to new guidelines - Added patch to fix open() due to new macros libfreebob-1.0.3-2.fc9 ---------------------- * Thu Jan 03 2008 Anthony Green 1.0.3-2 - Add cstdlib patch for gcc 4.3. libopensync-plugin-sunbird-0.22-3.fc8 ------------------------------------- libspectrum-0.4.0-1.fc9 ----------------------- * Sun Jan 06 2008 Ian Chapman 0.4.0-1 - Upgrade to 0.4.0 * Tue Aug 21 2007 Ian Chapman 0.3.0.1-3 - Release bump for F8 mass rebuild - License change due to new guidelines * Sat Jun 30 2007 Ian Chapman 0.3.0.1-2 - Release bump mingetty-1.07-7 --------------- * Sun Jan 06 2008 Florian La Roche - 1.07-7 - add rpmlint changes to .spec file from Jon Ciesla limb at jcomserv.net * Tue Aug 21 2007 Florian La Roche - 1.07-6 - rebuild * Wed Jul 12 2006 Jesse Keating - 1.07-5.2.2 - rebuild mod_wsgi-1.3-2.fc9 ------------------ monsterz-0.7.1-1.fc9 -------------------- * Sun Jan 06 2008 Ian Chapman 0.7.1-1 - Upgrade to 0.7.1 - Drop separate data package as it's unnecessary - Merge .desktop back into SPEC - Various spec cleanups - Updated the "use rpm opts" patch - Use the icon now supplied * Wed Aug 22 2007 Ian Chapman 0.7.0-8 - Release bump for F8 mass rebuild * Mon Aug 28 2006 Ian Chapman 0.7.0-7 - Release bump for FC6 mass rebuild mozldap-6.0.5-1.fc8 ------------------- * Wed Sep 26 2007 Rich Megginson - 6.0.5-1 - bump to version 6.0.5 - this version allows the use of SASL - with IPv6 numeric addresses, as well as some memory leak fixes multisync-0.91.0-3.fc8 ---------------------- * Sat Jan 05 2008 Andreas Bierfert - 0.91.0-3 - fix #249530 * Wed Apr 25 2007 Andreas Bierfert 0.91.0-2 - upgrade msynctool openvrml-0.17.1-1.fc9 --------------------- * Sun Jan 06 2008 Braden McDaniel - 0.17.1-1 - Updated to 0.17.1. perl-Convert-Binary-C-0.70-1.fc9 -------------------------------- * Sun Jan 06 2008 Alex Lancaster - 0.70-1 - Update to latest upstream (0.70) * Thu Aug 23 2007 Alex Lancaster 0.68-2 - License tag to GPL+ or Artistic as per new guidelines. * Sat Aug 18 2007 Alex Lancaster 0.68-1 - Update to latest upstream perl-Kwiki-Raw-0.02-5.fc9 ------------------------- * Mon Jan 07 2008 Ralf Cors??pius 0.04-5 - Update License-tag. - BR: perl(Test::More) (BZ 419631). photoml-0.24-4.fc9 ------------------ * Sun Jan 06 2008 Brendt Wohlberg - 0.24-4 - Added missing dependencies (previously listed only as build dependencies). python-cherrypy-2.2.1-8.fc9 --------------------------- * Sun Jan 06 2008 Toshio Kuratomi 2.2.1-8 - Fix a security bug with a backport of http://www.cherrypy.org/changeset/1775 - Include the egginfo files as well as the python files. python-gammu-0.24-1.fc8.1 ------------------------- * Thu Dec 27 2007 Xavier Lamien < lxtnow[at]gmail.com > - 0.24-1 - Updated Release. * Tue Jul 03 2007 Xavier Lamien < lxtnow[at]gmail.com > - 0.21-1 - Updated Release. * Wed May 23 2007 Xavier Lamien < lxtnow[at]gmail.com > - 0.20-1 - Updated release. - fixed permission on examples files. - added gammu as require (need it to work with wammu package). python-smbpasswd-1.0.1-7.fc9 ---------------------------- * Sun Jan 06 2008 Jochen Schmitt 1.0.1-7 - Add .egg-info file into package python-sqlalchemy0.3-0.3.11-1.fc8 --------------------------------- * Tue Dec 11 2007 Toshio Kuratomi - 0.3.11-1 - Update to 0.3.11. qca-gnupg-2.0.0-0.1.beta1.fc8 ----------------------------- ragel-5.25-2.fc9 ---------------- * Sun Jan 06 2008 Jeremy Hinegardner - 5.25-2 - bump release * Sun Jan 06 2008 Jeremy Hinegardner - 5.25-1 - update to 5.25 rosegarden4-1.6.0-1.fc8 ----------------------- shorewall-4.0.7-3.fc9 --------------------- * Sun Jan 06 2008 Jonathan G. Underwood - 4.0.7-2 - Remove 4.0.7.1 patch as it seems that's already been applied to the tarball contents * Sun Jan 06 2008 Jonathan G. Underwood - 4.0.7-2 - Fix error in patching commands in spec file (change -p0 to -p1 for new patches) * Sun Jan 06 2008 Jonathan G. Underwood - 4.0.7-1 - Update to version 4.0.7 - Added 4.0.7.1 patch and all parts of the 4.0.7.2 patch that are relevant (i.e. not the parts working around the iproute2-2.23 bug, as we don't ship the broken iproute2) - Clarified notes about tarball and patch locations smarteiffel-2.3-2.fc9 --------------------- * Sun Jan 06 2008 Gerard Milmeister - 2.3-2 - added buildreq libX11-devel * Sat Jan 05 2008 Gerard Milmeister - 2.3-1 - new release 2.3 snort-2.7.0.1-5.fc8 ------------------- * Sat Nov 17 2007 Dennis Gilmore - 2.7.0.1-5 - fix install command for /etc/sysconfig/snort * Sat Nov 17 2007 Dennis Gilmore - 2.7.0.1-4 - fix paths for alternatives binaries are in %{_sbindir} not %{_bindir} - move the interfaces definition out of the init script and into /etc/sysconfig/snort sos-1.8-1.fc8 ------------- * Fri Dec 14 2007 Navid Sheikhol-Eslami - 1.8-1 - do not obsolete sysreport in Fedora * Wed Nov 21 2007 Navid Sheikhol-Eslami - 1.8-0 - Resolves: bz368261 sosGetCommandOutput() does not block on hung processes - Resolves: bz361861 work-around missing traceback.format_exc() in RHEL4 - Resolves: bz394781 device-mapper: use /sbin/lvm_dump to collect dm related info - Resolves: bz386691 unattended --batch option - Resolves: bz371251 sos could hang when accessing /sys/hypervisor/uuid - selinux: always collect sestatus - added many languages - added --debug option which causes exceptions not to be trapped - updated to sysreport-1.4.3-13.el5 - ftp upload to dropbox with --upload - cluster: major rewrite to support different versions of RHEL - cluster: check rg_test for errors - minor changes in various plug-ins (yum, networking, process, kernel) - fixed some exceptions in threads which were not properly trapped - veritas: don't run rpm -qa every time - using rpm's python bindings instead of external binary - corrected autofs and ldap plugin that were failing when debug option was not found in config file. - implemented built-in checkdebug() that uses self.files and self.packages to make the decision - missing binaries are properly detected now. - better doExitCode handling - fixed problem with rpm module intercepting SIGINT - error when user specifies an invalid plugin or plugin option - named: fixed indentation - replaced isOptionEnabled() with getOption() - tune2fs and fdisk were not always run against the correct devices/mountpoint - added gpg key to package - updated README with new svn repo and contributors - updated manpage - better signal handling - caching of rpm -q outputs - report filename includes rhnUsername if available - report encryption via gpg and support pubkey - autofs: removed redundant files - filesys: better handling of removable devices - added sosReadFile() returns a file's contents - return after looping inside a directory - collect udevinfo for each block device - simply collect output of fdisk -l in one go - handle sysreport invocation properly (warn if shell is interactive, otherwise spawn sysreport.legacy) - progress bar don't show 100% until finished() is called - Resolves: bz238778 added lspci -t - now runs on RHEL3 as well (python 2.2) - replaced commonPrefix() with faster code - filesys: one fdisk -l for all - selinux: collect fixfilex check output - devicemapper: collect udevinfo for all block devices - cluster: validate node names according to RFC 2181 - systemtap: cleaned up and added checkenabled() method - added kdump plugin - added collection of /etc/inittab - Resolves: bz332151 apply regex to case number in sysreport for RHEL4 - Resolves: bz332211 apply regex to case number in sysreport for RHEL5 - Resolves: bz400111 sos incorrectly reports cluster data in SMP machine * Mon Aug 13 2007 Navid Sheikhol-Eslami - 1.7-8 - added README.rh-upload-core streamtuner-0.99.99-18.fc8 -------------------------- * Fri Dec 14 2007 Matthias Haase - 0.99.99-18 - broken live365 plugin disabled * Fri Dec 14 2007 Matthias Haase - 0.99.99-17 - htmlview changed to xdg-open as default action (opening a web page) - html-view replaced by xdg-utils (requires) * Mon Feb 26 2007 Matthias Haase - 0.99.99-16 - bump up release tecnoballz-0.92-2.fc9 --------------------- * Sun Jan 06 2008 Andrea Musuruane 0.92-2 - added a patch from upstream CVS to compile with GCC 4.3 tk-tktreectrl-2.2.3-4.fc9 ------------------------- * Sun Jan 06 2008 Wart - 2.2.3-4 - Add patch to install package into the correct directory * Fri Jan 04 2008 Wart - 2.2.3-3 - Rebuild for Tcl 8.5 urw-fonts-2.4-2.fc8 ------------------- * Wed Nov 28 2007 Than Ngo - 2.4-2 - fix #401641, add dependency on xorg-x11-font-utils vdradmin-am-3.6.1-1.fc8 ----------------------- * Wed Dec 19 2007 Ville Skytt?? - 3.6.1-1 - 3.6.1. - Fix translation file permissions/ownership. weechat-0.2.6-1.fc8 ------------------- * Fri Oct 19 2007 Paul P. Komkoff Jr - 0.2.6-1 - new upstream version, new license wlassistant-0.5.7-5.fc8 ----------------------- * Sat Nov 17 2007 Tom "spot" Callaway 0.5.7-5 - fix pam file to use console-apps pam tree, instead of its own resolves 243240, 306041 xdrawchem-1.9.9-7.fc9 --------------------- * Mon Jan 07 2008 Dominik Mierzejewski 1.9.9-7 - fix build with gcc-4.3 xine-lib-1.1.9-1.fc9 -------------------- * Sun Jan 06 2008 Ville Skytt?? - 1.1.9-1 - 1.1.9. * Thu Sep 27 2007 Ville Skytt?? - 1.1.8-6 - Enable wavpack support by default for all distros. * Sun Sep 23 2007 Ville Skytt?? - 1.1.8-5 - Enable JACK support by default for all distros. xzgv-0.9-3.fc9 -------------- * Sun Jan 06 2008 Terje Rosten - 0.9-3 - info file has moved, fix scripts zidrav-1.2.0-4.fc9 ------------------ * Sun Jan 06 2008 Dominik 'Rathann' Mierzejewski 1.2.0-4 - fix compilation with gcc-4.3 zvbi-0.2.26-2.fc9 ----------------- * Sun Jan 06 2008 Ian Chapman 0.2.26-2 - Release bump * Sun Jan 06 2008 Ian Chapman 0.2.26-1 - Upgrade to 0.2.26 * Wed Aug 22 2007 Ian Chapman 0.2.25-2 - Release bump for F8 mass rebuild - License change due to new guidelines - Use fontpath.d for F8+ - Added patch to fix compilation with open() macro on F8+ Broken deps for i386 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-client - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.i386 requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.i386 requires libcrypto.so.6 csound-tk - 5.03.0-13.fc7.i386 requires libtk8.4.so csound-tk - 5.03.0-13.fc7.i386 requires libtcl8.4.so epiphany-extensions - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires libgtkembedmoz.so expect - 5.43.0-9.fc8.i386 requires libtcl8.4.so expectk - 5.43.0-9.fc8.i386 requires libtk8.4.so expectk - 5.43.0-9.fc8.i386 requires libtcl8.4.so gcl - 2.6.7-15.fc8.i386 requires libtcl8.4.so gcl - 2.6.7-15.fc8.i386 requires libtk8.4.so gnome-web-photo - 0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.i386 requires libgtkembedmoz.so irsim - 9.7.50-1.fc8.i386 requires libtcl8.4.so irsim - 9.7.50-1.fc8.i386 requires libtk8.4.so isdn4k-utils-vboxgetty - 3.2-55.fc8.i386 requires libtcl8.4.so kannel - 1.4.1-5.i386 requires libssl.so.6 kannel - 1.4.1-5.i386 requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 libopensync-plugin-sunbird - 0.22-3.fc8.i386 requires libopensync.so.0 libopensync-plugin-synce - 0.22-4.fc8.i386 requires libopensync.so.0 liferea - 1.4.10-1.fc9.i386 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.i386 requires libgtkembedmoz.so magic - 7.4.35-6.fc8.i386 requires libtcl8.4.so magic - 7.4.35-6.fc8.i386 requires libtk8.4.so multisync - 0.91.0-3.fc8.i386 requires libopensync.so.0 multisync - 0.91.0-3.fc8.i386 requires libosengine.so.0 multisync-gui - 0.91.0-3.fc8.i386 requires libopensync.so.0 multisync-gui - 0.91.0-3.fc8.i386 requires libosengine.so.0 netgen - 1.3.7-13.fc9.i386 requires libtcl8.4.so netgen - 1.3.7-13.fc9.i386 requires libtk8.4.so plplot - 5.8.0-5.fc9.i386 requires libtcl8.4.so plplot - 5.8.0-5.fc9.i386 requires libtk8.4.so plplot-tk - 5.8.0-5.fc9.i386 requires libtk8.4.so plplot-tk - 5.8.0-5.fc9.i386 requires libtcl8.4.so postgresql-pltcl - 8.2.5-2.fc9.i386 requires libtcl8.4.so pvm-gui - 3.4.5-7.fc6.1.i386 requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.i386 requires libtcl8.4.so qtparted - 0.4.5-15.fc8.i386 requires libparted-1.8.so.6 skencil - 0.6.17-15.20070606svn.fc8.i386 requires libtk8.4.so skencil - 0.6.17-15.20070606svn.fc8.i386 requires libtcl8.4.so tcl-brlapi - 0.5.0-1.fc8.i386 requires libtcl8.4.so tcl-tcldict - 8.5.2-2.fc8.i386 requires tcl(abi) = 0:8.4 vtk - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtcl8.4.so Broken deps for x86_64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.x86_64 requires libssl.so.6()(64bit) csound-tk - 5.03.0-13.fc7.x86_64 requires libtk8.4.so()(64bit) csound-tk - 5.03.0-13.fc7.x86_64 requires libtcl8.4.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) expect - 5.43.0-9.fc8.x86_64 requires libtcl8.4.so()(64bit) expect - 5.43.0-9.fc8.i386 requires libtcl8.4.so expectk - 5.43.0-9.fc8.x86_64 requires libtk8.4.so()(64bit) expectk - 5.43.0-9.fc8.x86_64 requires libtcl8.4.so()(64bit) gcl - 2.6.7-15.fc8.x86_64 requires libtcl8.4.so()(64bit) gcl - 2.6.7-15.fc8.x86_64 requires libtk8.4.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) isdn4k-utils-vboxgetty - 3.2-55.fc8.x86_64 requires libtcl8.4.so()(64bit) kazehakase - 0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 libopensync-plugin-sunbird - 0.22-3.fc8.x86_64 requires libopensync.so.0()(64bit) libopensync-plugin-synce - 0.22-4.fc8.x86_64 requires libopensync.so.0()(64bit) liferea - 1.4.10-1.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.x86_64 requires libgtkembedmoz.so()(64bit) magic - 7.4.35-6.fc8.x86_64 requires libtcl8.4.so()(64bit) magic - 7.4.35-6.fc8.x86_64 requires libtk8.4.so()(64bit) multisync - 0.91.0-3.fc8.x86_64 requires libosengine.so.0()(64bit) multisync - 0.91.0-3.fc8.x86_64 requires libopensync.so.0()(64bit) multisync-gui - 0.91.0-3.fc8.x86_64 requires libopensync.so.0()(64bit) multisync-gui - 0.91.0-3.fc8.x86_64 requires libosengine.so.0()(64bit) netgen - 1.3.7-13.fc9.x86_64 requires libtcl8.4.so()(64bit) netgen - 1.3.7-13.fc9.x86_64 requires libtk8.4.so()(64bit) plplot - 5.8.0-5.fc9.x86_64 requires libtk8.4.so()(64bit) plplot - 5.8.0-5.fc9.x86_64 requires libtcl8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.x86_64 requires libtk8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.x86_64 requires libtcl8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.i386 requires libtk8.4.so plplot-tk - 5.8.0-5.fc9.i386 requires libtcl8.4.so postgresql-pltcl - 8.2.5-2.fc9.x86_64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.x86_64 requires libtk8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.x86_64 requires libtcl8.4.so()(64bit) qtparted - 0.4.5-15.fc8.x86_64 requires libparted-1.8.so.6()(64bit) skencil - 0.6.17-15.20070606svn.fc8.x86_64 requires libtcl8.4.so()(64bit) skencil - 0.6.17-15.20070606svn.fc8.x86_64 requires libtk8.4.so()(64bit) tcl-brlapi - 0.5.0-1.fc8.x86_64 requires libtcl8.4.so()(64bit) tcl-tcldict - 8.5.2-2.fc8.x86_64 requires tcl(abi) = 0:8.4 vtk - 5.0.3-20.fc8.x86_64 requires libtk8.4.so()(64bit) vtk - 5.0.3-20.fc8.x86_64 requires libtcl8.4.so()(64bit) vtk - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-python - 5.0.3-20.fc8.x86_64 requires libtk8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.x86_64 requires libtcl8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.x86_64 requires libtk8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.x86_64 requires libtcl8.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-client - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-gnome - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-console-wxwidgets - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-director-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-common - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-mysql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-postgresql - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-storage-sqlite - 2.0.3-11.fc8.ppc requires libcrypto.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libssl.so.6 bacula-traymonitor - 2.0.3-11.fc8.ppc requires libcrypto.so.6 csound-tk - 5.03.0-13.fc7.ppc requires libtk8.4.so csound-tk - 5.03.0-13.fc7.ppc requires libtcl8.4.so epiphany-extensions - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires libgtkembedmoz.so expect - 5.43.0-9.fc8.ppc64 requires libtcl8.4.so()(64bit) expect - 5.43.0-9.fc8.ppc requires libtcl8.4.so expectk - 5.43.0-9.fc8.ppc requires libtk8.4.so expectk - 5.43.0-9.fc8.ppc requires libtcl8.4.so gnome-web-photo - 0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.ppc requires libgtkembedmoz.so irsim - 9.7.50-1.fc8.ppc requires libtcl8.4.so irsim - 9.7.50-1.fc8.ppc requires libtk8.4.so isdn4k-utils-vboxgetty - 3.2-55.fc8.ppc requires libtcl8.4.so kannel - 1.4.1-5.ppc requires libssl.so.6 kannel - 1.4.1-5.ppc requires libcrypto.so.6 kazehakase - 0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 libopensync-plugin-sunbird - 0.22-3.fc8.ppc requires libopensync.so.0 libopensync-plugin-synce - 0.22-4.fc8.ppc requires libopensync.so.0 liferea - 1.4.10-1.fc9.ppc requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc requires libgtkembedmoz.so magic - 7.4.35-6.fc8.ppc requires libtcl8.4.so magic - 7.4.35-6.fc8.ppc requires libtk8.4.so monodevelop - 0.17-4.fc9.ppc requires boo multisync - 0.91.0-3.fc8.ppc requires libopensync.so.0 multisync - 0.91.0-3.fc8.ppc requires libosengine.so.0 multisync-gui - 0.91.0-3.fc8.ppc requires libopensync.so.0 multisync-gui - 0.91.0-3.fc8.ppc requires libosengine.so.0 netgen - 1.3.7-13.fc9.ppc requires libtcl8.4.so netgen - 1.3.7-13.fc9.ppc requires libtk8.4.so plplot - 5.8.0-5.fc9.ppc requires libtcl8.4.so plplot - 5.8.0-5.fc9.ppc requires libtk8.4.so plplot-tk - 5.8.0-5.fc9.ppc64 requires libtk8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.ppc64 requires libtcl8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.ppc requires libtk8.4.so plplot-tk - 5.8.0-5.fc9.ppc requires libtcl8.4.so postgresql-pltcl - 8.2.5-2.fc9.ppc requires libtcl8.4.so pvm-gui - 3.4.5-7.fc6.1.ppc requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.ppc requires libtcl8.4.so qtparted - 0.4.5-15.fc8.ppc requires libparted-1.8.so.6 skencil - 0.6.17-15.20070606svn.fc8.ppc requires libtk8.4.so skencil - 0.6.17-15.20070606svn.fc8.ppc requires libtcl8.4.so tcl-brlapi - 0.5.0-1.fc8.ppc requires libtcl8.4.so tcl-tcldict - 8.5.2-2.fc8.ppc requires tcl(abi) = 0:8.4 vtk - 5.0.3-20.fc8.ppc requires libtcl8.4.so vtk - 5.0.3-20.fc8.ppc requires libtk8.4.so vtk - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc requires libtk8.4.so vtk-python - 5.0.3-20.fc8.ppc requires libtcl8.4.so vtk-python - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc requires libtk8.4.so vtk-tcl - 5.0.3-20.fc8.ppc requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) Broken deps for ppc64 ---------------------------------------------------------- bacula-client - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-client - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-gnome - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-console-wxwidgets - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-director-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-common - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-mysql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-postgresql - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-storage-sqlite - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libcrypto.so.6()(64bit) bacula-traymonitor - 2.0.3-11.fc8.ppc64 requires libssl.so.6()(64bit) csound-tk - 5.03.0-13.fc7.ppc64 requires libtk8.4.so()(64bit) csound-tk - 5.03.0-13.fc7.ppc64 requires libtcl8.4.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) expect - 5.43.0-9.fc8.ppc64 requires libtcl8.4.so()(64bit) expectk - 5.43.0-9.fc8.ppc64 requires libtk8.4.so()(64bit) expectk - 5.43.0-9.fc8.ppc64 requires libtcl8.4.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) isdn4k-utils-vboxgetty - 3.2-55.fc8.ppc64 requires libtcl8.4.so()(64bit) kazehakase - 0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 libopensync-plugin-sunbird - 0.22-3.fc8.ppc64 requires libopensync.so.0()(64bit) libopensync-plugin-synce - 0.22-4.fc8.ppc64 requires libopensync.so.0()(64bit) liferea - 1.4.10-1.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 liferea - 1.4.10-1.fc9.ppc64 requires libgtkembedmoz.so()(64bit) magic - 7.4.35-6.fc8.ppc64 requires libtcl8.4.so()(64bit) magic - 7.4.35-6.fc8.ppc64 requires libtk8.4.so()(64bit) multisync - 0.91.0-3.fc8.ppc64 requires libosengine.so.0()(64bit) multisync - 0.91.0-3.fc8.ppc64 requires libopensync.so.0()(64bit) multisync-gui - 0.91.0-3.fc8.ppc64 requires libopensync.so.0()(64bit) multisync-gui - 0.91.0-3.fc8.ppc64 requires libosengine.so.0()(64bit) netgen - 1.3.7-13.fc9.ppc64 requires libtcl8.4.so()(64bit) netgen - 1.3.7-13.fc9.ppc64 requires libtk8.4.so()(64bit) perl-Test-AutoBuild-darcs - 1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 plplot - 5.8.0-5.fc9.ppc64 requires libtk8.4.so()(64bit) plplot - 5.8.0-5.fc9.ppc64 requires libtcl8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.ppc64 requires libtk8.4.so()(64bit) plplot-tk - 5.8.0-5.fc9.ppc64 requires libtcl8.4.so()(64bit) postgresql-pltcl - 8.2.5-2.fc9.ppc64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ppc64 requires libtk8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ppc64 requires libtcl8.4.so()(64bit) qtparted - 0.4.5-15.fc8.ppc64 requires libparted-1.8.so.6()(64bit) skencil - 0.6.17-15.20070606svn.fc8.ppc64 requires libtcl8.4.so()(64bit) skencil - 0.6.17-15.20070606svn.fc8.ppc64 requires libtk8.4.so()(64bit) tcl-brlapi - 0.5.0-1.fc8.ppc64 requires libtcl8.4.so()(64bit) tcl-tcldict - 8.5.2-2.fc8.ppc64 requires tcl(abi) = 0:8.4 vtk - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) From marc at mwiriadi.id.au Mon Jan 7 13:48:00 2008 From: marc at mwiriadi.id.au (Marc Wiriadisastra) Date: Mon, 07 Jan 2008 22:48:00 +0900 Subject: [OT] Re: f8 gripe#2: why did f8's pm-hibernate regress? In-Reply-To: <1199711953.3244.41.camel@s1.crocom.com.pl> References: <477ADF46.2040108@filteredperception.org> <200801021159.17964.opensource@till.name> <477C299D.2060400@filteredperception.org> <477C96B8.6040903@filteredperception.org> <1199382316.3261.7.camel@sb-home> <1199482347.3035.9.camel@watson> <1199711953.3244.41.camel@s1.crocom.com.pl> Message-ID: <1199713680.20753.91.camel@localhost.localdomain> On Mon, 2008-01-07 at 14:19 +0100, Tomasz Torcz wrote: > Dnia 04-01-2008, pi? o godzinie 22:32 +0100, David Nielsen pisze: > > tor, 03 01 2008 kl. 18:45 +0100, skrev nodata: > > > I don't know why people keep saying this. Vista boots fast and is > > > responsive. > > > > Wow.. can I have a puff at that crack pipe my good man? :) > > Sorry for offtopic. Vista needs few days (weeks?) of use to prime its > readahead/preload? caches. It's slow just after install, but gets better > with time. One have to give this OS time for all its tricks to show. > > BTW, I'm not advocating for Vista. Just be serious and don't treat Vista > with prejudice. Fedora is doing readahead also, but in less > sophisticated way. http://preload.sf.net seems to be dead and broken by > prelink. Why not learn how others are doing similar things? > > ? http://en.wikipedia.org/wiki/Windows_Vista_I/O_technologies#SuperFetch > > -- > Tomasz Torcz > Crocom Computer Systems > That package is getting worked on at the moment and it's currently getting reviewed and hopefully included in Fedora soon. Cheers, Marc From alexl at users.sourceforge.net Mon Jan 7 14:01:50 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Mon, 07 Jan 2008 07:01:50 -0700 Subject: Is anyone packaging sage? In-Reply-To: (Kevin Kofler's message of "Sat\, 5 Jan 2008 10\:29\:05 +0000 \(UTC\)") References: Message-ID: >>>>> "KK" == Kevin Kofler writes: [...] KK> Please tell us of your progress and link to any review requests as KK> you submit them. If you need help with the dependencies, please KK> tell us that too. KK> I think we could really use a Mathematics SIG. Count me as KK> interested (I'm a PhD student in Mathematics). I think Rex Dieter KK> is likely to be interested too as he's working as a sysadmin for KK> the Department of Mathematics at UNL. (Of course we're both KK> already very busy with KDE SIG matters though. ;-) ) And as the KK> interest in this thread is showing, there's probably more KK> potentially interested folks. :-) SAGE looks very cool and is a potential Mathematica-killer (which would be a very good thing as Mathematica is one of the most proprietary apps around and has some of the most expensive license fees and some of the most draconian per-process licensing terms). So I'd be interested in helping out too. We don't have a Mathematics SIG per se, but there is a SciTech sig: http://fedoraproject.org/wiki/SIGs/SciTech which is pretty quiet enough as it is, more than 50% of the packages discussed there are mathematical anyway, so I don't see reason to create a new separate Mathematics SIG. I've added a link to SAGE on that page. Maybe somebody might like to transfer some of the discussion here to a subpage of SciTech. Alex From pertusus at free.fr Mon Jan 7 14:05:38 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 7 Jan 2008 15:05:38 +0100 Subject: autoconf driving me mad In-Reply-To: <4782242F.8060102@cs.tu-berlin.de> References: <4782242F.8060102@cs.tu-berlin.de> Message-ID: <20080107140538.GH2614@free.fr> On Mon, Jan 07, 2008 at 02:07:59PM +0100, Christoph H?ger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > hey there, > > i want to patch & build openccs under fedora. > So I have to do the autoconf/automake chain. No problem at all, but one > special thing makes me wanne cry: > > I see the following line in configure.in (yes its an relatively old > tarball): Are you using the same autoconf version that was used to generate th eupsteram tarball (and same automake)? There are older versions kept in fedora exactly for such issues. -- Pat From enrico.scholz at informatik.tu-chemnitz.de Mon Jan 7 14:18:06 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 07 Jan 2008 15:18:06 +0100 Subject: autoconf driving me mad In-Reply-To: <4782242F.8060102@cs.tu-berlin.de> (Christoph's message of "Mon, 07 Jan 2008 14:07:59 +0100") References: <4782242F.8060102@cs.tu-berlin.de> Message-ID: <87zlvhpvmp.fsf@fc5.bigo.ensc.de> Christoph H?ger writes: > I see the following line in configure.in (yes its an relatively old > tarball): > > GLOB_INCLUDE="-I${srcdir} -I${srcdir}/include" GLOB_INCLUDE='-I${top_srcdir} -I${top_srcdir}/include' (note the \' instead of \") should do what you want. Enrico From nphilipp at redhat.com Mon Jan 7 14:38:49 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 07 Jan 2008 15:38:49 +0100 Subject: Init : someone could comment this ? In-Reply-To: <874pdprg1p.fsf@fc5.bigo.ensc.de> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> Message-ID: <1199716729.18170.40.camel@gibraltar.str.redhat.com> On Mon, 2008-01-07 at 13:11 +0100, Enrico Scholz wrote: > Nils Philippsen writes: > > >> I think, nobody doubts that current initsystem is the worst one of > >> the major linux distributions. > > > > Can the hyperbole please -- we know what we have otherwise we wouldn't > > be having this discussion. > > I can not remember how long there are discussions about replacing > RH's initsystem (perhaps 5-6 years), and nothing happened. Other > distributions implemented more (upstart, syslog-ng) or less (suse, Is syslog-ng really an init system (if yes, it would have a mighty confusing name)? > mandriva) innovative methods in the meantime. And now, RH tries to > write its own implementation by adding some d-bus features and using > a bloaty scripting language around current initscripts? Currently, there are no "innovative" init systems that can really be called a standard. Therefore if the other available projects are found lacking in some areas, trying to come up with something new that meets the needs is an option that's perfectly fine with me. Mind that what will get used (something existing or something new) is still in discussion and not carved in stone yet, at least that's what I read from FCNewInit[1]. [1]: http://fedoraproject.org/wiki/FCNewInit > >> By changing paradigm from forking to non-forking daemon you can avoid > >> all the complicated 'stop' code; e.g. 'start' will be > >> > >> | pid = fork(); > >> | if (pid==0) { /* ... */ execve(...); } > >> > >> and 'stop' be > >> > >> | kill(pid, SIGTERM); /* wait for timeout/sigchld */ kill(pid, SIGKILL); > > > > That'd be all fine and dandy for daemons that simply need to be > > started > > how much resp. which daemons are not in this category? If all prerequisites can be assumed as given, then none. I'm not convinced that this assumption is a safe one to make. > > without any variable options > > options are trivially to solve; e.g. by an easy to parse one-option-per-line > configuration file or by 'argv = --foo --bar' stylish options in the service > description file. Unless you specify that the command line options of the daemons are a valid interface to have here, some logic to convert speaking configuration options into command line options is needed. Read the bzfs(6) manpage for an example with numerous, in part mutually exclusive command line options where I'd rather give the user something else which is easier to understand. > > or preparations > > trivially to be solved by executing helper scripts instead of the daemon > itself > > | #!/bin/sh > | ... do something ... > | exec "$@" There goes the advantage of not having to fork()/exec(). > > and are obliging enough to write pid files. > > pid files are an anachronism required for initsystems with forking > daemons There's no guarantee that the pid of the child process that the init system forked will be the pid of the long running process whom you need to send signals later on in order to end it. PID files are one way to find this out halfway deterministically. > > I don't think that e.g. the postgresql > > works perfectly in this way; e.g. I start it with > > | /usr/bin/setuidgid postgres /usr/bin/postmaster -D /var/lib/pgsql/data This only works because you assume some things as a given. To make the init process robust, services should check their prerequisites before starting, or even ensure that they are met (e.g. /etc/init.d/sshd generating host keys). > >> But python or other bloaty scripting languages are not a solution and > >> completely unacceptable at this place. > > > > "Bloaty" is something that could be solved, don't you think? > > Not with python or perl. I've shown you the numbers. Why you still insist on it being bloated beyond redemption is a mystery to me. It's more powerful than shell, but that's easy since shell in itself can't do much without resorting to external executables with all the fork()/exec() overhead involved. Being powerful is not the same as being bloated in my book. > Perhaps lua. But I really do not see why an > extra scripting language is required for the initsystem. sh/bash is > perfect for doing potential preparation tasks. Shell being perfect for anything beyond the most simple things is an opinion that I can't share, even if you avail yourself of using bashisms. > > bash takes up about 5.1MB. > > you mean the 750kb sized 'bash' binary and the >4 MB documentation plus > locale files? Most of the modules contain their own documentation as well. Granted, bash documentation is easier to strip away ;-). Anyway, my point was that this would be small enough that bothering about the size of it seems a waste of time. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From debarshi.ray at gmail.com Mon Jan 7 15:05:19 2008 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Mon, 7 Jan 2008 20:35:19 +0530 Subject: Is anyone packaging sage? In-Reply-To: <477EC690.9030904@kobold.org> References: <477EC690.9030904@kobold.org> Message-ID: <3170f42f0801070705g6fbc7f33r71a03d88c024ec99@mail.gmail.com> > Note that the name 'sage' conflicts with another package that already > lives in Fedora: > > https://admin.fedoraproject.org/pkgdb/packages/name/sage For what it is worth, Debian calls it libsage: http://packages.debian.org/stable/libdevel/libsage-dev Cheers, Debarshi From mzerqung at 0pointer.de Mon Jan 7 15:07:38 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Mon, 7 Jan 2008 16:07:38 +0100 Subject: Init : someone could comment this ? In-Reply-To: <878x32q8ao.fsf@fc5.bigo.ensc.de> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> Message-ID: <20080107150738.GA14386@tango.0pointer.de> On Mon, 07.01.08 10:44, Enrico Scholz (enrico.scholz at informatik.tu-chemnitz.de) wrote: > > Casey Dahlin writes: > > >>> A shell which emulates POSIX process handling in-process and uses > >>> direct builtin function calls for commands like sed [...] Pipes and > >>> the like would also have to be emulated > >> > >> For what do you need 'sed' or pipes to start/stop a daemon? > >> > > It appears at least 13 times in our current init system. > > I think, nobody doubts that current initsystem is the worst one of > the major linux distributions. By changing paradigm from forking to > non-forking daemon you can avoid all the complicated 'stop' code; > e.g. 'start' will be > > | pid = fork(); > | if (pid==0) { /* ... */ execve(...); } > > and 'stop' be > > | kill(pid, SIGTERM); /* wait for timeout/sigchld */ kill(pid, SIGKILL); This is not as simple as it might appear. Well behaving daemons don't detach before initialization is complete. This fact is implicitly used by SysV init to make sure that daemons which depend on each other (like in "Avahi needs D-Bus") to start in order, one after the other, but only after the predependencies have started up completely. There have been several ideas how signalling of startup completion could be handled in a better way. Some suggest that waiting for D-Bus name to appear might be a good solution. Scott Remnant had the idea to run "raise(SIGSTOP)" in the daemon after initialization completed. Then, the parent process will be signalled via SIGCHLD and as soon as it is it will kill(child, SIGCONT) and know that the next daemon can be started. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From bnocera at redhat.com Mon Jan 7 15:37:08 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 07 Jan 2008 15:37:08 +0000 Subject: Consider this for Fedora 9 Live CD In-Reply-To: <1198870962.7175.20.camel@localhost.localdomain> References: <64b14b300712281000l532c03f1u9e81ecdee8f3a3d5@mail.gmail.com> <1198865128.7175.4.camel@localhost.localdomain> <64b14b300712281012j3548675aida4af4c196364946@mail.gmail.com> <1198870962.7175.20.camel@localhost.localdomain> Message-ID: <1199720228.6584.35.camel@cookie.hadess.net> On Fri, 2007-12-28 at 14:42 -0500, John (J5) Palmieri wrote: > > Please also consider this RFE which can be easily fixed, but still in > > F8 it is not: > > https://bugzilla.redhat.com/show_bug.cgi?id=315141 > > I looked at this and wrote a comment. The gist of it is that this > functionality exists and is easy to turn on but is turned off by > default, most likely for good reasons. What's turned off? nautilus-cd-burner should be installed by default. You might just be having problems with the new gvfs/gio enabled nautilus though, not sure which version you tested. Cheers From choeger at cs.tu-berlin.de Mon Jan 7 15:37:23 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Mon, 07 Jan 2008 16:37:23 +0100 Subject: autoconf driving me mad In-Reply-To: <20080107140538.GH2614@free.fr> References: <4782242F.8060102@cs.tu-berlin.de> <20080107140538.GH2614@free.fr> Message-ID: <1199720243.22793.6.camel@s5.math.tu-berlin.de> Hi, it was originally built with autoconf-2.59, which is not available for fedora as I see in 'yum search autoconf' output. Am Montag, den 07.01.2008, 15:05 +0100 schrieb Patrice Dumas: > On Mon, Jan 07, 2008 at 02:07:59PM +0100, Christoph H?ger wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > hey there, > > > > i want to patch & build openccs under fedora. > > So I have to do the autoconf/automake chain. No problem at all, but one > > special thing makes me wanne cry: > > > > I see the following line in configure.in (yes its an relatively old > > tarball): > > Are you using the same autoconf version that was used to generate th > eupsteram tarball (and same automake)? There are older versions kept in > fedora exactly for such issues. > > -- > Pat > From choeger at cs.tu-berlin.de Mon Jan 7 15:37:19 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Mon, 07 Jan 2008 16:37:19 +0100 Subject: autoconf driving me mad In-Reply-To: <87zlvhpvmp.fsf@fc5.bigo.ensc.de> References: <4782242F.8060102@cs.tu-berlin.de> <87zlvhpvmp.fsf@fc5.bigo.ensc.de> Message-ID: <1199720239.22793.5.camel@s5.math.tu-berlin.de> Hi Thanks, I will give it a try, but does that stop the configure script from setting srcdir to . ? Am Montag, den 07.01.2008, 15:18 +0100 schrieb Enrico Scholz: > Christoph H?ger writes: > > > I see the following line in configure.in (yes its an relatively old > > tarball): > > > > GLOB_INCLUDE="-I${srcdir} -I${srcdir}/include" > > GLOB_INCLUDE='-I${top_srcdir} -I${top_srcdir}/include' > > (note the \' instead of \") should do what you want. > > > > Enrico > From ajackson at redhat.com Mon Jan 7 16:03:47 2008 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 07 Jan 2008 11:03:47 -0500 Subject: X in rawhide during install In-Reply-To: <1199630953.2155.5.camel@scrappy.miketc.com> References: <1199630953.2155.5.camel@scrappy.miketc.com> Message-ID: <1199721827.30771.583.camel@localhost.localdomain> On Sun, 2008-01-06 at 08:49 -0600, Mike Chambers wrote: > Last week, I said the heck with it and did a yum update to rawhide from > F8+updates. It performed OK but upon boot, x didn't want to come up, > and think the error messages was about version mismatches or something. > > Well, just now, I was going to do a fresh rawhide install on same > machine (wipe out F8 completely), but when it got to starting X to > perform the install, it wouldn't run, not even in vesa (from the quick > msg I saw come across), so it went into text mode (which I cancelled at > that time). Would it had worked if I had went ahead with the text mode > install, then tried to get X configured to start post-install? > > So, is xorg not fully functioning as of yet, with the new compiles that > went on recently and I am guessing still happening? > > This was on a PIV 2.8Ghz w/1G ram, and an X1300 ATI card. I'm not sure how often the anaconda stage2 images are built, which is where it gets the X drivers. I'm sure Jeremy's told me at some point though. The vesa and radeonhd drivers should both be working with rawhide though. If you go ahead with a text-mode install, you should get the abortive X logs in the installed system under /var/log/anaconda, I believe; it would be enlightening to see them. - ajax From pertusus at free.fr Mon Jan 7 15:44:51 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 7 Jan 2008 16:44:51 +0100 Subject: autoconf driving me mad In-Reply-To: <1199720243.22793.6.camel@s5.math.tu-berlin.de> References: <4782242F.8060102@cs.tu-berlin.de> <20080107140538.GH2614@free.fr> <1199720243.22793.6.camel@s5.math.tu-berlin.de> Message-ID: <20080107154451.GL2614@free.fr> On Mon, Jan 07, 2008 at 04:37:23PM +0100, Christoph H?ger wrote: > Hi, > > it was originally built with autoconf-2.59, which is not available for > fedora as I see in 'yum search autoconf' output. Indeed. The idea is that 2.61 is compatible with 2.59, though it doesn't seems like it is true in your case... -- Pat From enrico.scholz at informatik.tu-chemnitz.de Mon Jan 7 16:05:34 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 07 Jan 2008 17:05:34 +0100 Subject: Init : someone could comment this ? In-Reply-To: <1199716729.18170.40.camel@gibraltar.str.redhat.com> (Nils Philippsen's message of "Mon, 07 Jan 2008 15:38:49 +0100") References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> Message-ID: <87ve65pqnl.fsf@fc5.bigo.ensc.de> Nils Philippsen writes: >> I can not remember how long there are discussions about replacing >> RH's initsystem (perhaps 5-6 years), and nothing happened. Other >> distributions implemented more (upstart, syslog-ng) or less (suse, > > Is syslog-ng really an init system uups, I meant 'initng'. >> options are trivially to solve; e.g. by an easy to parse >> one-option-per-line configuration file or by 'argv = --foo --bar' >> stylish options in the service description file. > > Unless you specify that the command line options of the daemons > are a valid interface to have here, some logic to convert speaking > configuration options into command line options is needed. Read > the bzfs(6) manpage for an example with numerous, in part mutually > exclusive command line options where I'd rather give the user > something else which is easier to understand. I think, when somebody wants to run a server, he has to understand how it works and how to configure it. When admin can not figure out correct cmdline options, how can he configure the server in a secure manner? >> > or preparations >> >> trivially to be solved by executing helper scripts instead of the daemon >> itself >> >> | #!/bin/sh >> | ... do something ... >> | exec "$@" > > There goes the advantage of not having to fork()/exec(). There is absolutely no problem with fork()/exec(); performance depends on the program being executed. E.g. 'fnord' HTTP server which is started (fork(2) + execve(2)) by tcpserver (an inetd like program) for every new request is faster than apache httpd with no-pipelined requests. When '... do something ...' is | if test ! -e /etc/ssh/ssh_host_key/...'; then ... expensive tasks ...; fi there will be "only" the overhead of /one/ execve("/bin/sh", ...) ('test' is a bash builtin) compared to the plain 'execve("", ...)'. The number of fork()'s stays constant. The real overhead is in loading '/bin/sh' and in interpreting the script. >> > and are obliging enough to write pid files. >> >> pid files are an anachronism required for initsystems with forking >> daemons > > There's no guarantee that the pid of the child process that the init > system forked will be the pid of the long running process then, the program is broken... >> | /usr/bin/setuidgid postgres /usr/bin/postmaster -D /var/lib/pgsql/data > > This only works because you assume some things as a given. And these things *are* given. Current postgresql's initscript is complicated because it contains code being executed exactly once. Speaking in initng terms, you could write --- daemons/postgresql ---- use = scripts/postgresql-prepare # depend on it only, when activated daemon = postmaster -D ... --- scripts/postgresql-prepare exec = /usr/libexec/postgresql-prepare --- /usr/lib/postgresql/postgresql-prepare --- #! /bin/sh ... initng-chkconfig scripts/postgresql-prepare off This means, the expensive (has to spawn /bin/sh) -prepare script turns off itself after running once. > To make the init process robust, services should check their prerequisites > before starting, or even ensure that they are met (e.g. /etc/init.d/sshd > generating host keys). Question is where to draw the line. E.g. do you make 'rpm -V postgresql' to verify that program is not corrupted? >> >> But python or other bloaty scripting languages are not a solution >> >> and completely unacceptable at this place. >> > >> > "Bloaty" is something that could be solved, don't you think? >> >> Not with python or perl. > > I've shown you the numbers. Why you still insist on it being bloated Resulting scripts will be much longer. E.g. how much lines of python code are required for | sed '/^foo/s!/bin!/opt!' file | tac ? Most time in preparation code will be spent in "payload" (e.g. ssh-keygen). > beyond redemption is a mystery to me. It's more powerful than shell, > but that's easy since shell in itself can't do much without resorting > to external executables with all the fork()/exec() overhead involved. Usually, preparation code will be executed only once. And I do not care about whether first startup needs 40 or 20 seconds. But I care about, whether regular startup needs 20 or 15 seconds. And there *is* the bloat of initializing the python runtime environment which can make this difference. >> Perhaps lua. But I really do not see why an extra scripting language >> is required for the initsystem. sh/bash is perfect for doing potential >> preparation tasks. > > Shell being perfect for anything beyond the most simple things is an > opinion that I can't share, even if you avail yourself of using > bashisms. What are you missing specifically? Enrico From enrico.scholz at informatik.tu-chemnitz.de Mon Jan 7 16:31:29 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 07 Jan 2008 17:31:29 +0100 Subject: Init : someone could comment this ? In-Reply-To: <20080107150738.GA14386@tango.0pointer.de> (Lennart Poettering's message of "Mon, 7 Jan 2008 16:07:38 +0100") References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <20080107150738.GA14386@tango.0pointer.de> Message-ID: <87r6gtppge.fsf@fc5.bigo.ensc.de> Lennart Poettering writes: >> the major linux distributions. By changing paradigm from forking to >> non-forking daemon you can avoid all the complicated 'stop' code; >> e.g. 'start' will be >> >> | pid = fork(); >> | if (pid==0) { /* ... */ execve(...); } >> >> and 'stop' be >> >> | kill(pid, SIGTERM); /* wait for timeout/sigchld */ kill(pid, SIGKILL); > > This is not as simple as it might appear. Well behaving daemons don't > detach before initialization is complete. That has the problem that heuristics like pid-files must be used to check/modify status of daemons. Has the problem too that only one state of "complete" is possible. But e.g. for dhclient the state 'link was brought up' might be interesting. > This fact is implicitly used by SysV init to make sure that daemons > which depend on each other (like in "Avahi needs D-Bus") meaning of "complete" depends on the program. E.g. waiting for completeness of udevd can be done by 'wait-for /dev/.udev'. It is an implementation detail of the initsystem, whether to detect it with external tools or by adding builtin functionality. E.g. udevd init might like like --- system/udevd --- need = scripts/udevd-wait --- scripts/udevd-wait need = daemon/udevd-daemon exec = some-inotify-tool --wait-for-file /dev/.udev # external tool wait_for = /dev/.udev # builtin --- daemon/udevd-daemon daemon = udevd Enrico From lesmikesell at gmail.com Mon Jan 7 16:35:43 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 07 Jan 2008 10:35:43 -0600 Subject: Init : someone could comment this ? In-Reply-To: <20080107120349.GA15518@devserv.devel.redhat.com> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> <20080107120349.GA15518@devserv.devel.redhat.com> Message-ID: <478254DF.9070308@gmail.com> Alan Cox wrote: > On Mon, Jan 07, 2008 at 05:35:33AM +0000, Kevin Kofler wrote: >> AFAIK, busybox still forks whereever a regular POSIX shell forks, so if the >> amount of forks is the problem, AFAICT busybox will resolve absolutely nothing. > > Fork should be pretty cheap - although that depends how much memory is unshared > by each of the resulting tasks. A smaller cleaner shell such as rc (which was > designed for this job in plan 9) or ash might well perform better. I'm dubious > it would be a big difference but someone can bench it. If a unix-like system can't fork/exec at a rate suitable to handle starting it's initial processes you should throw the whole system out and start over, because it will be useless even after you get it running. I think the real problem you need to solve is the number of file opens that happen between boot up and the end of the init script processing. This: http://kernelslacker.livejournal.com/35270.html and the presentation on the topic at Oscon looked pretty horrible and won't be fixed by using a dumber shell to parse the scripts. And note that the suggestion to break out lines of configurations into individual files for easier programmatic editing just compounds this already serious problem. -- Les Mikesell lesmikesell at gmail.com From jdennis at redhat.com Mon Jan 7 16:50:57 2008 From: jdennis at redhat.com (John Dennis) Date: Mon, 07 Jan 2008 11:50:57 -0500 Subject: Another selinux rant In-Reply-To: <1199677167.6022.102.camel@beck.corsepiu.local> References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <1199514823.6022.62.camel@beck.corsepiu.local> <16de708d0801042336n2fe73d69o62afe39c1583eb61@mail.gmail.com> <1199592013.6022.83.camel@beck.corsepiu.local> <4781690D.7040802@ncsu.edu> <1199677167.6022.102.camel@beck.corsepiu.local> Message-ID: <47825871.6040006@redhat.com> Ralf Corsepius wrote: >> And have you done with this bug what I'm sure we all know we are >> supposed to do with bugs we find? :P > Done right now. > > This morning's reboot gave me another opportunity to take a somewhat > deeper look ;) > > https://bugzilla.redhat.com/show_bug.cgi?id=427721 Thank you Ralf, following up with a bugzilla is very much appreciated. The key to diagnosing the problem is right there in the syslog: setroubleshoot: [program.ERROR] Can not handle AVC'S related to the dispatcher. exiting tcontext=unconfined_u:system_r:setroubleshootd_t:s0 scontext=unconfined_u:system_r:setroubleshootd_t:s0 This means setroubleshootd saw an AVC that it generated itself. This should never happen and to prevent infinite recursion the daemon shuts down. This is most likely due to a policy bug. There were some known policy bugs early in F8 (before GOLD) related to setroubleshoot but those should have been fixed. Is your policy up to date? -- John Dennis From michael.wiktowy at gmail.com Mon Jan 7 17:06:14 2008 From: michael.wiktowy at gmail.com (Michael Wiktowy) Date: Mon, 7 Jan 2008 12:06:14 -0500 Subject: Another selinux rant In-Reply-To: <47825871.6040006@redhat.com> References: <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <1199514823.6022.62.camel@beck.corsepiu.local> <16de708d0801042336n2fe73d69o62afe39c1583eb61@mail.gmail.com> <1199592013.6022.83.camel@beck.corsepiu.local> <4781690D.7040802@ncsu.edu> <1199677167.6022.102.camel@beck.corsepiu.local> <47825871.6040006@redhat.com> Message-ID: <3e4ec4600801070906j460b5cw80bd455dda36c142@mail.gmail.com> On Jan 7, 2008 11:50 AM, John Dennis wrote: > Ralf Corsepius wrote: > >> And have you done with this bug what I'm sure we all know we are > >> supposed to do with bugs we find? :P > > Done right now. > > > > This morning's reboot gave me another opportunity to take a somewhat > > deeper look ;) > > > > https://bugzilla.redhat.com/show_bug.cgi?id=427721 > > Thank you Ralf, following up with a bugzilla is very much appreciated. > The key to diagnosing the problem is right there in the syslog: > > setroubleshoot: [program.ERROR] Can not handle AVC'S related to the > dispatcher. exiting > > tcontext=unconfined_u:system_r:setroubleshootd_t:s0 > scontext=unconfined_u:system_r:setroubleshootd_t:s0 > > This means setroubleshootd saw an AVC that it generated itself. This > should never happen and to prevent infinite recursion the daemon shuts > down. This is most likely due to a policy bug. There were some known > policy bugs early in F8 (before GOLD) related to setroubleshoot but > those should have been fixed. Is your policy up to date? I have been seeing the same thing very recently with a fully up to date F8 installation that has never seen Rawhide. I thought that it was related to my LiveCD creation but I had setroubleshoot applet disconnect from the selinux deamon soon after my Sunday log rotation. I will add my logs to this bug when I get a chance. /Mike From mcanonic at libero.it Mon Jan 7 17:00:54 2008 From: mcanonic at libero.it (Massimo Canonico) Date: Mon, 07 Jan 2008 18:00:54 +0100 Subject: tgif does not work on fedora 8 Message-ID: <47825AC6.20205@libero.it> Hi, I have tested tgif in various fedora 8 installation, but no one can properly run tgif by "yum install" command". In particular, on fedora 8 32bit after "yum install tgif" without problem, if I try to use tgif I got this error: [user at shrek ~]# tgif Warning: No type converter registered for 'String' to 'Bitmap' conversion. Cannot load fontset specified by Tgif.MenuFontSet: '-*-helvetica-medium-r-normal--12-*-*-*-*-*-*-*,-alias-*-medium-r-normal--12-*-*-*-*-*-*-*'. Warning: Cannot set InitialFont to 'Ryumin'. SIGFPE signal received. Using the rpm on tgif's homepage ftp://bourbon.usc.edu/pub/tgif/bin/linux-glibc/4.1.45/tgif-4.1.45-1.i386.rpm I'm able to run it properly. I have contacted the tgif's developers and he has no idea what is the problem, he said:" So, I'm guessing that the executable may be compiled with different flags (or the code has been modified). I guess it would be difficult to figure out the differences" Could you help me please? M From nphilipp at redhat.com Mon Jan 7 17:27:35 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 07 Jan 2008 18:27:35 +0100 Subject: Init : someone could comment this ? In-Reply-To: <87ve65pqnl.fsf@fc5.bigo.ensc.de> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> Message-ID: <1199726855.20392.1.camel@gibraltar.str.redhat.com> On Mon, 2008-01-07 at 17:05 +0100, Enrico Scholz wrote: > Nils Philippsen writes: > > Unless you specify that the command line options of the daemons > > are a valid interface to have here, some logic to convert speaking > > configuration options into command line options is needed. Read > > the bzfs(6) manpage for an example with numerous, in part mutually > > exclusive command line options where I'd rather give the user > > something else which is easier to understand. > > I think, when somebody wants to run a server, he has to understand how > it works and how to configure it. When admin can not figure out correct > cmdline options, how can he configure the server in a secure manner? Along that line, everybody should be able to run configure && make && make install and wrap their own packages, so why should we bother ;-)? Seriously, I can cope with command line arguments and still like sysconfig files that are more understandable than just plain "OPTS='--foo -x=y -a'". I'm happy if I get things done without having to read the documentation for the common case. I'm not saying admins shouldn't be able to influence the cmd line options directly if they wish. > The real overhead is in loading '/bin/sh' and in interpreting the script. Agreed, I got this wrong. > >> > and are obliging enough to write pid files. > >> > >> pid files are an anachronism required for initsystems with forking > >> daemons > > > > There's no guarantee that the pid of the child process that the init > > system forked will be the pid of the long running process > > then, the program is broken... I don't think that there's a standard -- de-facto or written down -- that mandates this. > > To make the init process robust, services should check their prerequisites > > before starting, or even ensure that they are met (e.g. /etc/init.d/sshd > > generating host keys). > > Question is where to draw the line. E.g. do you make 'rpm -V postgresql' > to verify that program is not corrupted? You know what I mean -- verifying the package integrity is just silly. > Resulting scripts will be much longer. E.g. how much lines of python > code are required for > > | sed '/^foo/s!/bin!/opt!' file | tac > > ? Where would you find such a line in an init script? I could construe and equally short line in python that would take much more to be implemented in shell and tools. That proves nothing. > > Most time in preparation code will be spent in "payload" (e.g. ssh-keygen). > > > > beyond redemption is a mystery to me. It's more powerful than shell, > > but that's easy since shell in itself can't do much without resorting > > to external executables with all the fork()/exec() overhead involved. > > Usually, preparation code will be executed only once. And I do not care > about whether first startup needs 40 or 20 seconds. But I care about, > whether regular startup needs 20 or 15 seconds. > > And there *is* the bloat of initializing the python runtime environment > which can make this difference. The thing with the python runtime is that you'd only need to initialize it once. Thanks to proper use of namespaces and exceptions one actually can try to load other python modules into the same address space and not make the whole process unstable. An empty python script takes between 10ms and 30ms start to finish on my machine here. If that initialization time is taken only once, that's unlikely to be a bottleneck. > >> Perhaps lua. But I really do not see why an extra scripting language > >> is required for the initsystem. sh/bash is perfect for doing potential > >> preparation tasks. > > > > Shell being perfect for anything beyond the most simple things is an > > opinion that I can't share, even if you avail yourself of using > > bashisms. > > What are you missing specifically? Powerful string ops come to mind, built-in regular expressions or exceptions. I can get by without, but once you're used to it ;-). Note that I'm not necessarily favouring a python-based init tool, I'm just not buying your arguments against it. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From mzerqung at 0pointer.de Mon Jan 7 17:35:08 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Mon, 7 Jan 2008 18:35:08 +0100 Subject: Init : someone could comment this ? In-Reply-To: <87ve65pqnl.fsf@fc5.bigo.ensc.de> References: <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> Message-ID: <20080107173508.GA23429@tango.0pointer.de> On Mon, 07.01.08 17:05, Enrico Scholz (enrico.scholz at informatik.tu-chemnitz.de) wrote: > >> I can not remember how long there are discussions about replacing > >> RH's initsystem (perhaps 5-6 years), and nothing happened. Other > >> distributions implemented more (upstart, syslog-ng) or less (suse, > > > > Is syslog-ng really an init system > > uups, I meant 'initng'. Everytime I hear someone mentioning initng I get a headache. They got almost everything wrong you can get wrong in an init system. The kept the worst things from SysV (such as numerical "runlevels"), and added the worst things they could find in other people's software. Like the braindeadness to make everything a shared object, including stuff like executing chdir(). Can you believe that? They have a "plugin" to change a directory which consists of 100 lines or code or so. Unbelievable... Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From cjdahlin at ncsu.edu Mon Jan 7 17:35:39 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Mon, 07 Jan 2008 12:35:39 -0500 Subject: Init : someone could comment this ? In-Reply-To: <20080107173508.GA23429@tango.0pointer.de> References: <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <20080107173508.GA23429@tango.0pointer.de> Message-ID: <478262EB.8050407@ncsu.edu> Lennart Poettering wrote: > On Mon, 07.01.08 17:05, Enrico Scholz (enrico.scholz at informatik.tu-chemnitz.de) wrote: > > >>>> I can not remember how long there are discussions about replacing >>>> RH's initsystem (perhaps 5-6 years), and nothing happened. Other >>>> distributions implemented more (upstart, syslog-ng) or less (suse, >>>> >>> Is syslog-ng really an init system >>> >> uups, I meant 'initng'. >> > > Everytime I hear someone mentioning initng I get a headache. > > They got almost everything wrong you can get wrong in an init > system. The kept the worst things from SysV (such as numerical > "runlevels"), and added the worst things they could find in other > people's software. Like the braindeadness to make everything a shared > object, including stuff like executing chdir(). Can you believe that? > They have a "plugin" to change a directory which consists of 100 lines > or code or so. Unbelievable... > > Lennart > > This is all very useful. I am proposing a session at FUDcon to explore the options, and to definitively pick a solution. Hopefully the following day's hackfest will see direct effort toward implementing a solution. From cjdahlin at ncsu.edu Mon Jan 7 17:38:02 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Mon, 07 Jan 2008 12:38:02 -0500 Subject: Init : someone could comment this ? In-Reply-To: <478254DF.9070308@gmail.com> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> <20080107120349.GA15518@devserv.devel.redhat.com> <478254DF.9070308@gmail.com> Message-ID: <4782637A.8050203@ncsu.edu> Les Mikesell wrote: > Alan Cox wrote: >> On Mon, Jan 07, 2008 at 05:35:33AM +0000, Kevin Kofler wrote: >>> AFAIK, busybox still forks whereever a regular POSIX shell forks, so >>> if the amount of forks is the problem, AFAICT busybox will resolve >>> absolutely nothing. >> >> Fork should be pretty cheap - although that depends how much memory >> is unshared >> by each of the resulting tasks. A smaller cleaner shell such as rc >> (which was >> designed for this job in plan 9) or ash might well perform better. >> I'm dubious >> it would be a big difference but someone can bench it. > > If a unix-like system can't fork/exec at a rate suitable to handle > starting it's initial processes you should throw the whole system out > and start over, because it will be useless even after you get it > running. I think the real problem you need to solve is the number of > file opens that happen between boot up and the end of the init script > processing. This: http://kernelslacker.livejournal.com/35270.html > and the presentation on the topic at Oscon looked pretty horrible and > won't be fixed by using a dumber shell to parse the scripts. And note > that the suggestion to break out lines of configurations into > individual files for easier programmatic editing just compounds this > already serious problem. > Its not the fork or exec per se. It is the disk IO associated with loading the binary images. Normally this isn't too much of an issue, but in the highly IO-sensitive init process it can cause huge issues. Remember, seek time is the big issue with disk IO, so size of data to load is not the metric to go by. From lsof at nodata.co.uk Mon Jan 7 17:46:29 2008 From: lsof at nodata.co.uk (nodata) Date: Mon, 07 Jan 2008 18:46:29 +0100 Subject: Init : someone could comment this ? In-Reply-To: <4782637A.8050203@ncsu.edu> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> <20080107120349.GA15518@devserv.devel.redhat.com> <478254DF.9070308@gmail.com> <4782637A.8050203@ncsu.edu> Message-ID: <1199727989.4914.0.camel@sb-home> Am Montag, den 07.01.2008, 12:38 -0500 schrieb Casey Dahlin: > Les Mikesell wrote: > > Alan Cox wrote: > >> On Mon, Jan 07, 2008 at 05:35:33AM +0000, Kevin Kofler wrote: > >>> AFAIK, busybox still forks whereever a regular POSIX shell forks, so > >>> if the amount of forks is the problem, AFAICT busybox will resolve > >>> absolutely nothing. > >> > >> Fork should be pretty cheap - although that depends how much memory > >> is unshared > >> by each of the resulting tasks. A smaller cleaner shell such as rc > >> (which was > >> designed for this job in plan 9) or ash might well perform better. > >> I'm dubious > >> it would be a big difference but someone can bench it. > > > > If a unix-like system can't fork/exec at a rate suitable to handle > > starting it's initial processes you should throw the whole system out > > and start over, because it will be useless even after you get it > > running. I think the real problem you need to solve is the number of > > file opens that happen between boot up and the end of the init script > > processing. This: http://kernelslacker.livejournal.com/35270.html > > and the presentation on the topic at Oscon looked pretty horrible and > > won't be fixed by using a dumber shell to parse the scripts. And note > > that the suggestion to break out lines of configurations into > > individual files for easier programmatic editing just compounds this > > already serious problem. > > > Its not the fork or exec per se. It is the disk IO associated with > loading the binary images. Normally this isn't too much of an issue, but > in the highly IO-sensitive init process it can cause huge issues. > Remember, seek time is the big issue with disk IO, so size of data to > load is not the metric to go by. > So is this frequently loaded binary not being loaded from the disk cache? From lesmikesell at gmail.com Mon Jan 7 17:49:56 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 07 Jan 2008 11:49:56 -0600 Subject: Init : someone could comment this ? In-Reply-To: <1199726855.20392.1.camel@gibraltar.str.redhat.com> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <1199726855.20392.1.camel@gibraltar.str.redhat.com> Message-ID: <47826644.9030500@gmail.com> Nils Philippsen wrote: >> I think, when somebody wants to run a server, he has to understand how >> it works and how to configure it. When admin can not figure out correct >> cmdline options, how can he configure the server in a secure manner? > > Along that line, everybody should be able to run configure && make && > make install and wrap their own packages, so why should we bother ;-)? > Seriously, I can cope with command line arguments and still like > sysconfig files that are more understandable than just plain > "OPTS='--foo -x=y -a'". I'm happy if I get things done without having to > read the documentation for the common case. I'm not saying admins > shouldn't be able to influence the cmd line options directly if they > wish. If you change that to some abstraction that you think is easier to understand, how do you propose (a) that sysadmins that already knew the real options should deal with the now confusing abstraction and (b) that the abstraction (and its documentation) always stays in sync with upstream changes/additions to the underlying program's options? It is already fairly messy trying to track what options have been moved to new locations under /etc/sysconfig in fedora/RH boxes and which are still in their normal locations. -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Mon Jan 7 17:59:41 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 07 Jan 2008 11:59:41 -0600 Subject: Init : someone could comment this ? In-Reply-To: <20080107173508.GA23429@tango.0pointer.de> References: <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <20080107173508.GA23429@tango.0pointer.de> Message-ID: <4782688D.4030404@gmail.com> Lennart Poettering wrote: > Everytime I hear someone mentioning initng I get a headache. > > They got almost everything wrong you can get wrong in an init > system. The kept the worst things from SysV (such as numerical > "runlevels"), What's wrong with numerical runlevels other than Linux flavors starting the network in level 2 instead of 3? -- Les Mikesell lesmikesell at gmail.com From notting at redhat.com Mon Jan 7 18:01:51 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 7 Jan 2008 13:01:51 -0500 Subject: hardware-support comps group In-Reply-To: <1199222860.6673.6.camel@rousalka.dyndns.org> References: <1199222860.6673.6.camel@rousalka.dyndns.org> Message-ID: <20080107180151.GA19651@nostromo.devel.redhat.com> Nicolas Mailhot (nicolas.mailhot at laposte.net) said: > Hi, (and happy new year) > > Would it make sense to create a comps group for packages that need to be > updated regularly for fedora to have good hardware support? (kernel, > sane, xorg drivers, printer drivers, dcraw, etc) And then check > regularly (via a script or human auditing) none of the bits in this > group are stale? > > Or is it something best left to the maintainers of each of those > packages? Not sure why this would be in comps, as it's not something that should ever be exposed in that way. Out-of-band seems simpler. Bill From enrico.scholz at informatik.tu-chemnitz.de Mon Jan 7 18:05:12 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 07 Jan 2008 19:05:12 +0100 Subject: Init : someone could comment this ? In-Reply-To: <20080107173508.GA23429@tango.0pointer.de> (Lennart Poettering's message of "Mon, 7 Jan 2008 18:35:08 +0100") References: <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <20080107173508.GA23429@tango.0pointer.de> Message-ID: <87tzlp8qav.fsf@kosh.bigo.ensc.de> Lennart Poettering writes: > Everytime I hear someone mentioning initng I get a headache. > > They got almost everything wrong you can get wrong in an init > system. ack; they had bad code quality which was tried to be solved with stupid ideas like a garbage collector, or now they are back at (ba)sh based initscripts. But ideas like declarative init"scripts", the use/require concept are a real improvement compared with SysV init. > The kept the worst things from SysV (such as numerical "runlevels"), and > added the worst things they could find in other people's software. Like > the braindeadness to make everything a shared object, including stuff like > executing chdir(). Can you believe that? Yes; its like the basearchonly plugin of yum or the tab-mix-plus plugin of firefox. More or less trivial stuff and used by most people, but author does not want it in code base. Enrico From jonathan.underwood at gmail.com Mon Jan 7 18:10:13 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 7 Jan 2008 18:10:13 +0000 Subject: Init : someone could comment this ? In-Reply-To: <478262EB.8050407@ncsu.edu> References: <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <20080107173508.GA23429@tango.0pointer.de> <478262EB.8050407@ncsu.edu> Message-ID: <645d17210801071010g6ba535fdqdb724d00243f28e2@mail.gmail.com> On 07/01/2008, Casey Dahlin wrote: > I am proposing a session at FUDcon to explore the options, and to > definitively pick a solution. Hopefully the following day's hackfest > will see direct effort toward implementing a solution. Having a read of this document proves very enlightening about the issues that need to be addressed in designing a replacement init: https://lists.ubuntu.com/archives/upstart-devel/2007-September/000463.html From mzerqung at 0pointer.de Mon Jan 7 18:12:20 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Mon, 7 Jan 2008 19:12:20 +0100 Subject: Init : someone could comment this ? In-Reply-To: <478262EB.8050407@ncsu.edu> References: <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <20080107173508.GA23429@tango.0pointer.de> <478262EB.8050407@ncsu.edu> Message-ID: <20080107181220.GB30406@tango.0pointer.de> On Mon, 07.01.08 12:35, Casey Dahlin (cjdahlin at ncsu.edu) wrote: >> Everytime I hear someone mentioning initng I get a headache. >> >> They got almost everything wrong you can get wrong in an init >> system. The kept the worst things from SysV (such as numerical >> "runlevels"), and added the worst things they could find in other >> people's software. Like the braindeadness to make everything a shared >> object, including stuff like executing chdir(). Can you believe that? >> They have a "plugin" to change a directory which consists of 100 lines >> or code or so. Unbelievable... >> >> Lennart >> >> > This is all very useful. > > I am proposing a session at FUDcon to explore the options, and to > definitively pick a solution. Hopefully the following day's hackfest will > see direct effort toward implementing a solution. "Definitively" picking a solution? Unfortunately I don't see that any of the currently available init implementations get things right in a way that we could "definitively" pick it. The only one of the new systems that has good code is Upstart. However, in my understanding it got everything hooked up the wrong way round. I.e. instead of having other daemons contact Upstart to start and stop services it itself hooks into all kind of "events". A couple of RH and Novell people discussed that with Scott at this years GUADEC conference a while back. I think we managed to convince him that this should be changed. The result is his new Initkit project. However, that's still in its infancy and will take some time to be useful. This however means that now adopting Upstart would be investing in a project that's going to be replaced soonishly anyway. Also, Ubuntu uses Upstart mostly in SysV compatibility mode right now. So, in short: initng is a joke, initkit not ready yet, upstart a bit of a moving target that's going to be replaced soon anyway. The other systems seem to be too simple (minit, runit) or totally un-Linuxish (SMF, launchd). I think our safest bet for now is to stay with SysV but spice it up a little bit with LSB headers to allow parallel startup, like Debian is doing it now. And then, let's wait what Scott comes up with in InitKit. Given that he's a Canonical guy, and both RH and Novell engineers discussed Upstart in lengths with him I hope that this is also the best bet to get something done that is adopted by all "big three" distributions, working a bit against the balkanization of Linux userspace. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From vpivaini at cs.helsinki.fi Mon Jan 7 18:23:24 2008 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Mon, 7 Jan 2008 20:23:24 +0200 Subject: Help with packaging tmispell-voikko (Ispell compatible Finnish spellchecking) In-Reply-To: <200712282248.21314.vpivaini@cs.helsinki.fi> References: <200712282248.21314.vpivaini@cs.helsinki.fi> Message-ID: <200801072023.25274.vpivaini@cs.helsinki.fi> Hi, To get the ball rolling regarding tmispell-voikko, I have submitted a review request here: . This Spec/SRPM doesn't try to do any ispell integration yet, hopefully I'll get some help on that later. -- Ville-Pekka Vainio From mzerqung at 0pointer.de Mon Jan 7 18:26:48 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Mon, 7 Jan 2008 19:26:48 +0100 Subject: Init : someone could comment this ? In-Reply-To: <4782688D.4030404@gmail.com> References: <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <20080107173508.GA23429@tango.0pointer.de> <4782688D.4030404@gmail.com> Message-ID: <20080107182648.GC30406@tango.0pointer.de> On Mon, 07.01.08 11:59, Les Mikesell (lesmikesell at gmail.com) wrote: > > Lennart Poettering wrote: >> Everytime I hear someone mentioning initng I get a headache. >> They got almost everything wrong you can get wrong in an init >> system. The kept the worst things from SysV (such as numerical >> "runlevels"), > > What's wrong with numerical runlevels other than Linux flavors starting the > network in level 2 instead of 3? They don't make any sense, that's wrong with them. Why only 6 of them? I never understood why a process like "shutdown" or "reboot" should be considered a "level". Do you? Nobody knows what the actually mean. They are using numeric ids for no reason. I mean, people invented stuff like DNS for not having to deal with random numbers that often. Why should they deal with random numbers when dealing with init systems, then? Almost all distributions use only 2 or 3 of them. Their configuration is plain awful. They're totally awkward, because there are numeric levels and the magic runlevel S. Also, init doesn't really have any information what service is running in which one is not for the current runlevel. To work around that the configuration is highly redundant with lots of symlinks. Then, on the philosophical level, having a single set of "runlevels" just doesn't cut it, because services these days should only be started maybe when a certain HW is around, or when some specific user software runs that wants to make use of it. How do runlevels fit into that? They are too static to reflect this dynamic way of starting and stopping services properly. In short, they don't make any sense. They should die. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From enrico.scholz at informatik.tu-chemnitz.de Mon Jan 7 18:27:53 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 07 Jan 2008 19:27:53 +0100 Subject: Init : someone could comment this ? In-Reply-To: <1199726855.20392.1.camel@gibraltar.str.redhat.com> (Nils Philippsen's message of "Mon, 07 Jan 2008 18:27:35 +0100") References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <1199726855.20392.1.camel@gibraltar.str.redhat.com> Message-ID: <87prwd8p92.fsf@kosh.bigo.ensc.de> Nils Philippsen writes: >> > There's no guarantee that the pid of the child process that the init >> > system forked will be the pid of the long running process >> >> then, the program is broken... > > I don't think that there's a standard -- de-facto or written down -- > that mandates this. sorry, but a design like parent |-- child0 `- child1 where signals must be sent to child0 to control parent + child1 smells somehow broken. >> > To make the init process robust, services should check their >> > prerequisites before starting, or even ensure that they are met >> > (e.g. /etc/init.d/sshd generating host keys). >> >> Question is where to draw the line. E.g. do you make 'rpm -V postgresql' >> to verify that program is not corrupted? > > You know what I mean no >> Resulting scripts will be much longer. E.g. how much lines of python >> code are required for >> >> | sed '/^foo/s!/bin!/opt!' file | tac > > Where would you find such a line in an init script? Does it look so uncommon? 'sed' is used very often, pipes too. 'tac' can be there too, e.g. with a trailing 'sed "1p;d"' >> What are you missing specifically? > > Powerful string ops come to mind, which string ops other than ${..##..} + ${..%%..} do you need in initscripts? > built-in regular expressions or where do you need regexps in initscripts? > exceptions set -e Enrico From notting at redhat.com Mon Jan 7 18:38:03 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 7 Jan 2008 13:38:03 -0500 Subject: Potential bad dependencies: NetworkManager-gnome, totem and system-config-display In-Reply-To: <477D7812.9070205@fedoraproject.org> References: <477D7812.9070205@fedoraproject.org> Message-ID: <20080107183803.GB19651@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: > While creating the Xfce spin for Fedora 8, I noticed a few packages seem to > have a bad dependency list. NetworkManager-gnome has a hard dependency on > things like gnome-panel and gnome-keyring. Totem has a hard dependency on > gnome-desktop and gnome-themes. system-config-display has a hard dependency > on metacity. Are these really required? gnome-keyring, gnome-desktop, metacity - definitely. You can file bugs about the others if you feel strongly, but they may be hard requirements as well. Bill From skasal at redhat.com Mon Jan 7 19:01:54 2008 From: skasal at redhat.com (Stepan Kasal) Date: Mon, 7 Jan 2008 20:01:54 +0100 Subject: autoconf driving me mad In-Reply-To: <4782242F.8060102@cs.tu-berlin.de> References: <4782242F.8060102@cs.tu-berlin.de> Message-ID: <20080107190154.GA26540@camelia.ucw.cz> Hello, On Mon, Jan 07, 2008 at 02:07:59PM +0100, Christoph H?ger wrote: > GLOB_INCLUDE="-I${srcdir} -I${srcdir}/include" > AC_SUBST(GLOB_INCLUDE) variables like srcdir, top_srcdir, top_builddir, and such are not available for the shell code in the configure.ac. The manual does not mention them. (Yes, there is something about having the available in AC_CONFIG_* macros, but that's not the case here.) These variables are available in the file _created_ by configure, specifically in the makefiles. So, formally speaking, the observed problem with backward compatibility of 2.61 is caused by relying on undocumented features in the autoconfigury of openccs. Let me outline the way to fix this. src/make.rules should use $(top_srcdir) and such like this: GLOB_INCLUDE = \ -I$(top_srcdir) \ -I$(top_srcdir)/include TOOLS_INCLUDE = \ -I$(top_srcdir)/shared/rte \ -I$(top_builddir)/shared/comm \ -I$(top_srcdir)/shared/comm \ -I$(top_srcdir)/shared/filterIdent \ -I$(top_srcdir)/shared/tools AM_CPPFLAGS = $(GLOB_DEFINES) $(GLOB_INCLUDE) $(TOOLS_INCLUDE) Note: - the two lines quoted in the top of this mail should go away from configure.in, GLOB_INCLUDE in defined directly in make.rules - likewise, TOOLS_INCLUDE shall not be AC_SUBSTed - some Makefile.am contain INCLUDE = @GLOB_INCLUDE@ and such; these are redundant and should go away - $(GLOB_DEFINES) works even though it is not spelled as @...@; thats because all AC_SUBSTed variables are inherited in makefiles Hope this explanation will drag you back to the sane world. ;-) Have a nice day, Stepan Kasal From sundaram at fedoraproject.org Mon Jan 7 18:53:01 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 08 Jan 2008 00:23:01 +0530 Subject: Potential bad dependencies: NetworkManager-gnome, totem and system-config-display In-Reply-To: <20080107183803.GB19651@nostromo.devel.redhat.com> References: <477D7812.9070205@fedoraproject.org> <20080107183803.GB19651@nostromo.devel.redhat.com> Message-ID: <4782750D.1000800@fedoraproject.org> Bill Nottingham wrote: > Rahul Sundaram (sundaram at fedoraproject.org) said: >> While creating the Xfce spin for Fedora 8, I noticed a few packages seem to >> have a bad dependency list. NetworkManager-gnome has a hard dependency on >> things like gnome-panel and gnome-keyring. Totem has a hard dependency on >> gnome-desktop and gnome-themes. system-config-display has a hard dependency >> on metacity. Are these really required? > > gnome-keyring, gnome-desktop, metacity - definitely. You can file bugs > about the others if you feel strongly, but they may be hard requirements as > well. I have filed a few bug report related to this. Thanks for the input. Rahul From lesmikesell at gmail.com Mon Jan 7 19:06:59 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 07 Jan 2008 13:06:59 -0600 Subject: Init : someone could comment this ? In-Reply-To: <20080107182648.GC30406@tango.0pointer.de> References: <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <20080107173508.GA23429@tango.0pointer.de> <4782688D.4030404@gmail.com> <20080107182648.GC30406@tango.0pointer.de> Message-ID: <47827853.2000402@gmail.com> Lennart Poettering wrote: >> What's wrong with numerical runlevels other than Linux flavors starting the >> network in level 2 instead of 3? > > They don't make any sense, that's wrong with them. 1 as single user, 2 as multiuser makes reasonable sense, with networking as the logical next step. > Why only 6 of them? Until someone decided to make X something special you only needed 3 steps that you could jump among: single user, multiuser, multiuser+network. But with a scheme based on directory names and the inherent sort order of a wildcard expansion, there initially wasn't a real limit. > I never understood why a process like "shutdown" or "reboot" should be > considered a "level". Do you? runlevel 0 = quit sounds extremely logical. 6=reboot was someone just running out of ideas. > Nobody knows what the actually mean. Unless they read a SysV manual back when they fit in your pocket? > They are using numeric ids for no > reason. Their sort order is well known. > I mean, people invented stuff like DNS for not having to > deal with random numbers that often. Why should they deal with random > numbers when dealing with init systems, then? > > Almost all distributions use only 2 or 3 of them. > > Their configuration is plain awful. > > They're totally awkward, because there are numeric levels and the > magic runlevel S. Well, yeah - but then there is q also - and necessarily so... > Also, init doesn't really have any information what service is running > in which one is not for the current runlevel. That's the point. Init should not know anything specifically except for the stuff it manages directly per inittab. > To work around that the > configuration is highly redundant with lots of symlinks. Which lets it do anything it needs to do, finding out only when it needs to know. All very good things. > Then, on the philosophical level, having a single set of "runlevels" > just doesn't cut it, because services these days should only be > started maybe when a certain HW is around, or when some specific user > software runs that wants to make use of it. How do runlevels fit into > that? They are too static to reflect this dynamic way of starting and > stopping services properly. > > In short, they don't make any sense. They should die. They make sense for what they do - otherwise how can I tell the system I want to go down to single user mode with a clear definition of what will still be running? And I should be able to tell it I want multiuser mode but with no networking, but Linux distros screw that up. But init isn't limited to those, it also does things specified in inittab. If you want magic stuff to happen on certain events, respawn the thing that detects the event starting at the desired runlevel and let that program do whatever is supposed to happen next. Getty watching for a carrier detect hardware event is the original example - and it doesn't need to know anything except what to exec next and doesn't need to wait around for results. Processes are supposed to be cheap enough that if you need one you can use it - don't make init need to know anything else. -- Les Mikesell lesmikesell at gmail.com From wart at kobold.org Mon Jan 7 19:07:38 2008 From: wart at kobold.org (Wart) Date: Mon, 07 Jan 2008 11:07:38 -0800 Subject: Obsoleting packages Message-ID: <4782787A.9030609@kobold.org> tcl-8.5.0-4, which will be hitting rawhide soon, obsoletes tcl-tcldict: Obsoletes: tcl-tcldict <= 8.5.2 Provides: tcl-tcldict = 8.5.2 The tcl-tcldict package will no longer be necessary in Rawhide after this. Is it necessary to remove the tcl-tcldict rpm from the repository, or will it get removed automatically now that Tcl provides tcl-tcldict? --Wart From cjdahlin at ncsu.edu Mon Jan 7 19:21:28 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Mon, 07 Jan 2008 14:21:28 -0500 Subject: Init : someone could comment this ? In-Reply-To: <20080107181220.GB30406@tango.0pointer.de> References: <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <20080107173508.GA23429@tango.0pointer.de> <478262EB.8050407@ncsu.edu> <20080107181220.GB30406@tango.0pointer.de> Message-ID: <47827BB8.1060101@ncsu.edu> Lennart Poettering wrote: > On Mon, 07.01.08 12:35, Casey Dahlin (cjdahlin at ncsu.edu) wrote: > > >>> Everytime I hear someone mentioning initng I get a headache. >>> >>> They got almost everything wrong you can get wrong in an init >>> system. The kept the worst things from SysV (such as numerical >>> "runlevels"), and added the worst things they could find in other >>> people's software. Like the braindeadness to make everything a shared >>> object, including stuff like executing chdir(). Can you believe that? >>> They have a "plugin" to change a directory which consists of 100 lines >>> or code or so. Unbelievable... >>> >>> Lennart >>> >>> >>> >> This is all very useful. >> >> I am proposing a session at FUDcon to explore the options, and to >> definitively pick a solution. Hopefully the following day's hackfest will >> see direct effort toward implementing a solution. >> > > "Definitively" picking a solution? Unfortunately I don't see that any > of the currently available init implementations get things > right in a way that we could "definitively" pick it. > > The only one of the new systems that has good code is > Upstart. However, in my understanding it got everything hooked up the > wrong way round. I.e. instead of having other daemons contact Upstart > to start and stop services it itself hooks into all kind of > "events". A couple of RH and Novell people discussed that with Scott > at this years GUADEC conference a while back. I think we managed to > convince him that this should be changed. The result is his new > Initkit project. However, that's still in its infancy and will take > some time to be useful. This however means that now adopting Upstart > would be investing in a project that's going to be replaced soonishly > anyway. Also, Ubuntu uses Upstart mostly in SysV compatibility mode > right now. > > So, in short: initng is a joke, initkit not ready yet, upstart a bit of > a moving target that's going to be replaced soon anyway. The other > systems seem to be too simple (minit, runit) or totally un-Linuxish > (SMF, launchd). > > I think our safest bet for now is to stay with SysV but spice it up a > little bit with LSB headers to allow parallel startup, like Debian is > doing it now. > > And then, let's wait what Scott comes up with in InitKit. Given that > he's a Canonical guy, and both RH and Novell engineers discussed > Upstart in lengths with him I hope that this is also the best bet to > get something done that is adopted by all "big three" distributions, > working a bit against the balkanization of Linux userspace. > > Lennart > > Fine. Let's commit to that outright, and not let ourselves sit on our asses for another 5 years while everything blows by. I'm pushing this forward because I'm sick of seeing the action being taken on the weakest point of our distro consisting of a bunch of stale wiki pages. My point in saying "definitively" is that this will not be another mailing list thread where everyone shouts back and forth until they get bored and then everyone forgets about the issue. I mean to ensure we pick a goal, agree to stop bitching about it, and actually execute on it. rrn or whatever it ends up being called exists because I asked Harald Hoyer what needed to exist for Fedora's init system to be healed, and then I went and made it exist. Now we don't like that solution anymore. Great. Pick another one, and ensure it begins happening as fast as possible. Or don't. I'll do all the work. Just don't complain when its finished. Commit, and be done with it. It is time to set a terminal date beyond which discussion of other solutions is no longer welcome. When we are interested only in the implementation of that which has already been decided. Source code or GTFO. Fedora 9 is probably going to slip without a feature that should have been in Fedora 8. We're supposed to be innovators, and look at how much nothing we've done on this issue. This is absurd. I'm saying we end it now. --CJD From notting at redhat.com Mon Jan 7 19:24:32 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 7 Jan 2008 14:24:32 -0500 Subject: Init : someone could comment this ? In-Reply-To: <20080107181220.GB30406@tango.0pointer.de> References: <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <20080107173508.GA23429@tango.0pointer.de> <478262EB.8050407@ncsu.edu> <20080107181220.GB30406@tango.0pointer.de> Message-ID: <20080107192432.GE19651@nostromo.devel.redhat.com> Lennart Poettering (mzerqung at 0pointer.de) said: > I think our safest bet for now is to stay with SysV but spice it up a > little bit with LSB headers to allow parallel startup, like Debian is > doing it now. The problem with how the LSB headers is that as it currently stands (i.e., not counting prcsys or whatever), they're evaluated at script install time, and to *correctly* handle them, you need to do it at runtime, with information that's not in the scripts themselves. So, to do this right, you need something new to at least replace /etc/rc. Whether that's worth the effort is another issue. Bill From notting at redhat.com Mon Jan 7 19:27:27 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 7 Jan 2008 14:27:27 -0500 Subject: Init : someone could comment this ? In-Reply-To: <20080107120349.GA15518@devserv.devel.redhat.com> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> <20080107120349.GA15518@devserv.devel.redhat.com> Message-ID: <20080107192727.GF19651@nostromo.devel.redhat.com> Alan Cox (alan at redhat.com) said: > Fork should be pretty cheap - although that depends how much memory is unshared > by each of the resulting tasks. A smaller cleaner shell such as rc (which was > designed for this job in plan 9) or ash might well perform better. I'm dubious > it would be a big difference but someone can bench it. ash has been benchmarked. Required rooting out some bashisms from the scripts (or just calling those specific scripts with bash), but in any case, it didn't make much difference. Bill From notting at redhat.com Mon Jan 7 19:29:02 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 7 Jan 2008 14:29:02 -0500 Subject: Init : someone could comment this ? In-Reply-To: <4782637A.8050203@ncsu.edu> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> <20080107120349.GA15518@devserv.devel.redhat.com> <478254DF.9070308@gmail.com> <4782637A.8050203@ncsu.edu> Message-ID: <20080107192902.GG19651@nostromo.devel.redhat.com> Casey Dahlin (cjdahlin at ncsu.edu) said: > Its not the fork or exec per se. It is the disk IO associated with loading > the binary images. Normally this isn't too much of an issue, but in the > highly IO-sensitive init process it can cause huge issues. Remember, seek > time is the big issue with disk IO, so size of data to load is not the > metric to go by. So, switch to a storage metaphor that doesn't penalize seeks. While that's somewhat of a joke, you do want to avoid over-optimizing for what may not be the common case. Bill From cjdahlin at ncsu.edu Mon Jan 7 19:30:41 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Mon, 07 Jan 2008 14:30:41 -0500 Subject: Init : someone could comment this ? In-Reply-To: <20080107192432.GE19651@nostromo.devel.redhat.com> References: <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <20080107173508.GA23429@tango.0pointer.de> <478262EB.8050407@ncsu.edu> <20080107181220.GB30406@tango.0pointer.de> <20080107192432.GE19651@nostromo.devel.redhat.com> Message-ID: <47827DE1.6030600@ncsu.edu> Bill Nottingham wrote: > Lennart Poettering (mzerqung at 0pointer.de) said: > >> I think our safest bet for now is to stay with SysV but spice it up a >> little bit with LSB headers to allow parallel startup, like Debian is >> doing it now. >> > > The problem with how the LSB headers is that as it currently stands > (i.e., not counting prcsys or whatever), they're evaluated at script > install time, and to *correctly* handle them, you need to do it at > runtime, with information that's not in the scripts themselves. So, > to do this right, you need something new to at least replace /etc/rc. > > Whether that's worth the effort is another issue. > > Bill > > I have one. Its 60% done, will be ready for rawhide after Fudcon if we decide to pursue it. See earlier in the thread. --CJD From pasik at iki.fi Mon Jan 7 19:32:08 2008 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Mon, 7 Jan 2008 21:32:08 +0200 Subject: BUG: rawhide installer does not autoload xenblk/xennet modules Message-ID: <20080107193208.GO17677@edu.joroinen.fi> Hello! I just tried to install rawhide/development to a xen domU with virt-manager, and it seems current kernel (or xen drivers?) has a bug that prevents anaconda/installer from autoloading the needed drivers.. virt-install -n test -r 512 --vcpus=1 -f /dev/vg0/test_disk1 --vnc -p -b xenbr0 -l "http://mirror/fedora.redhat.com/pub/fedora/linux/development/i386/os" starts up the console/vnc window, boots up linux and the installer, lets me choose language and keyboard type, and then says: "No driver found" "Unable to find any devices of the type needed for this installation type." "Would you like to manually select your driver or use a driver disk?" And at the moment anaconda is broken for manually picking drivers, so installation doesn't work at all when using xen :) (this is a separate bug) -- Pasi From jdennis at redhat.com Mon Jan 7 19:35:40 2008 From: jdennis at redhat.com (John Dennis) Date: Mon, 07 Jan 2008 14:35:40 -0500 Subject: Another selinux rant In-Reply-To: <3e4ec4600801041859g4eb4ed93md8e58770dd244da3@mail.gmail.com> References: <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <645d17210801041430h7ab76f20qee0df7d1f295d23b@mail.gmail.com> <16de708d0801041447pa2a6486p7a1f7a15de41d867@mail.gmail.com> <645d17210801041457m134eb51er61cdc7aa0610a205@mail.gmail.com> <16de708d0801041503s598b5062ve669643465d29a1@mail.gmail.com> <645d17210801041554x527b050g513e9ec3bdd88744@mail.gmail.com> <3e4ec4600801041859g4eb4ed93md8e58770dd244da3@mail.gmail.com> Message-ID: <47827F0C.9080709@redhat.com> Michael Wiktowy wrote: > On Jan 4, 2008 6:54 PM, Jonathan Underwood wrote: >> That could be the case. Perhaps there's something that could be added >> to Smolt to allow the history of avc denials to be uploaded as part of >> the profile - that would allow some really interesting analysis. > > That is a great idea! > > Even just something that indicates the proportion of people using > enforcing/permissive/disabled. That would be useful to either support > or refute the periodic SELinux rant threads based on people's personal > usage patterns and seem to take on a life of their own and inevitably > lead to statistics being pulled out of thin air. For what it's worth setroubleshoot was designed to allow sending it's analysis to a central server to coalesce all the reports to get a global view (and to allow notifications to be sent back to the reporter when their issue was fixed if it was a bug). This was never fully implemented for the following reasons: * audit data is security sensitive, transmitting it to a central server raises a host of issues. * we needed a host to run the server on, at the time none existed (fedoraproject might be a viable option today). * no one thought it was important. The code in setroubleshoot still has all the logic built into it to support central aggregation, as it has from day one. But we would have to build the central server and solve the security issues. But this would occur if and only if there was a consensus this was important and volunteers stepped forward to perform the work. -- John Dennis From debarshi.ray at gmail.com Mon Jan 7 19:40:20 2008 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Tue, 8 Jan 2008 01:10:20 +0530 Subject: tgif does not work on fedora 8 In-Reply-To: <47825AC6.20205@libero.it> References: <47825AC6.20205@libero.it> Message-ID: <3170f42f0801071140u6618a4e8m23c0baa5d2b46f@mail.gmail.com> You can try to file a bug on https://bugzilla.redhat.com/ against the tgif package in Fedora. Cheers, Debarshi From jdennis at redhat.com Mon Jan 7 19:47:48 2008 From: jdennis at redhat.com (John Dennis) Date: Mon, 07 Jan 2008 14:47:48 -0500 Subject: Another selinux rant In-Reply-To: <1199514823.6022.62.camel@beck.corsepiu.local> References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <1199514823.6022.62.camel@beck.corsepiu.local> Message-ID: <478281E4.5090803@redhat.com> Ralf Corsepius wrote: > * Is it appropriate to inform arbitrary ordinary users about SELinux > issues? May-be this on single user/non-networked machines, but I don't > think this is the right concept for a networked environment in which > "ordinary user" normally isn't the system admin. This is why setroubleshoot was designed to operate in a distributed network mode. At the time of setroubleshoot's initial release it was felt this was a corner case, that the most likely user of the tool would be developers and technically astute users both running locally. The distributed aspects of the tool were never promoted, although they continue to reside in the code. In fairness the networked facilities need some enhancements to make them fully viable. For instance the network traffic is not encrypted, a critical feature when transmitting security sensitive data and it needs to be fronted by a more robust authentication mechanism. -- John Dennis From notting at redhat.com Mon Jan 7 19:57:42 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 7 Jan 2008 14:57:42 -0500 Subject: Init : someone could comment this ? In-Reply-To: <47827DE1.6030600@ncsu.edu> References: <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <20080107173508.GA23429@tango.0pointer.de> <478262EB.8050407@ncsu.edu> <20080107181220.GB30406@tango.0pointer.de> <20080107192432.GE19651@nostromo.devel.redhat.com> <47827DE1.6030600@ncsu.edu> Message-ID: <20080107195742.GJ19651@nostromo.devel.redhat.com> Casey Dahlin (cjdahlin at ncsu.edu) said: > I have one. Its 60% done, will be ready for rawhide after Fudcon if we > decide to pursue it. See earlier in the thread. How are you handling $time, $localfs, $named, etc? Bill From jam at zoidtechnologies.com Mon Jan 7 20:07:24 2008 From: jam at zoidtechnologies.com (jam at zoidtechnologies.com) Date: Mon, 7 Jan 2008 15:07:24 -0500 Subject: Another selinux rant In-Reply-To: <478281E4.5090803@redhat.com> References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <1199514823.6022.62.camel@beck.corsepiu.local> <478281E4.5090803@redhat.com> Message-ID: <20080107200724.GC489@zoidtechnologies.com> greetings, On Mon, Jan 07, 2008 at 02:47:48PM -0500, John Dennis wrote: [..snipped..] > In fairness the networked facilities need some enhancements to make them > fully viable. For instance the network traffic is not encrypted, a > critical feature when transmitting security sensitive data and it needs > to be fronted by a more robust authentication mechanism. > my use case would be in a private network environment (call center, noc, etc) so the messages would not necessarily need to be encrypted.. my concern would be that they get to the central server reliably. > -- > John Dennis > regards, --jeff -- http://zoidtechnologies.com/ -- websites that suck less From cjdahlin at ncsu.edu Mon Jan 7 20:08:41 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Mon, 07 Jan 2008 15:08:41 -0500 Subject: Init : someone could comment this ? In-Reply-To: <20080107195742.GJ19651@nostromo.devel.redhat.com> References: <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <20080107173508.GA23429@tango.0pointer.de> <478262EB.8050407@ncsu.edu> <20080107181220.GB30406@tango.0pointer.de> <20080107192432.GE19651@nostromo.devel.redhat.com> <47827DE1.6030600@ncsu.edu> <20080107195742.GJ19651@nostromo.devel.redhat.com> Message-ID: <478286C9.5080304@ncsu.edu> Bill Nottingham wrote: > Casey Dahlin (cjdahlin at ncsu.edu) said: > >> I have one. Its 60% done, will be ready for rawhide after Fudcon if we >> decide to pursue it. See earlier in the thread. >> > > How are you handling $time, $localfs, $named, etc? > > Bill > > At the moment they are just like any other provides, so they would be handled by a script (which will presumably just report on the status of the given item). This will likely change, however. --CJD From notting at redhat.com Mon Jan 7 20:12:03 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 7 Jan 2008 15:12:03 -0500 Subject: Init : someone could comment this ? In-Reply-To: <478286C9.5080304@ncsu.edu> References: <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <20080107173508.GA23429@tango.0pointer.de> <478262EB.8050407@ncsu.edu> <20080107181220.GB30406@tango.0pointer.de> <20080107192432.GE19651@nostromo.devel.redhat.com> <47827DE1.6030600@ncsu.edu> <20080107195742.GJ19651@nostromo.devel.redhat.com> <478286C9.5080304@ncsu.edu> Message-ID: <20080107201203.GM19651@nostromo.devel.redhat.com> Casey Dahlin (cjdahlin at ncsu.edu) said: >> How are you handling $time, $localfs, $named, etc? > > At the moment they are just like any other provides, so they would be > handled by a script (which will presumably just report on the status of the > given item). This will likely change, however. Right, that's the tricky part. $localfs leads to 'fun' loops when it's handled as part of the script, since it needs to be added at the latest possible point (after $network_fs, therefore in netfs). This then leads to loops. Similarly, $named needs to be provided by named, if it's started. Otherwise it needs to be provided by $network. Or possibly openldap, if you're using nss_ldap in your nsswitch.conf. Bill From wart at kobold.org Mon Jan 7 20:45:13 2008 From: wart at kobold.org (Michael Thomas) Date: Mon, 07 Jan 2008 12:45:13 -0800 Subject: New tcl-8.5 and 8Kingdoms In-Reply-To: <47820202.3020300@redhat.com> References: <477D5C7F.6050708@hhs.nl> <477D5C87.2010106@kobold.org> <477D5E86.2030004@hhs.nl> <47808AE8.7090702@kobold.org> <4780F505.70702@hhs.nl> <47820202.3020300@redhat.com> Message-ID: <47828F59.6000703@kobold.org> Marcela Maslanova wrote: > I've rebuilt tcl without stack checking. Please try rebuild 8Kingdoms. I don't think 8Kingdoms needs to be rebuilt to get the fix. It should get the fix automatically since it's dynamically linked with the tcl shared library. --Wart From bpepple at fedoraproject.org Mon Jan 7 20:46:52 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 07 Jan 2008 15:46:52 -0500 Subject: New Sponsor Request: Manuel Wolfshant Message-ID: <1199738812.20773.7.camel@kennedy> Hi all, Manuel Wolfshant(1) has requested to be made a sponsor. FESCo will vote on his request at the 2008-01-17 meeting. Here are links to some of work: https://bugzilla.redhat.com/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&component=Package+Review&component_text=&query_format=advanced&bug_status=NEW&bug_status=VERIFIED&bug_status=ASSIGNED&bug_status=CLOSED&bug_status=NEEDINFO&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=PASSES_QA&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&fixed_in_type=allwordssubstr&fixed_in=&qa_whiteboard_type=allwordssubstr&qa_whiteboard=&keywords_type=allwords&keywords=&emailassigned_to1=1&emailtype1=exact&email1=wolfy at nobugconsulting.ro&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=short_desc&type0-0-0=notsubstring&value0-0-0=Merge (1) http://fedoraproject.org/wiki/ManuelWolfshant BTW, any Fedora packager that wishes to become a sponsor, please contact me or go directly to: http://fedoraproject.org/wiki/Extras/Schedule/NewSponsors Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Mon Jan 7 18:38:31 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 7 Jan 2008 13:38:31 -0500 Subject: Reminder, Alpha freeze is Tuesday the 15th. Message-ID: <20080107133831.6d68c01c@redhat.com> As per http://fedoraproject.org/wiki/Releases/9/Schedule the alpha freeze is the 15th. This is a non-blocking freeze, as in we won't be freezing rawhide. Instead releng will be taking a snapshot (in koji) of rawhide and using this as the basis for the Alpha release. We will tag things for this snapshot at our discretion in coordination with QA. Maintainers can also request things be tagged via rel-eng at fedoraproject.org Now would be a great time to either land changes you want exposure to, or fix up those broken deps/upgrade paths/etc... -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From mjs at CLEMSON.EDU Mon Jan 7 21:12:01 2008 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Mon, 07 Jan 2008 16:12:01 -0500 Subject: Condor package? Message-ID: <1199740321.19180.47.camel@vincent52.localdomain> I understand that there is work going on at Red Hat to package the Condor high-throughput computing environment (http://www.cs.wisc.edu/condor/) for RH Linux--not sure if it's RHEL or Fedora. Is anyone on this list working on that project? We're interested in following the progress of that effort, and we might be able to help out, at least some. Thanks. -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From sgrubb at redhat.com Mon Jan 7 21:32:48 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Mon, 7 Jan 2008 16:32:48 -0500 Subject: Another selinux rant In-Reply-To: <20080107200724.GC489@zoidtechnologies.com> References: <478281E4.5090803@redhat.com> <20080107200724.GC489@zoidtechnologies.com> Message-ID: <200801071632.48268.sgrubb@redhat.com> On Monday 07 January 2008 15:07:24 jam at zoidtechnologies.com wrote: > > In fairness the networked facilities need some enhancements to make them > > fully viable. For instance the network traffic is not encrypted, a > > critical feature when transmitting security sensitive data and it needs > > to be fronted by a more robust authentication mechanism. > > my use case would be in a private network environment (call center, noc, > etc) so the messages would not necessarily need to be encrypted.. my > concern would be that they get to the central server reliably. There are plans to create a remote logging plugin for the audit system. This will handle more traffic than just the avc's. There are a number of issues that have to be resolved in order for this to work correctly. I hope that it will be done in time for F9. -Steve From j.w.r.degoede at hhs.nl Mon Jan 7 21:41:37 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 07 Jan 2008 22:41:37 +0100 Subject: New tcl-8.5 and 8Kingdoms In-Reply-To: <47828F59.6000703@kobold.org> References: <477D5C7F.6050708@hhs.nl> <477D5C87.2010106@kobold.org> <477D5E86.2030004@hhs.nl> <47808AE8.7090702@kobold.org> <4780F505.70702@hhs.nl> <47820202.3020300@redhat.com> <47828F59.6000703@kobold.org> Message-ID: <47829C91.9030502@hhs.nl> Michael Thomas wrote: > Marcela Maslanova wrote: >> I've rebuilt tcl without stack checking. Please try rebuild 8Kingdoms. > > I don't think 8Kingdoms needs to be rebuilt to get the fix. It should > get the fix automatically since it's dynamically linked with the tcl > shared library. > TCL upstream has been in contact with me and I have to rectify my statement about the badness of the code, it still doesn't work with 8Kingdoms, but my initial assesment was wrong, to be precise I take back: "The stack checking code works by comparing a pointer returned from malloc with that of an address from a variable in the current stack frame, assuming that if if stackaddress < heapaddress (on architectures where the stack grows down) that the stack has grown into the heap." I read the TCL stack checking code as "(localIntPtr) < (iPtr)", where it clearly reads: "(localIntPtr) < (iPtr)->stackBound", completely my bad! I also take the dinosaur back, I assumed (by my misreading) the code was trying to determine wether the stack had grown into the heap, which would only work on really old platforms hence the dinosaur reference. I'll be spending some time next properly debugging this and trying to find out whats really going amiss. Here are some first clue's I've added a simple printf to TclInterpReady(), which on 8Kingdoms startup prints (lots of times): stackbound: 0x7fffb4db2244, localint: 0x7fffb57a7564 But then I get: stackbound: 0x7fffb4db2244, localint: 0x43c04a14 out of stack space (infinite loop?) Notice how the actualstack is Tera bytes away from the determined stackbound (this is a 64 bit system, so yes those are real/correct addresses) Regards, Hans From tcallawa at redhat.com Mon Jan 7 21:37:11 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 07 Jan 2008 16:37:11 -0500 Subject: Condor package? In-Reply-To: <1199740321.19180.47.camel@vincent52.localdomain> References: <1199740321.19180.47.camel@vincent52.localdomain> Message-ID: <1199741831.22969.16.camel@localhost.localdomain> On Mon, 2008-01-07 at 16:12 -0500, Matthew Saltzman wrote: > I understand that there is work going on at Red Hat to package the > Condor high-throughput computing environment > (http://www.cs.wisc.edu/condor/) for RH Linux--not sure if it's RHEL or > Fedora. Is anyone on this list working on that project? > > We're interested in following the progress of that effort, and we might > be able to help out, at least some. I'm very very peripherally related to that effort, and I think that it is currently RHEL focused. I'll ask them if they've got any plans to do anything in the Fedora space. ~spot From wart at kobold.org Mon Jan 7 21:44:59 2008 From: wart at kobold.org (Michael Thomas) Date: Mon, 07 Jan 2008 13:44:59 -0800 Subject: New tcl-8.5 and 8Kingdoms In-Reply-To: <47829C91.9030502@hhs.nl> References: <477D5C7F.6050708@hhs.nl> <477D5C87.2010106@kobold.org> <477D5E86.2030004@hhs.nl> <47808AE8.7090702@kobold.org> <4780F505.70702@hhs.nl> <47820202.3020300@redhat.com> <47828F59.6000703@kobold.org> <47829C91.9030502@hhs.nl> Message-ID: <47829D5B.4070805@kobold.org> Hans de Goede wrote: > Michael Thomas wrote: >> Marcela Maslanova wrote: >>> I've rebuilt tcl without stack checking. Please try rebuild 8Kingdoms. >> >> I don't think 8Kingdoms needs to be rebuilt to get the fix. It should >> get the fix automatically since it's dynamically linked with the tcl >> shared library. >> > > TCL upstream has been in contact with me and I have to rectify my > statement about the badness of the code, it still doesn't work with > 8Kingdoms, but my initial assesment was wrong, to be precise I take back: > > "The stack checking code works by comparing a pointer returned from > malloc with that of an address from a variable in the current stack > frame, assuming that if if stackaddress < heapaddress (on architectures > where the stack grows down) that the stack has grown into the heap." > > I read the TCL stack checking code as "(localIntPtr) < (iPtr)", where it > clearly reads: "(localIntPtr) < (iPtr)->stackBound", completely my bad! > I also take the dinosaur back, I assumed (by my misreading) the code was > trying to determine wether the stack had grown into the heap, which > would only work on really old platforms hence the dinosaur reference. > I'll be spending some time next properly debugging this and trying to > find out whats really going amiss. > > Here are some first clue's I've added a simple printf to > TclInterpReady(), which on 8Kingdoms startup prints (lots of times): > stackbound: 0x7fffb4db2244, localint: 0x7fffb57a7564 > > But then I get: > stackbound: 0x7fffb4db2244, localint: 0x43c04a14 > out of stack space (infinite loop?) > > Notice how the actualstack is Tera bytes away from the determined > stackbound (this is a 64 bit system, so yes those are real/correct > addresses) Could this be some problem with interaction with threads? I noticed the 'out of stack space' error first occur as soon as 8Kingdoms launched a new thread. --Mike From devrim at CommandPrompt.com Mon Jan 7 21:48:50 2008 From: devrim at CommandPrompt.com (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=) Date: Mon, 07 Jan 2008 13:48:50 -0800 Subject: rpms/postgresql/F-7 postgresql-ac-version.patch, NONE, 1.1 .cvsignore, 1.37, 1.38 postgresql.spec, 1.80, 1.81 sources, 1.38, 1.39 In-Reply-To: <200801071917.m07JH2It026230@cvs-int.fedora.redhat.com> References: <200801071917.m07JH2It026230@cvs-int.fedora.redhat.com> Message-ID: <1199742530.30375.49.camel@localhost.localdomain> Hi, On Mon, 2008-01-07 at 14:17 -0500, Tom Lane wrote: > pgtcl1.6.0.tar.gz pgtcl 1.6.2 is out BTW -- it may be worth upgrading. Regards, -- Devrim G?ND?Z , RHCE PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From j.w.r.degoede at hhs.nl Mon Jan 7 21:54:41 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 07 Jan 2008 22:54:41 +0100 Subject: New tcl-8.5 and 8Kingdoms In-Reply-To: <47829D5B.4070805@kobold.org> References: <477D5C7F.6050708@hhs.nl> <477D5C87.2010106@kobold.org> <477D5E86.2030004@hhs.nl> <47808AE8.7090702@kobold.org> <4780F505.70702@hhs.nl> <47820202.3020300@redhat.com> <47828F59.6000703@kobold.org> <47829C91.9030502@hhs.nl> <47829D5B.4070805@kobold.org> Message-ID: <47829FA1.8050107@hhs.nl> Michael Thomas wrote: > Hans de Goede wrote: >> Michael Thomas wrote: >>> Marcela Maslanova wrote: >>>> I've rebuilt tcl without stack checking. Please try rebuild 8Kingdoms. >>> >>> I don't think 8Kingdoms needs to be rebuilt to get the fix. It >>> should get the fix automatically since it's dynamically linked with >>> the tcl shared library. >>> >> >> TCL upstream has been in contact with me and I have to rectify my >> statement about the badness of the code, it still doesn't work with >> 8Kingdoms, but my initial assesment was wrong, to be precise I take back: >> >> "The stack checking code works by comparing a pointer returned from >> malloc with that of an address from a variable in the current stack >> frame, assuming that if if stackaddress < heapaddress (on >> architectures where the stack grows down) that the stack has grown >> into the heap." >> >> I read the TCL stack checking code as "(localIntPtr) < (iPtr)", where >> it clearly reads: "(localIntPtr) < (iPtr)->stackBound", completely my >> bad! I also take the dinosaur back, I assumed (by my misreading) the >> code was trying to determine wether the stack had grown into the heap, >> which would only work on really old platforms hence the dinosaur >> reference. I'll be spending some time next properly debugging this and >> trying to find out whats really going amiss. >> >> Here are some first clue's I've added a simple printf to >> TclInterpReady(), which on 8Kingdoms startup prints (lots of times): >> stackbound: 0x7fffb4db2244, localint: 0x7fffb57a7564 >> >> But then I get: >> stackbound: 0x7fffb4db2244, localint: 0x43c04a14 >> out of stack space (infinite loop?) >> >> Notice how the actualstack is Tera bytes away from the determined >> stackbound (this is a 64 bit system, so yes those are real/correct >> addresses) > > Could this be some problem with interaction with threads? I noticed the > 'out of stack space' error first occur as soon as 8Kingdoms launched a > new thread. > Yes, it most likely is, still busy investigating ... Regards, Hans From choeger at cs.tu-berlin.de Mon Jan 7 21:57:49 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Mon, 07 Jan 2008 22:57:49 +0100 Subject: autoconf driving me mad In-Reply-To: <20080107190154.GA26540@camelia.ucw.cz> References: <4782242F.8060102@cs.tu-berlin.de> <20080107190154.GA26540@camelia.ucw.cz> Message-ID: <1199743069.3126.1.camel@choeger4> Am Montag, den 07.01.2008, 20:01 +0100 schrieb Stepan Kasal: > Hello, > > On Mon, Jan 07, 2008 at 02:07:59PM +0100, Christoph H?ger wrote: > > GLOB_INCLUDE="-I${srcdir} -I${srcdir}/include" > > AC_SUBST(GLOB_INCLUDE) > > variables like srcdir, top_srcdir, top_builddir, and such are > not available for the shell code in the configure.ac. The manual > does not mention them. (Yes, there is something about having the > available in AC_CONFIG_* macros, but that's not the case here.) > > These variables are available in the file _created_ by configure, > specifically in the makefiles. > > So, formally speaking, the observed problem with backward > compatibility of 2.61 is caused by relying on undocumented features > in the autoconfigury of openccs. > > Let me outline the way to fix this. > src/make.rules should use $(top_srcdir) and such like this: > > GLOB_INCLUDE = \ > -I$(top_srcdir) \ > -I$(top_srcdir)/include > TOOLS_INCLUDE = \ > -I$(top_srcdir)/shared/rte \ > -I$(top_builddir)/shared/comm \ > -I$(top_srcdir)/shared/comm \ > -I$(top_srcdir)/shared/filterIdent \ > -I$(top_srcdir)/shared/tools > > AM_CPPFLAGS = $(GLOB_DEFINES) $(GLOB_INCLUDE) $(TOOLS_INCLUDE) > > Note: > - the two lines quoted in the top of this mail should go away from > configure.in, GLOB_INCLUDE in defined directly in make.rules > - likewise, TOOLS_INCLUDE shall not be AC_SUBSTed > - some Makefile.am contain > INCLUDE = @GLOB_INCLUDE@ > and such; these are redundant and should go away > - $(GLOB_DEFINES) works even though it is not spelled as @...@; thats > because all AC_SUBSTed variables are inherited in makefiles > > Hope this explanation will drag you back to the sane world. ;-) > > Have a nice day, > Stepan Kasal > Hi, thank you for your advice! I'm going to fix the package tomorrow. (hopefully the doctor will let me go home tomorrow ;) ) christoph From mspevack at redhat.com Mon Jan 7 21:59:17 2008 From: mspevack at redhat.com (Max Spevack) Date: Mon, 7 Jan 2008 16:59:17 -0500 (EST) Subject: some FUDCon and hackfest details Message-ID: http://fedoraproject.org/wiki/FUDCon/FUDConF9 This page includes a Google map with the hotel, hackfest and FUDCon locations, and also some good places to get food and drink. For the folks who are attending the Friday hackfest, it gives the location and start time. It also links to the page where travelers are coordinating their arrival times. The general plan for Friday is that it is day 1 of the hackfest. We have a meeting place identified. From there, we can break up into smaller groups. We'll have lunch provided for folks. Saturday will be the actual FUDCon, taking place at Red Hat's headquarters. Sunday will be day 2 of the hackfest, also taking place at Red Hat's headquarters. Looking forward to seeing everyone! --Max From mfarrellee+fedora at redhat.com Mon Jan 7 22:26:28 2008 From: mfarrellee+fedora at redhat.com (Matthew Farrellee) Date: Mon, 07 Jan 2008 16:26:28 -0600 Subject: Condor package? In-Reply-To: <1199741831.22969.16.camel@localhost.localdomain> References: <1199740321.19180.47.camel@vincent52.localdomain> <1199741831.22969.16.camel@localhost.localdomain> Message-ID: <4782A714.8060305@redhat.com> Tom "spot" Callaway wrote: > On Mon, 2008-01-07 at 16:12 -0500, Matthew Saltzman wrote: >> I understand that there is work going on at Red Hat to package the >> Condor high-throughput computing environment >> (http://www.cs.wisc.edu/condor/) for RH Linux--not sure if it's RHEL or >> Fedora. Is anyone on this list working on that project? >> >> We're interested in following the progress of that effort, and we might >> be able to help out, at least some. > > I'm very very peripherally related to that effort, and I think that it > is currently RHEL focused. I'll ask them if they've got any plans to do > anything in the Fedora space. > > ~spot > I'm very very related to that effort, and I can tell you that it is already an add-on to RHEL through Red Hat's MRG product. I also have plans to (re)submit Condor to Fedora for inclusion. I'm simply waiting for the next stable release of Condor. Best, matt From loganjerry at gmail.com Mon Jan 7 22:30:03 2008 From: loganjerry at gmail.com (Jerry James) Date: Mon, 7 Jan 2008 15:30:03 -0700 Subject: Review swaps Message-ID: <870180fe0801071430q6d01ccf1j252ae475ee3f68f3@mail.gmail.com> I'm interested in swapping reviews. I've currently got 3 packages awaiting review. The first 2 are prerequisites for findbugs, which I hope to package up once these are in (modulo my ability to deal with findbugs' modified version of BCEL). The third one is a prerequisite for several other packages, such as nutch [1] and choco [2]. 262401, jcip-annotations: A set of Java annotations for describing multithreaded properties 285551, idw-gpl: A Swing-based docking windows framework 394871, automaton: a Java finite state automata / regular expression library Thanks! Footnotes: [1] http://www.nutch.org/ [2] http://choco-solver.net/ -- Jerry James http://loganjerry.googlepages.com/ From Matt_Domsch at dell.com Mon Jan 7 22:43:30 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 7 Jan 2008 16:43:30 -0600 Subject: Fedora x86_64 rawhide rebuild in mock status 2008-01-05 Message-ID: <20080107224330.GA14071@humbolt.us.dell.com> Fedora Rawhide-in-Mock Build Results for x86_64 using the rawhide tree as of Saturday, January 5, 2008. This is a full rebuild of all packages. Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 5163 Number failed to build: 527 Number expected to fail due to ExclusiveArch or ExcludeArch: 34 Leaving: 493 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 493 ---------------------------------- Django-0.96.1-1.fc9 (build/make) salimma GtkAda-2.8.0-7.fc7 (build/make) gemi LabPlot-1.5.1.6-4.fc8 (build/make) chitlesh PyRTF-0.45-5.fc8 (build/make) jamatos,mpeters,jamatos PySolFC-1.1-4.fc9 (build/make) firewing PyX-0.9-5.fc8 (build/make) jamatos,mpeters,jamatos QuantLib-0.8.1-4.fc9 (build/make) spot R-Biobase-1.16.1-3.fc9 (build/make) pingou R-BufferedMatrix-1.2.0-1.fc9 (build/make) pingou R-abind-1.1-1.fc9 (build/make) spot R-acepack-1.3-2.fc9 (build/make) spot R-mAr-1.1-11.fc8 (build/make) jamatos R-tkWidgets-1.16.0-1.fc9 (build/make) pingou R-waveslim-1.6-4.fc8 (build/make) jamatos R-wavethresh-2.2-7.fc8 (build/make) jamatos R-widgetTools-1.15.0-1.fc9 (build/make) pingou SOAPpy-0.11.6-6.fc7 (build/make) xulchris ScientificPython-2.6-10.fc8 (build/make) jspaleta TnL-071111-1.fc9 (build/make) jwrdegoede aasaver-0.3.2-1.fc8 (build/make) oddsocks abiword-2.4.6-6.fc8 (build/make) uwog airsnort-0.2.7e-11.fc7 (build/make) awjb alliance-5.0-10.20070718snap.fc8 (build/make) chitlesh amanith-0.3-5.fc9 (build/make) spot amarokFS-0.5-1.fc7 (build/make) faucamp anjuta-gdl-0.7.3-2.fc9 (build/make) rishi arm-gp2x-linux-glibc-2.3.6-4.fc8 (build/make) jwrdegoede at-3.1.10-19.fc9 (build/make) mmaslano atitvout-0.4-7 (build/make) awjb atlas-3.6.0-12.fc8 (build/make) qspencer avr-libc-1.4.6-4.fc8 (build/make) jwrdegoede awesfx-0.5.0d-4.fc7 (build/make) stransky bacula-2.0.3-11.fc8 (build/make) ixs,mmcgrath balsa-2.3.21-1.fc9 (build/make) pawsa bcfg2-0.9.5.2-1.fc9 (build/make) jcollie binutils-2.18.50.0.3-1 (build/make) jakub bitbake-1.8.8-1.fc8 (build/make) ixs bittorrent-4.4.0-5.fc7 (build/make) pghmcfc blogtk-1.1-8.fc7 (build/make) pfrields bluecurve-kwin-theme-1.0.0-1.fc8 (build/make) rstrode,rdieter,davidz,kkofler bmpx-0.40.13-7.fc9 (build/make) akahl brltty-3.8-1.fc8 (build/make) tjanouse camstream-0.26.3-12.fc8 (open_missing_mode) nomis80 castor-0.9.5-1jpp.7 (build/make) pcheung chkfontpath-1.10.1-2.fc8 (build/make) krh,fonts-sig clips-6.24-22.fc7 (build/make) rvinyard clisp-2.43-3.fc9 (build/make) gemi,green cobbler-0.6.4-2.fc9 (build/make) mdehaan compat-gcc-296-2.96-139 (build/make) jakub compat-gcc-32-3.2.3-62 (build/make) jakub compat-gcc-34-3.4.6-8 (build/make) jakub compiz-0.6.2-4.fc9 (build/make) krh compizconfig-backend-kconfig-0.6.0-1.fc9 (build/make) izhar,izhar conexus-0.5.3-2.fc8 (build/make) rvinyard cryptix-asn1-20011119-7jpp.2 (build/make) vivekl crystal-1.0.5-1.fc8 (build/make) chitlesh csound-5.03.0-13.fc7 (build/make) dcbw,pfj ctrlproxy-3.0.3-1.fc9 (build/make) jwboyer d4x-2.5.7.1-3.fc7 (build/make) thias darcs-1.0.9-6.fc8 (build/make) jjh,petersen db4o-6.1-2.fc7 (build/make) pfj dejagnu-1.4.4-11 (build/make) pmachata dekorator-0.3-3.fc7 (build/make) faucamp device-mapper-multipath-0.4.7-11.fc7 (build/make) lvm-team,agk,mornfall,mbroz,dwysocha,bmarzins dia-0.96.1-5.fc9 (build/make) jwrdegoede digikam-doc-0.9.3-0.1.beta3.fc9 (build/make) mgarski,rdieter dmraid-1.0.0.rc14-6.fc9 (build/make) lvm-team,agk,mornfall,bmr,mbroz,mauelsha,dwysocha dogtail-0.6.1-1.fc7 (build/make) zmc driconf-0.9.1-6.fc8 (build/make) kevin drivel-2.1.1-0.3.20071130svn.fc9 (build/make) pfrields duplicity-0.4.3-1.fc8 (build/make) robert e2fsprogs-1.40.4-2.fc9 (build/make) sandeen,oliver,kzak eclipse-emf-2.2.2-1.fc7 (build/make) overholt eclipse-mylyn-2.0.0-9.fc8 (build/make) overholt enblend-3.0-6.fc8 (build/make) bpostle,jspaleta epiphany-2.21.5-0.1.svn7844.fc9 (build/make) gecko-maint epiphany-extensions-2.20.1-3.fc9 (build/make) caillon,pgordon epydoc-2.1-8.fc8 (build/make) thias epylog-1.0.3-5.fc7 (build/make) icon esc-1.0.1-7.fc8 (build/make) jmagne evolution-brutus-1.1.28.7-2.fc8 (build/make) bpepple expect-5.43.0-9.fc8 (build/make) vcrhonek findutils-4.2.31-2.fc8 (build/make) vcrhonek flagpoll-0.9.1-1.fc8 (build/make) deji fluxconf-0.9.9-4.fc8 (build/make) awjb fluxstyle-1.0.1-2.fc7 (build/make) errr fonttools-2.0-0.11.20060223cvs.fc7 (build/make) roozbeh,fonts-sig fontypython-0.2.0-6.fc7 (build/make) cr33dog,fonts-sig fpc-2.2.0-10.fc8 (build/make) joost freetennis-0.4.8-6.fc7 (build/make) rjones func-0.13-3.fc9 (build/make) mdehaan,skvidal,alikins fusion-icon-0-0.2.20071206git.fc9 (build/make) karlik fwfstab-0.02-2.fc9 (build/make) firewing galternatives-0.13.4-4.fc7 (build/make) deji gazpacho-0.7.2-2.fc8 (build/make) icon gcl-2.6.7-15.fc8 (build/make) gemi,green gdb-6.7.1-6.fc9 (build/make) jkratoch gdl-0.9-0.pre6.fc9 (build/make) orion gdmap-0.7.5-6.fc6 (build/make) splinux gdome2-0.8.1-5.2.fc7 (build/make) bjohnson gedit-plugins-2.18.0-2.fc7 (build/make) trondd getmail-4.7.7-2.fc9 (build/make) knol gfa-0.4.1-4.fc7 (build/make) splinux gg2-2.3.0-5.fc9 (build/make) rathann gjots2-2.3.4-7.fc7 (build/make) rvokal glibmm24-2.14.2-1.fc9 (build/make) denis glipper-0.95.1-2.fc7 (build/make) splinux gnash-0.8.1-6.fc9 (build/make) pertusus gnome-applet-vm-0.1.2-2.fc7 (build/make) kzak gnome-device-manager-0.2-2.fc9 (build/make) davidz gnome-media-2.20.1-7.fc9 (build/make) hadess gnome-python2-desktop-2.21.1-1.fc9 (build/make) mbarnes gnome-scan-0.5.3-0.1.20071030svn.fc9 (build/make) deji gnome-sharp-2.16.0-5.fc8 (build/make) alexl,laxathom gnome-specimen-0.3-1.fc8 (build/make) splinux gnome-web-photo-0.3-8.fc9 (build/make) hadess gnubiff-2.2.7-3.fc9 (build/make) splinux gnupg-1.4.8-1 (build/make) nalin,rdieter gourmet-0.13.4-1.fc8 (build/make) jspaleta gquilt-0.20-1.fc7 (build/make) jwboyer gresistor-0.0.1-11.fc8 (build/make) chitlesh gstm-1.2-6.fc7 (build/make) splinux gstreamer-plugins-good-0.10.6-6.fc8 (build/make) ajax gtk-qt-engine-0.8-1.fc9 (build/make) rdieter gtk-sharp-1.0.10-12.fc7 (build/make) pfj gtk-sharp2-2.10.0-6.fc8 (build/make) alexl,laxathom gtk2hs-0.9.12.1-8.fc9 (build/make) bos,petersen gtkmathview-0.7.6-5.fc6 (needs_popt-devel) uwog gwave-2-4.20070514snap.fc9 (build/make) chitlesh gwenview-1.4.2-1.fc9 (build/make) abompard gwget-0.99-3.fc8 (build/make) cwickert hotwire-0.620-1.fc9 (build/make) walters ht2html-2.0-5.fc6 (build/make) ifoox htop-0.6.5-1.fc7 (build/make) gajownik hunspell-ar-0.20060208-1.fc8 (build/make) danken icecream-0.8.0-6.20071101svn.fc9 (build/make) michich inkscape-0.45.1-5.fc9 (build/make) denis ip-sentinel-0.12-10.fc7 (build/make) ensc iproute-2.6.23-1.fc9 (build/make) mmaslano,rvokal,mmaslano isdn4k-utils-3.2-55.fc8 (build/make) than itcl-3.3-0.11.RC1.fc9 (build/make) wart java-1.5.0-gcj-1.5.0.0-17.fc8 (build/make) fitzsim jgroups-2.2.9.2-3jpp.2 (build/make) vivekl jokosher-1.0-0.1.20070929svn.fc8 (build/make) snecker kaffeine-0.8.5-5.fc8 (build/make) rdieter,scop,mef kannel-1.4.1-5 (build/make) thias katapult-0.3.2.1-2.fc8 (build/make) chitlesh kazehakase-0.5.0-1.fc9.2 (build/make) mtasaka kbackup-0.5.2-1.fc8 (build/make) dionysos kbibtex-0.1.5.52-10.fc7 (build/make) noltec kbiof-0.3-1.fc8 (build/make) oddsocks kcemirror-0.1.5-1.fc7 (build/make) awjb,abompard kchmviewer-3.0-2.fc7 (build/make) pertusus,jpo kcometen3-1.1-5.fc8 (build/make) oddsocks kdbg-2.0.5-2.fc7 (build/make) than kdetv-0.8.9-8.fc9 (build/make) oddsocks kdirstat-2.5.3-6.fc8 (build/make) chitlesh kdissert-1.0.7-1.fc7 (build/make) icon keurocalc-0.9.7-3.fc8 (build/make) chitlesh kflickr-0.9-1.fc8 (build/make) stahnma kgtk-0.8-2.fc7 (build/make) faucamp kicker-compiz-3.5.4-4.fc8 (build/make) laxathom kio_p7zip-0.3.1-5.fc8 (build/make) nixaff4 kio_resources-0.2-3.fc8 (build/make) chitlesh kiosktool-1.0-8.fc8 (build/make) rdieter kleansweep-0.2.9-5.fc8 (build/make) chitlesh klear-0.6.1-1.fc8 (build/make) trasher klibido-0.2.5-8.fc8 (build/make) faucamp kmobiletools-0.4.3.3-3.fc6 (build/make) ausil knemo-0.4.7-1.fc7 (build/make) faucamp knetstats-1.6.1-4.fc8 (build/make) chitlesh koan-0.6.3-3.fc9 (build/make) mdehaan koffice-langpack-1.6.3-1.fc8 (build/make) awjb kompose-0.5.3-8.fc8 (build/make) orion konversation-1.0.1-3.fc8 (build/make) ausil kooldock-0.4.6-2.fc8 (build/make) ecik kover-3-2 (build/make) adrian koverartist-0.5-8.fc8 (build/make) svahl kphotobymail-0.4.1-1.fc7 (build/make) kushal kpolynome-0.1.2-10.fc8 (build/make) chitlesh kpowersave-0.7.3-1.fc9 (build/make) ausil,rdieter krecipes-0.9.1-6.fc8 (build/make) ausil krename-3.0.14-2.fc8 (build/make) ecik kshutdown-1.0.1-1.fc8 (build/make) chitlesh ksplash-engine-moodin-0.4.2-4.fc7 (build/make) trasher,chitlesh ksshaskpass-0.3-3.fc8 (build/make) abompard ksynaptics-0.3.3-2.fc8 (build/make) orion ktechlab-0.3.69-5.fc8 (build/make) chitlesh kyum-0.7.5-9.fc8 (build/make) s4504kr ladspa-1.12-8.fc7 (build/make) thomasvs ldapjdk-4.17-1jpp.7 (build/make) vivekl libchewing-0.3.0-8.fc8 (open_missing_mode) cchance libepc-0.3.1-1.fc9 (build/make) bpepple libevent-1.3b-1.fc7 (build/make) steved,ertzing libgdamm-2.9.8-1.fc8 (build/make) spot libieee1284-0.2.11-1.fc8 (build/make) twaugh libkexif-0.2.5-2.fc8 (build/make) abompard,rdieter libkexiv2-0.1.6-2.fc9 (build/make) rdieter,mgarski libkipi-0.1.5-2.fc8 (build/make) abompard,rdieter libmatheval-1.1.5-1.fc8 (build/make) edhill libopensync-plugin-sunbird-0.22-3.fc7 (build/make) mmahut,awjb libopensync-plugin-synce-0.22-4.fc8 (build/make) awjb libprelude-0.9.13-1.fc7 (build/make) tscherf libtommath-0.41-7.fc9 (build/make) jjh libtunepimp-0.5.3-9.fc8 (build/make) rdieter,kwizart libusb-0.1.12-12.fc9 (build/make) jnovy libzzub-0.2.3-10.fc9 (build/make) akahl,mtasaka liferea-1.4.10-1.fc9 (build/make) bpepple lineak-kdeplugins-0.9-2.fc6 (build/make) xris linkchecker-4.7-10.fc8 (build/make) mikep ltrace-0.5-9.45svn.fc8 (build/make) pmachata lvm2-2.02.29-5.fc9 (build/make) lvm-team,agk,mornfall,bmr,mbroz,dwysocha,bmarzins lybniz-1.3.1-1.fc9 (build/make) firewing m2crypto-0.18.2-2 (build/make) mitr mail-notification-5.0-0.2.rc1.fc9 (build/make) thl,buc makehuman-0.9-3.fc8 (build/make) kwizart maniadrive-1.2-6.fc9 (build/make) jwrdegoede mash-0.2.10-1.fc9 (build/make) notting,jkeating maven-wagon-1.0-0.1.a5.3jpp.1.fc7 (build/make) mwringe mbuffer-20070502-1.fc7 (open_missing_mode) adalloz metamonitor-0.4.5-3.fc6 (build/make) eitch module-init-tools-3.4-2.fc8 (build/make) jcm moin-1.5.8-2.fc8 (build/make) thias moto4lin-0.3-6.fc7 (build/make) jafo mugshot-1.1.56-1.fc8 (build/make) otaylor multisync-0.91.0-1.fc7 (build/make) awjb mx-2.0.6-3 (build/make) misa mx4j-3.0.1-6jpp.4 (build/make) fnasser mysql-5.0.45-6.fc9 (build/make) tgl nautilus-open-terminal-0.8-2.fc8 (build/make) pfrields nemiver-0.4.0-1.fc8 (build/make) pgordon netlabel_tools-0.17-5.fc6 (build/make) sconklin,sconklin ntfs-config-1.0-0.5.rc5.fc8 (build/make) laxathom numpy-1.0.3.1-1.fc8 (build/make) jwilson,jspaleta obexftp-0.22-0.5.rc7.fc8 (build/make) rathann obmenu-1.0-5.fc8 (build/make) mlichvar ocaml-lablgl-1.02-15.fc8 (build/make) gemi offlineimap-5.99.4-1.fc9 (build/make) till oggconvert-0.3.0-14.fc9 (build/make) ngompa oooqs2-1.0-3.fc6 (build/make) ausil openais-0.80.1-6 (open_missing_mode) sdake,sdake openbabel-2.1.1-2.fc9 (build/make) rathann orange-0.3-6.cvs20051118.fc9 (build/make) awjb orpie-1.4.3-5.fc6 (build/make) xris ots-0.4.2-11.fc7 (build/make) pgordon pam_abl-0.2.3-3.fc7 (build/make) adalloz pan-0.132-2.fc8 (build/make) adalloz,mpeters pari-2.3.0-5.fc7 (build/make) gemi pcmanx-gtk2-0.3.5-9.336svn.fc7 (open_missing_mode) leo perl-CGI-Ajax-0.701-2.fc7 (build/make) cweyl,perl-sig perl-CGI-Session-4.20-2.fc7 (build/make) ixs,perl-sig perl-Class-Observable-1.04-2.fc7 (build/make) ixs,perl-sig perl-Class-Std-0.0.8-1.fc7 (build/make) ixs,perl-sig perl-Data-Password-1.07-1.fc7 (build/make) ixs,perl-sig perl-Email-Reply-1.202-1.fc8 (build/make) spot,perl-sig perl-Kwiki-ModPerl-0.09-4.fc7 (build/make) steve,perl-sig perl-Kwiki-NewPage-0.12-5.fc7 (build/make) steve,perl-sig perl-Kwiki-Raw-0.02-4.fc7 (build/make) steve,perl-sig perl-Kwiki-RecentChanges-0.14-3.fc7 (build/make) steve,perl-sig perl-Kwiki-Revisions-0.15-5.fc7 (build/make) steve,perl-sig perl-Kwiki-Search-0.12-5.fc7 (build/make) steve,perl-sig perl-Kwiki-UserPreferences-0.13-5.fc7 (build/make) steve,perl-sig perl-Kwiki-Users-Remote-0.04-4.fc7 (build/make) steve,perl-sig perl-Math-Vec-0.04-2.fc7 (build/make) roozbeh,perl-sig perl-Module-Build-0.2808-1.fc8 (build/make) steve,perl-sig perl-MooseX-Getopt-0.05-1.fc8 (build/make) cweyl,perl-sig perl-Net-CUPS-0.51-2.fc7 (build/make) cweyl,perl-sig perl-PDL-2.4.3-4.fc8 (build/make) rnorwood perl-POE-Component-Child-1.39-2.fc6 (build/make) cweyl,perl-sig perl-POE-Component-Client-LDAP-0.04-3.fc6 (build/make) cweyl,perl-sig perl-POE-Component-SNMP-1.07-1.fc6 (build/make) cweyl,perl-sig perl-POE-Component-Server-HTTP-0.09-3.fc6 (build/make) cweyl,perl-sig perl-POE-Component-Server-SOAP-1.11-1.fc8 (build/make) cweyl,perl-sig perl-POE-Component-SimpleLog-1.04-1.fc6 (build/make) cweyl,perl-sig perl-POE-Wheel-Null-0.01-2.fc6 (build/make) cweyl,perl-sig perl-PPI-Tester-0.06-2.fc6 (build/make) spot,perl-sig perl-Perl-Critic-1.053-1.fc8 (build/make) cweyl,perl-sig perl-Perl-MinimumVersion-0.15-1.fc9 (build/make) corsepiu,perl-sig perl-Perl6-Bible-0.30-3.fc7 (build/make) steve,perl-sig perl-RRD-Simple-1.43-1.fc7 (build/make) cweyl,perl-sig perl-Spreadsheet-ParseExcel-0.3200-1.fc8 (build/make) steve,perl-sig,mpeters perl-Sys-SigAction-0.10-1.fc7 (build/make) ixs,perl-sig perl-Sys-Virt-0.1.1-9.fc7 (build/make) steve,perl-sig,berrange perl-XML-Filter-BufferText-1.01-2.fc7 (build/make) ixs,perl-sig perl-XML-SAX-Writer-0.50-2.fc7 (build/make) ixs,perl-sig perl-XML-Validator-Schema-1.08-1.fc7 (build/make) ixs,perl-sig perl-YAML-Parser-Syck-0.01-8.fc7 (build/make) steve,perl-sig,oliver pexpect-2.1-5.fc8 (build/make) robert pida-0.5.1-5.fc9 (build/make) rishi pikdev-0.9.2-3.fc8 (build/make) dionysos piklab-0.15.0-1.fc9 (build/make) chitlesh,dionysos pikloops-0.2.5-1.fc9 (build/make) dionysos plague-0.4.4.1-4.fc7 (build/make) dcbw planet-2.0-4.fc8 (build/make) richdawe plplot-5.8.0-5.fc9 (build/make) orion polyester-1.0.2-1.fc8 (build/make) svahl postr-0.9-1.fc8 (build/make) trondd powerpc-utils-papr-1.0.4-2.fc9 (build/make) dwmw2 prelink-0.4.0-1 (build/make) jakub prewikka-0.9.8-1.fc7 (build/make) tscherf purple-plugin_pack-2.2.0-2.fc9 (build/make) ivazquez pyOpenSSL-0.6-2.p24.9 (build/make) misa pychart-1.39-6.fc8 (build/make) spot pychecker-0.8.17-2 (build/make) vcrhonek pygame-1.7.1-14.fc7 (build/make) xulchris pygsl-0.9.1-6.fc8 (build/make) jamatos pylibacl-0.2.2-1.fc8 (build/make) szpak pylint-0.13.1-1.fc7 (build/make) icon pyparsing-1.4.7-1.fc8 (build/make) jamatos pyscript-0.6.1-1.fc8 (build/make) jspaleta python-4Suite-XML-1.0.2-1 (build/make) mitr python-GeoIP-1.2.1-9.fc8 (build/make) mfleming python-GnuPGInterface-0.3.2-2.fc8 (build/make) robert python-basemap-0.9.5-3.fc8 (build/make) jspaleta python-bibtex-1.2.4-2.fc8 (build/make) zkota python-cerealizer-0.6-2.fc9 (build/make) spot python-cherrypy-2.2.1-7.fc9 (build/make) lmacken,toshio python-cherrytemplate-1.0.0-5.fc7 (build/make) lmacken,jamatos python-configobj-4.4.0-2.fc8 (build/make) lmacken,toshio python-cpio-0.1-4.fc8 (build/make) jamatos python-dateutil-1.2-1.fc8 (build/make) jspaleta python-dialog-2.7-7.fc8 (build/make) abompard python-docs-2.5.1-1.fc8 (build/make) james,katzj python-durus-3.5-3.fc7 (build/make) shahms python-fpconst-0.7.3-1.fc8 (build/make) xulchris python-gammu-0.22-3.fc8 (build/make) laxathom python-gdata-1.0.9-1.fc9 (build/make) hadess,bjohnson python-irclib-0.4.6-3.fc7 (build/make) lmacken python-kiwi-1.9.16-1.fc8 (build/make) icon python-lirc-0.0.5-5 (build/make) thias python-logilab-astng-0.17.0-1.fc7 (build/make) icon python-logilab-common-0.21.2-1.fc7 (build/make) icon python-meld3-0.6-2.fc7.1 (build/make) mmcgrath,toshio python-memcached-1.39-1.fc8 (build/make) jafo python-metar-1.3.0-2.fc7 (build/make) thias python-nltk-0.9-0.2.b2.fc8 (build/make) salimma python-nltk_lite-0.9-0.1.b2.fc8 (build/make) salimma python-numarray-1.5.2-4.fc8 (build/make) orion python-ogg-1.3-7 (build/make) thias python-psyco-1.5.1-5.fc7 (build/make) shahms python-pydns-2.3.0-5.fc7 (build/make) jafo python-pyspf-2.0.3-1.fc8 (build/make) jafo python-quixote-2.4-5.fc7 (build/make) shahms python-reportlab-2.1-1.fc8 (build/make) bpepple python-simpletal-4.1-5.fc7 (build/make) shahms python-smbpasswd-1.0.1-6.fc8 (build/make) s4504kr python-sqlite2-2.3.3-1.fc7 (build/make) gajownik,lmacken python-sqlobject-0.9.2-1.fc9 (build/make) lmacken,toshio python-tag-0.91-5 (build/make) thias python-telepathy-0.14.0-4.fc9 (build/make) bpepple,tjikkun python-tpg-3.1.0-4.fc7 (build/make) shahms python-twisted-conch-0.8.0-1.fc8 (build/make) thomasvs python-twisted-core-2.5.0-2.fc8 (build/make) thomasvs python-twisted-lore-0.2.0-4.fc7 (build/make) thomasvs python-twisted-mail-0.4.0-1.fc8 (build/make) thomasvs python-twisted-names-0.4.0-1.fc8 (build/make) thomasvs python-twisted-news-0.3.0-1.fc8 (build/make) thomasvs python-twisted-runner-0.2.0-4.fc7 (build/make) thomasvs python-twisted-web-0.7.0-1.fc8 (build/make) thomasvs python-twisted-words-0.5.0-1.fc8 (build/make) thomasvs python-urlgrabber-3.0.0-3.fc8 (build/make) katzj python-urljr-1.0.1-1.fc7 (build/make) jcollie python-virtinst-0.300.1-3.fc8 (build/make) berrange python-vorbis-1.5-0.2.a (build/make) thias python-which-1.1.0-2.fc9 (build/make) nbecker,pertusus pytz-2006p-2.fc7 (build/make) jspaleta pyxattr-0.2.2-1.fc8 (build/make) szpak pyxdg-0.15-5.fc8.1 (build/make) spot,jpmahowa,sindrepb pyxf86config-0.3.34-1.fc8 (build/make) ajax pyxmms-2.06-4.fc7 (build/make) pfj pyzor-0.4.0-11.fc7 (build/make) ixs qa-assistant-0.4.90.5-2.fc6 (build/make) toshio qalculate-kde-0.9.6-2.fc8 (build/make) deji quadkonsole-2.0.2-1.fc7 (build/make) nomis80 quesoglc-0.6.5-4.fc9 (build/make) karlik radvd-1.0-5.fc9 (build/make) mnagy raidem-0.3.1-7.fc8 (build/make) jwrdegoede rdiff-backup-1.0.5-5.fc8 (build/make) ghenry,kevin rekall-2.4.5-6.fc8.1 (build/make) spot repoman-0.9-3.fc8 (build/make) dcantrel,clumens rkward-0.4.8-2.fc9 (build/make) pingou rosegarden4-1.6.0-1.fc7 (build/make) seg rpy-1.0-0.5.RC3.fc9 (build/make) jamatos,alexlan ruby-bdb-0.6.0-1.fc7 (build/make) errr ruby-fam-0.2.0-5.fc8 (build/make) lutter ruby-gettext-package-1.10.0-1.fc8 (build/make) mtasaka ruby-mecab-0.96-2.fc9.1 (build/make) mtasaka ruby-ncurses-1.1-5.fc8 (build/make) isimluk ruby-postgres-0.7.1-7.fc8 (build/make) lutter ruby-rpm-1.2.3-3.fc9 (build/make) lutter ruby-shadow-1.4.1-10.fc8 (build/make) georgiou ruby-sqlite3-1.2.1-1.fc8 (build/make) lutter rubygem-actionmailer-2.0.1-1.fc9 (build/make) lutter,sseago rubygem-actionpack-2.0.1-1.fc9 (build/make) lutter,sseago rubygem-activerecord-2.0.1-1.fc9 (build/make) lutter,sseago rubygem-activeresource-2.0.1-1.fc9 (build/make) lutter rubygem-activesupport-2.0.1-1.fc9 (build/make) lutter,sseago rubygem-daemons-1.0.7-2.fc8 (build/make) sseago rubygem-gem_plugin-0.2.2-2.fc8 (build/make) sseago rubygem-mongrel-1.0.1-5.fc8 (build/make) sseago rubygem-rake-0.7.3-2.fc8 (build/make) lutter,sseago rubygems-0.9.4-1.fc8 (build/make) lutter s3switch-0.0-9.20020912.fc6 (build/make) pwouters scipy-0.6.0-3.fc8 (build/make) jspaleta scons-0.97-2.fc8 (build/make) gemi scorched3d-41.1-1.fc9 (build/make) jwrdegoede sdljava-0.9.1-7.fc9 (build/make) jwrdegoede selinux-doc-1.26-1.1 (build/make) dwalsh setools-3.3.2-1.fc9 (build/make) pebenito,dwalsh six-0.5.3-6.fc8 (build/make) rafalzaq skencil-0.6.17-15.20070606svn.fc8 (build/make) gemi snake-0.9-0.5git.fc9 (build/make) jlaska,wwoods sobby-0.4.4-1.fc8 (build/make) lmacken sos-1.6-5.fc8 (build/make) navid specto-0.2.0-4.fc8 (build/make) laxathom straw-0.27-12.fc9 (build/make) subhodip subversion-1.4.4-11 (build/make) jorton supervisor-2.1-3.fc7 (build/make) mmcgrath,toshio svnmailer-1.0.8-3.fc7 (build/make) mfleming syck-0.61-3.fc9 (build/make) oliver synce-kde-0.9.1-1.fc7 (build/make) awjb,abompard syslog-ng-2.0.5-1.fc8 (build/make) silfreed,silfreed,pvrabec systemtap-0.6-1.fc9 (build/make) fche,wcohen tailor-0.9.29-1.fc9 (build/make) sharkcz tastymenu-0.8.2-2.fc8 (build/make) nixaff4 tbcload-1.4-5.20061030cvs.fc8 (build/make) wart tcl-tcldict-8.5.2-2.fc8 (build/make) wart tclabc-1.0.9-1.fc7 (build/make) gemi tclcompiler-1.5-3.20061030cvs.fc8 (build/make) wart tcltls-1.5.0-12.fc9 (build/make) tjikkun testoob-1.13-4.fc8 (build/make) dgoodwin tix-8.4.2-2.fc8 (build/make) vcrhonek totem-2.21.5-3.fc9 (build/make) hadess translate-toolkit-0.10.1-4.fc7 (build/make) roozbeh udev-116-3.fc8 (build/make) harald unison-2.13.16-3.fc6 (build/make) gemi ustr-1.0.2-4.fc9 (build/make) james veusz-0.10-16.fc8 (build/make) jsanders vim-7.1.159-1.fc9 (build/make) karsten vkeybd-0.1.17a-5.fc8 (build/make) green vnc-4.1.2-23.fc9 (build/make) atkac vtk-5.0.3-20.fc8 (build/make) athimm wammu-0.19-3.fc8 (build/make) laxathom wlassistant-0.5.7-4.fc8 (build/make) spot wordtrans-1.1-0.2.pre13.fc7 (build/make) than wuja-0.0.8-2.fc8 (build/make) dgoodwin wv-1.2.4-2.fc8 (build/make) abompard wxPython-2.8.4.0-2.fc8 (build/make) mattdm xaos-3.2.3-1.fc7 (build/make) gemi xca-0.6.4-1.fc8 (build/make) ensc xdaliclock-2.23-3.fc6 (build/make) kaboom xen-3.1.2-2.fc9 (build/make) xen-maint xfce4-battery-plugin-0.5.0-2.fc7 (build/make) cwickert xferstats-2.16-14.1 (build/make) than xml-commons-resolver-1.1-1jpp.12 (build/make) fnasser xmlunit-1.0-4jpp.1.fc7 (build/make) pcheung xorg-x11-drv-acecad-1.1.0-5.fc8 (build/make) xgl-maint xorg-x11-drv-apm-1.1.1-7.fc8 (build/make) xgl-maint xorg-x11-drv-ark-0.6.0-6.fc8 (build/make) xgl-maint xorg-x11-drv-ast-0.81.0-6.fc8 (build/make) xgl-maint xorg-x11-drv-calcomp-1.1.0-4.fc8 (build/make) xgl-maint xorg-x11-drv-chips-1.1.1-5.fc8 (build/make) xgl-maint xorg-x11-drv-cirrus-1.1.0-5.fc8 (build/make) xgl-maint xorg-x11-drv-citron-2.2.0-2.fc7 (build/make) xgl-maint xorg-x11-drv-dmc-1.1.0-3.fc7 (build/make) xgl-maint xorg-x11-drv-dynapro-1.1.0-3.fc7 (build/make) xgl-maint xorg-x11-drv-glint-1.1.1-7.fc8 (build/make) xgl-maint xorg-x11-drv-i128-1.2.1-1.fc8 (build/make) xgl-maint xorg-x11-drv-i740-1.1.0-5.fc8 (build/make) xgl-maint xorg-x11-drv-i810-2.2.0-2.fc9 (build/make) xgl-maint xorg-x11-drv-magellan-1.1.0-4.fc8 (build/make) xgl-maint xorg-x11-drv-microtouch-1.1.0-2.fc7 (build/make) xgl-maint xorg-x11-drv-nv-2.1.6-2.fc9 (build/make) xgl-maint xorg-x11-drv-penmount-1.1.0-3.fc7 (build/make) xgl-maint xorg-x11-drv-rendition-4.1.3-5.fc8 (build/make) xgl-maint xorg-x11-drv-s3-0.5.0-5.fc8 (build/make) xgl-maint xorg-x11-drv-s3virge-1.9.1-5.fc8 (build/make) xgl-maint xorg-x11-drv-savage-2.1.3-99.20071210.fc9 (build/make) xgl-maint xorg-x11-drv-siliconmotion-1.5.1-3.fc8 (build/make) xgl-maint xorg-x11-drv-sis-0.9.3-4.fc8 (build/make) xgl-maint xorg-x11-drv-spaceorb-1.1.0-4.fc8 (build/make) xgl-maint xorg-x11-drv-tdfx-1.3.0-6.fc8 (build/make) xgl-maint xorg-x11-drv-trident-1.2.3-6.fc8 (build/make) xgl-maint xorg-x11-drv-tseng-1.1.0-7.fc8 (build/make) xgl-maint xorg-x11-drv-vga-4.1.0-5.fc8 (build/make) xgl-maint xorg-x11-drv-via-0.2.2-4.fc8 (build/make) xgl-maint xorg-x11-drv-vmware-10.15.2-1.fc8 (build/make) xgl-maint xorg-x11-drv-voodoo-1.1.1-1.fc8 (build/make) xgl-maint xscreensaver-5.04-3.fc9 (build/make) mtasaka yakuake-2.7.5-4.fc7 (build/make) gajownik yelp-2.21.1-3.fc9 (build/make) mbarnes yum-metadata-parser-1.1.2-2.fc9 (build/make) skvidal,katzj,skvidal,pnasrat,jbowes zeroinstall-injector-0.30-2.fc8 (build/make) salimma With bugs filed: 0 ---------------------------------- -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From Matt_Domsch at dell.com Mon Jan 7 22:46:08 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 7 Jan 2008 16:46:08 -0600 Subject: Fedora i386 rawhide rebuild in mock status 2008-01-05 Message-ID: <20080107224608.GA14141@humbolt.us.dell.com> Fedora Rawhide-in-Mock Build Results for i386 using the rawhide tree as of Saturday, January 5, 2008. This is a full rebuild of all packages. Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 5164 Number failed to build: 491 Number expected to fail due to ExclusiveArch or ExcludeArch: 13 Leaving: 478 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 478 ---------------------------------- Django-0.96.1-1.fc9 (build/make) salimma GtkAda-2.8.0-7.fc7 (build/make) gemi LabPlot-1.5.1.6-4.fc8 (build/make) chitlesh PyRTF-0.45-5.fc8 (build/make) jamatos,mpeters,jamatos PySolFC-1.1-4.fc9 (build/make) firewing PyX-0.9-5.fc8 (build/make) jamatos,mpeters,jamatos QuantLib-0.8.1-4.fc9 (build/make) spot R-Biobase-1.16.1-3.fc9 (build/make) pingou R-BufferedMatrix-1.2.0-1.fc9 (build/make) pingou R-abind-1.1-1.fc9 (build/make) spot R-acepack-1.3-2.fc9 (build/make) spot R-mAr-1.1-11.fc8 (build/make) jamatos R-tkWidgets-1.16.0-1.fc9 (build/make) pingou R-waveslim-1.6-4.fc8 (build/make) jamatos R-wavethresh-2.2-7.fc8 (build/make) jamatos R-widgetTools-1.15.0-1.fc9 (build/make) pingou SOAPpy-0.11.6-6.fc7 (build/make) xulchris ScientificPython-2.6-10.fc8 (build/make) jspaleta aasaver-0.3.2-1.fc8 (build/make) oddsocks abiword-2.4.6-6.fc8 (build/make) uwog airsnort-0.2.7e-11.fc7 (build/make) awjb alliance-5.0-10.20070718snap.fc8 (build/make) chitlesh amarokFS-0.5-1.fc7 (build/make) faucamp anjuta-gdl-0.7.3-2.fc9 (build/make) rishi arm-gp2x-linux-glibc-2.3.6-4.fc8 (build/make) jwrdegoede athcool-0.3.11-5.fc6 (build/make) gajownik atlas-3.6.0-12.fc8 (build/make) qspencer avr-libc-1.4.6-4.fc8 (build/make) jwrdegoede awesfx-0.5.0d-4.fc7 (build/make) stransky bacula-2.0.3-11.fc8 (build/make) ixs,mmcgrath balsa-2.3.21-1.fc9 (build/make) pawsa bcfg2-0.9.5.2-1.fc9 (build/make) jcollie binutils-2.18.50.0.3-1 (build/make) jakub bitbake-1.8.8-1.fc8 (build/make) ixs bittorrent-4.4.0-5.fc7 (build/make) pghmcfc blogtk-1.1-8.fc7 (build/make) pfrields bluecurve-kwin-theme-1.0.0-1.fc8 (build/make) rstrode,rdieter,davidz,kkofler brltty-3.8-1.fc8 (build/make) tjanouse camstream-0.26.3-12.fc8 (open_missing_mode) nomis80 castor-0.9.5-1jpp.7 (build/make) pcheung chkfontpath-1.10.1-2.fc8 (build/make) krh,fonts-sig clearsilver-0.10.4-5.fc8 (build/make) jcollie,limb clips-6.24-22.fc7 (build/make) rvinyard clisp-2.43-3.fc9 (build/make) gemi,green cmucl-19d-5.fc8 (build/make) rdieter,green cobbler-0.6.4-2.fc9 (build/make) mdehaan compat-gcc-296-2.96-139 (build/make) jakub compat-gcc-32-3.2.3-62 (build/make) jakub compat-gcc-34-3.4.6-8 (build/make) jakub compiz-0.6.2-4.fc9 (build/make) krh compizconfig-backend-kconfig-0.6.0-1.fc9 (build/make) izhar,izhar conexus-0.5.3-2.fc8 (build/make) rvinyard cryptix-asn1-20011119-7jpp.2 (build/make) vivekl crystal-1.0.5-1.fc8 (build/make) chitlesh csound-5.03.0-13.fc7 (build/make) dcbw,pfj ctrlproxy-3.0.3-1.fc9 (build/make) jwboyer d4x-2.5.7.1-3.fc7 (build/make) thias darcs-1.0.9-6.fc8 (build/make) jjh,petersen db4o-6.1-2.fc7 (build/make) pfj dejagnu-1.4.4-11 (build/make) pmachata dekorator-0.3-3.fc7 (build/make) faucamp device-mapper-multipath-0.4.7-11.fc7 (build/make) lvm-team,agk,mornfall,mbroz,dwysocha,bmarzins dia-0.96.1-5.fc9 (build/make) jwrdegoede digikam-doc-0.9.3-0.1.beta3.fc9 (build/make) mgarski,rdieter dmraid-1.0.0.rc14-6.fc9 (build/make) lvm-team,agk,mornfall,bmr,mbroz,mauelsha,dwysocha dogtail-0.6.1-1.fc7 (build/make) zmc driconf-0.9.1-6.fc8 (build/make) kevin drivel-2.1.1-0.3.20071130svn.fc9 (build/make) pfrields duplicity-0.4.3-1.fc8 (build/make) robert e2fsprogs-1.40.4-2.fc9 (build/make) sandeen,oliver,kzak eclipse-emf-2.2.2-1.fc7 (build/make) overholt eclipse-mylyn-2.0.0-9.fc8 (build/make) overholt epiphany-2.21.5-0.1.svn7844.fc9 (build/make) gecko-maint epiphany-extensions-2.20.1-3.fc9 (build/make) caillon,pgordon epydoc-2.1-8.fc8 (build/make) thias epylog-1.0.3-5.fc7 (build/make) icon esc-1.0.1-7.fc8 (build/make) jmagne evolution-brutus-1.1.28.7-2.fc8 (build/make) bpepple expect-5.43.0-9.fc8 (build/make) vcrhonek findutils-4.2.31-2.fc8 (build/make) vcrhonek flagpoll-0.9.1-1.fc8 (build/make) deji fluxconf-0.9.9-4.fc8 (build/make) awjb fluxstyle-1.0.1-2.fc7 (build/make) errr fonttools-2.0-0.11.20060223cvs.fc7 (build/make) roozbeh,fonts-sig fontypython-0.2.0-6.fc7 (build/make) cr33dog,fonts-sig freetennis-0.4.8-6.fc7 (build/make) rjones func-0.13-3.fc9 (build/make) mdehaan,skvidal,alikins fusion-icon-0-0.2.20071206git.fc9 (build/make) karlik galternatives-0.13.4-4.fc7 (build/make) deji gambas-1.0.19-3.fc8 (build/make) spot gazpacho-0.7.2-2.fc8 (build/make) icon gcl-2.6.7-15.fc8 (build/make) gemi,green gdb-6.7.1-6.fc9 (build/make) jkratoch gdl-0.9-0.pre6.fc9 (build/make) orion gdmap-0.7.5-6.fc6 (build/make) splinux gdome2-0.8.1-5.2.fc7 (build/make) bjohnson gedit-plugins-2.18.0-2.fc7 (build/make) trondd getmail-4.7.7-2.fc9 (build/make) knol gfa-0.4.1-4.fc7 (build/make) splinux gg2-2.3.0-5.fc9 (build/make) rathann gjots2-2.3.4-7.fc7 (build/make) rvokal glibmm24-2.14.2-1.fc9 (build/make) denis glipper-0.95.1-2.fc7 (build/make) splinux gnash-0.8.1-6.fc9 (build/make) pertusus gnome-applet-vm-0.1.2-2.fc7 (build/make) kzak gnome-device-manager-0.2-2.fc9 (build/make) davidz gnome-media-2.20.1-7.fc9 (build/make) hadess gnome-python2-desktop-2.21.1-1.fc9 (build/make) mbarnes gnome-scan-0.5.3-0.1.20071030svn.fc9 (build/make) deji gnome-web-photo-0.3-8.fc9 (build/make) hadess gnubiff-2.2.7-3.fc9 (build/make) splinux gnupg-1.4.8-1 (build/make) nalin,rdieter gourmet-0.13.4-1.fc8 (build/make) jspaleta gquilt-0.20-1.fc7 (build/make) jwboyer gresistor-0.0.1-11.fc8 (build/make) chitlesh gstm-1.2-6.fc7 (build/make) splinux gstreamer-plugins-good-0.10.6-6.fc8 (build/make) ajax gtk-qt-engine-0.8-1.fc9 (build/make) rdieter gtk-sharp-1.0.10-12.fc7 (build/make) pfj gtk2hs-0.9.12.1-8.fc9 (build/make) bos,petersen gtkmathview-0.7.6-5.fc6 (needs_popt-devel) uwog gwenview-1.4.2-1.fc9 (build/make) abompard gwget-0.99-3.fc8 (build/make) cwickert hotwire-0.620-1.fc9 (build/make) walters ht2html-2.0-5.fc6 (build/make) ifoox htop-0.6.5-1.fc7 (build/make) gajownik hunspell-ar-0.20060208-1.fc8 (build/make) danken icecream-0.8.0-6.20071101svn.fc9 (build/make) michich inkscape-0.45.1-5.fc9 (build/make) denis ip-sentinel-0.12-10.fc7 (build/make) ensc isdn4k-utils-3.2-55.fc8 (build/make) than itcl-3.3-0.11.RC1.fc9 (build/make) wart java-1.5.0-gcj-1.5.0.0-17.fc8 (build/make) fitzsim jgroups-2.2.9.2-3jpp.2 (build/make) vivekl jokosher-1.0-0.1.20070929svn.fc8 (build/make) snecker kaffeine-0.8.5-5.fc8 (build/make) rdieter,scop,mef kannel-1.4.1-5 (build/make) thias katapult-0.3.2.1-2.fc8 (build/make) chitlesh kazehakase-0.5.0-1.fc9.2 (build/make) mtasaka kbackup-0.5.2-1.fc8 (build/make) dionysos kbibtex-0.1.5.52-10.fc7 (build/make) noltec kbiof-0.3-1.fc8 (build/make) oddsocks kcemirror-0.1.5-1.fc7 (build/make) awjb,abompard kchmviewer-3.0-2.fc7 (build/make) pertusus,jpo kcometen3-1.1-5.fc8 (build/make) oddsocks kdbg-2.0.5-2.fc7 (build/make) than kdetv-0.8.9-8.fc9 (build/make) oddsocks kdirstat-2.5.3-6.fc8 (build/make) chitlesh kdissert-1.0.7-1.fc7 (build/make) icon keurocalc-0.9.7-3.fc8 (build/make) chitlesh kflickr-0.9-1.fc8 (build/make) stahnma kgtk-0.8-2.fc7 (build/make) faucamp kicker-compiz-3.5.4-4.fc8 (build/make) laxathom kio_p7zip-0.3.1-5.fc8 (build/make) nixaff4 kio_resources-0.2-3.fc8 (build/make) chitlesh kiosktool-1.0-8.fc8 (build/make) rdieter kleansweep-0.2.9-5.fc8 (build/make) chitlesh klear-0.6.1-1.fc8 (build/make) trasher klibido-0.2.5-8.fc8 (build/make) faucamp kmobiletools-0.4.3.3-3.fc6 (build/make) ausil knemo-0.4.7-1.fc7 (build/make) faucamp knetstats-1.6.1-4.fc8 (build/make) chitlesh koan-0.6.3-3.fc9 (build/make) mdehaan koffice-langpack-1.6.3-1.fc8 (build/make) awjb kompose-0.5.3-8.fc8 (build/make) orion konversation-1.0.1-3.fc8 (build/make) ausil kooldock-0.4.6-2.fc8 (build/make) ecik kover-3-2 (build/make) adrian koverartist-0.5-8.fc8 (build/make) svahl kphotobymail-0.4.1-1.fc7 (build/make) kushal kpolynome-0.1.2-10.fc8 (build/make) chitlesh kpowersave-0.7.3-1.fc9 (build/make) ausil,rdieter krecipes-0.9.1-6.fc8 (build/make) ausil krename-3.0.14-2.fc8 (build/make) ecik kshutdown-1.0.1-1.fc8 (build/make) chitlesh ksplash-engine-moodin-0.4.2-4.fc7 (build/make) trasher,chitlesh ksshaskpass-0.3-3.fc8 (build/make) abompard ksynaptics-0.3.3-2.fc8 (build/make) orion ktechlab-0.3.69-5.fc8 (build/make) chitlesh kyum-0.7.5-9.fc8 (build/make) s4504kr ladspa-1.12-8.fc7 (build/make) thomasvs ldapjdk-4.17-1jpp.7 (build/make) vivekl libchewing-0.3.0-8.fc8 (open_missing_mode) cchance libepc-0.3.1-1.fc9 (build/make) bpepple libevent-1.3b-1.fc7 (build/make) steved,ertzing libieee1284-0.2.11-1.fc8 (build/make) twaugh libkexif-0.2.5-2.fc8 (build/make) abompard,rdieter libkexiv2-0.1.6-2.fc9 (build/make) rdieter,mgarski libkipi-0.1.5-2.fc8 (build/make) abompard,rdieter libopensync-plugin-sunbird-0.22-3.fc7 (build/make) mmahut,awjb libopensync-plugin-synce-0.22-4.fc8 (build/make) awjb libprelude-0.9.13-1.fc7 (build/make) tscherf libtommath-0.41-7.fc9 (build/make) jjh libtunepimp-0.5.3-9.fc8 (build/make) rdieter,kwizart libusb-0.1.12-12.fc9 (build/make) jnovy libzzub-0.2.3-10.fc9 (build/make) akahl,mtasaka liferea-1.4.10-1.fc9 (build/make) bpepple lineak-kdeplugins-0.9-2.fc6 (build/make) xris linkchecker-4.7-10.fc8 (build/make) mikep ltrace-0.5-9.45svn.fc8 (build/make) pmachata lvm2-2.02.29-5.fc9 (build/make) lvm-team,agk,mornfall,bmr,mbroz,dwysocha,bmarzins lybniz-1.3.1-1.fc9 (build/make) firewing m2crypto-0.18.2-2 (build/make) mitr mail-notification-5.0-0.2.rc1.fc9 (build/make) thl,buc makehuman-0.9-3.fc8 (build/make) kwizart mash-0.2.10-1.fc9 (build/make) notting,jkeating maven-wagon-1.0-0.1.a5.3jpp.1.fc7 (build/make) mwringe mbuffer-20070502-1.fc7 (open_missing_mode) adalloz metamonitor-0.4.5-3.fc6 (build/make) eitch module-init-tools-3.4-2.fc8 (build/make) jcm moin-1.5.8-2.fc8 (build/make) thias mosml-2.01-9.fc7 (build/make) gemi moto4lin-0.3-6.fc7 (build/make) jafo mugshot-1.1.56-1.fc8 (build/make) otaylor multisync-0.91.0-1.fc7 (build/make) awjb mx-2.0.6-3 (build/make) misa mx4j-3.0.1-6jpp.4 (build/make) fnasser mysql-5.0.45-6.fc9 (build/make) tgl nautilus-open-terminal-0.8-2.fc8 (build/make) pfrields nemiver-0.4.0-1.fc8 (build/make) pgordon netlabel_tools-0.17-5.fc6 (build/make) sconklin,sconklin numpy-1.0.3.1-1.fc8 (build/make) jwilson,jspaleta obexftp-0.22-0.5.rc7.fc8 (build/make) rathann obmenu-1.0-5.fc8 (build/make) mlichvar ocaml-lablgl-1.02-15.fc8 (build/make) gemi offlineimap-5.99.4-1.fc9 (build/make) till oggconvert-0.3.0-14.fc9 (build/make) ngompa oooqs2-1.0-3.fc6 (build/make) ausil openais-0.80.1-6 (open_missing_mode) sdake,sdake openbabel-2.1.1-2.fc9 (build/make) rathann orange-0.3-6.cvs20051118.fc9 (build/make) awjb orpie-1.4.3-5.fc6 (build/make) xris ots-0.4.2-11.fc7 (build/make) pgordon pam_abl-0.2.3-3.fc7 (build/make) adalloz pan-0.132-2.fc8 (build/make) adalloz,mpeters pari-2.3.0-5.fc7 (build/make) gemi pcmanx-gtk2-0.3.5-9.336svn.fc7 (open_missing_mode) leo perl-CGI-Ajax-0.701-2.fc7 (build/make) cweyl,perl-sig perl-CGI-Session-4.20-2.fc7 (build/make) ixs,perl-sig perl-Class-Observable-1.04-2.fc7 (build/make) ixs,perl-sig perl-Class-Std-0.0.8-1.fc7 (build/make) ixs,perl-sig perl-Data-Password-1.07-1.fc7 (build/make) ixs,perl-sig perl-Email-Reply-1.202-1.fc8 (build/make) spot,perl-sig perl-Kwiki-ModPerl-0.09-4.fc7 (build/make) steve,perl-sig perl-Kwiki-NewPage-0.12-5.fc7 (build/make) steve,perl-sig perl-Kwiki-Raw-0.02-4.fc7 (build/make) steve,perl-sig perl-Kwiki-RecentChanges-0.14-3.fc7 (build/make) steve,perl-sig perl-Kwiki-Revisions-0.15-5.fc7 (build/make) steve,perl-sig perl-Kwiki-Search-0.12-5.fc7 (build/make) steve,perl-sig perl-Kwiki-UserPreferences-0.13-5.fc7 (build/make) steve,perl-sig perl-Kwiki-Users-Remote-0.04-4.fc7 (build/make) steve,perl-sig perl-Math-Vec-0.04-2.fc7 (build/make) roozbeh,perl-sig perl-Module-Build-0.2808-1.fc8 (build/make) steve,perl-sig perl-MooseX-Getopt-0.05-1.fc8 (build/make) cweyl,perl-sig perl-Net-CUPS-0.51-2.fc7 (build/make) cweyl,perl-sig perl-PDL-2.4.3-4.fc8 (build/make) rnorwood perl-POE-Component-Child-1.39-2.fc6 (build/make) cweyl,perl-sig perl-POE-Component-Client-LDAP-0.04-3.fc6 (build/make) cweyl,perl-sig perl-POE-Component-SNMP-1.07-1.fc6 (build/make) cweyl,perl-sig perl-POE-Component-Server-HTTP-0.09-3.fc6 (build/make) cweyl,perl-sig perl-POE-Component-Server-SOAP-1.11-1.fc8 (build/make) cweyl,perl-sig perl-POE-Component-SimpleLog-1.04-1.fc6 (build/make) cweyl,perl-sig perl-POE-Wheel-Null-0.01-2.fc6 (build/make) cweyl,perl-sig perl-PPI-Tester-0.06-2.fc6 (build/make) spot,perl-sig perl-Perl-Critic-1.053-1.fc8 (build/make) cweyl,perl-sig perl-Perl-MinimumVersion-0.15-1.fc9 (build/make) corsepiu,perl-sig perl-Perl6-Bible-0.30-3.fc7 (build/make) steve,perl-sig perl-RRD-Simple-1.43-1.fc7 (build/make) cweyl,perl-sig perl-Spreadsheet-ParseExcel-0.3200-1.fc8 (build/make) steve,perl-sig,mpeters perl-Sys-SigAction-0.10-1.fc7 (build/make) ixs,perl-sig perl-Sys-Virt-0.1.1-9.fc7 (build/make) steve,perl-sig,berrange perl-XML-Filter-BufferText-1.01-2.fc7 (build/make) ixs,perl-sig perl-XML-SAX-Writer-0.50-2.fc7 (build/make) ixs,perl-sig perl-XML-Validator-Schema-1.08-1.fc7 (build/make) ixs,perl-sig perl-YAML-Parser-Syck-0.01-8.fc7 (build/make) steve,perl-sig,oliver pida-0.5.1-5.fc9 (build/make) rishi pikdev-0.9.2-3.fc8 (build/make) dionysos piklab-0.15.0-1.fc9 (build/make) chitlesh,dionysos pikloops-0.2.5-1.fc9 (build/make) dionysos plague-0.4.4.1-4.fc7 (build/make) dcbw planet-2.0-4.fc8 (build/make) richdawe plplot-5.8.0-5.fc9 (build/make) orion polyester-1.0.2-1.fc8 (build/make) svahl postr-0.9-1.fc8 (build/make) trondd powerpc-utils-papr-1.0.4-2.fc9 (build/make) dwmw2 prelink-0.4.0-1 (build/make) jakub prewikka-0.9.8-1.fc7 (build/make) tscherf purple-plugin_pack-2.2.0-2.fc9 (build/make) ivazquez pyOpenSSL-0.6-2.p24.9 (build/make) misa pychart-1.39-6.fc8 (build/make) spot pychecker-0.8.17-2 (build/make) vcrhonek pygame-1.7.1-14.fc7 (build/make) xulchris pygsl-0.9.1-6.fc8 (build/make) jamatos pylibacl-0.2.2-1.fc8 (build/make) szpak pylint-0.13.1-1.fc7 (build/make) icon pyparsing-1.4.7-1.fc8 (build/make) jamatos pyscript-0.6.1-1.fc8 (build/make) jspaleta python-4Suite-XML-1.0.2-1 (build/make) mitr python-GeoIP-1.2.1-9.fc8 (build/make) mfleming python-GnuPGInterface-0.3.2-2.fc8 (build/make) robert python-basemap-0.9.5-3.fc8 (build/make) jspaleta python-bibtex-1.2.4-2.fc8 (build/make) zkota python-cerealizer-0.6-2.fc9 (build/make) spot python-cherrypy-2.2.1-7.fc9 (build/make) lmacken,toshio python-cherrytemplate-1.0.0-5.fc7 (build/make) lmacken,jamatos python-configobj-4.4.0-2.fc8 (build/make) lmacken,toshio python-cpio-0.1-4.fc8 (build/make) jamatos python-dateutil-1.2-1.fc8 (build/make) jspaleta python-dialog-2.7-7.fc8 (build/make) abompard python-docs-2.5.1-1.fc8 (build/make) james,katzj python-durus-3.5-3.fc7 (build/make) shahms python-fpconst-0.7.3-1.fc8 (build/make) xulchris python-gammu-0.22-3.fc8 (build/make) laxathom python-gdata-1.0.9-1.fc9 (build/make) hadess,bjohnson python-irclib-0.4.6-3.fc7 (build/make) lmacken python-kiwi-1.9.16-1.fc8 (build/make) icon python-lirc-0.0.5-5 (build/make) thias python-logilab-astng-0.17.0-1.fc7 (build/make) icon python-logilab-common-0.21.2-1.fc7 (build/make) icon python-meld3-0.6-2.fc7.1 (build/make) mmcgrath,toshio python-memcached-1.39-1.fc8 (build/make) jafo python-metar-1.3.0-2.fc7 (build/make) thias python-nltk-0.9-0.2.b2.fc8 (build/make) salimma python-nltk_lite-0.9-0.1.b2.fc8 (build/make) salimma python-numarray-1.5.2-4.fc8 (build/make) orion python-ogg-1.3-7 (build/make) thias python-psyco-1.5.1-5.fc7 (build/make) shahms python-pydns-2.3.0-5.fc7 (build/make) jafo python-pyspf-2.0.3-1.fc8 (build/make) jafo python-quixote-2.4-5.fc7 (build/make) shahms python-reportlab-2.1-1.fc8 (build/make) bpepple python-simpletal-4.1-5.fc7 (build/make) shahms python-smbpasswd-1.0.1-6.fc8 (build/make) s4504kr python-sqlite2-2.3.3-1.fc7 (build/make) gajownik,lmacken python-sqlobject-0.9.2-1.fc9 (build/make) lmacken,toshio python-tag-0.91-5 (build/make) thias python-telepathy-0.14.0-4.fc9 (build/make) bpepple,tjikkun python-tpg-3.1.0-4.fc7 (build/make) shahms python-twisted-conch-0.8.0-1.fc8 (build/make) thomasvs python-twisted-core-2.5.0-2.fc8 (build/make) thomasvs python-twisted-lore-0.2.0-4.fc7 (build/make) thomasvs python-twisted-mail-0.4.0-1.fc8 (build/make) thomasvs python-twisted-names-0.4.0-1.fc8 (build/make) thomasvs python-twisted-news-0.3.0-1.fc8 (build/make) thomasvs python-twisted-runner-0.2.0-4.fc7 (build/make) thomasvs python-twisted-web-0.7.0-1.fc8 (build/make) thomasvs python-twisted-words-0.5.0-1.fc8 (build/make) thomasvs python-urlgrabber-3.0.0-3.fc8 (build/make) katzj python-urljr-1.0.1-1.fc7 (build/make) jcollie python-virtinst-0.300.1-3.fc8 (build/make) berrange python-vorbis-1.5-0.2.a (build/make) thias python-which-1.1.0-2.fc9 (build/make) nbecker,pertusus pytz-2006p-2.fc7 (build/make) jspaleta pyxattr-0.2.2-1.fc8 (build/make) szpak pyxdg-0.15-5.fc8.1 (build/make) spot,jpmahowa,sindrepb pyxf86config-0.3.34-1.fc8 (build/make) ajax pyxmms-2.06-4.fc7 (build/make) pfj pyzor-0.4.0-11.fc7 (build/make) ixs qa-assistant-0.4.90.5-2.fc6 (build/make) toshio qalculate-kde-0.9.6-2.fc8 (build/make) deji quadkonsole-2.0.2-1.fc7 (build/make) nomis80 rdiff-backup-1.0.5-5.fc8 (build/make) ghenry,kevin rekall-2.4.5-6.fc8.1 (build/make) spot repoman-0.9-3.fc8 (build/make) dcantrel,clumens rkward-0.4.8-2.fc9 (build/make) pingou rosegarden4-1.6.0-1.fc7 (build/make) seg rpy-1.0-0.5.RC3.fc9 (build/make) jamatos,alexlan ruby-bdb-0.6.0-1.fc7 (build/make) errr ruby-fam-0.2.0-5.fc8 (build/make) lutter ruby-gettext-package-1.10.0-1.fc8 (build/make) mtasaka ruby-mecab-0.96-2.fc9.1 (build/make) mtasaka ruby-ncurses-1.1-5.fc8 (build/make) isimluk ruby-postgres-0.7.1-7.fc8 (build/make) lutter ruby-rpm-1.2.3-3.fc9 (build/make) lutter ruby-shadow-1.4.1-10.fc8 (build/make) georgiou ruby-sqlite3-1.2.1-1.fc8 (build/make) lutter rubygem-actionmailer-2.0.1-1.fc9 (build/make) lutter,sseago rubygem-actionpack-2.0.1-1.fc9 (build/make) lutter,sseago rubygem-activerecord-2.0.1-1.fc9 (build/make) lutter,sseago rubygem-activeresource-2.0.1-1.fc9 (build/make) lutter rubygem-activesupport-2.0.1-1.fc9 (build/make) lutter,sseago rubygem-daemons-1.0.7-2.fc8 (build/make) sseago rubygem-gem_plugin-0.2.2-2.fc8 (build/make) sseago rubygem-mongrel-1.0.1-5.fc8 (build/make) sseago rubygem-rake-0.7.3-2.fc8 (build/make) lutter,sseago rubygems-0.9.4-1.fc8 (build/make) lutter scipy-0.6.0-3.fc8 (build/make) jspaleta scons-0.97-2.fc8 (build/make) gemi selinux-doc-1.26-1.1 (build/make) dwalsh setools-3.3.2-1.fc9 (build/make) pebenito,dwalsh six-0.5.3-6.fc8 (build/make) rafalzaq skencil-0.6.17-15.20070606svn.fc8 (build/make) gemi snake-0.9-0.5git.fc9 (build/make) jlaska,wwoods sos-1.6-5.fc8 (build/make) navid specto-0.2.0-4.fc8 (build/make) laxathom straw-0.27-12.fc9 (build/make) subhodip subversion-1.4.4-11 (build/make) jorton supervisor-2.1-3.fc7 (build/make) mmcgrath,toshio svnmailer-1.0.8-3.fc7 (build/make) mfleming syck-0.61-3.fc9 (build/make) oliver synce-kde-0.9.1-1.fc7 (build/make) awjb,abompard syslog-ng-2.0.5-1.fc8 (build/make) silfreed,silfreed,pvrabec systemtap-0.6-1.fc9 (build/make) fche,wcohen tailor-0.9.29-1.fc9 (build/make) sharkcz tastymenu-0.8.2-2.fc8 (build/make) nixaff4 tbcload-1.4-5.20061030cvs.fc8 (build/make) wart tcl-tcldict-8.5.2-2.fc8 (build/make) wart tclabc-1.0.9-1.fc7 (build/make) gemi tclcompiler-1.5-3.20061030cvs.fc8 (build/make) wart tcltls-1.5.0-12.fc9 (build/make) tjikkun testoob-1.13-4.fc8 (build/make) dgoodwin tix-8.4.2-2.fc8 (build/make) vcrhonek totem-2.21.5-3.fc9 (build/make) hadess translate-toolkit-0.10.1-4.fc7 (build/make) roozbeh udev-116-3.fc8 (build/make) harald unison-2.13.16-3.fc6 (build/make) gemi ustr-1.0.2-4.fc9 (build/make) james veusz-0.10-16.fc8 (build/make) jsanders vim-7.1.159-1.fc9 (build/make) karsten vkeybd-0.1.17a-5.fc8 (build/make) green vnc-4.1.2-23.fc9 (build/make) atkac vtk-5.0.3-20.fc8 (build/make) athimm wammu-0.19-3.fc8 (build/make) laxathom wine-docs-0.9.49-1.fc9 (build/make) awjb wlassistant-0.5.7-4.fc8 (build/make) spot wordtrans-1.1-0.2.pre13.fc7 (build/make) than wuja-0.0.8-2.fc8 (build/make) dgoodwin wv-1.2.4-2.fc8 (build/make) abompard wxPython-2.8.4.0-2.fc8 (build/make) mattdm xaos-3.2.3-1.fc7 (build/make) gemi xca-0.6.4-1.fc8 (build/make) ensc xdaliclock-2.23-3.fc6 (build/make) kaboom xen-3.1.2-2.fc9 (build/make) xen-maint xfce4-battery-plugin-0.5.0-2.fc7 (build/make) cwickert xferstats-2.16-14.1 (build/make) than xml-commons-resolver-1.1-1jpp.12 (build/make) fnasser xmlunit-1.0-4jpp.1.fc7 (build/make) pcheung xorg-x11-drv-acecad-1.1.0-5.fc8 (build/make) xgl-maint xorg-x11-drv-amd-0.0-22.20070625.fc8 (build/make) xgl-maint,bernie xorg-x11-drv-apm-1.1.1-7.fc8 (build/make) xgl-maint xorg-x11-drv-ark-0.6.0-6.fc8 (build/make) xgl-maint xorg-x11-drv-ast-0.81.0-6.fc8 (build/make) xgl-maint xorg-x11-drv-calcomp-1.1.0-4.fc8 (build/make) xgl-maint xorg-x11-drv-chips-1.1.1-5.fc8 (build/make) xgl-maint xorg-x11-drv-cirrus-1.1.0-5.fc8 (build/make) xgl-maint xorg-x11-drv-citron-2.2.0-2.fc7 (build/make) xgl-maint xorg-x11-drv-cyrix-1.1.0-5.fc8 (build/make) xgl-maint xorg-x11-drv-dmc-1.1.0-3.fc7 (build/make) xgl-maint xorg-x11-drv-dynapro-1.1.0-3.fc7 (build/make) xgl-maint xorg-x11-drv-glint-1.1.1-7.fc8 (build/make) xgl-maint xorg-x11-drv-i128-1.2.1-1.fc8 (build/make) xgl-maint xorg-x11-drv-i740-1.1.0-5.fc8 (build/make) xgl-maint xorg-x11-drv-i810-2.2.0-2.fc9 (build/make) xgl-maint xorg-x11-drv-magellan-1.1.0-4.fc8 (build/make) xgl-maint xorg-x11-drv-microtouch-1.1.0-2.fc7 (build/make) xgl-maint xorg-x11-drv-neomagic-1.1.1-4.fc8 (build/make) xgl-maint xorg-x11-drv-nv-2.1.6-2.fc9 (build/make) xgl-maint xorg-x11-drv-penmount-1.1.0-3.fc7 (build/make) xgl-maint xorg-x11-drv-rendition-4.1.3-5.fc8 (build/make) xgl-maint xorg-x11-drv-s3-0.5.0-5.fc8 (build/make) xgl-maint xorg-x11-drv-s3virge-1.9.1-5.fc8 (build/make) xgl-maint xorg-x11-drv-savage-2.1.3-99.20071210.fc9 (build/make) xgl-maint xorg-x11-drv-siliconmotion-1.5.1-3.fc8 (build/make) xgl-maint xorg-x11-drv-sis-0.9.3-4.fc8 (build/make) xgl-maint xorg-x11-drv-spaceorb-1.1.0-4.fc8 (build/make) xgl-maint xorg-x11-drv-tdfx-1.3.0-6.fc8 (build/make) xgl-maint xorg-x11-drv-trident-1.2.3-6.fc8 (build/make) xgl-maint xorg-x11-drv-tseng-1.1.0-7.fc8 (build/make) xgl-maint xorg-x11-drv-vermilion-1.0.0-2.fc8 (build/make) xgl-maint xorg-x11-drv-vga-4.1.0-5.fc8 (build/make) xgl-maint xorg-x11-drv-via-0.2.2-4.fc8 (build/make) xgl-maint xorg-x11-drv-vmware-10.15.2-1.fc8 (build/make) xgl-maint xorg-x11-drv-voodoo-1.1.1-1.fc8 (build/make) xgl-maint xscreensaver-5.04-3.fc9 (build/make) mtasaka yakuake-2.7.5-4.fc7 (build/make) gajownik yelp-2.21.1-3.fc9 (build/make) mbarnes yum-metadata-parser-1.1.2-2.fc9 (build/make) skvidal,katzj,skvidal,pnasrat,jbowes zeroinstall-injector-0.30-2.fc8 (build/make) salimma With bugs filed: 0 ---------------------------------- -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From dominik at greysector.net Mon Jan 7 22:56:30 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 7 Jan 2008 23:56:30 +0100 Subject: Fedora x86_64 rawhide rebuild in mock status 2008-01-05 In-Reply-To: <20080107224330.GA14071@humbolt.us.dell.com> References: <20080107224330.GA14071@humbolt.us.dell.com> Message-ID: <20080107225629.GA5778@ryvius.greysector.net> On Monday, 07 January 2008 at 23:43, Matt Domsch wrote: > Fedora Rawhide-in-Mock Build Results for x86_64 > using the rawhide tree as of Saturday, January 5, 2008. > > This is a full rebuild of all packages. > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ > > Total packages: 5163 > Number failed to build: 527 > Number expected to fail due to ExclusiveArch or ExcludeArch: 34 > Leaving: 493 > (there may be some duplicates if rawhide has 2 versions of a package) > > Of those expected to have worked... > Without a bug filed: 493 > ---------------------------------- [...] > gg2-2.3.0-5.fc9 (build/make) rathann That's new, investigating. [...] > obexftp-0.22-0.5.rc7.fc8 (build/make) rathann Working on it. [...] > openbabel-2.1.1-2.fc9 (build/make) rathann Already fixed. Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dimi at lattica.com Mon Jan 7 22:57:26 2008 From: dimi at lattica.com (Dimi Paun) Date: Mon, 07 Jan 2008 17:57:26 -0500 Subject: Bruttaly sluggish Eclipse performance in remote X Message-ID: <1199746646.9735.10.camel@dimi.lattica.com> Folks, I am running Fedora 8 on 3 boxes, all connected via Gb Ethernet. On two of the boxes (Intel Core 2 Quad @ 2.4GHz, 4 GB RAM) I've enabled XDMCP and am logging in from the 3 via remote X. It has been a rough experience: * the default GDM screen does not have an option to invoke the XDMCP chooser, despite the working in gdmsetup. This caused great confusion until I figured that I needed to switch to Happy Gnome login theme. * performance is a bit sluggish, but bearable. However, I have used in University (back in 97-98) old Sun boxes that were doing the same over a much slower network, I was expecting a lot more now, given all the hardware I've thrown at it. However, the deal break has been Eclipse. I need to run this app, but doing so is almost impossible. Every time it opens _any_ dialog (find, etc.) it locks hard for 10-20seconds at a time. Same thing happens when you dismiss the dialog. Of course, I can see no sign of CPU or network usage. WTH is going on?!? The app (Eclipse) works very well locally, why would it behave in such a fashion on the remove X? The delays are so big that I can't think it's doing anything, but rather that it's blocked somewhere waiting for a timeout of sorts. Any help figuring this out would be much appreciated. I think this is a rather nasty problem/regression, remote X used to work just fine in the past... -- Dimi Paun Lattica, Inc. From mjs at CLEMSON.EDU Mon Jan 7 22:58:27 2008 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Mon, 07 Jan 2008 17:58:27 -0500 Subject: Condor package? In-Reply-To: <4782A714.8060305@redhat.com> References: <1199740321.19180.47.camel@vincent52.localdomain> <1199741831.22969.16.camel@localhost.localdomain> <4782A714.8060305@redhat.com> Message-ID: <1199746707.28932.1.camel@vincent52.localdomain> On Mon, 2008-01-07 at 16:26 -0600, Matthew Farrellee wrote: > Tom "spot" Callaway wrote: > > On Mon, 2008-01-07 at 16:12 -0500, Matthew Saltzman wrote: > >> I understand that there is work going on at Red Hat to package the > >> Condor high-throughput computing environment > >> (http://www.cs.wisc.edu/condor/) for RH Linux--not sure if it's RHEL or > >> Fedora. Is anyone on this list working on that project? > >> > >> We're interested in following the progress of that effort, and we might > >> be able to help out, at least some. > > > > I'm very very peripherally related to that effort, and I think that it > > is currently RHEL focused. I'll ask them if they've got any plans to do > > anything in the Fedora space. > > > > ~spot > > > > I'm very very related to that effort, and I can tell you that it is > already an add-on to RHEL through Red Hat's MRG product. I also have > plans to (re)submit Condor to Fedora for inclusion. I'm simply waiting > for the next stable release of Condor. Cool! Thanks for the update. > > Best, > > > matt > > -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From wolfy at nobugconsulting.ro Mon Jan 7 23:00:48 2008 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Tue, 08 Jan 2008 01:00:48 +0200 Subject: Bruttaly sluggish Eclipse performance in remote X In-Reply-To: <1199746646.9735.10.camel@dimi.lattica.com> References: <1199746646.9735.10.camel@dimi.lattica.com> Message-ID: <4782AF20.1010505@nobugconsulting.ro> On 01/08/2008 12:57 AM, Dimi Paun wrote: > Folks, > > I am running Fedora 8 on 3 boxes, all connected via Gb Ethernet. > On two of the boxes (Intel Core 2 Quad @ 2.4GHz, 4 GB RAM) I've > enabled XDMCP and am logging in from the 3 via remote X. It has > been a rough experience: > * the default GDM screen does not have an option to invoke the > XDMCP chooser, despite the working in gdmsetup. This caused > great confusion until I figured that I needed to switch to > Happy Gnome login theme. > * performance is a bit sluggish, but bearable. However, I have > used in University (back in 97-98) old Sun boxes that were > doing the same over a much slower network, I was expecting > a lot more now, given all the hardware I've thrown at it. > > However, the deal break has been Eclipse. I need to run this app, > but doing so is almost impossible. Every time it opens _any_ > dialog (find, etc.) it locks hard for 10-20seconds at a time. > Same thing happens when you dismiss the dialog. Of course, I can > see no sign of CPU or network usage. > > WTH is going on?!? The app (Eclipse) works very well locally, why > would it behave in such a fashion on the remove X? The delays are > so big that I can't think it's doing anything, but rather that it's > blocked somewhere waiting for a timeout of sorts. > > Any help figuring this out would be much appreciated. I think this > is a rather nasty problem/regression, remote X used to work just > fine in the past... > > maybe something along "strace -f -e " would help ? From tibbs at math.uh.edu Mon Jan 7 23:03:10 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 07 Jan 2008 17:03:10 -0600 Subject: Review swaps In-Reply-To: <870180fe0801071430q6d01ccf1j252ae475ee3f68f3@mail.gmail.com> References: <870180fe0801071430q6d01ccf1j252ae475ee3f68f3@mail.gmail.com> Message-ID: >>>>> "JJ" == Jerry James writes: JJ> I'm interested in swapping reviews. I've currently got 3 packages JJ> awaiting review. One problem is that they all seem to be Java packages, and we still neither have Java packaging guidelines nor anyone willing sufficiently understanding of Java packaging to help write them. If you'd be willing to help, please let me know. I'm willing to help with packaging committee stuff (and I'll help review your packages) but I just don't understand Java well enough to write guidelines. - J< From pawsa-gpa at theochem.kth.se Mon Jan 7 23:09:47 2008 From: pawsa-gpa at theochem.kth.se (Pawel Salek) Date: Tue, 08 Jan 2008 00:09:47 +0100 Subject: Non-standard C-headers in glib2 (gtestutils.h) Message-ID: <1199747387l.6722l.1l@damage> Hi, I could not help noticing gtestutils.h from glib2-2.15.0-4 is not a standard C header file: it contains C++-style // comments. This breaks building my package (balsa). Should I work around this problem or a more up to date glib2 release is planned? I see the problem with the header has been fixed in glib2 on 2007-12-21. Pawel From Matt_Domsch at dell.com Mon Jan 7 23:14:15 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 7 Jan 2008 17:14:15 -0600 Subject: GPG Keysigning at FUDCon - INSTRUCTIONS In-Reply-To: <20080103031332.GA13994@auslistsprd01.us.dell.com> References: <20071212214010.GA20896@auslistsprd01.us.dell.com> <20080103024423.GL8896@inocybe.teonanacatl.org> <20080103031332.GA13994@auslistsprd01.us.dell.com> Message-ID: <20080107231415.GA7313@auslistsprd01.us.dell.com> On Wed, Jan 02, 2008 at 09:13:32PM -0600, Matt Domsch wrote: > On Wed, Jan 02, 2008 at 09:44:23PM -0500, Todd Zullinger wrote: > > If you haven't seen it before, I'd recommend giving a look at the > > "Efficient Group Key Signing Method" by Len Sassaman and Phil > > Zimmermann, documented at http://sion.quickie.net/keysigning.txt > > > > It cuts a lot of the tediousness out of a key signing involving more > > than just a few people. > > yep. That's basically my plan. So far only ~14 people have sent me > keys, so even bicycle chain won't take but a few minutes. I'll email > everyone who has sent keys, and fedora-devel, the instructions early > next week for getting the plaintext list of keys, the keyring I've > compiled from the sent fingerprints, the SHAx sums and the rest. I've compiled the list of keys for the FUDCon keysigning. These 20 are whom I have. If you're not on this list, and still want to participate, you may, details to follow. pub 1024D/92F0FC09 2001-04-16 Matt Domsch pub 1024D/BD113717 1997-09-19 Paul W. Frields pub 1024D/116521D9 2000-10-11 David Woodhouse (Insecure work key) pub 1024D/93054260 2001-03-22 Tom Callaway (spot) pub 1024D/1728D29B 2007-12-15 Lee Lorentz (WB0TRA) pub 1024D/CCAF484E 2007-04-17 Ricky Zhou pub 1024D/99B1F444 2006-04-02 G. Wolfe Woodbury pub 1024D/7BB612C9 2001-06-02 Kevin Sonney (The Alchemist) pub 1024D/8929CFFC 2006-12-05 Chris Tyler pub 1024D/ED00D312 2000-06-21 Douglas E. Warner pub 1536R/243A1329 1996-12-05 David Woodhouse pub 1024D/2E3F0935 2007-05-29 Yaakov Nemoy pub 1024D/87EF16E8 2007-02-27 Tyler Owen pub 1024D/7A47522D 2006-12-22 John Poelstra pub 1024D/78688BF5 2002-10-03 Nalin Dahyabhai pub 1024D/3B6A5B89 1999-09-16 Jack Neely pub 2048R/BEAF0CE3 2006-07-04 Todd M. Zullinger pub 1024D/D74908ED 2007-12-31 Eric Harlan Christensen pub 1024D/B05A59F7 2004-03-01 Dennis Gilmore pub 1024D/0D86AF59 2006-01-21 Jonathan Steffan (daMaestro) See the URL above for the process. Before the keysigning, you _must_ download a copy of http://domsch.com/linux/fedora/fudcon2008/fudcon-keysigning.txt and verify that your key is correct on there. You'll be asked at the keysigning to confirm that your key is correct in that file. Second, you must run both sha1sum and md5sum on the fudcon-keysigning.txt file, and validate that it in fact matches: http://domsch.com/linux/fedora/fudcon2008/fudcon-keysigning.txt.md5sum 0c799b9b70cf87e0039631e0cfd1586a fudcon-keysigning.txt http://domsch.com/linux/fedora/fudcon2008/fudcon-keysigning.txt.sha1sum d3fa0cda1d77cde8608c2506e88cb3cd60764c43 fudcon-keysigning.txt At the keysigning, I'll read these values. Everyone confirms they match, therefore we know your key as listed in the keyring is what everyone expects it to be. Then we each, in order, show our IDs for everyone to validate, and then each person can decide if they want to sign that person's key. After the keysigning, you can use a tool like caff from the pgp-tools package to sign each person's key and mail it to them. I'll see you all next Saturday! Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From jakub at redhat.com Mon Jan 7 23:17:48 2008 From: jakub at redhat.com (Jakub Jelinek) Date: Mon, 7 Jan 2008 18:17:48 -0500 Subject: Non-standard C-headers in glib2 (gtestutils.h) In-Reply-To: <1199747387l.6722l.1l@damage> References: <1199747387l.6722l.1l@damage> Message-ID: <20080107231748.GA15450@devserv.devel.redhat.com> On Tue, Jan 08, 2008 at 12:09:47AM +0100, Pawel Salek wrote: > I could not help noticing gtestutils.h from glib2-2.15.0-4 is not a > standard C header file: it contains C++-style // comments. This breaks > building my package (balsa). Should I work around this problem or a > more up to date glib2 release is planned? I see the problem with the > header has been fixed in glib2 on 2007-12-21. Just small correction, // comments are standard ISO C99, just not ISO C89 (and even there accepted as GNU extension in (the default) -std=gnu89 mode). Jakub From loganjerry at gmail.com Mon Jan 7 23:20:56 2008 From: loganjerry at gmail.com (Jerry James) Date: Mon, 7 Jan 2008 16:20:56 -0700 Subject: Review swaps In-Reply-To: References: <870180fe0801071430q6d01ccf1j252ae475ee3f68f3@mail.gmail.com> Message-ID: <870180fe0801071520r16ee79c6i2d86ea84fad086d5@mail.gmail.com> On 07 Jan 2008 17:03:10 -0600, Jason L Tibbitts III wrote: > One problem is that they all seem to be Java packages, and we still > neither have Java packaging guidelines nor anyone willing sufficiently > understanding of Java packaging to help write them. > > If you'd be willing to help, please let me know. I'm willing to help > with packaging committee stuff (and I'll help review your packages) > but I just don't understand Java well enough to write guidelines. I don't know that I'm sufficiently experienced with Java packaging to be helpful, but I've had a lot of experience with pedanticalness. Surely that qualifies me for writing guidelines! :-) Seriously, though, I'll be happy to give whatever help I can. I can start by reviewing both the Java-related material on the wiki and whatever guidelines I can find on jpackage.org. Has anybody compiled any kind of list of problems encountered with Java packages? -- Jerry James http://loganjerry.googlepages.com/ From mclasen at redhat.com Mon Jan 7 23:27:47 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 07 Jan 2008 18:27:47 -0500 Subject: Non-standard C-headers in glib2 (gtestutils.h) In-Reply-To: <1199747387l.6722l.1l@damage> References: <1199747387l.6722l.1l@damage> Message-ID: <1199748467.2866.1.camel@localhost.localdomain> On Tue, 2008-01-08 at 00:09 +0100, Pawel Salek wrote: > Hi, > > I could not help noticing gtestutils.h from glib2-2.15.0-4 is not a > standard C header file: it contains C++-style // comments. This breaks > building my package (balsa). Should I work around this problem or a > more up to date glib2 release is planned? I see the problem with the > header has been fixed in glib2 on 2007-12-21. No need to go all the way to C++, it is C99... As you notice, it has already been fixed, and 2.15.1 should appear in rawhide tomorrow (I am waiting for a new gvfs release to avoid breaking the desktop unnecessarily) From lordmorgul at gmail.com Mon Jan 7 23:27:29 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Mon, 07 Jan 2008 15:27:29 -0800 Subject: Init : someone could comment this ? In-Reply-To: <87ve65pqnl.fsf@fc5.bigo.ensc.de> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> Message-ID: <4782B561.2000302@gmail.com> Enrico Scholz wrote: >>>>> But python or other bloaty scripting languages are not a solution >>>>> and completely unacceptable at this place. >>>> "Bloaty" is something that could be solved, don't you think? >>> Not with python or perl. >> I've shown you the numbers. Why you still insist on it being bloated > > Resulting scripts will be much longer. E.g. how much lines of python > code are required for > > | sed '/^foo/s!/bin!/opt!' file | tac Looks like one line in python to me if you write a sed and tac replacement into your python library. (e.g. thats not about bash vs python at all...) -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From dimi at lattica.com Mon Jan 7 23:28:57 2008 From: dimi at lattica.com (Dimi Paun) Date: Mon, 7 Jan 2008 18:28:57 -0500 (EST) Subject: Bruttaly sluggish Eclipse performance in remote X In-Reply-To: <4782AF20.1010505@nobugconsulting.ro> References: <1199746646.9735.10.camel@dimi.lattica.com> <4782AF20.1010505@nobugconsulting.ro> Message-ID: <40742.99.229.154.251.1199748537.squirrel@lattica.com> On Mon, January 7, 2008 18:00, Manuel Wolfshant wrote: >> > maybe something along "strace -f -e " would help ? I think it has to do something with futexes: 4884 read(3, "\1\1\275\232\0\0\0\0\347\0\0\0\260\4\200\2\376\10\370\0\333\0\206\0\0\0\0\0h\224\376\277", 4096) = 32 4884 read(3, 0x8ce9840, 4096) = -1 EAGAIN (Resource temporarily unavailable) 4884 select(4, [3], [3], NULL, NULL) = 1 (out [3]) 4884 writev(3, [{"&\7\2\0\260\4\200\2", 8}], 1) = 8 4884 select(4, [3], [], NULL, NULL) = 1 (in [3]) 4884 read(3, "\1\1\276\232\0\0\0\0\347\0\0\0\261\4\200\2\376\10\370\0\333\0\206\0\0\0\0\0h\224\376\277", 4096) = 32 4884 read(3, 0x8ce9840, 4096) = -1 EAGAIN (Resource temporarily unavailable) 4884 select(4, [3], [3], NULL, NULL) = 1 (out [3]) 4884 writev(3, [{"&\7\2\0\261\4\200\2", 8}], 1) = 8 4884 select(4, [3], [], NULL, NULL) = 1 (in [3]) 4884 read(3, "\1\1\277\232\0\0\0\0\347\0\0\0\262\4\200\2\376\10\370\0\333\0\206\0\0\0\0\0h\224\376\277", 4096) = 32 4884 read(3, 0x8ce9840, 4096) = -1 EAGAIN (Resource temporarily unavailable) 4884 select(4, [3], [3], NULL, NULL) = 1 (out [3]) 4884 writev(3, [{"&\7\2\0\262\4\200\2", 8}], 1) = 8 4884 select(4, [3], [], NULL, NULL) = 1 (in [3]) 4884 read(3, "\1\1\300\232\0\0\0\0\347\0\0\0\263\4\200\2\376\10\370\0\333\0\206\0\0\0\0\0h\224\376\277", 4096) = 32 4884 read(3, 0x8ce9840, 4096) = -1 EAGAIN (Resource temporarily unavailable) 4884 select(4, [3], [3], NULL, NULL) = 1 (out [3]) 4884 writev(3, [{"&\7\2\0\263\4\200\2", 8}], 1) = 8 4884 select(4, [3], [], NULL, NULL) = 1 (in [3]) 4884 read(3, "\1\1\301\232\0\0\0\0\347\0\0\0\264\4\200\2\376\10\370\0\333\0\206\0\0\0\0\0h\224\376\277", 4096) = 32 4884 read(3, 0x8ce9840, 4096) = -1 EAGAIN (Resource temporarily unavailable) 4884 select(4, [3], [3], NULL, NULL) = 1 (out [3]) 4884 writev(3, [{"&\7\2\0\264\4\200\2", 8}], 1) = 8 4884 select(4, [3], [], NULL, NULL) = 1 (in [3]) 4884 read(3, "\1\1\302\232\0\0\0\0\347\0\0\0\265\4\200\2\376\10\370\0\306\0\206\0\0\0\0\0h\224\376\277", 4096) = 32 4884 read(3, 0x8ce9840, 4096) = -1 EAGAIN (Resource temporarily unavailable) 4884 select(4, [3], [3], NULL, NULL) = 1 (out [3]) 4884 writev(3, [{"&\7\2\0\265\4\200\2", 8}], 1) = 8 4884 select(4, [3], [], NULL, NULL) = 1 (in [3]) 4884 read(3, "\1\1\303\232\0\0\0\0\347\0\0\0\0\0\0\0\376\10\370\0\306\0\206\0\0\0\0\0h\224\376\277", 4096) = 32 4884 read(3, 0x8ce9840, 4096) = -1 EAGAIN (Resource temporarily unavailable) 4884 select(4, [3], [3], NULL, NULL) = 1 (out [3]) 4884 writev(3, [{"%\7\1\0", 4}], 1) = 4 4884 read(3, 0x8ce9840, 4096) = -1 EAGAIN (Resource temporarily unavailable) 4884 select(4, [3], [3], NULL, NULL) = 1 (out [3]) 4884 writev(3, [{"$\7\1\0&\7\2\0\347\0\0\0", 12}], 1) = 12 4884 select(4, [3], [], NULL, NULL 4891 <... futex resumed> ) = -1 ETIMEDOUT (Connection timed out) 4891 futex(0x8d76228, FUTEX_WAKE_PRIVATE, 1) = 0 4891 clock_gettime(CLOCK_MONOTONIC, {24863, 239467438}) = 0 4891 gettimeofday({1199748268, 870318}, NULL) = 0 4891 clock_gettime(CLOCK_MONOTONIC, {24863, 239529348}) = 0 4891 clock_gettime(CLOCK_MONOTONIC, {24863, 239554045}) = 0 4891 gettimeofday({1199748268, 870393}, NULL) = 0 4891 clock_gettime(CLOCK_REALTIME, {1199748268, 870418733}) = 0 4891 futex(0x8d76244, FUTEX_WAIT_PRIVATE, 1, {0, 49974267} -- Dimi Paun Lattica, Inc. From mike at miketc.com Tue Jan 8 00:03:39 2008 From: mike at miketc.com (Mike Chambers) Date: Mon, 07 Jan 2008 18:03:39 -0600 Subject: X in rawhide during install In-Reply-To: <1199721827.30771.583.camel@localhost.localdomain> References: <1199630953.2155.5.camel@scrappy.miketc.com> <1199721827.30771.583.camel@localhost.localdomain> Message-ID: <1199750619.2175.1.camel@scrappy.miketc.com> On Mon, 2008-01-07 at 11:03 -0500, Adam Jackson wrote: > I'm not sure how often the anaconda stage2 images are built, which is > where it gets the X drivers. I'm sure Jeremy's told me at some point > though. > > The vesa and radeonhd drivers should both be working with rawhide > though. If you go ahead with a text-mode install, you should get the > abortive X logs in the installed system under /var/log/anaconda, I > believe; it would be enlightening to see them. > Jeremy, any word on above, as to what date teh latest stage2 images were built, and/or what the latest xorg drivers were included? -- Mike Chambers Madisonville, KY "The best lil town on Earth!" From tibbs at math.uh.edu Tue Jan 8 00:24:53 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 07 Jan 2008 18:24:53 -0600 Subject: Another selinux rant In-Reply-To: <478281E4.5090803@redhat.com> References: <1199396217.3716.45.camel@localhost.localdomain> <1199434944.3244.7.camel@s1.crocom.com.pl> <477E67D9.1060808@redhat.com> <1199514823.6022.62.camel@beck.corsepiu.local> <478281E4.5090803@redhat.com> Message-ID: >>>>> "JD" == John Dennis writes: JD> This is why setroubleshoot was designed to operate in a JD> distributed network mode. At the time of setroubleshoot's initial JD> release it was felt this was a corner case, that the most likely JD> user of the tool would be developers and technically astute users JD> both running locally. The distributed aspects of the tool were JD> never promoted, although they continue to reside in the code. Well, I for one would be happy to run a local server so that I can keep an eye on selinux issues on the desktops here. I've been cautiously rolling selinux out on user desktops and try to run it on servers whenever I can (which is becoming much more often as I understand more about how it works) but the only way I know there are issues is if something explicitly breaks or by reading logwatch reports. Of course, my users should never see any kind of setroubleshoot applet; they have no idea what it would mean and they don't have privileges to make changes anyway. - J< From Matt_Domsch at dell.com Tue Jan 8 00:26:30 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 7 Jan 2008 18:26:30 -0600 Subject: GPG Keysigning at FUDCon - INSTRUCTIONS In-Reply-To: <20080107231415.GA7313@auslistsprd01.us.dell.com> References: <20071212214010.GA20896@auslistsprd01.us.dell.com> <20080103024423.GL8896@inocybe.teonanacatl.org> <20080103031332.GA13994@auslistsprd01.us.dell.com> <20080107231415.GA7313@auslistsprd01.us.dell.com> Message-ID: <20080108002630.GA15055@auslistsprd01.us.dell.com> On Mon, Jan 07, 2008 at 05:14:15PM -0600, Matt Domsch wrote: > On Wed, Jan 02, 2008 at 09:13:32PM -0600, Matt Domsch wrote: > > On Wed, Jan 02, 2008 at 09:44:23PM -0500, Todd Zullinger wrote: > > > If you haven't seen it before, I'd recommend giving a look at the > > > "Efficient Group Key Signing Method" by Len Sassaman and Phil > > > Zimmermann, documented at http://sion.quickie.net/keysigning.txt > > > > > > It cuts a lot of the tediousness out of a key signing involving more > > > than just a few people. > > > > yep. That's basically my plan. So far only ~14 people have sent me > > keys, so even bicycle chain won't take but a few minutes. I'll email > > everyone who has sent keys, and fedora-devel, the instructions early > > next week for getting the plaintext list of keys, the keyring I've > > compiled from the sent fingerprints, the SHAx sums and the rest. > > > I've compiled the list of keys for the FUDCon keysigning. These 20 > are whom I have. If you're not on this list, and still want to > participate, you may, details to follow. I meant to do the validations using the fingerprints, not just the --list-keys output. http://domsch.com/linux/fedora/fudcon2008/fudcon-keysigning-fingerprints.txt http://domsch.com/linux/fedora/fudcon2008/fudcon-keysigning-fingerprints.txt.md5sum http://domsch.com/linux/fedora/fudcon2008/fudcon-keysigning-fingerprints.txt.sha1sum http://domsch.com/linux/fedora/fudcon2008/fudcon-keysigning-fingerprints.txt.sign (signed by me) Please download the .txt file, and run md5sum and sha1sum against it and compare with the values posted there. They should match. Also be sure your key fingerprint is correct in that file. These, the keyring, etc. can be found at http://domsch.com/linux/fedora/fudcon2008/. Please download and validate them yourselves. Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From tibbs at math.uh.edu Tue Jan 8 00:32:45 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 07 Jan 2008 18:32:45 -0600 Subject: Obsoleting packages In-Reply-To: <4782787A.9030609@kobold.org> References: <4782787A.9030609@kobold.org> Message-ID: >>>>> "W" == Wart writes: W> Is it necessary to remove the tcl-tcldict rpm from the repository, W> or will it get removed automatically now that Tcl provides W> tcl-tcldict? It's not uncommon for several packages to provide the same thing, so nothing is done automatically in that instance. You should ask rel-eng to untag tcl-tcldict, and you should mark it as a dead.package in CVS as well if it's really gone from future Fedora releases. - J< From denis at poolshark.org Tue Jan 8 00:54:56 2008 From: denis at poolshark.org (Denis Leroy) Date: Tue, 08 Jan 2008 01:54:56 +0100 Subject: Fedora i386 rawhide rebuild in mock status 2008-01-05 In-Reply-To: <20080107224608.GA14141@humbolt.us.dell.com> References: <20080107224608.GA14141@humbolt.us.dell.com> Message-ID: <4782C9E0.8010508@poolshark.org> Matt Domsch wrote: > glibmm24-2.14.2-1.fc9 (build/make) denis I just built glibmm24 2.15.0 to keep par with glib2, so that should fix that. From jwboyer at gmail.com Tue Jan 8 01:44:56 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 7 Jan 2008 19:44:56 -0600 Subject: Fedora i386 rawhide rebuild in mock status 2008-01-05 In-Reply-To: <20080107224608.GA14141@humbolt.us.dell.com> References: <20080107224608.GA14141@humbolt.us.dell.com> Message-ID: <20080107194456.3687d647@hansolo.jdub.homelinux.org> On Mon, 7 Jan 2008 16:46:08 -0600 Matt Domsch wrote: > Fedora Rawhide-in-Mock Build Results for i386 > using the rawhide tree as of Saturday, January 5, 2008. > > This is a full rebuild of all packages. > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ > > Total packages: 5164 > Number failed to build: 491 > Number expected to fail due to ExclusiveArch or ExcludeArch: 13 > Leaving: 478 > (there may be some duplicates if rawhide has 2 versions of a package) > > Of those expected to have worked... > Without a bug filed: 478 > ctrlproxy-3.0.3-1.fc9 (build/make) jwboyer Died because of a weird glib header issue... will look into it. > gquilt-0.20-1.fc7 (build/make) jwboyer Build failed because it couldn't find python?? > powerpc-utils-papr-1.0.4-2.fc9 (build/make) dwmw2 This should be ExclusiveArch: ppc ppc64 josh From alexl at users.sourceforge.net Tue Jan 8 01:58:22 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Mon, 07 Jan 2008 18:58:22 -0700 Subject: Fedora i386 rawhide rebuild in mock status 2008-01-05 In-Reply-To: <20080107224608.GA14141@humbolt.us.dell.com> (Matt Domsch's message of "Mon\, 7 Jan 2008 16\:46\:08 -0600") References: <20080107224608.GA14141@humbolt.us.dell.com> Message-ID: >>>>> "MD" == Matt Domsch writes: MD> Of those expected to have worked... MD> Without a bug filed: 478 MD> ---------------------------------- R-Biobase-1.16.1-3.fc9 (build/make) pingou R-BufferedMatrix-1.2.0-1.fc9 (build/make) pingou R-abind-1.1-1.fc9 (build/make) spot R-acepack-1.3-2.fc9 (build/make) spot R-mAr-1.1-11.fc8 (build/make) jamatos R-tkWidgets-1.16.0-1.fc9 (build/make) pingou R-waveslim-1.6-4.fc8 (build/make) jamatos R-wavethresh-2.2-7.fc8 (build/make) jamatos R-widgetTools-1.15.0-1.fc9 (build/make) pingou All these except for R-waveslim (which is currently failing the test suite) should now be fixed either by me or pingou. From tcallawa at redhat.com Tue Jan 8 02:15:34 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 07 Jan 2008 21:15:34 -0500 Subject: Fedora i386 rawhide rebuild in mock status 2008-01-05 In-Reply-To: References: <20080107224608.GA14141@humbolt.us.dell.com> Message-ID: <1199758534.17013.1.camel@localhost.localdomain> On Mon, 2008-01-07 at 18:58 -0700, Alex Lancaster wrote: > All these except for R-waveslim (which is currently failing the test > suite) should now be fixed either by me or pingou. Just fixed R-waveslim. ~spot From stickster at gmail.com Tue Jan 8 02:41:57 2008 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 07 Jan 2008 21:41:57 -0500 Subject: GPG Keysigning at FUDCon - INSTRUCTIONS In-Reply-To: <20080107231415.GA7313@auslistsprd01.us.dell.com> References: <20071212214010.GA20896@auslistsprd01.us.dell.com> <20080103024423.GL8896@inocybe.teonanacatl.org> <20080103031332.GA13994@auslistsprd01.us.dell.com> <20080107231415.GA7313@auslistsprd01.us.dell.com> Message-ID: <1199760117.29973.3.camel@localhost.localdomain> On Mon, 2008-01-07 at 17:14 -0600, Matt Domsch wrote: > At the keysigning, I'll read these values. Everyone confirms they > match, therefore we know your key as listed in the keyring is what > everyone expects it to be. Then we each, in order, show our IDs for > everyone to validate, and then each person can decide if they want to > sign that person's key. > > After the keysigning, you can use a tool like caff from the pgp-tools > package to sign each person's key and mail it to them. If I may be so bold, last time we did this, a very small proportion of attendees actually sent around signed keys. Or did they just not want to sign mine? :-) If you've got a laptop and install pgp-tools on it, you can run through the signing routine at least once in the room so we can clear up any confusion that might prevent propagating the "web of trust." -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kevin.kofler at chello.at Tue Jan 8 02:47:16 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 8 Jan 2008 02:47:16 +0000 (UTC) Subject: Help with packaging tmispell-voikko (Ispell compatible Finnish spellchecking) References: <200712282248.21314.vpivaini@cs.helsinki.fi> <200801072023.25274.vpivaini@cs.helsinki.fi> Message-ID: Ville-Pekka Vainio cs.helsinki.fi> writes: > To get the ball rolling regarding tmispell-voikko, I have submitted a review > request here: . > > This Spec/SRPM doesn't try to do any ispell integration yet, hopefully I'll > get some help on that later. I attached a patch which adds support for tmispell to kdelibs3 (KSpell) to the bug report. KDE 4 and KSpell2 in kdelibs3 (with my FeatureDictionary patch) don't need any patching nor ispell hackery as they use enchant. Most GNOME stuff these days also uses enchant, partly thanks to the FeatureDictionary work. Any app which tries to call ispell, hunspell, aspell or whatever directly will need some patching though if we use that approach. Oh, in case somebody asks why Finnish isn't using hunspell (which is what we're trying to standardize on in Fedora): I don't believe there is any working Finnish dictionary for hunspell. The one on the OO.o dictionary page is a dummy empty dictionary. And given that Finnish has complex agglutinative grammar, a simple word list definitely won't cut it. So I trust the folks who actually speak Finnish to know what they're doing in this context. ;-) Kevin Kofler From tibbs at math.uh.edu Tue Jan 8 02:49:57 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 07 Jan 2008 20:49:57 -0600 Subject: GPG Keysigning at FUDCon - INSTRUCTIONS In-Reply-To: <1199760117.29973.3.camel@localhost.localdomain> References: <20071212214010.GA20896@auslistsprd01.us.dell.com> <20080103024423.GL8896@inocybe.teonanacatl.org> <20080103031332.GA13994@auslistsprd01.us.dell.com> <20080107231415.GA7313@auslistsprd01.us.dell.com> <1199760117.29973.3.camel@localhost.localdomain> Message-ID: >>>>> "PWF" == Paul W Frields writes: PWF> If I may be so bold, last time we did this, a very small PWF> proportion of attendees actually sent around signed keys. Yeah, I found that I got back home, got busy putting out fires and such (plus my wife decided that we should buy a new car on the way home from the airport) and I ended up forgetting what I was supposed to do to do all of the signing. I haven't sent my key info in this time out of embarrassment. - J< From debarshi.ray at gmail.com Tue Jan 8 03:25:04 2008 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Tue, 8 Jan 2008 08:55:04 +0530 Subject: Fedora x86_64 rawhide rebuild in mock status 2008-01-05 In-Reply-To: <20080107224330.GA14071@humbolt.us.dell.com> References: <20080107224330.GA14071@humbolt.us.dell.com> Message-ID: <3170f42f0801071925t6d57e3e0p1a729c1db51273f6@mail.gmail.com> > Fedora Rawhide-in-Mock Build Results for x86_64 > using the rawhide tree as of Saturday, January 5, 2008. > > [...] > anjuta-gdl-0.7.3-2.fc9 (build/make) rishi I inherited anjuta-gdl from Paul F. Johnson few weeks back. Since then I have updated it to a new upstream version; renamed it to libgdl (discussed on fedora-devel-list: https://www.redhat.com/archives/fedora-devel-list/2007-December/msg00830.html); and submitted for review: https://bugzilla.redhat.com/show_bug.cgi?id=426599 A few other packages, like anjuta, depend on this. Cheers, Debarshi From tmz at pobox.com Tue Jan 8 03:30:53 2008 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 7 Jan 2008 22:30:53 -0500 Subject: GPG Keysigning at FUDCon - INSTRUCTIONS In-Reply-To: <20080108002630.GA15055@auslistsprd01.us.dell.com> References: <20071212214010.GA20896@auslistsprd01.us.dell.com> <20080103024423.GL8896@inocybe.teonanacatl.org> <20080103031332.GA13994@auslistsprd01.us.dell.com> <20080107231415.GA7313@auslistsprd01.us.dell.com> Message-ID: <20080108033053.GQ3136@inocybe.teonanacatl.org> Matt Domsch wrote: > After the keysigning, you can use a tool like caff from the > pgp-tools package to sign each person's key and mail it to them. I'd like to put in a plug for not using caff (read: I'm a pedant ;). There are three things you want to verify when you certify (sign) a key: 1) The identity of the person asking me to certify their key. 2) The key's fingerprint, id, size, and type 3) The email address(es) associated with the key 1 can be accomplished via a drivers license or other form of ID. 2 is achieved by checking that the key info presented at the signing matches what is available on the public keyservers 3 is the trickier one. When you sign a key, you are signing the primary key + the user id(s). Most newer PGP keys consist of a primary key and one or more encryption subkeys. Using caff as I understand it, you would sign each uid on a key and then encrypt it to the address on the uid. This encryption is intended to verify that the key actually belongs to the recipient and that they can receive email add the address on the key. This is not entirely adequate for a few reasons. Firstly, it doesn't really verify that the uid you are signing belongs to the person at the address (see below). Secondly, it fails completely for anyone that doesn't have an encryption subkey. (Some people have a master key that they use for signing and for acquiring signatures on and another key that they use for day to day use and receiving encrypted mail. Not common perhaps, but a perfectly valid usage of gpg, and no reason to deny someone a signature on their key.) What you really want to do is ask the key owner to sign some text or data of your choosing and send it to you. That ensures that the thing you are signing (the primary key + uid) is under the control of the key owner and that they can receive mail at the address in the uid. I prodded the folks on gnupg-users about this a year or so ago. You can read the full thread starting at[1] and David Shaw's assertion that "sending an signed key via encrypted mail does not ensure anything about the key owner." at[2]. Ingo Kloecker was kind enough to post a short perl script in that thread that he used to send out challenge mail after a keysigning. I modified it a bit and used it after the last keysigning at my local LUG (all the bugs are surely mine). In the off chance that anyone is interested, I've posted that script at[3]. It requires the perl modules Text::Autoformat and Text::Template (among other standard modules). [1] http://marc.info/?l=gnupg-users&m=115221259531231&w=2 [2] http://marc.info/?l=gnupg-users&m=115230714808866&w=2 [3] http://tmz.fedorapeople.org/scripts/gpg-send-challenges -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Eat drink and be merry, for tomorrow they may make it illegal. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From kevin.kofler at chello.at Tue Jan 8 03:33:26 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 8 Jan 2008 03:33:26 +0000 (UTC) Subject: Init : someone could comment this ? References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <1199726855.20392.1.camel@gibraltar.str.redhat.com> <87prwd8p92.fsf@kosh.bigo.ensc.de> Message-ID: Enrico Scholz informatik.tu-chemnitz.de> writes: > Does it look so uncommon? 'sed' is used very often, pipes too. 'tac' > can be there too, e.g. with a trailing 'sed "1p;d"' Yet, elsewhere in this same thread, you wrote: > For what do you need 'sed' or pipes to start/stop a daemon? So you're contradicting yourself. Kevin Kofler From tmz at pobox.com Tue Jan 8 03:34:24 2008 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 7 Jan 2008 22:34:24 -0500 Subject: GPG Keysigning at FUDCon - INSTRUCTIONS In-Reply-To: References: <20071212214010.GA20896@auslistsprd01.us.dell.com> <20080103024423.GL8896@inocybe.teonanacatl.org> <20080103031332.GA13994@auslistsprd01.us.dell.com> <20080107231415.GA7313@auslistsprd01.us.dell.com> <1199760117.29973.3.camel@localhost.localdomain> Message-ID: <20080108033424.GR3136@inocybe.teonanacatl.org> Jason L Tibbitts III wrote: > Yeah, I found that I got back home, got busy putting out fires and > such (plus my wife decided that we should buy a new car on the way > home from the airport) and I ended up forgetting what I was supposed > to do to do all of the signing. > > I haven't sent my key info in this time out of embarrassment. I'd hazard a guess that most everyone can understand getting busy and sidetracked and that anyone who attended the last keysigning won't hold it against you. :) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Disobedience: The silver lining to the cloud of servitude. -- Ambrose Bierce -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From dennis at ausil.us Tue Jan 8 03:38:22 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 7 Jan 2008 21:38:22 -0600 Subject: GPG Keysigning at FUDCon - INSTRUCTIONS In-Reply-To: References: <20071212214010.GA20896@auslistsprd01.us.dell.com> <1199760117.29973.3.camel@localhost.localdomain> Message-ID: <200801072138.27711.dennis@ausil.us> On Monday 07 January 2008, Jason L Tibbitts III wrote: > >>>>> "PWF" == Paul W Frields writes: > > PWF> If I may be so bold, last time we did this, a very small > PWF> proportion of attendees actually sent around signed keys. > > Yeah, I found that I got back home, got busy putting out fires and > such (plus my wife decided that we should buy a new car on the way > home from the airport) and I ended up forgetting what I was supposed > to do to do all of the signing. > > I haven't sent my key info in this time out of embarrassment. > > - J< I missed the gpg session last time sine i had to do the EPEL presentation. however it would be good to get some of it done while there. perhaps we could have the session at a time by itself. at the beginning or end of the day. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From jonstanley at gmail.com Tue Jan 8 04:03:37 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Mon, 7 Jan 2008 23:03:37 -0500 Subject: Fwd: closing out old bugs of unmaintained releases In-Reply-To: <20080104140746.62518306@ghistelwchlohm.scrye.com> References: <20080104140746.62518306@ghistelwchlohm.scrye.com> Message-ID: On Jan 4, 2008 4:07 PM, Kevin Fenzi wrote: > See: http://www.jwz.org/doc/cadt.html See http://jwz.livejournal.com/154529.html where the original author comments: "There may not be an immediate practical difference to the user, but the attitude behind it matters: maybe the developer thinks it's ok to just ignore old bugs: that's often true, and that's really bad. But then, maybe the developer doesn't think that, but instead, the project is just totally floundering: that's also often true, and easier to forgive. In the latter case, at least they'll be trying to fix the problem; in the former case, they don't think there is a problem." We are obviously in the latter situation here. We *are* attempting to fix this (at least I know that I am). From tmz at pobox.com Tue Jan 8 04:03:38 2008 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 7 Jan 2008 23:03:38 -0500 Subject: GPG Keysigning at FUDCon - INSTRUCTIONS In-Reply-To: <1199760117.29973.3.camel@localhost.localdomain> References: <20071212214010.GA20896@auslistsprd01.us.dell.com> <20080103024423.GL8896@inocybe.teonanacatl.org> <20080103031332.GA13994@auslistsprd01.us.dell.com> <20080107231415.GA7313@auslistsprd01.us.dell.com> <1199760117.29973.3.camel@localhost.localdomain> Message-ID: <20080108040338.GS3136@inocybe.teonanacatl.org> Paul W. Frields wrote: > If I may be so bold, last time we did this, a very small proportion > of attendees actually sent around signed keys. Or did they just not > want to sign mine? :-) I've had that experience myself. I made a note to shower before the next keysigning. > If you've got a laptop and install pgp-tools on it, you can run > through the signing routine at least once in the room so we can > clear up any confusion that might prevent propagating the "web of > trust." Speaking of the web, here's a graph of the keys submitted so far and how they are related. The graph was made using the sig2dot script[1] and neato (from graphviz). Keys are colored: * Red proportional to sigs received (in arrows) * Green proportional to the ratio of sigs given to sigs received * Blue proportional to sigs given (out arrows) [1] http://ftp.de.debian.org/debian/pool/main/s/sig2dot/sig2dot_0.37.tar.gz -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It's not denial. I'm just very selective about what I accept as reality. -- Calvin ("Calvin and Hobbes") -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From tmz at pobox.com Tue Jan 8 04:06:07 2008 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 7 Jan 2008 23:06:07 -0500 Subject: GPG Keysigning at FUDCon - INSTRUCTIONS In-Reply-To: <20080108040338.GS3136@inocybe.teonanacatl.org> References: <20071212214010.GA20896@auslistsprd01.us.dell.com> <20080103024423.GL8896@inocybe.teonanacatl.org> <20080103031332.GA13994@auslistsprd01.us.dell.com> <20080107231415.GA7313@auslistsprd01.us.dell.com> <1199760117.29973.3.camel@localhost.localdomain> <20080108040338.GS3136@inocybe.teonanacatl.org> Message-ID: <20080108040607.GT3136@inocybe.teonanacatl.org> I wrote: > Speaking of the web, here's a graph of the keys submitted so far and > how they are related. I suppose the actual graph would be handy to have too. :) http://tmz.fedorapeople.org/fudcon9-keysigning/fudcon-graph.png -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ You will rue this day! Well, go on! Start ruing! -- Stewie Griffin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From jd at commandprompt.com Tue Jan 8 04:11:35 2008 From: jd at commandprompt.com (Joshua D. Drake) Date: Mon, 07 Jan 2008 20:11:35 -0800 Subject: PostgreSQL Conference East: Call for papers Message-ID: <4782F7F7.2010105@commandprompt.com> Hello, I know it is not strictly Fedora related, but if any of you folks are PostgreSQL freaks, I know the conference would appreciate your involvement. -- begin standard email -- PostgreSQL Conference East is being held on the weekend of March 29th and 30th, 2008 in College Park, Maryland. The conference will have a series of talks, mini-tutorials and tutorials and we are now accepting submissions! If you are a third pary vendor, PostgreSQL developer, PostgreSQL consultant, DBA, or just a user who really does cool stuff, you need to submit a talk, or tutorial. Do you know how to get that last 20 transactions per second out of an array using adaptive readahead? Maybe you know more about Autovacuum than you ever care to admit? Perhaps you recently deployed a large scale Grails app with PostgreSQL... Now is your time to share, learn and participate in the community! Submit your talk at: http://www.postgresqlconference.org/talk_submission/ . PostgreSQL Conference East is part of the PostgreSQL Community Conference series. All proceeds from the conferences are donations to PostgreSQL via the non-profit Software in the Public Interest a U.S. 501c3. Sincerely, Joshua D. Drake From nayankumarp at hotmail.com Tue Jan 8 05:33:52 2008 From: nayankumarp at hotmail.com (nayan kumar) Date: Tue, 8 Jan 2008 11:03:52 +0530 Subject: How to remove this warning Message-ID: Hi All, I am trying to make stack for my learning in which i made a bus driver and device driver when i am trying to create device sysfs file after registering it with the bus i am getting oops after some digging i found that the compiler is reporting warning for using preprocessor macro called DEV_ATT. code is as follows. can anybody help me to remove this warning. static ssize_t show_host_device_version(struct device *ddev, char *buf){ struct HOST *dev = ddev->driver_data; return print_dev_t(buf, dev->cdev.dev);}static DEVICE_ATTR(host_device_version,S_IRUGO,show_host_device_version,NULL); device_create_file(&dev->host.dev, &dev_attr_host_device_version); Regards _________________________________________________________________ Post ads for free - to sell, rent or even buy.www.yello.in http://ss1.richmedia.in/recurl.asp?pid=186 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tibbs at math.uh.edu Tue Jan 8 05:38:09 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 07 Jan 2008 23:38:09 -0600 Subject: GPG Keysigning at FUDCon - INSTRUCTIONS In-Reply-To: <20080107231415.GA7313@auslistsprd01.us.dell.com> References: <20071212214010.GA20896@auslistsprd01.us.dell.com> <20080103024423.GL8896@inocybe.teonanacatl.org> <20080103031332.GA13994@auslistsprd01.us.dell.com> <20080107231415.GA7313@auslistsprd01.us.dell.com> Message-ID: >>>>> "MD" == Matt Domsch writes: MD> If you're not on this list, and still want to participate, you MD> may, details to follow. Unfortunately I don't see those directions following. Did I miss the boat? I guess I can still print a bunch of copies of my key if so. - J< From jonstanley at gmail.com Tue Jan 8 05:42:28 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Tue, 8 Jan 2008 00:42:28 -0500 Subject: GPG Keysigning at FUDCon - INSTRUCTIONS In-Reply-To: References: <20071212214010.GA20896@auslistsprd01.us.dell.com> <20080103024423.GL8896@inocybe.teonanacatl.org> <20080103031332.GA13994@auslistsprd01.us.dell.com> <20080107231415.GA7313@auslistsprd01.us.dell.com> Message-ID: On 07 Jan 2008 23:38:09 -0600, Jason L Tibbitts III wrote: > Unfortunately I don't see those directions following. Did I miss the > boat? I guess I can still print a bunch of copies of my key if so. They're on the wiki now, and pretty much exactly that :) From james.antill at redhat.com Tue Jan 8 06:50:59 2008 From: james.antill at redhat.com (James Antill) Date: Tue, 08 Jan 2008 01:50:59 -0500 Subject: Init : someone could comment this ? In-Reply-To: <1199702578.5761.36.camel@wombat.tiptoe.de> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> Message-ID: <1199775059.18076.34.camel@code.and.org> I've been trying to stay out of this flamewa^W thread, but... On Mon, 2008-01-07 at 11:42 +0100, Nils Philippsen wrote: > On Mon, 2008-01-07 at 10:44 +0100, Enrico Scholz wrote: > > But python or other bloaty scripting languages are not a solution and > > completely unacceptable at this place. > > "Bloaty" is something that could be solved, don't you think? If python > was split up in a base package that contained the directory structure, > the binaries, the (small) documentation and only basic modules (with no > additional requirements) and a package containing the rest of the > modules, much of the (dep-)bloat wouldn't be an issue if init scripts > (ehh modules) would be limited to that basic set. With the set of > modules I would choose, such a python-base package would have less > dependencies than bash and only account for roughly 2.6MB on the disk as > well -- bash takes up about 5.1MB. From a Fed-9 python build: % rpm --qf '%{name} %{size}\n' -q python python-libs python-docs \ python-test python-devel python-tools python 17070643 python-libs 1505949 python-docs 17804516 python-test 11902909 python-devel 3124644 python-tools 2793600 ...all of which come from the python tarball, and only the top two of which you actually need to run scripts[1]. I looked at getting python itself down a bit more, but it would be a lot of work getting the deps. correct for "python-minimal" (or whatever) and even worse is that a lot of things that you'd think of as "non-core" are required by core applications like yum or setroubleshoot. [1] tkinter removed to protect any innocents who may be reading this :). -- James Antill -- "Please, no. Let's not pull in a dependency for something as simple as a string library." -- Kristian H?gsberg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From enrico.scholz at informatik.tu-chemnitz.de Tue Jan 8 07:37:00 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 08 Jan 2008 08:37:00 +0100 Subject: Init : someone could comment this ? In-Reply-To: (Kevin Kofler's message of "Tue, 8 Jan 2008 03:33:26 +0000 (UTC)") References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <1199726855.20392.1.camel@gibraltar.str.redhat.com> <87prwd8p92.fsf@kosh.bigo.ensc.de> Message-ID: <87lk7093ab.fsf@kosh.bigo.ensc.de> Kevin Kofler writes: >> Does it look so uncommon? 'sed' is used very often, pipes too. 'tac' >> can be there too, e.g. with a trailing 'sed "1p;d"' > > Yet, elsewhere in this same thread, you wrote: >> For what do you need 'sed' or pipes to start/stop a daemon? > > So you're contradicting yourself. no; latter was about starting/stopping a daemon. First one was done in a discussion about preparation scripts (which are usually not needed). Enrico From debarshi.ray at gmail.com Tue Jan 8 09:08:07 2008 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Tue, 8 Jan 2008 14:38:07 +0530 Subject: How to remove this warning In-Reply-To: References: Message-ID: <3170f42f0801080108s2fc3a9dbjee3d486d999a180f@mail.gmail.com> > I am trying to make stack for my learning in which i made a bus Sorry, but this is not relevant to this list: http://fedoraproject.org/wiki/PostIsOffTopic Cheers, Debarshi From j.w.r.degoede at hhs.nl Tue Jan 8 09:28:31 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 08 Jan 2008 10:28:31 +0100 Subject: tcl 8.5, stackchecking and 8Kingdoms Message-ID: <4783423F.9090002@hhs.nl> Hi All, It turns out that I misread the stackchecking code (oops, brown paper bag time), and that it is not at fault. The problem is that Tcl has a thread model where one can have multiple interpreters per thread, but may not call an interpreter from another thread then the one it was created in, and this is just what 8Kingdoms was doing. I'm working on a fix. In the mean time please turn stackchecking in the TCL packages back on, it was not at fault and acutally caught an error. 8Kingdoms working without it was more luck then anything else. Thanks & Regards, Hans From ivazqueznet at gmail.com Tue Jan 8 09:43:08 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Tue, 08 Jan 2008 04:43:08 -0500 Subject: tcl 8.5, stackchecking and 8Kingdoms In-Reply-To: <4783423F.9090002@hhs.nl> References: <4783423F.9090002@hhs.nl> Message-ID: <1199785388.5098.0.camel@ignacio.lan> On Tue, 2008-01-08 at 10:28 +0100, Hans de Goede wrote: > 8Kingdoms working without it was more luck then anything else. I'd say it was more a failure on the part of the TCL devs to do proper checking, but water under the bridge. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Tue Jan 8 06:29:11 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 08 Jan 2008 07:29:11 +0100 Subject: Init : someone could comment this ? In-Reply-To: <20080107192727.GF19651@nostromo.devel.redhat.com> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> <20080107120349.GA15518@devserv.devel.redhat.com> <20080107192727.GF19651@nostromo.devel.redhat.com> Message-ID: <1199773751.2831.5.camel@beck.corsepiu.local> On Mon, 2008-01-07 at 14:27 -0500, Bill Nottingham wrote: > Alan Cox (alan at redhat.com) said: > > Fork should be pretty cheap - although that depends how much memory is unshared > > by each of the resulting tasks. A smaller cleaner shell such as rc (which was > > designed for this job in plan 9) or ash might well perform better. I'm dubious > > it would be a big difference but someone can bench it. > > ash has been benchmarked. Required rooting out some bashisms from the scripts > (or just calling those specific scripts with bash), Right - Doing so (== bug fixing) is way over due. > but in any case, it didn't > make much difference. Well, depends on how things are being implemented. Some OSes wanted to avoid "bash's bloat" by using ash as /bin/sh - Had shown not to be a clever idea. Ralf From nphilipp at redhat.com Tue Jan 8 10:21:05 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 08 Jan 2008 11:21:05 +0100 Subject: Init : someone could comment this ? In-Reply-To: <87prwd8p92.fsf@kosh.bigo.ensc.de> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <1199726855.20392.1.camel@gibraltar.str.redhat.com> <87prwd8p92.fsf@kosh.bigo.ensc.de> Message-ID: <1199787665.29101.53.camel@gibraltar.str.redhat.com> On Mon, 2008-01-07 at 19:27 +0100, Enrico Scholz wrote: > Nils Philippsen writes: [...] > sorry, but a design like > > parent > |-- child0 > `- child1 > > where signals must be sent to child0 to control parent + child1 smells > somehow broken. I was more thinking along the lines of: 1. process 1 (p1) prepares the service 2. when finished, p1 forks p2 which will be the long-runner, controlling any eventual children 3. p1 exits This seems to be a standard procedure for self-detaching daemons to me. The caller can't know or even reliably guess the pid of p2. > >> > To make the init process robust, services should check their > >> > prerequisites before starting, or even ensure that they are met > >> > (e.g. /etc/init.d/sshd generating host keys). > >> > >> Question is where to draw the line. E.g. do you make 'rpm -V postgresql' > >> to verify that program is not corrupted? > > > > You know what I mean > > no You're intentionally ignoring what I mean. I could throw around terms like "common sense", but there's a lot of dissent about what that means ;-). > >> Resulting scripts will be much longer. E.g. how much lines of python > >> code are required for > >> > >> | sed '/^foo/s!/bin!/opt!' file | tac > > > > Where would you find such a line in an init script? > > Does it look so uncommon? 'sed' is used very often, pipes too. 'tac' > can be there too, e.g. with a trailing 'sed "1p;d"' I can think of easier ways to extract the last line (if I'm reading your sed correctly ;-). > >> What are you missing specifically? > > > > Powerful string ops come to mind, > > which string ops other than ${..##..} + ${..%%..} do you need in > initscripts? I've often had to chain multiple of these to get the desired results -- but that's more a matter of convenience (perhaps my bash is just too rusty and it can be done more elegantly). What matters more to me (this came to mind only yesterday while driving home) is that if you do: cat $somefile | while read line; do ... done variables set in the while loop have no effect outside of it, or if you want them to have effect, you have to do nasty things (or my bash is rusty again ;-). > > built-in regular expressions or > > where do you need regexps in initscripts? To (more) easily extract certain part of strings for example, instead of using multiple removal of heading and trailing characters. To find out whether a line matches a certain pattern, think of your "sed '/^foo/...'" construct above. > > exceptions > > set -e Throwing exceptions is one thing, but you should be able to catch them, too. E.g.: try: # some_complicated_task ... # problem raise SomeException ("Something's fishy, Dave") ... # more serious problem raise SomeSeriousError ("Something's screwed, Dave") ... except OSError, e: # clean up OS error if e.errno == ...: ... ... except SomeException, e: # do something else sys.stderr.print "Warning: doing foo failed, continuing (%s)" % str (e) except: # panic! sys.stderr.print "Error: %s" % str(e) sys.exit (42) I don't know if any of this is necessary for init code, but these are some things that I miss or find cumbersome in shell. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From nphilipp at redhat.com Tue Jan 8 10:26:10 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 08 Jan 2008 11:26:10 +0100 Subject: Init : someone could comment this ? In-Reply-To: <47826644.9030500@gmail.com> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <1199726855.20392.1.camel@gibraltar.str.redhat.com> <47826644.9030500@gmail.com> Message-ID: <1199787970.29101.58.camel@gibraltar.str.redhat.com> On Mon, 2008-01-07 at 11:49 -0600, Les Mikesell wrote: > Nils Philippsen wrote: > > >> I think, when somebody wants to run a server, he has to understand how > >> it works and how to configure it. When admin can not figure out correct > >> cmdline options, how can he configure the server in a secure manner? > > > > Along that line, everybody should be able to run configure && make && > > make install and wrap their own packages, so why should we bother ;-)? > > Seriously, I can cope with command line arguments and still like > > sysconfig files that are more understandable than just plain > > "OPTS='--foo -x=y -a'". I'm happy if I get things done without having to > > read the documentation for the common case. I'm not saying admins > > shouldn't be able to influence the cmd line options directly if they > > wish. > > If you change that to some abstraction that you think is easier to > understand, how do you propose (a) that sysadmins that already knew the > real options should deal with the now confusing abstraction E.g. like with the old /etc/sysconfig/hdparm, you could use "speaking options" but have an "HDPARM_OPTS" variable (or some name like that) which would just passed on the command line. > and (b) that > the abstraction (and its documentation) always stays in sync with > upstream changes/additions to the underlying program's options? It is > already fairly messy trying to track what options have been moved to new > locations under /etc/sysconfig in fedora/RH boxes and which are still in > their normal locations. That's the job of the maintainer of the concerned package: to ensure that sysconfig options he introduced get mapped to the correct set of command line arguments. If those change, the mapping has to change. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From aph at redhat.com Tue Jan 8 10:32:25 2008 From: aph at redhat.com (Andrew Haley) Date: Tue, 8 Jan 2008 10:32:25 +0000 Subject: Bruttaly sluggish Eclipse performance in remote X In-Reply-To: <1199746646.9735.10.camel@dimi.lattica.com> References: <1199746646.9735.10.camel@dimi.lattica.com> Message-ID: <18307.20793.534261.12649@zebedee.pink> Dimi Paun writes: > Folks, > > I am running Fedora 8 on 3 boxes, all connected via Gb Ethernet. > On two of the boxes (Intel Core 2 Quad @ 2.4GHz, 4 GB RAM) I've > enabled XDMCP and am logging in from the 3 via remote X. It has > been a rough experience: > * the default GDM screen does not have an option to invoke the > XDMCP chooser, despite the working in gdmsetup. This caused > great confusion until I figured that I needed to switch to > Happy Gnome login theme. > * performance is a bit sluggish, but bearable. However, I have > used in University (back in 97-98) old Sun boxes that were > doing the same over a much slower network, I was expecting > a lot more now, given all the hardware I've thrown at it. > > However, the deal break has been Eclipse. I need to run this app, > but doing so is almost impossible. Every time it opens _any_ > dialog (find, etc.) it locks hard for 10-20seconds at a time. > Same thing happens when you dismiss the dialog. Of course, I can > see no sign of CPU or network usage. > > WTH is going on?!? The app (Eclipse) works very well locally, why > would it behave in such a fashion on the remove X? The delays are > so big that I can't think it's doing anything, but rather that it's > blocked somewhere waiting for a timeout of sorts. If you ssh to the target machine and then run Eclipse, does that work better? Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From mmaslano at redhat.com Tue Jan 8 11:59:02 2008 From: mmaslano at redhat.com (Marcela Maslanova) Date: Tue, 08 Jan 2008 12:59:02 +0100 Subject: tcl 8.5, stackchecking and 8Kingdoms In-Reply-To: <1199785388.5098.0.camel@ignacio.lan> References: <4783423F.9090002@hhs.nl> <1199785388.5098.0.camel@ignacio.lan> Message-ID: <47836586.3060109@redhat.com> Ok, I rebuilt it with stack checking. Ignacio Vazquez-Abrams wrote: > On Tue, 2008-01-08 at 10:28 +0100, Hans de Goede wrote: > >> 8Kingdoms working without it was more luck then anything else. >> > > I'd say it was more a failure on the part of the TCL devs to do proper > checking, but water under the bridge. > > From enrico.scholz at informatik.tu-chemnitz.de Tue Jan 8 12:10:27 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 08 Jan 2008 13:10:27 +0100 Subject: Init : someone could comment this ? In-Reply-To: <1199787665.29101.53.camel@gibraltar.str.redhat.com> (Nils Philippsen's message of "Tue, 08 Jan 2008 11:21:05 +0100") References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <1199726855.20392.1.camel@gibraltar.str.redhat.com> <87prwd8p92.fsf@kosh.bigo.ensc.de> <1199787665.29101.53.camel@gibraltar.str.redhat.com> Message-ID: <87sl18frgs.fsf@fc5.bigo.ensc.de> Nils Philippsen writes: > 1. process 1 (p1) prepares the service > 2. when finished, p1 forks p2 which will be the long-runner, controlling > any eventual children > 3. p1 exits > > This seems to be a standard procedure for self-detaching daemons to > me. That's the old forking-daemon way. Most modern initsystems work best with non-forking daemons. > I've often had to chain multiple of these to get the desired results -- > but that's more a matter of convenience (perhaps my bash is just too > rusty and it can be done more elegantly). What matters more to me (this > came to mind only yesterday while driving home) is that if you do: > > cat $somefile | while read line; do ... done > > variables set in the while loop have no effect outside of it, or if you this effect is known and this example can be written as | while read line ... done < $somefile But we are speaking about preparation scripts of daemons. Do you really need such tasks there? > except OSError, e: > # clean up OS error > ... > except SomeException, e: > # do something else > sys.stderr.print "Warning: doing foo failed, continuing (%s)" % str (e) > except: > # panic! > sys.stderr.print "Error: %s" % str(e) > sys.exit (42) > > I don't know if any of this is necessary for init code, but these are > some things that I miss or find cumbersome in shell. I do not say that shell shall be used for everything. I just say that python is not an option for any part of sysinit which should be written completely in C. (ba)sh plus usual POSIX/GNU tools are the optimal choice for preparation tasks, but these are no deps of the sysinit system itself but of the specific daemon. Enrico From dwalsh at redhat.com Tue Jan 8 12:12:37 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 08 Jan 2008 07:12:37 -0500 Subject: Another selinux rant In-Reply-To: References: Message-ID: <478368B5.4030109@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ed Swierk wrote: > On 1/4/08, Matej Cepl wrote: >> When introducing SELinux on computer where it wasn't before, it >> is mandatory to >> >> touch /.autorelabel >> reboot > > ...and when copying files from another machine not running SELinux, > and when copying files from a machine running SELinux without using > funny tar/cp options. > > --Ed > restorecon on the files is a better solution. restorecon -R -v /etc for example. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkeDaLUACgkQrlYvE4MpobPXSACdGFqSw4JygcXU3utwR/At9SUB wLgAoM7GV+8bfvrcZbbnjTxf8St+gBlC =EnwM -----END PGP SIGNATURE----- From dimi at lattica.com Tue Jan 8 13:04:42 2008 From: dimi at lattica.com (Dimi Paun) Date: Tue, 08 Jan 2008 08:04:42 -0500 Subject: Bruttaly sluggish Eclipse performance in remote X In-Reply-To: <18307.20793.534261.12649@zebedee.pink> References: <1199746646.9735.10.camel@dimi.lattica.com> <18307.20793.534261.12649@zebedee.pink> Message-ID: <1199797482.4617.8.camel@dimi.lattica.com> On Tue, 2008-01-08 at 10:32 +0000, Andrew Haley wrote: > If you ssh to the target machine and then run Eclipse, does that work > better? No, it doesn't. I've tried it already, and I notice the exact same problem. As an aside, I've logged in to the local box via the Chooser (i.e.remotely), and while things are OK (except for Eclipse), they are not pretty: * Sound broke in strange ways. Even for me it was darn confusing given that sound was working just before the login. * Performance in general is sluggish to the point of being annoying. For example, switching tabs in any GTK app (say System | Administration | Login Window) has a noticeable latency, I'd say close to 1s. -- Dimi Paun Lattica, Inc. From aph at redhat.com Tue Jan 8 13:36:49 2008 From: aph at redhat.com (Andrew Haley) Date: Tue, 8 Jan 2008 13:36:49 +0000 Subject: Bruttaly sluggish Eclipse performance in remote X In-Reply-To: <1199797482.4617.8.camel@dimi.lattica.com> References: <1199746646.9735.10.camel@dimi.lattica.com> <18307.20793.534261.12649@zebedee.pink> <1199797482.4617.8.camel@dimi.lattica.com> Message-ID: <18307.31857.437199.701977@zebedee.pink> Dimi Paun writes: > > On Tue, 2008-01-08 at 10:32 +0000, Andrew Haley wrote: > > If you ssh to the target machine and then run Eclipse, does that work > > better? > > No, it doesn't. I've tried it already, and I notice the exact > same problem. Ah, OK. Well, I don't see that happen at all. > As an aside, I've logged in to the local box via the Chooser > (i.e.remotely), and while things are OK (except for Eclipse), > they are not pretty: > * Sound broke in strange ways. Even for me it was darn confusing > given that sound was working just before the login. > * Performance in general is sluggish to the point of being > annoying. For example, switching tabs in any GTK app > (say System | Administration | Login Window) has a noticeable > latency, I'd say close to 1s. Right, so I agree, you're looking for timeouts on the remote box. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From dimi at lattica.com Tue Jan 8 13:42:41 2008 From: dimi at lattica.com (Dimi Paun) Date: Tue, 08 Jan 2008 08:42:41 -0500 Subject: Bruttaly sluggish Eclipse performance in remote X In-Reply-To: <18307.31857.437199.701977@zebedee.pink> References: <1199746646.9735.10.camel@dimi.lattica.com> <18307.20793.534261.12649@zebedee.pink> <1199797482.4617.8.camel@dimi.lattica.com> <18307.31857.437199.701977@zebedee.pink> Message-ID: <1199799761.4617.13.camel@dimi.lattica.com> On Tue, 2008-01-08 at 13:36 +0000, Andrew Haley wrote: > Ah, OK. Well, I don't see that happen at all. This is excellent! (I mean, it gives me hope :)) > > As an aside, I've logged in to the local box via the Chooser > > (i.e.remotely), and while things are OK (except for Eclipse), > > they are not pretty: > > * Sound broke in strange ways. Even for me it was darn confusing > > given that sound was working just before the login. > > * Performance in general is sluggish to the point of being > > annoying. For example, switching tabs in any GTK app > > (say System | Administration | Login Window) has a noticeable > > latency, I'd say close to 1s. > > Right, so I agree, you're looking for timeouts on the remote box. I must note that these are pristine F8 installations, I just went into gdmsetup and enabled XDMCP business (again, is it just me, or from the default "Fedora Infinity" there is no way to get to the Chooser to login to a different box?). Is there anyway I can debug this in any way? I'd say this is a major regression for Fedora that needs addressing, I'm willing to lend a hand :) -- Dimi Paun Lattica, Inc. From fedora at camperquake.de Tue Jan 8 13:51:55 2008 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 8 Jan 2008 14:51:55 +0100 Subject: Bruttaly sluggish Eclipse performance in remote X In-Reply-To: <1199799761.4617.13.camel@dimi.lattica.com> References: <1199746646.9735.10.camel@dimi.lattica.com> <18307.20793.534261.12649@zebedee.pink> <1199797482.4617.8.camel@dimi.lattica.com> <18307.31857.437199.701977@zebedee.pink> <1199799761.4617.13.camel@dimi.lattica.com> Message-ID: <20080108145155.5dca2ffc@dhcp03.addix.net> Hi. On Tue, 08 Jan 2008 08:42:41 -0500, Dimi Paun wrote: > I must note that these are pristine F8 installations, I just went > into gdmsetup and enabled XDMCP business (again, is it just me, or > from the default "Fedora Infinity" there is no way to get to the > Chooser to login to a different box?). I think there's a non-obvious key for that. F10? From lesmikesell at gmail.com Tue Jan 8 13:59:52 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 08 Jan 2008 07:59:52 -0600 Subject: Init : someone could comment this ? In-Reply-To: <1199787970.29101.58.camel@gibraltar.str.redhat.com> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <1199726855.20392.1.camel@gibraltar.str.redhat.com> <47826644.9030500@gmail.com> <1199787970.29101.58.camel@gibraltar.str.redhat.com> Message-ID: <478381D8.3080606@gmail.com> Nils Philippsen wrote: >>>> I think, when somebody wants to run a server, he has to understand how >>>> it works and how to configure it. When admin can not figure out correct >>>> cmdline options, how can he configure the server in a secure manner? >>> Along that line, everybody should be able to run configure && make && >>> make install and wrap their own packages, so why should we bother ;-)? >>> Seriously, I can cope with command line arguments and still like >>> sysconfig files that are more understandable than just plain >>> "OPTS='--foo -x=y -a'". I'm happy if I get things done without having to >>> read the documentation for the common case. I'm not saying admins >>> shouldn't be able to influence the cmd line options directly if they >>> wish. >> If you change that to some abstraction that you think is easier to >> understand, how do you propose (a) that sysadmins that already knew the >> real options should deal with the now confusing abstraction > > E.g. like with the old /etc/sysconfig/hdparm, you could use "speaking > options" but have an "HDPARM_OPTS" variable (or some name like that) > which would just passed on the command line. And how is someone supposed to know that? >> and (b) that >> the abstraction (and its documentation) always stays in sync with >> upstream changes/additions to the underlying program's options? It is >> already fairly messy trying to track what options have been moved to new >> locations under /etc/sysconfig in fedora/RH boxes and which are still in >> their normal locations. > > That's the job of the maintainer of the concerned package: to ensure > that sysconfig options he introduced get mapped to the correct set of > command line arguments. If those change, the mapping has to change. I think you are missing my point. I run an operating system in order to run programs I add myself, some of which supply init scripts which I expect to continue to run from one version to the next with no or minor changes. Changing the way a sysv-like init service runs would be sort of like the C language changing its keywords. Changing the system-supplied scripts to do things more efficiently is one thing; breaking expected system behavior is something else. -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Tue Jan 8 14:16:06 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 08 Jan 2008 08:16:06 -0600 Subject: Bruttaly sluggish Eclipse performance in remote X In-Reply-To: <1199797482.4617.8.camel@dimi.lattica.com> References: <1199746646.9735.10.camel@dimi.lattica.com> <18307.20793.534261.12649@zebedee.pink> <1199797482.4617.8.camel@dimi.lattica.com> Message-ID: <478385A6.2060105@gmail.com> Dimi Paun wrote: >> If you ssh to the target machine and then run Eclipse, does that work >> better? > > No, it doesn't. I've tried it already, and I notice the exact > same problem. The quick fix is probably to run freenx on the server and the NX client from http://www.nomachine.com on the client side. It runs the stuff affected by latency locally on the server and does proxy/caching with the client. And it's worth setting up even on a fast local network for the ability to suspend and reconnect to running sessions. But, you should probably track down the source of the latency anyway. -- Les Mikesell lesmikesell at gmail.com From dimi at lattica.com Tue Jan 8 14:20:41 2008 From: dimi at lattica.com (Dimi Paun) Date: Tue, 08 Jan 2008 09:20:41 -0500 Subject: Bruttaly sluggish Eclipse performance in remote X In-Reply-To: <478385A6.2060105@gmail.com> References: <1199746646.9735.10.camel@dimi.lattica.com> <18307.20793.534261.12649@zebedee.pink> <1199797482.4617.8.camel@dimi.lattica.com> <478385A6.2060105@gmail.com> Message-ID: <1199802041.4617.35.camel@dimi.lattica.com> On Tue, 2008-01-08 at 08:16 -0600, Les Mikesell wrote: > The quick fix is probably to run freenx on the server and the NX > client from http://www.nomachine.com on the client side. It runs the > stuff affected by latency locally on the server and does proxy/caching > with the client. And it's worth setting up even on a fast local > network for the ability to suspend and reconnect to running > sessions. Thanks, I'll give it a try. > But, you should probably track down the source of the latency anyway. I completely agree. However, I'm at a loss on how to do that, any help would be much appreciated. -- Dimi Paun Lattica, Inc. From nigel.metheringham at dev.intechnology.co.uk Tue Jan 8 14:27:20 2008 From: nigel.metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Tue, 8 Jan 2008 14:27:20 +0000 Subject: Bruttaly sluggish Eclipse performance in remote X In-Reply-To: <1199802041.4617.35.camel@dimi.lattica.com> References: <1199746646.9735.10.camel@dimi.lattica.com> <18307.20793.534261.12649@zebedee.pink> <1199797482.4617.8.camel@dimi.lattica.com> <478385A6.2060105@gmail.com> <1199802041.4617.35.camel@dimi.lattica.com> Message-ID: On 8 Jan 2008, at 14:20, Dimi Paun wrote: >> But, you should probably track down the source of the latency anyway. > > I completely agree. However, I'm at a loss on how to do that, any help > would be much appreciated. I vaguely remember a problem of this type I encountered a couple of years back, which was down to something along the lines of the entry in hosts for the machine name pointing to 127.0.0.1 and something being too smart and trying to use unix domain sockets for X (when target ip was 127.0.0.1). Sorry this is so vague... I would attempt setting the X display to an explicit-non-loopback- ip:display-num and see if that helps... also check xauth entries. Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From aph at redhat.com Tue Jan 8 14:58:41 2008 From: aph at redhat.com (Andrew Haley) Date: Tue, 8 Jan 2008 14:58:41 +0000 Subject: Bruttaly sluggish Eclipse performance in remote X In-Reply-To: <1199799761.4617.13.camel@dimi.lattica.com> References: <1199746646.9735.10.camel@dimi.lattica.com> <18307.20793.534261.12649@zebedee.pink> <1199797482.4617.8.camel@dimi.lattica.com> <18307.31857.437199.701977@zebedee.pink> <1199799761.4617.13.camel@dimi.lattica.com> Message-ID: <18307.36769.858391.683128@zebedee.pink> Dimi Paun writes: > > On Tue, 2008-01-08 at 13:36 +0000, Andrew Haley wrote: > > > Ah, OK. Well, I don't see that happen at all. > > This is excellent! (I mean, it gives me hope :)) > > > > As an aside, I've logged in to the local box via the Chooser > > > (i.e.remotely), and while things are OK (except for Eclipse), > > > they are not pretty: > > > * Sound broke in strange ways. Even for me it was darn confusing > > > given that sound was working just before the login. > > > * Performance in general is sluggish to the point of being > > > annoying. For example, switching tabs in any GTK app > > > (say System | Administration | Login Window) has a noticeable > > > latency, I'd say close to 1s. > > > > Right, so I agree, you're looking for timeouts on the remote box. > > I must note that these are pristine F8 installations, I just went > into gdmsetup and enabled XDMCP business (again, is it just me, or > from the default "Fedora Infinity" there is no way to get to the > Chooser to login to a different box?). > > Is there anyway I can debug this in any way? I'd say this is a major > regression for Fedora that needs addressing, I'm willing to lend a > hand :) Well, ATM we don't know anyone but you has ever seen this. Let's go through things, one at a time, Do you get good performance on the local display of both boxes ? Do you get good neatwork throughput between boxes? What is the ping time betewwn boxes? Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From dimi at lattica.com Tue Jan 8 15:15:44 2008 From: dimi at lattica.com (Dimi Paun) Date: Tue, 08 Jan 2008 10:15:44 -0500 Subject: Bruttaly sluggish Eclipse performance in remote X In-Reply-To: <18307.36769.858391.683128@zebedee.pink> References: <1199746646.9735.10.camel@dimi.lattica.com> <18307.20793.534261.12649@zebedee.pink> <1199797482.4617.8.camel@dimi.lattica.com> <18307.31857.437199.701977@zebedee.pink> <1199799761.4617.13.camel@dimi.lattica.com> <18307.36769.858391.683128@zebedee.pink> Message-ID: <1199805344.4617.40.camel@dimi.lattica.com> On Tue, 2008-01-08 at 14:58 +0000, Andrew Haley wrote: > Do you get good performance on the local display of both boxes ? Yes, I do. No problems here. > Do you get good neatwork throughput between boxes? Yes, I do: [dimi at dimi download]$ scp mihai at shrek:~mihai/download/ipligence/worldlocations.csv.gz tmp worldlocations.csv.gz 100% 33MB 33.3MB/s 00:01 > What is the ping time betewwn boxes? [dimi at dimi download]$ ping shrek PING shrek.lattica.com (192.168.3.12) 56(84) bytes of data. 64 bytes from 192.168.3.12: icmp_seq=1 ttl=64 time=0.175 ms 64 bytes from 192.168.3.12: icmp_seq=2 ttl=64 time=0.148 ms 64 bytes from 192.168.3.12: icmp_seq=3 ttl=64 time=0.156 ms 64 bytes from 192.168.3.12: icmp_seq=4 ttl=64 time=0.154 ms 64 bytes from 192.168.3.12: icmp_seq=5 ttl=64 time=0.158 ms 64 bytes from 192.168.3.12: icmp_seq=6 ttl=64 time=0.163 ms --- shrek.lattica.com ping statistics --- 6 packets transmitted, 6 received, 0% packet loss, time 4999ms rtt min/avg/max/mdev = 0.148/0.159/0.175/0.008 ms -- Dimi Paun Lattica, Inc. From nphilipp at redhat.com Tue Jan 8 15:23:42 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 08 Jan 2008 16:23:42 +0100 Subject: Init : someone could comment this ? In-Reply-To: <4782B561.2000302@gmail.com> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <4782B561.2000302@gmail.com> Message-ID: <1199805822.17437.33.camel@gibraltar.str.redhat.com> On Mon, 2008-01-07 at 15:27 -0800, Andrew Farris wrote: > Enrico Scholz wrote: > >>>>> But python or other bloaty scripting languages are not a solution > >>>>> and completely unacceptable at this place. > >>>> "Bloaty" is something that could be solved, don't you think? > >>> Not with python or perl. > >> I've shown you the numbers. Why you still insist on it being bloated > > > > Resulting scripts will be much longer. E.g. how much lines of python > > code are required for > > > > | sed '/^foo/s!/bin!/opt!' file | tac > > Looks like one line in python to me if you write a sed and tac replacement into > your python library. (e.g. thats not about bash vs python at all...) If I'm not to try to emulate the single commands, but look at the whole job which I understand as "read file, replace first occurrence of '/bin' with '/opt' in lines beginning with 'foo', then put out the lines in reversed order" it could be along this (and wouldn't use any external module or program): print '\n'.join (reversed (map (lambda line: line[:3] == "foo" and line.replace ('/bin', '/opt', 1) or line, ''.join (open ('file').readlines ()).split ('\n')))) To make this more readable, I'd split this up and comment it: --- 8< --- # read the file and split it at '\n' lines = ''.join (open ('file').readlines ()).split ('\n') for i in range (len (lines)): if line[:3] == 'foo': # replace first occurrence of /bin with /opt lines[i] = lines[i].replace ('/bin', '/opt', 1) print '\n'.join (reversed (lines)) --- >8 --- Now the original sed can surely be changed that it would take more than one line to emulate the line's function, but then I would feel comfortable using (shipped) modules like "re" to achieve the same effect as the shell code uses sed and tac. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From jkeating at redhat.com Tue Jan 8 15:34:31 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 8 Jan 2008 10:34:31 -0500 Subject: X in rawhide during install In-Reply-To: <1199750619.2175.1.camel@scrappy.miketc.com> References: <1199630953.2155.5.camel@scrappy.miketc.com> <1199721827.30771.583.camel@localhost.localdomain> <1199750619.2175.1.camel@scrappy.miketc.com> Message-ID: <20080108103431.778b7605@redhat.com> On Mon, 07 Jan 2008 18:03:39 -0600 Mike Chambers wrote: > Jeremy, any word on above, as to what date teh latest stage2 images > were built, and/or what the latest xorg drivers were included? stage2 is attempted to be rebuilt every night with rawhide. It uses whatever is latest in the buildsystem at the time of the compose. However the compose failed last night so we don't have new images. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tibbs at math.uh.edu Tue Jan 8 15:51:51 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 08 Jan 2008 09:51:51 -0600 Subject: Review swaps In-Reply-To: <870180fe0801071520r16ee79c6i2d86ea84fad086d5@mail.gmail.com> References: <870180fe0801071430q6d01ccf1j252ae475ee3f68f3@mail.gmail.com> <870180fe0801071520r16ee79c6i2d86ea84fad086d5@mail.gmail.com> Message-ID: >>>>> "JJ" == Jerry James writes: JJ> I don't know that I'm sufficiently experienced with Java packaging JJ> to be helpful, but I've had a lot of experience with JJ> pedanticalness. Surely that qualifies me for writing guidelines! JJ> :-) Yes, we on the packaging committee are positiviously ecstaticised by pedanticalosity. I guess what needs to happen, in the absence of the board persuading Red Hat management to allocate a few Java-wizard-hours, is that those who know just enough to be dangerous work on a few packages, hammer out some potentially dumb guidelines, beg for answers to the tough questions from folks who understand them. And finally, be prepared to quite possibly be flamed for making a set of bad guidelines by people who might just spend more time composing the flames than they would have spent helping us write guidelines they wouldn't have felt the need to flame. So I'll be the reviewer. I'll need two or three simple packages and one more complicated one, preferably by multiple submitters who are willing to respond to input, plus some packages already in the distro to look at. Obviously that includes at least one of yours. From there we can get a handle on what these packages need to do, where files need to go, and what rpmlint complaints come up. This is almost certainly an after-fudcon thing, unless some folks at fudcon want to sit down and bang something out. - J< From mspevack at redhat.com Tue Jan 8 16:14:57 2008 From: mspevack at redhat.com (Max Spevack) Date: Tue, 8 Jan 2008 11:14:57 -0500 (EST) Subject: FUDCon -- hackfests and BarCamp Message-ID: FUDConners, Most of you who are coming to FUDCon already know the details, but I just want to make sure everyone knows what's going on. http://fedoraproject.org/wiki/FUDCon/FUDConF9 -- this URL has a Google Map with all the addresses, locations, etc that are mentioned below. http://barcamp.org/FUDConRaleigh2008 is the general information page. Friday is a hackfest day. Those of you who are here and participating in hackfests should meet at the State Club on NCSU's centennial campus at about 9:30 AM. From there, we will let people know the lunch plans, and also sort out which hackfests we want to concentrate on, and where there are rooms that can be used. Please try to coordinate with the folks who have cars at the hotel for transportation. Saturday and Sunday both take place at Red Hat's actual headquarters. BarCamp is Saturday starting at 9:00 (doors open around 8:30 with coffee and stuff). Sunday will be another hackfest day starting about 9:30. Again, please try to coordinate rides with the folks who have cars at the hotel. A decent number will, and the hotel is only about a 5 minute drive from the hackfest and BarCamp locations. For folks getting to and from the airport, please see this page: http://fedoraproject.org/wiki/FUDCon/FUDConF9/ParticipantTravelPlans If you are participating in a hackfest and incur costs traveling from Airport to Hotel, get a receipt and Fedora will pay you back. _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From che666 at gmail.com Tue Jan 8 16:18:16 2008 From: che666 at gmail.com (Rudolf Kastl) Date: Tue, 8 Jan 2008 17:18:16 +0100 Subject: Init : someone could comment this ? In-Reply-To: <20080107173508.GA23429@tango.0pointer.de> References: <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <20080107173508.GA23429@tango.0pointer.de> Message-ID: On Jan 7, 2008 6:35 PM, Lennart Poettering wrote: > On Mon, 07.01.08 17:05, Enrico Scholz (enrico.scholz at informatik.tu-chemnitz.de) wrote: > > > >> I can not remember how long there are discussions about replacing > > >> RH's initsystem (perhaps 5-6 years), and nothing happened. Other > > >> distributions implemented more (upstart, syslog-ng) or less (suse, > > > > > > Is syslog-ng really an init system > > > > uups, I meant 'initng'. > > Everytime I hear someone mentioning initng I get a headache. > > They got almost everything wrong you can get wrong in an init > system. The kept the worst things from SysV (such as numerical > "runlevels"), What do you mean with numerical runlevels? does "default" for the standard runlevel look "numerical" to you? and added the worst things they could find in other > people's software. Like the braindeadness to make everything a shared > object, including stuff like executing chdir(). Can you believe that? > They have a "plugin" to change a directory which consists of 100 lines > or code or so. Unbelievable... > > Lennart > > -- > Lennart Poettering Red Hat, Inc. > lennart [at] poettering [dot] net ICQ# 11060553 > http://0pointer.net/lennart/ GnuPG 0x1A015CC4 > > -- > > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From caillon at redhat.com Tue Jan 8 16:20:13 2008 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 08 Jan 2008 17:20:13 +0100 Subject: Update on building against XULRunner Message-ID: <4783A2BD.80206@redhat.com> We've removed the old style .pc files which were specific to Fedora from xulrunner-devel and now are using only the upstream versions. In short, if you were using: mozilla-embedding.pc xulrunner-embedding.pc you must now use: libxul-embedding.pc and if you were using: mozilla-xpcom.pc xulrunner-xpcom.pc Please see http://fedoraproject.org/wiki/Releases/FeatureXULRunnerAPIChanges for details as always. _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From lesmikesell at gmail.com Tue Jan 8 16:31:55 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 08 Jan 2008 10:31:55 -0600 Subject: Init : someone could comment this ? In-Reply-To: References: <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <20080107173508.GA23429@tango.0pointer.de> Message-ID: <4783A57B.2050005@gmail.com> Rudolf Kastl wrote: >> >> They got almost everything wrong you can get wrong in an init >> system. The kept the worst things from SysV (such as numerical >> "runlevels"), > > What do you mean with numerical runlevels? does "default" for the > standard runlevel look "numerical" to you? Yes, where it is defined in the 'id' line in inittab. And if it doesn't stay that way, all of the machines I manage will crash and burn. -- Les Mikesell lesmikesell at gmail.com From che666 at gmail.com Tue Jan 8 16:33:40 2008 From: che666 at gmail.com (Rudolf Kastl) Date: Tue, 8 Jan 2008 17:33:40 +0100 Subject: Init : someone could comment this ? In-Reply-To: <4783A57B.2050005@gmail.com> References: <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <20080107173508.GA23429@tango.0pointer.de> <4783A57B.2050005@gmail.com> Message-ID: On Jan 8, 2008 5:31 PM, Les Mikesell wrote: > Rudolf Kastl wrote: > >> > >> They got almost everything wrong you can get wrong in an init > >> system. The kept the worst things from SysV (such as numerical > >> "runlevels"), > > > > What do you mean with numerical runlevels? does "default" for the > > standard runlevel look "numerical" to you? > > Yes, where it is defined in the 'id' line in inittab. And if it doesn't > stay that way, all of the machines I manage will crash and burn. inittab is sysV init config file... it has nothing to do with initng ;) regards, Rudolf Kastl > > -- > Les Mikesell > lesmikesell at gmail.com > > -- > > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From lesmikesell at gmail.com Tue Jan 8 16:53:43 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 08 Jan 2008 10:53:43 -0600 Subject: Init : someone could comment this ? In-Reply-To: References: <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <20080107173508.GA23429@tango.0pointer.de> <4783A57B.2050005@gmail.com> Message-ID: <4783AA97.8090500@gmail.com> Rudolf Kastl wrote: > On Jan 8, 2008 5:31 PM, Les Mikesell wrote: >> Rudolf Kastl wrote: >>>> They got almost everything wrong you can get wrong in an init >>>> system. The kept the worst things from SysV (such as numerical >>>> "runlevels"), >>> What do you mean with numerical runlevels? does "default" for the >>> standard runlevel look "numerical" to you? >> Yes, where it is defined in the 'id' line in inittab. And if it doesn't >> stay that way, all of the machines I manage will crash and burn. > > inittab is sysV init config file... it has nothing to do with initng ;) > OK, that's a good reason not to use it, then. -- Les Mikesell lesmikesell at gmail.com From katzj at redhat.com Tue Jan 8 17:02:19 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 08 Jan 2008 12:02:19 -0500 Subject: BUG: rawhide installer does not autoload xenblk/xennet modules In-Reply-To: <20080107193208.GO17677@edu.joroinen.fi> References: <20080107193208.GO17677@edu.joroinen.fi> Message-ID: <1199811739.3139.5.camel@aglarond.local> On Mon, 2008-01-07 at 21:32 +0200, Pasi K?rkk?inen wrote: > I just tried to install rawhide/development to a xen domU with virt-manager, > and it seems current kernel (or xen drivers?) has a bug that prevents > anaconda/installer from autoloading the needed drivers.. [snip] > "No driver found" > "Unable to find any devices of the type needed for this installation type." > "Would you like to manually select your driver or use a driver disk?" This could either be the xen kernel or the changes within anaconda to stop using kudzu. Please file it in bugzilla so that it doesn't get lost in the noise of the list. Thanks! Jeremy From katzj at redhat.com Tue Jan 8 17:03:33 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 08 Jan 2008 12:03:33 -0500 Subject: X in rawhide during install In-Reply-To: <1199721827.30771.583.camel@localhost.localdomain> References: <1199630953.2155.5.camel@scrappy.miketc.com> <1199721827.30771.583.camel@localhost.localdomain> Message-ID: <1199811813.3139.8.camel@aglarond.local> On Mon, 2008-01-07 at 11:03 -0500, Adam Jackson wrote: > On Sun, 2008-01-06 at 08:49 -0600, Mike Chambers wrote: > > Last week, I said the heck with it and did a yum update to rawhide from > > F8+updates. It performed OK but upon boot, x didn't want to come up, > > and think the error messages was about version mismatches or something. > > > > Well, just now, I was going to do a fresh rawhide install on same > > machine (wipe out F8 completely), but when it got to starting X to > > perform the install, it wouldn't run, not even in vesa (from the quick > > msg I saw come across), so it went into text mode (which I cancelled at > > that time). Would it had worked if I had went ahead with the text mode > > install, then tried to get X configured to start post-install? > > > > So, is xorg not fully functioning as of yet, with the new compiles that > > went on recently and I am guessing still happening? > > > > This was on a PIV 2.8Ghz w/1G ram, and an X1300 ATI card. > > I'm not sure how often the anaconda stage2 images are built, which is > where it gets the X drivers. I'm sure Jeremy's told me at some point > though. The stage2 images are built when rawhide composes. Based on Jesse's mail, it sounds like there have been problems there. The drivers included are based on the requirements of the xorg-x11-drivers package, so if there's a new driver, be sure to update it to require the new driver package. Jeremy From notting at redhat.com Tue Jan 8 17:16:43 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 8 Jan 2008 12:16:43 -0500 Subject: BUG: rawhide installer does not autoload xenblk/xennet modules In-Reply-To: <1199811739.3139.5.camel@aglarond.local> References: <20080107193208.GO17677@edu.joroinen.fi> <1199811739.3139.5.camel@aglarond.local> Message-ID: <20080108171643.GE2792@nostromo.devel.redhat.com> Jeremy Katz (katzj at redhat.com) said: > On Mon, 2008-01-07 at 21:32 +0200, Pasi K?rkk?inen wrote: > > I just tried to install rawhide/development to a xen domU with virt-manager, > > and it seems current kernel (or xen drivers?) has a bug that prevents > > anaconda/installer from autoloading the needed drivers.. > [snip] > > "No driver found" > > "Unable to find any devices of the type needed for this installation type." > > "Would you like to manually select your driver or use a driver disk?" > > This could either be the xen kernel or the changes within anaconda to > stop using kudzu. Please file it in bugzilla so that it doesn't get > lost in the noise of the list. xenblk/xennet don't export any aliases that would cause them to get loaded. So they don't get loaded. Bill From katzj at redhat.com Tue Jan 8 17:20:18 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 08 Jan 2008 12:20:18 -0500 Subject: BUG: rawhide installer does not autoload xenblk/xennet modules In-Reply-To: <20080108171643.GE2792@nostromo.devel.redhat.com> References: <20080107193208.GO17677@edu.joroinen.fi> <1199811739.3139.5.camel@aglarond.local> <20080108171643.GE2792@nostromo.devel.redhat.com> Message-ID: <1199812818.3139.10.camel@aglarond.local> On Tue, 2008-01-08 at 12:16 -0500, Bill Nottingham wrote: > Jeremy Katz (katzj at redhat.com) said: > > On Mon, 2008-01-07 at 21:32 +0200, Pasi K?rkk?inen wrote: > > > I just tried to install rawhide/development to a xen domU with virt-manager, > > > and it seems current kernel (or xen drivers?) has a bug that prevents > > > anaconda/installer from autoloading the needed drivers.. > > [snip] > > > "No driver found" > > > "Unable to find any devices of the type needed for this installation type." > > > "Would you like to manually select your driver or use a driver disk?" > > > > This could either be the xen kernel or the changes within anaconda to > > stop using kudzu. Please file it in bugzilla so that it doesn't get > > lost in the noise of the list. > > xenblk/xennet don't export any aliases that would cause them to get loaded. > So they don't get loaded. That would do it. Thus, file the bug against kernel-xen. They should have modaliases so they can get loaded automatically Jeremy From ajackson at redhat.com Tue Jan 8 17:43:56 2008 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 08 Jan 2008 12:43:56 -0500 Subject: X in rawhide during install In-Reply-To: <1199811813.3139.8.camel@aglarond.local> References: <1199630953.2155.5.camel@scrappy.miketc.com> <1199721827.30771.583.camel@localhost.localdomain> <1199811813.3139.8.camel@aglarond.local> Message-ID: <1199814236.13583.5.camel@localhost.localdomain> On Tue, 2008-01-08 at 12:03 -0500, Jeremy Katz wrote: > On Mon, 2008-01-07 at 11:03 -0500, Adam Jackson wrote: > > I'm not sure how often the anaconda stage2 images are built, which is > > where it gets the X drivers. I'm sure Jeremy's told me at some point > > though. > > The stage2 images are built when rawhide composes. Based on Jesse's > mail, it sounds like there have been problems there. The drivers > included are based on the requirements of the xorg-x11-drivers package, > so if there's a new driver, be sure to update it to require the new > driver package. Broadly speaking I try to keep versioned deps out of x-x-d. radeonhd still isn't in there, but vesa should work regardless... - ajax From che666 at gmail.com Tue Jan 8 17:37:00 2008 From: che666 at gmail.com (Rudolf Kastl) Date: Tue, 8 Jan 2008 18:37:00 +0100 Subject: Init : someone could comment this ? In-Reply-To: <4783AA97.8090500@gmail.com> References: <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <20080107173508.GA23429@tango.0pointer.de> <4783A57B.2050005@gmail.com> <4783AA97.8090500@gmail.com> Message-ID: On Jan 8, 2008 5:53 PM, Les Mikesell wrote: > Rudolf Kastl wrote: > > On Jan 8, 2008 5:31 PM, Les Mikesell wrote: > >> Rudolf Kastl wrote: > >>>> They got almost everything wrong you can get wrong in an init > >>>> system. The kept the worst things from SysV (such as numerical > >>>> "runlevels"), > >>> What do you mean with numerical runlevels? does "default" for the > >>> standard runlevel look "numerical" to you? > >> Yes, where it is defined in the 'id' line in inittab. And if it doesn't > >> stay that way, all of the machines I manage will crash and burn. > > > > inittab is sysV init config file... it has nothing to do with initng ;) > > > > OK, that's a good reason not to use it, then. i dont get your logic... kind regards, Rudolf Kastl > > -- > > Les Mikesell > lesmikesell at gmail.com > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From ddutile at redhat.com Tue Jan 8 17:43:50 2008 From: ddutile at redhat.com (Don Dutile) Date: Tue, 08 Jan 2008 12:43:50 -0500 Subject: BUG: rawhide installer does not autoload xenblk/xennet modules In-Reply-To: <1199812818.3139.10.camel@aglarond.local> References: <20080107193208.GO17677@edu.joroinen.fi> <1199811739.3139.5.camel@aglarond.local> <20080108171643.GE2792@nostromo.devel.redhat.com> <1199812818.3139.10.camel@aglarond.local> Message-ID: <4783B656.9040504@redhat.com> Needs something like the attached patch file... Jeremy Katz wrote: > On Tue, 2008-01-08 at 12:16 -0500, Bill Nottingham wrote: >> Jeremy Katz (katzj at redhat.com) said: >>> On Mon, 2008-01-07 at 21:32 +0200, Pasi K??rkk??inen wrote: >>>> I just tried to install rawhide/development to a xen domU with virt-manager, >>>> and it seems current kernel (or xen drivers?) has a bug that prevents >>>> anaconda/installer from autoloading the needed drivers.. >>> [snip] >>>> "No driver found" >>>> "Unable to find any devices of the type needed for this installation type." >>>> "Would you like to manually select your driver or use a driver disk?" >>> This could either be the xen kernel or the changes within anaconda to >>> stop using kudzu. Please file it in bugzilla so that it doesn't get >>> lost in the noise of the list. >> xenblk/xennet don't export any aliases that would cause them to get loaded. >> So they don't get loaded. > > That would do it. Thus, file the bug against kernel-xen. They should > have modaliases so they can get loaded automatically > > Jeremy > -------------- next part -------------- A non-text attachment was scrubbed... Name: xenpv-autoload.patch Type: text/x-patch Size: 4172 bytes Desc: not available URL: From opensource at till.name Tue Jan 8 18:01:43 2008 From: opensource at till.name (Till Maas) Date: Tue, 08 Jan 2008 19:01:43 +0100 Subject: Init : someone could comment this ? In-Reply-To: <878x32q8ao.fsf@fc5.bigo.ensc.de> References: <1199550054.2847.1.camel@bureau.maison> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> Message-ID: <200801081901.48083.opensource@till.name> On Mon January 7 2008, Enrico Scholz wrote: > | kill(pid, SIGTERM); /* wait for timeout/sigchld */ kill(pid, SIGKILL); > > But python or other bloaty scripting languages are not a solution and > completely unacceptable at this place. Imho there is some code missing, that the pid really belongs to the service, e.g. when the service died/crashed and the pid file still exists, a wrong process can be killed here. Also I guess it would be better to first try to SIGTERM the all services that should be terminated, then wait, and then send the SIGKILL instead of waiting for each process independently. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From loupgaroublond at gmail.com Tue Jan 8 18:27:24 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Tue, 8 Jan 2008 13:27:24 -0500 Subject: Review swaps In-Reply-To: References: <870180fe0801071430q6d01ccf1j252ae475ee3f68f3@mail.gmail.com> <870180fe0801071520r16ee79c6i2d86ea84fad086d5@mail.gmail.com> Message-ID: <7f692fec0801081027y2feb7f6re5ac610cc09e30cb@mail.gmail.com> On 08 Jan 2008 09:51:51 -0600, Jason L Tibbitts III wrote: > Yes, we on the packaging committee are positiviously ecstaticised by > pedanticalosity. > > I guess what needs to happen, in the absence of the board persuading > Red Hat management to allocate a few Java-wizard-hours, is that those > who know just enough to be dangerous work on a few packages, hammer > out some potentially dumb guidelines, beg for answers to the tough > questions from folks who understand them. And finally, be prepared to > quite possibly be flamed for making a set of bad guidelines by people > who might just spend more time composing the flames than they would > have spent helping us write guidelines they wouldn't have felt the > need to flame. > I've banged out some bad guidelines for Haskell packaging. Is there anyone who wants to help review them, or just plain flame them to shreds? -Yaakov From enrico.scholz at informatik.tu-chemnitz.de Tue Jan 8 18:48:29 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 08 Jan 2008 19:48:29 +0100 Subject: Init : someone could comment this ? In-Reply-To: <200801081901.48083.opensource@till.name> (Till Maas's message of "Tue, 08 Jan 2008 19:01:43 +0100") References: <1199550054.2847.1.camel@bureau.maison> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <200801081901.48083.opensource@till.name> Message-ID: <874pdodugy.fsf@kosh.bigo.ensc.de> Till Maas writes: >> | kill(pid, SIGTERM); /* wait for timeout/sigchld */ kill(pid, SIGKILL); > > Imho there is some code missing, that the pid really belongs to the > service, no; as already written, modern initsystems use non-forking daemons where such checks are not needed anymore. > e.g. when the service died/crashed and the pid file still exists pidfiles are ancient hacks not required by modern initsystems anymore. > , a wrong process can be killed here. Also I guess it would be better > to first try to SIGTERM the all services that should be terminated, > then wait, and then send the SIGKILL instead of waiting for each > process independently. stop sequence happens in reverted order and can be done in parallel, but there must by synchronization points (e.g. 'httpd' + 'ftpd' -> sync -> 'udhcpc' -> sync -> 'udevd') Enrico From cjdahlin at ncsu.edu Tue Jan 8 18:57:13 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Tue, 08 Jan 2008 13:57:13 -0500 Subject: Init : someone could comment this ? In-Reply-To: <874pdodugy.fsf@kosh.bigo.ensc.de> References: <1199550054.2847.1.camel@bureau.maison> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <200801081901.48083.opensource@till.name> <874pdodugy.fsf@kosh.bigo.ensc.de> Message-ID: <4783C789.5070309@ncsu.edu> Enrico Scholz wrote: > Till Maas writes: > > >>> | kill(pid, SIGTERM); /* wait for timeout/sigchld */ kill(pid, SIGKILL); >>> >> Imho there is some code missing, that the pid really belongs to the >> service, >> > > no; as already written, modern initsystems use non-forking daemons where > such checks are not needed anymore. > > > It is up to the designer of the app whether it forks or not, and while there may be an argument that one way is better or worse, the init maintainers cannot guarantee the behavior of that which their system must start. >> e.g. when the service died/crashed and the pid file still exists >> > > pidfiles are ancient hacks not required by modern initsystems anymore. > > > >> , a wrong process can be killed here. Also I guess it would be better >> to first try to SIGTERM the all services that should be terminated, >> then wait, and then send the SIGKILL instead of waiting for each >> process independently. >> > > stop sequence happens in reverted order and can be done in parallel, but > there must by synchronization points (e.g. 'httpd' + 'ftpd' -> sync -> > 'udhcpc' -> sync -> 'udevd') > > > > Enrico > > From lsof at nodata.co.uk Tue Jan 8 18:59:56 2008 From: lsof at nodata.co.uk (nodata) Date: Tue, 08 Jan 2008 19:59:56 +0100 Subject: Init : someone could comment this ? In-Reply-To: <20080107173508.GA23429@tango.0pointer.de> References: <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <20080107173508.GA23429@tango.0pointer.de> Message-ID: <1199818796.5534.0.camel@sb-home> Am Montag, den 07.01.2008, 18:35 +0100 schrieb Lennart Poettering: > such as numerical "runlevels") I like Gentoo's init scripts. Very clean, with dependencies. From vpivaini at cs.helsinki.fi Tue Jan 8 19:03:25 2008 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Tue, 8 Jan 2008 21:03:25 +0200 Subject: Help with packaging tmispell-voikko (Ispell compatible Finnish spellchecking ) In-Reply-To: References: <200712282248.21314.vpivaini@cs.helsinki.fi> <200801072023.25274.vpivaini@cs.helsinki.fi> Message-ID: <200801082103.25988.vpivaini@cs.helsinki.fi> Kevin Kofler kirjoitti: > Ville-Pekka Vainio cs.helsinki.fi> writes: > > To get the ball rolling regarding tmispell-voikko, I have submitted a > > review request here: > > . > > > > This Spec/SRPM doesn't try to do any ispell integration yet, hopefully > > I'll get some help on that later. > > I attached a patch which adds support for tmispell to kdelibs3 (KSpell) to > the bug report. KDE 4 and KSpell2 in kdelibs3 (with my FeatureDictionary > patch) don't need any patching nor ispell hackery as they use enchant. Most > GNOME stuff these days also uses enchant, partly thanks to the > FeatureDictionary work. Any app which tries to call ispell, hunspell, > aspell or whatever directly will need some patching though if we use that > approach. Thanks! Now I'm just waiting for a review ;) As far as I know, Voikko has no aspell or hunspell support. As the Voikko main developer suggested, we could add ispell support to Fedora in the following way: /usr/bin/ispell in Fedora is a shell script, so we could make it call tmispell whenever it's called with the Finnish language. The ispell script is in the aspell package, which is maintained by Ivana Varekova. What's generally the best approach here, contacting her directly or submitting a feature request against aspell in Bugzilla? If we can get this change into the ispell script, then the KDE patch wouldn't necessarily be needed, I guess that depends on how well the ispell thing would work. > Oh, in case somebody asks why Finnish isn't using hunspell (which is what > we're trying to standardize on in Fedora): I don't believe there is any > working Finnish dictionary for hunspell. The one on the OO.o dictionary > page is a dummy empty dictionary. And given that Finnish has complex > agglutinative grammar, a simple word list definitely won't cut it. So I > trust the folks who actually speak Finnish to know what they're doing in > this context. ;-) Actually, the Voikko project initially started as Hunspell-fi, but the developers decided to switch to a Malaga/Suomi-malaga based approach, mostly because it works better and was less work for them. Those who are interested in Voikko may want to read this: . As you mentioned OpenOffice, there is also a Voikko extension for OpenOffice and I'm interested in packaging that too. I'll probably discuss that in it's own thread once I'll have atleast a preliminary spec file done. -- Ville-Pekka Vainio From lesmikesell at gmail.com Tue Jan 8 19:37:53 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 08 Jan 2008 13:37:53 -0600 Subject: Init : someone could comment this ? In-Reply-To: References: <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <20080107173508.GA23429@tango.0pointer.de> <4783A57B.2050005@gmail.com> <4783AA97.8090500@gmail.com> Message-ID: <4783D111.80308@gmail.com> Rudolf Kastl wrote: >>>>>> They got almost everything wrong you can get wrong in an init >>>>>> system. The kept the worst things from SysV (such as numerical >>>>>> "runlevels"), >>>>> What do you mean with numerical runlevels? does "default" for the >>>>> standard runlevel look "numerical" to you? >>>> Yes, where it is defined in the 'id' line in inittab. And if it doesn't >>>> stay that way, all of the machines I manage will crash and burn. >>> inittab is sysV init config file... it has nothing to do with initng ;) >>> >> OK, that's a good reason not to use it, then. > > i dont get your logic... People running fedora will expect to use sysV style init configuration to control it. -- Les Mikesell lesmikesell at gmail.com From poelstra at redhat.com Tue Jan 8 19:54:25 2008 From: poelstra at redhat.com (John Poelstra) Date: Tue, 08 Jan 2008 11:54:25 -0800 Subject: Fwd: closing out old bugs of unmaintained releases In-Reply-To: <47802400.7030407@gmail.com> References: <20080104140746.62518306@ghistelwchlohm.scrye.com> <477EA9DA.9040202@gmail.com> <20080104171008.3cc6db16@ghistelwchlohm.scrye.com> <47802400.7030407@gmail.com> Message-ID: <4783D4F1.8040008@redhat.com> Andrew Farris said the following on 01/05/2008 04:42 PM Pacific Time: > > The interesting thing here is that MANY of those rawhide bugs are in > fact not for current rawhide, and that because there is a lack of > rawhide versioning there are many of them that should be closed WONTFIX > as well. I had one open bug myself that had been filed as rawhide but > not updated since 2004 (I remedied that due to this thread). Yes, this should be part of the clean-up proposal--closing rawhide bugs before a certain date. > I would say that the recent change to rawhide tag rather than devel > should have been more thorough and included a rawhide version (pre-F9) > for instance. Getting rid of the 3 different -testX versions was good, > but rawhide changes and bugs filed against it get left behind. > It was discussed on fedora-test-list at the time of the change of the bugzilla versions. Most seemed to be in agreement that going forward, at the GA of each new release, the version of all existing rawhide bugs would be mass changed to the GA version. For example, for the upcoming release, open rawhide bugs at the time of GA we would changed to Fedora 9. This would have a few benefits as we go forward for each release: 1) encourage the closing of rawhide bugs that qualify 2) anchor the remaining rawhide bugs to the closest GA release so there is a marker in the future as to when they were reported. John From james.antill at redhat.com Tue Jan 8 20:38:10 2008 From: james.antill at redhat.com (James Antill) Date: Tue, 08 Jan 2008 15:38:10 -0500 Subject: Init : someone could comment this ? In-Reply-To: <874pdodugy.fsf@kosh.bigo.ensc.de> References: <1199550054.2847.1.camel@bureau.maison> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <200801081901.48083.opensource@till.name> <874pdodugy.fsf@kosh.bigo.ensc.de> Message-ID: <1199824690.18076.40.camel@code.and.org> On Tue, 2008-01-08 at 19:48 +0100, Enrico Scholz wrote: > Till Maas writes: > > >> | kill(pid, SIGTERM); /* wait for timeout/sigchld */ kill(pid, SIGKILL); > > > > Imho there is some code missing, that the pid really belongs to the > > service, > > no; as already written, modern initsystems use non-forking daemons where > such checks are not needed anymore. > > > e.g. when the service died/crashed and the pid file still exists > > pidfiles are ancient hacks not required by modern initsystems anymore. That's just not true, for example: http://www.initng.org/browser/initng-ifiles/trunk/initfiles/daemon/exim/listener.ii ...maybe you mean that they support it, and _in your opinion_ application code should change to use that model ... but that's a very different thing. -- James Antill Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From cjdahlin at ncsu.edu Tue Jan 8 20:38:38 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Tue, 08 Jan 2008 15:38:38 -0500 Subject: Init : someone could comment this ? In-Reply-To: <4783D111.80308@gmail.com> References: <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <20080107173508.GA23429@tango.0pointer.de> <4783A57B.2050005@gmail.com> <4783AA97.8090500@gmail.com> <4783D111.80308@gmail.com> Message-ID: <4783DF4E.8060906@ncsu.edu> Les Mikesell wrote: > Rudolf Kastl wrote: > >>>>>>> They got almost everything wrong you can get wrong in an init >>>>>>> system. The kept the worst things from SysV (such as numerical >>>>>>> "runlevels"), >>>>>> What do you mean with numerical runlevels? does "default" for the >>>>>> standard runlevel look "numerical" to you? >>>>> Yes, where it is defined in the 'id' line in inittab. And if it >>>>> doesn't >>>>> stay that way, all of the machines I manage will crash and burn. >>>> inittab is sysV init config file... it has nothing to do with >>>> initng ;) >>>> >>> OK, that's a good reason not to use it, then. >> >> i dont get your logic... > > People running fedora will expect to use sysV style init configuration > to control it. > great. Maybe we should move back to KDE 1, since a lot of people got used to that at the beginning. :( In fact we don't offer compatibility with the abacus. I'm sure computers alienated a lot of abacus users way back when, maybe we could do something about that. Interfaces change. We like to keep them the same but snapping the reigns and yelling "giddyup" just isn't a suitable control mechanism for a car. A new init system is likely going to have properties that inittab isn't capable of expressing. Users will have to learn. Anyone manually editing text config files is comfortable enough to handle the changes. --CJD From ville.skytta at iki.fi Tue Jan 8 20:44:44 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 8 Jan 2008 22:44:44 +0200 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: References: <20080103120242.GZ20451@devserv.devel.redhat.com> <20080106140633.GB2984@ryvius.greysector.net> Message-ID: <200801082244.44821.ville.skytta@iki.fi> On Sunday 06 January 2008, Kevin Kofler wrote: > Dominik 'Rathann' Mierzejewski greysector.net> writes: > > What are we supposed to do after getting a failing package to build with > > gcc-4.3? Just commit the fix to CVS/devel or tag and build the updated > > package, too? If there's going to be a mass rebuild with gcc-4.3, I don't > > see any value in building the fixed package until gcc-4.3 hits rawhide, > > just wasted mirrors' bandwith. > > Building the fixed package right now allows doing automated/scripted mass > rebuilds, which may well be the method used when GCC 4.3 actually hits > Rawhide. It is also useful for the on-the-side mass rebuilds like the one > Jakub did. Just committing to CVS (and perhaps tagging, but not building) would have the same benefit. Assuming of course that these mass rebuilds operate on CVS (last tagged version, or scripted bump+tag+build) and not the SRPMS tree. > This is Rawhide, I think you really don't have to worry about not pushing > rebuilds which aren't absolutely needed. If I was using or mirroring Rawhide, I wouldn't appreciate this mindset at all. From ville.skytta at iki.fi Tue Jan 8 20:49:21 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 8 Jan 2008 22:49:21 +0200 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <200801082244.44821.ville.skytta@iki.fi> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <200801082244.44821.ville.skytta@iki.fi> Message-ID: <200801082249.21461.ville.skytta@iki.fi> On Tuesday 08 January 2008, Ville Skytt? wrote: > On Sunday 06 January 2008, Kevin Kofler wrote: > > > This is Rawhide, I think you really don't have to worry about not pushing > > rebuilds which aren't absolutely needed. > > If I was using or mirroring Rawhide, I wouldn't appreciate this mindset at > all. Actually, I don't personally appreciate it even when I'm not using Rawhide because it can easily result in no-benefit package updates between distro versions; eg. in this case if for some reason gcc 4.3 won't make it to F9 after all and there was no other need to rebuild some packages after F8. From lesmikesell at gmail.com Tue Jan 8 20:55:34 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 08 Jan 2008 14:55:34 -0600 Subject: Init : someone could comment this ? In-Reply-To: <4783DF4E.8060906@ncsu.edu> References: <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <20080107173508.GA23429@tango.0pointer.de> <4783A57B.2050005@gmail.com> <4783AA97.8090500@gmail.com> <4783D111.80308@gmail.com> <4783DF4E.8060906@ncsu.edu> Message-ID: <4783E346.1030301@gmail.com> Casey Dahlin wrote: > Interfaces change. We like to keep them the same but snapping the reigns > and yelling "giddyup" just isn't a suitable control mechanism for a car. Great - how will you like it when the gas/brake pedals are reversed on your next model? > A new init system is likely going to have properties that inittab isn't > capable of expressing. What does that have to do with maintaining interfaces? If someone can't write a backwards-compatible interface why should you trust them to be able to improve something? > Users will have to learn. Or not. -- Les Mikesell lesmikesell at gmail.com From ml at deadbabylon.de Tue Jan 8 21:08:58 2008 From: ml at deadbabylon.de (Sebastian Vahl) Date: Tue, 8 Jan 2008 22:08:58 +0100 Subject: KDE-SIG weekly report (02/2008) Message-ID: <200801082209.03393.ml@deadbabylon.de> This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply ?to this email or add it to the related meeting page. ---------------------------------------------------------------------------------- = Weekly KDE Summary = Week: 02/2008 Time: 2008-01-08 16:00 UTC Meeting page: http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-01-08 Meeting log: http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-01-08?action=AttachFile&do=get&target=fedora-kde-sig-2008-01-08.txt ---------------------------------------------------------------------------------- = Participants = - KevinKofler - RexDieter - SebastianVahl - ThanNgo ---------------------------------------------------------------------------------- = Agenda = * KDE 4.0.0 final * preparing for Fedora 9 Alpha [1] * Review of KDE parts in Desktop User Guide [2] = Summary = o KDE 4.0.0 final: - kde-4.0.0. is already prepared in cvs - upstream asked us to not built and release it before final release (some tarballs are also re-spun) o preparing for Fedora 9 Alpha: - kde-l10n has to be prepared for the mixture of kde3 and kde4 packages - the list of bugs [3] collected from the kde 4 live image has to be checked against kde-4.0.0 again - upstream patch should be included to work with gtk+-applets (like nm-applet) (#427442) [4] - there are no news for knetworkmanager and the NetworkManager-0.7 problem - menu entries with only generic names should be fixed o Review of KDE parts in Desktop User Guide: - We were asked if we could review the current parts for KDE - We should find other (not so busy) volunteers for that job. But after the last "request for help" no documentation writers showed up o Open discussion: - Open review request: #427185: okteta - Binary editor [5] - Open review request: #425872: kde4-decoration-native-quarticurve-kwin - Unofficial port of the Bluecurve KWin decoration to KDE 4 [6] - packaging kaudiocreator is ongoing but waiting for a fix in kdelibs ---------------------------------------------------------------------------------- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-01-15 ---------------------------------------------------------------------------------- = Links = [1] http://fedoraproject.org/wiki/Releases/9/Schedule [2] http://fedoraproject.org/wiki/Docs/Drafts/DesktopUserGuide [3] http://fedoraproject.org/wiki/SebastianVahl/KDE4LiveBugs [4] https://bugzilla.redhat.com/show_bug.cgi?id=427442 [5] https://bugzilla.redhat.com/show_bug.cgi?id=427185 [6] https://bugzilla.redhat.com/show_bug.cgi?id=425872 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From tgl at redhat.com Tue Jan 8 21:28:21 2008 From: tgl at redhat.com (Tom Lane) Date: Tue, 08 Jan 2008 16:28:21 -0500 Subject: PPC needs lots more stack space in rawhide?? Message-ID: <14298.1199827701@sss.pgh.pa.us> I'm having a tough time trying to get mysql rebuilt in rawhide: the ppc build keeps failing like this: http://koji.fedoraproject.org/koji/getfile?taskID=335275&name=build.log Normally what a failure in execution_constants means is that the configuration constant STACK_MIN_SIZE has to be increased, because the error-recovery code needs more stack space than it did before. We have for years had to run that a bit higher than what mysql.com ships, but up to now 16384 has worked fine across all arches (all 7 redhat arches, not just Fedora). Sometime since 13 Dec 2007, however, the behavior of the ppc arch changed in rawhide, and now even boosting the number by 50% (to 24K) doesn't persuade it to work. I could try larger numbers, at the cost of also increasing DEFAULT_THREAD_STACK which is a pretty user-visible number. I am wondering if this isn't a bug in rawhide, though. Has gcc started making PPC stack frames a lot larger than before? Maybe glibc has gotten more stack-hungry? I'd guess on the problem being in gettext() or related code, if it is a glibc change, but I haven't tracked it down exactly. I can't prove at the moment that the problem affects *only* PPC, but given that that build always dies first it seems pretty likely. If anyone has a clue what to look at, I'd appreciate it. regards, tom lane From lordmorgul at gmail.com Tue Jan 8 21:59:32 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Tue, 08 Jan 2008 13:59:32 -0800 Subject: Fwd: closing out old bugs of unmaintained releases In-Reply-To: <4783D4F1.8040008@redhat.com> References: <20080104140746.62518306@ghistelwchlohm.scrye.com> <477EA9DA.9040202@gmail.com> <20080104171008.3cc6db16@ghistelwchlohm.scrye.com> <47802400.7030407@gmail.com> <4783D4F1.8040008@redhat.com> Message-ID: <4783F244.6050707@gmail.com> John Poelstra wrote: >> I would say that the recent change to rawhide tag rather than devel >> should have been more thorough and included a rawhide version (pre-F9) >> for instance. Getting rid of the 3 different -testX versions was good, >> but rawhide changes and bugs filed against it get left behind. >> > > It was discussed on fedora-test-list at the time of the change of the > bugzilla versions. > > Most seemed to be in agreement that going forward, at the GA of each new > release, the version of all existing rawhide bugs would be mass changed > to the GA version. For example, for the upcoming release, open rawhide > bugs at the time of GA we would changed to Fedora 9. This would have a > few benefits as we go forward for each release: > 1) encourage the closing of rawhide bugs that qualify > 2) anchor the remaining rawhide bugs to the closest GA release so > there is a marker in the future as to when they were reported. > > John > I guess I missed that discussion but that would indeed fix the problem of carrying Rawhide bugs along into next release. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From triad at df.lth.se Tue Jan 8 22:14:34 2008 From: triad at df.lth.se (Linus Walleij) Date: Tue, 8 Jan 2008 23:14:34 +0100 (CET) Subject: Init : someone could comment this ? In-Reply-To: <4783D111.80308@gmail.com> References: <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <20080107173508.GA23429@tango.0pointer.de> <4783A57B.2050005@gmail.com> <4783AA97.8090500@gmail.com> <4783D111.80308@gmail.com> Message-ID: On Tue, 8 Jan 2008, Les Mikesell wrote: > People running fedora will expect to use sysV style init configuration to > control it. Now, I think Lennart is right in pushing the concept behind Upstart and the new InitKit, both of which break the init config paradigm and its runlevels. The reason was actually outlined in Miguel de Icaza's "Let's Make Unix Not Suck" a few years back. It outlined some weaknesses of the Unix pipe and filter and signalling system: pipes are unidirectional, data is not typed, signals are crude in essence. Component-based thinking through CORBA led to the invention of Bonobo, then the condensed DCOP and eventually D-Bus which actually does the tricks most sought after: bidirectional messages between processes, typed messages, a strict namespace, broadcast messages. The SysVInit system currently suffers from not being able to use such a mechanism. Upstart solved it, basically, but has some design flaws and is used in init-compatibility mode in Ubuntu. So now InitKit is coming along. It's worth sacrificing runlevels to reach the next step of unsucky Unix. POSIX does not mandate init and its runlevels, nor does the Single Unix spec. I think there is a good reason for: it was awkward, so it wasn't standardized. If everyone though it was a good idea they would have standardized it back when POSIX was written. (I wasn't a member of the committes tho, so who knows.) Linus From notting at redhat.com Tue Jan 8 22:15:57 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 8 Jan 2008 17:15:57 -0500 Subject: Fwd: closing out old bugs of unmaintained releases In-Reply-To: <4783D4F1.8040008@redhat.com> References: <20080104140746.62518306@ghistelwchlohm.scrye.com> <477EA9DA.9040202@gmail.com> <20080104171008.3cc6db16@ghistelwchlohm.scrye.com> <47802400.7030407@gmail.com> <4783D4F1.8040008@redhat.com> Message-ID: <20080108221557.GB19726@nostromo.devel.redhat.com> John Poelstra (poelstra at redhat.com) said: > Most seemed to be in agreement that going forward, at the GA of each new > release, the version of all existing rawhide bugs would be mass changed to > the GA version. For example, for the upcoming release, open rawhide bugs > at the time of GA we would changed to Fedora 9. This would have a few > benefits as we go forward for each release: > 1) encourage the closing of rawhide bugs that qualify > 2) anchor the remaining rawhide bugs to the closest GA release so there > is a marker in the future as to when they were reported. Hm, this runs afoul of things like hosted projects that use Fedora bugzilla as essentially an upstream bug tracker. Bill From berrange at redhat.com Tue Jan 8 22:18:09 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 8 Jan 2008 22:18:09 +0000 Subject: Fwd: closing out old bugs of unmaintained releases In-Reply-To: <20080108221557.GB19726@nostromo.devel.redhat.com> References: <20080104140746.62518306@ghistelwchlohm.scrye.com> <477EA9DA.9040202@gmail.com> <20080104171008.3cc6db16@ghistelwchlohm.scrye.com> <47802400.7030407@gmail.com> <4783D4F1.8040008@redhat.com> <20080108221557.GB19726@nostromo.devel.redhat.com> Message-ID: <20080108221809.GR21294@redhat.com> On Tue, Jan 08, 2008 at 05:15:57PM -0500, Bill Nottingham wrote: > John Poelstra (poelstra at redhat.com) said: > > Most seemed to be in agreement that going forward, at the GA of each new > > release, the version of all existing rawhide bugs would be mass changed to > > the GA version. For example, for the upcoming release, open rawhide bugs > > at the time of GA we would changed to Fedora 9. This would have a few > > benefits as we go forward for each release: > > 1) encourage the closing of rawhide bugs that qualify > > 2) anchor the remaining rawhide bugs to the closest GA release so there > > is a marker in the future as to when they were reported. > > Hm, this runs afoul of things like hosted projects that use Fedora bugzilla > as essentially an upstream bug tracker. Shouldn't they be using a 'Fedora hosted' product, rather than the main 'Fedora' product (albeit with possibly the same 'component' value) Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From jonstanley at gmail.com Tue Jan 8 22:19:54 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Tue, 8 Jan 2008 17:19:54 -0500 Subject: Fwd: closing out old bugs of unmaintained releases In-Reply-To: <20080108221557.GB19726@nostromo.devel.redhat.com> References: <20080104140746.62518306@ghistelwchlohm.scrye.com> <477EA9DA.9040202@gmail.com> <20080104171008.3cc6db16@ghistelwchlohm.scrye.com> <47802400.7030407@gmail.com> <4783D4F1.8040008@redhat.com> <20080108221557.GB19726@nostromo.devel.redhat.com> Message-ID: On Jan 8, 2008 5:15 PM, Bill Nottingham wrote: > Hm, this runs afoul of things like hosted projects that use Fedora bugzilla > as essentially an upstream bug tracker. IIRC, there is both a 'Fedora Hosted' product, or individual trac instances. I think the trac instances are the current method of dealing with this. From lsof at nodata.co.uk Tue Jan 8 22:21:30 2008 From: lsof at nodata.co.uk (nodata) Date: Tue, 08 Jan 2008 23:21:30 +0100 Subject: Init : someone could comment this ? In-Reply-To: <1199805822.17437.33.camel@gibraltar.str.redhat.com> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <4781A04C.2080506@ncsu.edu> <87prwe5bac.fsf@kosh.bigo.ensc.de> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <4782B561.2000302@gmail.com> <1199805822.17437.33.camel@gibraltar.str.redhat.com> Message-ID: <1199830890.3080.7.camel@sb-home> Am Dienstag, den 08.01.2008, 16:23 +0100 schrieb Nils Philippsen: > On Mon, 2008-01-07 at 15:27 -0800, Andrew Farris wrote: > > Enrico Scholz wrote: > > >>>>> But python or other bloaty scripting languages are not a solution > > >>>>> and completely unacceptable at this place. > > >>>> "Bloaty" is something that could be solved, don't you think? > > >>> Not with python or perl. > > >> I've shown you the numbers. Why you still insist on it being bloated > > > > > > Resulting scripts will be much longer. E.g. how much lines of python > > > code are required for > > > > > > | sed '/^foo/s!/bin!/opt!' file | tac > > > > Looks like one line in python to me if you write a sed and tac replacement into > > your python library. (e.g. thats not about bash vs python at all...) > > If I'm not to try to emulate the single commands, but look at the whole > job which I understand as "read file, replace first occurrence of '/bin' > with '/opt' in lines beginning with 'foo', then put out the lines in > reversed order" it could be along this (and wouldn't use any external > module or program): > > print '\n'.join (reversed (map (lambda line: line[:3] == "foo" and line.replace ('/bin', '/opt', 1) or line, ''.join (open ('file').readlines ()).split ('\n')))) > > To make this more readable, I'd split this up and comment it: > > --- 8< --- > # read the file and split it at '\n' > lines = ''.join (open ('file').readlines ()).split ('\n') Yikes! Python just became Perl :) > > for i in range (len (lines)): > if line[:3] == 'foo': > # replace first occurrence of /bin with /opt > lines[i] = lines[i].replace ('/bin', '/opt', 1) > > print '\n'.join (reversed (lines)) > --- >8 --- > > Now the original sed can surely be changed that it would take more than > one line to emulate the line's function, but then I would feel > comfortable using (shipped) modules like "re" to achieve the same effect > as the shell code uses sed and tac. > > Nils > -- > Nils Philippsen / Red Hat / nphilipp at redhat.com > "Those who would give up Essential Liberty to purchase a little Temporary > Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 > PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 > From nicolas.mailhot at laposte.net Tue Jan 8 22:22:28 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 08 Jan 2008 23:22:28 +0100 Subject: Init : someone could comment this ? In-Reply-To: <4783D111.80308@gmail.com> References: <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <20080107173508.GA23429@tango.0pointer.de> <4783A57B.2050005@gmail.com> <4783AA97.8090500@gmail.com> <4783D111.80308@gmail.com> Message-ID: <1199830948.19622.3.camel@rousalka.dyndns.org> Le mardi 08 janvier 2008 ? 13:37 -0600, Les Mikesell a ?crit : > People running fedora will expect to use sysV style init configuration > to control it. IMHO people running Fedora (and RHEL) will gladly take any well-designed system over what exists now, and to hell with sysV style init if that helps making a good replacement. It's all very well to perpetuate habits, but don't overestimate the attachment people have to the current system. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jkeating at redhat.com Tue Jan 8 22:26:10 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 8 Jan 2008 17:26:10 -0500 Subject: Fwd: closing out old bugs of unmaintained releases In-Reply-To: <20080108221809.GR21294@redhat.com> References: <20080104140746.62518306@ghistelwchlohm.scrye.com> <477EA9DA.9040202@gmail.com> <20080104171008.3cc6db16@ghistelwchlohm.scrye.com> <47802400.7030407@gmail.com> <4783D4F1.8040008@redhat.com> <20080108221557.GB19726@nostromo.devel.redhat.com> <20080108221809.GR21294@redhat.com> Message-ID: <20080108172610.0aacf00a@redhat.com> On Tue, 8 Jan 2008 22:18:09 +0000 "Daniel P. Berrange" wrote: > Shouldn't they be using a 'Fedora hosted' product, rather than the > main 'Fedora' product (albeit with possibly the same 'component' > value) That product was a mistake on my part. It's unwieldy to use products like this, we'd have to create products for each hosted project, and that just gets noisy. This was also pre-Trac. Mock just hasn't been persuaded to move to Trac for upstream bug tracking. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cjdahlin at ncsu.edu Tue Jan 8 22:29:42 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Tue, 08 Jan 2008 17:29:42 -0500 Subject: Init : someone could comment this ? In-Reply-To: References: <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <20080107173508.GA23429@tango.0pointer.de> <4783A57B.2050005@gmail.com> <4783AA97.8090500@gmail.com> <4783D111.80308@gmail.com> Message-ID: <4783F956.90201@ncsu.edu> Linus Walleij wrote: > On Tue, 8 Jan 2008, Les Mikesell wrote: > >> People running fedora will expect to use sysV style init >> configuration to control it. > > Now, I think Lennart is right in pushing the concept behind Upstart > and the new InitKit, both of which break the init config paradigm and > its runlevels. > > The reason was actually outlined in Miguel de Icaza's "Let's Make Unix > Not Suck" a few years back. It outlined some weaknesses of the Unix > pipe and filter and signalling system: pipes are unidirectional, data > is not typed, signals are crude in essence. Component-based thinking > through CORBA led to the invention of Bonobo, then the condensed DCOP > and eventually D-Bus which actually does the tricks most sought after: > bidirectional messages between processes, typed messages, a strict > namespace, broadcast messages. > > The SysVInit system currently suffers from not being able to use such > a mechanism. > > Upstart solved it, basically, but has some design flaws and is used in > init-compatibility mode in Ubuntu. So now InitKit is coming along. > > It's worth sacrificing runlevels to reach the next step of unsucky Unix. > > POSIX does not mandate init and its runlevels, nor does the Single > Unix spec. I think there is a good reason for: it was awkward, so it > wasn't standardized. If everyone though it was a good idea they would > have standardized it back when POSIX was written. (I wasn't a member > of the committes tho, so who knows.) > > Linus > I agree. Also, I don't necessarily think we should wait for InitKit. InitKit is more of a fork-and-abandon of upstart (though major changes are in order) and I don't thing Upstart would be a bad stepping stone in the meantime. I will talk to the developer about this. Getting features to users sooner is a good thing :) --CJD From notting at redhat.com Tue Jan 8 22:44:50 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 8 Jan 2008 17:44:50 -0500 Subject: Fwd: closing out old bugs of unmaintained releases In-Reply-To: References: <20080104140746.62518306@ghistelwchlohm.scrye.com> <477EA9DA.9040202@gmail.com> <20080104171008.3cc6db16@ghistelwchlohm.scrye.com> <47802400.7030407@gmail.com> <4783D4F1.8040008@redhat.com> <20080108221557.GB19726@nostromo.devel.redhat.com> Message-ID: <20080108224450.GA26508@nostromo.devel.redhat.com> Jon Stanley (jonstanley at gmail.com) said: > On Jan 8, 2008 5:15 PM, Bill Nottingham wrote: > > > Hm, this runs afoul of things like hosted projects that use Fedora bugzilla > > as essentially an upstream bug tracker. > > IIRC, there is both a 'Fedora Hosted' product, or individual trac > instances. I think the trac instances are the current method of > dealing with this. And if the upstream maintainer runs screaming at the idea of using trac for bug tracking? (Note: most of these projects (anaconda, etc.) predate both hosted and trac.) Bill From ianburrell at gmail.com Tue Jan 8 22:45:14 2008 From: ianburrell at gmail.com (Ian Burrell) Date: Tue, 8 Jan 2008 14:45:14 -0800 Subject: Init : someone could comment this ? In-Reply-To: References: <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <20080107173508.GA23429@tango.0pointer.de> <4783A57B.2050005@gmail.com> <4783AA97.8090500@gmail.com> <4783D111.80308@gmail.com> Message-ID: On Jan 8, 2008 2:14 PM, Linus Walleij wrote: > On Tue, 8 Jan 2008, Les Mikesell wrote: > > > People running fedora will expect to use sysV style init configuration to > > control it. > > Now, I think Lennart is right in pushing the concept behind Upstart and > the new InitKit, both of which break the init config paradigm and its > runlevels. > > The reason was actually outlined in Miguel de Icaza's "Let's Make Unix Not > Suck" a few years back. It outlined some weaknesses of the Unix pipe and > filter and signalling system: pipes are unidirectional, data is not typed, > signals are crude in essence. Component-based thinking through CORBA led > to the invention of Bonobo, then the condensed DCOP and eventually D-Bus > which actually does the tricks most sought after: bidirectional messages > between processes, typed messages, a strict namespace, broadcast messages. > > The SysVInit system currently suffers from not being able to use such a > mechanism. > > Upstart solved it, basically, but has some design flaws and is used in > init-compatibility mode in Ubuntu. So now InitKit is coming along. > > It's worth sacrificing runlevels to reach the next step of unsucky Unix. > > POSIX does not mandate init and its runlevels, nor does the Single Unix > spec. I think there is a good reason for: it was awkward, so it wasn't > standardized. If everyone though it was a good idea they would have > standardized it back when POSIX was written. (I wasn't a member of the > committes tho, so who knows.) > I think it is important to look what interfaces the init system provides and which ones should be preserved. The current init has three, /etc/inittab to determine what is done for runlevels, the /etc/rc.d/rc symlinks to determine what services are run by /etc/rc.d/rc, and the /etc/init.d scripts that are executed. I think it is important that we preserve the ability to use sysv-style init scripts. They are part of LSB. It would be lots of work to convert everything to any new way. They are installed by third-party packages. It might be possible to change the functions to work better with a new system (for example by not forking when running new programs). I think it would be acceptable if the new features required a new file format as long as the old one is supported. The /sbin/service program should work with both. It would be nice if there was a program that could use the LSB metadata to configure dependencies and other startup. The /etc/inittab config file is specific to SysV init. Other systems don't even have the concept of runlevels. It would be nice to preserve the /etc/rc.d symlinks for determining which service to start, but the standard interface is the chkconfig program. Other Linux distributions with SysV init have the symlinks in different places. It would be nice if there was a program that could produce the new configuration from the old and even synchronize them after changes to the old. - Ian From jkeating at redhat.com Tue Jan 8 22:58:14 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 8 Jan 2008 17:58:14 -0500 Subject: Fwd: closing out old bugs of unmaintained releases In-Reply-To: <20080108224450.GA26508@nostromo.devel.redhat.com> References: <20080104140746.62518306@ghistelwchlohm.scrye.com> <477EA9DA.9040202@gmail.com> <20080104171008.3cc6db16@ghistelwchlohm.scrye.com> <47802400.7030407@gmail.com> <4783D4F1.8040008@redhat.com> <20080108221557.GB19726@nostromo.devel.redhat.com> <20080108224450.GA26508@nostromo.devel.redhat.com> Message-ID: <20080108175814.2de04e59@redhat.com> On Tue, 8 Jan 2008 17:44:50 -0500 Bill Nottingham wrote: > And if the upstream maintainer runs screaming at the idea of using > trac for bug tracking? > > (Note: most of these projects (anaconda, etc.) predate both hosted > and trac.) Those projects are likely a lot more tied to the Fedora release anyway, and it makes some sense to treat the bugs filed against them the same as bugs filed against the Fedora version of them. (whoh, meta) -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Tue Jan 8 23:07:29 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 09 Jan 2008 00:07:29 +0100 Subject: Init : someone could comment this ? In-Reply-To: <4783C789.5070309@ncsu.edu> (Casey Dahlin's message of "Tue, 08 Jan 2008 13:57:13 -0500") References: <1199550054.2847.1.camel@bureau.maison> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <200801081901.48083.opensource@till.name> <874pdodugy.fsf@kosh.bigo.ensc.de> <4783C789.5070309@ncsu.edu> Message-ID: <87zlvfdiha.fsf@kosh.bigo.ensc.de> Casey Dahlin writes: >> no; as already written, modern initsystems use non-forking daemons >> where such checks are not needed anymore. >> >> >> > It is up to the designer of the app whether it forks or not, and while > there may be an argument that one way is better or worse, the init > maintainers cannot guarantee the behavior of that which their system > must start. 1. most (yes, I have numbers) daemons have some kind of --do-not-fork switch 2. most (sorry, I do not have numbers there) daemons have some kind of bugzilla where you can report patches and enhancements Enrico From snecklifter at gmail.com Tue Jan 8 23:15:07 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Tue, 8 Jan 2008 23:15:07 +0000 Subject: Fwd: closing out old bugs of unmaintained releases In-Reply-To: <20080108172610.0aacf00a@redhat.com> References: <20080104140746.62518306@ghistelwchlohm.scrye.com> <477EA9DA.9040202@gmail.com> <20080104171008.3cc6db16@ghistelwchlohm.scrye.com> <47802400.7030407@gmail.com> <4783D4F1.8040008@redhat.com> <20080108221557.GB19726@nostromo.devel.redhat.com> <20080108221809.GR21294@redhat.com> <20080108172610.0aacf00a@redhat.com> Message-ID: <364d303b0801081515p1d9e0cb9ka983b42df21bf641@mail.gmail.com> Over the previous few days * wrote: Sorry I'm a bit late to the party but thought I'd throw my comments after having spent the past few months trawling through every F7 kernel bug[1]. Specifically in relation to F6 bugs, I think that closing out bugs with the EOL message is A Very Good Thing for the following reasons: - Closing bugs for a legitimate reason often gives them a shot in the arm. Yes, there will be a few people who get upset at this but I _firmly_ believe this is fewer than many fear. - A huge number of responses after prodding sleeping bugs have been "Oh, yeah, I upgraded to F7 and this was fixed. Forgot to update bug, please close." - F6 is EOL - we do not support it and people know (or should know) this - Reporter can re-open with updated info if necessary In response to the wider question of bug triaging, I find it extremely rewarding work [2] (though there are some bad days [3]) and as Jesse suggested [4] I would be happy to assist in the triaging effort. Chris Aillon [5] even suggested paying someone to do it so I officially apply for the position, providing my previous triaging work as my CV. :) Which works well btw as I'm currently jobseeking [6].... [1] https://www.redhat.com/archives/fedora-kernel-list/2007-September/msg00021.html [2] https://bugzilla.redhat.com/show_bug.cgi?id=297091 [3] https://bugzilla.redhat.com/show_bug.cgi?id=260101 [4] https://www.redhat.com/archives/fedora-advisory-board/2008-January/msg00019.html [5] https://www.redhat.com/archives/fedora-advisory-board/2008-January/msg00053.html [6] http://www.chruz.com/about/ Cheers -- Christopher Brown http://www.chruz.com From enrico.scholz at informatik.tu-chemnitz.de Tue Jan 8 23:29:51 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 09 Jan 2008 00:29:51 +0100 Subject: Init : someone could comment this ? In-Reply-To: <1199824690.18076.40.camel@code.and.org> (James Antill's message of "Tue, 08 Jan 2008 15:38:10 -0500") References: <1199550054.2847.1.camel@bureau.maison> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <200801081901.48083.opensource@till.name> <874pdodugy.fsf@kosh.bigo.ensc.de> <1199824690.18076.40.camel@code.and.org> Message-ID: <87ve63dhg0.fsf@kosh.bigo.ensc.de> James Antill writes: > > no; as already written, modern initsystems use non-forking daemons > > where such checks are not needed anymore. > > ... > > pidfiles are ancient hacks not required by modern initsystems > > anymore. > > That's just not true, for example: > http://www.initng.org/browser/initng-ifiles/trunk/initfiles/daemon/exim/listener.ii initng has code to deal with old daemons which do not have a --do-not-fork option. E.g. they *can* look for a pidfile after some time and inject back the pid. Enrico From lesmikesell at gmail.com Tue Jan 8 23:45:27 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 08 Jan 2008 17:45:27 -0600 Subject: Init : someone could comment this ? In-Reply-To: <1199830948.19622.3.camel@rousalka.dyndns.org> References: <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <1199702578.5761.36.camel@wombat.tiptoe.de> <874pdprg1p.fsf@fc5.bigo.ensc.de> <1199716729.18170.40.camel@gibraltar.str.redhat.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <20080107173508.GA23429@tango.0pointer.de> <4783A57B.2050005@gmail.com> <4783AA97.8090500@gmail.com> <4783D111.80308@gmail.com> <1199830948.19622.3.camel@rousalka.dyndns.org> Message-ID: <47840B17.4040402@gmail.com> Nicolas Mailhot wrote: > >> People running fedora will expect to use sysV style init configuration >> to control it. > > IMHO people running Fedora (and RHEL) will gladly take any well-designed > system over what exists now, and to hell with sysV style init if that > helps making a good replacement. It's all very well to perpetuate > habits, but don't overestimate the attachment people have to the current > system. But to be better, it has to do all that the old system did and more. Would it be able to process commands to suspend-to-ram/suspend-to-disk with sensibly sequenced operations as well as intercept the hardware hints that these things should be done - and likewise order the operations as it wakes up from these states? -- Les Mikesell lesmikesell at gmail.com From poelstra at redhat.com Wed Jan 9 01:17:06 2008 From: poelstra at redhat.com (John Poelstra) Date: Tue, 08 Jan 2008 17:17:06 -0800 Subject: FUDCon F9 Bugzilla Planning (was Re: dormant bugs and our perception) Message-ID: <47842092.5000401@redhat.com> John Poelstra said the following on 01/02/2008 02:14 PM Pacific Time: > In other words, we need to create a solid plan with input from lots of > people and then execute it. FUDCon would be a great place to get > started.... not sure if this is a hackfest or barcamp topic. > > John > > [1] I'll post to the wiki and announce once I have something of > substance. Most likely not until next week. > http://fedoraproject.org/wiki/JohnPoelstra/ImprovingBugzillaF9 During my searching I found that Jon Stanley has also put up a page of ideas which is excellent. I think he has already mentioned it in a post, but I'll give it another plug. http://fedoraproject.org/wiki/JonStanley/BugTriageIdeas My page probably overlaps in areas and is a 0.3 draft. It is definitely redundant in places and could be tightened up. Feel free to add to it--I'll be making changes to it too up until the time we meet. I think it is easier to gather proposed ideas for this on one of our wiki pages instead of continuing the mail threads so that there some central places to reference when we start discussing at FUDCon vs. trying to comb through all the mailing list threads again then. John From Michael_E_Brown at dell.com Wed Jan 9 05:50:38 2008 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 8 Jan 2008 23:50:38 -0600 Subject: Fwd: closing out old bugs of unmaintained releases In-Reply-To: <20080108172610.0aacf00a@redhat.com> References: <20080104140746.62518306@ghistelwchlohm.scrye.com> <477EA9DA.9040202@gmail.com> <20080104171008.3cc6db16@ghistelwchlohm.scrye.com> <47802400.7030407@gmail.com> <4783D4F1.8040008@redhat.com> <20080108221557.GB19726@nostromo.devel.redhat.com> <20080108221809.GR21294@redhat.com> <20080108172610.0aacf00a@redhat.com> Message-ID: <20080109055037.GD17806@humbolt.us.dell.com> On Tue, Jan 08, 2008 at 05:26:10PM -0500, Jesse Keating wrote: > On Tue, 8 Jan 2008 22:18:09 +0000 > "Daniel P. Berrange" wrote: > > > Shouldn't they be using a 'Fedora hosted' product, rather than the > > main 'Fedora' product (albeit with possibly the same 'component' > > value) > > That product was a mistake on my part. It's unwieldy to use products > like this, we'd have to create products for each hosted project, and > that just gets noisy. > > This was also pre-Trac. Mock just hasn't been persuaded to move to > Trac for upstream bug tracking. Benefits of Trac? It seems the case now that most mock users expect to just enter bugs in bugzilla. -- Michael From valent.turkovic at gmail.com Wed Jan 9 08:20:46 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 9 Jan 2008 09:20:46 +0100 Subject: Pulse Audio 0.9.8 - upgrade? Message-ID: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> Hi, I saw that Pulse Audio 0.9.8 got released two months ago: http://pulseaudio.org/milestone/0.9.8 and I see on my Fedora 8 that we still have 0.9.7 $ pulseaudio --version pulseaudio 0.9.7 Will there be an upgrade soon on Fedora 8 to Pulse Audio 0.9.8? Lost of issues have been fixed in new Pulse Audio so users like me who have issues with Pulse Audio would appreciate the much needed upgrade. Thank you, Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From mschwendt.tmp0701.nospam at arcor.de Wed Jan 9 08:45:32 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 9 Jan 2008 09:45:32 +0100 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> Message-ID: <20080109094532.811057b2.mschwendt.tmp0701.nospam@arcor.de> On Wed, 9 Jan 2008 09:20:46 +0100, Valent Turkovic wrote: > Hi, > I saw that Pulse Audio 0.9.8 got released two months ago: > http://pulseaudio.org/milestone/0.9.8 > and I see on my Fedora 8 that we still have 0.9.7 > > $ pulseaudio --version > pulseaudio 0.9.7 > > Will there be an upgrade soon on Fedora 8 to Pulse Audio 0.9.8? > > Lost of issues have been fixed in new Pulse Audio so users like me who > have issues with Pulse Audio would appreciate the much needed upgrade. I'm sure the person who maintains the Fedora packages is aware of that. :) Just notice the connection between Pulse Audio and Red Hat. From nicolas.mailhot at laposte.net Wed Jan 9 08:54:30 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 9 Jan 2008 09:54:30 +0100 (CET) Subject: Init : someone could comment this ? In-Reply-To: References: <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <87ve65pqnl.fsf@fc5.bigo.ensc.de> <20080107173508.GA23429@tango.0pointer.de> <4783A57B.2050005@gmail.com> <4783AA97.8090500@gmail.com> <4783D111.80308@gmail.com> Message-ID: <50837.192.54.193.53.1199868870.squirrel@rousalka.dyndns.org> Le Mar 8 janvier 2008 23:45, Ian Burrell a ?crit : > I think it is important that we preserve the ability to use sysv-style > init scripts. They are part of LSB. Sort-of. The LSB description is ambiguous, as evidenced by the many questions posted when we decided to migrate our existing pre-LSB scripts to the LSB variant. And I'm far from sure that other distributions answered those questions the same way. > It would be lots of work to > convert everything to any new way. It would be lots of work to shoehorn sysV init design in something radically different. SysV has no notion of hotplugging which must be a core design consideration of any semi-decent init system replacement. > They are installed by third-party packages. Because other distros have a "let's keep compat with RHEL init since ISVs target RHEL", but if Fedora/RHEL moves to something else keeping compat will mean supporting this something else. Don't mistake this for any particular attachment so sysV init scripts (quite the contrary) -- Nicolas Mailhot From dwmw2 at infradead.org Wed Jan 9 10:15:59 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 09 Jan 2008 10:15:59 +0000 Subject: PPC needs lots more stack space in rawhide?? In-Reply-To: <14298.1199827701@sss.pgh.pa.us> References: <14298.1199827701@sss.pgh.pa.us> Message-ID: <1199873759.4111.414.camel@shinybook.infradead.org> On Tue, 2008-01-08 at 16:28 -0500, Tom Lane wrote: > I'm having a tough time trying to get mysql rebuilt in rawhide: the ppc > build keeps failing like this: > http://koji.fedoraproject.org/koji/getfile?taskID=335275&name=build.log > > Normally what a failure in execution_constants means is that the > configuration constant STACK_MIN_SIZE has to be increased, because the > error-recovery code needs more stack space than it did before. We have > for years had to run that a bit higher than what mysql.com ships, but up > to now 16384 has worked fine across all arches (all 7 redhat arches, > not just Fedora). Sometime since 13 Dec 2007, however, the behavior > of the ppc arch changed in rawhide, and now even boosting the number > by 50% (to 24K) doesn't persuade it to work. I could try larger > numbers, at the cost of also increasing DEFAULT_THREAD_STACK which > is a pretty user-visible number. I am wondering if this isn't a bug > in rawhide, though. Has gcc started making PPC stack frames a lot > larger than before? Maybe glibc has gotten more stack-hungry? I'd > guess on the problem being in gettext() or related code, if it is a > glibc change, but I haven't tracked it down exactly. For a while we used 64KiB pages on ppc64, because IBM insisted on it in RHEL5 and I didn't notice we'd done the same stupid thing in Fedora. I believe it was like that in FC6 but I fixed it again for F7. Is it possible that the kernel on the build machines is now similarly afflicted? -- dwmw2 From caolanm at redhat.com Wed Jan 9 10:22:15 2008 From: caolanm at redhat.com (Caolan McNamara) Date: Wed, 09 Jan 2008 10:22:15 +0000 Subject: hunspell dictionaries, what's "missing" Message-ID: <1199874135.10609.122.camel@Jehannum> http://fedoraproject.org/wiki/Releases/FeatureDictionary now lists the languages for which we ship aspell dictionaries but not hunspell ones. i.e. ?Breton, Faeroese, Icelandic, Indonesian, Malayalam, Scots Gaelic and Serbian. Packaging those dictionaries will enable OOo to spell-check your language and have the same level of support in OOo/evo/gedit/xchat/tomboy/pidgen/KDE (and hopefully firefox eventually). Also a Swedish speaker should consider packaging the Swedish hyphenation dictionary available from http://wiki.services.openoffice.org/wiki/Dictionaries#Swedish_.28Sweden.29 which would enable better line breaking for over-long words in OOo, a complaint I've heard occasionally. C. From mschwendt.tmp0701.nospam at arcor.de Wed Jan 9 10:23:47 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 9 Jan 2008 11:23:47 +0100 Subject: PPC needs lots more stack space in rawhide?? In-Reply-To: <1199873759.4111.414.camel@shinybook.infradead.org> References: <14298.1199827701@sss.pgh.pa.us> <1199873759.4111.414.camel@shinybook.infradead.org> Message-ID: <20080109112347.5dac5df3.mschwendt.tmp0701.nospam@arcor.de> On Wed, 09 Jan 2008 10:15:59 +0000, David Woodhouse wrote: > > On Tue, 2008-01-08 at 16:28 -0500, Tom Lane wrote: > > I'm having a tough time trying to get mysql rebuilt in rawhide: the ppc > > build keeps failing like this: > > http://koji.fedoraproject.org/koji/getfile?taskID=335275&name=build.log > > > > Normally what a failure in execution_constants means is that the > > configuration constant STACK_MIN_SIZE has to be increased, because the > > error-recovery code needs more stack space than it did before. We have > > for years had to run that a bit higher than what mysql.com ships, but up > > to now 16384 has worked fine across all arches (all 7 redhat arches, > > not just Fedora). Sometime since 13 Dec 2007, however, the behavior > > of the ppc arch changed in rawhide, and now even boosting the number > > by 50% (to 24K) doesn't persuade it to work. I could try larger > > numbers, at the cost of also increasing DEFAULT_THREAD_STACK which > > is a pretty user-visible number. I am wondering if this isn't a bug > > in rawhide, though. Has gcc started making PPC stack frames a lot > > larger than before? Maybe glibc has gotten more stack-hungry? I'd > > guess on the problem being in gettext() or related code, if it is a > > glibc change, but I haven't tracked it down exactly. > > For a while we used 64KiB pages on ppc64, because IBM insisted on it in > RHEL5 and I didn't notice we'd done the same stupid thing in Fedora. I > believe it was like that in FC6 but I fixed it again for F7. > > Is it possible that the kernel on the build machines is now similarly > afflicted? In December the builders have been upgraded to RHEL5. From alexl at users.sourceforge.net Wed Jan 9 10:54:44 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Wed, 09 Jan 2008 03:54:44 -0700 Subject: Fedora x86_64 rawhide rebuild in mock status 2008-01-05 In-Reply-To: <3170f42f0801071925t6d57e3e0p1a729c1db51273f6@mail.gmail.com> (Debarshi Ray's message of "Tue\, 8 Jan 2008 08\:55\:04 +0530") References: <20080107224330.GA14071@humbolt.us.dell.com> <3170f42f0801071925t6d57e3e0p1a729c1db51273f6@mail.gmail.com> Message-ID: <3vir23clqj.fsf@allele2.eebweb.arizona.edu> >>>>> Debarshi 'Rishi' Ray writes: >> Fedora Rawhide-in-Mock Build Results for x86_64 using the rawhide >> tree as of Saturday, January 5, 2008. >> >> [...] anjuta-gdl-0.7.3-2.fc9 (build/make) rishi > I inherited anjuta-gdl from Paul F. Johnson few weeks back. Since > then I have updated it to a new upstream version; renamed it to > libgdl (discussed on fedora-devel-list: > https://www.redhat.com/archives/fedora-devel-list/2007-December/msg00830.html); > and submitted for review: > https://bugzilla.redhat.com/show_bug.cgi?id=426599 Review done. > A few other packages, like anjuta, depend on this. I presume you'll co-ordinate with the maintainers of the other packages to rebuild against the new libgdal. Alex From panemade at gmail.com Wed Jan 9 11:21:46 2008 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Wed, 9 Jan 2008 16:51:46 +0530 Subject: hunspell dictionaries, what's "missing" In-Reply-To: <1199874135.10609.122.camel@Jehannum> References: <1199874135.10609.122.camel@Jehannum> Message-ID: Hi caolan, On Jan 9, 2008 3:52 PM, Caolan McNamara wrote: > http://fedoraproject.org/wiki/Releases/FeatureDictionary now lists the > languages for which we ship aspell dictionaries but not hunspell ones. > i.e. Breton, Faeroese, Icelandic, Indonesian, Malayalam, Scots Gaelic > and Serbian. > Thanks for this FeatureDictionary work. I have already in communication with Malayalam hunspell dictionary author and he need some more time to fix some remaining issues. Also, asked him to include license when he will release new upstream tarball. Aspell-ml is going through review. > Packaging those dictionaries will enable OOo to spell-check your > language and have the same level of support in > OOo/evo/gedit/xchat/tomboy/pidgen/KDE (and hopefully firefox > eventually). > > Also a Swedish speaker should consider packaging the Swedish hyphenation > dictionary available from > http://wiki.services.openoffice.org/wiki/Dictionaries#Swedish_.28Sweden.29 > which would enable better line breaking for over-long words in OOo, a > complaint I've heard occasionally. > Regards, Parag. From ndbecker2 at gmail.com Wed Jan 9 11:30:31 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 09 Jan 2008 06:30:31 -0500 Subject: Procedure to rename review request? Message-ID: I believe the review request unuran should have been called libunuran. What is the procedure to rename it? From caillon at redhat.com Wed Jan 9 11:46:56 2008 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 09 Jan 2008 12:46:56 +0100 Subject: Procedure to rename review request? In-Reply-To: References: Message-ID: <4784B430.9060208@redhat.com> On 01/09/2008 12:30 PM, Neal Becker wrote: > I believe the review request unuran should have been called libunuran. What > is the procedure to rename it? It looks like it's still in review. You just change the bug summary and update the packages/specfile... or am I missing something? From rc040203 at freenet.de Wed Jan 9 12:14:39 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 09 Jan 2008 13:14:39 +0100 Subject: Init : someone could comment this ? In-Reply-To: <47812D36.4030309@ncsu.edu> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <1199638106.6022.88.camel@beck.corsepiu.local> <47812D36.4030309@ncsu.edu> Message-ID: <1199880879.5534.210.camel@beck.corsepiu.local> On Sun, 2008-01-06 at 14:34 -0500, Casey Dahlin wrote: > Ralf Corsepius wrote: > > On Sun, 2008-01-06 at 10:44 -0500, Yaakov Nemoy wrote: > > > >> On Jan 6, 2008 5:36 AM, Enrico Scholz > >> wrote: > >> > >>> An initsystem which requires depbloat like python or perl is completely > >>> unacceptably. > >>> > >> Bash is not depbloat, but bash + awk + grep + any other userspace > >> tools shows alot of dep bloat. > >> > > You will want to make yourself familiar with POSIX. > > > > > >> Since python is installed on most > >> machines, > >> > > Only because RH/Fedora's infrastructure forces users to install it. > > > > > >> and almost always putting at least some code in shared > >> memory space, asking for Python in particular is not unreasonable. > >> > > I could not disagree more - To me any init-script system requiring > > anything outside of what POSIX requires is a mis-conception and flawed > > design. > > > > > Is there a reason for this? It still sounds like a whole lot of "PURGE > THE IMPURE!!!" to me. No, it's "slim down a system to what is inevitably necessary" and don't try to fall into the trap of trying to replace one interpreter with another one, which in reality only means to _add_ another one. Ralf From valent.turkovic at gmail.com Wed Jan 9 12:46:03 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 9 Jan 2008 13:46:03 +0100 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <20080109094532.811057b2.mschwendt.tmp0701.nospam@arcor.de> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <20080109094532.811057b2.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <64b14b300801090446u1412557p7bee40aa9922223d@mail.gmail.com> On 1/9/08, Michael Schwendt wrote: > On Wed, 9 Jan 2008 09:20:46 +0100, Valent Turkovic wrote: > > > Hi, > > I saw that Pulse Audio 0.9.8 got released two months ago: > > http://pulseaudio.org/milestone/0.9.8 > > and I see on my Fedora 8 that we still have 0.9.7 > > > > $ pulseaudio --version > > pulseaudio 0.9.7 > > > > Will there be an upgrade soon on Fedora 8 to Pulse Audio 0.9.8? > > > > Lost of issues have been fixed in new Pulse Audio so users like me who > > have issues with Pulse Audio would appreciate the much needed upgrade. > > I'm sure the person who maintains the Fedora packages is aware of that. :) > Just notice the connection between Pulse Audio and Red Hat. I'm sure he is aware of that but I am not - that is why I wrote this email. Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From vpivaini at cs.helsinki.fi Wed Jan 9 13:00:17 2008 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Wed, 9 Jan 2008 15:00:17 +0200 Subject: hunspell dictionaries, what's "missing" In-Reply-To: <1199874135.10609.122.camel@Jehannum> References: <1199874135.10609.122.camel@Jehannum> Message-ID: <200801091500.17934.vpivaini@cs.helsinki.fi> Caolan McNamara kirjoitti: > http://fedoraproject.org/wiki/Releases/FeatureDictionary now lists the > languages for which we ship aspell dictionaries but not hunspell ones. > i.e. ?Breton, Faeroese, Icelandic, Indonesian, Malayalam, Scots Gaelic > and Serbian. > > Packaging those dictionaries will enable OOo to spell-check your > language and have the same level of support in > OOo/evo/gedit/xchat/tomboy/pidgen/KDE (and hopefully firefox > eventually). This is not strictly hunspell related, but I've been working on getting the free Finnish spellchecker and hyphenator Voikko into Fedora, see the thread at and (for some reason the web interface can't handle threads correctly when the month/year changes...) Looking at the FeatureDictionary page, with Voikko we can get direct support for KDE and Gnome, either through the ispell compatibility binary tmispell or Enchant. There is also an OpenOffice extension/plugin(/whatever those are called?) for Voikko at , I'm planning on packaging that as well, though it does look a bit complicated... Firefox and Thunderbird are a bit more difficult. There is a Finnish spellchecking extension for those at . This extension is able to use Voikko (it works well with the libvoikko I maintain in Fedora), but it is distributed with a proprietary spellchecker called Soikko, so it can't go into Fedora. There may be a free software only Voikko extension coming for Firefox 3, the Voikko developers are working on it, but I'm not aware of the exact status of that extension currently. -- Ville-Pekka Vainio From jkeating at redhat.com Wed Jan 9 13:10:41 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 9 Jan 2008 08:10:41 -0500 Subject: Fwd: closing out old bugs of unmaintained releases In-Reply-To: <20080109055037.GD17806@humbolt.us.dell.com> References: <20080104140746.62518306@ghistelwchlohm.scrye.com> <477EA9DA.9040202@gmail.com> <20080104171008.3cc6db16@ghistelwchlohm.scrye.com> <47802400.7030407@gmail.com> <4783D4F1.8040008@redhat.com> <20080108221557.GB19726@nostromo.devel.redhat.com> <20080108221809.GR21294@redhat.com> <20080108172610.0aacf00a@redhat.com> <20080109055037.GD17806@humbolt.us.dell.com> Message-ID: <20080109081041.3bb04c5d@redhat.com> On Tue, 8 Jan 2008 23:50:38 -0600 Michael E Brown wrote: > Benefits of Trac? It seems the case now that most mock users expect to > just enter bugs in bugzilla. The only real benefit is to separate bugs in Fedora versions from bugs in development, or long term tickets for changing things etc.. But it's totally not necessary. In fact, I think we can just do away with the Fedora Hosted Projects product in bugzilla and have all mock bugs just get filed as bugs in a fedora / epel release. The only issue with that is if any other distros start using mock, and forcing them to file Fedora bugs for their mock doesn't seem right. But meh. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dennis at ausil.us Wed Jan 9 13:22:11 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 9 Jan 2008 07:22:11 -0600 Subject: PPC needs lots more stack space in rawhide?? In-Reply-To: <1199873759.4111.414.camel@shinybook.infradead.org> References: <14298.1199827701@sss.pgh.pa.us> <1199873759.4111.414.camel@shinybook.infradead.org> Message-ID: <200801090722.16509.dennis@ausil.us> On Wednesday 09 January 2008, David Woodhouse wrote: > On Tue, 2008-01-08 at 16:28 -0500, Tom Lane wrote: > > I'm having a tough time trying to get mysql rebuilt in rawhide: the ppc > > build keeps failing like this: > > http://koji.fedoraproject.org/koji/getfile?taskID=335275&name=build.log > > > > Normally what a failure in execution_constants means is that the > > configuration constant STACK_MIN_SIZE has to be increased, because the > > error-recovery code needs more stack space than it did before. We have > > for years had to run that a bit higher than what mysql.com ships, but up > > to now 16384 has worked fine across all arches (all 7 redhat arches, > > not just Fedora). Sometime since 13 Dec 2007, however, the behavior > > of the ppc arch changed in rawhide, and now even boosting the number > > by 50% (to 24K) doesn't persuade it to work. I could try larger > > numbers, at the cost of also increasing DEFAULT_THREAD_STACK which > > is a pretty user-visible number. I am wondering if this isn't a bug > > in rawhide, though. Has gcc started making PPC stack frames a lot > > larger than before? Maybe glibc has gotten more stack-hungry? I'd > > guess on the problem being in gettext() or related code, if it is a > > glibc change, but I haven't tracked it down exactly. > > For a while we used 64KiB pages on ppc64, because IBM insisted on it in > RHEL5 and I didn't notice we'd done the same stupid thing in Fedora. I > believe it was like that in FC6 but I fixed it again for F7. > > Is it possible that the kernel on the build machines is now similarly > afflicted? The build system when refreshed in December got updates to RHEL5 so are all running RHEL5 kernels. they do have one extra patch for a bug in tux. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From caolanm at redhat.com Wed Jan 9 13:24:42 2008 From: caolanm at redhat.com (Caolan McNamara) Date: Wed, 09 Jan 2008 13:24:42 +0000 Subject: hunspell dictionaries, what's "missing" In-Reply-To: <200801091500.17934.vpivaini@cs.helsinki.fi> References: <1199874135.10609.122.camel@Jehannum> <200801091500.17934.vpivaini@cs.helsinki.fi> Message-ID: <1199885082.10609.163.camel@Jehannum> On Wed, 2008-01-09 at 15:00 +0200, Ville-Pekka Vainio wrote: > Caolan McNamara kirjoitti: > > http://fedoraproject.org/wiki/Releases/FeatureDictionary now lists the > > languages for which we ship aspell dictionaries but not hunspell ones. > > i.e. ?Breton, Faeroese, Icelandic, Indonesian, Malayalam, Scots Gaelic > > and Serbian. > > > > Packaging those dictionaries will enable OOo to spell-check your > > language and have the same level of support in > > OOo/evo/gedit/xchat/tomboy/pidgen/KDE (and hopefully firefox > > eventually). > > This is not strictly hunspell related, but I've been working on getting the > free Finnish spellchecker and hyphenator Voikko into Fedora, see the thread > at Yeah, I saw that. Unfortunately I'm just not qualified to know what blocks hunspell from supporting Finnish, but I'm surprised that it is the case given that hunspell was written to handle Hungarian which I thought was similarly agglunatively complicated as Finnish. :-( ? > There is also an OpenOffice extension/plugin(/whatever those are > called?) for Voikko at > , > I'm planning on packaging that as well, though it does look a bit > complicated... "extension" is the word of the moment FWIW. wrt. the extensions, follow the scheme at http://fedoraproject.org/wiki/OpenOffice.org for installing it. And I added the required -sdk packages some time ago to enable building the voikko extension, so it should be fairly straightforward to follow the opensuse example for the same package I think. I guess if there's a route to getting Finnish supported in everything then that's fine and doesn't break the spell-checking unification if everything ends up using the same backend for finnish eventually, just seems a pity to have to do it separately for OOo/firefox/enchant. C. From loupgaroublond at gmail.com Wed Jan 9 13:39:47 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 9 Jan 2008 08:39:47 -0500 Subject: Init : someone could comment this ? In-Reply-To: <1199880879.5534.210.camel@beck.corsepiu.local> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <1199638106.6022.88.camel@beck.corsepiu.local> <47812D36.4030309@ncsu.edu> <1199880879.5534.210.camel@beck.corsepiu.local> Message-ID: <7f692fec0801090539y4f8aa894i1ace29ab884aa994@mail.gmail.com> On Jan 9, 2008 7:14 AM, Ralf Corsepius wrote: > > On Sun, 2008-01-06 at 14:34 -0500, Casey Dahlin wrote: > > Ralf Corsepius wrote: > > > I could not disagree more - To me any init-script system requiring > > > anything outside of what POSIX requires is a mis-conception and flawed > > > design. > > > > > > > > Is there a reason for this? It still sounds like a whole lot of "PURGE > > THE IMPURE!!!" to me. > No, it's "slim down a system to what is inevitably necessary" and don't > try to fall into the trap of trying to replace one interpreter with > another one, which in reality only means to _add_ another one. Having spent enough time with religious people, that sounds a lot like the same argument for the same reasons. Well, many religions are different, so YMMV. Don't forget about the other advantages to replacing one interpreter with another. Sh and POSIX give you a certain kind of flexibility which I think is falling out of vogue in many circles because many people don't like embedding several DSL (domain specific languages) into their production code. Switching interpreters lets you pick a language that is more suited to the task, or writing one where there isn't. Also, due to implementation details, it might be easier to optimize one interpreter over another. Knowing very little about the CPython implementation, this argument is probably a stretch. I think it's quite possible to pick a balance between what we need and don't need, and the fun part is going to be making up those requirements, trimming a system down to meet those requirements, and then coding in the startup routines. -Yaakov From vpivaini at cs.helsinki.fi Wed Jan 9 13:50:13 2008 From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio) Date: Wed, 9 Jan 2008 15:50:13 +0200 Subject: hunspell dictionaries, what's "missing" In-Reply-To: <1199885082.10609.163.camel@Jehannum> References: <1199874135.10609.122.camel@Jehannum> <200801091500.17934.vpivaini@cs.helsinki.fi> <1199885082.10609.163.camel@Jehannum> Message-ID: <200801091550.14012.vpivaini@cs.helsinki.fi> Caolan McNamara kirjoitti: > Yeah, I saw that. Unfortunately I'm just not qualified to know what > blocks hunspell from supporting Finnish, but I'm surprised that it is > the case given that hunspell was written to handle Hungarian which I > thought was similarly agglunatively complicated as Finnish. :-( I don't have that much knowledge on the theory of Finnish language or spell checking either, I just pretty much have an itch to scratch here since I'd like to use Voikko with Fedora. I believe the main reason for not using hunspell is suomi-malaga, which I've packaged in Fedora as malaga-suomi-voikko. It is less work for the relatively small number of developers and in some cases it works better than hunspell would. More information is at . > "extension" is the word of the moment FWIW. wrt. the extensions, follow > the scheme at http://fedoraproject.org/wiki/OpenOffice.org for > installing it. And I added the required -sdk packages some time ago to > enable building the voikko extension, so it should be fairly > straightforward to follow the opensuse example for the same package I > think. Thanks for adding the SDK and also for the documentation on the wiki. I'll probably ask for help on this list if I encounter some issues I can't solve myself. -- Ville-Pekka Vainio From alexl at users.sourceforge.net Wed Jan 9 13:56:55 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Wed, 09 Jan 2008 06:56:55 -0700 Subject: Helping out with broken deps due to openssl changes In-Reply-To: <476C0A11.3060009@hhs.nl> (Hans de Goede's message of "Fri\, 21 Dec 2007 19\:46\:41 +0100") References: <476C0A11.3060009@hhs.nl> Message-ID: <9xsl17ayqg.fsf@allele2.eebweb.arizona.edu> >>>>> "HdG" == Hans de Goede writes: HdG> Hi All, I noticed in todays rawhide report that there are still HdG> quite a few packages whcih are broken due to the openssl update. HdG> I know these are the non trivial rebuild cases. I would hereby HdG> like to offer to help. So anyone interested in receiving some HdG> help in getting their package(s) fixed? Seems that as of today's rawhide all the openssl packages have finally been rebuilt, see the broken deps report here: http://koji.fedoraproject.org/mash/rawhide-20080109/logs/depcheck But there are now some non-trivial rebuild cases for the tcl 8.5 soname bump, for example vtk: vtk: https://bugzilla.redhat.com/show_bug.cgi?id=428102 gcl: http://koji.fedoraproject.org/koji/taskinfo?taskID=323688 csound: http://koji.fedoraproject.org/koji/buildinfo?buildID=29975 skencil: http://koji.fedoraproject.org/koji/buildinfo?buildID=30180 Those could do with some attention. ;) Alex From rc040203 at freenet.de Wed Jan 9 14:02:46 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 09 Jan 2008 15:02:46 +0100 Subject: Init : someone could comment this ? In-Reply-To: <7f692fec0801090539y4f8aa894i1ace29ab884aa994@mail.gmail.com> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <1199638106.6022.88.camel@beck.corsepiu.local> <47812D36.4030309@ncsu.edu> <1199880879.5534.210.camel@beck.corsepiu.local> <7f692fec0801090539y4f8aa894i1ace29ab884aa994@mail.gmail.com> Message-ID: <1199887366.5534.267.camel@beck.corsepiu.local> On Wed, 2008-01-09 at 08:39 -0500, Yaakov Nemoy wrote: > On Jan 9, 2008 7:14 AM, Ralf Corsepius wrote: > > > > On Sun, 2008-01-06 at 14:34 -0500, Casey Dahlin wrote: > > > Ralf Corsepius wrote: > > > > I could not disagree more - To me any init-script system requiring > > > > anything outside of what POSIX requires is a mis-conception and flawed > > > > design. > > > > > > > > > > > Is there a reason for this? It still sounds like a whole lot of "PURGE > > > THE IMPURE!!!" to me. > > No, it's "slim down a system to what is inevitably necessary" and don't > > try to fall into the trap of trying to replace one interpreter with > > another one, which in reality only means to _add_ another one. > > Having spent enough time with religious people, that sounds a lot like > the same argument for the same reasons. Well, many religions are > different, so YMMV. This has nothing to do with religion. We are talking about making a system to compliant to official standards. > Don't forget about the other advantages to replacing one interpreter > with another. Sh and POSIX give you a certain kind of flexibility > which I think is falling out of vogue in many circles because many > people don't like embedding several DSL (domain specific languages) > into their production code. Switching interpreters lets you pick a > language that is more suited to the task, or writing one where there > isn't. > > Also, due to implementation details, it might be easier to optimize > one interpreter over another. Knowing very little about the CPython > implementation, this argument is probably a stretch. I really don't care which python or other interpreter you want to add to the inevitable infrastructure and how well accepted and how stable or not it might be. OS history is filled with people having tried to do the same and all of them having gone through quite steep and bumpy learning curves. > I think it's quite possible to pick a balance between what we need and > don't need, and the fun part is going to be making up those > requirements, trimming a system down to meet those requirements, and > then coding in the startup routines. I think you are vastly underestimating the amount of resistance and accusations you can expect from breaking backward compatibility. You might want to check which amount of resistance SuSE devs had been facing on their (comparatively moderate) changes to init-scripts they had introduced several years ago. They already had dynamic sorting of init-scripts deps many years, then. Ralf From vonbrand at inf.utfsm.cl Wed Jan 9 14:06:39 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Wed, 09 Jan 2008 11:06:39 -0300 Subject: Init : someone could comment this ? In-Reply-To: <7f692fec0801090539y4f8aa894i1ace29ab884aa994@mail.gmail.com> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <1199638106.6022.88.camel@beck.corsepiu.local> <47812D36.4030309@ncsu.edu> <1199880879.5534.210.camel@beck.corsepiu.local> <7f692fec0801090539y4f8aa894i1ace29ab884aa994@mail.gmail.com> Message-ID: <200801091406.m09E6dOe013547@laptop13.inf.utfsm.cl> Yaakov Nemoy wrote: [...] > Don't forget about the other advantages to replacing one interpreter > with another. Sh and POSIX give you a certain kind of flexibility > which I think is falling out of vogue in many circles because many > people don't like embedding several DSL (domain specific languages) > into their production code. Switching interpreters lets you pick a > language that is more suited to the task, or writing one where there > isn't. But futzing around with the init of the machine is at most an occasional task for the average sysadmin, and s/he won't like (re)learning the specialized language each time around. The flexibility of being able to change this on the fly, plus a (reasonably) familiar language is a huge plus. Then again, this stuff was designed when machines were booted once a month or so (thus speed didn't matter), hardware (and other) configuration was mostly set in stone, and the machine and its setup was cared for by professionals ("high priests" ;-); today the rage is shutting down/sleeping and then booting/waking up several times a day, plus a huge variety of hotplug devices, and all in the hands of ever less knowledgeable users... In any case, as a one-time user of BSD-style initscripts (one huge script controlled all; to change anything you edited that one, and any typo made your system unbootable...), the SysV style of separate scripts (and predefined runlevels) was a huge step forward. What is missing IMVHO is the ability of handling service dependencies, but that one is very tricky. For example, it mostly makes no sense to run a mail/web/... server if there is no network, but the minority of cases where it does make sense is sizeable nonetheless. And trying to cater for both cases rapidly gets to be an unmanageable mess. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From lesmikesell at gmail.com Wed Jan 9 14:10:45 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 09 Jan 2008 08:10:45 -0600 Subject: Init : someone could comment this ? In-Reply-To: <7f692fec0801090539y4f8aa894i1ace29ab884aa994@mail.gmail.com> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <1199638106.6022.88.camel@beck.corsepiu.local> <47812D36.4030309@ncsu.edu> <1199880879.5534.210.camel@beck.corsepiu.local> <7f692fec0801090539y4f8aa894i1ace29ab884aa994@mail.gmail.com> Message-ID: <4784D5E5.8060201@gmail.com> Yaakov Nemoy wrote: > I think it's quite possible to pick a balance between what we need and > don't need, and the fun part is going to be making up those > requirements, trimming a system down to meet those requirements, and > then coding in the startup routines. Has anyone actually measured the system calls made by init itself and the shells parsing the scripts vs. the things the code it starts does? I wouldn't expect a real-time difference from any change to init other than figuring out what you can run in parallel so delays in (say) sendmail or samba's DNS lookups don't slow down the first login screen. -- Les Mikesell lesmikesell at gmail.com From hhoffman at ip-solutions.net Wed Jan 9 14:37:12 2008 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Wed, 09 Jan 2008 09:37:12 -0500 Subject: Install of FC8 stack trace on Thinkpad T43 Message-ID: <4784DC18.6020606@ip-solutions.net> Hi All, Wondering if anyone has run across this problem: I'm attempting to install FC8 on a IBM Thinkpad T43. The DVD boots just fine, I select to Install (in either GUI or text mode). Various kernel modules are loaded and then the install dies with a stack trace. At first I thought it was a memory issue, so I ran the mem test from the DVD but everything passed. Then I thought that perhaps the DVD was somehow damaged so I ran the test to check the media, that was fine too. Oddly enough FC7 installs without issue. Cheers, Harry From bernie at codewiz.org Wed Jan 9 14:38:53 2008 From: bernie at codewiz.org (Bernardo Innocenti) Date: Wed, 09 Jan 2008 09:38:53 -0500 Subject: ctrlproxy In-Reply-To: <20080108121210.35266172@zod.rchland.ibm.com> References: <4783B191.50104@codewiz.org> <20080108121210.35266172@zod.rchland.ibm.com> Message-ID: <4784DC7D.1050603@codewiz.org> (cc dwmw2, fedora-devel) Josh Boyer wrote: >> I'd like to import the latest version of ctrlproxy because >> 3.0.2 randomly crashes every few days of operation. > > Odd, I've been running it without problems for quite a while. Hmmm... Must be something specific to my configuration, then. I'm thinking x86_64, or the fact that I connect through 2 xchat clients all the time. Or irssi-style logging. >> Additionally, I wrote an initscript to run ctrlproxy >> as a daemon. Would you approve such a change to the package? > > Oh, interesting. I've scratch-built a candidate RPM for you to try: http://koji.fedoraproject.org/koji/taskinfo?taskID=336094 It includes both ctrlproxy-3.0.5 and the daemonization work. I'm also cc'ing dwmw2 because I know he uses ctrlproxy and may like to test this new version. > Could you open a bug in bugzilla and attach a patch there? (Or point > to the SRPM from there.) I'd certainly be interested in the changes. Unfortunately, I could never catch ctrlproxy 3.0.3 crashing when I had enabled coredumps with ulimit. Since I upgraded to 3.0.5, I've not yet seen another crash. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ From snecklifter at gmail.com Wed Jan 9 15:15:09 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Wed, 9 Jan 2008 15:15:09 +0000 Subject: Install of FC8 stack trace on Thinkpad T43 In-Reply-To: <4784DC18.6020606@ip-solutions.net> References: <4784DC18.6020606@ip-solutions.net> Message-ID: <364d303b0801090715t6be460a8j5824279c53dcb2ad@mail.gmail.com> Hi Harry, On 09/01/2008, Harry Hoffman wrote: > Hi All, > > Wondering if anyone has run across this problem: > > I'm attempting to install FC8 on a IBM Thinkpad T43. The DVD boots just > fine, I select to Install (in either GUI or text mode). Various kernel > modules are loaded and then the install dies with a stack trace. > > At first I thought it was a memory issue, so I ran the mem test from the > DVD but everything passed. Then I thought that perhaps the DVD was > somehow damaged so I ran the test to check the media, that was fine too. > > Oddly enough FC7 installs without issue. Fedora-devel isn't really the place for this. Can you bugzilla this and CC me in if you like. Firstly though take a look at: http://fedoraproject.org/wiki/Bugs/F8Common http://fedoraproject.org/wiki/KernelCommonProblems Cheers -- Christopher Brown http://www.chruz.com From tgl at redhat.com Wed Jan 9 16:11:04 2008 From: tgl at redhat.com (Tom Lane) Date: Wed, 09 Jan 2008 11:11:04 -0500 Subject: PPC needs lots more stack space in rawhide?? In-Reply-To: <200801090722.16509.dennis@ausil.us> References: <14298.1199827701@sss.pgh.pa.us> <1199873759.4111.414.camel@shinybook.infradead.org> <200801090722.16509.dennis@ausil.us> Message-ID: <6580.1199895064@sss.pgh.pa.us> Dennis Gilmore writes: > On Wednesday 09 January 2008, David Woodhouse wrote: >> On Tue, 2008-01-08 at 16:28 -0500, Tom Lane wrote: >>> ... Has gcc started making PPC stack frames a lot >>> larger than before? Maybe glibc has gotten more stack-hungry? I'd >>> guess on the problem being in gettext() or related code, if it is a >>> glibc change, but I haven't tracked it down exactly. >> >> For a while we used 64KiB pages on ppc64, because IBM insisted on it in >> RHEL5 and I didn't notice we'd done the same stupid thing in Fedora. I >> believe it was like that in FC6 but I fixed it again for F7. >> >> Is it possible that the kernel on the build machines is now similarly >> afflicted? > The build system when refreshed in December got updates to RHEL5 so are all > running RHEL5 kernels. they do have one extra patch for a bug in tux. Interesting, but would that affect the rate at which userland code consumes stack space? Since posting, I've verified that it still fails at STACK_MIN_SIZE = 48K, which is 300% of the setting that had worked up through mid-December. So *something* has gone pretty seriously wacko, but it's hard to tell what. I guess I shall have to request buildroot access and start poking at it with a debugger ... regards, tom lane From braden at endoframe.com Wed Jan 9 16:16:31 2008 From: braden at endoframe.com (Braden McDaniel) Date: Wed, 09 Jan 2008 11:16:31 -0500 Subject: Check for libgnomeui failing in rawhide Message-ID: <1199895391.5278.161.camel@hinge.endoframe.net> This configure check is failing in rawhide: PKG_CHECK_MODULES([GNOMEUI], [libgnomeui-2.0 libgnome-2.0 >= 2.14], , [have_gnomeui=no]) This is despite the fact that the spec file includes BuildRequires: libgnomeui-devel >= 2.14 This was working as recently as Sunday. Anyone know what changed? -- Braden McDaniel e-mail: Jabber: From hhoffman at ip-solutions.net Wed Jan 9 16:19:37 2008 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Wed, 09 Jan 2008 11:19:37 -0500 Subject: Install of FC8 stack trace on Thinkpad T43 In-Reply-To: <364d303b0801090715t6be460a8j5824279c53dcb2ad@mail.gmail.com> References: <4784DC18.6020606@ip-solutions.net> <364d303b0801090715t6be460a8j5824279c53dcb2ad@mail.gmail.com> Message-ID: <4784F419.9010406@ip-solutions.net> Hi, doh, sorry... that was a fat-finger send on my part. meant to send to the regular fedora list. looking into the respins now, thanks for the heads up! Cheers, Harry Christopher Brown wrote: > Hi Harry, > > On 09/01/2008, Harry Hoffman wrote: >> Hi All, >> >> Wondering if anyone has run across this problem: >> >> I'm attempting to install FC8 on a IBM Thinkpad T43. The DVD boots just >> fine, I select to Install (in either GUI or text mode). Various kernel >> modules are loaded and then the install dies with a stack trace. >> >> At first I thought it was a memory issue, so I ran the mem test from the >> DVD but everything passed. Then I thought that perhaps the DVD was >> somehow damaged so I ran the test to check the media, that was fine too. >> >> Oddly enough FC7 installs without issue. > > Fedora-devel isn't really the place for this. Can you bugzilla this > and CC me in if you like. Firstly though take a look at: > > http://fedoraproject.org/wiki/Bugs/F8Common > http://fedoraproject.org/wiki/KernelCommonProblems > > Cheers > From caolanm at redhat.com Wed Jan 9 16:21:36 2008 From: caolanm at redhat.com (Caolan McNamara) Date: Wed, 09 Jan 2008 16:21:36 +0000 Subject: Check for libgnomeui failing in rawhide In-Reply-To: <1199895391.5278.161.camel@hinge.endoframe.net> References: <1199895391.5278.161.camel@hinge.endoframe.net> Message-ID: <1199895696.10609.182.camel@Jehannum> On Wed, 2008-01-09 at 11:16 -0500, Braden McDaniel wrote: > This configure check is failing in rawhide: > > PKG_CHECK_MODULES([GNOMEUI], [libgnomeui-2.0 libgnome-2.0 >= 2.14], , > [have_gnomeui=no]) > > This is despite the fact that the spec file includes > > BuildRequires: libgnomeui-devel >= 2.14 > > This was working as recently as Sunday. Anyone know what changed? This might be due to a typo in GConf2-devel's /usr/%{_libdir}/pkgconfig/gconf-2.0.pc where it says Requires: glib and not Requires: glib-2.0 this is fixed in GConf-devel 2.21.1-2 and is broken in 2.21.1-1 C. From dwmw2 at infradead.org Wed Jan 9 16:22:43 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 09 Jan 2008 16:22:43 +0000 Subject: PPC needs lots more stack space in rawhide?? In-Reply-To: <6580.1199895064@sss.pgh.pa.us> References: <14298.1199827701@sss.pgh.pa.us> <1199873759.4111.414.camel@shinybook.infradead.org> <200801090722.16509.dennis@ausil.us> <6580.1199895064@sss.pgh.pa.us> Message-ID: <1199895763.2978.79.camel@pmac.infradead.org> On Wed, 2008-01-09 at 11:11 -0500, Tom Lane wrote: > Dennis Gilmore writes: > > On Wednesday 09 January 2008, David Woodhouse wrote: > >> On Tue, 2008-01-08 at 16:28 -0500, Tom Lane wrote: > >>> ... Has gcc started making PPC stack frames a lot > >>> larger than before? Maybe glibc has gotten more stack-hungry? I'd > >>> guess on the problem being in gettext() or related code, if it is a > >>> glibc change, but I haven't tracked it down exactly. > >> > >> For a while we used 64KiB pages on ppc64, because IBM insisted on it in > >> RHEL5 and I didn't notice we'd done the same stupid thing in Fedora. I > >> believe it was like that in FC6 but I fixed it again for F7. > >> > >> Is it possible that the kernel on the build machines is now similarly > >> afflicted? > > > The build system when refreshed in December got updates to RHEL5 so are all > > running RHEL5 kernels. they do have one extra patch for a bug in tux. > > Interesting, but would that affect the rate at which userland code > consumes stack space? It'll certainly affect the way it _allocates_ stack space. > Since posting, I've verified that it still fails at STACK_MIN_SIZE = 48K, That's still less than a single page. Did you try 64KiB or 128KiB? -- dwmw2 From braden at endoframe.com Wed Jan 9 16:43:48 2008 From: braden at endoframe.com (Braden McDaniel) Date: Wed, 09 Jan 2008 11:43:48 -0500 Subject: Check for libgnomeui failing in rawhide In-Reply-To: <1199895696.10609.182.camel@Jehannum> References: <1199895391.5278.161.camel@hinge.endoframe.net> <1199895696.10609.182.camel@Jehannum> Message-ID: <1199897028.5278.166.camel@hinge.endoframe.net> On Wed, 2008-01-09 at 16:21 +0000, Caolan McNamara wrote: > On Wed, 2008-01-09 at 11:16 -0500, Braden McDaniel wrote: > > This configure check is failing in rawhide: > > > > PKG_CHECK_MODULES([GNOMEUI], [libgnomeui-2.0 libgnome-2.0 >= 2.14], , > > [have_gnomeui=no]) > > > > This is despite the fact that the spec file includes > > > > BuildRequires: libgnomeui-devel >= 2.14 > > > > This was working as recently as Sunday. Anyone know what changed? > > This might be due to a typo in > GConf2-devel's /usr/%{_libdir}/pkgconfig/gconf-2.0.pc > where it says Requires: glib and not Requires: glib-2.0 > this is fixed in GConf-devel 2.21.1-2 and is broken in 2.21.1-1 Thanks. I'll wait for that to propagate and try my build again. -- Braden McDaniel e-mail: Jabber: From tgl at redhat.com Wed Jan 9 16:46:23 2008 From: tgl at redhat.com (Tom Lane) Date: Wed, 09 Jan 2008 11:46:23 -0500 Subject: PPC needs lots more stack space in rawhide?? In-Reply-To: <1199895763.2978.79.camel@pmac.infradead.org> References: <14298.1199827701@sss.pgh.pa.us> <1199873759.4111.414.camel@shinybook.infradead.org> <200801090722.16509.dennis@ausil.us> <6580.1199895064@sss.pgh.pa.us> <1199895763.2978.79.camel@pmac.infradead.org> Message-ID: <7199.1199897183@sss.pgh.pa.us> David Woodhouse writes: > On Wed, 2008-01-09 at 11:11 -0500, Tom Lane wrote: >> Interesting, but would that affect the rate at which userland code >> consumes stack space? > It'll certainly affect the way it _allocates_ stack space. >> Since posting, I've verified that it still fails at STACK_MIN_SIZE = 48K, > That's still less than a single page. Did you try 64KiB or 128KiB? I think you're missing the context. The actual requested size of the thread stack is 192K or 256K (and I've also tried 512K, without any better luck). I could see kernel page size affecting the result of that allocation request, but all the values are multiples of 64K already. The problem I'm having is with some code that tries to detect how much stack space has been consumed, and error out if it's too much, where "too much" means the requested stack size minus STACK_MIN_SIZE. So that constant needs to be set large enough to ensure that the error recovery code itself can execute without overflowing the stack and incurring SIGSEGV. My first assumption was that something was using a tad more stack space than before, but given the latest failed test I'm starting to think that something's been broken about the stack-depth-testing logic itself. regards, tom lane From notting at redhat.com Wed Jan 9 16:52:58 2008 From: notting at redhat.com (Bill Nottingham) Date: Wed, 9 Jan 2008 11:52:58 -0500 Subject: Init : someone could comment this ? In-Reply-To: <50837.192.54.193.53.1199868870.squirrel@rousalka.dyndns.org> References: <20080107173508.GA23429@tango.0pointer.de> <4783A57B.2050005@gmail.com> <4783AA97.8090500@gmail.com> <4783D111.80308@gmail.com> <50837.192.54.193.53.1199868870.squirrel@rousalka.dyndns.org> Message-ID: <20080109165258.GD12763@nostromo.devel.redhat.com> Nicolas Mailhot (nicolas.mailhot at laposte.net) said: > > Le Mar 8 janvier 2008 23:45, Ian Burrell a ?crit : > > > I think it is important that we preserve the ability to use sysv-style > > init scripts. They are part of LSB. > > Sort-of. The LSB description is ambiguous, as evidenced by the many > questions posted when we decided to migrate our existing pre-LSB > scripts to the LSB variant. And I'm far from sure that other > distributions answered those questions the same way. Well, they're not ambiguous in that they specify a script or command that accepts certain stop/start/whatever arguments. To put it a different way, the chances of a solution that doesn't at least support SysV scripts in some compatibility way going into RHEL is pretty much zero, at least for the first RHEL release that it would exist in. And (Red Hat hat on), Fedora should generally not try and break its downstream releases too much. Doesn't mean that the system itself should be using this mode for any of its scripts, though. Bill From buildsys at redhat.com Wed Jan 9 16:58:10 2008 From: buildsys at redhat.com (Build System) Date: Wed, 9 Jan 2008 11:58:10 -0500 Subject: rawhide report: 20080109 changes Message-ID: <200801091658.m09GwATQ024553@porkchop.devel.redhat.com> New package PyYAML YAML parser and emitter for Python New package dbxml-perl Perl bindings for Oracle DB XML New package geoqo GeoCaching and General Waypoint Database New package httptunnel Tunnels a data stream in HTTP requests New package kerneloops Tool to automatically collect and submit kernel crash signatures New package kmplayer Video plugin for Konqueror and basic Gstreamer/Xine frontend New package libvirt-cim A CIM provider for libvirt New package mono-basic VisualBasic.NET support for mono Updated Packages: 8Kingdoms-1.1.0-5.fc9 --------------------- * Tue Jan 08 2008 Hans de Goede 1.1.0-5 - Don't call a TclInterpreter from other threads then its created in, this violates Tcl's thread model, this fixes running with Tcl-8.5 CTL-1.4.1-4.fc9 --------------- * Tue Jan 08 2008 kwizart < kwizart at gmail.com > - 1.4.1-4 - Fix gcc43 GConf2-2.21.1-1.fc9 ------------------- * Tue Jan 08 2008 Matthias Clasen - 2.21.1-1 - Update to 2.21.1 - Drop upstreamed patches SDL_mixer-1.2.8-6.fc9 --------------------- * Tue Jan 08 2008 Brian Pepple - 1.2.8-6 - Pulseaudio hack has been moved to SDL. (#427865) anaconda-11.4.0.18-1 -------------------- * Wed Jan 09 2008 Chris Lumens - 11.4.0.18-1 - Fix encrypted autopart traceback. (dlehman) - Allow for better recovery if the CD/DVD is bad. (clumens) - If downloading the updates image fails, prompt for a new location. (clumens) - X now relies on libpciaccess, so add it to our list. (clumens) - Erase temporary packages after installing them on all methods. (clumens) animorph-0.3-2.fc9 ------------------ * Fri Jan 04 2008 kwizart < kwizart at gmail.com > - 0.3-2 - Fix for gcc43 bcfg2-0.9.5.3-1.fc9 ------------------- * Tue Jan 08 2008 Jeffrey C. Ollie - 0.9.5.3-1 - Update to 0.9.5.3 - Package egg-info files. busybox-1:1.9.0-1.fc9 --------------------- * Mon Jan 07 2008 Ivana Varekova - 1:1.9.0-1 - update to 1.9.0 childsplay_plugins-0.90-3.fc9 ----------------------------- * Tue Jan 08 2008 Hans de Goede 0.90-3 - Do not install patch backup (.orig) files (bz 427759) compizconfig-backend-gconf-0.6.0-3.fc9 -------------------------------------- * Tue Jan 08 2008 Mohd Izhar Firdaus Ismail 0.6.0-3 - applied gcc43 buildfix * Thu Oct 25 2007 Mohd Izhar Firdaus Ismail 0.6.0-2 - added Requires compiz-gnome for the gconf schemas createrepo-0.4.11-1.fc9 ----------------------- * Mon Nov 26 2007 Luke Macken - 0.4.11-1 - Update to 0.4.11 - Include COPYING file and change License to GPLv2 * Thu Jun 07 2007 Paul Nasrat - 0.4.10-1 - Update to 0.4.10 * Wed May 16 2007 Paul Nasrat - 0.4.9-1 - Update to 0.4.9 curl-7.17.1-5.fc9 ----------------- * Tue Jan 08 2008 Jindrich Novy 7.17.1-5 - do not attempt to close a bad socket (#427966), thanks to Caolam McNamara ecryptfs-utils-38-0.fc9 ----------------------- * Tue Jan 08 2008 Mike Halcrow 38-0 - Fix passthrough mount option prompt - Clarify man page - Add HMAC option (for future kernel versions) - Bump to version 38 expat-2.0.1-3 ------------- * Tue Jan 08 2008 Joe Orton 2.0.1-3 - chmod 644 the documentation (#427950) file-roller-2.21.1-1.fc9 ------------------------ * Tue Jan 08 2008 - Bastien Nocera - 2.21.1-1 - Update to 2.21.1 - Remove obsolete patch firefox-3.0-0.beta2.8.fc9 ------------------------- * Mon Jan 07 2008 Martin Stransky 3.0-0.beta2.8 - added ssl exception patch (mozbz #411037) flex-2.5.33-13.fc9 ------------------ * Tue Jan 08 2008 Petr Machata - 2.5.33-13 - Patch with -fPIC only after the autogen.sh is run. games-menus-0.3-1.fc9 --------------------- * Tue Jan 08 2008 Hans de Goede 0.3-1 - Make a new 0.3 tarbal with the French translations included, instead of patching the French translation in - Not patching fixes the problem of .orig files being packaged (bz 427863) gchempaint-0.8.5-2.fc9 ---------------------- * Tue Jan 08 2008 Julian Sikorski - 0.8.5-2 - Fixed Savannah bug #21964 - atoms and bonds are not correctly updated git-1.5.3.8-1.fc9 ----------------- * Tue Jan 08 2008 James Bowes 1.5.3.8-1 - git-1.5.3.8 glib2-2.15.1-1.fc9 ------------------ * Tue Jan 08 2008 Matthias Clasen - 2.15.1-1 - 2.15.1 - add new BuildRequires - gmime-2.2.15-1.fc9 ------------------ * Tue Jan 08 2008 - Bastien Nocera - 2.2.15-1 - Update to 2.2.15 gnucap-0.35-3.fc9 ----------------- * Tue Jan 08 2008 Hans de Goede 0.35-3 - Fix building with gcc 4.3 gperf-3.0.3-3.fc9 ----------------- * Tue Jan 08 2008 Florian La Roche - 3.0.3-3 - fix license tag and summary * Tue Aug 21 2007 Florian La Roche - 3.0.3-2 - rebuild * Sun Jun 03 2007 Florian La Roche - 3.0.3-1 - 3.0.3 gtk-doc-1.9-4.fc9 ----------------- * Tue Jan 08 2008 Matthias Clasen - 1.9-4 - Try again gtk2-2.12.4-1.fc9 ----------------- * Tue Jan 08 2008 Matthias Clasen - 2.13.4-1 - Update to 2.12.4 - Drop obsolete patches gtk2-engines-2.13.3-1.fc9 ------------------------- * Tue Jan 08 2008 - Bastien Nocera - 2.13.3-1 - Update to 2.13.3 gvfs-0.1.1-1.fc9 ---------------- hal-0.5.10-4.fc9 ---------------- * Tue Jan 08 2008 David Zeuthen - 0.5.10-4.fc9 - Backport some upstream patches that fixes crashers with fdi files icecream-0.8.0-7.20071101svn.fc9 -------------------------------- * Tue Jan 08 2008 Michal Schmidt - 0.8.0-7.20071101svn - Build fix. meinproc is now in kdelibs3. BuildRequire that instead of kdelibs. jabberd-2.1.21-1.fc9 -------------------- * Tue Jan 08 2008 Adrian Reber - 2.1.21-1 - updated to 2.1.21 * Tue Jan 08 2008 Adrian Reber - 2.1.20-1 - updated to 2.1.20 * Thu Dec 06 2007 Adrian Reber - 2.1.19-1 - updated to 2.1.19 - this version might be config file incompatible to 2.0 in certain cases - for details please refer to the UPGRADE file jabbim-0.3-0.62.20080108svn.fc9 ------------------------------- * Tue Jan 08 2008 Michal Schmidt - 0.3-0.62.20080108svn - Upstream SVN revision 1788. - changes: priority setting, "gone" chatstate, changing nick in MUC. - Compress upstream tarball with bz2. kaider-3.97.0-3.fc9 ------------------- * Wed Dec 12 2007 Kevin Kofler 3.97.0-3 - Patch to fix the documentation directory - Package translations * Wed Dec 12 2007 Kevin Kofler 3.97.0-2 - Add BR gettext * Wed Dec 12 2007 Kevin Kofler 3.97.0-1 - Switch to real release from KDE extragear kbilliards-0.8.7b-6.fc9 ----------------------- * Tue Jan 08 2008 Hans de Goede 0.8.7b-6 - Fix building with gcc 4.3 kdbg-1:2.1.0-1.fc9 ------------------ * Tue Jan 08 2008 Than Ngo 2.1.0-1 - 2.1.0 kdebase-6:3.97.0-5.fc9 ---------------------- * Tue Dec 25 2007 Kevin Kofler 3.97.0-5 - Obsoletes: dolphin, d3lphin, Provides: dolphin (F9+) * Fri Dec 14 2007 Rex Dieter 3.97.0-4 - Obsoletes: -extras (f9+) * Wed Dec 12 2007 Kevin Kofler 3.97.0-3 - rebuild for changed _kde4_includedir kdebase-runtime-3.97.0-1.fc9 ---------------------------- * Wed Dec 05 2007 Rex Dieter 3.97.0-1 - kde-3.97.0 * Tue Dec 04 2007 Rex Dieter 3.96.2-4 - disable kioslave/smb (f9+, samba-3.2.x/gplv3 ickiness) * Sun Dec 02 2007 Kevin Kofler 3.96.2-3 - build without libxcb in F7 as we STILL don't have it (see #373361) kdebase-workspace-3.97.0-5.fc9 ------------------------------ * Mon Dec 31 2007 Kevin Kofler - 3.97.0-5 - fix createGtkrc to set tooltip colors also for GTK+ 2.12+ * Sun Dec 30 2007 Kevin Kofler 3.97.0-4 - Obsoletes: kdmtheme * Mon Dec 17 2007 Rex Dieter 3.97.0-3 - Requires: coreutils dbus-x11 xorg-x11-apps xorg-x11-utils xorg-x11-server-utils (used in startkde) - drop pam configs that were previously moved to kde-settings kdebase3-3.5.8-29.fc9 --------------------- * Tue Jan 08 2008 Rex Dieter - 3.5.8-29 - f9+: omit conflicts w/kdebase-workspace-4.0.0 - f9+: DO_NOT_COMPILE="kappfinder kdesktop klipper kdm kmenuedit kpager kpersonalizer kscreensaver ktip nsplugins" - include %_libdir/libkdeinit_*.* only in main pkg (not -libs or -devel) kdelibs-6:3.97.0-11.fc9 ----------------------- * Fri Jan 04 2008 Kevin Kofler 3.97.0-11 - force Phonon to use the ALSA default device by default * Wed Jan 02 2008 Kevin Kofler 3.97.0-10 - apply patch by Alex Merry to support FLAC 1.1.3+ in FindFlac.cmake * Sat Dec 22 2007 Kevin Kofler 3.97.0-9 - drop BR aspell-devel on F9+, use only enchant (FeatureDictionary) kdepim-6:3.5.8-14.svn20071204.ent.fc9 ------------------------------------- * Tue Jan 08 2008 Rex Dieter 6:3.5.8-14.20071204.ent - omit kpalmdoc.png icons too (f9+) * Fri Dec 28 2007 Kevin Kofler 6:3.5.8-13.20071204.ent - rebuild for new libopensync * Wed Dec 12 2007 Rex Dieter 6:3.5.8-12.20071204.ent - omit crystalsvg icons (f9+) - kdepim_3.5.6.enterprise.0.20071204.744693 kdepimlibs-3.97.0-2.fc9 ----------------------- * Tue Dec 11 2007 Kevin Kofler 3.97.0-2 - rebuild for changed _kde4_includedir * Wed Dec 05 2007 Rex Dieter 3.97.0-1 - kde-3.97.0 * Thu Nov 29 2007 Rex Dieter 3.96.2-1 - kde-3.96.2 kdesdk-3.97.0-8.fc9 ------------------- * Wed Dec 19 2007 Kevin Kofler 3.97.0-8 - update Kompare from SVN (rev 750443) * Sun Dec 16 2007 Kevin Kofler 3.97.0-7 - don't look for libkompare*part.so in %{_kde4_libdir} - don't list D-Bus interfaces twice in file list - build Kompare documentation * Sun Dec 16 2007 Kevin Kofler 3.97.0-6 - update Kompare from SVN (rev 748928) - Kompare now installs unversioned (private) shared libs, package them properly kdeutils-6:4.0.0-1.fc9 ---------------------- * Tue Jan 08 2008 Rex Dieter 6:4.0.0-1 - kde-4.0.0 ksirk-1.7-5.fc9 --------------- * Tue Jan 08 2008 Hans de Goede 1.7-5 - Fix building with gcc 4.3 libchewing-0.3.0-9.fc9 ---------------------- * Tue Jan 08 2008 Caius Chance - 0.3.0-9.devel - Resolves: rhbz#200694 (Moving "Han-Yin" <-> Zhu-Yin" option to AUX UI.) libcompizconfig-0.6.0-4.fc9 --------------------------- * Tue Jan 08 2008 Mohd Izhar Firdaus Ismail 0.6.0-4 - applied gcc43 buildfix libebml-0.7.7-4.fc9 ------------------- * Tue Jan 08 2008 Hans de Goede 0.7.7-4 - Fix building with gcc 4.3 libmtp-0.2.5-1.fc9 ------------------ * Wed Jan 09 2008 Linus Walleij 0.2.5-1 - New upstream release. libselinux-2.0.46-4.fc9 ----------------------- * Tue Jan 08 2008 Dan Walsh - 2.0.46-4 - Add pid_t typemap for swig bindings logwatch-7.3.6-16.fc9 --------------------- * Tue Jan 08 2008 Ivana Varekova 7.3.6-16 - Resolves: #427734 fix amavis script - Resolves: #427761 remove *.orig scripts - Resolves: #230974 add no-oldfiles-log option - remove usage option description - Resolves: #427596 fix mailto setting mhgui-0.2-5.fc9 --------------- * Fri Jan 04 2008 kwizart < kwizart at gmail.com > - 0.2-5 - Another dependency and tested with gcc43 mingetty-1.07-8.fc9 ------------------- * Tue Jan 08 2008 Florian La Roche - 1.07-8 - add sf.net project url - add dist macro to release nautilus-2.21.2-1.fc9 --------------------- * Tue Jan 08 2008 Matthias Clasen - 2.21.2-1 - Update to 2.21.2 * Sun Dec 23 2007 Matthias Clasen - 2.21.1-2 - Fix extensiondir * Fri Dec 21 2007 Matthias Clasen - 2.21.1-1 - Upodate to 2.21.1 ogdi-3.2.0-0.7.beta1.fc9 ------------------------ * Wed Jan 09 2008 Balint Cristian - 3.2.0-0.7.beta1 - fix multilib issue for ogdi-config pam-0.99.8.1-14.fc9 ------------------- * Tue Jan 08 2008 Tomas Mraz 0.99.8.1-14 - support for sha256 and sha512 password hashes - account expiry checks moved to unix_chkpwd helper * Wed Jan 02 2008 Tomas Mraz 0.99.8.1-13 - wildcard match support in pam_tty_audit (by Miloslav Trma??) * Thu Nov 29 2007 Tomas Mraz 0.99.8.1-12 - add pam_tty_audit module (#244352) - written by Miloslav Trma?? perl-Apache-Session-1.85-1.fc9 ------------------------------ * Mon Jan 07 2008 Steven Pritchard 1.85-1 - Update to 1.85. - BR Test::Pod. * Mon Oct 15 2007 Steven Pritchard 1.84-1 - Update to 1.84. - License changed to GPL+ or Artistic. - Package Contributing.txt doc. * Mon May 28 2007 Steven Pritchard 1.83-1 - Update to 1.83. perl-CGI-Ajax-0.701-3.fc9 ------------------------- perl-File-Fetch-0.14-1.fc9 -------------------------- * Mon Jan 07 2008 Steven Pritchard 0.14-1 - Update to 0.14. perl-Kwiki-ModPerl-0.09-5.fc9 ----------------------------- * Wed Jan 09 2008 Ralf Cors??pius 0.09-5 - Update License-tag. - BR: perl(Test::More) (BZ 419631). plplot-5.8.0-7.fc9 ------------------ * Mon Jan 07 2008 - Orion Poplawski - 5.8.0-7 - Update to latest svn for Tcl 8.5 support - Don't build against itcl - does not support tcl 8.5 * Thu Jan 03 2008 Alex Lancaster - 5.8.0-6 - Rebuild for new Tcl 8.5 pm-utils-0.99.4-13.fc9 ---------------------- * Wed Jan 09 2008 Till Maas - 0.99.4-13 - update README to describe the current beheaviour of pm-utils * Tue Jan 08 2008 Till Maas - 0.99.4-12 - remove ExclusiveArch, because it contains all supported archs (in case an arch schould be excluded, please use ExcludeArch) - improve readability of usermode setup - remove pm-restart pm-shutdown from usermode setup, because there are no such binaries - list more files in %files explicit to make it obvious when there are changes in the distributed package - add .conf suffix to oldconfig files * Tue Jan 08 2008 Till Maas - 0.99.4-11 - make it possible to specify the hibernate mode (RH #375701) policycoreutils-2.0.34-7.fc9 ---------------------------- * Tue Jan 08 2008 Dan Walsh 2.0.34-7 - Fix fixfiles to handle no args purple-plugin_pack-2.2.0-4.fc9 ------------------------------ * Tue Jan 08 2008 Ignacio Vazquez-Abrams 2.2.0-4 - Switch from aspell to enchant (#427949) qemu-0.9.1-1.fc9 ---------------- * Tue Jan 08 2008 Daniel P. Berrange - 0.9.1-1.fc9 - Updated to 0.9.1 release - Fix license tag syntax - Don't mark init script as a config file * Wed Sep 26 2007 Daniel P. Berrange - 0.9.0-5.fc8 - Fix rtl8139 checksum calculation for Vista (rhbz #308201) * Tue Aug 28 2007 Daniel P. Berrange - 0.9.0-4.fc8 - Fix debuginfo by passing -Wl,--build-id to linker qimageblitz-0.0.4-0.3.svn706674.fc9 ----------------------------------- qtparted-0.4.5-17.fc9 --------------------- * Tue Jan 08 2008 Steven Pritchard 0.4.5-17 - Don't include NTFS support on ppc/ppc64 (#407151). - BR e2fsprogs. - Explicitly require ntfsprogs, just to be safe. * Thu Jan 03 2008 Steven Pritchard 0.4.5-16 - Update License. - Load /etc/profile.d/qt.sh to get PATH right. rarian-0.7.1-1.fc9 ------------------ * Tue Jan 08 2008 - Bastien Nocera - 0.7.1-1 - Update to 0.7.1 scim-chewing-0.3.1-12.fc9 ------------------------- * Tue Jan 08 2008 Caius Chance 0.3.1-12.fc9 - Updated buildrequires version of libchewing-devel to 0.3.0-9. * Tue Jan 08 2008 Caius Chance 0.3.1-11.fc9 - Resolves: rhbz#200694 (Moving "Han-Yin" <-> Zhu-Yin" option to AUX UI.) scim-python-0.1.9-1.fc9 ----------------------- * Tue Jan 08 2008 Huang Peng - 0.1.8-1 - Add post script to create indexes in pinyin phrase database. - Update to 0.1.9. scim-sinhala-0.2.0-5.fc9 ------------------------ * Tue Jan 08 2008 Pravin Satpute - 0.2.0-5.fc9 - removed preedit for unneccessary characters(#217065) - modified scim-sinhala-preedit-217065.patch seamonkey-1.1.7-4.fc9 --------------------- * Mon Jan 07 2008 Kai Engert - 1.1.7-4 - Create and own /etc/skel/.mozilla selinux-policy-3.2.5-9.fc9 -------------------------- * Mon Jan 07 2008 Dan Walsh 3.2.5-9 - Update gpg to allow reading of inotify smolt-1.0-4.fc9 --------------- * Tue Jan 08 2008 Mike McGrath 1.0-4 - Fixed firstboot * Tue Jan 08 2008 Mike McGrath 1.0-3 - Added python-urlgrabber as a requires - 427969 soprano-1.98.0-1.fc9 -------------------- * Sun Dec 02 2007 Kevin Kofler 1.98.0-1 - soprano-1.98.0 (soprano 2 rc 1) - update glibc/open patch * Sat Nov 10 2007 Rex Dieter 1.97.1-2 - glibc/open patch * Sat Nov 10 2007 Rex Dieter 1.97.1-1 - soprano-1.97.1 (soprano 2 beta 4) sound-juicer-2.21.1-1.fc9 ------------------------- * Tue Jan 08 2008 - Bastien Nocera - 2.21.1-1 - Update to 2.21.1 sqlite-3.5.4-2.fc9 ------------------ * Tue Jan 08 2008 Panu Matilainen - 3.5.4-2 - avoid packaging CVS directory as documentation (#427755) stormbaancoureur-2.0.2-1.fc9 ---------------------------- * Sun Jan 06 2008 Hans de Goede 2.0.2-1 - new upstream release 2.0.2 - drop most patches (upstreamed) - better sound error messages in an attempt to debug bz 427592 * Fri Jan 04 2008 Hans de Goede 2.0.0-2 - Fix compilation with gcc-4.3 - Fix running with the nvidea-legacy drivers, patch by Alexis de Ruelle t1lib-5.1.1-7.fc9 ----------------- * Tue Jan 08 2008 Patrice Dumas - 5.1.1-7 - add X libs BuildRequires (#353861) * Tue Jan 08 2008 Patrice Dumas - 5.1.1-6 - apply debian patch - use debian patches directly tcl-1:8.5.0-5.fc9 ----------------- * Tue Jan 08 2008 Marcela Maslanova - 1:8.5.0-5 - stack checking is ok, error is in application. Removing withouth stack. - tcl-8.5.0-hidden.patch isn't ok, fix should be in expect. In the meantime the patch stay here. * Mon Jan 07 2008 Marcela Maslanova - 1:8.5.0-4 - add patch from atkac at redhat dot com - fix linking with hidden objects * Sat Jan 05 2008 Wart - 1:8.5.0-3 - Obsolete the tcl-tcldict package that has been incorporated into the main Tcl source code. - Disable the the stack checking code; it makes assumptions that are not necessarily true on Fedora and causes some apps to fail (BZ #425799) tcltls-1.5.0-14.fc9 ------------------- * Tue Jan 08 2008 Sander Hoentjen - 1.5.0-14 - disable make test for the moment * Sat Jan 05 2008 Sander Hoentjen - 1.5.0-13 - update for tcl 8.5 telepathy-salut-0.2.1-1.fc9 --------------------------- * Tue Jan 08 2008 Brian Pepple - 0.2.1-1 - Update to 0.2.1. time-1.7-31.fc9 --------------- * Tue Jan 08 2008 Florian La Roche - 1.7-31 - update url/license tags * Tue Aug 21 2007 Florian La Roche - 1.7-30 - rebuild * Tue Feb 27 2007 Karsten Hopp 1.7-29 - remove trailing dot from summary - replace tabs with spaces - replace PreReq with Requires(post)/Requires(preun) - include license file in %doc - add smp flags - use make install DESTDIR= udev-118-1.fc9 -------------- * Tue Jan 08 2008 Harald Hoyer 118-1 - version 118 - removed old USB compat rule (rhbz#424331) - disabled static version urw-fonts-2.4-2.fc9 ------------------- * Tue Jan 08 2008 Than Ngo 2.4-2 - update to 1.0.7pre44 - fix #426245, removes two broken lines (two invalid glyph names) * Fri Aug 10 2007 Than Ngo - 2.4-1 - update to 1.0.7pre43, changed Roman glyphs in all fonts back to original metrics. bz#243180, bz#138896, bz#140584 - cleanup BR, bz#227297 - drop chkfontpath dependency and use the catalogue font path mechanism * Wed Jul 12 2006 Jesse Keating - 2.3-6.1.1 - rebuild vte-0.16.12-1.fc9 ----------------- * Tue Jan 08 2008 Matthias Clasen - 0.16.12-1 - Update to 0.16.12 wordtrans-1:1.1-0.3.pre13.fc9 ----------------------------- * Tue Jan 08 2008 Than Ngo 1.1-0.3.pre13 - BR kdelib3-devel xferstats-2.16-16.fc9 --------------------- * Tue Jan 08 2008 Than Ngo 2.16-16 - rebuilt * Thu Oct 18 2007 2.16-15 Than Ngo 2.16-15 - rebuild xorg-x11-drv-vesa-1.3.0-12.20071113.fc9 --------------------------------------- * Tue Jan 08 2008 Adam Jackson 1.3.0-12.20071113 - Rebuild for new ABI. xorg-x11-server-1.4.99.1-0.15.20080107.fc9 ------------------------------------------ * Mon Jan 07 2008 Adam Jackson 1.4.99.1-0.15 - Today's git snapshot. X-SELinux! - Drop the code to migrate from /etc/X11/XF86Config*. - s/perl -p -i -e/sed -i/g xulrunner-1.9-0.beta2.7.fc9 --------------------------- * Mon Jan 07 2008 Martin Stransky 1.9-0.beta2.7 - removed fedora specific pkg-config files - updated to the latest trunk (2008-01-07) - removed unnecessary patches - fixed idl dir (#427965) ypserv-2.19-7.fc9 ----------------- * Tue Jan 08 2008 Steve Dickson 2.19-7 - Changed Makefiles.in so binaries are not stripped. yum-metadata-parser-1.1.2-4.fc9 ------------------------------- * Tue Jan 08 2008 James Bowes 1.1.2-4 - egg-info is under the arch specific dir * Tue Jan 08 2008 James Bowes 1.1.2-3 - Include the egg-info dir. Broken deps for i386 ---------------------------------------------------------- csound-tk - 5.03.0-13.fc7.i386 requires libtk8.4.so csound-tk - 5.03.0-13.fc7.i386 requires libtcl8.4.so epiphany-extensions - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.i386 requires libgtkembedmoz.so gcl - 2.6.7-15.fc8.i386 requires libtcl8.4.so gcl - 2.6.7-15.fc8.i386 requires libtk8.4.so gnome-web-photo - 0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.i386 requires libgtkembedmoz.so irsim - 9.7.50-1.fc8.i386 requires libtcl8.4.so irsim - 9.7.50-1.fc8.i386 requires libtk8.4.so kazehakase - 0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 kdeutils - 6:4.0.0-1.fc9.i386 requires kdelibs4 >= 0:4.0.0 kdeutils - 6:4.0.0-1.fc9.i386 requires kdeutils-libs = 6:4.0.0-1.fc9 libopensync-plugin-sunbird - 0.22-3.fc8.i386 requires libopensync.so.0 libopensync-plugin-synce - 0.22-4.fc8.i386 requires libopensync.so.0 magic - 7.4.35-6.fc8.i386 requires libtcl8.4.so magic - 7.4.35-6.fc8.i386 requires libtk8.4.so multisync - 0.91.0-3.fc8.i386 requires libopensync.so.0 multisync - 0.91.0-3.fc8.i386 requires libosengine.so.0 multisync-gui - 0.91.0-3.fc8.i386 requires libopensync.so.0 multisync-gui - 0.91.0-3.fc8.i386 requires libosengine.so.0 netgen - 1.3.7-13.fc9.i386 requires libtcl8.4.so netgen - 1.3.7-13.fc9.i386 requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.i386 requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.i386 requires libtcl8.4.so sepostgresql - 8.2.5-1.66.fc9.i386 requires postgresql-server = 0:8.2.5 skencil - 0.6.17-15.20070606svn.fc8.i386 requires libtk8.4.so skencil - 0.6.17-15.20070606svn.fc8.i386 requires libtcl8.4.so tcl-tcldict - 8.5.2-2.fc8.i386 requires tcl(abi) = 0:8.4 vtk - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtcl8.4.so Broken deps for x86_64 ---------------------------------------------------------- csound-tk - 5.03.0-13.fc7.x86_64 requires libtk8.4.so()(64bit) csound-tk - 5.03.0-13.fc7.x86_64 requires libtcl8.4.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gcl - 2.6.7-15.fc8.x86_64 requires libtk8.4.so()(64bit) gcl - 2.6.7-15.fc8.x86_64 requires libtcl8.4.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) kazehakase - 0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 kdeutils - 6:4.0.0-1.fc9.i386 requires kdelibs4 >= 0:4.0.0 kdeutils - 6:4.0.0-1.fc9.i386 requires kdeutils-libs = 6:4.0.0-1.fc9 kdeutils - 6:4.0.0-1.fc9.x86_64 requires kdelibs4 >= 0:4.0.0 kdeutils - 6:4.0.0-1.fc9.x86_64 requires kdeutils-libs = 6:4.0.0-1.fc9 libopensync-plugin-sunbird - 0.22-3.fc8.x86_64 requires libopensync.so.0()(64bit) libopensync-plugin-synce - 0.22-4.fc8.x86_64 requires libopensync.so.0()(64bit) magic - 7.4.35-6.fc8.x86_64 requires libtk8.4.so()(64bit) magic - 7.4.35-6.fc8.x86_64 requires libtcl8.4.so()(64bit) multisync - 0.91.0-3.fc8.x86_64 requires libosengine.so.0()(64bit) multisync - 0.91.0-3.fc8.x86_64 requires libopensync.so.0()(64bit) multisync-gui - 0.91.0-3.fc8.x86_64 requires libopensync.so.0()(64bit) multisync-gui - 0.91.0-3.fc8.x86_64 requires libosengine.so.0()(64bit) netgen - 1.3.7-13.fc9.x86_64 requires libtk8.4.so()(64bit) netgen - 1.3.7-13.fc9.x86_64 requires libtcl8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.x86_64 requires libtk8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.x86_64 requires libtcl8.4.so()(64bit) sepostgresql - 8.2.5-1.66.fc9.x86_64 requires postgresql-server = 0:8.2.5 skencil - 0.6.17-15.20070606svn.fc8.x86_64 requires libtcl8.4.so()(64bit) skencil - 0.6.17-15.20070606svn.fc8.x86_64 requires libtk8.4.so()(64bit) tcl-tcldict - 8.5.2-2.fc8.x86_64 requires tcl(abi) = 0:8.4 vtk - 5.0.3-20.fc8.x86_64 requires libtk8.4.so()(64bit) vtk - 5.0.3-20.fc8.x86_64 requires libtcl8.4.so()(64bit) vtk - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-python - 5.0.3-20.fc8.x86_64 requires libtk8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.x86_64 requires libtcl8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.x86_64 requires libtk8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.x86_64 requires libtcl8.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- csound-tk - 5.03.0-13.fc7.ppc requires libtcl8.4.so csound-tk - 5.03.0-13.fc7.ppc requires libtk8.4.so epiphany-extensions - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc requires libgtkembedmoz.so gnome-web-photo - 0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.ppc requires libgtkembedmoz.so irsim - 9.7.50-1.fc8.ppc requires libtcl8.4.so irsim - 9.7.50-1.fc8.ppc requires libtk8.4.so kazehakase - 0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 kdeutils - 6:4.0.0-1.fc9.ppc64 requires kdelibs4 >= 0:4.0.0 kdeutils - 6:4.0.0-1.fc9.ppc64 requires kdeutils-libs = 6:4.0.0-1.fc9 kdeutils - 6:4.0.0-1.fc9.ppc requires kdelibs4 >= 0:4.0.0 kdeutils - 6:4.0.0-1.fc9.ppc requires kdeutils-libs = 6:4.0.0-1.fc9 libopensync-plugin-sunbird - 0.22-3.fc8.ppc requires libopensync.so.0 libopensync-plugin-synce - 0.22-4.fc8.ppc requires libopensync.so.0 magic - 7.4.35-6.fc8.ppc requires libtcl8.4.so magic - 7.4.35-6.fc8.ppc requires libtk8.4.so monodevelop - 0.17-4.fc9.ppc requires boo multisync - 0.91.0-3.fc8.ppc requires libopensync.so.0 multisync - 0.91.0-3.fc8.ppc requires libosengine.so.0 multisync-gui - 0.91.0-3.fc8.ppc requires libopensync.so.0 multisync-gui - 0.91.0-3.fc8.ppc requires libosengine.so.0 netgen - 1.3.7-13.fc9.ppc requires libtcl8.4.so netgen - 1.3.7-13.fc9.ppc requires libtk8.4.so pvm-gui - 3.4.5-7.fc6.1.ppc requires libtcl8.4.so pvm-gui - 3.4.5-7.fc6.1.ppc requires libtk8.4.so sepostgresql - 8.2.5-1.66.fc9.ppc requires postgresql-server = 0:8.2.5 skencil - 0.6.17-15.20070606svn.fc8.ppc requires libtk8.4.so skencil - 0.6.17-15.20070606svn.fc8.ppc requires libtcl8.4.so tcl-tcldict - 8.5.2-2.fc8.ppc requires tcl(abi) = 0:8.4 vtk - 5.0.3-20.fc8.ppc requires libtk8.4.so vtk - 5.0.3-20.fc8.ppc requires libtcl8.4.so vtk - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc requires libtk8.4.so vtk-python - 5.0.3-20.fc8.ppc requires libtcl8.4.so vtk-python - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc requires libtk8.4.so vtk-tcl - 5.0.3-20.fc8.ppc requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) Broken deps for ppc64 ---------------------------------------------------------- csound-tk - 5.03.0-13.fc7.ppc64 requires libtk8.4.so()(64bit) csound-tk - 5.03.0-13.fc7.ppc64 requires libtcl8.4.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 epiphany-extensions - 2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) kazehakase - 0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 kdeutils - 6:4.0.0-1.fc9.ppc64 requires kdelibs4 >= 0:4.0.0 kdeutils - 6:4.0.0-1.fc9.ppc64 requires kdeutils-libs = 6:4.0.0-1.fc9 libopensync-plugin-sunbird - 0.22-3.fc8.ppc64 requires libopensync.so.0()(64bit) libopensync-plugin-synce - 0.22-4.fc8.ppc64 requires libopensync.so.0()(64bit) magic - 7.4.35-6.fc8.ppc64 requires libtk8.4.so()(64bit) magic - 7.4.35-6.fc8.ppc64 requires libtcl8.4.so()(64bit) multisync - 0.91.0-3.fc8.ppc64 requires libosengine.so.0()(64bit) multisync - 0.91.0-3.fc8.ppc64 requires libopensync.so.0()(64bit) multisync-gui - 0.91.0-3.fc8.ppc64 requires libopensync.so.0()(64bit) multisync-gui - 0.91.0-3.fc8.ppc64 requires libosengine.so.0()(64bit) netgen - 1.3.7-13.fc9.ppc64 requires libtk8.4.so()(64bit) netgen - 1.3.7-13.fc9.ppc64 requires libtcl8.4.so()(64bit) perl-Test-AutoBuild-darcs - 1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 perl-Text-RecordParser - v1.2.1-3.fc7.noarch requires perl(Text::TabularDisplay) pvm-gui - 3.4.5-7.fc6.1.ppc64 requires libtk8.4.so()(64bit) pvm-gui - 3.4.5-7.fc6.1.ppc64 requires libtcl8.4.so()(64bit) sepostgresql - 8.2.5-1.66.fc9.ppc64 requires postgresql-server = 0:8.2.5 skencil - 0.6.17-15.20070606svn.fc8.ppc64 requires libtcl8.4.so()(64bit) skencil - 0.6.17-15.20070606svn.fc8.ppc64 requires libtk8.4.so()(64bit) tcl-tcldict - 8.5.2-2.fc8.ppc64 requires tcl(abi) = 0:8.4 vtk - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) From rdieter at math.unl.edu Wed Jan 9 17:33:27 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 09 Jan 2008 11:33:27 -0600 Subject: rawhide report: 20080109 changes References: <200801091658.m09GwATQ024553@porkchop.devel.redhat.com> Message-ID: Build System wrote: > kdeutils-6:4.0.0-1.fc9 > ---------------------- > * Tue Jan 08 2008 Rex Dieter 6:4.0.0-1 > - kde-4.0.0 oops, (jedi mind trick mode...) you didn't see this, move on, nothing to see here (untagged). -- Rex From j.w.r.degoede at hhs.nl Wed Jan 9 18:45:18 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 09 Jan 2008 19:45:18 +0100 Subject: Fedora too cutting edge? Message-ID: <4785163E.8010508@hhs.nl> Hi All, One of the few reasons why Fedora is my distro of choice is because its usually cutting edge, and I like to be where the development is happening. However today I've had an encounter with Fedora which make me wonder if sometimes we aren't a little too cutting edge. I tried to get an industrial firewire camera to work with the stock Fedora kernel using the juju stack. Long story short, it didn't work. Which after reading: http://wiki.linux1394.org/JujuMigration Isn't really surprising, quoting that page: "Almost no support for IIDC cameras: Not compatible with libdc1394 v1. Highly experimental support in libdc1394 v2 which works with some luck on only a few OHCI 1.1 controllers. Improvements are to be expected in Linux 2.6.25-rc1." Notice how a preliminary fix is expected for 2.6.25, which probably means that this will still be broken in Fedora 9, notice that the breakage was introduced in Fedora 7, so thats 18 months worth of broken firewire camera support (iow most digital video cameras). Add to that that the above referenced wiki page also says: "Regarding Linux 2.6.22 and 2.6.23, the best advice to Linux distributors (kernel packagers) ... is: Build only the old IEEE 1394 drivers." Does this mean that Fedora should not have shipped the new stack? No it doesn't! Getting code out there early into many hands for testing is a good thing. What IMHO we should have done is build both the new and the oldstack, which is possible on the kernel side, and modify our patches to userspace to support the juju stack, so that the userspace libs can work with either one. On top of this we should then have written a small gui utility for easy switching. --- Another example of Fedora being to cutting edge is pulseaudio, for prove click this URL: https://bugzilla.redhat.com/buglist.cgi?product=Fedora&version=&component=pulseaudio&bug_status=NEW&bug_status=ASSIGNED&bug_status=NEEDINFO&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=FAILS_QA&bug_status=POST&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc= Again I think its good to be shipping this, and even that its good having it on by default, but we should also provide a small gui utility for easily turning ir off. --- Considering the current state of affairs with regards to both features, I would even like to advocate to make them both optional for Fedora 9. Regards, Hans p.s. I'll also be posting this to my blog for some wider exposure. From bkoz at redhat.com Wed Jan 9 19:01:23 2008 From: bkoz at redhat.com (Benjamin Kosnik) Date: Wed, 9 Jan 2008 13:01:23 -0600 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080103095755.51bb7cb1@wabash.artheist.org> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <20080103123725.GA20451@devserv.devel.redhat.com> <20080103095755.51bb7cb1@wabash.artheist.org> Message-ID: <20080109130123.5fdc7d65@wabash.artheist.org> > I'm most interested in Pre-ISO header issues, and the dep streamlining > fallout. This part seems to be actually pretty minor, which is > encouraging to me. More formal analysis of the header dep fails: 7 fails for iostream.h 1 fail for fstream.h The rest of these pre-iso.h removals have no impact. I see vector.h stream.h hash_map.h Already being dealt with at the (auto) conf level (although usage of these is minor, at one each). I'll work on fixing up the above 8 errors. I see the libsigc++ and boost fallout for the name lookup changes as impacting a lot of packages filed as header dep: I'll work on fixing these two up first and then the rest of the issues will become much easier to see. > I'm going to organize some of your build info (esp changed > warning/errors in compilation) with some data I have from Debian, and > put it up on the gcc website in the form of a Porting to gcc-4.3 wiki > page. I will send link as soon as it's up. This is temporarily at: http://people.redhat.com/~bkoz/porting_to_gcc43.html While I wait for approval to put it http://gcc.gnu.org/gcc-4.3/porting_to.html -benjamin From ajackson at redhat.com Wed Jan 9 19:29:29 2008 From: ajackson at redhat.com (Adam Jackson) Date: Wed, 09 Jan 2008 14:29:29 -0500 Subject: Impending X driver deprecation Message-ID: <1199906969.15130.40.camel@localhost.localdomain> I'm grinding through porting the various X drivers to the new server APIs, and I'm taking the opportunity to clean house a bit. Here's what I'm planning: The avivo driver is going away, it's a dead end upstream, both the radeon-atombios and radeonhd projects look significantly more viable. I don't have a plan yet for which one to enable for F9 though. The vga driver is going away. It hasn't been installed by default since F7, and no one seems to have noticed, let alone complained. It's not a usable driver anyway, it can't do greater than 8bpp and Gnome won't even launch on that anymore. The ark, chips, s3, and tseng drivers are going away. These are all really boring early PCI chipsets that don't even have a 3d engine. They should be adequately serviced by the vesa driver. (Note that there are three drivers for the various S3 cards: s3, s3virge, and savage. s3 is for the old pre-Virge chips, 968 and Trio and friends. s3virge and savage are not being dropped.) The vesa driver will be updated to Obsolete these drivers (except avivo) and sufficient magic will happen to get anyone still using them silently moved onto vesa. Whichever of radeon or radeonhd we end up using for R500+ chips will Obsolete avivo. If you object to any part of this plan, speak loudly, now. - ajax From fedora at leemhuis.info Wed Jan 9 19:22:01 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 09 Jan 2008 20:22:01 +0100 Subject: Fedora too cutting edge? In-Reply-To: <4785163E.8010508@hhs.nl> References: <4785163E.8010508@hhs.nl> Message-ID: <47851ED9.2000800@leemhuis.info> On 09.01.2008 19:45, Hans de Goede wrote: > One of the few reasons why Fedora is my distro of choice is because its usually > cutting edge, and I like to be where the development is happening. +1 > However today I've had an encounter with Fedora which make me wonder if > sometimes we aren't a little too cutting edge. See below. But actually I think we here and there are not even cutting edge enough; we for example left users on Firefox2 for FC6 for about 7 months until we shipped F7 -- that looked totally odd for a distribution that is curring edge in most other areas. Another example: hplip is still on 2.7.7 for F8 right now while upstream is at 2.7.12 in between and supports 22 new printers ( http://hplip.sourceforge.net/release_notes.html ). We don't provide any solutions for users that buy those printers right now besides using rawhide. Thus they have to wait/ask for a proper update or wait until F9 or -- the latter means waiting about 6 months for driver. That's IMHO unacceptable -- especially as printer manufacturers release successor models quite often (it feels to me like a new successor model get released in each printer class about once a year, but I didn't check). > I tried to get an industrial > firewire camera to work with the stock Fedora kernel using the juju stack. Long > [...] > story short, it didn't work. > > Does this mean that Fedora should not have shipped the new stack? No it > doesn't! Getting code out there early into many hands for testing is a good thing. +1 > What IMHO we should have done is build both the new and the oldstack, which is > possible on the kernel side, and modify our patches to userspace to support the > juju stack, so that the userspace libs can work with either one. On top of this > we should then have written a small gui utility for easy switching. That's what I call "Fedora knows better then you". It's afaics not the first time Fedora forces users to use a new technology instead of giving them a choice for a small period. For example there are still users that would like to use the ntfs-module from the kernel, but we don't enable it (making ntfs-3g the default and eabling ntfs in the kernel should solve this problem). Another example: Xgl never made it into the Fedora repos (which in parts is due to packaging problems, but it looks a bit odd). Another example: Zope/Plone was excluded in F7 and later because we jumped to python 2.5 but didn't want to ship a compat-python package (this + Zope/Plone are now in livna for F7 and soon F8 and devel). > Another example of Fedora being to cutting edge is pulseaudio, [...] Not sure about pulseaudio -- works well for me afaics. But yeah, might be a similar issue. Linux is about choice. Just my 2 cent. Cu knurd From loupgaroublond at gmail.com Wed Jan 9 19:31:41 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 9 Jan 2008 14:31:41 -0500 Subject: Fedora too cutting edge? In-Reply-To: <4785163E.8010508@hhs.nl> References: <4785163E.8010508@hhs.nl> Message-ID: <7f692fec0801091131n272588bbp28ba11dd4bb3b45c@mail.gmail.com> On Jan 9, 2008 1:45 PM, Hans de Goede wrote: > Does this mean that Fedora should not have shipped the new stack? No it > doesn't! Getting code out there early into many hands for testing is a good thing. > > What IMHO we should have done is build both the new and the oldstack, which is > possible on the kernel side, and modify our patches to userspace to support the > juju stack, so that the userspace libs can work with either one. On top of this > we should then have written a small gui utility for easy switching. Supporting two versions of anything, especially on the same system is much harder than it looks. The people in charge have to make sure that the old version still works, even if it's unmaintained upstream, the new version works somewhat, so it doesn't completely suck, the userspace stack surrounding kernel bits has to work equally as well, so that the transition is smooth, the interoperability between the new/old components and the rest of the system is equal, etc... Then they have to worry about security advisories on both components, managing two packages where there could be one, propagating static materials twice, like documentation and configuration details, writing documentation on how to switch back and forth for those butterflies that are interested in making things work well, etc... All in all, it takes alot more manpower than what's available right now. -Yaakov From j.w.r.degoede at hhs.nl Wed Jan 9 19:45:23 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 09 Jan 2008 20:45:23 +0100 Subject: Fedora too cutting edge? In-Reply-To: <7f692fec0801091131n272588bbp28ba11dd4bb3b45c@mail.gmail.com> References: <4785163E.8010508@hhs.nl> <7f692fec0801091131n272588bbp28ba11dd4bb3b45c@mail.gmail.com> Message-ID: <47852453.3050702@hhs.nl> Yaakov Nemoy wrote: > On Jan 9, 2008 1:45 PM, Hans de Goede wrote: >> Does this mean that Fedora should not have shipped the new stack? No it >> doesn't! Getting code out there early into many hands for testing is a good thing. >> >> What IMHO we should have done is build both the new and the oldstack, which is >> possible on the kernel side, and modify our patches to userspace to support the >> juju stack, so that the userspace libs can work with either one. On top of this >> we should then have written a small gui utility for easy switching. > > Supporting two versions of anything, especially on the same system is > much harder than it looks. The people in charge have to make sure > that the old version still works, even if it's unmaintained upstream, > the new version works somewhat, so it doesn't completely suck, the > userspace stack surrounding kernel bits has to work equally as well, > so that the transition is smooth, the interoperability between the > new/old components and the rest of the system is equal, etc... > > Then they have to worry about security advisories on both components, > managing two packages where there could be one, propagating static > materials twice, like documentation and configuration details, writing > documentation on how to switch back and forth for those butterflies > that are interested in making things work well, etc... > > All in all, it takes alot more manpower than what's available right now. > You are talkin in generivs, where as this are 2 very specific cases, in both cases I gave the alternative is still actively maintained upstream. In the case of firewire, the alternative is even the preferred choice of upstream, in the case of pulseaudio, pa lies on top of alsa, the alternative, so surely we must still maintain that! I'll admit that in the firewire case there would be some extra work, but not a lot. Regards, Hans From wwoods at redhat.com Wed Jan 9 19:49:24 2008 From: wwoods at redhat.com (Will Woods) Date: Wed, 09 Jan 2008 19:49:24 +0000 Subject: Fedora too cutting edge? In-Reply-To: <4785163E.8010508@hhs.nl> References: <4785163E.8010508@hhs.nl> Message-ID: <1199908164.4765.49.camel@metroid.rdu.redhat.com> On Wed, 2008-01-09 at 19:45 +0100, Hans de Goede wrote: > Hi All, > > One of the few reasons why Fedora is my distro of choice is because its usually > cutting edge, and I like to be where the development is happening. > > However today I've had an encounter with Fedora which make me wonder if > sometimes we aren't a little too cutting edge. I tried to get an industrial > firewire camera to work with the stock Fedora kernel using the juju stack. Long > story short, it didn't work. > > Which after reading: http://wiki.linux1394.org/JujuMigration Isn't really > surprising, quoting that page: "Almost no support for IIDC cameras: Not > compatible with libdc1394 v1. Highly experimental support in libdc1394 v2 which > works with some luck on only a few OHCI 1.1 controllers. Improvements are to be > expected in Linux 2.6.25-rc1." > > Notice how a preliminary fix is expected for 2.6.25, which probably means that > this will still be broken in Fedora 9, notice that the breakage was introduced > in Fedora 7, so thats 18 months worth of broken firewire camera support (iow > most digital video cameras). Add to that that the above referenced wiki page > also says: "Regarding Linux 2.6.22 and 2.6.23, the best advice to Linux > distributors (kernel packagers) ... is: Build only the old IEEE 1394 drivers." libdc1394 isn't part of Fedora, so that's outside the scope of this discussion. As for the necessary Juju bits, they're already in Fedora 7 and Fedora 8. See this bug: https://bugzilla.redhat.com/show_bug.cgi?id=344851 That fix is included in kernel 2.6.23.9-44.fc7, 2.6.23.9-78.fc8, and rawhide. It'll hit the *upstream* kernel in 2.6.25. We were able to write that fix *because* the Juju stack was available in Fedora. -w -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From alan at redhat.com Wed Jan 9 19:53:33 2008 From: alan at redhat.com (Alan Cox) Date: Wed, 9 Jan 2008 14:53:33 -0500 Subject: Impending X driver deprecation In-Reply-To: <1199906969.15130.40.camel@localhost.localdomain> References: <1199906969.15130.40.camel@localhost.localdomain> Message-ID: <20080109195333.GB29801@devserv.devel.redhat.com> On Wed, Jan 09, 2008 at 02:29:29PM -0500, Adam Jackson wrote: > The ark, chips, s3, and tseng drivers are going away. These are all Object object object. The C&T 655xx mode setting is essential for all the small LCD displays on low power boxes I have. VESA won't set the modes right on these. > really boring early PCI chipsets that don't even have a 3d engine. They Yeah but they do support old very cheap low power flat panels that the banks threw out by the zillion and made their way onto ebay ;) I've got several C&T systems I depend upon so I'm happy to help test/debug C&T problems if that is needed. Alan From linville at redhat.com Wed Jan 9 20:06:34 2008 From: linville at redhat.com (John W. Linville) Date: Wed, 9 Jan 2008 15:06:34 -0500 Subject: Fedora too cutting edge? In-Reply-To: <4785163E.8010508@hhs.nl> References: <4785163E.8010508@hhs.nl> Message-ID: <20080109200634.GE17953@redhat.com> On Wed, Jan 09, 2008 at 07:45:18PM +0100, Hans de Goede wrote: > One of the few reasons why Fedora is my distro of choice is because its > usually cutting edge, and I like to be where the development is happening. > > However today I've had an encounter with Fedora which make me wonder if > sometimes we aren't a little too cutting edge. This question is worth asking, but I have no good answer. FWIW, I get criticized for pushing too much brand-new wireless bits into the Fedora kernels. Simultaneously (often the very same days) I get criticized for taking more than a day or two to get new upstream wireless patches merged into the Fedora kernels. There is no winning... Just my $0.02... John -- John W. Linville linville at redhat.com From limb at jcomserv.net Wed Jan 9 20:08:10 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 9 Jan 2008 14:08:10 -0600 (CST) Subject: Impending X driver deprecation In-Reply-To: <20080109195333.GB29801@devserv.devel.redhat.com> References: <1199906969.15130.40.camel@localhost.localdomain> <20080109195333.GB29801@devserv.devel.redhat.com> Message-ID: <21050.63.85.68.164.1199909290.squirrel@mail.jcomserv.net> > Yeah but they do support old very cheap low power flat panels that the > banks > threw out by the zillion and made their way onto ebay ;) +1 Agreed. I typically use hardware older than my children, which has always been a big selling point for Linux in general. I suppose I could use Slackware. .(ducks) -- novus ordo absurdum From ncorrare at fedoraproject.org Wed Jan 9 20:10:14 2008 From: ncorrare at fedoraproject.org (Nicolas Antonio Corrarello) Date: Wed, 09 Jan 2008 18:10:14 -0200 Subject: thinkpad-acpi upstream version? Message-ID: <47852A26.4010609@fedoraproject.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, Maybe I still don't get how upstream works, but I found that the latest thinkpad-acpi version is 0.19, still Fedora's latest kernel has [root at localhost ibm]# cat driver driver: ThinkPad ACPI Extras version: 0.16 - -- - - -- Nicolas A. Corrarello Fedora Ambassador Argentina c: +54 (911) 6017-2120 e: ncorrare at fedoraproject.org GPG Key: DFC893EE h: fedoraproject.org/wiki/NicolasCorrarello/ GPG Fingerprint: 5C93 42DA 98E1 4EEF B24B 7F8C E145 B2F9 DFC8 93EE Import my key: $ gpg --keyserver pgp.mit.edu --recv-key 0xDFC893EE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHhSom4UWy+d/Ik+4RAmN9AJsG2PIgkZB3tZIBt+dWyMuPrz9GwQCeJh8U zc0n9cU6+syRQ1/QKCZVJFY= =3w9p -----END PGP SIGNATURE----- From cjdahlin at ncsu.edu Wed Jan 9 20:15:39 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Wed, 09 Jan 2008 15:15:39 -0500 Subject: Init : someone could comment this ? In-Reply-To: <20080109165258.GD12763@nostromo.devel.redhat.com> References: <20080107173508.GA23429@tango.0pointer.de> <4783A57B.2050005@gmail.com> <4783AA97.8090500@gmail.com> <4783D111.80308@gmail.com> <50837.192.54.193.53.1199868870.squirrel@rousalka.dyndns.org> <20080109165258.GD12763@nostromo.devel.redhat.com> Message-ID: <47852B6B.6070102@ncsu.edu> Bill Nottingham wrote: > Nicolas Mailhot (nicolas.mailhot at laposte.net) said: > >> Le Mar 8 janvier 2008 23:45, Ian Burrell a ?crit : >> >> >>> I think it is important that we preserve the ability to use sysv-style >>> init scripts. They are part of LSB. >>> >> Sort-of. The LSB description is ambiguous, as evidenced by the many >> questions posted when we decided to migrate our existing pre-LSB >> scripts to the LSB variant. And I'm far from sure that other >> distributions answered those questions the same way. >> > > Well, they're not ambiguous in that they specify a script or command > that accepts certain stop/start/whatever arguments. > > To put it a different way, the chances of a solution that doesn't at > least support SysV scripts in some compatibility way going into RHEL > is pretty much zero, at least for the first RHEL release that it would > exist in. And (Red Hat hat on), Fedora should generally not try and break > its downstream releases too much. Doesn't mean that the system itself > should be using this mode for any of its scripts, though. > > Bill > > I'm not sure I see the point of this discussion. There hasn't been a single solution proposed to this problem which necessarily breaks sysV compatibility at runtime. Even a largely python-centric base of init scripts could clearly offer the ability to run shell scripts as a backward compatibility feature. Achieving a certain legacy level of support for the old sysV packages/scripts is trivial under any model. We need to decide on preferred methods. How do we want things to work? Adding in support for them working in other ways, particularly in the sysV way, is trivial. --CJD From cjdahlin at ncsu.edu Wed Jan 9 20:20:55 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Wed, 09 Jan 2008 15:20:55 -0500 Subject: Fedora too cutting edge? In-Reply-To: <47851ED9.2000800@leemhuis.info> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> Message-ID: <47852CA7.4010301@ncsu.edu> Thorsten Leemhuis wrote: > Another example: hplip is still on 2.7.7 for F8 right now while upstream > is at 2.7.12 in between and supports 22 new printers ( > http://hplip.sourceforge.net/release_notes.html ). We don't provide any > solutions for users that buy those printers right now besides using > rawhide. Thus they have to wait/ask for a proper update or wait until F9 > or -- the latter means waiting about 6 months for driver. That's IMHO > unacceptable -- especially as printer manufacturers release successor > models quite often (it feels to me like a new successor model get > released in each printer class about once a year, but I didn't check). > > What about NetworkManger? While our release engineers were screaming "It's not ready!" and refusing to enable it by default, Ubuntu was being credited for saving linux with it. --CJD From ajackson at redhat.com Wed Jan 9 20:51:29 2008 From: ajackson at redhat.com (Adam Jackson) Date: Wed, 09 Jan 2008 15:51:29 -0500 Subject: Impending X driver deprecation In-Reply-To: <20080109195333.GB29801@devserv.devel.redhat.com> References: <1199906969.15130.40.camel@localhost.localdomain> <20080109195333.GB29801@devserv.devel.redhat.com> Message-ID: <1199911889.15130.85.camel@localhost.localdomain> On Wed, 2008-01-09 at 14:53 -0500, Alan Cox wrote: > On Wed, Jan 09, 2008 at 02:29:29PM -0500, Adam Jackson wrote: > > really boring early PCI chipsets that don't even have a 3d engine. They > > Yeah but they do support old very cheap low power flat panels that the banks > threw out by the zillion and made their way onto ebay ;) > > I've got several C&T systems I depend upon so I'm happy to help test/debug > C&T problems if that is needed. chips will be spared from the coming apocalypse. - ajax From smooge at gmail.com Wed Jan 9 20:34:04 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 9 Jan 2008 13:34:04 -0700 Subject: Fedora too cutting edge? In-Reply-To: <47852CA7.4010301@ncsu.edu> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <47852CA7.4010301@ncsu.edu> Message-ID: <80d7e4090801091234l45bcb1ael7e6a90fb3adeb47f@mail.gmail.com> On Jan 9, 2008 1:20 PM, Casey Dahlin wrote: > Thorsten Leemhuis wrote: > > Another example: hplip is still on 2.7.7 for F8 right now while upstream > > is at 2.7.12 in between and supports 22 new printers ( > > http://hplip.sourceforge.net/release_notes.html ). We don't provide any > > solutions for users that buy those printers right now besides using > > rawhide. Thus they have to wait/ask for a proper update or wait until F9 > > or -- the latter means waiting about 6 months for driver. That's IMHO > > unacceptable -- especially as printer manufacturers release successor > > models quite often (it feels to me like a new successor model get > > released in each printer class about once a year, but I didn't check). > > > > > What about NetworkManger? While our release engineers were screaming > "It's not ready!" and refusing to enable it by default, Ubuntu was being > credited for saving linux with it. > There are always going to be examples of something that is chosen or not chosen to work with a release.. and some other distro is going to do it and get the credit. Fedora has probably gotten credit for things that Ubuntu was too extreme.. Choices have to be made of how many engineers are going to focus on some problem and what problems will have to wait. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From lordmorgul at gmail.com Wed Jan 9 20:34:00 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 09 Jan 2008 12:34:00 -0800 Subject: Init : someone could comment this ? In-Reply-To: <200801091406.m09E6dOe013547@laptop13.inf.utfsm.cl> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <1199638106.6022.88.camel@beck.corsepiu.local> <47812D36.4030309@ncsu.edu> <1199880879.5534.210.camel@beck.corsepiu.local> <7f692fec0801090539y4f8aa894i1ace29ab884aa994@mail.gmail.com> <200801091406.m09E6dOe013547@laptop13.inf.utfsm.cl> Message-ID: <47852FB8.6060603@gmail.com> Horst H. von Brand wrote: > What is missing IMVHO is the ability of handling service dependencies, but > that one is very tricky. For example, it mostly makes no sense to run a > mail/web/... server if there is no network, but the minority of cases where > it does make sense is sizeable nonetheless. And trying to cater for both > cases rapidly gets to be an unmanageable mess. What should be discussed are only serious *requirements* in the init scripts dependencies. In the example you gave here it makes no sense to prevent the web server from running because of no network because it could serve a purpose and it does function that way (and can be turned off if the user did not want it running). A dependency should be only what is absolutely required for basic functionality so that if it is turned on it has the *capability of starting*. It should be a much more manageable mess when the bare bones basics are figured out. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From ajackson at redhat.com Wed Jan 9 20:58:45 2008 From: ajackson at redhat.com (Adam Jackson) Date: Wed, 09 Jan 2008 15:58:45 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <47851ED9.2000800@leemhuis.info> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> Message-ID: <1199912325.15130.89.camel@localhost.localdomain> > Linux is about choice. If I could only have one thing this year, it would be to eliminate that meme from the collective consciousness. It is a disease. It strangles the mind and ensures you can never change anything ever because someone somewhere has OCD'd their environment exactly how they like it and how dare you change it on them you're so mean and next time I have friends over for Buffy night you're not invited mom he's sitting on my side again. As a consumer, yes, you have lots of choices in which Linux you use. This does not mean Linux is in any sense _about_ choice, any more than because there are so many kinds of cars you can buy that cars are about choice. The complaints up-thread about juju and pulse are entirely valid, but the solution is not to try to deliver two things at once. If you try to deliver both at once you have to also deliver a way of switching between the two. Now you have three moving parts instead of one, which means the failure rate has gone up by a factor of _six_ (three parts, and three interactions). We have essentially already posited that we have insufficient developer effort to have 100%-complete features at ship time, so asking them to take on six times the failure rate when they're already overburdened is just madness. Alternatively, we could say that we're integrating features too rapidly, but you do that at the expense of goal 1, to be the showcase for the latest and greatest in free software. Software is hard. The way to fix it is to fix it, not sweep it under the rug. There is a legitimate discussion to be had about where and how we draw the line for feature inclusion, about how we increase and formalize our testing efforts, and about how we develop and deploy spike solutions for corner-case problems like the one device class that juju happens to do worse than the old stack. But the chain of logic from "Linux is about choice" to "ship everything and let the user chose how they want their sound to not work" starts with fallacy and ends with disaster. - ajax From ml at deadbabylon.de Wed Jan 9 20:40:46 2008 From: ml at deadbabylon.de (Sebastian Vahl) Date: Wed, 9 Jan 2008 21:40:46 +0100 Subject: rawhide report: 20080109 changes In-Reply-To: <200801091658.m09GwATQ024553@porkchop.devel.redhat.com> References: <200801091658.m09GwATQ024553@porkchop.devel.redhat.com> Message-ID: <200801092140.47432.ml@deadbabylon.de> Am Mi 9.Januar 2008 schrieb Build System: > xorg-x11-drv-vesa-1.3.0-12.20071113.fc9 > --------------------------------------- > * Tue Jan 08 2008 Adam Jackson 1.3.0-12.20071113 > - Rebuild for new ABI. > > xorg-x11-server-1.4.99.1-0.15.20080107.fc9 > ------------------------------------------ > * Mon Jan 07 2008 Adam Jackson 1.4.99.1-0.15 > - Today's git snapshot. X-SELinux! > - Drop the code to migrate from /etc/X11/XF86Config*. > - s/perl -p -i -e/sed -i/g Are the other graphic drivers supposed to come tomorrow? Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From jkeating at redhat.com Wed Jan 9 20:46:11 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 9 Jan 2008 15:46:11 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199912325.15130.89.camel@localhost.localdomain> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> Message-ID: <20080109154611.26202487@redhat.com> On Wed, 09 Jan 2008 15:58:45 -0500 Adam Jackson wrote: > But the chain of logic from "Linux is about > choice" to "ship everything and let the user chose how they want their > sound to not work" starts with fallacy and ends with disaster. I cannot agree more. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jima at beer.tclug.org Wed Jan 9 20:46:47 2008 From: jima at beer.tclug.org (Jima) Date: Wed, 9 Jan 2008 14:46:47 -0600 (CST) Subject: Fedora too cutting edge? In-Reply-To: <4785163E.8010508@hhs.nl> References: <4785163E.8010508@hhs.nl> Message-ID: On Wed, 9 Jan 2008, Hans de Goede wrote: > Notice how a preliminary fix is expected for 2.6.25, which probably means > that this will still be broken in Fedora 9, notice that the breakage was > introduced in Fedora 7, so thats 18 months worth of broken firewire camera > support (iow most digital video cameras). That seems like a bold, and IMO, unsubstantiated claim. I managed to get a Firewire camera to work using the new stack a couple weeks ago. I had a bit of trouble, which lead me to discussions that came to the same general conclusion that you outlined in your email, but then I tried chown'ing the /dev/fw-* (or whatever) devices to my user, and things miraculously worked. This was on kernel-2.6.23.1-49.fc8; I hadn't gotten around to rebooting that box in a while (nor have I tried the camera since rebooting to 2.6.23.9-85.fc8). I won't deny, however, getting burned a time or three by Fedora's early-adopter practices. :-) Jima From airlied at redhat.com Wed Jan 9 20:52:52 2008 From: airlied at redhat.com (Dave Airlie) Date: Thu, 10 Jan 2008 06:52:52 +1000 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199912325.15130.89.camel@localhost.localdomain> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> Message-ID: <1199911972.10511.0.camel@optimus> On Wed, 2008-01-09 at 15:58 -0500, Adam Jackson wrote: > > Linux is about choice. > > If I could only have one thing this year, it would be to eliminate that > meme from the collective consciousness. It is a disease. It strangles > the mind and ensures you can never change anything ever because someone > somewhere has OCD'd their environment exactly how they like it and how > dare you change it on them you're so mean and next time I have friends > over for Buffy night you're not invited mom he's sitting on my side > again. Damn you where's my FreeBSD kernel package for Fedora? :) Dave. From lesmikesell at gmail.com Wed Jan 9 20:58:07 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 09 Jan 2008 14:58:07 -0600 Subject: Init : someone could comment this ? In-Reply-To: <47852FB8.6060603@gmail.com> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <1199638106.6022.88.camel@beck.corsepiu.local> <47812D36.4030309@ncsu.edu> <1199880879.5534.210.camel@beck.corsepiu.local> <7f692fec0801090539y4f8aa894i1ace29ab884aa994@mail.gmail.com> <200801091406.m09E6dOe013547@laptop13.inf.utfsm.cl> <47852FB8.6060603@gmail.com> Message-ID: <4785355F.5060302@gmail.com> Andrew Farris wrote: >> What is missing IMVHO is the ability of handling service dependencies, >> but >> that one is very tricky. For example, it mostly makes no sense to run a >> mail/web/... server if there is no network, but the minority of cases >> where >> it does make sense is sizeable nonetheless. And trying to cater for both >> cases rapidly gets to be an unmanageable mess. > > What should be discussed are only serious *requirements* in the init > scripts dependencies. In the example you gave here it makes no sense to > prevent the web server from running because of no network because it > could serve a purpose and it does function that way (and can be turned > off if the user did not want it running). What happens in practice, though, is that things that expect network services to be running will do DNS lookups, hanging for minutes at at time when there is no response. > A dependency should be only > what is absolutely required for basic functionality so that if it is > turned on it has the *capability of starting*. It should be a much more > manageable mess when the bare bones basics are figured out. Things may be 'capable' of starting with a several-minute timeout and failing DNS but that doesn't mean it is desirable - or that they will necessarily work when the interface(s) the services were supposed to be listening on become active later. On the other hand, you may have nothing but a loopback interface and a hosts file and want things to come up running so you can test them locally, or in sendmail's case so it can accept local submissions. And in the case of a laptop, it is fairly likely that you'll want to suspend it on one network (wired/wireless or both) and wake it up on something different. -- Les Mikesell lesmikesell at gmail.com From j.w.r.degoede at hhs.nl Wed Jan 9 20:56:54 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 09 Jan 2008 21:56:54 +0100 Subject: Fedora too cutting edge? In-Reply-To: <1199908164.4765.49.camel@metroid.rdu.redhat.com> References: <4785163E.8010508@hhs.nl> <1199908164.4765.49.camel@metroid.rdu.redhat.com> Message-ID: <47853516.2060600@hhs.nl> Will Woods wrote: > On Wed, 2008-01-09 at 19:45 +0100, Hans de Goede wrote: >> Hi All, >> >> One of the few reasons why Fedora is my distro of choice is because its usually >> cutting edge, and I like to be where the development is happening. >> >> However today I've had an encounter with Fedora which make me wonder if >> sometimes we aren't a little too cutting edge. I tried to get an industrial >> firewire camera to work with the stock Fedora kernel using the juju stack. Long >> story short, it didn't work. >> >> Which after reading: http://wiki.linux1394.org/JujuMigration Isn't really >> surprising, quoting that page: "Almost no support for IIDC cameras: Not >> compatible with libdc1394 v1. Highly experimental support in libdc1394 v2 which >> works with some luck on only a few OHCI 1.1 controllers. Improvements are to be >> expected in Linux 2.6.25-rc1." >> >> Notice how a preliminary fix is expected for 2.6.25, which probably means that >> this will still be broken in Fedora 9, notice that the breakage was introduced >> in Fedora 7, so thats 18 months worth of broken firewire camera support (iow >> most digital video cameras). Add to that that the above referenced wiki page >> also says: "Regarding Linux 2.6.22 and 2.6.23, the best advice to Linux >> distributors (kernel packagers) ... is: Build only the old IEEE 1394 drivers." > > libdc1394 isn't part of Fedora, so that's outside the scope of this > discussion. > Well actually it has been in review for quite a while, with the juju stack being one of the reasons for it not passing review yet (patents is another, but a patent free version is most likely possible). I would like to work on getting this into Fedora, and if things could be fixed so as to work with the new stack, I'm all for it. Shipping something which still doesn't work in F-9 makes us look rather bad IMHO, doing new things can cause breakage, but breakage for 3 releases in a row? > As for the necessary Juju bits, they're already in Fedora 7 and Fedora > 8. See this bug: https://bugzilla.redhat.com/show_bug.cgi?id=344851 > > That fix is included in kernel 2.6.23.9-44.fc7, 2.6.23.9-78.fc8, and > rawhide. It'll hit the *upstream* kernel in 2.6.25. > As for this being fixed, not for my case, as I have a via vt 6306 controller, which is like, only the most common PC firewire controller on the planet. Note that I'm more then willing to help debug this, I've added myself to the CC of: https://bugzilla.redhat.com/show_bug.cgi?id=415841 Anything I van do to help? Regards, Hans From jos at xos.nl Wed Jan 9 21:05:54 2008 From: jos at xos.nl (Jos Vos) Date: Wed, 9 Jan 2008 22:05:54 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199911972.10511.0.camel@optimus> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <1199911972.10511.0.camel@optimus> Message-ID: <20080109210554.GA2966@jasmine.xos.nl> On Thu, Jan 10, 2008 at 06:52:52AM +1000, Dave Airlie wrote: > Damn you where's my FreeBSD kernel package for Fedora? Weren't the Debian people targeting at a GNU Hurd-based version of their distro? :-) -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From fedora at leemhuis.info Wed Jan 9 21:18:25 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 09 Jan 2008 22:18:25 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199912325.15130.89.camel@localhost.localdomain> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> Message-ID: <47853A21.4020204@leemhuis.info> On 09.01.2008 21:58, Adam Jackson wrote: >> Linux is about choice. > [...] > The complaints up-thread about juju and pulse are entirely valid, but > the solution is not to try to deliver two things at once. I agree with most of the things you said. In a ideal world there would be no reason for some of the choices like juju or not. Juju afaics solves a lot of problems and I agree that it's the way forward. But we don't live in a ideal world and when we started shipping juju it was not capable to do some things that were possible with the old stack. Some things more then a handful of users wanted to do, so lot of users ran into trouble and had a hard a fight fixing it -- seems some people (including Hans afaics, who's a developer with a lot of skills) got confused/frustrated. That's bad for Fedoras reputing -- thus we should avoid that if we want to be a serious distribution and more than a beta-playground for RHEL (as that's how it feels from my point of view due to things like this). So that leaves two choices: - we could have delayed juju until F8 (or even F9) - we could have included juju in F7 (as we did) and made it optional (either enabled or disabled by default) I think the latter is the better solution and a serious option for one release. CU knurd From jkeating at redhat.com Wed Jan 9 21:27:57 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 9 Jan 2008 16:27:57 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <47853A21.4020204@leemhuis.info> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <47853A21.4020204@leemhuis.info> Message-ID: <20080109162757.5284bcc4@redhat.com> On Wed, 09 Jan 2008 22:18:25 +0100 Thorsten Leemhuis wrote: > - we could have delayed juju until F8 (or even F9) > - we could have included juju in F7 (as we did) and made it optional > (either enabled or disabled by default) > > I think the latter is the better solution and a serious option for one > release. And if we had chosen that, it likely still wouldn't be where it is today, because it wouldn't have had the exposure. It was functional for the vast majority of uses and the exposure got more and more things fixed on it. If there was an alternative then everybody would just switch back to the old method, and no bugs would get filed and no corner cases would get discovered. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From david at fubar.dk Wed Jan 9 21:28:31 2008 From: david at fubar.dk (David Zeuthen) Date: Wed, 09 Jan 2008 16:28:31 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199912325.15130.89.camel@localhost.localdomain> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> Message-ID: <1199914111.25567.4.camel@oneill.fubar.dk> Best mail on this list I've ever read. David From drago01 at gmail.com Wed Jan 9 21:33:33 2008 From: drago01 at gmail.com (drago01) Date: Wed, 9 Jan 2008 22:33:33 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <20080109154611.26202487@redhat.com> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <20080109154611.26202487@redhat.com> Message-ID: On Jan 9, 2008 9:46 PM, Jesse Keating wrote: > On Wed, 09 Jan 2008 15:58:45 -0500 > Adam Jackson wrote: > > > But the chain of logic from "Linux is about > > choice" to "ship everything and let the user chose how they want their > > sound to not work" starts with fallacy and ends with disaster. > > I cannot agree more. +1000 From notting at redhat.com Wed Jan 9 21:37:52 2008 From: notting at redhat.com (Bill Nottingham) Date: Wed, 9 Jan 2008 16:37:52 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <47853A21.4020204@leemhuis.info> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <47853A21.4020204@leemhuis.info> Message-ID: <20080109213752.GA3286@nostromo.devel.redhat.com> Thorsten Leemhuis (fedora at leemhuis.info) said: > So that leaves two choices: > > - we could have delayed juju until F8 (or even F9) > - we could have included juju in F7 (as we did) and made it optional > (either enabled or disabled by default) > > I think the latter is the better solution and a serious option for one > release. That way lies madness. Right now DRI/DRM breaks VT switch and suspend on my laptop. Should we ship two Intel drivers and two kernels until this is resolved? During the Fedora 8 devel cycle, NetworkManager didn't support WPA for a time. Should we have shipped two versions of NetworkManager and let users choose between them? If it doesn't work, it's a bug. Fix the bug. Not ship a version for each set of bugs that exists. Bill From dmc.fedora at filteredperception.org Wed Jan 9 21:48:24 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Wed, 09 Jan 2008 15:48:24 -0600 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199914111.25567.4.camel@oneill.fubar.dk> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <1199914111.25567.4.camel@oneill.fubar.dk> Message-ID: <47854128.8000200@filteredperception.org> David Zeuthen wrote: > Best mail on this list I've ever read. > > David Best slam against this list that I've ever read. -dmc From jdennis at redhat.com Wed Jan 9 21:51:57 2008 From: jdennis at redhat.com (John Dennis) Date: Wed, 09 Jan 2008 16:51:57 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199912325.15130.89.camel@localhost.localdomain> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> Message-ID: <478541FD.5000806@redhat.com> Adam Jackson wrote: > But the chain of logic from "Linux is about > choice" to "ship everything and let the user chose how they want their > sound to not work" starts with fallacy and ends with disaster. +1 FWIW, I tend to believe a good distribution is about limiting choice, not proliferating it. Limited choice enhances robustness by reducing the combinatorics of testing. Throwing the entire kitchen sink into the distribution is anarchy with the expected results. FWIW I liked the idea of Core vs. Extras because if it was in Core it was expected to work, if it was in Extras it was buyer beware. A good distribution works. Choice is provided by optional add-ons with no guarantees. After an optional package is shown to be robust and well supported it can be promoted from it's optional status, just as a core package can be demoted to optional if it fails to meet the requirements of robustness, security, and support required of the distribution. -- John Dennis From fedora at leemhuis.info Wed Jan 9 21:53:58 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 09 Jan 2008 22:53:58 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <20080109213752.GA3286@nostromo.devel.redhat.com> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <47853A21.4020204@leemhuis.info> <20080109213752.GA3286@nostromo.devel.redhat.com> Message-ID: <47854276.7060101@leemhuis.info> On 09.01.2008 22:37, Bill Nottingham wrote: > Thorsten Leemhuis (fedora at leemhuis.info) said: >> So that leaves two choices: >> >> - we could have delayed juju until F8 (or even F9) >> - we could have included juju in F7 (as we did) and made it optional >> (either enabled or disabled by default) >> >> I think the latter is the better solution and a serious option for one >> release. > That way lies madness. I suppose the users that ran into trouble would say the same about what we did. So both way lie madness here. Then I'm all for giving the users the choice so they can work around something without to much trouble if they run into problems with something new. > Right now DRI/DRM breaks VT switch and suspend on my laptop. Should we > ship two Intel drivers and two kernels until this is resolved? [...] Bugs in a updated package are something totally different (everyone tries to avoid them, but they happen, so we have to live with them) then switching to a new completely firewire stack that doesn't support everything yet what the old stack did. Jesse said juju "was functional for the vast majority of uses" when we shipped that; I doubt that, as the questions is saw in #fedora-de, the "howto switch to the old firewire stack"-Howtos in the net and the mail from Hans tell a different story. Cu knurd From dmc.fedora at filteredperception.org Wed Jan 9 22:00:26 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Wed, 09 Jan 2008 16:00:26 -0600 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <478541FD.5000806@redhat.com> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <478541FD.5000806@redhat.com> Message-ID: <478543FA.70809@filteredperception.org> John Dennis wrote: > Adam Jackson wrote: >> But the chain of logic from "Linux is about >> choice" to "ship everything and let the user chose how they want their >> sound to not work" starts with fallacy and ends with disaster. > > +1 > > FWIW, I tend to believe a good distribution is about limiting choice, > not proliferating it. Limited choice enhances robustness by reducing the > combinatorics of testing. Throwing the entire kitchen sink into the > distribution is anarchy with the expected results. > > FWIW I liked the idea of Core vs. Extras because if it was in Core it > was expected to work, if it was in Extras it was buyer beware. > > A good distribution works. Choice is provided by optional add-ons with > no guarantees. +42 This is where I think the intensity of this thread is somewhat confusing. I wholeheartedly agree that what you ship in one particular spin/strain of fedora should most often minimize choices for the user (unless the target users of the spin/strain explicitly want the choices). That is what is great about distro spin tools such as livecd-tools/revisor/VirOS- they make it easy for anyone who doesn't like the official fedora imposed choice, to as easily as possible, put together a 'fork' distro utilizing the alternate choice. The thing I wish would be come through clearer in this thread is that choices are fine for the massive Fedora Everything collection. Sure having more choices will lead to more bugs, but so what as long as the choices made for the official spin are well tested. $0.02 -dmc After an optional package is shown to be robust and well > supported it can be promoted from it's optional status, just as a core > package can be demoted to optional if it fails to meet the requirements > of robustness, security, and support required of the distribution. > From lordmorgul at gmail.com Wed Jan 9 22:07:16 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 09 Jan 2008 14:07:16 -0800 Subject: Init : someone could comment this ? In-Reply-To: <4785355F.5060302@gmail.com> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <1199638106.6022.88.camel@beck.corsepiu.local> <47812D36.4030309@ncsu.edu> <1199880879.5534.210.camel@beck.corsepiu.local> <7f692fec0801090539y4f8aa894i1ace29ab884aa994@mail.gmail.com> <200801091406.m09E6dOe013547@laptop13.inf.utfsm.cl> <47852FB8.6060603@gmail.com> <4785355F.5060302@gmail.com> Message-ID: <47854594.7070205@gmail.com> Les Mikesell wrote: > Andrew Farris wrote: > >>> What is missing IMVHO is the ability of handling service >>> dependencies, but >>> that one is very tricky. For example, it mostly makes no sense to run a >>> mail/web/... server if there is no network, but the minority of cases >>> where >>> it does make sense is sizeable nonetheless. And trying to cater for both >>> cases rapidly gets to be an unmanageable mess. >> >> What should be discussed are only serious *requirements* in the init >> scripts dependencies. In the example you gave here it makes no sense >> to prevent the web server from running because of no network because >> it could serve a purpose and it does function that way (and can be >> turned off if the user did not want it running). > > What happens in practice, though, is that things that expect network > services to be running will do DNS lookups, hanging for minutes at at > time when there is no response. Looks like a good way to identify bugs to me... the DNS hang needs fixed, not worked around. > > A dependency should be only >> what is absolutely required for basic functionality so that if it is >> turned on it has the *capability of starting*. It should be a much >> more manageable mess when the bare bones basics are figured out. > > Things may be 'capable' of starting with a several-minute timeout and > failing DNS but that doesn't mean it is desirable - or that they will > necessarily work when the interface(s) the services were supposed to be > listening on become active later. On the other hand, you may have > nothing but a loopback interface and a hosts file and want things to > come up running so you can test them locally, or in sendmail's case so > it can accept local submissions. > > And in the case of a laptop, it is fairly likely that you'll want to > suspend it on one network (wired/wireless or both) and wake it up on > something different. I can understand that as a real complication, but again thats (IMO) something different than a web server which can work quite well without a network. The point I was making is that there may be hard and fast requirements, and there may be 'would be nice' situations... and the init scripts should only be guaranteed to give the requirement in a parallelized booting sequence. Beyond that, the other issues need fixed so that for instance the service DOES start listening when the link goes active later, rather than blocking or delaying the service from starting at boot time. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From lkundrak at redhat.com Wed Jan 9 22:11:41 2008 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Wed, 09 Jan 2008 23:11:41 +0100 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <64b14b300801090446u1412557p7bee40aa9922223d@mail.gmail.com> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <20080109094532.811057b2.mschwendt.tmp0701.nospam@arcor.de> <64b14b300801090446u1412557p7bee40aa9922223d@mail.gmail.com> Message-ID: <1199916701.8159.2.camel@localhost.localdomain> On Wed, 2008-01-09 at 13:46 +0100, Valent Turkovic wrote: > On 1/9/08, Michael Schwendt wrote: > > On Wed, 9 Jan 2008 09:20:46 +0100, Valent Turkovic wrote: > > > > > Hi, > > > I saw that Pulse Audio 0.9.8 got released two months ago: > > > http://pulseaudio.org/milestone/0.9.8 > > > and I see on my Fedora 8 that we still have 0.9.7 > > > > > > $ pulseaudio --version > > > pulseaudio 0.9.7 > > > > > > Will there be an upgrade soon on Fedora 8 to Pulse Audio 0.9.8? > > > > > > Lost of issues have been fixed in new Pulse Audio so users like me who > > > have issues with Pulse Audio would appreciate the much needed upgrade. > > > > I'm sure the person who maintains the Fedora packages is aware of that. :) > > Just notice the connection between Pulse Audio and Red Hat. > > I'm sure he is aware of that but I am not - that is why I wrote this email. I know the answer -- He decided to save us from an useless upgrade that would solve none of our problems. This applies for all package maintainers who value bandwidth and time of the users more than a change of one digit in a version number -- my thanks to them. -- Lubomir Kundrak (Red Hat Security Response Team) From fedora at leemhuis.info Wed Jan 9 22:12:57 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 09 Jan 2008 23:12:57 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <478543FA.70809@filteredperception.org> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <478541FD.5000806@redhat.com> <478543FA.70809@filteredperception.org> Message-ID: <478546E9.4010303@leemhuis.info> On 09.01.2008 23:00, Douglas McClendon wrote: > John Dennis wrote: >> A good distribution works. +1 But Juju afaics didn't work well for to many people when we shipped it for the first time, thus choice here IMHO is a temporary solution. > This is where I think the intensity of this thread is somewhat > confusing. I wholeheartedly agree that what you ship in one particular > spin/strain of fedora should most often minimize choices for the user > (unless the target users of the spin/strain explicitly want the choices). +1 > That is what is great about distro spin tools such as > livecd-tools/revisor/VirOS- they make it easy for anyone who doesn't > like the official fedora imposed choice, to as easily as possible, put > together a 'fork' distro utilizing the alternate choice. You might want to look at a idea that came up on the list now and then by different people that Jesse added to the wiki: http://fedoraproject.org/wiki/JesseKeating/KojiPersonalRepos I like the idea, but the amount of work that might create is likely a lot. > [...] Cu knurd From jspaleta at gmail.com Wed Jan 9 22:13:29 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 9 Jan 2008 13:13:29 -0900 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <20080109162757.5284bcc4@redhat.com> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <47853A21.4020204@leemhuis.info> <20080109162757.5284bcc4@redhat.com> Message-ID: <604aa7910801091413g6ba4f739p5cbd4213b7ebc56a@mail.gmail.com> On Jan 9, 2008 12:27 PM, Jesse Keating wrote: > And if we had chosen that, it likely still wouldn't be where it is > today, because it wouldn't have had the exposure. It was functional > for the vast majority of uses and the exposure got more and more things > fixed on it. If there was an alternative then everybody would just > switch back to the old method, and no bugs would get filed and no > corner cases would get discovered. We need to build an accurate perception as to what we are offering in our releases. When we have the manpower to support it we drive technologies forward aggressively. We need to build the perception that our releases aren't just consumables, but they instead collaborative partnerships will our users to meet the goals of driving long term value into the open source software stack. We need to build the perception that when you choose to use fedora, you are choosing to be a part of the collaboration, and not just taking a product off the shelf giving it a spin. In areas where we have Fedora contributors who are active upstream developers, we tend to make integration decisions in release N which have the best potential for long term benefit for release N+1, N+2 and out into the future (especially in the area of hardware interaction). We know our process is not regression intolerant. But our process accommodates that fact by having an aggressive update process so people suffering hardware regressions can obtain fixes in a responsive manner. This isn't a policy, or a set of rules, this is how our development culture operates in broad brush strokes. It would be deeply disruptive to the project to attempt to suppress this essential nature. So how do we fix the perception that this is a bad thing? How do we attract users and contributors who are comfortable with some level of regression, for the sake of long term benefit? Naively, I would suggest continuing to enhance our Feature-scoping so that it includes known or suspected regression areas. And we need to be able to have our developers who are aggressively driving new technologies into our releases, make public commitments that they will work to address regressions as part of the update process. We can't make guarantees, but we can certainly project a perception that our developers care about hardware regressions and are willing to work with people to fix them. -jef From walters at redhat.com Wed Jan 9 22:17:17 2008 From: walters at redhat.com (Colin Walters) Date: Wed, 09 Jan 2008 17:17:17 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <478541FD.5000806@redhat.com> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <478541FD.5000806@redhat.com> Message-ID: <1199917037.6070.12.camel@space-ghost.verbum.private> On Wed, 2008-01-09 at 16:51 -0500, John Dennis wrote: > FWIW I liked the idea of Core vs. Extras because if it was in Core it > was expected to work, if it was in Extras it was buyer beware. The Core/Extras split still exists in the sense of "some packages are more important than others"- it's just now defined as the set of packages included in the Live image kickstart files and comps. From jkeating at redhat.com Wed Jan 9 22:18:18 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 9 Jan 2008 17:18:18 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <478546E9.4010303@leemhuis.info> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <478541FD.5000806@redhat.com> <478543FA.70809@filteredperception.org> <478546E9.4010303@leemhuis.info> Message-ID: <20080109171818.3791a68f@redhat.com> On Wed, 09 Jan 2008 23:12:57 +0100 Thorsten Leemhuis wrote: > +1 > > But Juju afaics didn't work well for to many people when we shipped it > for the first time, thus choice here IMHO is a temporary solution. Some people. Lets not confuse a few vocal folks for whom a part of it didn't work with the large amount of folks who just plain didn't notice that juju was there vs something else because things just kept working (or got better). I mistakenly claimed that it worked for most people, when in reality I have no way of proving that. Instead, most /functionality/ was working, and I extrapolated that into most people. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kwizart at gmail.com Wed Jan 9 22:18:09 2008 From: kwizart at gmail.com (KH KH) Date: Wed, 9 Jan 2008 23:18:09 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <20080109162757.5284bcc4@redhat.com> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <47853A21.4020204@leemhuis.info> <20080109162757.5284bcc4@redhat.com> Message-ID: 2008/1/9, Jesse Keating : > On Wed, 09 Jan 2008 22:18:25 +0100 > Thorsten Leemhuis wrote: > And if we had chosen that, it likely still wouldn't be where it is > today, because it wouldn't have had the exposure. It was functional > for the vast majority of uses and the exposure got more and more things > fixed on it. If there was an alternative then everybody would just > switch back to the old method, and no bugs would get filed and no > corner cases would get discovered. Then we might have a fallback method for people that want to test firewire. Because if it does not work for some userland apps, then people will just escape.(to RHEL based or others). If we really want to have valuable testers for firewire, I think they have to be taken with care. For now i'm building a own kmod-ieee1394 but it is not interesting to have it build that way... instead of within the kernel. then providing a compat-libraw1394 (without juju support) with the appropriate blacklisting for kernel modules, and that's would be all... See experiments here: http://kwizart.free.fr/fedora/testing/8/SRPMS/ I do think the firewire problem is different from others. Nicolas (kwizart) > > -- > Jesse Keating > Fedora -- All my bits are free, are yours? > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From wwoods at redhat.com Wed Jan 9 22:26:05 2008 From: wwoods at redhat.com (Will Woods) Date: Wed, 09 Jan 2008 22:26:05 +0000 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199917037.6070.12.camel@space-ghost.verbum.private> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <478541FD.5000806@redhat.com> <1199917037.6070.12.camel@space-ghost.verbum.private> Message-ID: <1199917565.4765.52.camel@metroid.rdu.redhat.com> On Wed, 2008-01-09 at 17:17 -0500, Colin Walters wrote: > On Wed, 2008-01-09 at 16:51 -0500, John Dennis wrote: > > > FWIW I liked the idea of Core vs. Extras because if it was in Core it > > was expected to work, if it was in Extras it was buyer beware. > > The Core/Extras split still exists in the sense of "some packages are > more important than others"- it's just now defined as the set of > packages included in the Live image kickstart files and comps. Live and/or the Default Install set. We should probably have a better way of listing of what that set of packages actually is so we can make sure they get extra attention during updates and whatnot. -w -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jeff at ocjtech.us Wed Jan 9 22:39:44 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Wed, 9 Jan 2008 16:39:44 -0600 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <1199916701.8159.2.camel@localhost.localdomain> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <20080109094532.811057b2.mschwendt.tmp0701.nospam@arcor.de> <64b14b300801090446u1412557p7bee40aa9922223d@mail.gmail.com> <1199916701.8159.2.camel@localhost.localdomain> Message-ID: <935ead450801091439i7f753516jaec140b859d5d921@mail.gmail.com> On 1/9/08, Lubomir Kundrak wrote: > > I know the answer -- He decided to save us from an useless upgrade that > would solve none of our problems. This applies for all package > maintainers who value bandwidth and time of the users more than a change > of one digit in a version number -- my thanks to them. I recompiled 0.9.8 (taken from rawhide) on my F-8 systems and I think that it's markedly improved from the version available in F-8. I haven't done a full comparison, but I don't think that the source in F-8 is even the full 0.9.7, but is a snapshot taken from subversion almost two weeks before 0.9.7 was released (0.9.7 was released on 2007-10-30 and the snapshot inlcuded in F-8 was taken on 2007-10-17). Jeff From ggw at wolves.durham.nc.us Wed Jan 9 22:36:43 2008 From: ggw at wolves.durham.nc.us (G.Wolfe Woodbury) Date: Wed, 09 Jan 2008 17:36:43 -0500 Subject: Init : someone could comment this ? In-Reply-To: <47854594.7070205@gmail.com> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <1199638106.6022.88.camel@beck.corsepiu.local> <47812D36.4030309@ncsu.edu> <1199880879.5534.210.camel@beck.corsepiu.local> <7f692fec0801090539y4f8aa894i1ace29ab884aa994@mail.gmail.com> <200801091406.m09E6dOe013547@laptop13.inf.utfsm.cl> <47852FB8.6060603@gmail.com> <4785355F.5060302@gmail.com> <47854594.7070205@gmail.com> Message-ID: <47854C7B.2000303@wolves.durham.nc.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Farris wrote: > Les Mikesell wrote: >> >> What happens in practice, though, is that things that expect network >> services to be running will do DNS lookups, hanging for minutes at at >> time when there is no response. > > Looks like a good way to identify bugs to me... the DNS hang needs > fixed, not worked around. One major help would be for Fedora to _not_ mangle the localhost line in /etc/hosts. This has casued me several headaches until I learned to remove the local realname from the default localhost line. Sure, its not technically incorrect, but its not nice when you've got static addresses on a LAN. - -- Wolfe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHhUx6GAa0f5mx9EQRAiDzAJ9V0uSCD/foGMBx5APzZZFL2UgTUwCcDUpr q7M2pJ08bCT+t1i9Io7lfUw= =tPKZ -----END PGP SIGNATURE----- From pertusus at free.fr Wed Jan 9 22:47:42 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 9 Jan 2008 23:47:42 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199912325.15130.89.camel@localhost.localdomain> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> Message-ID: <20080109224742.GB2664@free.fr> On Wed, Jan 09, 2008 at 03:58:45PM -0500, Adam Jackson wrote: > > Linux is about choice. > > The complaints up-thread about juju and pulse are entirely valid, but > the solution is not to try to deliver two things at once. If you try to > deliver both at once you have to also deliver a way of switching between > the two. Now you have three moving parts instead of one, which means > the failure rate has gone up by a factor of _six_ (three parts, and > three interactions). We have essentially already posited that we have > insufficient developer effort to have 100%-complete features at ship > time, so asking them to take on six times the failure rate when they're > already overburdened is just madness. Alternatively, we could say that Who 'essentially already posited that we have insufficient developer effort'? Who decided that, and for what task? Isn't the fedora contributors time used like they want to? If there are three parts, and three interactions but dozens of contributors willing to fix them where is the issue? > worse than the old stack. But the chain of logic from "Linux is about > choice" to "ship everything and let the user chose how they want their > sound to not work" starts with fallacy and ends with disaster. This is right. But care should be taken not to shift from constraining the user to constraining the developper. We should ship everything that a contributor has interest in maintaining. It should not be at the expense of innovating, so breaking some packages some time because they are not ready for changes in other packages is acceptable (in rawhide). In the design of new feature, however existing stuff should be taken into account such that, if possible, previous habits are still possible and there are no regression. Developpers of new features should look at it, even to discard it, in fedora I see too much 'this is old cruft no need to look at it is broken by design' even when it is untrue. -- Pat From david at fubar.dk Wed Jan 9 22:54:51 2008 From: david at fubar.dk (David Zeuthen) Date: Wed, 09 Jan 2008 17:54:51 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <20080109224742.GB2664@free.fr> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> Message-ID: <1199919291.25567.10.camel@oneill.fubar.dk> On Wed, 2008-01-09 at 23:47 +0100, Patrice Dumas wrote: > Who 'essentially already posited that we have insufficient developer > effort'? Who decided that, and for what task? Isn't the fedora > contributors time used like they want to? If there are three parts, > and three interactions but dozens of contributors willing to fix > them where is the issue? One issue is that most packagers maintainers in the Fedora Project are not code monkeys. Another issue is that complexity has this funny habit of growing exponentially with the number of moving parts... David From pertusus at free.fr Wed Jan 9 23:06:42 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 10 Jan 2008 00:06:42 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199919291.25567.10.camel@oneill.fubar.dk> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> <1199919291.25567.10.camel@oneill.fubar.dk> Message-ID: <20080109230642.GD2664@free.fr> On Wed, Jan 09, 2008 at 05:54:51PM -0500, David Zeuthen wrote: > > On Wed, 2008-01-09 at 23:47 +0100, Patrice Dumas wrote: > > Who 'essentially already posited that we have insufficient developer > > effort'? Who decided that, and for what task? Isn't the fedora > > contributors time used like they want to? If there are three parts, > > and three interactions but dozens of contributors willing to fix > > them where is the issue? > > One issue is that most packagers maintainers in the Fedora Project are > not code monkeys. Do you have other words that would say the same, but understandable by a non native speaker... > Another issue is that complexity has this funny habit > of growing exponentially with the number of moving parts... That's possible, and I am not advocating to let everything go in any direction, be it only because some of the burden fails on other packagers (misfiled bugs, complex issues that seems to arise from a package but in fact comes from another temporarily broken) but a middle ground is needed in which developpers, especially from the community can also do what they want in fedora to pursue their own (innovative or simply usefull). -- Pat From lordmorgul at gmail.com Wed Jan 9 23:16:14 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 09 Jan 2008 15:16:14 -0800 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <20080109230642.GD2664@free.fr> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> <1199919291.25567.10.camel@oneill.fubar.dk> <20080109230642.GD2664@free.fr> Message-ID: <478555BE.7040808@gmail.com> Patrice Dumas wrote: > On Wed, Jan 09, 2008 at 05:54:51PM -0500, David Zeuthen wrote: >> One issue is that most packagers maintainers in the Fedora Project are >> not code monkeys. > > Do you have other words that would say the same, but understandable by a > non native speaker... Explanation here: http://en.wikipedia.org/wiki/Code_monkey (often means 'person who only programs' opposed to engineer/designer, but I really think he meant 'programmer' versus 'packager' in a nicer way, in that most packagers can't always fix all the code bugs) -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From jkeating at redhat.com Wed Jan 9 23:18:11 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 9 Jan 2008 18:18:11 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <20080109230642.GD2664@free.fr> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> <1199919291.25567.10.camel@oneill.fubar.dk> <20080109230642.GD2664@free.fr> Message-ID: <20080109181811.11dc3536@redhat.com> On Thu, 10 Jan 2008 00:06:42 +0100 Patrice Dumas wrote: > > One issue is that most packagers maintainers in the Fedora Project > > are not code monkeys. > > Do you have other words that would say the same, but understandable > by a non native speaker.. He's saying that most our package maintainers are not actual code developers, but instead folks that know and understand how to package software. A valuable skill set, but not the skill set needed for developing software itself. See other threads recently on this topic. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jonstanley at gmail.com Wed Jan 9 23:19:14 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Wed, 9 Jan 2008 18:19:14 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <20080109230642.GD2664@free.fr> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> <1199919291.25567.10.camel@oneill.fubar.dk> <20080109230642.GD2664@free.fr> Message-ID: On Jan 9, 2008 6:06 PM, Patrice Dumas wrote: > Do you have other words that would say the same, but understandable by a > non native speaker... Sure - what's being said is that some or most Fedora package maintainers are not programmers or coders, but rather packager. Adding my own $0.02 here, I'm not sure that this is a problem. Coders code - they are often not good packagers/release engineering folk. However the packagers need the coding community behind them. From david at fubar.dk Wed Jan 9 23:24:08 2008 From: david at fubar.dk (David Zeuthen) Date: Wed, 09 Jan 2008 18:24:08 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <20080109230642.GD2664@free.fr> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> <1199919291.25567.10.camel@oneill.fubar.dk> <20080109230642.GD2664@free.fr> Message-ID: <1199921048.25567.21.camel@oneill.fubar.dk> On Thu, 2008-01-10 at 00:06 +0100, Patrice Dumas wrote: > On Wed, Jan 09, 2008 at 05:54:51PM -0500, David Zeuthen wrote: > > > > On Wed, 2008-01-09 at 23:47 +0100, Patrice Dumas wrote: > > > Who 'essentially already posited that we have insufficient developer > > > effort'? Who decided that, and for what task? Isn't the fedora > > > contributors time used like they want to? If there are three parts, > > > and three interactions but dozens of contributors willing to fix > > > them where is the issue? > > > > One issue is that most packagers maintainers in the Fedora Project are > > not code monkeys. > > Do you have other words that would say the same, but understandable by a > non native speaker... I just meant that most (certainly not all) Fedora package maintainers don't know how to write/debug code, create patches that will be accepted upstream, understand complex interactions involving multiple packages and processes (sometimes even user/kernel boundaries) and so on - you know, what programmers do. While this is probably fine for the majority of our packages (I mean, it's perfectly fine to package software even if you can't program), it's probably going to be a problem in situations like the proposed ones. David From mcepl at redhat.com Wed Jan 9 23:16:55 2008 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 10 Jan 2008 00:16:55 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <1199911972.10511.0.camel@optimus> Message-ID: <781g55xn86.ln2@ppp1053.in.ipex.cz> On 2008-01-09, 20:52 GMT, Dave Airlie wrote: > Damn you where's my FreeBSD kernel package for Fedora? You have to for it somewhere else http://www.us.debian.org/ports/kfreebsd-gnu/ :-) Mat?j From pertusus at free.fr Wed Jan 9 23:30:29 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 10 Jan 2008 00:30:29 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199921048.25567.21.camel@oneill.fubar.dk> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> <1199919291.25567.10.camel@oneill.fubar.dk> <20080109230642.GD2664@free.fr> <1199921048.25567.21.camel@oneill.fubar.dk> Message-ID: <20080109233027.GF2664@free.fr> On Wed, Jan 09, 2008 at 06:24:08PM -0500, David Zeuthen wrote: > > I just meant that most (certainly not all) Fedora package maintainers > don't know how to write/debug code, create patches that will be accepted > upstream, understand complex interactions involving multiple packages > and processes (sometimes even user/kernel boundaries) and so on - you > know, what programmers do. > > While this is probably fine for the majority of our packages (I mean, > it's perfectly fine to package software even if you can't program), it's > probably going to be a problem in situations like the proposed ones. That's sure people should not do things they cannot manage, but I can't see how it is related with the issues above. And notice that it is Hans who started the thread... -- Pat From david at fubar.dk Wed Jan 9 23:33:45 2008 From: david at fubar.dk (David Zeuthen) Date: Wed, 09 Jan 2008 18:33:45 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <20080109233027.GF2664@free.fr> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> <1199919291.25567.10.camel@oneill.fubar.dk> <20080109230642.GD2664@free.fr> <1199921048.25567.21.camel@oneill.fubar.dk> <20080109233027.GF2664@free.fr> Message-ID: <1199921625.25567.24.camel@oneill.fubar.dk> On Thu, 2008-01-10 at 00:30 +0100, Patrice Dumas wrote: > On Wed, Jan 09, 2008 at 06:24:08PM -0500, David Zeuthen wrote: > > > > I just meant that most (certainly not all) Fedora package maintainers > > don't know how to write/debug code, create patches that will be accepted > > upstream, understand complex interactions involving multiple packages > > and processes (sometimes even user/kernel boundaries) and so on - you > > know, what programmers do. > > > > While this is probably fine for the majority of our packages (I mean, > > it's perfectly fine to package software even if you can't program), it's > > probably going to be a problem in situations like the proposed ones. > > That's sure people should not do things they cannot manage, but I can't > see how it is related with the issues above. ?You claimed that there was dozens and dozens of people ready to help with such tasks. I submit that is not true. I wish it was. David From pertusus at free.fr Wed Jan 9 23:36:13 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 10 Jan 2008 00:36:13 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199911972.10511.0.camel@optimus> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <1199911972.10511.0.camel@optimus> Message-ID: <20080109233613.GG2664@free.fr> On Thu, Jan 10, 2008 at 06:52:52AM +1000, Dave Airlie wrote: > On Wed, 2008-01-09 at 15:58 -0500, Adam Jackson wrote: > > > Linux is about choice. > > > > If I could only have one thing this year, it would be to eliminate that > > meme from the collective consciousness. It is a disease. It strangles > > the mind and ensures you can never change anything ever because someone > > somewhere has OCD'd their environment exactly how they like it and how > > dare you change it on them you're so mean and next time I have friends > > over for Buffy night you're not invited mom he's sitting on my side > > again. > > Damn you where's my FreeBSD kernel package for Fedora? I guess that you are joking, but I think that a FreeBSD kernel package is perfectly right for fedora. It should not go in a stable release until it is stable, and could be less well integrated than the linux kernel but it would definitively be something interesting. -- Pat From mzerqung at 0pointer.de Wed Jan 9 23:46:05 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Thu, 10 Jan 2008 00:46:05 +0100 Subject: Init : someone could comment this ? In-Reply-To: <47854C7B.2000303@wolves.durham.nc.us> References: <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <1199638106.6022.88.camel@beck.corsepiu.local> <47812D36.4030309@ncsu.edu> <1199880879.5534.210.camel@beck.corsepiu.local> <7f692fec0801090539y4f8aa894i1ace29ab884aa994@mail.gmail.com> <200801091406.m09E6dOe013547@laptop13.inf.utfsm.cl> <47852FB8.6060603@gmail.com> <4785355F.5060302@gmail.com> <47854594.7070205@gmail.com> <47854C7B.2000303@wolves.durham.nc.us> Message-ID: <20080109234605.GB16506@tango.0pointer.de> On Wed, 09.01.08 17:36, G.Wolfe Woodbury (ggw at wolves.durham.nc.us) wrote: > >> What happens in practice, though, is that things that expect network > >> services to be running will do DNS lookups, hanging for minutes at at > >> time when there is no response. > > > > Looks like a good way to identify bugs to me... the DNS hang needs > > fixed, not worked around. > > One major help would be for Fedora to _not_ mangle the localhost line in > /etc/hosts. This has casued me several headaches until I learned to > remove the local realname from the default localhost line. > > Sure, its not technically incorrect, but its not nice when you've got > static addresses on a LAN. Although this is totally off-topic: I still think the proper fix is something like this: http://0pointer.de/lennart/projects/nss-myhostname/ http://0pointer.de/lennart/projects/nss-myhostname/README.txt I wrote that a while back. Maybe someone wants to dust this off and get it into Fedora and activated by default? This saved me a couple of times on embedded boxes, where each of the devices used a different hostname and I had to guarantee that the hostname stayed resolvable in all cases, with a ro root directory. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From pertusus at free.fr Wed Jan 9 23:48:17 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 10 Jan 2008 00:48:17 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199921625.25567.24.camel@oneill.fubar.dk> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> <1199919291.25567.10.camel@oneill.fubar.dk> <20080109230642.GD2664@free.fr> <1199921048.25567.21.camel@oneill.fubar.dk> <20080109233027.GF2664@free.fr> <1199921625.25567.24.camel@oneill.fubar.dk> Message-ID: <20080109234817.GH2664@free.fr> On Wed, Jan 09, 2008 at 06:33:45PM -0500, David Zeuthen wrote: > > > ?You claimed that there was dozens and dozens of people ready to help > with such tasks. I submit that is not true. I wish it was. I am not saying that there are dozens and dozens of people ready to help for these tasks. I am saying that when there are such people those who do the mainstream stuff it should let them play instead of being hostile for parallel/oldish/fun implementations. It has a cost, because there are always side effects, but it is a price to be paid for community involvment. -- Pat From riel at redhat.com Wed Jan 9 23:48:52 2008 From: riel at redhat.com (Rik van Riel) Date: Wed, 9 Jan 2008 18:48:52 -0500 Subject: hunspell dictionaries, what's "missing" In-Reply-To: <1199885082.10609.163.camel@Jehannum> References: <1199874135.10609.122.camel@Jehannum> <200801091500.17934.vpivaini@cs.helsinki.fi> <1199885082.10609.163.camel@Jehannum> Message-ID: <20080109184852.063f5d98@bree.surriel.com> On Wed, 09 Jan 2008 13:24:42 +0000 Caolan McNamara wrote: > On Wed, 2008-01-09 at 15:00 +0200, Ville-Pekka Vainio wrote: > > Caolan McNamara kirjoitti: > > This is not strictly hunspell related, but I've been working on getting the > > free Finnish spellchecker and hyphenator Voikko into Fedora, see the thread > > at > > Yeah, I saw that. Unfortunately I'm just not qualified to know what > blocks hunspell from supporting Finnish, but I'm surprised that it is > the case given that hunspell was written to handle Hungarian which I > thought was similarly agglunatively complicated as Finnish. :-( Most of Finnish grammar may be simpler than Hungarian, but IIRC Finnish does have some limited vowel shifting going on with certain cases on certain words. That might confuse a spell checker. Hungarian mostly seems complex in ways that spell checkers aren't bothered by :) -- All rights reversed. From triad at df.lth.se Wed Jan 9 23:51:13 2008 From: triad at df.lth.se (Linus Walleij) Date: Thu, 10 Jan 2008 00:51:13 +0100 (CET) Subject: Init : someone could comment this ? In-Reply-To: <20080109165258.GD12763@nostromo.devel.redhat.com> References: <20080107173508.GA23429@tango.0pointer.de> <4783A57B.2050005@gmail.com> <4783AA97.8090500@gmail.com> <4783D111.80308@gmail.com> <50837.192.54.193.53.1199868870.squirrel@rousalka.dyndns.org> <20080109165258.GD12763@nostromo.devel.redhat.com> Message-ID: On Wed, 9 Jan 2008, Bill Nottingham wrote: > To put it a different way, the chances of a solution that doesn't at > least support SysV scripts in some compatibility way going into RHEL > is pretty much zero, at least for the first RHEL release that it would > exist in. Sounds like Upstart is the candidate to me... it is Init-compatible but still support its own format too, AFAICS. It will perhaps be superseded by InitKit, but whatever. Linus From triad at df.lth.se Wed Jan 9 23:54:59 2008 From: triad at df.lth.se (Linus Walleij) Date: Thu, 10 Jan 2008 00:54:59 +0100 (CET) Subject: Fedora too cutting edge? In-Reply-To: <20080109200634.GE17953@redhat.com> References: <4785163E.8010508@hhs.nl> <20080109200634.GE17953@redhat.com> Message-ID: On Wed, 9 Jan 2008, John W. Linville wrote: > FWIW, I get criticized for pushing too much brand-new wireless > bits into the Fedora kernels. I, for one, THANK YOU for doing it John, it saved my day and I'm not going to forget that. So keep doing what you're doing. Linus From pertusus at free.fr Wed Jan 9 23:57:14 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 10 Jan 2008 00:57:14 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <20080109234817.GH2664@free.fr> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> <1199919291.25567.10.camel@oneill.fubar.dk> <20080109230642.GD2664@free.fr> <1199921048.25567.21.camel@oneill.fubar.dk> <20080109233027.GF2664@free.fr> <1199921625.25567.24.camel@oneill.fubar.dk> <20080109234817.GH2664@free.fr> Message-ID: <20080109235714.GI2664@free.fr> On Thu, Jan 10, 2008 at 12:48:17AM +0100, Patrice Dumas wrote: > On Wed, Jan 09, 2008 at 06:33:45PM -0500, David Zeuthen wrote: > > > > > > ?You claimed that there was dozens and dozens of people ready to help > > with such tasks. I submit that is not true. I wish it was. > > I am not saying that there are dozens and dozens of people ready to help > for these tasks. I am saying that when there are such people those who > do the mainstream stuff it should let them play instead of being hostile > for parallel/oldish/fun implementations. It has a cost, because there > are always side effects, but it is a price to be paid for community > involvment. It should have been: I am not saying that there are dozens and dozens of people ready to help for these tasks. I am saying that, when there are such people, those who do the mainstream stuff should let them play instead of being hostile for parallel/oldish/fun implementations. It has a cost, because there are always side effects, but it is a price to be paid for community involvment. -- Pat From ajackson at redhat.com Thu Jan 10 00:19:48 2008 From: ajackson at redhat.com (Adam Jackson) Date: Wed, 09 Jan 2008 19:19:48 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <20080109224742.GB2664@free.fr> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> Message-ID: <1199924388.15130.159.camel@localhost.localdomain> On Wed, 2008-01-09 at 23:47 +0100, Patrice Dumas wrote: > On Wed, Jan 09, 2008 at 03:58:45PM -0500, Adam Jackson wrote: > > The complaints up-thread about juju and pulse are entirely valid, but > > the solution is not to try to deliver two things at once. If you try to > > deliver both at once you have to also deliver a way of switching between > > the two. Now you have three moving parts instead of one, which means > > the failure rate has gone up by a factor of _six_ (three parts, and > > three interactions). We have essentially already posited that we have > > insufficient developer effort to have 100%-complete features at ship > > time, so asking them to take on six times the failure rate when they're > > already overburdened is just madness. Alternatively, we could say that > > Who 'essentially already posited that we have insufficient developer > effort'? Who decided that, and for what task? Partly that's just how software _works_. You don't ever ship anything 100% perfect because it's not an achievable goal. But, partly because it's just observed reality of how the project is staffed. For many of the features that people consider vitally important we have at best a small team of contributors. > Isn't the fedora contributors time used like they want to? Oh man. If only. > If there are three parts, and three interactions but dozens of contributors > willing to fix them where is the issue? If the moon were made of cheese, would you eat it? We don't _have_ dozens of contributors willing to fix them. I can count the number of unsolicited X patches I've received from random Fedora people on one hand. Statistically speaking, zero bug reports come with patches attached. Again, this is just a reality of software. Most users are not developers. There is no reason to ever expect this to change. Go read No Silver Bullet again. Software is hard. Complexity is the essence of the problem. Complexity is a handshake problem, n(n-1)/2. You can not just throw manpower at the problem, because the communication problem between the developers is also a handshake problem. The only solution is radical simplicity. I would love it if for every compromise problem like firewire we had a team of people ready to step up and own the transition and all the consequent complexity. We don't. We never will. - ajax From david at fubar.dk Wed Jan 9 23:59:31 2008 From: david at fubar.dk (David Zeuthen) Date: Wed, 09 Jan 2008 18:59:31 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <20080109235714.GI2664@free.fr> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> <1199919291.25567.10.camel@oneill.fubar.dk> <20080109230642.GD2664@free.fr> <1199921048.25567.21.camel@oneill.fubar.dk> <20080109233027.GF2664@free.fr> <1199921625.25567.24.camel@oneill.fubar.dk> <20080109234817.GH2664@free.fr> <20080109235714.GI2664@free.fr> Message-ID: <1199923171.25567.32.camel@oneill.fubar.dk> On Thu, 2008-01-10 at 00:57 +0100, Patrice Dumas wrote: > I am not saying that there are dozens and dozens of people ready to help > for these tasks. I am saying that, when there are such people, those who > do the mainstream stuff should let them play instead of being hostile > for parallel/oldish/fun implementations. It has a cost, because there > are always side effects, but it is a price to be paid for community > involvment. ?Sure, and if I had a pony I'm sure my life would be honky-dory. You're also deliberately ignoring that the issue of qualified man-power is only _one_ aspect of this discussion. David From david at fubar.dk Thu Jan 10 00:02:11 2008 From: david at fubar.dk (David Zeuthen) Date: Wed, 09 Jan 2008 19:02:11 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199923171.25567.32.camel@oneill.fubar.dk> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> <1199919291.25567.10.camel@oneill.fubar.dk> <20080109230642.GD2664@free.fr> <1199921048.25567.21.camel@oneill.fubar.dk> <20080109233027.GF2664@free.fr> <1199921625.25567.24.camel@oneill.fubar.dk> <20080109234817.GH2664@free.fr> <20080109235714.GI2664@free.fr> <1199923171.25567.32.camel@oneill.fubar.dk> Message-ID: <1199923331.25567.35.camel@oneill.fubar.dk> On Wed, 2008-01-09 at 18:59 -0500, David Zeuthen wrote: > On Thu, 2008-01-10 at 00:57 +0100, Patrice Dumas wrote: > > I am not saying that there are dozens and dozens of people ready to help > > for these tasks. I am saying that, when there are such people, those who > > do the mainstream stuff should let them play instead of being hostile > > for parallel/oldish/fun implementations. It has a cost, because there > > are always side effects, but it is a price to be paid for community > > involvment. > > ?Sure, and if I had a pony I'm sure my life would be honky-dory. You're > also deliberately ignoring that the issue of qualified man-power is only > _one_ aspect of this discussion. Uh, I meant. Something about that there are more aspects to this discussion that just man power. Such as even if we had people willing to e.g. maintain two firewire stacks we probably wouldn't want to do that because of the added complexity. Hope this clarifies. David From lesmikesell at gmail.com Thu Jan 10 00:08:13 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 09 Jan 2008 18:08:13 -0600 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <20080109233613.GG2664@free.fr> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> Message-ID: <478561ED.6050605@gmail.com> Patrice Dumas wrote: > >>>> Linux is about choice. >>> If I could only have one thing this year, it would be to eliminate that >>> meme from the collective consciousness. It is a disease. It strangles >>> the mind and ensures you can never change anything ever because someone >>> somewhere has OCD'd their environment exactly how they like it and how >>> dare you change it on them you're so mean and next time I have friends >>> over for Buffy night you're not invited mom he's sitting on my side >>> again. >> Damn you where's my FreeBSD kernel package for Fedora? > > I guess that you are joking, but I think that a FreeBSD kernel package > is perfectly right for fedora. It should not go in a stable release > until it is stable, and could be less well integrated than the linux > kernel but it would definitively be something interesting. > Can we have OpenSolaris (with zfs) too? I was going to point out that Linux wasn't about choice but about providing a free and compatible alternative to Unix. But this would complete the circle... -- Les Mikesell lesmikesell at gmail.com From pertusus at free.fr Thu Jan 10 00:19:41 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 10 Jan 2008 01:19:41 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199924388.15130.159.camel@localhost.localdomain> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> <1199924388.15130.159.camel@localhost.localdomain> Message-ID: <20080110001941.GJ2664@free.fr> On Wed, Jan 09, 2008 at 07:19:48PM -0500, Adam Jackson wrote: > > Partly that's just how software _works_. You don't ever ship anything > 100% perfect because it's not an achievable goal. But, partly because > it's just observed reality of how the project is staffed. For many of > the features that people consider vitally important we have at best a > small team of contributors. In that case let them do what they think best. > > Isn't the fedora contributors time used like they want to? > > Oh man. If only. Not in that sense, of course. What I am saying is that if somebody wants to work on something even if it is not where the main strand of fedora, even if it leads to having parallel stuff he should not be deterred. > > If there are three parts, and three interactions but dozens of contributors > > willing to fix them where is the issue? > > We don't _have_ dozens of contributors willing to fix them. I can count > the number of unsolicited X patches I've received from random Fedora > people on one hand. Statistically speaking, zero bug reports come with > patches attached. Again, this is just a reality of software. Most > users are not developers. There is no reason to ever expect this to > change. I can't see the connection with patches. > Go read No Silver Bullet again. Software is hard. Complexity is the > essence of the problem. Complexity is a handshake problem, n(n-1)/2. That's just untrue. Not everything interacts in complex ways with everything. Also adding some complexity may some time reduce development costs when some comparisons become possible when similar software coexist. > You can not just throw manpower at the problem, because the > communication problem between the developers is also a handshake > problem. The only solution is radical simplicity. It isn't that simple. Do we also want community handle on fedora or not? I really like redhat leadership and innovations, but I don't want to be a puppet either. If people from the community with specific needs and wants are to be accepted in fedora, it means that radical simplicity is not possible. -- Pat From bernie at codewiz.org Thu Jan 10 00:20:41 2008 From: bernie at codewiz.org (Bernardo Innocenti) Date: Wed, 09 Jan 2008 19:20:41 -0500 Subject: PATCH: add --loginpause to mingetty Message-ID: <478564D9.5080303@codewiz.org> Hello Florian, the attached patches add an option to pause login until the user hits a key. We need something like it on OLPC because: - we don't want to set an empty password for either user root or olpc - at the same time, we want to allow users to login as root at the console - finally, we do not wish to waste memory on shells the user hasn't yet used The security model we are implementing is very different from UNIX: we ultimately trust the user at the console, but we don't trust applications and we don't want them to gain root privileges using su or sudo with no password. I'm committing these changes to the OLPC-2 branch of mingetty in Fedora CVS. Please, let me know you'd like to merge them or something similar. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: mingetty-1.07-loginpause.patch Type: text/x-patch Size: 2447 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mingetty-1.07-rpm.patch Type: text/x-patch Size: 1836 bytes Desc: not available URL: From pertusus at free.fr Thu Jan 10 00:23:51 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 10 Jan 2008 01:23:51 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199923331.25567.35.camel@oneill.fubar.dk> References: <20080109224742.GB2664@free.fr> <1199919291.25567.10.camel@oneill.fubar.dk> <20080109230642.GD2664@free.fr> <1199921048.25567.21.camel@oneill.fubar.dk> <20080109233027.GF2664@free.fr> <1199921625.25567.24.camel@oneill.fubar.dk> <20080109234817.GH2664@free.fr> <20080109235714.GI2664@free.fr> <1199923171.25567.32.camel@oneill.fubar.dk> <1199923331.25567.35.camel@oneill.fubar.dk> Message-ID: <20080110002351.GK2664@free.fr> On Wed, Jan 09, 2008 at 07:02:11PM -0500, David Zeuthen wrote: > > Uh, I meant. Something about that there are more aspects to this > discussion that just man power. Such as even if we had people willing to > e.g. maintain two firewire stacks we probably wouldn't want to do that > because of the added complexity. Hope this clarifies. Hope it is untrue. I mean, maybe we wouldn't want to do that because of the added complexity, but this should be discussed and not just dismissed. -- Pat From nphilipp at redhat.com Thu Jan 10 00:26:50 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 10 Jan 2008 01:26:50 +0100 Subject: Init : someone could comment this ? In-Reply-To: <87zlvfdiha.fsf@kosh.bigo.ensc.de> References: <1199550054.2847.1.camel@bureau.maison> <4781DF6F.9090005@ncsu.edu> <878x32q8ao.fsf@fc5.bigo.ensc.de> <200801081901.48083.opensource@till.name> <874pdodugy.fsf@kosh.bigo.ensc.de> <4783C789.5070309@ncsu.edu> <87zlvfdiha.fsf@kosh.bigo.ensc.de> Message-ID: <1199924810.10450.13.camel@gibraltar.str.redhat.com> On Wed, 2008-01-09 at 00:07 +0100, Enrico Scholz wrote: > Casey Dahlin writes: > > >> no; as already written, modern initsystems use non-forking daemons > >> where such checks are not needed anymore. > >> > >> > >> > > It is up to the designer of the app whether it forks or not, and while > > there may be an argument that one way is better or worse, the init > > maintainers cannot guarantee the behavior of that which their system > > must start. > > 1. most (yes, I have numbers) daemons have some kind of --do-not-fork > switch Some (many?) of these log to stdout/stderr if these switches are used as it's assumed you want to debug the program. > 2. most (sorry, I do not have numbers there) daemons have some kind of > bugzilla where you can report patches and enhancements I don't think many of these would subscribe to your notion that doing "prepare -> fork() -> detach" would be erroneous. Good luck, though ;-). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From lesmikesell at gmail.com Thu Jan 10 00:29:44 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 09 Jan 2008 18:29:44 -0600 Subject: Init : someone could comment this ? In-Reply-To: <47854594.7070205@gmail.com> References: <1199550054.2847.1.camel@bureau.maison> <47801DC3.8010104@ncsu.edu> <877iin6y24.fsf@kosh.bigo.ensc.de> <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <1199638106.6022.88.camel@beck.corsepiu.local> <47812D36.4030309@ncsu.edu> <1199880879.5534.210.camel@beck.corsepiu.local> <7f692fec0801090539y4f8aa894i1ace29ab884aa994@mail.gmail.com> <200801091406.m09E6dOe013547@laptop13.inf.utfsm.cl> <47852FB8.6060603@gmail.com> <4785355F.5060302@gmail.com> <47854594.7070205@gmail.com> Message-ID: <478566F8.3070700@gmail.com> Andrew Farris wrote: >> >> And in the case of a laptop, it is fairly likely that you'll want to >> suspend it on one network (wired/wireless or both) and wake it up on >> something different. > > I can understand that as a real complication, but again thats (IMO) > something different than a web server which can work quite well without > a network. The point I was making is that there may be hard and fast > requirements, and there may be 'would be nice' situations... and the > init scripts should only be guaranteed to give the requirement in a > parallelized booting sequence. Beyond that, the other issues need fixed > so that for instance the service DOES start listening when the link goes > active later, rather than blocking or delaying the service from starting > at boot time. Init doesn't need to have much of a part in this but there probably are cases where an ordered sequence of initialization steps need to be managed even if the lower level things are smarter about events. At the moment, I don't think a static IP address or routes through it go away if a link goes down - in fact, it may not even be necessary for them to be assigned which is fairly clearly wrong and likely to cause trouble for newly noticed DHCP assigned interfaces. -- Les Mikesell lesmikesell at gmail.com From johannbg at hi.is Thu Jan 10 00:35:52 2008 From: johannbg at hi.is (=?iso-8859-1?Q?J=F3hann_B._Gu=F0mundsson?=) Date: Thu, 10 Jan 2008 00:35:52 -0000 (GMT) Subject: Fedora too cutting edge? In-Reply-To: <4785163E.8010508@hhs.nl> References: <4785163E.8010508@hhs.nl> Message-ID: <15536.88.149.97.225.1199925352.squirrel@webmail.hi.is> > Hi All, > > One of the few reasons why Fedora is my distro of choice is because its > usually > cutting edge, and I like to be where the development is happening. +1 Likewize.. :> > > However today I've had an encounter with Fedora which make me wonder if > sometimes we aren't a little too cutting edge. I on the other hand think we should be more Cutting edge.. Follow upstream all the way to test3. Release gold with upstream at test3! Some might say it's to little time for proper testing.. Others might say true but then again our target audience is ?, Certainly not regular Joe because then we would be where Ubuntu is now.. Then it's the issue to get everything to latest upstream and get the ball rolling from there.. > Does this mean that Fedora should not have shipped the new stack? No it > doesn't! Getting code out there early into many hands for testing is a > good thing. +1 > > What IMHO we should have done is build both the new and the oldstack, > which is > possible on the kernel side, and modify our patches to userspace to > support the > juju stack, so that the userspace libs can work with either one. On top of > this > we should then have written a small gui utility for easy switching. > > --- I'ts all about giving user a choose ;).. + if things aren't working properly they could fallback on something that does.. > > Another example of Fedora being to cutting edge is pulseaudio, for prove > click > this URL: > https://bugzilla.redhat.com/buglist.cgi?product=Fedora&version=&component=pulseaudio&bug_status=NEW&bug_status=ASSIGNED&bug_status=NEEDINFO&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=FAILS_QA&bug_status=POST&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc= > > Again I think its good to be shipping this, and even that its good having > it on > by default, but we should also provide a small gui utility for easily > turning > ir off. > I have had no problem with Pulseaudio, rather apps that dont support Pulseaudio or have it enabled by default, but since the choice is out there I just use the ones that do.. > Regards, > > Hans Best regards. Johann B. From snecklifter at gmail.com Thu Jan 10 00:41:01 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Thu, 10 Jan 2008 00:41:01 +0000 Subject: thinkpad-acpi upstream version? In-Reply-To: <47852A26.4010609@fedoraproject.org> References: <47852A26.4010609@fedoraproject.org> Message-ID: <364d303b0801091641y763baef2y12a95bde37547c42@mail.gmail.com> On 09/01/2008, Nicolas Antonio Corrarello wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi there, > Maybe I still don't get how upstream works, but I found that the latest > thinkpad-acpi version is 0.19, still Fedora's latest kernel has > [root at localhost ibm]# cat driver > driver: ThinkPad ACPI Extras > version: 0.16 Its built as an in-kernel module so 2.6.23 == 0.16, 2.6.24 == 0.17 and I guess 2.6.25 == 0.19. Cheers -- Christopher Brown http://www.chruz.com From david at fubar.dk Thu Jan 10 00:38:42 2008 From: david at fubar.dk (David Zeuthen) Date: Wed, 09 Jan 2008 19:38:42 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <20080110001941.GJ2664@free.fr> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> <1199924388.15130.159.camel@localhost.localdomain> <20080110001941.GJ2664@free.fr> Message-ID: <1199925522.25567.57.camel@oneill.fubar.dk> On Thu, 2008-01-10 at 01:19 +0100, Patrice Dumas wrote: > It isn't that simple. Do we also want community handle on fedora or > not? I really like redhat leadership and innovations, but I don't want > to be a puppet either. If people from the community with specific needs > and wants are to be accepted in fedora, it means that radical simplicity > is not possible. Oh nice. Now you're playing the "RH vs. community" card. Priceless. News flash: this is _not_ about RH vs. the community. It's about realizing that software development is _hard_. It's about realizing that throwing options and toggles at the problem very very rarely gives you something good. What it does give you is a lot of confused users (look around; we're getting better but it's still really bad) including e.g. UI crap for selecting the driver stack of the week or whatever. This essay is more than five years old http://ometer.com/free-software-ui.html I suggest you read it. It's not completely related to this topic but if you think about it long enough there's some glaring analogies to be made. David From snecklifter at gmail.com Thu Jan 10 00:44:15 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Thu, 10 Jan 2008 00:44:15 +0000 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <1199916701.8159.2.camel@localhost.localdomain> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <20080109094532.811057b2.mschwendt.tmp0701.nospam@arcor.de> <64b14b300801090446u1412557p7bee40aa9922223d@mail.gmail.com> <1199916701.8159.2.camel@localhost.localdomain> Message-ID: <364d303b0801091644s7c9109a8v4b1bfe0f90427cb@mail.gmail.com> On 09/01/2008, Lubomir Kundrak wrote: > > On Wed, 2008-01-09 at 13:46 +0100, Valent Turkovic wrote: > > On 1/9/08, Michael Schwendt wrote: > > > On Wed, 9 Jan 2008 09:20:46 +0100, Valent Turkovic wrote: > > > > > > > Hi, > > > > I saw that Pulse Audio 0.9.8 got released two months ago: > > > > http://pulseaudio.org/milestone/0.9.8 > > > > and I see on my Fedora 8 that we still have 0.9.7 > > > > > > > > $ pulseaudio --version > > > > pulseaudio 0.9.7 > > > > > > > > Will there be an upgrade soon on Fedora 8 to Pulse Audio 0.9.8? > > > > > > > > Lost of issues have been fixed in new Pulse Audio so users like me who > > > > have issues with Pulse Audio would appreciate the much needed upgrade. > > > > > > I'm sure the person who maintains the Fedora packages is aware of that. :) > > > Just notice the connection between Pulse Audio and Red Hat. > > > > I'm sure he is aware of that but I am not - that is why I wrote this email. > > I know the answer -- He decided to save us from an useless upgrade that > would solve none of our problems. This applies for all package > maintainers who value bandwidth and time of the users more than a change > of one digit in a version number -- my thanks to them. That is perhaps one view. Then there will be the people who are running pulseaudio for the first time because it is in Fedora for the first time, reporting bugs, these get resolved and then pushed out to those users who have their bugs fixed and don't give up on Fedora. -- Christopher Brown http://www.chruz.com From cjdahlin at ncsu.edu Thu Jan 10 00:48:34 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Wed, 09 Jan 2008 19:48:34 -0500 Subject: Init : someone could comment this ? In-Reply-To: References: <20080107173508.GA23429@tango.0pointer.de> <4783A57B.2050005@gmail.com> <4783AA97.8090500@gmail.com> <4783D111.80308@gmail.com> <50837.192.54.193.53.1199868870.squirrel@rousalka.dyndns.org> <20080109165258.GD12763@nostromo.devel.redhat.com> Message-ID: <47856B62.7040205@ncsu.edu> Linus Walleij wrote: > On Wed, 9 Jan 2008, Bill Nottingham wrote: > >> To put it a different way, the chances of a solution that doesn't at >> least support SysV scripts in some compatibility way going into RHEL >> is pretty much zero, at least for the first RHEL release that it would >> exist in. > > Sounds like Upstart is the candidate to me... it is Init-compatible > but still support its own format too, AFAICS. It will perhaps be > superseded by InitKit, but whatever. > > Linus > I have been in touch with Scott Remnant, and this is fortunately not true. InitKit is a project to create a standard for event-based activation. The idea is that even if a bunch of distros NIH and implement themselves, upstream can count on certain behaviors. No actual software is planned to emerge from the project. So, one less concern. --CJD From mzerqung at 0pointer.de Thu Jan 10 00:49:41 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Thu, 10 Jan 2008 01:49:41 +0100 Subject: Fedora too cutting edge? In-Reply-To: <4785163E.8010508@hhs.nl> References: <4785163E.8010508@hhs.nl> Message-ID: <20080110004941.GA20965@tango.0pointer.de> On Wed, 09.01.08 19:45, Hans de Goede (j.w.r.degoede at hhs.nl) wrote: > Another example of Fedora being to cutting edge is pulseaudio, for prove > click this URL: > https://bugzilla.redhat.com/buglist.cgi?product=Fedora&version=&component=pulseaudio&bug_status=NEW&bug_status=ASSIGNED&bug_status=NEEDINFO&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=FAILS_QA&bug_status=POST&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc= I don't think this BZ excerpt is any good as argument for your point. A big share of the bugs listed for PA are duplicates. BZ is very good for burying people in vast amount of emails due to new or updated bug reports. My main job is hacking on PA, not wading through BZ. Which is why I tend to ignore bugzilla as good as I can and clean it up only just before every release. Also, even if there were no duplicates and bogus bug reports in this list: I still find 47 bugs quite a low number, given that sound is something everyone uses all the time on the desktop these days. Huge numbers of bugs is more a sign that people are using your software, not necessarily so much that your software is buggy. > Considering the current state of affairs with regards to both features, I > would even like to advocate to make them both optional for Fedora 9. Maybe we should remove the Linux kernel from F9, too. According to your BZ metric it is beyond evil by far. (1611) Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Thu Jan 10 00:52:39 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Thu, 10 Jan 2008 01:52:39 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199914111.25567.4.camel@oneill.fubar.dk> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <1199914111.25567.4.camel@oneill.fubar.dk> Message-ID: <20080110005239.GB20965@tango.0pointer.de> On Wed, 09.01.08 16:28, David Zeuthen (david at fubar.dk) wrote: > Best mail on this list I've ever read. Me too, but I guess I might be a bit biased on this one. ;-) Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From pertusus at free.fr Thu Jan 10 00:57:03 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 10 Jan 2008 01:57:03 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199925522.25567.57.camel@oneill.fubar.dk> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> <1199924388.15130.159.camel@localhost.localdomain> <20080110001941.GJ2664@free.fr> <1199925522.25567.57.camel@oneill.fubar.dk> Message-ID: <20080110005703.GL2664@free.fr> On Wed, Jan 09, 2008 at 07:38:42PM -0500, David Zeuthen wrote: > > On Thu, 2008-01-10 at 01:19 +0100, Patrice Dumas wrote: > > It isn't that simple. Do we also want community handle on fedora or > > not? I really like redhat leadership and innovations, but I don't want > > to be a puppet either. If people from the community with specific needs > > and wants are to be accepted in fedora, it means that radical simplicity > > is not possible. > > Oh nice. Now you're playing the "RH vs. community" card. Priceless. News > flash: this is _not_ about RH vs. the community. It's about realizing > that software development is _hard_. It's about realizing that throwing It is not exactly "RH vs. community". I just want to make sure that things like xdm, initng, fluxbox, compat packages, xpdf or a non linux kernel (all are things that are duplicates of other packages) are still welcomed in fedora. After all it is not necessarily an issue if not, but this should be stated explicitely. My personal understanding of fedora was that a package was accepted as long as it was free software, usable in fedora, and decently integrated. Isn't it still the case? In fact there are already guidelines and FESCo rulings that in my opinion went in that direction (precisely, and if I recall well, the fnord and another package of Enrico that were linked statically against uclibc, and even he demonstrated that there was a performance gain and no security issue they were knocked down). I think that it was a wrong decision, but if it is for corner case it is different than if it becomes the rule. -- Pat From david at fubar.dk Thu Jan 10 01:14:02 2008 From: david at fubar.dk (David Zeuthen) Date: Wed, 09 Jan 2008 20:14:02 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <20080110005703.GL2664@free.fr> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> <1199924388.15130.159.camel@localhost.localdomain> <20080110001941.GJ2664@free.fr> <1199925522.25567.57.camel@oneill.fubar.dk> <20080110005703.GL2664@free.fr> Message-ID: <1199927642.25567.81.camel@oneill.fubar.dk> On Thu, 2008-01-10 at 01:57 +0100, Patrice Dumas wrote: > My personal understanding of fedora was that a package was accepted as > long as it was free software, usable in fedora, and decently integrated. > Isn't it still the case? Sure, live free or die etc. But you cannot expect maintainers of core packages to simply bend over just because you think it's l33t to e.g. have a non Linux kernel. Moreover, I'm pretty sure, by just reading your mails, that you don't realize what using a non Linux kernel even entails. > In fact there are already guidelines and FESCo rulings that in my opinion > went in that direction (precisely, and if I recall well, the fnord and > another package of Enrico that were linked statically against uclibc, > and even he demonstrated that there was a performance gain and no > security issue they were knocked down). I think that it was a wrong > decision, but if it is for corner case it is different than if it > becomes the rule. Ooo.. here's the "it's in the guidelines so do as I say" card. Annoying. Seriously. People. What the hell happened to simplicity and building a free OS for the world that just works? Is the state of Fedora really in such a bad shape that people think it's necessary have craptastic options like "what kernel would you like today?". Seriously, things like that is just masturbation and we in Fedora should be above that. I feel that people wanting this are treating Fedora like it's a playground for their Toy OS ideas. Playing classic cards like "RH vs. community" and "this or that committee says so" to justify their "ideas". It's seriously tiring. Is this what Fedora is becoming? Because if it is, I'll find something else to spend my time on. David From snecklifter at gmail.com Thu Jan 10 01:21:26 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Thu, 10 Jan 2008 01:21:26 +0000 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <20080110005703.GL2664@free.fr> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> <1199924388.15130.159.camel@localhost.localdomain> <20080110001941.GJ2664@free.fr> <1199925522.25567.57.camel@oneill.fubar.dk> <20080110005703.GL2664@free.fr> Message-ID: <364d303b0801091721q5d928b6er2508e923954b1061@mail.gmail.com> On 10/01/2008, Patrice Dumas wrote: > On Wed, Jan 09, 2008 at 07:38:42PM -0500, David Zeuthen wrote: > > > > On Thu, 2008-01-10 at 01:19 +0100, Patrice Dumas wrote: > > > It isn't that simple. Do we also want community handle on fedora or > > > not? I really like redhat leadership and innovations, but I don't want > > > to be a puppet either. If people from the community with specific needs > > > and wants are to be accepted in fedora, it means that radical simplicity > > > is not possible. > > > > Oh nice. Now you're playing the "RH vs. community" card. Priceless. News > > flash: this is _not_ about RH vs. the community. It's about realizing > > that software development is _hard_. It's about realizing that throwing > > It is not exactly "RH vs. community". I just want to make sure that > things like xdm, initng, fluxbox, compat packages, xpdf or a non linux > kernel (all are things that are duplicates of other packages) are still > welcomed in fedora. After all it is not necessarily an issue if not, but > this should be stated explicitely. > > My personal understanding of fedora was that a package was accepted as > long as it was free software, usable in fedora, and decently integrated. > Isn't it still the case? Of course but at some point, particularly with something such as separate subsystem stacks in the kernel, someone has to make a technical choice. In this instance JuJu was enabled in 7+ with the intention to work with the maintainers to resolve issues as they arose. Firewire in Linux is a mess but it is improving, thanks largely to the JuJu team and if I may say, the inclusion of said stack in Fedora. One of the maintainers is extremely active on the Fedora bugzilla. So when those qualified to do so make that choice, they are merely set as defaults. If you want the old firewire stack there are third party repos rolling kernels with it included. If you want xpdf over evince then you can have that as well. Some software such as fluxbox caters for smaller markets so it won't ever be default but as long as it works for what it does it will be there. That is what a distribution is essentially - a set of software packages deemed to be the best in class. It won't suit everyone but it should suit most. 80/20 rule and all that. Cheers -- Christopher Brown http://www.chruz.com From snecklifter at gmail.com Thu Jan 10 01:34:00 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Thu, 10 Jan 2008 01:34:00 +0000 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199927642.25567.81.camel@oneill.fubar.dk> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> <1199924388.15130.159.camel@localhost.localdomain> <20080110001941.GJ2664@free.fr> <1199925522.25567.57.camel@oneill.fubar.dk> <20080110005703.GL2664@free.fr> <1199927642.25567.81.camel@oneill.fubar.dk> Message-ID: <364d303b0801091734nd0896cex47cdcd9917993331@mail.gmail.com> On 10/01/2008, David Zeuthen wrote: > > On Thu, 2008-01-10 at 01:57 +0100, Patrice Dumas wrote: > > My personal understanding of fedora was that a package was accepted as > > long as it was free software, usable in fedora, and decently integrated. > > Isn't it still the case? > > Sure, live free or die etc. But you cannot expect maintainers of core > packages to simply bend over just because you think it's l33t to e.g. > have a non Linux kernel. Moreover, I'm pretty sure, by just reading your > mails, that you don't realize what using a non Linux kernel even > entails. > > > In fact there are already guidelines and FESCo rulings that in my opinion > > went in that direction (precisely, and if I recall well, the fnord and > > another package of Enrico that were linked statically against uclibc, > > and even he demonstrated that there was a performance gain and no > > security issue they were knocked down). I think that it was a wrong > > decision, but if it is for corner case it is different than if it > > becomes the rule. > > Ooo.. here's the "it's in the guidelines so do as I say" card. Annoying. > > Seriously. People. What the hell happened to simplicity and building a > free OS for the world that just works? Is the state of Fedora really in > such a bad shape that people think it's necessary have craptastic > options like "what kernel would you like today?". Seriously, things like > that is just masturbation and we in Fedora should be above that. I feel > that people wanting this are treating Fedora like it's a playground for > their Toy OS ideas. Playing classic cards like "RH vs. community" and > "this or that committee says so" to justify their "ideas". It's > seriously tiring. Is this what Fedora is becoming? Because if it is, > I'll find something else to spend my time on. Not sure how arguing over kernel builds is akin to wanking but really this is a "My $DEVICE wont work under Linux" thread that should have started as a bz entry and has gotten out of hand so don't get too disheartened. -- Christopher Brown http://www.chruz.com From nando at ccrma.Stanford.EDU Thu Jan 10 01:38:16 2008 From: nando at ccrma.Stanford.EDU (Fernando Pablo Lopez-Lezcano) Date: Wed, 9 Jan 2008 17:38:16 -0800 (PST) Subject: Fedora too cutting edge? In-Reply-To: <4785163E.8010508@hhs.nl> References: <4785163E.8010508@hhs.nl> Message-ID: On Wed, 9 Jan 2008, Hans de Goede wrote: > Hi All, > > One of the few reasons why Fedora is my distro of choice is because its > usually cutting edge, and I like to be where the development is happening. > > However today I've had an encounter with Fedora which make me wonder if > sometimes we aren't a little too cutting edge. I tried to get an industrial > firewire camera to work with the stock Fedora kernel using the juju stack. > Long story short, it didn't work. > > Which after reading: http://wiki.linux1394.org/JujuMigration Isn't really > surprising, quoting that page: "Almost no support for IIDC cameras: Not > compatible with libdc1394 v1. Highly experimental support in libdc1394 v2 > which works with some luck on only a few OHCI 1.1 controllers. Improvements > are to be expected in Linux 2.6.25-rc1." > > Notice how a preliminary fix is expected for 2.6.25, which probably means > that this will still be broken in Fedora 9, notice that the breakage was > introduced in Fedora 7, so thats 18 months worth of broken firewire camera > support (iow most digital video cameras). _and_ firewire audio interfaces as well. Which forced me and others to return to the original stack in my realtime tuned kernels for Planet CCRMA. And unpatch the corresponding libraries. And keep track of the whole mess. A royal pain you know where. Planet CCRMA is about audio. Non working interfaces that were working before is not good. If you ask me, 18 months is way too long. It is/was a failed experiment. > Add to that that the above > referenced wiki page also says: "Regarding Linux 2.6.22 and 2.6.23, the best > advice to Linux distributors (kernel packagers) ... is: Build only the old > IEEE 1394 drivers." > > Does this mean that Fedora should not have shipped the new stack? No it > doesn't! Ahem, sorry but no. It should not have in the condition it was. > Getting code out there early into many hands for testing is a good > thing. The balance between cutting edge and usability is subjective. My opinion is that the new stack was not and still is not ready for inclusion in a mainstream distro. It just breaks too many things that people actually need to do work on the computer running that kernel. > What IMHO we should have done is build both the new and the oldstack, which > is possible on the kernel side, and modify our patches to userspace to > support the juju stack, so that the userspace libs can work with either one. > On top of this we should then have written a small gui utility for easy > switching. Yup. Or wait till the stack actually works. But then a big chorus will probably say if we don't ship it it will not get fixed or whatever. But it has been shipped for a long time and not fixed so I _don't_ buy that argument. Most probably it just makes real users migrate somewhere else. Frankly that kind of stuff makes _me_ wonder about Planet CCRMA and where it should go. The only thing that stops me from moving somewhere else is the realization that migration would be in the short term a lot lot more work than working around the issue. Maybe it would be smarter in the long term, who knows. Sigh. > --- > > Another example of Fedora being to cutting edge is pulseaudio, for prove > click this URL: > https://bugzilla.redhat.com/buglist.cgi?product=Fedora&version=&component=pulseaudio&bug_status=NEW&bug_status=ASSIGNED&bug_status=NEEDINFO&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=FAILS_QA&bug_status=POST&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc= > > Again I think its good to be shipping this, and even that its good having it > on by default, but we should also provide a small gui utility for easily > turning ir off. > > --- > > Considering the current state of affairs with regards to both features, I > would even like to advocate to make them both optional for Fedora 9. Agreed... At least firewire has been broken for too long (IMHO) -- Fernando From david at fubar.dk Thu Jan 10 01:37:20 2008 From: david at fubar.dk (David Zeuthen) Date: Wed, 09 Jan 2008 20:37:20 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <364d303b0801091734nd0896cex47cdcd9917993331@mail.gmail.com> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> <1199924388.15130.159.camel@localhost.localdomain> <20080110001941.GJ2664@free.fr> <1199925522.25567.57.camel@oneill.fubar.dk> <20080110005703.GL2664@free.fr> <1199927642.25567.81.camel@oneill.fubar.dk> <364d303b0801091734nd0896cex47cdcd9917993331@mail.gmail.com> Message-ID: <1199929040.25567.88.camel@oneill.fubar.dk> On Thu, 2008-01-10 at 01:34 +0000, Christopher Brown wrote: > Not sure how arguing over kernel builds is akin to wanking but really > this is a "My $DEVICE wont work under Linux" thread that should have > started as a bz entry and has gotten out of hand so don't get too > disheartened. Maybe it wasn't clear but with ?"what kernel would you like today" I meant things like "do you want a FreeBSD or Linux" kernel. The very idea of supporting that kind of thing in Fedora is, at least from my neck of the woods, pure crack. David From lordmorgul at gmail.com Thu Jan 10 01:50:29 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 09 Jan 2008 17:50:29 -0800 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <364d303b0801091721q5d928b6er2508e923954b1061@mail.gmail.com> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> <1199924388.15130.159.camel@localhost.localdomain> <20080110001941.GJ2664@free.fr> <1199925522.25567.57.camel@oneill.fubar.dk> <20080110005703.GL2664@free.fr> <364d303b0801091721q5d928b6er2508e923954b1061@mail.gmail.com> Message-ID: <478579E5.4010104@gmail.com> Christopher Brown wrote: > On 10/01/2008, Patrice Dumas wrote: >> On Wed, Jan 09, 2008 at 07:38:42PM -0500, David Zeuthen wrote: >>> On Thu, 2008-01-10 at 01:19 +0100, Patrice Dumas wrote: >>>> It isn't that simple. Do we also want community handle on fedora or >>>> not? I really like redhat leadership and innovations, but I don't want >>>> to be a puppet either. If people from the community with specific needs >>>> and wants are to be accepted in fedora, it means that radical simplicity >>>> is not possible. >>> Oh nice. Now you're playing the "RH vs. community" card. Priceless. News >>> flash: this is _not_ about RH vs. the community. It's about realizing >>> that software development is _hard_. It's about realizing that throwing >> It is not exactly "RH vs. community". I just want to make sure that >> things like xdm, initng, fluxbox, compat packages, xpdf or a non linux >> kernel (all are things that are duplicates of other packages) are still >> welcomed in fedora. After all it is not necessarily an issue if not, but >> this should be stated explicitely. >> >> My personal understanding of fedora was that a package was accepted as >> long as it was free software, usable in fedora, and decently integrated. >> Isn't it still the case? > > Of course but at some point, particularly with something such as > separate subsystem stacks in the kernel, someone has to make a > technical choice. In this instance JuJu was enabled in 7+ with the > intention to work with the maintainers to resolve issues as they > arose. Firewire in Linux is a mess but it is improving, thanks largely > to the JuJu team and if I may say, the inclusion of said stack in > Fedora. One of the maintainers is extremely active on the Fedora > bugzilla. I think here (Christopher says it well) is the most salient point on 'is it welcome or not'... the problem that started the thread (JuJu new vs old stack) was simply the primary maintainer choosing to go with new, and if anyone (other than that maintainer who chose not to) had provided the appropriate compatibility/switching/coexistence patches to have both available I am pretty certain that it could have and would have been done. I mean look at the history and how long the simple mta switcher app survives because someone provided it when other options than sendmail were available. So Patrice I think the answer is and always will be 'its welcome' but the issue is who will do it. When that choice (or any other hard choice of innovation vs current working compatibility) is made it is up to those who need current compatibility to help keep it available. As others have said in the thread to plan on the primary maintainers handling it in a 'keep everything forever' fashion is guaranteed to be madness and a big failure. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From kevin.kofler at chello.at Thu Jan 10 01:51:54 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 10 Jan 2008 01:51:54 +0000 (UTC) Subject: Fedora too cutting edge? References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> Message-ID: Thorsten Leemhuis leemhuis.info> writes: > See below. But actually I think we here and there are not even cutting > edge enough; we for example left users on Firefox2 for FC6 for about 7 > months until we shipped F7 -- that looked totally odd for a distribution > that is curring edge in most other areas. I didn't quite understand the rationale there either. At least Remi Collet made a great job making Firefox 2 available for FC6 in his repo. > Another example: hplip is still on 2.7.7 for F8 right now while upstream > is at 2.7.12 in between and supports 22 new printers ( > http://hplip.sourceforge.net/release_notes.html ). We don't provide any > solutions for users that buy those printers right now besides using > rawhide. Thus they have to wait/ask for a proper update or wait until F9 > or -- the latter means waiting about 6 months for driver. That's IMHO > unacceptable -- especially as printer manufacturers release successor > models quite often (it feels to me like a new successor model get > released in each printer class about once a year, but I didn't check). With HP printers, usually the successor model works just fine if you pass it off as its predecessor. Kevin Kofler From kevin.kofler at chello.at Thu Jan 10 01:57:23 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 10 Jan 2008 01:57:23 +0000 (UTC) Subject: Fedora too cutting edge? References: <4785163E.8010508@hhs.nl> <20080109200634.GE17953@redhat.com> Message-ID: John W. Linville redhat.com> writes: > FWIW, I get criticized for pushing too much brand-new wireless > bits into the Fedora kernels. Simultaneously (often the very same > days) I get criticized for taking more than a day or two to get new > upstream wireless patches merged into the Fedora kernels. There is > no winning... I think you're doing the right thing, these backports are the reason wireless works for much more people on Fedora than on the average other distro. And that despite Fedora not including proprietary junk like madwifi (what's the state of ath5k by the way?) or ndiswrapper (yuck!). Kevin Kofler From wtogami at redhat.com Thu Jan 10 02:16:03 2008 From: wtogami at redhat.com (Warren Togami) Date: Wed, 09 Jan 2008 21:16:03 -0500 Subject: Impending X driver deprecation In-Reply-To: <1199906969.15130.40.camel@localhost.localdomain> References: <1199906969.15130.40.camel@localhost.localdomain> Message-ID: <47857FE3.7050000@redhat.com> Adam Jackson wrote: > I'm grinding through porting the various X drivers to the new server > APIs, and I'm taking the opportunity to clean house a bit. Here's what > I'm planning: > http://www.x.org/wiki/AMDGeodeDriver Could you help to port the AMD Geode driver to newer API's? It is a very common chipset used in thin client hardware (as well as OLPC). > > The ark, chips, s3, and tseng drivers are going away. These are all > really boring early PCI chipsets that don't even have a 3d engine. They > should be adequately serviced by the vesa driver. (Note that there are > three drivers for the various S3 cards: s3, s3virge, and savage. s3 is > for the old pre-Virge chips, 968 and Trio and friends. s3virge and > savage are not being dropped.) Please reconsider s3? It is used by several of the thin client models selling today, and Intel's "Affordable PC" reference platform that is being sold in large numbers in the developing world (e.g. China) by companies like Dell. Warren Togami wtogami at redhat.com From jkeating at redhat.com Thu Jan 10 02:24:55 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 9 Jan 2008 21:24:55 -0500 Subject: Impending X driver deprecation In-Reply-To: <47857FE3.7050000@redhat.com> References: <1199906969.15130.40.camel@localhost.localdomain> <47857FE3.7050000@redhat.com> Message-ID: <20080109212455.0dd3da54@redhat.com> On Wed, 09 Jan 2008 21:16:03 -0500 Warren Togami wrote: > Please reconsider s3? > > It is used by several of the thin client models selling today, and > Intel's "Affordable PC" reference platform that is being sold in > large numbers in the developing world (e.g. China) by companies like > Dell. Why do you need a specific driver for these instead of Vesa? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wtogami at redhat.com Thu Jan 10 02:36:14 2008 From: wtogami at redhat.com (Warren Togami) Date: Wed, 09 Jan 2008 21:36:14 -0500 Subject: Impending X driver deprecation In-Reply-To: <20080109212455.0dd3da54@redhat.com> References: <1199906969.15130.40.camel@localhost.localdomain> <47857FE3.7050000@redhat.com> <20080109212455.0dd3da54@redhat.com> Message-ID: <4785849E.7080208@redhat.com> Jesse Keating wrote: > On Wed, 09 Jan 2008 21:16:03 -0500 > Warren Togami wrote: > >> Please reconsider s3? >> >> It is used by several of the thin client models selling today, and >> Intel's "Affordable PC" reference platform that is being sold in >> large numbers in the developing world (e.g. China) by companies like >> Dell. > > Why do you need a specific driver for these instead of Vesa? I was under the impression that performance is much more usable with s3 than vesa, especially on very slow machines like these. I will not be able to test it until I get back from Raleigh late next week. (*WHY* does Intel's APC have such a crappy non-Intel video card?) Warren Togami wtogami at redhat.com From tibbs at math.uh.edu Thu Jan 10 02:58:54 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 09 Jan 2008 20:58:54 -0600 Subject: Review swaps In-Reply-To: <7f692fec0801081027y2feb7f6re5ac610cc09e30cb@mail.gmail.com> References: <870180fe0801071430q6d01ccf1j252ae475ee3f68f3@mail.gmail.com> <870180fe0801071520r16ee79c6i2d86ea84fad086d5@mail.gmail.com> <7f692fec0801081027y2feb7f6re5ac610cc09e30cb@mail.gmail.com> Message-ID: >>>>> "YN" == Yaakov Nemoy writes: YN> I've banged out some bad guidelines for Haskell packaging. It would help to have a copy of these in the wiki (and the URL, of course). The packaging committee wil meet January 22nd so we can discuss it then but it would be good to have a look well before then. - J< From sundaram at fedoraproject.org Thu Jan 10 02:54:13 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 10 Jan 2008 08:24:13 +0530 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <478561ED.6050605@gmail.com> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> Message-ID: <478588D5.5000909@fedoraproject.org> Les Mikesell wrote: > Can we have OpenSolaris (with zfs) too? I was going to point out that > Linux wasn't about choice but about providing a free and compatible > alternative to Unix. But this would complete the circle... You can have a lot of things if you step up to contribute. Wishlists are already overflowing. Rahul From mrmazda at ij.net Thu Jan 10 03:36:20 2008 From: mrmazda at ij.net (Felix Miata) Date: Wed, 09 Jan 2008 22:36:20 -0500 Subject: Impending X driver deprecation In-Reply-To: <1199906969.15130.40.camel@localhost.localdomain> References: <1199906969.15130.40.camel@localhost.localdomain> Message-ID: <478592B4.8080109@ij.net> On 2008/01/09 14:29 (GMT-0500) Adam Jackson apparently typed: > The ark, chips, s3, and tseng drivers are going away. > If you object to any part of this plan, speak loudly, now. Tseng ET6x00 made one of the best price to performance ratio low/mid cost PCI gfxcards ever made. They're highly suitable for forced system upgraders stuck with no AGP slots, no need for 3D silliness, or money to waste on expensive PCIx cards they have no use for. They also provide DOS support equalled only by the lowly Trident chips that doesn't exist at even a minimalist level in current chips. I still have about 8 ET6x00 in functional machines. So as to Tseng, I object X8. -- "In the beginning was the Word, and the Word was with God, and the Word was God." John 1:1 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/ From cra at WPI.EDU Thu Jan 10 03:44:39 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 9 Jan 2008 22:44:39 -0500 Subject: Fedora too cutting edge? In-Reply-To: References: <4785163E.8010508@hhs.nl> <20080109200634.GE17953@redhat.com> Message-ID: <20080110034439.GP8487@angus.ind.WPI.EDU> On Thu, Jan 10, 2008 at 01:57:23AM +0000, Kevin Kofler wrote: > despite Fedora not including proprietary junk like madwifi (what's the state of > ath5k by the way?) ath5k Works for me(TM), NM 0.7 EAP-TLS, with a few issues after suspend/resume. From loupgaroublond at gmail.com Thu Jan 10 04:13:47 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 9 Jan 2008 23:13:47 -0500 Subject: Review swaps In-Reply-To: References: <870180fe0801071430q6d01ccf1j252ae475ee3f68f3@mail.gmail.com> <870180fe0801071520r16ee79c6i2d86ea84fad086d5@mail.gmail.com> <7f692fec0801081027y2feb7f6re5ac610cc09e30cb@mail.gmail.com> Message-ID: <7f692fec0801092013n105d224dmb88d99ab164170c0@mail.gmail.com> On 09 Jan 2008 20:58:54 -0600, Jason L Tibbitts III wrote: > >>>>> "YN" == Yaakov Nemoy writes: > > YN> I've banged out some bad guidelines for Haskell packaging. > > It would help to have a copy of these in the wiki (and the URL, of > course). > > The packaging committee wil meet January 22nd so we can discuss it > then but it would be good to have a look well before then. Oh, sorry, here they are, http://fedoraproject.org/wiki/Features/GoodHaskellSupport http://fedoraproject.org/wiki/PackagingDrafts/Haskell -Yaakov From notting at redhat.com Thu Jan 10 04:59:24 2008 From: notting at redhat.com (Bill Nottingham) Date: Wed, 9 Jan 2008 23:59:24 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <47854276.7060101@leemhuis.info> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <47853A21.4020204@leemhuis.info> <20080109213752.GA3286@nostromo.devel.redhat.com> <47854276.7060101@leemhuis.info> Message-ID: <20080110045924.GA21600@nostromo.devel.redhat.com> Thorsten Leemhuis (fedora at leemhuis.info) said: > > Right now DRI/DRM breaks VT switch and suspend on my laptop. Should we > > ship two Intel drivers and two kernels until this is resolved? [...] > > Bugs in a updated package are something totally different (everyone > tries to avoid them, but they happen, so we have to live with them) then > switching to a new completely firewire stack that doesn't support > everything yet what the old stack did. By this logic, we should have enabled both old IDE and libata and let the users choose between them at runtime as well. The way to have a reliable core system is to pick a single supported interface and fix it. As far as I can tell, the firewire stack now works, except for an issue with one hardware chipset. While that is not good for users who have that chipset, it's certainly about par for the course with many other drivers we have, and I don't see why that should mean that the whole thing should be switched out. Bill From fedora at leemhuis.info Thu Jan 10 06:03:05 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 10 Jan 2008 07:03:05 +0100 Subject: regressions (was: Re: Linux is not about choice [was Re: Fedora too cutting edge?]) In-Reply-To: <20080110045924.GA21600@nostromo.devel.redhat.com> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <47853A21.4020204@leemhuis.info> <20080109213752.GA3286@nostromo.devel.redhat.com> <47854276.7060101@leemhuis.info> <20080110045924.GA21600@nostromo.devel.redhat.com> Message-ID: <4785B519.3070907@leemhuis.info> On 10.01.2008 05:59, Bill Nottingham wrote: > Thorsten Leemhuis (fedora at leemhuis.info) said: >>> Right now DRI/DRM breaks VT switch and suspend on my laptop. Should we >>> ship two Intel drivers and two kernels until this is resolved? [...] >> Bugs in a updated package are something totally different (everyone >> tries to avoid them, but they happen, so we have to live with them) then >> switching to a new completely firewire stack that doesn't support >> everything yet what the old stack did. > By this logic, we should have enabled both old IDE and libata and > let the users choose between them at runtime as well. Not sure about this one -- Alan afaics did a lot of work to make sure everything crucial worked with the new libata PATA driver on those systems I used. Sure, there were bugs, but there are bug in every software and Alan tried its best to fix them quickly. But yeah, maybe enabling both old IDE and libata (with defaulting to libata) for one release might have made sense. At least it made for OpenSuse, as that's what they did afaik. Sure, it's more work for one release, but if that is needed to support all systems that were supported earlier then it might be worth the trouble. > The way to have a reliable core system is to pick a single supported > interface and fix it. Totally agreed in general. But sometimes it's not easily possible when switching from foo to bar (be it the old firewire stack and juju or IDE and libata). > As far as I can tell, the firewire stack now > works, except for an issue with one hardware chipset. Now: seems so afaics. But when it was new it was a regression for quite a bunch of people. That's bad and we should avoid regressions as much as possible. Just like the kernel developers do -- Torvalds on lkml yells loudly if there is a regression. He sometimes even reverts patches that made the situation better for a lot of people if it is a regression for a quite small group of existing users. I think we need similar rules, as people will otherwise turn away from Fedora to something that just works for them; otherwise everyone will continue to say "Fedora is a Beta for RHEL" is we don#t take our userbase serious. CU knurd From fedora at leemhuis.info Thu Jan 10 06:06:12 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 10 Jan 2008 07:06:12 +0100 Subject: Fedora too cutting edge? In-Reply-To: References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> Message-ID: <4785B5D4.40102@leemhuis.info> On 10.01.2008 02:51, Kevin Kofler wrote: > Thorsten Leemhuis leemhuis.info> writes: >> Another example: hplip is still on 2.7.7 for F8 right now while upstream >> is at 2.7.12 in between and supports 22 new printers ( >> http://hplip.sourceforge.net/release_notes.html ). We don't provide any >> solutions for users that buy those printers right now besides using >> rawhide. Thus they have to wait/ask for a proper update or wait until F9 >> or -- the latter means waiting about 6 months for driver. That's IMHO >> unacceptable -- especially as printer manufacturers release successor >> models quite often (it feels to me like a new successor model get >> released in each printer class about once a year, but I didn't check). > With HP printers, usually the successor model works just fine if you pass it > off as its predecessor. We might know that. But most random users might not. An it's just "usually" and not "always". CU knurd From fedora at leemhuis.info Thu Jan 10 06:11:43 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 10 Jan 2008 07:11:43 +0100 Subject: Impending X driver deprecation In-Reply-To: <4785849E.7080208@redhat.com> References: <1199906969.15130.40.camel@localhost.localdomain> <47857FE3.7050000@redhat.com> <20080109212455.0dd3da54@redhat.com> <4785849E.7080208@redhat.com> Message-ID: <4785B71F.3050906@leemhuis.info> On 10.01.2008 03:36, Warren Togami wrote: > Jesse Keating wrote: >> On Wed, 09 Jan 2008 21:16:03 -0500 >> Warren Togami wrote: >> >>> Please reconsider s3? >>> >>> It is used by several of the thin client models selling today, and >>> Intel's "Affordable PC" reference platform that is being sold in >>> large numbers in the developing world (e.g. China) by companies like >>> Dell. Are you sure it's s3? It's IIRC a SiS-Chipset. See http://www.sis.com/pressroom/pressrelease_000287.htm [...] Another best-value PC solution presented at IDF is Dell?s Affordable PC (APC) EC280, which is developed by SiS and Dell for the emerging market. The Dell EC280 adopts the SiSM661GX chipset to support Intel FSB533MHz CPU and DDR 333 memory. [...] SiSM661GX is driven by xorg-x11-drv-sis > (*WHY* does Intel's APC have such a crappy non-Intel video card?) That's a interesting question :)) CU knurd From jdieter at gmail.com Thu Jan 10 07:59:48 2008 From: jdieter at gmail.com (Jonathan Dieter) Date: Thu, 10 Jan 2008 09:59:48 +0200 Subject: Fedora too cutting edge? In-Reply-To: <20080110004941.GA20965@tango.0pointer.de> References: <4785163E.8010508@hhs.nl> <20080110004941.GA20965@tango.0pointer.de> Message-ID: <1199951988.1742.18.camel@jndwidescreen.lesbg.loc> On Thu, 2008-01-10 at 01:49 +0100, Lennart Poettering wrote: > I don't think this BZ excerpt is any good as argument for your > point. A big share of the bugs listed for PA are duplicates. BZ is > very good for burying people in vast amount of emails due to new or > updated bug reports. My main job is hacking on PA, not wading through > BZ. Which is why I tend to ignore bugzilla as good as I can and clean > it up only just before every release. I really appreciate what you do with pulseaudio, but I'm not quite sure what to make of this comment. What do you want us to do if we come across a pulseaudio bug? For example, when pulseaudio is running as a system-wide daemon, any games using Alsa start to stutter after a few minutes. In single-user mode, they work perfectly. I opened a bug for this a month ago ( https://bugzilla.redhat.com/show_bug.cgi?id=417681 ), and I've not gotten any response yet. Now I realize this is probably a low-priority for you, but I guess I was hoping for at least an ACK. Will you eventually get around to looking at it or is BZ redirected to /dev/null for you (which is how I read the above excerpt, though it may not be what you meant). Please understand I'm not trying to jump on you, I just want to know the best way of reporting a bug to you. Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From j.w.r.degoede at hhs.nl Thu Jan 10 08:40:30 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 10 Jan 2008 09:40:30 +0100 Subject: Impending X driver deprecation In-Reply-To: <47857FE3.7050000@redhat.com> References: <1199906969.15130.40.camel@localhost.localdomain> <47857FE3.7050000@redhat.com> Message-ID: <4785D9FE.7070902@hhs.nl> > Adam Jackson wrote: > I'm grinding through porting the various X drivers to the new server > APIs, and I'm taking the opportunity to clean house a bit. Here's what > I'm planning: > > The ark, chips, s3, and tseng drivers are going away. These are all > really boring early PCI chipsets that don't even have a 3d engine. They > should be adequately serviced by the vesa driver. (Note that there are > three drivers for the various S3 cards: s3, s3virge, and savage. s3 is > for the old pre-Virge chips, 968 and Trio and friends. s3virge and > savage are not being dropped.) > Sorry for not properly replying to the top post, I already deleted it when I thought of this. I used to be the happy owner of a couple of s3 864 and trio64 cards back in the days, and I'm afraid the contigency plan of moving these over to vesa will not work. There BIOS's did not have vesa support, you needed to load a vesa driver (tsr) under dos to be able to use the vesa modes from dos programs. I still remember being amazed by some of the later cards actually having vesa in the bios, but those early cards did _not_ have vesa support in the bios. Regards, Hans From tmraz at redhat.com Thu Jan 10 08:49:52 2008 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 10 Jan 2008 09:49:52 +0100 Subject: Init : someone could comment this ? In-Reply-To: <20080109234605.GB16506@tango.0pointer.de> References: <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <1199638106.6022.88.camel@beck.corsepiu.local> <47812D36.4030309@ncsu.edu> <1199880879.5534.210.camel@beck.corsepiu.local> <7f692fec0801090539y4f8aa894i1ace29ab884aa994@mail.gmail.com> <200801091406.m09E6dOe013547@laptop13.inf.utfsm.cl> <47852FB8.6060603@gmail.com> <4785355F.5060302@gmail.com> <47854594.7070205@gmail.com> <47854C7B.2000303@wolves.durham.nc.us> <20080109234605.GB16506@tango.0pointer.de> Message-ID: <1199954992.18322.83.camel@vespa.frost.loc> On Thu, 2008-01-10 at 00:46 +0100, Lennart Poettering wrote: > On Wed, 09.01.08 17:36, G.Wolfe Woodbury (ggw at wolves.durham.nc.us) wrote: > > > >> What happens in practice, though, is that things that expect network > > >> services to be running will do DNS lookups, hanging for minutes at at > > >> time when there is no response. > > > > > > Looks like a good way to identify bugs to me... the DNS hang needs > > > fixed, not worked around. > > > > One major help would be for Fedora to _not_ mangle the localhost line in > > /etc/hosts. This has casued me several headaches until I learned to > > remove the local realname from the default localhost line. > > > > Sure, its not technically incorrect, but its not nice when you've got > > static addresses on a LAN. > > Although this is totally off-topic: I still think the proper fix is > something like this: > > http://0pointer.de/lennart/projects/nss-myhostname/ > http://0pointer.de/lennart/projects/nss-myhostname/README.txt > > I wrote that a while back. Maybe someone wants to dust this off and > get it into Fedora and activated by default? > > This saved me a couple of times on embedded boxes, where each of the > devices used a different hostname and I had to guarantee that the > hostname stayed resolvable in all cases, with a ro root directory. This seems like a nice idea - actually even better idea would be to be able to pass some arguments to modules in nsswitch.conf and then simply put: hosts: files dns files(conf=/etc/hosts-fallback) The first files module would look into the regular /etc/hosts and the second one into the /etc/hosts-fallback. But since there is no () syntax in nsswitch.conf currently, and the modules are not parametrized, your special module would work too. Also your proposed module has an advantage that it doesn't have to be configured in any way. So what about including this module in Fedora? -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From mschwendt.tmp0701.nospam at arcor.de Thu Jan 10 08:54:34 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 10 Jan 2008 09:54:34 +0100 Subject: Crashes in OpenLDAP and Sylpheed Message-ID: <20080110095434.312331ba.mschwendt.tmp0701.nospam@arcor.de> https://bugzilla.redhat.com/361461 contains two different backtraces for segfaults on x86_64, once in OpenLDAP and another time in Sylpheed's LDAP code. I'm still unable to reproduce this on x86, and upstream couldn't either yet. Can anyone else reproduce this at least? Proof-reading the code I've found memory leaks and other issues, but not the reason that would make the code crash as in the backtrace. From pertusus at free.fr Thu Jan 10 09:17:41 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 10 Jan 2008 10:17:41 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199927642.25567.81.camel@oneill.fubar.dk> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> <1199924388.15130.159.camel@localhost.localdomain> <20080110001941.GJ2664@free.fr> <1199925522.25567.57.camel@oneill.fubar.dk> <20080110005703.GL2664@free.fr> <1199927642.25567.81.camel@oneill.fubar.dk> Message-ID: <20080110091741.GA2556@free.fr> On Wed, Jan 09, 2008 at 08:14:02PM -0500, David Zeuthen wrote: > > On Thu, 2008-01-10 at 01:57 +0100, Patrice Dumas wrote: > > My personal understanding of fedora was that a package was accepted as > > long as it was free software, usable in fedora, and decently integrated. > > Isn't it still the case? > > Sure, live free or die etc. But you cannot expect maintainers of core > packages to simply bend over just because you think it's l33t to e.g. What do you mean exactly by 'bend over'? I don't expect maintainers of any package (what is a core package?) to do anything, but I don't expect them to block or cause problem to somebody wanting to add a new kernel to fedora (as long as that new kernel addition is done in a sound technical way). > have a non Linux kernel. Moreover, I'm pretty sure, by just reading your > mails, that you don't realize what using a non Linux kernel even > entails. Indeed. This was an extreme example to avoid getting in the technical argument, but keep talking on the organisational issues. > > In fact there are already guidelines and FESCo rulings that in my opinion > > went in that direction (precisely, and if I recall well, the fnord and > > another package of Enrico that were linked statically against uclibc, > > and even he demonstrated that there was a performance gain and no > > security issue they were knocked down). I think that it was a wrong > > decision, but if it is for corner case it is different than if it > > becomes the rule. > > Ooo.. here's the "it's in the guidelines so do as I say" card. Annoying. Hum, maybe I wasn't clear, but I actually meant that FESCo should have left Enrico link statically his packages. So I said the reverse... > Seriously. People. What the hell happened to simplicity and building a > free OS for the world that just works? Is the state of Fedora really in > such a bad shape that people think it's necessary have craptastic > options like "what kernel would you like today?". Seriously, things like > that is just masturbation and we in Fedora should be above that. It is not masturbation, it is about what is acceptable or not in fedora, from the point of view of a contributor. It is absolutely not related with the shape of fedora. > I feel > that people wanting this are treating Fedora like it's a playground for > their Toy OS ideas. You shouldn't make such assumptions. There are many reasons to have diversity and freedom to add anything. I could tell mine, but I don't think it is relevant. Point is do we allow any package to go in, be it for fedora contributors to use fedora as 'a playground for their Toy OS ideas' or for any other reason. > Playing classic cards like "RH vs. community" and > "this or that committee says so" to justify their "ideas". It's > seriously tiring. Is this what Fedora is becoming? Because if it is, > I'll find something else to spend my time on. Forget the "RH vs. community" stuff, rereading my mail I indeed said that but it was a mistake, and it isn't the issue here. It is mainstream fedora (a simple fedora that just works) versus freedom to add anything that is free software and works (even if not very well integrated). -- Pat From j.w.r.degoede at hhs.nl Thu Jan 10 09:40:35 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 10 Jan 2008 10:40:35 +0100 Subject: Fedora too cutting edge? In-Reply-To: <20080110004941.GA20965@tango.0pointer.de> References: <4785163E.8010508@hhs.nl> <20080110004941.GA20965@tango.0pointer.de> Message-ID: <4785E813.7020704@hhs.nl> Lennart Poettering wrote: > On Wed, 09.01.08 19:45, Hans de Goede (j.w.r.degoede at hhs.nl) wrote: > >> Another example of Fedora being to cutting edge is pulseaudio, for prove >> click this URL: > >> https://bugzilla.redhat.com/buglist.cgi?product=Fedora&version=&component=pulseaudio&bug_status=NEW&bug_status=ASSIGNED&bug_status=NEEDINFO&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=FAILS_QA&bug_status=POST&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc= > > I don't think this BZ excerpt is any good as argument for your > point. I agree with that to some part, I've recently been working on getting some pulseaudio problems in packages I maintain fixed, and when I ran that query I was a little bit amazed of the results. Also I've been receiving quite a few bugs for some of my packages related to sound problems, and often these bugs are caused by people turning of pulseaudio (not on my advice!) but only turning it of partially, for example they often still have alsa-plugins-pulseaudio installed and enabled as default alsa sink. So there are really problems with pulseaudio, or atleast people perceive some problems as being caused by pa, resulting in them turning pa off. > A big share of the bugs listed for PA are duplicates. BZ is > very good for burying people in vast amount of emails due to new or > updated bug reports. My main job is hacking on PA, not wading through > BZ. Which is why I tend to ignore bugzilla as good as I can and clean > it up only just before every release. And I think this is bad, we need to nourish people who provide valuable feedback, not ignore them and let BZ tickets rot. Also see Jonathan Dieter reply for an example of why this is bad. Why not reserve 30 minutes a day to respond to bug tickets, if you do this every day, keeping on top of things, then keeping BZ spam in track should be manageable. Anyways after my recent bugfixing surrounding pulseaudio, I've already been thinking about trying to help out with pulseaudio, so as usual I'm willing to put my code where my mouth is and I'm hereby offering to do pulseaudio bug triaging for you. But pulseaudio is a complex beast, so I will be needing help from you. I can do the initial grunt work of filtering duplicates, filtering configuration errors and trying to make problems reproducable, but after that I will need help from you. Does this sound like a deal? And once I'm in a stadium where I need help, how do I reach you in such a way that you do respond in a reasonable time? Thanks & Regards, Hans From twoerner at redhat.com Thu Jan 10 10:00:07 2008 From: twoerner at redhat.com (Thomas Woerner) Date: Thu, 10 Jan 2008 11:00:07 +0100 Subject: gripe/question: /etc/sysconfig/system-config-firewall??? In-Reply-To: <477839C5.6040200@filteredperception.org> References: <477839C5.6040200@filteredperception.org> Message-ID: <4785ECA7.20700@redhat.com> Douglas McClendon wrote: > Anybody care to explain to me the logic of the file > > /etc/sysconfig/system-config-firewall > > which makes my kickstart and/or lokkit invocations not be respected? > > I.e. port 22 remains open even if I do > > lokkit --enabled > > (or just firewall --enabled in kickstart) > > It seems like if anything lokkit should be writing this file, not > reading one installed by an rpm. But maybe I just need a clue. ??? > > -dmc > If you want to generate a new firewall configuration, you should use the '-f' option. lokkit is modifying the actual settings as long as this option is not given. Please have a look at the output of 'lokkit --help'. /etc/sysconfig/system-config-firewall is the config file generated by system-config-firewall, which replaces system-config-securitylevel since F-8. Thomas From khc at pm.waw.pl Thu Jan 10 10:02:59 2008 From: khc at pm.waw.pl (Krzysztof Halasa) Date: Thu, 10 Jan 2008 11:02:59 +0100 Subject: Fedora too cutting edge? In-Reply-To: <47853516.2060600@hhs.nl> (Hans de Goede's message of "Wed, 09 Jan 2008 21:56:54 +0100") References: <4785163E.8010508@hhs.nl> <1199908164.4765.49.camel@metroid.rdu.redhat.com> <47853516.2060600@hhs.nl> Message-ID: Hans de Goede writes: > As for this being fixed, not for my case, as I have a via vt 6306 > controller, which is like, only the most common PC firewire controller > on the planet. It should do OHCI 1.1, you may want to take the risk and try the program. Make sure you have a backup (the GUID and possibly whole EEPROM data). VIA claims both VT6306 and VT6307 are OHCI-1.1 (capable), I just have no VT6306 to test (actually it seems VT6307 is a cheeper version, aimed at motherboard manufacturers). -- Krzysztof Halasa From triad at df.lth.se Thu Jan 10 10:26:27 2008 From: triad at df.lth.se (Linus Walleij) Date: Thu, 10 Jan 2008 11:26:27 +0100 (CET) Subject: Init : someone could comment this ? In-Reply-To: <47856B62.7040205@ncsu.edu> References: <20080107173508.GA23429@tango.0pointer.de> <4783A57B.2050005@gmail.com> <4783AA97.8090500@gmail.com> <4783D111.80308@gmail.com> <50837.192.54.193.53.1199868870.squirrel@rousalka.dyndns.org> <20080109165258.GD12763@nostromo.devel.redhat.com> <47856B62.7040205@ncsu.edu> Message-ID: On Wed, 9 Jan 2008, Casey Dahlin wrote: > I have been in touch with Scott Remnant, and this is fortunately not true. GOOD NEWS! > InitKit is a project to create a standard for event-based activation. The > idea is that even if a bunch of distros NIH and implement themselves, > upstream can count on certain behaviors. No actual software is planned to > emerge from the project. So the place where we can see all the Good Stuff from InitKit first with regard to init-alike systems will be in Upstart. Great! Would be even greater if I could work full-time to get Upstart running on Fedora, but can't. I have this intense feeling that someone at RH must do this for it to work out... Linus From mcepl at redhat.com Thu Jan 10 10:15:42 2008 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 10 Jan 2008 11:15:42 +0100 Subject: Impending X driver deprecation References: <1199906969.15130.40.camel@localhost.localdomain> <478592B4.8080109@ij.net> Message-ID: On 2008-01-10, 03:36 GMT, Felix Miata wrote: > So as to Tseng, I object X8. And why wouldn't your machines work with vesa? Mat?j From mcepl at redhat.com Thu Jan 10 10:54:31 2008 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 10 Jan 2008 11:54:31 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> Message-ID: <74ah55x6io.ln2@ppp1053.in.ipex.cz> On 2008-01-10, 00:08 GMT, Les Mikesell wrote: > Can we have OpenSolaris (with zfs) too? I was going to point > out that Linux wasn't about choice but about providing a free > and compatible alternative to Unix. But this would complete > the circle... I would put my hope into http://oss.oracle.com/projects/btrfs/ rather than into port of ZFS on Linux. Yes, it is still alpha, and yes Oracle could screw it up somehow (I don't exepct it, though), but creating our own implementation of the stuff seems like The Linux Way (rather than whinning that Sun didn't give us the candy). Matej From warren at togami.com Thu Jan 10 12:06:16 2008 From: warren at togami.com (Warren Togami) Date: Thu, 10 Jan 2008 07:06:16 -0500 Subject: Impending X driver deprecation In-Reply-To: <4785B71F.3050906@leemhuis.info> References: <1199906969.15130.40.camel@localhost.localdomain> <47857FE3.7050000@redhat.com> <20080109212455.0dd3da54@redhat.com> <4785849E.7080208@redhat.com> <4785B71F.3050906@leemhuis.info> Message-ID: <47860A38.8000901@togami.com> Thorsten Leemhuis wrote: > On 10.01.2008 03:36, Warren Togami wrote: >> Jesse Keating wrote: >>> On Wed, 09 Jan 2008 21:16:03 -0500 >>> Warren Togami wrote: >>> >>>> Please reconsider s3? >>>> >>>> It is used by several of the thin client models selling today, and >>>> Intel's "Affordable PC" reference platform that is being sold in >>>> large numbers in the developing world (e.g. China) by companies like >>>> Dell. > > Are you sure it's s3? It's IIRC a SiS-Chipset. See > > http://www.sis.com/pressroom/pressrelease_000287.htm > [...] > Another best-value PC solution presented at IDF is Dell?s Affordable PC > (APC) EC280, which is developed by SiS and Dell for the emerging market. > The Dell EC280 adopts the SiSM661GX chipset to support Intel FSB533MHz > CPU and DDR 333 memory. > [...] > > SiSM661GX is driven by xorg-x11-drv-sis Oh crap. You're right. Nevermind me and my fuzzy memory. I was confusing two crappy chipsets. > >> (*WHY* does Intel's APC have such a crappy non-Intel video card?) > > That's a interesting question :)) Sigh. Warren From kevin.kofler at chello.at Thu Jan 10 12:15:37 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 10 Jan 2008 12:15:37 +0000 (UTC) Subject: regressions (was: Re: Linux is not about choice [was Re: Fedora too cutting edge?]) References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <47853A21.4020204@leemhuis.info> <20080109213752.GA3286@nostromo.devel.redhat.com> <47854276.7060101@leemhuis.info> <20080110045924.GA21600@nostromo.devel.redhat.com> <4785B519.3070907@leemhuis.info> Message-ID: Thorsten Leemhuis leemhuis.info> writes: > Now: seems so afaics. But when it was new it was a regression for quite > a bunch of people. That's bad and we should avoid regressions as much as > possible. Just like the kernel developers do -- Torvalds on lkml yells While I agree regressions are annoying, and thus perceived as a very bad thing, in practice regressions are less of a problem than unfixed bugs: if there's a regression, you can rollback to a working package, if there are unfixed bugs, you have nothing to upgrade or downgrade to. Kevin Kofler From atkac at redhat.com Thu Jan 10 12:31:17 2008 From: atkac at redhat.com (Adam Tkac) Date: Thu, 10 Jan 2008 13:31:17 +0100 Subject: regressions (was: Re: Linux is not about choice [was Re: Fedora too cutting edge?]) In-Reply-To: References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <47853A21.4020204@leemhuis.info> <20080109213752.GA3286@nostromo.devel.redhat.com> <47854276.7060101@leemhuis.info> <20080110045924.GA21600@nostromo.devel.redhat.com> <4785B519.3070907@leemhuis.info> Message-ID: <20080110123117.GA6319@evileye.atkac.englab.brq.redhat.com> On Thu, Jan 10, 2008 at 12:15:37PM +0000, Kevin Kofler wrote: > Thorsten Leemhuis leemhuis.info> writes: > > Now: seems so afaics. But when it was new it was a regression for quite > > a bunch of people. That's bad and we should avoid regressions as much as > > possible. Just like the kernel developers do -- Torvalds on lkml yells > > While I agree regressions are annoying, and thus perceived as a very bad thing, > in practice regressions are less of a problem than unfixed bugs: if there's a > regression, you can rollback to a working package, if there are unfixed bugs, > you have nothing to upgrade or downgrade to. > > Kevin Kofler I don't think so. If there's unfixed bug it means that things don't work, didn't work and won't work for some time. But regression means that thing worked but don't work now. At least for me bugs doesn't matter me. Regression yes. I remember Linus speach that if We fix all regressions and some bugs programs become better. If We neglect regressions it's impossible complain if software is better or worse, people will be annoyed. You were accustomed and you have to switch your habbits - it's pretty harder that you want start using something new and you can't so you will find other solution which works for you. We really should be focused primarily on regressions, not for "common" bugs. Adam -- Adam Tkac, Red Hat, Inc. From snecklifter at gmail.com Thu Jan 10 12:37:31 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Thu, 10 Jan 2008 12:37:31 +0000 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <1199964183.8159.15.camel@localhost.localdomain> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <20080109094532.811057b2.mschwendt.tmp0701.nospam@arcor.de> <64b14b300801090446u1412557p7bee40aa9922223d@mail.gmail.com> <1199916701.8159.2.camel@localhost.localdomain> <364d303b0801091644s7c9109a8v4b1bfe0f90427cb@mail.gmail.com> <1199964183.8159.15.camel@localhost.localdomain> Message-ID: <364d303b0801100437g1ed6c0b8tb7e71784e9ba3bd@mail.gmail.com> On 10/01/2008, Lubomir Kundrak wrote: > > On Thu, 2008-01-10 at 00:44 +0000, Christopher Brown wrote: > > On 09/01/2008, Lubomir Kundrak wrote: > > > > > > On Wed, 2008-01-09 at 13:46 +0100, Valent Turkovic wrote: > > > > On 1/9/08, Michael Schwendt wrote: > > > > > On Wed, 9 Jan 2008 09:20:46 +0100, Valent Turkovic wrote: > > > > > > > > > > > Hi, > > > > > > I saw that Pulse Audio 0.9.8 got released two months ago: > > > > > > http://pulseaudio.org/milestone/0.9.8 > > > > > > and I see on my Fedora 8 that we still have 0.9.7 > > > > > > > > > > > > $ pulseaudio --version > > > > > > pulseaudio 0.9.7 > > > > > > > > > > > > Will there be an upgrade soon on Fedora 8 to Pulse Audio 0.9.8? > > > > > > > > > > > > Lost of issues have been fixed in new Pulse Audio so users like me who > > > > > > have issues with Pulse Audio would appreciate the much needed upgrade. > > > > > > > > > > I'm sure the person who maintains the Fedora packages is aware of that. :) > > > > > Just notice the connection between Pulse Audio and Red Hat. > > > > > > > > I'm sure he is aware of that but I am not - that is why I wrote this email. > > > > > > I know the answer -- He decided to save us from an useless upgrade that > > > would solve none of our problems. This applies for all package > > > maintainers who value bandwidth and time of the users more than a change > > > of one digit in a version number -- my thanks to them. > > > > That is perhaps one view. Then there will be the people who are > > running pulseaudio for the first time because it is in Fedora for the > > first time, reporting bugs, these get resolved and then pushed out to > > those users who have their bugs fixed and don't give up on Fedora. > > (off-list) > Which of the bugs you reported against pulseaudio in bugzilla are fixed > by the new release? (on-list) I have not reported any bugs against pulseaudio so I have none which the new release fixes. However: http://pulseaudio.org/milestone/0.9.8 gives some good reasons to upgrade. This is more than just "a change of one digit in a version number". In any event my comment related not just to pulseaudio but to Fedora as a whole. Point releases reflect bug fixes - usually - and so upgrading to resolve outstanding bugs is something that I and many users no doubt will applaud. You are not forced to accept these upgrades. Cheers -- Christopher Brown http://www.chruz.com From dimi at lattica.com Thu Jan 10 11:36:09 2008 From: dimi at lattica.com (Dimi Paun) Date: Thu, 10 Jan 2008 06:36:09 -0500 Subject: Package updater Message-ID: <1199964969.4826.17.camel@dimi.lattica.com> Folks, Why in name of all that is good do we have this silly small dialogs that are close to impossible to use?!? This is annoying beyond belief. In the package updater (the one that comes up when you get a notification that updates are available), the "Details" window is just a *few* pixels in height!!! To use the darn thing, I have to always: * enter my root password (why oh why?) * open the details (why not have them open by default?) * resize the window to be wider (why not use the screen size?) To add insult to injury, when there are errors (or additional deps required), I have a tiny dialog popup, with "details". so I have to: * click to open the details (again, should be open by default, they are always interesting) * resize the dialog to a decent size, or else everything is unreadable This has been like this for a long time. In terms of UI, it is brutal (the textual interface is way nicer). Is it just me that finds this so offensive? -- Dimi Paun Lattica, Inc. From jkeating at redhat.com Thu Jan 10 12:52:30 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 10 Jan 2008 07:52:30 -0500 Subject: Package updater In-Reply-To: <1199964969.4826.17.camel@dimi.lattica.com> References: <1199964969.4826.17.camel@dimi.lattica.com> Message-ID: <20080110075230.1a8797dd@redhat.com> On Thu, 10 Jan 2008 06:36:09 -0500 Dimi Paun wrote: > This has been like this for a long time. In terms of UI, > it is brutal (the textual interface is way nicer). Is it > just me that finds this so offensive? Is there a bug filed for it? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From caillon at redhat.com Thu Jan 10 12:51:32 2008 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 10 Jan 2008 13:51:32 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <47854276.7060101@leemhuis.info> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <47853A21.4020204@leemhuis.info> <20080109213752.GA3286@nostromo.devel.redhat.com> <47854276.7060101@leemhuis.info> Message-ID: <478614D4.3030406@redhat.com> On 01/09/2008 10:53 PM, Thorsten Leemhuis wrote: > Jesse said juju "was functional for the vast majority of uses" when we > shipped that; I doubt that, as the questions is saw in #fedora-de, the > "howto switch to the old firewire stack"-Howtos in the net and the mail > from Hans tell a different story. Because people only complain when things don't work. Without data on which devices work with the juju stack that didn't work with the old stack, you can't say this accurately. From caillon at redhat.com Thu Jan 10 12:57:58 2008 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 10 Jan 2008 13:57:58 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <478546E9.4010303@leemhuis.info> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <478541FD.5000806@redhat.com> <478543FA.70809@filteredperception.org> <478546E9.4010303@leemhuis.info> Message-ID: <47861656.6070504@redhat.com> On 01/09/2008 11:12 PM, Thorsten Leemhuis wrote: > But Juju afaics didn't work well for to many people when we shipped it > for the first time, thus choice here IMHO is a temporary solution. Yes, it didn't work well for some people. It did work well for others, in some cases where the old stack didn't work at all for them. Too bad we have no way of counting them. Those who scream the loudest are not always in the majority. From caillon at redhat.com Thu Jan 10 13:02:32 2008 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 10 Jan 2008 14:02:32 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <20080109224742.GB2664@free.fr> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> Message-ID: <47861768.7040502@redhat.com> On 01/09/2008 11:47 PM, Patrice Dumas wrote: > Who 'essentially already posited that we have insufficient developer > effort'? Who decided that, and for what task? Isn't the fedora > contributors time used like they want to? If there are three parts, > and three interactions but dozens of contributors willing to fix > them where is the issue? Not trying to slam people, but don't confuse willing with able (for various reasons such as ability, time constraints, lack of specific hardware, etc.) From magnus.gustavsson at liu.se Thu Jan 10 12:26:55 2008 From: magnus.gustavsson at liu.se (Magnus Gustavsson) Date: Thu, 10 Jan 2008 12:26:55 +0000 (UTC) Subject: Bruttaly sluggish Eclipse performance in remote X References: <1199746646.9735.10.camel@dimi.lattica.com> Message-ID: Dimi Paun lattica.com> writes: > However, the deal break has been Eclipse. I've had a fair amount of problems with Eclipse and X-forwarding as well. They seems to be of a different kind than yours, but I thought I'd mention my experiences anyway. If nothing else, perhaps somebody has a suggestion about what to do? I'm running a Sun Ray server on RHEL4. When I use X-forwarding via SSH to a RHEL5- or Debian 4.0 (Etch) machine, Eclipse becomes extremly slow. That's hardly surprising if I take a look at the network traffic; just scrolling down a few pages in Eclipse generates more than 100 MiB of X11 data. I've never had this problem before, and that's because when I use X-forwarding to a RHEL4- or Debian 3.1 (Sarge) machine, the generated traffic "only" amounts to 5-10 MiB, and then the server can cope with it. I don't have this problem with other applications, and if I run Eclipse via X-forwarding on the console of the Sun Ray server (instead of from a Sun Ray client), the generated amount of traffic is much lower. Analyzing the network traffic makes me suspect that the reason is that Xnewt (the Sun Ray X-server) doesn't support the RENDER extension to X11. I havn't managed to figure out what the big difference is between RHEL4/Sarge on one hand and RHEL5/Etch on the other though, and if there's something I can do about, say, the fonts to at least make it usable until a better solution can be found. From lkundrak at redhat.com Thu Jan 10 13:24:14 2008 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Thu, 10 Jan 2008 14:24:14 +0100 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <364d303b0801100437g1ed6c0b8tb7e71784e9ba3bd@mail.gmail.com> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <20080109094532.811057b2.mschwendt.tmp0701.nospam@arcor.de> <64b14b300801090446u1412557p7bee40aa9922223d@mail.gmail.com> <1199916701.8159.2.camel@localhost.localdomain> <364d303b0801091644s7c9109a8v4b1bfe0f90427cb@mail.gmail.com> <1199964183.8159.15.camel@localhost.localdomain> <364d303b0801100437g1ed6c0b8tb7e71784e9ba3bd@mail.gmail.com> Message-ID: <1199971454.8159.26.camel@localhost.localdomain> On Thu, 2008-01-10 at 12:37 +0000, Christopher Brown wrote: > On 10/01/2008, Lubomir Kundrak wrote: > > > > On Thu, 2008-01-10 at 00:44 +0000, Christopher Brown wrote: > > > On 09/01/2008, Lubomir Kundrak wrote: > > > > > > > > On Wed, 2008-01-09 at 13:46 +0100, Valent Turkovic wrote: > > > > > On 1/9/08, Michael Schwendt wrote: > > > > > > On Wed, 9 Jan 2008 09:20:46 +0100, Valent Turkovic wrote: > > > > > > > > > > > > > Hi, > > > > > > > I saw that Pulse Audio 0.9.8 got released two months ago: > > > > > > > http://pulseaudio.org/milestone/0.9.8 > > > > > > > and I see on my Fedora 8 that we still have 0.9.7 > > > > > > > > > > > > > > $ pulseaudio --version > > > > > > > pulseaudio 0.9.7 > > > > > > > > > > > > > > Will there be an upgrade soon on Fedora 8 to Pulse Audio 0.9.8? > > > > > > > > > > > > > > Lost of issues have been fixed in new Pulse Audio so users like me who > > > > > > > have issues with Pulse Audio would appreciate the much needed upgrade. > > > > > > > > > > > > I'm sure the person who maintains the Fedora packages is aware of that. :) > > > > > > Just notice the connection between Pulse Audio and Red Hat. > > > > > > > > > > I'm sure he is aware of that but I am not - that is why I wrote this email. > > > > > > > > I know the answer -- He decided to save us from an useless upgrade that > > > > would solve none of our problems. This applies for all package > > > > maintainers who value bandwidth and time of the users more than a change > > > > of one digit in a version number -- my thanks to them. > > > > > > That is perhaps one view. Then there will be the people who are > > > running pulseaudio for the first time because it is in Fedora for the > > > first time, reporting bugs, these get resolved and then pushed out to > > > those users who have their bugs fixed and don't give up on Fedora. > > > > (off-list) > > Which of the bugs you reported against pulseaudio in bugzilla are fixed > > by the new release? > > (on-list) > I have not reported any bugs against pulseaudio so I have none which > the new release fixes. However: > > http://pulseaudio.org/milestone/0.9.8 > > gives some good reasons to upgrade. This is more than just "a change > of one digit in a version number". In any event my comment related not > just to pulseaudio but to Fedora as a whole. Point releases reflect > bug fixes - usually - and so upgrading to resolve outstanding bugs is > something that I and many users no doubt will applaud. You are not > forced to accept these upgrades. Pardon me, but I only see mostly reasons not to upgrade a stable release, such as "Rework ALSA surround sound configuration completely", etc. -- Lubomir Kundrak (Red Hat Security Response Team) From lkundrak at redhat.com Thu Jan 10 13:27:46 2008 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Thu, 10 Jan 2008 14:27:46 +0100 Subject: PATCH: add --loginpause to mingetty In-Reply-To: <478564D9.5080303@codewiz.org> References: <478564D9.5080303@codewiz.org> Message-ID: <1199971666.8159.28.camel@localhost.localdomain> On Wed, 2008-01-09 at 19:20 -0500, Bernardo Innocenti wrote: > Hello Florian, > > the attached patches add an option to pause login until the user hits > a key. > > We need something like it on OLPC because: > > - we don't want to set an empty password for either user root or olpc > > - at the same time, we want to allow users to login as root at the > console > > - finally, we do not wish to waste memory on shells the user hasn't > yet used > > The security model we are implementing is very different from UNIX: we > ultimately trust the user at the console, but we don't trust applications > and we don't want them to gain root privileges using su or sudo with no > password. > > I'm committing these changes to the OLPC-2 branch of mingetty in > Fedora CVS. Please, let me know you'd like to merge them or > something similar. Such things are definitely better upstreamed if possible. Have you tried contacting upstream? Thanks, -- Lubomir Kundrak (Red Hat Security Response Team) From myfedora at richip.dhs.org Thu Jan 10 13:31:58 2008 From: myfedora at richip.dhs.org (Richi Plana) Date: Thu, 10 Jan 2008 06:31:58 -0700 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <1199971454.8159.26.camel@localhost.localdomain> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <20080109094532.811057b2.mschwendt.tmp0701.nospam@arcor.de> <64b14b300801090446u1412557p7bee40aa9922223d@mail.gmail.com> <1199916701.8159.2.camel@localhost.localdomain> <364d303b0801091644s7c9109a8v4b1bfe0f90427cb@mail.gmail.com> <1199964183.8159.15.camel@localhost.localdomain> <364d303b0801100437g1ed6c0b8tb7e71784e9ba3bd@mail.gmail.com> <1199971454.8159.26.camel@localhost.localdomain> Message-ID: <1199971918.25862.8.camel@localhost6.localdomain6> On Thu, 2008-01-10 at 14:24 +0100, Lubomir Kundrak wrote: > On Thu, 2008-01-10 at 12:37 +0000, Christopher Brown wrote: > > On 10/01/2008, Lubomir Kundrak wrote: > > > > > > On Thu, 2008-01-10 at 00:44 +0000, Christopher Brown wrote: > > > > On 09/01/2008, Lubomir Kundrak wrote: > > > > > > > > > > On Wed, 2008-01-09 at 13:46 +0100, Valent Turkovic wrote: > > > > > > On 1/9/08, Michael Schwendt wrote: > > > > > > > On Wed, 9 Jan 2008 09:20:46 +0100, Valent Turkovic wrote: > > > > > > > > > > > > > > > Hi, > > > > > > > > I saw that Pulse Audio 0.9.8 got released two months ago: > > > > > > > > http://pulseaudio.org/milestone/0.9.8 > > > > > > > > and I see on my Fedora 8 that we still have 0.9.7 > > > > > > > > > > > > > > > > $ pulseaudio --version > > > > > > > > pulseaudio 0.9.7 > > > > > > > > > > > > > > > > Will there be an upgrade soon on Fedora 8 to Pulse Audio 0.9.8? > > > > > > > > > > > > > > > > Lost of issues have been fixed in new Pulse Audio so users like me who > > > > > > > > have issues with Pulse Audio would appreciate the much needed upgrade. > > > > > > > > > > > > > > I'm sure the person who maintains the Fedora packages is aware of that. :) > > > > > > > Just notice the connection between Pulse Audio and Red Hat. > > > > > > > > > > > > I'm sure he is aware of that but I am not - that is why I wrote this email. > > > > > > > > > > I know the answer -- He decided to save us from an useless upgrade that > > > > > would solve none of our problems. This applies for all package > > > > > maintainers who value bandwidth and time of the users more than a change > > > > > of one digit in a version number -- my thanks to them. > > > > > > > > That is perhaps one view. Then there will be the people who are > > > > running pulseaudio for the first time because it is in Fedora for the > > > > first time, reporting bugs, these get resolved and then pushed out to > > > > those users who have their bugs fixed and don't give up on Fedora. > > > > > > (off-list) > > > Which of the bugs you reported against pulseaudio in bugzilla are fixed > > > by the new release? > > > > (on-list) > > I have not reported any bugs against pulseaudio so I have none which > > the new release fixes. However: > > > > http://pulseaudio.org/milestone/0.9.8 > > > > gives some good reasons to upgrade. This is more than just "a change > > of one digit in a version number". In any event my comment related not > > just to pulseaudio but to Fedora as a whole. Point releases reflect > > bug fixes - usually - and so upgrading to resolve outstanding bugs is > > something that I and many users no doubt will applaud. You are not > > forced to accept these upgrades. > > Pardon me, but I only see mostly reasons not to upgrade a stable > release, such as "Rework ALSA surround sound configuration completely", > etc. That depends on which distro you're talking about and what the distro progenitors mean by stable. If you mean "stable" as in "no feature changes, just improvement in the way things run and security releases" as used by a lot of server distros including RHEL and Solaris, then *MAYBE* 0.9.8 isn't a reason. But if by "stable", they simply mean it crashes less or is just about equal", then it's fine to release a package. Specially if the distro is about introducing cutting-edge features and the previous release was actually a little short on features (a'la NetworkManager < 0.7). -- Richi Plana From snecklifter at gmail.com Thu Jan 10 13:35:33 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Thu, 10 Jan 2008 13:35:33 +0000 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <1199971454.8159.26.camel@localhost.localdomain> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <20080109094532.811057b2.mschwendt.tmp0701.nospam@arcor.de> <64b14b300801090446u1412557p7bee40aa9922223d@mail.gmail.com> <1199916701.8159.2.camel@localhost.localdomain> <364d303b0801091644s7c9109a8v4b1bfe0f90427cb@mail.gmail.com> <1199964183.8159.15.camel@localhost.localdomain> <364d303b0801100437g1ed6c0b8tb7e71784e9ba3bd@mail.gmail.com> <1199971454.8159.26.camel@localhost.localdomain> Message-ID: <364d303b0801100535u5ba0d223md03c7bdfc1fc419f@mail.gmail.com> On 10/01/2008, Lubomir Kundrak wrote: > > On Thu, 2008-01-10 at 12:37 +0000, Christopher Brown wrote: > > On 10/01/2008, Lubomir Kundrak wrote: > > > > > > On Thu, 2008-01-10 at 00:44 +0000, Christopher Brown wrote: > > > > On 09/01/2008, Lubomir Kundrak wrote: > > > > > > > > > > On Wed, 2008-01-09 at 13:46 +0100, Valent Turkovic wrote: > > > > > > On 1/9/08, Michael Schwendt wrote: > > > > > > > On Wed, 9 Jan 2008 09:20:46 +0100, Valent Turkovic wrote: > > > > > > > > > > > > > > > Hi, > > > > > > > > I saw that Pulse Audio 0.9.8 got released two months ago: > > > > > > > > http://pulseaudio.org/milestone/0.9.8 > > > > > > > > and I see on my Fedora 8 that we still have 0.9.7 > > > > > > > > > > > > > > > > $ pulseaudio --version > > > > > > > > pulseaudio 0.9.7 > > > > > > > > > > > > > > > > Will there be an upgrade soon on Fedora 8 to Pulse Audio 0.9.8? > > > > > > > > > > > > > > > > Lost of issues have been fixed in new Pulse Audio so users like me who > > > > > > > > have issues with Pulse Audio would appreciate the much needed upgrade. > > > > > > > > > > > > > > I'm sure the person who maintains the Fedora packages is aware of that. :) > > > > > > > Just notice the connection between Pulse Audio and Red Hat. > > > > > > > > > > > > I'm sure he is aware of that but I am not - that is why I wrote this email. > > > > > > > > > > I know the answer -- He decided to save us from an useless upgrade that > > > > > would solve none of our problems. This applies for all package > > > > > maintainers who value bandwidth and time of the users more than a change > > > > > of one digit in a version number -- my thanks to them. > > > > > > > > That is perhaps one view. Then there will be the people who are > > > > running pulseaudio for the first time because it is in Fedora for the > > > > first time, reporting bugs, these get resolved and then pushed out to > > > > those users who have their bugs fixed and don't give up on Fedora. > > > > > > (off-list) > > > Which of the bugs you reported against pulseaudio in bugzilla are fixed > > > by the new release? > > > > (on-list) > > I have not reported any bugs against pulseaudio so I have none which > > the new release fixes. However: > > > > http://pulseaudio.org/milestone/0.9.8 > > > > gives some good reasons to upgrade. This is more than just "a change > > of one digit in a version number". In any event my comment related not > > just to pulseaudio but to Fedora as a whole. Point releases reflect > > bug fixes - usually - and so upgrading to resolve outstanding bugs is > > something that I and many users no doubt will applaud. You are not > > forced to accept these upgrades. > > Pardon me, but I only see mostly reasons not to upgrade a stable > release, such as "Rework ALSA surround sound configuration completely", > etc. 0.9.8 _is_ a stable release. Do you therefore consider pulseaudio to be stable? I do not and judging from some of the comment threads I have read neither do a few others. -- Christopher Brown http://www.chruz.com From jkeating at redhat.com Thu Jan 10 13:45:02 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 10 Jan 2008 08:45:02 -0500 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <1199971918.25862.8.camel@localhost6.localdomain6> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <20080109094532.811057b2.mschwendt.tmp0701.nospam@arcor.de> <64b14b300801090446u1412557p7bee40aa9922223d@mail.gmail.com> <1199916701.8159.2.camel@localhost.localdomain> <364d303b0801091644s7c9109a8v4b1bfe0f90427cb@mail.gmail.com> <1199964183.8159.15.camel@localhost.localdomain> <364d303b0801100437g1ed6c0b8tb7e71784e9ba3bd@mail.gmail.com> <1199971454.8159.26.camel@localhost.localdomain> <1199971918.25862.8.camel@localhost6.localdomain6> Message-ID: <20080110084502.27d566a6@redhat.com> On Thu, 10 Jan 2008 06:31:58 -0700 Richi Plana wrote: > That depends on which distro you're talking about and what the distro > progenitors mean by stable. If you mean "stable" as in "no feature > changes, just improvement in the way things run and security releases" > as used by a lot of server distros including RHEL and Solaris, then > *MAYBE* 0.9.8 isn't a reason. But if by "stable", they simply mean it > crashes less or is just about equal", then it's fine to release a > package. Specially if the distro is about introducing cutting-edge > features and the previous release was actually a little short on > features (a'la NetworkManager < 0.7). > -- There is a (big) difference between introducing cutting-edge features during development to have them during the release, vs introducing cutting-edge releases as an update to an already released Fedora. BIG difference. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wtogami at redhat.com Thu Jan 10 13:43:34 2008 From: wtogami at redhat.com (Warren Togami) Date: Thu, 10 Jan 2008 08:43:34 -0500 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <364d303b0801100437g1ed6c0b8tb7e71784e9ba3bd@mail.gmail.com> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <20080109094532.811057b2.mschwendt.tmp0701.nospam@arcor.de> <64b14b300801090446u1412557p7bee40aa9922223d@mail.gmail.com> <1199916701.8159.2.camel@localhost.localdomain> <364d303b0801091644s7c9109a8v4b1bfe0f90427cb@mail.gmail.com> <1199964183.8159.15.camel@localhost.localdomain> <364d303b0801100437g1ed6c0b8tb7e71784e9ba3bd@mail.gmail.com> Message-ID: <47862106.2010607@redhat.com> Christopher Brown wrote: > > http://pulseaudio.org/milestone/0.9.8 > > gives some good reasons to upgrade. This is more than just "a change > of one digit in a version number". In any event my comment related not > just to pulseaudio but to Fedora as a whole. Point releases reflect > bug fixes - usually - and so upgrading to resolve outstanding bugs is > something that I and many users no doubt will applaud. You are not > forced to accept these upgrades. > > Cheers > We are yet to hear from Lennart about this, but I was under the impression that the pulseaudio shipped in F8 was a svn snapshot *very* close to 0.9.8. pulseaudio-0.9.7-0.17.svn20071017.fc8 was built October 30th 0.9.8 was released November 20th It might be the case that we might not gain much (or anything?) by upgrading only to 0.9.8. Lennart? Warren Togami wtogami at redhat.com From caillon at redhat.com Thu Jan 10 13:45:14 2008 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 10 Jan 2008 14:45:14 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199927642.25567.81.camel@oneill.fubar.dk> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> <1199924388.15130.159.camel@localhost.localdomain> <20080110001941.GJ2664@free.fr> <1199925522.25567.57.camel@oneill.fubar.dk> <20080110005703.GL2664@free.fr> <1199927642.25567.81.camel@oneill.fubar.dk> Message-ID: <4786216A.4060502@redhat.com> On 01/10/2008 02:14 AM, David Zeuthen wrote: > Seriously. People. What the hell happened to simplicity and building a > free OS for the world that just works? Is the state of Fedora really in > such a bad shape that people think it's necessary have craptastic > options like "what kernel would you like today?". Seriously, things like > that is just masturbation and we in Fedora should be above that. I feel > that people wanting this are treating Fedora like it's a playground for > their Toy OS ideas. Playing classic cards like "RH vs. community" and > "this or that committee says so" to justify their "ideas". It's > seriously tiring. Is this what Fedora is becoming? Because if it is, > I'll find something else to spend my time on. The Praeto principle is relevant here. The more software we have, the less time contributors have to spend time on fixing bugs in a random project (let's say the Firewire stack as a random example) if they wanted to because they have to worry about fixing bugs in the packages they maintain. From jwboyer at gmail.com Thu Jan 10 13:45:47 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 10 Jan 2008 07:45:47 -0600 Subject: ctrlproxy In-Reply-To: <4784DC7D.1050603@codewiz.org> References: <4783B191.50104@codewiz.org> <20080108121210.35266172@zod.rchland.ibm.com> <4784DC7D.1050603@codewiz.org> Message-ID: <20080110074547.785a7b61@zod.rchland.ibm.com> On Wed, 09 Jan 2008 09:38:53 -0500 Bernardo Innocenti wrote: > (cc dwmw2, fedora-devel) > > Josh Boyer wrote: > > >> I'd like to import the latest version of ctrlproxy because > >> 3.0.2 randomly crashes every few days of operation. > > > > Odd, I've been running it without problems for quite a while. > > Hmmm... Must be something specific to my configuration, then. > I'm thinking x86_64, or the fact that I connect through 2 xchat > clients all the time. Or irssi-style logging. I have it running on x86_64, using 2-3 xchat clients at a time. Not sure if I have logging enabled. By chance do you have it running under a different locale? > >> Additionally, I wrote an initscript to run ctrlproxy > >> as a daemon. Would you approve such a change to the package? > > > > Oh, interesting. > > I've scratch-built a candidate RPM for you to try: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=336094 > > It includes both ctrlproxy-3.0.5 and the daemonization work. > I'm also cc'ing dwmw2 because I know he uses ctrlproxy and > may like to test this new version. OK, I'll take a look soon. > > Could you open a bug in bugzilla and attach a patch there? (Or point > > to the SRPM from there.) I'd certainly be interested in the changes. > > Unfortunately, I could never catch ctrlproxy 3.0.3 crashing > when I had enabled coredumps with ulimit. Since I upgraded > to 3.0.5, I've not yet seen another crash. Upgrading is easy enough. I'll get it done when I can. josh From jeff at ocjtech.us Thu Jan 10 13:49:49 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Thu, 10 Jan 2008 07:49:49 -0600 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <1199971454.8159.26.camel@localhost.localdomain> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <20080109094532.811057b2.mschwendt.tmp0701.nospam@arcor.de> <64b14b300801090446u1412557p7bee40aa9922223d@mail.gmail.com> <1199916701.8159.2.camel@localhost.localdomain> <364d303b0801091644s7c9109a8v4b1bfe0f90427cb@mail.gmail.com> <1199964183.8159.15.camel@localhost.localdomain> <364d303b0801100437g1ed6c0b8tb7e71784e9ba3bd@mail.gmail.com> <1199971454.8159.26.camel@localhost.localdomain> Message-ID: <935ead450801100549k5b34e131w60a7b2d850a629ac@mail.gmail.com> On 1/10/08, Lubomir Kundrak wrote: > > Pardon me, but I only see mostly reasons not to upgrade a stable > release, such as "Rework ALSA surround sound configuration completely", > etc. I wouldn't call the version of pulseaudio in F-8 "stable". In fact there are 34 open bugs in bugzilla for pulseaudio for F-8. I didn't report any of those bugs because I'm self-sufficient enough to recompile 0.9.8 on my F-8 boxes. If I was forced to stick with 0.9.7-0.17.svn20071017 I'm sure I would have opened up or CC'd myself on several bugs. Jeff From caillon at redhat.com Thu Jan 10 13:48:51 2008 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 10 Jan 2008 14:48:51 +0100 Subject: Impending X driver deprecation In-Reply-To: <1199906969.15130.40.camel@localhost.localdomain> References: <1199906969.15130.40.camel@localhost.localdomain> Message-ID: <47862243.50003@redhat.com> Can we call it Operation: Impeding Doom? From ncorrare at fedoraproject.org Thu Jan 10 13:59:06 2008 From: ncorrare at fedoraproject.org (Nicolas Antonio Corrarello) Date: Thu, 10 Jan 2008 11:59:06 -0200 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <935ead450801100549k5b34e131w60a7b2d850a629ac@mail.gmail.com> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <20080109094532.811057b2.mschwendt.tmp0701.nospam@arcor.de> <64b14b300801090446u1412557p7bee40aa9922223d@mail.gmail.com> <1199916701.8159.2.camel@localhost.localdomain> <364d303b0801091644s7c9109a8v4b1bfe0f90427cb@mail.gmail.com> <1199964183.8159.15.camel@localhost.localdomain> <364d303b0801100437g1ed6c0b8tb7e71784e9ba3bd@mail.gmail.com> <1199971454.8159.26.camel@localhost.localdomain> <935ead450801100549k5b34e131w60a7b2d850a629ac@mail.gmail.com> Message-ID: <478624AA.8080206@fedoraproject.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I tried it yesterday to check if the bluetooth gadget worked. It still had some really strange behaviour... But it worked Jeffrey Ollie wrote: > On 1/10/08, Lubomir Kundrak wrote: >> Pardon me, but I only see mostly reasons not to upgrade a stable >> release, such as "Rework ALSA surround sound configuration completely", >> etc. > > I wouldn't call the version of pulseaudio in F-8 "stable". In fact > there are 34 open bugs in bugzilla for pulseaudio for F-8. I didn't > report any of those bugs because I'm self-sufficient enough to > recompile 0.9.8 on my F-8 boxes. If I was forced to stick with > 0.9.7-0.17.svn20071017 I'm sure I would have opened up or CC'd myself > on several bugs. > > Jeff > - -- - - -- Nicolas A. Corrarello Fedora Ambassador Argentina c: +54 (911) 5182-2245 e: ncorrare at fedoraproject.org GPG Key: DFC893EE h: fedoraproject.org/wiki/NicolasCorrarello/ GPG Fingerprint: 5C93 42DA 98E1 4EEF B24B 7F8C E145 B2F9 DFC8 93EE Import my key: $ gpg --keyserver pgp.mit.edu --recv-key 0xDFC893EE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHhiSq4UWy+d/Ik+4RAouKAKCbvEr0vqDpWqnig0bF9S6omWI/MgCfUsbk ZE+vbRMN6++Uc/PFAjMwXbk= =riGN -----END PGP SIGNATURE----- From jima at beer.tclug.org Thu Jan 10 14:03:07 2008 From: jima at beer.tclug.org (Jima) Date: Thu, 10 Jan 2008 08:03:07 -0600 (CST) Subject: Fedora too cutting edge? In-Reply-To: References: <4785163E.8010508@hhs.nl> <20080109200634.GE17953@redhat.com> Message-ID: On Thu, 10 Jan 2008, Linus Walleij wrote: > On Wed, 9 Jan 2008, John W. Linville wrote: >> FWIW, I get criticized for pushing too much brand-new wireless >> bits into the Fedora kernels. > > I, for one, THANK YOU for doing it John, it saved my day and I'm not going to > forget that. So keep doing what you're doing. +10. I thought about replying last night, but I didn't think it'd improve the S:N ratio. :-) I've always found John's work to be beneficial to the distro, including when he breaks support for my hardware. (Hey, he usually tries to fix it pretty quick, too!) Sometimes you've gotta break some yolks to make scrambled eggs. Does it suck? Sure. Is it for the best in the long run? I think so. On Wed, 9 Jan 2008, Chuck Anderson wrote: > On Thu, Jan 10, 2008 at 01:57:23AM +0000, Kevin Kofler wrote: > > despite Fedora not including proprietary junk like madwifi (what's the > > state of ath5k by the way?) > > ath5k Works for me(TM), NM 0.7 EAP-TLS, with a few issues after > suspend/resume. Oooh, I'll have to try that again. Where'd that Atheros MiniPCI card go...and the PCI one. Jima From jeff at ocjtech.us Thu Jan 10 14:05:29 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Thu, 10 Jan 2008 08:05:29 -0600 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <47862106.2010607@redhat.com> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <20080109094532.811057b2.mschwendt.tmp0701.nospam@arcor.de> <64b14b300801090446u1412557p7bee40aa9922223d@mail.gmail.com> <1199916701.8159.2.camel@localhost.localdomain> <364d303b0801091644s7c9109a8v4b1bfe0f90427cb@mail.gmail.com> <1199964183.8159.15.camel@localhost.localdomain> <364d303b0801100437g1ed6c0b8tb7e71784e9ba3bd@mail.gmail.com> <47862106.2010607@redhat.com> Message-ID: <935ead450801100605m6dda8021t2618b3132129e354@mail.gmail.com> On 1/10/08, Warren Togami wrote: > Christopher Brown wrote: > > > > http://pulseaudio.org/milestone/0.9.8 > > > > gives some good reasons to upgrade. This is more than just "a change > > of one digit in a version number". In any event my comment related not > > just to pulseaudio but to Fedora as a whole. Point releases reflect > > bug fixes - usually - and so upgrading to resolve outstanding bugs is > > something that I and many users no doubt will applaud. You are not > > forced to accept these upgrades. > > We are yet to hear from Lennart about this, but I was under the > impression that the pulseaudio shipped in F8 was a svn snapshot *very* > close to 0.9.8. > > pulseaudio-0.9.7-0.17.svn20071017.fc8 was built October 30th > 0.9.8 was released November 20th I don't see how the code in 0.9.7-0.17.svn20071017.fc8 could possibly be considered very close to 0.9.8, seeing as any SVN snapshot from 2007-10-17 is almost two weeks before 0.9.7 was tagged/released on 2007-10-30. Jeff From lesmikesell at gmail.com Thu Jan 10 14:06:53 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 10 Jan 2008 08:06:53 -0600 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <74ah55x6io.ln2@ppp1053.in.ipex.cz> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> Message-ID: <4786267D.9010800@gmail.com> Matej Cepl wrote: > On 2008-01-10, 00:08 GMT, Les Mikesell wrote: >> Can we have OpenSolaris (with zfs) too? I was going to point >> out that Linux wasn't about choice but about providing a free >> and compatible alternative to Unix. But this would complete >> the circle... > > I would put my hope into http://oss.oracle.com/projects/btrfs/ > rather than into port of ZFS on Linux. Yes, it is still alpha, > and yes Oracle could screw it up somehow (I don't exepct it, > though), but creating our own implementation of the stuff seems > like The Linux Way (rather than whinning that Sun didn't give us > the candy). Zfs isn't the only interesting thing about opensolaris and Sun does give you the candy if you take the whole package. It is only the Linux terms that keep you from adding the parts. Solaris has an entirely different attitude about backwards compatibility which makes the mention slightly on topic for this conversation. I can't, for example, imagine them ever changing a device name arbitrarily and breaking a previously working configuration while Linux has no such respect for its users' previous work. Fedora may not be the place for it, but I would seriously like to see a distribution based on the OpenSolaris kernel and the same user programs you'd find in a current Linux or *bsd distro. If nothing else, it would be an interesting exercise in testing Posix compatibility. -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Thu Jan 10 14:10:26 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 10 Jan 2008 08:10:26 -0600 Subject: Bruttaly sluggish Eclipse performance in remote X In-Reply-To: References: <1199746646.9735.10.camel@dimi.lattica.com> Message-ID: <47862752.3030103@gmail.com> Magnus Gustavsson wrote: > Dimi Paun lattica.com> writes: > >> However, the deal break has been Eclipse. > > I've had a fair amount of problems with Eclipse and X-forwarding as well. They > seems to be of a different kind than yours, but I thought I'd mention my > experiences anyway. If nothing else, perhaps somebody has a suggestion about > what to do? > > I'm running a Sun Ray server on RHEL4. When I use X-forwarding via SSH to a > RHEL5- or Debian 4.0 (Etch) machine, Eclipse becomes extremly slow. That's > hardly surprising if I take a look at the network traffic; just scrolling down a > few pages in Eclipse generates more than 100 MiB of X11 data. I've never had > this problem before, and that's because when I use X-forwarding to a RHEL4- or > Debian 3.1 (Sarge) machine, the generated traffic "only" amounts to 5-10 MiB, > and then the server can cope with it. > > I don't have this problem with other applications, and if I run Eclipse via > X-forwarding on the console of the Sun Ray server (instead of from a Sun Ray > client), the generated amount of traffic is much lower. Analyzing the network > traffic makes me suspect that the reason is that Xnewt (the Sun Ray X-server) > doesn't support the RENDER extension to X11. > > I havn't managed to figure out what the big difference is between RHEL4/Sarge on > one hand and RHEL5/Etch on the other though, and if there's something I can do > about, say, the fonts to at least make it usable until a better solution can be > found. Have you tried running freenx with the NX clients from http://www.nomachine.com? -- Les Mikesell lesmikesell at gmail.com From dimi at lattica.com Thu Jan 10 14:29:01 2008 From: dimi at lattica.com (Dimi Paun) Date: Thu, 10 Jan 2008 09:29:01 -0500 Subject: Bruttaly sluggish Eclipse performance in remote X In-Reply-To: <47862752.3030103@gmail.com> References: <1199746646.9735.10.camel@dimi.lattica.com> <47862752.3030103@gmail.com> Message-ID: <1199975341.4826.21.camel@dimi.lattica.com> On Thu, 2008-01-10 at 08:10 -0600, Les Mikesell wrote: > Have you tried running freenx with the NX clients from > http://www.nomachine.com? Oh, BTW, I have, and it works wonderful. However, I think that not being able to run it over X is a bug that needs fixing. -- Dimi Paun Lattica, Inc. From galibert at pobox.com Thu Jan 10 14:46:03 2008 From: galibert at pobox.com (Olivier Galibert) Date: Thu, 10 Jan 2008 15:46:03 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <4786267D.9010800@gmail.com> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> Message-ID: <20080110144603.GA38099@dspnet.fr.eu.org> On Thu, Jan 10, 2008 at 08:06:53AM -0600, Les Mikesell wrote: > Zfs isn't the only interesting thing about opensolaris and Sun does give > you the candy if you take the whole package. It is only the Linux terms > that keep you from adding the parts. Solaris has an entirely different > attitude about backwards compatibility which makes the mention slightly > on topic for this conversation. I can't, for example, imagine them ever > changing a device name arbitrarily and breaking a previously working > configuration while Linux has no such respect for its users' previous > work. Fedora may not be the place for it, but I would seriously like to > see a distribution based on the OpenSolaris kernel and the same user > programs you'd find in a current Linux or *bsd distro. Given that it's the user programs that have the lack of respect for previous configurations (Linus considers backwards-compatibility very important), I doubt you'll see any change for the better. OG. From pertusus at free.fr Thu Jan 10 14:50:42 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 10 Jan 2008 15:50:42 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <4786216A.4060502@redhat.com> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> <1199924388.15130.159.camel@localhost.localdomain> <20080110001941.GJ2664@free.fr> <1199925522.25567.57.camel@oneill.fubar.dk> <20080110005703.GL2664@free.fr> <1199927642.25567.81.camel@oneill.fubar.dk> <4786216A.4060502@redhat.com> Message-ID: <20080110145042.GA2587@free.fr> On Thu, Jan 10, 2008 at 02:45:14PM +0100, Christopher Aillon wrote: > > > The Praeto principle is relevant here. The more software we have, the less > time contributors have to spend time on fixing bugs in a random project > (let's say the Firewire stack as a random example) if they wanted to > because they have to worry about fixing bugs in the packages they maintain. It is not right if more softwares come with more contributors. Or if the contributors have do it anyway, but cannot easily share what they did. -- Pat From pertusus at free.fr Thu Jan 10 14:58:59 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 10 Jan 2008 15:58:59 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <47861768.7040502@redhat.com> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> <47861768.7040502@redhat.com> Message-ID: <20080110145859.GB2587@free.fr> On Thu, Jan 10, 2008 at 02:02:32PM +0100, Christopher Aillon wrote: > On 01/09/2008 11:47 PM, Patrice Dumas wrote: >> Who 'essentially already posited that we have insufficient developer >> effort'? Who decided that, and for what task? Isn't the fedora >> contributors time used like they want to? If there are three parts, and >> three interactions but dozens of contributors willing to fix them where is >> the issue? > > Not trying to slam people, but don't confuse willing with able (for various > reasons such as ability, time constraints, lack of specific hardware, etc.) This is true for any fedora related activity. And when I say willing, it means more than willing, but also a plan, and even better patches/packages already prepared... -- Pat From j.w.r.degoede at hhs.nl Thu Jan 10 15:04:14 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 10 Jan 2008 16:04:14 +0100 Subject: IIDC camera's and the juju firewirestack Message-ID: <478633EE.2030407@hhs.nl> Hi All, In the thread I started about Fedora perhaps being to cutting edge, it was said that I shouldn't complain as there is only one problem left with the juju stack which is a bug with via vt6306 cards in OHCI 1.0 cards. Further analysis of the problem has learned that this is not true, I'm using a via vt6306 card in OHCI 1.1 mode, which allegedly should work fine. However most documents talk about using the juju stack with either harddisks or DV for homevideo camera's. However I'm trying to use an industrial cam which used the IIDC protocol, and support in the new juju stack (kernel + userspace) for the IIDC protocol isn't very good. As the consensus from the other thread seems to be that having 2 parallel stacks is not a good plan, I have decided to spend some time to get the IIDC situation with the juju stack improved. However I'm pretty new to all this, so I will need a couple of pointers to get me up to speed. I've been testing with the grab_gray_image example from libdc1394-2.0.0. The problem is that it hangs at the dc1394_capture_dequeue(camera, DC1394_CAPTURE_POLICY_WAIT, &frame) call. The camera does seem to be sending data, as its activity led is flickering. Any clues for further debugging this would be much appreciated, shall I put this in bugzilla? If so against which component? Regards, Hans p.s. Yes I know that libdc1394 currently is not in Fedora, but that can be changed, it has some pieces of patented code, but those can be disabled using a ./configure option -> are #ifdef'd and can thus be removed automatically from the source code using some special tools. From ajackson at redhat.com Thu Jan 10 15:41:29 2008 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 10 Jan 2008 10:41:29 -0500 Subject: Impending X driver deprecation In-Reply-To: <47857FE3.7050000@redhat.com> References: <1199906969.15130.40.camel@localhost.localdomain> <47857FE3.7050000@redhat.com> Message-ID: <1199979689.15130.165.camel@localhost.localdomain> On Wed, 2008-01-09 at 21:16 -0500, Warren Togami wrote: > Adam Jackson wrote: > > I'm grinding through porting the various X drivers to the new server > > APIs, and I'm taking the opportunity to clean house a bit. Here's what > > I'm planning: > > http://www.x.org/wiki/AMDGeodeDriver > Could you help to port the AMD Geode driver to newer API's? It is a > very common chipset used in thin client hardware (as well as OLPC). I didn't say I was dropping geode. Implicit in this was that it would be ported. > > The ark, chips, s3, and tseng drivers are going away. These are all > > really boring early PCI chipsets that don't even have a 3d engine. They > > should be adequately serviced by the vesa driver. (Note that there are > > three drivers for the various S3 cards: s3, s3virge, and savage. s3 is > > for the old pre-Virge chips, 968 and Trio and friends. s3virge and > > savage are not being dropped.) > > Please reconsider s3? > > It is used by several of the thin client models selling today, and > Intel's "Affordable PC" reference platform that is being sold in large > numbers in the developing world (e.g. China) by companies like Dell. No it's not. I have one of those. It's a sis chip. - ajax From caillon at redhat.com Thu Jan 10 15:22:41 2008 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 10 Jan 2008 16:22:41 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <20080110145042.GA2587@free.fr> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> <1199924388.15130.159.camel@localhost.localdomain> <20080110001941.GJ2664@free.fr> <1199925522.25567.57.camel@oneill.fubar.dk> <20080110005703.GL2664@free.fr> <1199927642.25567.81.camel@oneill.fubar.dk> <4786216A.4060502@redhat.com> <20080110145042.GA2587@free.fr> Message-ID: <47863841.2020004@redhat.com> On 01/10/2008 03:50 PM, Patrice Dumas wrote: > It is not right if more softwares come with more contributors. Or if the > contributors have do it anyway, but cannot easily share what they did. Sure it does. We're getting contributors to completely new things, not the things we're shipping and definitely not the things people are complaining about being broken. It's great that people are interested in Fedora, and great that they want to see their package in Fedora. But it doesn't help fix your firewire bugs. One of the reasons projects like Mozilla, GNOME, KDE, etc. are successful is they have clearly defined goals, and people are working with more or less a stable amount of code. Things get re-written all the time, but the old thing gets thrown out in favor of the hot new thing. Any new contributor is _generally_ going to work on fixing existent code, not introducing new code, which is completely opposite from Fedora where the new contributor is adding code, not helping fix the existing code. Just some random musings... From jwilson at redhat.com Thu Jan 10 15:27:38 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 10 Jan 2008 10:27:38 -0500 Subject: IIDC camera's and the juju firewirestack In-Reply-To: <478633EE.2030407@hhs.nl> References: <478633EE.2030407@hhs.nl> Message-ID: <4786396A.4060605@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hans de Goede wrote: > In the thread I started about Fedora perhaps being to cutting edge, it > was said that I shouldn't complain as there is only one problem left > with the juju stack which is a bug with via vt6306 cards in OHCI 1.0 cards. Oh, there's definitely more than one problem left... :) > Further analysis of the problem has learned that this is not true, I'm > using a via vt6306 card in OHCI 1.1 mode, which allegedly should work fine. The particular bug is actually related to vt6306 and vt6307 cards in OHCI 1.0 mode doing dv capture. iidc is much less tested. I already know where at least a few of the iidc-related OHCI 1.0 bugs are, but they shouldn't be impacting you... I've also got an idea or two on what's up with dv capture, just need to get the spare cycles to test (which could happen shortly, just finished a major piece of lirc...) > However most documents talk about using the juju stack with either > harddisks or DV for homevideo camera's. However I'm trying to use an > industrial cam which used the IIDC protocol, and support in the new juju > stack (kernel + userspace) for the IIDC protocol isn't very good. I believe David Moore's patch in linux1394-2.6.git[*] should help, and it looks like that also needs to be ported over to the OHCI 1.0 code paths... > As the consensus from the other thread seems to be that having 2 > parallel stacks is not a good plan, I have decided to spend some time to > get the IIDC situation with the juju stack improved. However I'm pretty > new to all this, so I will need a couple of pointers to get me up to speed. Awesome, we definitely need more help. Neither krh nor I is able to spend quite as much time on juju as we'd like right now... > I've been testing with the grab_gray_image example from libdc1394-2.0.0. > The problem is that it hangs at the dc1394_capture_dequeue(camera, > DC1394_CAPTURE_POLICY_WAIT, &frame) call. > > The camera does seem to be sending data, as its activity led is flickering. > > Any clues for further debugging this would be much appreciated That git patch would be the first step. I'll look at doing similar for OHCI 1.0, as well as testing out an idea I had wrt dv capture on OHCI 1.0... > shall I put this in bugzilla? Might as well. Some of it is already there, but nothing iidc-specific yet. > If so against which component? I'd file it against kernel, but assign it to me and cc krh at redhat.com and fenlason at redhat.com. [*] http://git.kernel.org/?p=linux/kernel/git/ieee1394/linux1394-2.6.git;a=commitdiff;h=e9f5ca46377ac60a6b7d52c6c19a1661c87c6e20 - -- Jarod Wilson jwilson at redhat.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHhjlqtO+bni+75QMRAptqAJ4ndhFsNe9yyHVzjKVv7Mlzq7wHbACg0FFB eOsRcGVaAUtv7QbgEus+np4= =K0/M -----END PGP SIGNATURE----- From lesmikesell at gmail.com Thu Jan 10 15:31:14 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 10 Jan 2008 09:31:14 -0600 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <20080110144603.GA38099@dspnet.fr.eu.org> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> Message-ID: <47863A42.7010409@gmail.com> Olivier Galibert wrote: > On Thu, Jan 10, 2008 at 08:06:53AM -0600, Les Mikesell wrote: >> Zfs isn't the only interesting thing about opensolaris and Sun does give >> you the candy if you take the whole package. It is only the Linux terms >> that keep you from adding the parts. Solaris has an entirely different >> attitude about backwards compatibility which makes the mention slightly >> on topic for this conversation. I can't, for example, imagine them ever >> changing a device name arbitrarily and breaking a previously working >> configuration while Linux has no such respect for its users' previous >> work. Fedora may not be the place for it, but I would seriously like to >> see a distribution based on the OpenSolaris kernel and the same user >> programs you'd find in a current Linux or *bsd distro. > > Given that it's the user programs that have the lack of respect for > previous configurations (Linus considers backwards-compatibility very > important), I doubt you'll see any change for the better. Is it a user program that has changed my /dev/hdX into /dev/sdX more or less arbitrarily - or turns what used to be detected as eth0 into eth2 when a different kernel is booted? Admittedly it has been a while since I've used Solaris, but I can't recall anything like that ever happening with it. In a unix-like system where access to everything is through its device/file name, what is more fundamental than that? -- Les Mikesell lesmikesell at gmail.com From pertusus at free.fr Thu Jan 10 15:31:56 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 10 Jan 2008 16:31:56 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <47863841.2020004@redhat.com> References: <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> <1199924388.15130.159.camel@localhost.localdomain> <20080110001941.GJ2664@free.fr> <1199925522.25567.57.camel@oneill.fubar.dk> <20080110005703.GL2664@free.fr> <1199927642.25567.81.camel@oneill.fubar.dk> <4786216A.4060502@redhat.com> <20080110145042.GA2587@free.fr> <47863841.2020004@redhat.com> Message-ID: <20080110153156.GE2587@free.fr> On Thu, Jan 10, 2008 at 04:22:41PM +0100, Christopher Aillon wrote: > On 01/10/2008 03:50 PM, Patrice Dumas wrote: >> It is not right if more softwares come with more contributors. Or if the >> contributors have do it anyway, but cannot easily share what they did. > > Sure it does. We're getting contributors to completely new things, not the > things we're shipping and definitely not the things people are complaining > about being broken. It's great that people are interested in Fedora, and Why not? One could imagine that somebody steps up to package the stuff needed by the old firewire stack? I don't know that issue very well, but I can imagine people wanting to fix things in fedora if they are annoying them. -- Pat From david at fubar.dk Thu Jan 10 15:29:50 2008 From: david at fubar.dk (David Zeuthen) Date: Thu, 10 Jan 2008 10:29:50 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <20080110091741.GA2556@free.fr> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> <1199924388.15130.159.camel@localhost.localdomain> <20080110001941.GJ2664@free.fr> <1199925522.25567.57.camel@oneill.fubar.dk> <20080110005703.GL2664@free.fr> <1199927642.25567.81.camel@oneill.fubar.dk> <20080110091741.GA2556@free.fr> Message-ID: <1199978990.30858.28.camel@oneill.fubar.dk> On Thu, 2008-01-10 at 10:17 +0100, Patrice Dumas wrote: > > have a non Linux kernel. Moreover, I'm pretty sure, by just reading your > > mails, that you don't realize what using a non Linux kernel even > > entails. > > Indeed. This was an extreme example to avoid getting in the technical > argument, ?Interesting. So this is a concrete example of how your whole line of reasoning is filled with hyperbole. It seems you are using this hyperbole, along with mistaken notions of "freedom" and "diversity", as a platform for trying to argue that we should be more open to "choice". > but keep talking on the organisational issues. So please take this *elsewhere*. I think we should stick to technical subjects on this list instead of coming up with wacky examples that is beyond ones comprehension. All you have down here, Patrice, is to screw up the SN ratio of this list even more. (Seriously, I don't even know why I'm on this list anymore. Maybe we need a fedora-codemonkeys-list where we can ban people using hyperbole instead of sticking to technical facts and reality. Perhaps, someone could get even some work done on such a list.) David From jwilson at redhat.com Thu Jan 10 15:43:29 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 10 Jan 2008 10:43:29 -0500 Subject: Fedora too cutting edge? In-Reply-To: References: <4785163E.8010508@hhs.nl> <1199908164.4765.49.camel@metroid.rdu.redhat.com> <47853516.2060600@hhs.nl> Message-ID: <47863D21.8050905@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Krzysztof Halasa wrote: > Hans de Goede writes: > >> As for this being fixed, not for my case, as I have a via vt 6306 >> controller, which is like, only the most common PC firewire controller >> on the planet. > > It should do OHCI 1.1, you may want to take the risk and try the > program. Make sure you have a backup (the GUID and possibly whole > EEPROM data). > > VIA claims both VT6306 and VT6307 are OHCI-1.1 (capable), I just > have no VT6306 to test (actually it seems VT6307 is a cheeper > version, aimed at motherboard manufacturers). Honestly, I'd rather we just figured out what's wrong with the Via chipsets in OHCI 1.0 mode, rather than relying on people flashing their controllers to 1.1 mode. I've got a few ideas, hoping to get back to juju hacking shortly... - -- Jarod Wilson jwilson at redhat.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHhj0htO+bni+75QMRAhXwAKCmNgMnbjbja2N7KkZgIGOxt3rg/wCfbUfx tT80wr/+xTReayG/Bj5AjEk= =nykA -----END PGP SIGNATURE----- From dominik at greysector.net Thu Jan 10 15:42:30 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 10 Jan 2008 16:42:30 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <47863A42.7010409@gmail.com> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> Message-ID: <20080110154230.GB3246@ryvius.greysector.net> On Thursday, 10 January 2008 at 16:31, Les Mikesell wrote: > Olivier Galibert wrote: >> On Thu, Jan 10, 2008 at 08:06:53AM -0600, Les Mikesell wrote: >>> Zfs isn't the only interesting thing about opensolaris and Sun does give >>> you the candy if you take the whole package. It is only the Linux terms >>> that keep you from adding the parts. Solaris has an entirely different >>> attitude about backwards compatibility which makes the mention slightly >>> on topic for this conversation. I can't, for example, imagine them ever >>> changing a device name arbitrarily and breaking a previously working >>> configuration while Linux has no such respect for its users' previous >>> work. Fedora may not be the place for it, but I would seriously like to >>> see a distribution based on the OpenSolaris kernel and the same user >>> programs you'd find in a current Linux or *bsd distro. >> >> Given that it's the user programs that have the lack of respect for >> previous configurations (Linus considers backwards-compatibility very >> important), I doubt you'll see any change for the better. > > Is it a user program that has changed my /dev/hdX into /dev/sdX more or > less arbitrarily Can you say "filesystem labels"? I thought so. > - or turns what used to be detected as eth0 into eth2 when > a different kernel is booted? echo -e "alias eth0 module1\nalias eth2 module2\n" >> /etc/modprobe.conf has always worked for me. Have you filed a bug? Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From pertusus at free.fr Thu Jan 10 15:47:06 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 10 Jan 2008 16:47:06 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199978990.30858.28.camel@oneill.fubar.dk> References: <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> <1199924388.15130.159.camel@localhost.localdomain> <20080110001941.GJ2664@free.fr> <1199925522.25567.57.camel@oneill.fubar.dk> <20080110005703.GL2664@free.fr> <1199927642.25567.81.camel@oneill.fubar.dk> <20080110091741.GA2556@free.fr> <1199978990.30858.28.camel@oneill.fubar.dk> Message-ID: <20080110154706.GF2587@free.fr> On Thu, Jan 10, 2008 at 10:29:50AM -0500, David Zeuthen wrote: > > > Indeed. This was an extreme example to avoid getting in the technical > > argument, > > ?Interesting. So this is a concrete example of how your whole line of > reasoning is filled with hyperbole. It is not an hyperbole (I guess that you mean exageration by this word), it is an example. I used that example because it allows to discuss about choices. Choices that are done in the fedora community, that have technical consequences. > It seems you are using this > hyperbole, along with mistaken notions of "freedom" and "diversity", as > a platform for trying to argue that we should be more open to "choice". I personnally favour the openness to choice, but I am clearly not the only one to do such an important choice for fedora. It should be clear, however for fedora contributors what is acceptable. > > but keep talking on the organisational issues. > > So please take this *elsewhere*. I think we should stick to technical > subjects on this list instead of coming up with wacky examples that is > beyond ones comprehension. This is very important, in my opinion, to speak about organizational subjects and not only strictly technical subjects. I think that what kind of packages are accepted in fedora is an important question for the fedora community. > All you have down here, Patrice, is to screw > up the SN ratio of this list even more. That's possible, but not on purpose. > (Seriously, I don't even know why I'm on this list anymore. Maybe we > need a fedora-codemonkeys-list where we can ban people using hyperbole > instead of sticking to technical facts and reality. Perhaps, someone > could get even some work done on such a list.) If this list is not for discussing which packages should be acceptable in fedora which list should be used for that? In my opinion this is the list where the community members like me and you can voice their concerns. -- Pat From j.w.r.degoede at hhs.nl Thu Jan 10 15:48:46 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 10 Jan 2008 16:48:46 +0100 Subject: Fedora too cutting edge? In-Reply-To: <47863D21.8050905@redhat.com> References: <4785163E.8010508@hhs.nl> <1199908164.4765.49.camel@metroid.rdu.redhat.com> <47853516.2060600@hhs.nl> <47863D21.8050905@redhat.com> Message-ID: <47863E5E.5080500@hhs.nl> Jarod Wilson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Krzysztof Halasa wrote: >> Hans de Goede writes: >> >>> As for this being fixed, not for my case, as I have a via vt 6306 >>> controller, which is like, only the most common PC firewire controller >>> on the planet. >> It should do OHCI 1.1, you may want to take the risk and try the >> program. Make sure you have a backup (the GUID and possibly whole >> EEPROM data). >> >> VIA claims both VT6306 and VT6307 are OHCI-1.1 (capable), I just >> have no VT6306 to test (actually it seems VT6307 is a cheeper >> version, aimed at motherboard manufacturers). > > Honestly, I'd rather we just figured out what's wrong with the Via chipsets in > OHCI 1.0 mode, rather than relying on people flashing their controllers to 1.1 > mode. I've got a few ideas, hoping to get back to juju hacking shortly... > I didn't flash my controller, I wanted too, but it turned out it already was put in 1.1 by the manufacturer of the card I'm using. I'm willing to flash to 1.0 mode to help test IIDC in 1.0 mode though, but first let get IIDC working with the card in 1.1 mode :) Regards, Hans From caillon at redhat.com Thu Jan 10 15:49:58 2008 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 10 Jan 2008 16:49:58 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <20080110153156.GE2587@free.fr> References: <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> <1199924388.15130.159.camel@localhost.localdomain> <20080110001941.GJ2664@free.fr> <1199925522.25567.57.camel@oneill.fubar.dk> <20080110005703.GL2664@free.fr> <1199927642.25567.81.camel@oneill.fubar.dk> <4786216A.4060502@redhat.com> <20080110145042.GA2587@free.fr> <47863841.2020004@redhat.com> <20080110153156.GE2587@free.fr> Message-ID: <47863EA6.1080903@redhat.com> On 01/10/2008 04:31 PM, Patrice Dumas wrote: > On Thu, Jan 10, 2008 at 04:22:41PM +0100, Christopher Aillon wrote: >> On 01/10/2008 03:50 PM, Patrice Dumas wrote: >>> It is not right if more softwares come with more contributors. Or if the >>> contributors have do it anyway, but cannot easily share what they did. >> Sure it does. We're getting contributors to completely new things, not the >> things we're shipping and definitely not the things people are complaining >> about being broken. It's great that people are interested in Fedora, and > > Why not? One could imagine that somebody steps up to package the stuff > needed by the old firewire stack? I don't know that issue very well, but > I can imagine people wanting to fix things in fedora if they are > annoying them. Because that's not fixing them, as has been echoed many times. That's only reintroducing different code. Which works for some people and breaks for others. Fixing it would mean making it work for everyone. Or do we not care about that? From david at fubar.dk Thu Jan 10 15:58:14 2008 From: david at fubar.dk (David Zeuthen) Date: Thu, 10 Jan 2008 10:58:14 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <20080110154706.GF2587@free.fr> References: <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> <1199924388.15130.159.camel@localhost.localdomain> <20080110001941.GJ2664@free.fr> <1199925522.25567.57.camel@oneill.fubar.dk> <20080110005703.GL2664@free.fr> <1199927642.25567.81.camel@oneill.fubar.dk> <20080110091741.GA2556@free.fr> <1199978990.30858.28.camel@oneill.fubar.dk> <20080110154706.GF2587@free.fr> Message-ID: <1199980694.30858.31.camel@oneill.fubar.dk> On Thu, 2008-01-10 at 16:47 +0100, Patrice Dumas wrote: > If this list is not for discussing which packages should be acceptable > in fedora which list should be used for that? In my opinion this is the > list where the community members like me and you can voice their concerns. No, that's fedora-list or fedora-advisory-board or whatever list of the week that non-technical discussions happens on. This list is for technical discussions - please do avoid participating unless you know what you are talking about. David From jwilson at redhat.com Thu Jan 10 16:04:50 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 10 Jan 2008 11:04:50 -0500 Subject: Fedora too cutting edge? In-Reply-To: References: <4785163E.8010508@hhs.nl> Message-ID: <47864222.4090508@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Pablo Lopez-Lezcano wrote: > On Wed, 9 Jan 2008, Hans de Goede wrote: >> Notice how a preliminary fix is expected for 2.6.25, which probably >> means that this will still be broken in Fedora 9, notice that the >> breakage was introduced in Fedora 7, so thats 18 months worth of >> broken firewire camera support (iow most digital video cameras). No, we can add said preliminary fix to the F9 (and earlier) kernels. In fact, I'm inclined to add the OHCI 1.1 iidc fixes from David Moore to rawhide later today, as well as port them to the 1.0 code (which I'd also include). > _and_ firewire audio interfaces as well. > > Which forced me and others to return to the original stack in my > realtime tuned kernels for Planet CCRMA. And unpatch the corresponding > libraries. And keep track of the whole mess. A royal pain you know > where. Planet CCRMA is about audio. Non working interfaces that were > working before is not good. > > If you ask me, 18 months is way too long. It is/was a failed experiment. Nah, its not failed, its just not complete. It works quite well where it does work -- sbp2 devices and dv capture. In the sbp2 case, it works far better than the old stack ever did. We're just a bit lacking in man power to fix up the broken things. Rather than spend time working on fixing the new stack, people run back to the old stack. Of course, I understand some people need things to be working NOW, but there's a chicken and egg problem there. I don't do any firewire audio stuff, so offhand, I don't have a clue how to fix the particular problems you're seeing (I'm not even sure *what* the problems are). The things I do (sbp2 storage and dv capture) pretty much Just Work -- and dv capture only does so on (most) OHCI 1.0 controllers, because I sat down and wrote the OCHI 1.0 isochronous receive support code (with lots of help from krh, mind you, since I knew nothing about the code going in). > My opinion is that the new stack was not and still is not ready for > inclusion in a mainstream distro. It just breaks too many things that > people actually need to do work on the computer running that kernel. Another chicken and egg problem. How do we know it doesn't work if we don't ship it? >> What IMHO we should have done is build both the new and the oldstack, >> which is possible on the kernel side, and modify our patches to >> userspace to support the juju stack, so that the userspace libs can >> work with either one. On top of this we should then have written a >> small gui utility for easy switching. > > Yup. Or wait till the stack actually works. But then a big chorus will > probably say if we don't ship it it will not get fixed or whatever. Yeah, I'm part of the chorus. > But > it has been shipped for a long time and not fixed so I _don't_ buy that > argument. Admittedly, we've been rather slow to fix things, so I do understand your not agreeing with the chorus. :) But things *are* improving, and we *do* intend on continuing to fix things. We're just a bit short on man-power to actually sit down, reproduce problems, debug and fix them. I only recently got familiar with the kernel code myself, and my day job deals mainly with RHEL kernel stuff, but I'm quite happy to try to help out with any Fedora firewire bugs still outstanding (several are already on my plate). If you have any open bugs, or want to file any new ones, please do. Assign them to me (jwilson at redhat.com) and cc Kristian (krh at redhat.com) and Jay (fenlason at redhat.com). > Agreed... At least firewire has been broken for too long (IMHO) Agreed. - -- Jarod Wilson jwilson at redhat.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHhkIitO+bni+75QMRAkcmAJ9ta7O+tKguNZV4kC7f9m+dILAroACfRGED 5vFshBmoYxzrNhXwWDdR6BA= =F7YB -----END PGP SIGNATURE----- From jkeating at redhat.com Thu Jan 10 16:05:02 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 10 Jan 2008 11:05:02 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <20080110153156.GE2587@free.fr> References: <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> <1199924388.15130.159.camel@localhost.localdomain> <20080110001941.GJ2664@free.fr> <1199925522.25567.57.camel@oneill.fubar.dk> <20080110005703.GL2664@free.fr> <1199927642.25567.81.camel@oneill.fubar.dk> <4786216A.4060502@redhat.com> <20080110145042.GA2587@free.fr> <47863841.2020004@redhat.com> <20080110153156.GE2587@free.fr> Message-ID: <20080110110502.433d43d0@redhat.com> On Thu, 10 Jan 2008 16:31:56 +0100 Patrice Dumas wrote: > Why not? One could imagine that somebody steps up to package the stuff > needed by the old firewire stack? I don't know that issue very well, > but I can imagine people wanting to fix things in fedora if they are > annoying them. Also, there is a /huge/ difference between "I can package this!" and "I can be responsible for all the bug reports regarding this, and help to transition folks using this to that, and help improve that along the way." -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Thu Jan 10 16:14:00 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 10 Jan 2008 11:14:00 -0500 Subject: PATCH: add --loginpause to mingetty In-Reply-To: <1199971666.8159.28.camel@localhost.localdomain> References: <478564D9.5080303@codewiz.org> <1199971666.8159.28.camel@localhost.localdomain> Message-ID: <20080110161400.GB2852@nostromo.devel.redhat.com> Lubomir Kundrak (lkundrak at redhat.com) said: > > I'm committing these changes to the OLPC-2 branch of mingetty in > > Fedora CVS. Please, let me know you'd like to merge them or > > something similar. > > Such things are definitely better upstreamed if possible. Have you tried > contacting upstream? Florian is upstream, IIRC. Bill From lesmikesell at gmail.com Thu Jan 10 16:17:19 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 10 Jan 2008 10:17:19 -0600 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <20080110154230.GB3246@ryvius.greysector.net> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <20080110154230.GB3246@ryvius.greysector.net> Message-ID: <4786450F.8010900@gmail.com> Dominik 'Rathann' Mierzejewski wrote: >> Is it a user program that has changed my /dev/hdX into /dev/sdX more or >> less arbitrarily > > Can you say "filesystem labels"? I thought so. I can say it won't fix an existing configuration. I can say that filesystem label creation wasn't well thought out for people that move disks around (after you've installed fedora on all your machines, they'll all have the same labels and the system is not happy when you rebuild a machine with a different combination of drives). I can say that the design of solaris seems to take machine management over long intervals of time and large numbers of machines into consideration whereas Linux does not. >> - or turns what used to be detected as eth0 into eth2 when >> a different kernel is booted? > > echo -e "alias eth0 module1\nalias eth2 module2\n" >> /etc/modprobe.conf > has always worked for me. That worked in 2.4 kernels. It doesn't with udev based kernels. And if you managed some number of machines with multiple interfaces you'd probably care - especially if they are remote and you lose access when the network doesn't come up after a reboot. > Have you filed a bug? Is it a bug or is udev supposed to detect devices in parallel and dynamically (randomly)? It is the same with /dev/sdX devices. How do I know which one is /dev/sdh today? And If I don't know, even If I wanted to use filesystem labels, what would I call the device when I wanted to create the label? (BTW, what I usually do to work around this issue is create an md raid device even if it is a single drive with a missing partner and use the md device name in the fstab entry because at least so far I have been able to count on consistency in detecting the uuids and have always gotten unique ones by default). -- Les Mikesell lesmikesell at gmail.com From laroche at redhat.com Thu Jan 10 16:18:07 2008 From: laroche at redhat.com (Florian La Roche) Date: Thu, 10 Jan 2008 17:18:07 +0100 Subject: PATCH: add --loginpause to mingetty In-Reply-To: <20080110161400.GB2852@nostromo.devel.redhat.com> References: <478564D9.5080303@codewiz.org> <1199971666.8159.28.camel@localhost.localdomain> <20080110161400.GB2852@nostromo.devel.redhat.com> Message-ID: <20080110161807.GA14587@dudweiler.stuttgart.redhat.com> On Thu, Jan 10, 2008 at 11:14:00AM -0500, Bill Nottingham wrote: > Lubomir Kundrak (lkundrak at redhat.com) said: > > > I'm committing these changes to the OLPC-2 branch of mingetty in > > > Fedora CVS. Please, let me know you'd like to merge them or > > > something similar. > > > > Such things are definitely better upstreamed if possible. Have you tried > > contacting upstream? > > Florian is upstream, IIRC. Hello Bernardo Innocenti, I've refused to add many other feature requests and AFAIK we do have quite a few forks of mingetty now available. But I think the downscaling side of Linux is pretty important, from small machines up to larges ones with virtualization. ;-) I'll have a look around at other patches floating around and generate another upstream release with these posted ones here. They look sane to me. Thanks a lot, Florian La Roche From lesmikesell at gmail.com Thu Jan 10 16:29:41 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 10 Jan 2008 10:29:41 -0600 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <20080110110502.433d43d0@redhat.com> References: <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> <1199924388.15130.159.camel@localhost.localdomain> <20080110001941.GJ2664@free.fr> <1199925522.25567.57.camel@oneill.fubar.dk> <20080110005703.GL2664@free.fr> <1199927642.25567.81.camel@oneill.fubar.dk> <4786216A.4060502@redhat.com> <20080110145042.GA2587@free.fr> <47863841.2020004@redhat.com> <20080110153156.GE2587@free.fr> <20080110110502.433d43d0@redhat.com> Message-ID: <478647F5.30900@gmail.com> Jesse Keating wrote: > On Thu, 10 Jan 2008 16:31:56 +0100 > Patrice Dumas wrote: > >> Why not? One could imagine that somebody steps up to package the stuff >> needed by the old firewire stack? I don't know that issue very well, >> but I can imagine people wanting to fix things in fedora if they are >> annoying them. > > > Also, there is a /huge/ difference between "I can package this!" and "I > can be responsible for all the bug reports regarding this, and help to > transition folks using this to that, and help improve that along the > way." This is the philosophical issue - but it applies whether you support backwards compatiblity or not. In the now diverged firewire juju thread there is a comment: "Awesome, we definitely need more help. Neither krh nor I is able to spend quite as much time on juju as we'd like right now..." Of course "stuff happens" and things aren't ever going to be perfect, but why does a fundamental change go in at the device driver level without providing a way to revert to the previous version unless there is at least some expectation of having the resources to fix the new problems that will almost certainly show up? -- Les Mikesell lesmikesell at gmail.com From david at fubar.dk Thu Jan 10 16:28:07 2008 From: david at fubar.dk (David Zeuthen) Date: Thu, 10 Jan 2008 11:28:07 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <47863A42.7010409@gmail.com> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> Message-ID: <1199982487.30858.38.camel@oneill.fubar.dk> On Thu, 2008-01-10 at 09:31 -0600, Les Mikesell wrote: > Is it a user program that has changed my /dev/hdX into /dev/sdX more or > less arbitrarily - or turns what used to be detected as eth0 into eth2 > when a different kernel is booted? Admittedly it has been a while since > I've used Solaris, but I can't recall anything like that ever happening > with it. In a unix-like system where access to everything is through > its device/file name, what is more fundamental than that? This is a flawed example. The problem is that you're relying on names assigned in an irregular fashion and it will happen on Solaris as well if you move disks between controllers etc. The way to do this in the modern world is to rely on persistent names. See /dev/disk/* and the udev rules for stable network interface names. Of course you can argue that e.g. /dev/sda or /dev/hda should stay stable but I doubt you're going to find much sympathy for such a point of view. David From david at fubar.dk Thu Jan 10 16:28:07 2008 From: david at fubar.dk (David Zeuthen) Date: Thu, 10 Jan 2008 11:28:07 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <47863A42.7010409@gmail.com> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> Message-ID: <1199982487.30858.38.camel@oneill.fubar.dk> On Thu, 2008-01-10 at 09:31 -0600, Les Mikesell wrote: > Is it a user program that has changed my /dev/hdX into /dev/sdX more or > less arbitrarily - or turns what used to be detected as eth0 into eth2 > when a different kernel is booted? Admittedly it has been a while since > I've used Solaris, but I can't recall anything like that ever happening > with it. In a unix-like system where access to everything is through > its device/file name, what is more fundamental than that? This is a flawed example. The problem is that you're relying on names assigned in an irregular fashion and it will happen on Solaris as well if you move disks between controllers etc. The way to do this in the modern world is to rely on persistent names. See /dev/disk/* and the udev rules for stable network interface names. Of course you can argue that e.g. /dev/sda or /dev/hda should stay stable but I doubt you're going to find much sympathy for such a point of view. David From david at fubar.dk Thu Jan 10 16:31:51 2008 From: david at fubar.dk (David Zeuthen) Date: Thu, 10 Jan 2008 11:31:51 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199982487.30858.38.camel@oneill.fubar.dk> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> Message-ID: <1199982711.30858.41.camel@oneill.fubar.dk> On Thu, 2008-01-10 at 11:28 -0500, David Zeuthen wrote: > udev rules for stable network interface names. Btw, that would be /etc/udev/rules.d/70-persistent-net.rules /etc/udev/rules.d/75-persistent-net-generator.rules HTH. Follow up with questions on the udev list please. David From pemboa at gmail.com Thu Jan 10 16:40:34 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 10 Jan 2008 10:40:34 -0600 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199982711.30858.41.camel@oneill.fubar.dk> References: <4785163E.8010508@hhs.nl> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <1199982711.30858.41.camel@oneill.fubar.dk> Message-ID: <16de708d0801100840t61b4f1b4p2e999c07563d1030@mail.gmail.com> On Jan 10, 2008 10:31 AM, David Zeuthen wrote: > > On Thu, 2008-01-10 at 11:28 -0500, David Zeuthen wrote: > > udev rules for stable network interface names. > > Btw, that would be > > /etc/udev/rules.d/70-persistent-net.rules > /etc/udev/rules.d/75-persistent-net-generator.rules > > HTH. Follow up with questions on the udev list please. We are badly in need of system-config-udev. I spent several hours understanding udev adn building rules for my sound cards and tv cards. I hadn't done a yum update on my F7 box for weeks/months (lazyness) did one this week, and it apperently just blew away my custom udev config -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From devrim at CommandPrompt.com Thu Jan 10 16:45:07 2008 From: devrim at CommandPrompt.com (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=) Date: Thu, 10 Jan 2008 08:45:07 -0800 Subject: rpms/sepostgresql/devel postgresql-8.2.6.tar.gz, NONE, 1.1 .cvsignore, 1.4, 1.5 sepostgresql.init, 1.8, 1.9 sepostgresql.spec, 1.8, 1.9 sepostgresql.te, 1.8, 1.9 In-Reply-To: <200801101437.m0AEbemG002515@cvs-int.fedora.redhat.com> References: <200801101437.m0AEbemG002515@cvs-int.fedora.redhat.com> Message-ID: <1199983507.3398.14.camel@localhost.localdomain> Hi, On Thu, 2008-01-10 at 09:37 -0500, KaiGai Kohei wrote: > Added Files: > postgresql-8.2.6.tar.gz > Log Message: > add postgresql-8.2.6.tar.gz Why do you keep the tarball in CVS??? Regards, -- Devrim G?ND?Z , RHCE PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From lesmikesell at gmail.com Thu Jan 10 16:47:42 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 10 Jan 2008 10:47:42 -0600 Subject: Fedora too cutting edge? In-Reply-To: <47864222.4090508@redhat.com> References: <4785163E.8010508@hhs.nl> <47864222.4090508@redhat.com> Message-ID: <47864C2E.7090505@gmail.com> Jarod Wilson wrote: > > Another chicken and egg problem. How do we know it doesn't work if we don't > ship it? Ship it with a way to revert to previous behavior. If people post bugzilla items and revert, you know it didn't work and you will still have someone to test your next experiment. >> Agreed... At least firewire has been broken for too long (IMHO) I gave up on it somewhere around FC3 and switched to the CentOSplus kernel where I needed something that mostly worked. So I'm not a good tester any more. -- Les Mikesell lesmikesell at gmail.com From david at fubar.dk Thu Jan 10 16:54:42 2008 From: david at fubar.dk (David Zeuthen) Date: Thu, 10 Jan 2008 11:54:42 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <16de708d0801100840t61b4f1b4p2e999c07563d1030@mail.gmail.com> References: <4785163E.8010508@hhs.nl> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <1199982711.30858.41.camel@oneill.fubar.dk> <16de708d0801100840t61b4f1b4p2e999c07563d1030@mail.gmail.com> Message-ID: <1199984082.30858.56.camel@oneill.fubar.dk> On Thu, 2008-01-10 at 10:40 -0600, Arthur Pemberton wrote: > We are badly in need of system-config-udev. I spent several hours > understanding udev adn building rules for my sound cards and tv cards. > I hadn't done a yum update on my F7 box for weeks/months (lazyness) > did one this week, and it apperently just blew away my custom udev > config Hell no. We are in badly need of this crap just working out of the box. Throwing configuration / options at the problem will only make it worse. Trying to explain this to people is apparently impossible since people keep proposing stupid configuration tools with "unbreak my system" options. David From lesmikesell at gmail.com Thu Jan 10 17:00:24 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 10 Jan 2008 11:00:24 -0600 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199982487.30858.38.camel@oneill.fubar.dk> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> Message-ID: <47864F28.4030708@gmail.com> David Zeuthen wrote: >> Is it a user program that has changed my /dev/hdX into /dev/sdX more or >> less arbitrarily - or turns what used to be detected as eth0 into eth2 >> when a different kernel is booted? Admittedly it has been a while since >> I've used Solaris, but I can't recall anything like that ever happening >> with it. In a unix-like system where access to everything is through >> its device/file name, what is more fundamental than that? > > This is a flawed example. The problem is that you're relying on names > assigned in an irregular fashion and it will happen on Solaris as well > if you move disks between controllers etc. But the old names were predictable; the new ones aren't - when I move a disk to a new controller/drive position, I know about it. > The way to do this in the > modern world is to rely on persistent names. See /dev/disk/* and the > udev rules for stable network interface names. Of course you can argue > that e.g. /dev/sda or /dev/hda should stay stable but I doubt you're > going to find much sympathy for such a point of view. What I actually would argue is that a distribution making such changes should supply tools to migrate configurations based on old conventions to the new ones. Maybe Fedora doesn't have users with hundreds of machines and data that needs to span years of operation, but a unix-like system should be designed to make that practical. -- Les Mikesell lesmikesell at gmail.com From nphilipp at redhat.com Thu Jan 10 17:03:53 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 10 Jan 2008 18:03:53 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199984082.30858.56.camel@oneill.fubar.dk> References: <4785163E.8010508@hhs.nl> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <1199982711.30858.41.camel@oneill.fubar.dk> <16de708d0801100840t61b4f1b4p2e999c07563d1030@mail.gmail.com> <1199984082.30858.56.camel@oneill.fubar.dk> Message-ID: <1199984633.20047.44.camel@gibraltar.str.redhat.com> On Thu, 2008-01-10 at 11:54 -0500, David Zeuthen wrote: > On Thu, 2008-01-10 at 10:40 -0600, Arthur Pemberton wrote: > > We are badly in need of system-config-udev. I spent several hours > > understanding udev adn building rules for my sound cards and tv cards. > > I hadn't done a yum update on my F7 box for weeks/months (lazyness) > > did one this week, and it apperently just blew away my custom udev > > config > > Hell no. We are in badly need of this crap just working out of the box. > Throwing configuration / options at the problem will only make it worse. > Trying to explain this to people is apparently impossible since people > keep proposing stupid configuration tools with "unbreak my system" > options. There's the bad idea that everything under /etc/ is configurable, but in reality these rules are "program data" and ideally should go into /share if that existed (which would avoid people thinking they're meant to touch that stuff, hopefully). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From lesmikesell at gmail.com Thu Jan 10 17:07:47 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 10 Jan 2008 11:07:47 -0600 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199984082.30858.56.camel@oneill.fubar.dk> References: <4785163E.8010508@hhs.nl> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <1199982711.30858.41.camel@oneill.fubar.dk> <16de708d0801100840t61b4f1b4p2e999c07563d1030@mail.gmail.com> <1199984082.30858.56.camel@oneill.fubar.dk> Message-ID: <478650E3.6020003@gmail.com> David Zeuthen wrote: >> We are badly in need of system-config-udev. I spent several hours >> understanding udev adn building rules for my sound cards and tv cards. >> I hadn't done a yum update on my F7 box for weeks/months (lazyness) >> did one this week, and it apperently just blew away my custom udev >> config > > Hell no. We are in badly need of this crap just working out of the box. > Throwing configuration / options at the problem will only make it worse. > Trying to explain this to people is apparently impossible since people > keep proposing stupid configuration tools with "unbreak my system" > options. How can it work 'out of the box' when the person who knows which of many possible devices is which is separated from the kernel and device driver by a hidden level of indirection introduced between versions? -- Les Mikesell lesmikesell at gmail.com From david at fubar.dk Thu Jan 10 17:09:22 2008 From: david at fubar.dk (David Zeuthen) Date: Thu, 10 Jan 2008 12:09:22 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <47864F28.4030708@gmail.com> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <47864F28.4030708@gmail.com> Message-ID: <1199984962.30858.66.camel@oneill.fubar.dk> On Thu, 2008-01-10 at 11:00 -0600, Les Mikesell wrote: > But the old names were predictable; the new ones aren't - when I move a > disk to a new controller/drive position, I know about it. Uhm, no. You were just relying on a) limitations in the Linux kernel to probe devices in a sequential fashion (see big-iron boxes with tens of thousands of disks why this won't work); and b) the order of your controllers on the PCI bus. Trying to argue it was "predictable" when it was a "coincidence" is an interesting spin on reality. It's also wrong; there's a reason that RHL and Fedora been using LABEL= for ages. ?A side effect of Fedora and Linux being modernized is that you have stable names so in the future problems like you describe will go away. However, one issue is to make all the stuff in the distro actually take advantage of new shiny stuff; for example Anaconda just recently started to take it's first steps in the brave new world. It's a bit sad that it takes 2-3 years for things like this to happen, maybe someone having been yelling enough at e.g. the Anaconda team ;-) > What I actually would argue is that a distribution making such changes > should supply tools to migrate configurations based on old conventions > to the new ones. Maybe Fedora doesn't have users with hundreds of > machines and data that needs to span years of operation, but a unix-like > system should be designed to make that practical. No, Fedora is about being on the bleeding edge and creating a system where you don't *need* to migrate configuration files because the files will be correct if they are using stable identifiers for devices. David From david at fubar.dk Thu Jan 10 17:11:04 2008 From: david at fubar.dk (David Zeuthen) Date: Thu, 10 Jan 2008 12:11:04 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199984633.20047.44.camel@gibraltar.str.redhat.com> References: <4785163E.8010508@hhs.nl> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <1199982711.30858.41.camel@oneill.fubar.dk> <16de708d0801100840t61b4f1b4p2e999c07563d1030@mail.gmail.com> <1199984082.30858.56.camel@oneill.fubar.dk> <1199984633.20047.44.camel@gibraltar.str.redhat.com> Message-ID: <1199985064.30858.69.camel@oneill.fubar.dk> On Thu, 2008-01-10 at 18:03 +0100, Nils Philippsen wrote: > There's the bad idea that everything under /etc/ is configurable, but in > reality these rules are "program data" and ideally should go into /share > if that existed (which would avoid people thinking they're meant to > touch that stuff, hopefully). I agree it's confusing / misleading that udev stores it's rules in /etc. They are, as you point out, really just program data (at least 99% of them). I'll talk to upstream about moving the bulk to /lib[64]/udev instead. David From Jochen at herr-schmitt.de Thu Jan 10 17:12:59 2008 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 10 Jan 2008 18:12:59 +0100 Subject: autoconf issue using -stdc=gnu++0x option in AC_CHECK_HEADER macro. Message-ID: <4786521B.8050002@herr-schmitt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I have a special question about the AC_HEADER macro in autoconf. I'm trying to text for the existence of the unordered_set header file in C++. Unfortunately, I will got a message, that I have to use the -std=gnu++0x if I want to include this header file. So I want to ask, what I have to to, that autoconf will respect this option in the AC_HEADER macro. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHhlIJT2AHK6txfgwRAoErAJ4oh0N9zPezot5ElIURiojNmsoVsQCgioJc GuW69Vv7lk7448FL8OlRSjU= =PPj/ -----END PGP SIGNATURE----- From magnus.gustavsson at liu.se Thu Jan 10 17:13:47 2008 From: magnus.gustavsson at liu.se (Magnus Gustavsson) Date: Thu, 10 Jan 2008 17:13:47 +0000 (UTC) Subject: Bruttaly sluggish Eclipse performance in remote X References: <1199746646.9735.10.camel@dimi.lattica.com> <47862752.3030103@gmail.com> Message-ID: Les Mikesell gmail.com> writes: > Have you tried running freenx with the NX clients from > http://www.nomachine.com? I have now. No improvement. /Magnus From david at fubar.dk Thu Jan 10 17:13:13 2008 From: david at fubar.dk (David Zeuthen) Date: Thu, 10 Jan 2008 12:13:13 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <478650E3.6020003@gmail.com> References: <4785163E.8010508@hhs.nl> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <1199982711.30858.41.camel@oneill.fubar.dk> <16de708d0801100840t61b4f1b4p2e999c07563d1030@mail.gmail.com> <1199984082.30858.56.camel@oneill.fubar.dk> <478650E3.6020003@gmail.com> Message-ID: <1199985193.30858.73.camel@oneill.fubar.dk> On Thu, 2008-01-10 at 11:07 -0600, Les Mikesell wrote: > How can it work 'out of the box' when the person who knows which of many > possible devices is which is separated from the kernel and device driver > by a hidden level of indirection introduced between versions? By getting things properly integrated with the kernel and udev. Yes, there's a lot of drivers that needs fixing; mostly because the authors of said drivers thought it was "good enough" to require all sort of weird kernel module parameters and have people edit things like /etc/modprobe.conf and whatnot. David From notting at redhat.com Thu Jan 10 17:16:43 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 10 Jan 2008 12:16:43 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199985064.30858.69.camel@oneill.fubar.dk> References: <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <1199982711.30858.41.camel@oneill.fubar.dk> <16de708d0801100840t61b4f1b4p2e999c07563d1030@mail.gmail.com> <1199984082.30858.56.camel@oneill.fubar.dk> <1199984633.20047.44.camel@gibraltar.str.redhat.com> <1199985064.30858.69.camel@oneill.fubar.dk> Message-ID: <20080110171643.GA7050@nostromo.devel.redhat.com> David Zeuthen (david at fubar.dk) said: > I agree it's confusing / misleading that udev stores it's rules in /etc. > They are, as you point out, really just program data (at least 99% of > them). I'll talk to upstream about moving the bulk to /lib[64]/udev > instead. Just /lib, please. I can't imagine why they'd need separate /lib | /lib64 rules (and it already uses /lib/udev...) (Red bikeshed, dammit!) Bill From lesmikesell at gmail.com Thu Jan 10 17:20:29 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 10 Jan 2008 11:20:29 -0600 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199984633.20047.44.camel@gibraltar.str.redhat.com> References: <4785163E.8010508@hhs.nl> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <1199982711.30858.41.camel@oneill.fubar.dk> <16de708d0801100840t61b4f1b4p2e999c07563d1030@mail.gmail.com> <1199984082.30858.56.camel@oneill.fubar.dk> <1199984633.20047.44.camel@gibraltar.str.redhat.com> Message-ID: <478653DD.20908@gmail.com> Nils Philippsen wrote: > On Thu, 2008-01-10 at 11:54 -0500, David Zeuthen wrote: >> On Thu, 2008-01-10 at 10:40 -0600, Arthur Pemberton wrote: >>> We are badly in need of system-config-udev. I spent several hours >>> understanding udev adn building rules for my sound cards and tv cards. >>> I hadn't done a yum update on my F7 box for weeks/months (lazyness) >>> did one this week, and it apperently just blew away my custom udev >>> config >> Hell no. We are in badly need of this crap just working out of the box. >> Throwing configuration / options at the problem will only make it worse. >> Trying to explain this to people is apparently impossible since people >> keep proposing stupid configuration tools with "unbreak my system" >> options. > > There's the bad idea that everything under /etc/ is configurable, but in > reality these rules are "program data" and ideally should go into /share > if that existed (which would avoid people thinking they're meant to > touch that stuff, hopefully). I'm having trouble parsing that statement. Are you saying that people shouldn't be able to edit their own /etc/xxx files as documented by the upstream programs or that the distribution should move the parts that it modifies with its internal tools elsewhere? -- Les Mikesell lesmikesell at gmail.com From david at fubar.dk Thu Jan 10 17:18:48 2008 From: david at fubar.dk (David Zeuthen) Date: Thu, 10 Jan 2008 12:18:48 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <478653DD.20908@gmail.com> References: <4785163E.8010508@hhs.nl> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <1199982711.30858.41.camel@oneill.fubar.dk> <16de708d0801100840t61b4f1b4p2e999c07563d1030@mail.gmail.com> <1199984082.30858.56.camel@oneill.fubar.dk> <1199984633.20047.44.camel@gibraltar.str.redhat.com> <478653DD.20908@gmail.com> Message-ID: <1199985528.30858.75.camel@oneill.fubar.dk> On Thu, 2008-01-10 at 11:20 -0600, Les Mikesell wrote: > Nils Philippsen wrote: > > On Thu, 2008-01-10 at 11:54 -0500, David Zeuthen wrote: > >> On Thu, 2008-01-10 at 10:40 -0600, Arthur Pemberton wrote: > >>> We are badly in need of system-config-udev. I spent several hours > >>> understanding udev adn building rules for my sound cards and tv cards. > >>> I hadn't done a yum update on my F7 box for weeks/months (lazyness) > >>> did one this week, and it apperently just blew away my custom udev > >>> config > >> Hell no. We are in badly need of this crap just working out of the box. > >> Throwing configuration / options at the problem will only make it worse. > >> Trying to explain this to people is apparently impossible since people > >> keep proposing stupid configuration tools with "unbreak my system" > >> options. > > > > There's the bad idea that everything under /etc/ is configurable, but in > > reality these rules are "program data" and ideally should go into /share > > if that existed (which would avoid people thinking they're meant to > > touch that stuff, hopefully). > > I'm having trouble parsing that statement. Are you saying that people > shouldn't be able to edit their own /etc/xxx files as documented by the > upstream programs or that the distribution should move the parts that it > modifies with its internal tools elsewhere? Lots of files under /etc are not marked as %config or %config(noreplace) and they are not really configuration files. It's a problem because novice users just assume they can and should edit such files and then they get confused when said file is overwritten on a package upgrade. Does that make more sense? David From pemboa at gmail.com Thu Jan 10 17:00:02 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 10 Jan 2008 11:00:02 -0600 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199984082.30858.56.camel@oneill.fubar.dk> References: <4785163E.8010508@hhs.nl> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <1199982711.30858.41.camel@oneill.fubar.dk> <16de708d0801100840t61b4f1b4p2e999c07563d1030@mail.gmail.com> <1199984082.30858.56.camel@oneill.fubar.dk> Message-ID: <16de708d0801100900g12dc0c1do1d406b1228b3538@mail.gmail.com> On Jan 10, 2008 10:54 AM, David Zeuthen wrote: > > On Thu, 2008-01-10 at 10:40 -0600, Arthur Pemberton wrote: > > We are badly in need of system-config-udev. I spent several hours > > understanding udev adn building rules for my sound cards and tv cards. > > I hadn't done a yum update on my F7 box for weeks/months (lazyness) > > did one this week, and it apperently just blew away my custom udev > > config > > Hell no. We are in badly need of this crap just working out of the box. > Throwing configuration / options at the problem will only make it worse. > Trying to explain this to people is apparently impossible since people > keep proposing stupid configuration tools with "unbreak my system" > options. Most people don't need to worry about udev issues like mine, unless MythTV with multiple video cards very popular soon -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From lesmikesell at gmail.com Thu Jan 10 17:31:14 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 10 Jan 2008 11:31:14 -0600 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199984962.30858.66.camel@oneill.fubar.dk> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <47864F28.4030708@gmail.com> <1199984962.30858.66.camel@oneill.fubar.dk> Message-ID: <47865662.2080701@gmail.com> David Zeuthen wrote: > On Thu, 2008-01-10 at 11:00 -0600, Les Mikesell wrote: >> But the old names were predictable; the new ones aren't - when I move a >> disk to a new controller/drive position, I know about it. > > Uhm, no. You were just relying on a) limitations in the Linux kernel to > probe devices in a sequential fashion (see big-iron boxes with tens of > thousands of disks why this won't work); and b) the order of your > controllers on the PCI bus. Trying to argue it was "predictable" when it > was a "coincidence" is an interesting spin on reality. It's also wrong; > there's a reason that RHL and Fedora been using LABEL= for ages. OK, that's at least partly right but you forgot to tell me what to call the device when creating the label for filesystems that support it - or what name to use for access to the raw device for operations like image copies and addition/removal from raid arrays. The underlying problem can't be solved at the filesystem layer. >> What I actually would argue is that a distribution making such changes >> should supply tools to migrate configurations based on old conventions >> to the new ones. Maybe Fedora doesn't have users with hundreds of >> machines and data that needs to span years of operation, but a unix-like >> system should be designed to make that practical. > > No, Fedora is about being on the bleeding edge and creating a system > where you don't *need* to migrate configuration files because the files > will be correct if they are using stable identifiers for devices. I haven't found that to be the case. And I don't see any reason for today's experimental change to end up being the one that sticks. -- Les Mikesell lesmikesell at gmail.com From david at fubar.dk Thu Jan 10 17:34:56 2008 From: david at fubar.dk (David Zeuthen) Date: Thu, 10 Jan 2008 12:34:56 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <47865662.2080701@gmail.com> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <47864F28.4030708@gmail.com> <1199984962.30858.66.camel@oneill.fubar.dk> <47865662.2080701@gmail.com> Message-ID: <1199986496.30858.83.camel@oneill.fubar.dk> On Thu, 2008-01-10 at 11:31 -0600, Les Mikesell wrote: > OK, that's at least partly right but you forgot to tell me what to call > the device when creating the label for filesystems that support it - or > what name to use for access to the raw device for operations like image > copies and addition/removal from raid arrays. The underlying problem > can't be solved at the filesystem layer. Uhm. Did you *even* look at /dev/disk? There's by-path, by-uuid, by-label and so forth. Heck, SUSE/Ubuntu ships udev rules for making the md and dm devices use persistent naming too. Maybe if the distros were better at working together at the plumbing layer (another rant of mine)), this would be all standardized. Eventually it will all be standardized. > > No, Fedora is about being on the bleeding edge and creating a system > > where you don't *need* to migrate configuration files because the files > > will be correct if they are using stable identifiers for devices. > > I haven't found that to be the case. And I don't see any reason for > today's experimental change to end up being the one that sticks. There's nothing experimental about the path modern Linux is going in wrt. to device naming. If you had bothered you will fine that more and more device classes, including the infamous video4linux camp, is moving to persistent device names. It's true, however, that Fedora is super-reluctant on taking advantage of what happens upstream and keep using pre-2000 technology. That's, very slowly, changing though. David From limb at jcomserv.net Thu Jan 10 17:36:46 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 10 Jan 2008 11:36:46 -0600 (CST) Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <20080103120242.GZ20451@devserv.devel.redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> Message-ID: <17413.63.85.68.164.1199986606.squirrel@mail.jcomserv.net> > Hi! > > I've rebuilt 5118 rawhide-20071220 src.rpms on x86_64 in mock buildroots > which > contained rawhide-20071220 except {gcc,lib}*-4.1.2-36.*.rpm, with > additional > gcc-4.3.0-0.4 (available from koji, dist-f9-gcc43 component), > compat-libgfortran-41 (available from > http://people.redhat.com/jakub/gcc/compat-libgfortran-41-4.1.2-36.src.rpm > unsorted/astromenace-1.2-6.fc9.log This looks like an openal bug, see: http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/unsorted/astromenace-1.2-6.fc9.log /usr/include/AL/alc.h:190: error: '' has incomplete type /usr/include/AL/alc.h:190: error: invalid use of 'ALCvoid' /usr/include/AL/alc.h:251: error: '' has incomplete type /usr/include/AL/alc.h:251: error: invalid use of 'ALCvoid' Has someone caught this and I missed it, or should I BZ it? -- novus ordo absurdum From kevin.kofler at chello.at Thu Jan 10 17:38:01 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 10 Jan 2008 17:38:01 +0000 (UTC) Subject: autoconf issue using -stdc=gnu++0x option in AC_CHECK_HEADER macro. References: <4786521B.8050002@herr-schmitt.de> Message-ID: Jochen Schmitt herr-schmitt.de> writes: > So I want to ask, what I have to to, that autoconf will respect this > option in the AC_HEADER macro. Add it to the CXXFLAGS, you'll need it there anyway when actually building the program. I believe there's also a macro to check the existence of the flag, which will add it to the CXXFLAGS automatically if the test succeeds. But why are you still using autoconf and not something less insane? ;-) http://www.cmake.org/ Kevin Kofler From j.w.r.degoede at hhs.nl Thu Jan 10 17:39:09 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 10 Jan 2008 18:39:09 +0100 Subject: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220 In-Reply-To: <17413.63.85.68.164.1199986606.squirrel@mail.jcomserv.net> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <17413.63.85.68.164.1199986606.squirrel@mail.jcomserv.net> Message-ID: <4786583D.3020906@hhs.nl> Jon Ciesla wrote: >> Hi! >> >> I've rebuilt 5118 rawhide-20071220 src.rpms on x86_64 in mock buildroots >> which >> contained rawhide-20071220 except {gcc,lib}*-4.1.2-36.*.rpm, with >> additional >> gcc-4.3.0-0.4 (available from koji, dist-f9-gcc43 component), >> compat-libgfortran-41 (available from >> http://people.redhat.com/jakub/gcc/compat-libgfortran-41-4.1.2-36.src.rpm > >> unsorted/astromenace-1.2-6.fc9.log > This looks like an openal bug, see: > http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/unsorted/astromenace-1.2-6.fc9.log > > /usr/include/AL/alc.h:190: error: '' has incomplete type > /usr/include/AL/alc.h:190: error: invalid use of 'ALCvoid' > /usr/include/AL/alc.h:251: error: '' has incomplete type > /usr/include/AL/alc.h:251: error: invalid use of 'ALCvoid' > > Has someone caught this and I missed it, or should I BZ it? > Already fixed. Regards, Hans From Jochen at herr-schmitt.de Thu Jan 10 17:47:18 2008 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 10 Jan 2008 18:47:18 +0100 Subject: autoconf issue using -stdc=gnu++0x option in AC_CHECK_HEADER macro. In-Reply-To: References: <4786521B.8050002@herr-schmitt.de> Message-ID: <47865A26.8030704@herr-schmitt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kevin Kofler schrieb: > Add it to the CXXFLAGS, you'll need it there anyway when actually > building the program. I believe there's also a macro to check the > existence of the flag, which will add it to the CXXFLAGS > automatically if the test succeeds. > That was the first thing what I have tried to do after I have recognized this issue, but autoconf doesn't honor this settings when AC_CHECK_HEADER call the g++ compiler for compiling the test program. For you suggestion to using cmake, I'm not the upstream author. As follow a snippet from the config.log file: configure:9397: checking unordered_set usability configure:9414: g++ -c -O2 -Wall conftest.cpp >&5 In file included from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/unordered_set:40, from conftest.cpp:107: /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/c++0x_warning.h:36:2: error: #error This file requires compiler and library support for the upcoming ISO C++ standard, C++0x. This support is currently experimental, and must be enabled with the -std=c++0x or -std=gnu++0x compiler options. In file included from /usr/lib/gcc/i386-redhat-linux/4.3.0/../../../../include/c++/4.3.0/unordered_set:53, from conftest.cpp:107: Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHhlodT2AHK6txfgwRAmxPAKC4tGbJ83BgIDLEYnl6K+kENyglNgCg6I10 TAJXUh9oey+c6oMnS671+r4= =k0uj -----END PGP SIGNATURE----- From bernie at codewiz.org Thu Jan 10 17:52:38 2008 From: bernie at codewiz.org (Bernardo Innocenti) Date: Thu, 10 Jan 2008 12:52:38 -0500 Subject: ctrlproxy In-Reply-To: <20080110074547.785a7b61@zod.rchland.ibm.com> References: <4783B191.50104@codewiz.org> <20080108121210.35266172@zod.rchland.ibm.com> <4784DC7D.1050603@codewiz.org> <20080110074547.785a7b61@zod.rchland.ibm.com> Message-ID: <47865B66.7090803@codewiz.org> Josh Boyer wrote: > By chance do you have it running under a different locale? Yes: to speedup boot, I have commented out the "LANG=..." line in my /etc/sysconfig/i18n. As a result, all daemons run with the C locale. I have LANG=en_US.UTF-8 in my ~/.i18n. Too bad there's no C.UTF-8 in glibc. It should be the default :-) -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ From bkoz at redhat.com Thu Jan 10 18:16:40 2008 From: bkoz at redhat.com (Benjamin Kosnik) Date: Thu, 10 Jan 2008 12:16:40 -0600 Subject: autoconf issue using -stdc=gnu++0x option in AC_CHECK_HEADER macro. In-Reply-To: <4786521B.8050002@herr-schmitt.de> References: <4786521B.8050002@herr-schmitt.de> Message-ID: <20080110121640.505375e0@wabash.artheist.org> > I have a special question about the AC_HEADER macro in autoconf. I'm > trying to text for > the existence of the unordered_set header file in C++. I wrote up autoconf macros for this here: http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/backwards_compatibility.html See "Support for C++TR1 dialect" I'm waiting on feedback and then hope to merge these into the autoconf macro repository. > Unfortunately, > I will got a message, > that I have to use the -std=gnu++0x if I want to include this header > file. Yes, as is a C++0x standard header. If you'd like to use C++98, I suggest using TR1's best, benjamin From jwilson at redhat.com Thu Jan 10 18:20:52 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 10 Jan 2008 13:20:52 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <478647F5.30900@gmail.com> References: <1199912325.15130.89.camel@localhost.localdomain> <20080109224742.GB2664@free.fr> <1199924388.15130.159.camel@localhost.localdomain> <20080110001941.GJ2664@free.fr> <1199925522.25567.57.camel@oneill.fubar.dk> <20080110005703.GL2664@free.fr> <1199927642.25567.81.camel@oneill.fubar.dk> <4786216A.4060502@redhat.com> <20080110145042.GA2587@free.fr> <47863841.2020004@redhat.com> <20080110153156.GE2587@free.fr> <20080110110502.433d43d0@redhat.com> <478647F5.30900@gmail.com> Message-ID: <47866204.9060000@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Les Mikesell wrote: > Jesse Keating wrote: >> On Thu, 10 Jan 2008 16:31:56 +0100 >> Patrice Dumas wrote: >> >>> Why not? One could imagine that somebody steps up to package the stuff >>> needed by the old firewire stack? I don't know that issue very well, >>> but I can imagine people wanting to fix things in fedora if they are >>> annoying them. >> >> >> Also, there is a /huge/ difference between "I can package this!" and "I >> can be responsible for all the bug reports regarding this, and help to >> transition folks using this to that, and help improve that along the >> way." > > This is the philosophical issue - but it applies whether you support > backwards compatiblity or not. In the now diverged firewire juju thread > there is a comment: > > "Awesome, we definitely need more help. Neither krh nor I is able to > spend quite as much time on juju as we'd like right now..." > > Of course "stuff happens" and things aren't ever going to be perfect, > but why does a fundamental change go in at the device driver level > without providing a way to revert to the previous version unless there > is at least some expectation of having the resources to fix the new > problems that will almost certainly show up? Priorities change, unexpected problems crop up, things take much longer than anyone anticipated, etc. Also, note that a lot of the remaining current issues *might* be resolved by some forthcoming juju firewire patches from the linux1394 git tree, which I'm going to try to get into rawhide this afternoon... David Moore did a lot of excellent work over the holiday break while I was busy not paying much attention... :) - -- Jarod Wilson jwilson at redhat.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHhmIEtO+bni+75QMRAjl2AJ9M8GFOcZ7fTn9d2RmSVKysKRrZAQCgnCPC vMvYlg4XRI/WmnSeoieZw48= =2gX1 -----END PGP SIGNATURE----- From jwilson at redhat.com Thu Jan 10 18:22:02 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 10 Jan 2008 13:22:02 -0500 Subject: Fedora too cutting edge? In-Reply-To: <47863E5E.5080500@hhs.nl> References: <4785163E.8010508@hhs.nl> <1199908164.4765.49.camel@metroid.rdu.redhat.com> <47853516.2060600@hhs.nl> <47863D21.8050905@redhat.com> <47863E5E.5080500@hhs.nl> Message-ID: <4786624A.9060909@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hans de Goede wrote: > Jarod Wilson wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Krzysztof Halasa wrote: >>> Hans de Goede writes: >>> >>>> As for this being fixed, not for my case, as I have a via vt 6306 >>>> controller, which is like, only the most common PC firewire controller >>>> on the planet. >>> It should do OHCI 1.1, you may want to take the risk and try the >>> program. Make sure you have a backup (the GUID and possibly whole >>> EEPROM data). >>> >>> VIA claims both VT6306 and VT6307 are OHCI-1.1 (capable), I just >>> have no VT6306 to test (actually it seems VT6307 is a cheeper >>> version, aimed at motherboard manufacturers). >> >> Honestly, I'd rather we just figured out what's wrong with the Via >> chipsets in >> OHCI 1.0 mode, rather than relying on people flashing their >> controllers to 1.1 >> mode. I've got a few ideas, hoping to get back to juju hacking shortly... >> > > I didn't flash my controller, I wanted too, but it turned out it already > was put in 1.1 by the manufacturer of the card I'm using. > > I'm willing to flash to 1.0 mode to help test IIDC in 1.0 mode though, > but first let get IIDC working with the card in 1.1 mode :) I hope to have a rawhide kernel built soonish with some additional bits from the linux1394 git tree that may solve your iidc problems (and if I'm lucky, a few other items on my todo list). - -- Jarod Wilson jwilson at redhat.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHhmJJtO+bni+75QMRAlRUAJ9I19Az+oRB6qw125XQDZuM1U7AFgCfdPrw 11I2uTD5FGJyngy/D09EEXs= =Zk4k -----END PGP SIGNATURE----- From j.w.r.degoede at hhs.nl Thu Jan 10 18:25:33 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 10 Jan 2008 19:25:33 +0100 Subject: Fedora too cutting edge? In-Reply-To: <4786624A.9060909@redhat.com> References: <4785163E.8010508@hhs.nl> <1199908164.4765.49.camel@metroid.rdu.redhat.com> <47853516.2060600@hhs.nl> <47863D21.8050905@redhat.com> <47863E5E.5080500@hhs.nl> <4786624A.9060909@redhat.com> Message-ID: <4786631D.9040809@hhs.nl> Jarod Wilson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hans de Goede wrote: >> Jarod Wilson wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Krzysztof Halasa wrote: >>>> Hans de Goede writes: >>>> >>>>> As for this being fixed, not for my case, as I have a via vt 6306 >>>>> controller, which is like, only the most common PC firewire controller >>>>> on the planet. >>>> It should do OHCI 1.1, you may want to take the risk and try the >>>> program. Make sure you have a backup (the GUID and possibly whole >>>> EEPROM data). >>>> >>>> VIA claims both VT6306 and VT6307 are OHCI-1.1 (capable), I just >>>> have no VT6306 to test (actually it seems VT6307 is a cheeper >>>> version, aimed at motherboard manufacturers). >>> Honestly, I'd rather we just figured out what's wrong with the Via >>> chipsets in >>> OHCI 1.0 mode, rather than relying on people flashing their >>> controllers to 1.1 >>> mode. I've got a few ideas, hoping to get back to juju hacking shortly... >>> >> I didn't flash my controller, I wanted too, but it turned out it already >> was put in 1.1 by the manufacturer of the card I'm using. >> >> I'm willing to flash to 1.0 mode to help test IIDC in 1.0 mode though, >> but first let get IIDC working with the card in 1.1 mode :) > > I hope to have a rawhide kernel built soonish with some additional bits from > the linux1394 git tree that may solve your iidc problems (and if I'm lucky, a > few other items on my todo list). > Sounds good, let me know when koji has something to test for me. Regards, Hans From jwilson at redhat.com Thu Jan 10 18:25:36 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 10 Jan 2008 13:25:36 -0500 Subject: thinkpad-acpi upstream version? In-Reply-To: <364d303b0801091641y763baef2y12a95bde37547c42@mail.gmail.com> References: <47852A26.4010609@fedoraproject.org> <364d303b0801091641y763baef2y12a95bde37547c42@mail.gmail.com> Message-ID: <47866320.1040606@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christopher Brown wrote: > On 09/01/2008, Nicolas Antonio Corrarello wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi there, >> Maybe I still don't get how upstream works, but I found that the latest >> thinkpad-acpi version is 0.19, still Fedora's latest kernel has >> [root at localhost ibm]# cat driver >> driver: ThinkPad ACPI Extras >> version: 0.16 > > Its built as an in-kernel module so 2.6.23 == 0.16, 2.6.24 == 0.17 and > I guess 2.6.25 == 0.19. And if there's a particular problem with thinkpad-acpi you're encountering that is fixed by a later version, file a bug where you describe the problem, point to the fix, etc, and someone might be willing to backport the fix to the latest released kernel. I might even be willing to give it a go as a newly minted member of the ThinkPad community... (just got a T61) - -- Jarod Wilson jwilson at redhat.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHhmMftO+bni+75QMRAuKnAJ9kGxK9RIbPE5aDKDK+7irOahZz0QCgw9LM hF3YIKMhUq8FCjGD5hXEZUo= =CXAO -----END PGP SIGNATURE----- From j.w.r.degoede at hhs.nl Thu Jan 10 18:28:16 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 10 Jan 2008 19:28:16 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199985528.30858.75.camel@oneill.fubar.dk> References: <4785163E.8010508@hhs.nl> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <1199982711.30858.41.camel@oneill.fubar.dk> <16de708d0801100840t61b4f1b4p2e999c07563d1030@mail.gmail.com> <1199984082.30858.56.camel@oneill.fubar.dk> <1199984633.20047.44.camel@gibraltar.str.redhat.com> <478653DD.20908@gmail.com> <1199985528.30858.75.camel@oneill.fubar.dk> Message-ID: <478663C0.3030408@hhs.nl> Hi All, As the one who has started this thread: Can we pretty pretty please stop the flamefest and move on to something more productive. I know I have, I'm currently working together with the juju developers to fix my issues, so that in the end we will have only one stack, and one that works well. I tried to ask a serious question in the top level post, and tried to formulate it in a non inflaming way, well guess I failed there :( Regards, Hans From ncorrare at fedoraproject.org Thu Jan 10 18:34:36 2008 From: ncorrare at fedoraproject.org (Nicolas Antonio Corrarello) Date: Thu, 10 Jan 2008 16:34:36 -0200 Subject: thinkpad-acpi upstream version? In-Reply-To: <47866320.1040606@redhat.com> References: <47852A26.4010609@fedoraproject.org> <364d303b0801091641y763baef2y12a95bde37547c42@mail.gmail.com> <47866320.1040606@redhat.com> Message-ID: <4786653C.5020204@fedoraproject.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Maybe you're in the same condition as I am (Also T61 user, great machine)... Can't make the volume up/down keys to work, and I can't change the volume through /proc/acpi/ibm/volume. I'll se if this is solved in the thinkpad-acpi changelog and file a bug... Jarod Wilson wrote: > Christopher Brown wrote: >> On 09/01/2008, Nicolas Antonio Corrarello wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Hi there, >>> Maybe I still don't get how upstream works, but I found that the latest >>> thinkpad-acpi version is 0.19, still Fedora's latest kernel has >>> [root at localhost ibm]# cat driver >>> driver: ThinkPad ACPI Extras >>> version: 0.16 >> Its built as an in-kernel module so 2.6.23 == 0.16, 2.6.24 == 0.17 and >> I guess 2.6.25 == 0.19. > > And if there's a particular problem with thinkpad-acpi you're encountering > that is fixed by a later version, file a bug where you describe the problem, > point to the fix, etc, and someone might be willing to backport the fix to the > latest released kernel. I might even be willing to give it a go as a newly > minted member of the ThinkPad community... (just got a T61) > > - -- - - -- Nicolas A. Corrarello Fedora Ambassador Argentina c: +54 (911) 5182-2245 e: ncorrare at fedoraproject.org GPG Key: DFC893EE h: fedoraproject.org/wiki/NicolasCorrarello/ GPG Fingerprint: 5C93 42DA 98E1 4EEF B24B 7F8C E145 B2F9 DFC8 93EE Import my key: $ gpg --keyserver pgp.mit.edu --recv-key 0xDFC893EE -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHhmU84UWy+d/Ik+4RAtnBAKCh3Vvi0FcVWVNWdJHP7KjgKijimACgmDKE I710ty/Qja1PT8p5x3vfmX8= =Gqy3 -----END PGP SIGNATURE----- From jwilson at redhat.com Thu Jan 10 18:43:15 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 10 Jan 2008 13:43:15 -0500 Subject: IIDC camera's and the juju firewirestack In-Reply-To: <4786396A.4060605@redhat.com> References: <478633EE.2030407@hhs.nl> <4786396A.4060605@redhat.com> Message-ID: <47866743.8020608@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jarod Wilson wrote: > Hans de Goede wrote: >> In the thread I started about Fedora perhaps being to cutting edge, it >> was said that I shouldn't complain as there is only one problem left >> with the juju stack which is a bug with via vt6306 cards in OHCI 1.0 cards. > > Oh, there's definitely more than one problem left... :) > >> Further analysis of the problem has learned that this is not true, I'm >> using a via vt6306 card in OHCI 1.1 mode, which allegedly should work fine. > > The particular bug is actually related to vt6306 and vt6307 cards in OHCI 1.0 > mode doing dv capture. iidc is much less tested. I already know where at least > a few of the iidc-related OHCI 1.0 bugs are, but they shouldn't be impacting > you... I've also got an idea or two on what's up with dv capture, just need to > get the spare cycles to test (which could happen shortly, just finished a > major piece of lirc...) > >> However most documents talk about using the juju stack with either >> harddisks or DV for homevideo camera's. However I'm trying to use an >> industrial cam which used the IIDC protocol, and support in the new juju >> stack (kernel + userspace) for the IIDC protocol isn't very good. > > I believe David Moore's patch in linux1394-2.6.git[*] should help, and it > looks like that also needs to be ported over to the OHCI 1.0 code paths... Nope, looks like he's already done that too. As I said in another thread, I'm going to try to start tracking the linux1394 git tree in rawhide, and selectively pull back patches into released kernels. David's done a lot of excellent work of late while I was busy not paying attention, due to the holidays and other misc stuff (lirc, ia64 xen, ecryptfs, ext4...) - -- Jarod Wilson jwilson at redhat.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHhmdDtO+bni+75QMRAuXMAKCpQrPfZlS0fGOLqU4Lg2HRk2KxLACgy6xP yNP1JUzpzhAlOE5eGH6h4Go= =DZkp -----END PGP SIGNATURE----- From pertusus at free.fr Thu Jan 10 18:43:51 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 10 Jan 2008 19:43:51 +0100 Subject: Dropping Base X group? [Was: Re: KDE logout options with F8] In-Reply-To: References: <4727F17D.2090305@fedoraproject.org> <4728A579.4040901@redhat.com> <4728A66C.8070103@fedoraproject.org> <4728B0E4.2050209@redhat.com> <4728B36C.4060403@fedoraproject.org> <4728C284.405030!5@redhat.com> <20071105010239.GA3632@free.fr> Message-ID: <20080110184351.GC2638@free.fr> On Tue, Nov 06, 2007 at 07:10:53PM +0000, Kevin Kofler wrote: > Patrice Dumas free.fr> writes: > > I am a small desktop user. For the display managers, there are wdm, > > xdm and slim (but they lack integration with consolekit). For the > > I think my KDM ConsoleKit patch should be fairly easy to adapt to any > XDM-derived display manager, as KDM is also derived from XDM. The only caveat I have looked at both and, even though maybe kdm is derived from xdm they have diverged too much. Using libck-connector allows to achieve what the kdm consolekit does, however. And there is an equivalent of d->serverVT in xdm which would allow to set the X display device like sprintf(device, "/dev/tty%d", d->serverVT); However doing things like that seems very odd and non portable to me. In fact there is no reason why the display manager would know the X display device since X is all about hiding the hardware. I am currently discussing that with the xdm upstream maintainer, did you contact the kde upstream for the patch inclusion? -- Pat From cmadams at hiwaay.net Thu Jan 10 18:45:13 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 10 Jan 2008 12:45:13 -0600 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199984082.30858.56.camel@oneill.fubar.dk> References: <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <1199982711.30858.41.camel@oneill.fubar.dk> <16de708d0801100840t61b4f1b4p2e999c07563d1030@mail.gmail.com> <1199984082.30858.56.camel@oneill.fubar.dk> Message-ID: <20080110184513.GC1055637@hiwaay.net> Once upon a time, David Zeuthen said: > On Thu, 2008-01-10 at 10:40 -0600, Arthur Pemberton wrote: > > We are badly in need of system-config-udev. I spent several hours > > understanding udev adn building rules for my sound cards and tv cards. > > I hadn't done a yum update on my F7 box for weeks/months (lazyness) > > did one this week, and it apperently just blew away my custom udev > > config > > Hell no. We are in badly need of this crap just working out of the box. And how do you know automatically that one of my USB-to-RS232 adapters is my UPS (should be /dev/ups), one is my GPS (/dev/gps0), and one is a cell phone (/dev/modem)? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From lesmikesell at gmail.com Thu Jan 10 18:48:32 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 10 Jan 2008 12:48:32 -0600 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199985528.30858.75.camel@oneill.fubar.dk> References: <4785163E.8010508@hhs.nl> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <1199982711.30858.41.camel@oneill.fubar.dk> <16de708d0801100840t61b4f1b4p2e999c07563d1030@mail.gmail.com> <1199984082.30858.56.camel@oneill.fubar.dk> <1199984633.20047.44.camel@gibraltar.str.redhat.com> <478653DD.20908@gmail.com> <1199985528.30858.75.camel@oneill.fubar.dk> Message-ID: <47866880.6050706@gmail.com> David Zeuthen wrote: >>> There's the bad idea that everything under /etc/ is configurable, but in >>> reality these rules are "program data" and ideally should go into /share >>> if that existed (which would avoid people thinking they're meant to >>> touch that stuff, hopefully). >> I'm having trouble parsing that statement. Are you saying that people >> shouldn't be able to edit their own /etc/xxx files as documented by the >> upstream programs or that the distribution should move the parts that it >> modifies with its internal tools elsewhere? > > Lots of files under /etc are not marked as %config or %config(noreplace) > and they are not really configuration files. It's a problem because > novice users just assume they can and should edit such files and then > they get confused when said file is overwritten on a package upgrade. > > Does that make more sense? It doesn't disambiguate the situation unless you are saying that local administrators should not touch any files. How does a (novice or not) user know which files belong to him but are delivered as working defaults and which will be clobbered by subsequent updates? I thought most of the point of splattering stuff under /etc/sysconfig was to have a place to put distribution-tool managed bits without too much impact on standard, documented config files as they would work in other distributions. -- Les Mikesell lesmikesell at gmail.com From pemboa at gmail.com Thu Jan 10 18:53:00 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 10 Jan 2008 12:53:00 -0600 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <20080110184513.GC1055637@hiwaay.net> References: <20080109233613.GG2664@free.fr> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <1199982711.30858.41.camel@oneill.fubar.dk> <16de708d0801100840t61b4f1b4p2e999c07563d1030@mail.gmail.com> <1199984082.30858.56.camel@oneill.fubar.dk> <20080110184513.GC1055637@hiwaay.net> Message-ID: <16de708d0801101053m42f8d452v13d3891a73571352@mail.gmail.com> On Jan 10, 2008 12:45 PM, Chris Adams wrote: > Once upon a time, David Zeuthen said: > > On Thu, 2008-01-10 at 10:40 -0600, Arthur Pemberton wrote: > > > We are badly in need of system-config-udev. I spent several hours > > > understanding udev adn building rules for my sound cards and tv cards. > > > I hadn't done a yum update on my F7 box for weeks/months (lazyness) > > > did one this week, and it apperently just blew away my custom udev > > > config > > > > Hell no. We are in badly need of this crap just working out of the box. > > And how do you know automatically that one of my USB-to-RS232 adapters > is my UPS (should be /dev/ups), one is my GPS (/dev/gps0), and one is a > cell phone (/dev/modem)? I have no idea myself, and I have spent a few hours pondering the problem. The only solution I have come up with is to keep things as they are, but generate symantic aliases for them. Example: /dev/video1 -> /dev/video_hauppauge_iptv Far from perfect however, but would be adequate for my needs. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From lesmikesell at gmail.com Thu Jan 10 18:56:47 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 10 Jan 2008 12:56:47 -0600 Subject: Bruttaly sluggish Eclipse performance in remote X In-Reply-To: References: <1199746646.9735.10.camel@dimi.lattica.com> <47862752.3030103@gmail.com> Message-ID: <47866A6F.9000800@gmail.com> Magnus Gustavsson wrote: > Les Mikesell gmail.com> writes: > >> Have you tried running freenx with the NX clients from >> http://www.nomachine.com? > > I have now. No improvement. I'm somewhat shocked at this, since it should provide a caching layer for things moved on the screen in addition to compression and a proxy to fix network latency. Are you sure you aren't short on RAM? -- Les Mikesell lesmikesell at gmail.com From david at fubar.dk Thu Jan 10 19:02:07 2008 From: david at fubar.dk (David Zeuthen) Date: Thu, 10 Jan 2008 14:02:07 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <20080110184513.GC1055637@hiwaay.net> References: <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <1199982711.30858.41.camel@oneill.fubar.dk> <16de708d0801100840t61b4f1b4p2e999c07563d1030@mail.gmail.com> <1199984082.30858.56.camel@oneill.fubar.dk> <20080110184513.GC1055637@hiwaay.net> Message-ID: <1199991727.32394.3.camel@oneill.fubar.dk> On Thu, 2008-01-10 at 12:45 -0600, Chris Adams wrote: > Once upon a time, David Zeuthen said: > > On Thu, 2008-01-10 at 10:40 -0600, Arthur Pemberton wrote: > > > We are badly in need of system-config-udev. I spent several hours > > > understanding udev adn building rules for my sound cards and tv cards. > > > I hadn't done a yum update on my F7 box for weeks/months (lazyness) > > > did one this week, and it apperently just blew away my custom udev > > > config > > > > Hell no. We are in badly need of this crap just working out of the box. > > And how do you know automatically that one of my USB-to-RS232 adapters > is my UPS (should be /dev/ups), one is my GPS (/dev/gps0), and one is a > cell phone (/dev/modem)? Either we look at the USB device it's hanging off (vendor, product or class id's), the driver or we provide a simple interface in gnome-device-manager or similar (including command line apps) to set it. For the latter, there is going to be some development for F10, F11 and later in merging the hal and udev databases into a common device database that will feature persistent properties (such as classification and device naming) keyed off by-path, by-id and so on to easily make a feature like this available. That's the answer to this (very real) problem, not a silly program that generates udev rules. David From david at fubar.dk Thu Jan 10 19:04:04 2008 From: david at fubar.dk (David Zeuthen) Date: Thu, 10 Jan 2008 14:04:04 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <47866880.6050706@gmail.com> References: <4785163E.8010508@hhs.nl> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <1199982711.30858.41.camel@oneill.fubar.dk> <16de708d0801100840t61b4f1b4p2e999c07563d1030@mail.gmail.com> <1199984082.30858.56.camel@oneill.fubar.dk> <1199984633.20047.44.camel@gibraltar.str.redhat.com> <478653DD.20908@gmail.com> <1199985528.30858.75.camel@oneill.fubar.dk> <47866880.6050706@gmail.com> Message-ID: <1199991844.32394.6.camel@oneill.fubar.dk> On Thu, 2008-01-10 at 12:48 -0600, Les Mikesell wrote: > It doesn't disambiguate the situation unless you are saying that local > administrators should not touch any files. How does a (novice or not) > user know which files belong to him but are delivered as working > defaults and which will be clobbered by subsequent updates? I thought > most of the point of splattering stuff under /etc/sysconfig was to have > a place to put distribution-tool managed bits without too much impact on > standard, documented config files as they would work in other distributions. The problem is that a lot of software erroneously place files in /etc. Ideally all files (and that should be very few files!) in /etc should be safe to edit by the system administrator. David From ajackson at redhat.com Thu Jan 10 19:29:00 2008 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 10 Jan 2008 14:29:00 -0500 Subject: Dropping Base X group? [Was: Re: KDE logout options with F8] In-Reply-To: <20080110184351.GC2638@free.fr> References: <4727F17D.2090305@fedoraproject.org> <4728A579.4040901@redhat.com> <4728A66C.8070103@fedoraproject.org> <4728B0E4.2050209@redhat.com> <4728B36C.4060403@fedoraproject.org> <4728C284.405030!5@redhat.com> <20071105010239.GA3632@free.fr> <20080110184351.GC2638@free.fr> Message-ID: <1199993340.15130.216.camel@localhost.localdomain> On Thu, 2008-01-10 at 19:43 +0100, Patrice Dumas wrote: > On Tue, Nov 06, 2007 at 07:10:53PM +0000, Kevin Kofler wrote: > > Patrice Dumas free.fr> writes: > > > I am a small desktop user. For the display managers, there are wdm, > > > xdm and slim (but they lack integration with consolekit). For the > > > > I think my KDM ConsoleKit patch should be fairly easy to adapt to any > > XDM-derived display manager, as KDM is also derived from XDM. The only caveat > > I have looked at both and, even though maybe kdm is derived from xdm > they have diverged too much. Using libck-connector allows to achieve what > the kdm consolekit does, however. And there is an equivalent of > d->serverVT in xdm which would allow to set the X display device like > > sprintf(device, "/dev/tty%d", d->serverVT); Eew. Don't do it that way. atropine:~% xprop -root | grep VT XFree86_VT(INTEGER) = 7 - ajax From pertusus at free.fr Thu Jan 10 19:27:19 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 10 Jan 2008 20:27:19 +0100 Subject: Dropping Base X group? [Was: Re: KDE logout options with F8] In-Reply-To: <1199993340.15130.216.camel@localhost.localdomain> References: <4728A66C.8070103@fedoraproject.org> <4728B0E4.2050209@redhat.com> <4728B36C.4060403@fedoraproject.org> <4728C284.405030!5@redhat.com> <20071105010239.GA3632@free.fr> <20080110184351.GC2638@free.fr> <1199993340.15130.216.camel@localhost.localdomain> Message-ID: <20080110192719.GD2638@free.fr> On Thu, Jan 10, 2008 at 02:29:00PM -0500, Adam Jackson wrote: > On Thu, 2008-01-10 at 19:43 +0100, Patrice Dumas wrote: > > Eew. Don't do it that way. > > atropine:~% xprop -root | grep VT > XFree86_VT(INTEGER) = 7 And the device? How can it be obtained from the X server? -- Pat From pemboa at gmail.com Thu Jan 10 19:28:05 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 10 Jan 2008 13:28:05 -0600 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199991727.32394.3.camel@oneill.fubar.dk> References: <20080109233613.GG2664@free.fr> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <1199982711.30858.41.camel@oneill.fubar.dk> <16de708d0801100840t61b4f1b4p2e999c07563d1030@mail.gmail.com> <1199984082.30858.56.camel@oneill.fubar.dk> <20080110184513.GC1055637@hiwaay.net> <1199991727.32394.3.camel@oneill.fubar.dk> Message-ID: <16de708d0801101128r69e406d7s98260e8d1cb28564@mail.gmail.com> On Jan 10, 2008 1:02 PM, David Zeuthen wrote: > > On Thu, 2008-01-10 at 12:45 -0600, Chris Adams wrote: > > Once upon a time, David Zeuthen said: > > > On Thu, 2008-01-10 at 10:40 -0600, Arthur Pemberton wrote: > > > > We are badly in need of system-config-udev. I spent several hours > > > > understanding udev adn building rules for my sound cards and tv cards. > > > > I hadn't done a yum update on my F7 box for weeks/months (lazyness) > > > > did one this week, and it apperently just blew away my custom udev > > > > config > > > > > > Hell no. We are in badly need of this crap just working out of the box. > > > > And how do you know automatically that one of my USB-to-RS232 adapters > > is my UPS (should be /dev/ups), one is my GPS (/dev/gps0), and one is a > > cell phone (/dev/modem)? > > Either we look at the USB device it's hanging off (vendor, product or > class id's), the driver or we provide a simple interface in > gnome-device-manager or similar (including command line apps) to set it. You're wierd dude, this essentially the same thing I suggested and you discouraged. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From pertusus at free.fr Thu Jan 10 19:34:54 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 10 Jan 2008 20:34:54 +0100 Subject: Dropping Base X group? [Was: Re: KDE logout options with F8] In-Reply-To: <1199993340.15130.216.camel@localhost.localdomain> References: <4728A66C.8070103@fedoraproject.org> <4728B0E4.2050209@redhat.com> <4728B36C.4060403@fedoraproject.org> <4728C284.405030!5@redhat.com> <20071105010239.GA3632@free.fr> <20080110184351.GC2638@free.fr> <1199993340.15130.216.camel@localhost.localdomain> Message-ID: <20080110193450.GE2638@free.fr> On Thu, Jan 10, 2008 at 02:29:00PM -0500, Adam Jackson wrote: > > Eew. Don't do it that way. > > atropine:~% xprop -root | grep VT > XFree86_VT(INTEGER) = 7 Also looking at the xdm code, looks like it does about that: prop = XInternAtom(d->dpy, "XFree86_VT", False); XGetWindowProperty(d->dpy, DefaultRootWindow(d->dpy), prop, 0, 1, False, AnyPropertyType, &actualtype, &actualformat, &nitems, &bytes_after, &buf) -- Pat From lesmikesell at gmail.com Thu Jan 10 19:44:47 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 10 Jan 2008 13:44:47 -0600 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199986496.30858.83.camel@oneill.fubar.dk> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <47864F28.4030708@gmail.com> <1199984962.30858.66.camel@oneill.fubar.dk> <47865662.2080701@gmail.com> <1199986496.30858.83.camel@oneill.fubar.dk> Message-ID: <478675AF.7010501@gmail.com> David Zeuthen wrote: >> OK, that's at least partly right but you forgot to tell me what to call >> the device when creating the label for filesystems that support it - or >> what name to use for access to the raw device for operations like image >> copies and addition/removal from raid arrays. The underlying problem >> can't be solved at the filesystem layer. > > Uhm. Did you *even* look at /dev/disk? There's by-path, by-uuid, > by-label and so forth. I'm looking, but I don't see consistency anywhere across linux kernels. by-uuid, by-label seem to only refer to things that have been created by some other access, by-id doen't always appear, and by-path varies across kernels as the device drivers have changed. Where is something better than device driver major/minor numbers would have been? > Heck, SUSE/Ubuntu ships udev rules for making the > md and dm devices use persistent naming too. Maybe if the distros were > better at working together at the plumbing layer (another rant of > mine)), this would be all standardized. Eventually it will all be > standardized. Do you expect this to be standardized only for Linux or is there hope for a Posix specification for device name conventions? >>> No, Fedora is about being on the bleeding edge and creating a system >>> where you don't *need* to migrate configuration files because the files >>> will be correct if they are using stable identifiers for devices. >> I haven't found that to be the case. And I don't see any reason for >> today's experimental change to end up being the one that sticks. > > There's nothing experimental about the path modern Linux is going in > wrt. to device naming. If you had bothered you will fine that more and > more device classes, including the infamous video4linux camp, is moving > to persistent device names. If I had bothered to what? Is this documented somewhere? Is it version-specific to fedora? > It's true, however, that Fedora is > super-reluctant on taking advantage of what happens upstream and keep > using pre-2000 technology. That's, very slowly, changing though. Much of my data is on filesystems created before 2000. Will changing the names used to reference them make them work better? -- Les Mikesell lesmikesell at gmail.com From pertusus at free.fr Thu Jan 10 19:46:22 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 10 Jan 2008 20:46:22 +0100 Subject: use defoma in fedora? Message-ID: <20080110194622.GF2638@free.fr> Hello, I am currently looking at package that uses Type1 fonts through t1lib (grace, xglyph, xdvi). In fedora there is no system that I know of that can be used to make sure that all the type1 fonts are available for those applications. Discussing this with a debian maintainer he told me about defoma, a debian package which is used to register fonts and provide fonts for all the applications, for fonts not handled by fontconfig or applications not using fontconfig. Would it be a good idea to try to have something similar in fedora or is it a wrong direction? -- Pat From david at fubar.dk Thu Jan 10 19:51:13 2008 From: david at fubar.dk (David Zeuthen) Date: Thu, 10 Jan 2008 14:51:13 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <478675AF.7010501@gmail.com> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <47864F28.4030708@gmail.com> <1199984962.30858.66.camel@oneill.fubar.dk> <47865662.2080701@gmail.com> <1199986496.30858.83.camel@oneill.fubar.dk> <478675AF.7010501@gmail.com> Message-ID: <1199994673.32394.15.camel@oneill.fubar.dk> On Thu, 2008-01-10 at 13:44 -0600, Les Mikesell wrote: > > Uhm. Did you *even* look at /dev/disk? There's by-path, by-uuid, > > by-label and so forth. > > I'm looking, but I don't see consistency anywhere across linux kernels. > by-uuid, by-label seem to only refer to things that have been created > by some other access, by-id doen't always appear, and by-path varies > across kernels as the device drivers have changed. Where is something > better than device driver major/minor numbers would have been? You should use by-uuid. If you see other entries change according to what kernel you are using this should be reported on the udev list ?linux-hotplug at vger.kernel.org and please follow up there with other questions too (it's getting off-topic in this thread and even this list). Thanks. > Do you expect this to be standardized only for Linux or is there hope > for a Posix specification for device name conventions? No, I don't expect this to be standardized outside Linux. > > There's nothing experimental about the path modern Linux is going in > > wrt. to device naming. If you had bothered you will fine that more and > > more device classes, including the infamous video4linux camp, is moving > > to persistent device names. > > If I had bothered to what? Is this documented somewhere? Is it > version-specific to fedora? That's like asking if all the sysfs are documented somewhere and the answer to questions like that are normally "no, it's self-evident" (and I agree it's not always the case) or "look at the source". Anyway, by all means, send patches to the udev list with docs if you think it's required. > > It's true, however, that Fedora is > > super-reluctant on taking advantage of what happens upstream and keep > > using pre-2000 technology. That's, very slowly, changing though. > > Much of my data is on filesystems created before 2000. Will changing > the names used to reference them make them work better? This question doesn't really make sense to me. What I'm telling you is to use persistent device names. That entails having UUID and/or labels on your file systems. So if you don't have that, by all means, go ahead and create them and things will start appearing under /dev/disk. Anyway, please use the udev list for further questions. This thread is getting too long. Thanks. David From lightsolphoenix at gmail.com Thu Jan 10 19:54:51 2008 From: lightsolphoenix at gmail.com (Kelly Miller) Date: Thu, 10 Jan 2008 14:54:51 -0500 Subject: use defoma in fedora? In-Reply-To: <20080110194622.GF2638@free.fr> References: <20080110194622.GF2638@free.fr> Message-ID: Discussing this with a debian maintainer he told me > about defoma, a debian package which is used to register fonts and > provide fonts for all the applications, for fonts not handled by > fontconfig or applications not using fontconfig. Would it be a good idea > to try to have something similar in fedora or is it a wrong direction? > NO NO NO NO NO NO NO NO! Defoma is the reason I stopped using anything Debian-based. The theory is good, but defoma frequently forgets where fonts are installed, which leads to the X server puking on startup and other major problems. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesmikesell at gmail.com Thu Jan 10 19:57:48 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 10 Jan 2008 13:57:48 -0600 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <16de708d0801101128r69e406d7s98260e8d1cb28564@mail.gmail.com> References: <20080109233613.GG2664@free.fr> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <1199982711.30858.41.camel@oneill.fubar.dk> <16de708d0801100840t61b4f1b4p2e999c07563d1030@mail.gmail.com> <1199984082.30858.56.camel@oneill.fubar.dk> <20080110184513.GC1055637@hiwaay.net> <1199991727.32394.3.camel@oneill.fubar.dk> <16de708d0801101128r69e406d7s98260e8d1cb28564@mail.gmail.com> Message-ID: <478678BC.9010802@gmail.com> Arthur Pemberton wrote: >>>> Hell no. We are in badly need of this crap just working out of the box. >>> And how do you know automatically that one of my USB-to-RS232 adapters >>> is my UPS (should be /dev/ups), one is my GPS (/dev/gps0), and one is a >>> cell phone (/dev/modem)? >> Either we look at the USB device it's hanging off (vendor, product or >> class id's), the driver or we provide a simple interface in >> gnome-device-manager or similar (including command line apps) to set it. > > You're wierd dude, this essentially the same thing I suggested and you > discouraged. The system can't possibly work with multiple choices unless you have an interface to let a human configure which is which. Now the kicker is that most of my machines are in remote locations with swappable drives and I expect to be able to ship a pre-configured drive built locally and have someone pop it in a known controller position and have it come up working - and to be able to copy images that will work across a number of identical machines without individual attention other than setting the hostname and IP addresses. -- Les Mikesell lesmikesell at gmail.com From david at fubar.dk Thu Jan 10 19:58:00 2008 From: david at fubar.dk (David Zeuthen) Date: Thu, 10 Jan 2008 14:58:00 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199994673.32394.15.camel@oneill.fubar.dk> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <47864F28.4030708@gmail.com> <1199984962.30858.66.camel@oneill.fubar.dk> <47865662.2080701@gmail.com> <1199986496.30858.83.camel@oneill.fubar.dk> <478675AF.7010501@gmail.com> <1199994673.32394.15.camel@oneill.fubar.dk> Message-ID: <1199995080.32394.18.camel@oneill.fubar.dk> On Thu, 2008-01-10 at 14:51 -0500, David Zeuthen wrote: > > > There's nothing experimental about the path modern Linux is going in > > > wrt. to device naming. If you had bothered you will fine that more and > > > more device classes, including the infamous video4linux camp, is moving > > > to persistent device names. > > > > If I had bothered to what? Is this documented somewhere? Is it > > version-specific to fedora? > > That's like asking if all the sysfs are documented somewhere and the > answer to questions like that are normally "no, it's self-evident" (and > I agree it's not always the case) or "look at the source". Anyway, by > all means, send patches to the udev list with docs if you think it's > required. I wasn't really clear here; I meant if you had followed udev and kernel lists you would see a trend that more and more devices will start using udev rules to provide persistent device names. Hope this clarifies. David From alan at redhat.com Thu Jan 10 20:02:44 2008 From: alan at redhat.com (Alan Cox) Date: Thu, 10 Jan 2008 15:02:44 -0500 Subject: Impending X driver deprecation In-Reply-To: <47862243.50003@redhat.com> References: <1199906969.15130.40.camel@localhost.localdomain> <47862243.50003@redhat.com> Message-ID: <20080110200244.GA23496@devserv.devel.redhat.com> On Thu, Jan 10, 2008 at 02:48:51PM +0100, Christopher Aillon wrote: > Can we call it Operation: Impeding Doom? The X-orcist ? From pertusus at free.fr Thu Jan 10 20:04:31 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 10 Jan 2008 21:04:31 +0100 Subject: use defoma in fedora? In-Reply-To: References: <20080110194622.GF2638@free.fr> Message-ID: <20080110200431.GG2638@free.fr> On Thu, Jan 10, 2008 at 02:54:51PM -0500, Kelly Miller wrote: > Discussing this with a debian maintainer he told me > > > about defoma, a debian package which is used to register fonts and > > provide fonts for all the applications, for fonts not handled by > > fontconfig or applications not using fontconfig. Would it be a good idea > > to try to have something similar in fedora or is it a wrong direction? > > > > NO NO NO NO NO NO NO NO! > > Defoma is the reason I stopped using anything Debian-based. The theory is > good, but defoma frequently forgets where fonts are installed, which leads > to the X server puking on startup and other major problems. Hum I wouldn't have expected the X server to have anything to do with defoma. At least it is certainly unuseful in fedora. I would see it useful for postrscript and type1 fonts. Is there something fundamentaly broken in defoma, or is it a bug you are describing? In any case it is a interesting information. -- Pat From pemboa at gmail.com Thu Jan 10 20:13:52 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 10 Jan 2008 14:13:52 -0600 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <478678BC.9010802@gmail.com> References: <20080109233613.GG2664@free.fr> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <1199982711.30858.41.camel@oneill.fubar.dk> <16de708d0801100840t61b4f1b4p2e999c07563d1030@mail.gmail.com> <1199984082.30858.56.camel@oneill.fubar.dk> <20080110184513.GC1055637@hiwaay.net> <1199991727.32394.3.camel@oneill.fubar.dk> <16de708d0801101128r69e406d7s98260e8d1cb28564@mail.gmail.com> <478678BC.9010802@gmail.com> Message-ID: <16de708d0801101213g38a7883bv202ce8a5e6ab4312@mail.gmail.com> On Jan 10, 2008 1:57 PM, Les Mikesell wrote: > Arthur Pemberton wrote: > > >>>> Hell no. We are in badly need of this crap just working out of the box. > >>> And how do you know automatically that one of my USB-to-RS232 adapters > >>> is my UPS (should be /dev/ups), one is my GPS (/dev/gps0), and one is a > >>> cell phone (/dev/modem)? > >> Either we look at the USB device it's hanging off (vendor, product or > >> class id's), the driver or we provide a simple interface in > >> gnome-device-manager or similar (including command line apps) to set it. > > > > You're wierd dude, this essentially the same thing I suggested and you > > discouraged. > > The system can't possibly work with multiple choices unless you have an > interface to let a human configure which is which. Now the kicker is > that most of my machines are in remote locations with swappable drives > and I expect to be able to ship a pre-configured drive built locally and > have someone pop it in a known controller position and have it come up > working - and to be able to copy images that will work across a number > of identical machines without individual attention other than setting > the hostname and IP addresses. I would have thought that with dirves you can jsut mount by labels, does this not work for your use case? -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From alan at redhat.com Thu Jan 10 20:16:34 2008 From: alan at redhat.com (Alan Cox) Date: Thu, 10 Jan 2008 15:16:34 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <47864F28.4030708@gmail.com> References: <1199912325.15130.89.camel@localhost.localdomain> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <47864F28.4030708@gmail.com> Message-ID: <20080110201634.GC23496@devserv.devel.redhat.com> On Thu, Jan 10, 2008 at 11:00:24AM -0600, Les Mikesell wrote: > But the old names were predictable; the new ones aren't - when I move a > disk to a new controller/drive position, I know about it. They were not. If you added a controller they may change. Old unix naming is based on a fixed structure, modern system naming is based on the reality of hotplug From joachim.frieben at googlemail.com Thu Jan 10 20:17:42 2008 From: joachim.frieben at googlemail.com (Joachim Frieben) Date: Thu, 10 Jan 2008 21:17:42 +0100 Subject: Impending X driver deprecation In-Reply-To: References: <1199906969.15130.40.camel@localhost.localdomain> <478592B4.8080109@ij.net> Message-ID: <1c252d490801101217v4ef993dcnae880fb2cfc834e7@mail.gmail.com> On 1/10/08, Matej Cepl wrote: > > On 2008-01-10, 03:36 GMT, Felix Miata wrote: > > So as to Tseng, I object X8. > > And why wouldn't your machines work with vesa? > > Mat?j It's not necessarily a matter of work or not, but vesa usually provides abysmal 2D performance compared to a native driver. -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.antill at redhat.com Thu Jan 10 20:21:56 2008 From: james.antill at redhat.com (James Antill) Date: Thu, 10 Jan 2008 15:21:56 -0500 Subject: Init : someone could comment this ? In-Reply-To: <1199954992.18322.83.camel@vespa.frost.loc> References: <7f692fec0801060744s22532074s87b6b8369bde4d1e@mail.gmail.com> <1199638106.6022.88.camel@beck.corsepiu.local> <47812D36.4030309@ncsu.edu> <1199880879.5534.210.camel@beck.corsepiu.local> <7f692fec0801090539y4f8aa894i1ace29ab884aa994@mail.gmail.com> <200801091406.m09E6dOe013547@laptop13.inf.utfsm.cl> <47852FB8.6060603@gmail.com> <4785355F.5060302@gmail.com> <47854594.7070205@gmail.com> <47854C7B.2000303@wolves.durham.nc.us> <20080109234605.GB16506@tango.0pointer.de> <1199954992.18322.83.camel@vespa.frost.loc> Message-ID: <1199996516.18076.118.camel@code.and.org> On Thu, 2008-01-10 at 09:49 +0100, Tomas Mraz wrote: > On Thu, 2008-01-10 at 00:46 +0100, Lennart Poettering wrote: > > Although this is totally off-topic: I still think the proper fix is > > something like this: > > > > http://0pointer.de/lennart/projects/nss-myhostname/ > > http://0pointer.de/lennart/projects/nss-myhostname/README.txt > > > > I wrote that a while back. Maybe someone wants to dust this off and > > get it into Fedora and activated by default? > > > > This saved me a couple of times on embedded boxes, where each of the > > devices used a different hostname and I had to guarantee that the > > hostname stayed resolvable in all cases, with a ro root directory. > > This seems like a nice idea - actually even better idea would be to be > able to pass some arguments to modules in nsswitch.conf and then simply > put: > > hosts: files dns files(conf=/etc/hosts-fallback) My understanding was that the hostname thing is done so that bootup doesn't stop when you have no network ... and the above module doesn't help much there (you still have to timeout the DNS requests). And it still fails in the same way, when there is no network (Ie. daemon can bind to a specific IP that is the "wrong" one). -- James Antill Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mzerqung at 0pointer.de Thu Jan 10 20:32:39 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Thu, 10 Jan 2008 21:32:39 +0100 Subject: Init : someone could comment this ? In-Reply-To: <1199996516.18076.118.camel@code.and.org> References: <1199880879.5534.210.camel@beck.corsepiu.local> <7f692fec0801090539y4f8aa894i1ace29ab884aa994@mail.gmail.com> <200801091406.m09E6dOe013547@laptop13.inf.utfsm.cl> <47852FB8.6060603@gmail.com> <4785355F.5060302@gmail.com> <47854594.7070205@gmail.com> <47854C7B.2000303@wolves.durham.nc.us> <20080109234605.GB16506@tango.0pointer.de> <1199954992.18322.83.camel@vespa.frost.loc> <1199996516.18076.118.camel@code.and.org> Message-ID: <20080110203239.GA26570@tango.0pointer.de> On Thu, 10.01.08 15:21, James Antill (james.antill at redhat.com) wrote: > > On Thu, 2008-01-10 at 09:49 +0100, Tomas Mraz wrote: > > On Thu, 2008-01-10 at 00:46 +0100, Lennart Poettering wrote: > > > Although this is totally off-topic: I still think the proper fix is > > > something like this: > > > > > > http://0pointer.de/lennart/projects/nss-myhostname/ > > > http://0pointer.de/lennart/projects/nss-myhostname/README.txt > > > > > > I wrote that a while back. Maybe someone wants to dust this off and > > > get it into Fedora and activated by default? > > > > > > This saved me a couple of times on embedded boxes, where each of the > > > devices used a different hostname and I had to guarantee that the > > > hostname stayed resolvable in all cases, with a ro root directory. > > > > This seems like a nice idea - actually even better idea would be to be > > able to pass some arguments to modules in nsswitch.conf and then simply > > put: > > > > hosts: files dns files(conf=/etc/hosts-fallback) > > My understanding was that the hostname thing is done so that bootup > doesn't stop when you have no network ... and the above module doesn't > help much there (you still have to timeout the DNS requests). First, nothing hinders you to put this module first in your NSS list. It's should be put right next to the "files" item in nsswitch.conf, because it basically just replaces the special /etc/hosts entry for the local host name. Then, the reason I hacked this up was mostly to fix stuff like sudo and apache, which do a lookup+reverse lookup on initialization, which fails completely if DNS doesn't work (as in "*immediately* fail") and the entry is not available in /etc/hosts. DNS lookups that time out are a different problem. > And it still fails in the same way, when there is no network (Ie. > daemon can bind to a specific IP that is the "wrong" one). Hmm? Are you suggesting that there are daemons that bind on addresses by resolving host names? Who's doing something like that? Either daemons should bind on 0.0.0.0 or bind to manually configured IP adresses. Everything else is broken anyway. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From ajackson at redhat.com Thu Jan 10 20:55:44 2008 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 10 Jan 2008 15:55:44 -0500 Subject: Impending X driver deprecation In-Reply-To: <1c252d490801101217v4ef993dcnae880fb2cfc834e7@mail.gmail.com> References: <1199906969.15130.40.camel@localhost.localdomain> <478592B4.8080109@ij.net> <1c252d490801101217v4ef993dcnae880fb2cfc834e7@mail.gmail.com> Message-ID: <1199998544.15130.219.camel@localhost.localdomain> On Thu, 2008-01-10 at 21:17 +0100, Joachim Frieben wrote: > It's not necessarily a matter of work or not, but vesa usually > provides abysmal 2D performance compared to a native driver. The chips mentioned have abysmal performance to begin with. Since it seems just about every one of the drivers I threatened had someone speak up for them, I'll make the effort to port them as well, but they'll likely be at the end of the list. - ajax From jima at beer.tclug.org Thu Jan 10 20:47:51 2008 From: jima at beer.tclug.org (Jima) Date: Thu, 10 Jan 2008 14:47:51 -0600 (CST) Subject: Fedora too cutting edge? In-Reply-To: <47864C2E.7090505@gmail.com> References: <4785163E.8010508@hhs.nl> <47864222.4090508@redhat.com> <47864C2E.7090505@gmail.com> Message-ID: On Thu, 10 Jan 2008, Les Mikesell wrote: > Jarod Wilson wrote: >> Another chicken and egg problem. How do we know it doesn't work if we don't >> ship it? > > Ship it with a way to revert to previous behavior. If people post bugzilla > items and revert, you know it didn't work and you will still have someone to > test your next experiment. Are you realistically expecting people to not skip the "post bugzilla items" step? I like to think the best of people (okay, no I don't), but I try to keep my expectations on this planet. ;-) If we shipped that easy of a reversion (wow, that's a word!) technique, I strongly suspect we'd never hear Juju was broken. Jima From kevin.kofler at chello.at Thu Jan 10 20:57:07 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 10 Jan 2008 20:57:07 +0000 (UTC) Subject: Dropping Base X group? [Was: Re: KDE logout options with F8] References: <4727F17D.2090305@fedoraproject.org> <4728A579.4040901@redhat.com> <4728A66C.8070103@fedoraproject.org> <4728B0E4.2050209@redhat.com> <4728B36C.4060403@fedoraproject.org> <4728C284.405030!5@redhat.com> <20071105010239.GA3632@free.fr> <20080110184351.GC2638@free.fr> Message-ID: Patrice Dumas free.fr> writes: > device since X is all about hiding the hardware. I am currently > discussing that with the xdm upstream maintainer, did you contact the > kde upstream for the patch inclusion? Yes: http://bugs.kde.org/show_bug.cgi?id=147790 The KDM maintainer rejected it. :-( For pretty unconvincing reasons at that: he doesn't agree with the design (but it's the one which is advocated by the ConsoleKit developers and which would allow implementing true fast user switching in KDM later) and he doesn't want GPL (as opposed to X11-licensed) code in the KDM backend (which makes no sense because the frontend is already GPL and because merges back to XDM aren't going to happen anyway, because as you said, the code has diverged a lot). (Part of the code is GPL because it's derived from the GDM implementation.) That said, several other distributions picked it up, for example in OpenSUSE, it was applied to their packages by none other than Dirk M?ller, the upstream KDE release manager. Kevin Kofler From lesmikesell at gmail.com Thu Jan 10 21:00:39 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 10 Jan 2008 15:00:39 -0600 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <16de708d0801101213g38a7883bv202ce8a5e6ab4312@mail.gmail.com> References: <20080109233613.GG2664@free.fr> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <1199982711.30858.41.camel@oneill.fubar.dk> <16de708d0801100840t61b4f1b4p2e999c07563d1030@mail.gmail.com> <1199984082.30858.56.camel@oneill.fubar.dk> <20080110184513.GC1055637@hiwaay.net> <1199991727.32394.3.camel@oneill.fubar.dk> <16de708d0801101128r69e406d7s98260e8d1cb28564@mail.gmail.com> <478678BC.9010802@gmail.com> <16de708d0801101213g38a7883bv202ce8a5e6ab4312@mail.gmail.com> Message-ID: <47868777.9010209@gmail.com> Arthur Pemberton wrote: >>>> Either we look at the USB device it's hanging off (vendor, product or >>>> class id's), the driver or we provide a simple interface in >>>> gnome-device-manager or similar (including command line apps) to set it. >>> You're wierd dude, this essentially the same thing I suggested and you >>> discouraged. >> The system can't possibly work with multiple choices unless you have an >> interface to let a human configure which is which. Now the kicker is >> that most of my machines are in remote locations with swappable drives >> and I expect to be able to ship a pre-configured drive built locally and >> have someone pop it in a known controller position and have it come up >> working - and to be able to copy images that will work across a number >> of identical machines without individual attention other than setting >> the hostname and IP addresses. > > > I would have thought that with dirves you can jsut mount by labels, > does this not work for your use case? First, disks aren't born with labels. Second, most of my disks get created by dd'ing an existing raw disk or the equivalent, generally on a different machine and not necessarily under an exactly matching kernel that would know the filesystem or how to label it. Third, you can't use labels for fdisk/mkfs, or even dump and I'd really like to know which physical drive is going to be the target of those commands. I realize it is not an easy question. For example the adaptec SAS raid controller in an ibm 3550 maps drives to volumes internally and remembers them even if you only have one drive in a volume. That is, if you build a master image in the first slot, dd it to the drive in the 2nd slot, take that 2nd disk and put in the first slot of another and attempt to copy again, your disk with contents will be detected as /dev/sdb (remembered) instead of sda from being in the first position. This is fun when you try to repeat the dd command expecting the same thing to happen. Anyway, the long-winded point is that you do more things with disks than mount the file systems they contain, so a label doesn't solve the identification problem. -- Les Mikesell lesmikesell at gmail.com From dmc.fedora at filteredperception.org Thu Jan 10 21:00:48 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Thu, 10 Jan 2008 15:00:48 -0600 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <4786450F.8010900@gmail.com> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <20080110154230.GB3246@ryvius.greysector.net> <4786450F.8010900@gmail.com> Message-ID: <47868780.6030001@filteredperception.org> Les Mikesell wrote: > Dominik 'Rathann' Mierzejewski wrote: > >>> Is it a user program that has changed my /dev/hdX into /dev/sdX more >>> or less arbitrarily >> >> Can you say "filesystem labels"? I thought so. > > I can say it won't fix an existing configuration. I can say that > filesystem label creation wasn't well thought out for people that move > disks around (after you've installed fedora on all your machines, > they'll all have the same labels and the system is not happy when you > rebuild a machine with a different combination of drives). I can answer this one: Require people to name their system at install (like windows, like macosx, e.g. john-pc), perhaps with a default coming from install date (200807110711), and then make the default fslabels be prefixed with that name and an underscore. e.g. john-pc_/usr problem solved. -dmc I can say > that the design of solaris seems to take machine management over long > intervals of time and large numbers of machines into consideration > whereas Linux does not. From jwilson at redhat.com Thu Jan 10 21:08:03 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 10 Jan 2008 16:08:03 -0500 Subject: thinkpad-acpi upstream version? In-Reply-To: <4786653C.5020204@fedoraproject.org> References: <47852A26.4010609@fedoraproject.org> <364d303b0801091641y763baef2y12a95bde37547c42@mail.gmail.com> <47866320.1040606@redhat.com> <4786653C.5020204@fedoraproject.org> Message-ID: <47868933.6060008@redhat.com> Nicolas Antonio Corrarello wrote: > Maybe you're in the same condition as I am (Also T61 user, great > machine)... Can't make the volume > up/down keys to work, and I can't change the volume through > /proc/acpi/ibm/volume. I'll see if this is solved in the thinkpad-acpi > changelog and file a bug... Ah yes, mine has the same issue with 2.6.23.12 right now, forgot about that. Heck, *I* should have filed a bug already... But I'll let you. :) Also, the brightness keys don't do anything on mine, though that may be resolved in rawhide via xbacklight, iirc. Rawhide was a bit too explodey for me to want to upgrade to it just yet though. > Jarod Wilson wrote: >> Christopher Brown wrote: >>> On 09/01/2008, Nicolas Antonio Corrarello wrote: >>>> Maybe I still don't get how upstream works, but I found that the latest >>>> thinkpad-acpi version is 0.19, still Fedora's latest kernel has >>>> [root at localhost ibm]# cat driver >>>> driver: ThinkPad ACPI Extras >>>> version: 0.16 >>> Its built as an in-kernel module so 2.6.23 == 0.16, 2.6.24 == 0.17 and >>> I guess 2.6.25 == 0.19. >> And if there's a particular problem with thinkpad-acpi you're encountering >> that is fixed by a later version, file a bug where you describe the problem, >> point to the fix, etc, and someone might be willing to backport the fix to the >> latest released kernel. I might even be willing to give it a go as a newly >> minted member of the ThinkPad community... (just got a T61) -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jwilson at redhat.com Thu Jan 10 21:11:28 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 10 Jan 2008 16:11:28 -0500 Subject: Fedora too cutting edge? In-Reply-To: <47864C2E.7090505@gmail.com> References: <4785163E.8010508@hhs.nl> <47864222.4090508@redhat.com> <47864C2E.7090505@gmail.com> Message-ID: <47868A00.4000601@redhat.com> Les Mikesell wrote: > Jarod Wilson wrote: >> >> Another chicken and egg problem. How do we know it doesn't work if we >> don't >> ship it? > > Ship it with a way to revert to previous behavior. If people post > bugzilla items and revert, you know it didn't work and you will still > have someone to test your next experiment. Like jima said... I'm guessing most people simply won't bother with the bug report. Or ever test the new stack again for the life of the release. (Note that the latest F8 kernel has dv capture support for OHCI 1.0 controllers, while the initial release kernel does not). >>> Agreed... At least firewire has been broken for too long (IMHO) > > I gave up on it somewhere around FC3 and switched to the CentOSplus > kernel where I needed something that mostly worked. So I'm not a good > tester any more. Uhm... So you gave up on juju three releases before it existed? It didn't show up until F7... -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jwilson at redhat.com Thu Jan 10 21:17:20 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 10 Jan 2008 16:17:20 -0500 Subject: Fedora too cutting edge? In-Reply-To: <47868A00.4000601@redhat.com> References: <4785163E.8010508@hhs.nl> <47864222.4090508@redhat.com> <47864C2E.7090505@gmail.com> <47868A00.4000601@redhat.com> Message-ID: <47868B60.9080403@redhat.com> Jarod Wilson wrote: > Les Mikesell wrote: >> Ship it with a way to revert to previous behavior. If people post >> bugzilla items and revert, you know it didn't work and you will still >> have someone to test your next experiment. > > Like jima said... I'm guessing most people simply won't bother with the bug > report. Or ever test the new stack again for the life of the release. (Note > that the latest F8 kernel has dv capture support for OHCI 1.0 controllers, > while the initial release kernel does not). > >>>> Agreed... At least firewire has been broken for too long (IMHO) >> I gave up on it somewhere around FC3 and switched to the CentOSplus >> kernel where I needed something that mostly worked. So I'm not a good >> tester any more. > > Uhm... So you gave up on juju three releases before it existed? It didn't show > up until F7... Wow. I can't count. Make that four releases. Okay, anyhow, enough of this, as Hans said, we're working on fixing things. In the mean time, multiple 3rd-party repositories package up the old stack for those who still need it. /me goes back to attempting to be productive... -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From lesmikesell at gmail.com Thu Jan 10 21:22:34 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 10 Jan 2008 15:22:34 -0600 Subject: Fedora too cutting edge? In-Reply-To: References: <4785163E.8010508@hhs.nl> <47864222.4090508@redhat.com> <47864C2E.7090505@gmail.com> Message-ID: <47868C9A.3070404@gmail.com> Jima wrote: > >>> Another chicken and egg problem. How do we know it doesn't work if we >>> don't >>> ship it? >> >> Ship it with a way to revert to previous behavior. If people post >> bugzilla items and revert, you know it didn't work and you will still >> have someone to test your next experiment. > > Are you realistically expecting people to not skip the "post bugzilla > items" step? I like to think the best of people (okay, no I don't), but > I try to keep my expectations on this planet. ;-) > If we shipped that easy of a reversion (wow, that's a word!) technique, > I strongly suspect we'd never hear Juju was broken. Well you won't hear it from me anyway because I gave up on fedora/firewire back when the FC3-era bz entry sat for 6 months or so with no activity and no way to get to the data on my disks under fedora. But the solution is to put the reversion procedure in the bugzilla item in response to the first bug report and subsequently refer to it only by links. If you want bz reports you have to make them lead to quick solutions. -- Les Mikesell lesmikesell at gmail.com From lordmorgul at gmail.com Thu Jan 10 22:17:25 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Thu, 10 Jan 2008 14:17:25 -0800 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199982487.30858.38.camel@oneill.fubar.dk> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> Message-ID: <47869975.6010804@gmail.com> David Zeuthen wrote: > On Thu, 2008-01-10 at 09:31 -0600, Les Mikesell wrote: >> Is it a user program that has changed my /dev/hdX into /dev/sdX more or >> less arbitrarily - or turns what used to be detected as eth0 into eth2 >> when a different kernel is booted? Admittedly it has been a while since >> I've used Solaris, but I can't recall anything like that ever happening >> with it. In a unix-like system where access to everything is through >> its device/file name, what is more fundamental than that? > > This is a flawed example. The problem is that you're relying on names > assigned in an irregular fashion and it will happen on Solaris as well > if you move disks between controllers etc. The way to do this in the > modern world is to rely on persistent names. See /dev/disk/* and the > udev rules for stable network interface names. Of course you can argue > that e.g. /dev/sda or /dev/hda should stay stable but I doubt you're > going to find much sympathy for such a point of view. And the interesting thing is it looks like /dev/sdX will 'stay stable' as the way its done after that change. Change happens. :) -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From david at fubar.dk Thu Jan 10 22:24:08 2008 From: david at fubar.dk (David Zeuthen) Date: Thu, 10 Jan 2008 17:24:08 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <47869975.6010804@gmail.com> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <47869975.6010804@gmail.com> Message-ID: <1200003848.2981.13.camel@oneill.fubar.dk> On Thu, 2008-01-10 at 14:17 -0800, Andrew Farris wrote: > And the interesting thing is it looks like /dev/sdX will 'stay stable' as the > way its done after that change. Change happens. :) I wouldn't put my money on it.. maybe it's stable (for some definition of the word) now, probably not in a few years. (Interestingly enough, one price Fedora pays for this so-called stability is that booting is somewhat slower, e.g. crap like scsi_wait_scan.ko) David From caillon at redhat.com Thu Jan 10 22:46:11 2008 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 10 Jan 2008 23:46:11 +0100 Subject: Dropping Base X group? [Was: Re: KDE logout options with F8] In-Reply-To: References: <4727F17D.2090305@fedoraproject.org> <4728A579.4040901@redhat.com> <4728A66C.8070103@fedoraproject.org> <4728B0E4.2050209@redhat.com> <4728B36C.4060403@fedoraproject.org> <4728C284.405030!5@redhat.com> <20071105010239.GA3632@free.fr> <20080110184351.GC2638@free.fr> Message-ID: <4786A033.7030909@redhat.com> On 01/10/2008 09:57 PM, Kevin Kofler wrote: > Patrice Dumas free.fr> writes: >> device since X is all about hiding the hardware. I am currently >> discussing that with the xdm upstream maintainer, did you contact the >> kde upstream for the patch inclusion? > > Yes: http://bugs.kde.org/show_bug.cgi?id=147790 > > The KDM maintainer rejected it. :-( For pretty unconvincing reasons at that: he > doesn't agree with the design (but it's the one which is advocated by the > ConsoleKit developers and which would allow implementing true fast user > switching in KDM later) and he doesn't want GPL (as opposed to X11-licensed) > code in the KDM backend (which makes no sense because the frontend is already > GPL and because merges back to XDM aren't going to happen anyway, because as > you said, the code has diverged a lot). (Part of the code is GPL because it's > derived from the GDM implementation.) > > That said, several other distributions picked it up, for example in OpenSUSE, > it was applied to their packages by none other than Dirk M?ller, the upstream > KDE release manager. This makes me feel all warm and tingly about KDE... From ngompa13 at gmail.com Thu Jan 10 22:57:37 2008 From: ngompa13 at gmail.com (King InuYasha) Date: Thu, 10 Jan 2008 16:57:37 -0600 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <935ead450801100605m6dda8021t2618b3132129e354@mail.gmail.com> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <20080109094532.811057b2.mschwendt.tmp0701.nospam@arcor.de> <64b14b300801090446u1412557p7bee40aa9922223d@mail.gmail.com> <1199916701.8159.2.camel@localhost.localdomain> <364d303b0801091644s7c9109a8v4b1bfe0f90427cb@mail.gmail.com> <1199964183.8159.15.camel@localhost.localdomain> <364d303b0801100437g1ed6c0b8tb7e71784e9ba3bd@mail.gmail.com> <47862106.2010607@redhat.com> <935ead450801100605m6dda8021t2618b3132129e354@mail.gmail.com> Message-ID: <8278b1b0801101457k3f570193ja3a40ed14e2e48f7@mail.gmail.com> Well, there is also the issue that JACK module was not re added to PulseAudio until 0.9.8. It was taken out of the 0.9.7 release, and people who NEED that functionality should have the JACK module support in PulseAudio. On Jan 10, 2008 8:05 AM, Jeffrey Ollie wrote: > On 1/10/08, Warren Togami wrote: > > Christopher Brown wrote: > > > > > > http://pulseaudio.org/milestone/0.9.8 > > > > > > gives some good reasons to upgrade. This is more than just "a change > > > of one digit in a version number". In any event my comment related not > > > just to pulseaudio but to Fedora as a whole. Point releases reflect > > > bug fixes - usually - and so upgrading to resolve outstanding bugs is > > > something that I and many users no doubt will applaud. You are not > > > forced to accept these upgrades. > > > > We are yet to hear from Lennart about this, but I was under the > > impression that the pulseaudio shipped in F8 was a svn snapshot *very* > > close to 0.9.8. > > > > pulseaudio-0.9.7-0.17.svn20071017.fc8 was built October 30th > > 0.9.8 was released November 20th > > I don't see how the code in 0.9.7-0.17.svn20071017.fc8 could possibly > be considered very close to 0.9.8, seeing as any SVN snapshot from > 2007-10-17 is almost two weeks before 0.9.7 was tagged/released on > 2007-10-30. > > Jeff > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lesmikesell at gmail.com Thu Jan 10 23:04:40 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 10 Jan 2008 17:04:40 -0600 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1200003848.2981.13.camel@oneill.fubar.dk> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <47869975.6010804@gmail.com> <1200003848.2981.13.camel@oneill.fubar.dk> Message-ID: <4786A488.4060605@gmail.com> David Zeuthen wrote: > On Thu, 2008-01-10 at 14:17 -0800, Andrew Farris wrote: >> And the interesting thing is it looks like /dev/sdX will 'stay stable' as the >> way its done after that change. Change happens. :) > > I wouldn't put my money on it.. maybe it's stable (for some definition > of the word) now, probably not in a few years. > > (Interestingly enough, one price Fedora pays for this so-called > stability is that booting is somewhat slower, e.g. crap like > scsi_wait_scan.ko) The sdX names never were related to hardware in the same sense as the hdX ones were so 'stay stable' is an odd term. If you know the controller and drive select you knew the hdX name. The sdX names have always been whimsically assigned depending on what else happens to be present. There's nothing you can see to relate the name to a physical device. -- Les Mikesell lesmikesell at gmail.com From mzerqung at 0pointer.de Thu Jan 10 23:04:07 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Fri, 11 Jan 2008 00:04:07 +0100 Subject: Fedora too cutting edge? In-Reply-To: <1199951988.1742.18.camel@jndwidescreen.lesbg.loc> References: <4785163E.8010508@hhs.nl> <20080110004941.GA20965@tango.0pointer.de> <1199951988.1742.18.camel@jndwidescreen.lesbg.loc> Message-ID: <20080110230407.GA4078@tango.0pointer.de> On Thu, 10.01.08 09:59, Jonathan Dieter (jdieter at gmail.com) wrote: > On Thu, 2008-01-10 at 01:49 +0100, Lennart Poettering wrote: > > > I don't think this BZ excerpt is any good as argument for your > > point. A big share of the bugs listed for PA are duplicates. BZ is > > very good for burying people in vast amount of emails due to new or > > updated bug reports. My main job is hacking on PA, not wading through > > BZ. Which is why I tend to ignore bugzilla as good as I can and clean > > it up only just before every release. > > > I really appreciate what you do with pulseaudio, but I'm not quite sure > what to make of this comment. What do you want us to do if we come > across a pulseaudio bug? Report it via BZ or PA BTS! (Exactly like you did) I ask everyone to be patient, though. I do fix look at those bug reports and fix them, but only shortly before the next release. The point of my mail is just that statistics about the "buggyness" of software based on bugzilla data is bogus. > For example, when pulseaudio is running as a system-wide daemon, any > games using Alsa start to stutter after a few minutes. In single-user > mode, they work perfectly. I opened a bug for this a month ago > ( https://bugzilla.redhat.com/show_bug.cgi?id=417681 ), and I've not > gotten any response yet. Now I realize this is probably a low-priority > for you, but I guess I was hoping for at least an ACK. Uh, system-wide mode is not really supported anyway. On Fedora I chose to setup PA as a session service, and that's what is supported. But that's a different story. > Will you eventually get around to looking at it or is BZ redirected > to /dev/null for you (which is how I read the above excerpt, though it > may not be what you meant). I clean up BZ everytime I do a new release. "Clean up" as in "fix all relevant bugs". > Please understand I'm not trying to jump on you, I just want to know the > best way of reporting a bug to you. Use BZ or the PA BTS -- You did everything right! Thanks, Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From pertusus at free.fr Thu Jan 10 23:05:00 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 11 Jan 2008 00:05:00 +0100 Subject: Dropping Base X group? [Was: Re: KDE logout options with F8] In-Reply-To: References: <4728A66C.8070103@fedoraproject.org> <4728B0E4.2050209@redhat.com> <4728B36C.4060403@fedoraproject.org> <4728C284.405030!5@redhat.com> <20071105010239.GA3632@free.fr> <20080110184351.GC2638@free.fr> Message-ID: <20080110230459.GA6954@free.fr> On Thu, Jan 10, 2008 at 08:57:07PM +0000, Kevin Kofler wrote: > Patrice Dumas free.fr> writes: > > device since X is all about hiding the hardware. I am currently > > discussing that with the xdm upstream maintainer, did you contact the > > kde upstream for the patch inclusion? > > Yes: http://bugs.kde.org/show_bug.cgi?id=147790 > > The KDM maintainer rejected it. :-( For pretty unconvincing reasons at that: he > doesn't agree with the design (but it's the one which is advocated by the > ConsoleKit developers and which would allow implementing true fast user > switching in KDM later) and he doesn't want GPL (as opposed to X11-licensed) > code in the KDM backend (which makes no sense because the frontend is already > GPL and because merges back to XDM aren't going to happen anyway, because as > you said, the code has diverged a lot). (Part of the code is GPL because it's > derived from the GDM implementation.) I think he is right on one point, libck-connector should be used instead of picking the gdm code, it is under the MIT, and it is better to use a lib to reuse code instead of cut and paste. gdm should certainly also use libck-connector. -- Pat From lesmikesell at gmail.com Thu Jan 10 23:11:55 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 10 Jan 2008 17:11:55 -0600 Subject: Init : someone could comment this ? In-Reply-To: <20080110203239.GA26570@tango.0pointer.de> References: <1199880879.5534.210.camel@beck.corsepiu.local> <7f692fec0801090539y4f8aa894i1ace29ab884aa994@mail.gmail.com> <200801091406.m09E6dOe013547@laptop13.inf.utfsm.cl> <47852FB8.6060603@gmail.com> <4785355F.5060302@gmail.com> <47854594.7070205@gmail.com> <47854C7B.2000303@wolves.durham.nc.us> <20080109234605.GB16506@tango.0pointer.de> <1199954992.18322.83.camel@vespa.frost.loc> <1199996516.18076.118.camel@code.and.org> <20080110203239.GA26570@tango.0pointer.de> Message-ID: <4786A63B.1070404@gmail.com> Lennart Poettering wrote: > Then, the reason I hacked this up was mostly to fix stuff like sudo > and apache, which do a lookup+reverse lookup on initialization, which > fails completely if DNS doesn't work (as in "*immediately* fail") and > the entry is not available in /etc/hosts. DNS lookups that time out > are a different problem. > >> And it still fails in the same way, when there is no network (Ie. >> daemon can bind to a specific IP that is the "wrong" one). > > Hmm? > > Are you suggesting that there are daemons that bind on addresses by > resolving host names? Who's doing something like that? Either daemons > should bind on 0.0.0.0 or bind to manually configured IP > adresses. Everything else is broken anyway. There are a lot of things that can't work and will do horribly wrong things if started without a working DNS - and for reasons not related to your own hostname. Such daemons would be better off if they could defer startup until after DNS works. -- Les Mikesell lesmikesell at gmail.com From mzerqung at 0pointer.de Thu Jan 10 23:15:43 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Fri, 11 Jan 2008 00:15:43 +0100 Subject: Fedora too cutting edge? In-Reply-To: <4785E813.7020704@hhs.nl> References: <4785163E.8010508@hhs.nl> <20080110004941.GA20965@tango.0pointer.de> <4785E813.7020704@hhs.nl> Message-ID: <20080110231542.GB4078@tango.0pointer.de> On Thu, 10.01.08 10:40, Hans de Goede (j.w.r.degoede at hhs.nl) wrote: >> A big share of the bugs listed for PA are duplicates. BZ is >> very good for burying people in vast amount of emails due to new or >> updated bug reports. My main job is hacking on PA, not wading through >> BZ. Which is why I tend to ignore bugzilla as good as I can and clean >> it up only just before every release. > > And I think this is bad, we need to nourish people who provide valuable > feedback, not ignore them and let BZ tickets rot. Also see Jonathan Dieter > reply for an example of why this is bad. > > Why not reserve 30 minutes a day to respond to bug tickets, if you do this > every day, keeping on top of things, then keeping BZ spam in track should > be manageable. I did that initially, and then I stopped to do it that way. It just didn't work for me. I spent way too much time on BZ that way, And spending time on BZ is not what I am being primarily payed for. (And it's also not where the fun is in my eyes...) Also, since our BZ is so embarassingly slow the time spent on BZ is twenty times what it could be. Why, oh, why is our BZ just so f**g slow compared to all other BZs? Even SUSE's BZ is a million times faster than ours. > Anyways after my recent bugfixing surrounding pulseaudio, I've already been > thinking about trying to help out with pulseaudio, so as usual I'm willing > to put my code where my mouth is and I'm hereby offering to do pulseaudio > bug triaging for you. But pulseaudio is a complex beast, so I will be > needing help from you. I can do the initial grunt work of filtering > duplicates, filtering configuration errors and trying to make problems > reproducable, but after that I will need help from you. Does this sound > like a deal? And once I'm in a stadium where I need help, how do I reach > you in such a way that you do respond in a reasonable time? I am happy for every help! Feel free to merge, close or comment on all BZ bug reports if it seems sensible to you. It would certainly help me to release new PA versions more quickly! You can always, ping me on #pulseaudio on freenode. Ping me multiple times if I don't react. Thanks, Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Fri Jan 11 00:06:18 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Fri, 11 Jan 2008 01:06:18 +0100 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <47862106.2010607@redhat.com> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <20080109094532.811057b2.mschwendt.tmp0701.nospam@arcor.de> <64b14b300801090446u1412557p7bee40aa9922223d@mail.gmail.com> <1199916701.8159.2.camel@localhost.localdomain> <364d303b0801091644s7c9109a8v4b1bfe0f90427cb@mail.gmail.com> <1199964183.8159.15.camel@localhost.localdomain> <364d303b0801100437g1ed6c0b8tb7e71784e9ba3bd@mail.gmail.com> <47862106.2010607@redhat.com> Message-ID: <20080111000616.GC7758@tango.0pointer.de> On Thu, 10.01.08 08:43, Warren Togami (wtogami at redhat.com) wrote: > > Christopher Brown wrote: >> http://pulseaudio.org/milestone/0.9.8 >> gives some good reasons to upgrade. This is more than just "a change >> of one digit in a version number". In any event my comment related not >> just to pulseaudio but to Fedora as a whole. Point releases reflect >> bug fixes - usually - and so upgrading to resolve outstanding bugs is >> something that I and many users no doubt will applaud. You are not >> forced to accept these upgrades. >> Cheers > > We are yet to hear from Lennart about this, but I was under the impression > that the pulseaudio shipped in F8 was a svn snapshot *very* close to 0.9.8. > > pulseaudio-0.9.7-0.17.svn20071017.fc8 was built October 30th > 0.9.8 was released November 20th > > It might be the case that we might not gain much (or anything?) by > upgrading only to 0.9.8. Lennart? Sorry for not responding earlier. The Snapshot in F8 is a prerelease of 0.9.7. It basically is the same codebase as the final 0.9.7, but some modules that are available in 0.9.6 and the final 0.9.7 are not included in this preview since I didn't have the time back then to port them fully over to the new core. 0.9.8 is an even newer release, with major changes. I discussed the whole situation with Lubomir a while back, when I last updated the packages for Rawhide. Thing is: right now we don't have a real policy on what kind of updates should be pushed into already released releases and what updates shouldn't (but there's a draft, or something? don't really remember, didn't really follow this). My understanding is that no big updates should be pushed to released versions, but bugfixes should. (I used to follow Debian before I joined RH, and their policy is very strict on this stuff, and I believe that makes sense). So, looking on 0.9.7-pre, on 0.9.7-final and 0.9.8, I decided that the changes are not really suited for an updated package for an already released distribution, since they are almost exclusively new features, and only very few relevant bugfixes. I guess this is the classical distribution dilemma: are the new features or the stability more important? Whatever way I decide, I'll make some people unhappy. Long story short: The changes to 0.9.7 are no bugfixes, those to 0.9.8 are invasive. So I believe this better stays out of an already released distribution. And then, you can always run Rawhide. It has 0.9.8. And has had it for quite a while. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From devrim at CommandPrompt.com Fri Jan 11 00:15:23 2008 From: devrim at CommandPrompt.com (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=) Date: Thu, 10 Jan 2008 16:15:23 -0800 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <20080111000616.GC7758@tango.0pointer.de> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <20080109094532.811057b2.mschwendt.tmp0701.nospam@arcor.de> <64b14b300801090446u1412557p7bee40aa9922223d@mail.gmail.com> <1199916701.8159.2.camel@localhost.localdomain> <364d303b0801091644s7c9109a8v4b1bfe0f90427cb@mail.gmail.com> <1199964183.8159.15.camel@localhost.localdomain> <364d303b0801100437g1ed6c0b8tb7e71784e9ba3bd@mail.gmail.com> <47862106.2010607@redhat.com> <20080111000616.GC7758@tango.0pointer.de> Message-ID: <1200010523.3398.36.camel@localhost.localdomain> Hi, On Fri, 2008-01-11 at 01:06 +0100, Lennart Poettering wrote: > Thing is: right now we don't have a real policy on what kind of > updates should be pushed into already released releases and what > updates shouldn't It is up to the packager -- If I feel that an update won't break existing installations, and it will make people happy, then I push that update -- no matter what the version number is. Regards, -- Devrim G?ND?Z , RHCE PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mjs at CLEMSON.EDU Fri Jan 11 00:21:48 2008 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Thu, 10 Jan 2008 19:21:48 -0500 Subject: thinkpad-acpi upstream version? In-Reply-To: <47868933.6060008@redhat.com> References: <47852A26.4010609@fedoraproject.org> <364d303b0801091641y763baef2y12a95bde37547c42@mail.gmail.com> <47866320.1040606@redhat.com> <4786653C.5020204@fedoraproject.org> <47868933.6060008@redhat.com> Message-ID: <1200010908.20425.6.camel@vincent52.localdomain> On Thu, 2008-01-10 at 16:08 -0500, Jarod Wilson wrote: > Nicolas Antonio Corrarello wrote: > > Maybe you're in the same condition as I am (Also T61 user, great > > machine)... Can't make the volume > > up/down keys to work, and I can't change the volume through > > /proc/acpi/ibm/volume. I'll see if this is solved in the thinkpad-acpi > > changelog and file a bug... > > Ah yes, mine has the same issue with 2.6.23.12 right now, forgot about that. > Heck, *I* should have filed a bug already... But I'll let you. :) > > Also, the brightness keys don't do anything on mine, though that may be > resolved in rawhide via xbacklight, iirc. Rawhide was a bit too explodey for > me to want to upgrade to it just yet though. Which video driver? Does yours suspend properly? > > > > Jarod Wilson wrote: > >> Christopher Brown wrote: > >>> On 09/01/2008, Nicolas Antonio Corrarello wrote: > >>>> Maybe I still don't get how upstream works, but I found that the latest > >>>> thinkpad-acpi version is 0.19, still Fedora's latest kernel has > >>>> [root at localhost ibm]# cat driver > >>>> driver: ThinkPad ACPI Extras > >>>> version: 0.16 > >>> Its built as an in-kernel module so 2.6.23 == 0.16, 2.6.24 == 0.17 and > >>> I guess 2.6.25 == 0.19. > >> And if there's a particular problem with thinkpad-acpi you're encountering > >> that is fixed by a later version, file a bug where you describe the problem, > >> point to the fix, etc, and someone might be willing to backport the fix to the > >> latest released kernel. I might even be willing to give it a go as a newly > >> minted member of the ThinkPad community... (just got a T61) > -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From lesmikesell at gmail.com Fri Jan 11 00:35:14 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 10 Jan 2008 18:35:14 -0600 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <16de708d0801100840t61b4f1b4p2e999c07563d1030@mail.gmail.com> References: <4785163E.8010508@hhs.nl> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <1199982711.30858.41.camel@oneill.fubar.dk> <16de708d0801100840t61b4f1b4p2e999c07563d1030@mail.gmail.com> Message-ID: <4786B9C2.2050502@gmail.com> Arthur Pemberton wrote: >> On Thu, 2008-01-10 at 11:28 -0500, David Zeuthen wrote: >>> udev rules for stable network interface names. >> Btw, that would be >> >> /etc/udev/rules.d/70-persistent-net.rules >> /etc/udev/rules.d/75-persistent-net-generator.rules >> >> HTH. Follow up with questions on the udev list please. > > > We are badly in need of system-config-udev. I spent several hours > understanding udev adn building rules for my sound cards and tv cards. > I hadn't done a yum update on my F7 box for weeks/months (lazyness) > did one this week, and it apperently just blew away my custom udev > config Is this another work-in-progress? I don't have anything handy newer than FC6 which doesn't have persistent-net.rules and a similar question on the Centos list mentioned that ethX devices can be renamed when the the ifup scripts run. -- Les Mikesell lesmikesell at gmail.com From wtogami at redhat.com Fri Jan 11 03:07:19 2008 From: wtogami at redhat.com (Warren Togami) Date: Thu, 10 Jan 2008 22:07:19 -0500 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <20080111000616.GC7758@tango.0pointer.de> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <20080109094532.811057b2.mschwendt.tmp0701.nospam@arcor.de> <64b14b300801090446u1412557p7bee40aa9922223d@mail.gmail.com> <1199916701.8159.2.camel@localhost.localdomain> <364d303b0801091644s7c9109a8v4b1bfe0f90427cb@mail.gmail.com> <1199964183.8159.15.camel@localhost.localdomain> <364d303b0801100437g1ed6c0b8tb7e71784e9ba3bd@mail.gmail.com> <47862106.2010607@redhat.com> <20080111000616.GC7758@tango.0pointer.de> Message-ID: <4786DD67.1030808@redhat.com> Lennart Poettering wrote: > > I discussed the whole situation with Lubomir a while back, when I last > updated the packages for Rawhide. Thing is: right now we don't have a > real policy on what kind of updates should be pushed into already > released releases and what updates shouldn't (but there's a draft, or > something? don't really remember, didn't really follow this). My > understanding is that no big updates should be pushed to released > versions, but bugfixes should. (I used to follow Debian > before I joined RH, and their policy is very strict on this stuff, and > I believe that makes sense). > > So, looking on 0.9.7-pre, on 0.9.7-final and 0.9.8, I decided that the > changes are not really suited for an updated package for an already > released distribution, since they are almost exclusively new features, > and only very few relevant bugfixes. > > I guess this is the classical distribution dilemma: are the new > features or the stability more important? Whatever way I decide, I'll > make some people unhappy. > > Long story short: The changes to 0.9.7 are no bugfixes, those to 0.9.8 > are invasive. So I believe this better stays out of an already > released distribution. > > And then, you can always run Rawhide. It has 0.9.8. And has had it for > quite a while. > > Lennart > As a general rule, version upgrades with new features are NOT disallowed in Fedora. Version upgrades with new features are introduced in a controlled and careful manner only after heavy testing. For example, you might see several kernel rebases during a Fedora release lifetime like 2.6.22 -> 2.6.23 -> 2.6.24. Version upgrades that massively break ABI are disallowed during a stable Fedora release. For example, we never do a rebase to a newer openssl version during a stable release because they always break their so-name ABI revision, and far too many applications depend on the existing so-name ABI. Does upgrading from 0.9.7 to 0.9.8 break library ABI with applications already linked against any pulseaudio library? If not, we should really explore the possibility of upgrading to a newer pulseaudio version in Fedora 8. http://people.redhat.com/davej/kernels/Fedora/f8/ By explore the possibilty, I mean doing a test build of pulseaudio-0.9.8 for F8 and putting it into a side repository similar to davej's un-official test kernel repository. This allows folks to opt-in to easily test your latest pulseaudio on F8 without risking everyone. By having your own side-repository with F8 pulseuaudio, you can do your own builds and push new test packages as often as you want for your own test users. koji's build --scratch option makes it real easy to do test builds of a single package on all supported Fedora architectures without it being an official build. Later when the test users agree that the pulseaudio package in your test repository is seemingly good, it can be pushed to F8's updates-testing repository where many thousands of other users who opt-in to that optional channel will be exposed to it. It can be tested there for a while before pushing to the public in the stable updates channel. This multi-layered approach to testing should ensure that the update is of higher quality than the current F8 pulseaudio. Pulseaudio made many applications that used to be stable suddenly unreliable. Apps like pidgin, mplayer, xine, Adobe Flash Player and many more now have weird pulseaudio related crash issues. There is a desire to pull in newer pulseaudio versions if bugs are fixed to make it more stable. Please let us explore the feasibility of upgrading it in F8? Warren Togami wtogami at redhat.com From wtogami at redhat.com Fri Jan 11 03:19:00 2008 From: wtogami at redhat.com (Warren Togami) Date: Thu, 10 Jan 2008 22:19:00 -0500 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <20080111000616.GC7758@tango.0pointer.de> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <20080109094532.811057b2.mschwendt.tmp0701.nospam@arcor.de> <64b14b300801090446u1412557p7bee40aa9922223d@mail.gmail.com> <1199916701.8159.2.camel@localhost.localdomain> <364d303b0801091644s7c9109a8v4b1bfe0f90427cb@mail.gmail.com> <1199964183.8159.15.camel@localhost.localdomain> <364d303b0801100437g1ed6c0b8tb7e71784e9ba3bd@mail.gmail.com> <47862106.2010607@redhat.com> <20080111000616.GC7758@tango.0pointer.de> Message-ID: <4786E024.7030003@redhat.com> Lennart Poettering wrote: > > So, looking on 0.9.7-pre, on 0.9.7-final and 0.9.8, I decided that the > changes are not really suited for an updated package for an already > released distribution, since they are almost exclusively new features, > and only very few relevant bugfixes. > > I guess this is the classical distribution dilemma: are the new > features or the stability more important? Whatever way I decide, I'll > make some people unhappy. > We don't currently have even stability, so it really isn't a choice a between the two. It sounds like 0.9.8 doesn't have relevant stability fixes, and perhaps the desire to upgrade to 0.9.8 is misguided because it really wouldn't help? Warren Togami wtogami at redhat.com From cmadams at hiwaay.net Fri Jan 11 03:30:59 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 10 Jan 2008 21:30:59 -0600 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <1199991727.32394.3.camel@oneill.fubar.dk> References: <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <1199982711.30858.41.camel@oneill.fubar.dk> <16de708d0801100840t61b4f1b4p2e999c07563d1030@mail.gmail.com> <1199984082.30858.56.camel@oneill.fubar.dk> <20080110184513.GC1055637@hiwaay.net> <1199991727.32394.3.camel@oneill.fubar.dk> Message-ID: <20080111033059.GB818121@hiwaay.net> Once upon a time, David Zeuthen said: > > On Thu, 2008-01-10 at 12:45 -0600, Chris Adams wrote: > > And how do you know automatically that one of my USB-to-RS232 adapters > > is my UPS (should be /dev/ups), one is my GPS (/dev/gps0), and one is a > > cell phone (/dev/modem)? > > Either we look at the USB device it's hanging off (vendor, product or > class id's), the driver or we provide a simple interface in > gnome-device-manager or similar (including command line apps) to set it. Since they are all USB-to-RS232 adapters, you can't tell anything by USB info (they are all interfacing to RS232 devices). Two of them use the same driver, and annoyingly, the chip vendor for that USB-to-RS232 doesn't set a serial number, so the only way to distinguish them is via USB port. Also, some GNOME thing is not a solution, as I'd like my UPS and GPS to be active on boot (the GPS is used by NTP for clock sync), not some time later after a user logs in. > That's the answer to this (very real) > problem, not a silly program that generates udev rules. So then we have to have two things running trying to name devices? I thought udev was supposed to be "the" solution. Using udev rules is easy, it is just that writing them is beyond the point-n-click user. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From notting at redhat.com Fri Jan 11 05:10:07 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 11 Jan 2008 00:10:07 -0500 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <4786B9C2.2050502@gmail.com> References: <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <1199982711.30858.41.camel@oneill.fubar.dk> <16de708d0801100840t61b4f1b4p2e999c07563d1030@mail.gmail.com> <4786B9C2.2050502@gmail.com> Message-ID: <20080111051007.GA5489@nostromo.devel.redhat.com> Les Mikesell (lesmikesell at gmail.com) said: >> We are badly in need of system-config-udev. I spent several hours >> understanding udev adn building rules for my sound cards and tv cards. >> I hadn't done a yum update on my F7 box for weeks/months (lazyness) >> did one this week, and it apperently just blew away my custom udev >> config > > Is this another work-in-progress? I don't have anything handy newer than > FC6 which doesn't have persistent-net.rules and a similar question on the > Centos list mentioned that ethX devices can be renamed when the the ifup > scripts run. persistent-net.rules in Fedora is a F8 and later thing. Bill From mspevack at redhat.com Wed Jan 9 14:41:27 2008 From: mspevack at redhat.com (Max Spevack) Date: Wed, 9 Jan 2008 09:41:27 -0500 (EST) Subject: Regarding FUDCon's Friday Hackfest Message-ID: This is kind of amusing.... so the Friday hackfests for FUDCon are at the "State Club" which is on NCSU's campus. It's a really nice building with meeting rooms, a very nice lunch that you will partake in, etc. You'll love it, really. Turns out though, that there is a "no jeans, no shorts" dress code. So for all of you hackers -- bring a pair of khakis with you. If you wanted to wear a polo shirt, that would really knock their socks off. :) The actual Saturday FUDCon and Sunday hackfests -- clothing required, but that is all. Thanks, Max _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From mmcgrath at redhat.com Fri Jan 11 05:19:20 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 10 Jan 2008 23:19:20 -0600 (CST) Subject: Outage Notification - Fri Jan 11 05:11:26 UTC 2008 Message-ID: There will be an outage starting at Fri Jan 11 05:11:26 UTC 2008, which will last approximately X hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d 'Fri Jan 11 05:11:26 UTC 2008' Affected Services: Websites Buildsystem Database Unaffected Services: CVS / Source Control DNS Mail Torrent Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/338 Reason for Outage: db2 is having some issues with scaling and we believe the planner is a bit out out of whack. We have made some alterations and are re-analyzing, it could take some time. Expect slow responses or brief outages of the affected systems during this time. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From jdieter at gmail.com Fri Jan 11 05:56:56 2008 From: jdieter at gmail.com (Jonathan Dieter) Date: Fri, 11 Jan 2008 07:56:56 +0200 Subject: Fedora too cutting edge? In-Reply-To: <20080110230407.GA4078@tango.0pointer.de> References: <4785163E.8010508@hhs.nl> <20080110004941.GA20965@tango.0pointer.de> <1199951988.1742.18.camel@jndwidescreen.lesbg.loc> <20080110230407.GA4078@tango.0pointer.de> Message-ID: <1200031016.20982.1.camel@jndwidescreen.lesbg.loc> On Fri, 2008-01-11 at 00:04 +0100, Lennart Poettering wrote: > On Thu, 10.01.08 09:59, Jonathan Dieter (jdieter at gmail.com) wrote: > > > On Thu, 2008-01-10 at 01:49 +0100, Lennart Poettering wrote: > > > > > I don't think this BZ excerpt is any good as argument for your > > > point. A big share of the bugs listed for PA are duplicates. BZ is > > > very good for burying people in vast amount of emails due to new or > > > updated bug reports. My main job is hacking on PA, not wading through > > > BZ. Which is why I tend to ignore bugzilla as good as I can and clean > > > it up only just before every release. > > > > > > I really appreciate what you do with pulseaudio, but I'm not quite sure > > what to make of this comment. What do you want us to do if we come > > across a pulseaudio bug? > > Report it via BZ or PA BTS! (Exactly like you did) > > I ask everyone to be patient, though. I do fix look at those bug > reports and fix them, but only shortly before the next release. Ok, excellent. That's all I wanted to know! > The point of my mail is just that statistics about the "buggyness" of > software based on bugzilla data is bogus. Fair enough. And you did make a compelling argument. > > For example, when pulseaudio is running as a system-wide daemon, any > > games using Alsa start to stutter after a few minutes. In single-user > > mode, they work perfectly. I opened a bug for this a month ago > > ( https://bugzilla.redhat.com/show_bug.cgi?id=417681 ), and I've not > > gotten any response yet. Now I realize this is probably a low-priority > > for you, but I guess I was hoping for at least an ACK. > > Uh, system-wide mode is not really supported anyway. On Fedora I chose > to setup PA as a session service, and that's what is supported. But > that's a different story. Yeah, I know it's not really supported, but for my situation (where I don't want pulseaudio being shutdown on logout and I want all users to be able to access it), it fits. I expect that my bug will be at the bottom of the list, and that's not a problem. I'm just hoping it gets looked at sometime. Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Fri Jan 11 06:07:31 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 10 Jan 2008 21:07:31 -0900 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <20080111000616.GC7758@tango.0pointer.de> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <20080109094532.811057b2.mschwendt.tmp0701.nospam@arcor.de> <64b14b300801090446u1412557p7bee40aa9922223d@mail.gmail.com> <1199916701.8159.2.camel@localhost.localdomain> <364d303b0801091644s7c9109a8v4b1bfe0f90427cb@mail.gmail.com> <1199964183.8159.15.camel@localhost.localdomain> <364d303b0801100437g1ed6c0b8tb7e71784e9ba3bd@mail.gmail.com> <47862106.2010607@redhat.com> <20080111000616.GC7758@tango.0pointer.de> Message-ID: <604aa7910801102207v3e67b1a1y6c989cec6bcac110@mail.gmail.com> On Jan 10, 2008 3:06 PM, Lennart Poettering wrote: > Long story short: The changes to 0.9.7 are no bugfixes, those to 0.9.8 > are invasive. So I believe this better stays out of an already > released distribution. > > And then, you can always run Rawhide. It has 0.9.8. And has had it for > quite a while. You could drop 0.9.8 into F8 updates-testing, and let people chew on it, without making a firm commitment to actually release the package to updates. In reality a lot of the specifics on how pulseaudio updating should work is up to you. Whatever you do just try to be self-consistent about it. You could even recruit a co-maintainer to help with release updates if you personally want to focus primarily on devel branch in the future. -jef From lordmorgul at gmail.com Fri Jan 11 06:36:40 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Thu, 10 Jan 2008 22:36:40 -0800 Subject: Init : someone could comment this ? In-Reply-To: <4786A63B.1070404@gmail.com> References: <1199880879.5534.210.camel@beck.corsepiu.local> <7f692fec0801090539y4f8aa894i1ace29ab884aa994@mail.gmail.com> <200801091406.m09E6dOe013547@laptop13.inf.utfsm.cl> <47852FB8.6060603@gmail.com> <4785355F.5060302@gmail.com> <47854594.7070205@gmail.com> <47854C7B.2000303@wolves.durham.nc.us> <20080109234605.GB16506@tango.0pointer.de> <1199954992.18322.83.camel@vespa.frost.loc> <1199996516.18076.118.camel@code.and.org> <20080110203239.GA26570@tango.0pointer.de> <4786A63B.1070404@gmail.com> Message-ID: <47870E78.2070505@gmail.com> Les Mikesell wrote: > Lennart Poettering wrote: > >> Then, the reason I hacked this up was mostly to fix stuff like sudo >> and apache, which do a lookup+reverse lookup on initialization, which >> fails completely if DNS doesn't work (as in "*immediately* fail") and >> the entry is not available in /etc/hosts. DNS lookups that time out >> are a different problem. >> >>> And it still fails in the same way, when there is no network (Ie. >>> daemon can bind to a specific IP that is the "wrong" one). >> >> Hmm? >> >> Are you suggesting that there are daemons that bind on addresses by >> resolving host names? Who's doing something like that? Either daemons >> should bind on 0.0.0.0 or bind to manually configured IP >> adresses. Everything else is broken anyway. > > There are a lot of things that can't work and will do horribly wrong > things if started without a working DNS - and for reasons not related to > your own hostname. Such daemons would be better off if they could defer > startup until after DNS works. But shouldn't these things be fixed directly by identifying what goes wrong and when, and filing bugs against them upstream so that when DNS misbehaves the daemons handle it appropriately. It should never be a 'working as intended' behavior for a daemon to do things wrong just because DNS was unavailable... the daemon should postpone its operation until it can try to resolve the hostname again later, and keep doing exactly that until it works. In my view the init scripts should not have to handle that situation, but rather the daemon itself should. Defering the startup is a hack. Maybe its necessary and maybe its not, but it seems like a poor design either way. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From opensource at till.name Fri Jan 11 06:56:45 2008 From: opensource at till.name (Till Maas) Date: Fri, 11 Jan 2008 07:56:45 +0100 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <20080111000616.GC7758@tango.0pointer.de> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <47862106.2010607@redhat.com> <20080111000616.GC7758@tango.0pointer.de> Message-ID: <200801110756.50649.opensource@till.name> On Fri January 11 2008, Lennart Poettering wrote: > And then, you can always run Rawhide. It has 0.9.8. And has had it for > quite a while. Rawhide is there only for testing purposes. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From lightsolphoenix at gmail.com Fri Jan 11 08:02:34 2008 From: lightsolphoenix at gmail.com (Kelly Miller) Date: Fri, 11 Jan 2008 03:02:34 -0500 Subject: Backporting KDE4? Message-ID: <4787229A.6040706@gmail.com> Hey, since today is the official release date of KDE4, and I know it'll be going into Rawhide, I wanted to ask if there's going to be official packages for Fedora 8 to install KDE4. From kevin.kofler at chello.at Fri Jan 11 08:12:23 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 11 Jan 2008 08:12:23 +0000 (UTC) Subject: Backporting KDE4? References: <4787229A.6040706@gmail.com> Message-ID: Kelly Miller gmail.com> writes: > Hey, since today is the official release date of KDE4, and I know it'll > be going into Rawhide, I wanted to ask if there's going to be official > packages for Fedora 8 to install KDE4. Right now, no. Maybe later in kde-redhat unstable, but currently our efforts are focused on Fedora 9. Kevin Kofler From j.w.r.degoede at hhs.nl Fri Jan 11 09:21:46 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 11 Jan 2008 10:21:46 +0100 Subject: IDCC camera's & firewire juju stack In-Reply-To: <47863E82.4060307@s5r6.in-berlin.de> References: <4786340E.4060308@hhs.nl> <1199978334.28329.5.camel@aries.csail.mit.edu> <47863E82.4060307@s5r6.in-berlin.de> Message-ID: <4787352A.7020303@hhs.nl> Hi All, Thanks for all the help, I have it working now by building a 2.6.23 kernel with the patchset from here applied: http://me.in-berlin.de/~s5r6/linux1394/updates/ Then it works if I lower the number of buffer passed to dc1394_capture_setup() to 2, after also applying this patch: http://marc.info/?l=linux1394-devel&m=119965813322642 ? This is no longer needed and even coriander (from cvs) works fine! This is with a via vt6306 in OHCI 1.1 mode (which is the factory default for this pci card), should the above patches be enough to also get it to work in 1.0 mode? If that is the case I can try flashing it to 1.0 mode and see if that will also work. Regards, Hans p.s. Next step building libdc1394 and coriander packages for Fedora! From nphilipp at redhat.com Fri Jan 11 09:42:38 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 11 Jan 2008 10:42:38 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <16de708d0801100900g12dc0c1do1d406b1228b3538@mail.gmail.com> References: <4785163E.8010508@hhs.nl> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <1199982711.30858.41.camel@oneill.fubar.dk> <16de708d0801100840t61b4f1b4p2e999c07563d1030@mail.gmail.com> <1199984082.30858.56.camel@oneill.fubar.dk> <16de708d0801100900g12dc0c1do1d406b1228b3538@mail.gmail.com> Message-ID: <1200044558.20047.53.camel@gibraltar.str.redhat.com> On Thu, 2008-01-10 at 11:00 -0600, Arthur Pemberton wrote: > On Jan 10, 2008 10:54 AM, David Zeuthen wrote: > > > > On Thu, 2008-01-10 at 10:40 -0600, Arthur Pemberton wrote: > > > We are badly in need of system-config-udev. I spent several hours > > > understanding udev adn building rules for my sound cards and tv cards. > > > I hadn't done a yum update on my F7 box for weeks/months (lazyness) > > > did one this week, and it apperently just blew away my custom udev > > > config > > > > Hell no. We are in badly need of this crap just working out of the box. > > Throwing configuration / options at the problem will only make it worse. > > Trying to explain this to people is apparently impossible since people > > keep proposing stupid configuration tools with "unbreak my system" > > options. > > Most people don't need to worry about udev issues like mine, unless > MythTV with multiple video cards very popular soon The idea is that not even you should have to worry about it -- they should just work, i.e. if the hardware is present, the modules are loaded, device nodes are created and PolicyKit has a reasonable default policy for that class of hardware (e.g. "active sessions have access to the device"). My guess is that you tweaked the udev files to get access as a non-root user? In an ideal world this shouldn't be necessary, if you have to tweak things, please file a bug as well so when your modifications get overwritten (with an update) your stuff still works (hopefully). It's unfortunate that the udev rules are in /etc which conveys the (wrong) message that changes would be persistent over upgrades, but reading the thread that might get fixed. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From nphilipp at redhat.com Fri Jan 11 09:50:45 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 11 Jan 2008 10:50:45 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <16de708d0801101128r69e406d7s98260e8d1cb28564@mail.gmail.com> References: <20080109233613.GG2664@free.fr> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <1199982711.30858.41.camel@oneill.fubar.dk> <16de708d0801100840t61b4f1b4p2e999c07563d1030@mail.gmail.com> <1199984082.30858.56.camel@oneill.fubar.dk> <20080110184513.GC1055637@hiwaay.net> <1199991727.32394.3.camel@oneill.fubar.dk> <16de708d0801101128r69e406d7s98260e8d1cb28564@mail.gmail.com> Message-ID: <1200045045.20047.60.camel@gibraltar.str.redhat.com> On Thu, 2008-01-10 at 13:28 -0600, Arthur Pemberton wrote: > On Jan 10, 2008 1:02 PM, David Zeuthen wrote: > > > > On Thu, 2008-01-10 at 12:45 -0600, Chris Adams wrote: > > > And how do you know automatically that one of my USB-to-RS232 adapters > > > is my UPS (should be /dev/ups), one is my GPS (/dev/gps0), and one is a > > > cell phone (/dev/modem)? > > > > Either we look at the USB device it's hanging off (vendor, product or > > class id's), the driver or we provide a simple interface in > > gnome-device-manager or similar (including command line apps) to set it. > > You're wierd dude, this essentially the same thing I suggested and you > discouraged. I guess throwing around terms like "system-config-udev" might have gotten something different across than you meant then (sometimes you just need to spent the time to type out what you mean if you don't want people to guess ;-). A user interface to e.g. assign different serial ports to different functions are okay. GUI tools to fix broken/outdated udev rules are maybe a workaround, but not a solution. Such tools would possibly delay things getting fixed up for other users. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From nphilipp at redhat.com Fri Jan 11 09:57:20 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 11 Jan 2008 10:57:20 +0100 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <20080111033059.GB818121@hiwaay.net> References: <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <1199982711.30858.41.camel@oneill.fubar.dk> <16de708d0801100840t61b4f1b4p2e999c07563d1030@mail.gmail.com> <1199984082.30858.56.camel@oneill.fubar.dk> <20080110184513.GC1055637@hiwaay.net> <1199991727.32394.3.camel@oneill.fubar.dk> <20080111033059.GB818121@hiwaay.net> Message-ID: <1200045440.20047.67.camel@gibraltar.str.redhat.com> On Thu, 2008-01-10 at 21:30 -0600, Chris Adams wrote: > Once upon a time, David Zeuthen said: > > > > On Thu, 2008-01-10 at 12:45 -0600, Chris Adams wrote: > > > And how do you know automatically that one of my USB-to-RS232 adapters > > > is my UPS (should be /dev/ups), one is my GPS (/dev/gps0), and one is a > > > cell phone (/dev/modem)? > > > > Either we look at the USB device it's hanging off (vendor, product or > > class id's), the driver or we provide a simple interface in > > gnome-device-manager or similar (including command line apps) to set it. > > Since they are all USB-to-RS232 adapters, you can't tell anything by USB > info (they are all interfacing to RS232 devices). Two of them use the > same driver, and annoyingly, the chip vendor for that USB-to-RS232 > doesn't set a serial number, so the only way to distinguish them is via > USB port. I guess such a simple interface would tie the custom configuration of such a USB device to its hardware info and the USB path where to device is plugged. > Also, some GNOME thing is not a solution, as I'd like my UPS and GPS to > be active on boot (the GPS is used by NTP for clock sync), not some time > later after a user logs in. The resulting policy shouldn't depend on any desktop. > > That's the answer to this (very real) > > problem, not a silly program that generates udev rules. > > So then we have to have two things running trying to name devices? I > thought udev was supposed to be "the" solution. Using udev rules is > easy, it is just that writing them is beyond the point-n-click user. It might just be that the result of "a simple interface in gnome-device-manager or similar" is a bunch of udev rules (which ironically would belong into /etc instead of /lib/udev as this is the exceptional case where we talk about configuration, not working around omissions in udev rules). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From mitr at volny.cz Fri Jan 11 10:05:11 2008 From: mitr at volny.cz (Miloslav Trmac) Date: Fri, 11 Jan 2008 11:05:11 +0100 Subject: Common configuration for userhelper Message-ID: <47873F57.1020802@volny.cz> Hello, Thanks to Carlo de Wolf's patch, rawhide usermode >= 1.94 supports file inclusion. The usermode package also provides /etc/security/console.apps/config-util. If your package uses usermode to run system-wide configuration utilities, and is not special for some reason (roughly, if you include config-util in your PAM config file), please consider replacing the USER=root line in your userhelper configuration file by . config-util (that is dot, space, "config-util"). See #426095 for more information. Thank you, Mirek From lordmorgul at gmail.com Fri Jan 11 10:16:27 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Fri, 11 Jan 2008 02:16:27 -0800 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <47865662.2080701@gmail.com> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <47864F28.4030708@gmail.com> <1199984962.30858.66.camel@oneill.fubar.dk> <47865662.2080701@gmail.com> Message-ID: <478741FB.9040305@gmail.com> Les Mikesell wrote: > David Zeuthen wrote: >> On Thu, 2008-01-10 at 11:00 -0600, Les Mikesell wrote: >>> But the old names were predictable; the new ones aren't - when I move >>> a disk to a new controller/drive position, I know about it. >> >> Uhm, no. You were just relying on a) limitations in the Linux kernel to >> probe devices in a sequential fashion (see big-iron boxes with tens of >> thousands of disks why this won't work); and b) the order of your >> controllers on the PCI bus. Trying to argue it was "predictable" when it >> was a "coincidence" is an interesting spin on reality. It's also wrong; >> there's a reason that RHL and Fedora been using LABEL= for ages. > > OK, that's at least partly right but you forgot to tell me what to call > the device when creating the label for filesystems that support it - or > what name to use for access to the raw device for operations like image > copies and addition/removal from raid arrays. The underlying problem > can't be solved at the filesystem layer. Try cat /etc/mtab. The device being used for the particular label is clearly shown after its mounted, even when auto mounted by label in /etc/fstab. I fail to see what is so hidden here. When the device is connected to the machine its also identified in log messages as to which device node it is assigned. >>> What I actually would argue is that a distribution making such >>> changes should supply tools to migrate configurations based on old >>> conventions to the new ones. Maybe Fedora doesn't have users with >>> hundreds of machines and data that needs to span years of operation, >>> but a unix-like system should be designed to make that practical. >> >> No, Fedora is about being on the bleeding edge and creating a system >> where you don't *need* to migrate configuration files because the files >> will be correct if they are using stable identifiers for devices. > > I haven't found that to be the case. And I don't see any reason for > today's experimental change to end up being the one that sticks. Anaconda should have handled changing your configuration change in /etc/fstab for you at install if all your partitions were labeled. If they aren't all labeled this doesn't happen, which is a short-coming of anaconda in that it will not apply labels to FAT32 or NTFS disks that do not have them (and maybe other filesystems). There are also bugs against anaconda about this and I think a number of them are closed rawhide so it should be better now. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From mike at miketc.com Fri Jan 11 11:19:21 2008 From: mike at miketc.com (Mike Chambers) Date: Fri, 11 Jan 2008 05:19:21 -0600 Subject: Outage Notification - Fri Jan 11 05:11:26 UTC 2008 In-Reply-To: References: Message-ID: <1200050361.4191.3.camel@scrappy.miketc.com> On Thu, 2008-01-10 at 23:19 -0600, Mike McGrath wrote: > There will be an outage starting at Fri Jan 11 05:11:26 UTC 2008, which > will last approximately X hours. > > To convert UTC to your local time, take a look at > http://fedoraproject.org/wiki/Infrastructure/UTCHowto > or run: > > date -d 'Fri Jan 11 05:11:26 UTC 2008' And if below is correct, that outage already happened, at about 8 minutes *before* you sent that email. Maybe you meant Saturday morning utc? [mike at scrappy ~]$ date -d 'Fri Jan 11 05:11:26 UTC 2008' Thu Jan 10 23:11:26 CST 2008 (figured was -6 hours, was just making sure). -- Mike Chambers Madisonville, KY "The best lil town on Earth!" From triad at df.lth.se Fri Jan 11 12:44:44 2008 From: triad at df.lth.se (Linus Walleij) Date: Fri, 11 Jan 2008 13:44:44 +0100 (CET) Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <20080111000616.GC7758@tango.0pointer.de> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <20080109094532.811057b2.mschwendt.tmp0701.nospam@arcor.de> <64b14b300801090446u1412557p7bee40aa9922223d@mail.gmail.com> <1199916701.8159.2.camel@localhost.localdomain> <364d303b0801091644s7c9109a8v4b1bfe0f90427cb@mail.gmail.com> <1199964183.8159.15.camel@localhost.localdomain> <364d303b0801100437g1ed6c0b8tb7e71784e9ba3bd@mail.gmail.com> <47862106.2010607@redhat.com> <20080111000616.GC7758@tango.0pointer.de> Message-ID: On Fri, 11 Jan 2008, Lennart Poettering wrote: > My understanding is that no big updates should be pushed to released > versions, but bugfixes should. We had one exception which was the reason why libgpod and libmtp was recently upgraded along with Amarok and Rhythmbox: support for new hardware, especially if it is very popular and users start filing bugs on us about it. Linus From che666 at gmail.com Fri Jan 11 12:55:50 2008 From: che666 at gmail.com (Rudolf Kastl) Date: Fri, 11 Jan 2008 13:55:50 +0100 Subject: Init : someone could comment this ? In-Reply-To: <47870E78.2070505@gmail.com> References: <1199880879.5534.210.camel@beck.corsepiu.local> <4785355F.5060302@gmail.com> <47854594.7070205@gmail.com> <47854C7B.2000303@wolves.durham.nc.us> <20080109234605.GB16506@tango.0pointer.de> <1199954992.18322.83.camel@vespa.frost.loc> <1199996516.18076.118.camel@code.and.org> <20080110203239.GA26570@tango.0pointer.de> <4786A63B.1070404@gmail.com> <47870E78.2070505@gmail.com> Message-ID: On Jan 11, 2008 7:36 AM, Andrew Farris wrote: > Les Mikesell wrote: > > Lennart Poettering wrote: > > > >> Then, the reason I hacked this up was mostly to fix stuff like sudo > >> and apache, which do a lookup+reverse lookup on initialization, which > >> fails completely if DNS doesn't work (as in "*immediately* fail") and > >> the entry is not available in /etc/hosts. DNS lookups that time out > >> are a different problem. > >> > >>> And it still fails in the same way, when there is no network (Ie. > >>> daemon can bind to a specific IP that is the "wrong" one). > >> > >> Hmm? > >> > >> Are you suggesting that there are daemons that bind on addresses by > >> resolving host names? Who's doing something like that? Either daemons > >> should bind on 0.0.0.0 or bind to manually configured IP > >> adresses. Everything else is broken anyway. > > > > There are a lot of things that can't work and will do horribly wrong > > things if started without a working DNS - and for reasons not related to > > your own hostname. Such daemons would be better off if they could defer > > startup until after DNS works. > > But shouldn't these things be fixed directly by identifying what goes wrong and > when, and filing bugs against them upstream so that when DNS misbehaves the > daemons handle it appropriately. It should never be a 'working as intended' > behavior for a daemon to do things wrong just because DNS was unavailable... the > daemon should postpone its operation until it can try to resolve the hostname > again later, and keep doing exactly that until it works. > > In my view the init scripts should not have to handle that situation, but rather > the daemon itself should. Defering the startup is a hack. Maybe its necessary > and maybe its not, but it seems like a poor design either way. I am just generally curious... is anyone actively working on a new solution? there has been talks about init system replacements now for years and well actually lots of discussions and ideas were expressed. now i am curious about if anyone is already working on atleast a full design document how it should work and look like (besides the old one page on the wiki). there are a lot of argument why not to use the existing solutions. some are valid some arent (as it is always). but what tires me personally a bit is the fact that there is no effort beeing done besides making the existing old sysV scripts atleast behave a bit according to existing standards (they were largely unusable e.g. for clustering before and some still are e.g. due to incorrect exit codes). If something manifested yet id be happy to take a look at it... just direct me to the checkout url please. one of the things that are often managed is upstart. yet no one even found it useful enough to package it for fedora at all. sure in compat mode it is just another useless sleeping process hanging around with no real benefits to it... but still, it doesent seem to be worth the effort to roll and maintain an rpm with it for most people. there is always lots of criticism about initng. while some of the things beeing said are true... some are just myths. ... personally i can say ... it just wfm and i also wrote lots of patches for the new scripts recently... booting a system in below 15 seconds with NM and other fancy stuff enabled is quite appealing to me (especially since suspend was broken alot in the last years and at some points still is). there are various other systems aswell. most of them are directed at embedded devices.... for that sysV is just pure bloat and overhead and usually they are missing the required scripts to be properly used. but ok... not really in the scope of fedora anways (looking at the minimal install requirements). the prcsys solution to parallelize the current sys bootup does improve boot performance for me while maintaining backwards compatibility to the existing system (with the same crappy scripts that partially contain undocumented workarounds) seems to be one of the rather unintrusive ways that dont require major changes in any ways. kind regards, Rudolf Kastl > > -- > Andrew Farris > gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 > No one now has, and no one will ever again get, the big picture. - Daniel Geer > ---- ---- > > -- > > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From cjdahlin at ncsu.edu Fri Jan 11 13:43:31 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Fri, 11 Jan 2008 08:43:31 -0500 Subject: Init : someone could comment this ? In-Reply-To: References: <1199880879.5534.210.camel@beck.corsepiu.local> <4785355F.5060302@gmail.com> <47854594.7070205@gmail.com> <47854C7B.2000303@wolves.durham.nc.us> <20080109234605.GB16506@tango.0pointer.de> <1199954992.18322.83.camel@vespa.frost.loc> <1199996516.18076.118.camel@code.and.org> <20080110203239.GA26570@tango.0pointer.de> <4786A63B.1070404@gmail.com> <47870E78.2070505@gmail.com> Message-ID: <47877283.2020307@ncsu.edu> Rudolf Kastl wrote: > On Jan 11, 2008 7:36 AM, Andrew Farris wrote: > >> Les Mikesell wrote: >> >>> Lennart Poettering wrote: >>> >>> >>>> Then, the reason I hacked this up was mostly to fix stuff like sudo >>>> and apache, which do a lookup+reverse lookup on initialization, which >>>> fails completely if DNS doesn't work (as in "*immediately* fail") and >>>> the entry is not available in /etc/hosts. DNS lookups that time out >>>> are a different problem. >>>> >>>> >>>>> And it still fails in the same way, when there is no network (Ie. >>>>> daemon can bind to a specific IP that is the "wrong" one). >>>>> >>>> Hmm? >>>> >>>> Are you suggesting that there are daemons that bind on addresses by >>>> resolving host names? Who's doing something like that? Either daemons >>>> should bind on 0.0.0.0 or bind to manually configured IP >>>> adresses. Everything else is broken anyway. >>>> >>> There are a lot of things that can't work and will do horribly wrong >>> things if started without a working DNS - and for reasons not related to >>> your own hostname. Such daemons would be better off if they could defer >>> startup until after DNS works. >>> >> But shouldn't these things be fixed directly by identifying what goes wrong and >> when, and filing bugs against them upstream so that when DNS misbehaves the >> daemons handle it appropriately. It should never be a 'working as intended' >> behavior for a daemon to do things wrong just because DNS was unavailable... the >> daemon should postpone its operation until it can try to resolve the hostname >> again later, and keep doing exactly that until it works. >> >> In my view the init scripts should not have to handle that situation, but rather >> the daemon itself should. Defering the startup is a hack. Maybe its necessary >> and maybe its not, but it seems like a poor design either way. >> > > > I am just generally curious... is anyone actively working on a new > solution? there has been talks about init system replacements now for > years and well actually lots of discussions and ideas were expressed. > now i am curious about if anyone is already working on atleast a full > design document how it should work and look like (besides the old one > page on the wiki). there are a lot of argument why not to use the > existing solutions. some are valid some arent (as it is always). but > what tires me personally a bit is the fact that there is no effort > beeing done besides making the existing old sysV scripts atleast > behave a bit according to existing standards (they were largely > unusable e.g. for clustering before and some still are e.g. due to > incorrect exit codes). > If something manifested yet id be happy to take a look at it... just > direct me to the checkout url please. > > > one of the things that are often managed is upstart. yet no one even > found it useful enough to package it for fedora at all. sure in compat > mode it is just another useless sleeping process hanging around with > no real benefits to it... but still, it doesent seem to be worth the > effort to roll and maintain an rpm with it for most people. > > there is always lots of criticism about initng. while some of the > things beeing said are true... some are just myths. ... personally i > can say ... it just wfm and i also wrote lots of patches for the new > scripts recently... booting a system in below 15 seconds with NM and > other fancy stuff enabled is quite appealing to me (especially since > suspend was broken alot in the last years and at some points still > is). > > there are various other systems aswell. most of them are directed at > embedded devices.... for that sysV is just pure bloat and overhead > and usually they are missing the required scripts to be properly used. > but ok... not really in the scope of fedora anways (looking at the > minimal install requirements). > > the prcsys solution to parallelize the current sys bootup does improve > boot performance for me while maintaining backwards compatibility to > the existing system (with the same crappy scripts that partially > contain undocumented workarounds) seems to be one of the rather > unintrusive ways that dont require major changes in any ways. > > kind regards, > Rudolf Kastl > > > I'm off to the FUDCon hackfest now. I'm thinking about getting some people together to try to package Upstart. The prcsys solution seems to have benefits now, but in the long run it isn't going to give us things like service management, which we should be interested in, and it may not give us much of a speedup (theres been some suggestion that parallelizing scripts ends up not being much of a bonus). >> -- >> Andrew Farris >> gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 >> No one now has, and no one will ever again get, the big picture. - Daniel Geer >> ---- ---- >> >> -- >> >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> >> > > From rdieter at math.unl.edu Fri Jan 11 14:41:29 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 11 Jan 2008 08:41:29 -0600 Subject: Backporting KDE4? References: <4787229A.6040706@gmail.com> Message-ID: Kevin Kofler wrote: > Kelly Miller gmail.com> writes: >> Hey, since today is the official release date of KDE4, and I know it'll >> be going into Rawhide, I wanted to ask if there's going to be official >> packages for Fedora 8 to install KDE4. > > Right now, no. Maybe later in kde-redhat unstable, but currently our > efforts are focused on Fedora 9. That said, there are kde4 development platform updates queue'd for F-7,F-8. -- Rex From jakub.rusinek at gmail.com Fri Jan 11 13:53:24 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Fri, 11 Jan 2008 14:53:24 +0100 Subject: pirut, pup, system-*: policykit integration Message-ID: <5e92ee3f0801110553t66315134le53985bb653984df@mail.gmail.com> hi, dbus-based authentication system is ready to use, so pirut, pup and all system-* tools should switch to use it instead of... what does they use now? -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From che666 at gmail.com Fri Jan 11 13:54:03 2008 From: che666 at gmail.com (Rudolf Kastl) Date: Fri, 11 Jan 2008 14:54:03 +0100 Subject: Init : someone could comment this ? In-Reply-To: <47877283.2020307@ncsu.edu> References: <1199880879.5534.210.camel@beck.corsepiu.local> <47854C7B.2000303@wolves.durham.nc.us> <20080109234605.GB16506@tango.0pointer.de> <1199954992.18322.83.camel@vespa.frost.loc> <1199996516.18076.118.camel@code.and.org> <20080110203239.GA26570@tango.0pointer.de> <4786A63B.1070404@gmail.com> <47870E78.2070505@gmail.com> <47877283.2020307@ncsu.edu> Message-ID: On Jan 11, 2008 2:43 PM, Casey Dahlin wrote: > > Rudolf Kastl wrote: > > On Jan 11, 2008 7:36 AM, Andrew Farris wrote: > > > >> Les Mikesell wrote: > >> > >>> Lennart Poettering wrote: > >>> > >>> > >>>> Then, the reason I hacked this up was mostly to fix stuff like sudo > >>>> and apache, which do a lookup+reverse lookup on initialization, which > >>>> fails completely if DNS doesn't work (as in "*immediately* fail") and > >>>> the entry is not available in /etc/hosts. DNS lookups that time out > >>>> are a different problem. > >>>> > >>>> > >>>>> And it still fails in the same way, when there is no network (Ie. > >>>>> daemon can bind to a specific IP that is the "wrong" one). > >>>>> > >>>> Hmm? > >>>> > >>>> Are you suggesting that there are daemons that bind on addresses by > >>>> resolving host names? Who's doing something like that? Either daemons > >>>> should bind on 0.0.0.0 or bind to manually configured IP > >>>> adresses. Everything else is broken anyway. > >>>> > >>> There are a lot of things that can't work and will do horribly wrong > >>> things if started without a working DNS - and for reasons not related to > >>> your own hostname. Such daemons would be better off if they could defer > >>> startup until after DNS works. > >>> > >> But shouldn't these things be fixed directly by identifying what goes wrong and > >> when, and filing bugs against them upstream so that when DNS misbehaves the > >> daemons handle it appropriately. It should never be a 'working as intended' > >> behavior for a daemon to do things wrong just because DNS was unavailable... the > >> daemon should postpone its operation until it can try to resolve the hostname > >> again later, and keep doing exactly that until it works. > >> > >> In my view the init scripts should not have to handle that situation, but rather > >> the daemon itself should. Defering the startup is a hack. Maybe its necessary > >> and maybe its not, but it seems like a poor design either way. > >> > > > > > > I am just generally curious... is anyone actively working on a new > > solution? there has been talks about init system replacements now for > > years and well actually lots of discussions and ideas were expressed. > > now i am curious about if anyone is already working on atleast a full > > design document how it should work and look like (besides the old one > > page on the wiki). there are a lot of argument why not to use the > > existing solutions. some are valid some arent (as it is always). but > > what tires me personally a bit is the fact that there is no effort > > beeing done besides making the existing old sysV scripts atleast > > behave a bit according to existing standards (they were largely > > unusable e.g. for clustering before and some still are e.g. due to > > incorrect exit codes). > > If something manifested yet id be happy to take a look at it... just > > direct me to the checkout url please. > > > > > > one of the things that are often managed is upstart. yet no one even > > found it useful enough to package it for fedora at all. sure in compat > > mode it is just another useless sleeping process hanging around with > > no real benefits to it... but still, it doesent seem to be worth the > > effort to roll and maintain an rpm with it for most people. > > > > there is always lots of criticism about initng. while some of the > > things beeing said are true... some are just myths. ... personally i > > can say ... it just wfm and i also wrote lots of patches for the new > > scripts recently... booting a system in below 15 seconds with NM and > > other fancy stuff enabled is quite appealing to me (especially since > > suspend was broken alot in the last years and at some points still > > is). > > > > there are various other systems aswell. most of them are directed at > > embedded devices.... for that sysV is just pure bloat and overhead > > and usually they are missing the required scripts to be properly used. > > but ok... not really in the scope of fedora anways (looking at the > > minimal install requirements). > > > > the prcsys solution to parallelize the current sys bootup does improve > > boot performance for me while maintaining backwards compatibility to > > the existing system (with the same crappy scripts that partially > > contain undocumented workarounds) seems to be one of the rather > > unintrusive ways that dont require major changes in any ways. > > > > kind regards, > > Rudolf Kastl > > > > > > > I'm off to the FUDCon hackfest now. I'm thinking about getting some > people together to try to package Upstart. > > The prcsys solution seems to have benefits now, but in the long run it > isn't going to give us things like service management, which we should > be interested in, and it may not give us much of a speedup (theres been > some suggestion that parallelizing scripts ends up not being much of a > bonus). I fully agree with you. I just tried to point out a small overview of what is already available and what is going on actually. of course with obviously my personal opinion attached to it. If you want help packaging upstart... i can definitely help there. just talking without doing anything about the issues or atleast offering help or atleast valuable input would be somewhat cheap ;). kind regards, Rudolf Kastl > >> -- > >> Andrew Farris > >> gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 > >> No one now has, and no one will ever again get, the big picture. - Daniel Geer > >> ---- ---- > >> > >> -- > >> > >> fedora-devel-list mailing list > >> fedora-devel-list at redhat.com > >> https://www.redhat.com/mailman/listinfo/fedora-devel-list > >> > >> > > > > > > -- > > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From mmcgrath at redhat.com Fri Jan 11 14:01:47 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 11 Jan 2008 08:01:47 -0600 (CST) Subject: Outage Notification - Fri Jan 11 05:11:26 UTC 2008 In-Reply-To: <1200050361.4191.3.camel@scrappy.miketc.com> References: <1200050361.4191.3.camel@scrappy.miketc.com> Message-ID: On Fri, 11 Jan 2008, Mike Chambers wrote: > On Thu, 2008-01-10 at 23:19 -0600, Mike McGrath wrote: > > There will be an outage starting at Fri Jan 11 05:11:26 UTC 2008, which > > will last approximately X hours. > > > > To convert UTC to your local time, take a look at > > http://fedoraproject.org/wiki/Infrastructure/UTCHowto > > or run: > > > > date -d 'Fri Jan 11 05:11:26 UTC 2008' > > And if below is correct, that outage already happened, at about 8 > minutes *before* you sent that email. Maybe you meant Saturday morning > utc? > > [mike at scrappy ~]$ date -d 'Fri Jan 11 05:11:26 UTC 2008' > Thu Jan 10 23:11:26 CST 2008 (figured was -6 hours, was just making > sure). The outage was going on as I sent the email and there might be another one pending soon. -Mike From linville at redhat.com Fri Jan 11 14:06:52 2008 From: linville at redhat.com (John W. Linville) Date: Fri, 11 Jan 2008 09:06:52 -0500 Subject: Regarding FUDCon's Friday Hackfest In-Reply-To: References: Message-ID: <20080111140652.GA5953@redhat.com> On Wed, Jan 09, 2008 at 09:41:27AM -0500, Max Spevack wrote: > This is kind of amusing.... so the Friday hackfests for FUDCon are at > the "State Club" which is on NCSU's campus. It's a really nice building > with meeting rooms, a very nice lunch that you will partake in, etc. > You'll love it, really. > > Turns out though, that there is a "no jeans, no shorts" dress code. So > for all of you hackers -- bring a pair of khakis with you. If you > wanted to wear a polo shirt, that would really knock their socks off. > :) Not amusing at all, really. Ridiculous is a better word. Did this really get sent on Wednesday? The mail headers say Friday, which is a bit late for notification of a dress policy. I "only" live 45 miles away -- what about those who traveled much farther without realizing the need for special attire? Don't be surprised if you don't see me. John -- John W. Linville linville at redhat.com From lesmikesell at gmail.com Fri Jan 11 14:14:10 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 11 Jan 2008 08:14:10 -0600 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <478741FB.9040305@gmail.com> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <47864F28.4030708@gmail.com> <1199984962.30858.66.camel@oneill.fubar.dk> <47865662.2080701@gmail.com> <478741FB.9040305@gmail.com> Message-ID: <478779B2.5000706@gmail.com> Andrew Farris wrote: >> >> OK, that's at least partly right but you forgot to tell me what to >> call the device when creating the label for filesystems that support >> it - or what name to use for access to the raw device for operations >> like image copies and addition/removal from raid arrays. The >> underlying problem can't be solved at the filesystem layer. > > Try cat /etc/mtab. The device being used for the particular label is > clearly shown after its mounted, even when auto mounted by label in > /etc/fstab. I fail to see what is so hidden here. When the device is > connected to the machine its also identified in log messages as to which > device node it is assigned. Am I not making it clear that I want to be able to add and move disks that may or may not have a linux filesystem on them? You know, things that a unix-like operating system is supposed to let you do in some deterministic manner. I want the disks to work in dual-boot scenarios with earlier/later versions of linux. I want to be able to duplicate disks by copying the raw device or even raid-mirroring then failing and removing the device. >>> No, Fedora is about being on the bleeding edge and creating a system >>> where you don't *need* to migrate configuration files because the files >>> will be correct if they are using stable identifiers for devices. >> >> I haven't found that to be the case. And I don't see any reason for >> today's experimental change to end up being the one that sticks. > > Anaconda should have handled changing your configuration change in > /etc/fstab for you at install if all your partitions were labeled. When does anaconda run? I want to be able to install an OS, then add disks or move them. Right now a machine by my desktop has 2 scsi and 8 sata drives in hot-swap bays plus an assortment of pluggable firewire and USB external drives, and only the scsi pair were installed when anaconda ran. I'd much, much prefer that the raw devices for the swappable bays always had fixed device names for the drive inserted by position regardless of insertion order but I realize that's not likely to happen, so I'll settle for a reasonable description of how to figure out the right name for a newly inserted drive with the understanding that it may not have a filesystem lable and I may not want to mount it. At the moment, the most likely thing I'd want to do is add a partition from a newly inserted disk to an existing md array, but at some point in the setup (and not while anaconda is running...) it is necessary to partition and build the arrays out of a bunch of disks that mostly look the same. Is fedora suitable for jobs like this? > If > they aren't all labeled this doesn't happen, which is a short-coming of > anaconda in that it will not apply labels to FAT32 or NTFS disks that do > not have them (and maybe other filesystems). There are also bugs > against anaconda about this and I think a number of them are closed > rawhide so it should be better now. Anaconda isn't the solution unless I can run it anytime new unpartitioned devices are added or if I want something on the device other than a typical file system. -- Les Mikesell lesmikesell at gmail.com From mcepl at redhat.com Fri Jan 11 14:11:57 2008 From: mcepl at redhat.com (Matej Cepl) Date: Fri, 11 Jan 2008 15:11:57 +0100 Subject: use defoma in fedora? References: <20080110194622.GF2638@free.fr> <20080110200431.GG2638@free.fr> Message-ID: On 2008-01-10, 20:04 GMT, Patrice Dumas wrote: > Hum I wouldn't have expected the X server to have anything to > do with defoma. At least it is certainly unuseful in fedora. > I would see it useful for postrscript and type1 fonts. What's wrong with fontconfig? Besides, of course, that defoma has (in Debian) all to do with X server (which can use Type1 fonts pretty well, thank you). Mat?j From jwilson at redhat.com Fri Jan 11 14:26:39 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 11 Jan 2008 09:26:39 -0500 Subject: [libdc] IDCC camera's & firewire juju stack In-Reply-To: <47873A60.8030606@s5r6.in-berlin.de> References: <4786340E.4060308@hhs.nl> <1199978334.28329.5.camel@aries.csail.mit.edu> <47863E82.4060307@s5r6.in-berlin.de> <4787352A.7020303@hhs.nl> <47873A60.8030606@s5r6.in-berlin.de> Message-ID: <47877C9F.5000305@redhat.com> Stefan Richter wrote: > Hans de Goede wrote: >> Thanks for all the help, I have it working now by building a 2.6.23 kernel with >> the patchset from here applied: >> http://me.in-berlin.de/~s5r6/linux1394/updates/ >> >> Then it works if I lower the number of buffer passed to dc1394_capture_setup() >> to 2, after also applying this patch: >> http://marc.info/?l=linux1394-devel&m=119965813322642 ? >> >> This is no longer needed and even coriander (from cvs) works fine! >> >> This is with a via vt6306 in OHCI 1.1 mode (which is the factory default for >> this pci card), should the above patches be enough to also get it to work in >> 1.0 mode? If that is the case I can try flashing it to 1.0 mode and see if that >> will also work. I can take care of testing on an VT6306 OHCI 1.0 controller, as well as a VT6307 OHCI 1.0 controller. Just bumping to the latest linux1394 git code wasn't enough to get dv capture working (via dvgrab) on one of my VT6307 1.0 controllers, but I'm about to give it a go with the addition of David's dynamic buffer allocation patch. > No, according to what several people saw with VT630x in OHCI 1.0 mode, > there is still the bug that the DMA program stops after receiving one or > a few frames. This is 100% reproducible with coriander + IIDC camera > and dvgrab + DV camcorder. > https://bugzilla.redhat.com/show_bug.cgi?id=415841 > > As far as I understood, this presumably happens because the problem > which David Moore addressed with "fw-ohci: Fix for dualbuffer > three-or-more buffers" is also present but unfixed in the > packet-per-buffer code. I can probably get a similar fix added on top of the packet-per-buffer code today, if it is indeed still needed. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From mcepl at redhat.com Fri Jan 11 14:22:56 2008 From: mcepl at redhat.com (Matej Cepl) Date: Fri, 11 Jan 2008 15:22:56 +0100 Subject: Pulse Audio 0.9.8 - upgrade? References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <20080109094532.811057b2.mschwendt.tmp0701.nospam@arcor.de> <64b14b300801090446u1412557p7bee40aa9922223d@mail.gmail.com> <1199916701.8159.2.camel@localhost.localdomain> <364d303b0801091644s7c9109a8v4b1bfe0f90427cb@mail.gmail.com> <1199964183.8159.15.camel@localhost.localdomain> <364d303b0801100437g1ed6c0b8tb7e71784e9ba3bd@mail.gmail.com> <47862106.2010607@redhat.com> <20080111000616.GC7758@tango.0pointer.de> Message-ID: <0nak55xdiv.ln2@ppp1053.in.ipex.cz> On 2008-01-11, 00:06 GMT, Lennart Poettering wrote: > (I used to follow Debian > before I joined RH, and their policy is very strict on this stuff, and > I believe that makes sense). Me too (I was Debian-user until I came to Red Hat), so I am now what you are talking about, but Red Hat is not Debian, and (especially) Fedora is not RHEL. Fedora (even non-Rawhide) is meant as a developers' distro, and people who run production servers on it are doing it against the best judgement of community (IMHO). Given that PA is still in pretty steep development curve (judging by what I experience in Rawhide), I would be all for pushing 0.9.8 to F8. Mat?j From caillon at redhat.com Fri Jan 11 14:34:06 2008 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 11 Jan 2008 15:34:06 +0100 Subject: pirut, pup, system-*: policykit integration In-Reply-To: <5e92ee3f0801110553t66315134le53985bb653984df@mail.gmail.com> References: <5e92ee3f0801110553t66315134le53985bb653984df@mail.gmail.com> Message-ID: <47877E5E.9090208@redhat.com> On 01/11/2008 02:53 PM, Jakub 'Livio' Rusinek wrote: > dbus-based authentication system is ready to use, so pirut, pup and all > system-* tools should switch to use it instead of... what does they use now? /usr/bin/consolehelper From jakub.rusinek at gmail.com Fri Jan 11 14:46:39 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Fri, 11 Jan 2008 15:46:39 +0100 Subject: pirut, pup, system-*: policykit integration In-Reply-To: <47877E5E.9090208@redhat.com> References: <5e92ee3f0801110553t66315134le53985bb653984df@mail.gmail.com> <47877E5E.9090208@redhat.com> Message-ID: <5e92ee3f0801110646p79ef49dejc02b7def1bfa86e@mail.gmail.com> 2008/1/11, Christopher Aillon : > > On 01/11/2008 02:53 PM, Jakub 'Livio' Rusinek wrote: > > dbus-based authentication system is ready to use, so pirut, pup and all > > system-* tools should switch to use it instead of... what does they use > now? > > /usr/bin/consolehelper > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Ok, so now it's time to move. Mass move :> . Working upstream on well used (in future) project is good idea. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pertusus at free.fr Fri Jan 11 15:03:46 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 11 Jan 2008 16:03:46 +0100 Subject: use defoma in fedora? In-Reply-To: References: <20080110194622.GF2638@free.fr> <20080110200431.GG2638@free.fr> Message-ID: <20080111150346.GA2575@free.fr> On Fri, Jan 11, 2008 at 03:11:57PM +0100, Matej Cepl wrote: > On 2008-01-10, 20:04 GMT, Patrice Dumas wrote: > > Hum I wouldn't have expected the X server to have anything to > > do with defoma. At least it is certainly unuseful in fedora. > > I would see it useful for postrscript and type1 fonts. > > What's wrong with fontconfig? Nothing. But it seems to me that the applications I cited, grace, xglyph and xdvi don't use fontconfig. > Besides, of course, that defoma has > (in Debian) all to do with X server (which can use Type1 fonts > pretty well, thank you). But in fedora there is no need for something along defoma to have the X server using Type1 fonts. I think that using something along defoma would be useful for packages that don't use fontconfig and still have a way to use a list of fonts. So it wouldn't be for X, gnome/kde/openoffice, but for other applications that don't use fontconfig. It may also happen that it would be better to port t1lib to use fontconfig to find the font files. -- Pat From bernie at codewiz.org Fri Jan 11 15:04:25 2008 From: bernie at codewiz.org (Bernardo Innocenti) Date: Fri, 11 Jan 2008 10:04:25 -0500 Subject: [OLPC devel] su/sudo or not to sudo/su (was PATCH: add --loginpause to mingetty) In-Reply-To: <47872D41.0@schampijer.de> References: <52bb973e0801101537x3f00d67ard5b914b459ca390f@mail.gmail.com> <20862be60801101918v5dd124f4n58bccd7a63ad391c@mail.gmail.com> <47872D41.0@schampijer.de> Message-ID: <47878579.1030303@codewiz.org> Simon Schampijer wrote: > does not auto-complete. The bash-completion (141K) package solves this, > which I tried on my F8 machine. Maybe worth an inclusion since the > completion works as well for other cases like: > > yum in[tab] > > (even so in the case of 'yum install b[tab]' it takes a while to list > the packages). I love bash-completion and I use it everywhere, but I'd not support adding it to the base OS for the same reason we do not install vim-enhanced, links, lftp and all the other nice console tools. The default console environment should be just good enough to perform system recovery, and special administrative tasks which have no UI yet. Our OS images have grown over 300MB! I think we could get them back to 200MB or so just by dropping useless dependencies and splitting a few packages. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ From dwalsh at redhat.com Fri Jan 11 15:05:41 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 11 Jan 2008 10:05:41 -0500 Subject: selinux rant, compressed version (Was Re: kernels won't boot) In-Reply-To: <1199400411.3251.7.camel@oneill.fubar.dk> References: <200712221216.lBMCGW8U004528@porkchop.devel.redhat.com> <200712220828.48202.sgrubb@redhat.com> <1199385283.2850.1.camel@oneill.fubar.dk> <477D3178.9020108@redhat.com> <1199387293.3716.39.camel@localhost.localdomain> <1199387346.2850.24.camel@oneill.fubar.dk> <1199389522.4670.95.camel@dimi.lattica.com> <1199393006.10354.16.camel@oneill.fubar.dk> <477D5CA5.7030401@redhat.com> <1199400411.3251.7.camel@oneill.fubar.dk> Message-ID: <478785C5.60701@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Zeuthen wrote: > On Thu, 2008-01-03 at 17:07 -0500, Daniel J Walsh wrote: >> Well there are several problems with allowing the individual maintainers >> manage their own policy. >> >> #1 they won't. >> #2 when they do, they do a very bad job of it. Or basically just end up >> with unconfined_t. >> #3 The tools are too slow. Having 100 semodule -i will cause the >> installation to take for ever. >> #4 Interaction between confined domains does not work well when multiple >> maintainers writing policy. >> sendmail, procmail, spamassassin, clamav, postfix, qmail, mailserver, >> pyzor ... All interact in very complex ways. >> #5 conflicts on file_context directories/files > > See.. cause and effect.. #1 and #2 are the effects of #3 and the fact > that the policy is way too big and the whole system is way too > complicated. > > Besides.. I have asked probably more than ten times (both electronically > and in person) about maintaining the selinux policy for hal in the > _upstream_ tarball but I've always been told that it's not possible or > I've been told to wait. In the meantime it's business as usual; things > are broken and people turn off SELinux. > > Here's a challenge: Send me a patch against the hal git repo and the > RPM spec with the SELinux bits... Then I'll be happy to maintain it; > including spending time on learning SELinux well enough to do a good > job. Is this even possible? Should it be possible? > >> David, You are writing an application that is trying to do things on >> behalf of the user as root. These activities will cause conflicts and >> need to be well controlled. So you are likely to run into problems with >> SELinux. > > Sigh. Do you really honestly think this is a good answer for upstream > maintainers that are _willing_ to help? > > David > > I have build a spec file and included the current rawhide sources for both policy kit and hal. As soon as you are ready to ship them I will move them to update status in the selinux-policy package. If you need help building the policy or writing policy, please you know how to reach me. :^) If other maintainers are interested in shipping their own policy, I will make it available. Dan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkeHhcQACgkQrlYvE4MpobNGwACgnBukrbuALtgu8/M3Uy1gB3Y4 SrkAn0kM5y0IeGosdRrs9JoTebino+Px =H2NC -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: hal-policy.tgz Type: application/x-compressed-tar Size: 5489 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hal-policy.tgz.sig Type: application/octet-stream Size: 72 bytes Desc: not available URL: From paul at all-the-johnsons.co.uk Fri Jan 11 15:19:50 2008 From: paul at all-the-johnsons.co.uk (paul) Date: Fri, 11 Jan 2008 15:19:50 +0000 Subject: Getting a SIS900 chipset to work Message-ID: <1200064790.27279.5.camel@T7.Linux> Hi, I've just moved from FC6 to rawhide on the laptop and while most things are OK, the xorg-x11 stuff for the SIS900 chipset seems to be broken. I've looked on the lists and this was reported around the end of last year with the advice to change the config to use the vesa driver. While this works, it's making the laptop run dog slow. Any ideas when it'll be up and running again? TTFN Paul From jwilson at redhat.com Fri Jan 11 15:23:22 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 11 Jan 2008 10:23:22 -0500 Subject: thinkpad-acpi upstream version? In-Reply-To: <1200010908.20425.6.camel@vincent52.localdomain> References: <47852A26.4010609@fedoraproject.org> <364d303b0801091641y763baef2y12a95bde37547c42@mail.gmail.com> <47866320.1040606@redhat.com> <4786653C.5020204@fedoraproject.org> <47868933.6060008@redhat.com> <1200010908.20425.6.camel@vincent52.localdomain> Message-ID: <478789EA.50302@redhat.com> Matthew Saltzman wrote: > On Thu, 2008-01-10 at 16:08 -0500, Jarod Wilson wrote: >> Nicolas Antonio Corrarello wrote: >>> Maybe you're in the same condition as I am (Also T61 user, great >>> machine)... Can't make the volume >>> up/down keys to work, and I can't change the volume through >>> /proc/acpi/ibm/volume. I'll see if this is solved in the thinkpad-acpi >>> changelog and file a bug... >> Ah yes, mine has the same issue with 2.6.23.12 right now, forgot about that. >> Heck, *I* should have filed a bug already... But I'll let you. :) >> >> Also, the brightness keys don't do anything on mine, though that may be >> resolved in rawhide via xbacklight, iirc. Rawhide was a bit too explodey for >> me to want to upgrade to it just yet though. > > Which video driver? Intel X3100 graphics, 1680x1050 display, intel video driver. > Does yours suspend properly? Yep, though I did have to add my model # to the proper hal quirks file. Prior to that, it would often resume to a black screen (though I could get a console back via ctrl-alt-f1 then alt-f7 and X would be back). Now, its flawless, and gets me straight to the gnome unlock dialog within a few seconds. Still not nearly as fast as Mac OS X resumes on my 3 year old PowerBook G4, but still pretty damned good. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jonstanley at gmail.com Fri Jan 11 15:31:44 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Fri, 11 Jan 2008 10:31:44 -0500 Subject: Regarding FUDCon's Friday Hackfest In-Reply-To: <20080111140652.GA5953@redhat.com> References: <20080111140652.GA5953@redhat.com> Message-ID: On Jan 11, 2008 9:06 AM, John W. Linville wrote: > Did this really get sent on Wednesday? The mail headers say Friday, > which is a bit late for notification of a dress policy. Yes, I received it on Wednesday. I agree that today would have been a little late :) I'm not going today either, as there's no value that I could add (and my flight isn't til later this evening) :) But see everyone tomorrow! :) From jkeating at redhat.com Fri Jan 11 15:32:25 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 11 Jan 2008 10:32:25 -0500 Subject: Regarding FUDCon's Friday Hackfest In-Reply-To: <20080111140652.GA5953@redhat.com> References: <20080111140652.GA5953@redhat.com> Message-ID: <20080111103225.28a99d99@redhat.com> On Fri, 11 Jan 2008 09:06:52 -0500 "John W. Linville" wrote: > Not amusing at all, really. Ridiculous is a better word. > > Did this really get sent on Wednesday? The mail headers say Friday, > which is a bit late for notification of a dress policy. > > I "only" live 45 miles away -- what about those who traveled much > farther without realizing the need for special attire? > > Don't be surprised if you don't see me. Turns out they didn't enforce this. I'm sitting at the hack fest in my jeans. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwilson at redhat.com Fri Jan 11 15:41:26 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 11 Jan 2008 10:41:26 -0500 Subject: [libdc] IDCC camera's & firewire juju stack In-Reply-To: <1200065320.18669.15.camel@pisces.mit.edu> References: <4786340E.4060308@hhs.nl> <1199978334.28329.5.camel@aries.csail.mit.edu> <47863E82.4060307@s5r6.in-berlin.de> <4787352A.7020303@hhs.nl> <47873A60.8030606@s5r6.in-berlin.de> <1200065320.18669.15.camel@pisces.mit.edu> Message-ID: <47878E26.7010507@redhat.com> David Moore wrote: > On Fri, 2008-01-11 at 10:44 +0100, Stefan Richter wrote: >> No, according to what several people saw with VT630x in OHCI 1.0 mode, >> there is still the bug that the DMA program stops after receiving one or >> a few frames. This is 100% reproducible with coriander + IIDC camera >> and dvgrab + DV camcorder. >> https://bugzilla.redhat.com/show_bug.cgi?id=415841 >> >> As far as I understood, this presumably happens because the problem >> which David Moore addressed with "fw-ohci: Fix for dualbuffer >> three-or-more buffers" is also present but unfixed in the >> packet-per-buffer code. > > I thought I had fixed that in my "fw-ohci: Bug fixes for > packet-per-buffer support" patch That's what I was thinking/hoping, but... > but maybe it's still not working perfectly yet. ...I still can't get more than 1 or 2 frames of dv w/the OHCI 1.0 VT6307 I'm working with right now. :( > I'm running out of ideas for why that still might not > work so further testing or insights would be appreciated. I'm rather short on ideas too. I was really hoping the dynamic buffer allocation patch might help too, thinking maybe these cards were just exhausting the buffer and getting wedged, but no dice. Oh, I should also mention that I get some lockdep spew w/the dynamic buffer alloc patch added to the mix... (will get that report over to you via linux1394-devel though) -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jkeating at redhat.com Fri Jan 11 15:42:58 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 11 Jan 2008 10:42:58 -0500 Subject: Regarding FUDCon's Friday Hackfest In-Reply-To: References: <20080111140652.GA5953@redhat.com> Message-ID: <20080111104258.1ed92b5c@redhat.com> On Fri, 11 Jan 2008 10:31:44 -0500 "Jon Stanley" wrote: > Yes, I received it on Wednesday. I agree that today would have been a > little late :) I'm not going today either, as there's no value that I > could add (and my flight isn't til later this evening) :) But see > everyone tomorrow! :) We tried to start a bug triage session today... Guess we'll do it Sunday. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jeff at ocjtech.us Fri Jan 11 15:47:28 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Fri, 11 Jan 2008 09:47:28 -0600 Subject: Regarding FUDCon's Friday Hackfest In-Reply-To: <20080111140652.GA5953@redhat.com> References: <20080111140652.GA5953@redhat.com> Message-ID: <935ead450801110747v24704758m4ab4efd7b6673c15@mail.gmail.com> On 1/11/08, John W. Linville wrote: > > Did this really get sent on Wednesday? The mail headers say Friday, > which is a bit late for notification of a dress policy. Seems like the message got stuck in a queue at RH for a couple of days: Received: from hormel.redhat.com (hormel.redhat.com [209.132.177.30]) by mx.google.com with ESMTP id b45si2679968hsa.18.2008.01.10.21.25.19; Thu, 10 Jan 2008 21:25:20 -0800 (PST) Received: from listman.util.phx.redhat.com (listman.util.phx.redhat.com [10.8.4.110]) by hormel.redhat.com (Postfix) with ESMTP id 1C09C72E44; Fri, 11 Jan 2008 00:25:18 -0500 (EST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by listman.util.phx.redhat.com (8.13.1/8.13.1) with ESMTP id m09EgBSG017436 for ; Wed, 9 Jan 2008 09:42:12 -0500 Jeff From skasal at redhat.com Fri Jan 11 16:21:04 2008 From: skasal at redhat.com (Stepan Kasal) Date: Fri, 11 Jan 2008 17:21:04 +0100 Subject: autoconf issue using -stdc=gnu++0x option in AC_CHECK_HEADER macro. In-Reply-To: <47865A26.8030704@herr-schmitt.de> References: <4786521B.8050002@herr-schmitt.de> <47865A26.8030704@herr-schmitt.de> Message-ID: <20080111162104.GA5052@camelia.ucw.cz> Hello, On Thu, Jan 10, 2008 at 06:47:18PM +0100, Jochen Schmitt wrote: > Kevin Kofler schrieb: > > Add it to the CXXFLAGS, you'll need it there anyway when actually > > building the program. I believe there's also a macro to check the > > existence of the flag, which will add it to the CXXFLAGS > > automatically if the test succeeds. > > > That was the first thing what I have tried to do after I have > recognized this issue, but autoconf > doesn't honor this settings when AC_CHECK_HEADER call the g++ compiler for > compiling the test program. Autoconf checks for features of a compiler. To do this, it has to know which programming language is the compiler supposed to compile. This is why you have to specify the language using AC_LANG or AC_LANG_PUSH/POP. See http://www.gnu.org/software/autoconf/manual/html_node/Language-Choice.html The default language is C, thus people using C exclusively need not know about the language selection. But as soon as you use a different language, e.g. Erlang, Fortran, or C++, you have to keep this in mind. (Using CC=g++ says "my C compiler is named g++" which is not usually true.) And yes, Autoconf uses CXXFLAGS instead of CFLAGS when checking for C++ features. Hope this helps, Stepan Kasal From ivazqueznet at gmail.com Fri Jan 11 16:24:35 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 11 Jan 2008 11:24:35 -0500 Subject: pirut, pup, system-*: policykit integration In-Reply-To: <5e92ee3f0801110646p79ef49dejc02b7def1bfa86e@mail.gmail.com> References: <5e92ee3f0801110553t66315134le53985bb653984df@mail.gmail.com> <47877E5E.9090208@redhat.com> <5e92ee3f0801110646p79ef49dejc02b7def1bfa86e@mail.gmail.com> Message-ID: <1200068675.5098.20.camel@ignacio.lan> On Fri, 2008-01-11 at 15:46 +0100, Jakub 'Livio' Rusinek wrote: > 2008/1/11, Christopher Aillon : > On 01/11/2008 02:53 PM, Jakub 'Livio' Rusinek wrote: > > dbus-based authentication system is ready to use, so pirut, > pup and all > > system-* tools should switch to use it instead of... what > does they use now? > > /usr/bin/consolehelper > > Ok, so now it's time to move. Mass move :> . Have you logged bugs yet? -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skasal at redhat.com Fri Jan 11 16:47:18 2008 From: skasal at redhat.com (Stepan Kasal) Date: Fri, 11 Jan 2008 17:47:18 +0100 Subject: ctrlproxy In-Reply-To: <47865B66.7090803@codewiz.org> References: <4783B191.50104@codewiz.org> <20080108121210.35266172@zod.rchland.ibm.com> <4784DC7D.1050603@codewiz.org> <20080110074547.785a7b61@zod.rchland.ibm.com> <47865B66.7090803@codewiz.org> Message-ID: <20080111164718.GA5282@camelia.ucw.cz> Hello, On Thu, Jan 10, 2008 at 12:52:38PM -0500, Bernardo Innocenti wrote: > Josh Boyer wrote: > > By chance do you have it running under a different locale? > > Yes: to speedup boot, I have commented out the "LANG=..." line > in my /etc/sysconfig/i18n. As a result, all daemons run with > the C locale. I have LANG=en_US.UTF-8 in my ~/.i18n. > > Too bad there's no C.UTF-8 in glibc. It should be the default :-) I believe the right content of /etc/sysconfig/i18n is: LC_CTYPE=en_GB.UTF-8 AFAIK, it does what one would expect from LANG=C.UTF-8. And yes, it is confusing that C.UTF-8 does not exist. If it existed, I would probably have switched to Unicode a few years earlier. Stepan From mclasen at redhat.com Fri Jan 11 16:52:24 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 11 Jan 2008 11:52:24 -0500 Subject: pirut, pup, system-*: policykit integration In-Reply-To: <5e92ee3f0801110553t66315134le53985bb653984df@mail.gmail.com> References: <5e92ee3f0801110553t66315134le53985bb653984df@mail.gmail.com> Message-ID: <1200070344.2829.5.camel@localhost.localdomain> On Fri, 2008-01-11 at 14:53 +0100, Jakub 'Livio' Rusinek wrote: > hi, > > dbus-based authentication system is ready to use, so pirut, pup and > all system-* tools should switch to use it instead of... what does > they use now? Wrt to pup and pirut, we are working on making PackageKit good enough to replace them (at least in the desktop spin). PackageKit is using dbus activation and PolicyKit. Wrt to system config tools, one option would be for someone to investigate gnome-system-tools (at least, get it to work and package it for Fedora, for trying it out), which is also using these technologies. From cra at WPI.EDU Fri Jan 11 16:53:11 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 11 Jan 2008 11:53:11 -0500 Subject: thinkpad-acpi upstream version? In-Reply-To: <478789EA.50302@redhat.com> References: <47852A26.4010609@fedoraproject.org> <364d303b0801091641y763baef2y12a95bde37547c42@mail.gmail.com> <47866320.1040606@redhat.com> <4786653C.5020204@fedoraproject.org> <47868933.6060008@redhat.com> <1200010908.20425.6.camel@vincent52.localdomain> <478789EA.50302@redhat.com> Message-ID: <20080111165311.GU29887@angus.ind.WPI.EDU> On Fri, Jan 11, 2008 at 10:23:22AM -0500, Jarod Wilson wrote: > Matthew Saltzman wrote: > > On Thu, 2008-01-10 at 16:08 -0500, Jarod Wilson wrote: > >> Nicolas Antonio Corrarello wrote: > >>> Maybe you're in the same condition as I am (Also T61 user, great > >>> machine)... Can't make the volume > >>> up/down keys to work, and I can't change the volume through > >>> /proc/acpi/ibm/volume. I'll see if this is solved in the thinkpad-acpi > >>> changelog and file a bug... > >> Ah yes, mine has the same issue with 2.6.23.12 right now, forgot about that. > >> Heck, *I* should have filed a bug already... But I'll let you. :) > >> > >> Also, the brightness keys don't do anything on mine, though that may be > >> resolved in rawhide via xbacklight, iirc. Rawhide was a bit too explodey for > >> me to want to upgrade to it just yet though. > > > > Which video driver? > > Intel X3100 graphics, 1680x1050 display, intel video driver. On my ThinkPad T61 with Intel graphics, 1680x1050 display, my brightness keys cause the brightness on-screen display bar graph to appear, but the brightness doesn't actually change until I hit the very top of the scale, then it goes bright immediately. It also reacts very slowly to each key stroke. From pemboa at gmail.com Fri Jan 11 16:55:53 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 11 Jan 2008 10:55:53 -0600 Subject: pirut, pup, system-*: policykit integration In-Reply-To: <1200070344.2829.5.camel@localhost.localdomain> References: <5e92ee3f0801110553t66315134le53985bb653984df@mail.gmail.com> <1200070344.2829.5.camel@localhost.localdomain> Message-ID: <16de708d0801110855r3cd266beq70b768c255849a21@mail.gmail.com> On Jan 11, 2008 10:52 AM, Matthias Clasen wrote: > > On Fri, 2008-01-11 at 14:53 +0100, Jakub 'Livio' Rusinek wrote: > > hi, > > > > dbus-based authentication system is ready to use, so pirut, pup and > > all system-* tools should switch to use it instead of... what does > > they use now? > > > Wrt to pup and pirut, we are working on making PackageKit good enough to > replace them (at least in the desktop spin). PackageKit is using dbus > activation and PolicyKit. > > Wrt to system config tools, one option would be for someone to > investigate gnome-system-tools (at least, get it to work and package it > for Fedora, for trying it out), which is also using these technologies. Are you suggesting making the psuedo DE agnostic system-confg tools more Gnome reliant? -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From sundaram at fedoraproject.org Fri Jan 11 17:11:05 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 11 Jan 2008 22:41:05 +0530 Subject: pirut, pup, system-*: policykit integration In-Reply-To: <16de708d0801110855r3cd266beq70b768c255849a21@mail.gmail.com> References: <5e92ee3f0801110553t66315134le53985bb653984df@mail.gmail.com> <1200070344.2829.5.camel@localhost.localdomain> <16de708d0801110855r3cd266beq70b768c255849a21@mail.gmail.com> Message-ID: <4787A329.7030402@fedoraproject.org> Arthur Pemberton wrote: > On Jan 11, 2008 10:52 AM, Matthias Clasen wrote: > >> >> Wrt to system config tools, one option would be for someone to >> investigate gnome-system-tools (at least, get it to work and package it >> for Fedora, for trying it out), which is also using these technologies. > > > Are you suggesting making the psuedo DE agnostic system-confg tools > more Gnome reliant? gnome-system-tools is entirely different from system-config-* http://www.gnome.org/projects/gst/ Rahul From mclasen at redhat.com Fri Jan 11 17:06:13 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 11 Jan 2008 12:06:13 -0500 Subject: pirut, pup, system-*: policykit integration In-Reply-To: <16de708d0801110855r3cd266beq70b768c255849a21@mail.gmail.com> References: <5e92ee3f0801110553t66315134le53985bb653984df@mail.gmail.com> <1200070344.2829.5.camel@localhost.localdomain> <16de708d0801110855r3cd266beq70b768c255849a21@mail.gmail.com> Message-ID: <1200071173.2829.12.camel@localhost.localdomain> On Fri, 2008-01-11 at 10:55 -0600, Arthur Pemberton wrote: > > > > Wrt to system config tools, one option would be for someone to > > investigate gnome-system-tools (at least, get it to work and package it > > for Fedora, for trying it out), which is also using these technologies. > > > Are you suggesting making the psuedo DE agnostic system-confg tools > more Gnome reliant? Many of the system-config tools we ship are DE agnostic only in so far as the are just plain bad UI and wouldn't be accepted as part of either DE... most of the tools have been written many years ago, without input from interface designers, and have seen very little UI love since then. (I don't mean to be rude here. This is not the fault of the respective maintainers, whose primary job is not UI programming) gnome-system-tools uses a frontend-backend split, with dbus interfaces. So if you feel like it, you should be able to write frontends using other toolkits. From braden at endoframe.com Fri Jan 11 17:16:14 2008 From: braden at endoframe.com (Braden McDaniel) Date: Fri, 11 Jan 2008 12:16:14 -0500 Subject: "not tagged with dist-f8-updates-candidate" Message-ID: <1200071774.5278.230.camel@hinge.endoframe.net> When I attempt to edit this update: https://admin.fedoraproject.org/updates/F8/pending/openvrml-0.17.2-1.fc8 ... I get a message: openvrml-0.17.2-1.fc8 not tagged with dist-f8-updates-candidate What does this mean, exactly? (In particular to why I can't edit the update.) -- Braden McDaniel e-mail: Jabber: From jwilson at redhat.com Fri Jan 11 17:21:45 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 11 Jan 2008 12:21:45 -0500 Subject: [libdc] IDCC camera's & firewire juju stack In-Reply-To: <47878E26.7010507@redhat.com> References: <4786340E.4060308@hhs.nl> <1199978334.28329.5.camel@aries.csail.mit.edu> <47863E82.4060307@s5r6.in-berlin.de> <4787352A.7020303@hhs.nl> <47873A60.8030606@s5r6.in-berlin.de> <1200065320.18669.15.camel@pisces.mit.edu> <47878E26.7010507@redhat.com> Message-ID: <4787A5A9.3070405@redhat.com> Jarod Wilson wrote: > David Moore wrote: >> On Fri, 2008-01-11 at 10:44 +0100, Stefan Richter wrote: >>> No, according to what several people saw with VT630x in OHCI 1.0 mode, >>> there is still the bug that the DMA program stops after receiving one or >>> a few frames. This is 100% reproducible with coriander + IIDC camera >>> and dvgrab + DV camcorder. >>> https://bugzilla.redhat.com/show_bug.cgi?id=415841 >>> >>> As far as I understood, this presumably happens because the problem >>> which David Moore addressed with "fw-ohci: Fix for dualbuffer >>> three-or-more buffers" is also present but unfixed in the >>> packet-per-buffer code. >> I thought I had fixed that in my "fw-ohci: Bug fixes for >> packet-per-buffer support" patch > > That's what I was thinking/hoping, but... > >> but maybe it's still not working perfectly yet. > > ...I still can't get more than 1 or 2 frames of dv w/the OHCI 1.0 VT6307 I'm > working with right now. :( On the positive side, I *do* have coriander displaying video from a Unibrain Fire-i hooked to this same controller now, so the remaining problems appear to be dv-specific. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From denis at poolshark.org Fri Jan 11 17:42:14 2008 From: denis at poolshark.org (Denis Leroy) Date: Fri, 11 Jan 2008 18:42:14 +0100 Subject: thinkpad-acpi upstream version? In-Reply-To: <20080111165311.GU29887@angus.ind.WPI.EDU> References: <47852A26.4010609@fedoraproject.org> <364d303b0801091641y763baef2y12a95bde37547c42@mail.gmail.com> <47866320.1040606@redhat.com> <4786653C.5020204@fedoraproject.org> <47868933.6060008@redhat.com> <1200010908.20425.6.camel@vincent52.localdomain> <478789EA.50302@redhat.com> <20080111165311.GU29887@angus.ind.WPI.EDU> Message-ID: <4787AA76.4050105@poolshark.org> Chuck Anderson wrote: > On Fri, Jan 11, 2008 at 10:23:22AM -0500, Jarod Wilson wrote: >> Matthew Saltzman wrote: >>> On Thu, 2008-01-10 at 16:08 -0500, Jarod Wilson wrote: >>>> Nicolas Antonio Corrarello wrote: >>>>> Maybe you're in the same condition as I am (Also T61 user, great >>>>> machine)... Can't make the volume >>>>> up/down keys to work, and I can't change the volume through >>>>> /proc/acpi/ibm/volume. I'll see if this is solved in the thinkpad-acpi >>>>> changelog and file a bug... >>>> Ah yes, mine has the same issue with 2.6.23.12 right now, forgot about that. >>>> Heck, *I* should have filed a bug already... But I'll let you. :) >>>> >>>> Also, the brightness keys don't do anything on mine, though that may be >>>> resolved in rawhide via xbacklight, iirc. Rawhide was a bit too explodey for >>>> me to want to upgrade to it just yet though. >>> Which video driver? >> Intel X3100 graphics, 1680x1050 display, intel video driver. > > On my ThinkPad T61 with Intel graphics, 1680x1050 display, my > brightness keys cause the brightness on-screen display bar graph to > appear, but the brightness doesn't actually change until I hit the > very top of the scale, then it goes bright immediately. It also > reacts very slowly to each key stroke. On my T61 (Nvidia Quadro NVS-140M), suspend works, but the brightness keys and sound keys do not work. I also get the bar graph, but actual brightness doesn't change at all From opensource at till.name Fri Jan 11 17:52:02 2008 From: opensource at till.name (Till Maas) Date: Fri, 11 Jan 2008 18:52:02 +0100 Subject: Deleting a file/directory on startup Message-ID: <200801111852.08733.opensource@till.name> Hiyas, a package I comaintain (pm-utils) uses a lockfile. Because it may happen that the computer crashes when the program is used, the lockfile may be there already when no instance of pm-utils is running. Therefore the lockfile should be deleted on startup. Do I need to write an initscript for this? Which is imho not 100% correct, because this "service" should never be deactivated. Is there a directory , where one could drop a file for this? The only one I can think of would be /etc/sysconfig/modules, where ever .modules file is executed at startup. The original feature request to split up rc.sysinit in a rc.sysinit.d structure is more than five years old (which would be a good solution here), so I doubt that filing a feature request will help here. But maybe someone knows a better solution that the two I can think of. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From mjs at CLEMSON.EDU Fri Jan 11 17:53:59 2008 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Fri, 11 Jan 2008 12:53:59 -0500 Subject: thinkpad-acpi upstream version? In-Reply-To: <478789EA.50302@redhat.com> References: <47852A26.4010609@fedoraproject.org> <364d303b0801091641y763baef2y12a95bde37547c42@mail.gmail.com> <47866320.1040606@redhat.com> <4786653C.5020204@fedoraproject.org> <47868933.6060008@redhat.com> <1200010908.20425.6.camel@vincent52.localdomain> <478789EA.50302@redhat.com> Message-ID: <1200074039.28381.20.camel@vincent52.localdomain> On Fri, 2008-01-11 at 10:23 -0500, Jarod Wilson wrote: > Matthew Saltzman wrote: > > On Thu, 2008-01-10 at 16:08 -0500, Jarod Wilson wrote: > >> Nicolas Antonio Corrarello wrote: > >>> Maybe you're in the same condition as I am (Also T61 user, great > >>> machine)... Can't make the volume > >>> up/down keys to work, and I can't change the volume through > >>> /proc/acpi/ibm/volume. I'll see if this is solved in the thinkpad-acpi > >>> changelog and file a bug... > >> Ah yes, mine has the same issue with 2.6.23.12 right now, forgot about that. > >> Heck, *I* should have filed a bug already... But I'll let you. :) > >> > >> Also, the brightness keys don't do anything on mine, though that may be > >> resolved in rawhide via xbacklight, iirc. Rawhide was a bit too explodey for > >> me to want to upgrade to it just yet though. > > > > Which video driver? > > Intel X3100 graphics, 1680x1050 display, intel video driver. OK Can't help you there. For the nVidia cards, the latest binary driver fixes the brightness button issue. Buttons also work with the vesa driver, but the nv driver *still* doesn't work at all (https://bugzilla.redhat.com/show_bug.cgi?id=249367). > > > Does yours suspend properly? > > Yep, though I did have to add my model # to the proper hal quirks file. Prior > to that, it would often resume to a black screen (though I could get a console > back via ctrl-alt-f1 then alt-f7 and X would be back). Now, its flawless, and > gets me straight to the gnome unlock dialog within a few seconds. Still not > nearly as fast as Mac OS X resumes on my 3 year old PowerBook G4, but still > pretty damned good. Lucky you. Suspend issues are killing me... (https://bugzilla.redhat.com/show_bug.cgi?id=254214). > -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From buildsys at redhat.com Fri Jan 11 17:55:02 2008 From: buildsys at redhat.com (Build System) Date: Fri, 11 Jan 2008 12:55:02 -0500 Subject: rawhide report: 20080111 changes Message-ID: <200801111755.m0BHt2wY002105@porkchop.devel.redhat.com> New package diveintopython Dive into Python - a python book New package odccm Connection daemon for Pocket PC devices for Windows Mobile New package yanone-kaffeesatz-fonts Yanone Kaffeesatz decorative fonts Updated Packages: Inventor-2.1.5-31.fc9 --------------------- * Thu Jan 10 2008 Ralf Cors??pius - 2.1.5-31 - Spec file cleanup. - Introduce --with openmotif. - Add Inventor-2.1.5-30-31.diff. NetworkManager-1:0.7.0-0.8.svn3235.fc9 -------------------------------------- * Fri Jan 11 2008 Dan Williams - 1:0.7.0-0.8.svn3235 - Fix crash when activating a mobile broadband connection - Better handling of non-SSID-broadcasting APs on kernels that support it (gnome.org #464215) (rh #373841) - Honor DHCP-server provided MTU if present (gnome.org #332953) - Use previous DNS settings if the VPN concentrator doesn't provide any (gnome.org #346833) * Fri Jan 04 2008 Dan Williams - 1:0.7.0-0.8.svn3204 - Fix WPA passphrase hashing on big endian (PPC, Sparc, etc) (rh #426233) * Tue Dec 18 2007 Dan Williams - 1:0.7.0-0.8.svn3181 - Fixes to work better with new libnl (rh #401761) WebKit-1.0.0-0.4.svn29336.fc9 ----------------------------- * Wed Jan 09 2008 Peter Gordon 1.0.0-0.4.svn29336 - Update to new upstream snapshot (SVN 29336). - Drop TCSpinLock pthread workaround (fixed upstream): - TCSpinLock-use-pthread-stubs.patch abcm2ps-5.7.2-1.fc9 ------------------- * Thu Jan 10 2008 Gerard Milmeister - 5.7.2-1 - new release 5.7.2 babl-0.0.18-1.fc9 ----------------- * Thu Jan 10 2008 Deji Akingunola - 0.0.18-1 - Update to 0.0.18 cobbler-0.6.5-3.fc9 ------------------- * Thu Jan 10 2008 Michael DeHaan - 0.6.5-3 - added python-setuptools stanza for F9 * Thu Jan 10 2008 Michael DeHaan - 0.6.5-1 - Upstream changes (see CHANGELOG) - simplify directory permissions createrepo-0.9.1-2.fc9 ---------------------- * Thu Jan 10 2008 Seth Vidal 0.9.1-2 - patch to fix bug until 0.9.2 csound-5.03.0-15.fc9 -------------------- * Thu Jan 10 2008 Caolan McNamara - 5.03.0-15 - Resolves: rhbz#428176 make build * Thu Jan 03 2008 Alex Lancaster - 5.03.0-14 - Rebuild for new tcl (8.5) ebview-0.3.6-4.fc9 ------------------ extragear-plasma-4.0.0-1.fc9 ---------------------------- * Tue Jan 08 2008 Sebastian Vahl 4.0.0-1 - kde-4.0.0 galternatives-0.13.4-5.fc9 -------------------------- * Thu Jan 10 2008 Deji Akingunola - 0.13.4-5 - Package the python egg file - Update the License tag gdb-6.7.1-8.fc9 --------------- * Thu Jan 10 2008 Jan Kratochvil - 6.7.1-8 - Fix detaching from a threaded formerly stopped process with non-primary thread currently active (general BZ 233852). - Enable back again the testcases named `attachstop.exp' (no such exist now). - Rename the testcase `gdb.threads/attachstop' to `gdb.threads/attachstop-mt'. - Test ia64 memory leaks of the code using libunwind. - Testcase delay increase (for BZ 247354). - Test gcore memory and time requirements for large inferiors. gnome-launch-box-0.4-6.fc9 -------------------------- * Wed Jan 09 2008 - Bastien Nocera - 0.4-6 - Add patches to use xdg-user-dirs and auto-detect transparency (#428079) gnome-scan-0.5.3-0.2.20071030svn.fc9 ------------------------------------ * Thu Jan 10 2008 Deji Akingunola - 0.5.3-0.2.20071030svn - Fixed to build with latest gegl jabbim-0.3-0.63.20080110svn.fc9 ------------------------------- * Thu Jan 10 2008 Michal Schmidt - 0.3-0.63.20080110svn - Upstream SVN revision 1817. - Important fix: remote crash using ad-hoc commands. - Beginning of French translation. - XML-RPC plugin. - Packaging: Put the compressed diff since the the last full version into the lookaside cache. kaider-4.0.0-1.fc9 ------------------ * Mon Jan 07 2008 Kevin Kofler 4.0.0-1 - Update to 4.0.0 - Drop doc-subdir patch (fixed upstream) kcbench-0.3-1.1 --------------- * Thu Jan 10 2008 Thorsten Leemhuis - 0.3-1 - update kcbench to 0.3: -- fix typo -- improve some comments kde-settings-4.0-8.fc9 ---------------------- * Thu Jan 10 2008 Rex Dieter 4.0-8 - include /etc/kde/env/env.sh (#426115) - move extra sources into tarball - -kdm: cleanup deps kdeaccessibility-1:4.0.0-1.fc9 ------------------------------ * Tue Jan 08 2008 Kevin Kofler 1:4.0.0-1 - update to 4.0.0 - update file list kdeadmin-7:4.0.0-1.fc9 ---------------------- * Tue Jan 08 2008 Kevin Kofler 7:4.0.0-1 - update to 4.0.0 * Thu Dec 20 2007 Kevin Kofler 7:3.97.0-3 - don't run kpackage through consolehelper, it can elevate privileges on demand (see also #344751, though that bug appears not to have affected KDE 4) * Thu Dec 13 2007 Rex Dieter 7:3.97.0-2 - cosmetics (drop extraneous BR's, touchup %description) kdeartwork-4.0.0-1.fc9 ---------------------- * Tue Jan 08 2008 Kevin Kofler 4.0.0-1 - update to 4.0.0 kdebase-6:4.0.0-2.fc9 --------------------- * Tue Jan 08 2008 Rex Dieter 4.0.0-2 - respun tarball * Mon Jan 07 2008 Than Ngo 4.0.0-1 - 4.0.0 * Tue Dec 25 2007 Kevin Kofler 3.97.0-5 - Obsoletes: dolphin, d3lphin, Provides: dolphin (F9+) kdebase-runtime-4.0.0-2.fc9 --------------------------- * Tue Jan 08 2008 Rex Dieter 4.0.0-2 - respun tarball * Mon Jan 07 2008 Kevin Kofler 4.0.0-1 - update to 4.0.0 - update file list, don't remove renamed khotnewstuff.knsrc for KDE 3 desktop kdebase-workspace-4.0.0-5.fc9 ----------------------------- * Wed Jan 09 2008 Rex Dieter 4.0.0-5 - initial login with white background (#428131, kde#155122) * Wed Jan 09 2008 Rex Dieter 4.0.0-4 - use upstream systemtray patch (#427442, kde#153193) * Tue Jan 08 2008 Rex Dieter 4.0.0-3 - respun tarball - omit gtk_applet patch (for now, doesn't build) kdebindings-4.0.0-1.fc9 ----------------------- * Tue Jan 08 2008 Rex Dieter 4.0.0-1 - kde-4.0.0 kdeedu-4.0.0-2.fc9 ------------------ * Tue Jan 08 2008 Rex Dieter 4.0.0-2 - respun tarball * Tue Jan 08 2008 Rex Dieter 4.0.0-1 - kde-4.0.0 kdegames-6:4.0.0-1.fc9 ---------------------- * Tue Jan 08 2008 Rex Dieter 4.0.0-1 - kde-4.0.0 * Tue Dec 25 2007 Kevin Kofler 3.97.0-3 - move libkdegames.so to %{_libdir}/kde4/devel and patch search order (#426730) * Tue Dec 11 2007 Kevin Kofler 3.97.0-2 - rebuild for changed _kde4_includedir kdegraphics-7:4.0.0-1.fc9 ------------------------- * Tue Jan 08 2008 Rex Dieter 4.0.0-1 - kde-4.0.0 kdelibs-6:4.0.0-1.fc9 --------------------- * Mon Jan 07 2008 Than Ngo 4.0.0-1 - 4.0.0 kdemultimedia-6:4.0.0-1.fc9 --------------------------- * Tue Jan 08 2008 Rex Dieter 4.0.0-1 - kde-4.0.0 - drop upstreamed cdparanoia patch kdenetwork-7:4.0.0-1.fc9 ------------------------ * Tue Jan 08 2008 Rex Dieter 4.0.0-1 - kde-4.0.0 kdepimlibs-4.0.0-1.fc9 ---------------------- * Mon Jan 07 2008 Than Ngo 4.0.0-1 - 4.0.0 kdesdk-4.0.0-1.fc9 ------------------ * Tue Jan 08 2008 Kevin Kofler 4.0.0-1 - update to 4.0.0 - drop upstreamed fix-kompare patch - update file list (no more katesessionmenu.desktop) kdetoys-7:4.0.0-1.fc9 --------------------- * Tue Jan 08 2008 Rex Dieter 7:4.0.0-1 - kde-4.0.0 kdeutils-6:4.0.0-2.fc9 ---------------------- * Tue Jan 08 2008 Rex Dieter 6:4.0.0-2 - drop Requires: %name-libs (doesn't exist anymore) * Tue Jan 08 2008 Rex Dieter 6:4.0.0-1 - kde-4.0.0 kernel-2.6.24-0.147.rc7.git2.fc9 -------------------------------- * Thu Jan 10 2008 Chuck Ebbert - temporarily fix up utrace breakage * Thu Jan 10 2008 John W. Linville - rt2500usb thinko fix - b43 N phy pre-support updates - ath5k cleanups and beacon fixes * Thu Jan 10 2008 Eric Sandeen - ext4 updates slated for 2.6.25 klamav-0.41.1-14.fc9 -------------------- * Thu Jan 10 2008 Andy Shevchenko 0.41.1-14 - inherit archive limit defaults and pass their to the clamav even if they are equal to zero (#428066) koan-0.6.4-1.fc9 ---------------- * Thu Jan 10 2008 Michael DeHaan - 0.6.4-1 - Upstream changes (see CHANGELOG) * Thu Nov 15 2007 Michael DeHaan - 0.6.3-3 - Upstream changes (see CHANGELOG) libdhcp-1.99.5-1.fc9 -------------------- * Thu Jan 10 2008 David Cantrell - 1.99.5-1 - Prevent SIGABRT (#378641) libselinux-2.0.46-5.fc9 ----------------------- * Tue Jan 08 2008 Dan Walsh - 2.0.46-5 - Add audit2why python bindings libsmi-0.4.5-3.fc9 ------------------ * Thu Jan 10 2008 Stepan Kasal - 0.4.5-3 - libsmi-devel should not require automake - convert COPYING to utf-8 malaga-suomi-voikko-1.0-1.fc9 ----------------------------- * Thu Jan 10 2008 - Ville-Pekka Vainio 1.0-1 - Suomi-malaga 1.0 - Requires: libmalaga, not malaga. The malaga binaries are not needed for Finnish spellchecking, only the library is. - Changed description a bit mirage-0.9.1-1.fc9 ------------------ * Thu Jan 10 2008 Mamoru Tasaka - 0.9.1-1 - 0.9.1 nagios-plugins-1.4.10-3.fc9 --------------------------- * Thu Jan 10 2008 Mike McGrath 1.4.10-3 - Fixed check_log plugin #395601 * Thu Dec 06 2007 Release Engineering - 1.4.10-2 - Rebuild for deps * Thu Dec 06 2007 Mike McGrath 1.4.10-1 - Upstream released new version - Removed some patches nemiver-0.4.0-3.fc9 ------------------- * Thu Jan 10 2008 Peter Gordon - 0.4.0-3 - Make GConf scriplets quieter (bug 426801: "unclean" rpm transaction). - Add upstream patch to fix compile errors with casting from unsigned int* to pid_t* due to libgtop API change: + pid_t-fix-build.patch * Tue Aug 21 2007 Peter Gordon - 0.4.0-2 - Rebuild with BuildID-enabled binutils. - Update License tag (GPLv2+) nspluginwrapper-0.9.91.5-19.fc9 ------------------------------- * Thu Jan 10 2008 Martin Stransky 0.9.91.5-19 - xulrunner rebuild - fixed build script, added gthread-2.0 * Mon Dec 24 2007 Warren Togami 0.9.91.5-18 - Make nsviewer.bin initialized for multithreading, fixes #360891 openoffice.org-1:2.4.0-1.1.fc9 ------------------------------ * Sun Jan 06 2008 Caolan McNamara - 1:2.4.0-1.1 - first OOH680_m1 - remove redundant entries from configure - drop integrated openoffice.org-2.3.0.ooo77885.stoc.stocmerge.patch - drop integrated openoffice.org-1.9.129.ooo54603.fontconfig.patch - drop integrated workspace.as6.patch - drop integrated openoffice.org-2.0.3.ooo68048.vcl.imsurroundtext.patch - drop integrated openoffice.org-2.1.0.ooo72129.vcl.fontglyphindex.patch - drop integrated workspace.configrefactor01.patch - drop integrated openoffice.org-2.2.1.ooo80424.vcl.honourwidthtype.patch - drop integrated workspace.npower7.patch - drop integrated openoffice.org-2.3.0.ooo80721.reportdesign.stlportism.patch - drop integrated openoffice.org-2.3.0.ooo80735.cppu.map.patch - drop integrated openoffice.org-2.3.0.ooo80967.ucb.neon27.patch - drop integrated openoffice.org-2.3.0.ooo81112.reportdesign.parallel.patch - drop integrated openoffice.org-2.3.0.ooo81936.sc.maketypesagree.patch - drop integrated workspace.fpicker7.patch - drop integrated openoffice.org-2.3.0.ooo83591.vcl.checkboxes.patch - drop integrated openoffice.org-2.3.1.ooo82911.sd.insertbackground.patch - drop integrated workspace.sw8u10bf02.patch - drop integrated openoffice.org-2.3.1.ooo83930.sw.flushanchors.patch - drop integrated workspace.cmcfixes39.patch - drop integrated workspace.gcc430.patch - drop integrated workspace.locales24.patch - drop integrated openoffice.org-2.3.0.ooo81314.i18npool.crash.patch - drop openoffice.org-2.3.1.ooo84001.slideshow.gccisaprick.patch - drop openoffice.org-2.2.0.ooo53397.linkopt.patch - replace openoffice.org-2.1.0.ooo78148.lingucomponent.systemhunspell.patch with openoffice.org-2.1.0.oooXXXXX.lingucomponent.systemdicts.patch - add openoffice.org-2.4.0.ooo84684.vcl.fixfontconfig.patch - add Requires for indic hunspell dictionaries - Resolves: rhbz#427757 add openoffice.org-2.4.0.ooo85054.stlport.noorigs.patch - Resolves: rhbz#426876 add openoffice.org-2.4.0.ooo85055.psprint.linetoolong.patch - add openoffice.org-2.4.0.oooXXXXX.config_office.xpcomasxul.patch to build - add openoffice.org-2.4.0.ooo85097.desktop.pagein.patch * Thu Jan 03 2008 Caolan McNamara - 1:2.3.1-9.11 - Resolves: rhbz#427071 openoffice.org-2.3.0.ooo81314.i18npool.crash.patch * Thu Dec 20 2007 Caolan McNamara - 1:2.3.1-9.10 - Resolves: rhbz#425701 add workspace.locales24.patch - Resolves: rhbz#423371 openoffice.org-2.3.1.ooo84621.sw.insertexcel.patch - add workspace.gcc430.patch for gcc 4.3.0 - add openoffice.org-2.3.1.ooo84770.svx.eventsmismatch.patch paps-0.6.8-2.fc9 ---------------- * Thu Jan 10 2008 Akira TAGOH - 0.6.8-2 - paps-0.6.8-dsc-compliant.patch: Patch out to be DSC compliant. (#424951) pciutils-2.2.9-2.fc9 -------------------- * Thu Jan 10 2008 Harald Hoyer 2.2.9-2 - added more requirements for pciutils-devel perl-POE-Component-Child-1.39-3.fc9 ----------------------------------- * Thu Jan 10 2008 Ralf Cors??pius 1.39-3 - Update License-tag. - BR: perl(Test::Simple) (BZ 419631). perl-POE-Wheel-Null-0.01-3.fc9 ------------------------------ * Thu Jan 10 2008 Ralf Cors??pius 0.01-3 - Update License-tag. - BR perl(Test::More) (BZ 419631). - Minor spec cleanup. perl-Perl-MinimumVersion-0.15-2.fc9 ----------------------------------- perl-Spreadsheet-ParseExcel-0.3200-2.fc9 ---------------------------------------- * Thu Jan 10 2008 Ralf Cors??pius 0.3200-2 - Update License-tag. - BR perl(Test::More) (BZ 419631). - Let package own %{perl_vendorarch}/Unicode. php-pecl-memcache-2.2.2-1.fc9 ----------------------------- * Thu Jan 10 2008 Remi Collet 2.2.2-1 - new version pvm-3.4.5-8.fc9 --------------- * Tue Jan 08 2008 Alex Lancaster - 3.4.5-8 - rebuild for new Tcl 8.5 - apply patch from Florian La Roche (#427964) - do not package *.orig patch files - use dist macro pykickstart-1.24-1.fc9 ---------------------- * Thu Jan 10 2008 Chris Lumens - 1.24-1 - Make inheritance and overriding of %packages work (#427768). (clumens) - Add an option for which languages should be installed. (katzj) - Use the right name for the iscsi --target variable (#418781). (clumens) python-virtinst-0.300.2-2.fc9 ----------------------------- * Thu Jan 10 2008 Daniel P. Berrange - 0.300.2-2.fc9 - Added dep on libxml2-python and python-urlgrabber * Thu Jan 10 2008 Daniel P. Berrange - 0.300.2-1.fc9 - Update to 0.300.2 release qalculate-kde-0.9.6-3.fc9 ------------------------- * Thu Jan 10 2008 Deji Akingunola - 0.9.6-3 - Now BR kdelibs3 instead of kdelibs rlwrap-0.30-1.fc9 ----------------- * Thu Jan 10 2008 Michel Salim 0.30-1 - Update to 0.30 ruby-1.8.6.111-6.fc9 -------------------- * Fri Jan 11 2008 Akira TAGOH - 1.8.6.111-6 - Fix an unnecessary replacement for shebang. (#426835) * Fri Jan 04 2008 Akira TAGOH - 1.8.6.111-5 - Rebuild. * Fri Dec 28 2007 Akira TAGOH - 1.8.6.111-4 - Clean up again. rubyripper-0.4.4-2.fc9 ---------------------- * Thu Jan 10 2008 Sindre Pedersen Bj??rdal - 0.4.3-2 - New upstream release - Reworked installation path patch for new release sepostgresql-8.2.6-1.140.fc9 ---------------------------- * Tue Jan 08 2008 - 8.2.6-1.140 - add "security_sysattr_name" GUC variable - update base PostgreSQL to 8.2.6 six-0.5.3-8.fc9 --------------- * Thu Jan 10 2008 Rafa?? Psota - 0.5.3-8 - gcc 4.3 patch * Tue Jan 08 2008 Rafa?? Psota - 0.5.3-7 - fixed BR skencil-0.6.17-17.20070606svn.fc9 --------------------------------- * Thu Jan 10 2008 Caolan McNamara - 0.6.17-17.20070606svn - make build against Tcl 8.5 * Sat Jan 05 2008 Alex Lancaster - 0.6.17-16.20070606svn - Rebuild for new Tcl 8.5 soprano-2.0.0-1.fc9 ------------------- * Mon Jan 07 2008 Than Ngo 2.0.0-1 - 2.0.0 soundconverter-0.9.8-1.fc9 -------------------------- * Fri Jan 11 2008 Denis Leroy - 0.9.8-1 - Update to upstream 0.9.8, bugfix release supertux-0.3.1-1.fc9 -------------------- * Tue Jan 08 2008 Steven Pritchard 0.3.1-1 - Update to 0.3.1. - Upstream is calling this release "supertux2", so we get rid of the "2". - Update License. * Fri Oct 19 2007 Nils Philippsen 0.3.0-3 - use opengl-games-wrapper.sh from Fedora 7 on (#335701) * Fri Oct 19 2007 Nils Philippsen 0.3.0-2 - use opengl-games-wrapper.sh from Fedora 8 on (#335701) synce-gnome-0.11-2.fc9 ---------------------- system-config-netboot-0.1.44-1.fc9 ---------------------------------- * Mon Jan 07 2008 Radek Brich - 0.1.44-1 - separate command line utilities to extra -cmd package (bz#212271) - allow to set PXEBOOTDIR via sysconfig (bz#205105) - do not mount /dev from diskless snapshot, use tmpfs instead (patch by Ondrej Valousek, bz#406711) - few fixes for mkdiskless (bz#412401) - fix NFS4 mounting on diskless clients (bz#410411) taskjuggler-2.4.0-5.fc9 ----------------------- * Thu Jan 10 2008 Ondrej Vasik - 2.4.0-5 - Fixed crash when zooming a report after a non-embedded report has been viewed last(upstream). tix-1:8.4.2-3.fc9 ----------------- * Thu Jan 10 2008 Vitezslav Crhonek - 1:8.4.2-3 - Fix for build with tcl 8.5, change the installing paths, remove unused variable (Marcela Maslanova ) - Fix build issues and installation path problems for tcl 8.5, move demo programs to -doc subpackage (Wart ) - Fix buildroot, tix 8.4 to tcl 8.5 compatibility patch based on patch by Greg Couch tomcat5-0:5.5.25-3jpp.1.fc9 --------------------------- * Thu Jan 10 2008 Devrim GUNDUZ 0:5.5.25-3jpp.1 - Add new patch(24) for improving cookie parsing, per bz #428257 usermode-1.94-1.fc9 ------------------- * Thu Jan 10 2008 Miloslav Trma?? - 1.94-1 - Add support for including files from wrapper configuration files. Original patch by Carlo de Wolf. Resolves: #426095 - Add /etc/security/console.apps/config-util for use by system-config-* - Rename sr at Latn.po to sr at latin.po Resolves: #425842 vim-2:7.1.214-1.fc9 ------------------- * Thu Jan 10 2008 Karsten Hopp 7.1.214-1 - patchlevel 214 * Mon Jan 07 2008 Karsten Hopp 7.1.211-1 - patchlevel 211 * Sat Dec 22 2007 Karsten Hopp 7.1.175-1 - patchlevel 175 virt-manager-0.5.3-1.fc9 ------------------------ * Thu Jan 10 2008 Daniel P. Berrange - 0.5.3-1.fc9 - Update to 0.5.3 release wbxml2-0.9.2-10.fc9 ------------------- * Mon Jan 07 2008 Andreas Bierfert - 0.9.2-10 - add synce patches xen-3.2.0-0.fc9.rc5.dev16701.1 ------------------------------ * Thu Jan 10 2008 Daniel P. Berrange - 3.2.0-0.fc9.rc5.dev16701.1 - Rebase to Xen 3.2 rc5 changeset 16701 * Thu Dec 13 2007 Daniel P. Berrange - 3.1.2-3.fc9 - Re-factor to make it easier to test dev trees in RPMs - Include hypervisor build if doing a dev RPM * Fri Dec 07 2007 Release Engineering - 3.1.2-2.fc9 - Rebuild for deps xorg-x11-drv-openchrome-0.2.901-4.fc9 ------------------------------------- * Thu Jan 10 2008 Xavier Bachelot - 0.2.901-4 - Another try at fixing the libpciaccess patch. xqilla-2.0.0-1.fc9 ------------------ Broken deps for i386 ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.i386 requires libgtkembedmoz.so epiphany-extensions - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 gcl - 2.6.7-15.fc8.i386 requires libtk8.4.so gcl - 2.6.7-15.fc8.i386 requires libtcl8.4.so gdal-perl - 1.5.0-1.fc9.i386 requires perl(Geo::GDAL::Const) gnome-web-photo - 0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.i386 requires libgtkembedmoz.so gnome-web-photo - 0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 kazehakase - 0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 libopensync-plugin-sunbird - 0.22-3.fc8.i386 requires libopensync.so.0 libopensync-plugin-synce - 0.22-4.fc8.i386 requires libopensync.so.0 multisync - 0.91.0-3.fc8.i386 requires libopensync.so.0 multisync - 0.91.0-3.fc8.i386 requires libosengine.so.0 multisync-gui - 0.91.0-3.fc8.i386 requires libopensync.so.0 multisync-gui - 0.91.0-3.fc8.i386 requires libosengine.so.0 netgen - 1.3.7-13.fc9.i386 requires libtk8.4.so netgen - 1.3.7-13.fc9.i386 requires libtcl8.4.so openoffice.org-devel - 1:2.4.0-1.1.fc9.i386 requires sdk openoffice.org-devel - 1:2.4.0-1.1.fc9.i386 requires /bin/python openoffice.org-devel - 1:2.4.0-1.1.fc9.i386 requires /usr/solar/bin/perl tcl-tcldict - 8.5.2-2.fc8.i386 requires tcl(abi) = 0:8.4 tkinter - 2.5.1-20.fc9.i386 requires libTix8.4.so vtk - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtcl8.4.so Broken deps for x86_64 ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gcl - 2.6.7-15.fc8.x86_64 requires libtk8.4.so()(64bit) gcl - 2.6.7-15.fc8.x86_64 requires libtcl8.4.so()(64bit) gdal-perl - 1.5.0-1.fc9.x86_64 requires perl(Geo::GDAL::Const) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) kazehakase - 0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 libopensync-plugin-sunbird - 0.22-3.fc8.x86_64 requires libopensync.so.0()(64bit) libopensync-plugin-synce - 0.22-4.fc8.x86_64 requires libopensync.so.0()(64bit) multisync - 0.91.0-3.fc8.x86_64 requires libosengine.so.0()(64bit) multisync - 0.91.0-3.fc8.x86_64 requires libopensync.so.0()(64bit) multisync-gui - 0.91.0-3.fc8.x86_64 requires libopensync.so.0()(64bit) multisync-gui - 0.91.0-3.fc8.x86_64 requires libosengine.so.0()(64bit) netgen - 1.3.7-13.fc9.x86_64 requires libtcl8.4.so()(64bit) netgen - 1.3.7-13.fc9.x86_64 requires libtk8.4.so()(64bit) openoffice.org-devel - 1:2.4.0-1.1.fc9.i386 requires sdk openoffice.org-devel - 1:2.4.0-1.1.fc9.i386 requires /bin/python openoffice.org-devel - 1:2.4.0-1.1.fc9.i386 requires /usr/solar/bin/perl openoffice.org-devel - 1:2.4.0-1.1.fc9.x86_64 requires sdk openoffice.org-devel - 1:2.4.0-1.1.fc9.x86_64 requires /bin/python openoffice.org-devel - 1:2.4.0-1.1.fc9.x86_64 requires /usr/solar/bin/perl tcl-tcldict - 8.5.2-2.fc8.x86_64 requires tcl(abi) = 0:8.4 tkinter - 2.5.1-20.fc9.x86_64 requires libTix8.4.so()(64bit) vtk - 5.0.3-20.fc8.x86_64 requires libtk8.4.so()(64bit) vtk - 5.0.3-20.fc8.x86_64 requires libtcl8.4.so()(64bit) vtk - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.x86_64 requires libtk8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.x86_64 requires libtcl8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.x86_64 requires libtk8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.x86_64 requires libtcl8.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.ppc requires libgtkembedmoz.so epiphany-extensions - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 gdal-perl - 1.5.0-1.fc9.ppc requires perl(Geo::GDAL::Const) gnome-web-photo - 0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.ppc requires libgtkembedmoz.so gnome-web-photo - 0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 kazehakase - 0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 libopensync-plugin-sunbird - 0.22-3.fc8.ppc requires libopensync.so.0 libopensync-plugin-synce - 0.22-4.fc8.ppc requires libopensync.so.0 monodevelop - 0.17-4.fc9.ppc requires boo multisync - 0.91.0-3.fc8.ppc requires libopensync.so.0 multisync - 0.91.0-3.fc8.ppc requires libosengine.so.0 multisync-gui - 0.91.0-3.fc8.ppc requires libopensync.so.0 multisync-gui - 0.91.0-3.fc8.ppc requires libosengine.so.0 netgen - 1.3.7-13.fc9.ppc requires libtk8.4.so netgen - 1.3.7-13.fc9.ppc requires libtcl8.4.so openoffice.org-devel - 1:2.4.0-1.1.fc9.ppc requires sdk openoffice.org-devel - 1:2.4.0-1.1.fc9.ppc requires /bin/python openoffice.org-devel - 1:2.4.0-1.1.fc9.ppc requires /usr/solar/bin/perl openoffice.org-devel - 1:2.4.0-1.1.fc9.ppc64 requires sdk openoffice.org-devel - 1:2.4.0-1.1.fc9.ppc64 requires /bin/python openoffice.org-devel - 1:2.4.0-1.1.fc9.ppc64 requires /usr/solar/bin/perl tcl-tcldict - 8.5.2-2.fc8.ppc requires tcl(abi) = 0:8.4 tkinter - 2.5.1-20.fc9.ppc requires libTix8.4.so vtk - 5.0.3-20.fc8.ppc requires libtcl8.4.so vtk - 5.0.3-20.fc8.ppc requires libtk8.4.so vtk - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc requires libtk8.4.so vtk-python - 5.0.3-20.fc8.ppc requires libtcl8.4.so vtk-python - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc requires libtk8.4.so vtk-tcl - 5.0.3-20.fc8.ppc requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) Broken deps for ppc64 ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gdal-perl - 1.5.0-1.fc9.ppc64 requires perl(Geo::GDAL::Const) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) kazehakase - 0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 libopensync-plugin-sunbird - 0.22-3.fc8.ppc64 requires libopensync.so.0()(64bit) libopensync-plugin-synce - 0.22-4.fc8.ppc64 requires libopensync.so.0()(64bit) multisync - 0.91.0-3.fc8.ppc64 requires libosengine.so.0()(64bit) multisync - 0.91.0-3.fc8.ppc64 requires libopensync.so.0()(64bit) multisync-gui - 0.91.0-3.fc8.ppc64 requires libopensync.so.0()(64bit) multisync-gui - 0.91.0-3.fc8.ppc64 requires libosengine.so.0()(64bit) netgen - 1.3.7-13.fc9.ppc64 requires libtcl8.4.so()(64bit) netgen - 1.3.7-13.fc9.ppc64 requires libtk8.4.so()(64bit) openoffice.org-devel - 1:2.4.0-1.1.fc9.ppc64 requires sdk openoffice.org-devel - 1:2.4.0-1.1.fc9.ppc64 requires /bin/python openoffice.org-devel - 1:2.4.0-1.1.fc9.ppc64 requires /usr/solar/bin/perl perl-Test-AutoBuild-darcs - 1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 tcl-tcldict - 8.5.2-2.fc8.ppc64 requires tcl(abi) = 0:8.4 tkinter - 2.5.1-20.fc9.ppc64 requires libTix8.4.so()(64bit) vtk - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) From jbarnes at virtuousgeek.org Fri Jan 11 18:05:27 2008 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Fri, 11 Jan 2008 10:05:27 -0800 Subject: thinkpad-acpi upstream version? In-Reply-To: <478789EA.50302@redhat.com> References: <47852A26.4010609@fedoraproject.org> <1200010908.20425.6.camel@vincent52.localdomain> <478789EA.50302@redhat.com> Message-ID: <200801111005.27245.jbarnes@virtuousgeek.org> On Friday, January 11, 2008 7:23 am Jarod Wilson wrote: > > Which video driver? > > Intel X3100 graphics, 1680x1050 display, intel video driver. > > > Does yours suspend properly? > > Yep, though I did have to add my model # to the proper hal quirks file. > Prior to that, it would often resume to a black screen (though I could get > a console back via ctrl-alt-f1 then alt-f7 and X would be back). Now, its > flawless, and gets me straight to the gnome unlock dialog within a few > seconds. Still not nearly as fast as Mac OS X resumes on my 3 year old > PowerBook G4, but still pretty damned good. There are a couple of things to note about these features: - the rawhide kernel has bits to suspend/resume intel video devices (should be faster than using vbetool) - newer versions of the intel driver (2.2+) have a more sophisticated backlight control system, see the man page for more details. it should work with the thinkpad_acpi driver via the /sys/class/backlight interface Jesse From lordmorgul at gmail.com Fri Jan 11 18:25:34 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Fri, 11 Jan 2008 10:25:34 -0800 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <478779B2.5000706@gmail.com> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <47864F28.4030708@gmail.com> <1199984962.30858.66.camel@oneill.fubar.dk> <47865662.2080701@gmail.com> <478741FB.9040305@gmail.com> <478779B2.5000706@gmail.com> Message-ID: <4787B49E.4090806@gmail.com> Les Mikesell wrote: > Andrew Farris wrote: >> Anaconda should have handled changing your configuration change in >> /etc/fstab for you at install if all your partitions were labeled. > > When does anaconda run? I want to be able to install an OS, then add > disks or move them. Right now a machine by my desktop has 2 scsi and 8 > sata drives in hot-swap bays plus an assortment of pluggable firewire > and USB external drives, and only the scsi pair were installed when > anaconda ran. I'd much, much prefer that the raw devices for the > swappable bays always had fixed device names for the drive inserted by > position regardless of insertion order but I realize that's not likely > to happen, so I'll settle for a reasonable description of how to figure > out the right name for a newly inserted drive with the understanding > that it may not have a filesystem lable and I may not want to mount it. > At the moment, the most likely thing I'd want to do is add a partition > from a newly inserted disk to an existing md array, but at some point in > the setup (and not while anaconda is running...) it is necessary to > partition and build the arrays out of a bunch of disks that mostly look > the same. Is fedora suitable for jobs like this? Well in that particular situation where you know when the disk is inserted and you can do them one at a time it should be easily determined which device nodes are assigned just by 'tail -F /var/log/messages' prior to the disk insertion. I'd agree thats not exactly as elegant as the assumption that the device will consistently be assigned a certain device node but it works. When the disk is inserted the kernel messages very clearly identify it if a usable disk is found whether it is partitioned or not. You can also just look into /dev/disk/by-id for links that give you the device if you know which id is which (and if only one of the disks inserted doesn't have partitions you know which it is immediately). /dev/disk/by-path even tells you the controller you're connected to for each device node (with the caviat that it calls them all scsi, but primary controller to secondary controller should still make sense). That gives you all you should need to handle those disk management jobs... If thats still just not how you want it to be, thats understandable I suppose. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From opensource at till.name Fri Jan 11 18:32:14 2008 From: opensource at till.name (Till Maas) Date: Fri, 11 Jan 2008 19:32:14 +0100 Subject: Deleting a file/directory on startup In-Reply-To: <200801111852.08733.opensource@till.name> References: <200801111852.08733.opensource@till.name> Message-ID: <200801111932.22748.opensource@till.name> On Fri January 11 2008, Till Maas wrote: > request will help here. But maybe someone knows a better solution that the > two I can think of. Here is my third idea: Use a crontab with @reboot, but this creates a dependency on cron. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From jonathan.underwood at gmail.com Fri Jan 11 18:41:21 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 11 Jan 2008 18:41:21 +0000 Subject: Deleting a file/directory on startup In-Reply-To: <200801111852.08733.opensource@till.name> References: <200801111852.08733.opensource@till.name> Message-ID: <645d17210801111041k3bfa7195jbbe8b90ec6bf36fd@mail.gmail.com> On 11/01/2008, Till Maas wrote: > Hiyas, > > a package I comaintain (pm-utils) uses a lockfile. Because it may happen that > the computer crashes when the program is used, the lockfile may be there > already when no instance of pm-utils is running. Therefore the lockfile > should be deleted on startup. Do I need to write an initscript for this? > Which is imho not 100% correct, because this "service" should never be > deactivated. Is there a directory , where one could drop a file for this? The > only one I can think of would be /etc/sysconfig/modules, where ever .modules > file is executed at startup. The original feature request to split up > rc.sysinit in a rc.sysinit.d structure is more than five years old (which > would be a good solution here), so I doubt that filing a feature request will > help here. But maybe someone knows a better solution that the two I can think > of. Have a look at the logic used in the fail2ban init file - the start operation checks for a running fail2ban process. If non is found, it is safe to delete the lock file. As it happens, I just noticed that dovecot doesn't properly handle this situation either. From jdennis at redhat.com Fri Jan 11 18:54:50 2008 From: jdennis at redhat.com (John Dennis) Date: Fri, 11 Jan 2008 13:54:50 -0500 Subject: Deleting a file/directory on startup In-Reply-To: <645d17210801111041k3bfa7195jbbe8b90ec6bf36fd@mail.gmail.com> References: <200801111852.08733.opensource@till.name> <645d17210801111041k3bfa7195jbbe8b90ec6bf36fd@mail.gmail.com> Message-ID: <4787BB7A.7030508@redhat.com> The usual technique is to write a pid file in /var/run/name.pid. When the program is started check the running status of the process id found in the pid file. If it's dead remove the lock file and proceed, otherwise exit. -- John Dennis From opensource at till.name Fri Jan 11 19:01:19 2008 From: opensource at till.name (Till Maas) Date: Fri, 11 Jan 2008 20:01:19 +0100 Subject: Deleting a file/directory on startup In-Reply-To: <200801111932.22748.opensource@till.name> References: <200801111852.08733.opensource@till.name> <200801111932.22748.opensource@till.name> Message-ID: <200801112001.24928.opensource@till.name> On Fri January 11 2008, Till Maas wrote: > On Fri January 11 2008, Till Maas wrote: > > request will help here. But maybe someone knows a better solution that > > the two I can think of. > > Here is my third idea: Use a crontab with @reboot, but this creates a > dependency on cron. After I thought more about it, this may only work, when cron is started before acpid or any other service that may allow the user to suspend the machine. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From opensource at till.name Fri Jan 11 19:03:43 2008 From: opensource at till.name (Till Maas) Date: Fri, 11 Jan 2008 20:03:43 +0100 Subject: Deleting a file/directory on startup In-Reply-To: <645d17210801111041k3bfa7195jbbe8b90ec6bf36fd@mail.gmail.com> References: <200801111852.08733.opensource@till.name> <645d17210801111041k3bfa7195jbbe8b90ec6bf36fd@mail.gmail.com> Message-ID: <200801112003.44324.opensource@till.name> On Fri January 11 2008, Jonathan Underwood wrote: > Have a look at the logic used in the fail2ban init file - the start > operation checks for a running fail2ban process. If non is found, it > is safe to delete the lock file. The logic in fail2ban is vulnerable to race conditions, which does not help for pm-utils, where it can easily happen that it is run several times very fast after each other. Btw. the initial problem is to only delete a file at startup. I even found a bug report specifically about this: https://bugzilla.redhat.com/250927 Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From christoph.wickert at nurfuerspam.de Fri Jan 11 19:34:18 2008 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Fri, 11 Jan 2008 20:34:18 +0100 Subject: koji hosed? Message-ID: <1200080058.3448.1.camel@wicktop.localdomain> For some days koji hase become very slow. Now I'm not even able to open http://koji.fedoraproject.org/koji/ any longer: > Mod_python error: "PythonHandler mod_python.publisher" > > Traceback (most recent call last): > > File "/usr/lib64/python2.4/site-packages/mod_python/apache.py", line 299, in HandlerDispatch > result = object(req) > > File "/usr/lib64/python2.4/site-packages/mod_python/publisher.py", line 213, in handler > published = publish_object(req, object) > > File "/usr/lib64/python2.4/site-packages/mod_python/publisher.py", line 412, in publish_object > return publish_object(req,util.apply_fs_data(object, req.form, req=req)) > > File "/usr/lib64/python2.4/site-packages/mod_python/util.py", line 439, in apply_fs_data > return object(**args) > > File "/usr/share/koji-web/scripts/index.py", line 175, in index > start=buildStart, dataName='builds', prefix='build', order=buildOrder, pageSize=10) > > File "/usr/share/koji-web/lib/kojiweb/util.py", line 109, in paginateMethod > totalRows = getattr(server, methodName)(*args, **kw) > > File "/usr/lib/python2.4/site-packages/koji/__init__.py", line 1077, in __call__ > return self.__func(self.__name,args,opts) > > File "/usr/lib/python2.4/site-packages/koji/__init__.py", line 1302, in _callMethod > return proxy.__getattr__(name)(*args) > > File "/usr/lib64/python2.4/xmlrpclib.py", line 1096, in __call__ > return self.__send(self.__name, args) > > File "/usr/lib64/python2.4/xmlrpclib.py", line 1383, in __request > verbose=self.__verbose > > File "/usr/lib64/python2.4/xmlrpclib.py", line 1131, in request > errcode, errmsg, headers = h.getreply() > > File "/usr/lib64/python2.4/httplib.py", line 1137, in getreply > response = self._conn.getresponse() > > File "/usr/lib64/python2.4/httplib.py", line 866, in getresponse > response.begin() > > File "/usr/lib64/python2.4/httplib.py", line 336, in begin > version, status, reason = self._read_status() > > File "/usr/lib64/python2.4/httplib.py", line 294, in _read_status > line = self.fp.readline() > > File "/usr/lib64/python2.4/socket.py", line 325, in readline > data = recv(1) > > error: (4, 'Interrupted system call') > Christoph From nicolas.mailhot at laposte.net Fri Jan 11 20:01:29 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 11 Jan 2008 21:01:29 +0100 Subject: use defoma in fedora? In-Reply-To: <20080111150346.GA2575@free.fr> References: <20080110194622.GF2638@free.fr> <20080110200431.GG2638@free.fr> <20080111150346.GA2575@free.fr> Message-ID: <1200081689.22286.3.camel@rousalka.dyndns.org> Le vendredi 11 janvier 2008 ? 16:03 +0100, Patrice Dumas a ?crit : > On Fri, Jan 11, 2008 at 03:11:57PM +0100, Matej Cepl wrote: > > On 2008-01-10, 20:04 GMT, Patrice Dumas wrote: > > > Hum I wouldn't have expected the X server to have anything to > > > do with defoma. At least it is certainly unuseful in fedora. > > > I would see it useful for postrscript and type1 fonts. > > > > What's wrong with fontconfig? > > Nothing. But it seems to me that the applications I cited, grace, xglyph > and xdvi don't use fontconfig. Old stuff will be kept forever of course but you should be aware that all the entities that used to release Type1 fonts have migrated to OTF as their preferred non-TTF format lately. So Type1 fonts are going to be increasingly sparse in the future, and upgrading the font backend if those apps is a good idea. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From snecklifter at gmail.com Fri Jan 11 20:15:04 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Fri, 11 Jan 2008 20:15:04 +0000 Subject: koji hosed? In-Reply-To: <1200080058.3448.1.camel@wicktop.localdomain> References: <1200080058.3448.1.camel@wicktop.localdomain> Message-ID: <364d303b0801111215tb102effra75b558f40fbae73@mail.gmail.com> On 11/01/2008, Christoph Wickert wrote: > For some days koji hase become very slow. Now I'm not even able to open > http://koji.fedoraproject.org/koji/ any longer: > > > Mod_python error: "PythonHandler mod_python.publisher" > > > > Traceback (most recent call last): > > > > File "/usr/lib64/python2.4/site-packages/mod_python/apache.py", line 299, in HandlerDispatch > > result = object(req) > > > > File "/usr/lib64/python2.4/site-packages/mod_python/publisher.py", line 213, in handler > > published = publish_object(req, object) > > > > File "/usr/lib64/python2.4/site-packages/mod_python/publisher.py", line 412, in publish_object > > return publish_object(req,util.apply_fs_data(object, req.form, req=req)) > > > > File "/usr/lib64/python2.4/site-packages/mod_python/util.py", line 439, in apply_fs_data > > return object(**args) > > > > File "/usr/share/koji-web/scripts/index.py", line 175, in index > > start=buildStart, dataName='builds', prefix='build', order=buildOrder, pageSize=10) > > > > File "/usr/share/koji-web/lib/kojiweb/util.py", line 109, in paginateMethod > > totalRows = getattr(server, methodName)(*args, **kw) > > > > File "/usr/lib/python2.4/site-packages/koji/__init__.py", line 1077, in __call__ > > return self.__func(self.__name,args,opts) > > > > File "/usr/lib/python2.4/site-packages/koji/__init__.py", line 1302, in _callMethod > > return proxy.__getattr__(name)(*args) > > > > File "/usr/lib64/python2.4/xmlrpclib.py", line 1096, in __call__ > > return self.__send(self.__name, args) > > > > File "/usr/lib64/python2.4/xmlrpclib.py", line 1383, in __request > > verbose=self.__verbose > > > > File "/usr/lib64/python2.4/xmlrpclib.py", line 1131, in request > > errcode, errmsg, headers = h.getreply() > > > > File "/usr/lib64/python2.4/httplib.py", line 1137, in getreply > > response = self._conn.getresponse() > > > > File "/usr/lib64/python2.4/httplib.py", line 866, in getresponse > > response.begin() > > > > File "/usr/lib64/python2.4/httplib.py", line 336, in begin > > version, status, reason = self._read_status() > > > > File "/usr/lib64/python2.4/httplib.py", line 294, in _read_status > > line = self.fp.readline() > > > > File "/usr/lib64/python2.4/socket.py", line 325, in readline > > data = recv(1) > > > > error: (4, 'Interrupted system call') There's an outage ongoing at the moment - I'm getting BUILDROOT errors... https://fedorahosted.org/fedora-infrastructure/ticket/338 -- Christopher Brown http://www.chruz.com From jwilson at redhat.com Fri Jan 11 20:22:45 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 11 Jan 2008 15:22:45 -0500 Subject: IIDC camera's and the juju firewirestack In-Reply-To: <47866743.8020608@redhat.com> References: <478633EE.2030407@hhs.nl> <4786396A.4060605@redhat.com> <47866743.8020608@redhat.com> Message-ID: <4787D015.3000503@redhat.com> Jarod Wilson wrote: > Jarod Wilson wrote: >> Hans de Goede wrote: >>> In the thread I started about Fedora perhaps being to cutting edge, it >>> was said that I shouldn't complain as there is only one problem left >>> with the juju stack which is a bug with via vt6306 cards in OHCI 1.0 cards. >> Oh, there's definitely more than one problem left... :) > >>> Further analysis of the problem has learned that this is not true, I'm >>> using a via vt6306 card in OHCI 1.1 mode, which allegedly should work fine. >> The particular bug is actually related to vt6306 and vt6307 cards in OHCI 1.0 >> mode doing dv capture. iidc is much less tested. I already know where at least >> a few of the iidc-related OHCI 1.0 bugs are, but they shouldn't be impacting >> you... I've also got an idea or two on what's up with dv capture, just need to >> get the spare cycles to test (which could happen shortly, just finished a >> major piece of lirc...) > >>> However most documents talk about using the juju stack with either >>> harddisks or DV for homevideo camera's. However I'm trying to use an >>> industrial cam which used the IIDC protocol, and support in the new juju >>> stack (kernel + userspace) for the IIDC protocol isn't very good. >> I believe David Moore's patch in linux1394-2.6.git[*] should help, and it >> looks like that also needs to be ported over to the OHCI 1.0 code paths... > > Nope, looks like he's already done that too. As I said in another thread, I'm > going to try to start tracking the linux1394 git tree in rawhide, and > selectively pull back patches into released kernels. David's done a lot of > excellent work of late while I was busy not paying attention, due to the > holidays and other misc stuff (lirc, ia64 xen, ecryptfs, ext4...) After a bit of positive testing, I committed a linux1394 git patch plus David's dynamic buffer alloc patch, which is about to be in linux1394 git, to the rawhide kernel. We've now got working iidc streaming on all OHCI 1.0 and 1.1 cards, so far as I know. I'll see about back-porting these bits to the F7 and F8 kernels as well. Would definitely like to hear what *doesn't* work now, short of dv capture with Via VT630x OHCI 1.0 cards, which is known broken and under investigation. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From lesmikesell at gmail.com Fri Jan 11 20:30:39 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 11 Jan 2008 14:30:39 -0600 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <4787B49E.4090806@gmail.com> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <47864F28.4030708@gmail.com> <1199984962.30858.66.camel@oneill.fubar.dk> <47865662.2080701@gmail.com> <478741FB.9040305@gmail.com> <478779B2.5000706@gmail.com> <4787B49E.4090806@gmail.com> Message-ID: <4787D1EF.7070407@gmail.com> Andrew Farris wrote: >>> Anaconda should have handled changing your configuration change in >>> /etc/fstab for you at install if all your partitions were labeled. >> >> When does anaconda run? I want to be able to install an OS, then add >> disks or move them. Right now a machine by my desktop has 2 scsi and >> 8 sata drives in hot-swap bays plus an assortment of pluggable >> firewire and USB external drives, and only the scsi pair were >> installed when anaconda ran. I'd much, much prefer that the raw >> devices for the swappable bays always had fixed device names for the >> drive inserted by position regardless of insertion order but I realize >> that's not likely to happen, so I'll settle for a reasonable >> description of how to figure out the right name for a newly inserted >> drive with the understanding that it may not have a filesystem lable >> and I may not want to mount it. At the moment, the most likely thing >> I'd want to do is add a partition from a newly inserted disk to an >> existing md array, but at some point in the setup (and not while >> anaconda is running...) it is necessary to partition and build the >> arrays out of a bunch of disks that mostly look the same. Is fedora >> suitable for jobs like this? > > Well in that particular situation where you know when the disk is > inserted and you can do them one at a time it should be easily > determined which device nodes are assigned just by 'tail -F > /var/log/messages' prior to the disk insertion. I'd agree thats not > exactly as elegant as the assumption that the device will consistently > be assigned a certain device node but it works. When the disk is > inserted the kernel messages very clearly identify it if a usable disk > is found whether it is partitioned or not. > > You can also just look into /dev/disk/by-id for links that give you the > device if you know which id is which (and if only one of the disks > inserted doesn't have partitions you know which it is immediately). > /dev/disk/by-path even tells you the controller you're connected to for > each device node (with the caviat that it calls them all scsi, but > primary controller to secondary controller should still make sense). > That gives you all you should need to handle those disk management jobs... > > If thats still just not how you want it to be, thats understandable I > suppose. It doesn't seem as sensible as being able to plug into a known controller position and get a known device name, particularly in the scenario where the drives aren't hot-plug and you want to access a bunch of new ones after a reboot and know which is which. But I'm not interested in turning this into a helpdesk session about special case procedures. The same scenario happens even more often when I build a disk and ship it to a remote location where someone else (who doesn't know anything about linux...) swaps it into a server with multiple NICs - and now we have to associate the right NIC configuration with the right cable connection. In the old days if it was eth0 yesterday it would still be eth0 today, but that doesn't happen anymore. The servers typically have 4 nics with 2 in use and it can be painful figuring how to assign the addresses and routes so the network connections work on a new box or a replacement OS. So, the generic question is, now that the system uses essentially random names for devices, is there a way, or a plan for a way, to deal with situations where many choices of new devices appear as a result of hardware changes, disk moves, backup/restores on new hardware, etc. and if so, will it require a GUI to deal with it? So far I've only heard the notion that these things should "just work" and I want to make sure that everybody knows it can't "just work" because the system can't possibly know want I want to do with a newly attached device or a whole bunch of them and I normally don't want anything to happen automatically other than being able to know the device name to access them. Someone mentioned a scenario with usb->serial converters which would be a similar case - no matter how much you want to guess and do something friendly, you aren't going to know what's on the serial side of that thing or what to do with it. -- Les Mikesell lesmikesell at gmail.com From pemboa at gmail.com Fri Jan 11 20:36:27 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 11 Jan 2008 14:36:27 -0600 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <4787D1EF.7070407@gmail.com> References: <4785163E.8010508@hhs.nl> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <47864F28.4030708@gmail.com> <1199984962.30858.66.camel@oneill.fubar.dk> <47865662.2080701@gmail.com> <478741FB.9040305@gmail.com> <478779B2.5000706@gmail.com> <4787B49E.4090806@gmail.com> <4787D1EF.7070407@gmail.com> Message-ID: <16de708d0801111236q25f5277bs1a7eda1fb263e3f0@mail.gmail.com> On Jan 11, 2008 2:30 PM, Les Mikesell wrote: > It doesn't seem as sensible as being able to plug into a known > controller position and get a known device name, particularly in the > scenario where the drives aren't hot-plug and you want to access a bunch > of new ones after a reboot and know which is which. Frankly i like this idea, but I'm unsure of the practicality of it: What is the highest level which is even aware of the physical location of said device? I would imagine the BIOS knows, and maybe some really low level kernel modules but anything above that? -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From loganjerry at gmail.com Fri Jan 11 20:37:10 2008 From: loganjerry at gmail.com (Jerry James) Date: Fri, 11 Jan 2008 13:37:10 -0700 Subject: Intel compiler integration tool release Message-ID: <870180fe0801111237q1ffc1f24p265d8e06ddcbcc19@mail.gmail.com> I have just released attempt #3 at integrating the Intel C/C++ compilers and debugger into a Fedora system. My earlier attempts were named fedora-icc and icc-extras, respectively. I've changed the name yet again. This time it is called intel-extras (because Intel has some other tools that need integrating, so the package will grow to include them over time). The major issue with my previous attempts was tracking new Intel releases. Non-paying schmucks like me don't get access to the same versions as paying customers, so releasing new versions of the package that did nothing but bump the Intel version number just didn't cut it. This time, I have included a script, intel-update, that automatically detects the latest version (or optionally, a specified version) of the Intel tools on your system and integrates that version into Fedora. Get it here: http://jjames.fedorapeople.org/intel-extras/ (WARNING: ugly web page alert!). The earlier attempts were in the public domain. This is a complete rewrite, and this time I'm releasing it under an MIT license. A person who understands liability better than I do talked me into this change. I'm willing to help Intel make this package completely unnecessary, free of charge. There are now actual man pages. They contain important information. Please read them. If there is sufficient interest in this, I'll try to find a good home to host the project for the long term. If only the < 5 people who tried out my earlier attempts use it, I probably won't bother. I tried to makes the scripts work with bash, ksh, and zsh. I believe they work with all 3. If you find otherwise, it's a bug. Please let me know. Since one version of my package has to work with multiple Intel versions, there is some ugliness in the version number handling. I don't see a better way to deal with the situation. If you do, please enlighten me. While I have tested this new release on both x86 and x86_64 platforms, there are bound to be some bugs. Please use this product with caution. In particular, please back up your system before you try it out. -- Jerry James http://loganjerry.googlepages.com/ From vonbrand at inf.utfsm.cl Fri Jan 11 21:01:50 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Fri, 11 Jan 2008 18:01:50 -0300 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <4787D1EF.7070407@gmail.com> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <47864F28.4030708@gmail.com> <1199984962.30858.66.camel@oneill.fubar.dk> <47865662.2080701@gmail.com> <478741FB.9040305@gmail.com> <478779B2.5000706@gmail.com> <4787B49E.4090806@gmail.com> <4787D1EF.7070407@gmail.com> Message-ID: <200801112101.m0BL1obB031821@laptop13.inf.utfsm.cl> Les Mikesell wrote: [...] > It doesn't seem as sensible as being able to plug into a known > controller position and get a known device name, particularly in the > scenario where the drives aren't hot-plug and you want to access a > bunch of new ones after a reboot and know which is which. But I'm not > interested in turning this into a helpdesk session about special case > procedures. The same scenario happens even more often when I build a > disk and ship it to a remote location where someone else (who doesn't > know anything about linux...) swaps it into a server with multiple > NICs - and now we have to associate the right NIC configuration with > the right cable connection. In the old days if it was eth0 yesterday > it would still be eth0 today, but that doesn't happen anymore. The > servers typically have 4 nics with 2 in use and it can be painful > figuring how to assign the addresses and routes so the network > connections work on a new box or a replacement OS. Get them by MAC, not as ethX. I.e., here I have in /etc/sysconfig/network-scripts/ifcfg-eth0: # Intel Corporation 82573L Gigabit Ethernet Controller DEVICE=eth0 ONBOOT=yes BOOTPROTO=dhcp HWADDR=00:a0:d1:78:d7:c5 and the correct name is given to that eth. > So, the generic question is, now that the system uses essentially > random names for devices, is there a way, or a plan for a way, to deal > with situations where many choices of new devices appear as a result > of hardware changes, disk moves, backup/restores on new hardware, ... random hot(un)plugging, ... > etc. and if so, will it require a GUI to deal with it? So far I've > only heard the notion that these things should "just work" and I want > to make sure that everybody knows it can't "just work" because the > system can't possibly know want I want to do with a newly attached > device The systen /can/ tell e.g. this is still the FooLaser printer serial XYZ-ABCDE, even though it is connected through a different USB port today. AFAICS, as things stand, the system is /not/ doing anything funky, it just gives a way of finding out what is where (and the device has a clear ID); and uses this if the device had been configured before. Things do get tricky if you want to dd(1) disk images around, or are fond of serial devices connected through USB-serial dongles, etc. But then you want the system to do non-obvious stuff... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From lordmorgul at gmail.com Fri Jan 11 21:06:58 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Fri, 11 Jan 2008 13:06:58 -0800 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <16de708d0801111236q25f5277bs1a7eda1fb263e3f0@mail.gmail.com> References: <4785163E.8010508@hhs.nl> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <47864F28.4030708@gmail.com> <1199984962.30858.66.camel@oneill.fubar.dk> <47865662.2080701@gmail.com> <478741FB.9040305@gmail.com> <478779B2.5000706@gmail.com> <4787B49E.4090806@gmail.com> <4787D1EF.7070407@gmail.com> <16de708d0801111236q25f5277bs1a7eda1fb263e3f0@mail.gmail.com> Message-ID: <4787DA72.9070105@gmail.com> Arthur Pemberton wrote: > On Jan 11, 2008 2:30 PM, Les Mikesell wrote: >> It doesn't seem as sensible as being able to plug into a known >> controller position and get a known device name, particularly in the >> scenario where the drives aren't hot-plug and you want to access a bunch >> of new ones after a reboot and know which is which. > > Frankly i like this idea, but I'm unsure of the practicality of it: > > What is the highest level which is even aware of the physical location > of said device? I would imagine the BIOS knows, and maybe some really > low level kernel modules but anything above that? udev is fully aware of the physical location, because it knows the communication bus addressing to the device itself (/dev/disk/by-path). What Les is asking for is a consistent guaranteed device node naming scheme, which makes good sense for machines with few devices (desktops, small servers) and less sense for larger systems. The facts are the older scheme wasn't guaranteed to be deterministic, it just seemed to be because the kernel would probe / name the devices in sequential order, and its no longer guaranteed to do that (that still doesn't mean anything is named randomly). I suppose someone could have additional udev rules that would follow the older naming scheme at the same time as the new one... just doing the 'magic guesswork' to make sure things always got named in the predictable ordering. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From j.w.r.degoede at hhs.nl Fri Jan 11 21:10:35 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 11 Jan 2008 22:10:35 +0100 Subject: IIDC camera's and the juju firewirestack In-Reply-To: <4787D015.3000503@redhat.com> References: <478633EE.2030407@hhs.nl> <4786396A.4060605@redhat.com> <47866743.8020608@redhat.com> <4787D015.3000503@redhat.com> Message-ID: <4787DB4B.4020005@hhs.nl> Jarod Wilson wrote: > Jarod Wilson wrote: >> Jarod Wilson wrote: >>> Hans de Goede wrote: >>>> In the thread I started about Fedora perhaps being to cutting edge, it >>>> was said that I shouldn't complain as there is only one problem left >>>> with the juju stack which is a bug with via vt6306 cards in OHCI 1.0 cards. >>> Oh, there's definitely more than one problem left... :) >>>> Further analysis of the problem has learned that this is not true, I'm >>>> using a via vt6306 card in OHCI 1.1 mode, which allegedly should work fine. >>> The particular bug is actually related to vt6306 and vt6307 cards in OHCI 1.0 >>> mode doing dv capture. iidc is much less tested. I already know where at least >>> a few of the iidc-related OHCI 1.0 bugs are, but they shouldn't be impacting >>> you... I've also got an idea or two on what's up with dv capture, just need to >>> get the spare cycles to test (which could happen shortly, just finished a >>> major piece of lirc...) >>>> However most documents talk about using the juju stack with either >>>> harddisks or DV for homevideo camera's. However I'm trying to use an >>>> industrial cam which used the IIDC protocol, and support in the new juju >>>> stack (kernel + userspace) for the IIDC protocol isn't very good. >>> I believe David Moore's patch in linux1394-2.6.git[*] should help, and it >>> looks like that also needs to be ported over to the OHCI 1.0 code paths... >> Nope, looks like he's already done that too. As I said in another thread, I'm >> going to try to start tracking the linux1394 git tree in rawhide, and >> selectively pull back patches into released kernels. David's done a lot of >> excellent work of late while I was busy not paying attention, due to the >> holidays and other misc stuff (lirc, ia64 xen, ecryptfs, ext4...) > > After a bit of positive testing, I committed a linux1394 git patch plus > David's dynamic buffer alloc patch, which is about to be in linux1394 git, to > the rawhide kernel. We've now got working iidc streaming on all OHCI 1.0 and > 1.1 cards, so far as I know. I'll see about back-porting these bits to the F7 > and F8 kernels as well. > > Would definitely like to hear what *doesn't* work now, short of dv capture > with Via VT630x OHCI 1.0 cards, which is known broken and under investigation. > Excellent keep up to good work! Regards, Hans From orion at cora.nwra.com Fri Jan 11 21:33:08 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 11 Jan 2008 14:33:08 -0700 Subject: Problems with InstantMirror and iso images Message-ID: <4787E094.7090803@cora.nwra.com> For some reason apparently the download.fedora.redhat.com server doesn't product Last-Modified headers for iso images. This prevents InstantMirror from working with them. Thoughts? $ python Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) [GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import urllib, os, shutil, time, calendar, rfc822, string >>> o = urllib.urlopen("http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os/images/boot.iso") >>> o.headers.getdate("Last-Modified") >>> o = urllib.urlopen("http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os/images/diskboot.img") >>> o.headers.getdate("Last-Modified") (2008, 1, 11, 12, 51, 31, 0, 1, 0) >>> o = urllib.urlopen("http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os/images/boot.iso") >>> o.headers.getdate("Last-Modified") >>> -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From orion at cora.nwra.com Fri Jan 11 21:37:17 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 11 Jan 2008 14:37:17 -0700 Subject: Problems with InstantMirror and iso images In-Reply-To: <4787E094.7090803@cora.nwra.com> References: <4787E094.7090803@cora.nwra.com> Message-ID: <4787E18D.3050403@cora.nwra.com> Orion Poplawski wrote: > For some reason apparently the download.fedora.redhat.com server doesn't > product Last-Modified headers for iso images. This prevents > InstantMirror from working with them. Thoughts? > > $ python > Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11) > [GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> import urllib, os, shutil, time, calendar, rfc822, string > >>> o = > urllib.urlopen("http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os/images/boot.iso") > > >>> o.headers.getdate("Last-Modified") > >>> o = > urllib.urlopen("http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os/images/diskboot.img") > > >>> o.headers.getdate("Last-Modified") > (2008, 1, 11, 12, 51, 31, 0, 1, 0) > >>> o = > urllib.urlopen("http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os/images/boot.iso") > > >>> o.headers.getdate("Last-Modified") > >>> > Some more info (looks like a redirect to ftp). I'll file a ticket. wget -S http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os/images/boot.iso --14:34:01-- http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os/images/boot.iso => `boot.iso' Resolving download.fedora.redhat.com... 209.132.176.20, 209.132.176.220, 66.187.224.20 Connecting to download.fedora.redhat.com|209.132.176.20|:80... connected. HTTP request sent, awaiting response... HTTP/1.1 302 Found Date: Fri, 11 Jan 2008 21:34:01 GMT Server: Apache Location: ftp://download.fedora.redhat.com//pub/fedora/linux/development/i386/os/images/boot.iso Cache-Control: max-age=21600 Expires: Sat, 12 Jan 2008 03:34:01 GMT Content-Length: 270 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html; charset=iso-8859-1 Location: ftp://download.fedora.redhat.com//pub/fedora/linux/development/i386/os/images/boot.iso [following] --14:34:01-- ftp://download.fedora.redhat.com//pub/fedora/linux/development/i386/os/images/boot.iso => `boot.iso' Connecting to download.fedora.redhat.com|209.132.176.20|:21... connected. Logging in as anonymous ... 220 Fedora FTP server ready. Storage Provided by NetApp. All transfers are logged. [no EPSV] --> USER anonymous 331 Please specify the password. --> PASS Turtle Power! 230 Login successful. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From lesmikesell at gmail.com Fri Jan 11 21:44:31 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 11 Jan 2008 15:44:31 -0600 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <16de708d0801111236q25f5277bs1a7eda1fb263e3f0@mail.gmail.com> References: <4785163E.8010508@hhs.nl> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <47864F28.4030708@gmail.com> <1199984962.30858.66.camel@oneill.fubar.dk> <47865662.2080701@gmail.com> <478741FB.9040305@gmail.com> <478779B2.5000706@gmail.com> <4787B49E.4090806@gmail.com> <4787D1EF.7070407@gmail.com> <16de708d0801111236q25f5277bs1a7eda1fb263e3f0@mail.gmail.com> Message-ID: <4787E33F.8080605@gmail.com> Arthur Pemberton wrote: > On Jan 11, 2008 2:30 PM, Les Mikesell wrote: >> It doesn't seem as sensible as being able to plug into a known >> controller position and get a known device name, particularly in the >> scenario where the drives aren't hot-plug and you want to access a bunch >> of new ones after a reboot and know which is which. > > > Frankly i like this idea, but I'm unsure of the practicality of it: > > What is the highest level which is even aware of the physical location > of said device? I would imagine the BIOS knows, and maybe some really > low level kernel modules but anything above that? The bios doesn't necessarily know anything except for the one(s) that it might boot. But I think there may be some extra magic in what the kernel does with the names depending on which drive bios used to boot. The stuff in /dev/disk/by-path might be useful for the versions that have it, but I can't see anything for the empty controller positions where the drives aren't connected so the arrangement doesn't make a lot of sense. -- Les Mikesell lesmikesell at gmail.com From lordmorgul at gmail.com Fri Jan 11 21:50:02 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Fri, 11 Jan 2008 13:50:02 -0800 Subject: Problems with InstantMirror and iso images In-Reply-To: <4787E18D.3050403@cora.nwra.com> References: <4787E094.7090803@cora.nwra.com> <4787E18D.3050403@cora.nwra.com> Message-ID: <4787E48A.6080506@gmail.com> Orion Poplawski wrote: > Orion Poplawski wrote: >> For some reason apparently the download.fedora.redhat.com server >> doesn't product Last-Modified headers for iso images. This prevents >> InstantMirror from working with them. Thoughts? snip > Some more info (looks like a redirect to ftp). I'll file a ticket. If I'm not mistaken that redirect is there so that it can share the load with a few different primary mirrors (so intentional). -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From pemboa at gmail.com Fri Jan 11 21:51:58 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 11 Jan 2008 15:51:58 -0600 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <4787E33F.8080605@gmail.com> References: <4785163E.8010508@hhs.nl> <47864F28.4030708@gmail.com> <1199984962.30858.66.camel@oneill.fubar.dk> <47865662.2080701@gmail.com> <478741FB.9040305@gmail.com> <478779B2.5000706@gmail.com> <4787B49E.4090806@gmail.com> <4787D1EF.7070407@gmail.com> <16de708d0801111236q25f5277bs1a7eda1fb263e3f0@mail.gmail.com> <4787E33F.8080605@gmail.com> Message-ID: <16de708d0801111351h381bd93fk1425ceaba8c86b33@mail.gmail.com> On Jan 11, 2008 3:44 PM, Les Mikesell wrote: > > Arthur Pemberton wrote: > > On Jan 11, 2008 2:30 PM, Les Mikesell wrote: > >> It doesn't seem as sensible as being able to plug into a known > >> controller position and get a known device name, particularly in the > >> scenario where the drives aren't hot-plug and you want to access a bunch > >> of new ones after a reboot and know which is which. > > > > > > Frankly i like this idea, but I'm unsure of the practicality of it: > > > > What is the highest level which is even aware of the physical location > > of said device? I would imagine the BIOS knows, and maybe some really > > low level kernel modules but anything above that? > > The bios doesn't necessarily know anything except for the one(s) that it > might boot. But I think there may be some extra magic in what the > kernel does with the names depending on which drive bios used to boot. > The stuff in /dev/disk/by-path might be useful for the versions that > have it, but I can't see anything for the empty controller positions > where the drives aren't connected so the arrangement doesn't make a lot > of sense. Then it seems to me that what you/i/we want can be accomplished with soem clever udev rules. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From lesmikesell at gmail.com Fri Jan 11 21:54:44 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 11 Jan 2008 15:54:44 -0600 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <200801112101.m0BL1obB031821@laptop13.inf.utfsm.cl> References: <4785163E.8010508@hhs.nl> <47851ED9.2000800@leemhuis.info> <1199912325.15130.89.camel@localhost.localdomain> <1199911972.10511.0.camel@optimus> <20080109233613.GG2664@free.fr> <478561ED.6050605@gmail.com> <74ah55x6io.ln2@ppp1053.in.ipex.cz> <4786267D.9010800@gmail.com> <20080110144603.GA38099@dspnet.fr.eu.org> <47863A42.7010409@gmail.com> <1199982487.30858.38.camel@oneill.fubar.dk> <47864F28.4030708@gmail.com> <1199984962.30858.66.camel@oneill.fubar.dk> <47865662.2080701@gmail.com> <478741FB.9040305@gmail.com> <478779B2.5000706@gmail.com> <4787B49E.4090806@gmail.com> <4787D1EF.7070407@gmail.com> <200801112101.m0BL1obB031821@laptop13.inf.utfsm.cl> Message-ID: <4787E5A4.3090809@gmail.com> Horst H. von Brand wrote: >>In the old days if it was eth0 yesterday >> it would still be eth0 today, but that doesn't happen anymore. The >> servers typically have 4 nics with 2 in use and it can be painful >> figuring how to assign the addresses and routes so the network >> connections work on a new box or a replacement OS. > > Get them by MAC, not as ethX. I.e., here I have in > /etc/sysconfig/network-scripts/ifcfg-eth0: > > # Intel Corporation 82573L Gigabit Ethernet Controller > DEVICE=eth0 > ONBOOT=yes > BOOTPROTO=dhcp > HWADDR=00:a0:d1:78:d7:c5 > > and the correct name is given to that eth. Thanks - that works in the replacement case if I have the foresight to snarf the current MAC addresses before the disk dies. (Is this documented somewhere and is it going to stay this way?) But an equally common case is that new machines are being rolled out and the hardware tech plugging the drive in doesn't know much about linux or what the MAC address is for the machine - and I can't connect to help until he gets at least one of them right. >> So, the generic question is, now that the system uses essentially >> random names for devices, is there a way, or a plan for a way, to deal >> with situations where many choices of new devices appear as a result >> of hardware changes, disk moves, backup/restores on new hardware, > > ... random hot(un)plugging, ... Of devices that I don't necessarily want mounted. > >> etc. and if so, will it require a GUI to deal with it? So far I've >> only heard the notion that these things should "just work" and I want >> to make sure that everybody knows it can't "just work" because the >> system can't possibly know want I want to do with a newly attached >> device > > The systen /can/ tell e.g. this is still the FooLaser printer serial > XYZ-ABCDE, even though it is connected through a different USB port today. > AFAICS, as things stand, the system is /not/ doing anything funky, it just > gives a way of finding out what is where (and the device has a clear ID); > and uses this if the device had been configured before. Things do get > tricky if you want to dd(1) disk images around, or are fond of serial > devices connected through USB-serial dongles, etc. But then you want the > system to do non-obvious stuff... I'd say most of what I do is non-obvious, which is why I've always liked unix systems that don't make wrong guesses and do what someone else thought should be the obvious thing. There's a place for the black magic stuff, of course, but how do you turn it off - for example when you are building/copying drive images that will run elsewhere or you just want raw device access for other reasons? And how do you identify the device from a set of choices? -- Les Mikesell lesmikesell at gmail.com From dbhole at redhat.com Fri Jan 11 22:12:02 2008 From: dbhole at redhat.com (Deepak Bhole) Date: Fri, 11 Jan 2008 17:12:02 -0500 Subject: Policy on introducing new packages for discontinued projects? Message-ID: <20080111221202.GC26001@redhat.com> Hi There, I'm working on updating maven2 in Fedora, and one of the dependencies that it is cascading into is Jakarta Slide. This project hasn't had updates for a while, and is now officially dead as stated on the main page: http://jakarta.apache.org/slide/index.html The component is not critical to core maven functionality, and can be disabled. My question is: What is Fedora policy for introducing new packages for defunct projects? Specially when those packages provide optional functionality... IMO the functionality should be disabled until maven2 moves to use a different project for WebDAV deployment. In the mean time, users using the Fedora maven2 will continue to be able to use the functionality, but it will just not work in offline mode (assuming we don't package Slide). Deepak From lesmikesell at gmail.com Fri Jan 11 22:15:42 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 11 Jan 2008 16:15:42 -0600 Subject: Linux is not about choice [was Re: Fedora too cutting edge?] In-Reply-To: <16de708d0801111351h381bd93fk1425ceaba8c86b33@mail.gmail.com> References: <4785163E.8010508@hhs.nl> <47864F28.4030708@gmail.com> <1199984962.30858.66.camel@oneill.fubar.dk> <47865662.2080701@gmail.com> <478741FB.9040305@gmail.com> <478779B2.5000706@gmail.com> <4787B49E.4090806@gmail.com> <4787D1EF.7070407@gmail.com> <16de708d0801111236q25f5277bs1a7eda1fb263e3f0@mail.gmail.com> <4787E33F.8080605@gmail.com> <16de708d0801111351h381bd93fk1425ceaba8c86b33@mail.gmail.com> Message-ID: <4787EA8E.1090104@gmail.com> Arthur Pemberton wrote: >>> On Jan 11, 2008 2:30 PM, Les Mikesell wrote: >>>> It doesn't seem as sensible as being able to plug into a known >>>> controller position and get a known device name, particularly in the >>>> scenario where the drives aren't hot-plug and you want to access a bunch >>>> of new ones after a reboot and know which is which. >>> >>> Frankly i like this idea, but I'm unsure of the practicality of it: >>> >>> What is the highest level which is even aware of the physical location >>> of said device? I would imagine the BIOS knows, and maybe some really >>> low level kernel modules but anything above that? >> The bios doesn't necessarily know anything except for the one(s) that it >> might boot. But I think there may be some extra magic in what the >> kernel does with the names depending on which drive bios used to boot. >> The stuff in /dev/disk/by-path might be useful for the versions that >> have it, but I can't see anything for the empty controller positions >> where the drives aren't connected so the arrangement doesn't make a lot >> of sense. > > > Then it seems to me that what you/i/we want can be accomplished with > soem clever udev rules. Yes, maybe, someday... I'm just not getting a warm and fuzzy feeling that there will be a reasonable mechanism for people to interact with this process to get deterministic behavior for the simplest thing, accessing a device by a name related to the hardware in some way. Shouldn't that come before magically attempting some high-level thing with hot-plugged unknowns or browsing that only makes sense in a GUI? -- Les Mikesell lesmikesell at gmail.com From jwilson at redhat.com Fri Jan 11 22:47:45 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 11 Jan 2008 17:47:45 -0500 Subject: Wanted: FireWire testers Message-ID: <4787F211.3010402@redhat.com> If you're among those who have voiced concerns with the FireWire support in Fedora, particularly in the audio/video area, please do try to test out the latest rawhide kernels (2.6.24-0.149.fc7.git2.fc9 or later) and/or the 2.6.23.13 kernel working its way through koji right now[1]. For the most part, dvgrab should be functional with these kernels, on all but Via VT630x chipsets in OHCI 1.0 mode[2]. IIDC video streaming (such as coriander + libdc1394 v2) should be fully functional on all OHCI 1.0 and 1.1 FireWire controllers. As yet untested with this latest kernel is FireWire video capture off a cable box[3], but that's on my todo list for the weekend. (There's reason to believe this might be working now with the addition of dynamic buffer allocation). Additional feedback on other open FireWire bugs would be appreciated as well[4][5]. Note that most of the enhancements added to the latest kernels are on the a/v side, but I plan to start looking at storage more soon as well... [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=343219 [2] https://bugzilla.redhat.com/show_bug.cgi?id=415841 [3] https://bugzilla.redhat.com/show_bug.cgi?id=240774 [4] https://bugzilla.redhat.com/show_bug.cgi?id=243081 [5] https://bugzilla.redhat.com/show_bug.cgi?id=370931 -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From lesmikesell at gmail.com Fri Jan 11 23:02:24 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 11 Jan 2008 17:02:24 -0600 Subject: Wanted: FireWire testers In-Reply-To: <4787F211.3010402@redhat.com> References: <4787F211.3010402@redhat.com> Message-ID: <4787F580.2030405@gmail.com> Jarod Wilson wrote: > If you're among those who have voiced concerns with the FireWire support in > Fedora, particularly in the audio/video area, please do try to test out the > latest rawhide kernels (2.6.24-0.149.fc7.git2.fc9 or later) and/or the > 2.6.23.13 kernel working its way through koji right now[1]. > > For the most part, dvgrab should be functional with these kernels, on all but > Via VT630x chipsets in OHCI 1.0 mode[2]. IIDC video streaming (such as > coriander + libdc1394 v2) should be fully functional on all OHCI 1.0 and 1.1 > FireWire controllers. > > As yet untested with this latest kernel is FireWire video capture off a cable > box[3], but that's on my todo list for the weekend. (There's reason to believe > this might be working now with the addition of dynamic buffer allocation). > > Additional feedback on other open FireWire bugs would be appreciated as > well[4][5]. Note that most of the enhancements added to the latest kernels are > on the a/v side, but I plan to start looking at storage more soon as well... As a perhaps odd case, is it likely to be possible to build an initrd containing the firewire driver and have firewire drives included in md devices recognized and matched correctly during boot-up? -- Les Mikesell lesmikesell at gmail.com From pertusus at free.fr Fri Jan 11 23:00:53 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 12 Jan 2008 00:00:53 +0100 Subject: Policy on introducing new packages for discontinued projects? In-Reply-To: <20080111221202.GC26001@redhat.com> References: <20080111221202.GC26001@redhat.com> Message-ID: <20080111230053.GA4100@free.fr> On Fri, Jan 11, 2008 at 05:12:02PM -0500, Deepak Bhole wrote: > Hi There, > > I'm working on updating maven2 in Fedora, and one of the dependencies > that it is cascading into is Jakarta Slide. This project hasn't had > updates for a while, and is now officially dead as stated on the main > page: > > http://jakarta.apache.org/slide/index.html > > What is Fedora policy for introducing new packages for defunct projects? > Specially when those packages provide optional functionality... It depends on the reason why it is defunct. If it is because it works since a long time, such that nobody needs to take care of it, then it is a very good thing. If it is a package abandoned although it is not very stable, then if a packager wants to keep it in fedora he'll have to be prepared to be more or less the upstream. So this is left to the packager, but in the precise case you bring up, I'd suggest retiring the package http://fedoraproject.org/wiki/PackageMaintainers/RetiredPackages especially since there is a replacement. And indeed stop using that functionality. If not, then be prepared to do the patching yourself. -- Pat From jos at xos.nl Fri Jan 11 23:38:41 2008 From: jos at xos.nl (Jos Vos) Date: Sat, 12 Jan 2008 00:38:41 +0100 Subject: Start/stop of OpenVPN interfaces with ifup/ifdown Message-ID: <200801112338.m0BNcflD031668@jasmine.xos.nl> Hi, The Fedora OpenVPN package starts/stops all VPN connections together via a single init script. The classical way of handling interfaces in Red Hat / Fedora distros is to support new interface types via ifup/ifdown scripts. This is also the way it worked in the past for CIPE. In some situations this is a much better way to control your connections (i.e. being able to start/stop them separately). I see in that some work on this has already been done in this area. My questions: - Is there a technical reason to not handle OpenVPN connections this way in Fedora or is it just that it was decided to stay more close to the generic OpenVPN startup script? - Does anyone know of recent work in this area? I guess the example scripts in the thread I listed above might not work as-is with the current Fedora and OpenVPN versions. - Is there any interest in including (and maintaining) this in Fedora's OpenVPN package, maybe just as an alternative startup method, assuming someone wants to contribute the initial implementation? Thanks, -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From andrewparker at bigfoot.com Fri Jan 11 23:56:47 2008 From: andrewparker at bigfoot.com (Andrew Parker) Date: Fri, 11 Jan 2008 18:56:47 -0500 Subject: Start/stop of OpenVPN interfaces with ifup/ifdown In-Reply-To: <200801112338.m0BNcflD031668@jasmine.xos.nl> References: <200801112338.m0BNcflD031668@jasmine.xos.nl> Message-ID: <6c3f5e6c0801111556s22a5d6c6p89438cd6d3917364@mail.gmail.com> On Jan 11, 2008 6:38 PM, Jos Vos wrote: > Hi, > > The Fedora OpenVPN package starts/stops all VPN connections together > via a single init script. The classical way of handling interfaces > in Red Hat / Fedora distros is to support new interface types via > ifup/ifdown scripts. This is also the way it worked in the past for > CIPE. In some situations this is a much better way to control your > connections (i.e. being able to start/stop them separately). > > I see in > that some work on this has already been done in this area. > > My questions: > > - Is there a technical reason to not handle OpenVPN connections this > way in Fedora or is it just that it was decided to stay more close > to the generic OpenVPN startup script? > > - Does anyone know of recent work in this area? I guess the example > scripts in the thread I listed above might not work as-is with the > current Fedora and OpenVPN versions. > > - Is there any interest in including (and maintaining) this in Fedora's > OpenVPN package, maybe just as an alternative startup method, > assuming someone wants to contribute the initial implementation? > Personally I would like to see this and the mounting/unmounting of network shares wired up to NetworkManager. For my purposes, NM doesn't quite cut it as when I change wired to wireless, I need to unmount shares, shut down vpn, change network, start up vpn, mount shares again. Consequently I have some ugly scripts to do this work for me, but I would be much happier if NM would do the job for me. From mjs at CLEMSON.EDU Fri Jan 11 23:57:28 2008 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Fri, 11 Jan 2008 18:57:28 -0500 Subject: thinkpad-acpi upstream version? In-Reply-To: <4787AA76.4050105@poolshark.org> References: <47852A26.4010609@fedoraproject.org> <364d303b0801091641y763baef2y12a95bde37547c42@mail.gmail.com> <47866320.1040606@redhat.com> <4786653C.5020204@fedoraproject.org> <47868933.6060008@redhat.com> <1200010908.20425.6.camel@vincent52.localdomain> <478789EA.50302@redhat.com> <20080111165311.GU29887@angus.ind.WPI.EDU> <4787AA76.4050105@poolshark.org> Message-ID: <1200095848.14605.18.camel@vincent52.localdomain> On Fri, 2008-01-11 at 18:42 +0100, Denis Leroy wrote: > Chuck Anderson wrote: > > On Fri, Jan 11, 2008 at 10:23:22AM -0500, Jarod Wilson wrote: > >> Matthew Saltzman wrote: > >>> On Thu, 2008-01-10 at 16:08 -0500, Jarod Wilson wrote: > >>>> Nicolas Antonio Corrarello wrote: > >>>>> Maybe you're in the same condition as I am (Also T61 user, great > >>>>> machine)... Can't make the volume > >>>>> up/down keys to work, and I can't change the volume through > >>>>> /proc/acpi/ibm/volume. I'll see if this is solved in the thinkpad-acpi > >>>>> changelog and file a bug... > >>>> Ah yes, mine has the same issue with 2.6.23.12 right now, forgot about that. > >>>> Heck, *I* should have filed a bug already... But I'll let you. :) > >>>> > >>>> Also, the brightness keys don't do anything on mine, though that may be > >>>> resolved in rawhide via xbacklight, iirc. Rawhide was a bit too explodey for > >>>> me to want to upgrade to it just yet though. > >>> Which video driver? > >> Intel X3100 graphics, 1680x1050 display, intel video driver. > > > > On my ThinkPad T61 with Intel graphics, 1680x1050 display, my > > brightness keys cause the brightness on-screen display bar graph to > > appear, but the brightness doesn't actually change until I hit the > > very top of the scale, then it goes bright immediately. It also > > reacts very slowly to each key stroke. > > On my T61 (Nvidia Quadro NVS-140M), suspend works, but the brightness > keys and sound keys do not work. I also get the bar graph, but actual > brightness doesn't change at all That's very strange, as the conventional wisdom is that the suspend issues are nVidia related. If you don't mind my quizzing you a bit... - Are you suspending to RAM or hibernating to disk? If you're using GNOME, what options do you see if you left-click the battery/AC icon? How are you actually suspending? - What driver for the video card? Brightness control works for me with the vesa driver and the latest nVidia binary driver (169.04 or later), but not earlier ones. The nv driver doesn't work at all, but there is an update in the queue that should work. - What kernel, and what is the exact model number of your T61? Could you post or send me the results of lsmod, lshal, and lspci -v ? Could you check the BIOS version? Thanks! -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From kmaraas at broadpark.no Sat Jan 12 00:50:18 2008 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Sat, 12 Jan 2008 01:50:18 +0100 Subject: Intel compiler integration tool release In-Reply-To: <870180fe0801111237q1ffc1f24p265d8e06ddcbcc19@mail.gmail.com> References: <870180fe0801111237q1ffc1f24p265d8e06ddcbcc19@mail.gmail.com> Message-ID: <1200099018.3853.1.camel@localhost.localdomain> fr., 11.01.2008 kl. 13.37 -0700, skrev Jerry James: > I have just released attempt #3 at integrating the Intel C/C++ > compilers and debugger into a Fedora system. My earlier attempts were > named fedora-icc and icc-extras, respectively. I've changed the name > yet again. This time it is called intel-extras (because Intel has > some other tools that need integrating, so the package will grow to > include them over time). The major issue with my previous attempts > was tracking new Intel releases. Non-paying schmucks like me don't > get access to the same versions as paying customers, so releasing new > versions of the package that did nothing but bump the Intel version > number just didn't cut it. This time, I have included a script, > intel-update, that automatically detects the latest version (or > optionally, a specified version) of the Intel tools on your system and > integrates that version into Fedora. > > Get it here: http://jjames.fedorapeople.org/intel-extras/ (WARNING: > ugly web page alert!). > > The earlier attempts were in the public domain. This is a complete > rewrite, and this time I'm releasing it under an MIT license. A > person who understands liability better than I do talked me into this > change. I'm willing to help Intel make this package completely > unnecessary, free of charge. > > There are now actual man pages. They contain important information. > Please read them. > > If there is sufficient interest in this, I'll try to find a good home > to host the project for the long term. If only the < 5 people who > tried out my earlier attempts use it, I probably won't bother. > > I tried to makes the scripts work with bash, ksh, and zsh. I believe > they work with all 3. If you find otherwise, it's a bug. Please let > me know. > > Since one version of my package has to work with multiple Intel > versions, there is some ugliness in the version number handling. I > don't see a better way to deal with the situation. If you do, please > enlighten me. > > While I have tested this new release on both x86 and x86_64 platforms, > there are bound to be some bugs. Please use this product with > caution. In particular, please back up your system before you try it > out. Do I need to install icc in a particular prefix for this package to pick it up? I just did a default install of icc 10.1 and I don't see how to use your package to invoke it? Cheers Kjartan From lightsolphoenix at gmail.com Sat Jan 12 02:00:37 2008 From: lightsolphoenix at gmail.com (Kelly Miller) Date: Fri, 11 Jan 2008 21:00:37 -0500 Subject: use defoma in fedora? In-Reply-To: <20080110200431.GG2638@free.fr> References: <20080110194622.GF2638@free.fr> <20080110200431.GG2638@free.fr> Message-ID: <47881F45.1060006@gmail.com> Patrice Dumas wrote: > Is there something fundamentaly broken in defoma, or is it a bug you are > describing? I don't know which it is. I do know, however, I was able to repeatedly reproduce it, using different versions of both regular Debian and Debian-based systems (Ubuntu, LinuxMint, even Freespire once), over a period of about two years. As I said, it's the primary reason I stopped using Debian-based systems altogether and switched permanently to a combination of Fedora and PCLinuxOS (for those who need something simpler). From yabraham2 at gmail.com Sat Jan 12 02:58:54 2008 From: yabraham2 at gmail.com (yonas Abraham) Date: Fri, 11 Jan 2008 21:58:54 -0500 Subject: gdm: gnome-keyring problem Message-ID: <47324ed80801111858k55031ad2xab3d57c80244bbaa@mail.gmail.com> Hi, I am having this weird problem. on login via gdm on an up2dated rawhide syetem, i get a back screen with just the corser visible. if I login to that system via ssh from a diffrent PC on the network and look at the /var/log/message, I see Jan 11 21:12:04 siempc gdm-simple-slave[3077]: DEBUG: Writing wtmp session record to /var/log/wtmp Jan 11 21:12:04 siempc gdm-simple-slave[3077]: DEBUG: Adding new utmp record Jan 11 21:12:04 siempc gdm-simple-slave[3077]: DEBUG: GdmSimpleSlave: session started Jan 11 21:12:04 siempc gnome-keyring-daemon[3173]: Couldn't unlock login keyring with provided password Jan 11 21:12:04 siempc gnome-keyring-daemon[3173]: Failed to unlock login on startup Jan 11 21:12:04 siempc gconfd (yonas-3237): starting (version 2.21.1), pid 3237 user 'yonas' Jan 11 21:12:04 siempc gconfd (yonas-3237): Resolved address "xml:readonly:/etc/gconf/gconf.xml.mandatory" to a read-only configuration source at position 0 Jan 11 21:12:04 siempc gconfd (yonas-3237): Resolved address "xml:readwrite:/home/yonas/.gconf" to a writable configuration source at position 1 Jan 11 21:12:04 siempc gconfd (yonas-3237): Resolved address "xml:readonly:/etc/gconf/gconf.xml.system" to a read-only configuration source at position 2 Jan 11 21:12:04 siempc gconfd (yonas-3237): Resolved address "xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only configuration source at position 3 if i hit Alt+Ctrl+Backspace, the server die and I get no signal on the monitor. I can't even go to Alt+F1 . On the log file, I see: Jan 11 21:53:24 siempc gdm-simple-slave[3077]: DEBUG: GdmServer: child (pid:3079) done (status:0) the only way i can get any signal is, to do: telinit 3 telinit 5 most of the time this brings signal to the monitor. any idea? /Yonas From mark.bidewell at alumni.clemson.edu Sat Jan 12 03:32:04 2008 From: mark.bidewell at alumni.clemson.edu (Mark Bidewell) Date: Fri, 11 Jan 2008 19:32:04 -0800 Subject: F8 + rawhide in Qemu Message-ID: I installed F8 in Qemu in order to test rawhide. However, after I updated recently I no longer have network connectivity (the NIC is gone). Have any of you run into this issue? Mark Bidewell -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschwendt.tmp0701.nospam at arcor.de Sat Jan 12 05:50:47 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 12 Jan 2008 06:50:47 +0100 Subject: F8 + rawhide in Qemu In-Reply-To: References: Message-ID: <20080112065047.04cb96d7.mschwendt.tmp0701.nospam@arcor.de> On Fri, 11 Jan 2008 19:32:04 -0800, Mark Bidewell wrote: > I installed F8 in Qemu in order to test rawhide. However, after I updated > recently I no longer have network connectivity (the NIC is gone). Have any > of you run into this issue? Yes, here the interface config scripts all got renamed to *.bak, so temporarily I needed to "ifup eth1.bak" until I fixed the filenames. From kevin.kofler at chello.at Sat Jan 12 05:54:12 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 12 Jan 2008 05:54:12 +0000 (UTC) Subject: F8 + rawhide in Qemu References: Message-ID: Mark Bidewell alumni.clemson.edu> writes: > I installed F8 in Qemu in order to test rawhide.? However, after I updated > recently? I no longer have network connectivity (the NIC is gone).? Have any > of you run into this issue? If you upgraded the host from F7 to F8, you have to reconfigure the network in your guest image, the default emulated NIC in QEMU has changed from ne2k_pci to rtl8139 in Fedora 8 and later. According to the changelog, this was changed because rtl8139 supports linkstate reporting. Alternatively, you can explicitly tell QEMU on the command line to emulate an ne2k_pci network card. Kevin Kofler From jos at xos.nl Sat Jan 12 08:19:52 2008 From: jos at xos.nl (Jos Vos) Date: Sat, 12 Jan 2008 09:19:52 +0100 Subject: Start/stop of OpenVPN interfaces with ifup/ifdown In-Reply-To: <6c3f5e6c0801111556s22a5d6c6p89438cd6d3917364@mail.gmail.com> References: <200801112338.m0BNcflD031668@jasmine.xos.nl> <6c3f5e6c0801111556s22a5d6c6p89438cd6d3917364@mail.gmail.com> Message-ID: <20080112081952.GA3251@jasmine.xos.nl> On Fri, Jan 11, 2008 at 06:56:47PM -0500, Andrew Parker wrote: > Personally I would like to see this and the mounting/unmounting of > network shares wired up to NetworkManager. For my purposes, NM > doesn't quite cut it as when I change wired to wireless, I need to > unmount shares, shut down vpn, change network, start up vpn, mount > shares again. Consequently I have some ugly scripts to do this work > for me, but I would be much happier if NM would do the job for me. I'm personally not interested in NM, but only in the abillity to control individual OpenVPN connections in scripts and manually via the ifup/ifdown commands. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From rhally at mindspring.com Sat Jan 12 10:50:15 2008 From: rhally at mindspring.com (Richard Hally) Date: Sat, 12 Jan 2008 05:50:15 -0500 Subject: anaconda traceback Message-ID: <47889B67.9050507@mindspring.com> When trying to do a network install of rawhide I get the following: (using the boot.iso from rawhide) After retrieving images/stage2.img, "Running anaconda 11.4.0.18, the Fedora installer, please wait... traceback(most recent call last) file "/usr/bin/anaconda" line 623 in from exception import handleException file "/usr/lib/anaconda/exception.py" line 41 in import kickstart file "/use/lib/anaconda/kickstart.py" line 36 in import upgrade file "/usr/lib/anaconda/upgrade.py" line 31 in import selinux Import Error: no module named selinux install exited abnormally [1/1]" ... ok to reboot etc anyone tried installing the current rawhide? does this need a Bugzilla? Richard From mike at miketc.com Sat Jan 12 11:17:31 2008 From: mike at miketc.com (Mike Chambers) Date: Sat, 12 Jan 2008 05:17:31 -0600 Subject: anaconda traceback In-Reply-To: <47889B67.9050507@mindspring.com> References: <47889B67.9050507@mindspring.com> Message-ID: <1200136651.2642.0.camel@scrappy.miketc.com> On Sat, 2008-01-12 at 05:50 -0500, Richard Hally wrote: > When trying to do a network install of rawhide I get the following: > > (using the boot.iso from rawhide) > > After retrieving images/stage2.img, > > "Running anaconda 11.4.0.18, the Fedora installer, please wait... > traceback(most recent call last) > file "/usr/bin/anaconda" line 623 in > from exception import handleException > file "/usr/lib/anaconda/exception.py" line 41 in > import kickstart > file "/use/lib/anaconda/kickstart.py" line 36 in > import upgrade > file "/usr/lib/anaconda/upgrade.py" line 31 in > import selinux > Import Error: no module named selinux > install exited abnormally [1/1]" Happened to me as well, yesterday or day before I think it was, same message. I didn't bugzilla it though, figured it was known. -- Mike Chambers Madisonville, KY "The best lil town on Earth!" From pertusus at free.fr Sat Jan 12 11:53:28 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 12 Jan 2008 12:53:28 +0100 Subject: graphically show dependencies Message-ID: <20080112115328.GA2598@free.fr> Hello, I remember that there was a tool to show graphically the package dependencies. Did I dream? If not, where is it? -- Pat From lordmorgul at gmail.com Sat Jan 12 12:24:25 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sat, 12 Jan 2008 04:24:25 -0800 Subject: anaconda traceback In-Reply-To: <47889B67.9050507@mindspring.com> References: <47889B67.9050507@mindspring.com> Message-ID: <4788B179.4000901@gmail.com> Richard Hally wrote: > When trying to do a network install of rawhide I get the following: > > (using the boot.iso from rawhide) > > After retrieving images/stage2.img, > > "Running anaconda 11.4.0.18, the Fedora installer, please wait... > traceback(most recent call last) > file "/usr/bin/anaconda" line 623 in > from exception import handleException > file "/usr/lib/anaconda/exception.py" line 41 in > import kickstart > file "/use/lib/anaconda/kickstart.py" line 36 in > import upgrade > file "/usr/lib/anaconda/upgrade.py" line 31 in > import selinux > Import Error: no module named selinux > install exited abnormally [1/1]" > > ... > ok to reboot etc > > anyone tried installing the current rawhide? does this need a Bugzilla? > > Richard Looks like a new anaconda was built this morning but not sure if the image builds succeeded to try it with. I was planning to try a rawhide net install later today myself. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From sgrubb at redhat.com Sat Jan 12 12:52:19 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Sat, 12 Jan 2008 07:52:19 -0500 Subject: graphically show dependencies In-Reply-To: <20080112115328.GA2598@free.fr> References: <20080112115328.GA2598@free.fr> Message-ID: <200801120752.19888.sgrubb@redhat.com> On Saturday 12 January 2008 06:53:28 Patrice Dumas wrote: > I remember that there was a tool to show graphically the package > dependencies. Did I dream? If not, where is it? rpmgraph shows you the runtime dependencies that are in the rpm. Notably, rpmbuild does not figure out shell script dependencies, so that is missing. (But it could with a little work by scanning installed packages for shell scripts and running bash --rpm-requires $TARGET). I also wrote a utility for the rookery build system that captures the build time dependencies suitable for graphing which is a little different than runtime. This was to allow analysis of code or subsystem changes to see what might be affected. -Steve From buildsys at redhat.com Sat Jan 12 12:58:55 2008 From: buildsys at redhat.com (Build System) Date: Sat, 12 Jan 2008 07:58:55 -0500 Subject: rawhide report: 20080112 changes Message-ID: <200801121258.m0CCwtxo012628@porkchop.devel.redhat.com> New package gpicview A Simple and Fast Image Viewer for X New package halevt Generic handler for HAL events New package kitsune Program to solve mathematical problems New package rudecgi Library (C++ API) for reading CGI form data Removed package libopensync-plugin-sunbird Removed package multisync Removed package libopensync-plugin-synce Removed package tcl-tcldict Updated Packages: Ri-li-2.0.1-2.fc9 ----------------- * Fri Jan 11 2008 Hans de Goede 2.0.1-2 - Fix compilation with gcc 4.3 VLGothic-fonts-20071215-1.fc9 ----------------------------- * Sat Jan 12 2008 Ryo Dairiki - 20071215-1 - Update to 20071215 * Thu Oct 18 2007 Ryo Dairiki - 20071015-2 - Rename the font directory. - Fix font selection problem in Flash 9. - Make it remove the old configuration files on updating. * Thu Oct 18 2007 Ryo Dairiki - 20071015-1 - Update to 20071015 - Make it separated into subpackages amarok-1.4.8-2.fc9 ------------------ * Wed Jan 09 2008 Rex Dieter 1.4.8-2 - f9+: don't build/include konq(3) side bar support * Thu Dec 20 2007 Rex Dieter 1.4.8-1 - amarok-1.4.8 * Fri Dec 07 2007 Alex Lancaster 1.4.7-14 - Rebuild for new openssl anaconda-11.4.0.19-1 -------------------- * Fri Jan 11 2008 Chris Lumens - 11.4.0.19-1 - Make sure the arch is listedat the top of all loader screens. (clumens) - Add the version number really early in the log file too. (clumens) - Require latest libdhcp (dcantrell) - Add nicdelay parameter to loader, so we can wait before sending DHCP requests. (msivak) - Add dhcpdelay to loader so we can modify the default dhcp timeout (#198147, #254032). (msivak) - Fix the selected device when disabling entries in Add advanced drive dialog. (#248447) (msivak) - Include mkfs.gfs2 (#356661). (clumens) - Use the new default Japanese font (#428070). (clumens) - More urlinstall loader fixes. (clumens) apt-0.5.15lorg3.94-1.fc9 ------------------------ * Fri Jan 11 2008 Panu Matilainen 0.5.15lorg3.94-1 - update to 0.5.15lorg3.94, should fix #222927, #246866, #279921, and #419811 - update rpmpriorities to match current package set (#426143) audit-1.6.5-3.fc9 ----------------- * Fri Jan 11 2008 Steve Grubb 1.6.5-3 - Updates for spec file review - Adjust permission on selinux policy file avrdude-5.5-2.fc9 ----------------- * Fri Jan 11 2008 Trond Danielsen - 5.5-2 - Added patch for 64-bit systems. - Corrected the URL to the avrude homepage. bcfg2-0.9.5.5-1.fc9 ------------------- * Fri Jan 11 2008 Jeffrey C. Ollie - 0.9.5.5-1 - Update to 0.9.5.5 - More egg-info entries. bochs-2.3.6-2.fc9 ----------------- * Fri Jan 11 2008 Hans de Goede 2.3.6-2 - Fix compilation with gcc 4.3 control-center-1:2.21.4-3.fc9 ----------------------------- * Fri Jan 11 2008 - Bastien Nocera - 2.21.4-3 - Remove duplicated sylpheed entry (#428363) drupal-5.6-1.fc9 ---------------- * Fri Jan 11 2008 Jon Ciesla - 5.6-1 - Upgrade to 5.6, upstream security fixes. ds9-5.1-1.fc9 ------------- * Tue Jan 08 2008 Sergio Pascual 5.1-1 - New upstream source - Reorganized patches * Sat Dec 08 2007 Sergio Pascual 5.0-6 - Fixed problems with TCL package loading * Tue Dec 04 2007 Sergio Pascual 5.0-5 - Reverting tcllib patch, using package require instead fortune-mod-1.99.1-10.fc9 ------------------------- * Fri Jan 11 2008 Jeff Sheltren 1.99.1-10 - Rebuild for F9 gcdmaster-1.2.2-3.fc8 --------------------- * Mon Dec 24 2007 Denis Leroy - 1.2.2-3 - Added patches from current cdrdao package glibc-2.7.90-4 -------------- * Fri Jan 11 2008 Jakub Jelinek 2.7.90-4 - update to trunk - misc fixes (BZ#5541, BZ#5545, BZ#5553, BZ#5112, BZ#5520) - getaddrinfo fixes - signalize EOVERFLOW from sem_post instead of overflowing the counter - fix i?86 makecontext - fix iconv for iso-2022-jp//translit (#397021) gnu-efi-3.0d-2.fc9 ------------------ * Fri Jan 11 2008 Peter Jones - 3.0d-2 - Get rid of a bogus #ifdef . gstreamer-plugins-good-0.10.6-7.fc9 ----------------------------------- * Fri Jan 11 2008 Adam Jackson 0.10.6-7 - gst-plugins-good-0.10.6-v4l2-min-buffers.patch: Be sure to get at least GST_V4L2_MIN_BUFFERS from the source. (#316931) - gst-plugins-good-0.10.6-artist-sortname.patch: Avoid using a deprecated icu-3.8.1-2.fc9 --------------- * Fri Jan 11 2008 Caolan McNamara - 3.8.1-2 - remove icu.icu5365.dependantvowels.patch and cleanup icu.icu5506.multiplevowels.patch as they patch and unpatch eachother (thanks George Rhoten for pointing out that madness) * Fri Jan 11 2008 Caolan McNamara - 3.8.1-1 - latest version - drop fixed icu.icu6084.zwnj.notdef.patch itcl-3.4-1.fc9 -------------- * Thu Jan 10 2008 Wart - 3.4-0.1 - Update to latest CVS head for tcl 8.5 compatibility itk-3.4-1.fc9 ------------- * Fri Jan 11 2008 Wart - 3.4-1 - Update to latest CVS head for tcl 8.5 compatibility iwidgets-4.0.2-1.fc9 -------------------- * Fri Jan 11 2008 Wart - 4.0.2-1 - Update to 4.0.2 using a patch from CVS - Rebuild for tcl 8.5 kernel-xen-2.6-2.6.21.7-2892.fc9 -------------------------------- * Fri Jan 11 2008 Daniel P. Berrange - Rebuild due to koji build system failure * Thu Jan 10 2008 Daniel P. Berrange - Update HV to 3.2.0 rc5 changeset 16701 libselinux-2.0.47-1.fc9 ----------------------- * Fri Jan 11 2008 Dan Walsh - 2.0.47-1 - Fix memory references in audit2why and change to use tuples - Update to Upstream * Fix for the avc: granted null message bug from Stephen Smalley. * Fri Jan 11 2008 Dan Walsh - 2.0.46-6 - Fix __init__.py specification libxml2-2.6.31-1 ---------------- * Fri Jan 11 2008 Daniel Veillard 2.6.31-1.fc9 - upstream release 2.6.31 see http://xmlsoft.org/news.html - many bug fixed upstream libzip-0.8-4.fc9 ---------------- * Fri Jan 11 2008 Rex Dieter 0.8-4 - use better workaround for removing rpaths m2crypto-0.18.2-3 ----------------- * Fri Jan 11 2008 Miloslav Trma?? - 0.18.2-3 - Ship Python egg information man-pages-2.75-1.fc9 -------------------- * Fri Jan 11 2008 Ivana Varekova - 2.75-1 - update to 2.75 - remove fs page patch * Mon Dec 17 2007 Ivana Varekova - 2.73-1 - update to 2.73 * Tue Dec 04 2007 Ivana Varekova - 2.69-1 - update to 2.69 octave-6:3.0.0-2.fc9 -------------------- * Wed Jan 09 2008 Quentin Spencer 3.0.0-2 - Add curl-devel and pcre-devel as build dependencies. Closes bug 302231. opengl-games-utils-0.1-5.fc9 ---------------------------- * Fri Jan 11 2008 Hans de Goede 0.1-5 - Fix DRI detection to work with dual head configurations pam_mysql-1:0.7-0.3.rc1.fc9 --------------------------- * Wed Jan 09 2008 lonely wolf - 0.7-0.1.rc1.1 - couple of fixes php-5.2.5-5 ----------- * Fri Jan 11 2008 Joe Orton 5.2.5-5 - ext/date: use system timezone database pilot-link-2:0.12.3-6.fc9 ------------------------- * Fri Jan 11 2008 Ivana Varekova - 2:0.12.3-6 - Synchronize with F-8 branch: - remove visor modul remove from %post script - Change README.fedora use "ttyUSB[13579]" in 60-pilot.rules policycoreutils-2.0.35-1.fc9 ---------------------------- * Fri Jan 11 2008 Dan Walsh 2.0.35-1 - Update to upstream * Merged support for non-interactive newrole command invocation from Tim Reed. * Tue Jan 08 2008 Dan Walsh 2.0.34-8 - Change to use selinux bindings to audit2why procps-3.2.7-18.fc9 ------------------- * Fri Jan 11 2008 Tomas Smetana 3.2.7-18 - fix displaying the CPU column as integer (related #354001) - don't install slabtop -- there's no /proc/slabinfo python-4Suite-XML-1.0.2-2 ------------------------- * Fri Jan 11 2008 Miloslav Trma?? - 1.0.2-2 - Ship Python egg information quake3-1.34-0.7.rc4.fc9 ----------------------- * Fri Jan 11 2008 Hans de Goede 1.34-0.7.rc4 - Various patches to make openarena work with the generic ioquake3 we ship - Update urbanterror launcher script to set a much bigger com_hunkMegs, otherwise urbanterror will abort when loading bigger levels ruby-RMagick-2.1.0-1.fc9 ------------------------ * Fri Jan 11 2008 Mamoru Tasaka - 2.1.0-1 - 2.1.0 scorched3d-41.1-2.fc9 --------------------- * Fri Jan 11 2008 Hans de Goede 41.1-2 - Fix compilation with gcc 4.3 selinux-policy-3.2.5-10.fc9 --------------------------- * Mon Jan 07 2008 Dan Walsh 3.2.5-10 - dontaudit pam_t and dbusd writing to user_home_t setroubleshoot-2.0.2-1.fc9 -------------------------- * Fri Jan 11 2008 - 2.0.2-1 - Resolve bug #428252: Problem with update/remove old version - Add code to validate xml database version, if file is incompatible it is not read, the next time the database is written it will be in the new version format. This means the database contents are not preserved across database version upgrades. - Remove postun trigger from spec file used to clear database between incompatible versions the new database version check during database read will handle this instead - bullet proof exit status in init script and rpm scriptlets - Resolve bug #247302: setroubleshoot's autostart .desktop file fails to start under a KDE session - Resolve bug #376041: Cannot check setroubleshoot service status as non-root - Resolve bug #332281: remove obsolete translation - Resolve bug #344331: No description in gnome-session-properties - Resolve bug #358581: missing libuser-python dependency - Resolve bug #426586: Renaming translation po file from sr at Latn to sr at latin - Resolve bug #427260: German Translation - enhance the sealert man page * Fri Jan 04 2008 - 2.0.1-1 - make connection error message persist instead of timeout in browser - updated Brazilian Portuguese translation: Igor Pires Soares - implement uid,username checks - rpc methods now check for authenticated state - fix html handling of summary string - add 'named' messages to status bar, make sure all messages either timeout or are named - fix ordering of menus, resolves bug #427418 - add 'hide quiet' to browser view filtering, resolves bug #427421 - tweak siginfo text formatting - add logon to SECommandLine so that sealert -l works setroubleshoot-plugins-2.0.1-1.fc9 ---------------------------------- * Fri Jan 11 2008 - 2.0.1-1 - Resolve bug #332281: remove obsolete translation - Resolve bug #426586: Renaming translation po file from sr at Latn to sr at latin snownews-1.5.8-1.fc9 -------------------- * Fri Jan 11 2008 Zing - 1.5.8-1 - update to 1.5.8 - remove manpath and softlink patch (upstream) - update charset patch (utf-8 enabled in configure) - snowsync program removed soundtouch-1.3.1-9.fc9 ---------------------- * Fri Jan 11 2008 Hans de Goede 1.3.1-9 - Fix compilation with gcc 4.3 supertuxkart-0.3-3.fc9 ---------------------- * Fri Jan 11 2008 Hans de Goede 0.3-3 - Fix compilation with gcc 4.3 system-config-date-1.9.20-1.fc9 ------------------------------- * Fri Jan 11 2008 Nils Philippsen - 1.9.20-1 - use config-util for userhelper configuration from Fedora 9 on (#428394) system-config-nfs-1.3.35-1.fc9 ------------------------------ * Fri Jan 11 2008 Nils Philippsen - 1.3.35-1 - use config-util for userhelper configuration from Fedora 9 on (#428399) system-config-samba-1.2.60-1.fc9 -------------------------------- * Fri Jan 11 2008 Nils Philippsen - 1.2.60-1 - use config-util for userhelper configuration from Fedora 9 on (#428393) system-config-services-0.9.19-1.fc9 ----------------------------------- * Fri Jan 11 2008 Nils Philippsen - 0.9.19-1 - use config-util for userhelper configuration from Fedora 9 on (#428407) system-config-users-1.2.75-1.fc9 -------------------------------- * Fri Jan 11 2008 Nils Philippsen - 1.2.75-1 - use config-util for userhelper configuration from Fedora 9 on (#428403) t1lib-5.1.2-1.fc9 ----------------- * Sat Jan 12 2008 Patrice Dumas - 5.1.2-1 - update to 5.1.2 tokyocabinet-1.1.7-1.fc9 ------------------------ * Fri Jan 11 2008 Deji Akingunola - 1.1.7-1 - Update to 1.1.7 virt-viewer-0.0.2-3.fc9 ----------------------- * Fri Jan 11 2008 Daniel P. Berrange - 0.0.2-3.fc9 - Set domain name as window title - Hide input for passwd fields during auth wine-0.9.53-1.fc9 ----------------- * Sat Jan 12 2008 Andreas Bierfert - 0.9.53-1 - version upgrade wine-docs-0.9.53-1.fc9 ---------------------- * Sat Jan 12 2008 Andreas Bierfert - 0.9.53-1 - version upgrade * Fri Dec 28 2007 Andreas Bierfert - 0.9.52-1 - version upgrade xarchon-0.50-6.fc9 ------------------ * Fri Jan 11 2008 Hans de Goede 0.50-6 - Fix compilation with gcc 4.3 xu4-1.1-0.3.cvs20070510.fc9 --------------------------- * Fri Jan 11 2008 Hans de Goede 1.1-0.3.cvs20070510 - Fix compilation with gcc 4.3 xulrunner-1.9-0.beta2.8.fc9 --------------------------- * Wed Jan 09 2008 Martin Stransky 1.9-0.beta2.8 - divided devel package to devel and devel-unstable ypbind-3:1.20.4-3.fc9 --------------------- * Fri Jan 11 2008 Steve Dickson - 3:1.20.4-3 - Fixed init script to wait for ypbind to come up. (bz 322101) Broken deps for i386 ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.i386 requires libgtkembedmoz.so epiphany-extensions - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 gcl - 2.6.7-15.fc8.i386 requires libtk8.4.so gcl - 2.6.7-15.fc8.i386 requires libtcl8.4.so gdal-perl - 1.5.0-1.fc9.i386 requires perl(Geo::GDAL::Const) gnome-web-photo - 0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.i386 requires libgtkembedmoz.so gnome-web-photo - 0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 kazehakase - 0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 netgen - 1.3.7-13.fc9.i386 requires libtk8.4.so netgen - 1.3.7-13.fc9.i386 requires libtcl8.4.so openoffice.org-devel - 1:2.4.0-1.1.fc9.i386 requires sdk openoffice.org-devel - 1:2.4.0-1.1.fc9.i386 requires /bin/python openoffice.org-devel - 1:2.4.0-1.1.fc9.i386 requires /usr/solar/bin/perl tkinter - 2.5.1-20.fc9.i386 requires libTix8.4.so vtk - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtcl8.4.so Broken deps for x86_64 ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gcl - 2.6.7-15.fc8.x86_64 requires libtk8.4.so()(64bit) gcl - 2.6.7-15.fc8.x86_64 requires libtcl8.4.so()(64bit) gdal-perl - 1.5.0-1.fc9.x86_64 requires perl(Geo::GDAL::Const) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) kazehakase - 0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 netgen - 1.3.7-13.fc9.x86_64 requires libtcl8.4.so()(64bit) netgen - 1.3.7-13.fc9.x86_64 requires libtk8.4.so()(64bit) openoffice.org-devel - 1:2.4.0-1.1.fc9.i386 requires sdk openoffice.org-devel - 1:2.4.0-1.1.fc9.i386 requires /bin/python openoffice.org-devel - 1:2.4.0-1.1.fc9.i386 requires /usr/solar/bin/perl openoffice.org-devel - 1:2.4.0-1.1.fc9.x86_64 requires sdk openoffice.org-devel - 1:2.4.0-1.1.fc9.x86_64 requires /bin/python openoffice.org-devel - 1:2.4.0-1.1.fc9.x86_64 requires /usr/solar/bin/perl tkinter - 2.5.1-20.fc9.x86_64 requires libTix8.4.so()(64bit) vtk - 5.0.3-20.fc8.x86_64 requires libtk8.4.so()(64bit) vtk - 5.0.3-20.fc8.x86_64 requires libtcl8.4.so()(64bit) vtk - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.x86_64 requires libtk8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.x86_64 requires libtcl8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.x86_64 requires libtk8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.x86_64 requires libtcl8.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.ppc requires libgtkembedmoz.so epiphany-extensions - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 gdal-perl - 1.5.0-1.fc9.ppc requires perl(Geo::GDAL::Const) gnome-web-photo - 0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.ppc requires libgtkembedmoz.so gnome-web-photo - 0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 kazehakase - 0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 monodevelop - 0.17-4.fc9.ppc requires boo netgen - 1.3.7-13.fc9.ppc requires libtk8.4.so netgen - 1.3.7-13.fc9.ppc requires libtcl8.4.so openoffice.org-devel - 1:2.4.0-1.1.fc9.ppc requires sdk openoffice.org-devel - 1:2.4.0-1.1.fc9.ppc requires /bin/python openoffice.org-devel - 1:2.4.0-1.1.fc9.ppc requires /usr/solar/bin/perl openoffice.org-devel - 1:2.4.0-1.1.fc9.ppc64 requires sdk openoffice.org-devel - 1:2.4.0-1.1.fc9.ppc64 requires /bin/python openoffice.org-devel - 1:2.4.0-1.1.fc9.ppc64 requires /usr/solar/bin/perl tkinter - 2.5.1-20.fc9.ppc requires libTix8.4.so vtk - 5.0.3-20.fc8.ppc requires libtcl8.4.so vtk - 5.0.3-20.fc8.ppc requires libtk8.4.so vtk - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc requires libtk8.4.so vtk-python - 5.0.3-20.fc8.ppc requires libtcl8.4.so vtk-python - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc requires libtk8.4.so vtk-tcl - 5.0.3-20.fc8.ppc requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) Broken deps for ppc64 ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gdal-perl - 1.5.0-1.fc9.ppc64 requires perl(Geo::GDAL::Const) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) kazehakase - 0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 netgen - 1.3.7-13.fc9.ppc64 requires libtcl8.4.so()(64bit) netgen - 1.3.7-13.fc9.ppc64 requires libtk8.4.so()(64bit) openoffice.org-devel - 1:2.4.0-1.1.fc9.ppc64 requires sdk openoffice.org-devel - 1:2.4.0-1.1.fc9.ppc64 requires /bin/python openoffice.org-devel - 1:2.4.0-1.1.fc9.ppc64 requires /usr/solar/bin/perl perl-Test-AutoBuild-darcs - 1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 tkinter - 2.5.1-20.fc9.ppc64 requires libTix8.4.so()(64bit) vtk - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) From caolanm at redhat.com Sat Jan 12 13:19:34 2008 From: caolanm at redhat.com (Caolan McNamara) Date: Sat, 12 Jan 2008 13:19:34 +0000 Subject: graphically show dependencies In-Reply-To: <200801120752.19888.sgrubb@redhat.com> References: <20080112115328.GA2598@free.fr> <200801120752.19888.sgrubb@redhat.com> Message-ID: <1200143975.27355.74.camel@Jehannum> On Sat, 2008-01-12 at 07:52 -0500, Steve Grubb wrote: > On Saturday 12 January 2008 06:53:28 Patrice Dumas wrote: > > I remember that there was a tool to show graphically the package > > dependencies. Did I dream? If not, where is it? > > rpmgraph shows you the runtime dependencies that are in the rpm. Notably, > rpmbuild does not figure out shell script dependencies, so that is missing. > (But it could with a little work by scanning installed packages for shell > scripts and running bash --rpm-requires $TARGET). It'd be nice to see a graph of dependencies in pirut, see what things are at the tip of branches that nothing depends on that could be removed. C. From ivazqueznet at gmail.com Sat Jan 12 13:33:50 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sat, 12 Jan 2008 08:33:50 -0500 Subject: graphically show dependencies In-Reply-To: <1200143975.27355.74.camel@Jehannum> References: <20080112115328.GA2598@free.fr> <200801120752.19888.sgrubb@redhat.com> <1200143975.27355.74.camel@Jehannum> Message-ID: <1200144830.5098.23.camel@ignacio.lan> On Sat, 2008-01-12 at 13:19 +0000, Caolan McNamara wrote: > It'd be nice to see a graph of dependencies in pirut, see what things > are at the tip of branches that nothing depends on that could be > removed. Building such a graph is... non-trivial and shouldn't be done on the fly. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From csnook at redhat.com Sat Jan 12 13:31:50 2008 From: csnook at redhat.com (Chris Snook) Date: Sat, 12 Jan 2008 08:31:50 -0500 Subject: graphically show dependencies In-Reply-To: <1200144830.5098.23.camel@ignacio.lan> References: <20080112115328.GA2598@free.fr> <200801120752.19888.sgrubb@redhat.com> <1200143975.27355.74.camel@Jehannum> <1200144830.5098.23.camel@ignacio.lan> Message-ID: <4788C146.3000301@redhat.com> Ignacio Vazquez-Abrams wrote: > On Sat, 2008-01-12 at 13:19 +0000, Caolan McNamara wrote: >> It'd be nice to see a graph of dependencies in pirut, see what things >> are at the tip of branches that nothing depends on that could be >> removed. > > Building such a graph is... non-trivial and shouldn't be done on the > fly. http://en.wikipedia.org/wiki/Topological_sort -- Chris From jakub.rusinek at gmail.com Sat Jan 12 13:43:33 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Sat, 12 Jan 2008 14:43:33 +0100 Subject: pirut, pup, system-*: policykit integration In-Reply-To: <1200071173.2829.12.camel@localhost.localdomain> References: <5e92ee3f0801110553t66315134le53985bb653984df@mail.gmail.com> <1200070344.2829.5.camel@localhost.localdomain> <16de708d0801110855r3cd266beq70b768c255849a21@mail.gmail.com> <1200071173.2829.12.camel@localhost.localdomain> Message-ID: <5e92ee3f0801120543n68866866k881d9c8da47a6fa0@mail.gmail.com> 2008/1/11, Matthias Clasen : > > > On Fri, 2008-01-11 at 10:55 -0600, Arthur Pemberton wrote: > > > > > > > Wrt to system config tools, one option would be for someone to > > > investigate gnome-system-tools (at least, get it to work and package > it > > > for Fedora, for trying it out), which is also using these > technologies. > > > > > > Are you suggesting making the psuedo DE agnostic system-confg tools > > more Gnome reliant? > > Many of the system-config tools we ship are DE agnostic only in so far > as the are just plain bad UI and wouldn't be accepted as part of either > DE... most of the tools have been written many years ago, without input > from interface designers, and have seen very little UI love since then. > (I don't mean to be rude here. This is not the fault of the respective > maintainers, whose primary job is not UI programming) > > gnome-system-tools uses a frontend-backend split, with dbus interfaces. > So if you feel like it, you should be able to write frontends using > other toolkits. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Fedora ships GTK-based config tools which is VERY wrong. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.underwood at gmail.com Sat Jan 12 13:43:42 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sat, 12 Jan 2008 13:43:42 +0000 Subject: graphically show dependencies In-Reply-To: <1200144830.5098.23.camel@ignacio.lan> References: <20080112115328.GA2598@free.fr> <200801120752.19888.sgrubb@redhat.com> <1200143975.27355.74.camel@Jehannum> <1200144830.5098.23.camel@ignacio.lan> Message-ID: <645d17210801120543y7c0933a9y27ad249b17015924@mail.gmail.com> On 12/01/2008, Ignacio Vazquez-Abrams wrote: > On Sat, 2008-01-12 at 13:19 +0000, Caolan McNamara wrote: > > It'd be nice to see a graph of dependencies in pirut, see what things > > are at the tip of branches that nothing depends on that could be > > removed. > > Building such a graph is... non-trivial and shouldn't be done on the > fly. > That said, there is some of the logic in package-cleanup --leaves and package-cleanup --leaves --all From lmacken at redhat.com Sat Jan 12 14:16:33 2008 From: lmacken at redhat.com (Luke Macken) Date: Sat, 12 Jan 2008 09:16:33 -0500 Subject: "not tagged with dist-f8-updates-candidate" In-Reply-To: <1200071774.5278.230.camel@hinge.endoframe.net> References: <1200071774.5278.230.camel@hinge.endoframe.net> Message-ID: <20080112141633.GI10382@crow> On Fri, Jan 11, 2008 at 12:16:14PM -0500, Braden McDaniel wrote: > When I attempt to edit this update: > > https://admin.fedoraproject.org/updates/F8/pending/openvrml-0.17.2-1.fc8 > > ... I get a message: > > openvrml-0.17.2-1.fc8 not tagged with dist-f8-updates-candidate > > What does this mean, exactly? (In particular to why I can't edit the > update.) This should hopefully be fixed. For some reason the status of this update never got changed to 'testing' when it was pushed. I'll look into why this happened, but you should be able to edit it now. luke From jwilson at redhat.com Sat Jan 12 14:56:33 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Sat, 12 Jan 2008 09:56:33 -0500 Subject: Wanted: FireWire testers In-Reply-To: <4787F580.2030405@gmail.com> References: <4787F211.3010402@redhat.com> <4787F580.2030405@gmail.com> Message-ID: <4788D521.9000701@redhat.com> Les Mikesell wrote: > Jarod Wilson wrote: >> If you're among those who have voiced concerns with the FireWire >> support in >> Fedora, particularly in the audio/video area, please do try to test >> out the >> latest rawhide kernels (2.6.24-0.149.fc7.git2.fc9 or later) and/or the >> 2.6.23.13 kernel working its way through koji right now[1]. Its built. http://koji.fedoraproject.org/packages/kernel/2.6.23.13/106.fc8/ >> As yet untested with this latest kernel is FireWire video capture off >> a cable >> box[3], but that's on my todo list for the weekend. (There's reason to >> believe >> this might be working now with the addition of dynamic buffer >> allocation). Nope, still no dice. Will poke more soonish, I'm inclined to think its a userspace issue... > As a perhaps odd case, is it likely to be possible to build an initrd > containing the firewire driver and have firewire drives included in md > devices recognized and matched correctly during boot-up? Should be doable, yes. If you've got a line in modprobe.conf of 'alias scsi_hostadapterX firewire-sbp2' (for some value of X) and the array running when you create your initrd, it *should* automagically include the necessary modules in the initrd. I'd probably run mkinitrd -v by hand to see for sure. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From martin at marquesminen.com.ar Sat Jan 12 15:39:11 2008 From: martin at marquesminen.com.ar (Martin Marques) Date: Sat, 12 Jan 2008 13:39:11 -0200 Subject: Fedora 8 hanging Message-ID: <4788DF1F.6050802@marquesminen.com.ar> I'm getting constant hangs on my Fedora 8 on a Compaq Presario F500, with an AMD turion 64 (running Fedora 64) and an Nvidia video card (using the binary driver from livna). For some reason I get random hangs (nothing works at all) and don't know if the nvidia driver is to blame or something in the kernel. Logs say nothing. I'm using a koji kernel -101.fc8 which has a fix for my broadcom wireless card (with the kernels available in F8 hangs were more often and I couldn't get connected to my AP). This Notebook work very well with Fedora 7 and I did an upgrade using the December re spin from fedora unity. Any tip on what I can do to check where the problem is? I was gonna fill a bug report but I'm not sure where the problem is yet. From alan at redhat.com Sat Jan 12 15:45:48 2008 From: alan at redhat.com (Alan Cox) Date: Sat, 12 Jan 2008 10:45:48 -0500 Subject: Fedora 8 hanging In-Reply-To: <4788DF1F.6050802@marquesminen.com.ar> References: <4788DF1F.6050802@marquesminen.com.ar> Message-ID: <20080112154548.GA18472@devserv.devel.redhat.com> On Sat, Jan 12, 2008 at 01:39:11PM -0200, Martin Marques wrote: > with an AMD turion 64 (running Fedora 64) and an Nvidia video card > (using the binary driver from livna). Remove the binary driver. Reboot using the nv Fedora supplied driver and see how it runs for a bit. If it still hangs then you know its not likely to be the Nvidia driver From kevin.kofler at chello.at Sat Jan 12 15:47:10 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 12 Jan 2008 15:47:10 +0000 (UTC) Subject: pirut, pup, system-*: policykit integration References: <5e92ee3f0801110553t66315134le53985bb653984df@mail.gmail.com> <1200070344.2829.5.camel@localhost.localdomain> <16de708d0801110855r3cd266beq70b768c255849a21@mail.gmail.com> <1200071173.2829.12.camel@localhost.localdomain> <5e92ee3f0801120543n68866866k881d9c8da47a6fa0@mail.gmail.com> Message-ID: Jakub 'Livio' Rusinek gmail.com> writes: > Fedora ships GTK-based config tools which is VERY wrong. Would you rather the tools were in Tk, Xaw, lesstif or some other ancient ugly toolkit? GTK+ is much better than any of those! Kevin Kofler From wwoods at redhat.com Sat Jan 12 15:48:26 2008 From: wwoods at redhat.com (Will Woods) Date: Sat, 12 Jan 2008 15:48:26 +0000 Subject: anaconda traceback In-Reply-To: <4788B179.4000901@gmail.com> References: <47889B67.9050507@mindspring.com> <4788B179.4000901@gmail.com> Message-ID: <1200152906.4765.56.camel@metroid.rdu.redhat.com> On Sat, 2008-01-12 at 04:24 -0800, Andrew Farris wrote: > Richard Hally wrote: > > When trying to do a network install of rawhide I get the following: > > > > (using the boot.iso from rawhide) > > > > After retrieving images/stage2.img, > > > > "Running anaconda 11.4.0.18, the Fedora installer, please wait... > > traceback(most recent call last) > > file "/usr/bin/anaconda" line 623 in > > from exception import handleException > > file "/usr/lib/anaconda/exception.py" line 41 in > > import kickstart > > file "/use/lib/anaconda/kickstart.py" line 36 in > > import upgrade > > file "/usr/lib/anaconda/upgrade.py" line 31 in > > import selinux > > Import Error: no module named selinux > > install exited abnormally [1/1]" > > > > ... > > ok to reboot etc > > > > anyone tried installing the current rawhide? does this need a Bugzilla? Works for me with today's rawhide (20070112, anaconda 11.4.0.19). I wasn't using the boot.iso - just booted from the vmlinuz and initrd.img - but that shouldn't change anything. Does it work for you today? -w -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jakub.rusinek at gmail.com Sat Jan 12 15:55:22 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Sat, 12 Jan 2008 16:55:22 +0100 Subject: pirut, pup, system-*: policykit integration In-Reply-To: References: <5e92ee3f0801110553t66315134le53985bb653984df@mail.gmail.com> <1200070344.2829.5.camel@localhost.localdomain> <16de708d0801110855r3cd266beq70b768c255849a21@mail.gmail.com> <1200071173.2829.12.camel@localhost.localdomain> <5e92ee3f0801120543n68866866k881d9c8da47a6fa0@mail.gmail.com> Message-ID: <5e92ee3f0801120755i23e94af1qa5925f4e34a65e93@mail.gmail.com> 2008/1/12, Kevin Kofler : > > Jakub 'Livio' Rusinek gmail.com> writes: > > Fedora ships GTK-based config tools which is VERY wrong. > > Would you rather the tools were in Tk, Xaw, lesstif or some other ancient > ugly > toolkit? GTK+ is much better than any of those! > > Kevin Kofler > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Those tools should detect DE and then use adequate library. Exactly how YaST2 does, with success. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From myfedora at richip.dhs.org Sat Jan 12 16:14:16 2008 From: myfedora at richip.dhs.org (Richi Plana) Date: Sat, 12 Jan 2008 09:14:16 -0700 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <20080111000616.GC7758@tango.0pointer.de> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <20080109094532.811057b2.mschwendt.tmp0701.nospam@arcor.de> <64b14b300801090446u1412557p7bee40aa9922223d@mail.gmail.com> <1199916701.8159.2.camel@localhost.localdomain> <364d303b0801091644s7c9109a8v4b1bfe0f90427cb@mail.gmail.com> <1199964183.8159.15.camel@localhost.localdomain> <364d303b0801100437g1ed6c0b8tb7e71784e9ba3bd@mail.gmail.com> <47862106.2010607@redhat.com> <20080111000616.GC7758@tango.0pointer.de> Message-ID: <1200154456.3764.5.camel@localhost6.localdomain6> On Fri, 2008-01-11 at 01:06 +0100, Lennart Poettering wrote: > So, looking on 0.9.7-pre, on 0.9.7-final and 0.9.8, I decided that the > changes are not really suited for an updated package for an already > released distribution, since they are almost exclusively new features, > and only very few relevant bugfixes. > > I guess this is the classical distribution dilemma: are the new > features or the stability more important? Whatever way I decide, I'll > make some people unhappy. There are a couple of replies, but I thought I'd add that feature-set in the released version in F8 of PA is far from the advertised. There's little to no support for tunneling, realtime updating of remote virtual devices via avahi doesn't exist, etc. So in the end, what the F8 users are getting are a couple of features (per application volume control) at the cost of stability and headaches getting unsupported audio apps to work. Personally, I think the decision to include PA was the correct one, but at the very least, give the users more features to make up for the headaches. Otherwise, we may as well have waited for F9 instead of using users as bug-finders. -- Richi Plana From fedora at camperquake.de Sat Jan 12 16:30:18 2008 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 12 Jan 2008 17:30:18 +0100 Subject: Start/stop of OpenVPN interfaces with ifup/ifdown In-Reply-To: <200801112338.m0BNcflD031668@jasmine.xos.nl> References: <200801112338.m0BNcflD031668@jasmine.xos.nl> Message-ID: <20080112173018.7dd538e2@lain.camperquake.de> Hi. On Sat, 12 Jan 2008 00:38:41 +0100, Jos Vos wrote > - Does anyone know of recent work in this area? I guess the example > scripts in the thread I listed above might not work as-is with the > current Fedora and OpenVPN versions. I'm using the scripts below on Rawhide and Centos5: http://www.skytale.net/files/openvpn-ifscripts/openvpn-ifscripts-0.4-1.sky.src.rpm From wtogami at redhat.com Sat Jan 12 16:39:26 2008 From: wtogami at redhat.com (Warren Togami) Date: Sat, 12 Jan 2008 11:39:26 -0500 Subject: Pulse Audio 0.9.8 - upgrade? Message-ID: <4788ED3E.50104@redhat.com> What about this earlier reply? Could this be a solution? Lennart? Warren Togami wtogami at redhat.com -------- Original Message -------- Subject: Re: Pulse Audio 0.9.8 - upgrade? Date: Thu, 10 Jan 2008 22:07:19 -0500 From: Warren Togami Reply-To: Development discussions related to Fedora To: Development discussions related to Fedora , Lennart Poettering Lennart Poettering wrote: > > I discussed the whole situation with Lubomir a while back, when I last > updated the packages for Rawhide. Thing is: right now we don't have a > real policy on what kind of updates should be pushed into already > released releases and what updates shouldn't (but there's a draft, or > something? don't really remember, didn't really follow this). My > understanding is that no big updates should be pushed to released > versions, but bugfixes should. (I used to follow Debian > before I joined RH, and their policy is very strict on this stuff, and > I believe that makes sense). > > So, looking on 0.9.7-pre, on 0.9.7-final and 0.9.8, I decided that the > changes are not really suited for an updated package for an already > released distribution, since they are almost exclusively new features, > and only very few relevant bugfixes. > > I guess this is the classical distribution dilemma: are the new > features or the stability more important? Whatever way I decide, I'll > make some people unhappy. > > Long story short: The changes to 0.9.7 are no bugfixes, those to 0.9.8 > are invasive. So I believe this better stays out of an already > released distribution. > > And then, you can always run Rawhide. It has 0.9.8. And has had it for > quite a while. > > Lennart > As a general rule, version upgrades with new features are NOT disallowed in Fedora. Version upgrades with new features are introduced in a controlled and careful manner only after heavy testing. For example, you might see several kernel rebases during a Fedora release lifetime like 2.6.22 -> 2.6.23 -> 2.6.24. Version upgrades that massively break ABI are disallowed during a stable Fedora release. For example, we never do a rebase to a newer openssl version during a stable release because they always break their so-name ABI revision, and far too many applications depend on the existing so-name ABI. Does upgrading from 0.9.7 to 0.9.8 break library ABI with applications already linked against any pulseaudio library? If not, we should really explore the possibility of upgrading to a newer pulseaudio version in Fedora 8. http://people.redhat.com/davej/kernels/Fedora/f8/ By explore the possibilty, I mean doing a test build of pulseaudio-0.9.8 for F8 and putting it into a side repository similar to davej's un-official test kernel repository. This allows folks to opt-in to easily test your latest pulseaudio on F8 without risking everyone. By having your own side-repository with F8 pulseuaudio, you can do your own builds and push new test packages as often as you want for your own test users. koji's build --scratch option makes it real easy to do test builds of a single package on all supported Fedora architectures without it being an official build. Later when the test users agree that the pulseaudio package in your test repository is seemingly good, it can be pushed to F8's updates-testing repository where many thousands of other users who opt-in to that optional channel will be exposed to it. It can be tested there for a while before pushing to the public in the stable updates channel. This multi-layered approach to testing should ensure that the update is of higher quality than the current F8 pulseaudio. Pulseaudio made many applications that used to be stable suddenly unreliable. Apps like pidgin, mplayer, xine, Adobe Flash Player and many more now have weird pulseaudio related crash issues. There is a desire to pull in newer pulseaudio versions if bugs are fixed to make it more stable. Please let us explore the feasibility of upgrading it in F8? Warren Togami wtogami at redhat.com From jakub.rusinek at gmail.com Sat Jan 12 17:26:17 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Sat, 12 Jan 2008 18:26:17 +0100 Subject: compilation architecture Message-ID: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> do we need to support legacy cpu's by i386 compilation? i586 would make fedora faster even 3 times. difference is noticeable. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbhole at redhat.com Sat Jan 12 17:49:39 2008 From: dbhole at redhat.com (Deepak Bhole) Date: Sat, 12 Jan 2008 12:49:39 -0500 Subject: Policy on introducing new packages for discontinued projects? In-Reply-To: <20080111230053.GA4100@free.fr> References: <20080111221202.GC26001@redhat.com> <20080111230053.GA4100@free.fr> Message-ID: <20080112174939.GE26001@redhat.com> * Patrice Dumas [2008-01-11 18:01]: > On Fri, Jan 11, 2008 at 05:12:02PM -0500, Deepak Bhole wrote: > > Hi There, > > > > I'm working on updating maven2 in Fedora, and one of the dependencies > > that it is cascading into is Jakarta Slide. This project hasn't had > > updates for a while, and is now officially dead as stated on the main > > page: > > > > http://jakarta.apache.org/slide/index.html > > > > What is Fedora policy for introducing new packages for defunct projects? > > Specially when those packages provide optional functionality... > > It depends on the reason why it is defunct. If it is because it works > since a long time, such that nobody needs to take care of it, then it is > a very good thing. If it is a package abandoned although it is not very > stable, then if a packager wants to keep it in fedora he'll have to be > prepared to be more or less the upstream. > > So this is left to the packager, but in the precise case you bring up, > I'd suggest retiring the package > http://fedoraproject.org/wiki/PackageMaintainers/RetiredPackages > especially since there is a replacement. And indeed stop using that > functionality. If not, then be prepared to do the patching yourself. > Actually in this case, there is nothing to retire because the package doesn't exist in Fedora. That it why I was wondering on our stance on putting a new package in, for a known defunct project... It seems such a decision would lie on a packager as well though, so I am going to just avoid putting it in and work around the dependency requirement. Cheers, Deepak > -- > Pat > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From drago01 at gmail.com Sat Jan 12 17:51:19 2008 From: drago01 at gmail.com (drago01) Date: Sat, 12 Jan 2008 18:51:19 +0100 Subject: compilation architecture In-Reply-To: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> Message-ID: 2008/1/12 Jakub 'Livio' Rusinek : > do we need to support legacy cpu's by i386 compilation? > i586 would make fedora faster even 3 times. > difference is noticeable. ..... where are your benchmarks for the "3 times faster" claim? the i386 packages are already optimized for newer cpus (mtune vs. march) where it makes sense to have i686 versions there are some (kernel, glibc) From jakub.rusinek at gmail.com Sat Jan 12 18:06:50 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Sat, 12 Jan 2008 19:06:50 +0100 Subject: compilation architecture In-Reply-To: References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> Message-ID: <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> I've used openSUSE (i586) with the same configuration and packages installed and eg. Firefox 3 was started in < 1 sec. I have no benchmarks but everything runs faster and is more responsible. Our optimalization does nothing compared to > i386 compilation. 2008/1/12, drago01 : > > 2008/1/12 Jakub 'Livio' Rusinek : > > do we need to support legacy cpu's by i386 compilation? > > i586 would make fedora faster even 3 times. > > difference is noticeable. > > ..... > where are your benchmarks for the "3 times faster" claim? > the i386 packages are already optimized for newer cpus (mtune vs. march) > where it makes sense to have i686 versions there are some (kernel, glibc) > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pertusus at free.fr Sat Jan 12 18:12:39 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 12 Jan 2008 19:12:39 +0100 Subject: compilation architecture In-Reply-To: <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> Message-ID: <20080112181239.GA3043@free.fr> On Sat, Jan 12, 2008 at 07:06:50PM +0100, Jakub 'Livio' Rusinek wrote: > I've used openSUSE (i586) with the same configuration and packages installed > and eg. Firefox 3 was started in < 1 sec. I have no benchmarks but > everything runs faster and is more responsible. > > Our optimalization does nothing compared to > i386 compilation. I can only guess that there are many differences besides the arch between suse and fedora. Did you try a more meaningfull test, for instance rebuilding the firefox rpm as i586 and seeing what the gain is? -- Pat From denis at poolshark.org Sat Jan 12 18:13:40 2008 From: denis at poolshark.org (Denis Leroy) Date: Sat, 12 Jan 2008 19:13:40 +0100 Subject: compilation architecture In-Reply-To: <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> Message-ID: <47890354.9040700@poolshark.org> Jakub 'Livio' Rusinek wrote: > I've used openSUSE (i586) with the same configuration and packages > installed and eg. Firefox 3 was started in < 1 sec. I have no benchmarks > but everything runs faster and is more responsible. I'm afraid you're going to have to come up with hard scientific evidence to convince anyone. Firefox 3 startup is probably dominated by disk I/O anyways (all those dynamic libraries it has to load). Still, It would be a fun experiment to run. Compute the cold (i.e. just after boot) startup time of firefox, then recompiles all of its dependencies (all the way down to glibc) with i586, reboot, and recomputes. To be honest, I'd be surprised if you had even one tenth of a second of difference. -denis From jakub.rusinek at gmail.com Sat Jan 12 18:27:23 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Sat, 12 Jan 2008 19:27:23 +0100 Subject: compilation architecture In-Reply-To: <47890354.9040700@poolshark.org> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47890354.9040700@poolshark.org> Message-ID: <5e92ee3f0801121027g41fbce5ex19fae021936b6ad4@mail.gmail.com> Don't be silly. Try some > i386 distro, and look at the difference. About Firefox, I wasn't using Firefox 3 from RPM, but Trunk snapshot from Mozilla's FTP. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From debarshi.ray at gmail.com Sat Jan 12 18:47:14 2008 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Sun, 13 Jan 2008 00:17:14 +0530 Subject: Renaming anjuta-gdl to libgdl In-Reply-To: <3170f42f0712150443g535cc4c4u34c73cfb0726e964@mail.gmail.com> References: <3170f42f0712150443g535cc4c4u34c73cfb0726e964@mail.gmail.com> Message-ID: <3170f42f0801121047q16cf32fdy8e75fe5383f072bc@mail.gmail.com> > I propose to rename the anjuta-gdl package to lbgdl. The renaming has been done, and it is currently in Rawhide, F-8 testing and F-7 testing. Cheers, Debarshi -- Free software for the Indian community: * ftp://fedora.glug-nith.org/ (Fedora) * http://gnu.glug-nith.org/ (GNU) * http://mirror.wbut.ac.in/ (CRAN, Fedora, Mozilla, TLDP) From jreiser at BitWagon.com Sat Jan 12 18:50:48 2008 From: jreiser at BitWagon.com (John Reiser) Date: Sat, 12 Jan 2008 10:50:48 -0800 Subject: compilation architecture In-Reply-To: <5e92ee3f0801121027g41fbce5ex19fae021936b6ad4@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47890354.9040700@poolshark.org> <5e92ee3f0801121027g41fbce5ex19fae021936b6ad4@mail.gmail.com> Message-ID: <47890C08.1080109@BitWagon.com> > Don't be silly. Try some > i386 distro, and look at the difference. The rule is: Anyone who proposes a change because of performance, must supply *measurements* which support the change. The measurements must be reproducible on other machines by other members of the community, so the environment and test procedure must be well-specified, too. -- From ivazqueznet at gmail.com Sat Jan 12 18:50:33 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sat, 12 Jan 2008 13:50:33 -0500 Subject: pirut, pup, system-*: policykit integration In-Reply-To: <5e92ee3f0801120755i23e94af1qa5925f4e34a65e93@mail.gmail.com> References: <5e92ee3f0801110553t66315134le53985bb653984df@mail.gmail.com> <1200070344.2829.5.camel@localhost.localdomain> <16de708d0801110855r3cd266beq70b768c255849a21@mail.gmail.com> <1200071173.2829.12.camel@localhost.localdomain> <5e92ee3f0801120543n68866866k881d9c8da47a6fa0@mail.gmail.com> <5e92ee3f0801120755i23e94af1qa5925f4e34a65e93@mail.gmail.com> Message-ID: <1200163833.26270.1.camel@ignacio.lan> On Sat, 2008-01-12 at 16:55 +0100, Jakub 'Livio' Rusinek wrote: > 2008/1/12, Kevin Kofler : > Jakub 'Livio' Rusinek gmail.com> writes: > > Fedora ships GTK-based config tools which is VERY wrong. > > Would you rather the tools were in Tk, Xaw, lesstif or some > other ancient ugly > toolkit? GTK+ is much better than any of those! > > Kevin Kofler > > Those tools should detect DE and then use adequate library. Exactly > how YaST2 does, with success. Let us know when you've figured out how to do that. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed From ivazqueznet at gmail.com Sat Jan 12 18:54:25 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sat, 12 Jan 2008 13:54:25 -0500 Subject: compilation architecture In-Reply-To: <5e92ee3f0801121027g41fbce5ex19fae021936b6ad4@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47890354.9040700@poolshark.org> <5e92ee3f0801121027g41fbce5ex19fae021936b6ad4@mail.gmail.com> Message-ID: <1200164065.26270.4.camel@ignacio.lan> On Sat, 2008-01-12 at 19:27 +0100, Jakub 'Livio' Rusinek wrote: > Don't be silly. Try some > i386 distro, and look at the difference. > About Firefox, I wasn't using Firefox 3 from RPM, but Trunk snapshot > from Mozilla's FTP. You're suggesting trying a completely different architecture... with completely different features... and completely different build options? http://en.wikipedia.org/wiki/Scientific_method -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed From berrange at redhat.com Sat Jan 12 19:06:12 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Sat, 12 Jan 2008 19:06:12 +0000 Subject: pirut, pup, system-*: policykit integration In-Reply-To: <5e92ee3f0801120755i23e94af1qa5925f4e34a65e93@mail.gmail.com> References: <5e92ee3f0801110553t66315134le53985bb653984df@mail.gmail.com> <1200070344.2829.5.camel@localhost.localdomain> <16de708d0801110855r3cd266beq70b768c255849a21@mail.gmail.com> <1200071173.2829.12.camel@localhost.localdomain> <5e92ee3f0801120543n68866866k881d9c8da47a6fa0@mail.gmail.com> <5e92ee3f0801120755i23e94af1qa5925f4e34a65e93@mail.gmail.com> Message-ID: <20080112190612.GE936@redhat.com> On Sat, Jan 12, 2008 at 04:55:22PM +0100, Jakub 'Livio' Rusinek wrote: > 2008/1/12, Kevin Kofler : > > > > Jakub 'Livio' Rusinek gmail.com> writes: > > > Fedora ships GTK-based config tools which is VERY wrong. > > > > Would you rather the tools were in Tk, Xaw, lesstif or some other ancient > > ugly > > toolkit? GTK+ is much better than any of those! > > Those tools should detect DE and then use adequate library. Exactly how > YaST2 does, with success. gnome-system-tools lets you do exactly that. The core functionality is all in the non-GUI backend. The GUI is just a shim which talks to the backend over DBus. So you can plug in whatever GUI you like and use the same backend code . Feel free to write a backend for KDE / whatever other DE you care about... Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From jakub.rusinek at gmail.com Sat Jan 12 19:18:34 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Sat, 12 Jan 2008 20:18:34 +0100 Subject: compilation architecture In-Reply-To: <1200164065.26270.4.camel@ignacio.lan> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47890354.9040700@poolshark.org> <5e92ee3f0801121027g41fbce5ex19fae021936b6ad4@mail.gmail.com> <1200164065.26270.4.camel@ignacio.lan> Message-ID: <5e92ee3f0801121118x79e207e6jbc03cddc15f24aa9@mail.gmail.com> 2008/1/12, Ignacio Vazquez-Abrams : > > On Sat, 2008-01-12 at 19:27 +0100, Jakub 'Livio' Rusinek wrote: > > Don't be silly. Try some > i386 distro, and look at the difference. > > About Firefox, I wasn't using Firefox 3 from RPM, but Trunk snapshot > > from Mozilla's FTP. > > You're suggesting trying a completely different architecture... with > completely different features... and completely different build options? > > http://en.wikipedia.org/wiki/Scientific_method > > -- > Ignacio Vazquez-Abrams > > PLEASE don't CC me; I'm already subscribed > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > So I can say only one thing: "fedora does something in wrong, performance-loss way". -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakub.rusinek at gmail.com Sat Jan 12 19:19:22 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Sat, 12 Jan 2008 20:19:22 +0100 Subject: pirut, pup, system-*: policykit integration In-Reply-To: <20080112190612.GE936@redhat.com> References: <5e92ee3f0801110553t66315134le53985bb653984df@mail.gmail.com> <1200070344.2829.5.camel@localhost.localdomain> <16de708d0801110855r3cd266beq70b768c255849a21@mail.gmail.com> <1200071173.2829.12.camel@localhost.localdomain> <5e92ee3f0801120543n68866866k881d9c8da47a6fa0@mail.gmail.com> <5e92ee3f0801120755i23e94af1qa5925f4e34a65e93@mail.gmail.com> <20080112190612.GE936@redhat.com> Message-ID: <5e92ee3f0801121119g73bae15foe63b7a5d1844766d@mail.gmail.com> 2008/1/12, Daniel P. Berrange : > > On Sat, Jan 12, 2008 at 04:55:22PM +0100, Jakub 'Livio' Rusinek wrote: > > 2008/1/12, Kevin Kofler : > > > > > > Jakub 'Livio' Rusinek gmail.com> writes: > > > > Fedora ships GTK-based config tools which is VERY wrong. > > > > > > Would you rather the tools were in Tk, Xaw, lesstif or some other > ancient > > > ugly > > > toolkit? GTK+ is much better than any of those! > > > > Those tools should detect DE and then use adequate library. Exactly how > > YaST2 does, with success. > > gnome-system-tools lets you do exactly that. The core functionality is > all in the non-GUI backend. The GUI is just a shim which talks to the > backend over DBus. So you can plug in whatever GUI you like and use the > same backend code . Feel free to write a backend for KDE / whatever other > DE you care about... > > Dan. > -- > |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 > -=| > |=- Perl modules: http://search.cpan.org/~danberr/ > -=| > |=- Projects: http://freshmeat.net/~danielpb/ > -=| > |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B > 9505 -=| > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I'm not an programmer, but I know something about it... -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Sat Jan 12 19:33:57 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 12 Jan 2008 14:33:57 -0500 Subject: compilation architecture In-Reply-To: <5e92ee3f0801121118x79e207e6jbc03cddc15f24aa9@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47890354.9040700@poolshark.org> <5e92ee3f0801121027g41fbce5ex19fae021936b6ad4@mail.gmail.com> <1200164065.26270.4.camel@ignacio.lan> <5e92ee3f0801121118x79e207e6jbc03cddc15f24aa9@mail.gmail.com> Message-ID: <20080112143357.0ab033f1@redhat.com> On Sat, 12 Jan 2008 20:18:34 +0100 "Jakub 'Livio' Rusinek" wrote: > So I can say only one thing: "fedora does something in wrong, > performance-loss way". You could say that, but you'd be wrong. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From drago01 at gmail.com Sat Jan 12 19:45:44 2008 From: drago01 at gmail.com (drago01) Date: Sat, 12 Jan 2008 20:45:44 +0100 Subject: compilation architecture In-Reply-To: <5e92ee3f0801121118x79e207e6jbc03cddc15f24aa9@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47890354.9040700@poolshark.org> <5e92ee3f0801121027g41fbce5ex19fae021936b6ad4@mail.gmail.com> <1200164065.26270.4.camel@ignacio.lan> <5e92ee3f0801121118x79e207e6jbc03cddc15f24aa9@mail.gmail.com> Message-ID: 2008/1/12 Jakub 'Livio' Rusinek : > So I can say only one thing: "fedora does something in wrong, > performance-loss way". OK here is one synthetic benchmark (non real world) but it should show you that compiling for a different arch does not automatically makes things go faster: benchmark used was "flops.c" first run: gcc flops.c -o flops -m32 -O2 -march=i386 -mtune=i686 -DUNIX FLOPS C Program (Double Precision), V2.0 18 Dec 1992 Module Error RunTime MFLOPS (usec) 1 -8.1208e-11 0.0171 816.4320 2 1.4704e-15 0.0195 358.7055 3 -3.8213e-15 0.0101 1676.3571 4 6.1151e-14 0.0102 1471.7699 5 -4.4419e-14 0.0184 1574.1210 6 7.7002e-15 0.0172 1683.3209 7 -6.6161e-13 0.0517 232.0156 8 2.2789e-14 0.0187 1606.4346 Iterations = 512000000 NullTime (usec) = 0.0000 MFLOPS(1) = 482.7594 MFLOPS(2) = 542.8299 MFLOPS(3) = 1017.2301 MFLOPS(4) = 1618.1922 ---------------------------------------------------------- second run: gcc flops.c -o flops -m32 -O2 -march=i686 -mtune=i686 -DUNIX FLOPS C Program (Double Precision), V2.0 18 Dec 1992 Module Error RunTime MFLOPS (usec) 1 -8.1208e-11 0.0172 812.6376 2 1.4704e-15 0.0196 357.9533 3 -3.8213e-15 0.0101 1677.3263 4 6.1151e-14 0.0102 1471.7699 5 -4.4419e-14 0.0184 1575.9585 6 7.7002e-15 0.0172 1682.3675 7 -6.6161e-13 0.0517 232.1120 8 2.2789e-14 0.0187 1603.4166 Iterations = 512000000 NullTime (usec) = 0.0000 MFLOPS(1) = 481.8683 MFLOPS(2) = 542.8753 MFLOPS(3) = 1016.6906 MFLOPS(4) = 1617.0692 ------------------------------------------------------------ even thought not the topic here I have done a x86_64 run too: gcc flops.c -DUNIX -o flops -O2 ./flops FLOPS C Program (Double Precision), V2.0 18 Dec 1992 Module Error RunTime MFLOPS (usec) 1 4.0146e-13 0.0144 969.8444 2 -1.4166e-13 0.0163 430.2659 3 4.7184e-14 0.0091 1871.3076 4 -1.2557e-13 0.0083 1808.1842 5 -1.3800e-13 0.0302 960.4358 6 3.2380e-13 0.0158 1834.0442 7 -8.4583e-11 0.0433 276.9485 8 3.4867e-13 0.0303 991.5022 Iterations = 512000000 NullTime (usec) = 0.0000 MFLOPS(1) = 575.0329 MFLOPS(2) = 605.2412 MFLOPS(3) = 964.2780 MFLOPS(4) = 1434.2150 ----------------------------------------------------- Test machine was a Core 2 Duo T7400 running F8. So as you can see here there is no virtually difference between i386 and i686. x86_64 is faster in most cases but not always. (and its no way near "3 times faster") So numbers prove what I (and others) said before ... "it feels faster" isn't going to convince anyone or change anything. From jakub.rusinek at gmail.com Sat Jan 12 20:09:22 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Sat, 12 Jan 2008 21:09:22 +0100 Subject: compilation architecture In-Reply-To: <20080112143357.0ab033f1@redhat.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47890354.9040700@poolshark.org> <5e92ee3f0801121027g41fbce5ex19fae021936b6ad4@mail.gmail.com> <1200164065.26270.4.camel@ignacio.lan> <5e92ee3f0801121118x79e207e6jbc03cddc15f24aa9@mail.gmail.com> <20080112143357.0ab033f1@redhat.com> Message-ID: <5e92ee3f0801121209j12f91c1ud7e81e9fde5b6fc2@mail.gmail.com> 2008/1/12, Jesse Keating : > > On Sat, 12 Jan 2008 20:18:34 +0100 > "Jakub 'Livio' Rusinek" wrote: > > > So I can say only one thing: "fedora does something in wrong, > > performance-loss way". > > You could say that, but you'd be wrong. > > -- > Jesse Keating > Fedora -- All my bits are free, are yours? > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > Try openSUSE 10.3. You'll see the difference between it and F8. It's noticeable FASTER! -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From valent.turkovic at gmail.com Sat Jan 12 20:12:47 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sat, 12 Jan 2008 21:12:47 +0100 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <1199916701.8159.2.camel@localhost.localdomain> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <20080109094532.811057b2.mschwendt.tmp0701.nospam@arcor.de> <64b14b300801090446u1412557p7bee40aa9922223d@mail.gmail.com> <1199916701.8159.2.camel@localhost.localdomain> Message-ID: <47891F3F.3070106@gmail.com> Lubomir Kundrak wrote: > On Wed, 2008-01-09 at 13:46 +0100, Valent Turkovic wrote: >> On 1/9/08, Michael Schwendt wrote: >>> On Wed, 9 Jan 2008 09:20:46 +0100, Valent Turkovic wrote: >>> >>>> Hi, >>>> I saw that Pulse Audio 0.9.8 got released two months ago: >>>> http://pulseaudio.org/milestone/0.9.8 >>>> and I see on my Fedora 8 that we still have 0.9.7 >>>> >>>> $ pulseaudio --version >>>> pulseaudio 0.9.7 >>>> >>>> Will there be an upgrade soon on Fedora 8 to Pulse Audio 0.9.8? >>>> >>>> Lost of issues have been fixed in new Pulse Audio so users like me who >>>> have issues with Pulse Audio would appreciate the much needed upgrade. >>> I'm sure the person who maintains the Fedora packages is aware of that. :) >>> Just notice the connection between Pulse Audio and Red Hat. >> I'm sure he is aware of that but I am not - that is why I wrote this email. > > I know the answer -- He decided to save us from an useless upgrade that > would solve none of our problems. This applies for all package > maintainers who value bandwidth and time of the users more than a change > of one digit in a version number -- my thanks to them. > Are you serious? Users usually love to see bug fixes and ones that don't want to update have that option - just disable updates. Valent. From joachim.frieben at googlemail.com Sat Jan 12 20:17:48 2008 From: joachim.frieben at googlemail.com (Joachim Frieben) Date: Sat, 12 Jan 2008 21:17:48 +0100 Subject: compilation architecture In-Reply-To: <5e92ee3f0801121027g41fbce5ex19fae021936b6ad4@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47890354.9040700@poolshark.org> <5e92ee3f0801121027g41fbce5ex19fae021936b6ad4@mail.gmail.com> Message-ID: <1c252d490801121217w388b7942v9123364d7586b692@mail.gmail.com> On 1/12/08, Jakub 'Livio' Rusinek wrote: > > Don't be silly. Try some > i386 distro, and look at the difference. > About Firefox, I wasn't using Firefox 3 from RPM, but Trunk snapshot from > Mozilla's FTP. I'm fairly pissed off that a 15 year old school boy bullies fedora-devel list subscribers in the most annoying way not even mentioning the flow of unqualified postings clogging my inbox. After taking a 'yellow card' on the fedora-art list, Jakub seems to be eager to take another one here .. https://www.redhat.com/archives/fedora-art-list/2007-November/msg00225.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From valent.turkovic at gmail.com Sat Jan 12 20:24:17 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sat, 12 Jan 2008 21:24:17 +0100 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <935ead450801100549k5b34e131w60a7b2d850a629ac@mail.gmail.com> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <20080109094532.811057b2.mschwendt.tmp0701.nospam@arcor.de> <64b14b300801090446u1412557p7bee40aa9922223d@mail.gmail.com> <1199916701.8159.2.camel@localhost.localdomain> <364d303b0801091644s7c9109a8v4b1bfe0f90427cb@mail.gmail.com> <1199964183.8159.15.camel@localhost.localdomain> <364d303b0801100437g1ed6c0b8tb7e71784e9ba3bd@mail.gmail.com> <1199971454.8159.26.camel@localhost.localdomain> <935ead450801100549k5b34e131w60a7b2d850a629ac@mail.gmail.com> Message-ID: <478921F1.8010603@gmail.com> Jeffrey Ollie wrote: > On 1/10/08, Lubomir Kundrak wrote: >> Pardon me, but I only see mostly reasons not to upgrade a stable >> release, such as "Rework ALSA surround sound configuration completely", >> etc. > > I wouldn't call the version of pulseaudio in F-8 "stable". In fact > there are 34 open bugs in bugzilla for pulseaudio for F-8. I didn't > report any of those bugs because I'm self-sufficient enough to > recompile 0.9.8 on my F-8 boxes. If I was forced to stick with > 0.9.7-0.17.svn20071017 I'm sure I would have opened up or CC'd myself > on several bugs. > > Jeff > I did this on my Fedora 8 machine: yum update pulseaudio --enablerepo=development and now: # pulseaudio --version pulseaudio 0.9.8 ;) I have no issues with 0.9.8 breaking my system, but unfortunately I don't see a fix for my bug [1] either. [1] https://bugzilla.redhat.com/show_bug.cgi?id=366001 Valent. From mark.bidewell at alumni.clemson.edu Sat Jan 12 20:47:11 2008 From: mark.bidewell at alumni.clemson.edu (Mark Bidewell) Date: Sat, 12 Jan 2008 15:47:11 -0500 Subject: F8 + rawhide in Qemu In-Reply-To: <20080112065047.04cb96d7.mschwendt.tmp0701.nospam@arcor.de> References: <20080112065047.04cb96d7.mschwendt.tmp0701.nospam@arcor.de> Message-ID: Thanks that worked On Jan 12, 2008 12:50 AM, Michael Schwendt < mschwendt.tmp0701.nospam at arcor.de> wrote: > On Fri, 11 Jan 2008 19:32:04 -0800, Mark Bidewell wrote: > > > I installed F8 in Qemu in order to test rawhide. However, after I > updated > > recently I no longer have network connectivity (the NIC is gone). Have > any > > of you run into this issue? > > Yes, here the interface config scripts all got renamed to *.bak, so > temporarily I needed to "ifup eth1.bak" until I fixed the filenames. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakub.rusinek at gmail.com Sat Jan 12 21:11:43 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Sat, 12 Jan 2008 22:11:43 +0100 Subject: compilation architecture In-Reply-To: <1c252d490801121217w388b7942v9123364d7586b692@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47890354.9040700@poolshark.org> <5e92ee3f0801121027g41fbce5ex19fae021936b6ad4@mail.gmail.com> <1c252d490801121217w388b7942v9123364d7586b692@mail.gmail.com> Message-ID: <5e92ee3f0801121311s169bea3cy7a67582fe3a293f6@mail.gmail.com> 2008/1/12, Joachim Frieben : > > On 1/12/08, Jakub 'Livio' Rusinek wrote: > > > > Don't be silly. Try some > i386 distro, and look at the difference. > > About Firefox, I wasn't using Firefox 3 from RPM, but Trunk snapshot > > from Mozilla's FTP. > > > I'm fairly pissed off that a 15 year old school boy bullies fedora-devel > list subscribers in the most annoying way not even mentioning the flow of > unqualified postings clogging my inbox. After taking a 'yellow card' on the > fedora-art list, Jakub seems to be eager to take another one here .. > > > https://www.redhat.com/archives/fedora-art-list/2007-November/msg00225.html > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > So, unsubscribe yourself if you don't like something! I just want Fedora to be fast, beautiful and yet powerful, but I see you want to come back to C64 epoch... -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From valent.turkovic at gmail.com Sat Jan 12 21:13:11 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Sat, 12 Jan 2008 22:13:11 +0100 Subject: Evolution bug doesn't get fixed - please contribute somehow Message-ID: <64b14b300801121313v18fa775fob3f17ff6c3803560@mail.gmail.com> I use Evolution for my job. My company let me choose my desktop and I choose Fedora. My company uses exchange and I tested it on FC6 and it worked then great and it still works great, but on Fedora 8 it doesn't. I can't use Fedora 8 and Evolution for reading exchange email because or a bug [1] which lingers on for too much time. If you are experienced bugtracker I urge you to please, please contribute somehow in fixing this bug. Thank you a lot in advance. Valent from Croatia. [1] https://bugzilla.redhat.com/show_bug.cgi?id=296671 -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From pertusus at free.fr Sat Jan 12 21:19:40 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 12 Jan 2008 22:19:40 +0100 Subject: compilation architecture In-Reply-To: <5e92ee3f0801121209j12f91c1ud7e81e9fde5b6fc2@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47890354.9040700@poolshark.org> <5e92ee3f0801121027g41fbce5ex19fae021936b6ad4@mail.gmail.com> <1200164065.26270.4.camel@ignacio.lan> <5e92ee3f0801121118x79e207e6jbc03cddc15f24aa9@mail.gmail.com> <20080112143357.0ab033f1@redhat.com> <5e92ee3f0801121209j12f91c1ud7e81e9fde5b6fc2@mail.gmail.com> Message-ID: <20080112211940.GB3043@free.fr> On Sat, Jan 12, 2008 at 09:09:22PM +0100, Jakub 'Livio' Rusinek wrote: > Try openSUSE 10.3. You'll see the difference between it and F8. > It's noticeable FASTER! Knowing why indeed would be interesting. But I guess it doesn't come from the i386 versus i586 arch for rpm. -- Pat From jos at xos.nl Sat Jan 12 21:24:00 2008 From: jos at xos.nl (Jos Vos) Date: Sat, 12 Jan 2008 22:24:00 +0100 Subject: Start/stop of OpenVPN interfaces with ifup/ifdown In-Reply-To: <20080112173018.7dd538e2@lain.camperquake.de> References: <200801112338.m0BNcflD031668@jasmine.xos.nl> <20080112173018.7dd538e2@lain.camperquake.de> Message-ID: <20080112212400.GA9718@jasmine.xos.nl> On Sat, Jan 12, 2008 at 05:30:18PM +0100, Ralf Ertzinger wrote: > I'm using the scripts below on Rawhide and Centos5: > > http://www.skytale.net/files/openvpn-ifscripts/openvpn-ifscripts-0.4-1.sky.src.rpm Thanks. Did you write them yourself or did you only package them? In case of the latter, what is the source of these scripts? Now I have (together with the URL I included in my original mail) two alternatives. Question is which set of scripts is better :-). -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From jakub.rusinek at gmail.com Sat Jan 12 21:34:38 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Sat, 12 Jan 2008 22:34:38 +0100 Subject: compilation architecture In-Reply-To: <20080112211940.GB3043@free.fr> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47890354.9040700@poolshark.org> <5e92ee3f0801121027g41fbce5ex19fae021936b6ad4@mail.gmail.com> <1200164065.26270.4.camel@ignacio.lan> <5e92ee3f0801121118x79e207e6jbc03cddc15f24aa9@mail.gmail.com> <20080112143357.0ab033f1@redhat.com> <5e92ee3f0801121209j12f91c1ud7e81e9fde5b6fc2@mail.gmail.com> <20080112211940.GB3043@free.fr> Message-ID: <5e92ee3f0801121334pd8b0395j4c59cead4b3f56a@mail.gmail.com> 2008/1/12, Patrice Dumas : > > On Sat, Jan 12, 2008 at 09:09:22PM +0100, Jakub 'Livio' Rusinek wrote: > > Try openSUSE 10.3. You'll see the difference between it and F8. > > It's noticeable FASTER! > > Knowing why indeed would be interesting. But I guess it doesn't come > from the i386 versus i586 arch for rpm. > > -- > Pat > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > So where Fedora just... sucks? Don't tell me "everything in Fedora is perfect". Fedora is slow. It's a fact. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pertusus at free.fr Sat Jan 12 21:37:02 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 12 Jan 2008 22:37:02 +0100 Subject: compilation architecture In-Reply-To: <5e92ee3f0801121334pd8b0395j4c59cead4b3f56a@mail.gmail.com> References: <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47890354.9040700@poolshark.org> <5e92ee3f0801121027g41fbce5ex19fae021936b6ad4@mail.gmail.com> <1200164065.26270.4.camel@ignacio.lan> <5e92ee3f0801121118x79e207e6jbc03cddc15f24aa9@mail.gmail.com> <20080112143357.0ab033f1@redhat.com> <5e92ee3f0801121209j12f91c1ud7e81e9fde5b6fc2@mail.gmail.com> <20080112211940.GB3043@free.fr> <5e92ee3f0801121334pd8b0395j4c59cead4b3f56a@mail.gmail.com> Message-ID: <20080112213702.GC3043@free.fr> On Sat, Jan 12, 2008 at 10:34:38PM +0100, Jakub 'Livio' Rusinek wrote: > > > > So where Fedora just... sucks? Don't tell me "everything in Fedora is > perfect". Fedora is slow. It's a fact. If you want to know, search. And avoid coming with ideas, but with facts. -- Pat From jakub.rusinek at gmail.com Sat Jan 12 21:39:48 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Sat, 12 Jan 2008 22:39:48 +0100 Subject: compilation architecture In-Reply-To: <20080112213702.GC3043@free.fr> References: <47890354.9040700@poolshark.org> <5e92ee3f0801121027g41fbce5ex19fae021936b6ad4@mail.gmail.com> <1200164065.26270.4.camel@ignacio.lan> <5e92ee3f0801121118x79e207e6jbc03cddc15f24aa9@mail.gmail.com> <20080112143357.0ab033f1@redhat.com> <5e92ee3f0801121209j12f91c1ud7e81e9fde5b6fc2@mail.gmail.com> <20080112211940.GB3043@free.fr> <5e92ee3f0801121334pd8b0395j4c59cead4b3f56a@mail.gmail.com> <20080112213702.GC3043@free.fr> Message-ID: <5e92ee3f0801121339h12cd998cp730b2ec78e51a10e@mail.gmail.com> 2008/1/12, Patrice Dumas : > > On Sat, Jan 12, 2008 at 10:34:38PM +0100, Jakub 'Livio' Rusinek wrote: > > > > > > > So where Fedora just... sucks? Don't tell me "everything in Fedora is > > perfect". Fedora is slow. It's a fact. > > If you want to know, search. And avoid coming with ideas, but with > facts. > > -- > Pat > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > You're funny... -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpepple at fedoraproject.org Sat Jan 12 21:37:24 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sat, 12 Jan 2008 16:37:24 -0500 Subject: FESCo Meeting Summary for 2008-01-10 Message-ID: <1200173844.24909.14.camel@kennedy> = Members Present = * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Dennis Gilmore (dgilmore) * Bill Nottingham (notting) * Warren Togami (warren) * Kevin Fenzi (nirik) * Tom Callaway (spot) * Josh Boyer (jwb) * Jesse Keating (f13) * Christian Iseli (c4chris) = Absent = * Christopher Aillon (caillon) * David Woodhouse (dwmw2) * Jeremy Katz (jeremy) = Summary = == New Package Maintainer Sponsor == * FESCo approved making caillon a sponsor. == New Maintainer Containment == * FESCo gave general approval f13's new maintainer containment proposal, even though some issues will need to be worked out when it is implemented. f13 plans to work on implementing it, possibly with a summer infrastructure intern. http://fedoraproject.org/wiki/JesseKeating/PackageACLOpening * For: caillon, bpepple, nirik, dgilmore, spot, warren, c4chris, f13 * Against: * Abstain: jeremy, dwmw2, tibbs, notting, jwb == Opening Package ACL's == * FESCo approved f13's opening of package acl's proposal, with the condition that it is implemented after the new maintainer containment is finished. http://fedoraproject.org/wiki/JesseKeating/PackageACLOpening * For: caillon, dwmw2, spot, jwb, nirik, c4chris, bpepple, dgilmore, f13 * Against: * Abstain: notting, tibbs, warren, jeremy IRC log can be found at: http://bpepple.fedorapeople.org/fesco/FESCo-2008-01-11.html /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at camperquake.de Sat Jan 12 21:49:06 2008 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 12 Jan 2008 22:49:06 +0100 Subject: Start/stop of OpenVPN interfaces with ifup/ifdown In-Reply-To: <20080112212400.GA9718@jasmine.xos.nl> References: <200801112338.m0BNcflD031668@jasmine.xos.nl> <20080112173018.7dd538e2@lain.camperquake.de> <20080112212400.GA9718@jasmine.xos.nl> Message-ID: <20080112224906.0db40d74@lain.camperquake.de> Hi. On Sat, 12 Jan 2008 22:24:00 +0100, Jos Vos wrote > Thanks. Did you write them yourself or did you only package them? > In case of the latter, what is the source of these scripts? The scripts are mine, so they are build to do what I need, which may not be what everyone else needs :) From david at lovesunix.net Sat Jan 12 22:01:23 2008 From: david at lovesunix.net (David Nielsen) Date: Sat, 12 Jan 2008 23:01:23 +0100 Subject: compilation architecture In-Reply-To: <5e92ee3f0801121339h12cd998cp730b2ec78e51a10e@mail.gmail.com> References: <47890354.9040700@poolshark.org> <5e92ee3f0801121027g41fbce5ex19fae021936b6ad4@mail.gmail.com> <1200164065.26270.4.camel@ignacio.lan> <5e92ee3f0801121118x79e207e6jbc03cddc15f24aa9@mail.gmail.com> <20080112143357.0ab033f1@redhat.com> <5e92ee3f0801121209j12f91c1ud7e81e9fde5b6fc2@mail.gmail.com> <20080112211940.GB3043@free.fr> <5e92ee3f0801121334pd8b0395j4c59cead4b3f56a@mail.gmail.com> <20080112213702.GC3043@free.fr> <5e92ee3f0801121339h12cd998cp730b2ec78e51a10e@mail.gmail.com> Message-ID: <1200175283.13275.9.camel@localhost.localdomain> l?r, 12 01 2008 kl. 22:39 +0100, skrev Jakub 'Livio' Rusinek: > 2008/1/12, Patrice Dumas : > On Sat, Jan 12, 2008 at 10:34:38PM +0100, Jakub 'Livio' > Rusinek wrote: > > > > > > > So where Fedora just... sucks? Don't tell me "everything in > Fedora is > > perfect". Fedora is slow. It's a fact. > > If you want to know, search. And avoid coming with ideas, but > with > facts. > You're funny... If it's a fact, it should be a piece of cake for you to provide evidence in the form of hard numbers. As easy indeed as it was for drago01 provide numbers to show that you are wrong in your basic assessment (at least in a some what simplistic test case). There's the chain of analysis that is useful: Is Fedora indeed performing slowly compared to distributions released in the same time frame (Fedora 8 vs. OpenSuSE 10.3 or Ubuntu Gutsy)? If yes, what is the specific problem area in terms of performance. How do we test for this to avoid regressions, how do we fix it (if it's fixable at all). Then we need to retest the system performance after the change to see that it does not introduce a regression in another area. You do not jump directly to a conclusion without evidence and then insult contributors. With all possible lack of respect, David Nielsen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From jakub.rusinek at gmail.com Sat Jan 12 22:21:58 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Sat, 12 Jan 2008 23:21:58 +0100 Subject: compilation architecture In-Reply-To: <1200175283.13275.9.camel@localhost.localdomain> References: <1200164065.26270.4.camel@ignacio.lan> <5e92ee3f0801121118x79e207e6jbc03cddc15f24aa9@mail.gmail.com> <20080112143357.0ab033f1@redhat.com> <5e92ee3f0801121209j12f91c1ud7e81e9fde5b6fc2@mail.gmail.com> <20080112211940.GB3043@free.fr> <5e92ee3f0801121334pd8b0395j4c59cead4b3f56a@mail.gmail.com> <20080112213702.GC3043@free.fr> <5e92ee3f0801121339h12cd998cp730b2ec78e51a10e@mail.gmail.com> <1200175283.13275.9.camel@localhost.localdomain> Message-ID: <5e92ee3f0801121421o623d1025p7d993a7214841646@mail.gmail.com> > > With all possible lack of respect, > David Nielsen > I'm not talking with such people. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From csnook at redhat.com Sat Jan 12 22:21:41 2008 From: csnook at redhat.com (Chris Snook) Date: Sat, 12 Jan 2008 17:21:41 -0500 Subject: compilation architecture In-Reply-To: <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> Message-ID: <47893D75.1000406@redhat.com> Jakub 'Livio' Rusinek wrote: > I've used openSUSE (i586) with the same configuration and packages > installed and eg. Firefox 3 was started in < 1 sec. I have no benchmarks > but everything runs faster and is more responsible. > > Our optimalization does nothing compared to > i386 compilation. False. On modern processors, with most userspace code, building for i586 generates code with instruction scheduling that is *slower* than i386 instructions tuned for i686. This is why Fedora builds most packages as i386, tuned for i686. i586 really only makes sense for things like the kernel, glibc, JVMs, and multimedia/hpc libraries that use MMX/SSE instructions. In these cases, i686 will usually be even better, though it occasionally makes sense to build with i586 instructions and tune for i686 if you want to have one package that'll work acceptably on i586 and work very well on i686. On a typical desktop system, you'll never notice the difference between i386, i586, and i686 packages except with high-performance graphics. Your experience with openSUSE is interesting, but it is not related to compiler optimizations. -- Chris > 2008/1/12, drago01 >: > > 2008/1/12 Jakub 'Livio' Rusinek >: > > do we need to support legacy cpu's by i386 compilation? > > i586 would make fedora faster even 3 times. > > difference is noticeable. > > ..... > where are your benchmarks for the "3 times faster" claim? > the i386 packages are already optimized for newer cpus (mtune vs. march) > where it makes sense to have i686 versions there are some (kernel, > glibc) > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > -- > Jakub 'Livio' Rusinek > http://liviopl.jogger.pl/ > From jakub.rusinek at gmail.com Sat Jan 12 22:32:53 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Sat, 12 Jan 2008 23:32:53 +0100 Subject: compilation architecture In-Reply-To: <47893D75.1000406@redhat.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47893D75.1000406@redhat.com> Message-ID: <5e92ee3f0801121432qcf7287cx2982deafafe0674c@mail.gmail.com> I wonder if Fedora will be so fast some day. openSUSE really was faster on my computer. But I don't know why. I thinked it's compilation question. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From csnook at redhat.com Sat Jan 12 22:31:05 2008 From: csnook at redhat.com (Chris Snook) Date: Sat, 12 Jan 2008 17:31:05 -0500 Subject: compilation architecture In-Reply-To: <5e92ee3f0801121118x79e207e6jbc03cddc15f24aa9@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47890354.9040700@poolshark.org> <5e92ee3f0801121027g41fbce5ex19fae021936b6ad4@mail.gmail.com> <1200164065.26270.4.camel@ignacio.lan> <5e92ee3f0801121118x79e207e6jbc03cddc15f24aa9@mail.gmail.com> Message-ID: <47893FA9.5060500@redhat.com> Jakub 'Livio' Rusinek wrote: > So I can say only one thing: "fedora does something in wrong, > performance-loss way". I'm not sure if this is still the case, but I know SuSE used to not enable synchronization in syslogd. Yes, synchronization slows down your logging, but it also greatly improves the chances of having a record of why a system crashed, which is important. I don't mean this as a knock on SuSE, and I don't think that's why you're seeing this difference on your desktop, but it's a great example of how people with different design priorities can make different, reasonable decisions that may seem wrong to someone with the other priorities. Performance is all about tradeoffs. If you actually analyze the problem, you can usually design an intermediate solution that's good enough for people across most of the spectrum. There will always be outliers with special needs, but you can usually make Fedora (or openSuSE for that matter) satisfy them will a little careful tweaking. -- Chris From martin at marquesminen.com.ar Sat Jan 12 22:37:27 2008 From: martin at marquesminen.com.ar (Martin Marques) Date: Sat, 12 Jan 2008 20:37:27 -0200 Subject: Fedora 8 hanging In-Reply-To: <20080112154548.GA18472@devserv.devel.redhat.com> References: <4788DF1F.6050802@marquesminen.com.ar> <20080112154548.GA18472@devserv.devel.redhat.com> Message-ID: <47894127.2000705@marquesminen.com.ar> Alan Cox escribi?: > On Sat, Jan 12, 2008 at 01:39:11PM -0200, Martin Marques wrote: >> with an AMD turion 64 (running Fedora 64) and an Nvidia video card >> (using the binary driver from livna). > > Remove the binary driver. Reboot using the nv Fedora supplied driver and > see how it runs for a bit. If it still hangs then you know its not likely to > be the Nvidia driver > Removed nvidia.ko from the start up and the system hanged at boot time when trying to start NM. Hangs happen randomly as I said: At differnet times of boot or when in graphical mode. From csnook at redhat.com Sat Jan 12 22:34:22 2008 From: csnook at redhat.com (Chris Snook) Date: Sat, 12 Jan 2008 17:34:22 -0500 Subject: compilation architecture In-Reply-To: <5e92ee3f0801121432qcf7287cx2982deafafe0674c@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47893D75.1000406@redhat.com> <5e92ee3f0801121432qcf7287cx2982deafafe0674c@mail.gmail.com> Message-ID: <4789406E.2040003@redhat.com> Jakub 'Livio' Rusinek wrote: > I wonder if Fedora will be so fast some day. openSUSE really was faster > on my computer. But I don't know why. > > I thinked it's compilation question. I'm skeptical, but I'll believe you if you have some data. I suggest starting here: http://people.redhat.com/wcohen/FedoraCore6OProfileTutorial.txt -- Chris From jakub.rusinek at gmail.com Sat Jan 12 22:50:59 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Sat, 12 Jan 2008 23:50:59 +0100 Subject: compilation architecture In-Reply-To: <47893FA9.5060500@redhat.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47890354.9040700@poolshark.org> <5e92ee3f0801121027g41fbce5ex19fae021936b6ad4@mail.gmail.com> <1200164065.26270.4.camel@ignacio.lan> <5e92ee3f0801121118x79e207e6jbc03cddc15f24aa9@mail.gmail.com> <47893FA9.5060500@redhat.com> Message-ID: <5e92ee3f0801121450o6b5adc7rb9dcb5ff667d970f@mail.gmail.com> 2008/1/12, Chris Snook : > > Jakub 'Livio' Rusinek wrote: > > So I can say only one thing: "fedora does something in wrong, > > performance-loss way". > > I'm not sure if this is still the case, but I know SuSE used to not enable > synchronization in syslogd. Yes, synchronization slows down your logging, > but > it also greatly improves the chances of having a record of why a system > crashed, > which is important. > > I don't mean this as a knock on SuSE, and I don't think that's why you're > seeing > this difference on your desktop, but it's a great example of how people > with > different design priorities can make different, reasonable decisions that > may > seem wrong to someone with the other priorities. > > Performance is all about tradeoffs. If you actually analyze the problem, > you > can usually design an intermediate solution that's good enough for people > across > most of the spectrum. There will always be outliers with special needs, > but you > can usually make Fedora (or openSuSE for that matter) satisfy them will a > little > careful tweaking. > > -- Chris > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Fedora and openSUSE (there are openSUSE and SuSE - actuall spelling) are both using rsyslog, the newer, modern system logger. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matt_Domsch at dell.com Sat Jan 12 22:55:12 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 12 Jan 2008 16:55:12 -0600 Subject: Problems with InstantMirror and iso images In-Reply-To: <4787E48A.6080506@gmail.com> References: <4787E094.7090803@cora.nwra.com> <4787E18D.3050403@cora.nwra.com> <4787E48A.6080506@gmail.com> Message-ID: <20080112225512.GC21634@auslistsprd01.us.dell.com> On Fri, Jan 11, 2008 at 01:50:02PM -0800, Andrew Farris wrote: > Orion Poplawski wrote: > >Orion Poplawski wrote: > >>For some reason apparently the download.fedora.redhat.com server > >>doesn't product Last-Modified headers for iso images. This prevents > >>InstantMirror from working with them. Thoughts? > > snip > > >Some more info (looks like a redirect to ftp). I'll file a ticket. > > If I'm not mistaken that redirect is there so that it can share the load > with a few different primary mirrors (so intentional). The redirect to FTP is intentional because older apache servers can't serve >2GB files. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From rhally at mindspring.com Sat Jan 12 23:15:26 2008 From: rhally at mindspring.com (Richard Hally) Date: Sat, 12 Jan 2008 18:15:26 -0500 Subject: anaconda traceback In-Reply-To: <1200152906.4765.56.camel@metroid.rdu.redhat.com> References: <47889B67.9050507@mindspring.com> <4788B179.4000901@gmail.com> <1200152906.4765.56.camel@metroid.rdu.redhat.com> Message-ID: <47894A0E.8090409@mindspring.com> Will Woods wrote: > On Sat, 2008-01-12 at 04:24 -0800, Andrew Farris wrote: >> Richard Hally wrote: >>> When trying to do a network install of rawhide I get the following: >>> >>> (using the boot.iso from rawhide) >>> >>> After retrieving images/stage2.img, >>> >>> "Running anaconda 11.4.0.18, the Fedora installer, please wait... >>> traceback(most recent call last) >>> file "/usr/bin/anaconda" line 623 in >>> from exception import handleException >>> file "/usr/lib/anaconda/exception.py" line 41 in >>> import kickstart >>> file "/use/lib/anaconda/kickstart.py" line 36 in >>> import upgrade >>> file "/usr/lib/anaconda/upgrade.py" line 31 in >>> import selinux >>> Import Error: no module named selinux >>> install exited abnormally [1/1]" >>> >>> ... >>> ok to reboot etc >>> >>> anyone tried installing the current rawhide? does this need a Bugzilla? > > Works for me with today's rawhide (20070112, anaconda 11.4.0.19). I > wasn't using the boot.iso - just booted from the vmlinuz and initrd.img > - but that shouldn't change anything. > > Does it work for you today? > > -w well, it gets past the above error but then X doesn't start so I select text install but it doesn't find any drives to install to. end of story. this is on a box with an intel chipset that runs F8 just fine. Richard From mike at miketc.com Sat Jan 12 23:26:03 2008 From: mike at miketc.com (Mike Chambers) Date: Sat, 12 Jan 2008 17:26:03 -0600 Subject: anaconda traceback In-Reply-To: <47894A0E.8090409@mindspring.com> References: <47889B67.9050507@mindspring.com> <4788B179.4000901@gmail.com> <1200152906.4765.56.camel@metroid.rdu.redhat.com> <47894A0E.8090409@mindspring.com> Message-ID: <1200180363.3376.1.camel@scrappy.miketc.com> On Sat, 2008-01-12 at 18:15 -0500, Richard Hally wrote: > well, it gets past the above error but then X doesn't start so I > select text > install but it doesn't find any drives to install to. end of story. > this is on a > box with an intel chipset that runs F8 just fine. And upon saying that, guess I'll wait for a fix or something before trying again, especially for nada. I don't mind installing via text, but if X isn't going to work post install, then does me no good anyway. So you have intel, I have an ATI x1300 card, and got same thing last time, so there is something wrong with the drivers or something. -- Mike Chambers Madisonville, KY "The best lil town on Earth!" From lordmorgul at gmail.com Sat Jan 12 23:51:06 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sat, 12 Jan 2008 15:51:06 -0800 Subject: compilation architecture In-Reply-To: <5e92ee3f0801121027g41fbce5ex19fae021936b6ad4@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47890354.9040700@poolshark.org> <5e92ee3f0801121027g41fbce5ex19fae021936b6ad4@mail.gmail.com> Message-ID: <4789526A.5010501@gmail.com> Jakub 'Livio' Rusinek wrote: > Don't be silly. Try some > i386 distro, and look at the difference. > About Firefox, I wasn't using Firefox 3 from RPM, but Trunk snapshot from > Mozilla's FTP. I've spent *considerable time* keeping fully optimized i686 mtune p4 -O3 compiled gentoo installed on a machine I also had Fedora rawhide with *my own compiled and optimized i686 kernel and glibc*... the differences are minor at best. I guarantee a i586 compiled SUSE install is not faster than that gentoo build. If you're really seeing that large a performance difference you need to be considering legitimate sources of 'startup' time, such as already mentioned in the thread... disk IO. How SUSE is choosing to link the libraries might be the place to start. Are they prelinking? How. Did they maybe statically link certain apps (like firefox that is used more than anything else)? -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From triad at df.lth.se Sun Jan 13 00:05:10 2008 From: triad at df.lth.se (Linus Walleij) Date: Sun, 13 Jan 2008 01:05:10 +0100 (CET) Subject: SuSE Project SUPER [Was Re: compilation architecture] In-Reply-To: <5e92ee3f0801121432qcf7287cx2982deafafe0674c@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47893D75.1000406@redhat.com> <5e92ee3f0801121432qcf7287cx2982deafafe0674c@mail.gmail.com> Message-ID: On Sat, 12 Jan 2008, Jakub 'Livio' Rusinek wrote: > I thinked it's compilation question. There are much more probable things I think, SuSE had project SUPER http://en.opensuse.org/SUPER This project was closed in November last year because everything desirable had been integrated into OpenSuSE. It doesn't quite say which things they have integrated in the end sadly, but if we ask them they can probably tell us. AFAICS they atleast have these (correct me if wrong): * They use a LOT of preloading, personalized per user with PePr so it preloads the stuff you are most likely to use before you use it. Not strange if you feel it is noticably faster, especially if you have lots of RAM to preload things into. * They are possibly using and maintaining some of the non-mainlined CK patches. (i.e. a kernel responsiveness issue) but looks like they actually don't because of lack of support. Swap prefetch is the usual suspect key patch here. * They default to using reiserfs of their disks which may result in quicker loads. The mount it noatime,notail. This is QUICK. * They prelink heavily. (And so do we I think.) * They have all the same problems with sysvinit as we do. * Yes and they do use -O3 -march i686 -mtune i686 .. probably more. We could do all of these in Fedora of course. If they are using that PePr thing, it would be interesting to test on Fedora, it looks like a cool idea. A rootfs with reiserfs is customizable during install I think, but I don't think it'll mount noatime,notail default, but that is easy to test too. Linus From mike at miketc.com Sun Jan 13 00:07:04 2008 From: mike at miketc.com (Mike Chambers) Date: Sat, 12 Jan 2008 18:07:04 -0600 Subject: anaconda traceback In-Reply-To: <1200180363.3376.1.camel@scrappy.miketc.com> References: <47889B67.9050507@mindspring.com> <4788B179.4000901@gmail.com> <1200152906.4765.56.camel@metroid.rdu.redhat.com> <47894A0E.8090409@mindspring.com> <1200180363.3376.1.camel@scrappy.miketc.com> Message-ID: <1200182824.2226.2.camel@scrappy.miketc.com> On Sat, 2008-01-12 at 17:26 -0600, Mike Chambers wrote: > On Sat, 2008-01-12 at 18:15 -0500, Richard Hally wrote: > > well, it gets past the above error but then X doesn't start so I > > select text > > install but it doesn't find any drives to install to. end of story. > > this is on a > > box with an intel chipset that runs F8 just fine. > > And upon saying that, guess I'll wait for a fix or something before > trying again, especially for nada. I don't mind installing via text, > but if X isn't going to work post install, then does me no good anyway. > > So you have intel, I have an ATI x1300 card, and got same thing last > time, so there is something wrong with the drivers or something. Said heck with it, and tried to do a rawhide install as well, but same problem, no luck. When getting to the partitioning section, it doesn't show the drives at all, and can't find the device or whatever. It does see and know my video card, but it won't start up with whatever driver it should use, nor would it use vesa neither. -- Mike Chambers Madisonville, KY "The best lil town on Earth!" From kevin.kofler at chello.at Sun Jan 13 00:33:42 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 13 Jan 2008 00:33:42 +0000 (UTC) Subject: pirut, pup, system-*: policykit integration References: <5e92ee3f0801110553t66315134le53985bb653984df@mail.gmail.com> <1200070344.2829.5.camel@localhost.localdomain> <16de708d0801110855r3cd266beq70b768c255849a21@mail.gmail.com> <1200071173.2829.12.camel@localhost.localdomain> <5e92ee3f0801120543n68866866k881d9c8da47a6fa0@mail.gmail.com> <5e92ee3f0801120755i23e94af1qa5925f4e34a65e93@mail.gmail.com> <20080112190612.GE936@redhat.com> Message-ID: Daniel P. Berrange redhat.com> writes: > gnome-system-tools lets you do exactly that. The core functionality is > all in the non-GUI backend. The GUI is just a shim which talks to the > backend over DBus. So you can plug in whatever GUI you like and use the > same backend code . Feel free to write a backend for KDE / whatever other > DE you care about... But something tells me the "gnome" in the name won't make the project very attractive to the KDE community... Personally I don't care too much about the name, even though I think having something like "gnome-system-tools-backend" as a dependency of whatever the KDE version would be called if it gets written is going to confuse users. Kevin Kofler From d.jacobfeuerborn at conversis.de Sun Jan 13 00:45:14 2008 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Sun, 13 Jan 2008 01:45:14 +0100 Subject: upgrade to pulseaudio 0.9.8 and/or rawhide kernel makes audio fail Message-ID: <47895F1A.5040607@conversis.de> I yum-upgraded from F8 to rawhide but the current versions of the kernel and pulseaudio 0.9.8 kill audio for me. Using the latest F8 kernel and downgrading some pulseaudio packages back to their F8 version brings audio back to life. Is anybody else seeing this? Details here: https://bugzilla.redhat.com/show_bug.cgi?id=428537 Regards, Dennis From lordmorgul at gmail.com Sun Jan 13 00:45:34 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sat, 12 Jan 2008 16:45:34 -0800 Subject: anaconda traceback In-Reply-To: <1200182824.2226.2.camel@scrappy.miketc.com> References: <47889B67.9050507@mindspring.com> <4788B179.4000901@gmail.com> <1200152906.4765.56.camel@metroid.rdu.redhat.com> <47894A0E.8090409@mindspring.com> <1200180363.3376.1.camel@scrappy.miketc.com> <1200182824.2226.2.camel@scrappy.miketc.com> Message-ID: <47895F2E.2060202@gmail.com> Mike Chambers wrote: > On Sat, 2008-01-12 at 17:26 -0600, Mike Chambers wrote: >> On Sat, 2008-01-12 at 18:15 -0500, Richard Hally wrote: >>> well, it gets past the above error but then X doesn't start so I >>> select text >>> install but it doesn't find any drives to install to. end of story. >>> this is on a >>> box with an intel chipset that runs F8 just fine. >> And upon saying that, guess I'll wait for a fix or something before >> trying again, especially for nada. I don't mind installing via text, >> but if X isn't going to work post install, then does me no good anyway. >> >> So you have intel, I have an ATI x1300 card, and got same thing last >> time, so there is something wrong with the drivers or something. > > Said heck with it, and tried to do a rawhide install as well, but same > problem, no luck. When getting to the partitioning section, it doesn't > show the drives at all, and can't find the device or whatever. It does > see and know my video card, but it won't start up with whatever driver > it should use, nor would it use vesa neither. Same situation for me trying an install on vmware fusion with today's boot.iso and stage2.img. No X startup, no install devices. I mounted a flash drive to get dmesg though. In bugzilla now: https://bugzilla.redhat.com/show_bug.cgi?id=428538 -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From lordmorgul at gmail.com Sun Jan 13 00:48:27 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sat, 12 Jan 2008 16:48:27 -0800 Subject: anaconda traceback In-Reply-To: <47895F2E.2060202@gmail.com> References: <47889B67.9050507@mindspring.com> <4788B179.4000901@gmail.com> <1200152906.4765.56.camel@metroid.rdu.redhat.com> <47894A0E.8090409@mindspring.com> <1200180363.3376.1.camel@scrappy.miketc.com> <1200182824.2226.2.camel@scrappy.miketc.com> <47895F2E.2060202@gmail.com> Message-ID: <47895FDB.4070505@gmail.com> Andrew Farris wrote: > Same situation for me trying an install on vmware fusion with today's > boot.iso and stage2.img. No X startup, no install devices. I mounted a > flash drive to get dmesg though. In bugzilla now: > https://bugzilla.redhat.com/show_bug.cgi?id=428538 I'm going to try this with my P4 dell tower a little bit later. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From d.jacobfeuerborn at conversis.de Sun Jan 13 00:48:56 2008 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Sun, 13 Jan 2008 01:48:56 +0100 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <4788ED3E.50104@redhat.com> References: <4788ED3E.50104@redhat.com> Message-ID: <47895FF8.1080800@conversis.de> Warren Togami wrote: > Does upgrading from 0.9.7 to 0.9.8 break library ABI with applications > already linked against any pulseaudio library? If not, we should really > explore the possibility of upgrading to a newer pulseaudio version in > Fedora 8. 0.9.8 kills my audio completely for me so some testing is definitely required. (https://bugzilla.redhat.com/show_bug.cgi?id=428537) Regards, Dennis From lordmorgul at gmail.com Sun Jan 13 00:59:21 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sat, 12 Jan 2008 16:59:21 -0800 Subject: graphically show dependencies In-Reply-To: <645d17210801120543y7c0933a9y27ad249b17015924@mail.gmail.com> References: <20080112115328.GA2598@free.fr> <200801120752.19888.sgrubb@redhat.com> <1200143975.27355.74.camel@Jehannum> <1200144830.5098.23.camel@ignacio.lan> <645d17210801120543y7c0933a9y27ad249b17015924@mail.gmail.com> Message-ID: <47896269.9010408@gmail.com> Jonathan Underwood wrote: > On 12/01/2008, Ignacio Vazquez-Abrams wrote: >> On Sat, 2008-01-12 at 13:19 +0000, Caolan McNamara wrote: >>> It'd be nice to see a graph of dependencies in pirut, see what things >>> are at the tip of branches that nothing depends on that could be >>> removed. >> Building such a graph is... non-trivial and shouldn't be done on the >> fly. >> > > That said, there is some of the logic in package-cleanup --leaves and > package-cleanup --leaves --all If it could be built and saved as an addition to the rpm database perhaps... might it be faster to 'check' or correct such a graph later so it doesn't need to be built on the fly at all? -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From mzerqung at 0pointer.de Sun Jan 13 01:01:07 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Sun, 13 Jan 2008 02:01:07 +0100 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <47895FF8.1080800@conversis.de> References: <4788ED3E.50104@redhat.com> <47895FF8.1080800@conversis.de> Message-ID: <20080113010106.GA8695@tango.0pointer.de> On Sun, 13.01.08 01:48, Dennis Jacobfeuerborn (d.jacobfeuerborn at conversis.de) wrote: > > Warren Togami wrote: >> Does upgrading from 0.9.7 to 0.9.8 break library ABI with applications >> already linked against any pulseaudio library? If not, we should really >> explore the possibility of upgrading to a newer pulseaudio version in >> Fedora 8. > > 0.9.8 kills my audio completely for me so some testing is definitely > required. (https://bugzilla.redhat.com/show_bug.cgi?id=428537) Please keep bug reports on BZ, not on the ML. Your specific issues is a problem with ALSA, not PA. See my note on the BZ report. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mrmazda at ij.net Sun Jan 13 01:03:29 2008 From: mrmazda at ij.net (Felix Miata) Date: Sat, 12 Jan 2008 20:03:29 -0500 Subject: SuSE Project SUPER In-Reply-To: References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47893D75.1000406@redhat.com> <5e92ee3f0801121432qcf7287cx2982deafafe0674c@mail.gmail.com> Message-ID: <47896361.2010408@ij.net> On 2008/01/13 01:05 (GMT+0100) Linus Walleij apparently typed: > * They default to using reiserfs of their disks which may result in > quicker loads. The mount it noatime,notail. This is QUICK. OpenSUSE switched from reiserfs to ext3 a release or two back. OpenSUSE also supports upgrades that don't require repartitioning. Those with traditional partitions >15, and backup and support strategies that depend on them, have the option to continue using them, including for /. -- "In the beginning was the Word, and the Word was with God, and the Word was God." John 1:1 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/ From lordmorgul at gmail.com Sun Jan 13 01:03:15 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sat, 12 Jan 2008 17:03:15 -0800 Subject: pirut, pup, system-*: policykit integration In-Reply-To: References: <5e92ee3f0801110553t66315134le53985bb653984df@mail.gmail.com> <1200070344.2829.5.camel@localhost.localdomain> <16de708d0801110855r3cd266beq70b768c255849a21@mail.gmail.com> <1200071173.2829.12.camel@localhost.localdomain> <5e92ee3f0801120543n68866866k881d9c8da47a6fa0@mail.gmail.com> <5e92ee3f0801120755i23e94af1qa5925f4e34a65e93@mail.gmail.com> <20080112190612.GE936@redhat.com> Message-ID: <47896353.8090406@gmail.com> Kevin Kofler wrote: > Daniel P. Berrange redhat.com> writes: >> gnome-system-tools lets you do exactly that. The core functionality is >> all in the non-GUI backend. The GUI is just a shim which talks to the >> backend over DBus. So you can plug in whatever GUI you like and use the >> same backend code . Feel free to write a backend for KDE / whatever other >> DE you care about... > > But something tells me the "gnome" in the name won't make the project very > attractive to the KDE community... > > Personally I don't care too much about the name, even though I think having > something like "gnome-system-tools-backend" as a dependency of whatever the KDE > version would be called if it gets written is going to confuse users. > > Kevin Kofler Yeah that probably needs to be rethought, perhaps breaking the backend out to a 'DE independent' package name and description that gnome-system-tools then depends on. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From mclasen at redhat.com Sun Jan 13 01:06:20 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Sat, 12 Jan 2008 20:06:20 -0500 Subject: pirut, pup, system-*: policykit integration In-Reply-To: References: <5e92ee3f0801110553t66315134le53985bb653984df@mail.gmail.com> <1200070344.2829.5.camel@localhost.localdomain> <16de708d0801110855r3cd266beq70b768c255849a21@mail.gmail.com> <1200071173.2829.12.camel@localhost.localdomain> <5e92ee3f0801120543n68866866k881d9c8da47a6fa0@mail.gmail.com> <5e92ee3f0801120755i23e94af1qa5925f4e34a65e93@mail.gmail.com> <20080112190612.GE936@redhat.com> Message-ID: <1200186380.2906.0.camel@localhost.localdomain> On Sun, 2008-01-13 at 00:33 +0000, Kevin Kofler wrote: > Daniel P. Berrange redhat.com> writes: > > gnome-system-tools lets you do exactly that. The core functionality is > > all in the non-GUI backend. The GUI is just a shim which talks to the > > backend over DBus. So you can plug in whatever GUI you like and use the > > same backend code . Feel free to write a backend for KDE / whatever other > > DE you care about... > > But something tells me the "gnome" in the name won't make the project very > attractive to the KDE community... > > Personally I don't care too much about the name, even though I think having > something like "gnome-system-tools-backend" as a dependency of whatever the KDE > version would be called if it gets written is going to confuse users. > > Kevin Kofler > You are lucky... the backends are called system-tools-backends, and live on fd.o: http://system-tools-backends.freedesktop.org/ From mzerqung at 0pointer.de Sun Jan 13 01:16:11 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Sun, 13 Jan 2008 02:16:11 +0100 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <4786E024.7030003@redhat.com> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <20080109094532.811057b2.mschwendt.tmp0701.nospam@arcor.de> <64b14b300801090446u1412557p7bee40aa9922223d@mail.gmail.com> <1199916701.8159.2.camel@localhost.localdomain> <364d303b0801091644s7c9109a8v4b1bfe0f90427cb@mail.gmail.com> <1199964183.8159.15.camel@localhost.localdomain> <364d303b0801100437g1ed6c0b8tb7e71784e9ba3bd@mail.gmail.com> <47862106.2010607@redhat.com> <20080111000616.GC7758@tango.0pointer.de> <4786E024.7030003@redhat.com> Message-ID: <20080113011611.GB11015@tango.0pointer.de> On Thu, 10.01.08 22:19, Warren Togami (wtogami at redhat.com) wrote: >> changes are not really suited for an updated package for an already >> released distribution, since they are almost exclusively new features, >> and only very few relevant bugfixes. I guess this is the classical >> distribution dilemma: are the new >> features or the stability more important? Whatever way I decide, I'll >> make some people unhappy. > > We don't currently have even stability, so it really isn't a choice a > between the two. > > It sounds like 0.9.8 doesn't have relevant stability fixes, and perhaps the > desire to upgrade to 0.9.8 is misguided because it really wouldn't help? Yes, that's basically what I am suggesting. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Sun Jan 13 01:20:14 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Sun, 13 Jan 2008 02:20:14 +0100 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <4786DD67.1030808@redhat.com> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <20080109094532.811057b2.mschwendt.tmp0701.nospam@arcor.de> <64b14b300801090446u1412557p7bee40aa9922223d@mail.gmail.com> <1199916701.8159.2.camel@localhost.localdomain> <364d303b0801091644s7c9109a8v4b1bfe0f90427cb@mail.gmail.com> <1199964183.8159.15.camel@localhost.localdomain> <364d303b0801100437g1ed6c0b8tb7e71784e9ba3bd@mail.gmail.com> <47862106.2010607@redhat.com> <20080111000616.GC7758@tango.0pointer.de> <4786DD67.1030808@redhat.com> Message-ID: <20080113012014.GC11015@tango.0pointer.de> On Thu, 10.01.08 22:07, Warren Togami (wtogami at redhat.com) wrote: > Does upgrading from 0.9.7 to 0.9.8 break library ABI with applications > already linked against any pulseaudio library? If not, we should really > explore the possibility of upgrading to a newer pulseaudio version in > Fedora 8. ABI is stable in all 0.9.x versions. > Later when the test users agree that the pulseaudio package in your test > repository is seemingly good, it can be pushed to F8's updates-testing > repository where many thousands of other users who opt-in to that optional > channel will be exposed to it. It can be tested there for a while before > pushing to the public in the stable updates channel. This multi-layered > approach to testing should ensure that the update is of higher quality than > the current F8 pulseaudio. > > Pulseaudio made many applications that used to be stable suddenly > unreliable. Apps like pidgin, mplayer, xine, Adobe Flash Player and > many Uh, don't get me started on Flash. > more now have weird pulseaudio related crash issues. There is a desire to > pull in newer pulseaudio versions if bugs are fixed to make it more stable. > > Please let us explore the feasibility of upgrading it in F8? I will put a copy of 0.9.8 in updates-testing. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Sun Jan 13 01:27:50 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Sun, 13 Jan 2008 02:27:50 +0100 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <604aa7910801102207v3e67b1a1y6c989cec6bcac110@mail.gmail.com> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <20080109094532.811057b2.mschwendt.tmp0701.nospam@arcor.de> <64b14b300801090446u1412557p7bee40aa9922223d@mail.gmail.com> <1199916701.8159.2.camel@localhost.localdomain> <364d303b0801091644s7c9109a8v4b1bfe0f90427cb@mail.gmail.com> <1199964183.8159.15.camel@localhost.localdomain> <364d303b0801100437g1ed6c0b8tb7e71784e9ba3bd@mail.gmail.com> <47862106.2010607@redhat.com> <20080111000616.GC7758@tango.0pointer.de> <604aa7910801102207v3e67b1a1y6c989cec6bcac110@mail.gmail.com> Message-ID: <20080113012750.GA12654@tango.0pointer.de> On Thu, 10.01.08 21:07, Jeff Spaleta (jspaleta at gmail.com) wrote: > In reality a lot of the specifics on how pulseaudio updating should > work is up to you. Whatever you do just try to be self-consistent > about it. You could even recruit a co-maintainer to help with release > updates if you personally want to focus primarily on devel branch in > the future. Hmm, anyone interested in co-maintaining PA with me and doing stuff like doing updates for released distros and suchlike? I'd be very interested in focussing solely on devel. I'd be very happy about everyone helping out with packaging PA for the stable distros or looking a bit after bz. If you are interested, please ping me in private. Thanks, Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From lordmorgul at gmail.com Sun Jan 13 02:06:48 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sat, 12 Jan 2008 18:06:48 -0800 Subject: Wanted: FireWire testers In-Reply-To: <4788D521.9000701@redhat.com> References: <4787F211.3010402@redhat.com> <4787F580.2030405@gmail.com> <4788D521.9000701@redhat.com> Message-ID: <47897238.4000303@gmail.com> Jarod Wilson wrote: > Les Mikesell wrote: >> Jarod Wilson wrote: >>> If you're among those who have voiced concerns with the FireWire >>> support in >>> Fedora, particularly in the audio/video area, please do try to test >>> out the >>> latest rawhide kernels (2.6.24-0.149.fc7.git2.fc9 or later) and/or the >>> 2.6.23.13 kernel working its way through koji right now[1]. > > Its built. > > http://koji.fedoraproject.org/packages/kernel/2.6.23.13/106.fc8/ > >>> As yet untested with this latest kernel is FireWire video capture off >>> a cable >>> box[3], but that's on my todo list for the weekend. (There's reason to >>> believe >>> this might be working now with the addition of dynamic buffer >>> allocation). > > Nope, still no dice. Will poke more soonish, I'm inclined to think its a > userspace issue... > >> As a perhaps odd case, is it likely to be possible to build an initrd >> containing the firewire driver and have firewire drives included in md >> devices recognized and matched correctly during boot-up? > > Should be doable, yes. If you've got a line in modprobe.conf of 'alias > scsi_hostadapterX firewire-sbp2' (for some value of X) and the array running > when you create your initrd, it *should* automagically include the necessary > modules in the initrd. I'd probably run mkinitrd -v by hand to see for sure. I can confirm that the firewire-sbp2 driver will be included in initrd by kernel installs with that alias present, and it works at least for my single external firewire drive... I don't know about md devices though. It doesn't work flawlessly, I have a problem with my drive causing some kernels not fail booting (https://bugzilla.redhat.com/show_bug.cgi?id=349921) but I'm not sure if its the hardware's fault or not on that one. But as the bug says once the kernel is running access to the drive is fine. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From sandeen at redhat.com Sun Jan 13 03:39:30 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Sat, 12 Jan 2008 21:39:30 -0600 Subject: compilation architecture In-Reply-To: <5e92ee3f0801121339h12cd998cp730b2ec78e51a10e@mail.gmail.com> References: <47890354.9040700@poolshark.org> <5e92ee3f0801121027g41fbce5ex19fae021936b6ad4@mail.gmail.com> <1200164065.26270.4.camel@ignacio.lan> <5e92ee3f0801121118x79e207e6jbc03cddc15f24aa9@mail.gmail.com> <20080112143357.0ab033f1@redhat.com> <5e92ee3f0801121209j12f91c1ud7e81e9fde5b6fc2@mail.gmail.com> <20080112211940.GB3043@free.fr> <5e92ee3f0801121334pd8b0395j4c59cead4b3f56a@mail.gmail.com> <20080112213702.GC3043@free.fr> <5e92ee3f0801121339h12cd998cp730b2ec78e51a10e@mail.gmail.com> Message-ID: <478987F2.9040505@redhat.com> Jakub 'Livio' Rusinek wrote: > 2008/1/12, Patrice Dumas >: > > On Sat, Jan 12, 2008 at 10:34:38PM +0100, Jakub 'Livio' Rusinek wrote: > > > > > > > So where Fedora just... sucks? Don't tell me "everything in Fedora is > > perfect". Fedora is slow. It's a fact. > > If you want to know, search. And avoid coming with ideas, but with > facts. > You're funny... No, serious. And I think Patrice is willing to believe you when you say Fedora feels slower than OpenSuSE. But, if it's real, and you're motivated to see it change, stick with it, and *really* find out why it is so. First prove it: find a representative test, measure it objectively, and if Fedora is slower, find out why by further measurement and testing. You can be part of the solution. For example - the Linux Battery Life Toolkit (BLTK) has 6 representative workloads - Idle, Reader, Office, DVD Player, SW Developer, and 3D-Gamer. Maybe that could be a place to start: tweak it to measure the time for one run of an interesting workload on a fresh boot & login on both platforms. (This may not be the right test; "feels faster" is probably more of a latency/responsiveness thing than a total runtime thing, but perhaps this gets you thinking in the right direction). Show the numbers that prove your impression, and people will probably get much more interested. One thing I think SuSE does is more aggressive preloading of shared libraries: http://sourceware.org/ml/libc-alpha/2004-07/msg00135.html Like anything, this has tradeoffs of course. But it's an example of one difference worth investigating. (Incidentally, in that thread, Ulrich asks for hard numbers to show the performance gain, if any. Detect a theme here?) :) -Eric From lordmorgul at gmail.com Sun Jan 13 07:43:23 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sat, 12 Jan 2008 23:43:23 -0800 Subject: Wanted: FireWire testers In-Reply-To: <47897238.4000303@gmail.com> References: <4787F211.3010402@redhat.com> <4787F580.2030405@gmail.com> <4788D521.9000701@redhat.com> <47897238.4000303@gmail.com> Message-ID: <4789C11B.2040804@gmail.com> Andrew Farris wrote: > Jarod Wilson wrote: >> Les Mikesell wrote: >>> Jarod Wilson wrote: >>>> If you're among those who have voiced concerns with the FireWire >>>> support in >>>> Fedora, particularly in the audio/video area, please do try to test >>>> out the >>>> latest rawhide kernels (2.6.24-0.149.fc7.git2.fc9 or later) and/or the >>>> 2.6.23.13 kernel working its way through koji right now[1]. >> >> Its built. >> >> http://koji.fedoraproject.org/packages/kernel/2.6.23.13/106.fc8/ I tried the koji kernel linked above and this boot panic problem I was having seems to be fixed with that new kernel. If anyone has had issues with firewire drives when booting kernels in F8 take a look at: https://bugzilla.redhat.com/show_bug.cgi?id=428554 -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From drago01 at gmail.com Sun Jan 13 10:02:59 2008 From: drago01 at gmail.com (drago01) Date: Sun, 13 Jan 2008 11:02:59 +0100 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <20080113011611.GB11015@tango.0pointer.de> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <20080109094532.811057b2.mschwendt.tmp0701.nospam@arcor.de> <64b14b300801090446u1412557p7bee40aa9922223d@mail.gmail.com> <1199916701.8159.2.camel@localhost.localdomain> <364d303b0801091644s7c9109a8v4b1bfe0f90427cb@mail.gmail.com> <1199964183.8159.15.camel@localhost.localdomain> <364d303b0801100437g1ed6c0b8tb7e71784e9ba3bd@mail.gmail.com> <47862106.2010607@redhat.com> <20080111000616.GC7758@tango.0pointer.de> <4786E024.7030003@redhat.com> <20080113011611.GB11015@tango.0pointer.de> Message-ID: <4789E1D3.3060802@gmail.com> Lennart Poettering wrote: > On Thu, 10.01.08 22:19, Warren Togami (wtogami at redhat.com) wrote: > > >>> changes are not really suited for an updated package for an already >>> released distribution, since they are almost exclusively new features, >>> and only very few relevant bugfixes. I guess this is the classical >>> distribution dilemma: are the new >>> features or the stability more important? Whatever way I decide, I'll >>> make some people unhappy. >>> >> We don't currently have even stability, so it really isn't a choice a >> between the two. >> >> It sounds like 0.9.8 doesn't have relevant stability fixes, and perhaps the >> desire to upgrade to 0.9.8 is misguided because it really wouldn't help? >> > > Yes, that's basically what I am suggesting. > > new features (if they don't break stuff, come with an incomaptible API/ABI) are reasons for a update too. (maybe not for RHEL or debian but for distors like fedora). From jakub.rusinek at gmail.com Sun Jan 13 11:25:25 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Sun, 13 Jan 2008 12:25:25 +0100 Subject: SuSE Project SUPER [Was Re: compilation architecture] In-Reply-To: References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47893D75.1000406@redhat.com> <5e92ee3f0801121432qcf7287cx2982deafafe0674c@mail.gmail.com> Message-ID: <5e92ee3f0801130325n3aaa76ceo53a4a099c295941b@mail.gmail.com> > > * They default to using reiserfs of their disks which may result in > quicker loads. The mount it noatime,notail. This is QUICK. Not in openSUSE. SuSE maybe uses Reiser, but default for openSUSE is extended 2 or 3. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From buildsys at redhat.com Sun Jan 13 14:08:26 2008 From: buildsys at redhat.com (Build System) Date: Sun, 13 Jan 2008 09:08:26 -0500 Subject: rawhide report: 20080113 changes Message-ID: <200801131408.m0DE8QiV004072@porkchop.devel.redhat.com> New package R-qvalue Q-value estimation for false discovery rate control New package fprint_demo Demo of the fprint drivers New package librtfcomp Library for reading of compressed RTF files New package pywbxml Python wrapper for wbxml2 Updated Packages: Io-language-20071010-2.fc9 -------------------------- * Sat Jan 12 2008 Hans de Goede 20071010-2 - Fix compilation with gcc 4.3 - Enable Cairo addon PyX-0.10-3.fc9 -------------- * Sat Jan 12 2008 Jos?? Matos - 0.10-3 - egg-info is in sitearch... * Fri Jan 11 2008 Jos?? Matos - 0.10-2 - Add egg-info to F9+. * Fri Jan 11 2008 Jos?? Matos - 0.10-1 - New upstream release (#426816). - Package cleanup. SteGUI-0.0.1-12.fc9 ------------------- TnL-071111-2.fc9 ---------------- * Sat Jan 12 2008 Hans de Goede 071111-2 - Fix compilation with gcc 4.3 amoebax-0.2.0-2.fc9 ------------------- asc-2.0.1.0-2.fc9 ----------------- * Sat Jan 12 2008 Hans de Goede 2.0.1.0-2 - Fix compilation with gcc-4.3 boswars-2.4.1-4.fc9 ------------------- * Sat Jan 12 2008 Hans de Goede 2.4.1-4 - Fix compilation with gcc 4.3 - Drop workaround for intel graphics crash, this is "fixed" in SDL now chkrootkit-0.48-2.fc9 --------------------- * Sat Jan 12 2008 Michael Schwendt - 0.48-2 - Install README with mode 0644. cppad-20071229-6.fc9 -------------------- * Sat Jan 12 2008 Brad Bell 20071229-6 - Remove speed estimation correctness test because we are not in control of - which other jobs are on the machine that is doing the rpmbuild. * Fri Jan 11 2008 Brad Bell 20071229-5 - Remove introduction/exp_apx/exp_apx from the set of tests - (which should have been done in 20071229-4). - From now on test building rpm locally before making tags. * Thu Jan 10 2008 Brad Bell 20071229-4 - Add code to print out DBL_EPSILON at the beginning of the example tests. - Remove --with-Introduction (it only checks by hand calculations that are in - AD Introduction section of the documentation). - Remove extra --with-Documentation epiphany-2.21.5-0.1.svn7856.fc9 ------------------------------- * Sat Jan 12 2008 Christopher Aillon - 2.21.5-0.1.svn7856 - Update to newer svn, and update the xulrunner 1.9 patch gdb-6.7.1-10.fc9 ---------------- * Sat Jan 12 2008 Jan Kratochvil - 6.7.1-10 - Compilation fixup (-9 was never released). * Sat Jan 12 2008 Jan Kratochvil - 6.7.1-9 - Fix also threaded inferiors for hardware watchpoints after the fork call. - Test debugging statically linked threaded inferiors (BZ 239652). - It requires recent glibc to work in this case properly. - Testcase cleanup fixup of the gcore memory and time requirements of 6.7.1-8. * Thu Jan 10 2008 Jan Kratochvil - 6.7.1-8 - Fix detaching from a threaded formerly stopped process with non-primary thread currently active (general BZ 233852). - Enable back again the testcases named `attachstop.exp' (no such exist now). - Rename the testcase `gdb.threads/attachstop' to `gdb.threads/attachstop-mt'. - Test ia64 memory leaks of the code using libunwind. - Testcase delay increase (for BZ 247354). - Test gcore memory and time requirements for large inferiors. glew-1.4.0-4.fc9 ---------------- * Sat Jan 12 2008 Hans de Goede 1.4.0-4 - Add missing GL_FLOAT_MATXxX defines hedgewars-0.9.0-5.fc9 --------------------- * Sat Jan 12 2008 Hans de Goede 0.9.0-5 - Fix compilation with gcc 4.3 homebank-3.6-1.fc9 ------------------ * Sat Jan 12 2008 Johan Cwiklinski 3.6-1 - new upstream release * Sun Sep 16 2007 Johan Cwiklinski 3.5-5 - Removed pango from BR - Added libofx-devel to BR - Using macros everywhere - Added update-desktop-databas to post * Tue Sep 11 2007 Johan Cwiklinski 3.5-4 - Added release to doc subpackage requires kernel-2.6.24-0.150.rc7.git4.fc9 -------------------------------- * Sat Jan 12 2008 Kyle McMartin - 2.6.24-rc7-git4 * Fri Jan 11 2008 Jarod Wilson - Add linux1394/firewire git patches - FireWire IR dynamic buffer alloc (David Moore) * Thu Jan 10 2008 Chuck Ebbert - temporarily fix up utrace breakage njam-1.25-8.fc9 --------------- * Sat Jan 12 2008 Hans de Goede 1.25-8 - Fix compilation with gcc 4.3 pachi-1.0-4.fc9 --------------- * Sat Jan 12 2008 Hans de Goede 1.0-4 - Fix compilation with gcc 4.3 perl-Parse-CPAN-Packages-2.27-1.fc9 ----------------------------------- * Sat Jan 12 2008 Steven Pritchard 2.27-1 - Update to 2.27. - Switch from building with Build.PL to Makefile.PL. perl-Pod-Coverage-0.19-1.fc9 ---------------------------- * Sat Jan 12 2008 Steven Pritchard 0.19-1 - Update to 0.19. - Use fixperms macro instead of our own chmod incantation. - Reformat to match cpanspec output. * Wed Jan 10 2007 Tom "spot" Callaway - 0.18-3 - rebuild 2, enable Test::Pod, tests * Wed Jan 10 2007 Tom "spot" Callaway - 0.18-2.1 - rebuild (first pass, no tests, no Test::Pod) perl-Test-Deep-0.099-1.fc9 -------------------------- * Sat Jan 12 2008 Steven Pritchard 0.099-1 - Update to 0.099. - Update License tag. perl-Test-Exception-0.26-1.fc9 ------------------------------ * Sat Jan 12 2008 Steven Pritchard 0.26-1 - Update to 0.26. - Update License tag. - Use fixperms macro instead of our own chmod incantation. - Reformat to match cpanspec output. - Drop executable bits. perl-Test-NoWarnings-0.084-1.fc9 -------------------------------- * Sat Jan 12 2008 Steven Pritchard 0.084-1 - Update to 0.084. - Update License. - BR Devel::StackTrace. plplot-5.8.0-8.fc9 ------------------ * Sat Jan 12 2008 - Orion Poplawski - 5.8.0-8 - Re-enable itcl python-bugzilla-0.3-1.fc9 ------------------------- * Sat Jan 12 2008 Will Woods 0.3-1 - Update to python-bugzilla 0.3 - 'modify' works in the commandline-util - add Bug.close() and Bug.setstatus() scummvm-0.10.0-3.fc9 -------------------- * Sat Jan 12 2008 Hans de Goede 0.10.0-3 - Fix compilation with gcc 4.3 uniconvertor-1.1.0-1.fc9 ------------------------ * Sat Jan 12 2008 Andy Shevchenko 1.1.0-1 - update to 1.1.0 wbxml2-0.9.2-12.fc9 ------------------- * Sat Jan 12 2008 Andreas Bierfert - 0.9.2-12 - pkgconfig also needs libxml2-devel * Sat Jan 12 2008 Andreas Bierfert - 0.9.2-11 - fix devel requires xine-lib-1.1.9.1-1.fc9 ---------------------- * Sat Jan 12 2008 Ville Skytt?? - 1.1.9.1-1 - 1.1.9.1 (security update). xulrunner-1.9-0.beta2.9.fc9 --------------------------- * Sat Jan 12 2008 Christopher Aillon 1.9-0.beta2.9 - Provide gecko-devel-unstable as well Broken deps for i386 ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.i386 requires libgtkembedmoz.so epiphany-extensions - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 gcl - 2.6.7-15.fc8.i386 requires libtk8.4.so gcl - 2.6.7-15.fc8.i386 requires libtcl8.4.so gdal-perl - 1.5.0-1.fc9.i386 requires perl(Geo::GDAL::Const) gnome-web-photo - 0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.i386 requires libgtkembedmoz.so gnome-web-photo - 0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 kazehakase - 0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 netgen - 1.3.7-13.fc9.i386 requires libtk8.4.so netgen - 1.3.7-13.fc9.i386 requires libtcl8.4.so openoffice.org-devel - 1:2.4.0-1.1.fc9.i386 requires sdk openoffice.org-devel - 1:2.4.0-1.1.fc9.i386 requires /bin/python openoffice.org-devel - 1:2.4.0-1.1.fc9.i386 requires /usr/solar/bin/perl tkinter - 2.5.1-20.fc9.i386 requires libTix8.4.so vtk - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtcl8.4.so Broken deps for x86_64 ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gcl - 2.6.7-15.fc8.x86_64 requires libtk8.4.so()(64bit) gcl - 2.6.7-15.fc8.x86_64 requires libtcl8.4.so()(64bit) gdal-perl - 1.5.0-1.fc9.x86_64 requires perl(Geo::GDAL::Const) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) kazehakase - 0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 netgen - 1.3.7-13.fc9.x86_64 requires libtcl8.4.so()(64bit) netgen - 1.3.7-13.fc9.x86_64 requires libtk8.4.so()(64bit) openoffice.org-devel - 1:2.4.0-1.1.fc9.i386 requires sdk openoffice.org-devel - 1:2.4.0-1.1.fc9.i386 requires /bin/python openoffice.org-devel - 1:2.4.0-1.1.fc9.i386 requires /usr/solar/bin/perl openoffice.org-devel - 1:2.4.0-1.1.fc9.x86_64 requires sdk openoffice.org-devel - 1:2.4.0-1.1.fc9.x86_64 requires /bin/python openoffice.org-devel - 1:2.4.0-1.1.fc9.x86_64 requires /usr/solar/bin/perl tkinter - 2.5.1-20.fc9.x86_64 requires libTix8.4.so()(64bit) vtk - 5.0.3-20.fc8.x86_64 requires libtk8.4.so()(64bit) vtk - 5.0.3-20.fc8.x86_64 requires libtcl8.4.so()(64bit) vtk - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.x86_64 requires libtk8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.x86_64 requires libtcl8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.x86_64 requires libtk8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.x86_64 requires libtcl8.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.ppc requires libgtkembedmoz.so epiphany-extensions - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 gdal-perl - 1.5.0-1.fc9.ppc requires perl(Geo::GDAL::Const) gnome-web-photo - 0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.ppc requires libgtkembedmoz.so gnome-web-photo - 0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 kazehakase - 0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 monodevelop - 0.17-4.fc9.ppc requires boo netgen - 1.3.7-13.fc9.ppc requires libtk8.4.so netgen - 1.3.7-13.fc9.ppc requires libtcl8.4.so openoffice.org-devel - 1:2.4.0-1.1.fc9.ppc requires sdk openoffice.org-devel - 1:2.4.0-1.1.fc9.ppc requires /bin/python openoffice.org-devel - 1:2.4.0-1.1.fc9.ppc requires /usr/solar/bin/perl openoffice.org-devel - 1:2.4.0-1.1.fc9.ppc64 requires sdk openoffice.org-devel - 1:2.4.0-1.1.fc9.ppc64 requires /bin/python openoffice.org-devel - 1:2.4.0-1.1.fc9.ppc64 requires /usr/solar/bin/perl tkinter - 2.5.1-20.fc9.ppc requires libTix8.4.so vtk - 5.0.3-20.fc8.ppc requires libtcl8.4.so vtk - 5.0.3-20.fc8.ppc requires libtk8.4.so vtk - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc requires libtk8.4.so vtk-python - 5.0.3-20.fc8.ppc requires libtcl8.4.so vtk-python - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc requires libtk8.4.so vtk-tcl - 5.0.3-20.fc8.ppc requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) Broken deps for ppc64 ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gdal-perl - 1.5.0-1.fc9.ppc64 requires perl(Geo::GDAL::Const) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) kazehakase - 0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 netgen - 1.3.7-13.fc9.ppc64 requires libtcl8.4.so()(64bit) netgen - 1.3.7-13.fc9.ppc64 requires libtk8.4.so()(64bit) openoffice.org-devel - 1:2.4.0-1.1.fc9.ppc64 requires sdk openoffice.org-devel - 1:2.4.0-1.1.fc9.ppc64 requires /bin/python openoffice.org-devel - 1:2.4.0-1.1.fc9.ppc64 requires /usr/solar/bin/perl perl-Test-AutoBuild-darcs - 1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 tkinter - 2.5.1-20.fc9.ppc64 requires libTix8.4.so()(64bit) vtk - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) From mike at miketc.com Sun Jan 13 14:59:15 2008 From: mike at miketc.com (Mike Chambers) Date: Sun, 13 Jan 2008 08:59:15 -0600 Subject: Wanted: FireWire testers In-Reply-To: <4789C11B.2040804@gmail.com> References: <4787F211.3010402@redhat.com> <4787F580.2030405@gmail.com> <4788D521.9000701@redhat.com> <47897238.4000303@gmail.com> <4789C11B.2040804@gmail.com> Message-ID: <1200236355.2355.2.camel@scrappy.miketc.com> On Sat, 2008-01-12 at 23:43 -0800, Andrew Farris wrote: > >> Its built. > >> > >> http://koji.fedoraproject.org/packages/kernel/2.6.23.13/106.fc8/ > > I tried the koji kernel linked above and this boot panic problem I was having > seems to be fixed with that new kernel. If anyone has had issues with firewire > drives when booting kernels in F8 take a look at: I tried that kernel, it booted fine, but when it starting the x server, going into gnome or whatever, it shows a weird jibberish display and locks up hard, nothing works. You can boot to run level 3 and startx locks it up. Hope this update isn't coming through testing/updates for F8. -- Mike Chambers Madisonville, KY "The best lil town on Earth!" From jkeating at redhat.com Sun Jan 13 15:09:46 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 13 Jan 2008 10:09:46 -0500 Subject: compilation architecture In-Reply-To: <5e92ee3f0801121450o6b5adc7rb9dcb5ff667d970f@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47890354.9040700@poolshark.org> <5e92ee3f0801121027g41fbce5ex19fae021936b6ad4@mail.gmail.com> <1200164065.26270.4.camel@ignacio.lan> <5e92ee3f0801121118x79e207e6jbc03cddc15f24aa9@mail.gmail.com> <47893FA9.5060500@redhat.com> <5e92ee3f0801121450o6b5adc7rb9dcb5ff667d970f@mail.gmail.com> Message-ID: <20080113100946.3999576d@redhat.com> On Sat, 12 Jan 2008 23:50:59 +0100 "Jakub 'Livio' Rusinek" wrote: > Fedora and openSUSE (there are openSUSE and SuSE - actuall spelling) > are both using rsyslog, the newer, modern system logger. Which still has the option to sync the writes to the logger so that you have a record of what happened that doesn't get lost at a power outage. Fedora uses rsyslog too, which if you looked you would have noticed. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From markg85 at gmail.com Sun Jan 13 16:09:28 2008 From: markg85 at gmail.com (Mark) Date: Sun, 13 Jan 2008 17:09:28 +0100 Subject: compilation architecture In-Reply-To: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> Message-ID: <6e24a8e80801130809m78a158bfx4ca9ecb2a3b7129@mail.gmail.com> 2008/1/12, Jakub 'Livio' Rusinek : > do we need to support legacy cpu's by i386 compilation? > i586 would make fedora faster even 3 times. > difference is noticeable. > > -- > Jakub 'Livio' Rusinek > http://liviopl.jogger.pl/ > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list You really are making a fool of yourself around here. i can't imagine that the architecture has anything to do with performance. but this [1] will most likely explain why openSuSE is so "much" faster than fedora. Fedora used to use caching (preload) as well but it wasn't offering speed improvements on default installs. more the opposite and that why it's not in fedora anymore. Apparently opensuse has a better/custom/other preloading system than fedora had (which was readahead) and that's causing the speed improvements that you noticed. If you want to do a "fair" comparison of the speed than you must run Firefox on fedora once first (than it gets cached) and than start measuring the speed when you open it again. i bet it will be about equal to opensuse. I did this test a while ago with readahead and if the readahead files have the right paths than you will notice speed improvements in all apps that are in the readahead list. Fedora currently has no (correct me if i'm wrong) preloading/readahead thing started with a default install so (nearly) nothing gets pumped into the memory to get speed improvements. They will get there once they are started. So fedora isn't fast or slow. it's just working without caching programs that improve your performance. Perhaps it's time for fedora to look how opensuse is doing this preloading and investigate if that can be used in Fedora 9 (or Fedora 10 if 9 is feature frozen). [1] http://en.opensuse.org/SUPER_standard_benchmark From naheemzaffar at gmail.com Sun Jan 13 16:47:44 2008 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Sun, 13 Jan 2008 16:47:44 +0000 Subject: compilation architecture In-Reply-To: <6e24a8e80801130809m78a158bfx4ca9ecb2a3b7129@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <6e24a8e80801130809m78a158bfx4ca9ecb2a3b7129@mail.gmail.com> Message-ID: <3adc77210801130847p237383dcg5fc3bbf45419c9e8@mail.gmail.com> I would expect different services to also cause some performance penalties. I doubt OpenSUSE uses SElinux for one. This is a selling point for Fedora. From jonathan.underwood at gmail.com Sun Jan 13 17:13:27 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 13 Jan 2008 17:13:27 +0000 Subject: compilation architecture In-Reply-To: <3adc77210801130847p237383dcg5fc3bbf45419c9e8@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <6e24a8e80801130809m78a158bfx4ca9ecb2a3b7129@mail.gmail.com> <3adc77210801130847p237383dcg5fc3bbf45419c9e8@mail.gmail.com> Message-ID: <645d17210801130913r68d830bdk511ad3a0ac7e9187@mail.gmail.com> On 13/01/2008, Naheem Zaffar wrote: > I would expect different services to also cause some performance > penalties. I doubt OpenSUSE uses SElinux for one. This is a selling > point for Fedora. > This thread makes for interesting reading on the overhead of SElinux: http://lkml.org/lkml/2007/9/6/14 Even with that patch, SElinux seems to incur a 25% overhead on simple file open/close. Not sure if that's since been adressed, or if I am misinterpretting the data given. From drago01 at gmail.com Sun Jan 13 17:31:49 2008 From: drago01 at gmail.com (drago01) Date: Sun, 13 Jan 2008 18:31:49 +0100 Subject: compilation architecture In-Reply-To: <645d17210801130913r68d830bdk511ad3a0ac7e9187@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <6e24a8e80801130809m78a158bfx4ca9ecb2a3b7129@mail.gmail.com> <3adc77210801130847p237383dcg5fc3bbf45419c9e8@mail.gmail.com> <645d17210801130913r68d830bdk511ad3a0ac7e9187@mail.gmail.com> Message-ID: On Jan 13, 2008 6:13 PM, Jonathan Underwood wrote: > On 13/01/2008, Naheem Zaffar wrote: > > I would expect different services to also cause some performance > > penalties. I doubt OpenSUSE uses SElinux for one. This is a selling > > point for Fedora. > > > > This thread makes for interesting reading on the overhead of SElinux: > > http://lkml.org/lkml/2007/9/6/14 > > Even with that patch, SElinux seems to incur a 25% overhead on simple > file open/close. Not sure if that's since been adressed, or if I am > misinterpretting the data given. This is about a patch that fixes this issue and the patch is already merged. From txtoth at gmail.com Sun Jan 13 17:33:36 2008 From: txtoth at gmail.com (Xavier Toth) Date: Sun, 13 Jan 2008 11:33:36 -0600 Subject: xmlto build errors Message-ID: I googled for fixes to this problem but didn't see any. rpmbuild -bb ../SPECS/xmlto.spec Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.59339 + umask 022 + cd /home/jcdxdev/src2/Linux_x86_64/BUILD/rpmbuild/BUILD + LANG=C + export LANG + unset DISPLAY + cd /home/jcdxdev/src2/Linux_x86_64/BUILD/rpmbuild/BUILD + rm -rf xmlto-0.0.18 + /usr/bin/bzip2 -dc /home/jcdxdev/src2/Linux_x86_64/BUILD/rpmbuild/SOURCES/xmlto-0.0.18.tar.bz2 + tar -xf - + STATUS=0 + '[' 0 -ne 0 ']' + cd xmlto-0.0.18 ++ /usr/bin/id -u + '[' 500 = 0 ']' ++ /usr/bin/id -u + '[' 500 = 0 ']' + /bin/chmod -Rf a+rX,u+w,g-w,o-w . + echo 'Patch #0 (xmlto-basename.patch):' Patch #0 (xmlto-basename.patch): + patch -p1 -b --suffix .basename -s + echo 'Patch #1 (xmlto-findwarning.patch):' Patch #1 (xmlto-findwarning.patch): + patch -p1 -b --suffix .findwarning -s + exit 0 Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.59339 + umask 022 + cd /home/jcdxdev/src2/Linux_x86_64/BUILD/rpmbuild/BUILD + cd xmlto-0.0.18 + LANG=C + export LANG + unset DISPLAY + touch doc/xmlto.xml doc/xmlif.xml + CFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' + export CFLAGS + CXXFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' + export CXXFLAGS + FFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' + export FFLAGS ++ find . -name config.guess -o -name config.sub + ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for x86_64-redhat-linux-gnu-gcc... no checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking whether gcc and cc understand -c and -o together... yes checking for flex... flex checking for yywrap in -lfl... yes checking lex output file root... lex.yy checking whether yytext is a pointer... yes checking for mktemp program... mktemp checking for GNU find program... find checking for bash... bash checking for getopt program... getopt checking whether getopt handles long options... yes configure: creating ./config.status config.status: creating Makefile config.status: creating xmlto config.status: creating xmlto.spec config.status: creating config.h config.status: executing depfiles commands + make make all-am make[1]: Entering directory `/home/jcdxdev/src2/Linux_x86_64/BUILD/rpmbuild/BUILD/xmlto-0.0.18' if gcc -DHAVE_CONFIG_H -I. -I. -I. -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -MT xmlif/xmlif.o -MD -MP -MF "xmlif/.deps/xmlif.Tpo" -c -o xmlif/xmlif.o `test -f 'xmlif/xmlif.c' || echo './'`xmlif/xmlif.c; \ then mv -f "xmlif/.deps/xmlif.Tpo" "xmlif/.deps/xmlif.Po"; else rm -f "xmlif/.deps/xmlif.Tpo"; exit 1; fi xmlif/xmlif.l:33: warning: type defaults to 'int' in declaration of 'ifsense' xmlif/xmlif.c: In function 'yylex': xmlif/xmlif.l:215: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result xmlif/xmlif.l: At top level: xmlif/xmlif.l:223: warning: return type defaults to 'int' xmlif/xmlif.l: In function 'main': xmlif/xmlif.l:249: warning: control reaches end of non-void function xmlif/xmlif.l: At top level: xmlif/xmlif.c:1844: warning: 'yyunput' defined but not used gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -o xmlif/xmlif xmlif/xmlif.o for xml in xmlif.xml xmlto.xml; do \ FORMAT_DIR=./format XSL_DIR=./xsl \ bash ./xmlto -o man/man1 man ./doc/$xml ; \ done || ( RC=$?; cat ./FAQ; exit $RC ) I/O error : Attempt to load network entity http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl warning: failed to load external entity "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl" compilation error: file /tmp/xmlto-xsl.Xn2521 line 4 element import xsl:import : unable to load http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl I/O error : Attempt to load network entity http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl warning: failed to load external entity "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl" compilation error: file /tmp/xmlto-xsl.KT2576 line 4 element import xsl:import : unable to load http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl Q: I'm trying to build xmlto on my Debian box, but it doesn't work. A: If you get `Attempt to load network entity' errors when building xmlto, your system does not have the required support for XML Catalogs (http://www.oasis-open.org/committees/entity/spec-2001-08-06.html). In particular, Debian has no support for these. Try the Fedora Project . make[1]: *** [man/man1/xmlto.1] Error 1 make[1]: Leaving directory `/home/jcdxdev/src2/Linux_x86_64/BUILD/rpmbuild/BUILD/xmlto-0.0.18' make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.59339 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.59339 (%build) From jonathan.underwood at gmail.com Sun Jan 13 17:34:52 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 13 Jan 2008 17:34:52 +0000 Subject: compilation architecture In-Reply-To: References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <6e24a8e80801130809m78a158bfx4ca9ecb2a3b7129@mail.gmail.com> <3adc77210801130847p237383dcg5fc3bbf45419c9e8@mail.gmail.com> <645d17210801130913r68d830bdk511ad3a0ac7e9187@mail.gmail.com> Message-ID: <645d17210801130934x680130c2y687c2b0b1e86c3af@mail.gmail.com> On 13/01/2008, drago01 wrote: > This is about a patch that fixes this issue and the patch is already merged. I think you missread. The patch fixes the overhead of file read and write. It does not address the 25 % overhead associated with file open/close - look further down the thread. From drago01 at gmail.com Sun Jan 13 17:41:14 2008 From: drago01 at gmail.com (drago01) Date: Sun, 13 Jan 2008 18:41:14 +0100 Subject: compilation architecture In-Reply-To: <645d17210801130934x680130c2y687c2b0b1e86c3af@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <6e24a8e80801130809m78a158bfx4ca9ecb2a3b7129@mail.gmail.com> <3adc77210801130847p237383dcg5fc3bbf45419c9e8@mail.gmail.com> <645d17210801130913r68d830bdk511ad3a0ac7e9187@mail.gmail.com> <645d17210801130934x680130c2y687c2b0b1e86c3af@mail.gmail.com> Message-ID: On Jan 13, 2008 6:34 PM, Jonathan Underwood wrote: > On 13/01/2008, drago01 wrote: > > This is about a patch that fixes this issue and the patch is already merged. > > I think you missread. The patch fixes the overhead of file read and > write. It does not address the 25 % overhead associated with file > open/close - look further down the thread. true this seems to only deal with the read/write issues. From mschwendt.tmp0701.nospam at arcor.de Sun Jan 13 18:05:56 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 13 Jan 2008 19:05:56 +0100 Subject: xmlto build errors In-Reply-To: References: Message-ID: <20080113190556.a41f63f1.mschwendt.tmp0701.nospam@arcor.de> On Sun, 13 Jan 2008 11:33:36 -0600, Xavier Toth wrote: > I googled for fixes to this problem but didn't see any. > > rpmbuild -bb ../SPECS/xmlto.spec Executing(%prep): /bin/sh -e > /var/tmp/rpm-tmp.59339 > + umask 022 > + cd /home/jcdxdev/src2/Linux_x86_64/BUILD/rpmbuild/BUILD > + LANG=C > + export LANG > + unset DISPLAY > + cd /home/jcdxdev/src2/Linux_x86_64/BUILD/rpmbuild/BUILD > + rm -rf xmlto-0.0.18 > + /usr/bin/bzip2 -dc > /home/jcdxdev/src2/Linux_x86_64/BUILD/rpmbuild/SOURCES/xmlto-0.0.18.tar.bz2 > + tar -xf - > + STATUS=0 > + '[' 0 -ne 0 ']' > + cd xmlto-0.0.18 > ++ /usr/bin/id -u > + '[' 500 = 0 ']' > ++ /usr/bin/id -u > + '[' 500 = 0 ']' > + /bin/chmod -Rf a+rX,u+w,g-w,o-w . > + echo 'Patch #0 (xmlto-basename.patch):' > Patch #0 (xmlto-basename.patch): > + patch -p1 -b --suffix .basename -s > + echo 'Patch #1 (xmlto-findwarning.patch):' > Patch #1 (xmlto-findwarning.patch): > + patch -p1 -b --suffix .findwarning -s > + exit 0 > Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.59339 > + umask 022 > + cd /home/jcdxdev/src2/Linux_x86_64/BUILD/rpmbuild/BUILD > + cd xmlto-0.0.18 > + LANG=C > + export LANG > + unset DISPLAY > + touch doc/xmlto.xml doc/xmlif.xml > + CFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' > + export CFLAGS > + CXXFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' > + export CXXFLAGS > + FFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' > + export FFLAGS > ++ find . -name config.guess -o -name config.sub > + ./configure --build=x86_64-redhat-linux-gnu > --host=x86_64-redhat-linux-gnu --target=x86_64-redhat-linux-gnu > --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin > --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share > --includedir=/usr/include --libdir=/usr/lib64 > --libexecdir=/usr/libexec --localstatedir=/var > --sharedstatedir=/usr/com --mandir=/usr/share/man > --infodir=/usr/share/info > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for x86_64-redhat-linux-gnu-gcc... no > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ANSI C... none needed > checking for style of include used by make... GNU > checking dependency style of gcc... gcc3 > checking whether gcc and cc understand -c and -o together... yes > checking for flex... flex > checking for yywrap in -lfl... yes > checking lex output file root... lex.yy > checking whether yytext is a pointer... yes > checking for mktemp program... mktemp > checking for GNU find program... find > checking for bash... bash > checking for getopt program... getopt > checking whether getopt handles long options... yes > configure: creating ./config.status > config.status: creating Makefile > config.status: creating xmlto > config.status: creating xmlto.spec > config.status: creating config.h > config.status: executing depfiles commands > + make > make all-am > make[1]: Entering directory > `/home/jcdxdev/src2/Linux_x86_64/BUILD/rpmbuild/BUILD/xmlto-0.0.18' > if gcc -DHAVE_CONFIG_H -I. -I. -I. -O2 -g -pipe -Wall > -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > --param=ssp-buffer-size=4 -m64 -mtune=generic -MT xmlif/xmlif.o -MD > -MP -MF "xmlif/.deps/xmlif.Tpo" -c -o xmlif/xmlif.o `test -f > 'xmlif/xmlif.c' || echo './'`xmlif/xmlif.c; \ > then mv -f "xmlif/.deps/xmlif.Tpo" "xmlif/.deps/xmlif.Po"; > else rm -f "xmlif/.deps/xmlif.Tpo"; exit 1; fi > xmlif/xmlif.l:33: warning: type defaults to 'int' in declaration of 'ifsense' > xmlif/xmlif.c: In function 'yylex': > xmlif/xmlif.l:215: warning: ignoring return value of 'fwrite', > declared with attribute warn_unused_result > xmlif/xmlif.l: At top level: > xmlif/xmlif.l:223: warning: return type defaults to 'int' > xmlif/xmlif.l: In function 'main': > xmlif/xmlif.l:249: warning: control reaches end of non-void function > xmlif/xmlif.l: At top level: > xmlif/xmlif.c:1844: warning: 'yyunput' defined but not used > gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -o > xmlif/xmlif xmlif/xmlif.o > for xml in xmlif.xml xmlto.xml; do \ > FORMAT_DIR=./format XSL_DIR=./xsl \ > bash ./xmlto -o man/man1 man ./doc/$xml ; \ > done || ( RC=$?; cat ./FAQ; exit $RC ) > I/O error : Attempt to load network entity > http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl > warning: failed to load external entity > "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl" > compilation error: file /tmp/xmlto-xsl.Xn2521 line 4 element import > xsl:import : unable to load > http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl > I/O error : Attempt to load network entity > http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl > warning: failed to load external entity > "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl" > compilation error: file /tmp/xmlto-xsl.KT2576 line 4 element import > xsl:import : unable to load > http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl > > Q: I'm trying to build xmlto on my Debian box, but it doesn't work. > > A: If you get `Attempt to load network entity' errors when building > xmlto, your system does not have the required support for XML > Catalogs > (http://www.oasis-open.org/committees/entity/spec-2001-08-06.html). > In particular, Debian has no support for these. Try the Fedora > Project . > make[1]: *** [man/man1/xmlto.1] Error 1 > make[1]: Leaving directory > `/home/jcdxdev/src2/Linux_x86_64/BUILD/rpmbuild/BUILD/xmlto-0.0.18' > make: *** [all] Error 2 > error: Bad exit status from /var/tmp/rpm-tmp.59339 (%build) > > > RPM build errors: > Bad exit status from /var/tmp/rpm-tmp.59339 (%build) > Does "BuildRequires: docbook-style-xsl" help already? Else you may need to patch it a bit as was necessary with e.g. "libsigc++". From jwilson at redhat.com Sun Jan 13 18:56:09 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Sun, 13 Jan 2008 13:56:09 -0500 Subject: Wanted: FireWire testers In-Reply-To: <1200236355.2355.2.camel@scrappy.miketc.com> References: <4787F211.3010402@redhat.com> <4787F580.2030405@gmail.com> <4788D521.9000701@redhat.com> <47897238.4000303@gmail.com> <4789C11B.2040804@gmail.com> <1200236355.2355.2.camel@scrappy.miketc.com> Message-ID: <478A5EC9.2040909@redhat.com> Mike Chambers wrote: > On Sat, 2008-01-12 at 23:43 -0800, Andrew Farris wrote: > >>>> Its built. >>>> >>>> http://koji.fedoraproject.org/packages/kernel/2.6.23.13/106.fc8/ >> I tried the koji kernel linked above and this boot panic problem I was having >> seems to be fixed with that new kernel. If anyone has had issues with firewire >> drives when booting kernels in F8 take a look at: > > I tried that kernel, it booted fine, but when it starting the x server, > going into gnome or whatever, it shows a weird jibberish display and > locks up hard, nothing works. You can boot to run level 3 and startx > locks it up. Hope this update isn't coming through testing/updates for > F8. Hrm... Nothing I added to that kernel should have any impact whatsoever on X... I believe 104.fc8 or 105.fc8 did go into updates-testing though. Would certainly be curious to hear if those *don't* cause the problem that 106.fc8 does, but I'd be quite surprised if the firewire update was the case. FWIW, 106.fc8 runs without a problem on all of my boxes I've installed it on thus far. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jakub.rusinek at gmail.com Sun Jan 13 19:12:24 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Sun, 13 Jan 2008 20:12:24 +0100 Subject: compilation architecture In-Reply-To: <6e24a8e80801130809m78a158bfx4ca9ecb2a3b7129@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <6e24a8e80801130809m78a158bfx4ca9ecb2a3b7129@mail.gmail.com> Message-ID: <5e92ee3f0801131112t65e4994aja0c7824d90e14614@mail.gmail.com> 2008/1/13, Mark : > > 2008/1/12, Jakub 'Livio' Rusinek : > > do we need to support legacy cpu's by i386 compilation? > > i586 would make fedora faster even 3 times. > > difference is noticeable. > > > > -- > > Jakub 'Livio' Rusinek > > http://liviopl.jogger.pl/ > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > You really are making a fool of yourself around here. > i can't imagine that the architecture has anything to do with performance. > but this [1] will most likely explain why openSuSE is so "much" faster > than fedora. > > Fedora used to use caching (preload) as well but it wasn't offering > speed improvements on default installs. more the opposite and that why > it's not in fedora anymore. Apparently opensuse has a > better/custom/other preloading system than fedora had (which was > readahead) and that's causing the speed improvements that you noticed. > > If you want to do a "fair" comparison of the speed than you must run > Firefox on fedora once first (than it gets cached) and than start > measuring the speed when you open it again. i bet it will be about > equal to opensuse. I did this test a while ago with readahead and if > the readahead files have the right paths than you will notice speed > improvements in all apps that are in the readahead list. > > Fedora currently has no (correct me if i'm wrong) preloading/readahead > thing started with a default install so (nearly) nothing gets pumped > into the memory to get speed improvements. They will get there once > they are started. > > So fedora isn't fast or slow. it's just working without caching > programs that improve your performance. > > Perhaps it's time for fedora to look how opensuse is doing this > preloading and investigate if that can be used in Fedora 9 (or Fedora > 10 if 9 is feature frozen). > > [1] http://en.opensuse.org/SUPER_standard_benchmark > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Listen. Firefox 3 is very fast. First run always is long (every distro), but second, third, fourth run are faster than the first - that's normal with Firefox, but in openSUSE Firefox 3 started in less than one second on my current hardware. On Fedora it was more than 1 second in > 1st run. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora at leemhuis.info Sun Jan 13 19:12:36 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 13 Jan 2008 20:12:36 +0100 Subject: EPEL report week 02/2008 Message-ID: <478A62A4.3090208@leemhuis.info> http://fedoraproject.org/wiki/EPEL/Reports/Week02 = Weekly EPEL Summary = Week 02/2008 == Most important happenings == * Mschwendt send a "broken deps report" to the list for [https://www.redhat.com/archives/epel-devel-list/2008-January/msg00055.html EPEL4] and [https://www.redhat.com/archives/epel-devel-list/2008-January/msg00054.html EPEL5] == Mailing list == === Noteworthy discussions === * [https://www.redhat.com/archives/epel-devel-list/2008-January/msg00052.html Bunch of EPEL packages needing new maintainers] == Meeting == === Next Meeting === Wednesday, 20080116 at 18:00 UTC in #fedora-meeting. === Last weeks meeting === There was no meeting scheduled. == Stats == === General === Number of EPEL Contributors: 165 We welcome 1 new contributors: twaugh === EPEL 5 === Number of source packages: 975 Number of binary packages: 1798 There are 12 new Packages: * cln | Class Library for Numbers * dbus-qt | Qt-based library for using D-BUS * emacs-nxml-mode | Emacs package for editing XML * freealut | Implementation of OpenAL's ALUT standard * ginac | C++ library for symbolic calculations * kmplayer | Video plugin for Konqueror and basic Gstreamer/Xine frontend * mod_wsgi | A WSGI interface for Python web applications in Apache * openal | Open Audio Library * rlwrap | Wrapper for GNU readline * t1lib | PostScript Type 1 font rasterizer * tiresias-fonts | Low vision fonts * xpdf | A PDF file viewer for the X Window System === EPEL 4 === Number of source packages: 583 Number of binary packages: 1106 There are 6 new Packages: * emacs-nxml-mode | Emacs package for editing XML * freealut | Implementation of OpenAL's ALUT standard * mod_wsgi | A WSGI interface for Python web applications in Apache * openal | Open Audio Library * rlwrap | Wrapper for GNU readline * tiresias-fonts | Low vision fonts ---- ["CategoryEPELReports"] From jakub.rusinek at gmail.com Sun Jan 13 19:13:00 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Sun, 13 Jan 2008 20:13:00 +0100 Subject: compilation architecture In-Reply-To: <645d17210801130913r68d830bdk511ad3a0ac7e9187@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <6e24a8e80801130809m78a158bfx4ca9ecb2a3b7129@mail.gmail.com> <3adc77210801130847p237383dcg5fc3bbf45419c9e8@mail.gmail.com> <645d17210801130913r68d830bdk511ad3a0ac7e9187@mail.gmail.com> Message-ID: <5e92ee3f0801131113n57d77a9n4eaf64c9715cc352@mail.gmail.com> 2008/1/13, Jonathan Underwood : > > On 13/01/2008, Naheem Zaffar wrote: > > I would expect different services to also cause some performance > > penalties. I doubt OpenSUSE uses SElinux for one. This is a selling > > point for Fedora. > > > > This thread makes for interesting reading on the overhead of SElinux: > > http://lkml.org/lkml/2007/9/6/14 > > Even with that patch, SElinux seems to incur a 25% overhead on simple > file open/close. Not sure if that's since been adressed, or if I am > misinterpretting the data given. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I have SELinux disabled because of many problems. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From caillon at redhat.com Sun Jan 13 19:24:46 2008 From: caillon at redhat.com (Christopher Aillon) Date: Sun, 13 Jan 2008 20:24:46 +0100 Subject: compilation architecture In-Reply-To: <5e92ee3f0801131112t65e4994aja0c7824d90e14614@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <6e24a8e80801130809m78a158bfx4ca9ecb2a3b7129@mail.gmail.com> <5e92ee3f0801131112t65e4994aja0c7824d90e14614@mail.gmail.com> Message-ID: <478A657E.4020500@redhat.com> On 01/13/2008 08:12 PM, Jakub 'Livio' Rusinek wrote: > Listen. Firefox 3 is very fast. First run always is long (every distro), but > second, third, fourth run are faster than the first - that's normal with > Firefox, but in openSUSE Firefox 3 started in less than one second on my > current hardware. On Fedora it was more than 1 second in > 1st run. ... but you aren't even using Fedora's firefox RPMs! [1] If you're going to complain, complain about things we're building and have control over! [1] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg01202.html From jakub.rusinek at gmail.com Sun Jan 13 19:35:33 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Sun, 13 Jan 2008 20:35:33 +0100 Subject: compilation architecture In-Reply-To: <478A657E.4020500@redhat.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <6e24a8e80801130809m78a158bfx4ca9ecb2a3b7129@mail.gmail.com> <5e92ee3f0801131112t65e4994aja0c7824d90e14614@mail.gmail.com> <478A657E.4020500@redhat.com> Message-ID: <5e92ee3f0801131135o23b1a6abx63027a19778f2622@mail.gmail.com> 2008/1/13, Christopher Aillon : > > On 01/13/2008 08:12 PM, Jakub 'Livio' Rusinek wrote: > > Listen. Firefox 3 is very fast. First run always is long (every distro), > but > > second, third, fourth run are faster than the first - that's normal with > > Firefox, but in openSUSE Firefox 3 started in less than one second on my > > current hardware. On Fedora it was more than 1 second in > 1st run. > > ... but you aren't even using Fedora's firefox RPMs! [1] If you're > going to complain, complain about things we're building and have control > over! > > [1] > > https://www.redhat.com/archives/fedora-devel-list/2008-January/msg01202.html > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I'll now use you RPMs, because I want to use trunk code, which you'll don't package every day. In rawhide/remi's repo is oldest version. Firefox 3 without your flags is fast. Not in Fedora of course. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From caillon at redhat.com Sun Jan 13 19:37:21 2008 From: caillon at redhat.com (Christopher Aillon) Date: Sun, 13 Jan 2008 20:37:21 +0100 Subject: compilation architecture In-Reply-To: <5e92ee3f0801131135o23b1a6abx63027a19778f2622@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <6e24a8e80801130809m78a158bfx4ca9ecb2a3b7129@mail.gmail.com> <5e92ee3f0801131112t65e4994aja0c7824d90e14614@mail.gmail.com> <478A657E.4020500@redhat.com> <5e92ee3f0801131135o23b1a6abx63027a19778f2622@mail.gmail.com> Message-ID: <478A6871.7070707@redhat.com> On 01/13/2008 08:35 PM, Jakub 'Livio' Rusinek wrote: > I'll now use you RPMs, because I want to use trunk code, which you'll don't > package every day. > In rawhide/remi's repo is oldest version. > > Firefox 3 without your flags is fast. Not in Fedora of course. Um, I didn't understand that... From abo at kth.se Sun Jan 13 20:08:18 2008 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Sun, 13 Jan 2008 21:08:18 +0100 Subject: compilation architecture In-Reply-To: <5e92ee3f0801131135o23b1a6abx63027a19778f2622@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <6e24a8e80801130809m78a158bfx4ca9ecb2a3b7129@mail.gmail.com> <5e92ee3f0801131112t65e4994aja0c7824d90e14614@mail.gmail.com> <478A657E.4020500@redhat.com> <5e92ee3f0801131135o23b1a6abx63027a19778f2622@mail.gmail.com> Message-ID: <1200254898.17118.268.camel@home.alexander.bostrom.net> s?n 2008-01-13 klockan 20:35 +0100 skrev Jakub 'Livio' Rusinek: > Firefox 3 without your flags is fast. Not in Fedora of course. Perhaps the issue here is all the language pack extensions that you might get in the Fedora Firefox. They might slow down startup compared to the relatively clean upstream binaries. (This is a known problem, btw, the question is if it's a big problem and what to do about it.) /abo From jakub.rusinek at gmail.com Sun Jan 13 20:29:24 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Sun, 13 Jan 2008 21:29:24 +0100 Subject: compilation architecture In-Reply-To: <1200254898.17118.268.camel@home.alexander.bostrom.net> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <6e24a8e80801130809m78a158bfx4ca9ecb2a3b7129@mail.gmail.com> <5e92ee3f0801131112t65e4994aja0c7824d90e14614@mail.gmail.com> <478A657E.4020500@redhat.com> <5e92ee3f0801131135o23b1a6abx63027a19778f2622@mail.gmail.com> <1200254898.17118.268.camel@home.alexander.bostrom.net> Message-ID: <5e92ee3f0801131229r2fc2a2eco2a213f5d0bff0c85@mail.gmail.com> 2008/1/13, Alexander Bostr?m : > > s?n 2008-01-13 klockan 20:35 +0100 skrev Jakub 'Livio' Rusinek: > > > Firefox 3 without your flags is fast. Not in Fedora of course. > > Perhaps the issue here is all the language pack extensions that you > might get in the Fedora Firefox. They might slow down startup compared > to the relatively clean upstream binaries. (This is a known problem, > btw, the question is if it's a big problem and what to do about it.) > > /abo > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I didn't mean the localization slows down Firefox, but when using Firefox 3 from repo I feel little slowing down compared to Firefox 3 snapshot from trunk. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakub.rusinek at gmail.com Sun Jan 13 20:30:37 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Sun, 13 Jan 2008 21:30:37 +0100 Subject: compilation architecture In-Reply-To: <478A6871.7070707@redhat.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <6e24a8e80801130809m78a158bfx4ca9ecb2a3b7129@mail.gmail.com> <5e92ee3f0801131112t65e4994aja0c7824d90e14614@mail.gmail.com> <478A657E.4020500@redhat.com> <5e92ee3f0801131135o23b1a6abx63027a19778f2622@mail.gmail.com> <478A6871.7070707@redhat.com> Message-ID: <5e92ee3f0801131230m2dcbceeaydd0d3ef1c9be21df@mail.gmail.com> 2008/1/13, Christopher Aillon : > > On 01/13/2008 08:35 PM, Jakub 'Livio' Rusinek wrote: > > I'll now use you RPMs, because I want to use trunk code, which you'll > don't > > package every day. > > In rawhide/remi's repo is oldest version. > > > > Firefox 3 without your flags is fast. Not in Fedora of course. > > > Um, I didn't understand that... > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Trunk snapshot in Mozilla's FTP is updated every day. Using it instead of older RPMs is better if I want to see current bugs and file them (I'm involved in Firefox 3). -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwmw2 at infradead.org Sun Jan 13 20:33:33 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 13 Jan 2008 20:33:33 +0000 Subject: Start/stop of OpenVPN interfaces with ifup/ifdown In-Reply-To: <200801112338.m0BNcflD031668@jasmine.xos.nl> References: <200801112338.m0BNcflD031668@jasmine.xos.nl> Message-ID: <1200256413.2647.53.camel@shinybook.infradead.org> On Sat, 2008-01-12 at 00:38 +0100, Jos Vos wrote: > - Is there a technical reason to not handle OpenVPN connections this > way in Fedora or is it just that it was decided to stay more close > to the generic OpenVPN startup script? > > - Does anyone know of recent work in this area? I guess the example > scripts in the thread I listed above might not work as-is with the > current Fedora and OpenVPN versions. > > - Is there any interest in including (and maintaining) this in Fedora's > OpenVPN package, maybe just as an alternative startup method, > assuming someone wants to contribute the initial implementation? Please do. I believe it should have been a condition of the initial review of the package. We're supposed to be making a coherent distribution, not just packaging up a bunch of software and chucking it together on a DVD. -- dwmw2 From mmcgrath at redhat.com Sun Jan 13 18:58:34 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 13 Jan 2008 12:58:34 -0600 (CST) Subject: Outage Notification - 2008-01-16 04:01 UTC (Major) Message-ID: There will be an outage starting at 2008-01-16 04:01 UTC, which will last approximately 48 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d 'YYYY-MM-DD HH:MM UTC' Affected Services: Websites CVS / Source Control Buildsystem Database Mail Fedora Hosted (Trac auth outages) Unaffected Services: Torrent Fedorapeople DNS Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/340 Reason for Outage: We have some new hardware to install. In order to do it we will need to juggle some current hardware around. This could potentially involve all of our servers. As time is tight we can't stagger these outages over a period of days and will have to do them all within a 48 hour period. Please contact me for specific questions. This will also cause some parts of our environment to act funny (for example, fedorahosted.org will be largely unaffected but people may not be able to authenticate to the web-trac instance for periods of time. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From lordmorgul at gmail.com Sun Jan 13 21:15:15 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sun, 13 Jan 2008 13:15:15 -0800 Subject: Wanted: FireWire testers In-Reply-To: <478A5EC9.2040909@redhat.com> References: <4787F211.3010402@redhat.com> <4787F580.2030405@gmail.com> <4788D521.9000701@redhat.com> <47897238.4000303@gmail.com> <4789C11B.2040804@gmail.com> <1200236355.2355.2.camel@scrappy.miketc.com> <478A5EC9.2040909@redhat.com> Message-ID: <478A7F63.5070400@gmail.com> Jarod Wilson wrote: > Mike Chambers wrote: >> On Sat, 2008-01-12 at 23:43 -0800, Andrew Farris wrote: >> >>>>> Its built. >>>>> >>>>> http://koji.fedoraproject.org/packages/kernel/2.6.23.13/106.fc8/ >>> I tried the koji kernel linked above and this boot panic problem I was having >>> seems to be fixed with that new kernel. If anyone has had issues with firewire >>> drives when booting kernels in F8 take a look at: >> I tried that kernel, it booted fine, but when it starting the x server, >> going into gnome or whatever, it shows a weird jibberish display and >> locks up hard, nothing works. You can boot to run level 3 and startx >> locks it up. Hope this update isn't coming through testing/updates for >> F8. > > Hrm... Nothing I added to that kernel should have any impact whatsoever on > X... I believe 104.fc8 or 105.fc8 did go into updates-testing though. Would > certainly be curious to hear if those *don't* cause the problem that 106.fc8 > does, but I'd be quite surprised if the firewire update was the case. > > FWIW, 106.fc8 runs without a problem on all of my boxes I've installed it on > thus far. I haven't seen 104 or 105 in updates-testing, and no kernel at all is in the repo today. I will see if 104 and 105 both fix my firewire drive issue though. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From lkundrak at redhat.com Sun Jan 13 21:18:58 2008 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Sun, 13 Jan 2008 22:18:58 +0100 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> Message-ID: <1200259138.8498.11.camel@localhost.localdomain> On Wed, 2008-01-09 at 09:20 +0100, Valent Turkovic wrote: > Hi, > I saw that Pulse Audio 0.9.8 got released two months ago: > http://pulseaudio.org/milestone/0.9.8 > and I see on my Fedora 8 that we still have 0.9.7 > > $ pulseaudio --version > pulseaudio 0.9.7 > > Will there be an upgrade soon on Fedora 8 to Pulse Audio 0.9.8? > > Lost of issues have been fixed in new Pulse Audio so users like me who > have issues with Pulse Audio would appreciate the much needed upgrade. Pulseaudio 0.9.8 will hit testing soon. Please test it and rate it accordingly -- I am not going to mark it stable by hand, so it relies on getting enough karma points. Also, I would be especially thankful if anyone with this [1] hardware could confirm if the problem (not necessarily caused by pulseaudio itself) appears also in F8. If yes, I consider it a good reason to hold the update indefinitely, until it gets resovled. [1] https://bugzilla.redhat.com/show_bug.cgi?id=428537 Thanks, -- Lubomir Kundrak (Red Hat Security Response Team) From caillon at redhat.com Sun Jan 13 21:32:29 2008 From: caillon at redhat.com (Christopher Aillon) Date: Sun, 13 Jan 2008 22:32:29 +0100 Subject: compilation architecture In-Reply-To: <5e92ee3f0801131230m2dcbceeaydd0d3ef1c9be21df@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <6e24a8e80801130809m78a158bfx4ca9ecb2a3b7129@mail.gmail.com> <5e92ee3f0801131112t65e4994aja0c7824d90e14614@mail.gmail.com> <478A657E.4020500@redhat.com> <5e92ee3f0801131135o23b1a6abx63027a19778f2622@mail.gmail.com> <478A6871.7070707@redhat.com> <5e92ee3f0801131230m2dcbceeaydd0d3ef1c9be21df@mail.gmail.com> Message-ID: <478A836D.3040209@redhat.com> On 01/13/2008 09:30 PM, Jakub 'Livio' Rusinek wrote: > Trunk snapshot in Mozilla's FTP is updated every day. Using it instead of > older RPMs is better if I want to see current bugs and file them (I'm > involved in Firefox 3). We're tracking Mozilla upstream pretty closely in Rawhide. While not daily, we aren't that far off... From markg85 at gmail.com Sun Jan 13 21:34:56 2008 From: markg85 at gmail.com (Mark) Date: Sun, 13 Jan 2008 22:34:56 +0100 Subject: compilation architecture In-Reply-To: <5e92ee3f0801131230m2dcbceeaydd0d3ef1c9be21df@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <6e24a8e80801130809m78a158bfx4ca9ecb2a3b7129@mail.gmail.com> <5e92ee3f0801131112t65e4994aja0c7824d90e14614@mail.gmail.com> <478A657E.4020500@redhat.com> <5e92ee3f0801131135o23b1a6abx63027a19778f2622@mail.gmail.com> <478A6871.7070707@redhat.com> <5e92ee3f0801131230m2dcbceeaydd0d3ef1c9be21df@mail.gmail.com> Message-ID: <6e24a8e80801131334l27982d4o61a02d2fc571dca@mail.gmail.com> 2008/1/13, Jakub 'Livio' Rusinek : > 2008/1/13, Christopher Aillon : > > > On 01/13/2008 08:35 PM, Jakub 'Livio' Rusinek wrote: > > > I'll now use you RPMs, because I want to use trunk code, which you'll > don't > > > package every day. > > > In rawhide/remi's repo is oldest version. > > > > > > Firefox 3 without your flags is fast. Not in Fedora of course. > > > > > > Um, I didn't understand that... > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > Trunk snapshot in Mozilla's FTP is updated every day. Using it instead of > older RPMs is better if I want to see current bugs and file them (I'm > involved in Firefox 3). i can hardly believe that you are part of the FF3 development. O well... want to talk about speed? look at this: [mark at localhost ~]$ time firefox real 0m0.151s user 0m0.021s sys 0m0.029s [mark at localhost ~]$ Yes! that's well below one second (firefox 2.0.0.10)! and nothing is specially tuned! i even have one additional plugin installed (tamper data)! and my hardware isn't that fancy. it's just a $600 notebook. Perhaps you need to reinstall your Fedora? But you made me curious about how well FF3 will run on Fedora 8 so i will try to install that one and see shat the timings are than. From abo at kth.se Sun Jan 13 23:01:39 2008 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Mon, 14 Jan 2008 00:01:39 +0100 Subject: compilation architecture In-Reply-To: <5e92ee3f0801131229r2fc2a2eco2a213f5d0bff0c85@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <6e24a8e80801130809m78a158bfx4ca9ecb2a3b7129@mail.gmail.com> <5e92ee3f0801131112t65e4994aja0c7824d90e14614@mail.gmail.com> <478A657E.4020500@redhat.com> <5e92ee3f0801131135o23b1a6abx63027a19778f2622@mail.gmail.com> <1200254898.17118.268.camel@home.alexander.bostrom.net> <5e92ee3f0801131229r2fc2a2eco2a213f5d0bff0c85@mail.gmail.com> Message-ID: <1200265300.19314.4.camel@home.alexander.bostrom.net> s?n 2008-01-13 klockan 21:29 +0100 skrev Jakub 'Livio' Rusinek: > I didn't mean the localization slows down Firefox, but when using > Firefox 3 from repo I feel little slowing down compared to Firefox 3 > snapshot from trunk. Yes, and if you list the number of extensions in one versus the other...? /abo From triad at df.lth.se Mon Jan 14 00:14:01 2008 From: triad at df.lth.se (Linus Walleij) Date: Mon, 14 Jan 2008 01:14:01 +0100 (CET) Subject: Preloading [WAS: Re: SuSE Project SUPER] In-Reply-To: References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47893D75.1000406@redhat.com> <5e92ee3f0801121432qcf7287cx2982deafafe0674c@mail.gmail.com> Message-ID: On Sun, 13 Jan 2008, Linus Walleij wrote: > * They use a LOT of preloading, I have now looked a bit closer at this, and it is *indeed* looking like a major user-perceiveable thing, they preload pretty much everything and also add other hints to the kernel of what may be expected to be used soonish during boot, early-{x|g|k}dm and so forth. It is rather crude: the actual mechanisms used are: preload, source can be found here: http://download.opensuse.org/distribution/10.3/repo/src-oss/suse/src/preload-0.2-110.src.rpm anyone knows wher SuSE keep their CVS/SVN/git of this? Preload then uses readahead(2) or fadvice(2) to do the actual preloading. Then preload is triggered from /etc/init.d scripts prepended with ionice(1) like this: /usr/bin/ionice -n2 /sbin/preload /etc/preload.d/gdm Then as can be seen there are some app profiles in /etc/preload.d that configure depending on used desktop what to preload, e.g. gdm/kdm, Khelpcenter, OpenOffice, Firefox, Gimp (why?), etc. All code and scripts are heavily SuSEified. But has this really been under our radar for all this time? The entire concept is like 2-3 years old, surely it must have been discussed before? (Not that I heard it though...) I don't have much time in my life but unless someone else starts looking at this I will se if it can be Fedorified, target for F10 or so. And thanks to Jakub for the hints given that allowed me to find this cool thing... Linus From naheemzaffar at gmail.com Mon Jan 14 00:34:32 2008 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Mon, 14 Jan 2008 00:34:32 +0000 Subject: Preloading [WAS: Re: SuSE Project SUPER] In-Reply-To: References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47893D75.1000406@redhat.com> <5e92ee3f0801121432qcf7287cx2982deafafe0674c@mail.gmail.com> Message-ID: <3adc77210801131634q41296a6br5fd5c3f444f98588@mail.gmail.com> I think Fedora did use some sort of preloading (well, atleast Readahead), but it was decided that there was no tangible benefit from it in the way it was being done. From lordmorgul at gmail.com Mon Jan 14 01:25:30 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sun, 13 Jan 2008 17:25:30 -0800 Subject: Preloading [WAS: Re: SuSE Project SUPER] In-Reply-To: References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47893D75.1000406@redhat.com> <5e92ee3f0801121432qcf7287cx2982deafafe0674c@mail.gmail.com> Message-ID: <478ABA0A.4090900@gmail.com> Linus Walleij wrote: > Preload then uses readahead(2) or fadvice(2) to do the actual preloading. > > Then preload is triggered from /etc/init.d scripts prepended with > ionice(1) like this: > > /usr/bin/ionice -n2 /sbin/preload /etc/preload.d/gdm > > Then as can be seen there are some app profiles in /etc/preload.d that > configure depending on used desktop what to preload, e.g. gdm/kdm, > Khelpcenter, OpenOffice, Firefox, Gimp (why?), etc. Incidentally, I think one of the main reasons the idea hasn't had much discussion is that question of what applications are so crucial to preload like this (gimp? laughable). Also, once an application is open its shared libraries are cached for later, so for machines that stay on all day this has almost no real benefit. > All code and scripts are heavily SuSEified. > > But has this really been under our radar for all this time? The entire > concept is like 2-3 years old, surely it must have been discussed > before? (Not that I heard it though...) I've seen discussion of this concept at least, maybe not that particular implementation strategy. The idea should provide some better performance from the user perspective... but the fact is the real wall time of getting your machine cold booted, logged in, and an application fired up and usable should not be much different overall. The real differences would be seen if you are not sitting at the machine logging in asap for instance (the machine has nothing to do until you log in, whereas with that preloading it might start loading up firefox for you). If you put this in the distro, you need good high-level configuration tools so the user can choose what to preload or not, so you're not slowing the machine unnecessarily, or packing all the free memory with libraries the user doesn't intend to use that day/boot/login just to later unload it. I wouldn't even want something learning my most used applications, just something to configure what will get loaded and what won't. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From dmc.fedora at filteredperception.org Mon Jan 14 02:06:16 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 13 Jan 2008 20:06:16 -0600 Subject: Preloading [WAS: Re: SuSE Project SUPER] In-Reply-To: References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47893D75.1000406@redhat.com> <5e92ee3f0801121432qcf7287cx2982deafafe0674c@mail.gmail.com> Message-ID: <478AC398.6030100@filteredperception.org> Linus Walleij wrote: > On Sun, 13 Jan 2008, Linus Walleij wrote: > >> * They use a LOT of preloading, > > I have now looked a bit closer at this, and it is *indeed* looking like > a major user-perceiveable thing, they preload pretty much everything and > also add other hints to the kernel of what may be expected to be used > soonish during boot, early-{x|g|k}dm and so forth. > > It is rather crude: the actual mechanisms used are: ... FYI, I recently outlined a (livecd) preloading implementation completely unrelated to all of this, which I'd bet money will speed up livecd boot by at least 10% (perhaps much more). My method involves a devicemapper trick, the primary benefit of which is removing seeks. Theoretically this could help disk (non-cdrom) based boots, but would require ext3 features for sorting that I don't think currently exist, and the benefit would probably be <<5% anyway. Still, something to look forward to. Now that my no-root-privs livecd generator tool is looking pretty swank along with liveusb persistence, I think I'm nearly ready to write the relatively few lines of bash code required to implement "super device-mapper caching" (just plain d.m.c. was already taken for something different that might help the disk boot case as well) http://www.redhat.com/archives/fedora-livecd-list/2008-January/msg00036.html -dmc From sandeen at redhat.com Mon Jan 14 02:47:24 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Sun, 13 Jan 2008 20:47:24 -0600 Subject: Preloading [WAS: Re: SuSE Project SUPER] In-Reply-To: <3adc77210801131634q41296a6br5fd5c3f444f98588@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47893D75.1000406@redhat.com> <5e92ee3f0801121432qcf7287cx2982deafafe0674c@mail.gmail.com> <3adc77210801131634q41296a6br5fd5c3f444f98588@mail.gmail.com> Message-ID: <478ACD3C.6070106@redhat.com> Naheem Zaffar wrote: > I think Fedora did use some sort of preloading (well, atleast > Readahead), but it was decided that there was no tangible benefit from > it in the way it was being done. > Well, I looked into the readahead util for boot time, and it seemed to hurt more than help. But ongoing preload that learns & adjusts to usage patterns could help I'm sure, if done right -Eric (while waiting for the one long boot of OS X 10.5 after a system update, as it updates its caches for the *next* fast boot...) From mrmazda at ij.net Mon Jan 14 06:16:54 2008 From: mrmazda at ij.net (Felix Miata) Date: Mon, 14 Jan 2008 01:16:54 -0500 Subject: Impending X driver deprecation In-Reply-To: References: <1199906969.15130.40.camel@localhost.localdomain> <478592B4.8080109@ij.net> Message-ID: <478AFE56.8060609@ij.net> On 2008/01/10 11:15 (GMT+0100) Matej Cepl apparently typed: > On 2008-01-10, 03:36 GMT, Felix Miata wrote: >> So as to Tseng, I object X8. > And why wouldn't your machines work with vesa? Tseng driver when not broken (it's fully functional in SUSE, broken in Fedora) supports 1400x1050x16bpp and 1280x960x16bpp on 4MB cards. The best the VESA driver can do for standard 4/3 displays with these cards is 1152x864x16bpp. Native resolution on my LCD display is 1400x1050. All my other displays are CRT, where 1280x1024 is unacceptable though the only ostensibly better option than 1152x864 at 16bpp or better. -- "In the beginning was the Word, and the Word was with God, and the Word was God." John 1:1 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/ From mrmazda at ij.net Mon Jan 14 06:22:58 2008 From: mrmazda at ij.net (Felix Miata) Date: Mon, 14 Jan 2008 01:22:58 -0500 Subject: Impending X driver deprecation In-Reply-To: <1199998544.15130.219.camel@localhost.localdomain> References: <1199906969.15130.40.camel@localhost.localdomain> <478592B4.8080109@ij.net> <1c252d490801101217v4ef993dcnae880fb2cfc834e7@mail.gmail.com> <1199998544.15130.219.camel@localhost.localdomain> Message-ID: <478AFFC2.50102@ij.net> On 2008/01/10 21:55 (GMT+0100) Adam Jackson apparently typed: > On Thu, 2008-01-10 at 21:17 +0100, Joachim Frieben wrote: >> It's not necessarily a matter of work or not, but vesa usually >> provides abysmal 2D performance compared to a native driver. > The chips mentioned have abysmal performance to begin with. The Tseng ET6x00 chips with native driver have far better than abysmal performance, better than all the others that I ever tried in the list at start of thread. That's why I have so many of them. They were the best performing low cost cards of their day, and in the much faster systems of today, are perfectly fine for mundane 2D desktop workstation use. > Since it seems just about every one of the drivers I threatened had > someone speak up for them, I'll make the effort to port them as well, > but they'll likely be at the end of the list. -- "In the beginning was the Word, and the Word was with God, and the Word was God." John 1:1 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/ From lordmorgul at gmail.com Mon Jan 14 06:41:32 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sun, 13 Jan 2008 22:41:32 -0800 Subject: Impending X driver deprecation In-Reply-To: <47862243.50003@redhat.com> References: <1199906969.15130.40.camel@localhost.localdomain> <47862243.50003@redhat.com> Message-ID: <478B041C.6010207@gmail.com> Christopher Aillon wrote: > Can we call it Operation: Impeding Doom? By the looks of the comments a name like 'Operation: Delayed Doom' sounds more approriate. ;) So much for cleaning up the huge number of older drivers being maintained. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From jspaleta at gmail.com Mon Jan 14 06:44:05 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 13 Jan 2008 21:44:05 -0900 Subject: Preloading [WAS: Re: SuSE Project SUPER] In-Reply-To: <478ACD3C.6070106@redhat.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47893D75.1000406@redhat.com> <5e92ee3f0801121432qcf7287cx2982deafafe0674c@mail.gmail.com> <3adc77210801131634q41296a6br5fd5c3f444f98588@mail.gmail.com> <478ACD3C.6070106@redhat.com> Message-ID: <604aa7910801132244t15fbfdecg52c39f12b402406@mail.gmail.com> On Jan 13, 2008 5:47 PM, Eric Sandeen wrote: > Well, I looked into the readahead util for boot time, and it seemed to > hurt more than help. But ongoing preload that learns & adjusts to usage > patterns could help I'm sure, if done right That wont help the critical first impression phase.. before application usage patterns are established and people are feeling out the release. And to be more blunt about it.. it won't help first impression from the reviewers who run a distro just long enough to figure what they like and don't like about it and want to get their review in within the first week of a release. How many people end up relying on the first impression of others to form their own impressions? Adaptive methods that only help boot speeds after multiple reboots with extended usage pattern trending isn't really going to impact the impression people have one damn bit. And it wont help livecds where state information is lost between reboots. -jef From lordmorgul at gmail.com Mon Jan 14 07:05:32 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sun, 13 Jan 2008 23:05:32 -0800 Subject: Preloading [WAS: Re: SuSE Project SUPER] In-Reply-To: <604aa7910801132244t15fbfdecg52c39f12b402406@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47893D75.1000406@redhat.com> <5e92ee3f0801121432qcf7287cx2982deafafe0674c@mail.gmail.com> <3adc77210801131634q41296a6br5fd5c3f444f98588@mail.gmail.com> <478ACD3C.6070106@redhat.com> <604aa7910801132244t15fbfdecg52c39f12b402406@mail.gmail.com> Message-ID: <478B09BC.5080204@gmail.com> Jeff Spaleta wrote: > On Jan 13, 2008 5:47 PM, Eric Sandeen wrote: >> Well, I looked into the readahead util for boot time, and it seemed to >> hurt more than help. But ongoing preload that learns & adjusts to usage >> patterns could help I'm sure, if done right > > That wont help the critical first impression phase.. before > application usage patterns are established and people are feeling out > the release. And to be more blunt about it.. it won't help first > impression from the reviewers who run a distro just long enough to > figure what they like and don't like about it and want to get their > review in within the first week of a release. > How many people end up relying on the first impression of others to > form their own impressions? Adaptive methods that only help boot > speeds after multiple reboots with extended usage pattern trending > isn't really going to impact the impression people have one damn bit. Uhm, yeah you're right. But it will help those who actually use the distribution rather than toss it aside based off bad information they got from someone else. There is certainly time and place to consider user first impressions, but I hardly think its a good idea to filter an idea like the above by ONLY that consideration. > And it wont help livecds where state information is lost between reboots. > > -jef > -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From seg at haxxed.com Mon Jan 14 07:39:06 2008 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 14 Jan 2008 01:39:06 -0600 Subject: Preloading [WAS: Re: SuSE Project SUPER] In-Reply-To: <604aa7910801132244t15fbfdecg52c39f12b402406@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47893D75.1000406@redhat.com> <5e92ee3f0801121432qcf7287cx2982deafafe0674c@mail.gmail.com> <3adc77210801131634q41296a6br5fd5c3f444f98588@mail.gmail.com> <478ACD3C.6070106@redhat.com> <604aa7910801132244t15fbfdecg52c39f12b402406@mail.gmail.com> Message-ID: <1200296346.5433.10.camel@localhost> The whole idea of preloading is crackrock. Its just hiding the problem, at best. The problem is the relentless march of bloat. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From valent.turkovic at gmail.com Mon Jan 14 08:43:45 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Mon, 14 Jan 2008 09:43:45 +0100 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <1200259138.8498.11.camel@localhost.localdomain> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <1200259138.8498.11.camel@localhost.localdomain> Message-ID: <64b14b300801140043j4c5966cai95faf7ce430c1e9@mail.gmail.com> On 1/13/08, Lubomir Kundrak wrote: > > On Wed, 2008-01-09 at 09:20 +0100, Valent Turkovic wrote: > > Hi, > > I saw that Pulse Audio 0.9.8 got released two months ago: > > http://pulseaudio.org/milestone/0.9.8 > > and I see on my Fedora 8 that we still have 0.9.7 > > > > $ pulseaudio --version > > pulseaudio 0.9.7 > > > > Will there be an upgrade soon on Fedora 8 to Pulse Audio 0.9.8? > > > > Lost of issues have been fixed in new Pulse Audio so users like me who > > have issues with Pulse Audio would appreciate the much needed upgrade. > > Pulseaudio 0.9.8 will hit testing soon. Please test it and rate it > accordingly -- I am not going to mark it stable by hand, so it relies on > getting enough karma points. > > Also, I would be especially thankful if anyone with this [1] hardware > could confirm if the problem (not necessarily caused by pulseaudio > itself) appears also in F8. If yes, I consider it a good reason to hold > the update indefinitely, until it gets resovled. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=428537 > > Thanks, > -- > Lubomir Kundrak (Red Hat Security Response Team) Have you contacted pulseaudio mailing list? My bug [1] got some attention in bugzilla, and I "wasted" quite some time chasing all suggestions that I was given there and none was of any use to my specific bug, it was a good thing that it helped some other people with similar bugs. Then I posted a pulseaudio bug on their bug tracker - zero response there. A week lates (still no reply on their bug tracker) I posted my issue to mailing list, and I emediately got a really helpful sugestion and that fixed my issue with PulseAudio under Fedora 8! So I encourage you save your time and go directly to PA mailing list. Valent. [1] https://bugzilla.redhat.com/show_bug.cgi?id=366001 -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From triad at df.lth.se Mon Jan 14 09:03:12 2008 From: triad at df.lth.se (Linus Walleij) Date: Mon, 14 Jan 2008 10:03:12 +0100 (CET) Subject: Preloading [WAS: Re: SuSE Project SUPER] In-Reply-To: <604aa7910801132244t15fbfdecg52c39f12b402406@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47893D75.1000406@redhat.com> <5e92ee3f0801121432qcf7287cx2982deafafe0674c@mail.gmail.com> <3adc77210801131634q41296a6br5fd5c3f444f98588@mail.gmail.com> <478ACD3C.6070106@redhat.com> <604aa7910801132244t15fbfdecg52c39f12b402406@mail.gmail.com> Message-ID: On Sun, 13 Jan 2008, Jeff Spaleta wrote: > That wont help the critical first impression phase.. Agreed, what "other" OS:es (Vista, MacOS X) do is to come pre-installed, i.e. it was booted once by a technician out of sight of the user. Then they leverage on that. They are of course doing much more agressive things than simple preloading, more like suspend-to-disk, so the user actually more or less resumes a pre-booted image customized for that machine at "boot" time. I wonder if we could do that. Linus From ovasik at redhat.com Mon Jan 14 09:25:34 2008 From: ovasik at redhat.com (=?UTF-8?Q?Ond=C5=99ej_Va=C5=A1=C3=ADk?=) Date: Mon, 14 Jan 2008 10:25:34 +0100 Subject: xmlto build errors In-Reply-To: References: Message-ID: <1200302734.3924.6.camel@dhcp-lab-219.englab.brq.redhat.com> Hi, Sorry for that, that's caused by buggy %postun of one docbook-style-xsl package. That postun is already fixed in latest stable F8 and F7 packages , but still will cause troubles by deregistering catalogs (registered by post of current correct package). Following workarounds are available: 1) yum erase docbook-style-xsl and yum install docbook-style-xsl 2) force update with latest docbook-style-xsl package on F7/F8 once more time Problem could be fixed by doubled update or by pushing new version of docbook-style-xsl (which should be available at the end of Jan) Once more time sorry for troubles, Greetings, Ondrej Vasik docbook-style-xsl and xmlto Fedora maintainer Xavier Toth wrote Sun 13th Jan 2008 : > I googled for fixes to this problem but didn't see any. > I/O error : Attempt to load network entity > http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl > warning: failed to load external entity > "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl" > compilation error: file /tmp/xmlto-xsl.Xn2521 line 4 element import > xsl:import : unable to load > http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl > I/O error : Attempt to load network entity > http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl > warning: failed to load external entity > "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl" > compilation error: file /tmp/xmlto-xsl.KT2576 line 4 element import > xsl:import : unable to load > http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl > > Q: I'm trying to build xmlto on my Debian box, but it doesn't work. > > A: If you get `Attempt to load network entity' errors when building > xmlto, your system does not have the required support for XML > Catalogs > (http://www.oasis-open.org/committees/entity/spec-2001-08-06.html). > In particular, Debian has no support for these. Try the Fedora > Project . > make[1]: *** [man/man1/xmlto.1] Error 1 > make[1]: Leaving directory > `/home/jcdxdev/src2/Linux_x86_64/BUILD/rpmbuild/BUILD/xmlto-0.0.18' > make: *** [all] Error 2 > error: Bad exit status from /var/tmp/rpm-tmp.59339 (%build) > > > RPM build errors: > Bad exit status from /var/tmp/rpm-tmp.59339 (%build) > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Toto je digit?ln? podepsan? ??st zpr?vy URL: From drago01 at gmail.com Mon Jan 14 10:16:39 2008 From: drago01 at gmail.com (drago01) Date: Mon, 14 Jan 2008 11:16:39 +0100 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <1200259138.8498.11.camel@localhost.localdomain> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <1200259138.8498.11.camel@localhost.localdomain> Message-ID: <478B3687.6020105@gmail.com> Lubomir Kundrak wrote: > On Wed, 2008-01-09 at 09:20 +0100, Valent Turkovic wrote: > >> Hi, >> I saw that Pulse Audio 0.9.8 got released two months ago: >> http://pulseaudio.org/milestone/0.9.8 >> and I see on my Fedora 8 that we still have 0.9.7 >> >> $ pulseaudio --version >> pulseaudio 0.9.7 >> >> Will there be an upgrade soon on Fedora 8 to Pulse Audio 0.9.8? >> >> Lost of issues have been fixed in new Pulse Audio so users like me who >> have issues with Pulse Audio would appreciate the much needed upgrade. >> > > Pulseaudio 0.9.8 will hit testing soon. Please test it and rate it > accordingly -- I am not going to mark it stable by hand, so it relies on > getting enough karma points. > > I grabed pulseaudio-0.9.8-4.fc8.1 from koji and the results are: https://bugzilla.redhat.com/show_bug.cgi?id=321611 seems to be fixed for me. It now detects my tv card as input source (0.9.7 did not). Process name is now pulseaudio instead of exe. I wanted to test the avahi autodetect feature but could not because paprefs is still at 0.9.6 (even in rawhide) and this version does not provide this option. I have not noticed any regressions. From drago01 at gmail.com Mon Jan 14 10:24:26 2008 From: drago01 at gmail.com (drago01) Date: Mon, 14 Jan 2008 11:24:26 +0100 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <1200259138.8498.11.camel@localhost.localdomain> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <1200259138.8498.11.camel@localhost.localdomain> Message-ID: <478B385A.6070001@gmail.com> Let me correct myself the 0.9.6 version in rawhide provides it but the svn snaphost shipped in f8 does not please consider updating this too. From mschwendt.tmp0701.nospam at arcor.de Mon Jan 14 11:09:51 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 14 Jan 2008 12:09:51 +0100 Subject: rpms/sepostgresql/devel postgresql-8.2.6.tar.gz, NONE, 1.1 .cvsignore, 1.4, 1.5 sepostgresql.init, 1.8, 1.9 sepostgresql.spec, 1.8, 1.9 sepostgresql.te, 1.8, 1.9 In-Reply-To: <1199983507.3398.14.camel@localhost.localdomain> References: <200801101437.m0AEbemG002515@cvs-int.fedora.redhat.com> <1199983507.3398.14.camel@localhost.localdomain> Message-ID: <20080114120951.4c9df209.mschwendt.tmp0701.nospam@arcor.de> On Thu, 10 Jan 2008 08:45:07 -0800, Devrim G?ND?Z wrote: > Hi, > > On Thu, 2008-01-10 at 09:37 -0500, KaiGai Kohei wrote: > > Added Files: > > postgresql-8.2.6.tar.gz > > Log Message: > > add postgresql-8.2.6.tar.gz > > Why do you keep the tarball in CVS??? > > Regards, That is highly annoying. I just run into it. How can I find out who kaigai's sponsor is? The FAS does not show that information. Please fix sepostgresql in cvs ASAP. Upload large binary files to the lookaside cache as everyone else. From lkundrak at redhat.com Mon Jan 14 11:27:17 2008 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Mon, 14 Jan 2008 12:27:17 +0100 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <478B3687.6020105@gmail.com> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <1200259138.8498.11.camel@localhost.localdomain> <478B3687.6020105@gmail.com> Message-ID: <1200310037.8498.22.camel@localhost.localdomain> On Mon, 2008-01-14 at 11:16 +0100, drago01 wrote: > Lubomir Kundrak wrote: > > On Wed, 2008-01-09 at 09:20 +0100, Valent Turkovic wrote: > > > >> Hi, > >> I saw that Pulse Audio 0.9.8 got released two months ago: > >> http://pulseaudio.org/milestone/0.9.8 > >> and I see on my Fedora 8 that we still have 0.9.7 > >> > >> $ pulseaudio --version > >> pulseaudio 0.9.7 > >> > >> Will there be an upgrade soon on Fedora 8 to Pulse Audio 0.9.8? > >> > >> Lost of issues have been fixed in new Pulse Audio so users like me who > >> have issues with Pulse Audio would appreciate the much needed upgrade. > >> > > > > Pulseaudio 0.9.8 will hit testing soon. Please test it and rate it > > accordingly -- I am not going to mark it stable by hand, so it relies on > > getting enough karma points. > > > > > I grabed pulseaudio-0.9.8-4.fc8.1 from koji and the results are: > https://bugzilla.redhat.com/show_bug.cgi?id=321611 seems to be fixed for me. > It now detects my tv card as input source (0.9.7 did not). > Process name is now pulseaudio instead of exe. > I wanted to test the avahi autodetect feature but could not because > paprefs is still at 0.9.6 (even in rawhide) and this version does not > provide this option. > I have not noticed any regressions. Thanks a lot. Lennart; Would it make sense to update also paman paprefs pavucontrol and pavumeter (have I missed some?) to corresponding versions? (padevchooser seems to be post-last-release snapshot). -- Lubomir Kundrak (Red Hat Security Response Team) From lordmorgul at gmail.com Mon Jan 14 11:54:41 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Mon, 14 Jan 2008 03:54:41 -0800 Subject: Pulse Audio 0.9.8 - upgrade? In-Reply-To: <478B3687.6020105@gmail.com> References: <64b14b300801090020n14b9d565l59ded684c0a022c3@mail.gmail.com> <1200259138.8498.11.camel@localhost.localdomain> <478B3687.6020105@gmail.com> Message-ID: <478B4D81.2090705@gmail.com> drago01 wrote: > Lubomir Kundrak wrote: >> On Wed, 2008-01-09 at 09:20 +0100, Valent Turkovic wrote: >> >>> Hi, >>> I saw that Pulse Audio 0.9.8 got released two months ago: >>> http://pulseaudio.org/milestone/0.9.8 >>> and I see on my Fedora 8 that we still have 0.9.7 >>> >>> $ pulseaudio --version >>> pulseaudio 0.9.7 >>> >>> Will there be an upgrade soon on Fedora 8 to Pulse Audio 0.9.8? >>> >>> Lost of issues have been fixed in new Pulse Audio so users like me who >>> have issues with Pulse Audio would appreciate the much needed upgrade. >>> >> >> Pulseaudio 0.9.8 will hit testing soon. Please test it and rate it >> accordingly -- I am not going to mark it stable by hand, so it relies on >> getting enough karma points. >> >> > I grabed pulseaudio-0.9.8-4.fc8.1 from koji and the results are: > https://bugzilla.redhat.com/show_bug.cgi?id=321611 seems to be fixed for > me. > It now detects my tv card as input source (0.9.7 did not). > Process name is now pulseaudio instead of exe. > I wanted to test the avahi autodetect feature but could not because > paprefs is still at 0.9.6 (even in rawhide) and this version does not > provide this option. > I have not noticed any regressions. I did the same update from koji on F8 and having no problems, although I had no problems with 0.9.7 except that padevchooser does not save the default device for new streams and this did not change. I have both SB Audigy (snd-emu10k1) and Intel 82801BA/BAM AC97 (snd-intel8x0), still working the same with 0.9.8 as 0.9.7. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From vonbrand at inf.utfsm.cl Mon Jan 14 12:43:29 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Mon, 14 Jan 2008 09:43:29 -0300 Subject: xargs generates too long argument lists on i686 Message-ID: <200801141243.m0EChTgO016238@laptop13.inf.utfsm.cl> For some time now, each time I try to build an RPM it fails with something like: + /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot xargs: /usr/lib/rpm/check-rpaths-worker: Argument list too long error: Bad exit status from /var/tmp/rpm-tmp.39544 (%install) This I have traced back to xargs(1) generating huge argument lists, which the called command can't handle. Doing a "make clean" in a self-built kernel gives the same type of grief (I tweaked the Makefile there to call xargs with "-L 2000" to get it to work). I wonder how everybody else here is able to get anything done... findutils-4.2.31-2.fc8 on rawhide, fully up to date. Reported as BZ 275321 -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From magnus.gustavsson at liu.se Mon Jan 14 12:46:50 2008 From: magnus.gustavsson at liu.se (Magnus Gustavsson) Date: Mon, 14 Jan 2008 12:46:50 +0000 (UTC) Subject: Bruttaly sluggish Eclipse performance in remote X References: <1199746646.9735.10.camel@dimi.lattica.com> <47862752.3030103@gmail.com> <47866A6F.9000800@gmail.com> Message-ID: Les Mikesell gmail.com> writes: > Magnus Gustavsson wrote: > > Les Mikesell gmail.com> writes: > > > >> Have you tried running freenx with the NX clients from > >> http://www.nomachine.com? > > > > I have now. No improvement. > > I'm somewhat shocked at this, since it should provide a caching layer > for things moved on the screen in addition to compression and a proxy to > fix network latency. Are you sure you aren't short on RAM? I'm sorry. A better assessment might have been "Not enough improvement". I've measured the network traffic now, and it's been lowered to about a third compared to standard X-forwarding. Still, it's five times higher than RHEL4/Sarge with X-forwarding, and still too slow to be acceptable. I guess it's time for me to open a case with Sun and/or look for alternatives to Sun Ray. Thanks for the tip though. /Magnus From nphilipp at redhat.com Mon Jan 14 13:27:01 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 14 Jan 2008 14:27:01 +0100 Subject: rawhide report: 20080111 changes In-Reply-To: <200801111755.m0BHt2wY002105@porkchop.devel.redhat.com> References: <200801111755.m0BHt2wY002105@porkchop.devel.redhat.com> Message-ID: <1200317221.24328.10.camel@gibraltar.str.redhat.com> On Fri, 2008-01-11 at 12:55 -0500, Build System wrote: > New package diveintopython > Dive into Python - a python book Have we relaxed our "code vs. content" policy lately? While I'm not personally against having this package in, I don't think it falls under the "Package documentation or help files" exception in Packaging/Guidelines, or does it? Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From sundaram at fedoraproject.org Mon Jan 14 13:52:56 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 14 Jan 2008 19:22:56 +0530 Subject: rawhide report: 20080111 changes In-Reply-To: <1200317221.24328.10.camel@gibraltar.str.redhat.com> References: <200801111755.m0BHt2wY002105@porkchop.devel.redhat.com> <1200317221.24328.10.camel@gibraltar.str.redhat.com> Message-ID: <478B6938.5060008@fedoraproject.org> Nils Philippsen wrote: > On Fri, 2008-01-11 at 12:55 -0500, Build System wrote: >> New package diveintopython >> Dive into Python - a python book > > Have we relaxed our "code vs. content" policy lately? While I'm not > personally against having this package in, I don't think it falls under > the "Package documentation or help files" exception in > Packaging/Guidelines, or does it? There was a small discussion about this in this list and the general consensus seemed to be that such documentation is allowed. Rahul From rc040203 at freenet.de Mon Jan 14 09:14:53 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 14 Jan 2008 10:14:53 +0100 Subject: rpms/liberation-fonts/devel liberation-fonts.tar.gz,NONE,1.1 In-Reply-To: <200801140622.m0E6MTGk004121@cvs-int.fedora.redhat.com> References: <200801140622.m0E6MTGk004121@cvs-int.fedora.redhat.com> Message-ID: <1200302093.5174.7.camel@beck.corsepiu.local> On Mon, 2008-01-14 at 01:22 -0500, Caius Chance wrote: > Added Files: > liberation-fonts.tar.gz > Log Message: > * Mon Jan 14 2008 Caius Chance - 1.0-1.fc9 > - Resolves: rhbz#428596 (Liberation fonts need to be updated to latest font.) You have just committed a source tarball into cvs. I would appreciate it, if people were putting such tarballs into the look-aside cache instead. Thanks, Ralf From txtoth at gmail.com Mon Jan 14 14:04:52 2008 From: txtoth at gmail.com (Ted X Toth) Date: Mon, 14 Jan 2008 08:04:52 -0600 Subject: xmlto build errors In-Reply-To: <1200302734.3924.6.camel@dhcp-lab-219.englab.brq.redhat.com> References: <1200302734.3924.6.camel@dhcp-lab-219.englab.brq.redhat.com> Message-ID: <478B6C04.6080806@gmail.com> I currently have docbook-style-xsl-1.73.2-1.fc8 installed which is the latest fc8 version as best as I can tell. What version do think is fixed? By the way I'm building on x86_64 if that makes a difference. Ted Ond?ej Va??k wrote: > Hi, > Sorry for that, > that's caused by buggy %postun of one docbook-style-xsl package. > That postun is already fixed in latest stable F8 and F7 packages > , but still will cause troubles by deregistering catalogs > (registered by post of current correct package). > Following workarounds are available: > 1) yum erase docbook-style-xsl and yum install docbook-style-xsl > 2) force update with latest docbook-style-xsl package on F7/F8 > once more time > > Problem could be fixed by doubled update or by pushing new version > of docbook-style-xsl (which should be available at the end of Jan) > > Once more time sorry for troubles, > > Greetings, > Ondrej Vasik > > docbook-style-xsl and xmlto Fedora maintainer > > > > Xavier Toth wrote Sun 13th Jan 2008 : > >> I googled for fixes to this problem but didn't see any. >> I/O error : Attempt to load network entity >> http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl >> warning: failed to load external entity >> "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl" >> compilation error: file /tmp/xmlto-xsl.Xn2521 line 4 element import >> xsl:import : unable to load >> http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl >> I/O error : Attempt to load network entity >> http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl >> warning: failed to load external entity >> "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl" >> compilation error: file /tmp/xmlto-xsl.KT2576 line 4 element import >> xsl:import : unable to load >> http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl >> >> Q: I'm trying to build xmlto on my Debian box, but it doesn't work. >> >> A: If you get `Attempt to load network entity' errors when building >> xmlto, your system does not have the required support for XML >> Catalogs >> (http://www.oasis-open.org/committees/entity/spec-2001-08-06.html). >> In particular, Debian has no support for these. Try the Fedora >> Project . >> make[1]: *** [man/man1/xmlto.1] Error 1 >> make[1]: Leaving directory >> `/home/jcdxdev/src2/Linux_x86_64/BUILD/rpmbuild/BUILD/xmlto-0.0.18' >> make: *** [all] Error 2 >> error: Bad exit status from /var/tmp/rpm-tmp.59339 (%build) >> >> >> RPM build errors: >> Bad exit status from /var/tmp/rpm-tmp.59339 (%build) >> >> From mschwendt.tmp0701.nospam at arcor.de Mon Jan 14 14:18:49 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 14 Jan 2008 15:18:49 +0100 Subject: rpms/openldap/devel .cvsignore, 1.37, 1.38 openldap.spec, 1.107, 1.108 sources, 1.37, 1.38 In-Reply-To: <200801141322.m0EDMbR8021635@cvs-int.fedora.redhat.com> References: <200801141322.m0EDMbR8021635@cvs-int.fedora.redhat.com> Message-ID: <20080114151849.35d7498f.mschwendt.tmp0701.nospam@arcor.de> On Mon, 14 Jan 2008 08:22:37 -0500, Jan ?afr?nek (jsafrane) wrote: > Author: jsafrane > > Update of /cvs/pkgs/rpms/openldap/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv21562 > > Modified Files: > .cvsignore openldap.spec sources > Log Message: > new upstream version > --- sources 21 Nov 2007 12:12:15 -0000 1.37 > +++ sources 14 Jan 2008 13:21:58 -0000 1.38 > @@ -1,4 +1,4 @@ > e3fec2953c948f6990ccdc3af7bf7f18 openldap-2.3.39.tgz > 3faf83eb8482e55979bda47f1d1e6501 MigrationTools-47.tar.gz > 33851f01b455cca48aa601956de93c6f db-4.4.20.tar.gz > -4418da48649297587a3d07c987808a5e openldap-2.4.6.tgz > +4738ccb79215c027b857a6ea56e7351d openldap-2.4.7.tgz You can drop the old 2.3.39 from that file, also to speed up "make sources". From lesmikesell at gmail.com Mon Jan 14 14:18:55 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 14 Jan 2008 08:18:55 -0600 Subject: Preloading [WAS: Re: SuSE Project SUPER] In-Reply-To: <1200296346.5433.10.camel@localhost> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47893D75.1000406@redhat.com> <5e92ee3f0801121432qcf7287cx2982deafafe0674c@mail.gmail.com> <3adc77210801131634q41296a6br5fd5c3f444f98588@mail.gmail.com> <478ACD3C.6070106@redhat.com> <604aa7910801132244t15fbfdecg52c39f12b402406@mail.gmail.com> <1200296346.5433.10.camel@localhost> Message-ID: <478B6F4F.7020904@gmail.com> Callum Lerwick wrote: > The whole idea of preloading is crackrock. Its just hiding the problem, > at best. > > The problem is the relentless march of bloat. > One person's bloat is someone else's most needed feature - and there's not a big problem these days with disk space to store unused options. The problem is that the programs, their shared libraries, and config files are splattered all over the disk and seeking to access them is much slower than any other computer operation. There has to be some trick that could be used either to pre-arrange all the files used in the boot process together or load something early to pull in all of the shared libs in a certain order, or have them preloaded in a swapfile or something. If you change the goal to reducing disk seeks instead of specifically preloading files it might be easier to accomplish a speedup. -- Les Mikesell lesmikesell at gmail.com From txtoth at gmail.com Mon Jan 14 14:17:20 2008 From: txtoth at gmail.com (Ted X Toth) Date: Mon, 14 Jan 2008 08:17:20 -0600 Subject: xmlto build errors In-Reply-To: <1200302734.3924.6.camel@dhcp-lab-219.englab.brq.redhat.com> References: <1200302734.3924.6.camel@dhcp-lab-219.englab.brq.redhat.com> Message-ID: <478B6EF0.7090702@gmail.com> Ok I got the fc9 version of docbook-style-xsl built and installed it and now xmlto builds. Now I hope X will build as that was my real problem :) Thanks. Ond?ej Va??k wrote: > Hi, > Sorry for that, > that's caused by buggy %postun of one docbook-style-xsl package. > That postun is already fixed in latest stable F8 and F7 packages > , but still will cause troubles by deregistering catalogs > (registered by post of current correct package). > Following workarounds are available: > 1) yum erase docbook-style-xsl and yum install docbook-style-xsl > 2) force update with latest docbook-style-xsl package on F7/F8 > once more time > > Problem could be fixed by doubled update or by pushing new version > of docbook-style-xsl (which should be available at the end of Jan) > > Once more time sorry for troubles, > > Greetings, > Ondrej Vasik > > docbook-style-xsl and xmlto Fedora maintainer > > > > Xavier Toth wrote Sun 13th Jan 2008 : > >> I googled for fixes to this problem but didn't see any. >> I/O error : Attempt to load network entity >> http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl >> warning: failed to load external entity >> "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl" >> compilation error: file /tmp/xmlto-xsl.Xn2521 line 4 element import >> xsl:import : unable to load >> http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl >> I/O error : Attempt to load network entity >> http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl >> warning: failed to load external entity >> "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl" >> compilation error: file /tmp/xmlto-xsl.KT2576 line 4 element import >> xsl:import : unable to load >> http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl >> >> Q: I'm trying to build xmlto on my Debian box, but it doesn't work. >> >> A: If you get `Attempt to load network entity' errors when building >> xmlto, your system does not have the required support for XML >> Catalogs >> (http://www.oasis-open.org/committees/entity/spec-2001-08-06.html). >> In particular, Debian has no support for these. Try the Fedora >> Project . >> make[1]: *** [man/man1/xmlto.1] Error 1 >> make[1]: Leaving directory >> `/home/jcdxdev/src2/Linux_x86_64/BUILD/rpmbuild/BUILD/xmlto-0.0.18' >> make: *** [all] Error 2 >> error: Bad exit status from /var/tmp/rpm-tmp.59339 (%build) >> >> >> RPM build errors: >> Bad exit status from /var/tmp/rpm-tmp.59339 (%build) >> >> From ovasik at redhat.com Mon Jan 14 14:15:19 2008 From: ovasik at redhat.com (=?UTF-8?Q?Ond=C5=99ej_Va=C5=A1=C3=ADk?=) Date: Mon, 14 Jan 2008 15:15:19 +0100 Subject: xmlto build errors In-Reply-To: <478B6C04.6080806@gmail.com> References: <1200302734.3924.6.camel@dhcp-lab-219.englab.brq.redhat.com> <478B6C04.6080806@gmail.com> Message-ID: <1200320119.3924.32.camel@dhcp-lab-219.englab.brq.redhat.com> Hi, On Fri, 11 Jan 2008 10:36:43 -0700 was docbook-style-xsl-1.73.2-4.fc8 pushed to stable(at similar time the same for F7). That's latest version for F8 for me. Buggy version is docbook-style-xsl-1.73.2-3.fc8 and docbook-style-xsl-1.73.2-2.fc7. Anyway - your problem is related to missing registration of XML catalogs - that could be caused by this buggy postun or by missing libxml2 (which provides required /usr/bin/xmlcatalog and was added to Requires in that buggy update). So please update to docbook-style-xsl-1.73.2-4.fc8 - this should solve your troubles. Greetings, Ondrej Vasik Ted X Toth wrote: > I currently have docbook-style-xsl-1.73.2-1.fc8 installed which is the > latest fc8 version as best as I can tell. What version do think is > fixed? By the way I'm building on x86_64 if that makes a difference. > > Ted > > Ond?ej Va??k wrote: > > Hi, > > Sorry for that, > > that's caused by buggy %postun of one docbook-style-xsl package. > > That postun is already fixed in latest stable F8 and F7 packages > > , but still will cause troubles by deregistering catalogs > > (registered by post of current correct package). > > Following workarounds are available: > > 1) yum erase docbook-style-xsl and yum install docbook-style-xsl > > 2) force update with latest docbook-style-xsl package on F7/F8 > > once more time > > > > Problem could be fixed by doubled update or by pushing new version > > of docbook-style-xsl (which should be available at the end of Jan) > > > > Once more time sorry for troubles, > > > > Greetings, > > Ondrej Vasik > > > > docbook-style-xsl and xmlto Fedora maintainer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Toto je digit?ln? podepsan? ??st zpr?vy URL: From opensource at till.name Mon Jan 14 14:27:10 2008 From: opensource at till.name (Till Maas) Date: Mon, 14 Jan 2008 15:27:10 +0100 Subject: rpms/liberation-fonts/devel liberation-fonts.tar.gz,NONE,1.1 In-Reply-To: <1200302093.5174.7.camel@beck.corsepiu.local> References: <200801140622.m0E6MTGk004121@cvs-int.fedora.redhat.com> <1200302093.5174.7.camel@beck.corsepiu.local> Message-ID: <200801141527.28727.opensource@till.name> On Monday 14 January 2008 10:14:53 Ralf Corsepius wrote: > On Mon, 2008-01-14 at 01:22 -0500, Caius Chance wrote: > > Added Files: > > liberation-fonts.tar.gz > > Log Message: > > * Mon Jan 14 2008 Caius Chance - 1.0-1.fc9 > > - Resolves: rhbz#428596 (Liberation fonts need to be updated to latest > > font.) > > You have just committed a source tarball into cvs. > > I would appreciate it, if people were putting such tarballs into the > look-aside cache instead. In case it is the only tarball that is used, make new-sources FILES=liberation-fonts.tar.gz will do this. There is some information about this at: http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From kaigai at kaigai.gr.jp Mon Jan 14 14:31:43 2008 From: kaigai at kaigai.gr.jp (KaiGai Kohei) Date: Mon, 14 Jan 2008 23:31:43 +0900 Subject: rpms/sepostgresql/devel postgresql-8.2.6.tar.gz, NONE, 1.1 .cvsignore, 1.4, 1.5 sepostgresql.init, 1.8, 1.9 sepostgresql.spec, 1.8, 1.9 sepostgresql.te, 1.8, 1.9 In-Reply-To: <20080114120951.4c9df209.mschwendt.tmp0701.nospam@arcor.de> References: <200801101437.m0AEbemG002515@cvs-int.fedora.redhat.com> <1199983507.3398.14.camel@localhost.localdomain> <20080114120951.4c9df209.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <478B724F.4010002@kaigai.gr.jp> Michael Schwendt wrote: > On Thu, 10 Jan 2008 08:45:07 -0800, Devrim G?ND?Z wrote: > >> Hi, >> >> On Thu, 2008-01-10 at 09:37 -0500, KaiGai Kohei wrote: >>> Added Files: >>> postgresql-8.2.6.tar.gz >>> Log Message: >>> add postgresql-8.2.6.tar.gz >> Why do you keep the tarball in CVS??? >> >> Regards, > > That is highly annoying. I just run into it. > > How can I find out who kaigai's sponsor is? > The FAS does not show that information. > > Please fix sepostgresql in cvs ASAP. Upload large binary files to the > lookaside cache as everyone else. OK, I'll fix it soon. I'm sorry for the incorrect method to upgrade large binary file. Could you point out a documentation url which describes processes to do? I could not find it now... -- KaiGai Kohei From mtasaka at ioa.s.u-tokyo.ac.jp Mon Jan 14 14:43:35 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Mon, 14 Jan 2008 23:43:35 +0900 Subject: rpms/sepostgresql/devel postgresql-8.2.6.tar.gz, NONE, 1.1 .cvsignore, 1.4, 1.5 sepostgresql.init, 1.8, 1.9 sepostgresql.spec, 1.8, 1.9 sepostgresql.te, 1.8, 1.9 In-Reply-To: <478B724F.4010002@kaigai.gr.jp> References: <200801101437.m0AEbemG002515@cvs-int.fedora.redhat.com> <1199983507.3398.14.camel@localhost.localdomain> <20080114120951.4c9df209.mschwendt.tmp0701.nospam@arcor.de> <478B724F.4010002@kaigai.gr.jp> Message-ID: <478B7517.9010206@ioa.s.u-tokyo.ac.jp> Hello, Kaigai-san: KaiGai Kohei wrote, at 01/14/2008 11:31 PM +9:00: > Michael Schwendt wrote: >> Please fix sepostgresql in cvs ASAP. Upload large binary files to the >> lookaside cache as everyone else. > > OK, I'll fix it soon. > I'm sorry for the incorrect method to upgrade large binary file. > > Could you point out a documentation url which describes processes to do? > I could not find it now... Please refer to: http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo Sorry for not pointing out this before as your sponsor. Regards, Mamoru From dhollis at davehollis.com Mon Jan 14 14:51:35 2008 From: dhollis at davehollis.com (David Hollis) Date: Mon, 14 Jan 2008 09:51:35 -0500 Subject: Start/stop of OpenVPN interfaces with ifup/ifdown In-Reply-To: <6c3f5e6c0801111556s22a5d6c6p89438cd6d3917364@mail.gmail.com> References: <200801112338.m0BNcflD031668@jasmine.xos.nl> <6c3f5e6c0801111556s22a5d6c6p89438cd6d3917364@mail.gmail.com> Message-ID: <1200322295.3350.8.camel@dhollis-lnx.sunera.com> On Fri, 2008-01-11 at 18:56 -0500, Andrew Parker wrote: > Personally I would like to see this and the mounting/unmounting of > network shares wired up to NetworkManager. For my purposes, NM > doesn't quite cut it as when I change wired to wireless, I need to > unmount shares, shut down vpn, change network, start up vpn, mount > shares again. Consequently I have some ugly scripts to do this work > for me, but I would be much happier if NM would do the job for me. > Couldn't at least some of that be handled thru NetworkManagerDispatcher scripts? -- David Hollis From mschwendt.tmp0701.nospam at arcor.de Mon Jan 14 14:55:58 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 14 Jan 2008 15:55:58 +0100 Subject: rpms/sepostgresql/devel postgresql-8.2.6.tar.gz, NONE, 1.1 .cvsignore, 1.4, 1.5 sepostgresql.init, 1.8, 1.9 sepostgresql.spec, 1.8, 1.9 sepostgresql.te, 1.8, 1.9 In-Reply-To: <478B724F.4010002@kaigai.gr.jp> References: <200801101437.m0AEbemG002515@cvs-int.fedora.redhat.com> <1199983507.3398.14.camel@localhost.localdomain> <20080114120951.4c9df209.mschwendt.tmp0701.nospam@arcor.de> <478B724F.4010002@kaigai.gr.jp> Message-ID: <20080114155558.83443828.mschwendt.tmp0701.nospam@arcor.de> On Mon, 14 Jan 2008 23:31:43 +0900, KaiGai Kohei wrote: > Michael Schwendt wrote: > > On Thu, 10 Jan 2008 08:45:07 -0800, Devrim G?ND?Z wrote: > > > >> Hi, > >> > >> On Thu, 2008-01-10 at 09:37 -0500, KaiGai Kohei wrote: > >>> Added Files: > >>> postgresql-8.2.6.tar.gz > >>> Log Message: > >>> add postgresql-8.2.6.tar.gz > >> Why do you keep the tarball in CVS??? > >> > >> Regards, > > > > That is highly annoying. I just run into it. > > > > How can I find out who kaigai's sponsor is? > > The FAS does not show that information. > > > > Please fix sepostgresql in cvs ASAP. Upload large binary files to the > > lookaside cache as everyone else. > > OK, I'll fix it soon. > I'm sorry for the incorrect method to upgrade large binary file. > > Could you point out a documentation url which describes processes to do? > I could not find it now... http://cvs.fedora.redhat.com/ Item 1 in the FAQ. And yes, the Wiki is a confusing maze. :-( From david at lovesunix.net Mon Jan 14 15:05:43 2008 From: david at lovesunix.net (David Nielsen) Date: Mon, 14 Jan 2008 16:05:43 +0100 Subject: Preloading [WAS: Re: SuSE Project SUPER] In-Reply-To: <604aa7910801132244t15fbfdecg52c39f12b402406@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47893D75.1000406@redhat.com> <5e92ee3f0801121432qcf7287cx2982deafafe0674c@mail.gmail.com> <3adc77210801131634q41296a6br5fd5c3f444f98588@mail.gmail.com> <478ACD3C.6070106@redhat.com> <604aa7910801132244t15fbfdecg52c39f12b402406@mail.gmail.com> Message-ID: <1200323143.3973.3.camel@localhost.localdomain> s?n, 13 01 2008 kl. 21:44 -0900, skrev Jeff Spaleta: > On Jan 13, 2008 5:47 PM, Eric Sandeen wrote: > > Well, I looked into the readahead util for boot time, and it seemed to > > hurt more than help. But ongoing preload that learns & adjusts to usage > > patterns could help I'm sure, if done right > > That wont help the critical first impression phase.. before > application usage patterns are established and people are feeling out > the release. And to be more blunt about it.. it won't help first > impression from the reviewers who run a distro just long enough to > figure what they like and don't like about it and want to get their > review in within the first week of a release. > How many people end up relying on the first impression of others to > form their own impressions? Adaptive methods that only help boot > speeds after multiple reboots with extended usage pattern trending > isn't really going to impact the impression people have one damn bit. > > And it wont help livecds where state information is lost between reboots. Would it be possible to pre-seed such an adaptive scheme.. we know what we call on boot on a out of the box F9 final. Then as usage changes, updates are issued and such the adaptive stuff would be able to keep the preload system in as close to an optimal state? That would seem to be the best of both worlds to me, but then again I'm a self-admitted bumbling fool so what do I know. - David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From sandeen at redhat.com Mon Jan 14 15:36:35 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Mon, 14 Jan 2008 09:36:35 -0600 Subject: Preloading [WAS: Re: SuSE Project SUPER] In-Reply-To: <478B6F4F.7020904@gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47893D75.1000406@redhat.com> <5e92ee3f0801121432qcf7287cx2982deafafe0674c@mail.gmail.com> <3adc77210801131634q41296a6br5fd5c3f444f98588@mail.gmail.com> <478ACD3C.6070106@redhat.com> <604aa7910801132244t15fbfdecg52c39f12b402406@mail.gmail.com> <1200296346.5433.10.camel@localhost> <478B6F4F.7020904@gmail.com> Message-ID: <478B8183.5080607@redhat.com> Les Mikesell wrote: > If you change the goal to reducing disk seeks instead of > specifically preloading files it might be easier to accomplish a speedup. Just a note, seekwatcher is in F8 now ;) Doesn't solve the problem but helps visualize it (and potential solutions) at least. -Eric From kaigai at kaigai.gr.jp Mon Jan 14 16:08:43 2008 From: kaigai at kaigai.gr.jp (KaiGai Kohei) Date: Tue, 15 Jan 2008 01:08:43 +0900 Subject: rpms/sepostgresql/devel postgresql-8.2.6.tar.gz, NONE, 1.1 .cvsignore, 1.4, 1.5 sepostgresql.init, 1.8, 1.9 sepostgresql.spec, 1.8, 1.9 sepostgresql.te, 1.8, 1.9 In-Reply-To: <20080114155558.83443828.mschwendt.tmp0701.nospam@arcor.de> References: <200801101437.m0AEbemG002515@cvs-int.fedora.redhat.com> <1199983507.3398.14.camel@localhost.localdomain> <20080114120951.4c9df209.mschwendt.tmp0701.nospam@arcor.de> <478B724F.4010002@kaigai.gr.jp> <20080114155558.83443828.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <478B890B.2070005@kaigai.gr.jp> Michael Schwendt wrote: > On Mon, 14 Jan 2008 23:31:43 +0900, KaiGai Kohei wrote: > >> Michael Schwendt wrote: >>> On Thu, 10 Jan 2008 08:45:07 -0800, Devrim G?ND?Z wrote: >>> >>>> Hi, >>>> >>>> On Thu, 2008-01-10 at 09:37 -0500, KaiGai Kohei wrote: >>>>> Added Files: >>>>> postgresql-8.2.6.tar.gz >>>>> Log Message: >>>>> add postgresql-8.2.6.tar.gz >>>> Why do you keep the tarball in CVS??? >>>> >>>> Regards, >>> That is highly annoying. I just run into it. >>> >>> How can I find out who kaigai's sponsor is? >>> The FAS does not show that information. >>> >>> Please fix sepostgresql in cvs ASAP. Upload large binary files to the >>> lookaside cache as everyone else. >> OK, I'll fix it soon. >> I'm sorry for the incorrect method to upgrade large binary file. >> >> Could you point out a documentation url which describes processes to do? >> I could not find it now... > > http://cvs.fedora.redhat.com/ > > Item 1 in the FAQ. > > And yes, the Wiki is a confusing maze. :-( Thanks for your suggestion. I've fixed them with the above processes. If possible, please confirm it. -- KaiGai Kohei From buildsys at redhat.com Mon Jan 14 16:12:18 2008 From: buildsys at redhat.com (Build System) Date: Mon, 14 Jan 2008 11:12:18 -0500 Subject: rawhide report: 20080114 changes Message-ID: <200801141612.m0EGCIoZ007676@porkchop.devel.redhat.com> New package linux-igd The Linux UPNP Internet GATEWAY DEVICE New package nntpgrab NNTPGrab is a program to download files from the usenet New package pards A library for PARallel programs with Dataflow Synchronization New package perl-Linux-Pid Get the native PID and the PPID on Linux New package perl-XML-Xerces Perl API to Xerces XML parser New package synce-sync-engine Synce synchronization engine Updated Packages: DevIL-1.6.8-0.14.rc2.fc9 ------------------------ * Sun Jan 13 2008 Ian Chapman 1.6.8-0.14.rc2 - Patch to fix headers for gcc 4.3, see BZ #428527. (Thanks to Hans de Goede) * Wed Aug 22 2007 Ian Chapman 1.6.8-0.13.rc2 - Release bump for F8 mass rebuild - Added patch to fix BZ #253639 * Tue Aug 07 2007 Ian Chapman 1.6.8-0.12.rc2 - Split libILUT into separate package. See BZ #250734 - Removed some old provides: - Convert the CREDITS to UTF8 - Updated license field due to new guidelines anaconda-11.4.0.20-1 -------------------- * Sun Jan 13 2008 Chris Lumens - 11.4.0.20-1 - Install new udev paths so HAL can talk to it (notting) - Also get DSO deps for setuid binaries (like X). (clumens) - Fix a bunch of pychecker errors. (clumens) cernlib-2006-23.fc9 ------------------- * Sun Jan 13 2008 Patrice Dumas 2006-23 - new cernlib debian patcheset cernlib-g77-2006-23.fc9 ----------------------- * Sun Jan 13 2008 Patrice Dumas 2006-23 - new cernlib debian patcheset * Tue Jan 08 2008 Patrice Dumas 2006-22 - new debian patchesets * Mon Dec 31 2007 Patrice Dumas 2006-21 - no --build-id for EL-5 emacs-vm-8.0.7.522-1.fc9 ------------------------ * Sun Jan 13 2008 Jonathan G. Underwood - 8.0.7.522-1 - Update to version 8.0.7-522 - Add patch to fix correct display of redistributed flag (BZ #428248) exempi-1.99.7-1.fc9 ------------------- * Sun Jan 13 2008 Deji Akingunola - 1.99.7-1 - Update to 1.99.7 exiv2-0.16-1.fc9 ---------------- * Sun Jan 13 2008 Rex Dieter 0.16-1 - eviv2-0.16 fontmatrix-0.3.0-4.r289.fc9 --------------------------- * Mon Jan 14 2008 Parag - 0.3.0-4.r289 - update to svn revision 289(Stable release of 0.3.0 version) glpi-0.70.1-2.fc9 ----------------- * Sun Jan 13 2008 Remi Collet - 0.70.1-2 - fix typo in lang files * Sun Jan 13 2008 Remi Collet - 0.70.1-1 - update to 0.70.1 (0.70 + bugfixes) libXfont-1.3.1-2.fc9 -------------------- * Sun Jan 13 2008 parag 1.3.1-2 - Merge-review #226073 Spec cleanups. libXfontcache-1.0.4-4.fc9 ------------------------- * Sun Jan 13 2008 parag 1.0.4-4 - Merge-review #226072 spec cleanups. - Drop files with zero-length (README,AUTHORS) libjpeg-6b-40.fc9 ----------------- * Sun Jan 13 2008 Tom Lane - 6b-40 - Rip out the long-obsolete version of libtool that shipped with libjpeg 6b, and instead use the build system's libtool. This obsoletes most of the patches we were carrying. - Fix configure script to #define the various HAVE_FOO macros as 1, not empty, for better compatibility with most other autoconf-using packages. (This requires importing the original IJG configure.in, which was not shipped in libjpeg-6b for reasons that no longer seem very good.) Resolves: #427616 libvirt-0.4.0-3.fc9 ------------------- * Sun Jan 13 2008 Daniel P. Berrange - 0.4.0-3.fc9 - Fix crash when no auth callback netgen-1.3.7-14.fc9 ------------------- * Sun Jan 13 2008 Chitlesh Goorah - 1.3.7-14 - rebuilt for TCL 8.5 #428540 ogre-1.4.6-2.fc9 ---------------- * Sat Jan 12 2008 Hans de Goede 1.4.6-2 - Oops I just found out that ogre contains private copies of GL and GLEW headers, which fall under the not 100% SGI Free Software B and GLX Public License licenses, remove these (even from the tarbal!) and use the system versions instead openarena-0.7.1-5.fc9 --------------------- * Sun Jan 13 2008 Micha?? Bentkowski - 0.7.1-5 - Fix wrapper to include master server adress * Sat Jan 05 2008 Micha?? Bentkowski - 0.7.1-4 - Use quake3 package from repo instead of own engine - No -data subpackage since the main package now contains data - Now the spec simple creates wrapper and just copy data to proper dir openoffice.org-1:2.4.0-1.2.fc9 ------------------------------ * Fri Jan 11 2008 Caolan McNamara - 1:2.4.0-1.2 - add openoffice.org-2.4.0.oooXXXXX.solenv.paths.patch to fix up -devel Requires - add openoffice.org-2.4.0.rh133741.alwaysgtk.vcl.patch - Resolves: rhbz#425701/ooo#83410 try and fix serbian translations * Sun Jan 06 2008 Caolan McNamara - 1:2.4.0-1.1 - first OOH680_m1 - remove redundant entries from configure - drop integrated openoffice.org-2.3.0.ooo77885.stoc.stocmerge.patch - drop integrated openoffice.org-1.9.129.ooo54603.fontconfig.patch - drop integrated workspace.as6.patch - drop integrated openoffice.org-2.0.3.ooo68048.vcl.imsurroundtext.patch - drop integrated openoffice.org-2.1.0.ooo72129.vcl.fontglyphindex.patch - drop integrated workspace.configrefactor01.patch - drop integrated openoffice.org-2.2.1.ooo80424.vcl.honourwidthtype.patch - drop integrated workspace.npower7.patch - drop integrated openoffice.org-2.3.0.ooo80721.reportdesign.stlportism.patch - drop integrated openoffice.org-2.3.0.ooo80735.cppu.map.patch - drop integrated openoffice.org-2.3.0.ooo80967.ucb.neon27.patch - drop integrated openoffice.org-2.3.0.ooo81112.reportdesign.parallel.patch - drop integrated openoffice.org-2.3.0.ooo81936.sc.maketypesagree.patch - drop integrated workspace.fpicker7.patch - drop integrated openoffice.org-2.3.0.ooo83591.vcl.checkboxes.patch - drop integrated openoffice.org-2.3.1.ooo82911.sd.insertbackground.patch - drop integrated workspace.sw8u10bf02.patch - drop integrated openoffice.org-2.3.1.ooo83930.sw.flushanchors.patch - drop integrated workspace.cmcfixes39.patch - drop integrated workspace.gcc430.patch - drop integrated workspace.locales24.patch - drop integrated openoffice.org-2.3.0.ooo81314.i18npool.crash.patch - drop openoffice.org-2.3.1.ooo84001.slideshow.gccisaprick.patch - drop openoffice.org-2.2.0.ooo53397.linkopt.patch - replace openoffice.org-2.1.0.ooo78148.lingucomponent.systemhunspell.patch with openoffice.org-2.1.0.oooXXXXX.lingucomponent.systemdicts.patch - add openoffice.org-2.4.0.ooo84684.vcl.fixfontconfig.patch - add Requires for indic hunspell dictionaries - Resolves: rhbz#427757 add openoffice.org-2.4.0.ooo85054.stlport.noorigs.patch - Resolves: rhbz#426876 add openoffice.org-2.4.0.ooo85055.psprint.linetoolong.patch - add openoffice.org-2.4.0.oooXXXXX.config_office.xpcomasxul.patch to build - add openoffice.org-2.4.0.ooo85097.desktop.pagein.patch * Thu Jan 03 2008 Caolan McNamara - 1:2.3.1-9.11 - Resolves: rhbz#427071 openoffice.org-2.3.0.ooo81314.i18npool.crash.patch perl-Algorithm-CheckDigits-0.48-2.fc9 ------------------------------------- perl-XML-Generator-DBI-1.00-4.fc9 --------------------------------- * Sat Jan 12 2008 Xavier Bachelot - 1.00-4 - Remove '|| :' from %check section. perl-XML-Handler-YAWriter-0.23-4.fc9 ------------------------------------ * Sat Jan 12 2008 Xavier Bachelot - 0.23-4 - Remove '|| :' from %check section. phpMyAdmin-2.11.4-1.fc9 ----------------------- * Sun Jan 13 2008 Robert Scheck 2.11.4-1 - Upstream released 2.11.4 - Corrected mod_security example in configuration file (#427119) * Sun Dec 09 2007 Robert Scheck 2.11.3-1 - Upstream released 2.11.3 - Removed the RPM scriptlets doing httpd restarts (#227025) - Patched an information disclosure known as CVE-2007-0095 (#221694) - Provide virtual phpmyadmin package and a httpd alias (#231431) * Wed Nov 21 2007 Robert Scheck 2.11.2.2-1 - Upstream released 2.11.2.2 (#393771) selinux-policy-3.2.5-11.fc9 --------------------------- * Sun Jan 13 2008 Dan Walsh 3.2.5-11 - Fixes for xguest to run java plugin sipp-3.0-1.fc9 -------------- * Thu Jan 10 2008 Peter Lemenkov 3.0-1 - Version 3.0 - Updated license field - Preserved timestamp for *.pcap files trackballs-1.1.4-5.fc9 ---------------------- * Sun Jan 13 2008 Hans de Goede 1.1.4-5 - Fix building with gcc 4.3 vnstat-1.6-1.fc9 ---------------- * Sun Jan 13 2008 Adrian Reber - 1.6-1 - updated to 1.6 - added vnstat.conf to %{_sysconfdir} - fixed a few rpmlint warnings wine-0.9.53-2.fc9 ----------------- * Sun Jan 13 2008 Andreas Bierfert - 0.9.53-2 - add some missing BR Broken deps for i386 ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.i386 requires libgtkembedmoz.so epiphany-extensions - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 gcl - 2.6.7-15.fc8.i386 requires libtk8.4.so gcl - 2.6.7-15.fc8.i386 requires libtcl8.4.so gdal-perl - 1.5.0-1.fc9.i386 requires perl(Geo::GDAL::Const) gnome-web-photo - 0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.i386 requires libgtkembedmoz.so gnome-web-photo - 0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 kazehakase - 0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 openoffice.org-devel - 1:2.4.0-1.2.fc9.i386 requires /bin/python openoffice.org-devel - 1:2.4.0-1.2.fc9.i386 requires /usr/solar/bin/perl tkinter - 2.5.1-20.fc9.i386 requires libTix8.4.so vtk - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtcl8.4.so Broken deps for x86_64 ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gcl - 2.6.7-15.fc8.x86_64 requires libtk8.4.so()(64bit) gcl - 2.6.7-15.fc8.x86_64 requires libtcl8.4.so()(64bit) gdal-perl - 1.5.0-1.fc9.x86_64 requires perl(Geo::GDAL::Const) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) kazehakase - 0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 openoffice.org-devel - 1:2.4.0-1.2.fc9.i386 requires /bin/python openoffice.org-devel - 1:2.4.0-1.2.fc9.i386 requires /usr/solar/bin/perl openoffice.org-devel - 1:2.4.0-1.2.fc9.x86_64 requires /bin/python openoffice.org-devel - 1:2.4.0-1.2.fc9.x86_64 requires /usr/solar/bin/perl tkinter - 2.5.1-20.fc9.x86_64 requires libTix8.4.so()(64bit) vtk - 5.0.3-20.fc8.x86_64 requires libtk8.4.so()(64bit) vtk - 5.0.3-20.fc8.x86_64 requires libtcl8.4.so()(64bit) vtk - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-python - 5.0.3-20.fc8.x86_64 requires libtk8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.x86_64 requires libtcl8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.x86_64 requires libtk8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.x86_64 requires libtcl8.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.ppc requires libgtkembedmoz.so epiphany-extensions - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 gdal-perl - 1.5.0-1.fc9.ppc requires perl(Geo::GDAL::Const) gnome-web-photo - 0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.ppc requires libgtkembedmoz.so gnome-web-photo - 0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 kazehakase - 0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 monodevelop - 0.17-4.fc9.ppc requires boo openoffice.org-devel - 1:2.4.0-1.2.fc9.ppc requires /bin/python openoffice.org-devel - 1:2.4.0-1.2.fc9.ppc requires /usr/solar/bin/perl openoffice.org-devel - 1:2.4.0-1.2.fc9.ppc64 requires /bin/python openoffice.org-devel - 1:2.4.0-1.2.fc9.ppc64 requires /usr/solar/bin/perl tkinter - 2.5.1-20.fc9.ppc requires libTix8.4.so vtk - 5.0.3-20.fc8.ppc requires libtcl8.4.so vtk - 5.0.3-20.fc8.ppc requires libtk8.4.so vtk - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc requires libtk8.4.so vtk-python - 5.0.3-20.fc8.ppc requires libtcl8.4.so vtk-python - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc requires libtk8.4.so vtk-tcl - 5.0.3-20.fc8.ppc requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) Broken deps for ppc64 ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gdal-perl - 1.5.0-1.fc9.ppc64 requires perl(Geo::GDAL::Const) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) kazehakase - 0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 openoffice.org-devel - 1:2.4.0-1.2.fc9.ppc64 requires /bin/python openoffice.org-devel - 1:2.4.0-1.2.fc9.ppc64 requires /usr/solar/bin/perl perl-Test-AutoBuild-darcs - 1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 tkinter - 2.5.1-20.fc9.ppc64 requires libTix8.4.so()(64bit) vtk - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) From jakub.rusinek at gmail.com Mon Jan 14 17:18:33 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Mon, 14 Jan 2008 18:18:33 +0100 Subject: compilation architecture In-Reply-To: <1200265300.19314.4.camel@home.alexander.bostrom.net> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <6e24a8e80801130809m78a158bfx4ca9ecb2a3b7129@mail.gmail.com> <5e92ee3f0801131112t65e4994aja0c7824d90e14614@mail.gmail.com> <478A657E.4020500@redhat.com> <5e92ee3f0801131135o23b1a6abx63027a19778f2622@mail.gmail.com> <1200254898.17118.268.camel@home.alexander.bostrom.net> <5e92ee3f0801131229r2fc2a2eco2a213f5d0bff0c85@mail.gmail.com> <1200265300.19314.4.camel@home.alexander.bostrom.net> Message-ID: <5e92ee3f0801140918r68b7d273p29b4feaf0d49700b@mail.gmail.com> 2008/1/14, Alexander Bostr?m : > > s?n 2008-01-13 klockan 21:29 +0100 skrev Jakub 'Livio' Rusinek: > > > I didn't mean the localization slows down Firefox, but when using > > Firefox 3 from repo I feel little slowing down compared to Firefox 3 > > snapshot from trunk. > > Yes, and if you list the number of extensions in one versus the > other...? > > /abo > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I have no extensions, silly, but I noticed that starting Firefox 2 on Fedora always taked for me a long time. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmc.fedora at filteredperception.org Mon Jan 14 17:54:25 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 14 Jan 2008 11:54:25 -0600 Subject: Preloading [WAS: Re: SuSE Project SUPER] In-Reply-To: <1200323143.3973.3.camel@localhost.localdomain> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47893D75.1000406@redhat.com> <5e92ee3f0801121432qcf7287cx2982deafafe0674c@mail.gmail.com> <3adc77210801131634q41296a6br5fd5c3f444f98588@mail.gmail.com> <478ACD3C.6070106@redhat.com> <604aa7910801132244t15fbfdecg52c39f12b402406@mail.gmail.com> <1200323143.3973.3.camel@localhost.localdomain> Message-ID: <478BA1D1.8080208@filteredperception.org> David Nielsen wrote: > s?n, 13 01 2008 kl. 21:44 -0900, skrev Jeff Spaleta: >> On Jan 13, 2008 5:47 PM, Eric Sandeen wrote: >>> Well, I looked into the readahead util for boot time, and it seemed to >>> hurt more than help. But ongoing preload that learns & adjusts to usage >>> patterns could help I'm sure, if done right >> That wont help the critical first impression phase.. before >> application usage patterns are established and people are feeling out >> the release. And to be more blunt about it.. it won't help first >> impression from the reviewers who run a distro just long enough to >> figure what they like and don't like about it and want to get their >> review in within the first week of a release. >> How many people end up relying on the first impression of others to >> form their own impressions? Adaptive methods that only help boot >> speeds after multiple reboots with extended usage pattern trending >> isn't really going to impact the impression people have one damn bit. >> >> And it wont help livecds where state information is lost between reboots. > > Would it be possible to pre-seed such an adaptive scheme.. we know what > we call on boot on a out of the box F9 final. Personally of course, I think the long term ideal solution might end up looking like my method with the livecd, percolating to normal usage. I.e. my method does a precooking boot under qemu during livecd compose to get file access order. Then creates the ext3 fsimage on the livecd with that sorting order, by just copying the files in order. Then when booting, preloads a chunk from the beginning of the fs into ram(tmpfs), in one big long read. Then after boot is done, discards the chunk in ram. (And the size of the chunk is determined by how much ram the system has.) This already has a benefit of minimizing seeks for disk based installation once this ext3 image is copied to the hard drive, during a normal livecd installation now. The key to making this an ideal disk-boot solution, is that you need a daemon which watches each boot, and resorts the blocks on the ext3fs such that the earlier they are accessed relative to boot, the closer they are to the outter rim of the filesystem. And then using the same devicemapper ram caching trick during disk-boot as during livecd-boot. Note, the above method doesn't minimize seeks like sorting does, it removes them, as a huge chunk is read into ram with just a singe seek. I suspect something similar had been discussed for disk-boot before, but probably has been shelved because of the trouble of keeping the fs sorted. I'm amazed no one else however noticed how easy it is to apply to the livecd case, where seeks are drastically worse, and it is drastically easier to get the filesystem sorted. -dmc Then as usage changes, > updates are issued and such the adaptive stuff would be able to keep the > preload system in as close to an optimal state? > > That would seem to be the best of both worlds to me, but then again I'm > a self-admitted bumbling fool so what do I know. > > - David > > > From dmc.fedora at filteredperception.org Mon Jan 14 18:04:17 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 14 Jan 2008 12:04:17 -0600 Subject: Preloading [WAS: Re: SuSE Project SUPER] In-Reply-To: References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47893D75.1000406@redhat.com> <5e92ee3f0801121432qcf7287cx2982deafafe0674c@mail.gmail.com> <3adc77210801131634q41296a6br5fd5c3f444f98588@mail.gmail.com> <478ACD3C.6070106@redhat.com> <604aa7910801132244t15fbfdecg52c39f12b402406@mail.gmail.com> Message-ID: <478BA421.9070008@filteredperception.org> Linus Walleij wrote: > On Sun, 13 Jan 2008, Jeff Spaleta wrote: > >> That wont help the critical first impression phase.. > > > They are of course doing much more agressive things than simple > preloading, more like suspend-to-disk, so the user actually more or less > resumes a pre-booted image customized for that machine at "boot" time. > > I wonder if we could do that. I've considered this in the past, specifically for my mythtv home theatre box. The theory is that the 120G disk is a big data disk and has nothing to do with the OS. The OS can live on a little usbflash. Then, once thinking about it that way, and remembering the "repeatable resume" feature from vmware, the following idea occurred to me- Do just as you say- Do a livecd/liveusb style copy-on-write boot, where the rootfs is read-only and changes go to a devicemapper snapshot. Then do a hibernate during install, but save a copy of this golden hibernate (swap) image along with a golden copy of the dm-snapshot. Also, make the hibernate do an unmount of all data disks, and a resume do a remounting of them. Then, every power up of the system, would be a resume from the golden hibernation image. With a post-resume script that mounts data disks, resets the clock, and does whatever else is needed. Really it is similar behavior as a vmware 'repeatable resume', but non-virtual. -dmc From fedora at leemhuis.info Mon Jan 14 18:44:28 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 14 Jan 2008 19:44:28 +0100 Subject: diveintopython/book-prefix (was: Re: rawhide report: 20080111 changes) In-Reply-To: <478B6938.5060008@fedoraproject.org> References: <200801111755.m0BHt2wY002105@porkchop.devel.redhat.com> <1200317221.24328.10.camel@gibraltar.str.redhat.com> <478B6938.5060008@fedoraproject.org> Message-ID: <478BAD8C.9030306@leemhuis.info> On 14.01.2008 14:52, Rahul Sundaram wrote: > Nils Philippsen wrote: >> On Fri, 2008-01-11 at 12:55 -0500, Build System wrote: >>> New package diveintopython >>> Dive into Python - a python book >> Have we relaxed our "code vs. content" policy lately? While I'm not >> personally against having this package in, I don't think it falls under >> the "Package documentation or help files" exception in >> Packaging/Guidelines, or does it? > There was a small discussion about this in this list and the general > consensus seemed to be that such documentation is allowed. I think it's fine to ship it. But one thing looks odd to me: we use a lot of prefixes for packages in our repo already (fuse-, perl-, or python- are just some examples). I don't like them to much, as it just creates confusion if we ship a software under a different name than the one used upstream. But here upstream doesn't even have a proper name that users would expect to "yum install foo". So why not use a prefix like "book-" "doc-" or something else for diveintopython and similar packages to make it obvious that this is content (a book) and no code? Just wondering. CU knurd From dpquigl at tycho.nsa.gov Mon Jan 14 18:36:53 2008 From: dpquigl at tycho.nsa.gov (Dave Quigley) Date: Mon, 14 Jan 2008 13:36:53 -0500 Subject: Remastering an FC8 Livecd Message-ID: <1200335813.25017.13.camel@moss-terrapins.epoch.ncsc.mil> Hello, I am submitting a proposal for OLS this year for a tutorial session for SELinux. I figure the easiest way to get everyone a system with all the necessary SELinux packages is to make a livecd containing it all. I was wondering who is in charge of the Fedora livecd effort and what resources are there to get started on building Fedora livecds? Dave From mattdm at mattdm.org Mon Jan 14 18:57:14 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 14 Jan 2008 13:57:14 -0500 Subject: Preloading [WAS: Re: SuSE Project SUPER] In-Reply-To: <478B09BC.5080204@gmail.com> References: <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47893D75.1000406@redhat.com> <5e92ee3f0801121432qcf7287cx2982deafafe0674c@mail.gmail.com> <3adc77210801131634q41296a6br5fd5c3f444f98588@mail.gmail.com> <478ACD3C.6070106@redhat.com> <604aa7910801132244t15fbfdecg52c39f12b402406@mail.gmail.com> <478B09BC.5080204@gmail.com> Message-ID: <20080114185714.GA30554@jadzia.bu.edu> On Sun, Jan 13, 2008 at 11:05:32PM -0800, Andrew Farris wrote: > Uhm, yeah you're right. But it will help those who actually use the > distribution rather than toss it aside based off bad information they got > from someone else. There is certainly time and place to consider user > first impressions, but I hardly think its a good idea to filter an idea > like the above by ONLY that consideration. I dunno. It seems like optimizing for startup time seems a misguided if that's your goal. Starting stuff is a very low percentage of actual use, especially with suspend/hibernate. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From eparis at redhat.com Mon Jan 14 18:58:03 2008 From: eparis at redhat.com (Eric Paris) Date: Mon, 14 Jan 2008 13:58:03 -0500 Subject: xargs generates too long argument lists on i686 In-Reply-To: <200801141243.m0EChTgO016238@laptop13.inf.utfsm.cl> References: <200801141243.m0EChTgO016238@laptop13.inf.utfsm.cl> Message-ID: <1200337083.2761.11.camel@localhost.localdomain> On Mon, 2008-01-14 at 09:43 -0300, Horst H. von Brand wrote: > For some time now, each time I try to build an RPM it fails with something > like: > > + /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot > xargs: /usr/lib/rpm/check-rpaths-worker: Argument list too long > error: Bad exit status from /var/tmp/rpm-tmp.39544 (%install) > > This I have traced back to xargs(1) generating huge argument lists, which > the called command can't handle. Doing a "make clean" in a self-built > kernel gives the same type of grief (I tweaked the Makefile there to call > xargs with "-L 2000" to get it to work). > > I wonder how everybody else here is able to get anything done... > > findutils-4.2.31-2.fc8 on rawhide, fully up to date. well, if you aren't doing execve syscall argument logging with the audit system feel free to up /proc/sys/kernel/audit_argv_kb. If that fixes your troubles wait until 2.6.25 when my patch to finish unlimiting this stuff goes into kernel.... -Eric From dmc.fedora at filteredperception.org Mon Jan 14 18:57:05 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 14 Jan 2008 12:57:05 -0600 Subject: Remastering an FC8 Livecd In-Reply-To: <1200335813.25017.13.camel@moss-terrapins.epoch.ncsc.mil> References: <1200335813.25017.13.camel@moss-terrapins.epoch.ncsc.mil> Message-ID: <478BB081.7000900@filteredperception.org> Dave Quigley wrote: > Hello, > I am submitting a proposal for OLS this year for a tutorial session > for SELinux. I figure the easiest way to get everyone a system with all > the necessary SELinux packages is to make a livecd containing it all. I > was wondering who is in charge of the Fedora livecd effort and what > resources are there to get started on building Fedora livecds? > > Dave > second hit on google://"fedora livecd" http://fedoraproject.org/wiki/FedoraLiveCD -dmc From jkeating at redhat.com Mon Jan 14 19:03:58 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 14 Jan 2008 14:03:58 -0500 Subject: Slip of Alpha Message-ID: <20080114140358.05d19b3b@redhat.com> Today Release Engineering with input from QA has decided to slip the alpha release by a week. The current state of rawhide and the inability to install rawhide for many weeks now does not give us confident in a successful Alpha. We're giving the installer team an extra week to fix things up so that we have a better chance at a wide Alpha use. Releng/QA will revisit again next week during the release engineering meeting to give a go/no-go vote on enacting the freeze for Alpha. The schedule[1] has been updated to reflect this. No other dates have been adjusted at this point. [1]: http://fedoraproject.org/wiki/Releases/9/Schedule -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From lsof at nodata.co.uk Mon Jan 14 19:30:44 2008 From: lsof at nodata.co.uk (nodata) Date: Mon, 14 Jan 2008 20:30:44 +0100 Subject: Deleting a file/directory on startup In-Reply-To: <200801112003.44324.opensource@till.name> References: <200801111852.08733.opensource@till.name> <645d17210801111041k3bfa7195jbbe8b90ec6bf36fd@mail.gmail.com> <200801112003.44324.opensource@till.name> Message-ID: <1200339044.2884.1.camel@sb-home> Am Freitag, den 11.01.2008, 20:03 +0100 schrieb Till Maas: > On Fri January 11 2008, Jonathan Underwood wrote: > > > Have a look at the logic used in the fail2ban init file - the start > > operation checks for a running fail2ban process. If non is found, it > > is safe to delete the lock file. > > The logic in fail2ban is vulnerable to race conditions, which does not help > for pm-utils, where it can easily happen that it is run several times very > fast after each other. > > Btw. the initial problem is to only delete a file at startup. I even found a > bug report specifically about this: https://bugzilla.redhat.com/250927 > > Regards, > Till > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list The directory that stores these files should be wiped at boot or on shutdown.. From mlichvar at redhat.com Mon Jan 14 19:39:01 2008 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Mon, 14 Jan 2008 20:39:01 +0100 Subject: ncurses splitted Message-ID: <20080114193901.GA25265@localhost> ncurses package has now -base and -term subpackages, as was discussed here several months ago. -base is supposed to have descriptions of all commonly used terminals and -term is an optional package (not installed by default) that contains the rest. This saves almost 6MB of disk space. The split is based on Debian ncurses package. If you are missing description of your favorite terminal (even from another distro/system) in -base, drop me a line and I will move it. Thanks, -- Miroslav Lichvar From opensource at till.name Mon Jan 14 19:47:49 2008 From: opensource at till.name (Till Maas) Date: Mon, 14 Jan 2008 20:47:49 +0100 Subject: Deleting a file/directory on startup In-Reply-To: <1200339044.2884.1.camel@sb-home> References: <200801111852.08733.opensource@till.name> <200801112003.44324.opensource@till.name> <1200339044.2884.1.camel@sb-home> Message-ID: <200801142047.53471.opensource@till.name> On Mon January 14 2008, nodata wrote: > The directory that stores these files should be wiped at boot or on > shutdown.. Yes, this is where I search the best way to do this, except that I want that a directory is deleted. rc.sysinit does this only for some directories in /var/{run,lock}, e.g. for vmware. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From naheemzaffar at gmail.com Mon Jan 14 20:11:36 2008 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Mon, 14 Jan 2008 20:11:36 +0000 Subject: compilation architecture In-Reply-To: <5e92ee3f0801140918r68b7d273p29b4feaf0d49700b@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <6e24a8e80801130809m78a158bfx4ca9ecb2a3b7129@mail.gmail.com> <5e92ee3f0801131112t65e4994aja0c7824d90e14614@mail.gmail.com> <478A657E.4020500@redhat.com> <5e92ee3f0801131135o23b1a6abx63027a19778f2622@mail.gmail.com> <1200254898.17118.268.camel@home.alexander.bostrom.net> <5e92ee3f0801131229r2fc2a2eco2a213f5d0bff0c85@mail.gmail.com> <1200265300.19314.4.camel@home.alexander.bostrom.net> <5e92ee3f0801140918r68b7d273p29b4feaf0d49700b@mail.gmail.com> Message-ID: <3adc77210801141211u38273a8dy98aafa67e8306e57@mail.gmail.com> Firefox 2 in Fedora uses Pango for text layout. Upstream does not. No idea about other distributions, nor about whether this is more of a rendering performance penalty or a startup one. From seg at haxxed.com Mon Jan 14 20:14:02 2008 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 14 Jan 2008 14:14:02 -0600 Subject: compilation architecture In-Reply-To: References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> Message-ID: <1200341643.5433.81.camel@localhost> On Sat, 2008-01-12 at 18:51 +0100, drago01 wrote: > 2008/1/12 Jakub 'Livio' Rusinek : > > do we need to support legacy cpu's by i386 compilation? > > i586 would make fedora faster even 3 times. > > difference is noticeable. > > ..... > where are your benchmarks for the "3 times faster" claim? > the i386 packages are already optimized for newer cpus (mtune vs. march) > where it makes sense to have i686 versions there are some (kernel, glibc) Lets get some real numbers in here. For a quick and dirty benchmark I'm using OpenJPEG's MJ2 tools, I encode the speedway example using "frames_to_mj2 -i Speedway.yuv -o Speedway.mj2 -I 1", then decode it. I'm measuring the decode time. Tests were performed on a Mobile Celeron 1.3, which is P3 architecture. Here it is with -march=i386 -mcpu=generic. That is, standard Fedora flags: Total decoding time: 21.14 seconds (9.5 fps) With -march=i586 -mcpu=generic: Total decoding time: 21.26 seconds (9.4 fps) And -march=i686 -mcpu=generic: Total decoding time: 20.45 seconds (9.8 fps) So it is 0.54% *slower* when compiled for i586, which is unexpected and strange, but such is gcc. I wouldn't expect much of a speed difference compiling for i586, there was no major additions to the instruction set, and we're already scheduling for modern processors. Not quite "three times" faster, but 3.26% faster with i686. A major addition to the i686 architecture was cmov, and gcc is actually very aggressive about eliminating branching using cmovs, increasing performance on modern deeply pipelined processors by eliminating pipeline stalls. And yes, cmov is technically optional, earlier VIA C3 processors, still being sold, lack it. Completely dropping support for pre-i686 just isn't an option yet. If Smolt is to be believed, i686 machines are 99.43% (!) of all x86 machines. (Though I don't know if those pesky C3's are being counted as i686 or i586 or what...) I think its safe to say the vast majority of x86 systems out there have cmov, and are suffering with reduced performance in order to cater to a minority of systems. I suggest all key performance critical packages be made available in both i386 and i686 versions. glibc and openssl already do this. Off the top of my head, this would include Mesa, I know for a fact the majority of Second Life runtime is actually consumed by T&L inside Mesa/DRI. From what I understand, even Intel's latest chipsets lack hardware T&L. Makes sense, it helps sell more multi-core Intel processors, and probably helps consolidate power management. Also, all multimedia codecs. Old sub-Ghz machines have a lot of trouble playing the MPEG4 video that is common these days, and MythTV could use all the help it can get. Not that the MPEG4 codecs are in Fedora itself... Not that any of this has anything to do with the "firefox startup is slow" complaint that this thread has devolved into. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From lordmorgul at gmail.com Mon Jan 14 20:17:07 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Mon, 14 Jan 2008 12:17:07 -0800 Subject: Preloading [WAS: Re: SuSE Project SUPER] In-Reply-To: <20080114185714.GA30554@jadzia.bu.edu> References: <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47893D75.1000406@redhat.com> <5e92ee3f0801121432qcf7287cx2982deafafe0674c@mail.gmail.com> <3adc77210801131634q41296a6br5fd5c3f444f98588@mail.gmail.com> <478ACD3C.6070106@redhat.com> <604aa7910801132244t15fbfdecg52c39f12b402406@mail.gmail.com> <478B09BC.5080204@gmail.com> <20080114185714.GA30554@jadzia.bu.edu> Message-ID: <478BC343.3070309@gmail.com> Matthew Miller wrote: > On Sun, Jan 13, 2008 at 11:05:32PM -0800, Andrew Farris wrote: >> Uhm, yeah you're right. But it will help those who actually use the >> distribution rather than toss it aside based off bad information they got >> from someone else. There is certainly time and place to consider user >> first impressions, but I hardly think its a good idea to filter an idea >> like the above by ONLY that consideration. > > I dunno. It seems like optimizing for startup time seems a misguided if > that's your goal. Starting stuff is a very low percentage of actual use, > especially with suspend/hibernate. I'm aware its fairly low usage time, and not suggesting that any startup optimization options be made at the cost of others (quite the opposite...). What I was suggesting was that cached or otherwise optimized startup times are nicer than slow ones, and it would not be wasted effort if some improvements were made there. I like OSX's performance in that way alot. So I wouldn't call it misguided, just lower priority. It sounds like you would agree with me that no start time optimizations should have detrimental impact on performance the rest of the time though. I would not want startup performance caching to be going on while I'm trying to play a game for instance. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From jakub.rusinek at gmail.com Mon Jan 14 20:28:29 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Mon, 14 Jan 2008 21:28:29 +0100 Subject: compilation architecture In-Reply-To: <1200341643.5433.81.camel@localhost> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <1200341643.5433.81.camel@localhost> Message-ID: <5e92ee3f0801141228y4f11e91bieab63cfe2f3c6581@mail.gmail.com> 2008/1/14, Callum Lerwick : > > > On Sat, 2008-01-12 at 18:51 +0100, drago01 wrote: > > 2008/1/12 Jakub 'Livio' Rusinek : > > > do we need to support legacy cpu's by i386 compilation? > > > i586 would make fedora faster even 3 times. > > > difference is noticeable. > > > > ..... > > where are your benchmarks for the "3 times faster" claim? > > the i386 packages are already optimized for newer cpus (mtune vs. march) > > where it makes sense to have i686 versions there are some (kernel, > glibc) > > Lets get some real numbers in here. For a quick and dirty benchmark I'm > using OpenJPEG's MJ2 tools, I encode the speedway example using > "frames_to_mj2 -i Speedway.yuv -o Speedway.mj2 -I 1", then decode it. > I'm measuring the decode time. Tests were performed on a Mobile Celeron > 1.3, which is P3 architecture. > > Here it is with -march=i386 -mcpu=generic. That is, standard Fedora > flags: > > Total decoding time: 21.14 seconds (9.5 fps) > > With -march=i586 -mcpu=generic: > > Total decoding time: 21.26 seconds (9.4 fps) > > And -march=i686 -mcpu=generic: > > Total decoding time: 20.45 seconds (9.8 fps) > > So it is 0.54% *slower* when compiled for i586, which is unexpected and > strange, but such is gcc. I wouldn't expect much of a speed difference > compiling for i586, there was no major additions to the instruction set, > and we're already scheduling for modern processors. > > Not quite "three times" faster, but 3.26% faster with i686. A major > addition to the i686 architecture was cmov, and gcc is actually very > aggressive about eliminating branching using cmovs, increasing > performance on modern deeply pipelined processors by eliminating > pipeline stalls. > > And yes, cmov is technically optional, earlier VIA C3 processors, still > being sold, lack it. Completely dropping support for pre-i686 just isn't > an option yet. > > If Smolt is to be believed, i686 machines are 99.43% (!) of all x86 > machines. (Though I don't know if those pesky C3's are being counted as > i686 or i586 or what...) I think its safe to say the vast majority of > x86 systems out there have cmov, and are suffering with reduced > performance in order to cater to a minority of systems. > > I suggest all key performance critical packages be made available in > both i386 and i686 versions. glibc and openssl already do this. Off the > top of my head, this would include Mesa, I know for a fact the majority > of Second Life runtime is actually consumed by T&L inside Mesa/DRI. From > what I understand, even Intel's latest chipsets lack hardware T&L. Makes > sense, it helps sell more multi-core Intel processors, and probably > helps consolidate power management. > > Also, all multimedia codecs. Old sub-Ghz machines have a lot of trouble > playing the MPEG4 video that is common these days, and MythTV could use > all the help it can get. Not that the MPEG4 codecs are in Fedora > itself... > > Not that any of this has anything to do with the "firefox startup is > slow" complaint that this thread has devolved into. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > I have no idea, why Firefox 3 starts in Fedora so long and scrolls in smooth mode so long (with hanging for a while). Maybe it's Mesa compilation issue. Xorg? I don't know. I can only say that I want Fedora to be stable as rock, powerful and beautiful. No matter how we can do it. I sad my words few times and did nothing, it's true, but it's because I didn't know what I could really do. About compilation: preloading is probably making everything in openSUSE load faster, but how to implement this in Fedora? I'll invesigate where's their SVN/CVS/GIT/MNT/etc. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan at redhat.com Mon Jan 14 20:38:01 2008 From: alan at redhat.com (Alan Cox) Date: Mon, 14 Jan 2008 15:38:01 -0500 Subject: compilation architecture In-Reply-To: <1200341643.5433.81.camel@localhost> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <1200341643.5433.81.camel@localhost> Message-ID: <20080114203801.GA15725@devserv.devel.redhat.com> On Mon, Jan 14, 2008 at 02:14:02PM -0600, Callum Lerwick wrote: > using OpenJPEG's MJ2 tools, I encode the speedway example using > "frames_to_mj2 -i Speedway.yuv -o Speedway.mj2 -I 1", then decode it. Which is about the most extreme case you will find. > So it is 0.54% *slower* when compiled for i586, which is unexpected and > strange, but such is gcc. I wouldn't expect much of a speed difference > compiling for i586, there was no major additions to the instruction set, > and we're already scheduling for modern processors. 586 has completely different scheduling pipelines wiht complex rules > Not quite "three times" faster, but 3.26% faster with i686. A major > addition to the i686 architecture was cmov, and gcc is actually very Current CPUs cmov is generally a lose. > both i386 and i686 versions. glibc and openssl already do this. Off the > top of my head, this would include Mesa, I know for a fact the majority Mesa already internally uses things like 3DNow. The Mesa folks would I'm sure welcome more optimised paths and cpu tuned variants. > all the help it can get. Not that the MPEG4 codecs are in Fedora > itself... MPEG4 is dominated by memory bandwidth so cache size is critical and FSB, not compiler options. Memory actually dominates most things today - and -Os is often the macro scale win From jakub.rusinek at gmail.com Mon Jan 14 20:38:56 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Mon, 14 Jan 2008 21:38:56 +0100 Subject: Preloading [WAS: Re: SuSE Project SUPER] In-Reply-To: <478BC343.3070309@gmail.com> References: <5e92ee3f0801121432qcf7287cx2982deafafe0674c@mail.gmail.com> <3adc77210801131634q41296a6br5fd5c3f444f98588@mail.gmail.com> <478ACD3C.6070106@redhat.com> <604aa7910801132244t15fbfdecg52c39f12b402406@mail.gmail.com> <478B09BC.5080204@gmail.com> <20080114185714.GA30554@jadzia.bu.edu> <478BC343.3070309@gmail.com> Message-ID: <5e92ee3f0801141238h40c032e9t8f36feacf9fce1c5@mail.gmail.com> 2008/1/14, Andrew Farris : > > Matthew Miller wrote: > > On Sun, Jan 13, 2008 at 11:05:32PM -0800, Andrew Farris wrote: > >> Uhm, yeah you're right. But it will help those who actually use the > >> distribution rather than toss it aside based off bad information they > got > >> from someone else. There is certainly time and place to consider user > >> first impressions, but I hardly think its a good idea to filter an idea > >> like the above by ONLY that consideration. > > > > I dunno. It seems like optimizing for startup time seems a misguided if > > that's your goal. Starting stuff is a very low percentage of actual use, > > especially with suspend/hibernate. > > I'm aware its fairly low usage time, and not suggesting that any startup > optimization options be made at the cost of others (quite the > opposite...). > What I was suggesting was that cached or otherwise optimized startup times > are > nicer than slow ones, and it would not be wasted effort if some > improvements > were made there. I like OSX's performance in that way alot. > > So I wouldn't call it misguided, just lower priority. It sounds like you > would > agree with me that no start time optimizations should have detrimental > impact on > performance the rest of the time though. I would not want startup > performance > caching to be going on while I'm trying to play a game for instance. > > -- > Andrew Farris > gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B > 1DF3 > No one now has, and no one will ever again get, the big picture. - Daniel > Geer > ---- > ---- > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Disabling unused services is the first step :> . But hey, there's no second step :> . We should just make something with Fedora to make it load and work faster... -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at silug.org Mon Jan 14 20:40:14 2008 From: steve at silug.org (Steven Pritchard) Date: Mon, 14 Jan 2008 14:40:14 -0600 Subject: Start/stop of OpenVPN interfaces with ifup/ifdown In-Reply-To: <1200256413.2647.53.camel@shinybook.infradead.org> References: <200801112338.m0BNcflD031668@jasmine.xos.nl> <1200256413.2647.53.camel@shinybook.infradead.org> Message-ID: <20080114204014.GA18444@osiris.silug.org> On Sun, Jan 13, 2008 at 08:33:33PM +0000, David Woodhouse wrote: > On Sat, 2008-01-12 at 00:38 +0100, Jos Vos wrote: > > - Is there a technical reason to not handle OpenVPN connections this > > way in Fedora or is it just that it was decided to stay more close > > to the generic OpenVPN startup script? A combination of trying to stay close to upstream and lack of time, honestly. > > - Does anyone know of recent work in this area? I guess the example > > scripts in the thread I listed above might not work as-is with the > > current Fedora and OpenVPN versions. > > > > - Is there any interest in including (and maintaining) this in Fedora's > > OpenVPN package, maybe just as an alternative startup method, > > assuming someone wants to contribute the initial implementation? I'd be happy to include better initscript integration in the Fedora package. I just haven't had the time (or sufficient motivation) to write the code myself. > Please do. I believe it should have been a condition of the initial > review of the package. We're supposed to be making a coherent > distribution, not just packaging up a bunch of software and chucking it > together on a DVD. It was brought up at the time, but everyone was saying NetworkManager was going to take over the world, so making ifup/ifdown work didn't seem like a terribly high priority. NetworkManager-openvpn has been around for a while... Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)624-4440 Mobile: (618)567-7320 From ajackson at redhat.com Mon Jan 14 21:05:35 2008 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 14 Jan 2008 16:05:35 -0500 Subject: compilation architecture In-Reply-To: <1200341643.5433.81.camel@localhost> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <1200341643.5433.81.camel@localhost> Message-ID: <1200344735.15130.257.camel@localhost.localdomain> On Mon, 2008-01-14 at 14:14 -0600, Callum Lerwick wrote: > I suggest all key performance critical packages be made available in > both i386 and i686 versions. glibc and openssl already do this. Off the > top of my head, this would include Mesa, I know for a fact the majority > of Second Life runtime is actually consumed by T&L inside Mesa/DRI. From > what I understand, even Intel's latest chipsets lack hardware T&L. Makes > sense, it helps sell more multi-core Intel processors, and probably > helps consolidate power management. 915 does not have hardware vertex programs. 965 does though. 915 only has fragment programs, which makes sense since that's the most bang for the buck. 965 has both simply because it's a unified shader architecture. It's not really a power management or a sales decision either way, it's just what was easiest to build at the time. Our Mesa builds already include 586+ assembly for many routines, selected at runtime by processor inspection. I don't think they're using anything newer than SSE2 yet, there might be something to be gained from the newer ISA extensions. Patches gratefully accepted. If you want to see if there's any benefit from an i686 Mesa build just check it out from CVS and make local. Last time I looked the difference was down in the noise region. - ajax From chasd at silveroaks.com Mon Jan 14 21:03:59 2008 From: chasd at silveroaks.com (chasd) Date: Mon, 14 Jan 2008 15:03:59 -0600 Subject: Preloading [WAS: Re: SuSE Project SUPER] In-Reply-To: <20080114112723.6729A73712@hormel.redhat.com> References: <20080114112723.6729A73712@hormel.redhat.com> Message-ID: Linus Walleij wrote: > Agreed, what "other" OS:es (Vista, MacOS X) do is to come pre- > installed, > i.e. it was booted once by a technician out of sight of the user. Then > they leverage on that. OS X is pre-installed, but not boot-optimized. The OS is a standard image like most other pre-installed OS's. The first boot by the end user creates an ordered, compressed archive of the specific kernel modules for the exact hardware available. Sort of like an initrd ;) However, after the configuration the system doesn't reboot, you are presented with the configured system running. The user gets all the shiny without suffering a first boot first. One thing OS X attempts to do is for any file ( system _or_ user ) < 20 MB, it consolidates all the blocks for that file on disk to decrease seeks. It does this in the background when the system is idle. This speeds up booting, opening apps, and loading ( most ) files into apps. Vista in my experience is pre-installed but not optimized either. It goes through a lengthy "determining the performance of your system" - I guess to decide what kind of interface to display. It too switches to a running system without a reboot ( unlike XP ) so again the end user does not experience a cold boot to wait through to use the system. There is much thrashing of the disk for the first few days of Vista use as it tries to figure out how to optimize for what the end user is doing. Installs of either from optical media is a different experience, and more like installing Linux with a reboot at the end. However most users never experience that. Both OS X and Vista have data file search indexing that causes slow behavior until the user's files are indexed. That particular slow- down was not included by default in Fedora a release or two ago. The best-guess optimization for an end user won't be the best optimization for the _first_ use. What a user does in the first few days of use is generally much different from what the user does after the system is configured and the user establishes a routine. To me that means optimizing for a reviewer is orthogonal if not 180 degrees from the the best optimization for a "normal" end user, whatever that is determined to be. I personally dislike waiting for preloading, because I don't do the same thing in the same order every day. But I know I'm weird. Charles Dostale From loganjerry at gmail.com Mon Jan 14 21:10:53 2008 From: loganjerry at gmail.com (Jerry James) Date: Mon, 14 Jan 2008 14:10:53 -0700 Subject: Intel compiler integration tool release In-Reply-To: <1200099018.3853.1.camel@localhost.localdomain> References: <870180fe0801111237q1ffc1f24p265d8e06ddcbcc19@mail.gmail.com> <1200099018.3853.1.camel@localhost.localdomain> Message-ID: <870180fe0801141310j5140baa2g1774c3751a09cfc4@mail.gmail.com> Hi Kjartan, On Jan 11, 2008 5:50 PM, Kjartan Maraas wrote: > Do I need to install icc in a particular prefix for this package to pick > it up? I just did a default install of icc 10.1 and I don't see how to > use your package to invoke it? Yes, you do need to install in the default place (/opt/intel). Making that configurable will have to wait for a future release, assuming I ever get around to it. Once you have installed the Intel tools and my package, run intel-update as root. After that, you should see the icc, icpc, idb, etc. binaries in your PATH, get something useful out of "man icc", etc. Let me know if you need any further information. Regards, -- Jerry James http://loganjerry.googlepages.com/ From dhollis at davehollis.com Mon Jan 14 21:12:00 2008 From: dhollis at davehollis.com (David Hollis) Date: Mon, 14 Jan 2008 16:12:00 -0500 Subject: Start/stop of OpenVPN interfaces with ifup/ifdown In-Reply-To: <20080114204014.GA18444@osiris.silug.org> References: <200801112338.m0BNcflD031668@jasmine.xos.nl> <1200256413.2647.53.camel@shinybook.infradead.org> <20080114204014.GA18444@osiris.silug.org> Message-ID: <1200345120.6252.5.camel@dhollis-lnx.sunera.com> On Mon, 2008-01-14 at 14:40 -0600, Steven Pritchard wrote: > It was brought up at the time, but everyone was saying NetworkManager > was going to take over the world, so making ifup/ifdown work didn't > seem like a terribly high priority. NetworkManager-openvpn has been > around for a while... > Though it seemed abandoned at some point in time and the last time I checked, it didn't support some options that I use in my config namely 'tls-auth/tls-remote'. Maybe it's interface needs some simple option to add 'custom' name/value pairs that get passed to the openvpn program to allow for future enhancements or local customizations and such. -- David Hollis From darrellpf at gmail.com Mon Jan 14 21:19:22 2008 From: darrellpf at gmail.com (darrell pfeifer) Date: Mon, 14 Jan 2008 13:19:22 -0800 Subject: X broken in rawhide? Message-ID: I updated a couple of machines that were "week old" rawhide to latest rawhide. On both machines, X wouldn't start. The log file said it couldn't find a display 0, apparently because the driver is not the correct version. One machine is a desktop with nv driver, the other is a laptop with intel driver. The workaround for me was to restore an earlier version of X. I haven't seen anyone else reporting X problems. Is there something I've missed? darrell -------------- next part -------------- An HTML attachment was scrubbed... URL: From orion at cora.nwra.com Mon Jan 14 21:34:34 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 14 Jan 2008 14:34:34 -0700 Subject: Slip of Alpha In-Reply-To: <20080114140358.05d19b3b@redhat.com> References: <20080114140358.05d19b3b@redhat.com> Message-ID: <478BD56A.7070207@cora.nwra.com> Jesse Keating wrote: > Today Release Engineering with input from QA has decided to slip the > alpha release by a week. The current state of rawhide and the > inability to install rawhide for many weeks now does not give us > confident in a successful Alpha. We're giving the installer team an > extra week to fix things up so that we have a better chance at a wide > Alpha use. Releng/QA will revisit again next week during the release > engineering meeting to give a go/no-go vote on enacting the freeze for > Alpha. I can't install because of https://bugzilla.redhat.com/show_bug.cgi?id=428203 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From jos at xos.nl Mon Jan 14 21:53:12 2008 From: jos at xos.nl (Jos Vos) Date: Mon, 14 Jan 2008 22:53:12 +0100 Subject: Start/stop of OpenVPN interfaces with ifup/ifdown In-Reply-To: <20080114204014.GA18444@osiris.silug.org> References: <200801112338.m0BNcflD031668@jasmine.xos.nl> <1200256413.2647.53.camel@shinybook.infradead.org> <20080114204014.GA18444@osiris.silug.org> Message-ID: <20080114215312.GA9371@jasmine.xos.nl> On Mon, Jan 14, 2008 at 02:40:14PM -0600, Steven Pritchard wrote: > I'd be happy to include better initscript integration in the Fedora > package. I just haven't had the time (or sufficient motivation) to > write the code myself. I'll look at the existing examples and make a proposal. I need it now myself, so we can better include it mainstream then ;-). In the past I wrote some ifup/ifdown scripts for my own FreeS/WAN extensions to RHL, which was a horrible job (and it stayed more or less an incomplete hack), but I'm sure for OpenVPN it's much simpler. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From drago01 at gmail.com Mon Jan 14 22:21:01 2008 From: drago01 at gmail.com (drago01) Date: Mon, 14 Jan 2008 23:21:01 +0100 Subject: compilation architecture In-Reply-To: <1200341643.5433.81.camel@localhost> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <1200341643.5433.81.camel@localhost> Message-ID: 2008/1/14 Callum Lerwick : > > Also, all multimedia codecs. Old sub-Ghz machines have a lot of trouble > playing the MPEG4 video that is common these days, and MythTV could use > all the help it can get. Not that the MPEG4 codecs are in Fedora > itself... > Most (all) mpeg4 en-/decoders use hand written asm with runtime cpu detection so adding compiler flags won't gain anything there. From atkac at redhat.com Mon Jan 14 22:26:58 2008 From: atkac at redhat.com (Adam Tkac) Date: Mon, 14 Jan 2008 23:26:58 +0100 Subject: Preloading [WAS: Re: SuSE Project SUPER] In-Reply-To: <478B6F4F.7020904@gmail.com> References: <5e92ee3f0801121006x7c1b73d5tc3d990812f240e2c@mail.gmail.com> <47893D75.1000406@redhat.com> <5e92ee3f0801121432qcf7287cx2982deafafe0674c@mail.gmail.com> <3adc77210801131634q41296a6br5fd5c3f444f98588@mail.gmail.com> <478ACD3C.6070106@redhat.com> <604aa7910801132244t15fbfdecg52c39f12b402406@mail.gmail.com> <1200296346.5433.10.camel@localhost> <478B6F4F.7020904@gmail.com> Message-ID: <20080114222658.GA4835@traged.englab.brq.redhat.com> On Mon, Jan 14, 2008 at 08:18:55AM -0600, Les Mikesell wrote: > Callum Lerwick wrote: >> The whole idea of preloading is crackrock. Its just hiding the problem, >> at best. >> >> The problem is the relentless march of bloat. >> > > One person's bloat is someone else's most needed feature - and there's not > a big problem these days with disk space to store unused options. The > problem is that the programs, their shared libraries, and config files are > splattered all over the disk and seeking to access them is much slower than > any other computer operation. There has to be some trick that could be > used either to pre-arrange all the files used in the boot process together > or load something early to pull in all of the shared libs in a certain > order, or have them preloaded in a swapfile or something. If you change > the goal to reducing disk seeks instead of specifically preloading files it > might be easier to accomplish a speedup. > >From my point of view Callum has dead right. If I remember to Fedora Core 4 or 5 it was significantly faster that F8. I remember day when I turned off Compiz (maybe in F6) and said "Yeah, this is pretty fast". Now I'm back in Compiz days but without Compiz. I don't think disk usage is main problem (but in some cases yes - command yum update always bother me in this case) generally. It looks like code become slower and slower. And last team of really good programmers stucks with improvements like preloading or compiler optimization. I'm not against features. But We really should not add features and improve stability without care about code speed and quality. Looks like I have to switch from gnome to blackbox or fluxbox. This will solve my problem. For now. And after two years I will start using runlevel 3 by default... Adam -- Adam Tkac, Red Hat, Inc. From cjdahlin at ncsu.edu Mon Jan 14 22:27:45 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Mon, 14 Jan 2008 17:27:45 -0500 Subject: Deleting a file/directory on startup In-Reply-To: <200801142047.53471.opensource@till.name> References: <200801111852.08733.opensource@till.name> <200801112003.44324.opensource@till.name> <1200339044.2884.1.camel@sb-home> <200801142047.53471.opensource@till.name> Message-ID: <478BE1E1.5080405@ncsu.edu> Till Maas wrote: > On Mon January 14 2008, nodata wrote: > > >> The directory that stores these files should be wiped at boot or on >> shutdown.. >> > > Yes, this is where I search the best way to do this, except that I want that a > directory is deleted. rc.sysinit does this only for some directories > in /var/{run,lock}, e.g. for vmware. > > Regards, > Till > The most correct way is to put some content in the lockfile to allow it to be determined if it is valid. Then pm-utils itself can figure it out when its run. --CJD From dpquigl at tycho.nsa.gov Mon Jan 14 22:18:16 2008 From: dpquigl at tycho.nsa.gov (Dave Quigley) Date: Mon, 14 Jan 2008 17:18:16 -0500 Subject: Remastering an FC8 Livecd In-Reply-To: <478BB081.7000900@filteredperception.org> References: <1200335813.25017.13.camel@moss-terrapins.epoch.ncsc.mil> <478BB081.7000900@filteredperception.org> Message-ID: <1200349096.25017.23.camel@moss-terrapins.epoch.ncsc.mil> Hello, Thanks for the help. For some odd reasons the searches I was doing didn't come up with it. Probably because I was tossing remastering in the mix. Dave On Mon, 2008-01-14 at 12:57 -0600, Douglas McClendon wrote: > Dave Quigley wrote: > > Hello, > > I am submitting a proposal for OLS this year for a tutorial session > > for SELinux. I figure the easiest way to get everyone a system with all > > the necessary SELinux packages is to make a livecd containing it all. I > > was wondering who is in charge of the Fedora livecd effort and what > > resources are there to get started on building Fedora livecds? > > > > Dave > > > > second hit on google://"fedora livecd" > > http://fedoraproject.org/wiki/FedoraLiveCD > > -dmc > From dcbw at redhat.com Mon Jan 14 22:51:47 2008 From: dcbw at redhat.com (Dan Williams) Date: Mon, 14 Jan 2008 17:51:47 -0500 Subject: Start/stop of OpenVPN interfaces with ifup/ifdown In-Reply-To: <1200345120.6252.5.camel@dhollis-lnx.sunera.com> References: <200801112338.m0BNcflD031668@jasmine.xos.nl> <1200256413.2647.53.camel@shinybook.infradead.org> <20080114204014.GA18444@osiris.silug.org> <1200345120.6252.5.camel@dhollis-lnx.sunera.com> Message-ID: <1200351107.3195.10.camel@localhost.localdomain> On Mon, 2008-01-14 at 16:12 -0500, David Hollis wrote: > On Mon, 2008-01-14 at 14:40 -0600, Steven Pritchard wrote: > > > It was brought up at the time, but everyone was saying NetworkManager > > was going to take over the world, so making ifup/ifdown work didn't > > seem like a terribly high priority. NetworkManager-openvpn has been > > around for a while... > > > > > Though it seemed abandoned at some point in time and the last time I > checked, it didn't support some options that I use in my config namely > 'tls-auth/tls-remote'. > > Maybe it's interface needs some simple option to add 'custom' name/value > pairs that get passed to the openvpn program to allow for future > enhancements or local customizations and such. That's part of the problem. OpenVPN has so many options that adding everything to a dialog really isn't going to work. That may be a symptom of OpenVPN's feature-creep and attempt to work in every conceivable situation, which makes it less and less easy to actually set up, but I digress. (note also vpnc 0.4's addition of application-version, no-encryption, pfs, natt-mode, etc). There are so many obscure options that at least one person needs that there's no way either OpenVPN or vpnc will ever Just Work for the user. They basically require a sysadmin or somebody who really knows what they are doing to set up the VPN for them, which sucks. That said, allowing options not handled in the GUI bits to be added is probably the something that should be done; but it needs to be done in such a way that if the option is sanely added to the GUI later on, that it supersedes the custom-option-entry bit. I'm also a bit reluctant to take out the option filter/validator for VPN methods that don't support config-on-stdin, because passing random text on the command line is a security risk. About the last thing we want to be doing is executing a root process with random arguments entered by some trojan that stuffed values into GConf. Dan From triad at df.lth.se Tue Jan 15 01:39:16 2008 From: triad at df.lth.se (Linus Walleij) Date: Tue, 15 Jan 2008 02:39:16 +0100 (CET) Subject: X broken in rawhide? In-Reply-To: References: Message-ID: On Mon, 14 Jan 2008, darrell pfeifer wrote: > I haven't seen anyone else reporting X problems. Is there something I've > missed? I've seen X upgrades wiping out the ModulePath sections in /etc/X11/xorg.conf for me. I've been thinking to file a bug but haven't got around to until now. https://bugzilla.redhat.com/show_bug.cgi?id=428769 If you have a custom driver or so, this affects you. Linus From triad at df.lth.se Tue Jan 15 01:45:45 2008 From: triad at df.lth.se (Linus Walleij) Date: Tue, 15 Jan 2008 02:45:45 +0100 (CET) Subject: Preloading [WAS: Re: SuSE Project SUPER] In-Reply-To: References: <20080114112723.6729A73712@hormel.redhat.com> Message-ID: On Mon, 14 Jan 2008, chasd wrote: > The best-guess optimization for an end user won't be the best optimization > for the _first_ use. What SuSE actually do is optimize for a "generic" use case. In essence, they preload the display managers, Firefox and OpenOffice. And they get these program starts much more responsive as a result. It will be pointless for users using neither program (well we all have the display managers), of course. (I guess I would personalize it to preload emacs and gnome-terminal but that's just me...) Linus From rrankin at ihug.com.au Tue Jan 15 04:33:49 2008 From: rrankin at ihug.com.au (Roy Rankin) Date: Tue, 15 Jan 2008 15:33:49 +1100 Subject: Boot fails with "No Setup Signature" after update following YumUpdateFaq Message-ID: <478C37AD.4010201@ihug.com.au> The Problem: I recently upgraded a system from Fedora Core 6 to Fedora 8 using the YumUpdateFaq as a guide. When I tried to reboot the system with kernel 2.6.23.9-85.fc8 the system hung in the boot process with the message "No Setup Signature". However I could boot the system with kernel 2.6.22.14-72.fc6. The investigation: I tried reinstalling the kernel without success. I found on a mailing list a case where this problem was fixed by running grub-install. When I did this it also resolved my problem. I also remembered there has a note in the YumUpdateFaq about possibly needing to do this with a TODO note by Mads Kiilerich asking when this was required. I contacted Mads, who acted as a sounding board as I investigated why I needed to run grub-install. I determined by running "less -f /boot/grub/stage2" on a backup taken before I ran grub-install that the version of the GRUB files in /boot/grub was 0.92 whereas the current GRUB version, since Fedora Core 5, is 0.97. I determined that when YUM/RPM upgrades or installs GRUB, the files in /boot/grub do not get updated. This only happens when grub-install is run. When the system is upgraded from CD/DVD, Anaconda runs grub-install, although this can be bypassed. I had updated the system several times up to Fedora Core 6 using CD/DVD but skipped the GRUB update part of the install. To run grub-install in Fedora 8 (or 7) it is necessary that /boot/grub/device.map has the new drive device naming. This file, which is created by Anaconda, needs to be modified from "(hd0) /dev/hda" to "(hd0) /dev/sda" if it was created in Fedora core 6 or earlier. The Solution: Mads and I came up with the following changes to the YumUpdateFaq. 1> In section 4 "Do the upgrade", the following was added Before booting you should usually install the bootloader from your new grub by running * grub-install BOOTDEVICE - where BOOTDEVICE usually is /dev/sda 2> To the end of the first paragraph under "Fedora Core 6->Fedora 7" discussing the IDE drive device name change, the following was added. In /boot/grub/device.map change /dev/hd.. to /dev/sd.. before running grub-install - and don't change (hd0). Changing /boot/grub/grub.conf may also be required. Regards, Roy Rankin From luya_tfz at thefinalzone.com Tue Jan 15 04:42:34 2008 From: luya_tfz at thefinalzone.com (Luya Tshimbalanga) Date: Mon, 14 Jan 2008 20:42:34 -0800 Subject: Icons status for smolts.org Message-ID: <478C39BA.2030801@thefinalzone.com> Hi Mike, I read the wiki about icons status for smolts.org. You can use icons from echo-icon-theme[1] under Actions menu and I have linked them on DesignService wiki page[2]. Luya References: [1]https://fedorahosted.org/echo-icon-theme/wiki/IconThemeStatus [2]http://fedoraproject.org/wiki/Artwork/DesignService From jonstanley at gmail.com Tue Jan 15 04:46:36 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Mon, 14 Jan 2008 23:46:36 -0500 Subject: Fedora bug triage - workflow proposal Message-ID: Well, it was a great session at FUDCon. A lot came out of it, and I'm going to put some of them down here. The work flow suggested below I'd a FESco vote on, since it really affects you guys. This work flow was discussed between myself, John Poelstra, and Will Woods at the Sunday hackfest, and we agree that this is the correct way to move forward, however, we want community input and buy-in on this, since it has pretty far-reaching consequences. Here is the lifecycle of a bug: 1) Reporter files a bug report, it originates in NEW state 2) Triage team looks at bug report, determines if dupe or insufficient information exists to solve it. If there is not enough information in the bug, then triage team puts the bug in NEEDINFO. As you will see below, this state has a finite life cycle associated with it. 3) Assuming bug survives through the triage team, it changes state to ASSIGNED (triage team can put it in either NEEDINFO or CLOSED, as appropriate). Note that per the definition[1], ASSIGNED does not mean that someone has actually agreed to take action, simply that the issue is well defined and triaged accordingly 4) Once a developer has taken responsibility for a bug and is actively working on it, the state transitions to ON_DEV. 5) Once an update addressing a bug exists in Bodhi, and is pushed to updates-testing, the status automatically transitions to ON_QA 6) When the update is pushed to stable, Bodhi optionally closes the bug automatically. If the update does not auto-close the bug, it transitions to NEEDINFO_REPORTER, with a comment explaining that the update has been pushed to stable, and to update and test in the new release. Note that at any step of the above process, the maintainer can "fast track" the bug, and change it to ASSIGNED. The triage team is not going to look at bugs that are not in NEW or NEEDINFO state. On the flip side of that, it is not a maintainer's responsibility to look at bugs that are in NEW any longer. They can focus their energy on the bugs that are ASSIGNED to them. Also, maintainers should not be allowed to set priority on bugs. Setting severity is fine. Only QA or releng should set priorities. This allows us to look at things in a sane manner (which is impossible now since severity and priority fields come from /dev/urandom seemingly), and possibly lessen the reliance on blocker bugs (though blockers are useful in their own right, so don't think that we are going to eliminate them any time soon). It was also decided that when a bug is in NEEDINFO for one month, it will be closed. Maintainers would need to realize that putting a bug in NEEDINFO is putting it on the fast track for closure. I think that's all that I have to say on this topic right now, let me know if I'm missing anything or this is complete hogwash :) -Jon [1] https://bugzilla.redhat.com/page.cgi?id=bug_status.html#verified From rhally at mindspring.com Tue Jan 15 08:03:56 2008 From: rhally at mindspring.com (Richard Hally) Date: Tue, 15 Jan 2008 03:03:56 -0500 Subject: anaconda - unhandled exception Message-ID: <478C68EC.6030201@mindspring.com> Running the boot.iso from rawhide (dated 1/14/08 8:12) to do a network install produces an "unhandled exception" while in the "retrieving installation information" phase (after formating the disk). In the screen to save the bug or debug information, the local disk is grayed out so nothing could be saved. what now? Richard From mschwendt.tmp0701.nospam at arcor.de Tue Jan 15 08:11:54 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 15 Jan 2008 09:11:54 +0100 Subject: rpms/sepostgresql/devel postgresql-8.2.6.tar.gz, NONE, 1.1 .cvsignore, 1.4, 1.5 sepostgresql.init, 1.8, 1.9 sepostgresql.spec, 1.8, 1.9 sepostgresql.te, 1.8, 1.9 In-Reply-To: <478B890B.2070005@kaigai.gr.jp> References: <200801101437.m0AEbemG002515@cvs-int.fedora.redhat.com> <1199983507.3398.14.camel@localhost.localdomain> <20080114120951.4c9df209.mschwendt.tmp0701.nospam@arcor.de> <478B724F.4010002@kaigai.gr.jp> <20080114155558.83443828.mschwendt.tmp0701.nospam@arcor.de> <478B890B.2070005@kaigai.gr.jp> Message-ID: <20080115091154.a99c1fb2.mschwendt.tmp0701.nospam@arcor.de> On Tue, 15 Jan 2008 01:08:43 +0900, KaiGai Kohei wrote: > I've fixed them with the above processes. > If possible, please confirm it. Yes, the binaries are gone now. Good. You could also remove the old patch files, which are no longer used in your package. From pmatilai at laiskiainen.org Tue Jan 15 08:40:25 2008 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Tue, 15 Jan 2008 10:40:25 +0200 (EET) Subject: xargs generates too long argument lists on i686 In-Reply-To: <200801141243.m0EChTgO016238@laptop13.inf.utfsm.cl> References: <200801141243.m0EChTgO016238@laptop13.inf.utfsm.cl> Message-ID: On Mon, 14 Jan 2008, Horst H. von Brand wrote: > For some time now, each time I try to build an RPM it fails with something > like: > > + /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot > xargs: /usr/lib/rpm/check-rpaths-worker: Argument list too long > error: Bad exit status from /var/tmp/rpm-tmp.39544 (%install) > > This I have traced back to xargs(1) generating huge argument lists, which > the called command can't handle. Doing a "make clean" in a self-built > kernel gives the same type of grief (I tweaked the Makefile there to call > xargs with "-L 2000" to get it to work). > > I wonder how everybody else here is able to get anything done... Easy workaround: just remove the rpath check from ~/.rpmmacros (rpmdev-setuptree plants it there, it's not part of default rpm build setup otherwise). - Panu - From pertusus at free.fr Tue Jan 15 08:49:00 2008 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 15 Jan 2008 09:49:00 +0100 Subject: Fedora bug triage - workflow proposal In-Reply-To: References: Message-ID: <20080115084900.GA2691@free.fr> On Mon, Jan 14, 2008 at 11:46:36PM -0500, Jon Stanley wrote: > > It was also decided that when a bug is in NEEDINFO for one month, it > will be closed. Maintainers would need to realize that putting a bug > in NEEDINFO is putting it on the fast track for closure. So what is the equivalent of NEEDINFO that doesn't put the bug on tracks for closing? -- Pat From lordmorgul at gmail.com Tue Jan 15 08:49:09 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Tue, 15 Jan 2008 00:49:09 -0800 Subject: anaconda - unhandled exception In-Reply-To: <478C68EC.6030201@mindspring.com> References: <478C68EC.6030201@mindspring.com> Message-ID: <478C7385.80308@gmail.com> Richard Hally wrote: > Running the boot.iso from rawhide (dated 1/14/08 8:12) to do a network > install produces an "unhandled exception" while in the "retrieving > installation information" phase (after formating the disk). In the > screen to save the bug or debug information, the local disk is grayed > out so nothing could be saved. > > what now? > > Richard Wait for the next, this is in bugzilla already, see: https://bugzilla.redhat.com/show_bug.cgi?id=428709 -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From lordmorgul at gmail.com Tue Jan 15 08:53:05 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Tue, 15 Jan 2008 00:53:05 -0800 Subject: anaconda - unhandled exception In-Reply-To: <478C68EC.6030201@mindspring.com> References: <478C68EC.6030201@mindspring.com> Message-ID: <478C7471.3000905@gmail.com> Richard Hally wrote: > Running the boot.iso from rawhide (dated 1/14/08 8:12) to do a network > install produces an "unhandled exception" while in the "retrieving > installation information" phase (after formating the disk). In the > screen to save the bug or debug information, the local disk is grayed > out so nothing could be saved. I should have mentioned, its often possible in that situation with the installer to go to the shell on vt2 and mount a flash drive to copy error output. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From j.w.r.degoede at hhs.nl Tue Jan 15 09:06:56 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 15 Jan 2008 10:06:56 +0100 Subject: Fedora bug triage - workflow proposal In-Reply-To: References: Message-ID: <478C77B0.3070508@hhs.nl> Jon Stanley wrote: > Well, it was a great session at FUDCon. A lot came out of it, and I'm > going to put some of them down here. The work flow suggested below I'd > a FESco vote on, since it really affects you guys. This work flow was > discussed between myself, John Poelstra, and Will Woods at the Sunday > hackfest, and we agree that this is the correct way to move forward, > however, we want community input and buy-in on this, since it has > pretty far-reaching consequences. > > Here is the lifecycle of a bug: > > 1) Reporter files a bug report, it originates in NEW state > 2) Triage team looks at bug report, determines if dupe or > insufficient information exists to solve it. If there is not enough > information in the bug, then triage team puts the bug in NEEDINFO. As > you will see below, this state has a finite life cycle associated with > it. > 3) Assuming bug survives through the triage team, it changes state to > ASSIGNED (triage team can put it in either NEEDINFO or CLOSED, as > appropriate). Note that per the definition[1], ASSIGNED does not mean > that someone has actually agreed to take action, simply that the issue > is well defined and triaged accordingly > 4) Once a developer has taken responsibility for a bug and is > actively working on it, the state transitions to ON_DEV. > 5) Once an update addressing a bug exists in Bodhi, and is pushed to > updates-testing, the status automatically transitions to ON_QA > 6) When the update is pushed to stable, Bodhi optionally closes the > bug automatically. If the update does not auto-close the bug, it > transitions to NEEDINFO_REPORTER, with a comment explaining that the > update has been pushed to stable, and to update and test in the new > release. > > Note that at any step of the above process, the maintainer can "fast > track" the bug, and change it to ASSIGNED. The triage team is not > going to look at bugs that are not in NEW or NEEDINFO state. On the > flip side of that, it is not a maintainer's responsibility to look at > bugs that are in NEW any longer. They can focus their energy on the > bugs that are ASSIGNED to them. > > Also, maintainers should not be allowed to set priority on bugs. > Setting severity is fine. Only QA or releng should set priorities. > This allows us to look at things in a sane manner (which is impossible > now since severity and priority fields come from /dev/urandom > seemingly), and possibly lessen the reliance on blocker bugs (though > blockers are useful in their own right, so don't think that we are > going to eliminate them any time soon). > > It was also decided that when a bug is in NEEDINFO for one month, it > will be closed. Maintainers would need to realize that putting a bug > in NEEDINFO is putting it on the fast track for closure. > > I think that's all that I have to say on this topic right now, let me > know if I'm missing anything or this is complete hogwash :) > Sounds like an excellent plan to me, lets implement this asap! I would like to point out though that this solves only part of the problem. An important part, but I wonder if anything was discussed regarding the other part, unresponsive maintainers. I often see perfectly fine bugs (well described, reproducable) with 0 maintainer attention. I know we are all human but most of the time it are always the same maintainers who are unresponsive, and they seem to simply be unresponsive to any bugs. So its not that they are prioritizing, they seem to be simply ignoring bugzilla mail. I know we have the awol procedure for this, but often they are not awol, they are productive contributers, who's strengths lay outside of bugfixing. Thus I would like to see a bug fixing team, to complement the bug triage team who's task it will be to actually fix bugs which have moved to the assigned state. Now primarily this is the task of the maintainer, but sometimes leaving this up to the maintainer seems to not work one way or the other. So I guess it would be good to have a fallback bugfixing team, and maybe a way for packagers, who for example lack the coding skills, to subscribe to this team's services. As always I'll put my code where my mouth is and I will gladly join such a team if formed. Regards, Hans From rhally at mindspring.com Tue Jan 15 09:07:11 2008 From: rhally at mindspring.com (Richard Hally) Date: Tue, 15 Jan 2008 04:07:11 -0500 Subject: anaconda - unhandled exception In-Reply-To: <478C7385.80308@gmail.com> References: <478C68EC.6030201@mindspring.com> <478C7385.80308@gmail.com> Message-ID: <478C77BF.4060708@mindspring.com> Andrew Farris wrote: > Richard Hally wrote: >> Running the boot.iso from rawhide (dated 1/14/08 8:12) to do a network >> install produces an "unhandled exception" while in the "retrieving >> installation information" phase (after formating the disk). In the >> screen to save the bug or debug information, the local disk is grayed >> out so nothing could be saved. >> >> what now? >> >> Richard > > Wait for the next, this is in bugzilla already, see: > https://bugzilla.redhat.com/show_bug.cgi?id=428709 > thanks! I should have checked bugzy first. Richard From rhally at mindspring.com Tue Jan 15 09:08:48 2008 From: rhally at mindspring.com (Richard Hally) Date: Tue, 15 Jan 2008 04:08:48 -0500 Subject: anaconda - unhandled exception In-Reply-To: <478C7471.3000905@gmail.com> References: <478C68EC.6030201@mindspring.com> <478C7471.3000905@gmail.com> Message-ID: <478C7820.6030105@mindspring.com> Andrew Farris wrote: > Richard Hally wrote: >> Running the boot.iso from rawhide (dated 1/14/08 8:12) to do a network >> install produces an "unhandled exception" while in the "retrieving >> installation information" phase (after formating the disk). In the >> screen to save the bug or debug information, the local disk is grayed >> out so nothing could be saved. > > I should have mentioned, its often possible in that situation with the > installer to go to the shell on vt2 and mount a flash drive to copy > error output. > Thanks for the reminder about going to the VT. Richard From paul at all-the-johnsons.co.uk Tue Jan 15 09:45:06 2008 From: paul at all-the-johnsons.co.uk (paul) Date: Tue, 15 Jan 2008 09:45:06 +0000 Subject: X broken in rawhide? In-Reply-To: References: Message-ID: <1200390306.10860.0.camel@T7.Linux> Hi, > I haven't seen anyone else reporting X problems. Is there something > I've missed? The nv driver was bust about a week back, but it's happy now. TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! From sundaram at fedoraproject.org Tue Jan 15 10:12:09 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 15 Jan 2008 15:42:09 +0530 Subject: Fedora bug triage - workflow proposal In-Reply-To: <20080115084900.GA2691@free.fr> References: <20080115084900.GA2691@free.fr> Message-ID: <478C86F9.30405@fedoraproject.org> Patrice Dumas wrote: > On Mon, Jan 14, 2008 at 11:46:36PM -0500, Jon Stanley wrote: >> It was also decided that when a bug is in NEEDINFO for one month, it >> will be closed. Maintainers would need to realize that putting a bug >> in NEEDINFO is putting it on the fast track for closure. > > So what is the equivalent of NEEDINFO that doesn't put the bug on tracks > for closing? Can you explain why you need that? That information would be useful to determine a good workflow. Rahul From pertusus at free.fr Tue Jan 15 10:12:57 2008 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 15 Jan 2008 11:12:57 +0100 Subject: Fedora bug triage - workflow proposal In-Reply-To: <478C86F9.30405@fedoraproject.org> References: <20080115084900.GA2691@free.fr> <478C86F9.30405@fedoraproject.org> Message-ID: <20080115101257.GC2691@free.fr> On Tue, Jan 15, 2008 at 03:42:09PM +0530, Rahul Sundaram wrote: > Patrice Dumas wrote: >> On Mon, Jan 14, 2008 at 11:46:36PM -0500, Jon Stanley wrote: >>> It was also decided that when a bug is in NEEDINFO for one month, it >>> will be closed. Maintainers would need to realize that putting a bug >>> in NEEDINFO is putting it on the fast track for closure. >> >> So what is the equivalent of NEEDINFO that doesn't put the bug on tracks >> for closing? > > Can you explain why you need that? That information would be useful to > determine a good workflow. When I have a look at a number of bugs (for example my bugs) it allows for me to know which ones I don't have to care about since they are in wait for somebody to move. -- Pat From pertusus at free.fr Tue Jan 15 10:15:49 2008 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 15 Jan 2008 11:15:49 +0100 Subject: Fedora bug triage - workflow proposal In-Reply-To: <478C77B0.3070508@hhs.nl> References: <478C77B0.3070508@hhs.nl> Message-ID: <20080115101549.GD2691@free.fr> On Tue, Jan 15, 2008 at 10:06:56AM +0100, Hans de Goede wrote: >> > > Sounds like an excellent plan to me, lets implement this asap! > > I would like to point out though that this solves only part of the problem. > An important part, but I wonder if anything was discussed regarding the > other part, unresponsive maintainers. I often see perfectly fine bugs (well > described, reproducable) with 0 maintainer attention. I know we are all Even worse, there are trivial packaging changes needed as part of new guidelines, for example, that are not fixed after months, even with (trivial) patches attached. I don't know what should be done for that, but this is a bit irritating. -- Pat From dhollis at davehollis.com Tue Jan 15 10:24:50 2008 From: dhollis at davehollis.com (David Hollis) Date: Tue, 15 Jan 2008 05:24:50 -0500 Subject: Start/stop of OpenVPN interfaces with ifup/ifdown In-Reply-To: <1200351107.3195.10.camel@localhost.localdomain> References: <200801112338.m0BNcflD031668@jasmine.xos.nl> <1200256413.2647.53.camel@shinybook.infradead.org> <20080114204014.GA18444@osiris.silug.org> <1200345120.6252.5.camel@dhollis-lnx.sunera.com> <1200351107.3195.10.camel@localhost.localdomain> Message-ID: <1200392691.13445.6.camel@dhollis-lnx.sunera.com> On Mon, 2008-01-14 at 17:51 -0500, Dan Williams wrote: > On Mon, 2008-01-14 at 16:12 -0500, David Hollis wrote: > > On Mon, 2008-01-14 at 14:40 -0600, Steven Pritchard wrote: > > > > > It was brought up at the time, but everyone was saying NetworkManager > > > was going to take over the world, so making ifup/ifdown work didn't > > > seem like a terribly high priority. NetworkManager-openvpn has been > > > around for a while... > > > > > > > > > Though it seemed abandoned at some point in time and the last time I > > checked, it didn't support some options that I use in my config namely > > 'tls-auth/tls-remote'. > > > > Maybe it's interface needs some simple option to add 'custom' name/value > > pairs that get passed to the openvpn program to allow for future > > enhancements or local customizations and such. > > That's part of the problem. OpenVPN has so many options that adding > everything to a dialog really isn't going to work. That may be a > symptom of OpenVPN's feature-creep and attempt to work in every > conceivable situation, which makes it less and less easy to actually set > up, but I digress. (note also vpnc 0.4's addition of > application-version, no-encryption, pfs, natt-mode, etc). There are so > many obscure options that at least one person needs that there's no way > either OpenVPN or vpnc will ever Just Work for the user. They basically > require a sysadmin or somebody who really knows what they are doing to > set up the VPN for them, which sucks. > Plus some folks may compile in different options and such (like NTLM support or something). In my org, I administer the OpenVPN configuration used and I have a standard config file that I blow out to users with specific client certs. Unfortunately, I the NM-openvpn component doesn't allow me to just import that file, or link right to it so I have to manually add the config information to the client. It would seem that it wouldn't be to horrible for the cfg tool to be able to import a config and to just have a name/value grid kind of thing for non-gui-ified options. Maybe put that under an 'advanced settings' kind of thing. It definitely would be good to have some kind of filter to ensure that people aren't trying to inject bogus commands to the OS as root or something. That's where things can get sticky, especially with passing scripts to be run on ifup/down etc... > That said, allowing options not handled in the GUI bits to be added is > probably the something that should be done; but it needs to be done in > such a way that if the option is sanely added to the GUI later on, that > it supersedes the custom-option-entry bit. I'm also a bit reluctant to > take out the option filter/validator for VPN methods that don't support > config-on-stdin, because passing random text on the command line is a > security risk. About the last thing we want to be doing is executing a > root process with random arguments entered by some trojan that stuffed > values into GConf. > > Dan > > > > -- David Hollis From francois.aucamp at gmail.com Tue Jan 15 10:43:25 2008 From: francois.aucamp at gmail.com (Francois Aucamp) Date: Tue, 15 Jan 2008 12:43:25 +0200 Subject: Orphaning/retiring some KDE3 packages Message-ID: <200801151243.25612.faucamp@csir.co.za> Hi, Since Fedora 9 will be running KDE 4, the following KDE3-related packages are no longer needed/useful, and I will be orphaning/retiring them as indicated (unless someone speaks up): Retire: dekorator kgtk Orphan: amarokFS (no amarok 2/qt4 support, and no visible further development) knemo (no longer developed; a KDE 4 plasmoid similar to KNemo is planned) Cheers, -Francois From opensource at till.name Tue Jan 15 10:56:56 2008 From: opensource at till.name (Till Maas) Date: Tue, 15 Jan 2008 11:56:56 +0100 Subject: Fedora bug triage - workflow proposal In-Reply-To: References: Message-ID: <200801151157.00624.opensource@till.name> On Tue January 15 2008, Jon Stanley wrote: > 4) Once a developer has taken responsibility for a bug and is > actively working on it, the state transitions to ON_DEV. This status is not mentioned in [1], will this be changed when this workflow is accepted? > Note that at any step of the above process, the maintainer can "fast > track" the bug, and change it to ASSIGNED. The triage team is not > going to look at bugs that are not in NEW or NEEDINFO state. On the > flip side of that, it is not a maintainer's responsibility to look at > bugs that are in NEW any longer. They can focus their energy on the > bugs that are ASSIGNED to them. I guess the triage team should also look at REOPENED bugs, e.g. when they where closed because of lack from NEEDINFO. > It was also decided that when a bug is in NEEDINFO for one month, it > will be closed. Maintainers would need to realize that putting a bug > in NEEDINFO is putting it on the fast track for closure. It should be distinguished, from who information is required. E.g. when it is not NEEDINFO_REPORTER, closing it after one month would not help. > I think that's all that I have to say on this topic right now, let me > know if I'm missing anything or this is complete hogwash :) I like this workflow. Regards, Till [1] https://bugzilla.redhat.com/page.cgi?id=bug_status.html#verified -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From opensource at till.name Tue Jan 15 11:08:26 2008 From: opensource at till.name (Till Maas) Date: Tue, 15 Jan 2008 12:08:26 +0100 Subject: Deleting a file/directory on startup In-Reply-To: <478BE1E1.5080405@ncsu.edu> References: <200801111852.08733.opensource@till.name> <200801142047.53471.opensource@till.name> <478BE1E1.5080405@ncsu.edu> Message-ID: <200801151208.39098.opensource@till.name> On Mon January 14 2008, Casey Dahlin wrote: > The most correct way is to put some content in the lockfile to allow it > to be determined if it is valid. Then pm-utils itself can figure it out > when its run. How can this be done in a bullet-proof way[1]? Also it seems to be a lot more complicated than just to make sure, that the lockdirectory is removed on startup (and there are already a lot of files and directories that are removed on startup by rc.sysinit, so it is more a common way to do it). The best way I know would be to be able to identify whether or not a system was rebooted since a file was created, but given there are systems that do not have a hardware clock, I do not know of a way to identify it. Is there, e.g. a file in /proc or /sys that will have a unique content that only changes every time a system is powered up? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From ml at deadbabylon.de Tue Jan 15 11:09:45 2008 From: ml at deadbabylon.de (Sebastian Vahl) Date: Tue, 15 Jan 2008 12:09:45 +0100 Subject: Orphaning/retiring some KDE3 packages In-Reply-To: <200801151243.25612.faucamp@csir.co.za> References: <200801151243.25612.faucamp@csir.co.za> Message-ID: <200801151209.50523.ml@deadbabylon.de> Am Di 15.Januar 2008 schrieb Francois Aucamp: > amarokFS (no amarok 2/qt4 support, and no visible further development) amarok2 is still in pre-alpha stage. I'm not aware of any release schedule for amarok2 so we'll see if this is ready for f9 (but I might be wrong here). If not, still having amarokFS for amarok1 would be nice. Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From simon.andrews at bbsrc.ac.uk Tue Jan 15 11:58:48 2008 From: simon.andrews at bbsrc.ac.uk (Simon Andrews) Date: Tue, 15 Jan 2008 11:58:48 +0000 Subject: Fedora bug triage - workflow proposal In-Reply-To: References: Message-ID: Jon Stanley wrote: > It was also decided that when a bug is in NEEDINFO for one month, it > will be closed. Maintainers would need to realize that putting a bug > in NEEDINFO is putting it on the fast track for closure. If you're going to do this can someone please check that: https://bugzilla.redhat.com/show_bug.cgi?id=219267 ..has been fixed. I've had a couple of bugs which languished in NEEDINFO for far too long because adding an attachment didn't reset them to assigned. Simon. From mike at miketc.com Tue Jan 15 11:58:42 2008 From: mike at miketc.com (Mike Chambers) Date: Tue, 15 Jan 2008 05:58:42 -0600 Subject: anaconda - unhandled exception In-Reply-To: <478C7385.80308@gmail.com> References: <478C68EC.6030201@mindspring.com> <478C7385.80308@gmail.com> Message-ID: <1200398322.2903.2.camel@scrappy.miketc.com> On Tue, 2008-01-15 at 00:49 -0800, Andrew Farris wrote: > Richard Hally wrote: > > Running the boot.iso from rawhide (dated 1/14/08 8:12) to do a network > > install produces an "unhandled exception" while in the "retrieving > > installation information" phase (after formating the disk). In the > > screen to save the bug or debug information, the local disk is grayed > > out so nothing could be saved. > > > > what now? > > > > Richard > > Wait for the next, this is in bugzilla already, see: > https://bugzilla.redhat.com/show_bug.cgi?id=428709 Ran into same problem last night as well. Except I was able to save the debug output to a remote server (one beside me) in case needed (looks like you already found out though). One side note though, is X actually worked this time (ATI X1300 card), and it could see the drives. So moving in the right direction, least compared to last few days. Keep it up Jeremy, ya bout got it licked! -- Mike Chambers Madisonville, KY "The best lil town on Earth!" From francois.aucamp at gmail.com Tue Jan 15 12:06:06 2008 From: francois.aucamp at gmail.com (Francois Aucamp) Date: Tue, 15 Jan 2008 14:06:06 +0200 Subject: Orphaning/retiring some KDE3 packages In-Reply-To: <200801151209.50523.ml@deadbabylon.de> References: <200801151243.25612.faucamp@csir.co.za> <200801151209.50523.ml@deadbabylon.de> Message-ID: <200801151406.06890.faucamp@csir.co.za> On Tuesday 15 January 2008 01:09:45 pm Sebastian Vahl wrote: > > amarok2 is still in pre-alpha stage. I'm not aware of any release schedule > for amarok2 so we'll see if this is ready for f9 (but I might be wrong > here). If not, still having amarokFS for amarok1 would be nice. > Indeed; I was assuming amarok2 would ship with f9... So (since there's still interest), I will continue to maintain amarokFS. :-) From vonbrand at inf.utfsm.cl Tue Jan 15 02:33:19 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Mon, 14 Jan 2008 23:33:19 -0300 Subject: xargs generates too long argument lists on i686 In-Reply-To: <1200337083.2761.11.camel@localhost.localdomain> References: <200801141243.m0EChTgO016238@laptop13.inf.utfsm.cl> <1200337083.2761.11.camel@localhost.localdomain> Message-ID: <200801150233.m0F2XJdE009727@laptop13.inf.utfsm.cl> Eric Paris wrote: > On Mon, 2008-01-14 at 09:43 -0300, Horst H. von Brand wrote: > > For some time now, each time I try to build an RPM it fails with something > > like: > > > > + /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot > > xargs: /usr/lib/rpm/check-rpaths-worker: Argument list too long > > error: Bad exit status from /var/tmp/rpm-tmp.39544 (%install) > > > > This I have traced back to xargs(1) generating huge argument lists, which > > the called command can't handle. Doing a "make clean" in a self-built > > kernel gives the same type of grief (I tweaked the Makefile there to call > > xargs with "-L 2000" to get it to work). > > > > I wonder how everybody else here is able to get anything done... > > > > findutils-4.2.31-2.fc8 on rawhide, fully up to date. > > well, if you aren't doing execve syscall argument logging with the audit > system feel free to up /proc/sys/kernel/audit_argv_kb. If that fixes > your troubles wait until 2.6.25 when my patch to finish unlimiting this > stuff goes into kernel.... Yep, that fixes this. Thanks! But isn't it supposed that xargs asks the kernel for the maximal size of ARGV? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From s.dahdaah at spidernetlb.com Tue Jan 15 12:22:02 2008 From: s.dahdaah at spidernetlb.com (Salloum EL DAHDAAH) Date: Tue, 15 Jan 2008 14:22:02 +0200 Subject: Fedora Enhancement!! Message-ID: <1200399722.14798.9.camel@localhost.localdomain> Hello, I am currently using fedora 8 i was a windows users and vb.net developer, i currently switched to fedora 8 for having a stable os running on my machine but i would like to post some ideas for fedora development team: Driver Issues: 1- VGA: ATI NVIDIA 3D Support especially with the new series. 2- WEBCAM: Sony built in camera VCC 6 3- Pocket Pc: Imate JAM the drivers are really a mess to find and to make them work and sometimes it fails. I currently made 15 persons turn from windows to fedora due to its performance i would like to have a solution for the following issues and i would like to know if there is any version of fedora that can run on pocket pcs like Imate and HTC. Thank you looking forward to fedora 8 @ least beta 1 :D From pp at ee.oulu.fi Tue Jan 15 12:23:33 2008 From: pp at ee.oulu.fi (Pekka Pietikainen) Date: Tue, 15 Jan 2008 14:23:33 +0200 Subject: Fedora 8 hanging In-Reply-To: <47894127.2000705@marquesminen.com.ar> References: <4788DF1F.6050802@marquesminen.com.ar> <20080112154548.GA18472@devserv.devel.redhat.com> <47894127.2000705@marquesminen.com.ar> Message-ID: <20080115122333.GA29319@ee.oulu.fi> On Sat, Jan 12, 2008 at 08:37:27PM -0200, Martin Marques wrote: > Alan Cox escribi?: >> On Sat, Jan 12, 2008 at 01:39:11PM -0200, Martin Marques wrote: >>> with an AMD turion 64 (running Fedora 64) and an Nvidia video card (using >>> the binary driver from livna). >> >> Remove the binary driver. Reboot using the nv Fedora supplied driver and >> see how it runs for a bit. If it still hangs then you know its not likely to >> be the Nvidia driver >> > > Removed nvidia.ko from the start up and the system hanged at boot time when > trying to start NM. Hangs happen randomly as I said: At differnet times of > boot or when in graphical mode. See https://fedoraproject.org/wiki/KernelCommonProblems https://bugzilla.redhat.com/show_bug.cgi?id=283161 (Bug is i686 not x86_64 hangs, but the command line options are worth trying out, nohz=off, highres=off, clocksource=xxx etc. ). Rawhide kernels seemed to be the fix for me :-) -- Pekka Pietikainen From s.dahdaah at spidernetlb.com Tue Jan 15 12:25:05 2008 From: s.dahdaah at spidernetlb.com (Salloum EL DAHDAAH) Date: Tue, 15 Jan 2008 14:25:05 +0200 Subject: SpotLight into fedora Message-ID: <1200399905.14798.13.camel@localhost.localdomain> Hello, There is a utility on the mac os X.5 named spotlight this utility has the ability to search all the pc even mails even files in a very high speed for anything you type in and i am looking forward to see a search tool like spotlight inside fedora as well as the visualization of the file it is really like magic inside mac os X.5 From sundaram at fedoraproject.org Tue Jan 15 12:37:29 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 15 Jan 2008 18:07:29 +0530 Subject: SpotLight into fedora In-Reply-To: <1200399905.14798.13.camel@localhost.localdomain> References: <1200399905.14798.13.camel@localhost.localdomain> Message-ID: <478CA909.4040408@fedoraproject.org> Salloum EL DAHDAAH wrote: > Hello, > > There is a utility on the mac os X.5 named spotlight this utility has > the ability to search all the pc even mails even files in a very high > speed for anything you type in and i am looking forward to see a search > tool like spotlight inside fedora as well as the visualization of the > file it is really like magic inside mac os X.5 > You can use Beagle, Tracker or Strigi in KDE 4 which are similar desktop search programs. Rahul From jakub.rusinek at gmail.com Tue Jan 15 12:29:07 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Tue, 15 Jan 2008 13:29:07 +0100 Subject: SpotLight into fedora In-Reply-To: <1200399905.14798.13.camel@localhost.localdomain> References: <1200399905.14798.13.camel@localhost.localdomain> Message-ID: <5e92ee3f0801150429j4641feby956f0831e8072f7e@mail.gmail.com> 2008/1/15, Salloum EL DAHDAAH : > > Hello, > > There is a utility on the mac os X.5 named spotlight this utility has > the ability to search all the pc even mails even files in a very high > speed for anything you type in and i am looking forward to see a search > tool like spotlight inside fedora as well as the visualization of the > file it is really like magic inside mac os X.5 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > What are you waiting for? Write it yourself or try Beagle, Tracker... -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From singularitaet at gmx.net Tue Jan 15 12:46:45 2008 From: singularitaet at gmx.net (Stefan Grosse) Date: Tue, 15 Jan 2008 13:46:45 +0100 Subject: Fedora Enhancement!! In-Reply-To: <1200399722.14798.9.camel@localhost.localdomain> References: <1200399722.14798.9.camel@localhost.localdomain> Message-ID: <200801151346.45228.singularitaet@gmx.net> On Tuesday 15 January 2008 01:22:02 pm Salloum EL DAHDAAH wrote: SE> Driver Issues: SE> 1- VGA: SE> ATI SE> NVIDIA SE> 3D Support especially with the new series. There is a licence issue thats why fedora does not include the "official" driver. But where is the problem to use the livna repository which includes non-free stuff!: http://rpm.livna.org SE> 2- WEBCAM: SE> Sony built in camera VCC 6 I don't know whether this is supported by the uvc driver. If I remember correctly in future linux kernels uvc might be included. Stefan From vonbrand at inf.utfsm.cl Tue Jan 15 12:57:27 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Tue, 15 Jan 2008 09:57:27 -0300 Subject: compilation architecture In-Reply-To: <1200341643.5433.81.camel@localhost> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <1200341643.5433.81.camel@localhost> Message-ID: <200801151257.m0FCvREV008743@laptop13.inf.utfsm.cl> Callum Lerwick wrote: [...] > Not quite "three times" faster, but 3.26% faster with i686. A major > addition to the i686 architecture was cmov, and gcc is actually very > aggressive about eliminating branching using cmovs, increasing > performance on modern deeply pipelined processors by eliminating > pipeline stalls. [...] > I suggest all key performance critical packages be made available in > both i386 and i686 versions. glibc and openssl already do this. Off the > top of my head, this would include Mesa, I know for a fact the majority > of Second Life runtime is actually consumed by T&L inside Mesa/DRI. From > what I understand, even Intel's latest chipsets lack hardware T&L. Makes > sense, it helps sell more multi-core Intel processors, and probably > helps consolidate power management. Twice the size for 3% improvement in extremely CPU-intensive tasks, and no gain whatsoever in load time, etc? That will translate to < 1% improvement overall. Lost in the noise, anyway. Not worth it in my book. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From jakub.rusinek at gmail.com Tue Jan 15 13:07:30 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Tue, 15 Jan 2008 14:07:30 +0100 Subject: compilation architecture In-Reply-To: <200801151257.m0FCvREV008743@laptop13.inf.utfsm.cl> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <1200341643.5433.81.camel@localhost> <200801151257.m0FCvREV008743@laptop13.inf.utfsm.cl> Message-ID: <5e92ee3f0801150507y2b9f31a5mcc7fd14b5760e384@mail.gmail.com> 2008/1/15, Horst H. von Brand : > > Callum Lerwick wrote: > > [...] > > > Not quite "three times" faster, but 3.26% faster with i686. A major > > addition to the i686 architecture was cmov, and gcc is actually very > > aggressive about eliminating branching using cmovs, increasing > > performance on modern deeply pipelined processors by eliminating > > pipeline stalls. > > [...] > > > I suggest all key performance critical packages be made available in > > both i386 and i686 versions. glibc and openssl already do this. Off the > > top of my head, this would include Mesa, I know for a fact the majority > > of Second Life runtime is actually consumed by T&L inside Mesa/DRI. From > > what I understand, even Intel's latest chipsets lack hardware T&L. Makes > > sense, it helps sell more multi-core Intel processors, and probably > > helps consolidate power management. > > Twice the size for 3% improvement in extremely CPU-intensive tasks, and no > gain whatsoever in load time, etc? That will translate to < 1% improvement > overall. Lost in the noise, anyway. Not worth it in my book. > -- > Dr. Horst H. von Brand User #22616 counter.li.org > Departamento de Informatica Fono: +56 32 2654431 > Universidad Tecnica Federico Santa Maria +56 32 2654239 > Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > So what in your opinion should be made to make Fedora faster? -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From subhodip at fedoraproject.org Tue Jan 15 13:12:12 2008 From: subhodip at fedoraproject.org (subhodip biswas) Date: Tue, 15 Jan 2008 18:42:12 +0530 Subject: SpotLight into fedora In-Reply-To: <5e92ee3f0801150429j4641feby956f0831e8072f7e@mail.gmail.com> References: <1200399905.14798.13.camel@localhost.localdomain> <5e92ee3f0801150429j4641feby956f0831e8072f7e@mail.gmail.com> Message-ID: <539333cb0801150512o4cabe3b5w2d61a72fc91c7095@mail.gmail.com> try deskbar ... it is same as spotlight -- Regards Subhodip Biswas GPG key : FAEA34AB Server : pgp.mit.edu http://subhodipbiswas.wordpress.com http:/www.fedoraproject.org/wiki/SubhodipBiswas From jakub.rusinek at gmail.com Tue Jan 15 13:27:14 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Tue, 15 Jan 2008 14:27:14 +0100 Subject: SpotLight into fedora In-Reply-To: <539333cb0801150512o4cabe3b5w2d61a72fc91c7095@mail.gmail.com> References: <1200399905.14798.13.camel@localhost.localdomain> <5e92ee3f0801150429j4641feby956f0831e8072f7e@mail.gmail.com> <539333cb0801150512o4cabe3b5w2d61a72fc91c7095@mail.gmail.com> Message-ID: <5e92ee3f0801150527i11c499ebwd2e24e55f23c3356@mail.gmail.com> 2008/1/15, subhodip biswas : > > try deskbar ... it is same as spotlight > > > -- > Regards > Subhodip Biswas > > GPG key : FAEA34AB > Server : pgp.mit.edu > http://subhodipbiswas.wordpress.com > http:/www.fedoraproject.org/wiki/SubhodipBiswas > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Not the same. SIMILLIAR. Was the same until 2.20 release. Now it's not anchored to the panel, but it's normal window. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at fedoraproject.org Tue Jan 15 13:37:27 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 15 Jan 2008 19:07:27 +0530 Subject: Fedora bug triage - workflow proposal In-Reply-To: References: Message-ID: <478CB717.4000202@fedoraproject.org> Jon Stanley wrote: > > 1) Reporter files a bug report, it originates in NEW state Can we renamed this state to UNCONFIRMED? > 2) Triage team looks at bug report, determines if dupe or > insufficient information exists to solve it. If there is not enough > information in the bug, then triage team puts the bug in NEEDINFO. As > you will see below, this state has a finite life cycle associated with > it. > 3) Assuming bug survives through the triage team, it changes state to > ASSIGNED (triage team can put it in either NEEDINFO or CLOSED, as > appropriate). Note that per the definition[1], ASSIGNED does not mean > that someone has actually agreed to take action, simply that the issue > is well defined and triaged accordingly Wouldn't a state like TRIAGED be more meaningful then? ASSIGNED frequently is assumed to be assuming ownership by the maintainers. > 4) Once a developer has taken responsibility for a bug and is > actively working on it, the state transitions to ON_DEV. If ASSIGNED is renamed to TRIAGED, then this state can be known as ASSIGNED instead. > Setting severity is fine. Only QA or releng should set priorities. > This allows us to look at things in a sane manner (which is impossible > now since severity and priority fields come from /dev/urandom > seemingly), and possibly lessen the reliance on blocker bugs (though > blockers are useful in their own right, so don't think that we are > going to eliminate them any time soon). I believe bugzilla folks are recommending the usage of flags over blocker bugs. > It was also decided that when a bug is in NEEDINFO for one month, it > will be closed. Maintainers would need to realize that putting a bug > in NEEDINFO is putting it on the fast track for closure. Would a stock message be send to the bug reporters when closing bugs? Would a separate Fedora page in bugzilla.redhat.com be useful? Rahul From karsten at redhat.com Tue Jan 15 13:39:47 2008 From: karsten at redhat.com (Karsten Hopp) Date: Tue, 15 Jan 2008 14:39:47 +0100 Subject: Should vim-X11 conflict with vim-enhanced ? Message-ID: <478CB7A3.8000206@redhat.com> Hello, Till proposed in bugzilla #311061 to use alternatives in vim-enhanced and vim-X11 so that both of them can provide /usr/bin/vim. His reasoning as that when gvim gets started as vim (via a symlink) it opens the text mode vim with the additional benefit of xterm clipboard support. I agree with the /usr/bin/vim stuff, but I think a better solution would be to add a conflict between vim-X11 and vim-enhanced. vim-enhanced is only of use on systems without X11/gtk. On all other systems vim-X11 can provide the same (and more) functionality as vim-enhanced. Karsten -- Karsten Hopp | Mail: karsten at redhat.de Red Hat Deutschland | Tel: +49-711-96437-0 Hauptstaetterstr.58 | Fax: +49-711-613590 D-70178 Stuttgart | http://www.redhat.de From clumens at redhat.com Tue Jan 15 13:45:39 2008 From: clumens at redhat.com (Chris Lumens) Date: Tue, 15 Jan 2008 08:45:39 -0500 Subject: anaconda - unhandled exception In-Reply-To: <1200398322.2903.2.camel@scrappy.miketc.com> References: <478C68EC.6030201@mindspring.com> <478C7385.80308@gmail.com> <1200398322.2903.2.camel@scrappy.miketc.com> Message-ID: <20080115134539.GB9011@dhcp83-45.boston.redhat.com> > Keep it up Jeremy, ya bout got it licked! Not to be a jerk or anything, but you're aware at least five other people work on anaconda, right? In fact if you were to check out the source history, you'd see that I committed the fix for that bug (the libraries out of the nss package changed location, requiring us to modify the stage2 build script) and that David built the version containing the fix. - Chris From kaigai at kaigai.gr.jp Tue Jan 15 13:47:57 2008 From: kaigai at kaigai.gr.jp (KaiGai Kohei) Date: Tue, 15 Jan 2008 22:47:57 +0900 Subject: rpms/sepostgresql/devel postgresql-8.2.6.tar.gz, NONE, 1.1 .cvsignore, 1.4, 1.5 sepostgresql.init, 1.8, 1.9 sepostgresql.spec, 1.8, 1.9 sepostgresql.te, 1.8, 1.9 In-Reply-To: <20080115091154.a99c1fb2.mschwendt.tmp0701.nospam@arcor.de> References: <200801101437.m0AEbemG002515@cvs-int.fedora.redhat.com> <1199983507.3398.14.camel@localhost.localdomain> <20080114120951.4c9df209.mschwendt.tmp0701.nospam@arcor.de> <478B724F.4010002@kaigai.gr.jp> <20080114155558.83443828.mschwendt.tmp0701.nospam@arcor.de> <478B890B.2070005@kaigai.gr.jp> <20080115091154.a99c1fb2.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <478CB98D.9040507@kaigai.gr.jp> Michael Schwendt wrote: > On Tue, 15 Jan 2008 01:08:43 +0900, KaiGai Kohei wrote: > >> I've fixed them with the above processes. >> If possible, please confirm it. > > Yes, the binaries are gone now. Good. You could also remove the > old patch files, which are no longer used in your package. I also removed the lagacy patches applied for older base versions. Thanks, -- KaiGai Kohei From sundaram at fedoraproject.org Tue Jan 15 14:15:48 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 15 Jan 2008 19:45:48 +0530 Subject: anaconda - unhandled exception In-Reply-To: <20080115134539.GB9011@dhcp83-45.boston.redhat.com> References: <478C68EC.6030201@mindspring.com> <478C7385.80308@gmail.com> <1200398322.2903.2.camel@scrappy.miketc.com> <20080115134539.GB9011@dhcp83-45.boston.redhat.com> Message-ID: <478CC014.3070707@fedoraproject.org> Chris Lumens wrote: >> Keep it up Jeremy, ya bout got it licked! > > Not to be a jerk or anything, but you're aware at least five other > people work on anaconda, right? In fact if you were to check out the > source history, you'd see that I committed the fix for that bug (the > libraries out of the nss package changed location, requiring us to > modify the stage2 build script) and that David built the version > containing the fix. Having the team information listed and who does what might help http://fedoraproject.org/wiki/Anaconda Rahul From jdennis at redhat.com Tue Jan 15 14:08:52 2008 From: jdennis at redhat.com (John Dennis) Date: Tue, 15 Jan 2008 09:08:52 -0500 Subject: Deleting a file/directory on startup In-Reply-To: <200801151208.39098.opensource@till.name> References: <200801111852.08733.opensource@till.name> <200801142047.53471.opensource@till.name> <478BE1E1.5080405@ncsu.edu> <200801151208.39098.opensource@till.name> Message-ID: <478CBE74.5020405@redhat.com> Till Maas wrote: > On Mon January 14 2008, Casey Dahlin wrote: > >> The most correct way is to put some content in the lockfile to allow it >> to be determined if it is valid. Then pm-utils itself can figure it out >> when its run. > > How can this be done in a bullet-proof way[1]? Also it seems to be a lot more > complicated than just to make sure, that the lockdirectory is removed on > startup (and there are already a lot of files and directories that are > removed on startup by rc.sysinit, so it is more a common way to do it). > The best way I know would be to be able to identify whether or not a system > was rebooted since a file was created, but given there are systems that do > not have a hardware clock, I do not know of a way to identify it. Is there, > e.g. a file in /proc or /sys that will have a unique content that only > changes every time a system is powered up? Last week I answered and said a standard technique is the use of pid files and explained how it works. Is there some reason that approach does not give you exactly what you've asked for? The pid can either be in a separate pid file or in the lockfile, or both, just be aware of potential race conditions if the pid is in more than one file and do the operations in the correct order. -- John Dennis From mschwendt.tmp0701.nospam at arcor.de Tue Jan 15 14:19:25 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 15 Jan 2008 15:19:25 +0100 Subject: compilation architecture In-Reply-To: <5e92ee3f0801150507y2b9f31a5mcc7fd14b5760e384@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <1200341643.5433.81.camel@localhost> <200801151257.m0FCvREV008743@laptop13.inf.utfsm.cl> <5e92ee3f0801150507y2b9f31a5mcc7fd14b5760e384@mail.gmail.com> Message-ID: <20080115151925.652f0500.mschwendt.tmp0701.nospam@arcor.de> On Tue, 15 Jan 2008 14:07:30 +0100, Jakub 'Livio' Rusinek wrote: > So what in your opinion should be made to make Fedora faster? Have you performed any tests other than perception-based comparison of Firefox start-times under two different [unspecified] configurations? Any benchmark results? Is it just Firefox that starts more quickly? Or do you see faster builds when compiling software, compressing archives, encoding Ogg files, or FPS values in graphical rendering applications? Can you post even simple "time command" based results which compare execution times of several programs? First you say the compiler optimisation flags are insufficient. Then, with the assistance from list subscribers, it is found out that more likely the faster start-times are due to a different preloading strategy. It's not the first time somebody bumps into this list and claims that the compiler flags are either "wrong", "should be for i686 not i386" or "don't optimise enough". It happens once a year or so and is covered by the list archives. Usually, there is interest in discussing it. Even experts comment on such topics and give serious answers instead of treating the original poster like a troll. Nobody would mind if they ignored topics like this one. But what is missing in all these cases is a scientific approach to analysing what you believe is a problem. Even the step where you would collect data, from which to proceed, is missing. From z.kota at gmx.net Tue Jan 15 14:26:09 2008 From: z.kota at gmx.net (Zoltan Kota) Date: Tue, 15 Jan 2008 15:26:09 +0100 (CET) Subject: recode and gcc-4.3 (Was: Re: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220) In-Reply-To: <20080103120242.GZ20451@devserv.devel.redhat.com> References: <20080103120242.GZ20451@devserv.devel.redhat.com> Message-ID: Hi, Can you help me to find out what the problem is with recode compiled with gcc-4.3.0? The log is here: http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/unsorted/recode-3.6-24.fc8.log Thanks Zoltan From clumens at redhat.com Tue Jan 15 14:40:09 2008 From: clumens at redhat.com (Chris Lumens) Date: Tue, 15 Jan 2008 09:40:09 -0500 Subject: anaconda - unhandled exception In-Reply-To: <478CC014.3070707@fedoraproject.org> References: <478C68EC.6030201@mindspring.com> <478C7385.80308@gmail.com> <1200398322.2903.2.camel@scrappy.miketc.com> <20080115134539.GB9011@dhcp83-45.boston.redhat.com> <478CC014.3070707@fedoraproject.org> Message-ID: <20080115144009.GC9011@dhcp83-45.boston.redhat.com> > Having the team information listed and who does what might help > > http://fedoraproject.org/wiki/Anaconda Good idea. Fixed. - Chris From ajackson at redhat.com Tue Jan 15 14:58:08 2008 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 15 Jan 2008 09:58:08 -0500 Subject: X broken in rawhide? In-Reply-To: References: Message-ID: <1200409088.15130.269.camel@localhost.localdomain> On Tue, 2008-01-15 at 02:39 +0100, Linus Walleij wrote: > On Mon, 14 Jan 2008, darrell pfeifer wrote: > > > I haven't seen anyone else reporting X problems. Is there something I've > > missed? > > I've seen X upgrades wiping out the ModulePath sections in > /etc/X11/xorg.conf for me. This is intentional, yes. It's even in %post: # lame, the nvidia driver needs to override this if ! grep -q 'ModulePath.*nvidia' xorg.conf ; then perl -p -i -e 's#^\s*ModulePath.*$##gi' xorg.conf fi We do this because many people used to have a ModulePath section in their config file, and it changed when we moved to modular X because drivers were no longer installed in the same place, but if you explicitly specified a ModulePath you'd continue looking in the old place. And then X wouldn't start. If you want to build custom modules by hand, put them in the normal search path. The only reason the nvidia driver gets a workaround is because it replaces a library that the X server normally provides and rpm doesn't have file redirects. - ajax From singularitaet at gmx.net Tue Jan 15 15:06:53 2008 From: singularitaet at gmx.net (Stefan Grosse) Date: Tue, 15 Jan 2008 16:06:53 +0100 Subject: texlive + pdftex +kile: very slow Message-ID: <200801151606.59141.singularitaet@gmx.net> Hi, I have upgraded my tex to texlive from rawhide. Whenever I run pdftex on a document (unfortunately this is necessary for the beamer package) it takes 1-2 minutes on even a very small text kile consumes during this time ~100% cpu. I did not have the same problem with tetex. Is someone else observing the same? Is it a pdftex bug? Or kile bug? Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From z.kota at gmx.net Tue Jan 15 15:07:44 2008 From: z.kota at gmx.net (Zoltan Kota) Date: Tue, 15 Jan 2008 16:07:44 +0100 (CET) Subject: Python Eggs & distutils in Rawhide In-Reply-To: <475DBBAA.7030605@gmail.com> References: <475DBBAA.7030605@gmail.com> Message-ID: On Mon, 10 Dec 2007, Toshio Kuratomi wrote: > Just a small heads up for those of you packaging python modules. > python-2.5.1-18, just built for rawhide, has reverted a small patch we > were carrying that disabled generation of egg-info for modules created > by distutils. That means that python modules built against rawhide will > now create an extra file of metadata in the python_sitelib and > python_sitearch directories. You'll need to include those in your > %files section if it's not already pulled in via a wildcard. How is it decided where the egg-info will be installed: in the python_sitelib or python_sitearch? If my package installs files in python_sitearch, can I expect to have the egg-info there as well? Sorry for the stupid question! Zoltan From a.badger at gmail.com Tue Jan 15 15:10:31 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 15 Jan 2008 10:10:31 -0500 Subject: Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <478CB7A3.8000206@redhat.com> References: <478CB7A3.8000206@redhat.com> Message-ID: <478CCCE7.1000804@gmail.com> Karsten Hopp wrote: > Hello, > > Till proposed in bugzilla #311061 to use alternatives in vim-enhanced > and vim-X11 so that > both of them can provide /usr/bin/vim. His reasoning as that when gvim > gets started as vim > (via a symlink) it opens the text mode vim with the additional benefit > of xterm clipboard support. > How does this differ from using gvim -v? > I agree with the /usr/bin/vim stuff, but I think a better solution would > be to add a conflict between > vim-X11 and vim-enhanced. vim-enhanced is only of use on systems without > X11/gtk. On all other > systems vim-X11 can provide the same (and more) functionality as > vim-enhanced. > alternatives is not a good solution for end-user apps on a multi-user system because the admin is setting a preference that is really better left to the user to decide. The user can set this preference using an alias (alias vim='gvim -v'). Conflicts precludes the ability to have both versions installed in case one user of the system wants one thing and a different user wants another. Additionally, we are trying to get rid of unnecessary Conflicts... this seems to qualify as unnecessary for me as there's a valid method of creating the package at the moment which does not require Conflicts. What are you trying to achieve? Perhaps it would be simpler to get rid of the vim-enhanced package? Or perhaps what we have now is the simplest solution. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jakub.rusinek at gmail.com Tue Jan 15 15:11:44 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Tue, 15 Jan 2008 16:11:44 +0100 Subject: compilation architecture In-Reply-To: <20080115151925.652f0500.mschwendt.tmp0701.nospam@arcor.de> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <1200341643.5433.81.camel@localhost> <200801151257.m0FCvREV008743@laptop13.inf.utfsm.cl> <5e92ee3f0801150507y2b9f31a5mcc7fd14b5760e384@mail.gmail.com> <20080115151925.652f0500.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <5e92ee3f0801150711o9108b7apf83f4ae132b894e4@mail.gmail.com> 2008/1/15, Michael Schwendt : > > On Tue, 15 Jan 2008 14:07:30 +0100, Jakub 'Livio' Rusinek wrote: > > > So what in your opinion should be made to make Fedora faster? > > Have you performed any tests other than perception-based comparison of > Firefox start-times under two different [unspecified] configurations? Any > benchmark results? Is it just Firefox that starts more quickly? Or do you > see faster builds when compiling software, compressing archives, encoding > Ogg files, or FPS values in graphical rendering applications? Can you post > even simple "time command" based results which compare execution times of > several programs? First you say the compiler optimisation flags are > insufficient. Then, with the assistance from list subscribers, it is found > out that more likely the faster start-times are due to a different > preloading strategy. > > It's not the first time somebody bumps into this list and claims that the > compiler flags are either "wrong", "should be for i686 not i386" or "don't > optimise enough". It happens once a year or so and is covered by the list > archives. Usually, there is interest in discussing it. Even experts > comment on such topics and give serious answers instead of treating the > original poster like a troll. Nobody would mind if they ignored topics > like this one. But what is missing in all these cases is a scientific > approach to analysing what you believe is a problem. Even the step where > you would collect data, from which to proceed, is missing. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I'm not using openSUSE anymore, but I can say: * udev was running faster * networkmanager too * firefox started faster * firefox scrolled webpages faster (even in smooth mode, which doesn't work well for me in Fedora) * opengl rendering were waster (eg elisa started drawing earlier, compiz burn effect was smooth) -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamatos at fc.up.pt Tue Jan 15 15:15:58 2008 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Tue, 15 Jan 2008 15:15:58 +0000 Subject: texlive + pdftex +kile: very slow In-Reply-To: <200801151606.59141.singularitaet@gmx.net> References: <200801151606.59141.singularitaet@gmx.net> Message-ID: <200801151515.58308.jamatos@fc.up.pt> On Tuesday 15 January 2008 15:06:53 Stefan Grosse wrote: > Hi, > > I have upgraded my tex to texlive from rawhide. Whenever I run pdftex on a > document (unfortunately this is necessary for the beamer package) it takes > 1-2 minutes on even a very small text kile consumes during this time ~100% > cpu. > > I did not have the same problem with tetex. > > Is someone else observing the same? Is it a pdftex bug? Or kile bug? No problem here both on fc8 with Jind?ich texlive packages and lyx as well as with rawhide. It runs fast and I do not notice any difference from tetex in terms of speed. > Stefan -- Jos? Ab?lio From singularitaet at gmx.net Tue Jan 15 15:16:34 2008 From: singularitaet at gmx.net (Stefan Grosse) Date: Tue, 15 Jan 2008 16:16:34 +0100 Subject: Kernel halt problem with Cinergy T2 dvb device Message-ID: <200801151616.34958.singularitaet@gmx.net> Hi, another problem: I am not sure whether this belongs into this devel-group. My computer does not shut down completely when the cinergy T2 dvb device (usb) is plugged in. The shutdown process stops at halting the system. The display is (in most cases) switched off but the leds are still on and the fan is still working. Now when unplug the device even during the shutdown process the system is shutting down completely. Now is this a kernel bug? I was hoping from kernel update to kernel update that this is fixed. (although I havent tried the 24 development kernels yet). What can I provide (and where should I do this) to get this fixed? (I am not a programmer) Stefan My smolt profile: http://www.smolts.org/show?UUID=eda324cc-2c30-4f7c-9523-92e6c13aa4b0 From ajackson at redhat.com Tue Jan 15 15:35:58 2008 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 15 Jan 2008 10:35:58 -0500 Subject: compilation architecture In-Reply-To: <5e92ee3f0801150711o9108b7apf83f4ae132b894e4@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <1200341643.5433.81.camel@localhost> <200801151257.m0FCvREV008743@laptop13.inf.utfsm.cl> <5e92ee3f0801150507y2b9f31a5mcc7fd14b5760e384@mail.gmail.com> <20080115151925.652f0500.mschwendt.tmp0701.nospam@arcor.de> <5e92ee3f0801150711o9108b7apf83f4ae132b894e4@mail.gmail.com> Message-ID: <1200411358.15130.271.camel@localhost.localdomain> On Tue, 2008-01-15 at 16:11 +0100, Jakub 'Livio' Rusinek wrote: > I'm not using openSUSE anymore, but I can say: > > * udev was running faster > * networkmanager too > * firefox started faster > * firefox scrolled webpages faster (even in smooth mode, which doesn't > work well for me in Fedora) > * opengl rendering were waster (eg elisa started drawing earlier, > compiz burn effect was smooth) Measure or GTFO. - ajax From jakub.rusinek at gmail.com Tue Jan 15 15:26:56 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Tue, 15 Jan 2008 16:26:56 +0100 Subject: compilation architecture In-Reply-To: <1200411358.15130.271.camel@localhost.localdomain> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <1200341643.5433.81.camel@localhost> <200801151257.m0FCvREV008743@laptop13.inf.utfsm.cl> <5e92ee3f0801150507y2b9f31a5mcc7fd14b5760e384@mail.gmail.com> <20080115151925.652f0500.mschwendt.tmp0701.nospam@arcor.de> <5e92ee3f0801150711o9108b7apf83f4ae132b894e4@mail.gmail.com> <1200411358.15130.271.camel@localhost.localdomain> Message-ID: <5e92ee3f0801150726v2d708d70x7e51087f0bb0a254@mail.gmail.com> 2008/1/15, Adam Jackson : > > On Tue, 2008-01-15 at 16:11 +0100, Jakub 'Livio' Rusinek wrote: > > > I'm not using openSUSE anymore, but I can say: > > > > * udev was running faster > > * networkmanager too > > * firefox started faster > > * firefox scrolled webpages faster (even in smooth mode, which doesn't > > work well for me in Fedora) > > * opengl rendering were waster (eg elisa started drawing earlier, > > compiz burn effect was smooth) > > Measure or GTFO. > > - ajax > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > So now I must to install openSUSE only because you want to see data? It's kinda stupid. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattdm at mattdm.org Tue Jan 15 15:27:46 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 15 Jan 2008 10:27:46 -0500 Subject: Preloading [WAS: Re: SuSE Project SUPER] In-Reply-To: <20080114222658.GA4835@traged.englab.brq.redhat.com> References: <47893D75.1000406@redhat.com> <5e92ee3f0801121432qcf7287cx2982deafafe0674c@mail.gmail.com> <3adc77210801131634q41296a6br5fd5c3f444f98588@mail.gmail.com> <478ACD3C.6070106@redhat.com> <604aa7910801132244t15fbfdecg52c39f12b402406@mail.gmail.com> <1200296346.5433.10.camel@localhost> <478B6F4F.7020904@gmail.com> <20080114222658.GA4835@traged.englab.brq.redhat.com> Message-ID: <20080115152746.GA31165@jadzia.bu.edu> On Mon, Jan 14, 2008 at 11:26:58PM +0100, Adam Tkac wrote: > stability without care about code speed and quality. Looks like I have > to switch from gnome to blackbox or fluxbox. This will solve my > problem. For now. And after two years I will start using runlevel 3 by Adam: XFCE. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From bkoz at redhat.com Tue Jan 15 15:30:39 2008 From: bkoz at redhat.com (Benjamin Kosnik) Date: Tue, 15 Jan 2008 09:30:39 -0600 Subject: recode and gcc-4.3 (Was: Re: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220) In-Reply-To: References: <20080103120242.GZ20451@devserv.devel.redhat.com> Message-ID: <20080115093039.2870ab2d@wabash.artheist.org> > Can you help me to find out what the problem is with recode compiled > with gcc-4.3.0? > The log is here: > http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/unsorted/recode-3.6-24.fc8.log Error is: gcc -DLIBDIR=\"/usr/local/lib\" -DHAVE_CONFIG_H -I.. -I. -I../lib -I../libiconv -g -O2 -c combine.c -fPIC -DPIC -o .libs/combine.lo argmatch.c: In function '__argmatch_die': argmatch.c:69: warning: incompatible implicit declaration of built-in function 'exit' In file included from common.h:140, from charname.c:20: recodext.h:221: error: width of 'ignore' exceeds its type So, you'll need to look at recodext.h, line 221: /* Non zero if this one should be ignored. */ bool ignore : 2; Changing this to /* Non zero if this one should be ignored. */ bool ignore; Will fix it. Patch attached. -benjamin -------------- next part -------------- A non-text attachment was scrubbed... Name: recode-bool-bitfield.patch Type: text/x-patch Size: 498 bytes Desc: not available URL: From mattdm at mattdm.org Tue Jan 15 15:30:51 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 15 Jan 2008 10:30:51 -0500 Subject: X broken in rawhide? In-Reply-To: References: Message-ID: <20080115153051.GB31165@jadzia.bu.edu> On Mon, Jan 14, 2008 at 01:19:22PM -0800, darrell pfeifer wrote: > The workaround for me was to restore an earlier version of X. > I haven't seen anyone else reporting X problems. Is there something I've > missed? Happened with me and ATI but is all good now. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From P at draigBrady.com Tue Jan 15 15:29:11 2008 From: P at draigBrady.com (=?ISO-8859-1?Q?P=E1draig_Brady?=) Date: Tue, 15 Jan 2008 15:29:11 +0000 Subject: recode and gcc-4.3 (Was: Re: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220) In-Reply-To: References: <20080103120242.GZ20451@devserv.devel.redhat.com> Message-ID: <478CD147.2010206@draigBrady.com> Zoltan Kota wrote: > Hi, > > Can you help me to find out what the problem is with recode compiled > with gcc-4.3.0? > The log is here: > http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/unsorted/recode-3.6-24.fc8.log Looks like gcc is giving an error now for bitfields that are larger than their types. In this particular case it gives an error for: struct { bool ignore:2; }; Does the attached patch help? cheers, P?draig. -------------- next part -------------- A non-text attachment was scrubbed... Name: recode-3.6-gcc-4.3.patch Type: text/x-patch Size: 488 bytes Desc: not available URL: From sundaram at fedoraproject.org Tue Jan 15 15:40:49 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 15 Jan 2008 21:10:49 +0530 Subject: compilation architecture In-Reply-To: <5e92ee3f0801150726v2d708d70x7e51087f0bb0a254@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <1200341643.5433.81.camel@localhost> <200801151257.m0FCvREV008743@laptop13.inf.utfsm.cl> <5e92ee3f0801150507y2b9f31a5mcc7fd14b5760e384@mail.gmail.com> <20080115151925.652f0500.mschwendt.tmp0701.nospam@arcor.de> <5e92ee3f0801150711o9108b7apf83f4ae132b894e4@mail.gmail.com> <1200411358.15130.271.camel@localhost.localdomain> <5e92ee3f0801150726v2d708d70x7e51087f0bb0a254@mail.gmail.com> Message-ID: <478CD401.4030302@fedoraproject.org> Jakub 'Livio' Rusinek wrote: > So now I must to install openSUSE only because you want to see data? > It's kinda stupid. It isn't more stupid than this discussion without any data to support it. If you are really interested in improvements, that is what is needed. Rahul From rms at 1407.org Tue Jan 15 15:35:36 2008 From: rms at 1407.org (Rui Miguel Silva Seabra) Date: Tue, 15 Jan 2008 15:35:36 +0000 Subject: Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <478CB7A3.8000206@redhat.com> References: <478CB7A3.8000206@redhat.com> Message-ID: <20080115153536.GB6483@roque.1407.org> On Tue, Jan 15, 2008 at 02:39:47PM +0100, Karsten Hopp wrote: > I agree with the /usr/bin/vim stuff, but I think a better solution would be > to add a conflict between > vim-X11 and vim-enhanced. vim-enhanced is only of use on systems without > X11/gtk. On all other > systems vim-X11 can provide the same (and more) functionality as > vim-enhanced. I would strongly disagree that vim-enhanced is only of use on systems without X11/gtk. vim is far more pratical on an terminal emulator than gvim, even on a system with X11/gtk. Rui -- Or not. Today is Setting Orange, the 15th day of Chaos in the YOLD 3174 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? From tcallawa at redhat.com Tue Jan 15 15:37:24 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 15 Jan 2008 10:37:24 -0500 Subject: compilation architecture In-Reply-To: <5e92ee3f0801150726v2d708d70x7e51087f0bb0a254@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <1200341643.5433.81.camel@localhost> <200801151257.m0FCvREV008743@laptop13.inf.utfsm.cl> <5e92ee3f0801150507y2b9f31a5mcc7fd14b5760e384@mail.gmail.com> <20080115151925.652f0500.mschwendt.tmp0701.nospam@arcor.de> <5e92ee3f0801150711o9108b7apf83f4ae132b894e4@mail.gmail.com> <1200411358.15130.271.camel@localhost.localdomain> <5e92ee3f0801150726v2d708d70x7e51087f0bb0a254@mail.gmail.com> Message-ID: <1200411444.3852.35.camel@localhost.localdomain> On Tue, 2008-01-15 at 16:26 +0100, Jakub 'Livio' Rusinek wrote: > So now I must to install openSUSE only because you want to see data? > It's kinda stupid. Do you really not understand this? Let me try to make this simple. My car is faster than your car. Really? How fast does it go? I don't know, fast. OK, how did you measure the speed? I didn't. It just felt faster. Hmm. OK, maybe we could setup a race between our cars? I don't have that car anymore. So, let me get this straight. A car that you don't have anymore is somehow faster than mine, but you don't know how fast it goes, nor do you have any measurements of its speed? Yes! You need to make your car fast like that. I'll get right on that. Really. ~spot From opensource at till.name Tue Jan 15 15:39:58 2008 From: opensource at till.name (Till Maas) Date: Tue, 15 Jan 2008 16:39:58 +0100 Subject: Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <478CCCE7.1000804@gmail.com> References: <478CB7A3.8000206@redhat.com> <478CCCE7.1000804@gmail.com> Message-ID: <200801151640.03456.opensource@till.name> On Tue January 15 2008, Toshio Kuratomi wrote: > Karsten Hopp wrote: > > Hello, > > > > Till proposed in bugzilla #311061 to use alternatives in vim-enhanced > > and vim-X11 so that > > both of them can provide /usr/bin/vim. His reasoning as that when gvim > > gets started as vim > > (via a symlink) it opens the text mode vim with the additional benefit > > of xterm clipboard support. > > How does this differ from using gvim -v? It is more complicated that to run "vim". Running "vim" will always open an editor, even when gvim is not installed. I guess the reasons are the same why someone uses "gvim" instead of "vim -g". > > I agree with the /usr/bin/vim stuff, but I think a better solution would > > be to add a conflict between > > vim-X11 and vim-enhanced. vim-enhanced is only of use on systems without > > X11/gtk. On all other > > systems vim-X11 can provide the same (and more) functionality as > > vim-enhanced. > > alternatives is not a good solution for end-user apps on a multi-user > system because the admin is setting a preference that is really better > left to the user to decide. The user can set this preference using an > alias (alias vim='gvim -v'). > Conflicts precludes the ability to have both versions installed in case > one user of the system wants one thing and a different user wants > another. Additionally, we are trying to get rid of unnecessary Why should one want to use vim without X support, when vim with X support is installed? The only difference afaik is that it loads maybe some 1/100 of a second faster. Another issue is that maybe someone wants that vim-X11 is substituted by vim-enhanced when vim-X11 is removed because e.g. X11 is removed. But this does not mean that both binaries need to be installed all the time to make the user happy. > What are you trying to achieve? Perhaps it would be simpler to get rid > of the vim-enhanced package? Or perhaps what we have now is the > simplest solution. For a user it is a very annoying situation. When one installs vim-X11, the binary /usr/bin/gvim) cannot be run with all possible names, e.g. vim, vimdiff, view, ... And running it with, e.g. "gvim -v -d" instead of "vimdiff" is also annoying. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From cjdahlin at ncsu.edu Tue Jan 15 15:35:16 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Tue, 15 Jan 2008 10:35:16 -0500 Subject: Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <478CB7A3.8000206@redhat.com> References: <478CB7A3.8000206@redhat.com> Message-ID: <478CD2B4.6040205@ncsu.edu> Karsten Hopp wrote: > Hello, > > Till proposed in bugzilla #311061 to use alternatives in vim-enhanced > and vim-X11 so that > both of them can provide /usr/bin/vim. His reasoning as that when gvim > gets started as vim > (via a symlink) it opens the text mode vim with the additional > benefit of xterm clipboard support. > This can be turned on in vim-enhanced just by adding a few flags to the spec. It seems not to cause any trouble without an X server too. I've done it on RHEL. > I agree with the /usr/bin/vim stuff, but I think a better solution > would be to add a conflict between > vim-X11 and vim-enhanced. vim-enhanced is only of use on systems > without X11/gtk. On all other > systems vim-X11 can provide the same (and more) functionality as > vim-enhanced. > > Karsten > > -- > Karsten Hopp | Mail: karsten at redhat.de > Red Hat Deutschland | Tel: +49-711-96437-0 > Hauptstaetterstr.58 | Fax: +49-711-613590 > D-70178 Stuttgart | http://www.redhat.de > From opensource at till.name Tue Jan 15 15:47:52 2008 From: opensource at till.name (Till Maas) Date: Tue, 15 Jan 2008 16:47:52 +0100 Subject: Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <20080115153536.GB6483@roque.1407.org> References: <478CB7A3.8000206@redhat.com> <20080115153536.GB6483@roque.1407.org> Message-ID: <200801151647.53632.opensource@till.name> On Tue January 15 2008, Rui Miguel Silva Seabra wrote: > vim is far more pratical on an terminal emulator than gvim, even on a > system with X11/gtk. The gvim binary runs without any problems in an terminal emulator or a terminal when it is run with the name vim. Or do you know anything that breaks then? Btw. you can test it with: cd /tmp ln -s /usr/bin/gvim vim /tmp/vim Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From opensource at till.name Tue Jan 15 15:47:58 2008 From: opensource at till.name (Till Maas) Date: Tue, 15 Jan 2008 16:47:58 +0100 Subject: Deleting a file/directory on startup In-Reply-To: <478CBE74.5020405@redhat.com> References: <200801111852.08733.opensource@till.name> <200801151208.39098.opensource@till.name> <478CBE74.5020405@redhat.com> Message-ID: <200801151647.58720.opensource@till.name> On Tue January 15 2008, John Dennis wrote: > Last week I answered and said a standard technique is the use of pid > files and explained how it works. Is there some reason that approach > does not give you exactly what you've asked for? The pid can either be > in a separate pid file or in the lockfile, or both, just be aware of > potential race conditions if the pid is in more than one file and do the > operations in the correct order. What should happen in case there is process that is running with the pid that is stored, but it is not the process that stored the pid? Then additional checking needs to performed which is all code that may cause bugs and is always a lot more complicated than a simple "rm -rf /.suspended". Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From rms at 1407.org Tue Jan 15 15:50:02 2008 From: rms at 1407.org (Rui Miguel Silva Seabra) Date: Tue, 15 Jan 2008 15:50:02 +0000 Subject: Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <200801151647.53632.opensource@till.name> References: <478CB7A3.8000206@redhat.com> <20080115153536.GB6483@roque.1407.org> <200801151647.53632.opensource@till.name> Message-ID: <20080115155002.GC6483@roque.1407.org> On Tue, Jan 15, 2008 at 04:47:52PM +0100, Till Maas wrote: > On Tue January 15 2008, Rui Miguel Silva Seabra wrote: > > vim is far more pratical on an terminal emulator than gvim, even on a > > system with X11/gtk. > > The gvim binary runs without any problems in an terminal emulator or a > terminal when it is run with the name vim. Or do you know anything that > breaks then? > Btw. you can test it with: > > cd /tmp > ln -s /usr/bin/gvim vim > /tmp/vim Ah... I didn't know about this. Nothing to see here, move along ;) Rui -- Frink! Today is Setting Orange, the 15th day of Chaos in the YOLD 3174 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? From mr.ecik at gmail.com Tue Jan 15 15:50:55 2008 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Tue, 15 Jan 2008 16:50:55 +0100 Subject: Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <478CB7A3.8000206@redhat.com> References: <478CB7A3.8000206@redhat.com> Message-ID: <668bb39a0801150750g5360417bvc208b7d87587c4ed@mail.gmail.com> I think that what we can do is a wrapper (e.g. in vim-common package) which would check which vim is installed and run it. If both are, it could, say, prefer -X11 over -enhanced by default but it should be also possible to set it in a config file. What do you think? 2008/1/15, Karsten Hopp : > Hello, > > Till proposed in bugzilla #311061 to use alternatives in vim-enhanced and vim-X11 so that > both of them can provide /usr/bin/vim. His reasoning as that when gvim gets started as vim > (via a symlink) it opens the text mode vim with the additional benefit of xterm clipboard support. > > I agree with the /usr/bin/vim stuff, but I think a better solution would be to add a conflict between > vim-X11 and vim-enhanced. vim-enhanced is only of use on systems without X11/gtk. On all other > systems vim-X11 can provide the same (and more) functionality as vim-enhanced. > > Karsten > > -- > Karsten Hopp | Mail: karsten at redhat.de > Red Hat Deutschland | Tel: +49-711-96437-0 > Hauptstaetterstr.58 | Fax: +49-711-613590 > D-70178 Stuttgart | http://www.redhat.de > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Micha? Bentkowski mr.ecik at gmail.com From mschwendt.tmp0701.nospam at arcor.de Tue Jan 15 15:56:01 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 15 Jan 2008 16:56:01 +0100 Subject: compilation architecture In-Reply-To: <5e92ee3f0801150726v2d708d70x7e51087f0bb0a254@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <1200341643.5433.81.camel@localhost> <200801151257.m0FCvREV008743@laptop13.inf.utfsm.cl> <5e92ee3f0801150507y2b9f31a5mcc7fd14b5760e384@mail.gmail.com> <20080115151925.652f0500.mschwendt.tmp0701.nospam@arcor.de> <5e92ee3f0801150711o9108b7apf83f4ae132b894e4@mail.gmail.com> <1200411358.15130.271.camel@localhost.localdomain> <5e92ee3f0801150726v2d708d70x7e51087f0bb0a254@mail.gmail.com> Message-ID: <20080115165601.67bdf81e.mschwendt.tmp0701.nospam@arcor.de> On Tue, 15 Jan 2008 16:26:56 +0100, Jakub 'Livio' Rusinek wrote: > So now I must to install openSUSE only because you want to see data? It's > kinda stupid. No, it isn't. So far, you have not provided any data. You have not even posted data about your hardware, active drivers, your configuration of both test environments. > * udev was running faster > * networkmanager too Hmm, but especially when writing things like that it is really necessary to provide actual numbers to back up your claims and to take a close look at these two programs are configured. For example, a simple change in number of udev rules to process can have an impact. You skip that work and expect other people to do it instead? From buildsys at redhat.com Tue Jan 15 15:59:21 2008 From: buildsys at redhat.com (Build System) Date: Tue, 15 Jan 2008 10:59:21 -0500 Subject: rawhide report: 20080115 changes Message-ID: <200801151559.m0FFxL48014209@porkchop.devel.redhat.com> New package dragonplayer A simple video player for KDE 4 New package gnome-themes-extras Collection of metathemes for the Gnome desktop environment New package mkdst Source repository to tarball release tool New package perl-Spreadsheet-WriteExcel-Simple Simple single-sheet Excel document creator New package postgresql-plruby PostgreSQL Ruby Procedural Language New package qmmp Qt-based multimedia player Updated Packages: OpenEXR-1.6.1-2.fc9 ------------------- * Wed Jan 09 2008 Rex Dieter 1.6.1-2 - hack to omit unused-direct-shlib-dependencies - conditionalize -libs (f8+) anaconda-11.4.0.21-1 -------------------- * Mon Jan 14 2008 David Cantrell - 11.4.0.21-1 - Inherit from the right versions of pykickstart classes (clumens) - Update for nss files moving to /lib (clumens) - Remove unneeded arguments from detectHardware function (notting) - Symlink all udev support binaries to udevadm (notting) - /sbin/restorecon on /etc/modprobe.d (notting) - Add the kickstart syntax version to the kickstart file (clumens) - Require latest libdhcp to fix x86_64 SIGABRT problems at-3.1.10-20.fc9 ---------------- * Tue Jan 08 2008 Marcela Maslanova - 3.1.10-20 - used PIE instead of pie (with pie wasn't build on 64b successful) - rewrite PAM fail check - fix checking of settings setuid(s) * Mon Dec 03 2007 Marcela Maslanova - 3.1.10-19 - another problem with permission * Tue Oct 30 2007 Marcela Maslanova - 3.1.10-18 - Bug 398981: change on correct permissions at-spi-1.21.5-1.fc9 ------------------- * Mon Jan 14 2008 Matthias Clasen - 1.21.5-1 - Update to 1.21.5 atk-1.21.5-1.fc9 ---------------- * Mon Jan 14 2008 Matthias Clasen - 1.21.5-1 - Update to 1.21.5 autofs-1:5.0.3-2 ---------------- * Mon Jan 14 2008 Ian Kent - 5.0.3-2 - correct configure test for ldap page control functions. * Mon Jan 14 2008 Ian Kent - 5.0.3-1 - update source to version 5.0.3. cheese-2.21.5-1.fc9 ------------------- * Mon Jan 14 2008 Matthias Clasen 2.21.5-1 - Update to 2.21.5 ctrlproxy-3.0.5-1.fc9 --------------------- * Mon Jan 14 2008 Josh Boyer 3.0.5-1 - Update to latest upstream dcraw-8.81-1.fc9 ---------------- * Mon Jan 14 2008 Nils Philippsen - 8.81-1 - version 8.81 - add support for GPS data (#428600, patch by Ulrich Drepper) dhcp-12:4.0.0-2.fc9 ------------------- * Mon Jan 14 2008 David Cantrell - 12:4.0.0-2 - -fvisibility fails me again * Mon Jan 14 2008 David Cantrell - 12:4.0.0-1 - Upgrade to ISC dhcp-4.0.0 (#426634) - first ISC release to incorporate DHCPv6 protocol support - source tree now uses GNU autoconf/automake - Removed the libdhcp4client-static package * Tue Dec 04 2007 David Cantrell - 12:3.1.0-12 - Requires line fixes eel2-2.21.5-1.fc9 ----------------- * Mon Jan 14 2008 Matthias Clasen - 2.21.5-1 - Update to 2.21.5 eog-2.21.4-1.fc9 ---------------- * Mon Jan 14 2008 Matthias Clasen - 2.21.4-1 - Update to 2.21.4 evolution-2.21.5-1.fc9 ---------------------- * Mon Jan 14 2008 Matthew Barnes - 2.21.5-1.fc9 - Update to 2.21.5 - The backup-restore plugin is stable again. - Remove patch for RH bug #154360 (fixed upstream). - Remove patch for RH bug #166231 (obsolete, possibly fixed upstream). - Remove patch for RH bug #178295 (fixed upstream). - Remove patch for GNOME bug #362638 (fixed upstream). - Remove patch for GNOME bug #504030 (fixed upstream). - Remove patch for GNOME bug #507311 (fixed upstream). * Sat Jan 05 2008 Matthew Barnes - 2.21.4-2.fc9 - Add patch for GNOME bug #507311 (send Bug Buddy reports to the new BugBuddyBugs Bugzilla component). * Mon Dec 17 2007 Matthew Barnes - 2.21.4-1.fc9 - Update to 2.21.4 - Expunge unused patches. - Bump eds_version to 2.21.4 for new Camel functions. evolution-data-server-2.21.5-1.fc9 ---------------------------------- * Mon Jan 14 2008 Matthew Barnes - 2.21.5-1.fc9 - Update to 2.21.5 evolution-exchange-2.21.5-1.fc9 ------------------------------- * Mon Jan 14 2008 Matthew Barnes - 2.21.5-1.fc9 - Update to 2.21.5 firefox-3.0-0.beta2.10.nightly20080113.fc9 ------------------------------------------ * Sun Jan 13 2008 Christopher Aillon 3.0-0.beta2.10 - Update to latest trunk (20080113) - Fix the default prefs, homepage, and useragent string * Thu Jan 10 2008 Martin Stransky 3.0-0.beta2.9 - rebuilt agains xulrunner-devel-unstable fish-1.23.0-1.fc9 ----------------- * Mon Jan 14 2008 Oliver Falk - 1.23.0-1 - Update to fix #208780 - Remove openfix patch, included upstream now gail-1.21.5-1.fc9 ----------------- * Mon Jan 14 2008 Matthias Clasen - 1.21.5-1 - Update to 2.21.5 gcalctool-5.21.5-1.fc9 ---------------------- * Mon Jan 14 2008 Matthias Clasen - 5.21.5-1 - Update 5.21.5 gcl-2.6.7-17.fc9 ---------------- * Mon Jan 14 2008 Gerard Milmeister - 2.6.7-17 - exclude arch x86_64 for now * Thu Jan 03 2008 Alex Lancaster - 2.6.7-16 - Rebuild for new Tcl (8.5) gdal-1.5.0-2.fc9 ---------------- * Mon Jan 14 2008 Balint Cristian - 1.5.0-2 - fix perl dependency issue. gdm-1:2.21.2-0.2007.11.20.10.fc9 -------------------------------- * Tue Jan 15 2008 Dan Walsh - 1:2.21.2-0.2007.11.20.10 - Fix gdm.pam file so that session include system-auth happens after other session setup * Mon Jan 07 2008 Ray Strode - 1:2.21.2-0.2007.11.20.9 - hide guest account since it doesn't work * Fri Dec 21 2007 Ray Strode - 1:2.21.2-0.2007.11.20.8 - Fix background (and other settings) glib2-2.15.2-1.fc9 ------------------ * Mon Jan 14 2008 Matthias Clasen - 2.15.2-1 - Update to 2.15.2 gnome-desktop-2.21.5-1.fc9 -------------------------- * Mon Jan 14 2008 Matthias Clasen - 2.21.5-1 - Update to 2.21.5 gnome-games-1:2.21.5-1.fc9 -------------------------- * Tue Jan 15 2008 Matthias Clasen - 1:2.21.5-1 - Update to 2.21.5 gnome-keyring-2.21.5-1.fc9 -------------------------- * Mon Jan 14 2008 Matthias Clasen - 2.21.5-1 - Update to 2.21.5 * Tue Dec 18 2007 Matthias Clasen - 2.21.4-1 - Update to 2.21.4 * Fri Dec 07 2007 Matthias Clasen - 2.21.3.2-1 - Update to 2.21.3.2 gnome-menus-2.21.5-1.fc9 ------------------------ * Mon Jan 14 2008 Matthias Clasen - 2.21.4-1 - Update to 2.21.4 gnome-python2-desktop-2.21.2-1.fc9 ---------------------------------- * Mon Jan 14 2008 Matthew Barnes - 2.21.2-1.fc9 - Update to 2.21.2 gnome-speech-0.4.18-1.fc9 ------------------------- * Mon Jan 14 2008 Matthias Clasen - 0.4.18-1 - Update to 0.4.18 gnome-system-monitor-2.21.5-1.fc9 --------------------------------- * Mon Jan 14 2008 Matthias Clasen - 2.21.5-1 - Update to 2.21.5 gnome-terminal-2.21.5-1.fc9 --------------------------- * Tue Jan 15 2008 Matthias Clasen - 2.21.5-1 - Update to 2.21.5 gnome-themes-2.21.5-1.fc9 ------------------------- * Mon Jan 14 2008 Matthias Clasen - 2.21.5-1 - Update to 2.21.5 gramps-2.2.10-1.fc9 ------------------- * Mon Jan 14 2008 Brian Pepple - 2.2.10-1 - Update to 2.2.10. * Sun Oct 28 2007 Brian Pepple - 2.2.9-1 - Update to 2.2.9. - Update gtk icon scriptlet. * Sun Aug 05 2007 Brian Pepple - 2.2.8-5 - Update license tag. gtk-qt-engine-1:0.8-2.fc9 ------------------------- * Mon Jan 14 2008 Rex Dieter 1:0.8-2 - nslpluginviewer patch (kde#132138c#48) gtkhtml3-3.17.5-1.fc9 --------------------- * Mon Jan 14 2008 Matthew Barnes - 3.17.5-1.fc9 - Update to 3.17.5 gtksourceview2-2.1.0-1.fc9 -------------------------- * Mon Jan 14 2008 Matthias Clasen - 2.1.0-1 - Update to 2.1.0 gucharmap-2.21.5-1.fc9 ---------------------- * Tue Jan 15 2008 Matthias Clasen - 2.21.5-1 - Update to 2.21.5 gvfs-0.1.2-1.fc9 ---------------- horde-3.1.6-1.fc9 ----------------- * Fri Jan 11 2008 Brandon Holbrook 3.1.6-1 - Update to 3.1.6 icewm-1.2.35-1.fc9 ------------------ * Mon Jan 14 2008 - 1.2.35-1 - 1.2.35. - Missing BR: xorg-x11-fonts-truetype. (#351811) jday-2.4-2.fc9 -------------- kronolith-2.1.7-1.fc9 --------------------- * Mon Jan 14 2008 Brandon Holbrook 2.1.7-1 - Upgraded to 2.1.7 libXp-1.0.0-10.fc9 ------------------ * Tue Jan 15 2008 parag - 1.0.0-10 - Merge-Review #226082 - Removed XFree86-libs, xorg-x11-libs XFree86-devel, xorg-x11-devel as Obsoletes - Removed xorg-x11-deprecated-libs xorg-x11-deprecated-libs-devel as Obsoletes * Mon Jan 14 2008 parag - 1.0.0-9 - Merge-Review #226082 - Removed BR:pkgconfig - Removed zero-length README file libXpm-3.5.7-3.fc9 ------------------ * Tue Jan 15 2008 parag 3.5.7-3 - Merge-Review #226081 - Removed XFree86-libs, xorg-x11-libs XFree86-devel, xorg-x11-devel as Obsoletes - Bump release and correct changelog * Mon Jan 14 2008 parag 3.5.7-2 - Merge-Review #226081 - Removed BR:pkgconfig - Removed XFree86-libs, xorg-x11-libs XFree86-devel, xorg-x11-devel as Obsoletes - Removed zero-length README file libXrandr-1.2.2-2.fc9 --------------------- * Tue Jan 15 2008 parag 1.2.2-2 - Merge-Review #226083 - Removed BR:pkgconfig - Removed XFree86-libs, xorg-x11-libs XFree86-devel, xorg-x11-devel as Obsoletes - Removed zero-length README file libXrender-0.9.4-2.fc9 ---------------------- * Tue Jan 15 2008 parag 0.9.4-2 - Merge-Review #226084 - Removed BR:pkgconfig - Removed XFree86-libs, xorg-x11-libs XFree86-devel, xorg-x11-devel as Obsoletes - Removed zero-length README file libcap-1.10-31 -------------- * Mon Jan 14 2008 Karsten Hopp 1.10-30 - use cp -p in spec file to preserve file attributes (#225992) - add license file libdhcp-1.99.6-1.fc9 -------------------- * Mon Jan 14 2008 David Cantrell - 1.99.6-1 - Upgrade to libdhcp-1.99.6, fixes SIGABRT problems on x86_64 (#428511) * Mon Jan 14 2008 David Cantrell - 1.99.5-2 - Rebuild against dhcp-4.0.0 liberation-fonts-1.0-1.fc9 -------------------------- * Mon Jan 14 2008 Caius Chance - 1.0-1.fc9 - Resolves: rhbz#428596 (Liberation fonts need to be updated to latest font.) libgnomeui-2.21.5-1.fc9 ----------------------- * Mon Jan 14 2008 Matthias Clasen - 2.21.5-1 - Update to 2.21.5 * Sat Dec 22 2007 Matthias Clasen - 2.20.1.1-2 - Add the gvfs filechooser backend * Wed Oct 17 2007 Matthias Clasen - 2.20.1.1-1 - Update to 2.20.1.1 (fixes a crash in thumbnailing code) libgtop2-2.21.5-1.fc9 --------------------- * Mon Jan 14 2008 Matthias Clasen - 2.21.5-1 - Update to 2.21.5 libprelude-0.9.16.1-1.fc9 ------------------------- * Mon Jan 14 2008 Steve Grubb 0.9.16.1-1 - moved to new upstream version 0.9.16.1 libpreludedb-0.9.14.1-1.fc9 --------------------------- * Mon Jan 14 2008 Steve Grubb 0.9.14.1-1 - new upstream version 0.9.14.1 libvirt-cim-0.1-7.fc9 --------------------- * Mon Jan 14 2008 Dan Smith - 0.1-7 - Update to offical upstream release - Patch source to fix parallel make issue until fixed upstream libwnck-2.21.5-1.fc9 -------------------- * Mon Jan 14 2008 Matthias Clasen - 2.21.5-1 - Update to 2.21.5 man-pages-2.75-2.fc9 -------------------- * Fri Jan 11 2008 Ivana Varekova - 2.75-2 - update crypt.3 man page * Fri Jan 11 2008 Ivana Varekova - 2.75-1 - update to 2.75 - remove fs page patch * Mon Dec 17 2007 Ivana Varekova - 2.73-1 - update to 2.73 mkinitrd-6.0.28-2.fc9 --------------------- * Mon Jan 14 2008 David Cantrell - 6.0.28-2 - Rebuild for new libdhcp mod_fcgid-2.2-3.fc9 ------------------- * Mon Jan 14 2008 Paul Howarth 2.2-3 - Update SELinux policy to fix occasional failures on restarts (move shared memory file into /var/run/mod_fcgid directory) moodle-1.8.4-1.fc9 ------------------ * Sat Jan 12 2008 Jon Ciesla - 1.8.4-1 - Upgrade to 1.8.4, fix CVE-2008-0123. - Added Tamil (Sri Lanka) support. nautilus-2.21.5-1.fc9 --------------------- * Mon Jan 14 2008 Matthias Clasen - 2.21.5-1 - Update to 2.21.5 * Tue Jan 08 2008 Matthias Clasen - 2.21.2-1 - Update to 2.21.2 * Sun Dec 23 2007 Matthias Clasen - 2.21.1-2 - Fix extensiondir nautilus-open-terminal-0.8-3.fc9 -------------------------------- * Thu Jan 24 2008 Josh Boyer - 0.8-2 - Grab SVN snapshot to fix extension directory and building against newer nautilus ncurses-5.6-13.20080112.fc9 --------------------------- * Mon Jan 14 2008 Miroslav Lichvar 5.6-13.20080112 - update to patch 20080112 - make -libs, -base, -term subpackages - obsolete termcap and libtermcap - update urxvt entry nspluginwrapper-0.9.91.5-20.fc9 ------------------------------- * Mon Jan 14 2008 Martin Stransky 0.9.91.5-20 - fixed #426176 - Orphaned npviewer.bin processes openldap-2.4.7-1.fc9 -------------------- * Mon Jan 14 2008 Jan Safranek 2.4.7-1.fc9 - new upstream version (openldap-2.4.7) openoffice.org-1:2.4.0-1.3.fc9 ------------------------------ * Mon Jan 14 2008 Caolan McNamara - 1:2.4.0-1.3 - fix broken requires orca-2.21.5-1.fc9 ----------------- * Mon Jan 14 2008 Matthias Clasen - 2.21.5-1 - Update to 2.21.5 pam-0.99.8.1-15.fc9 ------------------- * Mon Jan 14 2008 Tomas Mraz 0.99.8.1-15 - merge review fixes (#226228) * Tue Jan 08 2008 Tomas Mraz 0.99.8.1-14 - support for sha256 and sha512 password hashes - account expiry checks moved to unix_chkpwd helper * Wed Jan 02 2008 Tomas Mraz 0.99.8.1-13 - wildcard match support in pam_tty_audit (by Miloslav Trma??) paps-0.6.8-3.fc9 ---------------- * Tue Jan 15 2008 Akira TAGOH - 0.6.8-3 - Put %%Pages: after %%Trailer. (#424951) parted-1.8.8-2.fc9 ------------------ * Sun Jan 13 2008 David Cantrell - 1.8.8-2 - Move libparted libraries to /lib (#428420) pitivi-0.11.1-2.fc9 ------------------- * Mon Jan 14 2008 Jeffrey C. Ollie - 0.11.1-2 - Add requirement for python-setuptools. (BZ#426855) polyester-1.95-1.fc9 -------------------- * Mon Jan 14 2008 Sebastian Vahl - 1.95-1 - Update to kde4 version: 1.95 - update %summary and %description (only style is ported to kde4) prelude-lml-0.9.11-1.fc9 ------------------------ * Mon Jan 14 2008 Steve Grubb 0.9.11-1 - new upstream version 0.9.11 prelude-manager-0.9.10-1.fc9 ---------------------------- * Mon Jan 14 2008 Steve Grubb 0.9.10-1 - new upstream version 0.9.10 prewikka-0.9.13-1.fc9 --------------------- * Mon Jan 14 2008 Steve Grubb 0.9.13-1 - new upstream version 0.9.13 * Sun Apr 08 2007 Thorsten Scherf 0.9.10-1 - moved to upstream version 0.9.10 pymsn-0.3.0-1.fc9 ----------------- * Mon Jan 14 2008 Brian Pepple - 0.3.0-1 - Update to 0.3.0. - Add BR for pyOpenSSL, python-crypto, python-adns, and pyobject2. python-paramiko-1.7.1-3.fc9 --------------------------- * Mon Jan 14 2008 Jeffrey C. Ollie - 1.7.1-3 - Update to latest Python packaging guidelines. - Apply patch that fixes insecure use of RandomPool. ruby-1.8.6.111-7.fc9 -------------------- * Tue Jan 15 2008 Akira TAGOH - 1.8.6.111-7 - Revert the change of libruby-static.a. (#428384) * Fri Jan 11 2008 Akira TAGOH - 1.8.6.111-6 - Fix an unnecessary replacement for shebang. (#426835) * Fri Jan 04 2008 Akira TAGOH - 1.8.6.111-5 - Rebuild. selinux-policy-3.2.5-12.fc9 --------------------------- * Mon Jan 14 2008 Dan Walsh 3.2.5-12 - Allow users to execute all files in homedir, if boolean set - Allow mount to read samba config sepostgresql-8.2.6-1.147.fc9 ---------------------------- sound-juicer-2.21.2-1.fc9 ------------------------- * Mon Jan 14 2008 Matthias Clasen - 2.21.2-1 - Update to 2.21.2 system-config-language-1.2.15-2.fc9 ----------------------------------- * Tue Jan 15 2008 Lingning Zhang - 1.2.15-2 - fix bug428391. system-config-netboot-0.1.45-1.fc9 ---------------------------------- * Mon Jan 14 2008 Radek Brich - 0.1.45-1 - add more items to diskless/files - fix permissions of /tftpboot/linux-install - fix bad SELinux context of linux-install/*/vmlinuz - rename locale sr at Latn to sr at latin (glibc change) texlive-2007-9.fc9 ------------------ * Mon Jan 14 2008 Jindrich Novy - 2007-9 - unify texlive and texlive-fonts filelists - package texdoc and texdoctk to a separate subpackage texlive-doc, because of the Perl-Tk dependencies and logic texlive-texmf-2007-7.fc9 ------------------------ * Mon Jan 14 2008 Jindrich Novy - 2007-7 - remove Requires: htmlview (#428506) - texlive-doc -> texlive-texmf-doc * Fri Jan 04 2008 Jindrich Novy - 2007-6 - require tex-preview (#425805) * Wed Jan 02 2008 Jindrich Novy - 2007-5 - remove preview, it is to be packaged separately (#425805) - add japanese ptex fmtutil configuration, thanks to Patrice Dumas - update texlive-texmf-fonts package description to reflect texlive and texlive-fonts merge (related: #426388) texlive-texmf-errata-2007-1.fc9 ------------------------------- * Mon Jan 14 2008 Jindrich Novy - 2007-1 - texlive-doc-errata -> texlive-texmf-errata-doc tomboy-0.9.4-1.fc9 ------------------ * Mon Jan 14 2008 Matthias Clasen - 0.9.4-1 - Update to 0.9.4 * Tue Jan 08 2008 Matthias Clasen - 0.9.3-1 - Update to 0.9.3 ustr-1.0.3-2.fc9 ---------------- * Mon Jan 14 2008 James Antill - 1.0.3-2 - Build new upstream in Fedora vim-2:7.1.228-1.fc9 ------------------- * Mon Jan 14 2008 Karsten Hopp 7.1.228-1 - patchlevel 228 - allow overwriting WITH_SELING at build time (#427710) * Thu Jan 10 2008 Karsten Hopp 7.1.214-1 - patchlevel 214 * Mon Jan 07 2008 Karsten Hopp 7.1.211-1 - patchlevel 211 xclip-0.10-2.fc9 ---------------- * Mon Jan 14 2008 Tom "spot" Callaway 0.10-2 - enable utf8 support by default xfce-utils-4.4.2-3.fc9 ---------------------- * Mon Jan 14 2008 Kevin Fenzi - 4.4.2-3 - Patch correct file xorg-x11-fonts-7.2-6.fc9 ------------------------ * Mon Jan 14 2008 Tom "spot" Callaway - 7.2-6 - IBM refused to relicense ibm-type1 fonts with permission to modify, so they were dropped (bugzilla 317641) - Meltho Syrian fonts (misc-meltho) have a bad license, upstream did not respond to request for relicensing, so they were dropped. This also means that the -syriac subpackage has been removed. (bugzilla 317641) xulrunner-1.9-0.beta2.10.nightly20080113.fc9 -------------------------------------------- * Sun Jan 13 2008 Christopher Aillon 1.9-0.beta2.10 - Update to latest trunk (2008-01-13) - Use CFLAGS instead of configure arguments - Random cleanups: BuildRequires, scriptlets, prefs, etc. Broken deps for i386 ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.i386 requires libgtkembedmoz.so epiphany-extensions - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.i386 requires libgtkembedmoz.so gnome-web-photo - 0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 icewm - 1.2.35-1.fc9.i386 requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 texlive-doc - 2007-9.fc9.i386 requires texlive-texmf-doc-errata = 0:2007 tkinter - 2.5.1-20.fc9.i386 requires libTix8.4.so vtk - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtcl8.4.so Broken deps for x86_64 ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) icewm - 1.2.35-1.fc9.x86_64 requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 texlive-doc - 2007-9.fc9.x86_64 requires texlive-texmf-doc-errata = 0:2007 tkinter - 2.5.1-20.fc9.x86_64 requires libTix8.4.so()(64bit) vtk - 5.0.3-20.fc8.x86_64 requires libtk8.4.so()(64bit) vtk - 5.0.3-20.fc8.x86_64 requires libtcl8.4.so()(64bit) vtk - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-python - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-python - 5.0.3-20.fc8.x86_64 requires libtk8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.x86_64 requires libtcl8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.i386 requires libtk8.4.so vtk-tcl - 5.0.3-20.fc8.i386 requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.x86_64 requires libtk8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.x86_64 requires libtcl8.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.ppc requires libgtkembedmoz.so epiphany-extensions - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.ppc requires libgtkembedmoz.so gnome-web-photo - 0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 icewm - 1.2.35-1.fc9.ppc requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 monodevelop - 0.17-4.fc9.ppc requires boo texlive-doc - 2007-9.fc9.ppc requires texlive-texmf-doc-errata = 0:2007 tkinter - 2.5.1-20.fc9.ppc requires libTix8.4.so vtk - 5.0.3-20.fc8.ppc requires libtcl8.4.so vtk - 5.0.3-20.fc8.ppc requires libtk8.4.so vtk - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc requires libtk8.4.so vtk-python - 5.0.3-20.fc8.ppc requires libtcl8.4.so vtk-python - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc requires libtk8.4.so vtk-tcl - 5.0.3-20.fc8.ppc requires libtcl8.4.so vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) Broken deps for ppc64 ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) icewm - 1.2.35-1.fc9.ppc64 requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 perl-Test-AutoBuild-darcs - 1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 texlive-doc - 2007-9.fc9.ppc64 requires texlive-texmf-doc-errata = 0:2007 tkinter - 2.5.1-20.fc9.ppc64 requires libTix8.4.so()(64bit) vtk - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-python - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtk8.4.so()(64bit) vtk-tcl - 5.0.3-20.fc8.ppc64 requires libtcl8.4.so()(64bit) From opensource at till.name Tue Jan 15 16:02:07 2008 From: opensource at till.name (Till Maas) Date: Tue, 15 Jan 2008 17:02:07 +0100 Subject: Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <668bb39a0801150750g5360417bvc208b7d87587c4ed@mail.gmail.com> References: <478CB7A3.8000206@redhat.com> <668bb39a0801150750g5360417bvc208b7d87587c4ed@mail.gmail.com> Message-ID: <200801151702.12768.opensource@till.name> On Tue January 15 2008, Micha? Bentkowski wrote: > I think that what we can do is a wrapper (e.g. in vim-common package) > which would check which vim is installed and run it. If both are, it > could, say, prefer -X11 over -enhanced by default but it should be > also possible to set it in a config file. > What do you think? Alternatives (man alternatives) can be used for this, there is no need to write a wrapper. Still the question why someone would want to run vim from the vim-enhanced package if vim-X11 is also installed is not answered. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From rc040203 at freenet.de Tue Jan 15 11:25:00 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 15 Jan 2008 12:25:00 +0100 Subject: Fedora bug triage - workflow proposal In-Reply-To: References: Message-ID: <1200396300.5174.158.camel@beck.corsepiu.local> On Mon, 2008-01-14 at 23:46 -0500, Jon Stanley wrote: > 2) Triage team looks at bug report, determines if dupe or > insufficient information exists to solve it. If there is not enough > information in the bug, then triage team puts the bug in NEEDINFO. As > you will see below, this state has a finite life cycle associated with > it. I am having doubts the bug triage team will be able to judge on whether a PR is legitimate or not but on trivial cases. I.e. I would expect them to end up spam essentially filtering. > 3) Assuming bug survives through the triage team, it changes state to > ASSIGNED To whom? IMO, the real problem is getting a competent volunteer involved who is likely sufficiently knowledgeable about a particular issue. i.e. to communicate such issues, such that a volunteer can take action when _he_ wants. That said, I consider lack of communication and "bug arbitration" to be the actual flaw behind current bug tracking workflow in Fedora. Ralf From singularitaet at gmx.net Tue Jan 15 16:12:24 2008 From: singularitaet at gmx.net (Stefan Grosse) Date: Tue, 15 Jan 2008 17:12:24 +0100 Subject: texlive + pdftex +kile: very slow In-Reply-To: <200801151515.58308.jamatos@fc.up.pt> References: <200801151606.59141.singularitaet@gmx.net> <200801151515.58308.jamatos@fc.up.pt> Message-ID: <200801151712.24830.singularitaet@gmx.net> On Tuesday 15 January 2008 04:15:58 pm Jos? Matos wrote: JM> No problem here both on fc8 with Jind?ich texlive packages and lyx as well JM> as with rawhide. JM> JM> It runs fast and I do not notice any difference from tetex in terms of JM> speed. Thanks, so it seems a problem with kile? Stefan From kevin at scrye.com Tue Jan 15 16:24:52 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Tue, 15 Jan 2008 09:24:52 -0700 Subject: Fedora bug triage - workflow proposal In-Reply-To: References: Message-ID: <20080115092452.245d5604@ghistelwchlohm.scrye.com> On Mon, 14 Jan 2008 23:46:36 -0500 jonstanley at gmail.com ("Jon Stanley") wrote: > Well, it was a great session at FUDCon. A lot came out of it, and I'm > going to put some of them down here. The work flow suggested below I'd > a FESco vote on, since it really affects you guys. Great. You might want to use (optional) http://fedoraproject.org/wiki/JesseKeating/FESCoProposalTemplateDraft and write up a page for FESCo to refer to for this. > This work flow was > discussed between myself, John Poelstra, and Will Woods at the Sunday > hackfest, and we agree that this is the correct way to move forward, > however, we want community input and buy-in on this, since it has > pretty far-reaching consequences. Sorry I couldn't make it on sunday... had to catch a plane. ;) > Here is the lifecycle of a bug: ...snipp... Looks great to me. > Note that at any step of the above process, the maintainer can "fast > track" the bug, and change it to ASSIGNED. The triage team is not > going to look at bugs that are not in NEW or NEEDINFO state. On the What if the bug is put in NEEDINFO(maintainer) by the reporter? Ie, they have provided info or need to ask the maintainer about something, but the maintainer isn't responding? Are those closed? They probibly shouldn't be... > flip side of that, it is not a maintainer's responsibility to look at > bugs that are in NEW any longer. They can focus their energy on the > bugs that are ASSIGNED to them. > > Also, maintainers should not be allowed to set priority on bugs. > Setting severity is fine. Only QA or releng should set priorities. > This allows us to look at things in a sane manner (which is impossible > now since severity and priority fields come from /dev/urandom > seemingly), and possibly lessen the reliance on blocker bugs (though > blockers are useful in their own right, so don't think that we are > going to eliminate them any time soon). I'm not sure how usefull this will be. Maintainers pretty much ignore priority now, as reporter (or any package maintainer) can set it... > It was also decided that when a bug is in NEEDINFO for one month, it > will be closed. Maintainers would need to realize that putting a bug > in NEEDINFO is putting it on the fast track for closure. What about the above case of NEEDINFO(maintainer)? > I think that's all that I have to say on this topic right now, let me > know if I'm missing anything or this is complete hogwash :) I think this is great! ;) I'd be happy to help with triage... > -Jon kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Tue Jan 15 16:27:29 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 15 Jan 2008 11:27:29 -0500 Subject: anaconda - unhandled exception In-Reply-To: <20080115134539.GB9011@dhcp83-45.boston.redhat.com> References: <478C68EC.6030201@mindspring.com> <478C7385.80308@gmail.com> <1200398322.2903.2.camel@scrappy.miketc.com> <20080115134539.GB9011@dhcp83-45.boston.redhat.com> Message-ID: <1200414449.3433.4.camel@aglarond.local> On Tue, 2008-01-15 at 08:45 -0500, Chris Lumens wrote: > > Keep it up Jeremy, ya bout got it licked! > > Not to be a jerk or anything, but you're aware at least five other > people work on anaconda, right? And I'm not even really around this month (other than sporadic looking at email). Luckily, we've got a team of other rock stars these days[1] helping out on anaconda these days and it doesn't all just fall to me anymore. Jeremy [1] And have for a while at this point. Keep up Mike! :-) From jakub.rusinek at gmail.com Tue Jan 15 16:31:04 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Tue, 15 Jan 2008 17:31:04 +0100 Subject: compilation architecture In-Reply-To: <20080115165601.67bdf81e.mschwendt.tmp0701.nospam@arcor.de> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <1200341643.5433.81.camel@localhost> <200801151257.m0FCvREV008743@laptop13.inf.utfsm.cl> <5e92ee3f0801150507y2b9f31a5mcc7fd14b5760e384@mail.gmail.com> <20080115151925.652f0500.mschwendt.tmp0701.nospam@arcor.de> <5e92ee3f0801150711o9108b7apf83f4ae132b894e4@mail.gmail.com> <1200411358.15130.271.camel@localhost.localdomain> <5e92ee3f0801150726v2d708d70x7e51087f0bb0a254@mail.gmail.com> <20080115165601.67bdf81e.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <5e92ee3f0801150831t685810f1jb2ac41c7975a1675@mail.gmail.com> Installing openSUSE again would complicate my life. Again. But if it's so necessary, I can install it one more time. My hardware and configuration? http://www.smolts.org/show_all?UUID=c8dbb9d3-a9bd-4ba6-b92e-4a294ba5a95f -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamatos at fc.up.pt Tue Jan 15 16:32:39 2008 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Tue, 15 Jan 2008 16:32:39 +0000 Subject: texlive + pdftex +kile: very slow In-Reply-To: <200801151712.24830.singularitaet@gmx.net> References: <200801151606.59141.singularitaet@gmx.net> <200801151515.58308.jamatos@fc.up.pt> <200801151712.24830.singularitaet@gmx.net> Message-ID: <200801151632.39422.jamatos@fc.up.pt> On Tuesday 15 January 2008 16:12:24 Stefan Grosse wrote: > Thanks, so it seems a problem with kile? That seems strange, nevertheless try to run pdflatex from the command line and see what is going on. I would expect kile to be not guilty here and the command line will point where the problem is... > Stefan -- Jos? Ab?lio From zboszor at freemail.hu Tue Jan 15 16:41:24 2008 From: zboszor at freemail.hu (Zoltan Boszormenyi) Date: Tue, 15 Jan 2008 17:41:24 +0100 Subject: SpotLight into fedora In-Reply-To: <5e92ee3f0801150527i11c499ebwd2e24e55f23c3356@mail.gmail.com> References: <1200399905.14798.13.camel@localhost.localdomain> <5e92ee3f0801150429j4641feby956f0831e8072f7e@mail.gmail.com> <539333cb0801150512o4cabe3b5w2d61a72fc91c7095@mail.gmail.com> <5e92ee3f0801150527i11c499ebwd2e24e55f23c3356@mail.gmail.com> Message-ID: <478CE234.3090901@freemail.hu> Jakub 'Livio' Rusinek ?rta: > Not the same. SIMILLIAR. Sure you meant "Silmarillion". From subhodip at fedoraproject.org Tue Jan 15 16:44:24 2008 From: subhodip at fedoraproject.org (subhodip biswas) Date: Tue, 15 Jan 2008 22:14:24 +0530 Subject: SpotLight into fedora In-Reply-To: <478CE234.3090901@freemail.hu> References: <1200399905.14798.13.camel@localhost.localdomain> <5e92ee3f0801150429j4641feby956f0831e8072f7e@mail.gmail.com> <539333cb0801150512o4cabe3b5w2d61a72fc91c7095@mail.gmail.com> <5e92ee3f0801150527i11c499ebwd2e24e55f23c3356@mail.gmail.com> <478CE234.3090901@freemail.hu> Message-ID: <539333cb0801150844o2e34bffcob66745345002b16f@mail.gmail.com> ah ... sorry i forgot to mention that .. thanx for reminding On Jan 15, 2008 10:11 PM, Zoltan Boszormenyi wrote: > Jakub 'Livio' Rusinek ?rta: > > Not the same. SIMILLIAR. > > Sure you meant "Silmarillion". > > > > -- > > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Regards Subhodip Biswas GPG key : FAEA34AB Server : pgp.mit.edu http://subhodipbiswas.wordpress.com http:/www.fedoraproject.org/wiki/SubhodipBiswas From mmcgrath at redhat.com Tue Jan 15 16:47:38 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 15 Jan 2008 10:47:38 -0600 (CST) Subject: Where are the CD ISO's? (fwd) Message-ID: What are the plans for media support for Fedora 9? -Mike ---------- Forwarded message ---------- Date: Tue, 15 Jan 2008 10:32:33 +0100 From: Heinrich Winther Christensen To: webmaster at fedoraproject.org Subject: Where are the CD ISO's? Hi... My old but useful server doesn't have DVD, so I desperately need ISO's for CD's. Where will I find them? Heinrich -- Fedora-websites-list mailing list Fedora-websites-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-websites-list From subhodip at fedoraproject.org Tue Jan 15 16:53:21 2008 From: subhodip at fedoraproject.org (subhodip biswas) Date: Tue, 15 Jan 2008 22:23:21 +0530 Subject: Where are the CD ISO's? (fwd) In-Reply-To: References: Message-ID: <539333cb0801150853j6f417db2q4027fffbf54e93d3@mail.gmail.com> Yeah .. this is a good issue .. many of fedora user here stick to older version because cd iso in unavailable .... and live cd does not serve their purpose .. -- Regards Subhodip Biswas GPG key : FAEA34AB Server : pgp.mit.edu http://subhodipbiswas.wordpress.com http:/www.fedoraproject.org/wiki/SubhodipBiswas From jkeating at redhat.com Tue Jan 15 16:53:15 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 Jan 2008 11:53:15 -0500 Subject: Where are the CD ISO's? (fwd) In-Reply-To: References: Message-ID: <20080115115315.0307581e@redhat.com> On Tue, 15 Jan 2008 10:47:38 -0600 (CST) Mike McGrath wrote: > What are the plans for media support for Fedora 9? Generating split media as part of the official compose process. Alpha will see DVD + split CD media. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From snecklifter at gmail.com Tue Jan 15 17:01:29 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Tue, 15 Jan 2008 17:01:29 +0000 Subject: Fedora bug triage - workflow proposal In-Reply-To: <478CB717.4000202@fedoraproject.org> References: <478CB717.4000202@fedoraproject.org> Message-ID: <364d303b0801150901i20b6b30cs923506c0ebc2e3d8@mail.gmail.com> On 15/01/2008, Rahul Sundaram wrote: > Jon Stanley wrote: > > > > 1) Reporter files a bug report, it originates in NEW state > > Can we renamed this state to UNCONFIRMED? NEW or UNCONFIRMED, its six of one, half-a-dozen of the other... > > 2) Triage team looks at bug report, determines if dupe or > > insufficient information exists to solve it. If there is not enough > > information in the bug, then triage team puts the bug in NEEDINFO. As > > you will see below, this state has a finite life cycle associated with > > it. > > 3) Assuming bug survives through the triage team, it changes state to > > ASSIGNED (triage team can put it in either NEEDINFO or CLOSED, as > > appropriate). Note that per the definition[1], ASSIGNED does not mean > > that someone has actually agreed to take action, simply that the issue > > is well defined and triaged accordingly > > Wouldn't a state like TRIAGED be more meaningful then? ASSIGNED > frequently is assumed to be assuming ownership by the maintainers. ASSIGNED is easier and more understandable to people who have language barriers to contend with. > > 4) Once a developer has taken responsibility for a bug and is > > actively working on it, the state transitions to ON_DEV. Sounds good. > If ASSIGNED is renamed to TRIAGED, then this state can be known as > ASSIGNED instead. I'm keen not to get lost in arguing about the names of states. I think all is fine as is - the issue here is workflow and what is best for that. > > Setting severity is fine. Only QA or releng should set priorities. > > This allows us to look at things in a sane manner (which is impossible > > now since severity and priority fields come from /dev/urandom > > seemingly), and possibly lessen the reliance on blocker bugs (though > > blockers are useful in their own right, so don't think that we are > > going to eliminate them any time soon). These seemed to be quite useful in the run-up to F8 release. > I believe bugzilla folks are recommending the usage of flags over > blocker bugs. > > > It was also decided that when a bug is in NEEDINFO for one month, it > > will be closed. Maintainers would need to realize that putting a bug > > in NEEDINFO is putting it on the fast track for closure. Yes, a large number of bugs are fire-and-forget where a fix is found but the reporter forgets to close the bug. > Would a stock message be send to the bug reporters when closing bugs? I'm currently using: As indicated previously there has been no update on the progress of this bug therefore I am closing it as INSUFFICIENT_DATA. Please re-open if the issue still occurs for you and I will try to assist in its resolution. Thank you for taking the time to report the initial bug. though I think it may need improvement. > Would a separate Fedora page in bugzilla.redhat.com be useful? One issue the triage team have at the moment is the ten different wiki pages all making mention of bug triaging. We aim to tackle this as a priority. A separate fedora bugzilla instance is under discussion but is obviously a mammoth task. Jon: ACK - I like all of the above. Do we have a procedure if a maintainer does not respond to a bug - there are a few... :) Cheers -- Christopher Brown http://www.chruz.com From jonathan.underwood at gmail.com Tue Jan 15 17:05:55 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 15 Jan 2008 17:05:55 +0000 Subject: texlive + pdftex +kile: very slow In-Reply-To: <200801151606.59141.singularitaet@gmx.net> References: <200801151606.59141.singularitaet@gmx.net> Message-ID: <645d17210801150905t344d9226p30b96958e8d25c07@mail.gmail.com> On 15/01/2008, Stefan Grosse wrote: > Hi, > > I have upgraded my tex to texlive from rawhide. Whenever I run pdftex on a > document (unfortunately this is necessary for the beamer package) it takes > 1-2 minutes on even a very small text kile consumes during this time ~100% > cpu. > > I did not have the same problem with tetex. > > Is someone else observing the same? Is it a pdftex bug? Or kile bug? > It would be helpful if you would produce a simple (minimal) tex file which reproduced the problem, and filed a bug report attaching that file. From clumens at redhat.com Tue Jan 15 17:09:42 2008 From: clumens at redhat.com (Chris Lumens) Date: Tue, 15 Jan 2008 12:09:42 -0500 Subject: Where are the CD ISO's? (fwd) In-Reply-To: <20080115115315.0307581e@redhat.com> References: <20080115115315.0307581e@redhat.com> Message-ID: <20080115170942.GA31981@dhcp83-45.boston.redhat.com> > > What are the plans for media support for Fedora 9? > > Generating split media as part of the official compose process. Alpha > will see DVD + split CD media. Hooray! Writing all that split media code was hard, so I'm glad we'll actually be making use of it again. - Chris From mr.ecik at gmail.com Tue Jan 15 17:19:46 2008 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Tue, 15 Jan 2008 18:19:46 +0100 Subject: Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <200801151702.12768.opensource@till.name> References: <478CB7A3.8000206@redhat.com> <668bb39a0801150750g5360417bvc208b7d87587c4ed@mail.gmail.com> <200801151702.12768.opensource@till.name> Message-ID: <668bb39a0801150919j192c0d97r1d5b482da749dd75@mail.gmail.com> 15-01-08, Till Maas napisa?(a): > Alternatives (man alternatives) can be used for this, there is no need to > write a wrapper. Still the question why someone would want to run vim from > the vim-enhanced package if vim-X11 is also installed is not answered. But it's possible that someone might like to do so. We shouldn't force anybody to do anything. If someone wants to have -X11 and -enhanced installed and use the second one - that's his business, he ought not be prevented from doing that. -- Micha? Bentkowski mr.ecik at gmail.com From joachim.frieben at googlemail.com Tue Jan 15 17:43:56 2008 From: joachim.frieben at googlemail.com (Joachim Frieben) Date: Tue, 15 Jan 2008 18:43:56 +0100 Subject: Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <200801151702.12768.opensource@till.name> References: <478CB7A3.8000206@redhat.com> <668bb39a0801150750g5360417bvc208b7d87587c4ed@mail.gmail.com> <200801151702.12768.opensource@till.name> Message-ID: <1c252d490801150943q677a6be3n3b48e442edd1697@mail.gmail.com> 2008/1/15 Till Maas : > Alternatives (man alternatives) can be used for this, there is no need to > write a wrapper. Still the question why someone would want to run vim from > the vim-enhanced package if vim-X11 is also installed is not answered. > > Regards, > Till vim-X11 has a lot more dependencies than vim-enhanced, in particular on GNOME. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jochen at herr-schmitt.de Tue Jan 15 17:44:09 2008 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 15 Jan 2008 18:44:09 +0100 Subject: Trouble to initiate koji scratch build Message-ID: <478CF0E9.1060702@herr-schmitt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, when I try to initate a koji scratch build, I will get the following messages: $ koji -scratch build dist-fc9-gcc43 gnu-smalltalk-3.0-0.fc9.src.rpm Traceback (most recent call last): File "/usr/bin/koji", line 3915, in session = koji.ClientSession(options.server,session_opts) File "/usr/lib/python2.5/site-packages/koji/__init__.py", line 1100, in __init__ self.setSession(sinfo) File "/usr/lib/python2.5/site-packages/koji/__init__.py", line 1126, in setSession self.proxy = self.proxyClass(url,**self.proxyOpts) File "/usr/lib64/python2.5/xmlrpclib.py", line 1414, in __init__ raise IOError, "unsupported XML-RPC protocol" IOError: unsupported XML-RPC protocol It will be nice, if anyone can give me a hint to solve this issue. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHjPDeT2AHK6txfgwRAlDaAJ9Fhiq5zXmQD0h3+DbZdmV9BAXeTwCfX2tc tsyS8omhf20WaOHK5JON2gw= =saIX -----END PGP SIGNATURE----- From mtasaka at ioa.s.u-tokyo.ac.jp Tue Jan 15 17:52:59 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 16 Jan 2008 02:52:59 +0900 Subject: Trouble to initiate koji scratch build In-Reply-To: <478CF0E9.1060702@herr-schmitt.de> References: <478CF0E9.1060702@herr-schmitt.de> Message-ID: <478CF2FB.3000503@ioa.s.u-tokyo.ac.jp> Jochen Schmitt wrote, at 01/16/2008 02:44 AM +9:00: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > when I try to initate a koji scratch build, I will get the following > messages: > > $ koji -scratch build dist-fc9-gcc43 gnu-smalltalk-3.0-0.fc9.src.rpm The correct command is $ koji build --scratch dist-f9-gcc43 Regards, Mamoru From fedora at dm.cobite.com Tue Jan 15 17:57:09 2008 From: fedora at dm.cobite.com (David Mansfield) Date: Tue, 15 Jan 2008 12:57:09 -0500 Subject: Fedora bug triage - workflow proposal In-Reply-To: <364d303b0801150901i20b6b30cs923506c0ebc2e3d8@mail.gmail.com> References: <478CB717.4000202@fedoraproject.org> <364d303b0801150901i20b6b30cs923506c0ebc2e3d8@mail.gmail.com> Message-ID: <1200419829.3001.29.camel@gandalf.cobite.com> On Tue, 2008-01-15 at 17:01 +0000, Christopher Brown wrote: > On 15/01/2008, Rahul Sundaram wrote: > > Jon Stanley wrote: > > > > > > 1) Reporter files a bug report, it originates in NEW state > > > > Can we renamed this state to UNCONFIRMED? > > NEW or UNCONFIRMED, its six of one, half-a-dozen of the other... > > > > 2) Triage team looks at bug report, determines if dupe or > > > insufficient information exists to solve it. If there is not enough > > > information in the bug, then triage team puts the bug in NEEDINFO. As > > > you will see below, this state has a finite life cycle associated with > > > it. > > > 3) Assuming bug survives through the triage team, it changes state to > > > ASSIGNED (triage team can put it in either NEEDINFO or CLOSED, as > > > appropriate). Note that per the definition[1], ASSIGNED does not mean > > > that someone has actually agreed to take action, simply that the issue > > > is well defined and triaged accordingly > > > > Wouldn't a state like TRIAGED be more meaningful then? ASSIGNED > > frequently is assumed to be assuming ownership by the maintainers. > > ASSIGNED is easier and more understandable to people who have language > barriers to contend with. > > > > 4) Once a developer has taken responsibility for a bug and is > > > actively working on it, the state transitions to ON_DEV. > > Sounds good. > > > If ASSIGNED is renamed to TRIAGED, then this state can be known as > > ASSIGNED instead. > > I'm keen not to get lost in arguing about the names of states. I think > all is fine as is - the issue here is workflow and what is best for > that. > I disagree and agree with the original poster, more or less, and I think names ARE important. Do you name a variable tracking weight as 'height' in your program? No. So names are important AND they should be understandable for non-native speakers. I believe using ASSIGNED when it's _not_ assigned is a bad design choice, and using ON_DEV for ASSIGNED is also a bad choice, but I agree with you, TRIAGED is a bad choice for the WAITING_FOR_MANPOWER state... David From opensource at till.name Tue Jan 15 17:57:21 2008 From: opensource at till.name (Till Maas) Date: Tue, 15 Jan 2008 18:57:21 +0100 Subject: Trouble to initiate koji scratch build In-Reply-To: <478CF0E9.1060702@herr-schmitt.de> References: <478CF0E9.1060702@herr-schmitt.de> Message-ID: <200801151857.26721.opensource@till.name> On Tue January 15 2008, Jochen Schmitt wrote: > when I try to initate a koji scratch build, I will get the following > messages: > > $ koji -scratch build dist-fc9-gcc43 gnu-smalltalk-3.0-0.fc9.src.rpm > It will be nice, if anyone can give me a hint to solve this issue. Did you try it with "--scratch"? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From Jochen at herr-schmitt.de Tue Jan 15 18:08:13 2008 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Tue, 15 Jan 2008 19:08:13 +0100 Subject: Trouble to initiate koji scratch build In-Reply-To: <478CF2FB.3000503@ioa.s.u-tokyo.ac.jp> References: <478CF0E9.1060702@herr-schmitt.de> <478CF2FB.3000503@ioa.s.u-tokyo.ac.jp> Message-ID: <478CF68D.2010206@herr-schmitt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mamoru Tasaka schrieb: > Jochen Schmitt wrote, at 01/16/2008 02:44 AM +9:00: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hello, >> >> when I try to initate a koji scratch build, I will get the following >> messages: >> >> $ koji -scratch build dist-fc9-gcc43 gnu-smalltalk-3.0-0.fc9.src.rpm > > The correct command is > $ koji build --scratch dist-f9-gcc43 > Thank you, it seems, that --scratch have to be after the build command option. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHjPZ6T2AHK6txfgwRAnLfAKDXYeS1L9FgpYUxvgGcNkbk9L64zgCgysGd n1h8APkXUlNNgXcVNTA+srA= =+FI9 -----END PGP SIGNATURE----- From singularitaet at gmx.net Tue Jan 15 18:12:03 2008 From: singularitaet at gmx.net (Stefan Grosse) Date: Tue, 15 Jan 2008 19:12:03 +0100 Subject: texlive + pdftex +kile: very slow In-Reply-To: <645d17210801150905t344d9226p30b96958e8d25c07@mail.gmail.com> References: <200801151606.59141.singularitaet@gmx.net> <645d17210801150905t344d9226p30b96958e8d25c07@mail.gmail.com> Message-ID: <200801151912.03388.singularitaet@gmx.net> On Tuesday 15 January 2008 06:05:55 pm Jonathan Underwood wrote: JU> It would be helpful if you would produce a simple (minimal) tex file JU> which reproduced the problem, and filed a bug report attaching that JU> file. I think you can take any file. But here is some minimal example: \documentclass{beamer} \usetheme{Warsaw} \begin{document} \begin{frame} \frametitle{A test} some text \end{frame} \end{document} With that kile uses 100% for some minute to compile. Command line takes a second... Where should I file it? Fedora or kile? Stefan From singularitaet at gmx.net Tue Jan 15 18:16:46 2008 From: singularitaet at gmx.net (Stefan Grosse) Date: Tue, 15 Jan 2008 19:16:46 +0100 Subject: texlive + pdftex +kile: very slow In-Reply-To: <200801151632.39422.jamatos@fc.up.pt> References: <200801151606.59141.singularitaet@gmx.net> <200801151712.24830.singularitaet@gmx.net> <200801151632.39422.jamatos@fc.up.pt> Message-ID: <200801151916.46358.singularitaet@gmx.net> On Tuesday 15 January 2008 05:32:39 pm Jos? Matos wrote: JM> That seems strange, nevertheless try to run pdflatex from the command line JM> and see what is going on. I would expect kile to be not guilty here and the JM> command line will point where the problem is... it runs fine from the command line. But not it is slow from the button. There are many errors of the kind pdfTeX warning: pdflatex (file /var/lib/texmf/fonts/map/pdftex/updmap/pdftex.ma p): ambiguous entry for `toti10': font file present but not included, will be t reated as font file not present }] (./text.aux) But the resulting pdf looks fine and compiled within a second. Stefan From loupgaroublond at gmail.com Tue Jan 15 18:18:11 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Tue, 15 Jan 2008 13:18:11 -0500 Subject: Icons status for smolts.org In-Reply-To: <478C39BA.2030801@thefinalzone.com> References: <478C39BA.2030801@thefinalzone.com> Message-ID: <7f692fec0801151018k1048f76o2417341d0e6590b2@mail.gmail.com> Hey Luya, On Jan 14, 2008 11:42 PM, Luya Tshimbalanga wrote: > Hi Mike, > > I read the wiki about icons status for smolts.org. You can use icons > from echo-icon-theme[1] under Actions menu and I have linked them on > DesignService wiki page[2]. > > Luya > > References: > [1]https://fedorahosted.org/echo-icon-theme/wiki/IconThemeStatus > [2]http://fedoraproject.org/wiki/Artwork/DesignService > Thanks alot! I'll file a bug report in our tracker to get them put in someday. -Yaakov From jreiser at BitWagon.com Tue Jan 15 18:21:52 2008 From: jreiser at BitWagon.com (John Reiser) Date: Tue, 15 Jan 2008 10:21:52 -0800 Subject: Where are the CD ISO's? (fwd) In-Reply-To: References: Message-ID: <478CF9C0.4000302@BitWagon.com> > What are the plans for media support for Fedora 9? The Fedora Unity project also distributes CDs (via jigdo), including monthly roll-ups into CD form of the official release plus all the updated .rpms; somewhat like the result of a monthly "yum update". >From time to time Fedora Unity also backports fixes from other sources, in order to provide the best possible monthly distribution. http://fedoraunity.org/news-archives/fedora-8-re-spin-released -- From rdieter at math.unl.edu Tue Jan 15 18:41:19 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 15 Jan 2008 12:41:19 -0600 Subject: texlive + pdftex +kile: very slow References: <200801151606.59141.singularitaet@gmx.net> <645d17210801150905t344d9226p30b96958e8d25c07@mail.gmail.com> <200801151912.03388.singularitaet@gmx.net> Message-ID: Stefan Grosse wrote: > On Tuesday 15 January 2008 06:05:55 pm Jonathan Underwood wrote: > JU> It would be helpful if you would produce a simple (minimal) tex file > JU> which reproduced the problem, and filed a bug report attaching that > JU> file. > > I think you can take any file. But here is some minimal example: > > \documentclass{beamer} > \usetheme{Warsaw} > \begin{document} > \begin{frame} > \frametitle{A test} > some text > \end{frame} > \end{document} > > With that kile uses 100% for some minute to compile. Command line takes a > second... > > Where should I file it? Fedora or kile? kile, it would appear. -- Rex From notting at redhat.com Tue Jan 15 18:53:57 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 15 Jan 2008 13:53:57 -0500 Subject: Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <1c252d490801150943q677a6be3n3b48e442edd1697@mail.gmail.com> References: <478CB7A3.8000206@redhat.com> <668bb39a0801150750g5360417bvc208b7d87587c4ed@mail.gmail.com> <200801151702.12768.opensource@till.name> <1c252d490801150943q677a6be3n3b48e442edd1697@mail.gmail.com> Message-ID: <20080115185357.GD9082@nostromo.devel.redhat.com> Joachim Frieben (joachim.frieben at googlemail.com) said: > vim-X11 has a lot more dependencies than vim-enhanced, in particular on > GNOME. vim-X11 has no gnome dependencies. GTK != GNOME, just as QT != KDE. Bill From poelstra at redhat.com Tue Jan 15 18:54:06 2008 From: poelstra at redhat.com (John Poelstra) Date: Tue, 15 Jan 2008 13:54:06 -0500 Subject: Fedora bug triage - workflow proposal In-Reply-To: References: Message-ID: <478D014E.6010603@redhat.com> Jon Stanley said the following on 01/14/2008 11:46 PM Pacific Time: > Well, it was a great session at FUDCon. A lot came out of it, and I'm > going to put some of them down here. The work flow suggested below I'd > a FESco vote on, since it really affects you guys. This work flow was > discussed between myself, John Poelstra, and Will Woods at the Sunday > hackfest, and we agree that this is the correct way to move forward, > however, we want community input and buy-in on this, since it has > pretty far-reaching consequences. > > Here is the lifecycle of a bug: During our discussion we looked at this page: https://bugzilla.redhat.com/page.cgi?id=fields.html#bug_status After a careful review we found that we agreed with each of the descriptions of the states as stated and thought it reasonable to proceed with them. Our goal is to get this launched ASAP and to reuse as much existing stuff we can--where it makes sense. With that in mind, there is a little bit of Red Hat centric stuff on this page, nothing to get excited about. I think our goal should be to keep the process as simple as possible by using the fewest number of states possible. > 1) Reporter files a bug report, it originates in NEW state > 2) Triage team looks at bug report, determines if dupe or > insufficient information exists to solve it. If there is not enough > information in the bug, then triage team puts the bug in NEEDINFO. As > you will see below, this state has a finite life cycle associated with > it. > 3) Assuming bug survives through the triage team, it changes state to > ASSIGNED (triage team can put it in either NEEDINFO or CLOSED, as > appropriate). Note that per the definition[1], ASSIGNED does not mean > that someone has actually agreed to take action, simply that the issue > is well defined and triaged accordingly > 4) Once a developer has taken responsibility for a bug and is > actively working on it, the state transitions to ON_DEV. I think ASSIGNED is fine. Do we gain that much from adding ON_DEV to the process? > 5) Once an update addressing a bug exists in Bodhi, and is pushed to > updates-testing, the status automatically transitions to ON_QA A *future* feature here might also be the ability to automatically change a bug to VERIFIED if enough positive feedback is received by bodhi. This would require the ability to give individual bug feedback to bodhi vs. a package. > 6) When the update is pushed to stable, Bodhi optionally closes the > bug automatically. If the update does not auto-close the bug, it > transitions to NEEDINFO_REPORTER, with a comment explaining that the > update has been pushed to stable, and to update and test in the new > release. > > Note that at any step of the above process, the maintainer can "fast > track" the bug, and change it to ASSIGNED. The triage team is not > going to look at bugs that are not in NEW or NEEDINFO state. On the > flip side of that, it is not a maintainer's responsibility to look at > bugs that are in NEW any longer. They can focus their energy on the > bugs that are ASSIGNED to them. > > Also, maintainers should not be allowed to set priority on bugs. > Setting severity is fine. Only QA or releng should set priorities. > This allows us to look at things in a sane manner (which is impossible > now since severity and priority fields come from /dev/urandom > seemingly), and possibly lessen the reliance on blocker bugs (though > blockers are useful in their own right, so don't think that we are > going to eliminate them any time soon). We talked about this, but I thought we agreed that it made the most sense to keep using blocker bugs and that ironing out how to use priority and severity was something to worry about after establishing some success with a new triage process. John From cjdahlin at ncsu.edu Tue Jan 15 18:51:14 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Tue, 15 Jan 2008 13:51:14 -0500 Subject: Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <1c252d490801150943q677a6be3n3b48e442edd1697@mail.gmail.com> References: <478CB7A3.8000206@redhat.com> <668bb39a0801150750g5360417bvc208b7d87587c4ed@mail.gmail.com> <200801151702.12768.opensource@till.name> <1c252d490801150943q677a6be3n3b48e442edd1697@mail.gmail.com> Message-ID: <478D00A2.1030807@ncsu.edu> Joachim Frieben wrote: > 2008/1/15 Till Maas >: > > Alternatives (man alternatives) can be used for this, there is no > need to > write a wrapper. Still the question why someone would want to run > vim from > the vim-enhanced package if vim-X11 is also installed is not > answered. > > Regards, > Till > > > vim-X11 has a lot more dependencies than vim-enhanced, in particular > on GNOME. He presupposed that vim-X11 was already installed, which means we were at a stage where that point was moot. --CJD From dominik at greysector.net Tue Jan 15 18:58:48 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 15 Jan 2008 19:58:48 +0100 Subject: gxine (Re: Mass rebuild status with gcc-4.3.0-0.4 of rawhide-20071220) In-Reply-To: <1199636599.5090.2.camel@pc-notebook> References: <20080103120242.GZ20451@devserv.devel.redhat.com> <1199386420.6116.8.camel@pc-notebook> <20080103192157.GI20451@devserv.devel.redhat.com> <20080106160849.GH2984@ryvius.greysector.net> <1199636599.5090.2.camel@pc-notebook> Message-ID: <20080115185848.GA3903@ryvius.greysector.net> On Sunday, 06 January 2008 at 17:23, Martin Sourada wrote: > > On Sun, 2008-01-06 at 17:08 +0100, Dominik 'Rathann' Mierzejewski wrote: > > On Thursday, 03 January 2008 at 20:21, Jakub Jelinek wrote: > > > On Thu, Jan 03, 2008 at 07:53:40PM +0100, Martin Sourada wrote: > > > > my package is listed there and look into sources showed only 'static > > > > inline' functions but none of these seems to be listed in the build log. > > > > Instead lots of (to me) confusing messages about multiple defs in glib > > > > header files like this (end of the really long list): > > > > > > > > wizards.o: In function `g_bit_storage': > > > > /usr/include/glib-2.0/glib/gutils.h:345: multiple definition of > > > > `g_bit_storage' > > > > console_output.o:/usr/include/glib-2.0/glib/gutils.h:345: first defined > > > > here > > > > > > The problem is on the glib2 side. > > [...] > > > > I seem to have hit the same bug rebuilding ekg2. > > Martin, have you filed a bug against glib2? > > > Not yet, didn't have time yet... (working on nodoka gtk engine, > currently in the progress of switching to different e-mail address, > examination term on the university is very close...). > > I'd be grateful if some with this same issue reported it... Filed as https://bugzilla.redhat.com/show_bug.cgi?id=428865 . Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From notting at redhat.com Tue Jan 15 18:59:25 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 15 Jan 2008 13:59:25 -0500 Subject: Fedora bug triage - workflow proposal In-Reply-To: References: Message-ID: <20080115185925.GE9082@nostromo.devel.redhat.com> Jon Stanley (jonstanley at gmail.com) said: > Here is the lifecycle of a bug: > > 1) Reporter files a bug report, it originates in NEW state > 2) Triage team looks at bug report, determines if dupe or > insufficient information exists to solve it. If there is not enough > information in the bug, then triage team puts the bug in NEEDINFO. As > you will see below, this state has a finite life cycle associated with > it. > 3) Assuming bug survives through the triage team, it changes state to > ASSIGNED (triage team can put it in either NEEDINFO or CLOSED, as > appropriate). Note that per the definition[1], ASSIGNED does not mean > that someone has actually agreed to take action, simply that the issue > is well defined and triaged accordingly > 4) Once a developer has taken responsibility for a bug and is > actively working on it, the state transitions to ON_DEV. > 5) Once an update addressing a bug exists in Bodhi, and is pushed to > updates-testing, the status automatically transitions to ON_QA > 6) When the update is pushed to stable, Bodhi optionally closes the > bug automatically. If the update does not auto-close the bug, it > transitions to NEEDINFO_REPORTER, with a comment explaining that the > update has been pushed to stable, and to update and test in the new > release. So... this conflicts with the RHEL workflow, in that NEW is used for 'no one is looking at this', and ASSIGNED means 'someone is on the hook for that'. I'd prefer something like: UNCONFIRMED -> NEW -> ASSIGNED rather than: NEW -> ASSIGNED -> ON_DEV If no one is currently looking at it, I think 'NEW' conveys that better to the user than 'ASSIGNED'. Bill From cjdahlin at ncsu.edu Tue Jan 15 19:01:44 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Tue, 15 Jan 2008 14:01:44 -0500 Subject: Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <20080115185357.GD9082@nostromo.devel.redhat.com> References: <478CB7A3.8000206@redhat.com> <668bb39a0801150750g5360417bvc208b7d87587c4ed@mail.gmail.com> <200801151702.12768.opensource@till.name> <1c252d490801150943q677a6be3n3b48e442edd1697@mail.gmail.com> <20080115185357.GD9082@nostromo.devel.redhat.com> Message-ID: <478D0318.2010108@ncsu.edu> Bill Nottingham wrote: > Joachim Frieben (joachim.frieben at googlemail.com) said: > >> vim-X11 has a lot more dependencies than vim-enhanced, in particular on >> GNOME. >> > > vim-X11 has no gnome dependencies. > > GTK != GNOME, just as QT != KDE. > > Bill > > In terms of direct dependencies you are right, though I would not be surprised if vim-X11 managed to pull a large chunk of GNOME in secondary and tertiary dependencies. --CJD From notting at redhat.com Tue Jan 15 19:09:39 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 15 Jan 2008 14:09:39 -0500 Subject: Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <478D0318.2010108@ncsu.edu> References: <478CB7A3.8000206@redhat.com> <668bb39a0801150750g5360417bvc208b7d87587c4ed@mail.gmail.com> <200801151702.12768.opensource@till.name> <1c252d490801150943q677a6be3n3b48e442edd1697@mail.gmail.com> <20080115185357.GD9082@nostromo.devel.redhat.com> <478D0318.2010108@ncsu.edu> Message-ID: <20080115190939.GF9082@nostromo.devel.redhat.com> Casey Dahlin (cjdahlin at ncsu.edu) said: > In terms of direct dependencies you are right, though I would not be > surprised if vim-X11 managed to pull a large chunk of GNOME in secondary > and tertiary dependencies. It would pull in nothing more than any XFCE app would. Bill From pertusus at free.fr Tue Jan 15 19:15:08 2008 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 15 Jan 2008 20:15:08 +0100 Subject: texlive + pdftex +kile: very slow In-Reply-To: <200801151916.46358.singularitaet@gmx.net> References: <200801151606.59141.singularitaet@gmx.net> <200801151712.24830.singularitaet@gmx.net> <200801151632.39422.jamatos@fc.up.pt> <200801151916.46358.singularitaet@gmx.net> Message-ID: <20080115191508.GE2672@free.fr> On Tue, Jan 15, 2008 at 07:16:46PM +0100, Stefan Grosse wrote: > On Tuesday 15 January 2008 05:32:39 pm Jos? Matos wrote: > JM> That seems strange, nevertheless try to run pdflatex from the command line > JM> and see what is going on. I would expect kile to be not guilty here and > the > JM> command line will point where the problem is... > > it runs fine from the command line. But not it is slow from the button. > > There are many errors of the kind > > pdfTeX warning: pdflatex > (file /var/lib/texmf/fonts/map/pdftex/updmap/pdftex.ma > p): ambiguous entry for `toti10': font file present but not included, will be > t > reated as font file not present > }] (./text.aux) I think this is due to the updmap post script not being run rightly. -- Pat From jonstanley at gmail.com Tue Jan 15 19:29:45 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Tue, 15 Jan 2008 14:29:45 -0500 Subject: Fedora bug triage - workflow proposal In-Reply-To: <478D014E.6010603@redhat.com> References: <478D014E.6010603@redhat.com> Message-ID: On Jan 15, 2008 1:54 PM, John Poelstra wrote: > I think ASSIGNED is fine. Do we gain that much from adding ON_DEV to > the process? I think that locating an AWOL maintainer is easier this way, but I'm open to suggestions for how else to do that. > A *future* feature here might also be the ability to automatically > change a bug to VERIFIED if enough positive feedback is received by > bodhi. This would require the ability to give individual bug feedback > to bodhi vs. a package. Forgot about this one. Luke, what's the level of effort to add something like this to Bodhi? (i.e. can we have it in time for F9 release?) > We talked about this, but I thought we agreed that it made the most > sense to keep using blocker bugs and that ironing out how to use > priority and severity was something to worry about after establishing > some success with a new triage process. Yep, I was just getting stuff down. No changes here for the moment.... From jonstanley at gmail.com Tue Jan 15 19:36:14 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Tue, 15 Jan 2008 14:36:14 -0500 Subject: Fedora bug triage - workflow proposal In-Reply-To: <20080115185925.GE9082@nostromo.devel.redhat.com> References: <20080115185925.GE9082@nostromo.devel.redhat.com> Message-ID: On Jan 15, 2008 1:59 PM, Bill Nottingham wrote: > So... this conflicts with the RHEL workflow, in that NEW is used > for 'no one is looking at this', and ASSIGNED means 'someone is > on the hook for that'. I'd prefer something like: > > UNCONFIRMED -> NEW -> ASSIGNED Yep, but we don't currently have an UNCONFIRMED state. One thing that we didn't know was whether or not you could assign different initial states per product - so that RHEL bugs don't wind up in UNCONFIRMED, etc. > If no one is currently looking at it, I think 'NEW' conveys that > better to the user than 'ASSIGNED'. It does, but like John said, we were looking to launch with a minimal amount of effort and retooling, and using what we already had. From benny+usenet at amorsen.dk Tue Jan 15 19:55:58 2008 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Tue, 15 Jan 2008 20:55:58 +0100 Subject: Where are the CD ISO's? (fwd) References: <20080115115315.0307581e@redhat.com> Message-ID: Jesse Keating writes: > Generating split media as part of the official compose process. Alpha > will see DVD + split CD media. What about USB sticks etc? I don't mind if they need to be DVD size or larger. /Benny From emmanuel.seyman at club-internet.fr Tue Jan 15 19:55:52 2008 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Tue, 15 Jan 2008 20:55:52 +0100 Subject: Fedora bug triage - workflow proposal In-Reply-To: References: <20080115185925.GE9082@nostromo.devel.redhat.com> Message-ID: <20080115195552.GA503@orient.maison.lan> * Jon Stanley [15/01/2008 20:53] : > > Yep, but we don't currently have an UNCONFIRMED state. One thing that > we didn't know was whether or not you could assign different initial > states per product - so that RHEL bugs don't wind up in UNCONFIRMED, > etc. In upstream Bugzilla, UNCONFIRMED can be activated per-product. Emmanuel From sundaram at fedoraproject.org Tue Jan 15 20:10:09 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 16 Jan 2008 01:40:09 +0530 Subject: Where are the CD ISO's? (fwd) In-Reply-To: References: <20080115115315.0307581e@redhat.com> Message-ID: <478D1321.4070703@fedoraproject.org> Benny Amorsen wrote: > Jesse Keating writes: > >> Generating split media as part of the official compose process. Alpha >> will see DVD + split CD media. > > What about USB sticks etc? I don't mind if they need to be DVD size or > larger. # yum install livecd-tools # livecd-iso-to-disk Rahul From opensource at till.name Tue Jan 15 20:24:39 2008 From: opensource at till.name (Till Maas) Date: Tue, 15 Jan 2008 21:24:39 +0100 Subject: Where are the CD ISO's? (fwd) In-Reply-To: <478D1321.4070703@fedoraproject.org> References: <478D1321.4070703@fedoraproject.org> Message-ID: <200801152124.40032.opensource@till.name> On Tue January 15 2008, Rahul Sundaram wrote: > Benny Amorsen wrote: > > Jesse Keating writes: > >> Generating split media as part of the official compose process. Alpha > >> will see DVD + split CD media. > > > > What about USB sticks etc? I don't mind if they need to be DVD size or > > larger. > > # yum install livecd-tools > # livecd-iso-to-disk Just to make it sure: Does this work for the normal (non live media) installation media, too? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From notting at redhat.com Tue Jan 15 20:42:54 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 15 Jan 2008 15:42:54 -0500 Subject: Where are the CD ISO's? (fwd) In-Reply-To: <200801152124.40032.opensource@till.name> References: <478D1321.4070703@fedoraproject.org> <200801152124.40032.opensource@till.name> Message-ID: <20080115204254.GB21991@nostromo.devel.redhat.com> Till Maas (opensource at till.name) said: > > # yum install livecd-tools > > # livecd-iso-to-disk > > Just to make it sure: Does this work for the normal (non live media) > installation media, too? ... how? Bill From joachim.frieben at googlemail.com Tue Jan 15 20:48:48 2008 From: joachim.frieben at googlemail.com (Joachim Frieben) Date: Tue, 15 Jan 2008 21:48:48 +0100 Subject: Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <20080115185357.GD9082@nostromo.devel.redhat.com> References: <478CB7A3.8000206@redhat.com> <668bb39a0801150750g5360417bvc208b7d87587c4ed@mail.gmail.com> <200801151702.12768.opensource@till.name> <1c252d490801150943q677a6be3n3b48e442edd1697@mail.gmail.com> <20080115185357.GD9082@nostromo.devel.redhat.com> Message-ID: <1c252d490801151248t3783daf2sc49b7cb90133fce5@mail.gmail.com> On Jan 15, 2008 7:53 PM, Bill Nottingham wrote: > Joachim Frieben (joachim.frieben at googlemail.com) said: > > vim-X11 has a lot more dependencies than vim-enhanced, in particular on > > GNOME. > > vim-X11 has no gnome dependencies. > > GTK != GNOME, just as QT != KDE. > > Bill > A GNOME build is actually possible among many others, but in the present case, you're absolutely right: the current build definitely chooses the GTK frontend, not the GNOME one. The resulting dependencies are thus only slightly increased with respect to vim-enhanced. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora at camperquake.de Tue Jan 15 20:57:12 2008 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 15 Jan 2008 21:57:12 +0100 Subject: Where are the CD ISO's? (fwd) In-Reply-To: <20080115204254.GB21991@nostromo.devel.redhat.com> References: <478D1321.4070703@fedoraproject.org> <200801152124.40032.opensource@till.name> <20080115204254.GB21991@nostromo.devel.redhat.com> Message-ID: <20080115215712.3bd0d162@lain.camperquake.de> Hi. On Tue, 15 Jan 2008 15:42:54 -0500, Bill Nottingham wrote > > Just to make it sure: Does this work for the normal (non live > > media) installation media, too? > > ... how? Well... basically just like the live image, but booting the normal installer instead? I could have used that a week ago, as a matter of fact. From opensource at till.name Tue Jan 15 20:55:24 2008 From: opensource at till.name (Till Maas) Date: Tue, 15 Jan 2008 21:55:24 +0100 Subject: Where are the CD ISO's? (fwd) In-Reply-To: <20080115204254.GB21991@nostromo.devel.redhat.com> References: <200801152124.40032.opensource@till.name> <20080115204254.GB21991@nostromo.devel.redhat.com> Message-ID: <200801152155.29186.opensource@till.name> On Tue January 15 2008, Bill Nottingham wrote: > Till Maas (opensource at till.name) said: > > > # yum install livecd-tools > > > # livecd-iso-to-disk > > > > Just to make it sure: Does this work for the normal (non live media) > > installation media, too? > > ... how? I do not know the details, but when it is possible to make usb sticks bootable, it should be possible to use them to boot the contents of an installation dvd. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From jreiser at BitWagon.com Tue Jan 15 20:59:26 2008 From: jreiser at BitWagon.com (John Reiser) Date: Tue, 15 Jan 2008 12:59:26 -0800 Subject: Where are the CD ISO's? (fwd) In-Reply-To: <478D1321.4070703@fedoraproject.org> References: <20080115115315.0307581e@redhat.com> <478D1321.4070703@fedoraproject.org> Message-ID: <478D1EAE.5060407@BitWagon.com> > # yum install livecd-tools > # livecd-iso-to-disk Please improve the documentation by giving a literal example of , and explain. Is it, for instance: # livecd-iso-to-disk Fedora-9-i386-DVD.iso /dev/sde where is the entire device (in this case the fifth device ['e'] which uses the "SCSI" driver), or should it be instead # livecd-iso-to-disk Fedora-9-i386-DVD.iso /dev/sde1 where is a DOS-style partition on the device? Or can both of these work in some cases, and how can you tell? Which one should you try first, and why? [I really don't know!] There are enough BIOS with quirks and bugs in booting from USB that any extra uncertainty is an excessive burden on users. -- From s.dahdaah at spidernetlb.com Tue Jan 15 21:00:37 2008 From: s.dahdaah at spidernetlb.com (Salloum EL DAHDAAH) Date: Tue, 15 Jan 2008 23:00:37 +0200 Subject: spotlight in fedora 8 In-Reply-To: <20080115170004.50B6A73681@hormel.redhat.com> References: <20080115170004.50B6A73681@hormel.redhat.com> Message-ID: <1200430837.4008.0.camel@localhost.localdomain> I didnt understand what is the 4 th software written in message 7 and 8 thank you On Tue, 2008-01-15 at 12:00 -0500, fedora-devel-list-request at redhat.com wrote: > Send fedora-devel-list mailing list submissions to > fedora-devel-list at redhat.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/fedora-devel-list > or, via email, send a message with subject or body 'help' to > fedora-devel-list-request at redhat.com > > You can reach the person managing the list at > fedora-devel-list-owner at redhat.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of fedora-devel-list digest..." > > > Today's Topics: > > 1. Re: Fedora bug triage - workflow proposal (Ralf Corsepius) > 2. Re: texlive + pdftex +kile: very slow (Stefan Grosse) > 3. Re: Fedora bug triage - workflow proposal (Kevin Fenzi) > 4. Re: anaconda - unhandled exception (Jeremy Katz) > 5. Re: compilation architecture (Jakub 'Livio' Rusinek) > 6. Re: texlive + pdftex +kile: very slow (Jos? Matos) > 7. Re: SpotLight into fedora (Zoltan Boszormenyi) > 8. Re: SpotLight into fedora (subhodip biswas) > 9. Where are the CD ISO's? (fwd) (Mike McGrath) > 10. Re: Where are the CD ISO's? (fwd) (subhodip biswas) > 11. Re: Where are the CD ISO's? (fwd) (Jesse Keating) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 15 Jan 2008 12:25:00 +0100 > From: Ralf Corsepius > Subject: Re: Fedora bug triage - workflow proposal > To: Development discussions related to Fedora > > Message-ID: <1200396300.5174.158.camel at beck.corsepiu.local> > Content-Type: text/plain > > > On Mon, 2008-01-14 at 23:46 -0500, Jon Stanley wrote: > > 2) Triage team looks at bug report, determines if dupe or > > insufficient information exists to solve it. If there is not enough > > information in the bug, then triage team puts the bug in NEEDINFO. As > > you will see below, this state has a finite life cycle associated with > > it. > I am having doubts the bug triage team will be able to judge on whether > a PR is legitimate or not but on trivial cases. > > I.e. I would expect them to end up spam essentially filtering. > > > 3) Assuming bug survives through the triage team, it changes state to > > ASSIGNED > > To whom? > > IMO, the real problem is getting a competent volunteer involved who is > likely sufficiently knowledgeable about a particular issue. i.e. to > communicate such issues, such that a volunteer can take action when _he_ > wants. > > That said, I consider lack of communication and "bug arbitration" to be > the actual flaw behind current bug tracking workflow in Fedora. > > Ralf > > > > > ------------------------------ > > Message: 2 > Date: Tue, 15 Jan 2008 17:12:24 +0100 > From: Stefan Grosse > Subject: Re: texlive + pdftex +kile: very slow > To: Development discussions related to Fedora > > Message-ID: <200801151712.24830.singularitaet at gmx.net> > Content-Type: text/plain; charset="utf-8" > > On Tuesday 15 January 2008 04:15:58 pm Jos Matos wrote: > JM> No problem here both on fc8 with Jindich texlive packages and lyx as > well > JM> as with rawhide. > JM> > JM> It runs fast and I do not notice any difference from tetex in terms of > JM> speed. > > Thanks, so it seems a problem with kile? > > Stefan > > > > ------------------------------ > > Message: 3 > Date: Tue, 15 Jan 2008 09:24:52 -0700 > From: Kevin Fenzi > Subject: Re: Fedora bug triage - workflow proposal > To: fedora-devel-list at redhat.com > Message-ID: <20080115092452.245d5604 at ghistelwchlohm.scrye.com> > Content-Type: text/plain; charset="us-ascii" > > On Mon, 14 Jan 2008 23:46:36 -0500 > jonstanley at gmail.com ("Jon Stanley") wrote: > > > Well, it was a great session at FUDCon. A lot came out of it, and I'm > > going to put some of them down here. The work flow suggested below I'd > > a FESco vote on, since it really affects you guys. > > Great. You might want to use (optional) > http://fedoraproject.org/wiki/JesseKeating/FESCoProposalTemplateDraft > and write up a page for FESCo to refer to for this. > > > This work flow was > > discussed between myself, John Poelstra, and Will Woods at the Sunday > > hackfest, and we agree that this is the correct way to move forward, > > however, we want community input and buy-in on this, since it has > > pretty far-reaching consequences. > > Sorry I couldn't make it on sunday... had to catch a plane. ;) > > > Here is the lifecycle of a bug: > > ...snipp... > Looks great to me. > > > Note that at any step of the above process, the maintainer can "fast > > track" the bug, and change it to ASSIGNED. The triage team is not > > going to look at bugs that are not in NEW or NEEDINFO state. On the > > What if the bug is put in NEEDINFO(maintainer) by the reporter? > Ie, they have provided info or need to ask the maintainer about > something, but the maintainer isn't responding? Are those closed? > They probibly shouldn't be... > > > flip side of that, it is not a maintainer's responsibility to look at > > bugs that are in NEW any longer. They can focus their energy on the > > bugs that are ASSIGNED to them. > > > > Also, maintainers should not be allowed to set priority on bugs. > > Setting severity is fine. Only QA or releng should set priorities. > > This allows us to look at things in a sane manner (which is impossible > > now since severity and priority fields come from /dev/urandom > > seemingly), and possibly lessen the reliance on blocker bugs (though > > blockers are useful in their own right, so don't think that we are > > going to eliminate them any time soon). > > I'm not sure how usefull this will be. Maintainers pretty much ignore > priority now, as reporter (or any package maintainer) can set it... > > > It was also decided that when a bug is in NEEDINFO for one month, it > > will be closed. Maintainers would need to realize that putting a bug > > in NEEDINFO is putting it on the fast track for closure. > > What about the above case of NEEDINFO(maintainer)? > > > I think that's all that I have to say on this topic right now, let me > > know if I'm missing anything or this is complete hogwash :) > > I think this is great! ;) > I'd be happy to help with triage... > > > -Jon > > kevin > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 189 bytes > Desc: not available > Url : https://www.redhat.com/archives/fedora-devel-list/attachments/20080115/804c8a2b/signature.bin > > ------------------------------ > > Message: 4 > Date: Tue, 15 Jan 2008 11:27:29 -0500 > From: Jeremy Katz > Subject: Re: anaconda - unhandled exception > To: Development discussions related to Fedora > > Message-ID: <1200414449.3433.4.camel at aglarond.local> > Content-Type: text/plain > > On Tue, 2008-01-15 at 08:45 -0500, Chris Lumens wrote: > > > Keep it up Jeremy, ya bout got it licked! > > > > Not to be a jerk or anything, but you're aware at least five other > > people work on anaconda, right? > > And I'm not even really around this month (other than sporadic looking > at email). Luckily, we've got a team of other rock stars these days[1] > helping out on anaconda these days and it doesn't all just fall to me > anymore. > > Jeremy > > [1] And have for a while at this point. Keep up Mike! :-) > > > > ------------------------------ > > Message: 5 > Date: Tue, 15 Jan 2008 17:31:04 +0100 > From: "Jakub 'Livio' Rusinek" > Subject: Re: compilation architecture > To: "Development discussions related to Fedora" > > Message-ID: > <5e92ee3f0801150831t685810f1jb2ac41c7975a1675 at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Installing openSUSE again would complicate my life. Again. > But if it's so necessary, I can install it one more time. > > My hardware and configuration? > > http://www.smolts.org/show_all?UUID=c8dbb9d3-a9bd-4ba6-b92e-4a294ba5a95f > > -- > Jakub 'Livio' Rusinek > http://liviopl.jogger.pl/ > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: https://www.redhat.com/archives/fedora-devel-list/attachments/20080115/df91a460/attachment.html > > ------------------------------ > > Message: 6 > Date: Tue, 15 Jan 2008 16:32:39 +0000 > From: Jos? Matos > Subject: Re: texlive + pdftex +kile: very slow > To: fedora-devel-list at redhat.com > Message-ID: <200801151632.39422.jamatos at fc.up.pt> > Content-Type: text/plain; charset="utf-8" > > On Tuesday 15 January 2008 16:12:24 Stefan Grosse wrote: > > Thanks, so it seems a problem with kile? > > That seems strange, nevertheless try to run pdflatex from the command line > and see what is going on. I would expect kile to be not guilty here and the > command line will point where the problem is... > > > Stefan > > -- > Jos Ablio > > > > ------------------------------ > > Message: 7 > Date: Tue, 15 Jan 2008 17:41:24 +0100 > From: Zoltan Boszormenyi > Subject: Re: SpotLight into fedora > To: Development discussions related to Fedora > > Message-ID: <478CE234.3090901 at freemail.hu> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Jakub 'Livio' Rusinek rta: > > Not the same. SIMILLIAR. > > Sure you meant "Silmarillion". > > > > > > ------------------------------ > > Message: 8 > Date: Tue, 15 Jan 2008 22:14:24 +0530 > From: "subhodip biswas" > Subject: Re: SpotLight into fedora > To: "Development discussions related to Fedora" > > Message-ID: > <539333cb0801150844o2e34bffcob66745345002b16f at mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > ah ... sorry i forgot to mention that .. thanx for reminding > > On Jan 15, 2008 10:11 PM, Zoltan Boszormenyi wrote: > > Jakub 'Livio' Rusinek rta: > > > Not the same. SIMILLIAR. > > > > Sure you meant "Silmarillion". > > > > > > > > -- > > > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > -- > Regards > Subhodip Biswas > > GPG key : FAEA34AB > Server : pgp.mit.edu > http://subhodipbiswas.wordpress.com > http:/www.fedoraproject.org/wiki/SubhodipBiswas > > > > ------------------------------ > > Message: 9 > Date: Tue, 15 Jan 2008 10:47:38 -0600 (CST) > From: Mike McGrath > Subject: Where are the CD ISO's? (fwd) > To: fedora-devel-list at redhat.com > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII > > What are the plans for media support for Fedora 9? > > -Mike > > ---------- Forwarded message ---------- > Date: Tue, 15 Jan 2008 10:32:33 +0100 > From: Heinrich Winther Christensen > To: webmaster at fedoraproject.org > Subject: Where are the CD ISO's? > > Hi... > > My old but useful server doesn't have DVD, so I desperately need ISO's > for CD's. > Where will I find them? > > Heinrich > > -- > Fedora-websites-list mailing list > Fedora-websites-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-websites-list > > > > ------------------------------ > > Message: 10 > Date: Tue, 15 Jan 2008 22:23:21 +0530 > From: "subhodip biswas" > Subject: Re: Where are the CD ISO's? (fwd) > To: "Development discussions related to Fedora" > > Message-ID: > <539333cb0801150853j6f417db2q4027fffbf54e93d3 at mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Yeah .. this is a good issue .. many of fedora user here stick to > older version because cd iso in unavailable .... and live cd does not > serve their purpose .. > > > -- > Regards > Subhodip Biswas > > GPG key : FAEA34AB > Server : pgp.mit.edu > http://subhodipbiswas.wordpress.com > http:/www.fedoraproject.org/wiki/SubhodipBiswas > > > > ------------------------------ > > Message: 11 > Date: Tue, 15 Jan 2008 11:53:15 -0500 > From: Jesse Keating > Subject: Re: Where are the CD ISO's? (fwd) > To: fedora-devel-list at redhat.com > Message-ID: <20080115115315.0307581e at redhat.com> > Content-Type: text/plain; charset="us-ascii" > > On Tue, 15 Jan 2008 10:47:38 -0600 (CST) > Mike McGrath wrote: > > > What are the plans for media support for Fedora 9? > > Generating split media as part of the official compose process. Alpha > will see DVD + split CD media. > > -- > Jesse Keating > Fedora -- All my bits are free, are yours? > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 189 bytes > Desc: not available > Url : https://www.redhat.com/archives/fedora-devel-list/attachments/20080115/55daba84/signature.bin > > ------------------------------ > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > End of fedora-devel-list Digest, Vol 47, Issue 105 > ************************************************** From sundaram at fedoraproject.org Tue Jan 15 21:12:22 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 16 Jan 2008 02:42:22 +0530 Subject: Where are the CD ISO's? (fwd) In-Reply-To: <478D1EAE.5060407@BitWagon.com> References: <20080115115315.0307581e@redhat.com> <478D1321.4070703@fedoraproject.org> <478D1EAE.5060407@BitWagon.com> Message-ID: <478D21B6.7040805@fedoraproject.org> John Reiser wrote: >> # yum install livecd-tools >> # livecd-iso-to-disk > > Please improve the documentation by giving a literal example > of , and explain. > > Is it, for instance: > # livecd-iso-to-disk Fedora-9-i386-DVD.iso /dev/sde > where is the entire device (in this case the > fifth device ['e'] which uses the "SCSI" driver), > or should it be instead > # livecd-iso-to-disk Fedora-9-i386-DVD.iso /dev/sde1 > where is a DOS-style partition on the device? > Or can both of these work in some cases, and how can you tell? The latter. Rahul From notting at redhat.com Tue Jan 15 21:14:01 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 15 Jan 2008 16:14:01 -0500 Subject: Where are the CD ISO's? (fwd) In-Reply-To: <20080115215712.3bd0d162@lain.camperquake.de> References: <478D1321.4070703@fedoraproject.org> <200801152124.40032.opensource@till.name> <20080115204254.GB21991@nostromo.devel.redhat.com> <20080115215712.3bd0d162@lain.camperquake.de> Message-ID: <20080115211401.GB22768@nostromo.devel.redhat.com> Ralf Ertzinger (fedora at camperquake.de) said: > > > Just to make it sure: Does this work for the normal (non live > > > media) installation media, too? > > > > ... how? > > Well... basically just like the live image, but booting the > normal installer instead? > > I could have used that a week ago, as a matter of fact. Not in livecd-tools, no. It knows nothing of merging repodata, etc. Note that if you wanted to do this, you'd want to handle split media. Bill From opensource at till.name Tue Jan 15 21:14:25 2008 From: opensource at till.name (Till Maas) Date: Tue, 15 Jan 2008 22:14:25 +0100 Subject: Where are the CD ISO's? (fwd) In-Reply-To: <478D1EAE.5060407@BitWagon.com> References: <478D1321.4070703@fedoraproject.org> <478D1EAE.5060407@BitWagon.com> Message-ID: <200801152214.33678.opensource@till.name> On Tue January 15 2008, John Reiser wrote: > > # yum install livecd-tools > > # livecd-iso-to-disk > > Please improve the documentation by giving a literal example > of , and explain. Please open a bug report for this. :-) Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From mjs at CLEMSON.EDU Tue Jan 15 21:21:37 2008 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Tue, 15 Jan 2008 21:21:37 +0000 Subject: Fedora bug triage - workflow proposal In-Reply-To: References: <20080115185925.GE9082@nostromo.devel.redhat.com> Message-ID: <1200432097.28156.13.camel@vincent52.localdomain> On Tue, 2008-01-15 at 14:36 -0500, Jon Stanley wrote: > On Jan 15, 2008 1:59 PM, Bill Nottingham wrote: > > > So... this conflicts with the RHEL workflow, in that NEW is used > > for 'no one is looking at this', and ASSIGNED means 'someone is > > on the hook for that'. I'd prefer something like: > > > > UNCONFIRMED -> NEW -> ASSIGNED > > Yep, but we don't currently have an UNCONFIRMED state. One thing that > we didn't know was whether or not you could assign different initial > states per product - so that RHEL bugs don't wind up in UNCONFIRMED, > etc. > > > If no one is currently looking at it, I think 'NEW' conveys that > > better to the user than 'ASSIGNED'. > > It does, but like John said, we were looking to launch with a minimal > amount of effort and retooling, and using what we already had. (I'm usually just a lurker on discussions like this, but I couldn't resist.) NEW -> CONFIRMED -> ASSIGNED ? > > -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From opensource at till.name Tue Jan 15 21:27:33 2008 From: opensource at till.name (Till Maas) Date: Tue, 15 Jan 2008 22:27:33 +0100 Subject: Where are the CD ISO's? (fwd) In-Reply-To: <20080115211401.GB22768@nostromo.devel.redhat.com> References: <20080115215712.3bd0d162@lain.camperquake.de> <20080115211401.GB22768@nostromo.devel.redhat.com> Message-ID: <200801152227.38455.opensource@till.name> On Tue January 15 2008, Bill Nottingham wrote: > Not in livecd-tools, no. It knows nothing of merging repodata, etc. > Note that if you wanted to do this, you'd want to handle split > media. When one uses the dvd image, there is afaik no need to merge anything. And imho merging would also not be needed, if only separte directories for each medium would be used and anaconda could be told where to look for each medium. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From benny+usenet at amorsen.dk Tue Jan 15 21:28:34 2008 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Tue, 15 Jan 2008 22:28:34 +0100 Subject: Where are the CD ISO's? (fwd) References: <20080115115315.0307581e@redhat.com> <478D1321.4070703@fedoraproject.org> Message-ID: Rahul Sundaram writes: > # yum install livecd-tools > # livecd-iso-to-disk I have zero interest in a livecd, sorry. I'm talking about the real release. /Benny From notting at redhat.com Tue Jan 15 21:32:46 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 15 Jan 2008 16:32:46 -0500 Subject: Where are the CD ISO's? (fwd) In-Reply-To: <200801152227.38455.opensource@till.name> References: <20080115215712.3bd0d162@lain.camperquake.de> <20080115211401.GB22768@nostromo.devel.redhat.com> <200801152227.38455.opensource@till.name> Message-ID: <20080115213246.GD22768@nostromo.devel.redhat.com> Till Maas (opensource at till.name) said: > > Not in livecd-tools, no. It knows nothing of merging repodata, etc. > > Note that if you wanted to do this, you'd want to handle split > > media. > > When one uses the dvd image, there is afaik no need to merge anything. And > imho merging would also not be needed, if only separte directories for each > medium would be used and anaconda could be told where to look for each > medium. Right, I still am not seeing why this would be in livecd-XXX-to-YYY. Bill From sundaram at fedoraproject.org Tue Jan 15 21:42:05 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 16 Jan 2008 03:12:05 +0530 Subject: Where are the CD ISO's? (fwd) In-Reply-To: References: <20080115115315.0307581e@redhat.com> <478D1321.4070703@fedoraproject.org> Message-ID: <478D28AD.7090509@fedoraproject.org> Benny Amorsen wrote: > Rahul Sundaram writes: > >> # yum install livecd-tools >> # livecd-iso-to-disk > > I have zero interest in a livecd, sorry. I'm talking about the real > release. Live CD's are part of the "real" release too. You probably mean regular installable images and there isn't any easy way to convert them into a bootable USB image. Rahul From jonstanley at gmail.com Tue Jan 15 21:36:42 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Tue, 15 Jan 2008 16:36:42 -0500 Subject: Fedora bug triage - workflow proposal In-Reply-To: <1200432097.28156.13.camel@vincent52.localdomain> References: <20080115185925.GE9082@nostromo.devel.redhat.com> <1200432097.28156.13.camel@vincent52.localdomain> Message-ID: On Jan 15, 2008 4:21 PM, Matthew Saltzman wrote: > (I'm usually just a lurker on discussions like this, but I couldn't > resist.) > > NEW -> CONFIRMED -> ASSIGNED ? Got some word on this off-list - it is a non-trivial endeavor to add states, it adds nothing to the workflow. Let's not get into a discussion here whereby we're arguing over what color the bike shed is...to quote: Yet so many objections, proposals and changes were raised and launched that one would think the change would have plugged all the holes in swiss cheese or changed the taste of Coca Cola or something similar serious. Parkinson shows how you can go in to the board of directors and get approval for building a multi-million or even billion dollar atomic power plant, but if you want to build a bike shed you will be tangled up in endless discussions. Parkinson explains that this is because an atomic plant is so vast, so expensive and so complicated that people cannot grasp it, and rather than try, they fall back on the assumption that somebody else checked all the details before it got this far. Richard P. Feynmann gives a couple of interesting, and very much to the point, examples relating to Los Alamos in his books. A bike shed on the other hand. Anyone can build one of those over a weekend, and still have time to watch the game on TV. So no matter how well prepared, no matter how reasonable you are with your proposal, somebody will seize the chance to show that he is doing his job, that he is paying attention, that he is *here*. In Denmark we call it "setting your fingerprint". It is about personal pride and prestige, it is about being able to point somewhere and say "There! *I* did that." It is a strong trait in politicians, but present in most people given the chance. Just think about footsteps in wet cement. From opensource at till.name Tue Jan 15 21:42:09 2008 From: opensource at till.name (Till Maas) Date: Tue, 15 Jan 2008 22:42:09 +0100 Subject: Where are the CD ISO's? (fwd) In-Reply-To: <20080115213246.GD22768@nostromo.devel.redhat.com> References: <200801152227.38455.opensource@till.name> <20080115213246.GD22768@nostromo.devel.redhat.com> Message-ID: <200801152242.13976.opensource@till.name> On Tue January 15 2008, Bill Nottingham wrote: > Till Maas (opensource at till.name) said: > > > Not in livecd-tools, no. It knows nothing of merging repodata, etc. > > > Note that if you wanted to do this, you'd want to handle split > > > media. > > > > When one uses the dvd image, there is afaik no need to merge anything. > > And imho merging would also not be needed, if only separte directories > > for each medium would be used and anaconda could be told where to look > > for each medium. > > Right, I still am not seeing why this would be in livecd-XXX-to-YYY. Using livecd-iso-to-usb was an answer that was given to the question, how to get this (using the installation medium with usb) done. Then I asked, whether this really works and explained how it could work. Maybe installationmedia-image-to-usb would be a better name for such a programm, but I guess most of the code would be common with livecd-iso-to-usb. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From opensource at till.name Tue Jan 15 21:42:59 2008 From: opensource at till.name (Till Maas) Date: Tue, 15 Jan 2008 22:42:59 +0100 Subject: Where are the CD ISO's? (fwd) In-Reply-To: <478D28AD.7090509@fedoraproject.org> References: <478D28AD.7090509@fedoraproject.org> Message-ID: <200801152243.00189.opensource@till.name> On Tue January 15 2008, Rahul Sundaram wrote: > Live CD's are part of the "real" release too. You probably mean regular > installable images and there isn't any easy way to convert them into a > bootable USB image. Why is it not easy? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From mszpak at wp.pl Tue Jan 15 21:44:12 2008 From: mszpak at wp.pl (=?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?=) Date: Tue, 15 Jan 2008 22:44:12 +0100 Subject: Python Eggs and problem with %{python_sitelib} Message-ID: Hi, Recently I was updating my python package in rawhide to be compatible with Python Eggs and from an error in a log it seems that %{python_sitelib} is not declared. Is it really required to define that variable at the beginning of every SPEC file (eventually use %{_libdir}/python*/site-packages/) or it should be already defined in the system? Sample log: http://koji.fedoraproject.org/koji/getfile?taskID=351446&name=build.log Regards Marcin From jkeating at redhat.com Tue Jan 15 21:47:22 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 Jan 2008 16:47:22 -0500 Subject: Python Eggs and problem with %{python_sitelib} In-Reply-To: References: Message-ID: <20080115164722.3b4f5781@redhat.com> On Tue, 15 Jan 2008 22:44:12 +0100 Marcin Zaj?czkowski wrote: > Hi, > > Recently I was updating my python package in rawhide to be compatible > with Python Eggs and from an error in a log it seems that > %{python_sitelib} is not declared. > Is it really required to define that variable at the beginning of > every SPEC file (eventually use %{_libdir}/python*/site-packages/) or > it should be already defined in the system? > > Sample log: > http://koji.fedoraproject.org/koji/getfile?taskID=351446&name=build.log Python specs should have one of either python_sitelib or python_sitearch defined at the top of them. See the guidelines for python packages. Use of one or the other depends on if your module is arch specific (compiled) or not. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From opensource at till.name Tue Jan 15 21:50:10 2008 From: opensource at till.name (Till Maas) Date: Tue, 15 Jan 2008 22:50:10 +0100 Subject: Python Eggs and problem with %{python_sitelib} In-Reply-To: References: Message-ID: <200801152250.12079.opensource@till.name> On Tue January 15 2008, Marcin Zaj?czkowski wrote: > Is it really required to define that variable at the beginning of every > SPEC file (eventually use %{_libdir}/python*/site-packages/) or it > should be already defined in the system? You have to define it in the spec, regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From sundaram at fedoraproject.org Tue Jan 15 22:00:07 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 16 Jan 2008 03:30:07 +0530 Subject: Where are the CD ISO's? (fwd) In-Reply-To: <200801152243.00189.opensource@till.name> References: <478D28AD.7090509@fedoraproject.org> <200801152243.00189.opensource@till.name> Message-ID: <478D2CE7.3030102@fedoraproject.org> Till Maas wrote: > On Tue January 15 2008, Rahul Sundaram wrote: > >> Live CD's are part of the "real" release too. You probably mean regular >> installable images and there isn't any easy way to convert them into a >> bootable USB image. > > Why is it not easy? ... because nobody has developed such a tool or packaged one for Fedora if it already exists. Rahul From marc at mwiriadi.id.au Tue Jan 15 22:02:04 2008 From: marc at mwiriadi.id.au (Marc Wiriadisastra) Date: Wed, 16 Jan 2008 07:02:04 +0900 Subject: diveintopython/book-prefix (was: Re: rawhide report: 20080111 changes) In-Reply-To: <478BAD8C.9030306@leemhuis.info> References: <200801111755.m0BHt2wY002105@porkchop.devel.redhat.com> <1200317221.24328.10.camel@gibraltar.str.redhat.com> <478B6938.5060008@fedoraproject.org> <478BAD8C.9030306@leemhuis.info> Message-ID: <1200434524.30057.26.camel@localhost.localdomain> On Mon, 2008-01-14 at 19:44 +0100, Thorsten Leemhuis wrote: > On 14.01.2008 14:52, Rahul Sundaram wrote: > > Nils Philippsen wrote: > >> On Fri, 2008-01-11 at 12:55 -0500, Build System wrote: > >>> New package diveintopython > >>> Dive into Python - a python book > >> Have we relaxed our "code vs. content" policy lately? While I'm not > >> personally against having this package in, I don't think it falls under > >> the "Package documentation or help files" exception in > >> Packaging/Guidelines, or does it? > > There was a small discussion about this in this list and the general > > consensus seemed to be that such documentation is allowed. > > I think it's fine to ship it. But one thing looks odd to me: we use a > lot of prefixes for packages in our repo already (fuse-, perl-, or > python- are just some examples). I actually posted to the list about documentation awhile ago the thread didn't grow legs. I then obviously got it approved to go through.... I would think the description or summary. A python book. Cheers, Marc From notting at redhat.com Tue Jan 15 22:03:17 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 15 Jan 2008 17:03:17 -0500 Subject: Fedora bug triage - workflow proposal In-Reply-To: References: <20080115185925.GE9082@nostromo.devel.redhat.com> <1200432097.28156.13.camel@vincent52.localdomain> Message-ID: <20080115220317.GA26378@nostromo.devel.redhat.com> Jon Stanley (jonstanley at gmail.com) said: > On Jan 15, 2008 4:21 PM, Matthew Saltzman wrote: > > > (I'm usually just a lurker on discussions like this, but I couldn't > > resist.) > > > > NEW -> CONFIRMED -> ASSIGNED ? > > Got some word on this off-list - it is a non-trivial endeavor to add > states, it adds nothing to the workflow. Let's not get into a > discussion here whereby we're arguing over what color the bike shed > is...to quote: I know the story. I still think telling the user their bug is ASSIGNED when it still may be completely ignored is bad form. The developers are generally more adaptable than the users filing the bugs - things like UNCONFIRMED, NEW, ASSIGNED are all easily understandable. ON_QA, ON_DEV are not. (Also, the prior states are all in *upstream* bugzilla, as opposed to RH inventions - if we use those, we'll have common states across bugzillas.) Bill From alan at redhat.com Tue Jan 15 22:03:25 2008 From: alan at redhat.com (Alan Cox) Date: Tue, 15 Jan 2008 17:03:25 -0500 Subject: Fedora bug triage - workflow proposal In-Reply-To: References: <20080115185925.GE9082@nostromo.devel.redhat.com> <1200432097.28156.13.camel@vincent52.localdomain> Message-ID: <20080115220325.GB15302@devserv.devel.redhat.com> On Tue, Jan 15, 2008 at 04:36:42PM -0500, Jon Stanley wrote: > Parkinson explains that this is because an atomic plant is so vast, so > expensive and so complicated that people cannot grasp it, and rather > than try, they fall back on the assumption that somebody else checked > all the details before it got this far. Richard P. Feynmann gives a There is another more unkind interpretation. An atomic power plant is also so complex that the person who made the decision is entirely absolved of blame. Nobody can hold them responsible for the decision because they were clearly misled by experts. Thus a large project is all gain no blame (for the manager). Either it succeeds "such vision by the board" or it fails "poorly advised" Alan From mcepl at redhat.com Tue Jan 15 22:11:13 2008 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 15 Jan 2008 23:11:13 +0100 Subject: Fedora bug triage - workflow proposal References: <1200396300.5174.158.camel@beck.corsepiu.local> Message-ID: <1lnv55x6g.ln2@ppp1053.in.ipex.cz> On 2008-01-15, 11:25 GMT, Ralf Corsepius wrote: >> 3) Assuming bug survives through the triage team, it changes >> state to ASSIGNED > > To whom? > > IMO, the real problem is getting a competent volunteer involved who is > likely sufficiently knowledgeable about a particular issue. i.e. to > communicate such issues, such that a volunteer can take action when _he_ > wants. My bugmastering experience is that it is absolutely essential for bug triager to be in continuous contact (IRC, Jabber, etc.) with developers of the set of components she triages. From which it follows, that people should be triaging only limited number of components, where they also are able to provide workarounds, see problems in configuration, know what kind of developers need and can get (infamouse "please, attach /etc/X11/xorg.conf and /var/log/Xorg.*.log as uncompressed separate attachments to this bug." -- my wife tells me that I am talking this phrase while sleeping ;-)) and so forth. Mat?j From mcepl at redhat.com Tue Jan 15 22:05:42 2008 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 15 Jan 2008 23:05:42 +0100 Subject: Fedora bug triage - workflow proposal References: <20080115084900.GA2691@free.fr> <478C86F9.30405@fedoraproject.org> <20080115101257.GC2691@free.fr> Message-ID: On 2008-01-15, 10:12 GMT, Patrice Dumas wrote: > When I have a look at a number of bugs (for example my bugs) it > allows for me to know which ones I don't have to care about > since they are in wait for somebody to move. Don't use NEEDINFO for that bug some whiteboard -- I usually use Status whiteboard, but I am not sure that it is the one. Mat?j From lordmorgul at gmail.com Tue Jan 15 22:25:59 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Tue, 15 Jan 2008 14:25:59 -0800 Subject: spotlight in fedora 8 In-Reply-To: <1200430837.4008.0.camel@localhost.localdomain> References: <20080115170004.50B6A73681@hormel.redhat.com> <1200430837.4008.0.camel@localhost.localdomain> Message-ID: <478D32F7.30203@gmail.com> Salloum EL DAHDAAH wrote: > I didnt understand what is the 4 th software written in message 7 and 8 > thank you The Silmarillion is a book by J.R.R. Tolkien, and was a joke on the misspelled word in the first post. See: http://en.wikipedia.org/wiki/The_Silmarillion The first three search tools mentioned are the answers to your original post. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From ml at deadbabylon.de Tue Jan 15 22:28:34 2008 From: ml at deadbabylon.de (Sebastian Vahl) Date: Tue, 15 Jan 2008 23:28:34 +0100 Subject: KDE-SIG weekly report (03/2008) Message-ID: <200801152328.39308.ml@deadbabylon.de> This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply ?to this email or add it to the related meeting page. ---------------------------------------------------------------------------------- = Weekly KDE Summary = Week: 03/2008 Time: 2008-01-15 16:00 UTC Meeting page: http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-01-15 Meeting log: http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-01-15?action=AttachFile&do=get&target=fedora-kde-sig-2008-01-15.txt ---------------------------------------------------------------------------------- = Participants = - DennisGilmore - KevinKofler - RexDieter - SebastianVahl - ThanNgo - "fengshaun" (IRC-Nick) - "No5251" (IRC-Nick) ---------------------------------------------------------------------------------- = Agenda = * feedback of kde-4.0.0 live image [1] * preparing for Fedora 9 Alpha [2] * swfdec is proposed to be installed by default in Gnome spin. What about konqueror? [3,4] * KDE 4.0.0 at kde-redhat.org: Useful to get testers or too much work? = Summary = o feedback of kde-4.0.0 live image - good feedback: https://www.redhat.com/archives/fedora-list/2008-January/msg01754.html [5] - should be verified which problems should go upstream and which ones to our bugzilla - we should try to test vesa support and get a testing matrix up (it seems to run on some machines and on some not) - Everyone with an intel graphics card should test the livecd with xdriver=vesa - RexDieter will also set up a torrent for the livecd o preparing for Fedora 9 Alpha - problems with kde-l10n/kde-i18n should be sorted out until the alpha freeze (conflicts between kde3 and kde4) - ThanNgo will take care about that - decision about alternative menu as default was postponed to kde-4.0.1 (it was implemented last minute in kde-4.0.0 and isn't configurable (yet)) o swfdec is proposed to be installed by default in Gnome spin. What about konqueror? (1) - swfdec-konqueror was only initially imported but no further commits were done - Klash (the kpart of gnash) should also be verified but must be ported to kde4 - We'll add "finding a flash solution" to our todo list for F9 o KDE 4.0.0 at kde-redhat.org: Useful to get testers or too much work? - RexDieter will work on getting kde-4.0.0 into kde-redhat-unstable for Fedora 8 o Open discussion - SebastianVahl is thinking about replacing kaffeine with dragonplayer on the live images. But the latter lacks some features in comparison to kaffeine - Okteta finally got a reviewer - Quarticurve-KWin's review is mostly finished - RahulSanduram is thinking about writing an article on KDE 4 for Red Hat Magazine and asked for generall interest and possible reviewers. ---------------------------------------------------------------------------------- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-01-22 ---------------------------------------------------------------------------------- = Links = [1] https://www.redhat.com/archives/fedora-test-list/2008-January/msg00145.html [2] http://fedoraproject.org/wiki/Releases/9/Schedule [3] https://www.redhat.com/archives/fedora-desktop-list/2008-January/msg00075.html [4] http://lists.freedesktop.org/archives/swfdec/2007-July/000419.html [5] https://www.redhat.com/archives/fedora-list/2008-January/msg01754.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From pertusus at free.fr Tue Jan 15 22:49:59 2008 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 15 Jan 2008 23:49:59 +0100 Subject: Fedora bug triage - workflow proposal In-Reply-To: References: <20080115084900.GA2691@free.fr> <478C86F9.30405@fedoraproject.org> <20080115101257.GC2691@free.fr> Message-ID: <20080115224959.GG2672@free.fr> On Tue, Jan 15, 2008 at 11:05:42PM +0100, Matej Cepl wrote: > On 2008-01-15, 10:12 GMT, Patrice Dumas wrote: > > When I have a look at a number of bugs (for example my bugs) it > > allows for me to know which ones I don't have to care about > > since they are in wait for somebody to move. > > Don't use NEEDINFO for that bug some whiteboard -- I usually use > Status whiteboard, but I am not sure that it is the one. What you are saying looks like interesting but I don't understand. Could you please be more specific? What is a whiteboard in this context? -- Pat From jkeating at redhat.com Tue Jan 15 22:50:43 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 15 Jan 2008 17:50:43 -0500 Subject: Where are the CD ISO's? (fwd) In-Reply-To: <200801152242.13976.opensource@till.name> References: <200801152227.38455.opensource@till.name> <20080115213246.GD22768@nostromo.devel.redhat.com> <200801152242.13976.opensource@till.name> Message-ID: <20080115175043.191b3ea7@redhat.com> On Tue, 15 Jan 2008 22:42:09 +0100 Till Maas wrote: > Using livecd-iso-to-usb was an answer that was given to the question, > how to get this (using the installation medium with usb) done. Then I > asked, whether this really works and explained how it could work. > Maybe installationmedia-image-to-usb would be a better name for such > a programm, but I guess most of the code would be common with > livecd-iso-to-usb. The only common code would be the part that makes the usb bootable. The rest would be vastly different. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Tue Jan 15 23:03:40 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 16 Jan 2008 04:33:40 +0530 Subject: Fedora bug triage - workflow proposal In-Reply-To: <20080115224959.GG2672@free.fr> References: <20080115084900.GA2691@free.fr> <478C86F9.30405@fedoraproject.org> <20080115101257.GC2691@free.fr> <20080115224959.GG2672@free.fr> Message-ID: <478D3BCC.7070603@fedoraproject.org> Patrice Dumas wrote: > On Tue, Jan 15, 2008 at 11:05:42PM +0100, Matej Cepl wrote: >> On 2008-01-15, 10:12 GMT, Patrice Dumas wrote: >>> When I have a look at a number of bugs (for example my bugs) it >>> allows for me to know which ones I don't have to care about >>> since they are in wait for somebody to move. >> Don't use NEEDINFO for that bug some whiteboard -- I usually use >> Status whiteboard, but I am not sure that it is the one. > > What you are saying looks like interesting but I don't understand. Could > you please be more specific? What is a whiteboard in this context? Bugzilla has a status whiteboard feature. http://www.mozilla.org/bugs/ "Status Whiteboard The Status Whiteboard is used for writing short notes about the bug." Rahul From mike at miketc.com Tue Jan 15 22:54:21 2008 From: mike at miketc.com (Mike Chambers) Date: Tue, 15 Jan 2008 16:54:21 -0600 Subject: anaconda - unhandled exception In-Reply-To: <20080115134539.GB9011@dhcp83-45.boston.redhat.com> References: <478C68EC.6030201@mindspring.com> <478C7385.80308@gmail.com> <1200398322.2903.2.camel@scrappy.miketc.com> <20080115134539.GB9011@dhcp83-45.boston.redhat.com> Message-ID: <1200437661.2899.10.camel@scrappy.miketc.com> On Tue, 2008-01-15 at 08:45 -0500, Chris Lumens wrote: > > Keep it up Jeremy, ya bout got it licked! > > Not to be a jerk or anything, but you're aware at least five other > people work on anaconda, right? In fact if you were to check out the > source history, you'd see that I committed the fix for that bug (the > libraries out of the nss package changed location, requiring us to > modify the stage2 build script) and that David built the version > containing the fix. NO, I was not aware there were others working on anaconda, or at least as much as Jeremy does/used to. I visited the page Rahul posted earlier and see everyone that is listed. So to you ALL, keep up the good work and hope to see/use an even nicer looking/working installer for the next release. For some reason, been dying to get back to using rawhide like I used to, but have stayed away little longer this release due to x upgrades and the like. Sooo, upon saying all that, what *is* the status of anaconda now? Will it do an install now at this point or is there a couple things still broken? Reallllyy thinking of trying another install again tonight, but not sure yet. Might file my taxes first then look into it in a little while. Keep up the good work Anaconda team! -- Mike Chambers Madisonville, KY "The best lil town on Earth!" From mcepl at redhat.com Tue Jan 15 22:59:49 2008 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 15 Jan 2008 23:59:49 +0100 Subject: Fedora bug triage - workflow proposal References: Message-ID: <5gqv55xcl.ln2@ppp1053.in.ipex.cz> On 2008-01-15, 04:46 GMT, Jon Stanley wrote: > 6) When the update is pushed to stable, Bodhi optionally > closes the bug automatically. If the update does not > auto-close the bug, it transitions to NEEDINFO_REPORTER, with > a comment explaining that the update has been pushed to stable, > and to update and test in the new release. Hello, (just for those who don't know it already) I am a bugmaster (or bug triager, if you wish) of the desktop team. I think that this proposal is pretty sane, so I have just a little nitpicking comments (nitpicking is a substance of bugmaster's work ;-)). (so the really nitpicking is that there is no NEEDINFO_REPORTER, but only regular NEEDINFO targeted towards reporter). > It was also decided that when a bug is in NEEDINFO for one > month, it will be closed. Maintainers would need to realize > that putting a bug in NEEDINFO is putting it on the fast track > for closure. Although I think I am pretty tough on both reporters and developers in this regard (and I get flamed all the time for bugs I closed because somebody hasn't bothered to answer the request for information in half-a-year), I would never subscribe to so draconical policy as this. The sad state of life is that all NEEDINFO bugs need to be followed manually (there are some tools which can help -- about which later): a) Bugzilla is not reliable in changing from NEEDINFO -- some problems are cause by bugs in bugzilla (e.g., attachments don't count), but sometime it is error of some human. b) On the other hand, there many bugs which are not in NEEDINFO even though they should be. For example quite often the message which bugzilla counts as an answer to originally request is something like "Sorry, that I cannot answer now, I will get to my office computer only after Christmas" (I met plenty of them in December). So, a bug triager should see such message and just switch the bug back to NEEDINFO without much ado. c) Sometimes emails are just not enough reliable -- somebody deletes email by mistake, it gets filtered somewhere, SA is too active, etc. One more kick is worthy especially when it is low cost (we have to see those bugs anyway). d) The last argument which I hear quite often is just a fundamental fairness -- we have bugs in bugzilla opened as NEW even for years and now we are closing reporters' bugs after a month? Yes, exactly by more draconical measures we won't to make our bugzilla more functional, but we are not there yet and we won't be for some time, it is huge amount of work we need to do. e) there are some other arguments but I am too sleep deprived to remember them now. ;-) So, what I propose is that at least somebody has to see all obsolete NEEDINFOs before they are closed. I would love to see people actually following all bugmail for particular component or sets of components and fixing the goo reporters (and developers) leave in bugzilla, but that's probably too demanding for non-professional bug triagers. Concerning tools, I use for my bugs this search https://bugzilla.redhat.com/buglist.cgi?cmdtype=runnamed\ &namedcmd=old%20NEEDINFO%202&namedowner=mcepl%40redhat.com (run this search, then click on "Edit search" in the results, change the set of packages you follow, run the search again, and save it to your preferred searches just next to search which finds all NEW bugs in your components). It is probably the best what we can get (if somebody has any ideas how to make this more reliable just go ahead), and it can be pretty easily screwed up -- when somebody decides that it needs to touch all bugs in bugzilla (for example, because of renaming and renumbering products -- happened in December), this searches gets out of whack and reports obsolete NEEDINFO a month later -- all 175 of them at once (in my case ;-)). However, modulo these bugs it is pretty useful. Another useful thing (at least useful for me) are these Greasemonkey scripts, available at fedorapeople.org. Get them by running git clone http://mcepl.fedorapeople.org/repo/greasemonkey.git and install them as any other Greasemonkey script (if you were living under a rock for the past four or so years, and you don't know what Greasemonkey is go to http://en.wikipedia.org/wiki/Greasemonkey and enlighten yourself). It will create couple of useful (and less useful for you) buttons in every webpage you visit. Patches are welcome. I will probably reorganize the scripts to those which are just for my personal use and those which could be used by others (however, I am afraid that some customization will be necessary always -- these scripts are just too desktop-centric; which means also that there will never be a package of this script). Comments? Mat?j From opensource at till.name Tue Jan 15 23:01:59 2008 From: opensource at till.name (Till Maas) Date: Wed, 16 Jan 2008 00:01:59 +0100 Subject: Where are the CD ISO's? (fwd) In-Reply-To: <20080115175043.191b3ea7@redhat.com> References: <200801152242.13976.opensource@till.name> <20080115175043.191b3ea7@redhat.com> Message-ID: <200801160002.10129.opensource@till.name> On Tue January 15 2008, Jesse Keating wrote: > On Tue, 15 Jan 2008 22:42:09 +0100 > > Till Maas wrote: > > Using livecd-iso-to-usb was an answer that was given to the question, > > how to get this (using the installation medium with usb) done. Then I > > asked, whether this really works and explained how it could work. > > Maybe installationmedia-image-to-usb would be a better name for such > > a programm, but I guess most of the code would be common with > > livecd-iso-to-usb. > > The only common code would be the part that makes the usb bootable. > The rest would be vastly different. I just played around with it a little, when I use livecd-iso-to-disk on the Fedora 8 i386 iso Image, a bootable stick is created. It does not boot with my USB hd (or maybe it just needs a lot longer than with the 1 GB stick). When I boot from the stick, anaconda allows to select to install from harddisk. Both devices are then found. The only problem is, that anaconda does not recognize the iso image, it says on some console, that the Fedora-8-i386-DVD.iso image is not the right one. In German it also only mentions CDs but not DVDs, don't know, whether this is an issue. Long story short: The only extra code seems to be to copy the iso image(s) to the usb device, given that anaconda supports using a harddisk for installation source and can use the iso files. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From mcepl at redhat.com Tue Jan 15 23:07:10 2008 From: mcepl at redhat.com (Matej Cepl) Date: Wed, 16 Jan 2008 00:07:10 +0100 Subject: Fedora bug triage - workflow proposal References: <20080115084900.GA2691@free.fr> <478C86F9.30405@fedoraproject.org> <20080115101257.GC2691@free.fr> <20080115224959.GG2672@free.fr> Message-ID: On 2008-01-15, 22:49 GMT, Patrice Dumas wrote: > What you are saying looks like interesting but I don't > understand. Could > you please be more specific? What is a whiteboard in this context? Go to https://bugzilla.redhat.com/show_bug.cgi?id=243255 and scroll down the page -- the third line in "Additional information" is "Status Whiteboard" where you can (I believe anybody with login can, but I am not sure as I have no unprivileged BZ account around) write whatever. The text in this field can be then searched with BZ queries. There is nothing to stop you (if you have rights) to write there something like "PatriceBugsNeedingMyAttention". Mat?j From pertusus at free.fr Tue Jan 15 23:12:25 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 16 Jan 2008 00:12:25 +0100 Subject: Fedora bug triage - workflow proposal In-Reply-To: References: <20080115084900.GA2691@free.fr> <478C86F9.30405@fedoraproject.org> <20080115101257.GC2691@free.fr> <20080115224959.GG2672@free.fr> Message-ID: <20080115231224.GI2672@free.fr> On Wed, Jan 16, 2008 at 12:07:10AM +0100, Matej Cepl wrote: > On 2008-01-15, 22:49 GMT, Patrice Dumas wrote: > > What you are saying looks like interesting but I don't > > understand. Could > > you please be more specific? What is a whiteboard in this context? > > Go to https://bugzilla.redhat.com/show_bug.cgi?id=243255 and > scroll down the page -- the third line in "Additional > information" is "Status Whiteboard" where you can (I believe > anybody with login can, but I am not sure as I have no > unprivileged BZ account around) write whatever. The text in this > field can be then searched with BZ queries. There is nothing to > stop you (if you have rights) to write there something like > "PatriceBugsNeedingMyAttention". I see, but does this field appear in lists generated by buglist.cgi? It doesn't seems to me, while the status does. -- Pat From mjs at CLEMSON.EDU Tue Jan 15 23:26:16 2008 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Tue, 15 Jan 2008 18:26:16 -0500 Subject: Fedora bug triage - workflow proposal In-Reply-To: References: <20080115185925.GE9082@nostromo.devel.redhat.com> <1200432097.28156.13.camel@vincent52.localdomain> Message-ID: <1200439576.31730.21.camel@vincent52.localdomain> On Tue, 2008-01-15 at 16:36 -0500, Jon Stanley wrote: > On Jan 15, 2008 4:21 PM, Matthew Saltzman wrote: > > > (I'm usually just a lurker on discussions like this, but I couldn't > > resist.) > > > > NEW -> CONFIRMED -> ASSIGNED ? > > Got some word on this off-list - it is a non-trivial endeavor to add > states, it adds nothing to the workflow. Let's not get into a > discussion here whereby we're arguing over what color the bike shed > is...to quote: > ... > > In Denmark we call it "setting your fingerprint". It is about > personal pride and prestige, it is about being able to point somewhere > and say "There! *I* did that." It is a strong trait in politicians, > but present in most people given the chance. Just think about > footsteps in wet cement. I don't have a battlebot (can't say dog anymore) in this fight. But I do think it's important to have statuses that convey to the common user some real information about state of the bug. Initiates (such as maintainers and readers of this list) may easily understand that ASSIGNED is a symbol with a meaning that is not intuitive (and in particular doesn't mean that somebody is responsible), but a "normal" user who was not privy to this discussion will not understand that. You'll spend a lot of time dealing with the frustrations of such users and you'll create a lot of frustrated users and animosity toward maintainers--more than necessary. > > > > -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From emmanuel.seyman at club-internet.fr Tue Jan 15 23:27:18 2008 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Wed, 16 Jan 2008 00:27:18 +0100 Subject: Fedora bug triage - workflow proposal In-Reply-To: <20080115231224.GI2672@free.fr> References: <20080115084900.GA2691@free.fr> <478C86F9.30405@fedoraproject.org> <20080115101257.GC2691@free.fr> <20080115224959.GG2672@free.fr> <20080115231224.GI2672@free.fr> Message-ID: <20080115232718.GA1741@orient.maison.lan> * Patrice Dumas [16/01/2008 00:22] : > > I see, but does this field appear in lists generated by buglist.cgi? You can choose which columns appear in a buglist. Just click on the "Change Columns" link at the bottom of the page. Whiteboard is probably the field you're looking for. Emmanuel From opensource at till.name Tue Jan 15 23:32:07 2008 From: opensource at till.name (Till Maas) Date: Wed, 16 Jan 2008 00:32:07 +0100 Subject: Where are the CD ISO's? (fwd) In-Reply-To: <200801160002.10129.opensource@till.name> References: <20080115175043.191b3ea7@redhat.com> <200801160002.10129.opensource@till.name> Message-ID: <200801160032.14993.opensource@till.name> On Wed January 16 2008, Till Maas wrote: > Long story short: The only extra code seems to be to copy the iso image(s) > to the usb device, given that anaconda supports using a harddisk for > installation source and can use the iso files. With the CentOS 4.4 Server CD (CentOS-4.4.ServerCD-i386.iso) this seems to work. Anaconda finds stage 2 and I get the disk druid screen. I did not try any further. I only needed to copy the iso to the usb stick after runnung livecd-iso-to-disk with the iso and selected install from harddisk. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From mr.ecik at gmail.com Tue Jan 15 23:58:03 2008 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Wed, 16 Jan 2008 00:58:03 +0100 Subject: Global definitions (Re: Python Eggs and problem with %{python_sitelib}) Message-ID: <668bb39a0801151558s151493agf48d3776871c6fdc@mail.gmail.com> 15-01-08, Till Maas napisa?(a): > You have to define it in the spec, > It's a good occasion to ask why. Why don't we define it globally? A few more snippets can be found that would be good to already defined. For example: everybody needs to type the same lines to update gtk icon cache. Does anything stands in the way to define %update_gtk_icon_cache globally? -- Micha? Bentkowski mr.ecik at gmail.com From tgl at redhat.com Wed Jan 16 00:09:16 2008 From: tgl at redhat.com (Tom Lane) Date: Tue, 15 Jan 2008 19:09:16 -0500 Subject: rpms/sepostgresql/devel postgresql-8.2.6.tar.gz, NONE, 1.1 .cvsignore, 1.4, 1.5 sepostgresql.init, 1.8, 1.9 sepostgresql.spec, 1.8, 1.9 sepostgresql.te, 1.8, 1.9 In-Reply-To: <20080115091154.a99c1fb2.mschwendt.tmp0701.nospam@arcor.de> References: <200801101437.m0AEbemG002515@cvs-int.fedora.redhat.com> <1199983507.3398.14.camel@localhost.localdomain> <20080114120951.4c9df209.mschwendt.tmp0701.nospam@arcor.de> <478B724F.4010002@kaigai.gr.jp> <20080114155558.83443828.mschwendt.tmp0701.nospam@arcor.de> <478B890B.2070005@kaigai.gr.jp> <20080115091154.a99c1fb2.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <15352.1200442156@sss.pgh.pa.us> BTW, I'm planning to push postgresql 8.3 into rawhide very soon (actually it'll likely be 8.3RC2 at first, just to make sure it gets in there before F9 alpha freeze). Don't know what impact that will have on sepostgresql. If you won't be ready to update, it might be necessary to decouple the two packages after all. regards, tom lane From sesanach at gmail.com Wed Jan 16 00:23:44 2008 From: sesanach at gmail.com (Sam Gordon) Date: Tue, 15 Jan 2008 18:23:44 -0600 Subject: Orphaning/retiring some KDE3 packages In-Reply-To: <200801151406.06890.faucamp@csir.co.za> References: <200801151243.25612.faucamp@csir.co.za> <200801151209.50523.ml@deadbabylon.de> <200801151406.06890.faucamp@csir.co.za> Message-ID: <1dfb71690801151623q1a4c1338qbbbb90396d1bdcef@mail.gmail.com> how do i stop receiving these emails from ur bulletins? sumone registered my email and now i wont stop receiving these emails from u guys....i want it to stop i know nothing bout this fedora thing On Jan 15, 2008 6:06 AM, Francois Aucamp wrote: > On Tuesday 15 January 2008 01:09:45 pm Sebastian Vahl wrote: > > > > amarok2 is still in pre-alpha stage. I'm not aware of any release > schedule > > for amarok2 so we'll see if this is ready for f9 (but I might be wrong > > here). If not, still having amarokFS for amarok1 would be nice. > > > > Indeed; I was assuming amarok2 would ship with f9... So (since there's > still > interest), I will continue to maintain amarokFS. :-) > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewparker at bigfoot.com Wed Jan 16 00:55:04 2008 From: andrewparker at bigfoot.com (Andrew Parker) Date: Tue, 15 Jan 2008 19:55:04 -0500 Subject: KDE-SIG weekly report (03/2008) In-Reply-To: <200801152328.39308.ml@deadbabylon.de> References: <200801152328.39308.ml@deadbabylon.de> Message-ID: <6c3f5e6c0801151655n5f60ea7bxa66ee9b4cb916650@mail.gmail.com> 2008/1/15 Sebastian Vahl : > - we should try to test vesa support and get a testing matrix up (it seems to > run on some machines and on some not) > - Everyone with an intel graphics card should test the livecd with > xdriver=vesa I have a laptop with an intel GM965/GL960 graphics card, but I'm not sure what the xdriver=vesa is supposed to be fixing. I get the same results when using xdriver=vesa and without. i.e. the text during rhgb is corrupted on both the progress bar view and the details view. KDE is fine with or without vesa though. Is there something else that I should be looking for? From lordmorgul at gmail.com Wed Jan 16 01:06:05 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Tue, 15 Jan 2008 17:06:05 -0800 Subject: anaconda - unhandled exception In-Reply-To: <1200437661.2899.10.camel@scrappy.miketc.com> References: <478C68EC.6030201@mindspring.com> <478C7385.80308@gmail.com> <1200398322.2903.2.camel@scrappy.miketc.com> <20080115134539.GB9011@dhcp83-45.boston.redhat.com> <1200437661.2899.10.camel@scrappy.miketc.com> Message-ID: <478D587D.1050600@gmail.com> Mike Chambers wrote: > On Tue, 2008-01-15 at 08:45 -0500, Chris Lumens wrote: >>> Keep it up Jeremy, ya bout got it licked! >> Not to be a jerk or anything, but you're aware at least five other >> people work on anaconda, right? In fact if you were to check out the >> source history, you'd see that I committed the fix for that bug (the >> libraries out of the nss package changed location, requiring us to >> modify the stage2 build script) and that David built the version >> containing the fix. > > NO, I was not aware there were others working on anaconda, or at least > as much as Jeremy does/used to. I visited the page Rahul posted earlier > and see everyone that is listed. So to you ALL, keep up the good work > and hope to see/use an even nicer looking/working installer for the next > release. For some reason, been dying to get back to using rawhide like > I used to, but have stayed away little longer this release due to x > upgrades and the like. > > Sooo, upon saying all that, what *is* the status of anaconda now? Will > it do an install now at this point or is there a couple things still > broken? Reallllyy thinking of trying another install again tonight, but > not sure yet. Might file my taxes first then look into it in a little > while. > > Keep up the good work Anaconda team! > The 20080115 repo version of boot.iso and stage2.img worked in text mode for me today and its now 80% done with network install to vmware guest machine. It may not finish that install, don't know yet, but all looks good so far. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From mike at miketc.com Wed Jan 16 01:36:58 2008 From: mike at miketc.com (Mike Chambers) Date: Tue, 15 Jan 2008 19:36:58 -0600 Subject: anaconda - unhandled exception In-Reply-To: <478D587D.1050600@gmail.com> References: <478C68EC.6030201@mindspring.com> <478C7385.80308@gmail.com> <1200398322.2903.2.camel@scrappy.miketc.com> <20080115134539.GB9011@dhcp83-45.boston.redhat.com> <1200437661.2899.10.camel@scrappy.miketc.com> <478D587D.1050600@gmail.com> Message-ID: <1200447418.2628.0.camel@scrappy.miketc.com> On Tue, 2008-01-15 at 17:06 -0800, Andrew Farris wrote: > The 20080115 repo version of boot.iso and stage2.img worked in text mode for me > today and its now 80% done with network install to vmware guest machine. It may > not finish that install, don't know yet, but all looks good so far. After the install tonight, or tomorrow, would you care to elaborate on how it went, any major failures and/or nuiances post-install? -- Mike Chambers Madisonville, KY "The best lil town on Earth!" From peter at thecodergeek.com Wed Jan 16 01:41:56 2008 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 15 Jan 2008 17:41:56 -0800 Subject: System xulrunner Extensions? [rpms/xulrunner/devel .cvsignore, 1.9, 1.10 sources, 1.9, 1.10 xulrunner.spec, 1.48, 1.49] In-Reply-To: <200801160056.m0G0u4Hp003503@cvs-int.fedora.redhat.com> References: <200801160056.m0G0u4Hp003503@cvs-int.fedora.redhat.com> Message-ID: <1200447717.3189.1.camel@tuxhugs> On Tue, 2008-01-15 at 19:56 -0500, Christopher Aillon wrote: > Log Message: > * Tue Jan 15 2008 Christopher Aillon 1.9-0.beta2.11 > - Update to latest trunk (2008-01-15) > - Now with system extensions directory support Just for my own curiosity, how complete is this system extensions support? Can we now package, for example, Enigmail for Thunderbird or AdBlock for Firefox as a system-level thing to make it a bit simpler for users? Thanks. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jreiser at BitWagon.com Wed Jan 16 01:54:25 2008 From: jreiser at BitWagon.com (John Reiser) Date: Tue, 15 Jan 2008 17:54:25 -0800 Subject: Where are the CD ISO's? (fwd) In-Reply-To: <200801152243.00189.opensource@till.name> References: <478D28AD.7090509@fedoraproject.org> <200801152243.00189.opensource@till.name> Message-ID: <478D63D1.8030303@BitWagon.com> >>You probably mean regular >>installable images and there isn't any easy way to convert them into a >>bootable USB image. > Why is it not easy? It can be easy. Use boot parameter "askmethod" with any device at all (including a minimal diskboot.img on USB, rescue CD, GRUB, etc.), then proceed. If the DVD fits onto your USB2.0 flash memory device, then copy the .iso as a file into some filesystem on a partition on the device, and do a harddrive install from .iso images. You must remember the path to the directory which contains the .iso. [I hope that the DVD stays below 4.0GB. A 4GB USB stick is somewhat inexpensive, while an 8GB USB stick costs more than twice as much.] For a CD install set whose .iso files all fit onto the same USB device, then the same technique works as long as all the .iso files are in the same directory. If the CDs don't all fit onto the same USB flash device, then it gets interesting. If you put each CD onto its own 1GB USB stick, then does anaconda handle changing USB sticks just like changing CDs? Or, in theory you could plug in all the USB sticks simultaneously, just like mounting multiple physical discs on multiple CD drives. -- From snecklifter at gmail.com Wed Jan 16 02:23:16 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Wed, 16 Jan 2008 02:23:16 +0000 Subject: Fedora bug triage - workflow proposal In-Reply-To: <1200419829.3001.29.camel@gandalf.cobite.com> References: <478CB717.4000202@fedoraproject.org> <364d303b0801150901i20b6b30cs923506c0ebc2e3d8@mail.gmail.com> <1200419829.3001.29.camel@gandalf.cobite.com> Message-ID: <364d303b0801151823p34801e4bga2a8ae9a53ef15ee@mail.gmail.com> On 15/01/2008, David Mansfield wrote: > > On Tue, 2008-01-15 at 17:01 +0000, Christopher Brown wrote: > > On 15/01/2008, Rahul Sundaram wrote: > > > Jon Stanley wrote: > > > > > > > > 1) Reporter files a bug report, it originates in NEW state > > > > > > Can we renamed this state to UNCONFIRMED? > > > > NEW or UNCONFIRMED, its six of one, half-a-dozen of the other... > > > > > > 2) Triage team looks at bug report, determines if dupe or > > > > insufficient information exists to solve it. If there is not enough > > > > information in the bug, then triage team puts the bug in NEEDINFO. As > > > > you will see below, this state has a finite life cycle associated with > > > > it. > > > > 3) Assuming bug survives through the triage team, it changes state to > > > > ASSIGNED (triage team can put it in either NEEDINFO or CLOSED, as > > > > appropriate). Note that per the definition[1], ASSIGNED does not mean > > > > that someone has actually agreed to take action, simply that the issue > > > > is well defined and triaged accordingly > > > > > > Wouldn't a state like TRIAGED be more meaningful then? ASSIGNED > > > frequently is assumed to be assuming ownership by the maintainers. > > > > ASSIGNED is easier and more understandable to people who have language > > barriers to contend with. > > > > > > 4) Once a developer has taken responsibility for a bug and is > > > > actively working on it, the state transitions to ON_DEV. > > > > Sounds good. > > > > > If ASSIGNED is renamed to TRIAGED, then this state can be known as > > > ASSIGNED instead. > > > > I'm keen not to get lost in arguing about the names of states. I think > > all is fine as is - the issue here is workflow and what is best for > > that. > > > > I disagree and agree with the original poster, more or less, and I think > names ARE important. Do you name a variable tracking weight as 'height' > in your program? No. So names are important AND they should be > understandable for non-native speakers. I believe using ASSIGNED when > it's _not_ assigned is a bad design choice, and using ON_DEV for > ASSIGNED is also a bad choice, but I agree with you, TRIAGED is a bad > choice for the WAITING_FOR_MANPOWER state... In my triage work I use NEW, NEEDINFO and ASSIGNED for 95% of all open bugs. Anything else I should not care about because it doesn't involve me. I take NEW bugs and move them either to NEEDINFO or, if I think there is enough for the maintainer to go on, I move it to ASSIGNED. It is then up to the maintainer to resolve the bug in which ever way they see fit. NEW - A new bug NEEDINFO - We need more info before we can proceed ASSIGNED - Probably a bug, maintainer please review Not difficult, pretty clear and no name changes required. Jon made the point that the flipside to assigning bugs to maintainers is that an equal if not greater number will be closed. Essentially, the above is the workflow I'm using and for the past three months it has worked very well. Cheers -- Christopher Brown http://www.chruz.com From subhodip at fedoraproject.org Wed Jan 16 02:42:33 2008 From: subhodip at fedoraproject.org (subhodip biswas) Date: Wed, 16 Jan 2008 08:12:33 +0530 Subject: spotlight in fedora 8 In-Reply-To: <478D32F7.30203@gmail.com> References: <20080115170004.50B6A73681@hormel.redhat.com> <1200430837.4008.0.camel@localhost.localdomain> <478D32F7.30203@gmail.com> Message-ID: <539333cb0801151842t2606891v601b94cf2382180e@mail.gmail.com> On Jan 16, 2008 3:55 AM, Andrew Farris wrote: > Salloum EL DAHDAAH wrote: > > I didnt understand what is the 4 th software written in message 7 and 8 > > thank you i mentioned about "deskbar" ... an application pretty similar to spotlight in Mac os x . It is kind of wierd that that mail is not in the digest ... while my reply to correction is there ... -- Regards Subhodip Biswas GPG key : FAEA34AB Server : pgp.mit.edu http://subhodipbiswas.wordpress.com http:/www.fedoraproject.org/wiki/SubhodipBiswas From caillon at redhat.com Wed Jan 16 02:44:52 2008 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 16 Jan 2008 03:44:52 +0100 Subject: System xulrunner Extensions? [rpms/xulrunner/devel .cvsignore, 1.9, 1.10 sources, 1.9, 1.10 xulrunner.spec, 1.48, 1.49] In-Reply-To: <1200447717.3189.1.camel@tuxhugs> References: <200801160056.m0G0u4Hp003503@cvs-int.fedora.redhat.com> <1200447717.3189.1.camel@tuxhugs> Message-ID: <478D6FA4.8010907@redhat.com> On 01/16/2008 02:41 AM, Peter Gordon wrote: > On Tue, 2008-01-15 at 19:56 -0500, Christopher Aillon wrote: >> Log Message: >> * Tue Jan 15 2008 Christopher Aillon 1.9-0.beta2.11 >> - Update to latest trunk (2008-01-15) >> - Now with system extensions directory support > > Just for my own curiosity, how complete is this system extensions > support? Can we now package, for example, Enigmail for Thunderbird or > AdBlock for Firefox as a system-level thing to make it a bit simpler for > users? For your own curiosity, you sure have a funny way of asking on a public forum. Yes, I wrote this support and pushed it upstream to be complete. I had waited on committing to any Fedora branches until it made it upstream as there was debate about the location name. However there are caveats: * It will only work for applications based upon XULRunner. Meaning, not Thunderbird (yet). * Packaging Guidelines are still being formulated[1], so be patient. * It's noteworthy that many extensions do not have original sources available or are under bizarre licenses which would eliminate them from consideration for inclusion in Fedora. * Most extensions are not yet compatible with Firefox 3.0 yet anyway, so there's some time yet. [1] I've already been in touch with a member or two of FPC to get this started, but we aren't finished yet and as I'm travelling over the next few days is unlikely to get done until next week some time. From lordmorgul at gmail.com Wed Jan 16 02:46:37 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Tue, 15 Jan 2008 18:46:37 -0800 Subject: anaconda - unhandled exception In-Reply-To: <1200447418.2628.0.camel@scrappy.miketc.com> References: <478C68EC.6030201@mindspring.com> <478C7385.80308@gmail.com> <1200398322.2903.2.camel@scrappy.miketc.com> <20080115134539.GB9011@dhcp83-45.boston.redhat.com> <1200437661.2899.10.camel@scrappy.miketc.com> <478D587D.1050600@gmail.com> <1200447418.2628.0.camel@scrappy.miketc.com> Message-ID: <478D700D.6040802@gmail.com> Mike Chambers wrote: > On Tue, 2008-01-15 at 17:06 -0800, Andrew Farris wrote: > >> The 20080115 repo version of boot.iso and stage2.img worked in text mode for me >> today and its now 80% done with network install to vmware guest machine. It may >> not finish that install, don't know yet, but all looks good so far. > > After the install tonight, or tomorrow, would you care to elaborate on > how it went, any major failures and/or nuiances post-install? It had an issue, see https://bugzilla.redhat.com/show_bug.cgi?id=428927 Cannot unmount /mnt/source after downloading corrupt rpm. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From rc040203 at freenet.de Wed Jan 16 03:10:53 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 16 Jan 2008 04:10:53 +0100 Subject: Global definitions (Re: Python Eggs and problem with %{python_sitelib}) In-Reply-To: <668bb39a0801151558s151493agf48d3776871c6fdc@mail.gmail.com> References: <668bb39a0801151558s151493agf48d3776871c6fdc@mail.gmail.com> Message-ID: <1200453053.5174.218.camel@beck.corsepiu.local> On Wed, 2008-01-16 at 00:58 +0100, Micha? Bentkowski wrote: > 15-01-08, Till Maas napisa?(a): > > You have to define it in the spec, > > > > It's a good occasion to ask why. Why don't we define it globally? > A few more snippets can be found that would be good to already > defined. For example: everybody needs to type the same lines to update > gtk icon cache. Does anything stands in the way to define > %update_gtk_icon_cache globally? Yes. Once such rpm-macros are in, one can not get rid of them anymore. Ralf From kaigai at ak.jp.nec.com Wed Jan 16 03:39:42 2008 From: kaigai at ak.jp.nec.com (Kohei KaiGai) Date: Wed, 16 Jan 2008 12:39:42 +0900 Subject: rpms/sepostgresql/devel postgresql-8.2.6.tar.gz, NONE, 1.1 .cvsignore, 1.4, 1.5 sepostgresql.init, 1.8, 1.9 sepostgresql.spec, 1.8, 1.9 sepostgresql.te, 1.8, 1.9 In-Reply-To: <15352.1200442156@sss.pgh.pa.us> References: <200801101437.m0AEbemG002515@cvs-int.fedora.redhat.com> <1199983507.3398.14.camel@localhost.localdomain> <20080114120951.4c9df209.mschwendt.tmp0701.nospam@arcor.de> <478B724F.4010002@kaigai.gr.jp> <20080114155558.83443828.mschwendt.tmp0701.nospam@arcor.de> <478B890B.2070005@kaigai.gr.jp> <20080115091154.a99c1fb2.mschwendt.tmp0701.nospam@arcor.de> <15352.1200442156@sss.pgh.pa.us> Message-ID: <478D7C7E.9060205@ak.jp.nec.com> Tom Lane wrote: > BTW, I'm planning to push postgresql 8.3 into rawhide very soon (actually > it'll likely be 8.3RC2 at first, just to make sure it gets in there > before F9 alpha freeze). Don't know what impact that will have on > sepostgresql. If you won't be ready to update, it might be necessary > to decouple the two packages after all. > > regards, tom lane I've ported sepostgresql features into 8.3 based postgresql for a while. See, http://sepgsql.googlecode.com/svn/ . "/trunk" is already designed for 8.3RC1 based sepostgresql. There will be an impact indeed, but it's not a negative one. On the 8.3 based sepostgresql, it stores security attribute of HeapTuple using the t_hoff padding area as you suggested at: https://bugzilla.redhat.com/show_bug.cgi?id=249522#c58 This is a reson why we cannot share any *.so libraries, as is. However, I believe this change enables to share most of contrib packages without any changing/rebuilding. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei From ggw at wolves.durham.nc.us Wed Jan 16 05:50:13 2008 From: ggw at wolves.durham.nc.us (G.Wolfe Woodbury) Date: Wed, 16 Jan 2008 00:50:13 -0500 Subject: anaconda - unhandled exception In-Reply-To: <1200437661.2899.10.camel@scrappy.miketc.com> References: <478C68EC.6030201@mindspring.com> <478C7385.80308@gmail.com> <1200398322.2903.2.camel@scrappy.miketc.com> <20080115134539.GB9011@dhcp83-45.boston.redhat.com> <1200437661.2899.10.camel@scrappy.miketc.com> Message-ID: <478D9B15.80801@wolves.durham.nc.us> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mike Chambers wrote: > Sooo, upon saying all that, what *is* the status of anaconda now? Will > it do an install now at this point or is there a couple things still > broken? Reallllyy thinking of trying another install again tonight, but > not sure yet. Might file my taxes first then look into it in a little > while. I just finished a rawhide install with boot.iso on i686. The only problems I had were the "New Firstboot" not being complete and not having access to "cracklib" Notting fixed the SELinux error on modprobe even without a bug report. :-) > > Keep up the good work Anaconda team! > Yes, *ATTABOY* Good Job. - -- Wolfe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iQCVAwUBR42bEi1+lL6/CF63AQKH7wQAu6cQBIB3fImMfBRp+KbfjS5Dj4gpCCxC fEBtKlQgcx77y/q8iCrV15NNepLt5KjdINMzuSxtPIf/R3MnjX7yL2p30RnOBM75 5tn/ejwtTgT5+l9723ItAY3LR31jATPCiXxnDu+ogpOInchA6+Fs0y7/2Ho3eHxm ScVitCuj87s= =iovW -----END PGP SIGNATURE----- From peter at thecodergeek.com Wed Jan 16 05:54:07 2008 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 15 Jan 2008 21:54:07 -0800 Subject: [resolved] Re: System xulrunner Extensions? [rpms/xulrunner/devel .cvsignore, 1.9, 1.10 sources, 1.9, 1.10 xulrunner.spec, 1.48, 1.49] In-Reply-To: <478D6FA4.8010907@redhat.com> References: <200801160056.m0G0u4Hp003503@cvs-int.fedora.redhat.com> <1200447717.3189.1.camel@tuxhugs> <478D6FA4.8010907@redhat.com> Message-ID: <1200462847.3189.6.camel@tuxhugs> On Wed, 2008-01-16 at 03:44 +0100, Christopher Aillon wrote: > [... Lots of informative stuff ...] Thanks for the reply. That explained what I wanted to know quite clearly. :) -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jonstanley at gmail.com Wed Jan 16 06:21:33 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Wed, 16 Jan 2008 01:21:33 -0500 Subject: Fedora bug triage - workflow proposal In-Reply-To: <20080115092452.245d5604@ghistelwchlohm.scrye.com> References: <20080115092452.245d5604@ghistelwchlohm.scrye.com> Message-ID: On 2008/1/15 Kevin Fenzi wrote: > Great. You might want to use (optional) > http://fedoraproject.org/wiki/JesseKeating/FESCoProposalTemplateDraft > and write up a page for FESCo to refer to for this. Created at http://fedoraproject.org/wiki/JonStanley/BugWorkflow > I'm not sure how usefull this will be. Maintainers pretty much ignore > priority now, as reporter (or any package maintainer) can set it...+ Yep, part of the proposal is to change that - it's not mentioned in the proposal page since the current process of blocker bugs seems to work. Maybe not the most efficient thing in the world, but if it ain't broke.... > What about the above case of NEEDINFO(maintainer)? Great question, I've never seen this actually used. Most of the time it's in NEEDINFO(reporter). I guess some logic could be used, I'm not sure of the how good tag support is in the XMLRPC API. Maybe someone smarter than me could comment. > I think this is great! ;) > I'd be happy to help with triage... We need all the help that we can get. Make sure to tell all your friends :) From debarshi.ray at gmail.com Wed Jan 16 07:57:11 2008 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Wed, 16 Jan 2008 13:27:11 +0530 Subject: Access to a Fedora PPC64 system Message-ID: <3170f42f0801152357g67f1afb8gc0b9394da4bc6786@mail.gmail.com> http://koji.fedoraproject.org/koji/getfile?taskID=351914&name=build.log It would be nice if anyone of you could temporarily give me access to a Fedora PPC64 system to investigate the above failure. username: rishi ssh public key: Thank you very much, Debarshi -- Free software for the Indian community: * ftp://fedora.glug-nith.org/ (Fedora) * http://gnu.glug-nith.org/ (GNU) * http://mirror.wbut.ac.in/ (CRAN, Fedora, Mozilla, TLDP) From rc040203 at freenet.de Tue Jan 15 17:31:46 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 15 Jan 2008 18:31:46 +0100 Subject: Where are the CD ISO's? (fwd) In-Reply-To: <20080115115315.0307581e@redhat.com> References: <20080115115315.0307581e@redhat.com> Message-ID: <1200418306.5174.198.camel@beck.corsepiu.local> On Tue, 2008-01-15 at 11:53 -0500, Jesse Keating wrote: > On Tue, 15 Jan 2008 10:47:38 -0600 (CST) > Mike McGrath wrote: > > > What are the plans for media support for Fedora 9? > > Generating split media as part of the official compose process. Alpha > will see DVD + split CD media. Will we see a split "Everything"? The "stripped" "Fedora"-isos are not really suitable for upgrades. Ralf From mike at miketc.com Wed Jan 16 11:44:28 2008 From: mike at miketc.com (Mike Chambers) Date: Wed, 16 Jan 2008 05:44:28 -0600 Subject: anaconda - unhandled exception In-Reply-To: <478D9B15.80801@wolves.durham.nc.us> References: <478C68EC.6030201@mindspring.com> <478C7385.80308@gmail.com> <1200398322.2903.2.camel@scrappy.miketc.com> <20080115134539.GB9011@dhcp83-45.boston.redhat.com> <1200437661.2899.10.camel@scrappy.miketc.com> <478D9B15.80801@wolves.durham.nc.us> Message-ID: <1200483868.4162.5.camel@scrappy.miketc.com> On Wed, 2008-01-16 at 00:50 -0500, G.Wolfe Woodbury wrote: > I just finished a rawhide install with boot.iso on i686. > The only problems I had were the "New Firstboot" not being complete and > not having access to "cracklib" > > Notting fixed the SELinux error on modprobe even without a bug report. :-) How did the install go, during the package install part (packages actually being installed)? On an updated F8 spin the other day, the time I clicked next to install the packages, it took 1.5 or so hours to finish. That is on a PIV 2.8Ghz 1G ram machine. It's not slow, so comparing I guess. Of course, this is using nfs via boot.iso to a dvd.iso image. Oh, and no customizing, just the initial choice of production/whatever that comes up, like 880 packages or something. How long did yours take? -- Mike Chambers Madisonville, KY "The best lil town on Earth!" From valent.turkovic at gmail.com Wed Jan 16 11:52:38 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 16 Jan 2008 12:52:38 +0100 Subject: intel driver and dual screen Message-ID: <64b14b300801160352mbaa4261sae58a74ecf6fa0a0@mail.gmail.com> Hi, when I connect external LCD monitor to my laptop's VGA connector I get image on both monitors with the "same" resolution - just that the one on the laptop is cropped. Laptop supports 1280x800 and LCD 1280x1024 so I see the same desktop on both screens just I don't see the bottom part on laptop screen. I would like to have an option to do two things: 1. to turn off the laptop screen when I'm using only the external one. (I have vista on this laptop also but I don't use it - under vista I can use FN+F4 to rotate video modes and in one video mode only external LCD is on, under Fedora 8 FN+F4 does nothing) 2. ability to switch both screens on but not in mirror mode but in dual screen mode. I'm using Fedora 8 with latest updates and with intel 2.1.1 driver. Are there any intel utilities that make managing video setup easier? Can you please point me to some web resources that address issues I mentioned. Thank you in advance, Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From ggw at wolves.durham.nc.us Wed Jan 16 12:02:24 2008 From: ggw at wolves.durham.nc.us (G.Wolfe Woodbury) Date: Wed, 16 Jan 2008 07:02:24 -0500 Subject: anaconda - unhandled exception In-Reply-To: <1200483868.4162.5.camel@scrappy.miketc.com> References: <478C68EC.6030201@mindspring.com> <478C7385.80308@gmail.com> <1200398322.2903.2.camel@scrappy.miketc.com> <20080115134539.GB9011@dhcp83-45.boston.redhat.com> <1200437661.2899.10.camel@scrappy.miketc.com> <478D9B15.80801@wolves.durham.nc.us> <1200483868.4162.5.camel@scrappy.miketc.com> Message-ID: <478DF250.1000903@wolves.durham.nc.us> Mike Chambers wrote: > On Wed, 2008-01-16 at 00:50 -0500, G.Wolfe Woodbury wrote: > >> I just finished a rawhide install with boot.iso on i686. >> The only problems I had were the "New Firstboot" not being complete and >> not having access to "cracklib" >> >> Notting fixed the SELinux error on modprobe even without a bug report. :-) > > How did the install go, during the package install part (packages > actually being installed)? On an updated F8 spin the other day, the > time I clicked next to install the packages, it took 1.5 or so hours to > finish. That is on a PIV 2.8Ghz 1G ram machine. It's not slow, so > comparing I guess. Of course, this is using nfs via boot.iso to a > dvd.iso image. Oh, and no customizing, just the initial choice of > production/whatever that comes up, like 880 packages or something. > > How long did yours take? Depending on how many packages I pick, 1.5 - 4 hours. Machine is a 2.0GHz intel i686 box, 1GiB ram, NFS to local repository mirror. About the same. They're supposed to be fixing the progress bar problem. -- G.Wolfe Woodbury Have you hugged your wolf today? From jonathan.underwood at gmail.com Wed Jan 16 12:34:45 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 16 Jan 2008 12:34:45 +0000 Subject: intel driver and dual screen In-Reply-To: <64b14b300801160352mbaa4261sae58a74ecf6fa0a0@mail.gmail.com> References: <64b14b300801160352mbaa4261sae58a74ecf6fa0a0@mail.gmail.com> Message-ID: <645d17210801160434g74cbf0e7j77584240ce69d374@mail.gmail.com> On 16/01/2008, Valent Turkovic wrote: > Hi, > when I connect external LCD monitor to my laptop's VGA connector I get > image on both monitors with the "same" resolution - just that the one > on the laptop is cropped. > Laptop supports 1280x800 and LCD 1280x1024 so I see the same desktop > on both screens just I don't see the bottom part on laptop screen. > > I would like to have an option to do two things: > 1. to turn off the laptop screen when I'm using only the external one. > (I have vista on this laptop also but I don't use it - under vista I > can use FN+F4 to rotate video modes and in one video mode only > external LCD is on, under Fedora 8 FN+F4 does nothing) > 2. ability to switch both screens on but not in mirror mode but in > dual screen mode. > > I'm using Fedora 8 with latest updates and with intel 2.1.1 driver. > > Are there any intel utilities that make managing video setup easier? > Can you please point me to some web resources that address issues I > mentioned. > xrandr can do the first xrandr --output LVDS off there may be a way to use xrandr to do the second, but I haven't figured it out yet. There's a nice utility in development to give a nice shiny GUI for these things: http://albertomilone.com/urandr.html From jakub.rusinek at gmail.com Wed Jan 16 13:09:13 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Wed, 16 Jan 2008 14:09:13 +0100 Subject: compilation architecture In-Reply-To: <5e92ee3f0801150831t685810f1jb2ac41c7975a1675@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <1200341643.5433.81.camel@localhost> <200801151257.m0FCvREV008743@laptop13.inf.utfsm.cl> <5e92ee3f0801150507y2b9f31a5mcc7fd14b5760e384@mail.gmail.com> <20080115151925.652f0500.mschwendt.tmp0701.nospam@arcor.de> <5e92ee3f0801150711o9108b7apf83f4ae132b894e4@mail.gmail.com> <1200411358.15130.271.camel@localhost.localdomain> <5e92ee3f0801150726v2d708d70x7e51087f0bb0a254@mail.gmail.com> <20080115165601.67bdf81e.mschwendt.tmp0701.nospam@arcor.de> <5e92ee3f0801150831t685810f1jb2ac41c7975a1675@mail.gmail.com> Message-ID: <5e92ee3f0801160509x6655b9car15171ec594744d60@mail.gmail.com> Ok, I've installed openSUSE and configured it like my Fedora. time commands (fedora vs opensuse) firefox 3, snapshot from trunk real 12.125s 6.598s user 6.564s 4.584s sys 0.766s 0.544s gnome-terminal real 2.359s 0.312s user 0.451s 0.076s sys 0.099s 0.028s nautilus (when running on desktop, below new instance ran from gnome-terminal) real 0.523s 0.257s user 0.151s 0.148s sys 0.045s 0.024s totem real 3.742s 2.758s user 1.440s 1.816s sys 0.415s 0.352s Tell me if you want more data (I'll provide bootchart too). -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Wed Jan 16 13:13:35 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 16 Jan 2008 08:13:35 -0500 Subject: Where are the CD ISO's? (fwd) In-Reply-To: <1200418306.5174.198.camel@beck.corsepiu.local> References: <20080115115315.0307581e@redhat.com> <1200418306.5174.198.camel@beck.corsepiu.local> Message-ID: <20080116081335.675a7d4c@redhat.com> On Tue, 15 Jan 2008 18:31:46 +0100 Ralf Corsepius wrote: > Will we see a split "Everything"? > > The "stripped" "Fedora"-isos are not really suitable for upgrades. Not as of yet. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From drago01 at gmail.com Wed Jan 16 13:14:37 2008 From: drago01 at gmail.com (drago01) Date: Wed, 16 Jan 2008 14:14:37 +0100 Subject: compilation architecture In-Reply-To: <5e92ee3f0801160509x6655b9car15171ec594744d60@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <1200341643.5433.81.camel@localhost> <200801151257.m0FCvREV008743@laptop13.inf.utfsm.cl> <5e92ee3f0801150507y2b9f31a5mcc7fd14b5760e384@mail.gmail.com> <20080115151925.652f0500.mschwendt.tmp0701.nospam@arcor.de> <5e92ee3f0801150711o9108b7apf83f4ae132b894e4@mail.gmail.com> <1200411358.15130.271.camel@localhost.localdomain> <5e92ee3f0801150726v2d708d70x7e51087f0bb0a254@mail.gmail.com> <20080115165601.67bdf81e.mschwendt.tmp0701.nospam@arcor.de> <5e92ee3f0801150831t685810f1jb2ac41c7975a1675@mail.gmail.com> <5e92ee3f0801160509x6655b9car15171ec594744d60@mail.gmail.com> Message-ID: <478E033D.4090201@gmail.com> Jakub 'Livio' Rusinek wrote: > Ok, I've installed openSUSE and configured it like my Fedora. > > time commands (fedora vs opensuse) where are the fedora and where are the opensuse numbers? Plain numbers without something to compare too are useless (you need to post both fedora _AND_ opensuse numbers). From jakub.rusinek at gmail.com Wed Jan 16 13:18:48 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Wed, 16 Jan 2008 14:18:48 +0100 Subject: compilation architecture In-Reply-To: <478E033D.4090201@gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801150507y2b9f31a5mcc7fd14b5760e384@mail.gmail.com> <20080115151925.652f0500.mschwendt.tmp0701.nospam@arcor.de> <5e92ee3f0801150711o9108b7apf83f4ae132b894e4@mail.gmail.com> <1200411358.15130.271.camel@localhost.localdomain> <5e92ee3f0801150726v2d708d70x7e51087f0bb0a254@mail.gmail.com> <20080115165601.67bdf81e.mschwendt.tmp0701.nospam@arcor.de> <5e92ee3f0801150831t685810f1jb2ac41c7975a1675@mail.gmail.com> <5e92ee3f0801160509x6655b9car15171ec594744d60@mail.gmail.com> <478E033D.4090201@gmail.com> Message-ID: <5e92ee3f0801160518n1f0012d3u74764924f1faf9a8@mail.gmail.com> 2008/1/16, drago01 : > > Jakub 'Livio' Rusinek wrote: > > Ok, I've installed openSUSE and configured it like my Fedora. > > > > time commands (fedora vs opensuse) > where are the fedora and where are the opensuse numbers? > Plain numbers without something to compare too are useless (you need to > post both fedora _AND_ opensuse numbers). > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I've posted Fedora and openSUSE numbers, silly. | example program: | | real (fedora) (opensuse) | user (fedora) (opensuse) | sys (fedora) (opensuse) They're even easy to compare. Higher time - Fedora, lower - openSUSE. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Wed Jan 16 13:20:05 2008 From: aph at redhat.com (Andrew Haley) Date: Wed, 16 Jan 2008 13:20:05 +0000 Subject: compilation architecture In-Reply-To: <5e92ee3f0801160509x6655b9car15171ec594744d60@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <1200341643.5433.81.camel@localhost> <200801151257.m0FCvREV008743@laptop13.inf.utfsm.cl> <5e92ee3f0801150507y2b9f31a5mcc7fd14b5760e384@mail.gmail.com> <20080115151925.652f0500.mschwendt.tmp0701.nospam@arcor.de> <5e92ee3f0801150711o9108b7apf83f4ae132b894e4@mail.gmail.com> <1200411358.15130.271.camel@localhost.localdomain> <5e92ee3f0801150726v2d708d70x7e51087f0bb0a254@mail.gmail.com> <20080115165601.67bdf81e.mschwendt.tmp0701.nospam@arcor.de> <5e92ee3f0801150831t685810f1jb2ac41c7975a1675@mail.gmail.com> <5e92ee3f0801160509x6655b9car15171ec594744d60@mail.gmail.com> Message-ID: <18318.1157.209676.811339@zebedee.pink> Jakub 'Livio' Rusinek writes: > Ok, I've installed openSUSE and configured it like my Fedora. > > time commands (fedora vs opensuse) > > firefox 3, snapshot from trunk > > real 12.125s 6.598s > user 6.564s 4.584s > sys 0.766s 0.544s What command did you use to time Firefox startup? At what point did you stop the clock? > gnome-terminal > > real 2.359s 0.312s > user 0.451s 0.076s > sys 0.099s 0.028s What exactly are you testing here? I get $ time gnome-terminal real 0m0.035s user 0m0.012s sys 0m0.012s Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From drago01 at gmail.com Wed Jan 16 13:25:05 2008 From: drago01 at gmail.com (drago01) Date: Wed, 16 Jan 2008 14:25:05 +0100 Subject: compilation architecture In-Reply-To: <5e92ee3f0801160518n1f0012d3u74764924f1faf9a8@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801150507y2b9f31a5mcc7fd14b5760e384@mail.gmail.com> <20080115151925.652f0500.mschwendt.tmp0701.nospam@arcor.de> <5e92ee3f0801150711o9108b7apf83f4ae132b894e4@mail.gmail.com> <1200411358.15130.271.camel@localhost.localdomain> <5e92ee3f0801150726v2d708d70x7e51087f0bb0a254@mail.gmail.com> <20080115165601.67bdf81e.mschwendt.tmp0701.nospam@arcor.de> <5e92ee3f0801150831t685810f1jb2ac41c7975a1675@mail.gmail.com> <5e92ee3f0801160509x6655b9car15171ec594744d60@mail.gmail.com> <478E033D.4090201@gmail.com> <5e92ee3f0801160518n1f0012d3u74764924f1faf9a8@mail.gmail.com> Message-ID: <478E05B1.4010305@gmail.com> Jakub 'Livio' Rusinek wrote: > 2008/1/16, drago01 >: > > Jakub 'Livio' Rusinek wrote: > > Ok, I've installed openSUSE and configured it like my Fedora. > > > > time commands (fedora vs opensuse) > where are the fedora and where are the opensuse numbers? > Plain numbers without something to compare too are useless (you > need to > post both fedora _AND_ opensuse numbers). > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > I've posted Fedora and openSUSE numbers, silly. > Sorry I missed it because there where only one "real, user and sys" line for each app From jnovy at redhat.com Wed Jan 16 13:30:55 2008 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 16 Jan 2008 14:30:55 +0100 Subject: texlive + pdftex +kile: very slow In-Reply-To: <200801151606.59141.singularitaet@gmx.net> References: <200801151606.59141.singularitaet@gmx.net> Message-ID: <20080116133055.GA28107@dhcp-lab-186.brq.redhat.com> On Tue, Jan 15, 2008 at 04:06:53PM +0100, Stefan Grosse wrote: > Hi, > > I have upgraded my tex to texlive from rawhide. Whenever I run pdftex on a > document (unfortunately this is necessary for the beamer package) it takes > 1-2 minutes on even a very small text kile consumes during this time ~100% > cpu. > > I did not have the same problem with tetex. > > Is someone else observing the same? Is it a pdftex bug? Or kile bug? Hi, actually both of them are culprits. pdflatex used to create very verbose output because of warnings about ambiguous entries in pdflatex.map. This doesn't affect the output PDF from pdflatex, but it causes kile to consume lots of time because it parses the logs very slowly so that it is unresponsive for some time. pdflatex no more warns because of ambiguous entries since texlive-2007-11 and it made kile work much faster for me. Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From singularitaet at gmx.net Wed Jan 16 14:00:12 2008 From: singularitaet at gmx.net (Stefan Grosse) Date: Wed, 16 Jan 2008 15:00:12 +0100 Subject: texlive + pdftex +kile: very slow In-Reply-To: <20080116133055.GA28107@dhcp-lab-186.brq.redhat.com> References: <200801151606.59141.singularitaet@gmx.net> <20080116133055.GA28107@dhcp-lab-186.brq.redhat.com> Message-ID: <200801161500.13028.singularitaet@gmx.net> On Wednesday 16 January 2008 02:30:55 pm Jindrich Novy wrote: JN> actually both of them are culprits. pdflatex used to create very JN> verbose output because of warnings about ambiguous entries in JN> pdflatex.map. This doesn't affect the output PDF from pdflatex, but JN> it causes kile to consume lots of time because it parses the logs JN> very slowly so that it is unresponsive for some time. JN> JN> pdflatex no more warns because of ambiguous entries since JN> texlive-2007-11 and it made kile work much faster for me. Thanks! I filed already a bug on kile in bugs.kde.org, so maybe there is also someone improving the message parsing. (#155909) Stefan From ssorce at redhat.com Wed Jan 16 14:14:18 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 16 Jan 2008 09:14:18 -0500 Subject: intel driver and dual screen In-Reply-To: <64b14b300801160352mbaa4261sae58a74ecf6fa0a0@mail.gmail.com> References: <64b14b300801160352mbaa4261sae58a74ecf6fa0a0@mail.gmail.com> Message-ID: <1200492858.10631.18.camel@localhost.localdomain> On Wed, 2008-01-16 at 12:52 +0100, Valent Turkovic wrote: > Hi, > when I connect external LCD monitor to my laptop's VGA connector I get > image on both monitors with the "same" resolution - just that the one > on the laptop is cropped. > Laptop supports 1280x800 and LCD 1280x1024 so I see the same desktop > on both screens just I don't see the bottom part on laptop screen. > > I would like to have an option to do two things: > 1. to turn off the laptop screen when I'm using only the external one. > (I have vista on this laptop also but I don't use it - under vista I > can use FN+F4 to rotate video modes and in one video mode only > external LCD is on, under Fedora 8 FN+F4 does nothing) > 2. ability to switch both screens on but not in mirror mode but in > dual screen mode. > > I'm using Fedora 8 with latest updates and with intel 2.1.1 driver. > > Are there any intel utilities that make managing video setup easier? > Can you please point me to some web resources that address issues I > mentioned. > > Thank you in advance, > Valent. I have exactly the same situation, I have a xrandr command I start from my session that sets up the dual screen thing: xrandr --output VGA --right-of LVDS to shutdown the LCD: xrandr --output LVDS off See xrandr --help for more fun Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From jreiser at BitWagon.com Wed Jan 16 15:07:17 2008 From: jreiser at BitWagon.com (John Reiser) Date: Wed, 16 Jan 2008 07:07:17 -0800 Subject: Where are the CD ISO's? (fwd) In-Reply-To: <1200418306.5174.198.camel@beck.corsepiu.local> References: <20080115115315.0307581e@redhat.com> <1200418306.5174.198.camel@beck.corsepiu.local> Message-ID: <478E1DA5.8060004@BitWagon.com> > Will we see a split "Everything"? http://spins.fedoraunity.org/unity/fedora-8-everything-spin which was released within four days of the official release. -- From rc040203 at freenet.de Wed Jan 16 15:23:49 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 16 Jan 2008 16:23:49 +0100 Subject: Where are the CD ISO's? (fwd) In-Reply-To: <478E1DA5.8060004@BitWagon.com> References: <20080115115315.0307581e@redhat.com> <1200418306.5174.198.camel@beck.corsepiu.local> <478E1DA5.8060004@BitWagon.com> Message-ID: <1200497030.5174.321.camel@beck.corsepiu.local> On Wed, 2008-01-16 at 07:07 -0800, John Reiser wrote: > > Will we see a split "Everything"? > > http://spins.fedoraunity.org/unity/fedora-8-everything-spin > which was released within four days of the official release. Great! I was aware about fedoraunity's spins, but have never used them - May-be I should give them a try next time, before wasting bandwidth and time on the original sites :/ BTW: Do you also have or at least consider a "network install Everything +updates iso/img"? I mean something similar to Fedora's standard boot.iso, but configured to point to a networked "Everything+updates" instead of "Fedora"? This is at least what I what consider a direly missing feature from the current ways to install Fedora ;) Ralf From jeff at ocjtech.us Wed Jan 16 15:37:50 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Wed, 16 Jan 2008 09:37:50 -0600 Subject: intel driver and dual screen In-Reply-To: <645d17210801160434g74cbf0e7j77584240ce69d374@mail.gmail.com> References: <64b14b300801160352mbaa4261sae58a74ecf6fa0a0@mail.gmail.com> <645d17210801160434g74cbf0e7j77584240ce69d374@mail.gmail.com> Message-ID: <935ead450801160737i44f59064yd615a0fcf634e1c6@mail.gmail.com> On 1/16/08, Jonathan Underwood wrote: > > There's a nice utility in development to give a nice shiny GUI for these things: > > http://albertomilone.com/urandr.html Unfortunately this utility seems very Debian/Ubuntu specific - for example there's some code that shells out to dpkg and apt-get. Plus I see some rather dubious code... First of all, it seems to want to run as root, which shouldn't be necessary to use XRandR. Second, code like this: self.command = 'sudo rm -R ' self.remove(files, verb) seems to be begging to be exploited. I think that I'm staying far away from this code... Jeff From mschwendt.tmp0701.nospam at arcor.de Wed Jan 16 15:44:27 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 16 Jan 2008 16:44:27 +0100 Subject: compilation architecture In-Reply-To: <5e92ee3f0801160509x6655b9car15171ec594744d60@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <1200341643.5433.81.camel@localhost> <200801151257.m0FCvREV008743@laptop13.inf.utfsm.cl> <5e92ee3f0801150507y2b9f31a5mcc7fd14b5760e384@mail.gmail.com> <20080115151925.652f0500.mschwendt.tmp0701.nospam@arcor.de> <5e92ee3f0801150711o9108b7apf83f4ae132b894e4@mail.gmail.com> <1200411358.15130.271.camel@localhost.localdomain> <5e92ee3f0801150726v2d708d70x7e51087f0bb0a254@mail.gmail.com> <20080115165601.67bdf81e.mschwendt.tmp0701.nospam@arcor.de> <5e92ee3f0801150831t685810f1jb2ac41c7975a1675@mail.gmail.com> <5e92ee3f0801160509x6655b9car15171ec594744d60@mail.gmail.com> Message-ID: <20080116164427.0361c924.mschwendt.tmp0701.nospam@arcor.de> On Wed, 16 Jan 2008 14:09:13 +0100, Jakub 'Livio' Rusinek wrote: > Ok, I've installed openSUSE and configured it like my Fedora. > > time commands (fedora vs opensuse) > > firefox 3, snapshot from trunk > > real 12.125s 6.598s > user 6.564s 4.584s > sys 0.766s 0.544s What command did you use to do this? Do consecutive runs of the same test change the values? How? Earlier you wrote: > and eg. Firefox 3 was started in < 1 sec. That doesn't match your new values at all. From jakub.rusinek at gmail.com Wed Jan 16 15:56:58 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Wed, 16 Jan 2008 16:56:58 +0100 Subject: compilation architecture In-Reply-To: <20080116164427.0361c924.mschwendt.tmp0701.nospam@arcor.de> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801150507y2b9f31a5mcc7fd14b5760e384@mail.gmail.com> <20080115151925.652f0500.mschwendt.tmp0701.nospam@arcor.de> <5e92ee3f0801150711o9108b7apf83f4ae132b894e4@mail.gmail.com> <1200411358.15130.271.camel@localhost.localdomain> <5e92ee3f0801150726v2d708d70x7e51087f0bb0a254@mail.gmail.com> <20080115165601.67bdf81e.mschwendt.tmp0701.nospam@arcor.de> <5e92ee3f0801150831t685810f1jb2ac41c7975a1675@mail.gmail.com> <5e92ee3f0801160509x6655b9car15171ec594744d60@mail.gmail.com> <20080116164427.0361c924.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <5e92ee3f0801160756o2aa5750cu4b403c8c405c2d69@mail.gmail.com> 2008/1/16, Michael Schwendt : > > On Wed, 16 Jan 2008 14:09:13 +0100, Jakub 'Livio' Rusinek wrote: > > > Ok, I've installed openSUSE and configured it like my Fedora. > > > > time commands (fedora vs opensuse) > > > > firefox 3, snapshot from trunk > > > > real 12.125s 6.598s > > user 6.564s 4.584s > > sys 0.766s 0.544s > > What command did you use to do this? > Do consecutive runs of the same test change the values? How? > > Earlier you wrote: > > > and eg. Firefox 3 was started in < 1 sec. > > That doesn't match your new values at all. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > What command did you use to do this? time, /usr/bin/time, I guess time (some command here) and then quick exit of program, quickest you can. It was second start of Firefox. > 2nd time it's starting faster and faster. 12s for Fedora and 6s for openSUSE is time from starting command to Firefox being shown. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From krh at redhat.com Wed Jan 16 16:00:26 2008 From: krh at redhat.com (Kristian =?ISO-8859-1?Q?H=F8gsberg?=) Date: Wed, 16 Jan 2008 11:00:26 -0500 Subject: intel driver and dual screen In-Reply-To: <1200492858.10631.18.camel@localhost.localdomain> References: <64b14b300801160352mbaa4261sae58a74ecf6fa0a0@mail.gmail.com> <1200492858.10631.18.camel@localhost.localdomain> Message-ID: <1200499226.9549.5.camel@gaara.boston.redhat.com> On Wed, 2008-01-16 at 09:14 -0500, Simo Sorce wrote: > On Wed, 2008-01-16 at 12:52 +0100, Valent Turkovic wrote: > > Hi, > > when I connect external LCD monitor to my laptop's VGA connector I get > > image on both monitors with the "same" resolution - just that the one > > on the laptop is cropped. > > Laptop supports 1280x800 and LCD 1280x1024 so I see the same desktop > > on both screens just I don't see the bottom part on laptop screen. > > > > I would like to have an option to do two things: > > 1. to turn off the laptop screen when I'm using only the external one. > > (I have vista on this laptop also but I don't use it - under vista I > > can use FN+F4 to rotate video modes and in one video mode only > > external LCD is on, under Fedora 8 FN+F4 does nothing) > > 2. ability to switch both screens on but not in mirror mode but in > > dual screen mode. > > > > I'm using Fedora 8 with latest updates and with intel 2.1.1 driver. > > > > Are there any intel utilities that make managing video setup easier? > > Can you please point me to some web resources that address issues I > > mentioned. > > > > Thank you in advance, > > Valent. > > I have exactly the same situation, I have a xrandr command I start from > my session that sets up the dual screen thing: > > xrandr --output VGA --right-of LVDS One things that's not very well documented is that you need to tweak you xorg.conf for this to work. You need to add a Virtual line to the "Display" subsection in the "Screen" section of the xorg.conf file, for example: Section "Screen" Identifier "Screen0" Device "Videocard0" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 24 Virtual 3600 1200 EndSubSection EndSection The exact resolution depends on the monitors you want to use, but it has to be big enough to hold both side by side. In my case, I have 1900x1200 and 1680x1050 monitors side by side, which gives me the numbers above. cheers, Kristian From limb at jcomserv.net Wed Jan 16 16:05:50 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 16 Jan 2008 10:05:50 -0600 (CST) Subject: Where are the CD ISO's? (fwd) In-Reply-To: <1200497030.5174.321.camel@beck.corsepiu.local> References: <20080115115315.0307581e@redhat.com> <1200418306.5174.198.camel@beck.corsepiu.local> <478E1DA5.8060004@BitWagon.com> <1200497030.5174.321.camel@beck.corsepiu.local> Message-ID: <25764.63.85.68.164.1200499550.squirrel@mail.jcomserv.net> > > On Wed, 2008-01-16 at 07:07 -0800, John Reiser wrote: >> > Will we see a split "Everything"? >> >> http://spins.fedoraunity.org/unity/fedora-8-everything-spin >> which was released within four days of the official release. > > Great! I was aware about fedoraunity's spins, but have never used them - > May-be I should give them a try next time, before wasting bandwidth and > time on the original sites :/ > > BTW: Do you also have or at least consider a "network install Everything > +updates iso/img"? The rescue cd does that, as I recently discovered. Works very well. > I mean something similar to Fedora's standard boot.iso, but configured > to point to a networked "Everything+updates" instead of "Fedora"? > > This is at least what I what consider a direly missing feature from the > current ways to install Fedora ;) > > Ralf > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From mclasen at redhat.com Wed Jan 16 16:11:37 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 16 Jan 2008 11:11:37 -0500 Subject: intel driver and dual screen In-Reply-To: <935ead450801160737i44f59064yd615a0fcf634e1c6@mail.gmail.com> References: <64b14b300801160352mbaa4261sae58a74ecf6fa0a0@mail.gmail.com> <645d17210801160434g74cbf0e7j77584240ce69d374@mail.gmail.com> <935ead450801160737i44f59064yd615a0fcf634e1c6@mail.gmail.com> Message-ID: <1200499897.2771.14.camel@localhost.localdomain> On Wed, 2008-01-16 at 09:37 -0600, Jeffrey Ollie wrote: > On 1/16/08, Jonathan Underwood wrote: > > > > There's a nice utility in development to give a nice shiny GUI for these things: > > > > http://albertomilone.com/urandr.html > > Unfortunately this utility seems very Debian/Ubuntu specific - for > example there's some code that shells out to dpkg and apt-get. Plus I > see some rather dubious code... First of all, it seems to want to run > as root, which shouldn't be necessary to use XRandR. Second, code > like this: > > self.command = 'sudo rm -R ' > self.remove(files, verb) > > seems to be begging to be exploited. I think that I'm staying far > away from this code... We are working on this for F9: http://fedoraproject.org/wiki/Features/RandrSupport Admittedly, we have not been very good at keeping that page updated, but Soeren hopes that we'll be able to land this in rawhide shortly after test1. Is that still correct, Soeren ? Matthias From jkeating at redhat.com Wed Jan 16 16:14:45 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 16 Jan 2008 11:14:45 -0500 Subject: Where are the CD ISO's? (fwd) In-Reply-To: <1200497030.5174.321.camel@beck.corsepiu.local> References: <20080115115315.0307581e@redhat.com> <1200418306.5174.198.camel@beck.corsepiu.local> <478E1DA5.8060004@BitWagon.com> <1200497030.5174.321.camel@beck.corsepiu.local> Message-ID: <20080116111445.61320126@redhat.com> On Wed, 16 Jan 2008 16:23:49 +0100 Ralf Corsepius wrote: > BTW: Do you also have or at least consider a "network install > Everything +updates iso/img"? > > I mean something similar to Fedora's standard boot.iso, but configured > to point to a networked "Everything+updates" instead of "Fedora"? > > This is at least what I what consider a direly missing feature from > the current ways to install Fedora ;) rescue.iso (which will be renamed to be more intuitive this release) can be used to do that. The only missing thing is adding the 'updates' repo at upgrade time. Currently we don't have UI for adding repos during upgrade, and that should probably be fixed. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ssorce at redhat.com Wed Jan 16 16:24:35 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 16 Jan 2008 11:24:35 -0500 Subject: intel driver and dual screen In-Reply-To: <1200499226.9549.5.camel@gaara.boston.redhat.com> References: <64b14b300801160352mbaa4261sae58a74ecf6fa0a0@mail.gmail.com> <1200492858.10631.18.camel@localhost.localdomain> <1200499226.9549.5.camel@gaara.boston.redhat.com> Message-ID: <1200500675.10767.9.camel@localhost.localdomain> On Wed, 2008-01-16 at 11:00 -0500, Kristian H?gsberg wrote: > On Wed, 2008-01-16 at 09:14 -0500, Simo Sorce wrote: > > On Wed, 2008-01-16 at 12:52 +0100, Valent Turkovic wrote: > > > Hi, > > > when I connect external LCD monitor to my laptop's VGA connector I get > > > image on both monitors with the "same" resolution - just that the one > > > on the laptop is cropped. > > > Laptop supports 1280x800 and LCD 1280x1024 so I see the same desktop > > > on both screens just I don't see the bottom part on laptop screen. > > > > > > I would like to have an option to do two things: > > > 1. to turn off the laptop screen when I'm using only the external one. > > > (I have vista on this laptop also but I don't use it - under vista I > > > can use FN+F4 to rotate video modes and in one video mode only > > > external LCD is on, under Fedora 8 FN+F4 does nothing) > > > 2. ability to switch both screens on but not in mirror mode but in > > > dual screen mode. > > > > > > I'm using Fedora 8 with latest updates and with intel 2.1.1 driver. > > > > > > Are there any intel utilities that make managing video setup easier? > > > Can you please point me to some web resources that address issues I > > > mentioned. > > > > > > Thank you in advance, > > > Valent. > > > > I have exactly the same situation, I have a xrandr command I start from > > my session that sets up the dual screen thing: > > > > xrandr --output VGA --right-of LVDS > > One things that's not very well documented is that you need to tweak you > xorg.conf for this to work. You need to add a Virtual line to the > "Display" subsection in the "Screen" section of the xorg.conf file, for > example: > > Section "Screen" > Identifier "Screen0" > Device "Videocard0" > DefaultDepth 24 > SubSection "Display" > Viewport 0 0 > Depth 24 > Virtual 3600 1200 > EndSubSection > EndSection > > The exact resolution depends on the monitors you want to use, but it has > to be big enough to hold both side by side. In my case, I have > 1900x1200 and 1680x1050 monitors side by side, which gives me the > numbers above. Oh, right, I completely forgot I had to change xorg.conf Also need to be noted that if you want to use desktop effects (compiz) you must not exceed 2048 in any direction. In my case putting them side by side makes it impossible to run compiz as 1024+1280 = 2304 > 2048 for me. (Virtual 2304 1024) I tested that putting one above the other works with compiz as 768+1024 < 2048 (Virtual 1280 1792 and xrandr --output VGA --above LVDS) Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From buildsys at redhat.com Wed Jan 16 16:39:40 2008 From: buildsys at redhat.com (Build System) Date: Wed, 16 Jan 2008 11:39:40 -0500 Subject: rawhide report: 20080116 changes Message-ID: <200801161639.m0GGdexE021103@porkchop.devel.redhat.com> New package R-BSgenome.Celegans.UCSC.ce2 Caenorhabditis elegans genome (UCSC Release ce2) New package dropbear SSH2 server and client New package evolution-zimbra Zimbra Connector for Evolution New package firstaidkit System Rescue Tool New package libgweather A library for weather information New package perl-Spreadsheet-ParseExcel-Simple Simple interface to Excel data New package system-summary A quick summary of system hardware New package tcl-html Tcl/Tk manual in html format New package xdvik An X viewer for DVI files Removed package perl-DateManip Updated Packages: GREYCstoration-2.6-2.fc9 ------------------------ * Tue Jan 15 2008 Marc Bradshaw 2.6-2 - New upstream version, testing 64 bit build issues * Wed Jan 09 2008 Marc Bradshaw 2.6-1 - New upstream version - This release deals with RGB/YCbCr color bases, and processes only particular - channels of a hyperspectral image. Only the command line version has been updated. abcm2ps-5.7.3-1.fc9 ------------------- * Tue Jan 15 2008 Gerard Milmeister - 5.7.3-1 - new release 5.7.3 aqbanking-2.3.3-1.fc9 --------------------- * Tue Jan 15 2008 Bill Nottingham - 2.3.3-1 - update to 2.3.3 bash-3.2-20.fc9 --------------- * Mon Jan 14 2008 Tomas Janousek - 3.2-20 - Added bash32-026 upstream official patch - Added bash32-027 upstream official patch (#249987) - Added bash32-028 upstream official patch - Added bash32-029 upstream official patch (#286861) - Added bash32-030 upstream official patch - Added bash32-031 upstream official patch (#358231) - Added bash32-032 upstream official patch - Added bash32-033 upstream official patch - Fix insert command repeating in vi mode (#190350) * Tue Nov 06 2007 Tomas Janousek - 3.2-19 - fix cursor position when prompt has one invisible character (#358231) - dropped examples/loadables/ from docs, since it wasn't possible to build them anyway (#174380) - fix #286861: Wrong input confuses bash's arithmetic unit permanently - fix #344411: $RANDOM stays the same when job executed in the background * Fri Aug 31 2007 Pete Graner - 3.2-18 - Added bash32-021 upstream official patch - Added bash32-025 upstream official patch - Added bash32-024 upstream official patch - Added bash32-023 upstream official patch - Added bash32-022 upstream official patch createrepo-0.9.1-3.fc9 ---------------------- * Tue Jan 15 2008 Seth Vidal 0.9.1-3 - more patches - almost 0.9.2 but not quite cupsddk-1.2.3-2.fc9 ------------------- * Tue Jan 15 2008 Tim Waugh 1.2.3-2 - Ship cupsprofile.ppm (bug #428504). dhcp-12:4.0.0-3.fc9 ------------------- * Tue Jan 15 2008 David Cantrell - 12:4.0.0-3 - Fix segfault in next_iface4() and next_iface6() (#428870) dragonplayer-2.0-0.3.beta1.fc9 ------------------------------ driconf-0.9.1-7.fc9 ------------------- * Tue Jan 15 2008 Kevin Fenzi - 0.9.1-7 - Add egginfo file. e2fsprogs-1.40.4-4.fc9 ---------------------- * Thu Jan 10 2008 Eric Sandeen 1.40.4-4 - Build e2fsck as a dynamically linked binary. - Re-fix uidd manpage default paths. * Wed Jan 09 2008 Eric Sandeen 1.40.4-3 - New uuidd subpackage, and properly set up uuidd at install. elilo-3.6-7 ----------- * Tue Jan 15 2008 Peter Jones - 3.6-7 - Rebuild to work on i386. * Thu Jan 10 2008 Chris Lumens 3.6-6 - Remove efibootmgr, which is now in its own package (Matt Domsch). * Mon Nov 12 2007 Matt Domsch 3.6-5 - provide efibootmgr in preparation for split eric-3.9.5-1.fc9 ---------------- * Fri Jan 11 2008 Johan Cwiklinski 3.9.5-1 - Rebuild for last version - Include the translation files espeak-1.30-1.fc9 ----------------- * Tue Jan 15 2008 Francois Aucamp - 1.30-1 - Update to version 1.30 - Removed local "synthdata_strlen" patch (included upstream) evolution-2.21.5-2.fc9 ---------------------- * Tue Jan 15 2008 Matthew Barnes - 2.21.5-2.fc9 - Add patch for GNOME bug #509741 (crash on startup). * Mon Jan 14 2008 Matthew Barnes - 2.21.5-1.fc9 - Update to 2.21.5 - The backup-restore plugin is stable again. - Remove patch for RH bug #154360 (fixed upstream). - Remove patch for RH bug #166231 (obsolete, possibly fixed upstream). - Remove patch for RH bug #178295 (fixed upstream). - Remove patch for GNOME bug #362638 (fixed upstream). - Remove patch for GNOME bug #504030 (fixed upstream). - Remove patch for GNOME bug #507311 (fixed upstream). * Sat Jan 05 2008 Matthew Barnes - 2.21.4-2.fc9 - Add patch for GNOME bug #507311 (send Bug Buddy reports to the new BugBuddyBugs Bugzilla component). firefox-3.0-0.beta2.11.nightly20080115.fc9 ------------------------------------------ * Tue Jan 15 2008 Christopher Aillon 3.0-0.beta2.11 - Update to latest trunk (2008-01-15) - Now with system extensions directory support - Temporarily disable langpacks while we're on the bleeding edge - Remove skeleton files; they are in xulrunner now flex-2.5.33-15.fc9 ------------------ * Tue Jan 15 2008 Stepan Kasal - 2.5.33-15 - Do not run autogen.sh, it undoes the effect of includedir patch. - Adapt test-linedir-r.patch so that it fixes Makefile.in and works even though autogen.sh is not run. * Thu Jan 10 2008 Stepan Kasal - 2.5.33-14 - Insert the "-fPIC" on configure command-line. - Drop the -fPIC patch. glabels-2.2.0-1.fc9 ------------------- * Mon Jan 14 2008 Peter Gordon - 2.2.0-1 - Update to new upstream release (2.2.0 Final); Yay! glpi-0.70.1a-1.fc9 ------------------ * Tue Jan 15 2008 Remi Collet - 0.70.1a-1 - update gnome-session-2.21.5-1.fc9 -------------------------- * Tue Jan 15 2008 Matthias Clasen - 2.21.5-1 - Update to 2.21.5 gnome-volume-manager-2.22.0-2.fc9 --------------------------------- * Wed Jan 16 2008 Matthias Clasen - 2.22.0-2 - Remove the first two tabs, since the functionality is covered by nautilus now gtk-vnc-0.3.2-2.fc9 ------------------- * Mon Jan 14 2008 Daniel P. Berrange - 0.3.2-2.fc9 - Track keystate to avoid stuck modifier keys gtkwave-3.1.3-1.fc9 ------------------- * Tue Jan 15 2008 Paul Howarth 3.1.3-1 - update to 3.1.3 gwenhywfar-2.6.2-1.fc9 ---------------------- * Tue Jan 15 2008 Bill Nottingham - 2.6.2-1 - update to 2.6.2 hunspell-en-0.20061130-4.fc9 ---------------------------- * Tue Jan 15 2008 Caolan McNamara - 0.20061130-4 - clean up spec hwdata-0.213-1.fc9 ------------------ * Tue Jan 15 2008 Karsten Hopp 0.213-1 - add many monitor entries (Im Sza, #367111) * Fri Jan 11 2008 Karsten Hopp 0.212-1 - pull new upstream pci.ids, usb.ids - Resolves: #300831 - added HP TFT5600 LCD Monitor - Resolves: #250569 - added Acer AL1916W, Eizo L568/L568D, Samsung 795DF - Resolves: #250582 - Add Samsung 205BW/206BW/225BW/226BW - Resolves: #250584 - Add Samsung 931BF - Resolves: #250587 imp-4.1.6-1.fc9 --------------- * Mon Jan 14 2008 Brandon Holbrook 4.1.6-1 - Upgraded to 4.1.6 ingo-1.1.5-1.fc9 ---------------- * Mon Jan 14 2008 Brandon Holbrook 1.1.5-1 - Upgraded to 1.1.5 iptraf-3.0.1-2.fc9 ------------------ * Tue Jan 15 2008 Marcela Maslanova - 3.0.1-2 - logratate now rotate only *.log files, not all of them #428683 kernel-2.6.24-0.155.rc7.git6.fc9 -------------------------------- * Wed Jan 16 2008 Dave Airlie - update r500 patch to remove dup pciids. * Mon Jan 14 2008 Kyle McMartin - 2.6.24-rc7-git6 * Mon Jan 14 2008 Kyle McMartin - Remerge linux-2.6-wireless-pending bits. - Fixup rt2x00 build due to automerge lossage. kvm-59-1.fc9 ------------ * Tue Jan 15 2008 Bill Nottingham : - 59-1 - add upstream patch to fix VMs that no longer boot (#427317) - update to kvm-59 libXext-1.0.1-5.fc9 ------------------- * Tue Jan 15 2008 parag - 1.0.1-5 - Merge-Review #226070 - Removed XFree86-libs, xorg-x11-libs XFree86-devel, xorg-x11-devel as Obsoletes - Removed BR:pkgconfig - Removed zero-length README file libXft-2.1.12-4.fc9 ------------------- * Tue Jan 15 2008 parag - 2.1.12-4 - Merge-Review #226074 - Removed XFree86-libs, xorg-x11-libs XFree86-devel, xorg-x11-devel as Obsoletes - Removed BR:pkgconfig - Removed zero-length NEWS file libXi-1.1.3-3.fc9 ----------------- * Tue Jan 15 2008 Brian Pepple - 1.1.3-3 - Fix pkconfig type on -devel. * Fri Jan 11 2008 parag 1.1.3-2 - Merge-review #226076 - Removed BR:pkgconfig - Removed XFree86-libs, xorg-x11-libs XFree86-devel, xorg-x11-devel as Obsoletes - Removed zero-length AUTHORS README file * Mon Sep 24 2007 Adam Jackson 1.1.3-1 - libXi 1.1.3 libXmu-1.0.3-4.fc9 ------------------ * Tue Jan 15 2008 parag - 1.0.3-4 - Merge-Review #226080 - Removed XFree86-libs, xorg-x11-libs XFree86-devel, xorg-x11-devel as Obsoletes - Removed BR:pkgconfig - Removed zero-length AUTHORS file libXt-1.0.4-4.fc9 ----------------- * Tue Jan 15 2008 parag - 1.0.4-4 - Merge-Review #226090 - Removed XFree86-libs, xorg-x11-libs XFree86-devel, xorg-x11-devel as Obsoletes - Removed BR:pkgconfig - Removed zero-length README AUTHORS NEWS file * Tue Aug 21 2007 Adam Jackson - 1.0.4-3 - Rebuild for build id * Sat Apr 21 2007 Matthias Clasen 1.0.4-2 - Don't install INSTALL libXtst-1.0.3-2.fc9 ------------------- * Tue Jan 15 2008 parag - 1.0.3-2 - Merge-Review #226091 - Removed XFree86-libs, xorg-x11-libs XFree86-devel, xorg-x11-devel as Obsoletes - Removed BR:pkgconfig - Removed zero-length README AUTHORS file libXv-1.0.3-4.fc9 ----------------- * Tue Jan 15 2008 parag - 1.0.3-4 - Merge-Review #226093 - Removed XFree86-libs, xorg-x11-libs XFree86-devel, xorg-x11-devel as Obsoletes - Removed BR:pkgconfig - Removed zero-length README file * Tue Aug 21 2007 Adam Jackson - 1.0.3-3 - Rebuild for build id * Sat Apr 21 2007 Matthias Clasen 1.0.3-2 - Don't install INSTALL libepc-0.3.3-1.fc9 ------------------ * Tue Jan 15 2008 Brian Pepple - 0.3.3-1 - Update to 0.3.3. liberation-fonts-1.0-2.fc9 -------------------------- * Wed Jan 16 2008 Caius Chance - 1.0-2.fc9 - Moved source tarball from cvs to separated storage. libgnome-2.20.1-4.fc9 --------------------- * Wed Jan 16 2008 Matthias Clasen - 2.20.1-4 - Make gvfs the default filechooser backend * Tue Dec 18 2007 Matthias Clasen - 2.20.1-3 - Add schema for gtk-im-module GConf key * Wed Oct 17 2007 Matthias Clasen - 2.20.1-2 - Install all necessary GConf schemas libnova-0.12.1-2.fc9 -------------------- libselinux-2.0.47-2.fc9 ----------------------- * Tue Jan 15 2008 Dan Walsh - 2.0.47-2 - Put back libselinux.a libxkbfile-1.0.4-4.fc9 ---------------------- * Tue Jan 15 2008 parag - 1.0.4-4 - Merge-Review #226077 - Removed XFree86-libs, xorg-x11-libs XFree86-devel, xorg-x11-devel as Obsoletes - Removed BR:pkgconfig - Removed zero-length AUTHORS README file mailman-3:2.1.9-9.fc9 --------------------- * Thu Jan 10 2008 Tomas Smetana - 3:2.1.9-9 - fix #393911 - mail is not added to the archive man-pages-cs-0.17.20080113-1.fc9 -------------------------------- * Tue Jan 15 2008 Ivana Varekova - 0.17.20080113-1 - update to 0.17.20080113 ncurses-5.6-14.20080112.fc9 --------------------------- * Tue Jan 15 2008 Miroslav Lichvar 5.6-14.20080112 - obsolete libtermcap-devel (#428898) openoffice.org-1:2.4.0-2.1.fc9 ------------------------------ * Tue Jan 15 2008 Caolan McNamara - 1:2.4.0-2.1 - drop integrated openoffice.org-2.3.0.ooo74751.bean.mawt.patch - drop integrated openoffice.org-1.9.88.rhXXXXXX.noxfonts.desktop.patch - next candidate * Mon Jan 14 2008 Caolan McNamara - 1:2.4.0-1.3 - fix broken requires * Fri Jan 11 2008 Caolan McNamara - 1:2.4.0-1.2 - add openoffice.org-2.4.0.oooXXXXX.solenv.paths.patch to fix up -devel Requires - add openoffice.org-2.4.0.rh133741.alwaysgtk.vcl.patch - Resolves: rhbz#425701/ooo#83410 try and fix serbian translations openswan-2.6.03-2.fc9 --------------------- * Fri Jan 11 2008 Steve Conklin - 2.6.03-2 - Removed copy of file that no longer exists * Fri Jan 11 2008 Steve Conklin - 2.6.03-1 - Latest upstream tarball, includes fixes * Thu Jan 10 2008 Steve Conklin - 2.6.02-2 - Rebase to 2.6.02, add initial ikev2 support perl-BSD-Resource-1.28-3.fc9 ---------------------------- plplot-5.8.0-9.fc9 ------------------ * Tue Jan 15 2008 - Orion Poplawski - 5.8.0-9 - Require numpy (bug #428876) - Update SVN patch to add support for detecting Tcl version - Look for itcl 3.4 policycoreutils-2.0.35-2.fc9 ---------------------------- * Tue Jan 15 2008 Dan Walsh 2.0.35-2 - Add descriptions of booleans to audit2allow pykickstart-1.25-1.fc9 ---------------------- * Tue Jan 15 2008 Chris Lumens - 1.25-1 - Add the version to the output ks file. (clumens) - Add syntax for encrypted partitions and raid devices. (clumens) pylibacl-0.2.2-2.fc9 -------------------- * Tue Jan 15 2008 Marcin Zajaczkowski - 0.2.2-2 - added compatibility with Python Eggs forced in F9 python-bibtex-1.2.4-3.fc9 ------------------------- * Tue Jan 15 2008 Zoltan Kota - 1.2.4-3 - include egg-info file pyxattr-0.2.2-2.fc9 ------------------- * Tue Jan 15 2008 Marcin Zajaczkowski - 0.2.2-2 - added compatibility with Python Eggs forced in F9 rkward-0.4.9-2.fc9 ------------------ * Tue Jan 15 2008 Pingou 0.4.9-2 - Change on the BR to fix rawhide build * Tue Jan 15 2008 Pingou 0.4.9-1 - Update to 0.4.9 * Sun Jan 06 2008 Pingou 0.4.9pre1-1 - Update to 0.4.9pre1 rpm-4.4.2.2-13.fc9 ------------------ * Fri Jan 11 2008 Panu Matilainen 4.4.2.2-13 - lose the useless rpm user+group, use root:root like everything else - install x86 arch macros on x86_64 (#194123) - dont mess up target os+arch on rpmrc include (#232429) - set pkg-config path based on target (#212522) - fix funky automake breakage from nss libraries moving to /lib* * Fri Jan 04 2008 Panu Matilainen 4.4.2.2-12 - fix segfault in devel symlink dependency generation from Mark Salter (#338971) - fix debugedit build with gcc 4.3 - drop popt-static build dependency * Thu Nov 15 2007 Panu Matilainen 4.4.2.2-11 - Unbreak debugedit (missing crypto initialization) setroubleshoot-2.0.3-1.fc9 -------------------------- * Fri Jan 11 2008 - 2.0.2-1 - Resolve bug #428252: Problem with update/remove old version - Add code to validate xml database version, if file is incompatible it is not read, the next time the database is written it will be in the new version format. This means the database contents are not preserved across database version upgrades. - Remove postun trigger from spec file used to clear database between incompatible versions the new database version check during database read will handle this instead - bullet proof exit status in init script and rpm scriptlets - Resolve bug #247302: setroubleshoot's autostart .desktop file fails to start under a KDE session - Resolve bug #376041: Cannot check setroubleshoot service status as non-root - Resolve bug #332281: remove obsolete translation - Resolve bug #344331: No description in gnome-session-properties - Resolve bug #358581: missing libuser-python dependency - Resolve bug #426586: Renaming translation po file from sr at Latn to sr at latin - Resolve bug #427260: German Translation - enhance the sealert man page * Fri Jan 04 2008 - 2.0.1-1 - make connection error message persist instead of timeout in browser - updated Brazilian Portuguese translation: Igor Pires Soares - implement uid,username checks - rpc methods now check for authenticated state - fix html handling of summary string - add 'named' messages to status bar, make sure all messages either timeout or are named - fix ordering of menus, resolves bug #427418 - add 'hide quiet' to browser view filtering, resolves bug #427421 - tweak siginfo text formatting - add logon to SECommandLine so that sealert -l works * Fri Dec 28 2007 - 2.0.0-1 - prepare for v2 test release - Completed most work for version 2 of setroubleshoot, prepare for test release - import Dan's changes from the mainline primarily allow_postfix_local_write_mail_spool plugin - escape html, fix siginfo.format_html(), siginfo.format_text() - add async-error signal - change identity to just username - make sure set_filter user validation works and reports error in browser - fix generation of line numbers and host when connected to audispd - add permissive notification, resolves bug #231334: Wording doesn't change for permissive mode - resolves bug #244345: avc path information incomplete - get the uid,gid when a client connects to the server - set_filter now verifies the filter is owned by the user, - resolves bug #288261: setroubleshoot lack of user authentication - remove filter options which weren't being used - change '@' in audit data hostname to '.' - remove restart dialog resolves bug #321171: sealert's dialog after update is higly confusing - fix rpc xml arg - fix handling of host value - tweak what fields are in signature - move data items which had been in 'avc' object into siginfo - clean up siginfo format - large parts of new audit data pipeline working, checkpoint - fix duplicate xml nodes when generating xml tree - audit event can now be xml serialized - switch from using int's for audit record types to strings - avoid conversion headaches and possibilty of not being able to convert a new unknown type - add logic to allow XmlSerialize to be subclassed and init_from_xml_node to be overridden - add support to xml serialize classes AuditEventID, AuditEvent, AuditRecord - use metaclass for xml class init - start adding xml support to audit data classes - Use metaclass to wrap class init - move xml serialization code from signature.py to xml_serialize.py - simplify aspect of the serialization code - add unstructured xml mapping, each xml element name has its content mapped to obj.name - modify xml serialization to be driven by xml contents - general clean up - checkpoint conversion of serialization to use metaclasses - clean up class/data specifications for XmlSerializable - add support for client rpc testing - add changelog entry - add SubProcess class to setroubleshootd in preparation to - run daemon as subprocess so we can gather results and compare them to the expected data we sent - rewrite all plugins to use new v2 audit data - add SubProcess class to setroubleshootd in preparation to run daemon as subprocess so we can gather results and compare them to the expected data we sent - add new test support: add config section 'test', add boolean 'analyze' to config test section, add class TestPluginReportReceiver which is installed if test.analyze is True, it prints analysis report. In test_setroubleshootd send AUDIT_EOE to assure sequential event processing so analysis results have same ordering as events that are sent by test_setroubleshootd - alert signatures now include host information, alerts will be grouped by host setroubleshoot-plugins-2.0.3-1.fc9 ---------------------------------- * Tue Jan 15 2008 - 2.0.2-1 - Add catchall_boolean.py plugin slrn-0.9.8.1pl1-6.20070716cvs.fc9 --------------------------------- * Tue Jan 15 2008 Miroslav Lichvar 0.9.8.1pl1-6.20070716cvs - add release to slrn-pull requirement (#226422) smartmontools-1:5.37-8.4.fc9 ---------------------------- * Tue Jan 15 2008 Tomas Smetana - 1:5.37-8.4 - change '-d ata' to '-d sat' in the config script for SATA drives tcl-1:8.5.0-6.fc9 ----------------- * Tue Jan 15 2008 Marcela Maslanova - 1:8.5.0-6 - tclsh8.5 is back because of back compatibility #428712 * Tue Jan 08 2008 Marcela Maslanova - 1:8.5.0-5 - stack checking is ok, error is in application. Removing withouth stack. - tcl-8.5.0-hidden.patch isn't ok, fix should be in expect. In the meantime the patch stay here. * Mon Jan 07 2008 Marcela Maslanova - 1:8.5.0-4 - add patch from atkac at redhat dot com - fix linking with hidden objects teg-0.11.2-12.fc9 ----------------- * Tue Jan 15 2008 josef radinger - 0.11.2-12 - fresh rebuild * Tue Jan 15 2008 josef radinger - 0.11.2-11 - fresh rebuild tetrinetx-1.13.16-3.fc9 ----------------------- texlive-2007-10.fc9 ------------------- * Tue Jan 15 2008 Jindrich Novy - 2007-10 - don't build/package xdvik/pxdvik, it's now separated - fix texlive-doc requires, description - use virtual provides with parentheses to avoid clashes with real packages (#410401) * Mon Jan 14 2008 Jindrich Novy - 2007-9 - unify texlive and texlive-fonts filelists - package texdoc and texdoctk to a separate subpackage texlive-doc, because of the Perl-Tk dependencies and logic * Mon Jan 07 2008 Jindrich Novy - 2007-8 - add tex-latex and tex-dvips virtual provides - mktexlsr fixes from Patrice Dumas tk-1:8.5.0-3.fc9 ---------------- * Tue Jan 15 2008 Marcela Maslanova - 1:8.5.0-3 - wish8.5 is here again for back compatibility * Sat Jan 05 2008 Marcela Maslanova - 1:8.5.0-2 - Obsolete the tile package that has been incorporated into the core tk source. * Wed Jan 02 2008 Marcela Maslanova - 1:8.5.0-1 - upgrade on the 8.5.0 tn5250-0.17.3-18.fc9 -------------------- * Tue Jan 15 2008 Karsten Hopp 0.17.3-18 - fix multilib problem in /usr/bin/tn5250-config (#343301) turba-2.1.6-1.fc9 ----------------- * Mon Jan 14 2008 Brandon Holbrook 2.1.6-1 - Upgraded to 2.1.6 vtk-5.0.3-22.fc9 ---------------- * Tue Jan 15 2008 Alex Lancaster - 5.0.3-22 - Add Python Eggs for F9+ * Thu Jan 10 2008 Caolan McNamara - 5.0.3-21 - Rebuild for new tcl/tk * Tue Aug 28 2007 Fedora Release Engineering - 5.0.3-20 - Rebuild for selinux ppc32 issue. xorg-x11-drv-sis-0.9.4-1.fc9 ---------------------------- * Wed Jan 16 2008 Dave Airlie - 0.9.4-1 - new upstream version - sis-pciaccess.patch - add initial pciaccess port * Wed Aug 22 2007 Adam Jackson - 0.9.3-4 - Rebuild for PPC toolchain bug * Mon Jun 18 2007 Adam Jackson 0.9.3-3 - Update Requires and BuildRequires. Disown the module directories. Add Requires: hwdata. xulrunner-1.9-0.beta2.11.nightly20080115.fc9 -------------------------------------------- * Tue Jan 15 2008 Christopher Aillon 1.9-0.beta2.11 - Update to latest trunk (2008-01-15) - Now with system extensions directory support zaptel-1.4.8-1.fc9 ------------------ * Mon Jan 14 2008 Jeffrey C. Ollie - 1.4.8-1 - Update to 1.4.8 Broken deps for i386 ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.i386 requires libgtkembedmoz.so epiphany-extensions - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.i386 requires libgtkembedmoz.so gnome-web-photo - 0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 icewm - 1.2.35-1.fc9.i386 requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 tkinter - 2.5.1-20.fc9.i386 requires libTix8.4.so Broken deps for x86_64 ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) icewm - 1.2.35-1.fc9.x86_64 requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 tkinter - 2.5.1-20.fc9.x86_64 requires libTix8.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.ppc requires libgtkembedmoz.so epiphany-extensions - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.ppc requires libgtkembedmoz.so gnome-web-photo - 0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 icewm - 1.2.35-1.fc9.ppc requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 monodevelop - 0.17-4.fc9.ppc requires boo tkinter - 2.5.1-20.fc9.ppc requires libTix8.4.so Broken deps for ppc64 ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) icewm - 1.2.35-1.fc9.ppc64 requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 perl-Test-AutoBuild-darcs - 1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 tkinter - 2.5.1-20.fc9.ppc64 requires libTix8.4.so()(64bit) From valent.turkovic at gmail.com Wed Jan 16 16:39:49 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 16 Jan 2008 17:39:49 +0100 Subject: intel driver and dual screen In-Reply-To: <1200499897.2771.14.camel@localhost.localdomain> References: <64b14b300801160352mbaa4261sae58a74ecf6fa0a0@mail.gmail.com> <645d17210801160434g74cbf0e7j77584240ce69d374@mail.gmail.com> <935ead450801160737i44f59064yd615a0fcf634e1c6@mail.gmail.com> <1200499897.2771.14.camel@localhost.localdomain> Message-ID: <64b14b300801160839m3c735532ge0be2c0039ca2c3a@mail.gmail.com> On Jan 16, 2008 5:11 PM, Matthias Clasen wrote: > > On Wed, 2008-01-16 at 09:37 -0600, Jeffrey Ollie wrote: > > On 1/16/08, Jonathan Underwood wrote: > > > > > > There's a nice utility in development to give a nice shiny GUI for these things: > > > > > > http://albertomilone.com/urandr.html > > > > Unfortunately this utility seems very Debian/Ubuntu specific - for > > example there's some code that shells out to dpkg and apt-get. Plus I > > see some rather dubious code... First of all, it seems to want to run > > as root, which shouldn't be necessary to use XRandR. Second, code > > like this: > > > > self.command = 'sudo rm -R ' > > self.remove(files, verb) > > > > seems to be begging to be exploited. I think that I'm staying far > > away from this code... > > We are working on this for F9: > http://fedoraproject.org/wiki/Features/RandrSupport > > Admittedly, we have not been very good at keeping that page updated, > but Soeren hopes that we'll be able to land this in rawhide shortly > after test1. Is that still correct, Soeren ? > > > Matthias Sounds great! Will that be incorporated in system-config-display or will it be a stand alone application? -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From valent.turkovic at gmail.com Wed Jan 16 16:42:16 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 16 Jan 2008 17:42:16 +0100 Subject: intel driver and dual screen In-Reply-To: <935ead450801160737i44f59064yd615a0fcf634e1c6@mail.gmail.com> References: <64b14b300801160352mbaa4261sae58a74ecf6fa0a0@mail.gmail.com> <645d17210801160434g74cbf0e7j77584240ce69d374@mail.gmail.com> <935ead450801160737i44f59064yd615a0fcf634e1c6@mail.gmail.com> Message-ID: <64b14b300801160842g2904d467xcb331c52faeca97d@mail.gmail.com> On Jan 16, 2008 4:37 PM, Jeffrey Ollie wrote: > On 1/16/08, Jonathan Underwood wrote: > > > > There's a nice utility in development to give a nice shiny GUI for these things: > > > > http://albertomilone.com/urandr.html > > Unfortunately this utility seems very Debian/Ubuntu specific - for > example there's some code that shells out to dpkg and apt-get. Plus I > see some rather dubious code... First of all, it seems to want to run > as root, which shouldn't be necessary to use XRandR. Second, code > like this: > > self.command = 'sudo rm -R ' > self.remove(files, verb) > > seems to be begging to be exploited. I think that I'm staying far > away from this code... > > Jeff Maybe some should suggest the author to make it a bit more distro agnostic so it works on fedora also? And I believe that the author would welcome and feedback in making his application more security wise and better for end users. Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From kzak at redhat.com Wed Jan 16 16:45:46 2008 From: kzak at redhat.com (Karel Zak) Date: Wed, 16 Jan 2008 17:45:46 +0100 Subject: Fedora bug triage - workflow proposal In-Reply-To: <20080115185925.GE9082@nostromo.devel.redhat.com> References: <20080115185925.GE9082@nostromo.devel.redhat.com> Message-ID: <20080116164546.GD26049@petra.dvoda.cz> On Tue, Jan 15, 2008 at 01:59:25PM -0500, Bill Nottingham wrote: > on the hook for that'. I'd prefer something like: > > UNCONFIRMED -> NEW -> ASSIGNED Sounds good. +1 Karel -- Karel Zak From mclasen at redhat.com Wed Jan 16 16:51:25 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 16 Jan 2008 11:51:25 -0500 Subject: intel driver and dual screen In-Reply-To: <64b14b300801160839m3c735532ge0be2c0039ca2c3a@mail.gmail.com> References: <64b14b300801160352mbaa4261sae58a74ecf6fa0a0@mail.gmail.com> <645d17210801160434g74cbf0e7j77584240ce69d374@mail.gmail.com> <935ead450801160737i44f59064yd615a0fcf634e1c6@mail.gmail.com> <1200499897.2771.14.camel@localhost.localdomain> <64b14b300801160839m3c735532ge0be2c0039ca2c3a@mail.gmail.com> Message-ID: <1200502285.2771.18.camel@localhost.localdomain> On Wed, 2008-01-16 at 17:39 +0100, Valent Turkovic wrote: > On Jan 16, 2008 5:11 PM, Matthias Clasen wrote: > > > > On Wed, 2008-01-16 at 09:37 -0600, Jeffrey Ollie wrote: > > > On 1/16/08, Jonathan Underwood wrote: > > > > > > > > There's a nice utility in development to give a nice shiny GUI for these things: > > > > > > > > http://albertomilone.com/urandr.html > > > > > > Unfortunately this utility seems very Debian/Ubuntu specific - for > > > example there's some code that shells out to dpkg and apt-get. Plus I > > > see some rather dubious code... First of all, it seems to want to run > > > as root, which shouldn't be necessary to use XRandR. Second, code > > > like this: > > > > > > self.command = 'sudo rm -R ' > > > self.remove(files, verb) > > > > > > seems to be begging to be exploited. I think that I'm staying far > > > away from this code... > > > > We are working on this for F9: > > http://fedoraproject.org/wiki/Features/RandrSupport > > > > Admittedly, we have not been very good at keeping that page updated, > > but Soeren hopes that we'll be able to land this in rawhide shortly > > after test1. Is that still correct, Soeren ? > > > > > > Matthias > > Sounds great! Will that be incorporated in system-config-display or > will it be a stand alone application? It will replace the screen resolution capplet; system-config-display will hopefully just go away at some point. From valent.turkovic at gmail.com Wed Jan 16 16:52:15 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 16 Jan 2008 17:52:15 +0100 Subject: intel driver and dual screen In-Reply-To: <64b14b300801160839m3c735532ge0be2c0039ca2c3a@mail.gmail.com> References: <64b14b300801160352mbaa4261sae58a74ecf6fa0a0@mail.gmail.com> <645d17210801160434g74cbf0e7j77584240ce69d374@mail.gmail.com> <935ead450801160737i44f59064yd615a0fcf634e1c6@mail.gmail.com> <1200499897.2771.14.camel@localhost.localdomain> <64b14b300801160839m3c735532ge0be2c0039ca2c3a@mail.gmail.com> Message-ID: <64b14b300801160852i6dc80a82t3d567a09945860b2@mail.gmail.com> On Jan 16, 2008 5:39 PM, Valent Turkovic wrote: > On Jan 16, 2008 5:11 PM, Matthias Clasen wrote: > > > > On Wed, 2008-01-16 at 09:37 -0600, Jeffrey Ollie wrote: > > > On 1/16/08, Jonathan Underwood wrote: > > > > > > > > There's a nice utility in development to give a nice shiny GUI for these things: > > > > > > > > http://albertomilone.com/urandr.html > > > > > > Unfortunately this utility seems very Debian/Ubuntu specific - for > > > example there's some code that shells out to dpkg and apt-get. Plus I > > > see some rather dubious code... First of all, it seems to want to run > > > as root, which shouldn't be necessary to use XRandR. Second, code > > > like this: > > > > > > self.command = 'sudo rm -R ' > > > self.remove(files, verb) > > > > > > seems to be begging to be exploited. I think that I'm staying far > > > away from this code... > > > > We are working on this for F9: > > http://fedoraproject.org/wiki/Features/RandrSupport > > > > Admittedly, we have not been very good at keeping that page updated, > > but Soeren hopes that we'll be able to land this in rawhide shortly > > after test1. Is that still correct, Soeren ? > > > > > > Matthias > > Sounds great! Will that be incorporated in system-config-display or > will it be a stand alone application? I looked at these: http://www.gnome.org/~clarkbw/designs/monitor-resolution-settings/ and it looks fabulous, can't wait to test it out in rawhide and fedora 9! Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From jonstanley at gmail.com Wed Jan 16 16:58:33 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Wed, 16 Jan 2008 11:58:33 -0500 Subject: Fedora bug triage - workflow proposal In-Reply-To: <20080116164546.GD26049@petra.dvoda.cz> References: <20080115185925.GE9082@nostromo.devel.redhat.com> <20080116164546.GD26049@petra.dvoda.cz> Message-ID: On Jan 16, 2008 11:45 AM, Karel Zak wrote: > Sounds good. +1 -1,000,000,000 since it's technically not feasible :( From emmanuel.seyman at club-internet.fr Wed Jan 16 17:00:55 2008 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Wed, 16 Jan 2008 18:00:55 +0100 Subject: Fedora bug triage - workflow proposal In-Reply-To: References: <20080115185925.GE9082@nostromo.devel.redhat.com> <20080116164546.GD26049@petra.dvoda.cz> Message-ID: <20080116170055.GA4949@orient.maison.lan> * Jon Stanley [16/01/2008 17:59] : > > -1,000,000,000 since it's technically not feasible :( How is it not feasible ? Emmanuel From lesmikesell at gmail.com Wed Jan 16 17:05:42 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 16 Jan 2008 11:05:42 -0600 Subject: Fedora bug triage - workflow proposal In-Reply-To: <20080116164546.GD26049@petra.dvoda.cz> References: <20080115185925.GE9082@nostromo.devel.redhat.com> <20080116164546.GD26049@petra.dvoda.cz> Message-ID: <478E3966.2060205@gmail.com> Karel Zak wrote: > On Tue, Jan 15, 2008 at 01:59:25PM -0500, Bill Nottingham wrote: >> on the hook for that'. I'd prefer something like: >> >> UNCONFIRMED -> NEW -> ASSIGNED > > Sounds good. +1 Making ASSIGNED actually mean assigned "to" someone makes sense (and the only thing that makes sense to me), but having UNCONFIRMED newer than NEW would be just as confusing. -- Les Mikesell lesmikesell at gmail.com From a.badger at gmail.com Wed Jan 16 17:06:06 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 16 Jan 2008 09:06:06 -0800 Subject: Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <200801151640.03456.opensource@till.name> References: <478CB7A3.8000206@redhat.com> <478CCCE7.1000804@gmail.com> <200801151640.03456.opensource@till.name> Message-ID: <478E397E.4050703@gmail.com> Till Maas wrote: >> alternatives is not a good solution for end-user apps on a multi-user >> system because the admin is setting a preference that is really better >> left to the user to decide. The user can set this preference using an >> alias (alias vim='gvim -v'). > >> Conflicts precludes the ability to have both versions installed in case >> one user of the system wants one thing and a different user wants >> another. Additionally, we are trying to get rid of unnecessary > > > Why should one want to use vim without X support, when vim with X support is > installed? The only difference afaik is that it loads maybe some 1/100 of a > second faster. Has this been fixed? https://www.redhat.com/archives/fedora-maintainers/2007-March/msg00286.html > Another issue is that maybe someone wants that vim-X11 is > substituted by vim-enhanced when vim-X11 is removed because e.g. X11 is > removed. But this does not mean that both binaries need to be installed all > the time to make the user happy. > >> What are you trying to achieve? Perhaps it would be simpler to get rid >> of the vim-enhanced package? Or perhaps what we have now is the >> simplest solution. > > For a user it is a very annoying situation. When one installs vim-X11, the > binary /usr/bin/gvim) cannot be run with all possible names, e.g. vim, > vimdiff, view, ... And running it with, e.g. "gvim -v -d" instead > of "vimdiff" is also annoying. You only need one command line arg. "gvimdiff -v" But I think you're missing the point of my question. We are presently treating vim and gvim as two different editors. When I install joe, I can't run it by invoking vim either :-) If this is the right concept we should let the user decide which editor to run. If this is conceptually wrong then we should only package one of them. If this is the right concept but vim-enhanced is merely lacking features that are expected from a modern OS then maybe we need to tweak the build options and reorganize the package a bit. For instance, to enable the xclipboard we could change the packages like this: vim-minimal (/bin/vi) is for people on embedded systems. vim-enhanced (/usr/bin/vim) compiled with --with-x=yes so that the xclipboard can be used. (Depends on the following additional packages above the current vim-enhanced:: libICE libSM libX11 libXt libxcb xorg-x11-filesystem libXau libXdmcp vim-gtk (/usr/bin/gvim; basically the current vim-X11) compiled with the gtk ui and drags in the gtk stack. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jonstanley at gmail.com Wed Jan 16 17:07:40 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Wed, 16 Jan 2008 12:07:40 -0500 Subject: Fedora bug triage - workflow proposal In-Reply-To: <20080116170055.GA4949@orient.maison.lan> References: <20080115185925.GE9082@nostromo.devel.redhat.com> <20080116164546.GD26049@petra.dvoda.cz> <20080116170055.GA4949@orient.maison.lan> Message-ID: On Jan 16, 2008 12:00 PM, Emmanuel Seyman wrote: > How is it not feasible ? Don't kill the messenger! :) I've gotten word from the RH maintainer that in the RH version of bugzilla (which as you know is nothing like upstream), states cannot be defined per product. There was an effort to take out the UNCONFIMRED state, and all references to it. Re-introducing it is a non-trivial task in the current codebase, and even if it weren't, it would affect all products. This summer, it may be easier - but not now. We've got to live with what we've got. From sandmann at redhat.com Wed Jan 16 17:15:00 2008 From: sandmann at redhat.com (Soeren Sandmann Pedersen) Date: 16 Jan 2008 12:15:00 -0500 Subject: intel driver and dual screen In-Reply-To: <1200499897.2771.14.camel@localhost.localdomain> References: <64b14b300801160352mbaa4261sae58a74ecf6fa0a0@mail.gmail.com> <645d17210801160434g74cbf0e7j77584240ce69d374@mail.gmail.com> <935ead450801160737i44f59064yd615a0fcf634e1c6@mail.gmail.com> <1200499897.2771.14.camel@localhost.localdomain> Message-ID: Matthias Clasen writes: > On Wed, 2008-01-16 at 09:37 -0600, Jeffrey Ollie wrote: > > On 1/16/08, Jonathan Underwood wrote: > > > > > > There's a nice utility in development to give a nice shiny GUI for these things: > > > > > > http://albertomilone.com/urandr.html > > > > Unfortunately this utility seems very Debian/Ubuntu specific - for > > example there's some code that shells out to dpkg and apt-get. Plus I > > see some rather dubious code... First of all, it seems to want to run > > as root, which shouldn't be necessary to use XRandR. Second, code > > like this: > > > > self.command = 'sudo rm -R ' > > self.remove(files, verb) > > > > seems to be begging to be exploited. I think that I'm staying far > > away from this code... > > We are working on this for F9: > http://fedoraproject.org/wiki/Features/RandrSupport > > Admittedly, we have not been very good at keeping that page updated, > but Soeren hopes that we'll be able to land this in rawhide shortly > after test1. Is that still correct, Soeren ? Yes, in fact, my hope is to get a prototype into test1. The code I have written so far is available here: http://www.gnome.org/~ssp/randr/ It doesn't really do anything yet though. Soren From valent.turkovic at gmail.com Wed Jan 16 17:22:46 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 16 Jan 2008 18:22:46 +0100 Subject: intel driver and dual screen In-Reply-To: <1200492858.10631.18.camel@localhost.localdomain> References: <64b14b300801160352mbaa4261sae58a74ecf6fa0a0@mail.gmail.com> <1200492858.10631.18.camel@localhost.localdomain> Message-ID: <64b14b300801160922u375d3d99q5cc040c17812bfe4@mail.gmail.com> On Jan 16, 2008 3:14 PM, Simo Sorce wrote: > > On Wed, 2008-01-16 at 12:52 +0100, Valent Turkovic wrote: > > Hi, > > when I connect external LCD monitor to my laptop's VGA connector I get > > image on both monitors with the "same" resolution - just that the one > > on the laptop is cropped. > > Laptop supports 1280x800 and LCD 1280x1024 so I see the same desktop > > on both screens just I don't see the bottom part on laptop screen. > > > > I would like to have an option to do two things: > > 1. to turn off the laptop screen when I'm using only the external one. > > (I have vista on this laptop also but I don't use it - under vista I > > can use FN+F4 to rotate video modes and in one video mode only > > external LCD is on, under Fedora 8 FN+F4 does nothing) > > 2. ability to switch both screens on but not in mirror mode but in > > dual screen mode. > > > > I'm using Fedora 8 with latest updates and with intel 2.1.1 driver. > > > > Are there any intel utilities that make managing video setup easier? > > Can you please point me to some web resources that address issues I > > mentioned. > > > > Thank you in advance, > > Valent. > > I have exactly the same situation, I have a xrandr command I start from > my session that sets up the dual screen thing: > > xrandr --output VGA --right-of LVDS > > to shutdown the LCD: xrandr --output LVDS off > > See xrandr --help for more fun > > Simo. This doesn't work for me :( $ xrandr --output LVDS off usage: xrandr [options] where options are: -display or -d -help -o or --orientation -q or --query -s /x or --size /x -r or --rate or --refresh -v or --version -x (reflect in x) -y (reflect in y) --screen --verbose --dryrun --prop or --properties --fb x --fbmm x --dpi / --output --auto --mode --preferred --pos x --rate or --refresh --reflect normal,x,y,xy --rotate normal,inverted,left,right --left-of --right-of --above --below --same-as --set --off --crtc --newmode [+HSync] [-HSync] [+VSync] [-VSync] --rmmode --addmode --delmode As you can see it only lists xrandr help and does nothing to laptop screen. When I run xrandr --properties I get monitors to flash and this output: $ xrandr --properties Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 1280 x 1280 VGA connected 1280x1024+0+0 (normal left inverted right x axis y axis) 376mm x 301mm EDID_DATA: 00ffffffffffff00410c470801010101 181001030e261e78ee6d65a25a4c9d23 134f54bfef80714f8140818001010101 010101010101302a009851002a403070 1300782d1100001e000000ff00204155 20203030323532390a20000000fc0050 68696c69707320313930560a000000fd 00384c1e530e000a20202020202000fa 1280x1024 60.0*+ 75.0 59.9 1280x960 59.9 1152x864 75.0 74.8 1024x768 75.1 70.1 60.0 832x624 74.6 800x600 72.2 75.0 60.3 56.2 640x480 75.0 72.8 66.7 60.0 720x400 70.1 LVDS connected 1280x800+0+0 (normal left inverted right x axis y axis) 331mm x 207mm EDID_DATA: 00ffffffffffff004493270000000000 000f0103802115780a4dc0935c518827 21505400000001010101010101010101 010101010101ea1a0080502010301520 44004bcf100000180000000f0008002a 0001000400324a041402000000fe0051 55414e5441444953504c4159000000fe 0051443135544c3032340a20202000aa BACKLIGHT: 0 (0x00000000) range: (0,0) 1280x800 60.0*+ 60.0 1280x768 60.0 1280x720 60.0 1024x768 60.0 800x600 60.3 640x480 59.9 TV disconnected (normal left inverted right x axis y axis) BOTTOM: 37 (0x00000025) range: (0,100) RIGHT: 46 (0x0000002e) range: (0,100) TOP: 36 (0x00000024) range: (0,100) LEFT: 54 (0x00000036) range: (0,100) TV_FORMAT: NTSC-M supported: NTSC-M NTSC-443 NTSC-J PAL-M PAL-N PAL 480p at 59.94Hz 480p at 60Hz 576p 720p at 60Hz 720p at 59.94Hz 720p at 50Hz 1080i at 50Hz 1080i at 60Hz 1080i at 59.94H -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From jkeating at redhat.com Wed Jan 16 17:33:49 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 16 Jan 2008 12:33:49 -0500 Subject: intel driver and dual screen In-Reply-To: <64b14b300801160922u375d3d99q5cc040c17812bfe4@mail.gmail.com> References: <64b14b300801160352mbaa4261sae58a74ecf6fa0a0@mail.gmail.com> <1200492858.10631.18.camel@localhost.localdomain> <64b14b300801160922u375d3d99q5cc040c17812bfe4@mail.gmail.com> Message-ID: <20080116123349.3bdef6e1@redhat.com> On Wed, 16 Jan 2008 18:22:46 +0100 "Valent Turkovic" wrote: > This doesn't work for me :( > > $ xrandr --output LVDS off Small typo. xrandr --output LVDS --off Warning, that's going to turn off your laptops LCD. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bpepple at fedoraproject.org Wed Jan 16 17:34:06 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 16 Jan 2008 12:34:06 -0500 Subject: Plan for tomorrows (20080117) FESCO meeting Message-ID: <1200504846.363.5.camel@kennedy> Hi, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 18:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCO-Meeting -- sponsor nominations -- Manuel Wolfshant - https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00689.html /topic FESCo-Meeting -- New Features - http://fedoraproject.org/wiki/Features/Dashboard - poelcat * http://fedoraproject.org/wiki/Releases/FeatureDictionary * http://fedoraproject.org/wiki/Features/XenPvops * http://fedoraproject.org/wiki/Features/GoodHaskellSupport * http://fedoraproject.org/wiki/Features/CommonLispController * http://fedoraproject.org/wiki/Features/IMDesktopIntegration * http://fedoraproject.org/wiki/Features/freeIPA /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, since we have a pretty full schedule). You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From albertomilone at alice.it Wed Jan 16 17:47:01 2008 From: albertomilone at alice.it (Alberto Milone) Date: Wed, 16 Jan 2008 18:47:01 +0100 Subject: intel driver and dual screen Message-ID: <1200505621.5969.18.camel@alberto-desktop> On 1/16/08, Jeffrey Ollie wrote: > Unfortunately this utility seems very Debian/Ubuntu specific - for > example there's some code that shells out to dpkg and apt-get. Plus I > see some rather dubious code... First of all, it seems to want to run > as root, which shouldn't be necessary to use XRandR. Second, code > like this: > > self.command = 'sudo rm -R ' > self.remove(files, verb) > > seems to be begging to be exploited. I think that I'm staying far > away from this code... > > Jeff Jeff, that code is useless and I will remove it from my application. Good point. The only reason why I would like to make my application run as root is that, as you might already know, sometimes a line such as the following has to be appended to the "Screen" section of the xorg.conf: Virtual 2880 1600 It depends on the graphic card but for example if I wanted to set up multiple screens (like xinerama used to do) so as to have my 1600x1200 screen to the left of my laptop's monitor (1280x800) I couldn't do it without setting the virtual resolution in my xorg.conf and restarting the Xserver, otherwise xrandr would say that the screen cannot be larger than 1600x1600. URandR should add that line automatically. Of course if you have a better idea I would be glad if you could let me know. P.S. I have an Intel card and, as far as I know, the Intel driver cannot reallocate the frame buffer, therefore whatever size you start with is the maximum the screen can ever become. Alberto From twoerner at redhat.com Wed Jan 16 17:52:32 2008 From: twoerner at redhat.com (Thomas Woerner) Date: Wed, 16 Jan 2008 18:52:32 +0100 Subject: firewall changes for F-9+ Message-ID: <478E4460.8040805@redhat.com> Hello, here are the latest changes for system-config-firewall for F-9+: The usage of --port=: for lokkit will open up this port and not a service using this port anymore. To enable a service you have to use the new --service= option. There are no magic default open services. You have to open up the services, you want to use. The interim options --no-X; X in ["ipsec", "mdns", "ipp"] are obsolete now. To setup a new firewall, you can use the new --default= configuration option as a start: server : ssh is enabled desktop : ipsec, mdns and ipp are enabled These changes for lokkit also affect the kickstart firewall configuration. There is an utility to convert existing configurations, which will be used automatically while updating the package. Thanks, Thomas From tmraz at redhat.com Wed Jan 16 17:53:46 2008 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 16 Jan 2008 18:53:46 +0100 Subject: Fedora bug triage - workflow proposal In-Reply-To: <478E3966.2060205@gmail.com> References: <20080115185925.GE9082@nostromo.devel.redhat.com> <20080116164546.GD26049@petra.dvoda.cz> <478E3966.2060205@gmail.com> Message-ID: <1200506027.3122.90.camel@vespa.frost.loc> On Wed, 2008-01-16 at 11:05 -0600, Les Mikesell wrote: > Karel Zak wrote: > > On Tue, Jan 15, 2008 at 01:59:25PM -0500, Bill Nottingham wrote: > >> on the hook for that'. I'd prefer something like: > >> > >> UNCONFIRMED -> NEW -> ASSIGNED > > > > Sounds good. +1 > > Making ASSIGNED actually mean assigned "to" someone makes sense (and the > only thing that makes sense to me), but having UNCONFIRMED newer than > NEW would be just as confusing. What about using "confirmed" keyword or flag? -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From albertomilone at alice.it Wed Jan 16 17:54:54 2008 From: albertomilone at alice.it (Alberto Milone) Date: Wed, 16 Jan 2008 18:54:54 +0100 Subject: intel driver and dual screen In-Reply-To: <1200505621.5969.18.camel@alberto-desktop> References: <1200505621.5969.18.camel@alberto-desktop> Message-ID: <1200506094.5969.25.camel@alberto-desktop> On Wed, 2008-01-16 at 18:47 +0100, Alberto Milone wrote: > > The only reason why I would like to make my application run as root is > that, as you might already know, sometimes a line such as the following > has to be appended to the "Screen" section of the xorg.conf: > > Virtual 2880 1600 > > It depends on the graphic card but for example if I wanted to set up > multiple screens (like xinerama used to do) so as to have my 1600x1200 > screen to the left of my laptop's monitor (1280x800) I couldn't do it > without setting the virtual resolution in my xorg.conf and restarting > the Xserver, otherwise xrandr would say that the screen cannot be larger > than 1600x1600. URandR should add that line automatically. > > Of course if you have a better idea I would be glad if you could let me > know. > > P.S. I have an Intel card and, as far as I know, the Intel driver cannot > reallocate the frame buffer, therefore whatever size you start with is > the maximum the screen can ever become. > > Alberto > and another reason why I want URandR to run as root is driver detection with this command (at least in Debian/Ubuntu): cat /proc/`pidof X`/smaps | grep _drv.so as I need to see if either the Intel (modesetting) or the ati driver are loaded. Alberto From ssorce at redhat.com Wed Jan 16 18:11:29 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 16 Jan 2008 13:11:29 -0500 Subject: intel driver and dual screen In-Reply-To: <1200506094.5969.25.camel@alberto-desktop> References: <1200505621.5969.18.camel@alberto-desktop> <1200506094.5969.25.camel@alberto-desktop> Message-ID: <1200507089.10767.11.camel@localhost.localdomain> On Wed, 2008-01-16 at 18:54 +0100, Alberto Milone wrote: > On Wed, 2008-01-16 at 18:47 +0100, Alberto Milone wrote: > > > > The only reason why I would like to make my application run as root is > > that, as you might already know, sometimes a line such as the following > > has to be appended to the "Screen" section of the xorg.conf: > > > > Virtual 2880 1600 > > > > It depends on the graphic card but for example if I wanted to set up > > multiple screens (like xinerama used to do) so as to have my 1600x1200 > > screen to the left of my laptop's monitor (1280x800) I couldn't do it > > without setting the virtual resolution in my xorg.conf and restarting > > the Xserver, otherwise xrandr would say that the screen cannot be larger > > than 1600x1600. URandR should add that line automatically. > > > > Of course if you have a better idea I would be glad if you could let me > > know. > > > > P.S. I have an Intel card and, as far as I know, the Intel driver cannot > > reallocate the frame buffer, therefore whatever size you start with is > > the maximum the screen can ever become. > > > > Alberto > > > and another reason why I want URandR to run as root is driver detection > with this command (at least in Debian/Ubuntu): > cat /proc/`pidof X`/smaps | grep _drv.so > > as I need to see if either the Intel (modesetting) or the ati driver are > loaded. Use helpers and integrate with PolicyKit, please!! Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From albertomilone at alice.it Wed Jan 16 18:21:23 2008 From: albertomilone at alice.it (Alberto Milone) Date: Wed, 16 Jan 2008 19:21:23 +0100 Subject: intel driver and dual screen In-Reply-To: <1200507089.10767.11.camel@localhost.localdomain> References: <1200505621.5969.18.camel@alberto-desktop> <1200506094.5969.25.camel@alberto-desktop> <1200507089.10767.11.camel@localhost.localdomain> Message-ID: <1200507683.5969.30.camel@alberto-desktop> On Wed, 2008-01-16 at 13:11 -0500, Simo Sorce wrote: > > Use helpers and integrate with PolicyKit, please!! > > Simo. > > -- > | Simo S Sorce | > | Sr.Soft.Eng. | > | Red Hat, Inc | > | New York, NY | > Ok, I'll read PolicyKit fine manual. Thanks Alberto From valent.turkovic at gmail.com Wed Jan 16 18:43:37 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 16 Jan 2008 19:43:37 +0100 Subject: intel driver and dual screen In-Reply-To: <20080116123349.3bdef6e1@redhat.com> References: <64b14b300801160352mbaa4261sae58a74ecf6fa0a0@mail.gmail.com> <1200492858.10631.18.camel@localhost.localdomain> <64b14b300801160922u375d3d99q5cc040c17812bfe4@mail.gmail.com> <20080116123349.3bdef6e1@redhat.com> Message-ID: <64b14b300801161043hd11db2wdb5291aeb0d8348f@mail.gmail.com> 2008/1/16 Jesse Keating : > On Wed, 16 Jan 2008 18:22:46 +0100 > "Valent Turkovic" wrote: > > > This doesn't work for me :( > > > > $ xrandr --output LVDS off > > Small typo. xrandr --output LVDS --off > > Warning, that's going to turn off your laptops LCD. > > -- > Jesse Keating > Fedora -- All my bits are free, are yours? Works like a charm. Thank you. Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From dcbw at redhat.com Wed Jan 16 18:48:31 2008 From: dcbw at redhat.com (Dan Williams) Date: Wed, 16 Jan 2008 13:48:31 -0500 Subject: intel driver and dual screen In-Reply-To: <1200499226.9549.5.camel@gaara.boston.redhat.com> References: <64b14b300801160352mbaa4261sae58a74ecf6fa0a0@mail.gmail.com> <1200492858.10631.18.camel@localhost.localdomain> <1200499226.9549.5.camel@gaara.boston.redhat.com> Message-ID: <1200509311.21414.6.camel@localhost.localdomain> On Wed, 2008-01-16 at 11:00 -0500, Kristian H?gsberg wrote: > On Wed, 2008-01-16 at 09:14 -0500, Simo Sorce wrote: > > On Wed, 2008-01-16 at 12:52 +0100, Valent Turkovic wrote: > > > Hi, > > > when I connect external LCD monitor to my laptop's VGA connector I get > > > image on both monitors with the "same" resolution - just that the one > > > on the laptop is cropped. > > > Laptop supports 1280x800 and LCD 1280x1024 so I see the same desktop > > > on both screens just I don't see the bottom part on laptop screen. > > > > > > I would like to have an option to do two things: > > > 1. to turn off the laptop screen when I'm using only the external one. > > > (I have vista on this laptop also but I don't use it - under vista I > > > can use FN+F4 to rotate video modes and in one video mode only > > > external LCD is on, under Fedora 8 FN+F4 does nothing) > > > 2. ability to switch both screens on but not in mirror mode but in > > > dual screen mode. > > > > > > I'm using Fedora 8 with latest updates and with intel 2.1.1 driver. > > > > > > Are there any intel utilities that make managing video setup easier? > > > Can you please point me to some web resources that address issues I > > > mentioned. > > > > > > Thank you in advance, > > > Valent. > > > > I have exactly the same situation, I have a xrandr command I start from > > my session that sets up the dual screen thing: > > > > xrandr --output VGA --right-of LVDS > > One things that's not very well documented is that you need to tweak you > xorg.conf for this to work. You need to add a Virtual line to the > "Display" subsection in the "Screen" section of the xorg.conf file, for > example: > > Section "Screen" > Identifier "Screen0" > Device "Videocard0" > DefaultDepth 24 > SubSection "Display" > Viewport 0 0 > Depth 24 > Virtual 3600 1200 > EndSubSection > EndSection > > The exact resolution depends on the monitors you want to use, but it has > to be big enough to hold both side by side. In my case, I have > 1900x1200 and 1680x1050 monitors side by side, which gives me the > numbers above. Can that eventually be allocated dynamically or adjusted when the hotplug events come in? Because this leads to the problem where X will just plain fail to bring up the new hotplugged 27" Apple Cinema display that I just got because I need some random obscure option in the X config. Hopefully this option will just Go Away (TM) too in the next few releases? Dan From valent.turkovic at gmail.com Wed Jan 16 19:05:48 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 16 Jan 2008 20:05:48 +0100 Subject: intel driver and dual screen In-Reply-To: References: <64b14b300801160352mbaa4261sae58a74ecf6fa0a0@mail.gmail.com> <645d17210801160434g74cbf0e7j77584240ce69d374@mail.gmail.com> <935ead450801160737i44f59064yd615a0fcf634e1c6@mail.gmail.com> <1200499897.2771.14.camel@localhost.localdomain> Message-ID: <64b14b300801161105v6b6d9684p3b801b0225bd256a@mail.gmail.com> On 16 Jan 2008 12:15:00 -0500, Soeren Sandmann Pedersen wrote: > Matthias Clasen writes: > > > On Wed, 2008-01-16 at 09:37 -0600, Jeffrey Ollie wrote: > > > On 1/16/08, Jonathan Underwood wrote: > > > > > > > > There's a nice utility in development to give a nice shiny GUI for these things: > > > > > > > > http://albertomilone.com/urandr.html > > > > > > Unfortunately this utility seems very Debian/Ubuntu specific - for > > > example there's some code that shells out to dpkg and apt-get. Plus I > > > see some rather dubious code... First of all, it seems to want to run > > > as root, which shouldn't be necessary to use XRandR. Second, code > > > like this: > > > > > > self.command = 'sudo rm -R ' > > > self.remove(files, verb) > > > > > > seems to be begging to be exploited. I think that I'm staying far > > > away from this code... > > > > We are working on this for F9: > > http://fedoraproject.org/wiki/Features/RandrSupport > > > > Admittedly, we have not been very good at keeping that page updated, > > but Soeren hopes that we'll be able to land this in rawhide shortly > > after test1. Is that still correct, Soeren ? > > Yes, in fact, my hope is to get a prototype into test1. > > The code I have written so far is available here: > > http://www.gnome.org/~ssp/randr/ > > It doesn't really do anything yet though. > > > Soren Will that include an option to turn on and off used/unused displays? Like in my example from the first post? And I saw a comment on your page about fall back when external monitors are unplugged - that would be really essential. Thanks and I eagerly await to test and use new ranrd features in rawhide and fedora. Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From j.w.r.degoede at hhs.nl Wed Jan 16 19:33:30 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 16 Jan 2008 20:33:30 +0100 Subject: Headsup: soname changing ogre update on its way to F-8 and F-7 Message-ID: <478E5C0A.5090609@hhs.nl> Hi all, Unfortunately until now I have overlooked / missed the fact that ogre includes its own private copy of GLEW and of a few OpenGL headers, both if which are licensed under the not 100% free, SGI Free Software B and GLX Public License licenses. I've already pushed a version of ogre to rawhide with this fixed (its using the system version of the OpenGL headers and GLEW (which is especially patched by yours truly to not have the license problem) instead. Ar request of Spot I'll also be pushing the devel version to Fedora-8 and -7 updates, I'll also be pushing a new version of the ogre using chess package (I wish I wasn't so green when I packaged that and that I would have used a less generic name) too. AFAIK chess is the only user of ogre, I've verified this with repoquery: [hans at localhost ~]$ repoquery -q --whatrequires 'libOgreMain-1.4.5.so()(64bit)' chess-0:1.0-10.fc8.x86_64 ogre-0:1.4.5-1.fc8.x86_64 ogre-devel-0:1.4.5-1.fc8.x86_64 ogre-samples-0:1.4.5-1.fc8.x86_64 [hans at localhost ~]$ If you have an ogre using package in F-8, a simple rebuild should fix things, notice that for F-7 we're going from 1.2.5 -> 1.4.6 , so thats not only an ABI breakage but also an _API_ one, so a mere recompile won't fix this. If you expect to be bitten by this please yell loudly asap. Regards, Hans From opensource at till.name Wed Jan 16 19:48:54 2008 From: opensource at till.name (Till Maas) Date: Wed, 16 Jan 2008 20:48:54 +0100 Subject: Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <478E397E.4050703@gmail.com> References: <478CB7A3.8000206@redhat.com> <200801151640.03456.opensource@till.name> <478E397E.4050703@gmail.com> Message-ID: <200801162049.03450.opensource@till.name> On Wed January 16 2008, Toshio Kuratomi wrote: > Till Maas wrote: > > Why should one want to use vim without X support, when vim with X support > > is installed? The only difference afaik is that it loads maybe some 1/100 > > of a second faster. > > Has this been fixed? > https://www.redhat.com/archives/fedora-maintainers/2007-March/msg00286.html Adam Jackson wrote a long time ago: | The one major reason to not want X support in your editor is so you | don't block on the XOpenDisplay, which can take much longer than you | want when using ssh with a forwarded display. But I'd assert that the | right way to fix that is to teach vim about xcb so the open can fail | asynchronously. Do you know how this can be reproduced? I did not find a bug for this in Red Hat's Bugzilla and when I use vim via ssh with "-X" and without and with it always opens instantly. Adam, do you know, whether this is still unfixed? Or can you please describe how to reproduce this and open a bug report or provide a pointer? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From valent.turkovic at gmail.com Wed Jan 16 19:57:56 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 16 Jan 2008 20:57:56 +0100 Subject: SELinux removed from desktop cd spin? Message-ID: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> Hi, I believe that SELinux is a great linux server security hardening tool but that has little use in desktop linux usage and it confuses ordinary desktop users. If it hasn't been discussed before I would like to propose that on desktop cd spin SELinux is not installed by default, of course after discussion and approval from you (fedora devels). Cheers, Valent -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From berrange at redhat.com Wed Jan 16 20:03:33 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 16 Jan 2008 20:03:33 +0000 Subject: SELinux removed from desktop cd spin? In-Reply-To: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> Message-ID: <20080116200333.GE15623@redhat.com> On Wed, Jan 16, 2008 at 08:57:56PM +0100, Valent Turkovic wrote: > Hi, > I believe that SELinux is a great linux server security hardening tool > but that has little use in desktop linux usage and it confuses > ordinary desktop users. It is of great use in a desktop spin. On my 'desktop' install for my laptop I have many many system daemons running under a confined domain auditd console-kit-daemon crond cupsd dbus-daemon hald init libvirtd NetworkManager rklogd rpcbind rpc.statd rsyslogd /sbin/dhclient /sbin/mingetty /sbin/udevd /usr/bin/nm-vpnc-service /usr/sbin/acpid /usr/sbin/dnsmasq /usr/sbin/gdm-binary /usr/sbin/hcid /usr/sbin/smartd /usr/sbin/sshd /usr/sbin/wpa_supplicant > If it hasn't been discussed before I would like to propose that on > desktop cd spin SELinux is not installed by default, of course after > discussion and approval from you (fedora devels). No. SELinux provides very real & important protection for desktop users. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From jakub.rusinek at gmail.com Wed Jan 16 20:12:25 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Wed, 16 Jan 2008 21:12:25 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <20080116200333.GE15623@redhat.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116200333.GE15623@redhat.com> Message-ID: <5e92ee3f0801161212o55db58a3y9e6ea31abc464783@mail.gmail.com> 2008/1/16, Daniel P. Berrange : > > On Wed, Jan 16, 2008 at 08:57:56PM +0100, Valent Turkovic wrote: > > Hi, > > I believe that SELinux is a great linux server security hardening tool > > but that has little use in desktop linux usage and it confuses > > ordinary desktop users. > > It is of great use in a desktop spin. On my 'desktop' install for my > laptop I have many many system daemons running under a confined domain > > auditd > console-kit-daemon > crond > cupsd > dbus-daemon > hald > init > libvirtd > NetworkManager > rklogd > rpcbind > rpc.statd > rsyslogd > /sbin/dhclient > /sbin/mingetty > /sbin/udevd > /usr/bin/nm-vpnc-service > /usr/sbin/acpid > /usr/sbin/dnsmasq > /usr/sbin/gdm-binary > /usr/sbin/hcid > /usr/sbin/smartd > /usr/sbin/sshd > /usr/sbin/wpa_supplicant > > > > If it hasn't been discussed before I would like to propose that on > > desktop cd spin SELinux is not installed by default, of course after > > discussion and approval from you (fedora devels). > > No. SELinux provides very real & important protection for desktop users. > > Dan. > -- > |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 > -=| > |=- Perl modules: http://search.cpan.org/~danberr/ > -=| > |=- Projects: http://freshmeat.net/~danielpb/ > -=| > |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B > 9505 -=| > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Yes, it protect internet connection from being shared, protects system from drivers, needed for some hardware and protects system from everything useful. It's question of policy, but SELinux on LiveCD maked me stupid in my brother's eyes. I wanted to show him internet connection sharing via superb user friendly tool, which appeared in F8, but SELinux blocked my changed... Nice. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lsof at nodata.co.uk Wed Jan 16 20:17:29 2008 From: lsof at nodata.co.uk (nodata) Date: Wed, 16 Jan 2008 21:17:29 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> Message-ID: <1200514649.5036.5.camel@sb-home> Am Mittwoch, den 16.01.2008, 20:57 +0100 schrieb Valent Turkovic: > Hi, > I believe that SELinux is a great linux server security hardening tool > but that has little use in desktop linux usage and it confuses > ordinary desktop users. > If it hasn't been discussed before I would like to propose that on > desktop cd spin SELinux is not installed by default, of course after > discussion and approval from you (fedora devels). > -2 From lsof at nodata.co.uk Wed Jan 16 20:18:22 2008 From: lsof at nodata.co.uk (nodata) Date: Wed, 16 Jan 2008 21:18:22 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <5e92ee3f0801161212o55db58a3y9e6ea31abc464783@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116200333.GE15623@redhat.com> <5e92ee3f0801161212o55db58a3y9e6ea31abc464783@mail.gmail.com> Message-ID: <1200514702.5036.7.camel@sb-home> Am Mittwoch, den 16.01.2008, 21:12 +0100 schrieb Jakub 'Livio' Rusinek: > It's question of policy, but SELinux on LiveCD maked me stupid in my > brother's eyes. > I wanted to show him internet connection sharing via superb user > friendly tool, which appeared in F8, but SELinux blocked my changed... > Nice. bz#? From valent.turkovic at gmail.com Wed Jan 16 20:19:38 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 16 Jan 2008 21:19:38 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <20080116200333.GE15623@redhat.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116200333.GE15623@redhat.com> Message-ID: <64b14b300801161219q355d93b0jb57f91f48615591a@mail.gmail.com> On Jan 16, 2008 9:03 PM, Daniel P. Berrange wrote: > On Wed, Jan 16, 2008 at 08:57:56PM +0100, Valent Turkovic wrote: > > Hi, > > I believe that SELinux is a great linux server security hardening tool > > but that has little use in desktop linux usage and it confuses > > ordinary desktop users. > > It is of great use in a desktop spin. On my 'desktop' install for my > laptop I have many many system daemons running under a confined domain You, of course, will always have the ability to choose to install it and use it. > > If it hasn't been discussed before I would like to propose that on > > desktop cd spin SELinux is not installed by default, of course after > > discussion and approval from you (fedora devels). > > No. SELinux provides very real & important protection for desktop users. Can you give me examples of this protection over fedora 9 without SELInux or with SELinux in permissive mode? I'm a desktop user and I personally don't see any benefit. It actually prevented me in using multimedia on fedora 8 desktop (I filed a bug). I believe it is more of a nuisance (constant alerts) for average desktop users. Advanced users always have an option to install and use SELinux if they need it. Cheers, Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From ville.skytta at iki.fi Wed Jan 16 20:20:15 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Wed, 16 Jan 2008 22:20:15 +0200 Subject: Headsup: soname changing ogre update on its way to F-8 and F-7 In-Reply-To: <478E5C0A.5090609@hhs.nl> References: <478E5C0A.5090609@hhs.nl> Message-ID: <200801162220.15910.ville.skytta@iki.fi> On Wednesday 16 January 2008, Hans de Goede wrote: > AFAIK chess is the only user of ogre, I've verified this with repoquery: > [hans at localhost ~]$ repoquery -q --whatrequires > 'libOgreMain-1.4.5.so()(64bit)' That probably produced the correct list of packages in this particular case, but generally an easier and better way is to use --alldeps to repoquery, like repoquery --whatrequires --alldeps ogre From sds at tycho.nsa.gov Wed Jan 16 20:20:48 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 16 Jan 2008 15:20:48 -0500 Subject: SELinux removed from desktop cd spin? In-Reply-To: <20080116200333.GE15623@redhat.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116200333.GE15623@redhat.com> Message-ID: <1200514848.9669.169.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2008-01-16 at 20:03 +0000, Daniel P. Berrange wrote: > On Wed, Jan 16, 2008 at 08:57:56PM +0100, Valent Turkovic wrote: > > Hi, > > I believe that SELinux is a great linux server security hardening tool > > but that has little use in desktop linux usage and it confuses > > ordinary desktop users. > > It is of great use in a desktop spin. On my 'desktop' install for my > laptop I have many many system daemons running under a confined domain Also, note that XACE/XSELinux has been merged to the trunk of xorg, so the ability of SELinux to confine desktop applications in interesting ways is only going to increase over time... > > auditd > console-kit-daemon > crond > cupsd > dbus-daemon > hald > init > libvirtd > NetworkManager > rklogd > rpcbind > rpc.statd > rsyslogd > /sbin/dhclient > /sbin/mingetty > /sbin/udevd > /usr/bin/nm-vpnc-service > /usr/sbin/acpid > /usr/sbin/dnsmasq > /usr/sbin/gdm-binary > /usr/sbin/hcid > /usr/sbin/smartd > /usr/sbin/sshd > /usr/sbin/wpa_supplicant > > > > If it hasn't been discussed before I would like to propose that on > > desktop cd spin SELinux is not installed by default, of course after > > discussion and approval from you (fedora devels). > > No. SELinux provides very real & important protection for desktop users. > > Dan. > -- > |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| > |=- Perl modules: http://search.cpan.org/~danberr/ -=| > |=- Projects: http://freshmeat.net/~danielpb/ -=| > |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| > -- Stephen Smalley National Security Agency From valent.turkovic at gmail.com Wed Jan 16 20:21:40 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 16 Jan 2008 21:21:40 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <1200514649.5036.5.camel@sb-home> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <1200514649.5036.5.camel@sb-home> Message-ID: <64b14b300801161221t60ad187o1a1fc92dfd0f4dac@mail.gmail.com> On Jan 16, 2008 9:17 PM, nodata wrote: > > Am Mittwoch, den 16.01.2008, 20:57 +0100 schrieb Valent Turkovic: > > Hi, > > I believe that SELinux is a great linux server security hardening tool > > but that has little use in desktop linux usage and it confuses > > ordinary desktop users. > > If it hasn't been discussed before I would like to propose that on > > desktop cd spin SELinux is not installed by default, of course after > > discussion and approval from you (fedora devels). > > > > -2 -19 explain. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From valent.turkovic at gmail.com Wed Jan 16 20:25:19 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 16 Jan 2008 21:25:19 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <1200514702.5036.7.camel@sb-home> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116200333.GE15623@redhat.com> <5e92ee3f0801161212o55db58a3y9e6ea31abc464783@mail.gmail.com> <1200514702.5036.7.camel@sb-home> Message-ID: <64b14b300801161225q17be0ba2xdf238f87b2ce04@mail.gmail.com> On Jan 16, 2008 9:18 PM, nodata wrote: > Am Mittwoch, den 16.01.2008, 21:12 +0100 schrieb Jakub 'Livio' Rusinek: > > It's question of policy, but SELinux on LiveCD maked me stupid in my > > brother's eyes. > > I wanted to show him internet connection sharing via superb user > > friendly tool, which appeared in F8, but SELinux blocked my changed... > > Nice. > > bz#? > mine is: https://bugzilla.redhat.com/show_bug.cgi?id=355291 -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From berrange at redhat.com Wed Jan 16 20:25:54 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 16 Jan 2008 20:25:54 +0000 Subject: SELinux removed from desktop cd spin? In-Reply-To: <64b14b300801161219q355d93b0jb57f91f48615591a@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116200333.GE15623@redhat.com> <64b14b300801161219q355d93b0jb57f91f48615591a@mail.gmail.com> Message-ID: <20080116202554.GF15623@redhat.com> On Wed, Jan 16, 2008 at 09:19:38PM +0100, Valent Turkovic wrote: > On Jan 16, 2008 9:03 PM, Daniel P. Berrange wrote: > > On Wed, Jan 16, 2008 at 08:57:56PM +0100, Valent Turkovic wrote: > > > Hi, > > > I believe that SELinux is a great linux server security hardening tool > > > but that has little use in desktop linux usage and it confuses > > > ordinary desktop users. > > > > It is of great use in a desktop spin. On my 'desktop' install for my > > laptop I have many many system daemons running under a confined domain > > You, of course, will always have the ability to choose to install it > and use it. > > > > If it hasn't been discussed before I would like to propose that on > > > desktop cd spin SELinux is not installed by default, of course after > > > discussion and approval from you (fedora devels). > > > > No. SELinux provides very real & important protection for desktop users. > > Can you give me examples of this protection over fedora 9 without > SELInux or with SELinux in permissive mode? Yes. SELinux mitigated against the recent HPLIP security flaw which would have allowed arbitrary code execution as root. http://james-morris.livejournal.com/25140.html https://rhn.redhat.com/errata/RHSA-2007-0960.html There have been other similar scenarios where security flaws have been prevented, or their damage mitigated by presence of SELinux Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From jakub.rusinek at gmail.com Wed Jan 16 20:30:27 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Wed, 16 Jan 2008 21:30:27 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <1200514702.5036.7.camel@sb-home> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116200333.GE15623@redhat.com> <5e92ee3f0801161212o55db58a3y9e6ea31abc464783@mail.gmail.com> <1200514702.5036.7.camel@sb-home> Message-ID: <5e92ee3f0801161230j6b58da38uf53befc5c6681705@mail.gmail.com> 2008/1/16, nodata : > > Am Mittwoch, den 16.01.2008, 21:12 +0100 schrieb Jakub 'Livio' Rusinek: > > It's question of policy, but SELinux on LiveCD maked me stupid in my > > brother's eyes. > > I wanted to show him internet connection sharing via superb user > > friendly tool, which appeared in F8, but SELinux blocked my changed... > > Nice. > > bz#? > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I would file bug not, because it was only LiveCD-test. On desktop I'm always disabling SELinux. Just like that. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From valent.turkovic at gmail.com Wed Jan 16 20:35:54 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 16 Jan 2008 21:35:54 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <20080116202554.GF15623@redhat.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116200333.GE15623@redhat.com> <64b14b300801161219q355d93b0jb57f91f48615591a@mail.gmail.com> <20080116202554.GF15623@redhat.com> Message-ID: <64b14b300801161235i4a4ed432h4f7b81ecefaf292b@mail.gmail.com> On Jan 16, 2008 9:25 PM, Daniel P. Berrange wrote: > On Wed, Jan 16, 2008 at 09:19:38PM +0100, Valent Turkovic wrote: > > On Jan 16, 2008 9:03 PM, Daniel P. Berrange wrote: > > > On Wed, Jan 16, 2008 at 08:57:56PM +0100, Valent Turkovic wrote: > > > > Hi, > > > > I believe that SELinux is a great linux server security hardening tool > > > > but that has little use in desktop linux usage and it confuses > > > > ordinary desktop users. > > > > > > It is of great use in a desktop spin. On my 'desktop' install for my > > > laptop I have many many system daemons running under a confined domain > > > > You, of course, will always have the ability to choose to install it > > and use it. > > > > > > If it hasn't been discussed before I would like to propose that on > > > > desktop cd spin SELinux is not installed by default, of course after > > > > discussion and approval from you (fedora devels). > > > > > > No. SELinux provides very real & important protection for desktop users. > > > > Can you give me examples of this protection over fedora 9 without > > SELInux or with SELinux in permissive mode? > > Yes. SELinux mitigated against the recent HPLIP security flaw which > would have allowed arbitrary code execution as root. > > http://james-morris.livejournal.com/25140.html > https://rhn.redhat.com/errata/RHSA-2007-0960.html > > There have been other similar scenarios where security flaws have been > prevented, or their damage mitigated by presence of SELinux > > > Dan. Dan you are taking this the wrong way. Of course SElinux is great, of course it prevents from 0day exploits, no body is challenging that. But what was the real threat to average desktop users? Has anybody made use of this 0day exploit threat? is there a linux virus in the wild that spread like wildfire that took down all desktops that didn't use SELinux? It is a question of cost and benefit. I argue that SELinux makes much more trouble that it saves people from real danger in desktop enviroment. Ofcourse that you need it in corporate enviroment and if you use Fedora as corporate desktop you should enable it - but don't make it default for them - especially if most of the people using it won't understand cryptic messages that it gives :( If fedora is used as testing ground for redhat corporate desktop then I understand the decision to make it on by default but if you really want average home desktop users to have a pleasant linux experience I really see no point in SELinux. Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From jakub.rusinek at gmail.com Wed Jan 16 20:42:24 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Wed, 16 Jan 2008 21:42:24 +0100 Subject: compilation architecture Message-ID: <5e92ee3f0801161242w2e6c9340lee2eed34cfc3158f@mail.gmail.com> I have two bootcharts. Fedora's: http://img.wklej.org/images/77224fedora-bootchart.png openSUSE's: http://img.wklej.org/images/50076opensuse-bootchart.png Look at many differencies. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at lovesunix.net Wed Jan 16 20:57:03 2008 From: david at lovesunix.net (David Nielsen) Date: Wed, 16 Jan 2008 21:57:03 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> Message-ID: <1200517023.13296.9.camel@localhost.localdomain> ons, 16 01 2008 kl. 20:57 +0100, skrev Valent Turkovic: > Hi, > I believe that SELinux is a great linux server security hardening tool > but that has little use in desktop linux usage and it confuses > ordinary desktop users. > If it hasn't been discussed before I would like to propose that on > desktop cd spin SELinux is not installed by default, of course after > discussion and approval from you (fedora devels). -infinity You opt out of security not into it, if SELinux presents a problem in an otherwise legitimate use case then it's a bug and it should be fixed. Dan Walsh is normally a very responsive maintainer and bugs get fixed nearly instantly. Prevention is better than waiting for a problem to erupt and then scramble to provide a 0 day patch to every critical bug. In much the same way as we vaccinate people to avoid illness in the future instead of just relying on luck and treatment. All that being said, SELinux is disabled on this box, I run constantly on an up to date Development and every day uptill a few weeks ago it has run basically without a problem with SELinux enabled in enforcing mode. I totally put that on me though because I haven't gotten around to tracking the issues and filing them. - David From alan at redhat.com Wed Jan 16 21:00:16 2008 From: alan at redhat.com (Alan Cox) Date: Wed, 16 Jan 2008 16:00:16 -0500 Subject: SELinux removed from desktop cd spin? In-Reply-To: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> Message-ID: <20080116210016.GA10162@devserv.devel.redhat.com> On Wed, Jan 16, 2008 at 08:57:56PM +0100, Valent Turkovic wrote: > I believe that SELinux is a great linux server security hardening tool > but that has little use in desktop linux usage and it confuses > ordinary desktop users. Desktop users are the people it is most important for. If it is still confusing people we need to fix the confusions. Perhaps you can explain more ? From valent.turkovic at gmail.com Wed Jan 16 21:11:28 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 16 Jan 2008 22:11:28 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <20080116210016.GA10162@devserv.devel.redhat.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116210016.GA10162@devserv.devel.redhat.com> Message-ID: <64b14b300801161311n219205f6qb6687d482041f90c@mail.gmail.com> On Jan 16, 2008 10:00 PM, Alan Cox wrote: > On Wed, Jan 16, 2008 at 08:57:56PM +0100, Valent Turkovic wrote: > > I believe that SELinux is a great linux server security hardening tool > > but that has little use in desktop linux usage and it confuses > > ordinary desktop users. > > Desktop users are the people it is most important for. If it is still confusing > people we need to fix the confusions. Perhaps you can explain more ? AVC denials that SELinux Troubleshoot Tool pops up really scare me :) There is half of screen of text and I can't figure out anything important form that. I see no information of value to me as a desktop user. I don't know is my laptop about to blow up or is it some minor error I can safely ignore. I have about 20 AVC denial messages in SE Tool right now... the all make zero sense to me. I just got one from NetworkManager after my laptop returned from sleep... and I see a bunch of them regarding VirtualBox temporary files... etc... etc... Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From michel.sylvan at gmail.com Wed Jan 16 21:12:02 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Wed, 16 Jan 2008 16:12:02 -0500 Subject: spotlight in fedora 8 In-Reply-To: <539333cb0801151842t2606891v601b94cf2382180e@mail.gmail.com> References: <20080115170004.50B6A73681@hormel.redhat.com> <1200430837.4008.0.camel@localhost.localdomain> <478D32F7.30203@gmail.com> <539333cb0801151842t2606891v601b94cf2382180e@mail.gmail.com> Message-ID: On Jan 15, 2008 9:42 PM, subhodip biswas wrote: > On Jan 16, 2008 3:55 AM, Andrew Farris wrote: > > Salloum EL DAHDAAH wrote: > > > I didnt understand what is the 4 th software written in message 7 and 8 > > > thank you > > i mentioned about "deskbar" ... an application pretty similar to > spotlight in Mac os x . It is kind of wierd that that mail is not in > the digest ... while my reply to correction is there ... > Someone misspelled similar => similliar, and Silmarillion is a novel by Tolkien :) Incidentally, for a Spotlight-like indexer, you might want to look at Tracker as well. It has a lean memory profile and it even integrates with Deskbar. Regards, -- Michel Salim http://hircus.jaiku.com/ From airlied at redhat.com Wed Jan 16 21:13:55 2008 From: airlied at redhat.com (Dave Airlie) Date: Thu, 17 Jan 2008 07:13:55 +1000 Subject: SELinux removed from desktop cd spin? In-Reply-To: <20080116210016.GA10162@devserv.devel.redhat.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116210016.GA10162@devserv.devel.redhat.com> Message-ID: <1200518035.5766.2.camel@localhost> On Wed, 2008-01-16 at 16:00 -0500, Alan Cox wrote: > On Wed, Jan 16, 2008 at 08:57:56PM +0100, Valent Turkovic wrote: > > I believe that SELinux is a great linux server security hardening tool > > but that has little use in desktop linux usage and it confuses > > ordinary desktop users. > > Desktop users are the people it is most important for. If it is still confusing > people we need to fix the confusions. Perhaps you can explain more ? > > We made one big mistake with SELinux, selinuxalert or whatever it is called... we haven't learned from the MAC vs Windows ads... we now have an app that puts us squarely into the Windows lack of usefulness camp. "hey user this app is doing something bad. do you want to let it do it?"_t. Dave. From pemboa at gmail.com Wed Jan 16 21:16:58 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 16 Jan 2008 15:16:58 -0600 Subject: SELinux removed from desktop cd spin? In-Reply-To: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> Message-ID: <16de708d0801161316v66d0d49ch2508c29cb25e4abd@mail.gmail.com> On Jan 16, 2008 1:57 PM, Valent Turkovic wrote: > Hi, > I believe that SELinux is a great linux server security hardening tool > but that has little use in desktop linux usage and it confuses > ordinary desktop users. > If it hasn't been discussed before I would like to propose that on > desktop cd spin SELinux is not installed by default, of course after > discussion and approval from you (fedora devels). About how many people would you all estimate even use Fedora as desktop? -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From valent.turkovic at gmail.com Wed Jan 16 21:26:18 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 16 Jan 2008 22:26:18 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <1200518035.5766.2.camel@localhost> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116210016.GA10162@devserv.devel.redhat.com> <1200518035.5766.2.camel@localhost> Message-ID: <64b14b300801161326l76fbca60pf806f9815db3fa@mail.gmail.com> On Jan 16, 2008 10:13 PM, Dave Airlie wrote: > > On Wed, 2008-01-16 at 16:00 -0500, Alan Cox wrote: > > On Wed, Jan 16, 2008 at 08:57:56PM +0100, Valent Turkovic wrote: > > > I believe that SELinux is a great linux server security hardening tool > > > but that has little use in desktop linux usage and it confuses > > > ordinary desktop users. > > > > Desktop users are the people it is most important for. If it is still confusing > > people we need to fix the confusions. Perhaps you can explain more ? > > > > > > We made one big mistake with SELinux, selinuxalert or whatever it is > called... we haven't learned from the MAC vs Windows ads... we now have > an app that puts us squarely into the Windows lack of usefulness camp. > > "hey user this app is doing something bad. do you want to let it do > it?"_t. I wish it was that easy when I installed fluendo codes I couldn't play my multimedia because SELInux blocked it (nobody tested it even that fedora 8 advertised fluendo codec support as one of its new shiny features). selinux troubleshoot tool it still to hard for ordinary desktop users. I see the real benefit of SELinux troubleshoot tool for admins using RHEL of fedora on their servers but on desktop I hardly see any point. I will bet anybody who wants that Fedora live cd users will have more trouble from using SElinux than benefit. Also that ubuntu, opensuse and other distros that don't use SElinux won't be in trouble from some 0day exploit. Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From eparis at redhat.com Wed Jan 16 21:27:30 2008 From: eparis at redhat.com (Eric Paris) Date: Wed, 16 Jan 2008 16:27:30 -0500 Subject: SELinux removed from desktop cd spin? In-Reply-To: <1200518035.5766.2.camel@localhost> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116210016.GA10162@devserv.devel.redhat.com> <1200518035.5766.2.camel@localhost> Message-ID: <1200518850.3277.5.camel@localhost.localdomain> On Thu, 2008-01-17 at 07:13 +1000, Dave Airlie wrote: > On Wed, 2008-01-16 at 16:00 -0500, Alan Cox wrote: > > On Wed, Jan 16, 2008 at 08:57:56PM +0100, Valent Turkovic wrote: > > > I believe that SELinux is a great linux server security hardening tool > > > but that has little use in desktop linux usage and it confuses > > > ordinary desktop users. > > > > Desktop users are the people it is most important for. If it is still confusing > > people we need to fix the confusions. Perhaps you can explain more ? > > > > > > We made one big mistake with SELinux, selinuxalert or whatever it is > called... we haven't learned from the MAC vs Windows ads... we now have > an app that puts us squarely into the Windows lack of usefulness camp. > > "hey user this app is doing something bad. do you want to let it do > it?"_t. > > Dave. A difference though is that while we do pop up that little window which exposes the inherent complexities of the underlying operating system we attempt to explain in human readable format what is going on (sometimes we fail, just read this thread). I must admit some of it must seem very cryptic, but that cryptic information is what the selinux developers need to actually asses and fix the issue. We could hide it on the mian screen, but then every BZ that got filed would have a first responce of 'please include the useful information hidden behind the 'developer information' button. But more importantly we are working towards having that application never show up unless it is a well known tunable the user may want to flip or there is something going severely wrong. Installing a new program selinux has never heard of should not cause selinux problems (ok, if the app does something terrible with memory maybe.) We only pop up that dialog for applications we 'think' we already know everything it needs to do. I wish it popped up less but we get closer and closer to the goal every day. Thanks Dan. -Eric From lesmikesell at gmail.com Wed Jan 16 21:29:43 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 16 Jan 2008 15:29:43 -0600 Subject: SELinux removed from desktop cd spin? In-Reply-To: <16de708d0801161316v66d0d49ch2508c29cb25e4abd@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <16de708d0801161316v66d0d49ch2508c29cb25e4abd@mail.gmail.com> Message-ID: <478E7747.4020202@gmail.com> Arthur Pemberton wrote: >> Hi, >> I believe that SELinux is a great linux server security hardening tool >> but that has little use in desktop linux usage and it confuses >> ordinary desktop users. >> If it hasn't been discussed before I would like to propose that on >> desktop cd spin SELinux is not installed by default, of course after >> discussion and approval from you (fedora devels). > > About how many people would you all estimate even use Fedora as desktop? Where else would you use it? -- Les Mikesell lesmikesell at gmail.com From valent.turkovic at gmail.com Wed Jan 16 21:28:52 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 16 Jan 2008 22:28:52 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <16de708d0801161316v66d0d49ch2508c29cb25e4abd@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <16de708d0801161316v66d0d49ch2508c29cb25e4abd@mail.gmail.com> Message-ID: <64b14b300801161328u1bd44f7ajc0d1f2ef9a172513@mail.gmail.com> On Jan 16, 2008 10:16 PM, Arthur Pemberton wrote: > On Jan 16, 2008 1:57 PM, Valent Turkovic wrote: > > Hi, > > I believe that SELinux is a great linux server security hardening tool > > but that has little use in desktop linux usage and it confuses > > ordinary desktop users. > > If it hasn't been discussed before I would like to propose that on > > desktop cd spin SELinux is not installed by default, of course after > > discussion and approval from you (fedora devels). > > About how many people would you all estimate even use Fedora as desktop? > > -- > Fedora 7 : sipping some of that moonshine > ( www.pembo13.com ) few hundred thousands? Don't know... look at fedora statistics page and judge for yourself... And I bet that more will choose ubuntu as a "friendlier" desktop if fedora forces people to use SELinux. Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From valent.turkovic at gmail.com Wed Jan 16 21:35:17 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 16 Jan 2008 22:35:17 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <1200518850.3277.5.camel@localhost.localdomain> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116210016.GA10162@devserv.devel.redhat.com> <1200518035.5766.2.camel@localhost> <1200518850.3277.5.camel@localhost.localdomain> Message-ID: <64b14b300801161335o1f27cf76t3affe31e8aae02ab@mail.gmail.com> On Jan 16, 2008 10:27 PM, Eric Paris wrote: > > On Thu, 2008-01-17 at 07:13 +1000, Dave Airlie wrote: > > On Wed, 2008-01-16 at 16:00 -0500, Alan Cox wrote: > > > On Wed, Jan 16, 2008 at 08:57:56PM +0100, Valent Turkovic wrote: > > > > I believe that SELinux is a great linux server security hardening tool > > > > but that has little use in desktop linux usage and it confuses > > > > ordinary desktop users. > > > > > > Desktop users are the people it is most important for. If it is still confusing > > > people we need to fix the confusions. Perhaps you can explain more ? > > > > > > > > > > We made one big mistake with SELinux, selinuxalert or whatever it is > > called... we haven't learned from the MAC vs Windows ads... we now have > > an app that puts us squarely into the Windows lack of usefulness camp. > > > > "hey user this app is doing something bad. do you want to let it do > > it?"_t. > > > > Dave. > > A difference though is that while we do pop up that little window which > exposes the inherent complexities of the underlying operating system we > attempt to explain in human readable format what is going on (sometimes > we fail, just read this thread). I must admit some of it must seem very > cryptic, but that cryptic information is what the selinux developers > need to actually asses and fix the issue. We could hide it on the mian > screen, but then every BZ that got filed would have a first responce of > 'please include the useful information hidden behind the 'developer > information' button. And that is exactly why this feels like testing ground for RHEL and not an option that actually benefits users because you admit that it is not ready for "joe user". > But more importantly we are working towards having that application > never show up unless it is a well known tunable the user may want to > flip or there is something going severely wrong. Installing a new > program selinux has never heard of should not cause selinux problems > (ok, if the app does something terrible with memory maybe.) We only pop > up that dialog for applications we 'think' we already know everything it > needs to do. I wish it popped up less but we get closer and closer to > the goal every day. I really love SELinux and it is a great tool, and it helps a lot of admins who use it, but because it is still too rough for the general public it should not be forced onto them. What is your target audience with SELinux? I'm here only talking form removing it on Gnome Live Fedora cd - focus of that "spin" are desktop users AFAIK. Leave it on DVD version whose target audience is much wider. Valent -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From valent.turkovic at gmail.com Wed Jan 16 21:45:46 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 16 Jan 2008 22:45:46 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <1200517023.13296.9.camel@localhost.localdomain> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <1200517023.13296.9.camel@localhost.localdomain> Message-ID: <64b14b300801161345m748eb8e8ga39a3525b6faf69b@mail.gmail.com> On Jan 16, 2008 9:57 PM, David Nielsen wrote: > > ons, 16 01 2008 kl. 20:57 +0100, skrev Valent Turkovic: > > Hi, > > I believe that SELinux is a great linux server security hardening tool > > but that has little use in desktop linux usage and it confuses > > ordinary desktop users. > > If it hasn't been discussed before I would like to propose that on > > desktop cd spin SELinux is not installed by default, of course after > > discussion and approval from you (fedora devels). > > -infinity > > You opt out of security not into it, if SELinux presents a problem in an > otherwise legitimate use case then it's a bug and it should be fixed. > Dan Walsh is normally a very responsive maintainer and bugs get fixed > nearly instantly. You bring again something that has nothing to do with the issue. Off course you opt out from security, not opt in. But I believe that using fedora as a general desktop is already all the security 99% people need. Other special cases can enable SELinux or even better build their own kernel. In order to use wireless fedora had to accept using firmware blobs AFAIK just because people need their wireless JustToWork. And I believe that people would like also not to get some useless (to them) cryptic messages that don't give them any security. I get contantly AVC Denial messages and none of them was a threat to my system. > Prevention is better than waiting for a problem to erupt and then > scramble to provide a 0 day patch to every critical bug. In much the > same way as we vaccinate people to avoid illness in the future instead > of just relying on luck and treatment. SELinux on desktop feels much more like keeping people from ever leaving their house in order for them not to get hurt outside that vaccination. On servers I can follow your vaccination analogy... I believe that some technologies are made for servers and their place it on server not on desktop. SELinux is top of that list. Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From poelstra at redhat.com Wed Jan 16 21:50:04 2008 From: poelstra at redhat.com (John Poelstra) Date: Wed, 16 Jan 2008 13:50:04 -0800 Subject: Fedora Rel-Eng Meeting Recap 2007-JAN-14 Message-ID: <478E7C0C.7060202@redhat.com> Recap and full IRC transcript found here: http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-jan-14 Please make corrections and clarifications to the wiki page. == Meeting Highlights == * Alpha freeze is 2008-01-15 * Rawhide is not currently installable * http://wwoods.fedorapeople.org/rawhide.html has what I've got so far * Alpha blocker bug: https://bugzilla.redhat.com/show_bug.cgi?id=428703 * Release Engineering Schedule: http://poelstra.fedorapeople.org/schedules/f-9/f-9-releng-tasks.html DECISION: slip alpha freeze by one week, re-evaluate state next meeting; hold to planned GA date == IRC Transcript == From wtogami at redhat.com Wed Jan 16 21:46:49 2008 From: wtogami at redhat.com (Warren Togami) Date: Wed, 16 Jan 2008 16:46:49 -0500 Subject: SELinux removed from desktop cd spin? In-Reply-To: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> Message-ID: <478E7B49.2020309@redhat.com> Valent Turkovic wrote: > Hi, > I believe that SELinux is a great linux server security hardening tool > but that has little use in desktop linux usage and it confuses > ordinary desktop users. > If it hasn't been discussed before I would like to propose that on > desktop cd spin SELinux is not installed by default, of course after > discussion and approval from you (fedora devels). > > > Cheers, > Valent > Also keep in mind that if SELinux break something on the desktop, THAT is a bug. Starting before F8 I personally began to use SELinux enabled all the time. At first a few things were broken, but I figured out how to report smart Bugzilla reports against selinux-policy and dwalsh takes care of them real quick. Warren Togami wtogami at redhat.com From dmc.fedora at filteredperception.org Wed Jan 16 21:49:23 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Wed, 16 Jan 2008 15:49:23 -0600 Subject: SELinux removed from desktop cd spin? In-Reply-To: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> Message-ID: <478E7BE3.3060901@filteredperception.org> Valent Turkovic wrote: > Hi, > I believe that SELinux is a great linux server security hardening tool > but that has little use in desktop linux usage and it confuses > ordinary desktop users. > If it hasn't been discussed before I would like to propose that on > desktop cd spin SELinux is not installed by default, of course after > discussion and approval from you (fedora devels). But don't you see- this isn't a real issue- BECAUSE LINUX IS ABOUT CHOICE ;) How hard is this? -> yum -y install livecd-tools sed -i -e 's/selinux\ --enforcing/selinux\ --disabled/' \ /usr/share/livecd-tools/livecd-fedora-8-base-desktop.ks livecd-creator \ --config=/usr/share/livecd-tools/livecd-fedora-8-desktop.ks Cheers, -dmc P.S. - yes, it's a bit trickier to extract the 100MB or so of selinux support packages so that you can actually fit more of the software you are interested in on the constrained 700MB livecd, but I'll leave that as an excercise for the reader. From kevin.kofler at chello.at Wed Jan 16 21:53:05 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 16 Jan 2008 21:53:05 +0000 (UTC) Subject: rawhide report: 20080116 changes References: <200801161639.m0GGdexE021103@porkchop.devel.redhat.com> Message-ID: Build System redhat.com> writes: > New package R-BSgenome.Celegans.UCSC.ce2 > Caenorhabditis elegans genome (UCSC Release ce2) Huh? What's that doing in a Fedora package? It's plain data, isn't it? Are we going to get a R-BSgenome.*.UCSC.ce* package for every species in existence? ;-) Kevin Kofler From tibbs at math.uh.edu Wed Jan 16 21:58:27 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 16 Jan 2008 15:58:27 -0600 Subject: rawhide report: 20080116 changes In-Reply-To: References: <200801161639.m0GGdexE021103@porkchop.devel.redhat.com> Message-ID: >>>>> "KK" == Kevin Kofler writes: KK> Huh? What's that doing in a Fedora package? What do you mean? Do you feel this is somehow unacceptable? KK> It's plain data, isn't it? It's data for use with other packages in the distribution. KK> Are we going to get a R-BSgenome.*.UCSC.ce* package for every KK> species in existence? ;-) Only the ones which have been sequenced. I think there are three or four of them available. - J< From jspaleta at gmail.com Wed Jan 16 22:00:58 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 16 Jan 2008 13:00:58 -0900 Subject: SELinux removed from desktop cd spin? In-Reply-To: <64b14b300801161335o1f27cf76t3affe31e8aae02ab@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116210016.GA10162@devserv.devel.redhat.com> <1200518035.5766.2.camel@localhost> <1200518850.3277.5.camel@localhost.localdomain> <64b14b300801161335o1f27cf76t3affe31e8aae02ab@mail.gmail.com> Message-ID: <604aa7910801161400k2e3ea6d6r3706a721a9106aed@mail.gmail.com> On Jan 16, 2008 12:35 PM, Valent Turkovic wrote: > What is your target audience with SELinux? Everyone who runs a computer that takes input from an external source, whether that be floppies, or a network connection, or a bluetooth keyboard. Security matters... it doesn't matter if you are a desktop user or not... security matters. If we are doing a good enough job at policy writing and management then we fix the policies. You really need to go back and read every single blog post from Dan Walsh concerning the new xguest policy he is working on. He's got very clear and very real desktop usage cases in mind for it. Turning selinux off wholesale on a desktop spin just because its not optimal yet, is short-sighted. -jef From ggw at wolves.durham.nc.us Wed Jan 16 22:10:09 2008 From: ggw at wolves.durham.nc.us (G.Wolfe Woodbury) Date: Wed, 16 Jan 2008 17:10:09 -0500 Subject: Fedora Rel-Eng Meeting Recap 2007-JAN-14 In-Reply-To: <478E7C0C.7060202@redhat.com> References: <478E7C0C.7060202@redhat.com> Message-ID: <478E80C1.5040909@wolves.durham.nc.us> John Poelstra wrote: > Recap and full IRC transcript found here: > http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-jan-14 > > Please make corrections and clarifications to the wiki page. > > == Meeting Highlights == > * Alpha freeze is 2008-01-15 > * Rawhide is not currently installable I'd quibble about this. It installs _mostly_ but doesn't have a working firstboot sequence to finish the install setup details. I've installed ix86 (not _64) twice in the last three days. > * http://wwoods.fedorapeople.org/rawhide.html has what I've got so far neat little page, does it really automagically track the status, or do you fix it up by hand. -- Wolfe From pingoufc4 at yahoo.fr Wed Jan 16 22:07:09 2008 From: pingoufc4 at yahoo.fr (pingou) Date: Wed, 16 Jan 2008 23:07:09 +0100 Subject: rawhide report: 20080116 changes In-Reply-To: References: <200801161639.m0GGdexE021103@porkchop.devel.redhat.com> Message-ID: <478E800D.5050708@yahoo.fr> Jason L Tibbitts III wrote: >>>>>> "KK" == Kevin Kofler writes: > > KK> Huh? What's that doing in a Fedora package? > > What do you mean? Do you feel this is somehow unacceptable? > > KK> It's plain data, isn't it? > > It's data for use with other packages in the distribution. It is a requires from a R librairies from bioconductor (bioconductor.org) > > KK> Are we going to get a R-BSgenome.*.UCSC.ce* package for every > KK> species in existence? ;-) > > Only the ones which have been sequenced. I think there are three or > four of them available. > hmm well... http://bioconductor.org/packages/2.1/data/annotation/ Regards, Pierre ___________________________________________________________________________ Yahoo! Mail r?invente le mail ! D?couvrez le nouveau Yahoo! Mail et son interface r?volutionnaire. http://fr.mail.yahoo.com From martin at marquesminen.com.ar Wed Jan 16 22:28:41 2008 From: martin at marquesminen.com.ar (Martin Marques) Date: Wed, 16 Jan 2008 20:28:41 -0200 Subject: Fedora 8 hanging In-Reply-To: <20080115122333.GA29319@ee.oulu.fi> References: <4788DF1F.6050802@marquesminen.com.ar> <20080112154548.GA18472@devserv.devel.redhat.com> <47894127.2000705@marquesminen.com.ar> <20080115122333.GA29319@ee.oulu.fi> Message-ID: <478E8519.3050208@marquesminen.com.ar> Pekka Pietikainen escribi?: > On Sat, Jan 12, 2008 at 08:37:27PM -0200, Martin Marques wrote: >> Alan Cox escribi?: >>> On Sat, Jan 12, 2008 at 01:39:11PM -0200, Martin Marques wrote: >>>> with an AMD turion 64 (running Fedora 64) and an Nvidia video card (using >>>> the binary driver from livna). >>> Remove the binary driver. Reboot using the nv Fedora supplied driver and >>> see how it runs for a bit. If it still hangs then you know its not likely to >>> be the Nvidia driver >>> >> Removed nvidia.ko from the start up and the system hanged at boot time when >> trying to start NM. Hangs happen randomly as I said: At differnet times of >> boot or when in graphical mode. > See > > https://fedoraproject.org/wiki/KernelCommonProblems > https://bugzilla.redhat.com/show_bug.cgi?id=283161 (Bug is i686 not > x86_64 hangs, but the command line options are worth trying out, nohz=off, > highres=off, clocksource=xxx etc. ). Rawhide kernels seemed to be the fix > for me :-) The thing is that I'm using the x86_64 kernel on a turion64. Also I had some other issues, like the fact that I couldn't see the tty[1-6] virtual terminals, and after suspending the system it came back with a blank screen which sometimes got fixed by trying to move to one of the text virtual terminals and back to graphical mode. These two issues were fixed when I moved completely back to the NV driver from xorg. The problem is that I still get hangs at random time. Right now I'm gonna try the acpi=off option at boot time. Any other ideas are welcomed? From lordmorgul at gmail.com Wed Jan 16 22:29:37 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 16 Jan 2008 14:29:37 -0800 Subject: SELinux removed from desktop cd spin? In-Reply-To: <64b14b300801161235i4a4ed432h4f7b81ecefaf292b@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116200333.GE15623@redhat.com> <64b14b300801161219q355d93b0jb57f91f48615591a@mail.gmail.com> <20080116202554.GF15623@redhat.com> <64b14b300801161235i4a4ed432h4f7b81ecefaf292b@mail.gmail.com> Message-ID: <478E8551.1030907@gmail.com> Valent Turkovic wrote: > On Jan 16, 2008 9:25 PM, Daniel P. Berrange wrote: >> On Wed, Jan 16, 2008 at 09:19:38PM +0100, Valent Turkovic wrote: >>> On Jan 16, 2008 9:03 PM, Daniel P. Berrange wrote: >>>> On Wed, Jan 16, 2008 at 08:57:56PM +0100, Valent Turkovic wrote: >>>>> Hi, >>>>> I believe that SELinux is a great linux server security hardening tool >>>>> but that has little use in desktop linux usage and it confuses >>>>> ordinary desktop users. >>>> It is of great use in a desktop spin. On my 'desktop' install for my >>>> laptop I have many many system daemons running under a confined domain >>> You, of course, will always have the ability to choose to install it >>> and use it. >>> >>>>> If it hasn't been discussed before I would like to propose that on >>>>> desktop cd spin SELinux is not installed by default, of course after >>>>> discussion and approval from you (fedora devels). >>>> No. SELinux provides very real & important protection for desktop users. >>> Can you give me examples of this protection over fedora 9 without >>> SELInux or with SELinux in permissive mode? >> Yes. SELinux mitigated against the recent HPLIP security flaw which >> would have allowed arbitrary code execution as root. >> >> http://james-morris.livejournal.com/25140.html >> https://rhn.redhat.com/errata/RHSA-2007-0960.html >> >> There have been other similar scenarios where security flaws have been >> prevented, or their damage mitigated by presence of SELinux >> >> >> Dan. > > Dan you are taking this the wrong way. Of course SElinux is great, of > course it prevents from 0day exploits, no body is challenging that. > But what was the real threat to average desktop users? Has anybody > made use of this 0day exploit threat? is there a linux virus in the > wild that spread like wildfire that took down all desktops that didn't > use SELinux? > > It is a question of cost and benefit. I argue that SELinux makes much > more trouble that it saves people from real danger in desktop > enviroment. Ofcourse that you need it in corporate enviroment and if > you use Fedora as corporate desktop you should enable it - but don't > make it default for them - especially if most of the people using it > won't understand cryptic messages that it gives :( > > If fedora is used as testing ground for redhat corporate desktop then > I understand the decision to make it on by default but if you really > want average home desktop users to have a pleasant linux experience I > really see no point in SELinux. > > Valent. I would argue that for the continued development, improvement, and eventual adoption of selinux across the linux community at large, it must be tested in ever widening circles... and its crucially important for distributions to take steps in that direction. Fedora users should expect to either 1) know how to turn it off, 2) learn how to use it. Google provides great search results on both of those options; if thats your only place to start I would expect anyone who actually tried to be able to disable it. It should not be up to the distribution which is atm doing the most to develop selinux to turn it off for people who choose the distro targetted at cutting edge linux technologies. Sooner or later there WILL be increasing threats to linux and its quite possible to have virii spread in the wild... if good protections against it are not developed and supported now then when? After they show up? -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From wwoods at redhat.com Wed Jan 16 22:31:31 2008 From: wwoods at redhat.com (Will Woods) Date: Wed, 16 Jan 2008 17:31:31 -0500 Subject: Fedora Rel-Eng Meeting Recap 2007-JAN-14 In-Reply-To: <478E80C1.5040909@wolves.durham.nc.us> References: <478E7C0C.7060202@redhat.com> <478E80C1.5040909@wolves.durham.nc.us> Message-ID: <1200522691.2980.3.camel@metroid.rdu.redhat.com> On Wed, 2008-01-16 at 17:10 -0500, G.Wolfe Woodbury wrote: > John Poelstra wrote: > > Recap and full IRC transcript found here: > > http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-jan-14 > > > > Please make corrections and clarifications to the wiki page. > > > > == Meeting Highlights == > > * Alpha freeze is 2008-01-15 > > * Rawhide is not currently installable > > I'd quibble about this. It installs _mostly_ but doesn't have a working > firstboot sequence to finish the install setup details. I've installed > ix86 (not _64) twice in the last three days. Yeah, it's installable today, but it wasn't on the 14th. It's been OK since then. > > > * http://wwoods.fedorapeople.org/rawhide.html has what I've got so far > > neat little page, does it really automagically track the status, or do > you fix it up by hand. The page is generated dynamically.. but I generate a static copy and upload *that*. Once I have some time to flesh out the code for the notes section it'll go live somewhere more useful. -w -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Wed Jan 16 22:34:06 2008 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 16 Jan 2008 16:34:06 -0600 Subject: Fedora bug triage - workflow proposal In-Reply-To: <1200432097.28156.13.camel@vincent52.localdomain> References: <20080115185925.GE9082@nostromo.devel.redhat.com> <1200432097.28156.13.camel@vincent52.localdomain> Message-ID: <1200522846.15354.2.camel@localhost> On Tue, 2008-01-15 at 21:21 +0000, Matthew Saltzman wrote: > (I'm usually just a lurker on discussions like this, but I couldn't > resist.) > > NEW -> CONFIRMED -> ASSIGNED ? I like this color best. "UNCONFIRMED" contains a negation, which is not something that comes naturally to the mushy grey computers that live in people's skulls[1]... [1] Which I can not find any scientific references to offhand, as I can't seem to figure out what to google for that doesn't bring up a lot of self help bullpoopy... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From lordmorgul at gmail.com Wed Jan 16 22:34:44 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 16 Jan 2008 14:34:44 -0800 Subject: SELinux removed from desktop cd spin? In-Reply-To: <64b14b300801161311n219205f6qb6687d482041f90c@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116210016.GA10162@devserv.devel.redhat.com> <64b14b300801161311n219205f6qb6687d482041f90c@mail.gmail.com> Message-ID: <478E8684.6080402@gmail.com> Valent Turkovic wrote: > On Jan 16, 2008 10:00 PM, Alan Cox wrote: >> On Wed, Jan 16, 2008 at 08:57:56PM +0100, Valent Turkovic wrote: >>> I believe that SELinux is a great linux server security hardening tool >>> but that has little use in desktop linux usage and it confuses >>> ordinary desktop users. >> Desktop users are the people it is most important for. If it is still confusing >> people we need to fix the confusions. Perhaps you can explain more ? > > AVC denials that SELinux Troubleshoot Tool pops up really scare me :) > There is half of screen of text and I can't figure out anything > important form that. I see no information of value to me as a desktop > user. I don't know is my laptop about to blow up or is it some minor > error I can safely ignore. > > I have about 20 AVC denial messages in SE Tool right now... the all > make zero sense to me. I just got one from NetworkManager after my > laptop returned from sleep... and I see a bunch of them regarding > VirtualBox temporary files... etc... etc... That tool should not be running for users who do not understand it. The typical user (assuming the policy is *correct* and no longer buggy, future use case) does not need to care about avc denials, they do not need to know about them. The typical user will happily go along doing what they want to do, and having selinux protecting their machine from doing things it should not. (obviously due to buggy policy and the ever changing needs of various packages this is not a stable condition yet!) If selinux troubleshoot scares you, turn it off, its for development and debugging. A user should not need to know when denials happen, unless they are 1) helping to debug policy, or 2) looking for security breaches. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From lordmorgul at gmail.com Wed Jan 16 22:41:19 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 16 Jan 2008 14:41:19 -0800 Subject: SELinux removed from desktop cd spin? In-Reply-To: <16de708d0801161316v66d0d49ch2508c29cb25e4abd@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <16de708d0801161316v66d0d49ch2508c29cb25e4abd@mail.gmail.com> Message-ID: <478E880F.1040408@gmail.com> Arthur Pemberton wrote: > On Jan 16, 2008 1:57 PM, Valent Turkovic wrote: >> Hi, >> I believe that SELinux is a great linux server security hardening tool >> but that has little use in desktop linux usage and it confuses >> ordinary desktop users. >> If it hasn't been discussed before I would like to propose that on >> desktop cd spin SELinux is not installed by default, of course after >> discussion and approval from you (fedora devels). > > About how many people would you all estimate even use Fedora as desktop? > http://smolts.org/static/stats/stats.html Take a good look at stats on form factor, runlevel, arch, and cpu. Those give a pretty good estimation of usage, and the typical desktop machine appears to be by far the most common. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From seg at haxxed.com Wed Jan 16 22:49:04 2008 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 16 Jan 2008 16:49:04 -0600 Subject: SELinux removed from desktop cd spin? In-Reply-To: <64b14b300801161328u1bd44f7ajc0d1f2ef9a172513@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <16de708d0801161316v66d0d49ch2508c29cb25e4abd@mail.gmail.com> <64b14b300801161328u1bd44f7ajc0d1f2ef9a172513@mail.gmail.com> Message-ID: <1200523744.15354.7.camel@localhost> On Wed, 2008-01-16 at 22:28 +0100, Valent Turkovic wrote: > And I bet that more will choose ubuntu as a "friendlier" desktop if > fedora forces people to use SELinux. Yes kids, Linux *is* about choice. Linux != Fedora. If you love Ubuntu so much, why don't you choose to marry it? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From galibert at pobox.com Wed Jan 16 23:07:31 2008 From: galibert at pobox.com (Olivier Galibert) Date: Thu, 17 Jan 2008 00:07:31 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478E880F.1040408@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <16de708d0801161316v66d0d49ch2508c29cb25e4abd@mail.gmail.com> <478E880F.1040408@gmail.com> Message-ID: <20080116230731.GA15477@dspnet.fr.eu.org> On Wed, Jan 16, 2008 at 02:41:19PM -0800, Andrew Farris wrote: > http://smolts.org/static/stats/stats.html > > Take a good look at stats on form factor, runlevel, arch, and cpu. Those > give a pretty good estimation of usage, and the typical desktop machine > appears to be by far the most common. You realize smolt misses most if not all kickstart or otherwise automatic/semiautomatic installs, right? OG. From lordmorgul at gmail.com Wed Jan 16 23:07:52 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 16 Jan 2008 15:07:52 -0800 Subject: SELinux removed from desktop cd spin? In-Reply-To: <64b14b300801161328u1bd44f7ajc0d1f2ef9a172513@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <16de708d0801161316v66d0d49ch2508c29cb25e4abd@mail.gmail.com> <64b14b300801161328u1bd44f7ajc0d1f2ef9a172513@mail.gmail.com> Message-ID: <478E8E48.6080003@gmail.com> Valent Turkovic wrote: > And I bet that more will choose ubuntu as a "friendlier" desktop if > fedora forces people to use SELinux. Except noone is talking about forcing anyone to use selinux, just about not 'suggesting' that they don't use it... which is exactly what turning it off at install would be doing. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From lordmorgul at gmail.com Wed Jan 16 23:13:09 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 16 Jan 2008 15:13:09 -0800 Subject: SELinux removed from desktop cd spin? In-Reply-To: <20080116230731.GA15477@dspnet.fr.eu.org> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <16de708d0801161316v66d0d49ch2508c29cb25e4abd@mail.gmail.com> <478E880F.1040408@gmail.com> <20080116230731.GA15477@dspnet.fr.eu.org> Message-ID: <478E8F85.2000206@gmail.com> Olivier Galibert wrote: > On Wed, Jan 16, 2008 at 02:41:19PM -0800, Andrew Farris wrote: >> http://smolts.org/static/stats/stats.html >> >> Take a good look at stats on form factor, runlevel, arch, and cpu. Those >> give a pretty good estimation of usage, and the typical desktop machine >> appears to be by far the most common. > > You realize smolt misses most if not all kickstart or otherwise > automatic/semiautomatic installs, right? > > OG. Actually I wasn't aware of that, thanks (I'm sure if I had thought about it that should have been obvious). I guess that might be a nice thing to change. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From jmorris at namei.org Wed Jan 16 23:15:36 2008 From: jmorris at namei.org (James Morris) Date: Thu, 17 Jan 2008 10:15:36 +1100 (EST) Subject: SELinux removed from desktop cd spin? In-Reply-To: <64b14b300801161335o1f27cf76t3affe31e8aae02ab@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116210016.GA10162@devserv.devel.redhat.com> <1200518035.5766.2.camel@localhost> <1200518850.3277.5.camel@localhost.localdomain> <64b14b300801161335o1f27cf76t3affe31e8aae02ab@mail.gmail.com> Message-ID: On Wed, 16 Jan 2008, Valent Turkovic wrote: > I really love SELinux and it is a great tool, and it helps a lot of > admins who use it, but because it is still too rough for the general > public it should not be forced onto them. > > What is your target audience with SELinux? The target audience is everyone. What we are trying to do is make a fundamental change to computer security by taking decades of research and making it useful in the general case. We are shipping MAC as a standard, enabled-by-default feature of a general purpose OS. Welcome to the future, and thanks for being part of it. - James -- James Morris From pemboa at gmail.com Wed Jan 16 23:16:21 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 16 Jan 2008 17:16:21 -0600 Subject: SELinux removed from desktop cd spin? In-Reply-To: <64b14b300801161328u1bd44f7ajc0d1f2ef9a172513@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <16de708d0801161316v66d0d49ch2508c29cb25e4abd@mail.gmail.com> <64b14b300801161328u1bd44f7ajc0d1f2ef9a172513@mail.gmail.com> Message-ID: <16de708d0801161516w1144fc5fp7cb5f866bd33d84b@mail.gmail.com> On Jan 16, 2008 3:28 PM, Valent Turkovic wrote: > And I bet that more will choose ubuntu as a "friendlier" desktop if > fedora forces people to use SELinux. Problem 1 : Any arguement based on Ubuntu is almost useless to me Problem 2 : No one is forcing anyone to use SELinux, the only way to make it easier to not use SELinux would be to have mind reading software in Anaconda -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From dmc.fedora at filteredperception.org Wed Jan 16 23:54:16 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Wed, 16 Jan 2008 17:54:16 -0600 Subject: SELinux removed from desktop cd spin? In-Reply-To: References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116210016.GA10162@devserv.devel.redhat.com> <1200518035.5766.2.camel@localhost> <1200518850.3277.5.camel@localhost.localdomain> <64b14b300801161335o1f27cf76t3affe31e8aae02ab@mail.gmail.com> Message-ID: <478E9928.9070406@filteredperception.org> James Morris wrote: > On Wed, 16 Jan 2008, Valent Turkovic wrote: > >> I really love SELinux and it is a great tool, and it helps a lot of >> admins who use it, but because it is still too rough for the general >> public it should not be forced onto them. >> >> What is your target audience with SELinux? > > The target audience is everyone. > > What we are trying to do is make a fundamental change to computer security > by taking decades of research and making it useful in the general case. > We are shipping MAC as a standard, enabled-by-default feature of a general > purpose OS. Welcome to the future, and thanks for being part of it. You *have* seen Tron, right? SELinux would just be so much more aesthetically pleasing if it was just named MCP. Just as the idea is decades old, the idea that it might also end up as a convoluted tormentor of 'the users' that gets in the way of actual productive achievement is also decades old. Do you believe in 'the users'? Of course that movie did look like it was made by a bunch of drug using frisbee throwers... -dmc From bnocera at redhat.com Thu Jan 17 00:02:18 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Thu, 17 Jan 2008 00:02:18 +0000 Subject: SELinux removed from desktop cd spin? In-Reply-To: <64b14b300801161326l76fbca60pf806f9815db3fa@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116210016.GA10162@devserv.devel.redhat.com> <1200518035.5766.2.camel@localhost> <64b14b300801161326l76fbca60pf806f9815db3fa@mail.gmail.com> Message-ID: <1200528138.26259.60.camel@cookie.hadess.net> On Wed, 2008-01-16 at 22:26 +0100, Valent Turkovic wrote: > I wish it was that easy when I installed fluendo codes I couldn't play > my multimedia because SELInux blocked it (nobody tested it even that > fedora 8 advertised fluendo codec support as one of its new shiny > features). We certainly did test it, but there's nothing we could do about it. Look at the timestamp for the upstream bug filed with Fluendo, and look at the release date. We made sure it worked for the default installation for the MP3 plugin with a special-casing in Codeina. Please stop lying. Cheers From bnocera at redhat.com Thu Jan 17 00:07:52 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Thu, 17 Jan 2008 00:07:52 +0000 Subject: firewall changes for F-9+ In-Reply-To: <478E4460.8040805@redhat.com> References: <478E4460.8040805@redhat.com> Message-ID: <1200528472.26259.63.camel@cookie.hadess.net> On Wed, 2008-01-16 at 18:52 +0100, Thomas Woerner wrote: > Hello, > > here are the latest changes for system-config-firewall for F-9+: > > The usage of --port=: for lokkit will open up this port and > not a service using this port anymore. To enable a service you have to > use the new --service= option. There are no magic default open > services. You have to open up the services, you want to use. The interim > options --no-X; X in ["ipsec", "mdns", "ipp"] are obsolete now. > > To setup a new firewall, you can use the new --default= > configuration option as a start: > server : ssh is enabled > desktop : ipsec, mdns and ipp are enabled IpSec and IPP as services don't sound very much like desktop applications. From buytenh at wantstofly.org Mon Jan 14 23:33:31 2008 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Tue, 15 Jan 2008 00:33:31 +0100 Subject: Fedora 8/ARM available Message-ID: <20080114233331.GL17358@xi.wantstofly.org> Hi all, We are proud to announce the availability of a(n unofficial) Fedora 8 package repository for the ARM architecture. The package repository has been built for ARMv5 EABI, soft-float, little endian. The majority of the important and frequently used Fedora packages have been built for ARM. The Fedora/ARM architecture wiki page has more info: http://fedoraproject.org/wiki/Architectures/ARM The easiest way to start using Fedora 8/ARM is to download the prebuilt root filesystem, which can be booted in QEMU, or chroot'ed into or booted from on any ARMv5 or later processor running in little endian mode. Additional packages can be installed by using yum, which is provided in the filesystem. A HOWTO which describes getting Fedora/ARM running in QEMU is here: http://fedoraproject.org/wiki/Architectures/ARM/HowToQemu There currently are a handful of known issues, which are described at: http://fedoraproject.org/wiki/Architectures/ARM/TODO Please help us by using the Fedora/ARM port and reporting any issues you run into so that we can fix them. thanks, Lennert _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From loupgaroublond at gmail.com Thu Jan 17 01:17:17 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 16 Jan 2008 20:17:17 -0500 Subject: SELinux removed from desktop cd spin? In-Reply-To: <64b14b300801161235i4a4ed432h4f7b81ecefaf292b@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116200333.GE15623@redhat.com> <64b14b300801161219q355d93b0jb57f91f48615591a@mail.gmail.com> <20080116202554.GF15623@redhat.com> <64b14b300801161235i4a4ed432h4f7b81ecefaf292b@mail.gmail.com> Message-ID: <7f692fec0801161717x3b0d77b9n9cd4a2dd939c6398@mail.gmail.com> On Jan 16, 2008 3:35 PM, Valent Turkovic wrote: > Dan you are taking this the wrong way. Of course SElinux is great, of > course it prevents from 0day exploits, no body is challenging that. > But what was the real threat to average desktop users? Has anybody > made use of this 0day exploit threat? is there a linux virus in the > wild that spread like wildfire that took down all desktops that didn't > use SELinux? If a single Linux desktop goes down because of a 0day event, then we've already failed at making a secure desktop. By that point, it's too late. This is a failure, and we should do everything we can to make sure it *never* happens. -Yaakov From loupgaroublond at gmail.com Thu Jan 17 01:30:29 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 16 Jan 2008 20:30:29 -0500 Subject: Smolt and Kickstart (Was:SELinux removed from desktop cd spin?) Message-ID: <7f692fec0801161730x35d8d2dfubd2bb07d21871da9@mail.gmail.com> On Jan 16, 2008 6:07 PM, Olivier Galibert wrote: > You realize smolt misses most if not all kickstart or otherwise > automatic/semiautomatic installs, right? It does? How? If it's true, it's a bug we have to fix :) -Yaakov From jkeating at redhat.com Thu Jan 17 01:33:52 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 16 Jan 2008 20:33:52 -0500 Subject: Smolt and Kickstart (Was:SELinux removed from desktop cd spin?) In-Reply-To: <7f692fec0801161730x35d8d2dfubd2bb07d21871da9@mail.gmail.com> References: <7f692fec0801161730x35d8d2dfubd2bb07d21871da9@mail.gmail.com> Message-ID: <20080116203352.1513c980@redhat.com> On Wed, 16 Jan 2008 20:30:29 -0500 "Yaakov Nemoy" wrote: > It does? How? > > If it's true, it's a bug we have to fix :) A large number of kickstarts result in no firstboot being ran (or no gui for that matter), and as such, smolt is not ran. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kwade at redhat.com Thu Jan 17 02:16:22 2008 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Wed, 16 Jan 2008 18:16:22 -0800 Subject: Cast your vote for the Fedora 9 Codename! In-Reply-To: <20080116184835.1bddf0f3@zod.rchland.ibm.com> References: <20080116184835.1bddf0f3@zod.rchland.ibm.com> Message-ID: <1200536182.920.64.camel@calliope.phig.org> On Wed, 2008-01-16 at 18:48 -0600, Josh Boyer wrote: > We have several options for the Fedora 9 codename, and you get to help > decide which we use! Once again I am at a complete loss as to the meanings of the various choices. Did anyone compile a wiki page of what the routes to these are from Werewolf? BTW, I understand one route is through "syndrome". While 'Lycanthropy' is a syndrome/condition, 'Werewolf' is not. Thanks - Karsten -- Karsten Wade, Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Thu Jan 17 02:21:54 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 16 Jan 2008 17:21:54 -0900 Subject: Smolt and Kickstart (Was:SELinux removed from desktop cd spin?) In-Reply-To: <7f692fec0801161730x35d8d2dfubd2bb07d21871da9@mail.gmail.com> References: <7f692fec0801161730x35d8d2dfubd2bb07d21871da9@mail.gmail.com> Message-ID: <604aa7910801161821l738ecad2lb6e1fa523ae13e90@mail.gmail.com> On Jan 16, 2008 4:30 PM, Yaakov Nemoy wrote: > If it's true, it's a bug we have to fix :) How exactly do you fix the fact that some people choose to opt-out? I'm not even sure there is a problem here that needs fixing. Full coverage of smolt information isn't a reasonable goal. -jef From jkeating at redhat.com Thu Jan 17 02:27:12 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 16 Jan 2008 21:27:12 -0500 Subject: Cast your vote for the Fedora 9 Codename! In-Reply-To: <1200536182.920.64.camel@calliope.phig.org> References: <20080116184835.1bddf0f3@zod.rchland.ibm.com> <1200536182.920.64.camel@calliope.phig.org> Message-ID: <20080116212712.6446511e@redhat.com> On Wed, 16 Jan 2008 18:16:22 -0800 "Karsten 'quaid' Wade" wrote: > Once again I am at a complete loss as to the meanings of the various > choices. > > Did anyone compile a wiki page of what the routes to these are from > Werewolf? > > BTW, I understand one route is through "syndrome". While > 'Lycanthropy' is a syndrome/condition, 'Werewolf' is not. Half the fun is in guessing and investigating what the links are. Now that we're taking suggestions in the open public a lot of that fun is killed :/ -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at gmail.com Thu Jan 17 02:32:06 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 16 Jan 2008 20:32:06 -0600 Subject: Cast your vote for the Fedora 9 Codename! In-Reply-To: <1200536182.920.64.camel@calliope.phig.org> References: <20080116184835.1bddf0f3@zod.rchland.ibm.com> <1200536182.920.64.camel@calliope.phig.org> Message-ID: <20080116203206.32b5c37b@zod.rchland.ibm.com> On Wed, 16 Jan 2008 18:16:22 -0800 "Karsten 'quaid' Wade" wrote: > > On Wed, 2008-01-16 at 18:48 -0600, Josh Boyer wrote: > > We have several options for the Fedora 9 codename, and you get to help > > decide which we use! > > Once again I am at a complete loss as to the meanings of the various > choices. > > Did anyone compile a wiki page of what the routes to these are from > Werewolf? I have them all logged. They're also available in the list archives... Quite a few of them took the lame way and said "Mythical Creature!" josh From jwboyer at gmail.com Thu Jan 17 02:33:30 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 16 Jan 2008 20:33:30 -0600 Subject: Fedora 8/ARM available In-Reply-To: <20080114233331.GL17358@xi.wantstofly.org> References: <20080114233331.GL17358@xi.wantstofly.org> Message-ID: <20080116203330.787a06dc@zod.rchland.ibm.com> On Tue, 15 Jan 2008 00:33:31 +0100 Lennert Buytenhek wrote: > Hi all, > > We are proud to announce the availability of a(n unofficial) > Fedora 8 package repository for the ARM architecture. > > The package repository has been built for ARMv5 EABI, soft-float, > little endian. The majority of the important and frequently used > Fedora packages have been built for ARM. > > The Fedora/ARM architecture wiki page has more info: > http://fedoraproject.org/wiki/Architectures/ARM > > The easiest way to start using Fedora 8/ARM is to download the > prebuilt root filesystem, which can be booted in QEMU, or chroot'ed > into or booted from on any ARMv5 or later processor running in little > endian mode. Additional packages can be installed by using yum, > which is provided in the filesystem. > > A HOWTO which describes getting Fedora/ARM running in QEMU is here: > http://fedoraproject.org/wiki/Architectures/ARM/HowToQemu > > There currently are a handful of known issues, which are described at: > http://fedoraproject.org/wiki/Architectures/ARM/TODO > > Please help us by using the Fedora/ARM port and reporting any issues > you run into so that we can fix them. How long until you have instructions on installing Fedora on the n800/n810? :) josh From loupgaroublond at gmail.com Thu Jan 17 02:39:06 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 16 Jan 2008 21:39:06 -0500 Subject: Smolt and Kickstart (Was:SELinux removed from desktop cd spin?) In-Reply-To: <604aa7910801161821l738ecad2lb6e1fa523ae13e90@mail.gmail.com> References: <7f692fec0801161730x35d8d2dfubd2bb07d21871da9@mail.gmail.com> <604aa7910801161821l738ecad2lb6e1fa523ae13e90@mail.gmail.com> Message-ID: <7f692fec0801161839s272941b5i8db12c02b4626850@mail.gmail.com> On Jan 16, 2008 9:21 PM, Jeff Spaleta wrote: > On Jan 16, 2008 4:30 PM, Yaakov Nemoy wrote: > > If it's true, it's a bug we have to fix :) > > > How exactly do you fix the fact that some people choose to opt-out? > I'm not even sure there is a problem here that needs fixing. Full > coverage of smolt information isn't a reasonable goal. We don't. I'm just thinking this needs to be made into a kickstart feature so that people can opt in here as well. If kickstart can be used to supplement or replace firstboot options, shouldn't smolt be there too? -Yaakov From cjdahlin at ncsu.edu Thu Jan 17 03:15:53 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Wed, 16 Jan 2008 22:15:53 -0500 Subject: Smolt and Kickstart (Was:SELinux removed from desktop cd spin?) In-Reply-To: <7f692fec0801161839s272941b5i8db12c02b4626850@mail.gmail.com> References: <7f692fec0801161730x35d8d2dfubd2bb07d21871da9@mail.gmail.com> <604aa7910801161821l738ecad2lb6e1fa523ae13e90@mail.gmail.com> <7f692fec0801161839s272941b5i8db12c02b4626850@mail.gmail.com> Message-ID: <478EC869.4070100@ncsu.edu> Yaakov Nemoy wrote: > On Jan 16, 2008 9:21 PM, Jeff Spaleta wrote: > >> On Jan 16, 2008 4:30 PM, Yaakov Nemoy wrote: >> >>> If it's true, it's a bug we have to fix :) >>> >> How exactly do you fix the fact that some people choose to opt-out? >> I'm not even sure there is a problem here that needs fixing. Full >> coverage of smolt information isn't a reasonable goal. >> > > We don't. I'm just thinking this needs to be made into a kickstart > feature so that people can opt in here as well. > > If kickstart can be used to supplement or replace firstboot options, > shouldn't smolt be there too? > > -Yaakov > > You can opt in by running smoltSendProfile in your post-install script. We just need to advertise this. --CJD From myfedora at richip.dhs.org Thu Jan 17 03:36:22 2008 From: myfedora at richip.dhs.org (Richi Plana) Date: Wed, 16 Jan 2008 20:36:22 -0700 Subject: SELinux removed from desktop cd spin? In-Reply-To: <64b14b300801161235i4a4ed432h4f7b81ecefaf292b@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116200333.GE15623@redhat.com> <64b14b300801161219q355d93b0jb57f91f48615591a@mail.gmail.com> <20080116202554.GF15623@redhat.com> <64b14b300801161235i4a4ed432h4f7b81ecefaf292b@mail.gmail.com> Message-ID: <1200540982.15373.7.camel@localhost6.localdomain6> On Wed, 2008-01-16 at 21:35 +0100, Valent Turkovic wrote: > On Jan 16, 2008 9:25 PM, Daniel P. Berrange wrote: > > On Wed, Jan 16, 2008 at 09:19:38PM +0100, Valent Turkovic wrote: > > > On Jan 16, 2008 9:03 PM, Daniel P. Berrange wrote: > > > > On Wed, Jan 16, 2008 at 08:57:56PM +0100, Valent Turkovic wrote: > > > > > Hi, > > > > > I believe that SELinux is a great linux server security hardening tool > > > > > but that has little use in desktop linux usage and it confuses > > > > > ordinary desktop users. > > > > > > > > It is of great use in a desktop spin. On my 'desktop' install for my > > > > laptop I have many many system daemons running under a confined domain > > > > > > You, of course, will always have the ability to choose to install it > > > and use it. > > > > > > > > If it hasn't been discussed before I would like to propose that on > > > > > desktop cd spin SELinux is not installed by default, of course after > > > > > discussion and approval from you (fedora devels). > > > > > > > > No. SELinux provides very real & important protection for desktop users. > > > > > > Can you give me examples of this protection over fedora 9 without > > > SELInux or with SELinux in permissive mode? > > > > Yes. SELinux mitigated against the recent HPLIP security flaw which > > would have allowed arbitrary code execution as root. > > > > http://james-morris.livejournal.com/25140.html > > https://rhn.redhat.com/errata/RHSA-2007-0960.html > > > > There have been other similar scenarios where security flaws have been > > prevented, or their damage mitigated by presence of SELinux > > > > > > Dan. > > Dan you are taking this the wrong way. Of course SElinux is great, of > course it prevents from 0day exploits, no body is challenging that. > But what was the real threat to average desktop users? Has anybody > made use of this 0day exploit threat? is there a linux virus in the > wild that spread like wildfire that took down all desktops that didn't > use SELinux? > > It is a question of cost and benefit. I argue that SELinux makes much > more trouble that it saves people from real danger in desktop > enviroment. Ofcourse that you need it in corporate enviroment and if > you use Fedora as corporate desktop you should enable it - but don't > make it default for them - especially if most of the people using it > won't understand cryptic messages that it gives :( > > If fedora is used as testing ground for redhat corporate desktop then > I understand the decision to make it on by default but if you really > want average home desktop users to have a pleasant linux experience I > really see no point in SELinux. I actually agree with you that SELinux for the desktop user currently leaves a bad taste in users' mouths ... specially new users trying it out. You've mentioned problems with codecs (though I've not had the same problem myself even with SELinux enabled). I did run across problems with it initially with some printer drivers, NFS shares and a couple of first-person shooter games. That said, I do believe that it's something that has to be done now because it IS an important feature that has to be fixed for the common desktop user ASAP. Of course, I would only agree with it being adopted now even if it causes problems for users WITH THE UNDERSTANDING that the devs actually taking people's pain and fixing their problems. I've followed your travails with getting audio codecs to work from the beginning and I feel your pain. If I'm not mistaken, the problem lies now with Fluendo to come up with a fix for it. Again, I would go back to the premise that SELinux is alright so long as the time is being used to fix things for users. If things aren't getting fixed, then perhaps the situation should be re-evaluated. For the most part, however, Dan Walsh (?) and others have done an excellent job of shooting down SELinux bugs as they appear ... and most are problems for desktop users. -- Richi Plana From jam at zoidtechnologies.com Thu Jan 17 03:40:56 2008 From: jam at zoidtechnologies.com (jam at zoidtechnologies.com) Date: Wed, 16 Jan 2008 22:40:56 -0500 Subject: SELinux removed from desktop cd spin? In-Reply-To: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> Message-ID: <20080117034056.GG18982@zoidtechnologies.com> On Wed, Jan 16, 2008 at 08:57:56PM +0100, Valent Turkovic wrote: > Hi, > I believe that SELinux is a great linux server security hardening tool > but that has little use in desktop linux usage and it confuses > ordinary desktop users. > If it hasn't been discussed before I would like to propose that on > desktop cd spin SELinux is not installed by default, of course after > discussion and approval from you (fedora devels). > > > Cheers, > Valent > -1 selinux should most definately *remain* in the desktop spin and *all* of the fedora spins because it drastically increases the security of the box in question. hopefully all the replies to this thread agree with me. regards --jonez -- http://zoidtechnologies.com/ -- websites that suck less From loganjerry at gmail.com Thu Jan 17 04:16:40 2008 From: loganjerry at gmail.com (Jerry James) Date: Wed, 16 Jan 2008 21:16:40 -0700 Subject: What component is this? Message-ID: <870180fe0801162016l5c7ba5bt470864bfcbc847fe@mail.gmail.com> In spite of the thread complaining about SELinux, I've actually had no problems with it in F8. Before today, I only had 2 alerts, and they were both due to needing to relabel, which I did a few days ago. (I had big problems with SELinux on FC-6, which is why I initially set it to permissive. I need to change to enforcing.) Tonight I logged in, walked off to do some kid-tucking-into-bed, and came back to find this: Source Context: unconfined_u:system_r:unconfined_t:SystemLow-SystemHigh Target Context: unconfined_u:system_r:unconfined_t:SystemLow-SystemHigh Target Objects: None [ process ] Affected RPM Packages: Policy RPM: selinux-policy-3.0.8-73.fc8 Selinux Enabled: True Policy Type: targeted MLS Enabled: True Enforcing Mode: Permissive Plugin Name: plugins.allow_execheap Host Name: localhost.localdomain Platform: Linux localhost.localdomain 2.6.23.9-85.fc8 #1 SMP Fri Dec 7 15:49:59 EST 2007 i686 i686 Alert Count: 1 First Seen: Wed 16 Jan 2008 08:42:07 PM MST Last Seen: Wed 16 Jan 2008 08:42:07 PM MST Local ID: 264c0f89-91de-43d3-a095-50d6636c25d0 Line Numbers: Raw Audit Messages : avc: denied { execheap } for comm=gnome-settings- pid=2851 scontext=unconfined_u:system_r:unconfined_t:s0-s0:c0.c1023 tclass=process tcontext=unconfined_u:system_r:unconfined_t:s0-s0:c0.c1023 PID 2851 didn't exist by the time I was able to check for it. I didn't find anything relevant in bugzilla. A little poking around on my system failed to turn up anything called gnome-settings-. I'd file a bug, but I have no idea what component this is. Anybody know? -- Jerry James http://loganjerry.googlepages.com/ From dmc.fedora at filteredperception.org Thu Jan 17 04:35:07 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Wed, 16 Jan 2008 22:35:07 -0600 Subject: SELinux removed from desktop cd spin? In-Reply-To: <20080117034056.GG18982@zoidtechnologies.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080117034056.GG18982@zoidtechnologies.com> Message-ID: <478EDAFB.7090506@filteredperception.org> jam at zoidtechnologies.com wrote: > On Wed, Jan 16, 2008 at 08:57:56PM +0100, Valent Turkovic wrote: >> Hi, >> I believe that SELinux is a great linux server security hardening tool >> but that has little use in desktop linux usage and it confuses >> ordinary desktop users. >> If it hasn't been discussed before I would like to propose that on >> desktop cd spin SELinux is not installed by default, of course after >> discussion and approval from you (fedora devels). >> >> >> Cheers, >> Valent >> > > -1 > > selinux should most definately *remain* in the desktop spin and *all* of the > fedora spins because it drastically increases the security of the box in > question. > > hopefully all the replies to this thread agree with me. I wish I could say that I'm sorry to crush your hopes, but I'm really not. Despite what I've said in the past, I have the utmost respect for selinux and security. But what I don't have any respect for is people of your mind, who myopically just see "increased security". People who view security that way IMO contribute to some of the worst cancers against humanity. This is just standard rhetoric that I shouldn't be wasting my time repeating here, but security is ALWAYS a balance and a tradeoff against other *values*, and never an absolute. When selinux is the right tool for the job, bringing a greater benefit to the system at hand than the costs involved with using it, then great. But to claim that it should remain in "*all* of the fedora spins" is IMO utterly wrong, and a narrow vision of what fedora could be useful for. There are times and applications where selinux is JUST NOT WORTH IT. I'm not saying it's the majority of the time, or even >1%. But if fedora is (to be) used in tens of millions of systems, 1% of that is actually a *significant* number. If only I could waterboard the fuck out of all the loyal bushies that see "national security" as the *only* value to be measured when making a decision. There are times when you let innocent people die and get hurt by terrorists, because the values sacrificed in making a decision that could and does stop the terrorists, are MORE IMPORTANT than a narrow short term view of "national security". I sincerely hope that what I've said will cause you to think a little more before uttering "I hope everyone agrees with me that more security is always better" again. But I welcome you to crush my hopes as I've just crushed yours. -dmc From pemboa at gmail.com Thu Jan 17 04:55:46 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 16 Jan 2008 22:55:46 -0600 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478EDAFB.7090506@filteredperception.org> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080117034056.GG18982@zoidtechnologies.com> <478EDAFB.7090506@filteredperception.org> Message-ID: <16de708d0801162055q5dca70e1yf24e9d2faf6567ca@mail.gmail.com> So have those proposing the remove of SELinux come to the conclusion that the average Fedora user is too stupid to click (2,3 clicks?) SELinux to disabled and be done with it? Maybe even on firstboot? -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From jam at zoidtechnologies.com Thu Jan 17 05:04:22 2008 From: jam at zoidtechnologies.com (jam at zoidtechnologies.com) Date: Thu, 17 Jan 2008 00:04:22 -0500 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478EDAFB.7090506@filteredperception.org> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080117034056.GG18982@zoidtechnologies.com> <478EDAFB.7090506@filteredperception.org> Message-ID: <20080117050421.GH18982@zoidtechnologies.com> On Wed, Jan 16, 2008 at 10:35:07PM -0600, Douglas McClendon wrote: > [...snipped mindless drivel with no relevance...] > I sincerely hope that what I've said will cause you to think a little > more before uttering "I hope everyone agrees with me that more security > is always better" again. But I welcome you to crush my hopes as I've > just crushed yours. > > nah.. too easy. but thanks for playing! > -dmc > -jam -- http://zoidtechnologies.com/ -- websites that suck less From seg at haxxed.com Thu Jan 17 05:10:02 2008 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 16 Jan 2008 23:10:02 -0600 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478EDAFB.7090506@filteredperception.org> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080117034056.GG18982@zoidtechnologies.com> <478EDAFB.7090506@filteredperception.org> Message-ID: <1200546602.15354.8.camel@localhost> On Wed, 2008-01-16 at 22:35 -0600, Douglas McClendon wrote: > There are times when you let innocent people die and get hurt by > terrorists, because the values sacrificed in making a decision that > could and does stop the terrorists, are MORE IMPORTANT than a narrow > short term view of "national security". In before Hitler. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From loupgaroublond at gmail.com Thu Jan 17 05:21:13 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 17 Jan 2008 00:21:13 -0500 Subject: Smolt and Kickstart (Was:SELinux removed from desktop cd spin?) In-Reply-To: <478EC869.4070100@ncsu.edu> References: <7f692fec0801161730x35d8d2dfubd2bb07d21871da9@mail.gmail.com> <604aa7910801161821l738ecad2lb6e1fa523ae13e90@mail.gmail.com> <7f692fec0801161839s272941b5i8db12c02b4626850@mail.gmail.com> <478EC869.4070100@ncsu.edu> Message-ID: <7f692fec0801162121m4e3f0b1bwf312dc66e6c15c35@mail.gmail.com> On Jan 16, 2008 10:15 PM, Casey Dahlin wrote: > You can opt in by running smoltSendProfile in your post-install script. > We just need to advertise this. That doesn't actually set up the monthly submissions. Furthermore, we're going to start filtering by submission date. Anything older than 35 days is going to be considered 'not running'. The solution is to add a hook into kickstart that handles all the other firstboot options, that also handles smolt. -Yaakov From loupgaroublond at gmail.com Thu Jan 17 05:34:35 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 17 Jan 2008 00:34:35 -0500 Subject: Icons status for smolts.org In-Reply-To: <478C39BA.2030801@thefinalzone.com> References: <478C39BA.2030801@thefinalzone.com> Message-ID: <7f692fec0801162134n532b2180lceddedbb8d5234d9@mail.gmail.com> On Jan 14, 2008 11:42 PM, Luya Tshimbalanga wrote: > Hi Mike, > > I read the wiki about icons status for smolts.org. You can use icons > from echo-icon-theme[1] under Actions menu and I have linked them on > DesignService wiki page[2]. > > Luya > > References: > [1]https://fedorahosted.org/echo-icon-theme/wiki/IconThemeStatus > [2]http://fedoraproject.org/wiki/Artwork/DesignService We need a bit more art. I've left comments on the wiki. thanks again! Yaakov From lordmorgul at gmail.com Thu Jan 17 05:48:06 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 16 Jan 2008 21:48:06 -0800 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478EDAFB.7090506@filteredperception.org> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080117034056.GG18982@zoidtechnologies.com> <478EDAFB.7090506@filteredperception.org> Message-ID: <478EEC16.9010902@gmail.com> Douglas McClendon wrote: > > > I wish I could say that I'm sorry to crush your hopes, but I'm really > not. Despite what I've said in the past, I have the utmost respect for > selinux and security. But what I don't have any respect for is people > of your mind, who myopically just see "increased security". People who > view security that way IMO contribute to some of the worst cancers > against humanity. > > This is just standard rhetoric that I shouldn't be wasting my time > repeating here, but security is ALWAYS a balance and a tradeoff against > other *values*, and never an absolute. Sounds like politically charged nonsense, not rhetoric related to computer security. > When selinux is the right tool for the job, bringing a greater benefit > to the system at hand than the costs involved with using it, then great. > But to claim that it should remain in "*all* of the fedora spins" is > IMO utterly wrong, and a narrow vision of what fedora could be useful > for. There are times and applications where selinux is JUST NOT WORTH > IT. I'm not saying it's the majority of the time, or even >1%. But if > fedora is (to be) used in tens of millions of systems, 1% of that is > actually a *significant* number. > > If only I could waterboard the fuck out of all the loyal bushies that > see "national security" as the *only* value to be measured when making a > decision. Humanity and liberty are so important to you that you want to torture people (and evidently not to gather information because you know it already). Clearly we're learning something here. > There are times when you let innocent people die and get hurt by > terrorists, because the values sacrificed in making a decision that > could and does stop the terrorists, are MORE IMPORTANT than a narrow > short term view of "national security". "Essential Liberty vs. Temporary Freedom". Yes, liberty is important, but largely unrelated to whether you have selinux present in your favorite spin. SELinux *should* be in every official Fedora spin, especially those to be used on networked computer systems. But it should also be possible to turn it off and/or uninstall it, and be possible to build custom packages for embedded processing applications without it... but if I want an embedded linux with selinux enabled why shouldn't it be there available? Choice (somehow related to Liberty in your rant) does not mean you get to choose what is present all the time, it means you get to choose whether to use it or not. The presence of selinux does not infringe on your 'choice'. The preference of one person to have it in all spins does not infringe on your 'choice'. More importantly, the desire of some to improve computer security around the globe does not prevent you from running open boxes with blank root passwords... the choice is yours how insecure you want it. > I sincerely hope that what I've said will cause you to think a little > more before uttering "I hope everyone agrees with me that more security > is always better" again. But I welcome you to crush my hopes as I've > just crushed yours. SELinux can and very likely will protect computer systems for terrorist's use just as easily as anyone else, since it is 1) free, 2) available to the entire known universe; it therefore has nothing whatsoever to do with US national security in the context of your 'rhetoric' and poorly argued politics. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From mmcgrath at redhat.com Thu Jan 17 05:55:56 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 16 Jan 2008 23:55:56 -0600 (CST) Subject: Smolt and Kickstart (Was:SELinux removed from desktop cd spin?) In-Reply-To: <478EC869.4070100@ncsu.edu> References: <7f692fec0801161730x35d8d2dfubd2bb07d21871da9@mail.gmail.com> <604aa7910801161821l738ecad2lb6e1fa523ae13e90@mail.gmail.com> <7f692fec0801161839s272941b5i8db12c02b4626850@mail.gmail.com> <478EC869.4070100@ncsu.edu> Message-ID: On Wed, 16 Jan 2008, Casey Dahlin wrote: > Yaakov Nemoy wrote: > > On Jan 16, 2008 9:21 PM, Jeff Spaleta wrote: > > > > > On Jan 16, 2008 4:30 PM, Yaakov Nemoy wrote: > > > > > > > If it's true, it's a bug we have to fix :) > > > > > > > How exactly do you fix the fact that some people choose to opt-out? > > > I'm not even sure there is a problem here that needs fixing. Full > > > coverage of smolt information isn't a reasonable goal. > > > > > > > We don't. I'm just thinking this needs to be made into a kickstart > > feature so that people can opt in here as well. > > > > If kickstart can be used to supplement or replace firstboot options, > > shouldn't smolt be there too? > > > > -Yaakov > > > > > You can opt in by running smoltSendProfile in your post-install script. We > just need to advertise this. We could do a better job with smolt education / advertisement. -Mike From lordmorgul at gmail.com Thu Jan 17 05:57:10 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 16 Jan 2008 21:57:10 -0800 Subject: Smolt and Kickstart (Was:SELinux removed from desktop cd spin?) In-Reply-To: <7f692fec0801162121m4e3f0b1bwf312dc66e6c15c35@mail.gmail.com> References: <7f692fec0801161730x35d8d2dfubd2bb07d21871da9@mail.gmail.com> <604aa7910801161821l738ecad2lb6e1fa523ae13e90@mail.gmail.com> <7f692fec0801161839s272941b5i8db12c02b4626850@mail.gmail.com> <478EC869.4070100@ncsu.edu> <7f692fec0801162121m4e3f0b1bwf312dc66e6c15c35@mail.gmail.com> Message-ID: <478EEE36.4040600@gmail.com> Yaakov Nemoy wrote: > On Jan 16, 2008 10:15 PM, Casey Dahlin wrote: >> You can opt in by running smoltSendProfile in your post-install script. >> We just need to advertise this. > > That doesn't actually set up the monthly submissions. Furthermore, > we're going to start filtering by submission date. Anything older > than 35 days is going to be considered 'not running'. Hopefully 'not running' is nothing more than another flag here... not to be confused with 'removed from the database'? If that is going to be more than a filter, something longer than 35 days would probably be better. > The solution is to add a hook into kickstart that handles all the > other firstboot options, that also handles smolt. > > -Yaakov > -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From dmc.fedora at filteredperception.org Thu Jan 17 06:14:02 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Thu, 17 Jan 2008 00:14:02 -0600 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478EEC16.9010902@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080117034056.GG18982@zoidtechnologies.com> <478EDAFB.7090506@filteredperception.org> <478EEC16.9010902@gmail.com> Message-ID: <478EF22A.2090406@filteredperception.org> Andrew Farris wrote: > Douglas McClendon wrote: >> >> >> I wish I could say that I'm sorry to crush your hopes, but I'm really >> not. Despite what I've said in the past, I have the utmost respect >> for selinux and security. But what I don't have any respect for is >> people of your mind, who myopically just see "increased security". >> People who view security that way IMO contribute to some of the worst >> cancers against humanity. >> >> This is just standard rhetoric that I shouldn't be wasting my time >> repeating here, but security is ALWAYS a balance and a tradeoff >> against other *values*, and never an absolute. > > Sounds like politically charged nonsense, not rhetoric related to > computer security. > >> When selinux is the right tool for the job, bringing a greater benefit >> to the system at hand than the costs involved with using it, then >> great. But to claim that it should remain in "*all* of the fedora >> spins" is IMO utterly wrong, and a narrow vision of what fedora could >> be useful for. There are times and applications where selinux is JUST >> NOT WORTH IT. I'm not saying it's the majority of the time, or even >> >1%. But if fedora is (to be) used in tens of millions of systems, 1% >> of that is actually a *significant* number. >> >> If only I could waterboard the fuck out of all the loyal bushies that >> see "national security" as the *only* value to be measured when making >> a decision. > > Humanity and liberty are so important to you that you want to torture > people (and evidently not to gather information because you know it > already). Clearly we're learning something here. > >> There are times when you let innocent people die and get hurt by >> terrorists, because the values sacrificed in making a decision that >> could and does stop the terrorists, are MORE IMPORTANT than a narrow >> short term view of "national security". > > "Essential Liberty vs. Temporary Freedom". Yes, liberty is important, > but largely unrelated to whether you have selinux present in your > favorite spin. > > SELinux *should* be in every official Fedora spin, especially those to > be used on networked computer systems. But it should also be possible > to turn it off and/or uninstall it, and be possible to build custom > packages for embedded processing applications without it... but if I > want an embedded linux with selinux enabled why shouldn't it be there > available? Since I love politically charged discussions- What you just said is similar to the logical difference between a) not mandating that evolution to be taught as a theory in schools vs b) mandating that evolution not be taught as a theory in schools. I.e., I whole heartedly agree with you that if you want an embedded linux with selinux enabled, it SHOULD be available. But my holding that opinion does not change the fact that I also hold the opinion that at some point down the road, there should be an official fedora spin that comes with selinux disabled. Clearly since I work on livecd-tools and the like, I am all for making it as easy as possible to create variants. But really, since I know how easy it is to just spin a distro of linux wiht 99.9999% the same code base as fedora, that just isn't called fedora, I don't *REALLY* care about this technical issue very much, and I *REALLY* was just doing some soapboxing. But I think the political and technical points I made (computer security, national security) are not so disjoint that it is useless to speak of them in the same breath. > > Choice (somehow related to Liberty in your rant) does not mean you get > to choose what is present all the time, it means you get to choose > whether to use it or not. The presence of selinux does not infringe on > your 'choice'. The preference of one person to have it in all spins > does not infringe on your 'choice'. More importantly, the desire of > some to improve computer security around the globe does not prevent you > from running open boxes with blank root passwords... the choice is yours > how insecure you want it. I agree with every bit of that. Not sure what you thought I meant that was different. > >> I sincerely hope that what I've said will cause you to think a little >> more before uttering "I hope everyone agrees with me that more >> security is always better" again. But I welcome you to crush my hopes >> as I've just crushed yours. > > SELinux can and very likely will protect computer systems for > terrorist's use just as easily as anyone else, since it is 1) free, 2) > available to the entire known universe; it therefore has nothing > whatsoever to do with US national security in the context of your > 'rhetoric' and poorly argued politics. I was really talking about whether the choice to use torture to improve national security, without considering the other values lost in the decision, was a wise one to make. The parallel was whether or not the choice to *ALWAYS* use selinux to improve computer security, without considering the other values (bloat/performance degradation/user frustration), was not a wise one to make. But sometimes the subtlety of my logic goes over people's heads. -dmc From kwade at redhat.com Thu Jan 17 06:44:36 2008 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Wed, 16 Jan 2008 22:44:36 -0800 Subject: Cast your vote for the Fedora 9 Codename! In-Reply-To: <20080116203206.32b5c37b@zod.rchland.ibm.com> References: <20080116184835.1bddf0f3@zod.rchland.ibm.com> <1200536182.920.64.camel@calliope.phig.org> <20080116203206.32b5c37b@zod.rchland.ibm.com> Message-ID: <1200552276.920.91.camel@calliope.phig.org> On Wed, 2008-01-16 at 20:32 -0600, Josh Boyer wrote: > I have them all logged. They're also available in the list archives... > > Quite a few of them took the lame way and said "Mythical Creature!" ... and ... On Wed, 2008-01-16 at 21:27 -0500, Jesse Keating wrote: > Half the fun is in guessing and investigating what the links are. Now > that we're taking suggestions in the open public a lot of that fun is > killed :/ Ok, yes, in the old days it was all about surprises and deciphering hidden messages in the bottle. But now here we are in the bright and shiny future, and I'd love to make a reasonable vote based on the intended back story/connection without a ton of research and de-confounding. Would it make sense now to compile the various back stories in one location? I guess if you've got them logged I can do the wiki scut work. I don't relish parsing the archives since I've done that for previous votes and I am resisting the time sink. Thanks - Karsten -- Karsten Wade, Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dmc.fedora at filteredperception.org Thu Jan 17 06:43:42 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Thu, 17 Jan 2008 00:43:42 -0600 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478EEC16.9010902@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080117034056.GG18982@zoidtechnologies.com> <478EDAFB.7090506@filteredperception.org> <478EEC16.9010902@gmail.com> Message-ID: <478EF91E.1040803@filteredperception.org> Andrew Farris wrote: > Douglas McClendon wrote: >> >> >> I wish I could say that I'm sorry to crush your hopes, but I'm really >> not. Despite what I've said in the past, I have the utmost respect >> for selinux and security. But what I don't have any respect for is >> people of your mind, who myopically just see "increased security". >> People who view security that way IMO contribute to some of the worst >> cancers against humanity. >> >> This is just standard rhetoric that I shouldn't be wasting my time >> repeating here, but security is ALWAYS a balance and a tradeoff >> against other *values*, and never an absolute. > > Sounds like politically charged nonsense, not rhetoric related to > computer security. Guess you're no fan Bruce - http://www.news.com/2010-7348-5204924.html " But that's only half of the equation; it's just as important to discuss the costs. Security is always a trade-off, and herein lies the real question: "Is this security countermeasure worth it?" As Americans, and as citizens of the world, we need to think of ourselves as security consumers. Just as a smart consumer looks for the best value for his dollar, we need to do the same. Many of the countermeasures being proposed and implemented cost billions. Others cost in other ways: convenience, privacy, civil liberties, fundamental freedoms, greater danger of other threats. As consumers, we need to get the most security we can for what we spend. " From lordmorgul at gmail.com Thu Jan 17 06:53:49 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 16 Jan 2008 22:53:49 -0800 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478EF22A.2090406@filteredperception.org> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080117034056.GG18982@zoidtechnologies.com> <478EDAFB.7090506@filteredperception.org> <478EEC16.9010902@gmail.com> <478EF22A.2090406@filteredperception.org> Message-ID: <478EFB7D.1060508@gmail.com> Douglas McClendon wrote: > Andrew Farris wrote: >> Douglas McClendon wrote: >>> I sincerely hope that what I've said will cause you to think a little >>> more before uttering "I hope everyone agrees with me that more >>> security is always better" again. But I welcome you to crush my >>> hopes as I've just crushed yours. >> >> SELinux can and very likely will protect computer systems for >> terrorist's use just as easily as anyone else, since it is 1) free, 2) >> available to the entire known universe; it therefore has nothing >> whatsoever to do with US national security in the context of your >> 'rhetoric' and poorly argued politics. > > I was really talking about whether the choice to use torture to improve > national security, without considering the other values lost in the > decision, was a wise one to make. > > The parallel was whether or not the choice to *ALWAYS* use selinux to > improve computer security, without considering the other values > (bloat/performance degradation/user frustration), was not a wise one to > make. > > But sometimes the subtlety of my logic goes over people's heads. Oh I followed your intention, I just disagree with whether that parallel is a fair or even logical one to make about whether selinux is *in* the official spins as opposed to *forcing* people to enable it, which is the difference between effecting your choice or not. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From lordmorgul at gmail.com Thu Jan 17 06:57:36 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 16 Jan 2008 22:57:36 -0800 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478EF91E.1040803@filteredperception.org> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080117034056.GG18982@zoidtechnologies.com> <478EDAFB.7090506@filteredperception.org> <478EEC16.9010902@gmail.com> <478EF91E.1040803@filteredperception.org> Message-ID: <478EFC60.1020002@gmail.com> Douglas McClendon wrote: > Andrew Farris wrote: >> Douglas McClendon wrote: >>> >>> >>> I wish I could say that I'm sorry to crush your hopes, but I'm really >>> not. Despite what I've said in the past, I have the utmost respect >>> for selinux and security. But what I don't have any respect for is >>> people of your mind, who myopically just see "increased security". >>> People who view security that way IMO contribute to some of the worst >>> cancers against humanity. >>> >>> This is just standard rhetoric that I shouldn't be wasting my time >>> repeating here, but security is ALWAYS a balance and a tradeoff >>> against other *values*, and never an absolute. >> >> Sounds like politically charged nonsense, not rhetoric related to >> computer security. > > Guess you're no fan Bruce - > > http://www.news.com/2010-7348-5204924.html > > " > But that's only half of the equation; it's just as important to discuss > the costs. Security is always a trade-off, and herein lies the real > question: "Is this security countermeasure worth it?" I was never debating this concept of cost-benefit tradeoff. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From valent.turkovic at gmail.com Thu Jan 17 07:00:27 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 17 Jan 2008 08:00:27 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478E7BE3.3060901@filteredperception.org> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <478E7BE3.3060901@filteredperception.org> Message-ID: <64b14b300801162300m1a9bc57q565583178fd264ff@mail.gmail.com> On Jan 16, 2008 10:49 PM, Douglas McClendon wrote: > Valent Turkovic wrote: > > Hi, > > I believe that SELinux is a great linux server security hardening tool > > but that has little use in desktop linux usage and it confuses > > ordinary desktop users. > > If it hasn't been discussed before I would like to propose that on > > desktop cd spin SELinux is not installed by default, of course after > > discussion and approval from you (fedora devels). > > > But don't you see- this isn't a real issue- > > BECAUSE LINUX IS ABOUT CHOICE ;) > > How hard is this? -> > > yum -y install livecd-tools > > sed -i -e 's/selinux\ --enforcing/selinux\ --disabled/' \ > /usr/share/livecd-tools/livecd-fedora-8-base-desktop.ks > > livecd-creator \ > --config=/usr/share/livecd-tools/livecd-fedora-8-desktop.ks > > Cheers, > > -dmc > > > P.S. - yes, it's a bit trickier to extract the 100MB or so of selinux > support packages so that you can actually fit more of the software you > are interested in on the constrained 700MB livecd, but I'll leave that > as an excercise for the reader. > What 100mb? That is even a better reason to dump SELinux out of Desktip spin and give users in those 100MB apps that they actually need on their desktops. Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From dmc.fedora at filteredperception.org Thu Jan 17 06:58:20 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Thu, 17 Jan 2008 00:58:20 -0600 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478EFB7D.1060508@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080117034056.GG18982@zoidtechnologies.com> <478EDAFB.7090506@filteredperception.org> <478EEC16.9010902@gmail.com> <478EF22A.2090406@filteredperception.org> <478EFB7D.1060508@gmail.com> Message-ID: <478EFC8C.7060208@filteredperception.org> Andrew Farris wrote: > Douglas McClendon wrote: >> Andrew Farris wrote: >>> Douglas McClendon wrote: >>>> I sincerely hope that what I've said will cause you to think a >>>> little more before uttering "I hope everyone agrees with me that >>>> more security is always better" again. But I welcome you to crush >>>> my hopes as I've just crushed yours. >>> >>> SELinux can and very likely will protect computer systems for >>> terrorist's use just as easily as anyone else, since it is 1) free, >>> 2) available to the entire known universe; it therefore has nothing >>> whatsoever to do with US national security in the context of your >>> 'rhetoric' and poorly argued politics. >> >> I was really talking about whether the choice to use torture to >> improve national security, without considering the other values lost >> in the decision, was a wise one to make. >> >> The parallel was whether or not the choice to *ALWAYS* use selinux to >> improve computer security, without considering the other values >> (bloat/performance degradation/user frustration), was not a wise one >> to make. >> >> But sometimes the subtlety of my logic goes over people's heads. > > Oh I followed your intention, I just disagree with whether that parallel > is a fair or even logical one to make about whether selinux is *in* the > official spins as opposed to *forcing* people to enable it, which is the > difference between effecting your choice or not. No, please reread what I said. It was never about the choice to force people to enable it. It was about the decision to mandate that *every* official fedora spin had it enabled by default. I contend that that there is room for enough official spins, such that >0 will have selinux not enabled by default. The target of the rant was advocating that exactly 0 official fedora spins have selinux not enabled be default. -dmc From valent.turkovic at gmail.com Thu Jan 17 07:04:35 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 17 Jan 2008 08:04:35 +0100 Subject: Fedora Enhancement!! In-Reply-To: <200801151346.45228.singularitaet@gmx.net> References: <1200399722.14798.9.camel@localhost.localdomain> <200801151346.45228.singularitaet@gmx.net> Message-ID: <478EFE03.7000708@gmail.com> Stefan Grosse wrote: > On Tuesday 15 January 2008 01:22:02 pm Salloum EL DAHDAAH wrote: > SE> Driver Issues: > SE> 1- VGA: > SE> ATI > SE> NVIDIA > SE> 3D Support especially with the new series. > > There is a licence issue thats why fedora does not include the "official" > driver. But where is the problem to use the livna repository which includes > non-free stuff!: > > http://rpm.livna.org > > > SE> 2- WEBCAM: > SE> Sony built in camera VCC 6 > > I don't know whether this is supported by the uvc driver. If I remember > correctly in future linux kernels uvc might be included. > > Stefan Why isn't fedora packaging uvc webcam drivers? On ubuntu my webcams work (uvc driver) but under fedora they don't :( uvc driver should have gone into main kernel but they prologued that for unknown amount of time. Valent. From valent.turkovic at gmail.com Thu Jan 17 07:06:15 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 17 Jan 2008 08:06:15 +0100 Subject: Fedora Enhancement!! In-Reply-To: <1200399722.14798.9.camel@localhost.localdomain> References: <1200399722.14798.9.camel@localhost.localdomain> Message-ID: <478EFE67.4050704@gmail.com> Salloum EL DAHDAAH wrote: > Hello, > > > I am currently using fedora 8 i was a windows users and vb.net > developer, i currently switched to fedora 8 for having a stable os > running on my machine but i would like to post some ideas for fedora > development team: > > Driver Issues: > 1- VGA: > ATI > NVIDIA > 3D Support especially with the new series. > > 2- WEBCAM: > Sony built in camera VCC 6 > > 3- Pocket Pc: > Imate JAM > > the drivers are really a mess to find and to make them work and > sometimes it fails. > > I currently made 15 persons turn from windows to fedora due to its > performance i would like to have a solution for the following issues and > i would like to know if there is any version of fedora that can run on > pocket pcs like Imate and HTC. > > Thank you > > looking forward to fedora 8 @ least beta 1 :D > > If you are looking for a better out of the box experience and just need stuff to work try MintLinux 4.0. Fedora has legal restraints because uf US laws that prevent them from distributing some code - but distros like MintLinux don't so check that out. Valent From pemboa at gmail.com Thu Jan 17 07:09:06 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 17 Jan 2008 01:09:06 -0600 Subject: Fedora Enhancement!! In-Reply-To: <478EFE03.7000708@gmail.com> References: <1200399722.14798.9.camel@localhost.localdomain> <200801151346.45228.singularitaet@gmx.net> <478EFE03.7000708@gmail.com> Message-ID: <16de708d0801162309v5933c5c8if1c58ee49c40fd9@mail.gmail.com> On Jan 17, 2008 1:04 AM, Valent Turkovic wrote: > Why isn't fedora packaging uvc webcam drivers? On ubuntu my webcams work > (uvc driver) but under fedora they don't :( > uvc driver should have gone into main kernel but they prologued that for > unknown amount of time. Seems like you just answered your own question. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From trond.danielsen at gmail.com Thu Jan 17 07:12:19 2008 From: trond.danielsen at gmail.com (Trond Danielsen) Date: Thu, 17 Jan 2008 08:12:19 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478EEC16.9010902@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080117034056.GG18982@zoidtechnologies.com> <478EDAFB.7090506@filteredperception.org> <478EEC16.9010902@gmail.com> Message-ID: <409676c70801162312v7fcb8193g648f3245d6320143@mail.gmail.com> 2008/1/17, Andrew Farris : > SELinux *should* be in every official Fedora spin, especially those to be used > on networked computer systems. But it should also be possible to turn it off > and/or uninstall it, and be possible to build custom packages for embedded > processing applications without it... but if I want an embedded linux with > selinux enabled why shouldn't it be there available? I am sure that you are aware of this, but it is currently _very_ easy to disable SELinux during install. The problem is how to communicate clearly to the user when, why, and if SELinux should be disabled. Given the complexity of a system like SELinux, it is very difficult to explain to non-technical users what SELinux actually does. The current dialog in firstboot makes no attempt to explain this is a non-technical way, which makes it very hard for new users to decide whether or not this is something they want. Perhaps both the firewall and SELinux page should ask whether or not the user is aware of what these settings actually do before they are forced to make a choice? Personally I haven't had any trouble with SELinux as long as I stick to software that is part of Fedora, but the problem arises as soon as somebody tries to install proprietary (shivers) software such as Matlab. I am well aware of that supporting non-free software is not on Fedoras agenda, but this is a real-world example of where SELinux makes ordinary users unhappy. I try to convince my Matlab-using friends and colleges that numpy and scipy are superior alternatives, but it is hard save the world all by yourself. So what is my conclusion? Well, given how easy it is for the user to disable SELinux during install if he or she does not want to use it for one reason or another, I see no reason to disable it by default. SELinux is an important technology that protects the computer from threats both from the inside (buggy sw) and from the outside. If Fedora cannot provide policies for SELinux that work in a real-world environment, then that is a bug and should be fixed; problems do not go away by ignoring them. Regards, -- Trond Danielsen From luya_tfz at thefinalzone.com Thu Jan 17 07:14:52 2008 From: luya_tfz at thefinalzone.com (Luya Tshimbalanga) Date: Wed, 16 Jan 2008 23:14:52 -0800 Subject: Icons status for smolts.org In-Reply-To: <7f692fec0801162134n532b2180lceddedbb8d5234d9@mail.gmail.com> References: <478C39BA.2030801@thefinalzone.com> <7f692fec0801162134n532b2180lceddedbb8d5234d9@mail.gmail.com> Message-ID: <478F006C.1040301@thefinalzone.com> Yaakov Nemoy a ?crit : > We need a bit more art. I've left comments on the wiki. > > thanks again! > > Yaakov > Done. I have also included the modified dialog-cancel inside the tarball. Luya Reference: --------------- http://fedoraproject.org/wiki/Artwork/DesignService From valent.turkovic at gmail.com Thu Jan 17 07:15:59 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 17 Jan 2008 08:15:59 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116210016.GA10162@devserv.devel.redhat.com> <1200518035.5766.2.camel@localhost> <1200518850.3277.5.camel@localhost.localdomain> <64b14b300801161335o1f27cf76t3affe31e8aae02ab@mail.gmail.com> Message-ID: <478F00AF.2080206@gmail.com> James Morris wrote: > On Wed, 16 Jan 2008, Valent Turkovic wrote: > >> I really love SELinux and it is a great tool, and it helps a lot of >> admins who use it, but because it is still too rough for the general >> public it should not be forced onto them. >> >> What is your target audience with SELinux? > > The target audience is everyone. > > What we are trying to do is make a fundamental change to computer security > by taking decades of research and making it useful in the general case. > We are shipping MAC as a standard, enabled-by-default feature of a general > purpose OS. Welcome to the future, and thanks for being part of it. > > > - James "Welcome to the future." No thanks, I disable my SELinux and they use my fedora desktop comfortably. Somebody would argu that "Welcome to the future." would be more appropriate if fedora looked like future os. Don't get me wrong, I love using fedora. But to my mac and windows friends it looks like win98 :( Also not enabling 3d bling by default doesn't help (some like that feature much more that SELinux just because it makes thing pretty). Weclome to the social. Wow starts now. ect, etc... Those are just a nonsense quotes as yours. I understand security. I also understand desktop usability. I believe that SELinux it too raw for general purpose desktop. Give it a year or two to mature and maybe then. Valent From lordmorgul at gmail.com Thu Jan 17 07:16:05 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 16 Jan 2008 23:16:05 -0800 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478EFC8C.7060208@filteredperception.org> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080117034056.GG18982@zoidtechnologies.com> <478EDAFB.7090506@filteredperception.org> <478EEC16.9010902@gmail.com> <478EF22A.2090406@filteredperception.org> <478EFB7D.1060508@gmail.com> <478EFC8C.7060208@filteredperception.org> Message-ID: <478F00B5.60306@gmail.com> Douglas McClendon wrote: > Andrew Farris wrote: >> Oh I followed your intention, I just disagree with whether that >> parallel is a fair or even logical one to make about whether selinux >> is *in* the official spins as opposed to *forcing* people to enable >> it, which is the difference between effecting your choice or not. > > No, please reread what I said. > > It was never about the choice to force people to enable it. > > It was about the decision to mandate that *every* official fedora spin > had it enabled by default. > > I contend that that there is room for enough official spins, such that > >0 will have selinux not enabled by default. > > The target of the rant was advocating that exactly 0 official fedora > spins have selinux not enabled be default. The OP you replied to (jonez) did not mention enabling selinux, only having it. This may be a minor semantic difference, but I see no reason why the distribution should produce official spins without selinux *available*... I agree there is plenty of room for a spin in which it is not enabled by default (but I would not agree the main desktop spin is one of them). As you've already mentioned if its that important for someone to build a custom spin with no selinux bits on it at all, thats not exactly hard for them to do. But is there honestly a need for Fedora to host and build it? IMO No. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From valent.turkovic at gmail.com Thu Jan 17 07:19:43 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 17 Jan 2008 08:19:43 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <604aa7910801161400k2e3ea6d6r3706a721a9106aed@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116210016.GA10162@devserv.devel.redhat.com> <1200518035.5766.2.camel@localhost> <1200518850.3277.5.camel@localhost.localdomain> <64b14b300801161335o1f27cf76t3affe31e8aae02ab@mail.gmail.com> <604aa7910801161400k2e3ea6d6r3706a721a9106aed@mail.gmail.com> Message-ID: <478F018F.50009@gmail.com> Jeff Spaleta wrote: > On Jan 16, 2008 12:35 PM, Valent Turkovic wrote: >> What is your target audience with SELinux? > > Everyone who runs a computer that takes input from an external source, > whether that be floppies, or a network connection, or a bluetooth > keyboard. Security matters... it doesn't matter if you are a desktop > user or not... security matters. If we are doing a good enough job at > policy writing and management then we fix the policies. Will fedora include virus scanners? If not why? > You really need to go back and read every single blog post from Dan > Walsh concerning the new xguest policy he is working on. He's got > very clear and very real desktop usage cases in mind for it. Turning > selinux off wholesale on a desktop spin just because its not optimal > yet, is short-sighted. When it becomes usable for general use, by all means, enable it by default. There is no real threat to linux desktop users from any source and there has been zero viruses or explioits that had any significant impact on any linux desktop. I don't see that changing in next 5 years so why force desktop users now to have this rough edged products bother them all the time? Valent From valent.turkovic at gmail.com Thu Jan 17 07:22:23 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 17 Jan 2008 08:22:23 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <1200523744.15354.7.camel@localhost> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <16de708d0801161316v66d0d49ch2508c29cb25e4abd@mail.gmail.com> <64b14b300801161328u1bd44f7ajc0d1f2ef9a172513@mail.gmail.com> <1200523744.15354.7.camel@localhost> Message-ID: <478F022F.8080100@gmail.com> Callum Lerwick wrote: > On Wed, 2008-01-16 at 22:28 +0100, Valent Turkovic wrote: >> And I bet that more will choose ubuntu as a "friendlier" desktop if >> fedora forces people to use SELinux. > > Yes kids, Linux *is* about choice. Linux != Fedora. > > If you love Ubuntu so much, why don't you choose to marry it? > I don't love ubuntu, I like fedora and it is my desktop of choice. Why do people flip out when somebody mentions ubuntu? Ubuntu is much more desktop centric distro that fedora it and new people to linux know only about ubuntu. Have you thought about why? Valent. From pemboa at gmail.com Thu Jan 17 07:23:16 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 17 Jan 2008 01:23:16 -0600 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478F018F.50009@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116210016.GA10162@devserv.devel.redhat.com> <1200518035.5766.2.camel@localhost> <1200518850.3277.5.camel@localhost.localdomain> <64b14b300801161335o1f27cf76t3affe31e8aae02ab@mail.gmail.com> <604aa7910801161400k2e3ea6d6r3706a721a9106aed@mail.gmail.com> <478F018F.50009@gmail.com> Message-ID: <16de708d0801162323t6db1e974j4eca4aeb2af344f4@mail.gmail.com> On Jan 17, 2008 1:19 AM, Valent Turkovic wrote: > Jeff Spaleta wrote: > > On Jan 16, 2008 12:35 PM, Valent Turkovic wrote: > >> What is your target audience with SELinux? > > > > Everyone who runs a computer that takes input from an external source, > > whether that be floppies, or a network connection, or a bluetooth > > keyboard. Security matters... it doesn't matter if you are a desktop > > user or not... security matters. If we are doing a good enough job at > > policy writing and management then we fix the policies. > > Will fedora include virus scanners? If not why? > > > You really need to go back and read every single blog post from Dan > > Walsh concerning the new xguest policy he is working on. He's got > > very clear and very real desktop usage cases in mind for it. Turning > > selinux off wholesale on a desktop spin just because its not optimal > > yet, is short-sighted. > > When it becomes usable for general use, by all means, enable it by > default. There is no real threat to linux desktop users from any source > and there has been zero viruses or explioits that had any significant > impact on any linux desktop. I don't see that changing in next 5 years > so why force desktop users now to have this rough edged products bother > them all the time? > > Valent You have yet to explain why two clicks after install, or one click at first boot is too many. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From fedora at camperquake.de Thu Jan 17 07:23:46 2008 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 17 Jan 2008 08:23:46 +0100 Subject: rawhide report: 20080116 changes In-Reply-To: References: <200801161639.m0GGdexE021103@porkchop.devel.redhat.com> Message-ID: <20080117082346.6ead8eb0@dhcp03.addix.net> Hi On Wed, 16 Jan 2008 21:53:05 +0000 (UTC), Kevin Kofler wrote: > Huh? What's that doing in a Fedora package? It's plain data, isn't > it? One may argue that, being genome data, it's some kind of code. We just don't ship a compiler for it, yet ;) From braden at endoframe.com Thu Jan 17 07:26:31 2008 From: braden at endoframe.com (Braden McDaniel) Date: Thu, 17 Jan 2008 02:26:31 -0500 Subject: Whither libmozjs? Message-ID: <1200554791.8577.11.camel@hinge.endoframe.net> Where is libmozjs living these days? The Real Problem, though, is that for some reason xulrunner-js.pc seems not to be conveying this information. I am seeing the following failure: /bin/sh ../libtool --tag=CXX --mode=link g++ -pthread -I/usr/include/freetype2 -DXP_UNIX -DJS_THREADSAFE -I/usr/include/xulrunner-sdk-1.9pre/stable -I/usr/include/xulrunner-sdk-1.9pre/js -I/usr/include/nspr4 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -version-info 8:2:0 -ljpeg -lpng -lz -lfontconfig -lfreetype -L/usr/lib/xulrunner-sdk-1.9pre/lib -L/lib -lmozjs -lplds4 -lplc4 -lnspr4 -lpthread -ldl -o libopenvrml/libopenvrml.la -rpath /usr/lib libopenvrml/openvrml/libopenvrml_libopenvrml_la-vrml97_grammar.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-x3d_vrml_grammar.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-read_write_mutex.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-basetypes.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-field_value.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-event.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-exposedfield.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-scope.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-node.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-bounding_volume.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-script.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-ScriptJDK.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-browser.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-viewer.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-rendering_context.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-frustum.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-node_impl_util.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-vrml97node.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-x3d_core.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-x3d_networking.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-x3d_grouping.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-x3d_rendering.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-x3d_shape.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-x3d_geometry2d.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-x3d_texturing.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-x3d_interpolation.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-x3d_key_device_sensor.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-x3d_event_utilities.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-x3d_dis.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-x3d_environmental_effects.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-x3d_geospatial.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-x3d_hanim.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-x3d_nurbs.lo libopenvrml/openvrml/libopenvrml_libopenvrml_la-x3d_cad_geometry.lo -lboost_thread-mt mkdir libopenvrml/.libs g++ -shared -nostdlib /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../crti.o /usr/lib/gcc/i386-redhat-linux/4.1.2/crtbeginS.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-vrml97_grammar.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-x3d_vrml_grammar.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-read_write_mutex.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-basetypes.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-field_value.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-event.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-exposedfield.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-scope.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-node.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-bounding_volume.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-script.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-ScriptJDK.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-browser.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-viewer.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-rendering_context.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-frustum.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-node_impl_util.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-vrml97node.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-x3d_core.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-x3d_networking.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-x3d_grouping.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-x3d_rendering.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-x3d_shape.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-x3d_geometry2d.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-x3d_texturing.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-x3d_interpolation.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-x3d_key_device_sensor.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-x3d_event_utilities.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-x3d_dis.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-x3d_environmental_effects.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-x3d_geospatial.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-x3d_hanim.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-x3d_nurbs.o libopenvrml/openvrml/.libs/libopenvrml_libopenvrml_la-x3d_cad_geometry.o -ljpeg -lpng -lz -lfontconfig -lfreetype -L/usr/lib/xulrunner-sdk-1.9pre/lib -L/lib -lmozjs -lplds4 -lplc4 -lnspr4 -lpthread -ldl -lboost_thread-mt -L/usr/lib/gcc/i386-redhat-linux/4.1.2 -L/usr/lib/gcc/i386-redhat-linux/4.1.2/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/i386-redhat-linux/4.1.2/crtendS.o /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../crtn.o -pthread -m32 -march=i386 -mtune=generic -Wl,-soname -Wl,libopenvrml.so.8 -o libopenvrml/.libs/libopenvrml.so.8.0.2 /usr/bin/ld: cannot find -lmozjs I notice that "-L/usr/lib/xulrunner-sdk-1.9pre/lib" is being provided to libtool; is this as it should be? The full log is here: -- Braden McDaniel e-mail: Jabber: From valent.turkovic at gmail.com Thu Jan 17 07:26:57 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 17 Jan 2008 08:26:57 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478E8E48.6080003@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <16de708d0801161316v66d0d49ch2508c29cb25e4abd@mail.gmail.com> <64b14b300801161328u1bd44f7ajc0d1f2ef9a172513@mail.gmail.com> <478E8E48.6080003@gmail.com> Message-ID: <478F0341.9050509@gmail.com> Andrew Farris wrote: > Valent Turkovic wrote: > >> And I bet that more will choose ubuntu as a "friendlier" desktop if >> fedora forces people to use SELinux. > > Except noone is talking about forcing anyone to use selinux, just about > not 'suggesting' that they don't use it... which is exactly what turning > it off at install would be doing. > Sorry but you are forcing it if is enabled by default on install. How much users (not counting devels, admins and testers) of fedora know about SELinux and what it is? And what do people do when they install something - they probably leave all settings on default in hope that they don't "break" something with their wrong choices. Again I'm talking about desktop spin - I believe that it's target aren't devels and sysadmins but general public. Correct me if I'm wrong. Valent From lordmorgul at gmail.com Thu Jan 17 07:27:37 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 16 Jan 2008 23:27:37 -0800 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478F00AF.2080206@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116210016.GA10162@devserv.devel.redhat.com> <1200518035.5766.2.camel@localhost> <1200518850.3277.5.camel@localhost.localdomain> <64b14b300801161335o1f27cf76t3affe31e8aae02ab@mail.gmail.com> <478F00AF.2080206@gmail.com> Message-ID: <478F0369.8050602@gmail.com> Valent Turkovic wrote: > Those are just a nonsense quotes as yours. I understand security. I also > understand desktop usability. I believe that SELinux it too raw for > general purpose desktop. Give it a year or two to mature and maybe then. How is this 'maturing' process supposed to occur when the vast majority of general purpose users are not even trying it? The rawhide testers using it on a daily basis cannot possibly invoke all the possible combinations of operations that lead to selinux issues, and they don't have all the proprietary software to install and find out what happens. When a user tries it and runs into problems, they can turn it off. When a user never tries it, the problems stay hidden (and no thats not a better result). -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From tibbs at math.uh.edu Thu Jan 17 07:28:06 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 17 Jan 2008 01:28:06 -0600 Subject: rawhide report: 20080116 changes In-Reply-To: <20080117082346.6ead8eb0@dhcp03.addix.net> References: <200801161639.m0GGdexE021103@porkchop.devel.redhat.com> <20080117082346.6ead8eb0@dhcp03.addix.net> Message-ID: >>>>> "RE" == Ralf Ertzinger writes: RE> One may argue that, being genome data, it's some kind of code. We RE> just don't ship a compiler for it, yet ;) "Please place a blank disc in your DNA-RW drive." But of course I don't want nematodes writhing around within my computers. - J< From valent.turkovic at gmail.com Thu Jan 17 07:30:11 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 17 Jan 2008 08:30:11 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <16de708d0801161516w1144fc5fp7cb5f866bd33d84b@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <16de708d0801161316v66d0d49ch2508c29cb25e4abd@mail.gmail.com> <64b14b300801161328u1bd44f7ajc0d1f2ef9a172513@mail.gmail.com> <16de708d0801161516w1144fc5fp7cb5f866bd33d84b@mail.gmail.com> Message-ID: <478F0403.9050307@gmail.com> Arthur Pemberton wrote: > On Jan 16, 2008 3:28 PM, Valent Turkovic wrote: >> And I bet that more will choose ubuntu as a "friendlier" desktop if >> fedora forces people to use SELinux. > > Problem 1 : Any arguement based on Ubuntu is almost useless to me > Problem 2 : No one is forcing anyone to use SELinux, the only way to > make it easier to not use SELinux would be to have mind reading > software in Anaconda You maybe are technically true but I believe that until anaconda has default setting of "premisive" or "disabled" on SELinux you are not. We know that people leave default settings - especially to "security" things and cryptic things they don't understand like "SELinux". Valent From giallu at gmail.com Thu Jan 17 07:31:10 2008 From: giallu at gmail.com (Gianluca Sforna) Date: Thu, 17 Jan 2008 08:31:10 +0100 Subject: Fedora 8/ARM available In-Reply-To: <20080116203330.787a06dc@zod.rchland.ibm.com> References: <20080114233331.GL17358@xi.wantstofly.org> <20080116203330.787a06dc@zod.rchland.ibm.com> Message-ID: On Jan 17, 2008 3:33 AM, Josh Boyer wrote: > On Tue, 15 Jan 2008 00:33:31 +0100 > Lennert Buytenhek wrote: > > > > A HOWTO which describes getting Fedora/ARM running in QEMU is here: > > http://fedoraproject.org/wiki/Architectures/ARM/HowToQemu > > > > There currently are a handful of known issues, which are described at: > > http://fedoraproject.org/wiki/Architectures/ARM/TODO > > > > Please help us by using the Fedora/ARM port and reporting any issues > > you run into so that we can fix them. > > How long until you have instructions on installing Fedora on the > n800/n810? :) Don't forget about my Linksys NSLU2... From dmc.fedora at filteredperception.org Thu Jan 17 07:34:29 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Thu, 17 Jan 2008 01:34:29 -0600 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478F00B5.60306@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080117034056.GG18982@zoidtechnologies.com> <478EDAFB.7090506@filteredperception.org> <478EEC16.9010902@gmail.com> <478EF22A.2090406@filteredperception.org> <478EFB7D.1060508@gmail.com> <478EFC8C.7060208@filteredperception.org> <478F00B5.60306@gmail.com> Message-ID: <478F0505.4040103@filteredperception.org> Andrew Farris wrote: > Douglas McClendon wrote: >> Andrew Farris wrote: >>> Oh I followed your intention, I just disagree with whether that >>> parallel is a fair or even logical one to make about whether selinux >>> is *in* the official spins as opposed to *forcing* people to enable >>> it, which is the difference between effecting your choice or not. >> >> No, please reread what I said. >> >> It was never about the choice to force people to enable it. >> >> It was about the decision to mandate that *every* official fedora spin >> had it enabled by default. >> >> I contend that that there is room for enough official spins, such that >> >0 will have selinux not enabled by default. >> >> The target of the rant was advocating that exactly 0 official fedora >> spins have selinux not enabled be default. > > The OP you replied to (jonez) did not mention enabling selinux, only > having it. This may be a minor semantic difference, Yes, I agree that that minor semantic difference was not addressed in my rant or reply to your reply. But it doesn't really change the point I was trying to make, because I see this- selinux has benefits, and costs in disk space and performance, and usability. My logic is that because of this, I vehenemently disagree with the proposition that fedora have a policy of installing it by default (regardless of default enable/disable) on *every* official spin. It is clear, that the target of my rant was advocating *at least* that proposition (and perhaps the further that it be enabled by default). but I see no reason > why the distribution should produce official spins without selinux > *available*... neither do I. I agree there is plenty of room for a spin in which it is > not enabled by default (but I would not agree the main desktop spin is > one of them) neither would I (being charitable and taking the word that the rate of user annoyances will continue decreasing, and more desktop user benefits will be added) . As you've already mentioned if its that important for > someone to build a custom spin with no selinux bits on it at all, thats > not exactly hard for them to do. But is there honestly a need for > Fedora to host and build it? IMO No. Is there honestly a need for fedora to position policy to preclude such an event, should interest in such a project build? Again, the non-political aspect of this debate is basically one which I've sadly always been easily drawn into. I'm a 'never say never' kind of person. I think there may even be some mathematical 'black swan' philosophy related to it. I.e. just because you might not see a big need for a particular subset of the possible spins of fedora, does not mean that you should advocate that such spins not be permitted, or be precluded by policy. Or so my opinion goes. But really, that is a bunch of long winded technical justification for the fact that I presented a rant against current public policies that seem willing to sacrifice what I considered valuable ideals and culture, for the sake of national security. I guess I should just wake up and smell the post-9/11 world and get used to it, and not use every chance I find to speak up against what I perceive as a world where the US constitution is being metaphorically shat on. Que Sera Sera... -dmc From ssorce at redhat.com Thu Jan 17 07:38:21 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 17 Jan 2008 02:38:21 -0500 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478F0341.9050509@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <16de708d0801161316v66d0d49ch2508c29cb25e4abd@mail.gmail.com> <64b14b300801161328u1bd44f7ajc0d1f2ef9a172513@mail.gmail.com> <478E8E48.6080003@gmail.com> <478F0341.9050509@gmail.com> Message-ID: <1200555501.10767.47.camel@localhost.localdomain> On Thu, 2008-01-17 at 08:26 +0100, Valent Turkovic wrote: > Andrew Farris wrote: > > Valent Turkovic wrote: > > > >> And I bet that more will choose ubuntu as a "friendlier" desktop if > >> fedora forces people to use SELinux. > > > > Except noone is talking about forcing anyone to use selinux, just about > > not 'suggesting' that they don't use it... which is exactly what turning > > it off at install would be doing. > > > > Sorry but you are forcing it if is enabled by default on install. > How much users (not counting devels, admins and testers) of fedora know > about SELinux and what it is? And what do people do when they install > something - they probably leave all settings on default in hope that > they don't "break" something with their wrong choices. I would like to propose that the CD Desktop spin also always run as root. Users do not know how to correctly use file permissions (or even know what they are) and they often are annoyed that they cannot simply remove useless directories like /usr that serve no apparent purpose but occupy a lot of space. Ah, also, can we run Fedora on a FAT file system by default, it's a much easier file system to deal with and works on Cameras too and it is not case sensitive, which is really helpful, case sensitivity is sooo annoying ... And also those annoying pop-ups asking for the root of a password when you want to change some configuration? What in the earth is the root of a password? I'd say login as root with no password is the best for usability, please consider it! -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From valent.turkovic at gmail.com Thu Jan 17 07:40:31 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 17 Jan 2008 08:40:31 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478E7B49.2020309@redhat.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <478E7B49.2020309@redhat.com> Message-ID: <478F066F.8070603@gmail.com> Warren Togami wrote: > Valent Turkovic wrote: >> Hi, >> I believe that SELinux is a great linux server security hardening tool >> but that has little use in desktop linux usage and it confuses >> ordinary desktop users. >> If it hasn't been discussed before I would like to propose that on >> desktop cd spin SELinux is not installed by default, of course after >> discussion and approval from you (fedora devels). >> >> >> Cheers, >> Valent >> > > Also keep in mind that if SELinux break something on the desktop, THAT > is a bug. Starting before F8 I personally began to use SELinux enabled Well I repoted how SELinux "broke" a mayor Fedora 8 feature. Fluendo codecs don't work even if you buy them. Sure it is SELinux job to disable if software has bugs, but fluendo can't fix it because it is intel compiler bug that they can fix... and so on and on... This is just one example. I disabled SELiux for that bug and now I can play my multimedia. Did my machine blow up? Dig I get OWNED? Am I now asking hacked to come and get me? Are my files being read and deleted randomly by somebody? Did my memory overflow? No, no, no, no. People just want thing to JustWork and SELinux has the stoping power of magnum .44. Sure it is a powefull tool but you are puting it in inexperienced hands and doing more damage to fedora desktop that it gives benefit to users. On my RHEL or CentoOS servers, yes. But on my desktop no. > all the time. At first a few things were broken, but I figured out how > to report smart Bugzilla reports against selinux-policy and dwalsh takes > care of them real quick. Same here. But I still see too much negative that positive for average users who aren't going to understand your or mine point and for sure won't like if something doesn't work on their desktop no matter the reason being bugs or security. From pemboa at gmail.com Thu Jan 17 07:44:44 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 17 Jan 2008 01:44:44 -0600 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478F066F.8070603@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <478E7B49.2020309@redhat.com> <478F066F.8070603@gmail.com> Message-ID: <16de708d0801162344l64cad055u675d814d9e70b64e@mail.gmail.com> On Jan 17, 2008 1:40 AM, Valent Turkovic wrote: > Warren Togami wrote: > > Valent Turkovic wrote: > >> Hi, > >> I believe that SELinux is a great linux server security hardening tool > >> but that has little use in desktop linux usage and it confuses > >> ordinary desktop users. > >> If it hasn't been discussed before I would like to propose that on > >> desktop cd spin SELinux is not installed by default, of course after > >> discussion and approval from you (fedora devels). > >> > >> > >> Cheers, > >> Valent > >> > > > > Also keep in mind that if SELinux break something on the desktop, THAT > > is a bug. Starting before F8 I personally began to use SELinux enabled > > Well I repoted how SELinux "broke" a mayor Fedora 8 feature. Fluendo > codecs don't work even if you buy them. Sure it is SELinux job to > disable if software has bugs, but fluendo can't fix it because it is > intel compiler bug that they can fix... and so on and on... > This is just one example. I disabled SELiux for that bug and now I can > play my multimedia. Did my machine blow up? Dig I get OWNED? Am I now > asking hacked to come and get me? Are my files being read and deleted > randomly by somebody? Did my memory overflow? No, no, no, no. > People just want thing to JustWork and SELinux has the stoping power of > magnum .44. Sure it is a powefull tool but you are puting it in > inexperienced hands and doing more damage to fedora desktop that it > gives benefit to users. Maybe you should have considered your real request when you wrote the original email, since in the title you say 'remove' now you're saying disable. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From valent.turkovic at gmail.com Thu Jan 17 07:45:12 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 17 Jan 2008 08:45:12 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <16de708d0801162055q5dca70e1yf24e9d2faf6567ca@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080117034056.GG18982@zoidtechnologies.com> <478EDAFB.7090506@filteredperception.org> <16de708d0801162055q5dca70e1yf24e9d2faf6567ca@mail.gmail.com> Message-ID: <478F0788.1020403@gmail.com> Arthur Pemberton wrote: > So have those proposing the remove of SELinux come to the conclusion > that the average Fedora user is too stupid to click (2,3 clicks?) > SELinux to disabled and be done with it? Maybe even on firstboot? > Do you actually believe that average (less than year of linux experience) fedora user knows about and understands SELinux? From vlada at fedora.org.nz Thu Jan 17 07:46:17 2008 From: vlada at fedora.org.nz (Vladimir N Kosovac) Date: Thu, 17 Jan 2008 20:46:17 +1300 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478F018F.50009@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116210016.GA10162@devserv.devel.redhat.com> <1200518035.5766.2.camel@localhost> <1200518850.3277.5.camel@localhost.localdomain> <64b14b300801161335o1f27cf76t3affe31e8aae02ab@mail.gmail.com> <604aa7910801161400k2e3ea6d6r3706a721a9106aed@mail.gmail.com> <478F018F.50009@gmail.com> Message-ID: <1200555977.4103.16.camel@nebula> On Thu, 2008-01-17 at 08:19 +0100, Valent Turkovic wrote: > Jeff Spaleta wrote: > > On Jan 16, 2008 12:35 PM, Valent Turkovic wrote: > >> What is your target audience with SELinux? > > > > Everyone who runs a computer that takes input from an external source, > > whether that be floppies, or a network connection, or a bluetooth > > keyboard. Security matters... it doesn't matter if you are a desktop > > user or not... security matters. If we are doing a good enough job at > > policy writing and management then we fix the policies. > > Will fedora include virus scanners? If not why? > yum search clamav I think you need to go a step (or two) back and re-read what people are saying about the reasoning behind SElinux enforcing by default. It is a good thing and a positive shift in the right direction. It does not cause many problems anymore but if, in some cases, it does, everybody is free to turn it off if not willing to help developers to make it better by filing a bug. You can disable it, as you know, at install time as well. Comparing Fedora to other distributions is meaningless. Every distro has its own reasons to package stuff as they do. Fedora is not in a business of competing with them. While still providing pretty awesome computing experience, it's purpose is mostly introduction and advancement of cool, new stuff. The future, you know. Vladimir > > You really need to go back and read every single blog post from Dan > > Walsh concerning the new xguest policy he is working on. He's got > > very clear and very real desktop usage cases in mind for it. Turning > > selinux off wholesale on a desktop spin just because its not optimal > > yet, is short-sighted. > > When it becomes usable for general use, by all means, enable it by > default. There is no real threat to linux desktop users from any source > and there has been zero viruses or explioits that had any significant > impact on any linux desktop. I don't see that changing in next 5 years > so why force desktop users now to have this rough edged products bother > them all the time? > > Valent > From pemboa at gmail.com Thu Jan 17 07:48:28 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 17 Jan 2008 01:48:28 -0600 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478F0788.1020403@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080117034056.GG18982@zoidtechnologies.com> <478EDAFB.7090506@filteredperception.org> <16de708d0801162055q5dca70e1yf24e9d2faf6567ca@mail.gmail.com> <478F0788.1020403@gmail.com> Message-ID: <16de708d0801162348j2fdd57adwddec0775e37ed5a@mail.gmail.com> On Jan 17, 2008 1:45 AM, Valent Turkovic wrote: > Arthur Pemberton wrote: > > So have those proposing the remove of SELinux come to the conclusion > > that the average Fedora user is too stupid to click (2,3 clicks?) > > SELinux to disabled and be done with it? Maybe even on firstboot? > > > > Do you actually believe that average (less than year of linux > experience) fedora user knows about and understands SELinux? I would like to believe that they can maneuver a mouse to choose disable from a drop down menu. We are not talking logging in as root and running command here. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From luya_tfz at thefinalzone.com Thu Jan 17 07:54:44 2008 From: luya_tfz at thefinalzone.com (Luya Tshimbalanga) Date: Wed, 16 Jan 2008 23:54:44 -0800 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478F0788.1020403@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080117034056.GG18982@zoidtechnologies.com> <478EDAFB.7090506@filteredperception.org> <16de708d0801162055q5dca70e1yf24e9d2faf6567ca@mail.gmail.com> <478F0788.1020403@gmail.com> Message-ID: <478F09C4.9050609@thefinalzone.com> Valent Turkovic a ?crit : > > Do you actually believe that average (less than year of linux > experience) fedora user knows about and understands SELinux? > At least those average fedora users know they must not disable SELinux (setting to permissive if necessary) and figure out it is better to submit a report rather than being sorry. Luya From caolanm at redhat.com Thu Jan 17 08:12:03 2008 From: caolanm at redhat.com (Caolan McNamara) Date: Thu, 17 Jan 2008 08:12:03 +0000 Subject: Fedora 8/ARM available In-Reply-To: <20080114233331.GL17358@xi.wantstofly.org> References: <20080114233331.GL17358@xi.wantstofly.org> Message-ID: <1200557523.9954.62.camel@Jehannum> On Tue, 2008-01-15 at 00:33 +0100, Lennert Buytenhek wrote: > Hi all, > > We are proud to announce the availability of a(n unofficial) > Fedora 8 package repository for the ARM architecture. > > The package repository has been built for ARMv5 EABI, soft-float, > little endian. The majority of the important and frequently used > Fedora packages have been built for ARM. FWIW, I ported OOo to arm-eabi last year, the "vanilla" rpms of the time are at... http://ooo.services.openoffice.org/pub/OpenOffice.org/cws/upload/armeabiport01/ and that work is now integrated into 2.4.0 as in rawhide so in theory for F9 it should build out of the box. At the time there was no ecj/libgcj port to arm-eabi so the extra flag to OOo's configure required to workaround that was --without-java, I see java-1.5.0-gcj-devel in the repo now so that's presumably unnecessary now. C. From oliver at linux-kernel.at Thu Jan 17 08:23:10 2008 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 17 Jan 2008 09:23:10 +0100 Subject: Fedora 8/ARM available In-Reply-To: <20080114233331.GL17358@xi.wantstofly.org> References: <20080114233331.GL17358@xi.wantstofly.org> Message-ID: <478F106E.90509@linux-kernel.at> Lennert Buytenhek wrote: > Hi all, > > We are proud to announce the availability of a(n unofficial) > Fedora 8 package repository for the ARM architecture. > > The package repository has been built for ARMv5 EABI, soft-float, > little endian. The majority of the important and frequently used > Fedora packages have been built for ARM. > > The Fedora/ARM architecture wiki page has more info: > http://fedoraproject.org/wiki/Architectures/ARM > > The easiest way to start using Fedora 8/ARM is to download the > prebuilt root filesystem, which can be booted in QEMU, or chroot'ed > into or booted from on any ARMv5 or later processor running in little > endian mode. Additional packages can be installed by using yum, > which is provided in the filesystem. > > A HOWTO which describes getting Fedora/ARM running in QEMU is here: > http://fedoraproject.org/wiki/Architectures/ARM/HowToQemu > > There currently are a handful of known issues, which are described at: > http://fedoraproject.org/wiki/Architectures/ARM/TODO > > Please help us by using the Fedora/ARM port and reporting any issues > you run into so that we can fix them. I should have bought something else/bigger than my WRT54, I guess :-) -of From ivazqueznet at gmail.com Thu Jan 17 08:27:36 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Thu, 17 Jan 2008 03:27:36 -0500 Subject: Fedora Enhancement!! In-Reply-To: <478EFE03.7000708@gmail.com> References: <1200399722.14798.9.camel@localhost.localdomain> <200801151346.45228.singularitaet@gmx.net> <478EFE03.7000708@gmail.com> Message-ID: <1200558457.9899.3.camel@ignacio.lan> On Thu, 2008-01-17 at 08:04 +0100, Valent Turkovic wrote: > Why isn't fedora packaging uvc webcam drivers? On ubuntu my webcams work > (uvc driver) but under fedora they don't :( > uvc driver should have gone into main kernel but they prologued that for > unknown amount of time. It's going into 2.6.25, so maybe if you ask *real* nicely... -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From j.w.r.degoede at hhs.nl Thu Jan 17 08:29:20 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 17 Jan 2008 09:29:20 +0100 Subject: Fedora Enhancement!! In-Reply-To: <1200558457.9899.3.camel@ignacio.lan> References: <1200399722.14798.9.camel@localhost.localdomain> <200801151346.45228.singularitaet@gmx.net> <478EFE03.7000708@gmail.com> <1200558457.9899.3.camel@ignacio.lan> Message-ID: <478F11E0.1000402@hhs.nl> Ignacio Vazquez-Abrams wrote: > On Thu, 2008-01-17 at 08:04 +0100, Valent Turkovic wrote: >> Why isn't fedora packaging uvc webcam drivers? On ubuntu my webcams work >> (uvc driver) but under fedora they don't :( >> uvc driver should have gone into main kernel but they prologued that for >> unknown amount of time. > > It's going into 2.6.25, so maybe if you ask *real* nicely... > Cool! Do you happen to know where the latest cleaned up version meant for 2.6.25 inclusion is? I would be willing to maintain this as part of the kernel rpm until its upstream, if davej will let me. But before suggesting this to davej I would rather first give it a spin. Regards, Hans From ivazqueznet at gmail.com Thu Jan 17 08:42:39 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Thu, 17 Jan 2008 03:42:39 -0500 Subject: Fedora Enhancement!! In-Reply-To: <478F11E0.1000402@hhs.nl> References: <1200399722.14798.9.camel@localhost.localdomain> <200801151346.45228.singularitaet@gmx.net> <478EFE03.7000708@gmail.com> <1200558457.9899.3.camel@ignacio.lan> <478F11E0.1000402@hhs.nl> Message-ID: <1200559359.9899.7.camel@ignacio.lan> On Thu, 2008-01-17 at 09:29 +0100, Hans de Goede wrote: > Ignacio Vazquez-Abrams wrote: > > On Thu, 2008-01-17 at 08:04 +0100, Valent Turkovic wrote: > >> Why isn't fedora packaging uvc webcam drivers? On ubuntu my webcams work > >> (uvc driver) but under fedora they don't :( > >> uvc driver should have gone into main kernel but they prologued that for > >> unknown amount of time. > > > > It's going into 2.6.25, so maybe if you ask *real* nicely... > > > > Cool! > > Do you happen to know where the latest cleaned up version meant for 2.6.25 > inclusion is? I would be willing to maintain this as part of the kernel rpm > until its upstream, if davej will let me. But before suggesting this to davej I > would rather first give it a spin. Nope. But here's the thread: http://thread.gmane.org/gmane.comp.video.video4linux/36224 OT: I don't know why the RH list archives are private when there's a public copy floating around... -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From wes.shull at gmail.com Thu Jan 17 08:45:11 2008 From: wes.shull at gmail.com (Wes Shull) Date: Thu, 17 Jan 2008 01:45:11 -0700 Subject: Fedora Enhancement!! In-Reply-To: <1200399722.14798.9.camel@localhost.localdomain> References: <1200399722.14798.9.camel@localhost.localdomain> Message-ID: On Jan 15, 2008 5:22 AM, Salloum EL DAHDAAH wrote: > 3- Pocket Pc: > Imate JAM > [...] i would like to know if there is any version of fedora that can run on > pocket pcs like Imate and HTC. > Fedora, not AFAIK. But there are other embedded/mobile oriented Linux projects. Take a look at: http://handhelds.org/moin/moin.cgi/SupportedHandheldSummary I believe your iMate JAM is a rebranded HTC Magician. Note lots of "NO" in the "Ready for users" column. However, we can always hope that the advent of Google's Android platform may turn this situation around... looking forward to fedora 8 @ least beta 1 :D > Looking backward... ;-D --wes -------------- next part -------------- An HTML attachment was scrubbed... URL: From pertusus at free.fr Thu Jan 17 08:49:17 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 17 Jan 2008 09:49:17 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <64b14b300801161335o1f27cf76t3affe31e8aae02ab@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116210016.GA10162@devserv.devel.redhat.com> <1200518035.5766.2.camel@localhost> <1200518850.3277.5.camel@localhost.localdomain> <64b14b300801161335o1f27cf76t3affe31e8aae02ab@mail.gmail.com> Message-ID: <20080117084917.GA2811@free.fr> On Wed, Jan 16, 2008 at 10:35:17PM +0100, Valent Turkovic wrote: > > And that is exactly why this feels like testing ground for RHEL and > not an option that actually benefits users because you admit that it > is not ready for "joe user". I think that your assumption that fedora is ready for joe user is wrong. But it suits users who have a knowledge of linux and what is going on and how to go find on the internet how to fix some brokenness. For example how to disable selinux, how to workaround updates failing, and so on for the other bugs that creep in. I personnally don't advise fedora for perfect newbies. On the other hand I advise it for power users, and even wanna be power users. I also think that it is nice for users who have a power user to troubleshoot the rare issues. In most cases a power user will know which features to disable at install time (currently selinux) and what is the right security/usability balance for a given user. I think that ubuntu is better for an isolated newbie who uses the desktop only and wants to install linux on his own by downloading a CD. Now I also find ubuntu very sysadmin and power user hostile. And also I prefer to install fedora on pc of friends who are perfect newbies, but know how to reach me when they have a problem. -- Pat From nicolas.mailhot at laposte.net Thu Jan 17 09:01:28 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 17 Jan 2008 10:01:28 +0100 (CET) Subject: Fedora Enhancement!! In-Reply-To: <478EFE03.7000708@gmail.com> References: <1200399722.14798.9.camel@localhost.localdomain> <200801151346.45228.singularitaet@gmx.net> <478EFE03.7000708@gmail.com> Message-ID: <19639.192.54.193.53.1200560488.squirrel@rousalka.dyndns.org> Le Jeu 17 janvier 2008 08:04, Valent Turkovic a ?crit : > Why isn't fedora packaging uvc webcam drivers? Because they've not been merged in Linus' tree and it's been decided after years of trying to make them work that out-of-tree modules cause more problems than they solve -- Nicolas Mailhot From aph at redhat.com Thu Jan 17 09:51:21 2008 From: aph at redhat.com (Andrew Haley) Date: Thu, 17 Jan 2008 09:51:21 +0000 Subject: Fedora 8/ARM available In-Reply-To: <1200557523.9954.62.camel@Jehannum> References: <20080114233331.GL17358@xi.wantstofly.org> <1200557523.9954.62.camel@Jehannum> Message-ID: <18319.9497.534662.589650@zebedee.pink> Caolan McNamara writes: > > On Tue, 2008-01-15 at 00:33 +0100, Lennert Buytenhek wrote: > > Hi all, > > > > We are proud to announce the availability of a(n unofficial) > > Fedora 8 package repository for the ARM architecture. > > > > The package repository has been built for ARMv5 EABI, soft-float, > > little endian. The majority of the important and frequently used > > Fedora packages have been built for ARM. > > FWIW, I ported OOo to arm-eabi last year, the "vanilla" rpms of the time > are at... > http://ooo.services.openoffice.org/pub/OpenOffice.org/cws/upload/armeabiport01/ > and that work is now integrated into 2.4.0 as in rawhide so in theory > for F9 it should build out of the box. > > At the time there was no ecj/libgcj port to arm-eabi so the extra flag > to OOo's configure required to workaround that was --without-java, I > see java-1.5.0-gcj-devel in the repo now so that's presumably > unnecessary now. I certainly hope so. Lennert and I have done a lot of work to get gcj working on ARM EABI, so if anything fails I'd appreciate a heads-up. Yeah, I know it's rather slow. :-) Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From valent.turkovic at gmail.com Thu Jan 17 09:52:23 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 17 Jan 2008 10:52:23 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <16de708d0801162348j2fdd57adwddec0775e37ed5a@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080117034056.GG18982@zoidtechnologies.com> <478EDAFB.7090506@filteredperception.org> <16de708d0801162055q5dca70e1yf24e9d2faf6567ca@mail.gmail.com> <478F0788.1020403@gmail.com> <16de708d0801162348j2fdd57adwddec0775e37ed5a@mail.gmail.com> Message-ID: <478F2557.6070304@gmail.com> Arthur Pemberton wrote: > On Jan 17, 2008 1:45 AM, Valent Turkovic wrote: >> Arthur Pemberton wrote: >>> So have those proposing the remove of SELinux come to the conclusion >>> that the average Fedora user is too stupid to click (2,3 clicks?) >>> SELinux to disabled and be done with it? Maybe even on firstboot? >>> >> Do you actually believe that average (less than year of linux >> experience) fedora user knows about and understands SELinux? > > > I would like to believe that they can maneuver a mouse to choose > disable from a drop down menu. We are not talking logging in as root > and running command here. In order to do that people first need to to know what SELinux actually does. I don't believe that users who aren't a bit experienced with linux have a clue what SELinux is and what it does, except pops up some strange "AVC Denial" messages. Valent. From valent.turkovic at gmail.com Thu Jan 17 10:07:46 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 17 Jan 2008 11:07:46 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <16de708d0801162344l64cad055u675d814d9e70b64e@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <478E7B49.2020309@redhat.com> <478F066F.8070603@gmail.com> <16de708d0801162344l64cad055u675d814d9e70b64e@mail.gmail.com> Message-ID: <478F28F2.8030004@gmail.com> Arthur Pemberton wrote: > On Jan 17, 2008 1:40 AM, Valent Turkovic wrote: >> Warren Togami wrote: >>> Valent Turkovic wrote: >>>> Hi, >>>> I believe that SELinux is a great linux server security hardening tool >>>> but that has little use in desktop linux usage and it confuses >>>> ordinary desktop users. >>>> If it hasn't been discussed before I would like to propose that on >>>> desktop cd spin SELinux is not installed by default, of course after >>>> discussion and approval from you (fedora devels). >>>> >>>> >>>> Cheers, >>>> Valent >>>> >>> Also keep in mind that if SELinux break something on the desktop, THAT >>> is a bug. Starting before F8 I personally began to use SELinux enabled >> Well I repoted how SELinux "broke" a mayor Fedora 8 feature. Fluendo >> codecs don't work even if you buy them. Sure it is SELinux job to >> disable if software has bugs, but fluendo can't fix it because it is >> intel compiler bug that they can fix... and so on and on... >> This is just one example. I disabled SELiux for that bug and now I can >> play my multimedia. Did my machine blow up? Dig I get OWNED? Am I now >> asking hacked to come and get me? Are my files being read and deleted >> randomly by somebody? Did my memory overflow? No, no, no, no. >> People just want thing to JustWork and SELinux has the stoping power of >> magnum .44. Sure it is a powefull tool but you are puting it in >> inexperienced hands and doing more damage to fedora desktop that it >> gives benefit to users. > > > Maybe you should have considered your real request when you wrote the > original email, since in the title you say 'remove' now you're saying > disable. > It should be *ATLEAST* disabled by default, and I see more and more reason for it not being on cd in the first place. The space it occupies can be much more used and give much more functionality and you sacrifice just one "feature" that hardly anybody would miss, and ones that do can easily install it and enable it. Valent. From valent.turkovic at gmail.com Thu Jan 17 10:09:51 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 17 Jan 2008 11:09:51 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <1200555501.10767.47.camel@localhost.localdomain> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <16de708d0801161316v66d0d49ch2508c29cb25e4abd@mail.gmail.com> <64b14b300801161328u1bd44f7ajc0d1f2ef9a172513@mail.gmail.com> <478E8E48.6080003@gmail.com> <478F0341.9050509@gmail.com> <1200555501.10767.47.camel@localhost.localdomain> Message-ID: <478F296F.10405@gmail.com> Simo Sorce wrote: > On Thu, 2008-01-17 at 08:26 +0100, Valent Turkovic wrote: >> Andrew Farris wrote: >>> Valent Turkovic wrote: >>> >>>> And I bet that more will choose ubuntu as a "friendlier" desktop if >>>> fedora forces people to use SELinux. >>> Except noone is talking about forcing anyone to use selinux, just about >>> not 'suggesting' that they don't use it... which is exactly what turning >>> it off at install would be doing. >>> >> Sorry but you are forcing it if is enabled by default on install. >> How much users (not counting devels, admins and testers) of fedora know >> about SELinux and what it is? And what do people do when they install >> something - they probably leave all settings on default in hope that >> they don't "break" something with their wrong choices. > > I would like to propose that the CD Desktop spin also always run as > root. > Users do not know how to correctly use file permissions (or even know > what they are) and they often are annoyed that they cannot simply remove > useless directories like /usr that serve no apparent purpose but occupy > a lot of space. > > Ah, also, can we run Fedora on a FAT file system by default, it's a much > easier file system to deal with and works on Cameras too and it is not > case sensitive, which is really helpful, case sensitivity is sooo > annoying ... > > And also those annoying pop-ups asking for the root of a password when > you want to change some configuration? What in the earth is the root of > a password? I'd say login as root with no password is the best for > usability, > > please consider it! > > > Where is your bugzilla RFE? Don't say you didn't post it to bugzilla :) I believe that all your most of your concerns can be dealth through policykit so please put RFE to correct package. From valent.turkovic at gmail.com Thu Jan 17 10:12:17 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 17 Jan 2008 11:12:17 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <16de708d0801162323t6db1e974j4eca4aeb2af344f4@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116210016.GA10162@devserv.devel.redhat.com> <1200518035.5766.2.camel@localhost> <1200518850.3277.5.camel@localhost.localdomain> <64b14b300801161335o1f27cf76t3affe31e8aae02ab@mail.gmail.com> <604aa7910801161400k2e3ea6d6r3706a721a9106aed@mail.gmail.com> <478F018F.50009@gmail.com> <16de708d0801162323t6db1e974j4eca4aeb2af344f4@mail.gmail.com> Message-ID: <478F2A01.9030105@gmail.com> Arthur Pemberton wrote: > On Jan 17, 2008 1:19 AM, Valent Turkovic wrote: >> Jeff Spaleta wrote: >>> On Jan 16, 2008 12:35 PM, Valent Turkovic wrote: >>>> What is your target audience with SELinux? >>> Everyone who runs a computer that takes input from an external source, >>> whether that be floppies, or a network connection, or a bluetooth >>> keyboard. Security matters... it doesn't matter if you are a desktop >>> user or not... security matters. If we are doing a good enough job at >>> policy writing and management then we fix the policies. >> Will fedora include virus scanners? If not why? >> >>> You really need to go back and read every single blog post from Dan >>> Walsh concerning the new xguest policy he is working on. He's got >>> very clear and very real desktop usage cases in mind for it. Turning >>> selinux off wholesale on a desktop spin just because its not optimal >>> yet, is short-sighted. >> When it becomes usable for general use, by all means, enable it by >> default. There is no real threat to linux desktop users from any source >> and there has been zero viruses or explioits that had any significant >> impact on any linux desktop. I don't see that changing in next 5 years >> so why force desktop users now to have this rough edged products bother >> them all the time? >> >> Valent > > > You have yet to explain why two clicks after install, or one click at > first boot is too many. > It is not, nobody said that it was. The problem is people knowing that those clicks mean. Does anaconda explain what SELinux does? Please show me where if you see it because I don't. From lkundrak at redhat.com Thu Jan 17 10:18:25 2008 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Thu, 17 Jan 2008 11:18:25 +0100 Subject: What component is this? In-Reply-To: <870180fe0801162016l5c7ba5bt470864bfcbc847fe@mail.gmail.com> References: <870180fe0801162016l5c7ba5bt470864bfcbc847fe@mail.gmail.com> Message-ID: <1200565105.23106.2.camel@localhost.localdomain> On Wed, 2008-01-16 at 21:16 -0700, Jerry James wrote: ... > avc: denied { execheap } for comm=gnome-settings- pid=2851 ... > PID 2851 didn't exist by the time I was able to check for it. I > didn't find anything relevant in bugzilla. A little poking around on > my system failed to turn up anything called gnome-settings-. I'd file > a bug, but I have no idea what component this is. Anybody know? gnome-settings-daemon I suspect. 'control-center' component. -- Lubomir Kundrak (Red Hat Security Response Team) From lordmorgul at gmail.com Thu Jan 17 10:26:18 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Thu, 17 Jan 2008 02:26:18 -0800 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478F2A01.9030105@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116210016.GA10162@devserv.devel.redhat.com> <1200518035.5766.2.camel@localhost> <1200518850.3277.5.camel@localhost.localdomain> <64b14b300801161335o1f27cf76t3affe31e8aae02ab@mail.gmail.com> <604aa7910801161400k2e3ea6d6r3706a721a9106aed@mail.gmail.com> <478F018F.50009@gmail.com> <16de708d0801162323t6db1e974j4eca4aeb2af344f4@mail.gmail.com> <478F2A01.9030105@gmail.com> Message-ID: <478F2D4A.1000001@gmail.com> Valent Turkovic wrote: > Arthur Pemberton wrote: >> You have yet to explain why two clicks after install, or one click at >> first boot is too many. >> > > It is not, nobody said that it was. The problem is people knowing that > those clicks mean. Does anaconda explain what SELinux does? Please show > me where if you see it because I don't. This is a problem that needs dealt with, I'll agree with you. Anaconda should offer a user an understandable basic explanation and a location (url) where to find a much more detailed version. (I haven't managed to get a latest fc9 anaconda to run graphical so I don't know if this has been improved) But thats a different issue entirely and you could be filing RFE on improving the user experience for that through documentation. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From j.w.r.degoede at hhs.nl Thu Jan 17 10:47:54 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 17 Jan 2008 11:47:54 +0100 Subject: Wanted: FireWire testers In-Reply-To: <47897238.4000303@gmail.com> References: <4787F211.3010402@redhat.com> <4787F580.2030405@gmail.com> <4788D521.9000701@redhat.com> <47897238.4000303@gmail.com> Message-ID: <478F325A.1010600@hhs.nl> > Jarod Wilson wrote: > Its built. > > http://koji.fedoraproject.org/packages/kernel/2.6.23.13/106.fc8/ > Works like like a charm over here! Regards, Hans From opensource at till.name Thu Jan 17 10:50:18 2008 From: opensource at till.name (Till Maas) Date: Thu, 17 Jan 2008 11:50:18 +0100 Subject: What component is this? In-Reply-To: <1200565105.23106.2.camel@localhost.localdomain> References: <870180fe0801162016l5c7ba5bt470864bfcbc847fe@mail.gmail.com> <1200565105.23106.2.camel@localhost.localdomain> Message-ID: <200801171150.26979.opensource@till.name> On Thu January 17 2008, Lubomir Kundrak wrote: > On Wed, 2008-01-16 at 21:16 -0700, Jerry James wrote: > ... > > > avc: denied { execheap } for comm=gnome-settings- pid=2851 > > ... > > > PID 2851 didn't exist by the time I was able to check for it. I > > didn't find anything relevant in bugzilla. A little poking around on > > my system failed to turn up anything called gnome-settings-. I'd file > > a bug, but I have no idea what component this is. Anybody know? > > gnome-settings-daemon I suspect. 'control-center' component. I would use selinux-policy, because there the selinux policy is stored and the maintainers of the other packages most of the time can only reassign it to selinux-policy, because they do not know how to fix this or it has to be fixed within the selinux-policy by a selinux-policy maintainer. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From jochen.schlick at comsoft.de Thu Jan 17 11:30:20 2008 From: jochen.schlick at comsoft.de (Jochen Schlick) Date: Thu, 17 Jan 2008 12:30:20 +0100 Subject: rawhide with X as qemu/kvm guests Message-ID: <478F3C4C.90002@comsoft.de> Hi, it would be nice if there were also updated cirrus driver(s) available [qemu/kvm's default graphic adapter is Cirrus CLGD 5446] With the current vesa driver some of the resolutions doesn't work or are very slow. best regards -- --------------------------------------------------------------------------- Jochen Schlick --------------------------------------------------------------------------- From airlied at redhat.com Thu Jan 17 11:36:32 2008 From: airlied at redhat.com (Dave Airlie) Date: Thu, 17 Jan 2008 21:36:32 +1000 Subject: rawhide with X as qemu/kvm guests In-Reply-To: <478F3C4C.90002@comsoft.de> References: <478F3C4C.90002@comsoft.de> Message-ID: <1200569792.4413.1.camel@localhost> On Thu, 2008-01-17 at 12:30 +0100, Jochen Schlick wrote: > Hi, > > it would be nice if there were also updated cirrus driver(s) > available [qemu/kvm's default graphic adapter is Cirrus CLGD 5446] I just pushed one into rawhide like 3 hours ago :) please test and let me know if it works at all, it was a blind pciaccess port and I have one report of badness, but more would be appreciated.. A log from F8 might also be useful if anyone has one.. Dave. From mcepl at redhat.com Thu Jan 17 11:34:20 2008 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 17 Jan 2008 12:34:20 +0100 Subject: Fedora bug triage - workflow proposal References: <20080115092452.245d5604@ghistelwchlohm.scrye.com> Message-ID: On 2008-01-16, 06:21 GMT, Jon Stanley wrote: >> What about the above case of NEEDINFO(maintainer)? > > Great question, I've never seen this actually used. Most of the time > it's in NEEDINFO(reporter). I guess some logic could be used, I'm not > sure of the how good tag support is in the XMLRPC API. Maybe someone > smarter than me could comment. NEEDINFO(maintainer) is kind of difficult. I know for sure that there are developers with huge number of opened bugs (I won't name the ...) who actually claim that marking a bug as NEEDINFO(maintainer) is one of the most secure ways how to make it lost. Developers either follow all their bugmail and NEEDINFO(maintainer) is unnecessary, or they just go for ASSIGNED bugs and then it is actually pretty harmful. While writing previous paragraph, the issue begin pretty clear to me -- now I would vote for removing NEEDINFO(maintainer) from the bugzilla (or at least its Fedora part it is possible to separate it) completely. If anybody every comes with the reason why he needs to set NEEDINFO against maintainer, there is always NEEDINFO(other). Just my 0.02 CZK Mat?j From opensource at till.name Thu Jan 17 12:21:24 2008 From: opensource at till.name (Till Maas) Date: Thu, 17 Jan 2008 13:21:24 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <64b14b300801161235i4a4ed432h4f7b81ecefaf292b@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116202554.GF15623@redhat.com> <64b14b300801161235i4a4ed432h4f7b81ecefaf292b@mail.gmail.com> Message-ID: <200801171321.29240.opensource@till.name> On Wed January 16 2008, Valent Turkovic wrote: > Dan you are taking this the wrong way. Of course SElinux is great, of > course it prevents from 0day exploits, no body is challenging that. > But what was the real threat to average desktop users? Has anybody > made use of this 0day exploit threat? is there a linux virus in the > wild that spread like wildfire that took down all desktops that didn't > use SELinux? The desktop users are the threat, e.g. in internet cafes or computer pools in universities or libraries. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From atkac at redhat.com Thu Jan 17 13:12:11 2008 From: atkac at redhat.com (Adam Tkac) Date: Thu, 17 Jan 2008 14:12:11 +0100 Subject: firewall changes for F-9+ In-Reply-To: <1200528472.26259.63.camel@cookie.hadess.net> References: <478E4460.8040805@redhat.com> <1200528472.26259.63.camel@cookie.hadess.net> Message-ID: <20080117131211.GA3940@evileye.atkac.englab.brq.redhat.com> On Thu, Jan 17, 2008 at 12:07:52AM +0000, Bastien Nocera wrote: > > On Wed, 2008-01-16 at 18:52 +0100, Thomas Woerner wrote: > > Hello, > > > > here are the latest changes for system-config-firewall for F-9+: > > > > The usage of --port=: for lokkit will open up this port and > > not a service using this port anymore. To enable a service you have to > > use the new --service= option. There are no magic default open > > services. You have to open up the services, you want to use. The interim > > options --no-X; X in ["ipsec", "mdns", "ipp"] are obsolete now. > > > > To setup a new firewall, you can use the new --default= > > configuration option as a start: > > server : ssh is enabled > > desktop : ipsec, mdns and ipp are enabled > > IpSec and IPP as services don't sound very much like desktop > applications. > Definitely. Also mdns enabled on desktop doesn't make sence for me. I think only ssh will be enabled on both server and desktop. Adam -- Adam Tkac, Red Hat, Inc. From buildsys at redhat.com Thu Jan 17 13:24:32 2008 From: buildsys at redhat.com (Build System) Date: Thu, 17 Jan 2008 08:24:32 -0500 Subject: rawhide report: 20080117 changes Message-ID: <200801171324.m0HDOWbU006382@porkchop.devel.redhat.com> New package OpenEXR_CTL A simplified OpenEXR interface to CTL New package mono-zeroconf mono-zeroconf namespace New package perl-Parallel-ForkManager Simple parallel processing fork manager New package portecle Multipurpose keystore and certificate tool Removed package gwenview Updated Packages: VLGothic-fonts-20071215-2.fc9 ----------------------------- * Thu Jan 17 2008 Jens Petersen - 20071215-2 - move monospace font to main package and obsolete monospace subpackage - rename sans subpackage to proportional and obsolete sans subpackage - use a separate font dir for the proportional font subpackage - add fc-cache scriptlets - drop the docs subpackage - use fontname, fontdir, and fontconfdir macros - improve summaries and descriptions - do not require fontconfig - drop VLGothic obsoletes and provides azureus-3.0.3.4-6.fc9 --------------------- * Wed Jan 16 2008 Lillian Angel - 3.0.3.4-6 - Removed azureus-themed.patch bluez-gnome-0.15-1.fc9 ---------------------- * Wed Jan 16 2008 - Bastien Nocera - 0.15-1 - Update to 0.15 - Add patch to remove the useless hardware type selection boost-1.34.1-7.fc9 ------------------ * Mon Jan 14 2008 Benjamin Kosnik 1.34.1-7 - Fixes for boost.regex (rev 42674). bouml-3.5-1.fc9 --------------- * Wed Jan 16 2008 Debarshi Ray - 3.5-1 - Version bump to 3.5. Closes Red Hat Bugzilla bug #428840. - Previous releases can not read a project saved with this version, but projects made by previous releases can be read. * Fri Dec 21 2007 Debarshi Ray - 3.4-1 - Version bump to 3.4. Closes Red Hat Bugzilla bug #426485. - Previous releases can not read a project saved with this version, but projects made by previous releases can be read. * Thu Nov 29 2007 Debarshi Ray - 3.3.3-1 - Version bump to 3.3.3. Closes Red Hat Bugzilla bug #398811. - Fixed usage of _remove_encoding to prevent failure on Fedora 7. dbus-1.1.3-1.fc9 ---------------- * Wed Jan 16 2008 John (J5) Palmieri - 1.1.3-1 - new upstream version which obsoletes a number of our patches - doc section added for the devhelp docs dhcp-12:4.0.0-4.fc9 ------------------- * Wed Jan 16 2008 David Cantrell - 12:4.0.0-4 - Fix dhclient.lease file parsing problems (#428785) - Disable IPv6 support for now as we already ship dhcpv6 (#428987) dhcpv6-1.0.7-1.fc9 ------------------ * Wed Jan 16 2008 David Cantrell - 1.0.7-1 - Upgrade to dhcpv6-1.0.7 * Wed Jan 16 2008 David Cantrell - 1.0.6-1 - Upgrade to dhcpv6-1.0.6 - License is now LGPL v2.1 or any later version evolution-data-server-2.21.5-2.fc9 ---------------------------------- * Wed Jan 16 2008 Matthew Barnes - 2.21.5-2.fc9 - Add patch for GNOME bug #509644 (password dialog breakage). - Remove patch for RH bug #384741 (fixed upstream). - Remove patch for GNOME bug #363695 (obsolete). - Remove patch for GNOME bug #376991 (obsolete). fribidi-0.19.1-1.fc9 -------------------- * Wed Jan 16 2008 Caolan McNamara 0.19.1-1 - next version - workaround PAGE_SIZE requirement gnome-applets-1:2.21.4-1.fc9 ---------------------------- * Wed Jan 16 2008 Matthias Clasen - 1:2.21.4-1 - Update to 2.21.4 gnome-panel-2.21.5-1.fc9 ------------------------ * Wed Jan 16 2008 Matthias Clasen - 2.21.5-1 - Update to 2.21.5 - Drop separate intlclock gocr-0.44-4.fc9 --------------- * Mon Jan 14 2008 Tomas Smetana - 0.44-4 - build devel package (with static library) inn-2.4.3-9.fc9 --------------- * Wed Jan 16 2008 Ondrej Vasik 2.4.3-9 - do not show annoying fatal log message when nonfatal error eaddrinuse occured in rcreader - use /etc/rsyslog.conf instead of /etc/syslog.conf kdnssd-avahi-0.1.3-0.5.20080116svn.fc9 -------------------------------------- * Wed Jan 16 2008 Rex Dieter 0.1.3-0.5.20080116svn - 20080116svn - -devel: Requires: kdelibs3-devel libcap-1.10-33.fc9 ------------------ * Wed Jan 16 2008 Karsten Hopp 1.10-33 - drop post,postun requirements on ldconfig as find-requires can handle this * Tue Jan 15 2008 Karsten Hopp 1.10-32 - add disttag - fix changelog - fix defattr * Mon Jan 14 2008 Karsten Hopp 1.10-31 - use cp -p in spec file to preserve file attributes (#225992) - add license file libgweather-2.21.2-4.fc9 ------------------------ * Wed Jan 16 2008 Matthias Clasen 2.21.2-4 - Add Obsoletes for gnome-applets-devel liferea-1.4.11-1.fc9 -------------------- * Wed Jan 16 2008 Brian Pepple - 1.4.11-1 - Update to 1.4.11. milter-greylist-4.0-1.fc9 ------------------------- * Sat Nov 10 2007 Enrico Scholz - 4.0-1 - updated to final 4.0 - fixed conflicts between libbind and libresolv by linking them manually * Mon Oct 29 2007 Enrico Scholz - 4.0-0.3.rc2 - updated to 4.0rc2 mock-0.9.6-1.fc9 ---------------- * Wed Jan 16 2008 Clark Williams - 0.9.6-1 - renamed configs and put compat symlinks in place - misc cleanups (whitespace fixes, info messages, etc.) - tmpfs plugin fix - split --target and --arch command line arguments - changed from -l to --login on bash invocations - create /dev/full in chroot mpage-2.5.6-1.fc9 ----------------- * Tue Jan 15 2008 Tomas Smetana - 2.5.6-1 - new upstream version openoffice.org-1:2.4.0-2.2.fc9 ------------------------------ * Tue Jan 15 2008 Caolan McNamara - 1:2.4.0-2.2 - fix hyphenation pcsc-lite-1.4.4-2.fc9 --------------------- * Wed Jan 16 2008 Bob Relyea - 1.4.4-2 - Silence libpcsc-lite even when the daemon isn't running. - fix typo in init file which prevents the config file from being read. perl-Math-Vec-1.01-1.fc9 ------------------------ pykickstart-1.26-1.fc9 ---------------------- * Thu Jan 17 2008 Chris Lumens - 1.26-1 - Add support for network --bootproto=ask. (clumens) pymsn-0.3.1-1.fc9 ----------------- * Wed Jan 16 2008 Brian Pepple - 0.3.1-1 - Update to 0.3.1. rdiff-backup-1.0.5-6.fc9 ------------------------ * Tue Jan 15 2008 Kevin Fenzi 1.0.5-6 - Add egginfo file. recode-3.6-25.fc9 ----------------- * Wed Jan 16 2008 Zoltan Kota 3.6-25 - add patch for gcc43 ruby-mechanize-0.7.0-1.fc9 -------------------------- * Thu Jan 17 2008 Mamoru Tasaka - 0.7.0-1 - 0.7.0 snake-0.10-0.2git.fc9 --------------------- * Wed Jan 16 2008 James Laska 0.10-0.2git - Fix snake.spec for better handling of F9 .egg-info files * Tue Jan 15 2008 James Laska 0.10-0.1git - Ticket#6 - Initial support for alternative kickstart delivery support (jlaska) - Created man pages (snake-install, snake-ks, and snake-tree) (jlaska) - Created man pages (snake-install, snake-ks, and snake-tree) (jlaska) - Ticket#31 - added sample minimal.ks template (jlaska) - Ticket#15 - make cli tools operate on remote server (jlaska) - Ticket#34 - added 'describe' and 'rename' cmds to snake-ks (jlaska) - Move tree verification to snake.client.check_tree with proper return codes (wwoods) - Ticket#10 - created snake/tui.py to handle text-mode snack screens (jlaska) sonata-1.4-1.fc9 ---------------- * Wed Jan 16 2008 Micha?? Bentkowski - 1.4-1 - 1.4 - Now sonata puts manpage in proper directory system-config-firewall-1.1.3-2.fc9 ---------------------------------- * Wed Jan 16 2008 Thomas Woerner 1.1.3-2 - added fw_compat files to files section * Tue Jan 15 2008 Thomas Woerner 1.1.3-1 - new fw_compat, used in config-convert and fw_sysconfig to automatically convert old system-config-securitylevel configurations - new wizard look - fixed range check for user defined ports - some code cleanup - updated translations for fi, fr and ja * Mon Jan 07 2008 Thomas Woerner 1.1.2-1 - fw_gui: fixed row activation for masquerading - fw_gui: fixed _setInterfaces to use internal functions to correctly set toggles - fw_gui: show info dialog if no config exists and firewall gets enabled: new function enableFirewall - fw_gui, fw_tui: disable firewall if no config exists - fw_gui, fw_tui: do not print traceback if NCDeviceList.getDeviceList raises and exception - forward masqueraded connections - gtk_cellrenderercheck: fixed size calculations - fw_sysconfig: set config.filename to None for merged configuration in read_sysconfig_config if no configuration exists - new translations taglib-1.5-0.7.20080116svn.fc9 ------------------------------ * Wed Jan 16 2008 Rex Dieter 1.5-0.7.20080116svn - svn20080116 snapshot - multiarch conflicts (#343241) telepathy-mission-control-4.55-1.fc9 ------------------------------------ * Tue Jan 15 2008 Peter Gordon - 4.55-1 - Update to new upstream release (4.55) - Drop obsolete 64-bit patch. - size_t_vs_guint.patch texlive-2007-11.fc9 ------------------- * Wed Jan 16 2008 Jindrich Novy - 2007-11 - temporary fix to pdflatex to not to warn verbosely because of ambiguous entries in pdflatex.map (#425804) - update post scriptlets, spec cleanup * Tue Jan 15 2008 Jindrich Novy - 2007-10 - don't build/package xdvik/pxdvik, it's now separated - fix texlive-doc requires, description - use virtual provides with parentheses to avoid clashes with real packages (#410401) * Mon Jan 14 2008 Jindrich Novy - 2007-9 - unify texlive and texlive-fonts filelists - package texdoc and texdoctk to a separate subpackage texlive-doc, because of the Perl-Tk dependencies and logic vala-0.1.5-5.fc9 ---------------- * Tue Jan 15 2008 Michel Salim - 0.1.5-5 - Manually add Gee vapi file to package (bz #428692) * Tue Dec 04 2007 Michel Salim - 0.1.5-4 - Backport patch to autodetect location of automake shared files * Tue Dec 04 2007 Michel Salim - 0.1.5-3 - Add build dependency on gtk2-devel vim-2:7.1.230-2.fc9 ------------------- * Wed Jan 16 2008 Karsten Hopp 7.1.230-2 - add newer ada runtime files to fix bugzilla #246378 * Wed Jan 16 2008 Karsten Hopp 7.1.230-1 - patchlevel 230, fixes memory leak xorg-x11-drv-ati-6.7.196-7.fc9 ------------------------------ * Thu Jan 17 2008 Dave Airlie 6.7.196-7 - fix up IGPs from upstream fix. xorg-x11-drv-cirrus-1.1.0-6.fc9 ------------------------------- * Thu Jan 17 2008 Dave Airlie - 1.1.0-6 - update for new server build and pciaccess xorg-x11-drv-sis-0.9.4-3.fc9 ---------------------------- * Thu Jan 17 2008 Dave Airlie - 0.9.4-3 - fix more bugs in pciaccess port - tested on actual hardware. * Wed Jan 16 2008 Dave Airlie - 0.9.4-2 - fixup bugs in pciaccess port xorg-x11-drv-void-1.1.1-8.fc9 ----------------------------- * Wed Jan 16 2008 Jason L Tibbitts III - 1.1.1-8 - Don't own %{mandir}. Broken deps for i386 ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.i386 requires libgtkembedmoz.so epiphany-extensions - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.i386 requires libgtkembedmoz.so gnome-web-photo - 0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 icewm - 1.2.35-1.fc9.i386 requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 tkinter - 2.5.1-20.fc9.i386 requires libTix8.4.so Broken deps for x86_64 ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) icewm - 1.2.35-1.fc9.x86_64 requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 tkinter - 2.5.1-20.fc9.x86_64 requires libTix8.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.ppc requires libgtkembedmoz.so epiphany-extensions - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.ppc requires libgtkembedmoz.so gnome-web-photo - 0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 icewm - 1.2.35-1.fc9.ppc requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 monodevelop - 0.17-4.fc9.ppc requires boo tkinter - 2.5.1-20.fc9.ppc requires libTix8.4.so Broken deps for ppc64 ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) icewm - 1.2.35-1.fc9.ppc64 requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 perl-Test-AutoBuild-darcs - 1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 tkinter - 2.5.1-20.fc9.ppc64 requires libTix8.4.so()(64bit) From benny+usenet at amorsen.dk Thu Jan 17 13:29:00 2008 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Thu, 17 Jan 2008 14:29:00 +0100 Subject: SELinux removed from desktop cd spin? References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <16de708d0801161316v66d0d49ch2508c29cb25e4abd@mail.gmail.com> <478E880F.1040408@gmail.com> <20080116230731.GA15477@dspnet.fr.eu.org> Message-ID: Olivier Galibert writes: > You realize smolt misses most if not all kickstart or otherwise > automatic/semiautomatic installs, right? Also, many people keep smolt disabled on their servers, simply because it's still new and an unnecessary service. Does smolt just work if you yum install it by the way, or does it need configuring? /Benny From ssorce at redhat.com Thu Jan 17 13:33:36 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 17 Jan 2008 08:33:36 -0500 Subject: Fedora Enhancement!! In-Reply-To: <1200558457.9899.3.camel@ignacio.lan> References: <1200399722.14798.9.camel@localhost.localdomain> <200801151346.45228.singularitaet@gmx.net> <478EFE03.7000708@gmail.com> <1200558457.9899.3.camel@ignacio.lan> Message-ID: <1200576816.10767.52.camel@localhost.localdomain> On Thu, 2008-01-17 at 03:27 -0500, Ignacio Vazquez-Abrams wrote: > On Thu, 2008-01-17 at 08:04 +0100, Valent Turkovic wrote: > > Why isn't fedora packaging uvc webcam drivers? On ubuntu my webcams work > > (uvc driver) but under fedora they don't :( > > uvc driver should have gone into main kernel but they prologued that for > > unknown amount of time. > > It's going into 2.6.25, so maybe if you ask *real* nicely... May I ask real nicely? I use Logitech webcams that are supported only by this driver to see (ekiga) my relatives on the other side of the ocean. It's a bit problematic to upgrade their system without that driver being in fedora :-) Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From benny+usenet at amorsen.dk Thu Jan 17 13:34:23 2008 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Thu, 17 Jan 2008 14:34:23 +0100 Subject: Smolt and Kickstart References: <7f692fec0801161730x35d8d2dfubd2bb07d21871da9@mail.gmail.com> <604aa7910801161821l738ecad2lb6e1fa523ae13e90@mail.gmail.com> <7f692fec0801161839s272941b5i8db12c02b4626850@mail.gmail.com> <478EC869.4070100@ncsu.edu> <7f692fec0801162121m4e3f0b1bwf312dc66e6c15c35@mail.gmail.com> Message-ID: "Yaakov Nemoy" writes: > That doesn't actually set up the monthly submissions. Furthermore, > we're going to start filtering by submission date. Anything older > than 35 days is going to be considered 'not running'. > The solution is to add a hook into kickstart that handles all the > other firstboot options, that also handles smolt. How about just adding a file to /etc/cron.monthly in the rpm? Does smolt really need to interact with the user at some point? /Benny From ndbecker2 at gmail.com Thu Jan 17 13:36:10 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 17 Jan 2008 08:36:10 -0500 Subject: tex4ht status? Message-ID: Is there a tex4ht working with texlive in rawhide? (There is a tetex-tex4ht in rawhide, but I know there were issues with integration with texlive) From gilboad at gmail.com Thu Jan 17 13:55:26 2008 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 17 Jan 2008 15:55:26 +0200 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478E8551.1030907@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116200333.GE15623@redhat.com> <64b14b300801161219q355d93b0jb57f91f48615591a@mail.gmail.com> <20080116202554.GF15623@redhat.com> <64b14b300801161235i4a4ed432h4f7b81ecefaf292b@mail.gmail.com> <478E8551.1030907@gmail.com> Message-ID: <1200578126.5005.23.camel@gilboa-work-dev.localdomain> On Wed, 2008-01-16 at 14:29 -0800, Andrew Farris wrote: > Valent Turkovic wrote: [snip] > Sooner or later there WILL be increasing threats to linux and its quite possible > to have virii spread in the wild... if good protections against it are not > developed and supported now then when? After they show up? Let alone the fact the having SELinux enabled by default might discourage (some) virus writers from even trying to target Linux - reducing the risk even further... - Gilboa From valent.turkovic at gmail.com Thu Jan 17 14:09:29 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 17 Jan 2008 15:09:29 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <1200555977.4103.16.camel@nebula> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116210016.GA10162@devserv.devel.redhat.com> <1200518035.5766.2.camel@localhost> <1200518850.3277.5.camel@localhost.localdomain> <64b14b300801161335o1f27cf76t3affe31e8aae02ab@mail.gmail.com> <604aa7910801161400k2e3ea6d6r3706a721a9106aed@mail.gmail.com> <478F018F.50009@gmail.com> <1200555977.4103.16.camel@nebula> Message-ID: <478F6199.9070605@gmail.com> Vladimir N Kosovac wrote: > On Thu, 2008-01-17 at 08:19 +0100, Valent Turkovic wrote: >> Jeff Spaleta wrote: >>> On Jan 16, 2008 12:35 PM, Valent Turkovic wrote: >>>> What is your target audience with SELinux? >>> Everyone who runs a computer that takes input from an external source, >>> whether that be floppies, or a network connection, or a bluetooth >>> keyboard. Security matters... it doesn't matter if you are a desktop >>> user or not... security matters. If we are doing a good enough job at >>> policy writing and management then we fix the policies. >> Will fedora include virus scanners? If not why? >> > yum search clamav I ment by default like SELinux. > I think you need to go a step (or two) back and re-read what people are > saying about the reasoning behind SElinux enforcing by default. > > It is a good thing and a positive shift in the right direction. It does > not cause many problems anymore but if, in some cases, it does, > everybody is free to turn it off if not willing to help developers to > make it better by filing a bug. You can disable it, as you know, at > install time as well. > > Comparing Fedora to other distributions is meaningless. Every distro has > its own reasons to package stuff as they do. Fedora is not in a business I'm not comparing Fedora distro as a hole! Why doesn't nobody get the point?!? I'm just talking about Fedora Destop spin. Valent. From jima at beer.tclug.org Thu Jan 17 14:13:05 2008 From: jima at beer.tclug.org (Jima) Date: Thu, 17 Jan 2008 08:13:05 -0600 (CST) Subject: Fedora 8/ARM available In-Reply-To: References: <20080114233331.GL17358@xi.wantstofly.org> <20080116203330.787a06dc@zod.rchland.ibm.com> Message-ID: On Thu, 17 Jan 2008, Gianluca Sforna wrote: > On Jan 17, 2008 3:33 AM, Josh Boyer wrote: >> On Tue, 15 Jan 2008 00:33:31 +0100 >> Lennert Buytenhek wrote: >>> >>> A HOWTO which describes getting Fedora/ARM running in QEMU is here: >>> http://fedoraproject.org/wiki/Architectures/ARM/HowToQemu >> >> How long until you have instructions on installing Fedora on the >> n800/n810? :) > > Don't forget about my Linksys NSLU2... I'd love to get Fedora on my NSLU2 -- although that'll probably require me to find/buy a USB hard drive. :-) Jima From valent.turkovic at gmail.com Thu Jan 17 14:13:46 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 17 Jan 2008 15:13:46 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478F0369.8050602@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116210016.GA10162@devserv.devel.redhat.com> <1200518035.5766.2.camel@localhost> <1200518850.3277.5.camel@localhost.localdomain> <64b14b300801161335o1f27cf76t3affe31e8aae02ab@mail.gmail.com> <478F00AF.2080206@gmail.com> <478F0369.8050602@gmail.com> Message-ID: <478F629A.1070701@gmail.com> Andrew Farris wrote: > Valent Turkovic wrote: >> Those are just a nonsense quotes as yours. I understand security. I >> also understand desktop usability. I believe that SELinux it too raw >> for general purpose desktop. Give it a year or two to mature and maybe >> then. > > How is this 'maturing' process supposed to occur when the vast majority > of general purpose users are not even trying it? The rawhide testers > using it on a daily basis cannot possibly invoke all the possible > combinations of operations that lead to selinux issues, and they don't > have all the proprietary software to install and find out what happens. > When a user tries it and runs into problems, they can turn it off. When > a user never tries it, the problems stay hidden (and no thats not a > better result). > I believe that Fedora has some guidelines how some technology gets tested? Surely not by showing it to peoples faces and making them deal with it. I saw lost of examples where fedora devels have pulled out some feature because it wasn't mature and was getting in way of usability. I don't get why is this case any different. Again I'm not talking about general fedora distro, only Desktop spin. Valent. From valent.turkovic at gmail.com Thu Jan 17 14:22:11 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 17 Jan 2008 15:22:11 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <1200578126.5005.23.camel@gilboa-work-dev.localdomain> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116200333.GE15623@redhat.com> <64b14b300801161219q355d93b0jb57f91f48615591a@mail.gmail.com> <20080116202554.GF15623@redhat.com> <64b14b300801161235i4a4ed432h4f7b81ecefaf292b@mail.gmail.com> <478E8551.1030907@gmail.com> <1200578126.5005.23.camel@gilboa-work-dev.localdomain> Message-ID: <478F6493.60601@gmail.com> Gilboa Davara wrote: > On Wed, 2008-01-16 at 14:29 -0800, Andrew Farris wrote: >> Valent Turkovic wrote: > [snip] >> Sooner or later there WILL be increasing threats to linux and its quite possible >> to have virii spread in the wild... if good protections against it are not >> developed and supported now then when? After they show up? > > Let alone the fact the having SELinux enabled by default might > discourage (some) virus writers from even trying to target Linux - > reducing the risk even further... What virus writers? linux desktops are that much more secure that I really don't see any benefit - just the opposite for a desktop spin of fodora to have such an invasive security tool as SELinux. On the server every security measure is welcome. Are you really saying that there are any actual threats in the wild that have spread on linux desktops? I think not, and can't see that being any different in next 5 years. So keep developing SELinux and test it in the non desktop spins while tools mature enough to be usable to general linux users on desktop. Valent. From loupgaroublond at gmail.com Thu Jan 17 14:29:21 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 17 Jan 2008 09:29:21 -0500 Subject: Smolt and Kickstart In-Reply-To: References: <7f692fec0801161730x35d8d2dfubd2bb07d21871da9@mail.gmail.com> <604aa7910801161821l738ecad2lb6e1fa523ae13e90@mail.gmail.com> <7f692fec0801161839s272941b5i8db12c02b4626850@mail.gmail.com> <478EC869.4070100@ncsu.edu> <7f692fec0801162121m4e3f0b1bwf312dc66e6c15c35@mail.gmail.com> Message-ID: <7f692fec0801170629u7c1e4584i49f5e8a424e33817@mail.gmail.com> On Jan 17, 2008 8:34 AM, Benny Amorsen wrote: > "Yaakov Nemoy" writes: > > The solution is to add a hook into kickstart that handles all the > > other firstboot options, that also handles smolt. > > How about just adding a file to /etc/cron.monthly in the rpm? Does > smolt really need to interact with the user at some point? We require the user to opt-in. Therefore we must interact with the user at *some* point. -Yaakov From valent.turkovic at gmail.com Thu Jan 17 14:31:48 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 17 Jan 2008 15:31:48 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <200801171321.29240.opensource@till.name> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116202554.GF15623@redhat.com> <64b14b300801161235i4a4ed432h4f7b81ecefaf292b@mail.gmail.com> <200801171321.29240.opensource@till.name> Message-ID: <478F66D4.7040901@gmail.com> Till Maas wrote: > On Wed January 16 2008, Valent Turkovic wrote: > >> Dan you are taking this the wrong way. Of course SElinux is great, of >> course it prevents from 0day exploits, no body is challenging that. >> But what was the real threat to average desktop users? Has anybody >> made use of this 0day exploit threat? is there a linux virus in the >> wild that spread like wildfire that took down r all desktops that didn't >> use SELinux? > > The desktop users are the threat, e.g. in internet cafes or computer pools in > universities or libraries. > > Regards, > Till > Also for internet caffes I believe that Ubuntu with LTS is much viable option that fedora with it's too short life cycle. Valent. From galibert at pobox.com Thu Jan 17 14:32:16 2008 From: galibert at pobox.com (Olivier Galibert) Date: Thu, 17 Jan 2008 15:32:16 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478F6493.60601@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116200333.GE15623@redhat.com> <64b14b300801161219q355d93b0jb57f91f48615591a@mail.gmail.com> <20080116202554.GF15623@redhat.com> <64b14b300801161235i4a4ed432h4f7b81ecefaf292b@mail.gmail.com> <478E8551.1030907@gmail.com> <1200578126.5005.23.camel@gilboa-work-dev.localdomain> <478F6493.60601@gmail.com> Message-ID: <20080117143216.GA49530@dspnet.fr.eu.org> On Thu, Jan 17, 2008 at 03:22:11PM +0100, Valent Turkovic wrote: > What virus writers? linux desktops are that much more secure that I > really don't see any benefit Not for long. You're training the users to type the root password and/or click "do it anyway" when popups ask for it. OG. From kirantpatil at gmail.com Thu Jan 17 14:33:37 2008 From: kirantpatil at gmail.com (Kiran Patil) Date: Thu, 17 Jan 2008 20:03:37 +0530 Subject: KSCSOPE Support in Fedora Message-ID: Hello All, Thanks for making wonderfull Distribution. As we are doing kernel hacking, we found that KSCOPE app is really worth and tried our hand in Fedora. I am sad to say that it has not been ported to either Fedora or any Redhat Linux clones. We would like to see it in Fedora as soon as possible. Since Fedora is not supporting KSCOPE, we are using Ubuntu for our development. Thanks, Kiran. -------------- next part -------------- An HTML attachment was scrubbed... URL: From loupgaroublond at gmail.com Thu Jan 17 14:34:19 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 17 Jan 2008 09:34:19 -0500 Subject: Smolt and Kickstart (Was:SELinux removed from desktop cd spin?) In-Reply-To: <478EEE36.4040600@gmail.com> References: <7f692fec0801161730x35d8d2dfubd2bb07d21871da9@mail.gmail.com> <604aa7910801161821l738ecad2lb6e1fa523ae13e90@mail.gmail.com> <7f692fec0801161839s272941b5i8db12c02b4626850@mail.gmail.com> <478EC869.4070100@ncsu.edu> <7f692fec0801162121m4e3f0b1bwf312dc66e6c15c35@mail.gmail.com> <478EEE36.4040600@gmail.com> Message-ID: <7f692fec0801170634tab55388pccc19035358fdded@mail.gmail.com> On Jan 17, 2008 12:57 AM, Andrew Farris wrote: > Yaakov Nemoy wrote: > > On Jan 16, 2008 10:15 PM, Casey Dahlin wrote: > >> You can opt in by running smoltSendProfile in your post-install script. > >> We just need to advertise this. > > > > That doesn't actually set up the monthly submissions. Furthermore, > > we're going to start filtering by submission date. Anything older > > than 35 days is going to be considered 'not running'. > > Hopefully 'not running' is nothing more than another flag here... not to be > confused with 'removed from the database'? If that is going to be more than a > filter, something longer than 35 days would probably be better. By not running, it means the unique System + OS Install are no longer running. Maybe the user installed a new OS, or doesn't use that machine. A running machine updates its profile with smolts.org every 30 days by default. 35 days is a metric that means the computer has not been updated because a) smolt is disabled or b) the computer is not running. We haven't decided if we want to purge old data yet, but we're going to rewrite our queries to give more up to date information. The only edge case is a computer that is operational less than once a month. I'm not going to consider working around this. -Yaakov From vonbrand at inf.utfsm.cl Thu Jan 17 13:16:27 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Thu, 17 Jan 2008 10:16:27 -0300 Subject: Cast your vote for the Fedora 9 Codename! In-Reply-To: <1200536182.920.64.camel@calliope.phig.org> References: <20080116184835.1bddf0f3@zod.rchland.ibm.com> <1200536182.920.64.camel@calliope.phig.org> Message-ID: <200801171318.m0HDGRqx011867@laptop13.inf.utfsm.cl> Karsten 'quaid' Wade wrote: > On Wed, 2008-01-16 at 18:48 -0600, Josh Boyer wrote: > > We have several options for the Fedora 9 codename, and you get to help > > decide which we use! > > Once again I am at a complete loss as to the meanings of the various > choices. Google and/or Wikipedia are your friends. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From vonbrand at inf.utfsm.cl Thu Jan 17 13:47:56 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Thu, 17 Jan 2008 10:47:56 -0300 Subject: rawhide report: 20080116 changes In-Reply-To: References: <200801161639.m0GGdexE021103@porkchop.devel.redhat.com> Message-ID: <200801171349.m0HDluOP013322@laptop13.inf.utfsm.cl> Jason L Tibbitts III wrote: > >>>>> "KK" == Kevin Kofler writes: > > KK> Huh? What's that doing in a Fedora package? > > What do you mean? Do you feel this is somehow unacceptable? > > KK> It's plain data, isn't it? > > It's data for use with other packages in the distribution. > > KK> Are we going to get a R-BSgenome.*.UCSC.ce* package for every > KK> species in existence? ;-) > > Only the ones which have been sequenced. I think there are three or > four of them available. While I'm not against including genome data, this is a very specialized area... perhaps a separate YUM repo for such stuff? Copies of this will have to be carried by each and every mirror. Next step will be to include all of iBiblio's collection of literary works that are now in the public domain? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From valent.turkovic at gmail.com Thu Jan 17 14:36:33 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 17 Jan 2008 15:36:33 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <20080117143216.GA49530@dspnet.fr.eu.org> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116200333.GE15623@redhat.com> <64b14b300801161219q355d93b0jb57f91f48615591a@mail.gmail.com> <20080116202554.GF15623@redhat.com> <64b14b300801161235i4a4ed432h4f7b81ecefaf292b@mail.gmail.com> <478E8551.1030907@gmail.com> <1200578126.5005.23.camel@gilboa-work-dev.localdomain> <478F6493.60601@gmail.com> <20080117143216.GA49530@dspnet.fr.eu.org> Message-ID: <478F67F1.3050007@gmail.com> Olivier Galibert wrote: > On Thu, Jan 17, 2008 at 03:22:11PM +0100, Valent Turkovic wrote: >> What virus writers? linux desktops are that much more secure that I >> really don't see any benefit > > Not for long. You're training the users to type the root password > and/or click "do it anyway" when popups ask for it. > > OG. > I'm training users?!? What are you talking about? I said no such thing! Valent. From jspaleta at gmail.com Thu Jan 17 14:37:25 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 17 Jan 2008 05:37:25 -0900 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478F629A.1070701@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116210016.GA10162@devserv.devel.redhat.com> <1200518035.5766.2.camel@localhost> <1200518850.3277.5.camel@localhost.localdomain> <64b14b300801161335o1f27cf76t3affe31e8aae02ab@mail.gmail.com> <478F00AF.2080206@gmail.com> <478F0369.8050602@gmail.com> <478F629A.1070701@gmail.com> Message-ID: <604aa7910801170637j71b3f6d3q829cc64f60cc6ea8@mail.gmail.com> On Jan 17, 2008 5:13 AM, Valent Turkovic wrote: > Again I'm not talking about general fedora distro, only Desktop spin. I garuantee you that people understand the argument you are making. And I'm pretty sure that you haven't actually come up with a new line of reasoning that hasn't already been considered previously. It comes down to this. You either value the selinux technology for a specific usage case, or your don't. If you value it, then you must support Fedora having it enabled by default because Fedora so that we can continue to refine it through more feedback. If you don't value it as a technology for the usage case you are interested in then you aren't ever going to really be comfortable with it being included at all. So clearly you don't value it. And clearly I do. Continuing to run in circles about this for another 300 posts isn't going to go anywhere because at a pretty fundamental level our assumptions about what is important are vastly different. But you know what, my opinion and your opinion are really not that important. What I care about in terms of project direction is what the security experts and the expert interface designers think. We must find a way to continue to incrementally make dealing with selinux easier. I'd rather get the right people in a room somewhere to sit down and discuss selinux desktop integration away from the noise and pitchforks in a mailinglist, and then move forward from there. You and I are not the right people. -jef From jspaleta at gmail.com Thu Jan 17 14:39:34 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 17 Jan 2008 05:39:34 -0900 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478F66D4.7040901@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116202554.GF15623@redhat.com> <64b14b300801161235i4a4ed432h4f7b81ecefaf292b@mail.gmail.com> <200801171321.29240.opensource@till.name> <478F66D4.7040901@gmail.com> Message-ID: <604aa7910801170639l1268828ci7f989abe92bd11cb@mail.gmail.com> On Jan 17, 2008 5:31 AM, Valent Turkovic wrote: > Also for internet caffes I believe that Ubuntu with LTS is much viable > option that fedora with it's too short life cycle. And I believe that virtualization will make this comment moot soon enough. -jef From buytenh at wantstofly.org Thu Jan 17 14:40:43 2008 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Thu, 17 Jan 2008 15:40:43 +0100 Subject: [fedora-arm] Re: Fedora 8/ARM available In-Reply-To: <478F106E.90509@linux-kernel.at> References: <20080114233331.GL17358@xi.wantstofly.org> <478F106E.90509@linux-kernel.at> Message-ID: <20080117144043.GB13114@xi.wantstofly.org> On Thu, Jan 17, 2008 at 09:23:10AM +0100, Oliver Falk wrote: > > We are proud to announce the availability of a(n unofficial) > > Fedora 8 package repository for the ARM architecture. > > > > The package repository has been built for ARMv5 EABI, soft-float, > > little endian. The majority of the important and frequently used > > Fedora packages have been built for ARM. > > > > The Fedora/ARM architecture wiki page has more info: > > http://fedoraproject.org/wiki/Architectures/ARM > > > > The easiest way to start using Fedora 8/ARM is to download the > > prebuilt root filesystem, which can be booted in QEMU, or chroot'ed > > into or booted from on any ARMv5 or later processor running in little > > endian mode. Additional packages can be installed by using yum, > > which is provided in the filesystem. > > > > A HOWTO which describes getting Fedora/ARM running in QEMU is here: > > http://fedoraproject.org/wiki/Architectures/ARM/HowToQemu > > > > There currently are a handful of known issues, which are described at: > > http://fedoraproject.org/wiki/Architectures/ARM/TODO > > > > Please help us by using the Fedora/ARM port and reporting any issues > > you run into so that we can fix them. > > I should have bought something else/bigger than my WRT54, I guess :-) Isn't the WRT54 MIPS based with 4M of RAM or so? :) From buytenh at wantstofly.org Thu Jan 17 14:46:19 2008 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Thu, 17 Jan 2008 15:46:19 +0100 Subject: [fedora-arm] Re: Fedora 8/ARM available In-Reply-To: <1200557523.9954.62.camel@Jehannum> References: <20080114233331.GL17358@xi.wantstofly.org> <1200557523.9954.62.camel@Jehannum> Message-ID: <20080117144619.GC13114@xi.wantstofly.org> On Thu, Jan 17, 2008 at 08:12:03AM +0000, Caolan McNamara wrote: > > We are proud to announce the availability of a(n unofficial) > > Fedora 8 package repository for the ARM architecture. > > > > The package repository has been built for ARMv5 EABI, soft-float, > > little endian. The majority of the important and frequently used > > Fedora packages have been built for ARM. > > FWIW, I ported OOo to arm-eabi last year, the "vanilla" rpms of the time > are at... > http://ooo.services.openoffice.org/pub/OpenOffice.org/cws/upload/armeabiport01/ > and that work is now integrated into 2.4.0 as in rawhide so in theory > for F9 it should build out of the box. Cool! Is there any place that documents the changes necessary for 2.3 so that we can also provide a (separate) set of 2.3 rpms for F8? > At the time there was no ecj/libgcj port to arm-eabi so the extra flag > to OOo's configure required to workaround that was --without-java, I > see java-1.5.0-gcj-devel in the repo now so that's presumably > unnecessary now. Yep, in theory. :) From pbrobinson at gmail.com Thu Jan 17 14:48:56 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 17 Jan 2008 14:48:56 +0000 Subject: [fedora-arm] Re: Fedora 8/ARM available In-Reply-To: <20080117144043.GB13114@xi.wantstofly.org> References: <20080114233331.GL17358@xi.wantstofly.org> <478F106E.90509@linux-kernel.at> <20080117144043.GB13114@xi.wantstofly.org> Message-ID: <5256d0b0801170648n6ac4cbf4ya67d9c09b3698fe4@mail.gmail.com> On Jan 17, 2008 2:40 PM, Lennert Buytenhek wrote: > On Thu, Jan 17, 2008 at 09:23:10AM +0100, Oliver Falk wrote: > > > > We are proud to announce the availability of a(n unofficial) > > > Fedora 8 package repository for the ARM architecture. > > > > > > The package repository has been built for ARMv5 EABI, soft-float, > > > little endian. The majority of the important and frequently used > > > Fedora packages have been built for ARM. > > > > > > The Fedora/ARM architecture wiki page has more info: > > > http://fedoraproject.org/wiki/Architectures/ARM > > > > > > The easiest way to start using Fedora 8/ARM is to download the > > > prebuilt root filesystem, which can be booted in QEMU, or chroot'ed > > > into or booted from on any ARMv5 or later processor running in little > > > endian mode. Additional packages can be installed by using yum, > > > which is provided in the filesystem. > > > > > > A HOWTO which describes getting Fedora/ARM running in QEMU is here: > > > http://fedoraproject.org/wiki/Architectures/ARM/HowToQemu > > > > > > There currently are a handful of known issues, which are described at: > > > http://fedoraproject.org/wiki/Architectures/ARM/TODO > > > > > > Please help us by using the Fedora/ARM port and reporting any issues > > > you run into so that we can fix them. > > > > I should have bought something else/bigger than my WRT54, I guess :-) > > Isn't the WRT54 MIPS based with 4M of RAM or so? :) Yes I think so. They're Broadcom chips which I'm pretty sure uses a MIPS32 core. But on the other hand my Dlink DNS-323 is a 500Hmz Marvell ARM chip. A storage Fedora sub distro would be cool. Peter From valent.turkovic at gmail.com Thu Jan 17 14:26:48 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 17 Jan 2008 15:26:48 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <200801171321.29240.opensource@till.name> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116202554.GF15623@redhat.com> <64b14b300801161235i4a4ed432h4f7b81ecefaf292b@mail.gmail.com> <200801171321.29240.opensource@till.name> Message-ID: <478F65A8.7090503@gmail.com> Till Maas wrote: > On Wed January 16 2008, Valent Turkovic wrote: > >> Dan you are taking this the wrong way. Of course SElinux is great, of >> course it prevents from 0day exploits, no body is challenging that. >> But what was the real threat to average desktop users? Has anybody >> made use of this 0day exploit threat? is there a linux virus in the >> wild that spread like wildfire that took down all desktops that didn't >> use SELinux? > > The desktop users are the threat, e.g. in internet cafes or computer pools in > universities or libraries. Come on, you stretching it waaaay to much. I believe that universities would go a more corporate way with support - something like SLED maybe, since RedHat doesn't provide any corporate desktop and fedora it too cutting edge for such institutions. Look just at evolution, is has much more bugs now in Fedora 8 that in Fedora Core 6 (yes I filed bugs). Nobody sane doesn't install fedora on such large numbers of desktops without any support. Valent. From jspaleta at gmail.com Thu Jan 17 14:49:45 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 17 Jan 2008 05:49:45 -0900 Subject: Smolt and Kickstart (Was:SELinux removed from desktop cd spin?) In-Reply-To: References: <7f692fec0801161730x35d8d2dfubd2bb07d21871da9@mail.gmail.com> <604aa7910801161821l738ecad2lb6e1fa523ae13e90@mail.gmail.com> <7f692fec0801161839s272941b5i8db12c02b4626850@mail.gmail.com> <478EC869.4070100@ncsu.edu> Message-ID: <604aa7910801170649v20194ad5mb1fee4c33ff06ba0@mail.gmail.com> On Jan 16, 2008 8:55 PM, Mike McGrath wrote: > We could do a better job with smolt education / advertisement. I think we could do a better job with kickstart education... more generally. -jef From valent.turkovic at gmail.com Thu Jan 17 14:53:59 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 17 Jan 2008 15:53:59 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <7f692fec0801161717x3b0d77b9n9cd4a2dd939c6398@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116200333.GE15623@redhat.com> <64b14b300801161219q355d93b0jb57f91f48615591a@mail.gmail.com> <20080116202554.GF15623@redhat.com> <64b14b300801161235i4a4ed432h4f7b81ecefaf292b@mail.gmail.com> <7f692fec0801161717x3b0d77b9n9cd4a2dd939c6398@mail.gmail.com> Message-ID: <478F6C07.2050108@gmail.com> Yaakov Nemoy wrote: > On Jan 16, 2008 3:35 PM, Valent Turkovic wrote: >> Dan you are taking this the wrong way. Of course SElinux is great, of >> course it prevents from 0day exploits, no body is challenging that. >> But what was the real threat to average desktop users? Has anybody >> made use of this 0day exploit threat? is there a linux virus in the >> wild that spread like wildfire that took down all desktops that didn't >> use SELinux? > > If a single Linux desktop goes down because of a 0day event, then > we've already failed at making a secure desktop. By that point, it's > too late. > > This is a failure, and we should do everything we can to make sure it > *never* happens. > > -Yaakov > Scaring people away from fedora desktop with too "paranoid" utilities is a good way to ensure that there are not too much users on it even if linux judgment 0day comes one day. Are you actually hoping to really protect from real threats? Not even SElinux can protect from rootkits. Are you actually saying that SELinux is security silver bullet? If you know anything about security you know that there is no silver bullet in security is it always a trade off in usability vs. security. No desktop spins for fedora I see no actual benefit and huge cost in user experience, usabillity and cost of valuable CD space. A quick googleing showed that security experts see SELinux like a backdor and as a problem just waiting to happed, and they suggest UNINSTALLING SElinux! "As a final note, I follow the logic of the grsecurity team, who claim that LSM and SELinux are backdoors waiting to happen." See the link: http://www.matasano.com/log/650/is-open-source-rootkit-detection-behind-the-curve/ Valent. From valent.turkovic at gmail.com Thu Jan 17 14:55:08 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 17 Jan 2008 15:55:08 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <604aa7910801170639l1268828ci7f989abe92bd11cb@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116202554.GF15623@redhat.com> <64b14b300801161235i4a4ed432h4f7b81ecefaf292b@mail.gmail.com> <200801171321.29240.opensource@till.name> <478F66D4.7040901@gmail.com> <604aa7910801170639l1268828ci7f989abe92bd11cb@mail.gmail.com> Message-ID: <478F6C4C.2000402@gmail.com> Jeff Spaleta wrote: > On Jan 17, 2008 5:31 AM, Valent Turkovic wrote: >> Also for internet caffes I believe that Ubuntu with LTS is much viable >> option that fedora with it's too short life cycle. > > And I believe that virtualization will make this comment moot soon enough. > > -jef > How? From ben.kreuter at gmail.com Thu Jan 17 14:59:14 2008 From: ben.kreuter at gmail.com (Benjamin Kreuter) Date: Thu, 17 Jan 2008 09:59:14 -0500 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478F65A8.7090503@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <200801171321.29240.opensource@till.name> <478F65A8.7090503@gmail.com> Message-ID: <200801170959.19021.ben.kreuter@gmail.com> On Thursday 17 January 2008 09:26:48 Valent Turkovic wrote: > Come on, you stretching it waaaay to much. I believe that universities > would go a more corporate way with support - something like SLED maybe, > since RedHat doesn't provide any corporate desktop and fedora it too > cutting edge for such institutions. > Red Hat does ship a corporate desktop, I have no idea where you got the idea that they don't. > Look just at evolution, is has much more bugs now in Fedora 8 that in > Fedora Core 6 (yes I filed bugs). Nobody sane doesn't install fedora on > such large numbers of desktops without any support. > Nobody sane installs a system like Fedora on a large scale or "mission critical" environment anyway. Fedora changes to often and too quickly. -- Benjamin Kreuter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From ben.kreuter at gmail.com Thu Jan 17 15:08:57 2008 From: ben.kreuter at gmail.com (Benjamin Kreuter) Date: Thu, 17 Jan 2008 10:08:57 -0500 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478F6C07.2050108@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <7f692fec0801161717x3b0d77b9n9cd4a2dd939c6398@mail.gmail.com> <478F6C07.2050108@gmail.com> Message-ID: <200801171009.02142.ben.kreuter@gmail.com> On Thursday 17 January 2008 09:53:59 Valent Turkovic wrote: > Are you actually saying that SELinux is security silver bullet? > If you know anything about security you know that there is no silver > bullet in security is it always a trade off in usability vs. security. > Which we try to mitigate with "permissive" mode. > A quick googleing showed that security experts see SELinux like a > backdor and as a problem just waiting to happed, and they suggest > UNINSTALLING SElinux! An even quicker search on Google reveals that RHEL5 with SELinux enabled and in enforcing mode has top security marks from the NSA, rivaled only by TrustedSolaris 10. > "As a final note, I follow the logic of the grsecurity team, who claim > that LSM and SELinux are backdoors waiting to happen." > Any program that provides security is a backdoor waiting to happen. What is your point? SELinux is meant to secure common exploits in other programs, such as Apache trying to write to /etc/passwd. Could SELinux be vulnerable? Sure. So could your keyboard driver. -- Benjamin Kreuter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From caolanm at redhat.com Thu Jan 17 15:23:44 2008 From: caolanm at redhat.com (Caolan McNamara) Date: Thu, 17 Jan 2008 15:23:44 +0000 Subject: [fedora-arm] Re: Fedora 8/ARM available In-Reply-To: <20080117144619.GC13114@xi.wantstofly.org> References: <20080114233331.GL17358@xi.wantstofly.org> <1200557523.9954.62.camel@Jehannum> <20080117144619.GC13114@xi.wantstofly.org> Message-ID: <1200583424.9954.114.camel@Jehannum> On Thu, 2008-01-17 at 15:46 +0100, Lennert Buytenhek wrote: > > Cool! Is there any place that documents the changes necessary for > 2.3 so that we can also provide a (separate) set of 2.3 rpms for F8? Should in theory just be http://people.redhat.com/caolanm/patches/workspace.armoabiport01.patch + http://people.redhat.com/caolanm/patches/workspace.armeabi01.patch Though if OOo fails to register components or start up then you might ?need to make additional changes to some makefile.mks that reference "VERSIONMAP" to reuse the i386 map files for arm, all of which was fixed up for 2.4. I don't remember if its strictly necessary to fix that in 2.3 or not. C. From valent.turkovic at gmail.com Thu Jan 17 15:27:22 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 17 Jan 2008 16:27:22 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <604aa7910801170637j71b3f6d3q829cc64f60cc6ea8@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116210016.GA10162@devserv.devel.redhat.com> <1200518035.5766.2.camel@localhost> <1200518850.3277.5.camel@localhost.localdomain> <64b14b300801161335o1f27cf76t3affe31e8aae02ab@mail.gmail.com> <478F00AF.2080206@gmail.com> <478F0369.8050602@gmail.com> <478F629A.1070701@gmail.com> <604aa7910801170637j71b3f6d3q829cc64f60cc6ea8@mail.gmail.com> Message-ID: <478F73DA.2030207@gmail.com> Jeff Spaleta wrote: > On Jan 17, 2008 5:13 AM, Valent Turkovic wrote: >> Again I'm not talking about general fedora distro, only Desktop spin. > > I garuantee you that people understand the argument you are making. > And I'm pretty sure that you haven't actually come up with a new line > of reasoning that hasn't already been considered previously. > > It comes down to this. You either value the selinux technology for a > specific usage case, or your don't. If you value it, then you must > support Fedora having it enabled by default because Fedora so that we > can continue to refine it through more feedback. If you don't value > it as a technology for the usage case you are interested in then you > aren't ever going to really be comfortable with it being included at > all. > > So clearly you don't value it. And clearly I do. Continuing to run > in circles about this for another 300 posts isn't going to go anywhere > because at a pretty fundamental level our assumptions about what is > important are vastly different. > > But you know what, my opinion and your opinion are really not that > important. What I care about in terms of project direction is what > the security experts and the expert interface designers think. We > must find a way to continue to incrementally make dealing with selinux > easier. I'd rather get the right people in a room somewhere to sit > down and discuss selinux desktop integration away from the noise and > pitchforks in a mailinglist, and then move forward from there. You > and I are not the right people. Jeff I completely agree with you, it is not on me or you to decide, but I thing that this discussion really needs to happen because fedora currently has lost it's focus. It is not a server distro, it is not desktop focused distro - nobody knows what exacly fedora should be used for. So I hoped that Fedora desktop spin will have some clear focus - the desktop as the name suggests, but it looks much more to me like it should be called just Fedora light. There is no real difference (only NetworkManager turner on by default on desktop spin) in Fedora and Fedora Desktop spin. I don't agree that security experts should decide if SELinux should go or not on Fedora Desktop spin or should it be on/off by default but some team of people who have a clear vision what Fedora Desktop experience should be about. They should look real hard at the the costs to usability vs. security benefits on desktop. What are the real security issues on desktop? OpenOffice exploits? Gnome expoits? What? You aren't running apache, mysql and php on desktop and those services shouldn't be running. Maybe ssh is running and that can be hardened really easily with firewall rules. What is actual threat that SELinux prevents on Fedora Desktop? Is it just there because SELinux exists and it makes things secure in general but also gets in way of user experience? That is a poor excuse IMHO. Valent. From mschmidt at redhat.com Thu Jan 17 15:38:57 2008 From: mschmidt at redhat.com (Michal Schmidt) Date: Thu, 17 Jan 2008 16:38:57 +0100 Subject: KSCSOPE Support in Fedora In-Reply-To: References: Message-ID: <20080117163857.21697df3@brian.englab.brq.redhat.com> On Thu, 17 Jan 2008 20:03:37 +0530 "Kiran Patil" wrote: > Hello All, > > Thanks for making wonderfull Distribution. > > As we are doing kernel hacking, we found that KSCOPE app is really > worth and tried our hand in Fedora. You mean this one?: http://kscope.sourceforge.net/ > I am sad to say that it has not been ported to either Fedora or any > Redhat Linux clones. > > We would like to see it in Fedora as soon as possible. Fedora is a distribution developed by an open community. Have you considered joining us and packaging the application for Fedora by yourself? See http://fedoraproject.org/wiki/PackageMaintainers/Join > Since Fedora is not supporting KSCOPE, we are using Ubuntu for our > development. > > Thanks, > Kiran. Michal From gilboad at gmail.com Thu Jan 17 15:47:42 2008 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 17 Jan 2008 17:47:42 +0200 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478F6493.60601@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116200333.GE15623@redhat.com> <64b14b300801161219q355d93b0jb57f91f48615591a@mail.gmail.com> <20080116202554.GF15623@redhat.com> <64b14b300801161235i4a4ed432h4f7b81ecefaf292b@mail.gmail.com> <478E8551.1030907@gmail.com> <1200578126.5005.23.camel@gilboa-work-dev.localdomain> <478F6493.60601@gmail.com> Message-ID: <1200584862.5005.50.camel@gilboa-work-dev.localdomain> On Thu, 2008-01-17 at 15:22 +0100, Valent Turkovic wrote: > Gilboa Davara wrote: > > On Wed, 2008-01-16 at 14:29 -0800, Andrew Farris wrote: > >> Valent Turkovic wrote: > > [snip] > >> Sooner or later there WILL be increasing threats to linux and its quite possible > >> to have virii spread in the wild... if good protections against it are not > >> developed and supported now then when? After they show up? > > > > Let alone the fact the having SELinux enabled by default might > > discourage (some) virus writers from even trying to target Linux - > > reducing the risk even further... > > What virus writers? linux desktops are that much more secure that I > really don't see any benefit - just the opposite for a desktop spin of > fodora to have such an invasive security tool as SELinux. On the server > every security measure is welcome. Secure? As I see it, you have type of threats: A. Network facing services corruption and/or privilege escalation.. B. Local application corruption and/or privilege escalation. C. Social engineering. (Please type the root password to install this amazing bouncing icon applet on your machine) You may, or may not be aware of it, but many desktop machines have open network facing services (1), such as SMB/NFS/NTP/SSH/etc, and we -all- open documents/spreadsheets/etc (2). While it's true that Linux (and *BSD) users tend to be security conscious (far more then Joe-Windows-user), making them less prune to 1,2 (and especially) 3, but having a 0-day exploit in Firefox, SMB or SSH can be just as destructive in the Linux world, as it is in the Windows world. In such as case, SELinux can be the only thing standing between a hacker and your data. > > Are you really saying that there are any actual threats in the wild that > have spread on linux desktops? Desktops? Less. Servers. Sure. > > I think not, and can't see that being any different in next 5 years. So > keep developing SELinux and test it in the non desktop spins while tools > mature enough to be usable to general linux users on desktop. -FAR- too late. SELinux is a very complicated piece of technology. When things break, you won't have the time to start mocking around with it. Last and not least, one of Fedora's main selling point -is- SELinux. If you can't be bothered to disable it (let alone learn how to operate/fix it), you shouldn't be using Fedora in the first place. Making user easier to use and configure? Sure. Dumbing it down? Hell no. - Gilboa From tim at niemueller.de Thu Jan 17 16:13:20 2008 From: tim at niemueller.de (Tim Niemueller) Date: Thu, 17 Jan 2008 17:13:20 +0100 Subject: firewall changes for F-9+ In-Reply-To: <20080117131211.GA3940@evileye.atkac.englab.brq.redhat.com> References: <478E4460.8040805@redhat.com> <1200528472.26259.63.camel@cookie.hadess.net> <20080117131211.GA3940@evileye.atkac.englab.brq.redhat.com> Message-ID: <478F7EA0.30508@niemueller.de> Adam Tkac schrieb: >> IpSec and IPP as services don't sound very much like desktop >> applications. They do if you have a desktop machine sharing a printer. If the system-config-printer tool would open up the IPP port automatically when you share a printer that would be fine though. > Definitely. Also mdns enabled on desktop doesn't make sence for me. I > think only ssh will be enabled on both server and desktop. DNS-SD over mDNS is used by Avahi for service discovery. Especially on a desktop/laptop you want to see the services other machines announce on the network like file shares (someone going to solve the firewall issue here?), VNC, printer etc.. I'd consider Avahi to be important for the "just works" network experience. Tim -- Tim Niemueller www.niemueller.de ================================================================= Imagination is more important than knowledge. (Albert Einstein) From galibert at pobox.com Thu Jan 17 16:23:30 2008 From: galibert at pobox.com (Olivier Galibert) Date: Thu, 17 Jan 2008 17:23:30 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478F73DA.2030207@gmail.com> References: <20080116210016.GA10162@devserv.devel.redhat.com> <1200518035.5766.2.camel@localhost> <1200518850.3277.5.camel@localhost.localdomain> <64b14b300801161335o1f27cf76t3affe31e8aae02ab@mail.gmail.com> <478F00AF.2080206@gmail.com> <478F0369.8050602@gmail.com> <478F629A.1070701@gmail.com> <604aa7910801170637j71b3f6d3q829cc64f60cc6ea8@mail.gmail.com> <478F73DA.2030207@gmail.com> Message-ID: <20080117162330.GA63424@dspnet.fr.eu.org> On Thu, Jan 17, 2008 at 04:27:22PM +0100, Valent Turkovic wrote: > What are the real security issues on desktop? OpenOffice exploits? Gnome > expoits? What? You aren't running apache, mysql and php on desktop and > those services shouldn't be running. Maybe you aren't. Your case is not a generality. Mediawiki is my notebook, and I'm not the only one. One of the strengths of Linux is that you can afford that kind of setup in the first place, and it's not even hard to do. OG. From pertusus at free.fr Thu Jan 17 16:36:40 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 17 Jan 2008 17:36:40 +0100 Subject: tex4ht status? In-Reply-To: References: Message-ID: <20080117163640.GB27862@free.fr> On Thu, Jan 17, 2008 at 08:36:10AM -0500, Neal Becker wrote: > Is there a tex4ht working with texlive in rawhide? (There is a tetex-tex4ht > in rawhide, but I know there were issues with integration with texlive) tetex-tex4ht should be working with texlive. There are no issues of integration. There may be bugs, however, but I still haven't seen any report. -- Pat From ben.kreuter at gmail.com Thu Jan 17 16:41:31 2008 From: ben.kreuter at gmail.com (Benjamin Kreuter) Date: Thu, 17 Jan 2008 11:41:31 -0500 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478F73DA.2030207@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <604aa7910801170637j71b3f6d3q829cc64f60cc6ea8@mail.gmail.com> <478F73DA.2030207@gmail.com> Message-ID: <200801171141.35222.ben.kreuter@gmail.com> On Thursday 17 January 2008 10:27:22 Valent Turkovic wrote: > > What are the real security issues on desktop? OpenOffice exploits? Gnome > expoits? What? You aren't running apache, mysql and php Really? I can think of a few apps that use Apache or MySQL on the desktop. The first that comes to mind is Amarok, which can use MySQL to manage information about your music collection -- and I even know someone whose music collection is so large that he had to use MySQL because SQLite was breaking. Just because you can't think of how these servers might be used at home doesn't mean that there is no use for them. It just means that you have different needs, and therefore haven't found yourself using them. > on desktop and > those services shouldn't be running. Maybe ssh is running and that can > be hardened really easily with firewall rules. Maybe OpenSSH has an exploit that allows a remote user to start writing to rc.local, allowing them to take control of a system once it reboots. SELinux solves that problem. > What is actual threat > that SELinux prevents on Fedora Desktop? It may not even be known; SELinux makes the system less vulnerable to an attack. It also helps expose apps that are doing things that could worsen an attack, like GDM trying to gain write access to /etc/passwd. > Is it just there because SELinux exists and it makes things secure in > general but also gets in way of user experience? That is a poor excuse > IMHO. It gets in the way of the user experience when the user is doing something potentially dangerous. Most of the complaints about other systems is that it is too easy for the user to expose themselves to viruses and worms, but the only way to truly prevent that is to get in the user's face when he does something like that. There really is no good argument against SELinux, especially with permissive mode available for people who don't want to be bothered tweaking ACLs for every single service they plan to use. It is also possible to disable SELinux entirely, if that is what you want to do. Disabling it on the desktop spin would only annoy the people who want it enabled, because they would then have to wait while their filesystem is scanned (it takes a very long time). -- B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From dwalsh at redhat.com Thu Jan 17 16:42:34 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 17 Jan 2008 11:42:34 -0500 Subject: SELinux removed from desktop cd spin? In-Reply-To: <64b14b300801161326l76fbca60pf806f9815db3fa@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116210016.GA10162@devserv.devel.redhat.com> <1200518035.5766.2.camel@localhost> <64b14b300801161326l76fbca60pf806f9815db3fa@mail.gmail.com> Message-ID: <478F857A.6030502@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Valent Turkovic wrote: > On Jan 16, 2008 10:13 PM, Dave Airlie wrote: >> On Wed, 2008-01-16 at 16:00 -0500, Alan Cox wrote: >>> On Wed, Jan 16, 2008 at 08:57:56PM +0100, Valent Turkovic wrote: >>>> I believe that SELinux is a great linux server security hardening tool >>>> but that has little use in desktop linux usage and it confuses >>>> ordinary desktop users. >>> Desktop users are the people it is most important for. If it is still confusing >>> people we need to fix the confusions. Perhaps you can explain more ? >>> >>> >> We made one big mistake with SELinux, selinuxalert or whatever it is >> called... we haven't learned from the MAC vs Windows ads... we now have >> an app that puts us squarely into the Windows lack of usefulness camp. >> >> "hey user this app is doing something bad. do you want to let it do >> it?"_t. > > I wish it was that easy when I installed fluendo codes I couldn't play > my multimedia because SELInux blocked it (nobody tested it even that > fedora 8 advertised fluendo codec support as one of its new shiny > features). > selinux troubleshoot tool it still to hard for ordinary desktop users. > I see the real benefit of SELinux troubleshoot tool for admins using > RHEL of fedora on their servers but on desktop I hardly see any point. > > I will bet anybody who wants that Fedora live cd users will have more > trouble from using SElinux than benefit. Also that ubuntu, opensuse > and other distros that don't use SElinux won't be in trouble from some > 0day exploit. > > Valent. > # setsebool -P allow_execmod=1 THis will turn off checking for badly coded shared libraries. (fluendo codecs and others.) Also make sure you are up2date with the latest policy. Finally make sure /var/log/ has the right context. restorecon -R -v /var/log logrotate had a bug where it was loosing file context. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkePhXoACgkQrlYvE4MpobN6BACg62mp19pUufL5EwKUhGSLcaww xZ0AoMHcROWszGaH17h/07SbPrFshfVM =SNMc -----END PGP SIGNATURE----- From limb at jcomserv.net Thu Jan 17 16:40:52 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 17 Jan 2008 10:40:52 -0600 (CST) Subject: KSCSOPE Support in Fedora In-Reply-To: <20080117163857.21697df3@brian.englab.brq.redhat.com> References: <20080117163857.21697df3@brian.englab.brq.redhat.com> Message-ID: <60603.63.85.68.164.1200588052.squirrel@mail.jcomserv.net> > On Thu, 17 Jan 2008 20:03:37 +0530 > "Kiran Patil" wrote: > >> Hello All, >> >> Thanks for making wonderfull Distribution. >> >> As we are doing kernel hacking, we found that KSCOPE app is really >> worth and tried our hand in Fedora. > > You mean this one?: http://kscope.sourceforge.net/ > >> I am sad to say that it has not been ported to either Fedora or any >> Redhat Linux clones. >> >> We would like to see it in Fedora as soon as possible. > > Fedora is a distribution developed by an open community. Have you > considered joining us and packaging the application for Fedora > by yourself? See http://fedoraproject.org/wiki/PackageMaintainers/Join Failing that, you could ask someone to put it on the: http://fedoraproject.org/wiki/PackageMaintainers/WishList as I've just done. >> Since Fedora is not supporting KSCOPE, we are using Ubuntu for our >> development. >> >> Thanks, >> Kiran. > > Michal > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From bkoz at redhat.com Thu Jan 17 16:57:45 2008 From: bkoz at redhat.com (Benjamin Kosnik) Date: Thu, 17 Jan 2008 10:57:45 -0600 Subject: Cast your vote for the Fedora 9 Codename! BE A MARFAN In-Reply-To: <1200536182.920.64.camel@calliope.phig.org> References: <20080116184835.1bddf0f3@zod.rchland.ibm.com> <1200536182.920.64.camel@calliope.phig.org> Message-ID: <20080117105745.350f5e71@wabash.artheist.org> > BTW, I understand one route is through "syndrome". While > 'Lycanthropy' is a syndrome/condition, 'Werewolf' is not. Maybe you are talking about Marfan here? If so, I propose another meaning for this candidate: one of the under 2,000 person who lives in Marfa, TX!!! Home to the Marfa lights and to an an eclectic collection of modern art (Donald Judd, and Warhol's Last supper paintings), close to the Mexico border (in case you need to make a run for it), on the high plains of the desert, and home to excellent thermals for ultra-light gliding. http://en.wikipedia.org/wiki/Marfa http://www.marfa.org/ Full disclosure, I'm a temporary Marfan and I voted for it. As a bonus, it's close enough to "martian" that most people will look askance when the name is uttered. -benjamin From pingoufc4 at yahoo.fr Thu Jan 17 15:40:00 2008 From: pingoufc4 at yahoo.fr (pingou) Date: Thu, 17 Jan 2008 16:40:00 +0100 Subject: rawhide report: 20080116 changes In-Reply-To: <200801171349.m0HDluOP013322@laptop13.inf.utfsm.cl> References: <200801161639.m0GGdexE021103@porkchop.devel.redhat.com> <200801171349.m0HDluOP013322@laptop13.inf.utfsm.cl> Message-ID: <478F76D0.4060308@yahoo.fr> Horst H. von Brand wrote: > Jason L Tibbitts III wrote: >>>>>>> "KK" == Kevin Kofler writes: >> KK> Huh? What's that doing in a Fedora package? >> >> What do you mean? Do you feel this is somehow unacceptable? >> >> KK> It's plain data, isn't it? >> >> It's data for use with other packages in the distribution. >> >> KK> Are we going to get a R-BSgenome.*.UCSC.ce* package for every >> KK> species in existence? ;-) >> >> Only the ones which have been sequenced. I think there are three or >> four of them available. > > While I'm not against including genome data, this is a very specialized > area... perhaps a separate YUM repo for such stuff? Copies of this will > have to be carried by each and every mirror. If we do so we end to the question Should we make a specific repo for each specific field and let the user pick the repo he is interested in. There will be then a repo for EPEL, a repo for Bioinformatics... but even, how would you distinguish the different repo ? Is electronic part of the EPEL, but I guess there are some software there that are used in others sciences... R is used in bioinformatics but can be also used for statistics or for data manipulation... Would you split the different libraries of R into different repo ? It is an idea but have to be investigated, and also the way for the user to find where are the software he is interested in... I see a big work there... Regards, Pierre ___________________________________________________________________________ Yahoo! Mail r?invente le mail ! D?couvrez le nouveau Yahoo! Mail et son interface r?volutionnaire. http://fr.mail.yahoo.com From kwade at redhat.com Thu Jan 17 17:37:18 2008 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Thu, 17 Jan 2008 09:37:18 -0800 Subject: Cast your vote for the Fedora 9 Codename! In-Reply-To: <200801171318.m0HDGRqx011867@laptop13.inf.utfsm.cl> References: <20080116184835.1bddf0f3@zod.rchland.ibm.com> <1200536182.920.64.camel@calliope.phig.org> <200801171318.m0HDGRqx011867@laptop13.inf.utfsm.cl> Message-ID: <1200591438.920.119.camel@calliope.phig.org> On Thu, 2008-01-17 at 10:16 -0300, Horst H. von Brand wrote: > Karsten 'quaid' Wade wrote: > > On Wed, 2008-01-16 at 18:48 -0600, Josh Boyer wrote: > > > We have several options for the Fedora 9 codename, and you get to help > > > decide which we use! > > > > Once again I am at a complete loss as to the meanings of the various > > choices. > > Google and/or Wikipedia are your friends. Time unfortunately is not. Since all this work has been done already by the community, why should each of us repeat the work? IIRC, there are >1000 potential voters. I'm presuming you can do the math yourself. If not, gnome-calculator is your friend. ;-) OTOH, we could take thrice the time to argue about whether I should repeat that work or not ... - Karsten -- Karsten Wade, Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jonstanley at gmail.com Thu Jan 17 17:48:27 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Thu, 17 Jan 2008 12:48:27 -0500 Subject: firewall changes for F-9+ In-Reply-To: <1200528472.26259.63.camel@cookie.hadess.net> References: <478E4460.8040805@redhat.com> <1200528472.26259.63.camel@cookie.hadess.net> Message-ID: On Jan 16, 2008 7:07 PM, Bastien Nocera wrote: > IpSec and IPP as services don't sound very much like desktop > applications. IPSec sounds reasonable since users may be using a VPN client in order to access a corporate or remote network. If not enabled by default, there needs to be something easy in s-c-firewall to enable it, since making IPSec work is a non-trivial endeavor. In the 'server' profile, though - it's absolute rubbish. If someone wants to run a VPN server, they should know enough about it to configure the firewall appropriately :) From galibert at pobox.com Thu Jan 17 18:02:51 2008 From: galibert at pobox.com (Olivier Galibert) Date: Thu, 17 Jan 2008 19:02:51 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478F857A.6030502@redhat.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116210016.GA10162@devserv.devel.redhat.com> <1200518035.5766.2.camel@localhost> <64b14b300801161326l76fbca60pf806f9815db3fa@mail.gmail.com> <478F857A.6030502@redhat.com> Message-ID: <20080117180251.GA77139@dspnet.fr.eu.org> On Thu, Jan 17, 2008 at 11:42:34AM -0500, Daniel J Walsh wrote: > # setsebool -P allow_execmod=1 > > THis will turn off checking for badly coded shared libraries. (fluendo > codecs and others.) Now that's a superb example of one of the things that suck with selinux: put "allow_execmod" in google and try to find a page that actually explain what it means. OG. From atkac at redhat.com Thu Jan 17 18:06:22 2008 From: atkac at redhat.com (Adam Tkac) Date: Thu, 17 Jan 2008 19:06:22 +0100 Subject: firewall changes for F-9+ In-Reply-To: References: <478E4460.8040805@redhat.com> <1200528472.26259.63.camel@cookie.hadess.net> Message-ID: <20080117180622.GA7367@evileye.atkac.englab.brq.redhat.com> On Thu, Jan 17, 2008 at 12:48:27PM -0500, Jon Stanley wrote: > On Jan 16, 2008 7:07 PM, Bastien Nocera wrote: > > > IpSec and IPP as services don't sound very much like desktop > > applications. > > IPSec sounds reasonable since users may be using a VPN client in order > to access a corporate or remote network. If not enabled by default, > there needs to be something easy in s-c-firewall to enable it, since > making IPSec work is a non-trivial endeavor. In the 'server' profile, > though - it's absolute rubbish. If someone wants to run a VPN server, > they should know enough about it to configure the firewall > appropriately :) > I think you don't need open ports for VPN clients. State firewall should take care about such situation, doesn't? Adam -- Adam Tkac, Red Hat, Inc. From opensource at till.name Thu Jan 17 18:20:27 2008 From: opensource at till.name (Till Maas) Date: Thu, 17 Jan 2008 19:20:27 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <20080117180251.GA77139@dspnet.fr.eu.org> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <478F857A.6030502@redhat.com> <20080117180251.GA77139@dspnet.fr.eu.org> Message-ID: <200801171920.32764.opensource@till.name> On Thu January 17 2008, Olivier Galibert wrote: > Now that's a superb example of one of the things that suck with > selinux: put "allow_execmod" in google and try to find a page that > actually explain what it means. Here the 6th result is: http://www.livejournal.com/go.bml?journal=danwalsh&itemid=13376&dir=next And on that page is a link to: http://people.redhat.com/~drepper/selinux-mem.html What are you missing there? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From seg at haxxed.com Thu Jan 17 18:23:20 2008 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 17 Jan 2008 12:23:20 -0600 Subject: firewall changes for F-9+ In-Reply-To: <20080117180622.GA7367@evileye.atkac.englab.brq.redhat.com> References: <478E4460.8040805@redhat.com> <1200528472.26259.63.camel@cookie.hadess.net> <20080117180622.GA7367@evileye.atkac.englab.brq.redhat.com> Message-ID: <1200594201.15354.17.camel@localhost> On Thu, 2008-01-17 at 19:06 +0100, Adam Tkac wrote: > I think you don't need open ports for VPN clients. State firewall > should take care about such situation, doesn't? In the case of IPSec, it is implemented as a distinct protocol directly on top of IP, so no. It does not run over TCP or UDP. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dmalcolm at redhat.com Thu Jan 17 18:35:04 2008 From: dmalcolm at redhat.com (David Malcolm) Date: Thu, 17 Jan 2008 13:35:04 -0500 Subject: SELinux removed from desktop cd spin? In-Reply-To: <200801171920.32764.opensource@till.name> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <478F857A.6030502@redhat.com> <20080117180251.GA77139@dspnet.fr.eu.org> <200801171920.32764.opensource@till.name> Message-ID: <1200594904.3259.143.camel@cassandra.boston.redhat.com> On Thu, 2008-01-17 at 19:20 +0100, Till Maas wrote: > On Thu January 17 2008, Olivier Galibert wrote: > > > Now that's a superb example of one of the things that suck with > > selinux: put "allow_execmod" in google and try to find a page that > > actually explain what it means. > > Here the 6th result is: > http://www.livejournal.com/go.bml?journal=danwalsh&itemid=13376&dir=next > And on that page is a link to: > http://people.redhat.com/~drepper/selinux-mem.html > > What are you missing there? To be fair, are the policy types and booleans actually documented somewhere? e.g. a set of manpages that could get autogenerated when the policy package is built? Does the policy source language support some kind of inline commenting that could be used doxygen-style to generate docs (and check doc coverage)? Obviously, this would be aimed more at the classic unix sysadmin rather than a desktop user From dwalsh at redhat.com Thu Jan 17 18:48:42 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 17 Jan 2008 13:48:42 -0500 Subject: SELinux removed from desktop cd spin? In-Reply-To: <1200594904.3259.143.camel@cassandra.boston.redhat.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <478F857A.6030502@redhat.com> <20080117180251.GA77139@dspnet.fr.eu.org> <200801171920.32764.opensource@till.name> <1200594904.3259.143.camel@cassandra.boston.redhat.com> Message-ID: <478FA30A.6030405@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Malcolm wrote: > On Thu, 2008-01-17 at 19:20 +0100, Till Maas wrote: >> On Thu January 17 2008, Olivier Galibert wrote: >> >>> Now that's a superb example of one of the things that suck with >>> selinux: put "allow_execmod" in google and try to find a page that >>> actually explain what it means. >> Here the 6th result is: >> http://www.livejournal.com/go.bml?journal=danwalsh&itemid=13376&dir=next >> And on that page is a link to: >> http://people.redhat.com/~drepper/selinux-mem.html >> >> What are you missing there? > > To be fair, are the policy types and booleans actually documented > somewhere? e.g. a set of manpages that could get autogenerated when the > policy package is built? Does the policy source language support some > kind of inline commenting that could be used doxygen-style to generate > docs (and check doc coverage)? Obviously, this would be aimed more at > the classic unix sysadmin rather than a desktop user > > >

Allow unconfined executables to map a memory region as both executable and writable, this is dangerous and the executable should be reported in bugzilla")

This is in policy and extracted out into /usr/share/selinux/devel/policy.xml But not currently in a man page. audit2why and setroubleshoot are starting to use these definitions in Fedora 9. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkePowoACgkQrlYvE4MpobMQ7gCgzo2UB2AGXEVFVvNjXIXIkhgJ sBAAoNcSNidCpD9R0IywUGX2BVAqb8Vh =ZLcT -----END PGP SIGNATURE----- From loupgaroublond at gmail.com Thu Jan 17 19:02:12 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 17 Jan 2008 14:02:12 -0500 Subject: Icons status for smolts.org In-Reply-To: <478F006C.1040301@thefinalzone.com> References: <478C39BA.2030801@thefinalzone.com> <7f692fec0801162134n532b2180lceddedbb8d5234d9@mail.gmail.com> <478F006C.1040301@thefinalzone.com> Message-ID: <7f692fec0801171102j4763b1e9s8dc1e0d6c2be7239@mail.gmail.com> On Jan 17, 2008 2:14 AM, Luya Tshimbalanga wrote: > Yaakov Nemoy a ?crit : > > We need a bit more art. I've left comments on the wiki. > > > > thanks again! > > > > Yaakov > > > Done. I have also included the modified dialog-cancel inside the tarball. > These look great. I'll commit them tonight probably. My one comment though is that it is still hard to tell the difference between dialog-close and dialog-close-unsaturated. -Yaakov From galibert at pobox.com Thu Jan 17 19:05:42 2008 From: galibert at pobox.com (Olivier Galibert) Date: Thu, 17 Jan 2008 20:05:42 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <200801171920.32764.opensource@till.name> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <478F857A.6030502@redhat.com> <20080117180251.GA77139@dspnet.fr.eu.org> <200801171920.32764.opensource@till.name> Message-ID: <20080117190542.GA84707@dspnet.fr.eu.org> On Thu, Jan 17, 2008 at 07:20:27PM +0100, Till Maas wrote: > On Thu January 17 2008, Olivier Galibert wrote: > > > Now that's a superb example of one of the things that suck with > > selinux: put "allow_execmod" in google and try to find a page that > > actually explain what it means. > > Here the 6th result is: > http://www.livejournal.com/go.bml?journal=danwalsh&itemid=13376&dir=next > And on that page is a link to: > http://people.redhat.com/~drepper/selinux-mem.html > > What are you missing there? A page called something like "SELinux memory protection configuration documentation" or "SELinux configration manpage" which is actually linked from google, not a blog post with a flameworthy title which easily goes under the radar, as it did for me. Incidentally, the link in the post is incorrect, there is an extra comma at the end. OG. From mjs at CLEMSON.EDU Thu Jan 17 19:05:51 2008 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Thu, 17 Jan 2008 19:05:51 +0000 Subject: firewall changes for F-9+ In-Reply-To: <478F7EA0.30508@niemueller.de> References: <478E4460.8040805@redhat.com> <1200528472.26259.63.camel@cookie.hadess.net> <20080117131211.GA3940@evileye.atkac.englab.brq.redhat.com> <478F7EA0.30508@niemueller.de> Message-ID: <1200596751.29217.87.camel@vincent52.localdomain> On Thu, 2008-01-17 at 17:13 +0100, Tim Niemueller wrote: > Adam Tkac schrieb: > >> IpSec and IPP as services don't sound very much like desktop > >> applications. > > They do if you have a desktop machine sharing a printer. If the > system-config-printer tool would open up the IPP port automatically when > you share a printer that would be fine though. Does the "sharee" also need the IPP ports open? So a user would need to explicitly set "show printers shared by other systems" in s-c-printers--it couldn't be the default. ISTR some discussion in the past of why it was a bad idea for s-c-printers to open and close the ipp and lpr ports. (Don't have a link handy, but I think there was a BZ about this issue). > > > Definitely. Also mdns enabled on desktop doesn't make sence for me. I > > think only ssh will be enabled on both server and desktop. > > DNS-SD over mDNS is used by Avahi for service discovery. Especially on a > desktop/laptop you want to see the services other machines announce on > the network like file shares (someone going to solve the firewall issue > here?), VNC, printer etc.. I'd consider Avahi to be important for the > "just works" network experience. > > Tim > -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From galibert at pobox.com Thu Jan 17 19:10:51 2008 From: galibert at pobox.com (Olivier Galibert) Date: Thu, 17 Jan 2008 20:10:51 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478FA30A.6030405@redhat.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <478F857A.6030502@redhat.com> <20080117180251.GA77139@dspnet.fr.eu.org> <200801171920.32764.opensource@till.name> <1200594904.3259.143.camel@cassandra.boston.redhat.com> <478FA30A.6030405@redhat.com> Message-ID: <20080117191051.GB84707@dspnet.fr.eu.org> On Thu, Jan 17, 2008 at 01:48:42PM -0500, Daniel J Walsh wrote: > > >

> Allow unconfined executables to map a memory region as both executable > and writable, this is dangerous and the executable should be reported in > bugzilla") That should be "to map a file in a memory region", as UD's page explains. Otherwise anyone who knows a little about dynamic recompilers/JITs is gonna go "huh?". OG. From seg at haxxed.com Thu Jan 17 19:11:24 2008 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 17 Jan 2008 13:11:24 -0600 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478F73DA.2030207@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116210016.GA10162@devserv.devel.redhat.com> <1200518035.5766.2.camel@localhost> <1200518850.3277.5.camel@localhost.localdomain> <64b14b300801161335o1f27cf76t3affe31e8aae02ab@mail.gmail.com> <478F00AF.2080206@gmail.com> <478F0369.8050602@gmail.com> <478F629A.1070701@gmail.com> <604aa7910801170637j71b3f6d3q829cc64f60cc6ea8@mail.gmail.com> <478F73DA.2030207@gmail.com> Message-ID: <1200597084.15354.43.camel@localhost> On Thu, 2008-01-17 at 16:27 +0100, Valent Turkovic wrote: > What are the real security issues on desktop? OpenOffice exploits? Gnome > expoits? What? You aren't running apache, mysql and php on desktop > and > those services shouldn't be running. Maybe ssh is running and that > can > be hardened really easily with firewall rules. What is actual threat > that SELinux prevents on Fedora Desktop? Well lets see. On the desktop, you have a web browser whose entire purpose is to take in massive amounts of untrusted data from the network, and hand it off to all sorts of libraries and plugins and helpers. Jpeg libraries, PNG libraries, the Totem plugin which can draw in *hundreds* of different AV codecs, Java plugins, and more than likely a proprietary Flash plugin. How much do you really trust Adobe? You also have PDFs and word documents, which users will be opening with Evince and OpenOffice, and quite possibly another proprietary Adobe binary... The typical Aunt Tillie is putting *millions* of lines of code in direct contact with *gigabytes* of untrusted and potentially hostile data coming in from all corners of the Internet. Now you tell me where the greatest security risk lies. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Thu Jan 17 19:22:57 2008 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 17 Jan 2008 13:22:57 -0600 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478F6C07.2050108@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116200333.GE15623@redhat.com> <64b14b300801161219q355d93b0jb57f91f48615591a@mail.gmail.com> <20080116202554.GF15623@redhat.com> <64b14b300801161235i4a4ed432h4f7b81ecefaf292b@mail.gmail.com> <7f692fec0801161717x3b0d77b9n9cd4a2dd939c6398@mail.gmail.com> <478F6C07.2050108@gmail.com> Message-ID: <1200597777.15354.47.camel@localhost> On Thu, 2008-01-17 at 15:53 +0100, Valent Turkovic wrote: > A quick googleing showed that security experts see SELinux like a > backdor and as a problem just waiting to happed, and they suggest > UNINSTALLING SElinux! > > "As a final note, I follow the logic of the grsecurity team, who claim > that LSM and SELinux are backdoors waiting to happen." > > See the link: > http://www.matasano.com/log/650/is-open-source-rootkit-detection-behind-the-curve/ Wow, some random idiot linking to another random idiot commenting on another random idiot's blog. A strong argument indeed. (Hey look, a random idiot wasting his time replying to a random idiot linking to another random idiot...) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jam at zoidtechnologies.com Thu Jan 17 19:23:23 2008 From: jam at zoidtechnologies.com (jam at zoidtechnologies.com) Date: Thu, 17 Jan 2008 14:23:23 -0500 Subject: SELinux removed from desktop cd spin? In-Reply-To: <1200597084.15354.43.camel@localhost> References: <1200518035.5766.2.camel@localhost> <1200518850.3277.5.camel@localhost.localdomain> <64b14b300801161335o1f27cf76t3affe31e8aae02ab@mail.gmail.com> <478F00AF.2080206@gmail.com> <478F0369.8050602@gmail.com> <478F629A.1070701@gmail.com> <604aa7910801170637j71b3f6d3q829cc64f60cc6ea8@mail.gmail.com> <478F73DA.2030207@gmail.com> <1200597084.15354.43.camel@localhost> Message-ID: <20080117192323.GO18982@zoidtechnologies.com> On Thu, Jan 17, 2008 at 01:11:24PM -0600, Callum Lerwick wrote: > Now you tell me where the greatest security risk lies. between the keyboard and the chair. -- http://zoidtechnologies.com/ -- websites that suck less From seg at haxxed.com Thu Jan 17 19:38:48 2008 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 17 Jan 2008 13:38:48 -0600 Subject: SELinux removed from desktop cd spin? In-Reply-To: <20080117192323.GO18982@zoidtechnologies.com> References: <1200518035.5766.2.camel@localhost> <1200518850.3277.5.camel@localhost.localdomain> <64b14b300801161335o1f27cf76t3affe31e8aae02ab@mail.gmail.com> <478F00AF.2080206@gmail.com> <478F0369.8050602@gmail.com> <478F629A.1070701@gmail.com> <604aa7910801170637j71b3f6d3q829cc64f60cc6ea8@mail.gmail.com> <478F73DA.2030207@gmail.com> <1200597084.15354.43.camel@localhost> <20080117192323.GO18982@zoidtechnologies.com> Message-ID: <1200598728.15354.49.camel@localhost> On Thu, 2008-01-17 at 14:23 -0500, jam at zoidtechnologies.com wrote: > On Thu, Jan 17, 2008 at 01:11:24PM -0600, Callum Lerwick wrote: > > Now you tell me where the greatest security risk lies. > > between the keyboard and the chair. You win a cookie! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Thu Jan 17 20:18:53 2008 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 17 Jan 2008 14:18:53 -0600 Subject: Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <200801151647.53632.opensource@till.name> References: <478CB7A3.8000206@redhat.com> <20080115153536.GB6483@roque.1407.org> <200801151647.53632.opensource@till.name> Message-ID: <1200601133.15354.60.camel@localhost> On Tue, 2008-01-15 at 16:47 +0100, Till Maas wrote: > On Tue January 15 2008, Rui Miguel Silva Seabra wrote: > > > vim is far more pratical on an terminal emulator than gvim, even on a > > system with X11/gtk. > > The gvim binary runs without any problems in an terminal emulator or a > terminal when it is run with the name vim. Or do you know anything that > breaks then? With longer startup time, and strange errors, and just because I ssh into a system with X11 forwarding enabled, so that it is available when I want it, doesn't mean I want vim to use it *now*. gvim startup over ssh is rather irritatingly slow, I use it when I know I'm going to have it open for a while, and if I want multiple windows open. And similarly, just because my screen session is pointing to the local X display, doesn't mean I haven't sshed into the screen session from another machine and want it to open on the local X display that I am not sitting in front of... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mszpak at wp.pl Thu Jan 17 21:05:56 2008 From: mszpak at wp.pl (=?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?=) Date: Thu, 17 Jan 2008 22:05:56 +0100 Subject: Python Eggs and problem with %{python_sitelib} In-Reply-To: <20080115164722.3b4f5781@redhat.com> References: <20080115164722.3b4f5781@redhat.com> Message-ID: On 2008-01-15 22:47, Jesse Keating wrote: > On Tue, 15 Jan 2008 22:44:12 +0100 > Marcin Zaj?czkowski wrote: > >> Hi, >> >> Recently I was updating my python package in rawhide to be compatible >> with Python Eggs and from an error in a log it seems that >> %{python_sitelib} is not declared. >> Is it really required to define that variable at the beginning of >> every SPEC file (eventually use %{_libdir}/python*/site-packages/) or >> it should be already defined in the system? >> >> Sample log: >> http://koji.fedoraproject.org/koji/getfile?taskID=351446&name=build.log > > Python specs should have one of either python_sitelib or > python_sitearch defined at the top of them. See the guidelines for > python packages. Use of one or the other depends on if your module is > arch specific (compiled) or not. Thanks for both your answers. I looked only at Python Eggs guide and missed info in common Python hints. Regards Marcin From ericsbinaryworld at gmail.com Thu Jan 17 21:14:56 2008 From: ericsbinaryworld at gmail.com (Eric Mesa) Date: Thu, 17 Jan 2008 16:14:56 -0500 Subject: KDE 4.0, Compiz, and Fedora 9 Message-ID: <478FC550.40504@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey there, I'm currently using Fedora 8 and primarily use Gnome with Compiz-Fusion. I also enjoy going into KDE every once in a while. However, I've noticed that Compiz-Fusion wreaks havoc on KDE. First of all, a lot of my programs with status messages (Kopete chat windows, Amarok) get garbled text in the status bar and sometimes in the title bar. Second, the pager does not show all of my programs open in other desktops. Also, it appears to ignore my KDE-set Window decorations. Since KDE 4.0 is going to have its own Composite Manager built in as well as many of the same desktop effects as Compiz, I propose that for Fedora 9/KDE 4.0 we have Compiz-Fusion not load when the user in in KDE (unless they really want it to and then we can have some checkbox they can check) Thanks, - -- Eric Mesa ericsbinaryworld at gmail.com http://www.ericsbinaryworld.com Note: All emails from this address should have a GPG signature. If you have the proper setup you can use this to confirm my identity and that the email was not changed in transit. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHj8VLPvU+8ApmWXIRAtPmAJ4gNgUTmZbhjXbTPIkLt9WMvefitwCfeT2o hGeWgZpFPu68u228fWbgE6k= =oilD -----END PGP SIGNATURE----- From opensource at till.name Thu Jan 17 21:19:55 2008 From: opensource at till.name (Till Maas) Date: Thu, 17 Jan 2008 22:19:55 +0100 Subject: Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <1200601133.15354.60.camel@localhost> References: <478CB7A3.8000206@redhat.com> <200801151647.53632.opensource@till.name> <1200601133.15354.60.camel@localhost> Message-ID: <200801172220.00064.opensource@till.name> On Thu January 17 2008, Callum Lerwick wrote: > On Tue, 2008-01-15 at 16:47 +0100, Till Maas wrote: > > On Tue January 15 2008, Rui Miguel Silva Seabra wrote: > > > vim is far more pratical on an terminal emulator than gvim, even on a > > > system with X11/gtk. > > > > The gvim binary runs without any problems in an terminal emulator or a > > terminal when it is run with the name vim. Or do you know anything that > > breaks then? > > With longer startup time, and strange errors, and just because I ssh > into a system with X11 forwarding enabled, so that it is available when > I want it, doesn't mean I want vim to use it *now*. gvim startup over > ssh is rather irritatingly slow, I use it when I know I'm going to have > it open for a while, and if I want multiple windows open. > > And similarly, just because my screen session is pointing to the local X > display, doesn't mean I haven't sshed into the screen session from > another machine and want it to open on the local X display that I am not > sitting in front of... Did you read the other postings in this thread? Your answers sounds to me, that you think I proposed, that vim should open a gtk window whenever it can. But this is not what I suggested. When you run the gvim binary as vim, then it opens in the terminal you are logged in and does not open a graphical window. Also it does not look anything other than the current vim-enhanced vim binary and I do not feel that the startup time is higher. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From opensource at till.name Thu Jan 17 21:20:35 2008 From: opensource at till.name (Till Maas) Date: Thu, 17 Jan 2008 22:20:35 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <20080117190542.GA84707@dspnet.fr.eu.org> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <200801171920.32764.opensource@till.name> <20080117190542.GA84707@dspnet.fr.eu.org> Message-ID: <200801172220.35601.opensource@till.name> On Thu January 17 2008, Olivier Galibert wrote: > A page called something like "SELinux memory protection configuration > documentation" When I use this as a google search term, I find: http://docs.fedoraproject.org/selinux-faq-fc5/ (1st result) On this page the second search on "memory protection" results again in a section with a link to: http://people.redhat.com/drepper/selinux-mem.html > or "SELinux configration manpage" which is actually When I use this (with an extra "u" for configuration), I get this as 5th hit: http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Deployment_Guide-en-US/ch-selinux.html This looks not too bad, either. If you want to write your own police, you can also look at: http://www.nsa.gov/selinux/papers/policy2-abs.cfm http://www.nsa.gov/selinux is mentioned in man selinux and there is a documentation link in the menu. > linked from google, not a blog post with a flameworthy title which > easily goes under the radar, as it did for me. Incidentally, the link > in the post is incorrect, there is an extra comma at the end. The link worked here when I clicked on it there. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From ml at deadbabylon.de Thu Jan 17 21:21:49 2008 From: ml at deadbabylon.de (Sebastian Vahl) Date: Thu, 17 Jan 2008 22:21:49 +0100 Subject: KDE 4.0, Compiz, and Fedora 9 In-Reply-To: <478FC550.40504@gmail.com> References: <478FC550.40504@gmail.com> Message-ID: <200801172221.54094.ml@deadbabylon.de> Am Do 17.Januar 2008 schrieb Eric Mesa: > Since KDE 4.0 is going to have its own Composite Manager built in as > well as many of the same desktop effects as Compiz, I propose that for > Fedora 9/KDE 4.0 we have Compiz-Fusion not load when the user in in KDE > (unless they really want it to and then we can have some checkbox they > can check) compiz also wasn't auto-loaded in F8. The live image contains a script that could easily switch between kwin and compiz but it need's some adjustments for KDE 4. But I haven't found the time to look into that, yet. And for kde-window-decorator: I don't know if it's already ready for KDE 4. Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From pertusus at free.fr Thu Jan 17 21:48:03 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 17 Jan 2008 22:48:03 +0100 Subject: anyone willing to package libmspack? Message-ID: <20080117214803.GA2568@free.fr> Hello, Some packages use internal versions of libmspack, according to https://bugzilla.redhat.com/show_bug.cgi?id=427638 samba, clamav. And cabextract. I don't want to maintain one more package but would review it. -- Pat From marc at mwiriadi.id.au Thu Jan 17 21:52:49 2008 From: marc at mwiriadi.id.au (Marc Wiriadisastra) Date: Fri, 18 Jan 2008 06:52:49 +0900 Subject: anyone willing to package libmspack? In-Reply-To: <20080117214803.GA2568@free.fr> References: <20080117214803.GA2568@free.fr> Message-ID: <1200606769.14544.21.camel@localhost.localdomain> On Thu, 2008-01-17 at 22:48 +0100, Patrice Dumas wrote: > Hello, > > Some packages use internal versions of libmspack, according to > https://bugzilla.redhat.com/show_bug.cgi?id=427638 > samba, clamav. And cabextract. > > I don't want to maintain one more package but would review it. > > -- > Pat > What version did you want packaged the cvs version of the pack that they list the 2006-09-20? Cheers, Marc From pertusus at free.fr Thu Jan 17 21:56:34 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 17 Jan 2008 22:56:34 +0100 Subject: anyone willing to package libmspack? In-Reply-To: <1200606769.14544.21.camel@localhost.localdomain> References: <20080117214803.GA2568@free.fr> <1200606769.14544.21.camel@localhost.localdomain> Message-ID: <20080117215634.GB2568@free.fr> On Fri, Jan 18, 2008 at 06:52:49AM +0900, Marc Wiriadisastra wrote: > > On Thu, 2008-01-17 at 22:48 +0100, Patrice Dumas wrote: > > Hello, > > > > Some packages use internal versions of libmspack, according to > > https://bugzilla.redhat.com/show_bug.cgi?id=427638 > > samba, clamav. And cabextract. > > > > I don't want to maintain one more package but would review it. > > > > -- > > Pat > > > > What version did you want packaged the cvs version of the pack that they > list the 2006-09-20? The package they list the 2006-09-20. Unless there is a good reason cvs snapshots shouldn't be packaged. The 2006-09-20 version is the same than what appears in cabextract-1.2 so it looks right to me. -- Pat From marc at mwiriadi.id.au Thu Jan 17 21:58:34 2008 From: marc at mwiriadi.id.au (Marc Wiriadisastra) Date: Fri, 18 Jan 2008 06:58:34 +0900 Subject: anyone willing to package libmspack? In-Reply-To: <20080117215634.GB2568@free.fr> References: <20080117214803.GA2568@free.fr> <1200606769.14544.21.camel@localhost.localdomain> <20080117215634.GB2568@free.fr> Message-ID: <1200607114.14544.23.camel@localhost.localdomain> On Thu, 2008-01-17 at 22:56 +0100, Patrice Dumas wrote: > On Fri, Jan 18, 2008 at 06:52:49AM +0900, Marc Wiriadisastra wrote: > > > > On Thu, 2008-01-17 at 22:48 +0100, Patrice Dumas wrote: > > > Hello, > > > > > > Some packages use internal versions of libmspack, according to > > > https://bugzilla.redhat.com/show_bug.cgi?id=427638 > > > samba, clamav. And cabextract. > > > > > > I don't want to maintain one more package but would review it. > > > > > > -- > > > Pat > > > > > > > What version did you want packaged the cvs version of the pack that they > > list the 2006-09-20? > > The package they list the 2006-09-20. Unless there is a good reason cvs > snapshots shouldn't be packaged. The 2006-09-20 version is the same than > what appears in cabextract-1.2 so it looks right to me. > > -- > Pat > I'll start work on it if nobody else really wants it. Cheers, Marc From ssorce at redhat.com Thu Jan 17 22:34:07 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 17 Jan 2008 17:34:07 -0500 Subject: anyone willing to package libmspack? In-Reply-To: <20080117214803.GA2568@free.fr> References: <20080117214803.GA2568@free.fr> Message-ID: <1200609247.10767.104.camel@localhost.localdomain> On Thu, 2008-01-17 at 22:48 +0100, Patrice Dumas wrote: > Hello, > > Some packages use internal versions of libmspack, according to > https://bugzilla.redhat.com/show_bug.cgi?id=427638 > samba, clamav. And cabextract. Never seen that code in samba, and I honestly do not know why we would need it. I know we have something to handle compression on some RPC pipe in samba4, but again I don't think it is libmspack ... Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From mike at miketc.com Thu Jan 17 22:37:56 2008 From: mike at miketc.com (Mike Chambers) Date: Thu, 17 Jan 2008 16:37:56 -0600 Subject: Rawhide broke? Message-ID: <1200609476.2876.1.camel@scrappy.miketc.com> There a couple of directories (images for one) that are missing in rawhide? -- Mike Chambers Madisonville, KY "The best lil town on Earth!" From jkeating at redhat.com Thu Jan 17 22:47:57 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 17 Jan 2008 17:47:57 -0500 Subject: Rawhide broke? In-Reply-To: <1200609476.2876.1.camel@scrappy.miketc.com> References: <1200609476.2876.1.camel@scrappy.miketc.com> Message-ID: <20080117174757.7189d425@redhat.com> On Thu, 17 Jan 2008 16:37:56 -0600 Mike Chambers wrote: > There a couple of directories (images for one) that are missing in > rawhide? Yep, small snafu with pykickstart lead to the 'make it installable' part to fail. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From vlada at fedora.org.nz Thu Jan 17 22:59:00 2008 From: vlada at fedora.org.nz (Vladimir N Kosovac) Date: Fri, 18 Jan 2008 11:59:00 +1300 Subject: Rawhide broke? In-Reply-To: <1200609476.2876.1.camel@scrappy.miketc.com> References: <1200609476.2876.1.camel@scrappy.miketc.com> Message-ID: <1200610740.5584.1.camel@nebula> On Thu, 2008-01-17 at 16:37 -0600, Mike Chambers wrote: > There a couple of directories (images for one) that are missing in > rawhide? > Seems to be the case only on the main download site. Internode mirror [AU] works for me as I write this. Vladimir > -- > Mike Chambers > Madisonville, KY > > "The best lil town on Earth!" > From lordmorgul at gmail.com Thu Jan 17 23:08:24 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Thu, 17 Jan 2008 15:08:24 -0800 Subject: Rawhide broke? In-Reply-To: <1200610740.5584.1.camel@nebula> References: <1200609476.2876.1.camel@scrappy.miketc.com> <1200610740.5584.1.camel@nebula> Message-ID: <478FDFE8.7070406@gmail.com> Vladimir N Kosovac wrote: > On Thu, 2008-01-17 at 16:37 -0600, Mike Chambers wrote: >> There a couple of directories (images for one) that are missing in >> rawhide? >> > Seems to be the case only on the main download site. Internode mirror > [AU] works for me as I write this. > > Vladimir That is most likely yesterday's data however. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From kwade at redhat.com Thu Jan 17 23:17:43 2008 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Thu, 17 Jan 2008 15:17:43 -0800 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478F00AF.2080206@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116210016.GA10162@devserv.devel.redhat.com> <1200518035.5766.2.camel@localhost> <1200518850.3277.5.camel@localhost.localdomain> <64b14b300801161335o1f27cf76t3affe31e8aae02ab@mail.gmail.com> <478F00AF.2080206@gmail.com> Message-ID: <1200611863.920.130.camel@calliope.phig.org> On Thu, 2008-01-17 at 08:15 +0100, Valent Turkovic wrote: > I believe that SELinux it too raw for > general purpose desktop. Give it a year or two to mature and maybe > then. Were you not a Fedora user during the FC2 and FC3 introduction of SELinux? SELinux is exceedingly mature, especially compared to some of the rest of the software we provide. What it does is complex and crucial. The only way to make it better is to run it, report the few problems that occur, and get them fixed. Meanwhile, covering >1500 applications with solid policy is a good thing, no matter what. After all, the last thing we need is a live media desktop edition that has SELinux disabled, then a vulnerability is discovered in the live media that allows an attacker to root the box. Since there is no SELinux to limit root privileges, we have an unknown number of live media discs out there, no way to update them, waiting to make bad news for the user and the Fedora Project. I think Michael Tiemann said it best: "SE Linux--a great open source success story" http://opensource.org/node/240 Michael is not talking about a future success story but one that has been successful for a few years already. - Karsten, who will never forget FC2/FC3 SELinux introduction ... -- Karsten Wade, Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From orion at cora.nwra.com Thu Jan 17 23:21:12 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 17 Jan 2008 16:21:12 -0700 Subject: Smolt and Kickstart (Was:SELinux removed from desktop cd spin?) In-Reply-To: <478EC869.4070100@ncsu.edu> References: <7f692fec0801161730x35d8d2dfubd2bb07d21871da9@mail.gmail.com> <604aa7910801161821l738ecad2lb6e1fa523ae13e90@mail.gmail.com> <7f692fec0801161839s272941b5i8db12c02b4626850@mail.gmail.com> <478EC869.4070100@ncsu.edu> Message-ID: <478FE2E8.6080606@cora.nwra.com> Casey Dahlin wrote: > You can opt in by running smoltSendProfile in your post-install script. > We just need to advertise this. Shouldn't that be: smoltSendProfile -a chkconfig smolt on Also how come the number of registered hosts on smolts.org toggles from about 302767 and about 294655 as I refresh the web page? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From kwade at redhat.com Thu Jan 17 23:25:19 2008 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Thu, 17 Jan 2008 15:25:19 -0800 Subject: SELinux removed from desktop cd spin? In-Reply-To: <64b14b300801161326l76fbca60pf806f9815db3fa@mail.gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116210016.GA10162@devserv.devel.redhat.com> <1200518035.5766.2.camel@localhost> <64b14b300801161326l76fbca60pf806f9815db3fa@mail.gmail.com> Message-ID: <1200612319.920.139.camel@calliope.phig.org> On Wed, 2008-01-16 at 22:26 +0100, Valent Turkovic wrote: > I will bet anybody who wants that Fedora live cd users will have more > trouble from using SElinux than benefit. Also that ubuntu, opensuse > and other distros that don't use SElinux won't be in trouble from some > 0day exploit. I'd take that bet if there were ever any way to prove who won. Unfortunately, when a live media for any Linux distro ships with an unknown zero-day exploit ... how are you ever to know: * How many are still out there? * How many got updated? * How many were exploited and no one ever knew? Since we still get reports from people running RHL 7.x, believe me that a live media with a built in exploit can live on to haunt you for many years. Similar to your first comparison, how would we ever know, of every exploit blocked by SELinux, is it better or worse to have blocked that exploit than to have encountered whatever potential problems with SELinux? So, you are on for the bet, if you can figure out a way to track the results. Otherwise, repeating that you "know security" and "know that SELinux is worse than what it prevents" are just assertions without facts. You are welcome to your opinion, but please don't undermine the good security reputation of Fedora to serve it. - Karsten -- Karsten Wade, Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From vlada at fedora.org.nz Thu Jan 17 23:25:18 2008 From: vlada at fedora.org.nz (Vladimir N Kosovac) Date: Fri, 18 Jan 2008 12:25:18 +1300 Subject: Rawhide broke? In-Reply-To: <478FDFE8.7070406@gmail.com> References: <1200609476.2876.1.camel@scrappy.miketc.com> <1200610740.5584.1.camel@nebula> <478FDFE8.7070406@gmail.com> Message-ID: <1200612318.5584.3.camel@nebula> On Thu, 2008-01-17 at 15:08 -0800, Andrew Farris wrote: > Vladimir N Kosovac wrote: > > On Thu, 2008-01-17 at 16:37 -0600, Mike Chambers wrote: > >> There a couple of directories (images for one) that are missing in > >> rawhide? > >> > > Seems to be the case only on the main download site. Internode mirror > > [AU] works for me as I write this. > > > > Vladimir > > That is most likely yesterday's data however. > It is > -- > Andrew Farris > gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 > No one now has, and no one will ever again get, the big picture. - Daniel Geer > ---- ---- > From cra at WPI.EDU Thu Jan 17 22:57:33 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 17 Jan 2008 17:57:33 -0500 Subject: anaconda support for encrypted LVs (as opposed to PVs) Message-ID: <20080117225733.GL29887@angus.ind.WPI.EDU> A while back I was told that Anaconda supported creating encrypted LVs, but it appears as of today's rawhide it only supports encrypted PVs. Is that true? If not, what is the magic UI sequence that allows LVs to be created and encrypted? From triad at df.lth.se Thu Jan 17 23:36:33 2008 From: triad at df.lth.se (Linus Walleij) Date: Fri, 18 Jan 2008 00:36:33 +0100 (CET) Subject: Fedora 8/ARM available In-Reply-To: <20080114233331.GL17358@xi.wantstofly.org> References: <20080114233331.GL17358@xi.wantstofly.org> Message-ID: On Tue, 15 Jan 2008, Lennert Buytenhek wrote: > We are proud to announce the availability of a(n unofficial) > Fedora 8 package repository for the ARM architecture. This is a great day for Fedora, thank you Lennert! Hm, my package libnjb does not build, no good. :-( Linus From buytenh at wantstofly.org Thu Jan 17 23:40:43 2008 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Fri, 18 Jan 2008 00:40:43 +0100 Subject: [fedora-arm] Re: Fedora 8/ARM available In-Reply-To: References: <20080114233331.GL17358@xi.wantstofly.org> Message-ID: <20080117234042.GA20934@xi.wantstofly.org> On Fri, Jan 18, 2008 at 12:36:33AM +0100, Linus Walleij wrote: > > We are proud to announce the availability of a(n unofficial) > > Fedora 8 package repository for the ARM architecture. > > This is a great day for Fedora, thank you Lennert! Thanks. :) > Hm, my package libnjb does not build, no good. :-( It is built? f8-updates-arm/libnjb-2.2.6-2.fc8.armv5tel.rpm f8-updates-arm/libnjb-debuginfo-2.2.6-2.fc8.armv5tel.rpm f8-updates-arm/libnjb-devel-2.2.6-2.fc8.armv5tel.rpm f8-updates-arm/libnjb-examples-2.2.6-2.fc8.armv5tel.rpm A consequence of not being hooked up in the main Fedora build system is that we don't do builds in the same order as they are done on i386/x86_64/ppc/ppc64. By the time libnjb was queued for building, an F8 update had already been issued for it, and the way we've set things up means that the F8 base package won't be built anymore if a newer version of the package (i.e. the update) has already been built. From buytenh at wantstofly.org Thu Jan 17 23:54:57 2008 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Fri, 18 Jan 2008 00:54:57 +0100 Subject: [fedora-arm] Re: Fedora 8/ARM available In-Reply-To: <5256d0b0801170648n6ac4cbf4ya67d9c09b3698fe4@mail.gmail.com> References: <20080114233331.GL17358@xi.wantstofly.org> <478F106E.90509@linux-kernel.at> <20080117144043.GB13114@xi.wantstofly.org> <5256d0b0801170648n6ac4cbf4ya67d9c09b3698fe4@mail.gmail.com> Message-ID: <20080117235457.GC20934@xi.wantstofly.org> On Thu, Jan 17, 2008 at 02:48:56PM +0000, Peter Robinson wrote: > > > > We are proud to announce the availability of a(n unofficial) > > > > Fedora 8 package repository for the ARM architecture. > > > > > > > > The package repository has been built for ARMv5 EABI, soft-float, > > > > little endian. The majority of the important and frequently used > > > > Fedora packages have been built for ARM. > > > > > > > > The Fedora/ARM architecture wiki page has more info: > > > > http://fedoraproject.org/wiki/Architectures/ARM > > > > > > > > The easiest way to start using Fedora 8/ARM is to download the > > > > prebuilt root filesystem, which can be booted in QEMU, or chroot'ed > > > > into or booted from on any ARMv5 or later processor running in little > > > > endian mode. Additional packages can be installed by using yum, > > > > which is provided in the filesystem. > > > > > > > > A HOWTO which describes getting Fedora/ARM running in QEMU is here: > > > > http://fedoraproject.org/wiki/Architectures/ARM/HowToQemu > > > > > > > > There currently are a handful of known issues, which are described at: > > > > http://fedoraproject.org/wiki/Architectures/ARM/TODO > > > > > > > > Please help us by using the Fedora/ARM port and reporting any issues > > > > you run into so that we can fix them. > > > > > > I should have bought something else/bigger than my WRT54, I guess :-) > > > > Isn't the WRT54 MIPS based with 4M of RAM or so? :) > > Yes I think so. They're Broadcom chips which I'm pretty sure uses a MIPS32 core. > > But on the other hand my Dlink DNS-323 is a 500Hmz Marvell ARM chip. A > storage Fedora sub distro would be cool. I'll hack up prebuilt kernel packages for a bunch of popular ARM boards, probably once support for Orion (i.e. the ARM CPU you speak of) hits mainline (it's queued for 2.6.25.) From mschwendt.tmp0701.nospam at arcor.de Fri Jan 18 00:03:24 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 18 Jan 2008 01:03:24 +0100 Subject: compilation architecture In-Reply-To: <5e92ee3f0801161242w2e6c9340lee2eed34cfc3158f@mail.gmail.com> References: <5e92ee3f0801161242w2e6c9340lee2eed34cfc3158f@mail.gmail.com> Message-ID: <20080118010324.b45bd216.mschwendt.tmp0701.nospam@arcor.de> On Wed, 16 Jan 2008 21:42:24 +0100, Jakub 'Livio' Rusinek wrote: > I have two bootcharts. > > Fedora's: http://img.wklej.org/images/77224fedora-bootchart.png > openSUSE's: http://img.wklej.org/images/50076opensuse-bootchart.png > > Look at many differencies. No. In short what you got is: openSUSE: 39 seconds Fedora: 41 seconds inspite of a very slow networking init From mschwendt.tmp0701.nospam at arcor.de Fri Jan 18 00:03:34 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 18 Jan 2008 01:03:34 +0100 Subject: compilation architecture In-Reply-To: <5e92ee3f0801160756o2aa5750cu4b403c8c405c2d69@mail.gmail.com> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801150507y2b9f31a5mcc7fd14b5760e384@mail.gmail.com> <20080115151925.652f0500.mschwendt.tmp0701.nospam@arcor.de> <5e92ee3f0801150711o9108b7apf83f4ae132b894e4@mail.gmail.com> <1200411358.15130.271.camel@localhost.localdomain> <5e92ee3f0801150726v2d708d70x7e51087f0bb0a254@mail.gmail.com> <20080115165601.67bdf81e.mschwendt.tmp0701.nospam@arcor.de> <5e92ee3f0801150831t685810f1jb2ac41c7975a1675@mail.gmail.com> <5e92ee3f0801160509x6655b9car15171ec594744d60@mail.gmail.com> <20080116164427.0361c924.mschwendt.tmp0701.nospam@arcor.de> <5e92ee3f0801160756o2aa5750cu4b403c8c405c2d69@mail.gmail.com> Message-ID: <20080118010334.a6e31dd7.mschwendt.tmp0701.nospam@arcor.de> On Wed, 16 Jan 2008 16:56:58 +0100, Jakub 'Livio' Rusinek wrote: > > On Wed, 16 Jan 2008 14:09:13 +0100, Jakub 'Livio' Rusinek wrote: > > > > > Ok, I've installed openSUSE and configured it like my Fedora. I went through the pains of installing openSUSE 10.3 for GNOME. Except for the installation settings, which I adjusted only minimally, I used the defaults and I did not reconfigure anything after booting the first time. I explicitly did not enable the non-free repository. First thing I noticed: harddisk access in openSUSE happens at half the speed of Fedora. hdparm -t confirms it whereas hdparm -T results for cache reads are about the same for both systems. This difference in disk access had a bad effect on some data processing speed tests. For huge files, openSUSE was about 33% slower in overall execution time, and I almost stopped at that point. For tests with smaller files, openSUSE computed approx. 3% faster than Fedora 8 (this is on AMD Athlon). Sometimes 2%, sometimes a bit more than 3%, but I didn't spend the time to take more than 1 or 2 samples each. And it was unconvincing enough to even consider comparing special computations of e.g. ASM-optimised A/V codecs. The openSUSE GNOME Desktop does not feel any snappier to me. Not when starting applications and not when opening xterm either. Though, I've noticed that when dragging xterm from the menu onto the desktop, an invalid launcher file is created and gives an error. ;) Firefox (it's 2.0.0.6 in openSUSE and 2.0.0.10 in F8) in Fedora 8 starts and exits from within a terminal in roughly 4.3 seconds (reproducibly) when quickly pressing Ctrl+W as soon as the window appears. That should mimic your own test procedure. In openSUSE it did that in approx. 6 seconds, and possibly due to the disk access issues I had difficulties in trying to start and close it faster than in 5-6 seconds. From michel.sylvan at gmail.com Fri Jan 18 00:13:06 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Thu, 17 Jan 2008 19:13:06 -0500 Subject: Fedora 8/ARM available In-Reply-To: <20080114233331.GL17358@xi.wantstofly.org> References: <20080114233331.GL17358@xi.wantstofly.org> Message-ID: On Jan 14, 2008 6:33 PM, Lennert Buytenhek wrote: > Hi all, > > We are proud to announce the availability of a(n unofficial) > Fedora 8 package repository for the ARM architecture. Great news! Would it be possible to install this on Scratchbox? Maemo's SDK is already using it. -- Michel Salim http://hircus.jaiku.com/ From seg at haxxed.com Fri Jan 18 00:29:53 2008 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 17 Jan 2008 18:29:53 -0600 Subject: rawhide report: 20080116 changes In-Reply-To: <200801171349.m0HDluOP013322@laptop13.inf.utfsm.cl> References: <200801161639.m0GGdexE021103@porkchop.devel.redhat.com> <200801171349.m0HDluOP013322@laptop13.inf.utfsm.cl> Message-ID: <1200616193.15354.64.camel@localhost> On Thu, 2008-01-17 at 10:47 -0300, Horst H. von Brand wrote: > While I'm not against including genome data, this is a very specialized > area... perhaps a separate YUM repo for such stuff? Copies of this will > have to be carried by each and every mirror. It appears it is 29M. Which is quite a bit smaller than a number of other things: http://mirrors.kernel.org/fedora/updates/7/i386/?C=S;O=D -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Fri Jan 18 00:35:17 2008 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Thu, 17 Jan 2008 16:35:17 -0800 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478F296F.10405@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <16de708d0801161316v66d0d49ch2508c29cb25e4abd@mail.gmail.com> <64b14b300801161328u1bd44f7ajc0d1f2ef9a172513@mail.gmail.com> <478E8E48.6080003@gmail.com> <478F0341.9050509@gmail.com> <1200555501.10767.47.camel@localhost.localdomain> <478F296F.10405@gmail.com> Message-ID: <1200616517.920.148.camel@calliope.phig.org> On Thu, 2008-01-17 at 11:09 +0100, Valent Turkovic wrote: > Simo Sorce wrote: > > On Thu, 2008-01-17 at 08:26 +0100, Valent Turkovic wrote: > >> Andrew Farris wrote: > >>> Valent Turkovic wrote: > >>> > >>>> And I bet that more will choose ubuntu as a "friendlier" desktop if > >>>> fedora forces people to use SELinux. > >>> Except noone is talking about forcing anyone to use selinux, just about > >>> not 'suggesting' that they don't use it... which is exactly what turning > >>> it off at install would be doing. > >>> > >> Sorry but you are forcing it if is enabled by default on install. > >> How much users (not counting devels, admins and testers) of fedora know > >> about SELinux and what it is? And what do people do when they install > >> something - they probably leave all settings on default in hope that > >> they don't "break" something with their wrong choices. > > > > I would like to propose that the CD Desktop spin also always run as > > root. > > Users do not know how to correctly use file permissions (or even know > > what they are) and they often are annoyed that they cannot simply remove > > useless directories like /usr that serve no apparent purpose but occupy > > a lot of space. > > > > Ah, also, can we run Fedora on a FAT file system by default, it's a much > > easier file system to deal with and works on Cameras too and it is not > > case sensitive, which is really helpful, case sensitivity is sooo > > annoying ... > > > > And also those annoying pop-ups asking for the root of a password when > > you want to change some configuration? What in the earth is the root of > > a password? I'd say login as root with no password is the best for > > usability, > > > > please consider it! > > > > > > > > Where is your bugzilla RFE? Don't say you didn't post it to bugzilla :) > > I believe that all your most of your concerns can be dealth through > policykit so please put RFE to correct package. I think you missed the smell of sarcasm on Simo's breath. -- Karsten Wade, Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kwade at redhat.com Fri Jan 18 00:46:42 2008 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Thu, 17 Jan 2008 16:46:42 -0800 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478F6C07.2050108@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116200333.GE15623@redhat.com> <64b14b300801161219q355d93b0jb57f91f48615591a@mail.gmail.com> <20080116202554.GF15623@redhat.com> <64b14b300801161235i4a4ed432h4f7b81ecefaf292b@mail.gmail.com> <7f692fec0801161717x3b0d77b9n9cd4a2dd939c6398@mail.gmail.com> <478F6C07.2050108@gmail.com> Message-ID: <1200617202.920.156.camel@calliope.phig.org> On Thu, 2008-01-17 at 15:53 +0100, Valent Turkovic wrote: > Are you actually hoping to really protect from real threats? Not even > SElinux can protect from rootkits. Um ... yes, it can. Russel Coker for many years has run an SELinux enabled server on the open Internet ... with an openly published root password. In all those years, with full root access, not one single crack attempt has succeeded. > A quick googleing showed that security experts see SELinux like a > backdor and as a problem just waiting to happed, and they suggest > UNINSTALLING SElinux! > > "As a final note, I follow the logic of the grsecurity team, who claim > that LSM and SELinux are backdoors waiting to happen." One could just as easily say (as if it were an actual argument): "As a final note, I follow the logic of the NSA and Red Hat security experts, who claim that grsecurity is a backdoor waiting to happen" I'm not going to go taking shots at the grsecurity team, who have spent many years attacking SELinux (which "competes" with their "solution".) They clearly have a biased opinion But when it comes to who knows how to implement IT security, I'll take the US's National Security Agency over just about any group in the history of the world. In the "fantasy football" of NSA v. grsecurity team, I wonder who wins? -- Karsten Wade, Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From smooge at gmail.com Fri Jan 18 02:05:19 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 17 Jan 2008 19:05:19 -0700 Subject: Cast your vote for the Fedora 9 Codename! In-Reply-To: <1200591438.920.119.camel@calliope.phig.org> References: <20080116184835.1bddf0f3@zod.rchland.ibm.com> <1200536182.920.64.camel@calliope.phig.org> <200801171318.m0HDGRqx011867@laptop13.inf.utfsm.cl> <1200591438.920.119.camel@calliope.phig.org> Message-ID: <80d7e4090801171805t3abb9651ie8ff1390267c51e@mail.gmail.com> Is campaigning for a name legal? -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From notting at redhat.com Fri Jan 18 02:24:57 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 17 Jan 2008 21:24:57 -0500 Subject: Cast your vote for the Fedora 9 Codename! In-Reply-To: <80d7e4090801171805t3abb9651ie8ff1390267c51e@mail.gmail.com> References: <20080116184835.1bddf0f3@zod.rchland.ibm.com> <1200536182.920.64.camel@calliope.phig.org> <200801171318.m0HDGRqx011867@laptop13.inf.utfsm.cl> <1200591438.920.119.camel@calliope.phig.org> <80d7e4090801171805t3abb9651ie8ff1390267c51e@mail.gmail.com> Message-ID: <20080118022457.GA1991@nostromo.devel.redhat.com> Stephen John Smoogen (smooge at gmail.com) said: > Is campaigning for a name legal? I don't know. It probably depends on how the Campaign For the Chupacabra Of the Future gets its funding. Bill From smooge at gmail.com Fri Jan 18 03:06:08 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 17 Jan 2008 20:06:08 -0700 Subject: Cast your vote for the Fedora 9 Codename! In-Reply-To: <20080118022457.GA1991@nostromo.devel.redhat.com> References: <20080116184835.1bddf0f3@zod.rchland.ibm.com> <1200536182.920.64.camel@calliope.phig.org> <200801171318.m0HDGRqx011867@laptop13.inf.utfsm.cl> <1200591438.920.119.camel@calliope.phig.org> <80d7e4090801171805t3abb9651ie8ff1390267c51e@mail.gmail.com> <20080118022457.GA1991@nostromo.devel.redhat.com> Message-ID: <80d7e4090801171906v61812ffbjbd1cf85ae93deae0@mail.gmail.com> On Jan 17, 2008 7:24 PM, Bill Nottingham wrote: > Stephen John Smoogen (smooge at gmail.com) said: > > Is campaigning for a name legal? > > I don't know. It probably depends on how the Campaign For the Chupacabra > Of the Future gets its funding. > Well mostly sucking the blood from our victims^Wvoters like any other political party. Actually I was going for Asperger because it would bring attention to a syndrome that affects some people I know. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From mike at miketc.com Fri Jan 18 03:06:59 2008 From: mike at miketc.com (Mike Chambers) Date: Thu, 17 Jan 2008 21:06:59 -0600 Subject: Rawhide update status Message-ID: <1200625619.2208.10.camel@scrappy.miketc.com> Updated my F8 system via yum tonight (took bout 3 or so hours, sheww) to rawhide. The yum updates went well but it's the boot up that is the problem as below.. 1 - When running on the kernel-2.6.24-0.155.rc7.git6.fc9, the system boots, but like the 2.6.23.13 kernels in F8, when it gets to X, there are some squibberish lines on top of black and that's it when it gets to gnome. I can't control the keyboard neither. When I was in F8 on the .13 kernels, the .9 acted fine, but .13's wouldn't unless there was an xorg.conf file and and then wouldn't even display the proper resolution. So they are both the same problem one way shape or form. ATI x1300 card and Proview 926 (19" flat panel) monitor. 2 - Some of the icons seem to be missing in the echo-icon-theme icons. Instead of the blue circled F there is the gnome foot. Same thing for File Browser icon, and xchat icon. 3 - Also, under the latest gdm, it is very primitive (think I seen discussion on this already). Also, I couldn't find the Menu/System/Administration/Login Window menu to configure it. I downloaded to F8 latest gdm for now (haven't tested that yet). Have to test some more but that is it so far. When rawhide is installable again, might do a clean install and try it out then. Haven't bugged any of this yet in case already known. -- Mike Chambers Madisonville, KY "The best lil town on Earth!" From cjdahlin at ncsu.edu Fri Jan 18 03:11:52 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Thu, 17 Jan 2008 22:11:52 -0500 Subject: Cast your vote for the Fedora 9 Codename! In-Reply-To: <80d7e4090801171906v61812ffbjbd1cf85ae93deae0@mail.gmail.com> References: <20080116184835.1bddf0f3@zod.rchland.ibm.com> <1200536182.920.64.camel@calliope.phig.org> <200801171318.m0HDGRqx011867@laptop13.inf.utfsm.cl> <1200591438.920.119.camel@calliope.phig.org> <80d7e4090801171805t3abb9651ie8ff1390267c51e@mail.gmail.com> <20080118022457.GA1991@nostromo.devel.redhat.com> <80d7e4090801171906v61812ffbjbd1cf85ae93deae0@mail.gmail.com> Message-ID: <479018F8.8080408@ncsu.edu> Stephen John Smoogen wrote: > On Jan 17, 2008 7:24 PM, Bill Nottingham wrote: > >> Stephen John Smoogen (smooge at gmail.com) said: >> >>> Is campaigning for a name legal? >>> >> I don't know. It probably depends on how the Campaign For the Chupacabra >> Of the Future gets its funding. >> >> > > Well mostly sucking the blood from our victims^Wvoters like any other > political party. > > Actually I was going for Asperger because it would bring attention to > a syndrome that affects some people I know. > > As a sufferer myself, let me extend a heartfelt "Thanks, but I'm good." --CJD From jwboyer at gmail.com Fri Jan 18 03:20:27 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 17 Jan 2008 21:20:27 -0600 Subject: Rawhide update status In-Reply-To: <1200625619.2208.10.camel@scrappy.miketc.com> References: <1200625619.2208.10.camel@scrappy.miketc.com> Message-ID: <20080117212027.688eed5e@zod.rchland.ibm.com> On Thu, 17 Jan 2008 21:06:59 -0600 Mike Chambers wrote: > Updated my F8 system via yum tonight (took bout 3 or so hours, sheww) to > rawhide. The yum updates went well but it's the boot up that is the > problem as below.. > > 1 - When running on the kernel-2.6.24-0.155.rc7.git6.fc9, the system > boots, but like the 2.6.23.13 kernels in F8, when it gets to X, there > are some squibberish lines on top of black and that's it when it gets to > gnome. I can't control the keyboard neither. When I was in F8 on > the .13 kernels, the .9 acted fine, but .13's wouldn't unless there was > an xorg.conf file and and then wouldn't even display the proper > resolution. So they are both the same problem one way shape or form. > ATI x1300 card and Proview 926 (19" flat panel) monitor. That sounds somewhat similar to bug 428813. I'm blaming DRI at the moment. > 2 - Some of the icons seem to be missing in the echo-icon-theme icons. > Instead of the blue circled F there is the gnome foot. Same thing for > File Browser icon, and xchat icon. Known. > > 3 - Also, under the latest gdm, it is very primitive (think I seen > discussion on this already). Also, I couldn't find the > Menu/System/Administration/Login Window menu to configure it. I > downloaded to F8 latest gdm for now (haven't tested that yet). This is a known issue. gdm needs love. josh From orion at cora.nwra.com Fri Jan 18 03:23:39 2008 From: orion at cora.nwra.com (orion at cora.nwra.com) Date: Thu, 17 Jan 2008 20:23:39 -0700 (MST) Subject: Large data packages In-Reply-To: <1200616193.15354.64.camel@localhost> References: <200801161639.m0GGdexE021103@porkchop.devel.redhat.com> <200801171349.m0HDluOP013322@laptop13.inf.utfsm.cl> <1200616193.15354.64.camel@localhost> Message-ID: <4958.71.208.64.7.1200626619.squirrel@www.cora.nwra.com> > > On Thu, 2008-01-17 at 10:47 -0300, Horst H. von Brand wrote: >> While I'm not against including genome data, this is a very specialized >> area... perhaps a separate YUM repo for such stuff? Copies of this will >> have to be carried by each and every mirror. > > It appears it is 29M. Which is quite a bit smaller than a number of > other things: > > http://mirrors.kernel.org/fedora/updates/7/i386/?C=S;O=D Yeah, until InstantMirror came around (++!) I spend a lot of time making sure my local mirror didn't download game stuff. If we start talking separate repos, that would be the first candidate. Not a big deal for me though as InstantMirror pretty much satisfies my needs. - Orion From orion at cora.nwra.com Fri Jan 18 03:52:07 2008 From: orion at cora.nwra.com (orion at cora.nwra.com) Date: Thu, 17 Jan 2008 20:52:07 -0700 (MST) Subject: Fedora bug triage - workflow proposal In-Reply-To: References: Message-ID: <1344.71.208.64.7.1200628327.squirrel@www.cora.nwra.com> > Well, it was a great session at FUDCon. A lot came out of it, and I'm > going to put some of them down here. The work flow suggested below I'd > a FESco vote on, since it really affects you guys. This work flow was > discussed between myself, John Poelstra, and Will Woods at the Sunday > hackfest, and we agree that this is the correct way to move forward, > however, we want community input and buy-in on this, since it has > pretty far-reaching consequences. > > Here is the lifecycle of a bug: > > 1) Reporter files a bug report, it originates in NEW state > 2) Triage team looks at bug report, determines if dupe or > insufficient information exists to solve it. If there is not enough > information in the bug, then triage team puts the bug in NEEDINFO. As > you will see below, this state has a finite life cycle associated with > it. > 3) Assuming bug survives through the triage team, it changes state to > ASSIGNED (triage team can put it in either NEEDINFO or CLOSED, as > appropriate). Note that per the definition[1], ASSIGNED does not mean > that someone has actually agreed to take action, simply that the issue > is well defined and triaged accordingly > 4) Once a developer has taken responsibility for a bug and is > actively working on it, the state transitions to ON_DEV. A question - what about bugs blocked by another bug. For example, I have a tracker bug to build plplot for ppc64 once Ada is built for ppc64, and is blocked by the Ada for ppc64 bug. Is there some easy way for it to show up in my bug list as obviously "blocked"? - Orion From a.badger at gmail.com Fri Jan 18 04:18:36 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 17 Jan 2008 20:18:36 -0800 Subject: Python Eggs & distutils in Rawhide In-Reply-To: References: <475DBBAA.7030605@gmail.com> Message-ID: <4790289C.2020205@gmail.com> Zoltan Kota wrote: > On Mon, 10 Dec 2007, Toshio Kuratomi wrote: > >> Just a small heads up for those of you packaging python modules. >> python-2.5.1-18, just built for rawhide, has reverted a small patch we >> were carrying that disabled generation of egg-info for modules created >> by distutils. That means that python modules built against rawhide will >> now create an extra file of metadata in the python_sitelib and >> python_sitearch directories. You'll need to include those in your >> %files section if it's not already pulled in via a wildcard. > > How is it decided where the egg-info will be installed: in the > python_sitelib or python_sitearch? If my package installs files in > python_sitearch, can I expect to have the egg-info there as well? > You've got it right. If the module installs to %{python_sitearch}, the .egg-info file should also appear in %{python_sitearch}. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From mike at miketc.com Fri Jan 18 04:25:40 2008 From: mike at miketc.com (Mike Chambers) Date: Thu, 17 Jan 2008 22:25:40 -0600 Subject: Rawhide update status In-Reply-To: <20080117212027.688eed5e@zod.rchland.ibm.com> References: <1200625619.2208.10.camel@scrappy.miketc.com> <20080117212027.688eed5e@zod.rchland.ibm.com> Message-ID: <1200630340.2592.6.camel@scrappy.miketc.com> On Thu, 2008-01-17 at 21:20 -0600, Josh Boyer wrote: > On Thu, 17 Jan 2008 21:06:59 -0600 > Mike Chambers wrote: > > > Updated my F8 system via yum tonight (took bout 3 or so hours, sheww) to > > rawhide. The yum updates went well but it's the boot up that is the > > problem as below.. > > > > 1 - When running on the kernel-2.6.24-0.155.rc7.git6.fc9, the system > > boots, but like the 2.6.23.13 kernels in F8, when it gets to X, there > > are some squibberish lines on top of black and that's it when it gets to > > gnome. I can't control the keyboard neither. When I was in F8 on > > the .13 kernels, the .9 acted fine, but .13's wouldn't unless there was > > an xorg.conf file and and then wouldn't even display the proper > > resolution. So they are both the same problem one way shape or form. > > ATI x1300 card and Proview 926 (19" flat panel) monitor. > > That sounds somewhat similar to bug 428813. I'm blaming DRI at the > moment. Looks/sounds like same thing. I chimed in on the bug, so hopefully find the problem real quick like. > > 2 - Some of the icons seem to be missing in the echo-icon-theme icons. > > Instead of the blue circled F there is the gnome foot. Same thing for > > File Browser icon, and xchat icon. > > Known. Goood, will wait for a fix. > > 3 - Also, under the latest gdm, it is very primitive (think I seen > > discussion on this already). Also, I couldn't find the > > Menu/System/Administration/Login Window menu to configure it. I > > downloaded to F8 latest gdm for now (haven't tested that yet). > > This is a known issue. gdm needs love. Good, hope it gets it, cuz dat thang is *ugly* hehe. Hrm, guess there *might* be one more thing, but this was in F8 and maybe it's in F9. I have onboard sound (AC97?) and a SB Audigy pci card. I use the SB card for main sound. So currently usually it's ac97 for card1 and SB for card0. Well, pulseaudio detects them that way, but it keeps putting card1 on top in pulseaudio volume control menu, and making it default, when it's not. So I have to move the modules up/down so SB is 1, detected as that and then it appears and as default. Otherwise, I have to manually make it default every time I reboot/login to gnome, so I can hear sounds, instead of it remembering the setting. Heh, hope I explained that right. Anyway, off to bed, more testing tomorrow and the weekend. -- Mike Chambers Madisonville, KY "The best lil town on Earth!" From lordmorgul at gmail.com Fri Jan 18 04:44:02 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Thu, 17 Jan 2008 20:44:02 -0800 Subject: Rawhide update status In-Reply-To: <1200630340.2592.6.camel@scrappy.miketc.com> References: <1200625619.2208.10.camel@scrappy.miketc.com> <20080117212027.688eed5e@zod.rchland.ibm.com> <1200630340.2592.6.camel@scrappy.miketc.com> Message-ID: <47902E92.7080104@gmail.com> Mike Chambers wrote: > Hrm, guess there *might* be one more thing, but this was in F8 and maybe > it's in F9. I have onboard sound (AC97?) and a SB Audigy pci card. I > use the SB card for main sound. So currently usually it's ac97 for > card1 and SB for card0. Well, pulseaudio detects them that way, but it > keeps putting card1 on top in pulseaudio volume control menu, and making > it default, when it's not. So I have to move the modules up/down so SB > is 1, detected as that and then it appears and as default. Otherwise, I > have to manually make it default every time I reboot/login to gnome, so > I can hear sounds, instead of it remembering the setting. Heh, hope I > explained that right. > > Anyway, off to bed, more testing tomorrow and the weekend. My primary desktop system has that exact issue with F8 (audigy and intel ac97), except with the pulseaudio 0.9.8 update from testing this is partly fixed. While I still cannot get the volume meter to open with the correct card (it picks the intel chip) I do get most applications to use the correct one by default now, and they did not in 0.9.7. In 0.9.7 I had to open an application, then open volume control, and move the stream to the other sink. I hope to move that system to rawhide soon and see how things are progressing with fresh pulseaudio settings. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From kyle at mcmartin.ca Fri Jan 18 04:44:49 2008 From: kyle at mcmartin.ca (Kyle McMartin) Date: Thu, 17 Jan 2008 23:44:49 -0500 Subject: Rawhide update status In-Reply-To: <1200630340.2592.6.camel@scrappy.miketc.com> References: <1200625619.2208.10.camel@scrappy.miketc.com> <20080117212027.688eed5e@zod.rchland.ibm.com> <1200630340.2592.6.camel@scrappy.miketc.com> Message-ID: <20080118044449.GA974@phobos.i.cabal.ca> On Thu, Jan 17, 2008 at 10:25:40PM -0600, Mike Chambers wrote: > Looks/sounds like same thing. I chimed in on the bug, so hopefully find > the problem real quick like. > what i meant to say on the bug, was that it's probably fixed in the f8 kernel now. the radeon drm issue on rawhide probably still exists. this can be worked around in rawhide by disabling drm for now. cheers, kyle From mike at miketc.com Fri Jan 18 04:44:51 2008 From: mike at miketc.com (Mike Chambers) Date: Thu, 17 Jan 2008 22:44:51 -0600 Subject: Xorg radeon drivers Message-ID: <1200631491.2150.2.camel@scrappy.miketc.com> Ajax, I know there was discussion on this, or still is, but wanted to get something clarified. Have you made up your mind on what package(s) to put ati drivers (latest anyway) in? Cause in F8 I used to have to run in vesa mode to get my resolutionl, but in rawhide it's using radeon and proper resolution is being used. X1300 Card btw, w/Proview 926 19" Flat monitor. -- Mike Chambers Madisonville, KY "The best lil town on Earth!" From jonstanley at gmail.com Fri Jan 18 05:48:23 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Fri, 18 Jan 2008 00:48:23 -0500 Subject: Fedora bug triage - workflow proposal In-Reply-To: <1344.71.208.64.7.1200628327.squirrel@www.cora.nwra.com> References: <1344.71.208.64.7.1200628327.squirrel@www.cora.nwra.com> Message-ID: On Jan 17, 2008 10:52 PM, wrote: > is blocked by the Ada for ppc64 bug. Is there some easy way for it to > show up in my bug list as obviously "blocked"? Yes, use the change columns link down at the bottom of the list of bugs. That will change the columns for all of your buglist displays. From airlied at redhat.com Fri Jan 18 06:06:19 2008 From: airlied at redhat.com (Dave Airlie) Date: Fri, 18 Jan 2008 16:06:19 +1000 Subject: Xorg radeon drivers In-Reply-To: <1200631491.2150.2.camel@scrappy.miketc.com> References: <1200631491.2150.2.camel@scrappy.miketc.com> Message-ID: <1200636379.29147.0.camel@localhost> On Thu, 2008-01-17 at 22:44 -0600, Mike Chambers wrote: > Ajax, > > I know there was discussion on this, or still is, but wanted to get > something clarified. Have you made up your mind on what package(s) to > put ati drivers (latest anyway) in? Cause in F8 I used to have to run > in vesa mode to get my resolutionl, but in rawhide it's using radeon and > proper resolution is being used. Also F8 updates-testing should work fine.. We haven't picked a driver by default yet, (need to add .xinf file for that). Dave. > > X1300 Card btw, w/Proview 926 19" Flat monitor. > > -- > Mike Chambers > Madisonville, KY > > "The best lil town on Earth!" > From cra at WPI.EDU Fri Jan 18 08:02:11 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 18 Jan 2008 03:02:11 -0500 Subject: blacklisted iwl4965 ?? Message-ID: <20080118080211.GM29887@angus.ind.WPI.EDU> I just did a fresh rawhide install and found this in /etc/modprobe.d/blacklist: # don't load iwl4965 by default, bug 245379 blacklist iwl4965 https://bugzilla.redhat.com/show_bug.cgi?id=245379 Does someone have any better explanation for this than the 6+ month old bug report for RHEL 5? What are us iwl4965 users supposed to be using? From kms at passback.co.uk Fri Jan 18 08:15:21 2008 From: kms at passback.co.uk (Keith Sharp) Date: Fri, 18 Jan 2008 08:15:21 +0000 Subject: intel driver and dual screen In-Reply-To: <1200499226.9549.5.camel@gaara.boston.redhat.com> References: <64b14b300801160352mbaa4261sae58a74ecf6fa0a0@mail.gmail.com> <1200492858.10631.18.camel@localhost.localdomain> <1200499226.9549.5.camel@gaara.boston.redhat.com> Message-ID: <1200644121.32595.14.camel@animal.passback.co.uk> On Wed, 2008-01-16 at 11:00 -0500, Kristian H?gsberg wrote: > One things that's not very well documented is that you need to tweak you > xorg.conf for this to work. You need to add a Virtual line to the > "Display" subsection in the "Screen" section of the xorg.conf file, for > example: > > Section "Screen" > Identifier "Screen0" > Device "Videocard0" > DefaultDepth 24 > SubSection "Display" > Viewport 0 0 > Depth 24 > Virtual 3600 1200 > EndSubSection > EndSection > > The exact resolution depends on the monitors you want to use, but it has > to be big enough to hold both side by side. In my case, I have > 1900x1200 and 1680x1050 monitors side by side, which gives me the > numbers above. I have a related issue on F9 - how do I persist the existence of my second monitor? I have a desktop with a dual head ATI graphics card[1], when I boot and login the same image is shown on both monitors. Once I have logged in I can run the command: xrandr --output VGA-0 --left-of DVI-0 and that sets things up as I want them (Xinerama style). Despite much googling I can find no way to make this persist. Can anyone offer any suggestions? I've attached my xorg.conf file in case it is relevant. Many thanks, Keith. [1] $ lspci | grep ATI 01:00.0 VGA compatible controller: ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)] 01:00.1 Display controller: ATI Technologies Inc RV370 [Radeon X300SE] -------------- next part -------------- # Xorg configuration for Xrandr based off the Intel web page: # http://intellinuxgraphics.org/dualhead.html Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "XkbModel" "pc105" Option "XkbLayout" "gb" EndSection Section "Device" Identifier "Videocard0" Driver "radeon" Option "VGA-0" "left" Option "DVI-0" "right" EndSection Section "Monitor" Identifier "left" Option "PreferredMode" "1280x1024" EndSection Section "Monitor" Identifier "right" Option "PreferredMode" "1280x1024" Option "RightOf" "left" EndSection Section "Screen" Identifier "Default Screen" Device "Videocard0" Monitor "left" DefaultDepth 24 SubSection "Display" Depth 24 Modes "2560x1024" Virtual 2560 2048 EndSubSection EndSection From airlied at redhat.com Fri Jan 18 08:25:45 2008 From: airlied at redhat.com (Dave Airlie) Date: Fri, 18 Jan 2008 18:25:45 +1000 Subject: intel driver and dual screen In-Reply-To: <1200644121.32595.14.camel@animal.passback.co.uk> References: <64b14b300801160352mbaa4261sae58a74ecf6fa0a0@mail.gmail.com> <1200492858.10631.18.camel@localhost.localdomain> <1200499226.9549.5.camel@gaara.boston.redhat.com> <1200644121.32595.14.camel@animal.passback.co.uk> Message-ID: <1200644745.29147.3.camel@localhost> On Fri, 2008-01-18 at 08:15 +0000, Keith Sharp wrote: > On Wed, 2008-01-16 at 11:00 -0500, Kristian H?gsberg wrote: > > > One things that's not very well documented is that you need to tweak you > > xorg.conf for this to work. You need to add a Virtual line to the > > "Display" subsection in the "Screen" section of the xorg.conf file, for > > example: > > > > Section "Screen" > > Identifier "Screen0" > > Device "Videocard0" > > DefaultDepth 24 > > SubSection "Display" > > Viewport 0 0 > > Depth 24 > > Virtual 3600 1200 > > EndSubSection > > EndSection > > > > The exact resolution depends on the monitors you want to use, but it has > > to be big enough to hold both side by side. In my case, I have > > 1900x1200 and 1680x1050 monitors side by side, which gives me the > > numbers above. > > I have a related issue on F9 - how do I persist the existence of my > second monitor? > > I have a desktop with a dual head ATI graphics card[1], when I boot and > login the same image is shown on both monitors. Once I have logged in I > can run the command: > > xrandr --output VGA-0 --left-of DVI-0 > > and that sets things up as I want them (Xinerama style). Despite much > googling I can find no way to make this persist. Can anyone offer any > suggestions? I've attached my xorg.conf file in case it is relevant. > http://www.intellinuxgraphics.org/dualhead.html should point the way, you just need to use the ATI output namings.. Dave. > Many thanks, > > Keith. > > [1] $ lspci | grep ATI > 01:00.0 VGA compatible controller: ATI Technologies Inc RV370 5B60 > [Radeon X300 (PCIE)] > 01:00.1 Display controller: ATI Technologies Inc RV370 [Radeon X300SE] > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From bruno at wolff.to Fri Jan 18 08:27:04 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Fri, 18 Jan 2008 02:27:04 -0600 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478F018F.50009@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116210016.GA10162@devserv.devel.redhat.com> <1200518035.5766.2.camel@localhost> <1200518850.3277.5.camel@localhost.localdomain> <64b14b300801161335o1f27cf76t3affe31e8aae02ab@mail.gmail.com> <604aa7910801161400k2e3ea6d6r3706a721a9106aed@mail.gmail.com> <478F018F.50009@gmail.com> Message-ID: <20080118082704.GA29940@wolff.to> On Thu, Jan 17, 2008 at 08:19:43 +0100, Valent Turkovic wrote: > > Will fedora include virus scanners? If not why? Because virus scanners are resource sucking hogs that don't work very well. If you want to go down that road you need to sign code and have a white list. From jamatos at fc.up.pt Fri Jan 18 08:46:29 2008 From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=) Date: Fri, 18 Jan 2008 08:46:29 +0000 Subject: Wild buildsys reports? Message-ID: <200801180846.29537.jamatos@fc.up.pt> Hi, I have been receiving reports of broken for all the packages I maintain and/or indirectly dependent. The report are very suspicious in the sense that they complain about everything. The simples example: python-HTMLgen has broken dependencies in the development tree: On ppc: python-HTMLgen - 2.2.2-10.fc8.noarch requires python(abi) = 0:2.5 On x86_64: python-HTMLgen - 2.2.2-10.fc8.noarch requires python(abi) = 0:2.5 On i386: python-HTMLgen - 2.2.2-10.fc8.noarch requires python(abi) = 0:2.5 On ppc64: python-HTMLgen - 2.2.2-10.fc8.noarch requires python(abi) = 0:2.5 Please resolve this as soon as possible. Unless we have python 2.6 (not yet released) I can not see how this fails, other than some borkage in the buildsys report generation. :-) Regards, -- Jos? Ab?lio From bruno at wolff.to Fri Jan 18 08:46:59 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Fri, 18 Jan 2008 02:46:59 -0600 Subject: Xorg radeon drivers In-Reply-To: <1200636379.29147.0.camel@localhost> References: <1200631491.2150.2.camel@scrappy.miketc.com> <1200636379.29147.0.camel@localhost> Message-ID: <20080118084659.GB29940@wolff.to> On Fri, Jan 18, 2008 at 16:06:19 +1000, Dave Airlie wrote: > > On Thu, 2008-01-17 at 22:44 -0600, Mike Chambers wrote: > > Ajax, > > > > I know there was discussion on this, or still is, but wanted to get > > something clarified. Have you made up your mind on what package(s) to > > put ati drivers (latest anyway) in? Cause in F8 I used to have to run > > in vesa mode to get my resolutionl, but in rawhide it's using radeon and > > proper resolution is being used. > > Also F8 updates-testing should work fine.. I have had problems with xorg-x11-drv-ati-6.7.196-5.fc8 and have reverted to using xorg-x11-drv-ati-6.7.196-2.fc8. Though in my case I have a 9200, so he might be better off with the updates-testing version, even though it doesn't work for me. From caolanm at redhat.com Fri Jan 18 08:53:40 2008 From: caolanm at redhat.com (Caolan McNamara) Date: Fri, 18 Jan 2008 08:53:40 +0000 Subject: Wild buildsys reports? In-Reply-To: <200801180846.29537.jamatos@fc.up.pt> References: <200801180846.29537.jamatos@fc.up.pt> Message-ID: <1200646420.9954.143.camel@Jehannum> On Fri, 2008-01-18 at 08:46 +0000, Jos? Matos wrote: > Hi, > I have been receiving reports of broken for all the packages I maintain > and/or indirectly dependent. Yeah, everyone is getting loads of them on nutball impossibilities, I think we can safely ignore the lot of them for now. Maybe some bleed over from a Test 1 procedure or test or something. C. From frank-buettner at gmx.net Fri Jan 18 08:53:48 2008 From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=) Date: Fri, 18 Jan 2008 09:53:48 +0100 Subject: mock 0.8.9 will not build anything Message-ID: <4790691C.3080605@gmx.net> Hello, when I try to build an package mock will fail with: ERROR: Command(/usr/sbin/groupadd -g 102 mockbuild) failed. See logs for output. At the root.log: 2008-01-18 09:48:01,860 - DEBUG trace_decorator.py, Line: 20: ENTER: doChroot((, '/usr/sbin/grou padd -g 102 mockbuild', ''), {}) 2008-01-18 09:48:01,861 - DEBUG trace_decorator.py, Line: 20: ENTER: do(('/usr/sbin/groupadd -g 102 mockbuild', '/var/lib/mock/fedora-de velopment-i386/root', 0, True, 0, None, None, None, None), {}) 2008-01-18 09:48:01,862 - DEBUG util.py, Line: 212: Run cmd: /usr/sbin/groupadd -g 102 mockbuild 2008-01-18 09:48:01,862 - DEBUG util.py, Line: 218: Executing timeout(0): /usr/sbin/groupadd -g 102 mockbuild 2008-01-18 09:48:01,866 - DEBUG trace_decorator.py, Line: 20: ENTER: condPersonality((None,), {}) 2008-01-18 09:48:01,869 - DEBUG trace_decorator.py, Line: 30: LEAVE condPersonality --> None 2008-01-18 09:48:01,870 - DEBUG trace_decorator.py, Line: 20: ENTER: condChroot(('/var/lib/mock/fedora-development-i386/root', None), {} ) 2008-01-18 09:48:01,871 - DEBUG trace_decorator.py, Line: 30: LEAVE condChroot --> None 2008-01-18 03:48:01,872 - DEBUG trace_decorator.py, Line: 20: ENTER: condDropPrivs((None, None, None), {}) 2008-01-18 03:48:01,873 - DEBUG trace_decorator.py, Line: 30: LEAVE condDropPrivs --> None 2008-01-18 09:48:01,973 - DEBUG util.py, Line: 234: groupadd: name mockbuild is not unique 2008-01-18 09:48:01,977 - DEBUG trace_decorator.py, Line: 27: EXCEPTION: Command(/usr/sbin/groupadd -g 102 mockbuild) failed. See logs f or output. Any ideas, what goes wrong?? Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5766 bytes Desc: S/MIME Cryptographic Signature URL: From j.w.r.degoede at hhs.nl Fri Jan 18 09:04:58 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 18 Jan 2008 10:04:58 +0100 Subject: Wild buildsys reports? In-Reply-To: <1200646420.9954.143.camel@Jehannum> References: <200801180846.29537.jamatos@fc.up.pt> <1200646420.9954.143.camel@Jehannum> Message-ID: <47906BBA.8030207@hhs.nl> Caolan McNamara wrote: > On Fri, 2008-01-18 at 08:46 +0000, Jos? Matos wrote: >> Hi, >> I have been receiving reports of broken for all the packages I maintain >> and/or indirectly dependent. > > Yeah, everyone is getting loads of them on nutball impossibilities, I > think we can safely ignore the lot of them for now. Maybe some bleed > over from a Test 1 procedure or test or something. > Yeah, Sofar I only received 124 of them, I wonder when I get the remaining 76, or has someone stopped this madness? Regards, Hans From fedora at leemhuis.info Fri Jan 18 09:14:53 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 18 Jan 2008 10:14:53 +0100 Subject: Wild buildsys reports? In-Reply-To: <47906BBA.8030207@hhs.nl> References: <200801180846.29537.jamatos@fc.up.pt> <1200646420.9954.143.camel@Jehannum> <47906BBA.8030207@hhs.nl> Message-ID: <47906E0D.3040408@leemhuis.info> On 18.01.2008 10:04, Hans de Goede wrote: > Sofar I only received 124 of them, I wonder when I get the remaining 76, or has > someone stopped this madness? I suppose you might get even more, as afaics you not only get them for your own packages, but also for packages owned by other people if one of your packages is a missing dep there. ;-) CU knurd From ivazqueznet at gmail.com Fri Jan 18 09:20:11 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 18 Jan 2008 04:20:11 -0500 Subject: Wild buildsys reports? In-Reply-To: <200801180846.29537.jamatos@fc.up.pt> References: <200801180846.29537.jamatos@fc.up.pt> Message-ID: <1200648012.9899.10.camel@ignacio.lan> On Fri, 2008-01-18 at 08:46 +0000, Jos? Matos wrote: > I have been receiving reports of broken for all the packages I maintain > and/or indirectly dependent. > > The report are very suspicious in the sense that they complain about > everything. Looks like mash imploded. I'd just ignore them for now. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kms at passback.co.uk Fri Jan 18 09:39:32 2008 From: kms at passback.co.uk (Keith Sharp) Date: Fri, 18 Jan 2008 09:39:32 +0000 Subject: SELinux removed from desktop cd spin? In-Reply-To: <478F6C4C.2000402@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116202554.GF15623@redhat.com> <64b14b300801161235i4a4ed432h4f7b81ecefaf292b@mail.gmail.com> <200801171321.29240.opensource@till.name> <478F66D4.7040901@gmail.com> <604aa7910801170639l1268828ci7f989abe92bd11cb@mail.gmail.com> <478F6C4C.2000402@gmail.com> Message-ID: <1200649175.32595.21.camel@animal.passback.co.uk> On Thu, 2008-01-17 at 15:55 +0100, Valent Turkovic wrote: > Jeff Spaleta wrote: > > On Jan 17, 2008 5:31 AM, Valent Turkovic wrote: > >> Also for internet caffes I believe that Ubuntu with LTS is much viable > >> option that fedora with it's too short life cycle. > > > > And I believe that virtualization will make this comment moot soon enough. > > > > -jef > > > > How? Probably something like: All desktops run a hypervisor and domain0, when a customer (student, whoever) wants to use a machine they get a clone of the latest good virtual machine instance as domainU. They have no access to the hypervisor or domain0. Any data they want to keep is stored to a flash drive, central server storage, online Internet storage, etc. Then when they are done the VM instance is destroyed and the physical machine is available for allocation to someone else. Similar setups are possible without the VM bit, but normally you need to do a network boot or install which has an initial performance penalty. I'm sure Jef can clarify further if I've got the wrong end of the stick. Keith. From harald at redhat.com Fri Jan 18 09:57:28 2008 From: harald at redhat.com (Harald Hoyer) Date: Fri, 18 Jan 2008 10:57:28 +0100 Subject: koji: sslv3 alert certificate expired Message-ID: $ make build : [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert certificate expired'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl handshake failure')] make: *** [koji] Error 1 From jdieter at gmail.com Fri Jan 18 09:59:35 2008 From: jdieter at gmail.com (Jonathan Dieter) Date: Fri, 18 Jan 2008 11:59:35 +0200 Subject: Broken dependencies? Message-ID: <1200650375.23175.87.camel@jndwidescreen.lesbg.loc> I got an e-mail saying that presto-utils has broken dependencies in the development branch, and then this list: presto-utils - 0.3.2-1.fc8.noarch requires createrepo >= 0:0.4.8 presto-utils - 0.3.2-1.fc8.noarch requires deltarpm >= 0:3.4-2 presto-utils - 0.3.2-1.fc8.noarch requires /bin/sh presto-utils - 0.3.2-1.fc8.noarch requires /usr/bin/python presto-utils - 0.3.2-1.fc8.noarch requires python >= 0:2.4 All of those dependencies are filled by packages in the development repository. What am I missing? Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jdieter at gmail.com Fri Jan 18 10:01:35 2008 From: jdieter at gmail.com (Jonathan Dieter) Date: Fri, 18 Jan 2008 12:01:35 +0200 Subject: Broken dependencies? In-Reply-To: <1200650375.23175.87.camel@jndwidescreen.lesbg.loc> References: <1200650375.23175.87.camel@jndwidescreen.lesbg.loc> Message-ID: <1200650495.23175.90.camel@jndwidescreen.lesbg.loc> On Fri, 2008-01-18 at 11:59 +0200, Jonathan Dieter wrote: > I got an e-mail saying that presto-utils has broken dependencies in the > development branch, and then this list: > > presto-utils - 0.3.2-1.fc8.noarch requires createrepo >= 0:0.4.8 > presto-utils - 0.3.2-1.fc8.noarch requires deltarpm >= 0:3.4-2 > presto-utils - 0.3.2-1.fc8.noarch requires /bin/sh > presto-utils - 0.3.2-1.fc8.noarch requires /usr/bin/python > presto-utils - 0.3.2-1.fc8.noarch requires python >= 0:2.4 > > All of those dependencies are filled by packages in the development > repository. What am I missing? Feel free to ignore this. I missed the other messages about the same problem. Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From opensource at till.name Fri Jan 18 10:13:26 2008 From: opensource at till.name (Till Maas) Date: Fri, 18 Jan 2008 11:13:26 +0100 Subject: koji: sslv3 alert certificate expired In-Reply-To: References: Message-ID: <200801181113.33212.opensource@till.name> On Fri January 18 2008, Harald Hoyer wrote: > $ make build > : [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 > alert certificate expired'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl > handshake failure')] > make: *** [koji] Error 1 http://fedoraproject.org/wiki/PackageMaintainers/UsingCvsFaq#head-f003c4260a18a6b9ac472da9e7d56891ae5508c2 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From limb at jcomserv.net Fri Jan 18 11:04:51 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 18 Jan 2008 05:04:51 -0600 (CST) Subject: Xorg radeon drivers In-Reply-To: <20080118084659.GB29940@wolff.to> References: <1200631491.2150.2.camel@scrappy.miketc.com> <1200636379.29147.0.camel@localhost> <20080118084659.GB29940@wolff.to> Message-ID: <52636.192.168.0.1.1200654291.squirrel@mail.jcomserv.net> > On Fri, Jan 18, 2008 at 16:06:19 +1000, > Dave Airlie wrote: >> >> On Thu, 2008-01-17 at 22:44 -0600, Mike Chambers wrote: >> > Ajax, >> > >> > I know there was discussion on this, or still is, but wanted to get >> > something clarified. Have you made up your mind on what package(s) to >> > put ati drivers (latest anyway) in? Cause in F8 I used to have to run >> > in vesa mode to get my resolutionl, but in rawhide it's using radeon >> and >> > proper resolution is being used. >> >> Also F8 updates-testing should work fine.. > > I have had problems with xorg-x11-drv-ati-6.7.196-5.fc8 and have reverted > to > using xorg-x11-drv-ati-6.7.196-2.fc8. Though in my case I have a 9200, so > he might be better off with the updates-testing version, even though it > doesn't work for me. Now that's funny, I have a 9200, and I use the same driver, and I've been having bizarre symptoms that I've been trying to quanify properly for a BZ. Some things won't launch locally, or crash right away, but if I run the same app onthe same box remotely with either NX or X->ssh tunnelling, it displays fine on the other box. Is that anything like what you've been seeing? > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From harald at redhat.com Fri Jan 18 11:52:08 2008 From: harald at redhat.com (Harald Hoyer) Date: Fri, 18 Jan 2008 12:52:08 +0100 Subject: koji: sslv3 alert certificate expired In-Reply-To: <200801181113.33212.opensource@till.name> References: <200801181113.33212.opensource@till.name> Message-ID: Till Maas wrote: > On Fri January 18 2008, Harald Hoyer wrote: >> $ make build >> : [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 >> alert certificate expired'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl >> handshake failure')] >> make: *** [koji] Error 1 > > http://fedoraproject.org/wiki/PackageMaintainers/UsingCvsFaq#head-f003c4260a18a6b9ac472da9e7d56891ae5508c2 > Thank you :) Thought it was on the server side (would not have been the first time) :) From harald at redhat.com Fri Jan 18 11:56:46 2008 From: harald at redhat.com (Harald Hoyer) Date: Fri, 18 Jan 2008 12:56:46 +0100 Subject: koji: sslv3 alert certificate expired In-Reply-To: References: <200801181113.33212.opensource@till.name> Message-ID: Harald Hoyer wrote: > Till Maas wrote: >> On Fri January 18 2008, Harald Hoyer wrote: >>> $ make build >>> : [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 >>> alert certificate expired'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl >>> handshake failure')] >>> make: *** [koji] Error 1 >> >> http://fedoraproject.org/wiki/PackageMaintainers/UsingCvsFaq#head-f003c4260a18a6b9ac472da9e7d56891ae5508c2 >> >> > > Thank you :) > > Thought it was on the server side (would not have been the first time) :) > maybe the koji client could display a reasonable error message hinting to the wiki page From snecklifter at gmail.com Fri Jan 18 12:17:57 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Fri, 18 Jan 2008 12:17:57 +0000 Subject: blacklisted iwl4965 ?? In-Reply-To: <20080118080211.GM29887@angus.ind.WPI.EDU> References: <20080118080211.GM29887@angus.ind.WPI.EDU> Message-ID: <364d303b0801180417h252b226du561b2c64d308ccd1@mail.gmail.com> On 18/01/2008, Chuck Anderson wrote: > I just did a fresh rawhide install and found this in > /etc/modprobe.d/blacklist: > > # don't load iwl4965 by default, bug 245379 > blacklist iwl4965 > > https://bugzilla.redhat.com/show_bug.cgi?id=245379 > > Does someone have any better explanation for this than the 6+ month > old bug report for RHEL 5? What are us iwl4965 users supposed to be > using? Its being superceded by all that funky mac80211 stuff, no? I am not an intel wireless user though so find the whole thing very confusing... :) -- Christopher Brown http://www.chruz.com From opensource at till.name Fri Jan 18 12:05:24 2008 From: opensource at till.name (Till Maas) Date: Fri, 18 Jan 2008 13:05:24 +0100 Subject: koji: sslv3 alert certificate expired In-Reply-To: References: Message-ID: <200801181305.29167.opensource@till.name> On Fri January 18 2008, Harald Hoyer wrote: > maybe the koji client could display a reasonable error message hinting to > the wiki page Yes I totally agree. You can request this feature with a new ticket here: https://fedorahosted.org/koji/newticket Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From jima at beer.tclug.org Fri Jan 18 12:35:58 2008 From: jima at beer.tclug.org (Jima) Date: Fri, 18 Jan 2008 06:35:58 -0600 (CST) Subject: Wild buildsys reports? In-Reply-To: <47906E0D.3040408@leemhuis.info> References: <200801180846.29537.jamatos@fc.up.pt> <1200646420.9954.143.camel@Jehannum> <47906BBA.8030207@hhs.nl> <47906E0D.3040408@leemhuis.info> Message-ID: On Fri, 18 Jan 2008, Thorsten Leemhuis wrote: > On 18.01.2008 10:04, Hans de Goede wrote: >> Sofar I only received 124 of them, I wonder when I get the remaining 76, or has >> someone stopped this madness? > > I suppose you might get even more, as afaics you not only get them for > your own packages, but also for packages owned by other people if one of > your packages is a missing dep there. ;-) Man, never have I felt so fortunate that next to nothing depends on my packages. :-) Jima From opensource at till.name Fri Jan 18 12:36:06 2008 From: opensource at till.name (Till Maas) Date: Fri, 18 Jan 2008 13:36:06 +0100 Subject: blacklisted iwl4965 ?? In-Reply-To: <20080118080211.GM29887@angus.ind.WPI.EDU> References: <20080118080211.GM29887@angus.ind.WPI.EDU> Message-ID: <200801181336.17150.opensource@till.name> On Fri January 18 2008, Chuck Anderson wrote: > Does someone have any better explanation for this than the 6+ month > old bug report for RHEL 5? What are us iwl4965 users supposed to be > using? Maybe you find something better, when you look at the output of modprobe -l | grep wireless | sort I do not have a rawhide kernel, therefore I do not know what this would produce. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From snecklifter at gmail.com Fri Jan 18 12:53:42 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Fri, 18 Jan 2008 12:53:42 +0000 Subject: anyone willing to package libmspack? In-Reply-To: <20080117214803.GA2568@free.fr> References: <20080117214803.GA2568@free.fr> Message-ID: <364d303b0801180453m289a1f6aue030b6fa89dd3c29@mail.gmail.com> On 17/01/2008, Patrice Dumas wrote: > Hello, > > Some packages use internal versions of libmspack, according to > https://bugzilla.redhat.com/show_bug.cgi?id=427638 > samba, clamav. And cabextract. > > I don't want to maintain one more package but would review it. Did anyone else think this was a request to package Max Spevack's libraries? (sorry Patrice, couldn't resist) -- Christopher Brown http://www.chruz.com From dwalsh at redhat.com Fri Jan 18 13:30:44 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 18 Jan 2008 08:30:44 -0500 Subject: SELinux removed from desktop cd spin? In-Reply-To: <20080117191051.GB84707@dspnet.fr.eu.org> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <478F857A.6030502@redhat.com> <20080117180251.GA77139@dspnet.fr.eu.org> <200801171920.32764.opensource@till.name> <1200594904.3259.143.camel@cassandra.boston.redhat.com> <478FA30A.6030405@redhat.com> <20080117191051.GB84707@dspnet.fr.eu.org> Message-ID: <4790AA04.2020409@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Olivier Galibert wrote: > On Thu, Jan 17, 2008 at 01:48:42PM -0500, Daniel J Walsh wrote: >> >> >>

>> Allow unconfined executables to map a memory region as both executable >> and writable, this is dangerous and the executable should be reported in >> bugzilla") > > That should be "to map a file in a memory region", as UD's page > explains. Otherwise anyone who knows a little about dynamic > recompilers/JITs is gonna go "huh?". > > OG. > Bad cut and paste. The one I pasted was for allow_execmem. Where the definition is correct. java/mono apps are not confined by this, since they run under a different context.

Allow all unconfined executables to use libraries requiring text relocation that are not labeled textrel_shlib_t")

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkeQqgMACgkQrlYvE4MpobMllACfbUExz5TnteGJqrtJVpg+p7q6 f0EAoOX4qBNtr/svMG28E8X6sLYnBW2F =tFNe -----END PGP SIGNATURE----- From ssorce at redhat.com Fri Jan 18 13:55:43 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 18 Jan 2008 08:55:43 -0500 Subject: Cast your vote for the Fedora 9 Codename! In-Reply-To: <20080118022457.GA1991@nostromo.devel.redhat.com> References: <20080116184835.1bddf0f3@zod.rchland.ibm.com> <1200536182.920.64.camel@calliope.phig.org> <200801171318.m0HDGRqx011867@laptop13.inf.utfsm.cl> <1200591438.920.119.camel@calliope.phig.org> <80d7e4090801171805t3abb9651ie8ff1390267c51e@mail.gmail.com> <20080118022457.GA1991@nostromo.devel.redhat.com> Message-ID: <1200664543.10767.119.camel@localhost.localdomain> On Thu, 2008-01-17 at 21:24 -0500, Bill Nottingham wrote: > Stephen John Smoogen (smooge at gmail.com) said: > > Is campaigning for a name legal? > > I don't know. It probably depends on how the Campaign For the Chupacabra > Of the Future gets its funding. Aww what happened to my beloved Anubis (not on the list :/) ? Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From katzj at redhat.com Fri Jan 18 14:01:33 2008 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 18 Jan 2008 09:01:33 -0500 Subject: blacklisted iwl4965 ?? In-Reply-To: <20080118080211.GM29887@angus.ind.WPI.EDU> References: <20080118080211.GM29887@angus.ind.WPI.EDU> Message-ID: <1200664893.7520.2.camel@aglarond.local> On Fri, 2008-01-18 at 03:02 -0500, Chuck Anderson wrote: > I just did a fresh rawhide install and found this in > /etc/modprobe.d/blacklist: [snip] > Does someone have any better explanation for this than the 6+ month > old bug report for RHEL 5? What are us iwl4965 users supposed to be > using? Looks like a merge problem -- and it looks like Karsten has already committed changes to switch back and not do the RHEL blacklist pieces[1] on Fedora Jeremy From katzj at redhat.com Fri Jan 18 14:02:28 2008 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 18 Jan 2008 09:02:28 -0500 Subject: anaconda support for encrypted LVs (as opposed to PVs) In-Reply-To: <20080117225733.GL29887@angus.ind.WPI.EDU> References: <20080117225733.GL29887@angus.ind.WPI.EDU> Message-ID: <1200664948.7520.4.camel@aglarond.local> On Thu, 2008-01-17 at 17:57 -0500, Chuck Anderson wrote: > A while back I was told that Anaconda supported creating encrypted > LVs, but it appears as of today's rawhide it only supports encrypted > PVs. Is that true? If not, what is the magic UI sequence that allows > LVs to be created and encrypted? It should work -- there should just be a checkbox for Encrypt on the LV creation dialog. If not, file a bug :) Jeremy From matt at truch.net Fri Jan 18 14:17:14 2008 From: matt at truch.net (Matthew D Truch) Date: Fri, 18 Jan 2008 09:17:14 -0500 Subject: Orphaning gpsd Message-ID: <20080118141714.GA21107@truch.net> Greetings, I no longer have as much free time to work on Fedora, so I'm orphaning the package which I no longer use, gpsd. It would be awesome if someone would take gpsd over. -- "Ice Cream has no bones." -------------------------- Matthew Truch Department of Physics and Astronomy University of Pennsylvania matt at truch.net http://matt.truch.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jcm at redhat.com Fri Jan 18 14:18:34 2008 From: jcm at redhat.com (Jon Masters) Date: Fri, 18 Jan 2008 09:18:34 -0500 Subject: Broken dependencies? In-Reply-To: <1200650495.23175.90.camel@jndwidescreen.lesbg.loc> References: <1200650375.23175.87.camel@jndwidescreen.lesbg.loc> <1200650495.23175.90.camel@jndwidescreen.lesbg.loc> Message-ID: <1200665914.13187.0.camel@perihelion> On Fri, 2008-01-18 at 12:01 +0200, Jonathan Dieter wrote: > Feel free to ignore this. I missed the other messages about the same > problem. You're not the only one :-) Jon. From jcm at redhat.com Fri Jan 18 14:21:15 2008 From: jcm at redhat.com (Jon Masters) Date: Fri, 18 Jan 2008 09:21:15 -0500 Subject: blacklisted iwl4965 ?? In-Reply-To: <1200664893.7520.2.camel@aglarond.local> References: <20080118080211.GM29887@angus.ind.WPI.EDU> <1200664893.7520.2.camel@aglarond.local> Message-ID: <1200666075.13187.3.camel@perihelion> On Fri, 2008-01-18 at 09:01 -0500, Jeremy Katz wrote: > On Fri, 2008-01-18 at 03:02 -0500, Chuck Anderson wrote: > > I just did a fresh rawhide install and found this in > > /etc/modprobe.d/blacklist: > [snip] > > Does someone have any better explanation for this than the 6+ month > > old bug report for RHEL 5? What are us iwl4965 users supposed to be > > using? > > Looks like a merge problem -- and it looks like Karsten has already > committed changes to switch back and not do the RHEL blacklist pieces[1] > on Fedora FWIW, the original IPW driver is likely to die a death in due course, so we'll probably all want to be using the IWL driver soon enough. Jon. From mschwendt.tmp0701.nospam at arcor.de Fri Jan 18 14:22:55 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 18 Jan 2008 15:22:55 +0100 Subject: Wild buildsys reports? In-Reply-To: <1200648012.9899.10.camel@ignacio.lan> References: <200801180846.29537.jamatos@fc.up.pt> <1200648012.9899.10.camel@ignacio.lan> Message-ID: <20080118152255.618a29af.mschwendt.tmp0701.nospam@arcor.de> On Fri, 18 Jan 2008 04:20:11 -0500, Ignacio Vazquez-Abrams wrote: > On Fri, 2008-01-18 at 08:46 +0000, Jos? Matos wrote: > > I have been receiving reports of broken for all the packages I maintain > > and/or indirectly dependent. > > > > The report are very suspicious in the sense that they complain about > > everything. > > Looks like mash imploded. I'd just ignore them for now. Other packagers don't, however, and are active rebuilding their packages. Just watch commits-list. ;) Hopefully they don't sync their bumped spec files to F-8. From silfreed at silfreed.net Fri Jan 18 14:22:00 2008 From: silfreed at silfreed.net (Douglas E. Warner) Date: Fri, 18 Jan 2008 09:22:00 -0500 Subject: Orphaning gpsd In-Reply-To: <20080118141714.GA21107@truch.net> References: <20080118141714.GA21107@truch.net> Message-ID: <200801180922.00542.silfreed@silfreed.net> On Friday 18 January 2008, Matthew D Truch wrote: > I no longer have as much free time to work on Fedora, so I'm orphaning > the package which I no longer use, gpsd. > > It would be awesome if someone would take gpsd over. I've applied to take over the package. If others would like to co-maintain it, the more the merrier. -Doug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From jonstanley at gmail.com Fri Jan 18 14:23:32 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Fri, 18 Jan 2008 09:23:32 -0500 Subject: Fedora bug triage - workflow proposal In-Reply-To: References: <20080115092452.245d5604@ghistelwchlohm.scrye.com> Message-ID: On Jan 16, 2008 1:21 AM, Jon Stanley wrote: > Created at http://fedoraproject.org/wiki/JonStanley/BugWorkflow This has been updated - the ON_DEV state has been removed is the major change. This *is* going before FESCo for a vote, so PLEASE make comments on that wiki page if you have strong opinions on the topic. From jakub.rusinek at gmail.com Fri Jan 18 14:24:41 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Fri, 18 Jan 2008 15:24:41 +0100 Subject: compilation architecture In-Reply-To: <20080118010324.b45bd216.mschwendt.tmp0701.nospam@arcor.de> References: <5e92ee3f0801161242w2e6c9340lee2eed34cfc3158f@mail.gmail.com> <20080118010324.b45bd216.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <5e92ee3f0801180624w53c16622le1dd321b348c2efd@mail.gmail.com> 2008/1/18, Michael Schwendt : > > On Wed, 16 Jan 2008 21:42:24 +0100, Jakub 'Livio' Rusinek wrote: > > > I have two bootcharts. > > > > Fedora's: http://img.wklej.org/images/77224fedora-bootchart.png > > openSUSE's: http://img.wklej.org/images/50076opensuse-bootchart.png > > > > Look at many differencies. > > No. > > In short what you got is: > > openSUSE: 39 seconds > Fedora: 41 seconds inspite of a very slow networking init > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I cannot use NetworkManager, because Samba over DHCP doesn't work. Also, NM for now doesn't use network config files (it's probably done in SVN). GDM is loaded earlier - starting feels much shorter. Also, I've found reason of faster opengl drawing! They include GARTSize option in Device section (for radeon). This makes improvement of drawing, but makes me use XaaNoOffscreenPixmaps to avoid shadow bug in Compiz. Also, without LIBGL_ALWAYS_INDIRECT Compiz wont start (it's not a problem for me). -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakub.rusinek at gmail.com Fri Jan 18 14:27:16 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Fri, 18 Jan 2008 15:27:16 +0100 Subject: compilation architecture In-Reply-To: <20080118010334.a6e31dd7.mschwendt.tmp0701.nospam@arcor.de> References: <5e92ee3f0801120926u7e67b39fk80f18d0420f867cc@mail.gmail.com> <5e92ee3f0801150711o9108b7apf83f4ae132b894e4@mail.gmail.com> <1200411358.15130.271.camel@localhost.localdomain> <5e92ee3f0801150726v2d708d70x7e51087f0bb0a254@mail.gmail.com> <20080115165601.67bdf81e.mschwendt.tmp0701.nospam@arcor.de> <5e92ee3f0801150831t685810f1jb2ac41c7975a1675@mail.gmail.com> <5e92ee3f0801160509x6655b9car15171ec594744d60@mail.gmail.com> <20080116164427.0361c924.mschwendt.tmp0701.nospam@arcor.de> <5e92ee3f0801160756o2aa5750cu4b403c8c405c2d69@mail.gmail.com> <20080118010334.a6e31dd7.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <5e92ee3f0801180627rf1ebbb0w17f4488320e5e55a@mail.gmail.com> 2008/1/18, Michael Schwendt : > > On Wed, 16 Jan 2008 16:56:58 +0100, Jakub 'Livio' Rusinek wrote: > > > > On Wed, 16 Jan 2008 14:09:13 +0100, Jakub 'Livio' Rusinek wrote: > > > > > > > Ok, I've installed openSUSE and configured it like my Fedora. > > I went through the pains of installing openSUSE 10.3 for GNOME. Except for > the installation settings, which I adjusted only minimally, I used the > defaults and I did not reconfigure anything after booting the first time. > > I explicitly did not enable the non-free repository. > > First thing I noticed: harddisk access in openSUSE happens at half the > speed of Fedora. hdparm -t confirms it whereas hdparm -T results for > cache reads are about the same for both systems. > > This difference in disk access had a bad effect on some data processing > speed tests. For huge files, openSUSE was about 33% slower in overall > execution time, and I almost stopped at that point. > > For tests with smaller files, openSUSE computed approx. 3% faster than > Fedora 8 (this is on AMD Athlon). Sometimes 2%, sometimes a bit more than > 3%, but I didn't spend the time to take more than 1 or 2 samples each. And > it was unconvincing enough to even consider comparing special computations > of e.g. ASM-optimised A/V codecs. > > The openSUSE GNOME Desktop does not feel any snappier to me. Not when > starting applications and not when opening xterm either. Though, I've > noticed that when dragging xterm from the menu onto the desktop, an > invalid launcher file is created and gives an error. ;) > > Firefox (it's 2.0.0.6 in openSUSE and 2.0.0.10 in F8) in Fedora 8 starts > and exits from within a terminal in roughly 4.3 seconds (reproducibly) > when quickly pressing Ctrl+W as soon as the window appears. That should > mimic your own test procedure. In openSUSE it did that in approx. 6 > seconds, and possibly due to the disk access issues I had difficulties in > trying to start and close it faster than in 5-6 seconds. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > But notice that I've used Firefox 3. It's MUCH faster than Firefox 2. They removed many memory leaks and improved many things (eg they're using Cairo for drawing interface and websites). Only thing that I do not like now is starting apps. It takes sometimes very long for eg Nautilus to open some window (in browser mode, ofc). -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From drago01 at gmail.com Fri Jan 18 14:41:33 2008 From: drago01 at gmail.com (drago01) Date: Fri, 18 Jan 2008 15:41:33 +0100 Subject: compilation architecture In-Reply-To: <5e92ee3f0801180624w53c16622le1dd321b348c2efd@mail.gmail.com> References: <5e92ee3f0801161242w2e6c9340lee2eed34cfc3158f@mail.gmail.com> <20080118010324.b45bd216.mschwendt.tmp0701.nospam@arcor.de> <5e92ee3f0801180624w53c16622le1dd321b348c2efd@mail.gmail.com> Message-ID: 2008/1/18 Jakub 'Livio' Rusinek : > 2008/1/18, Michael Schwendt : > > > > On Wed, 16 Jan 2008 21:42:24 +0100, Jakub 'Livio' Rusinek wrote: > > > > > I have two bootcharts. > > > > > > Fedora's: http://img.wklej.org/images/77224fedora-bootchart.png > > > openSUSE's: http://img.wklej.org/images/50076opensuse-bootchart.png > > > > > > Look at many differencies. > > > > No. > > > > In short what you got is: > > > > openSUSE: 39 seconds > > Fedora: 41 seconds inspite of a very slow networking init > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > I cannot use NetworkManager, because Samba over DHCP doesn't work. works fine here. > GDM is loaded earlier - starting feels much shorter. we had this in earilier releases, but this does not fix anything it just hiddes the real issues. > Also, I've found reason of faster opengl drawing! benchmarks? > They include GARTSize option in Device section (for radeon). This makes > improvement of drawing, but makes me use XaaNoOffscreenPixmaps to avoid > shadow bug in Compiz. I don't have a radeon card so I can't comment on this. > Also, without LIBGL_ALWAYS_INDIRECT Compiz wont start > (it's not a problem for me). where fedora or openSUSE ? On fedora desktop-effekts takes care of this. From fedora at leemhuis.info Fri Jan 18 15:08:46 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 18 Jan 2008 16:08:46 +0100 Subject: compilation architecture In-Reply-To: References: <5e92ee3f0801161242w2e6c9340lee2eed34cfc3158f@mail.gmail.com> <20080118010324.b45bd216.mschwendt.tmp0701.nospam@arcor.de> <5e92ee3f0801180624w53c16622le1dd321b348c2efd@mail.gmail.com> Message-ID: <4790C0FE.40905@leemhuis.info> On 18.01.2008 15:41, drago01 wrote: >> GDM is loaded earlier - starting feels much shorter. > we had this in earilier releases, Are you sure? IIRC gdm-early-login never left the experimental stage. > but this does not fix anything it just hiddes the real issues. I tend to disagree a small bit. It could be a net win if we'd use the time while the user logs in (?) for other things in the background (loading things that we know will be used into the cache, start non-crucial daemons, ....). It works well in Opensuse and the boot feels faster (even if it's sometimes not that much faster if you measure it with a stopwatch). CU knurd (?) currently afaics the computer mainly is waiting for the user to type username and password (which can take 5 seconds or more -- depending on how fast you type and if you are actually around when GDM shows up), thus there are a lot of spare cycles that could be used for other things From matt at truch.net Fri Jan 18 15:10:37 2008 From: matt at truch.net (Matthew D Truch) Date: Fri, 18 Jan 2008 10:10:37 -0500 Subject: Orphaning gpsd In-Reply-To: <200801180922.00542.silfreed@silfreed.net> References: <20080118141714.GA21107@truch.net> <200801180922.00542.silfreed@silfreed.net> Message-ID: <20080118151037.GC21107@truch.net> On Fri, Jan 18, 2008 at 09:22:00AM -0500, Douglas E. Warner wrote: > On Friday 18 January 2008, Matthew D Truch wrote: > > I no longer have as much free time to work on Fedora, so I'm orphaning > > the package which I no longer use, gpsd. > > > > It would be awesome if someone would take gpsd over. > > I've applied to take over the package. If others would like to co-maintain > it, the more the merrier. Great. Let me know if I can help out (by passing along any info or explaining any crap that I've done). Also note that there is a bugfix release that came out around the new year (to fix a y2k8 bug!) which I haven't had time to push. -- "Physics isn't difficult; it's just weird. -- Vincent Icke" -------------------------- Matthew Truch Department of Physics and Astronomy University of Pennsylvania matt at truch.net http://matt.truch.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jakub.rusinek at gmail.com Fri Jan 18 15:19:15 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Fri, 18 Jan 2008 16:19:15 +0100 Subject: compilation architecture In-Reply-To: References: <5e92ee3f0801161242w2e6c9340lee2eed34cfc3158f@mail.gmail.com> <20080118010324.b45bd216.mschwendt.tmp0701.nospam@arcor.de> <5e92ee3f0801180624w53c16622le1dd321b348c2efd@mail.gmail.com> Message-ID: <5e92ee3f0801180719j831c136x8d12b4c3db2e8da@mail.gmail.com> 2008/1/18, drago01 : > > 2008/1/18 Jakub 'Livio' Rusinek : > > 2008/1/18, Michael Schwendt : > > > > > > > On Wed, 16 Jan 2008 21:42:24 +0100, Jakub 'Livio' Rusinek wrote: > > > > > > > I have two bootcharts. > > > > > > > > Fedora's: http://img.wklej.org/images/77224fedora-bootchart.png > > > > openSUSE's: http://img.wklej.org/images/50076opensuse-bootchart.png > > > > > > > > Look at many differencies. > > > > > > No. > > > > > > In short what you got is: > > > > > > openSUSE: 39 seconds > > > Fedora: 41 seconds inspite of a very slow networking init > > > > > > -- > > > fedora-devel-list mailing list > > > fedora-devel-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > > I cannot use NetworkManager, because Samba over DHCP doesn't work. > > works fine here. > > > > GDM is loaded earlier - starting feels much shorter. > > we had this in earilier releases, but this does not fix anything it > just hiddes the real issues. > > > Also, I've found reason of faster opengl drawing! > benchmarks? > > They include GARTSize option in Device section (for radeon). This makes > > improvement of drawing, but makes me use XaaNoOffscreenPixmaps to avoid > > shadow bug in Compiz. > > I don't have a radeon card so I can't comment on this. > > > Also, without LIBGL_ALWAYS_INDIRECT Compiz wont start > > (it's not a problem for me). > > where fedora or openSUSE ? > On fedora desktop-effekts takes care of this. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I'm not using desktop-effects. I'm modifying /usr/bin/gnome-wm and using gnome-wm for starting WM. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakub.rusinek at gmail.com Fri Jan 18 15:24:51 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Fri, 18 Jan 2008 16:24:51 +0100 Subject: packaging: new spec filed idea Message-ID: <5e92ee3f0801180724g7f2f2cd4i491d535a604e3fa8@mail.gmail.com> hi, I have simple idea. PackageKit in its search results component shows items with package-x-generic icon: http://fedoraproject.org/wiki/Interviews/PackageKit?action=AttachFile&do=get&target=pk-application-search.png I think that SPEC should have "Icon: " filed which would tell PK and others to display that icon from current icon theme. Then PK instead of generic package icon would should eg Firefox icon, gedit, gnome-terminal, etc. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdehaan at redhat.com Fri Jan 18 15:38:50 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 18 Jan 2008 10:38:50 -0500 Subject: Cast your vote for the Fedora 9 Codename! In-Reply-To: <1200664543.10767.119.camel@localhost.localdomain> References: <20080116184835.1bddf0f3@zod.rchland.ibm.com> <1200536182.920.64.camel@calliope.phig.org> <200801171318.m0HDGRqx011867@laptop13.inf.utfsm.cl> <1200591438.920.119.camel@calliope.phig.org> <80d7e4090801171805t3abb9651ie8ff1390267c51e@mail.gmail.com> <20080118022457.GA1991@nostromo.devel.redhat.com> <1200664543.10767.119.camel@localhost.localdomain> Message-ID: <4790C80A.6030302@redhat.com> Simo Sorce wrote: > On Thu, 2008-01-17 at 21:24 -0500, Bill Nottingham wrote: > >> Stephen John Smoogen (smooge at gmail.com) said: >> >>> Is campaigning for a name legal? >>> >> I don't know. It probably depends on how the Campaign For the Chupacabra >> Of the Future gets its funding. >> > > Aww what happened to my beloved Anubis (not on the list :/) ? > > Simo. > > I heard there were other projects named that, apparently. Which is too bad, so you should all vote for Dragicorn instead :) --Michael From notting at redhat.com Fri Jan 18 15:50:35 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 18 Jan 2008 10:50:35 -0500 Subject: rawhide broken dependency reports for today... Message-ID: <20080118155035.GA26985@nostromo.devel.redhat.com> Please ignore them. There was a problem with the rawhide compose; it managed to miss pulling in various pieces, leading to the dependency chaos you see in the messages. Apologies for the inconvenience. Bill From notting at redhat.com Fri Jan 18 15:51:55 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 18 Jan 2008 10:51:55 -0500 Subject: packaging: new spec filed idea In-Reply-To: <5e92ee3f0801180724g7f2f2cd4i491d535a604e3fa8@mail.gmail.com> References: <5e92ee3f0801180724g7f2f2cd4i491d535a604e3fa8@mail.gmail.com> Message-ID: <20080118155155.GB26985@nostromo.devel.redhat.com> Jakub 'Livio' Rusinek (jakub.rusinek at gmail.com) said: > PackageKit in its search results component shows items with > package-x-generic icon: > http://fedoraproject.org/wiki/Interviews/PackageKit?action=AttachFile&do=get&target=pk-application-search.png > > I think that SPEC should have "Icon: " filed which would tell PK and others > to display that icon from current icon theme. > > Then PK instead of generic package icon would should eg Firefox icon, gedit, > gnome-terminal, etc. This would require: a) all the packages put this PNG info in the header b) all this information make it into the repository data c) all users would have to download the icons for *all packages* before trying an update That last one is the killer. Bill From ssorce at redhat.com Fri Jan 18 15:59:43 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 18 Jan 2008 15:59:43 +0000 Subject: packaging: new spec filed idea In-Reply-To: <20080118155155.GB26985@nostromo.devel.redhat.com> References: <5e92ee3f0801180724g7f2f2cd4i491d535a604e3fa8@mail.gmail.com> <20080118155155.GB26985@nostromo.devel.redhat.com> Message-ID: <1200671983.10767.140.camel@localhost.localdomain> On Fri, 2008-01-18 at 10:51 -0500, Bill Nottingham wrote: > Jakub 'Livio' Rusinek (jakub.rusinek at gmail.com) said: > > PackageKit in its search results component shows items with > > package-x-generic icon: > > http://fedoraproject.org/wiki/Interviews/PackageKit?action=AttachFile&do=get&target=pk-application-search.png > > > > I think that SPEC should have "Icon: " filed which would tell PK and others > > to display that icon from current icon theme. > > > > Then PK instead of generic package icon would should eg Firefox icon, gedit, > > gnome-terminal, etc. > > This would require: > > a) all the packages put this PNG info in the header > b) all this information make it into the repository data > c) all users would have to download the icons for *all packages* before trying > an update > > That last one is the killer. Nah, you just embed the icon in the metadata like windows does for .exe files Simo. P.S: j/k no flames :) -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From galibert at pobox.com Fri Jan 18 16:12:36 2008 From: galibert at pobox.com (Olivier Galibert) Date: Fri, 18 Jan 2008 17:12:36 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <4790AA04.2020409@redhat.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <478F857A.6030502@redhat.com> <20080117180251.GA77139@dspnet.fr.eu.org> <200801171920.32764.opensource@till.name> <1200594904.3259.143.camel@cassandra.boston.redhat.com> <478FA30A.6030405@redhat.com> <20080117191051.GB84707@dspnet.fr.eu.org> <4790AA04.2020409@redhat.com> Message-ID: <20080118161236.GA61848@dspnet.fr.eu.org> On Fri, Jan 18, 2008 at 08:30:44AM -0500, Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Olivier Galibert wrote: > > On Thu, Jan 17, 2008 at 01:48:42PM -0500, Daniel J Walsh wrote: > >> > >> > >>

> >> Allow unconfined executables to map a memory region as both executable > >> and writable, this is dangerous and the executable should be reported in > >> bugzilla") > > > > That should be "to map a file in a memory region", as UD's page > > explains. Otherwise anyone who knows a little about dynamic > > recompilers/JITs is gonna go "huh?". > > > > OG. > > > Bad cut and paste. The one I pasted was for allow_execmem. Where the > definition is correct. You mean Ulrich's page is incorrect then? I indeed had noticed it was about execmem. > java/mono apps are not confined by this, since > they run under a different context. Java/Mono are not the only programs with dynamic code generators in them. OG. From cra at WPI.EDU Fri Jan 18 16:13:18 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 18 Jan 2008 11:13:18 -0500 Subject: rawhide broken dependency reports for today... In-Reply-To: <20080118155035.GA26985@nostromo.devel.redhat.com> References: <20080118155035.GA26985@nostromo.devel.redhat.com> Message-ID: <20080118161317.GG26108@angus.ind.WPI.EDU> On Fri, Jan 18, 2008 at 10:50:35AM -0500, Bill Nottingham wrote: > Please ignore them. There was a problem with the rawhide compose; > it managed to miss pulling in various pieces, leading to the dependency > chaos you see in the messages. Apologies for the inconvenience. Ok, that explains why there is no anaconda... From jakub.rusinek at gmail.com Fri Jan 18 16:13:59 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Fri, 18 Jan 2008 17:13:59 +0100 Subject: packaging: new spec filed idea In-Reply-To: <1200671983.10767.140.camel@localhost.localdomain> References: <5e92ee3f0801180724g7f2f2cd4i491d535a604e3fa8@mail.gmail.com> <20080118155155.GB26985@nostromo.devel.redhat.com> <1200671983.10767.140.camel@localhost.localdomain> Message-ID: <5e92ee3f0801180813s66422393x3cc90500eda5ad76@mail.gmail.com> > c) all users would have to download the icons for *all packages* before trying > an update Downloading? For what? "Icon: " should contain icon name from icon theme. Eg banshee package would contain "Icon: banshee" in SPEC. Hicolor icon theme would contain this icon and PackageKit would display it. Nah, you just embed the icon in the metadata like windows does for .exe > files > I don't think it's good... Hmmm, I have idea to realize it. All icons (those not available in icon themes) should be contained in hicolor-icon-theme. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cra at WPI.EDU Fri Jan 18 16:18:43 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 18 Jan 2008 11:18:43 -0500 Subject: anaconda support for encrypted LVs (as opposed to PVs) In-Reply-To: <1200664948.7520.4.camel@aglarond.local> References: <20080117225733.GL29887@angus.ind.WPI.EDU> <1200664948.7520.4.camel@aglarond.local> Message-ID: <20080118161843.GH26108@angus.ind.WPI.EDU> On Fri, Jan 18, 2008 at 09:02:28AM -0500, Jeremy Katz wrote: > On Thu, 2008-01-17 at 17:57 -0500, Chuck Anderson wrote: > > A while back I was told that Anaconda supported creating encrypted > > LVs, but it appears as of today's rawhide it only supports encrypted > > PVs. Is that true? If not, what is the magic UI sequence that allows > > LVs to be created and encrypted? > > It should work -- there should just be a checkbox for Encrypt on the LV > creation dialog. If not, file a bug :) Done, #429299. From notting at redhat.com Fri Jan 18 16:20:15 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 18 Jan 2008 11:20:15 -0500 Subject: packaging: new spec filed idea In-Reply-To: <5e92ee3f0801180813s66422393x3cc90500eda5ad76@mail.gmail.com> References: <5e92ee3f0801180724g7f2f2cd4i491d535a604e3fa8@mail.gmail.com> <20080118155155.GB26985@nostromo.devel.redhat.com> <1200671983.10767.140.camel@localhost.localdomain> <5e92ee3f0801180813s66422393x3cc90500eda5ad76@mail.gmail.com> Message-ID: <20080118162015.GC26753@nostromo.devel.redhat.com> Jakub 'Livio' Rusinek (jakub.rusinek at gmail.com) said: > Hmmm, I have idea to realize it. > All icons (those not available in icon themes) should be contained in > hicolor-icon-theme. I think updating the hicolor-icon-theme package every time we add a new app to Fedora, or any time such an app changes its icon, is somewhere beyond impractical. Bill From jos at xos.nl Fri Jan 18 16:21:33 2008 From: jos at xos.nl (Jos Vos) Date: Fri, 18 Jan 2008 17:21:33 +0100 Subject: packaging: new spec filed idea In-Reply-To: <5e92ee3f0801180724g7f2f2cd4i491d535a604e3fa8@mail.gmail.com> References: <5e92ee3f0801180724g7f2f2cd4i491d535a604e3fa8@mail.gmail.com> Message-ID: <20080118162133.GC26915@jasmine.xos.nl> On Fri, Jan 18, 2008 at 04:24:51PM +0100, Jakub 'Livio' Rusinek wrote: > I think that SPEC should have "Icon: " filed which would tell PK and others > to display that icon from current icon theme. I thought the "Icon" tag was deprecated in RPM, but I can't find that back now. Anyway, it's a lot of hassle (with all possible problems, like referring to non-existing icons, synchronizing new icons etc.) for a rather small cosmetic issue. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From jos at xos.nl Fri Jan 18 16:23:38 2008 From: jos at xos.nl (Jos Vos) Date: Fri, 18 Jan 2008 17:23:38 +0100 Subject: packaging: new spec filed idea In-Reply-To: <20080118162015.GC26753@nostromo.devel.redhat.com> References: <5e92ee3f0801180724g7f2f2cd4i491d535a604e3fa8@mail.gmail.com> <20080118155155.GB26985@nostromo.devel.redhat.com> <1200671983.10767.140.camel@localhost.localdomain> <5e92ee3f0801180813s66422393x3cc90500eda5ad76@mail.gmail.com> <20080118162015.GC26753@nostromo.devel.redhat.com> Message-ID: <20080118162338.GD26915@jasmine.xos.nl> On Fri, Jan 18, 2008 at 11:20:15AM -0500, Bill Nottingham wrote: > I think updating the hicolor-icon-theme package every time we add a > new app to Fedora, or any time such an app changes its icon, is > somewhere beyond impractical. Yes, and the issues you get when you want to rebuild the package for another environment, like EPEL, that may have a different icon set. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From jakub.rusinek at gmail.com Fri Jan 18 16:24:53 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Fri, 18 Jan 2008 17:24:53 +0100 Subject: packaging: new spec filed idea In-Reply-To: <20080118162133.GC26915@jasmine.xos.nl> References: <5e92ee3f0801180724g7f2f2cd4i491d535a604e3fa8@mail.gmail.com> <20080118162133.GC26915@jasmine.xos.nl> Message-ID: <5e92ee3f0801180824g214df523j84b44e5a874de139@mail.gmail.com> 2008/1/18, Jos Vos : > > On Fri, Jan 18, 2008 at 04:24:51PM +0100, Jakub 'Livio' Rusinek wrote: > > > I think that SPEC should have "Icon: " filed which would tell PK and > others > > to display that icon from current icon theme. > > I thought the "Icon" tag was deprecated in RPM, but I can't find > that back now. > > Anyway, it's a lot of hassle (with all possible problems, like > referring to non-existing icons, synchronizing new icons etc.) > for a rather small cosmetic issue. > > -- > -- Jos Vos > -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 > -- Amsterdam, The Netherlands | Fax: +31 20 6948204 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I had so good idea... Zero usability, zero future-thinking... Every idea I have is moving to trash. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From drago01 at gmail.com Fri Jan 18 16:38:13 2008 From: drago01 at gmail.com (drago01) Date: Fri, 18 Jan 2008 17:38:13 +0100 Subject: compilation architecture In-Reply-To: <4790C0FE.40905@leemhuis.info> References: <5e92ee3f0801161242w2e6c9340lee2eed34cfc3158f@mail.gmail.com> <20080118010324.b45bd216.mschwendt.tmp0701.nospam@arcor.de> <5e92ee3f0801180624w53c16622le1dd321b348c2efd@mail.gmail.com> <4790C0FE.40905@leemhuis.info> Message-ID: On Jan 18, 2008 4:08 PM, Thorsten Leemhuis wrote: > On 18.01.2008 15:41, drago01 wrote: > > >> GDM is loaded earlier - starting feels much shorter. > > we had this in earilier releases, yes but it was not on by default passing "early-login" to on the kernel cmd was needed to enable it. > Are you sure? IIRC gdm-early-login never left the experimental stage. > > > but this does not fix anything it just hiddes the real issues. > > I tend to disagree a small bit. It could be a net win if we'd use the > time while the user logs in (?) for other things in the background > (loading things that we know will be used into the cache, start > non-crucial daemons, ....). It works well in Opensuse and the boot feels > faster (even if it's sometimes not that much faster if you measure it > with a stopwatch). > > CU > knurd > > (?) currently afaics the computer mainly is waiting for the user to type > username and password (which can take 5 seconds or more -- depending on > how fast you type and if you are actually around when GDM shows up), > thus there are a lot of spare cycles that could be used for other things sure, but we somehow have to decide when to start gdm (ie to not break nfs homedirs etc) From jspaleta at gmail.com Fri Jan 18 16:41:55 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 18 Jan 2008 07:41:55 -0900 Subject: packaging: new spec filed idea In-Reply-To: <20080118162015.GC26753@nostromo.devel.redhat.com> References: <5e92ee3f0801180724g7f2f2cd4i491d535a604e3fa8@mail.gmail.com> <20080118155155.GB26985@nostromo.devel.redhat.com> <1200671983.10767.140.camel@localhost.localdomain> <5e92ee3f0801180813s66422393x3cc90500eda5ad76@mail.gmail.com> <20080118162015.GC26753@nostromo.devel.redhat.com> Message-ID: <604aa7910801180841u1a8b509cg428df28ceb7db3a@mail.gmail.com> On Jan 18, 2008 7:20 AM, Bill Nottingham wrote: > I think updating the hicolor-icon-theme package every time we add a new app to > Fedora, or any time such an app changes its icon, is somewhere beyond impractical. I'm not sure I understand the value of icons when searching for applications that you haven't already installed. But perhaps there is value in using icons for updates. My reasoning is, most people should have icon awareness for applications they use a lot. So is there a compromise here. Would it be worth embedding an icon name into repodata for a package, and if they icon exists on the system then the gui tools will use the icon in reference to a package update? But I don't know how you would drive that information into the repodata Is that something packagedb would have to do? For applications not already on the system, an icon representing the comps group or rpm group for which the package belongs is perhaps pulled from the hi-color set on system and displayed instead? But the underlying question that I cannot answer is if there is a real benefit to exposing icons at all. I'm not sure there is. And even if there is, I'm not sure its worth the complexity of implementing it. -jef From jakub.rusinek at gmail.com Fri Jan 18 16:49:37 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Fri, 18 Jan 2008 17:49:37 +0100 Subject: packaging: new spec filed idea In-Reply-To: <604aa7910801180841u1a8b509cg428df28ceb7db3a@mail.gmail.com> References: <5e92ee3f0801180724g7f2f2cd4i491d535a604e3fa8@mail.gmail.com> <20080118155155.GB26985@nostromo.devel.redhat.com> <1200671983.10767.140.camel@localhost.localdomain> <5e92ee3f0801180813s66422393x3cc90500eda5ad76@mail.gmail.com> <20080118162015.GC26753@nostromo.devel.redhat.com> <604aa7910801180841u1a8b509cg428df28ceb7db3a@mail.gmail.com> Message-ID: <5e92ee3f0801180849h3c978758ka91f4ccc70db5172@mail.gmail.com> 2008/1/18, Jeff Spaleta : > > On Jan 18, 2008 7:20 AM, Bill Nottingham wrote: > > I think updating the hicolor-icon-theme package every time we add a new > app to > > Fedora, or any time such an app changes its icon, is somewhere beyond > impractical. > > I'm not sure I understand the value of icons when searching for > applications that you haven't already installed. But perhaps there is > value in using icons for updates. My reasoning is, most people should > have icon awareness for applications they use a lot. > > So is there a compromise here. Would it be worth embedding an icon > name into repodata for a package, and if they icon exists on the > system then the gui tools will use the icon in reference to a package > update? But I don't know how you would drive that information into > the repodata Is that something packagedb would have to do? For > applications not already on the system, an icon representing the comps > group or rpm group for which the package belongs is perhaps pulled > from the hi-color set on system and displayed instead? > > But the underlying question that I cannot answer is if there is a real > benefit to exposing icons at all. I'm not sure there is. And even if > there is, I'm not sure its worth the complexity of implementing it. > > -jef > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Listen, PackageKit displays unuseful icons in his main package browsing component. Replacing them with appropriate icons from icon theme would be some improvement. Everybody knows gimp, so searching for gimp would be faster and easier if people would see gimp's icons only for gimp (not for gimp-libs etc). It would make PK look like gnome-app-install in Ubuntu (which I personally didn't liked), but it's just usability improvement. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwboyer at gmail.com Fri Jan 18 16:50:54 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 18 Jan 2008 10:50:54 -0600 Subject: Cast your vote for the Fedora 9 Codename! In-Reply-To: <1200664543.10767.119.camel@localhost.localdomain> References: <20080116184835.1bddf0f3@zod.rchland.ibm.com> <1200536182.920.64.camel@calliope.phig.org> <200801171318.m0HDGRqx011867@laptop13.inf.utfsm.cl> <1200591438.920.119.camel@calliope.phig.org> <80d7e4090801171805t3abb9651ie8ff1390267c51e@mail.gmail.com> <20080118022457.GA1991@nostromo.devel.redhat.com> <1200664543.10767.119.camel@localhost.localdomain> Message-ID: <20080118105054.354c12e5@zod.rchland.ibm.com> On Fri, 18 Jan 2008 08:55:43 -0500 Simo Sorce wrote: > > On Thu, 2008-01-17 at 21:24 -0500, Bill Nottingham wrote: > > Stephen John Smoogen (smooge at gmail.com) said: > > > Is campaigning for a name legal? > > > > I don't know. It probably depends on how the Campaign For the Chupacabra > > Of the Future gets its funding. > > Aww what happened to my beloved Anubis (not on the list :/) ? It was pruned by legal. As were many other names. josh From vonbrand at inf.utfsm.cl Fri Jan 18 16:53:43 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Fri, 18 Jan 2008 13:53:43 -0300 Subject: Wild buildsys reports? In-Reply-To: <200801180846.29537.jamatos@fc.up.pt> References: <200801180846.29537.jamatos@fc.up.pt> Message-ID: <200801181653.m0IGrh2l015361@laptop13.inf.utfsm.cl> Jos?? Matos wrote: > I have been receiving reports of broken for all the packages I > maintain and/or indirectly dependent. > The report are very suspicious in the sense that they complain about > everything. > > The simples example: > python-HTMLgen has broken dependencies in the development tree: > On ppc: > python-HTMLgen - 2.2.2-10.fc8.noarch requires python(abi) = 0:2.5 Python has been updated ==> ABI change. Need to check/rebuild the lot? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From notting at redhat.com Fri Jan 18 16:56:44 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 18 Jan 2008 11:56:44 -0500 Subject: Wild buildsys reports? In-Reply-To: <200801181653.m0IGrh2l015361@laptop13.inf.utfsm.cl> References: <200801180846.29537.jamatos@fc.up.pt> <200801181653.m0IGrh2l015361@laptop13.inf.utfsm.cl> Message-ID: <20080118165644.GA30968@nostromo.devel.redhat.com> Horst H. von Brand (vonbrand at inf.utfsm.cl) said: > Python has been updated ==> ABI change. Need to check/rebuild the lot? No, python fell out of the tree, move along, will be fixed shortly. Bill From michel.sylvan at gmail.com Fri Jan 18 17:14:17 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Fri, 18 Jan 2008 12:14:17 -0500 Subject: rawhide broken dependency reports for today... In-Reply-To: <20080118155035.GA26985@nostromo.devel.redhat.com> References: <20080118155035.GA26985@nostromo.devel.redhat.com> Message-ID: On Jan 18, 2008 10:50 AM, Bill Nottingham wrote: > Please ignore them. There was a problem with the rawhide compose; > it managed to miss pulling in various pieces, leading to the dependency > chaos you see in the messages. Apologies for the inconvenience. Ugh. Is it possible to retract the rebuilds I've just done? (gai, gai-pal, grhino). Thanks, -- Michel Salim http://hircus.jaiku.com/ From rnorwood at redhat.com Fri Jan 18 17:16:08 2008 From: rnorwood at redhat.com (Robin Norwood) Date: Fri, 18 Jan 2008 12:16:08 -0500 Subject: packaging: new spec filed idea In-Reply-To: <604aa7910801180841u1a8b509cg428df28ceb7db3a@mail.gmail.com> References: <5e92ee3f0801180724g7f2f2cd4i491d535a604e3fa8@mail.gmail.com> <20080118155155.GB26985@nostromo.devel.redhat.com> <1200671983.10767.140.camel@localhost.localdomain> <5e92ee3f0801180813s66422393x3cc90500eda5ad76@mail.gmail.com> <20080118162015.GC26753@nostromo.devel.redhat.com> <604aa7910801180841u1a8b509cg428df28ceb7db3a@mail.gmail.com> Message-ID: <1200676568.24019.9.camel@solitude.devel.redhat.com> On Fri, 2008-01-18 at 07:41 -0900, Jeff Spaleta wrote: > On Jan 18, 2008 7:20 AM, Bill Nottingham wrote: > > I think updating the hicolor-icon-theme package every time we add a new app to > > Fedora, or any time such an app changes its icon, is somewhere beyond impractical. > > I'm not sure I understand the value of icons when searching for > applications that you haven't already installed. But perhaps there is > value in using icons for updates. My reasoning is, most people should > have icon awareness for applications they use a lot. Well, one benefit is this use case: o User installs $app o User looks in the menus to try to run $app Having the icon the user saw when he installed the app be the same as the one in the menus would be a nice win. IIRC, there (is/was?) an Ubuntu tool that trolled the packages for .desktop files and used the icon from that. I don't know the exact details, but it must've been an offline process. This wouldn't of course work for packages that don't have a .desktop file, but then of course they wouldn't appear in the menus either. > So is there a compromise here. Would it be worth embedding an icon > name into repodata for a package, and if they icon exists on the > system then the gui tools will use the icon in reference to a package > update? But I don't know how you would drive that information into > the repodata Is that something packagedb would have to do? For > applications not already on the system, an icon representing the comps > group or rpm group for which the package belongs is perhaps pulled > from the hi-color set on system and displayed instead? I think that's about what Jakub was suggesting, actually. > But the underlying question that I cannot answer is if there is a real > benefit to exposing icons at all. I'm not sure there is. And even if > there is, I'm not sure its worth the complexity of implementing it. I think there would be a lot of value in it, but at the same time, implementation is non-trivial. -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From notting at redhat.com Fri Jan 18 15:50:35 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 18 Jan 2008 10:50:35 -0500 Subject: rawhide broken dependency reports for today... Message-ID: <20080118155035.GA26985@nostromo.devel.redhat.com> Please ignore them. There was a problem with the rawhide compose; it managed to miss pulling in various pieces, leading to the dependency chaos you see in the messages. Apologies for the inconvenience. Bill _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From cra at WPI.EDU Fri Jan 18 17:19:22 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 18 Jan 2008 12:19:22 -0500 Subject: anaconda support for encrypted LVs (as opposed to PVs) In-Reply-To: <20080118161843.GH26108@angus.ind.WPI.EDU> References: <20080117225733.GL29887@angus.ind.WPI.EDU> <1200664948.7520.4.camel@aglarond.local> <20080118161843.GH26108@angus.ind.WPI.EDU> Message-ID: <20080118171922.GI26108@angus.ind.WPI.EDU> On Fri, Jan 18, 2008 at 11:18:43AM -0500, Chuck Anderson wrote: > On Fri, Jan 18, 2008 at 09:02:28AM -0500, Jeremy Katz wrote: > > On Thu, 2008-01-17 at 17:57 -0500, Chuck Anderson wrote: > > > A while back I was told that Anaconda supported creating encrypted > > > LVs, but it appears as of today's rawhide it only supports encrypted > > > PVs. Is that true? If not, what is the magic UI sequence that allows > > > LVs to be created and encrypted? > > > > It should work -- there should just be a checkbox for Encrypt on the LV > > creation dialog. If not, file a bug :) > > Done, #429299. Oh well. I guess I'll stick with a smaller system PV/VG for encrypted root/swap, and create LVs after install manually: ------- Additional Comments From dlehman at redhat.com 2008-01-18 11:37 EST ------- This is intentional. We currently support encryption of PVs, but not LVs. From rnorwood at redhat.com Fri Jan 18 17:22:32 2008 From: rnorwood at redhat.com (Robin Norwood) Date: Fri, 18 Jan 2008 12:22:32 -0500 Subject: packaging: new spec filed idea In-Reply-To: <5e92ee3f0801180849h3c978758ka91f4ccc70db5172@mail.gmail.com> References: <5e92ee3f0801180724g7f2f2cd4i491d535a604e3fa8@mail.gmail.com> <20080118155155.GB26985@nostromo.devel.redhat.com> <1200671983.10767.140.camel@localhost.localdomain> <5e92ee3f0801180813s66422393x3cc90500eda5ad76@mail.gmail.com> <20080118162015.GC26753@nostromo.devel.redhat.com> <604aa7910801180841u1a8b509cg428df28ceb7db3a@mail.gmail.com> <5e92ee3f0801180849h3c978758ka91f4ccc70db5172@mail.gmail.com> Message-ID: <1200676952.24019.17.camel@solitude.devel.redhat.com> On Fri, 2008-01-18 at 17:49 +0100, Jakub 'Livio' Rusinek wrote: > Listen, PackageKit displays unuseful icons in his main package > browsing component. > Replacing them with appropriate icons from icon theme would be some > improvement. Well, FYI, the purpose of that particular column in the UI at the moment is 'is the package installed'. The icons used are pretty bad, and the whole UI is very much up for debate. I agree with you that there would be some value in adding the icons. But the implementation is non-trivial. I think the first step would be to get an 'icon' field added to the package metadata files that yum uses. However, if the icon field is the actual .png data, that makes the metadata files much bigger. If the icon field is a name or label, then that label has to match something already on the system. It wouldn't be useful for packages that aren't installed yet because the icon data is...in the package. So, I agree that it would be better, but it's non-trivial to do. -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From kevin.kofler at chello.at Fri Jan 18 17:26:05 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 18 Jan 2008 17:26:05 +0000 (UTC) Subject: rawhide broken dependency reports for today... References: <20080118155035.GA26985@nostromo.devel.redhat.com> Message-ID: Michel Salim gmail.com> writes: > Ugh. Is it possible to retract the rebuilds I've just done? (gai, > gai-pal, grhino). koji untag-pkg dist-f9 name-version-release But hurry up, untagging packages once they've been included in a Rawhide compose is frowned upon. Kevin Kofler From notting at redhat.com Fri Jan 18 17:33:50 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 18 Jan 2008 12:33:50 -0500 Subject: packaging: new spec filed idea In-Reply-To: <1200676952.24019.17.camel@solitude.devel.redhat.com> References: <5e92ee3f0801180724g7f2f2cd4i491d535a604e3fa8@mail.gmail.com> <20080118155155.GB26985@nostromo.devel.redhat.com> <1200671983.10767.140.camel@localhost.localdomain> <5e92ee3f0801180813s66422393x3cc90500eda5ad76@mail.gmail.com> <20080118162015.GC26753@nostromo.devel.redhat.com> <604aa7910801180841u1a8b509cg428df28ceb7db3a@mail.gmail.com> <5e92ee3f0801180849h3c978758ka91f4ccc70db5172@mail.gmail.com> <1200676952.24019.17.camel@solitude.devel.redhat.com> Message-ID: <20080118173350.GA630@nostromo.devel.redhat.com> Robin Norwood (rnorwood at redhat.com) said: > non-trivial. I think the first step would be to get an 'icon' field > added to the package metadata files that yum uses. However, if the icon > field is the actual .png data, that makes the metadata files much > bigger. If the icon field is a name or label, then that label has to > match something already on the system. It wouldn't be useful for > packages that aren't installed yet because the icon data is...in the > package. The Icon tag in the package is the raw image data, not a name/identifier. Bill From kevin.kofler at chello.at Fri Jan 18 17:31:06 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 18 Jan 2008 17:31:06 +0000 (UTC) Subject: packaging: new spec filed idea References: <5e92ee3f0801180724g7f2f2cd4i491d535a604e3fa8@mail.gmail.com> <20080118162133.GC26915@jasmine.xos.nl> <5e92ee3f0801180824g214df523j84b44e5a874de139@mail.gmail.com> Message-ID: Jakub 'Livio' Rusinek gmail.com> writes: > I had so good idea... Zero usability, zero future-thinking... > Every idea I have is moving to trash. Don't take it personally. The issue is that you're mainly an artwork guy and appear to lack the software development experience to understand the practical implementation constraints which make many of your ideas impractical to actually implement. Some developers have explained why this idea is not practically implementable. Kevin Kofler From jakub.rusinek at gmail.com Fri Jan 18 17:45:01 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Fri, 18 Jan 2008 18:45:01 +0100 Subject: packaging: new spec filed idea In-Reply-To: References: <5e92ee3f0801180724g7f2f2cd4i491d535a604e3fa8@mail.gmail.com> <20080118162133.GC26915@jasmine.xos.nl> <5e92ee3f0801180824g214df523j84b44e5a874de139@mail.gmail.com> Message-ID: <5e92ee3f0801180945v2e16566ekfc6bd64504171c9d@mail.gmail.com> 2008/1/18, Kevin Kofler : > > Jakub 'Livio' Rusinek gmail.com> writes: > > I had so good idea... Zero usability, zero future-thinking... > > Every idea I have is moving to trash. > > Don't take it personally. The issue is that you're mainly an artwork guy > and > appear to lack the software development experience to understand the > practical > implementation constraints which make many of your ideas impractical to > actually implement. Some developers have explained why this idea is not > practically implementable. > > Kevin Kofler > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > So, I have another idea 'bout this. If app isn't installed, package-x-generic is shown (with Icon: appname in SPEC), if app is installed, selectedicon is shown or package-x-generic with some emblem (which would indicate installed state). It would not require downloading additional metadata or images. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hughsient at gmail.com Fri Jan 18 17:57:06 2008 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 18 Jan 2008 17:57:06 +0000 Subject: packaging: new spec filed idea In-Reply-To: <1200676952.24019.17.camel@solitude.devel.redhat.com> References: <5e92ee3f0801180724g7f2f2cd4i491d535a604e3fa8@mail.gmail.com> <20080118155155.GB26985@nostromo.devel.redhat.com> <1200671983.10767.140.camel@localhost.localdomain> <5e92ee3f0801180813s66422393x3cc90500eda5ad76@mail.gmail.com> <20080118162015.GC26753@nostromo.devel.redhat.com> <604aa7910801180841u1a8b509cg428df28ceb7db3a@mail.gmail.com> <5e92ee3f0801180849h3c978758ka91f4ccc70db5172@mail.gmail.com> <1200676952.24019.17.camel@solitude.devel.redhat.com> Message-ID: <1200679026.12890.3.camel@hughsie-laptop> On Fri, 2008-01-18 at 12:22 -0500, Robin Norwood wrote: > On Fri, 2008-01-18 at 17:49 +0100, Jakub 'Livio' Rusinek wrote: > > Listen, PackageKit displays unuseful icons in his main package > > browsing component. > > Replacing them with appropriate icons from icon theme would be some > > improvement. > > Well, FYI, the purpose of that particular column in the UI at the moment > is 'is the package installed'. The icons used are pretty bad, and the > whole UI is very much up for debate. Totally. I want to do something separate like gnome-app-install that lets a new user just point and click. > I agree with you that there would be some value in adding the icons. Agreed. > But the implementation is > non-trivial. I think the first step would be to get an 'icon' field > added to the package metadata files that yum uses. However, if the icon > field is the actual .png data, that makes the metadata files much > bigger. Much, much bigger. > If the icon field is a name or label, then that label has to > match something already on the system. It wouldn't be useful for > packages that aren't installed yet because the icon data is...in the > package. Sure, but we could ship a packagekit-icons package, although that sucks as it requires constant rebuilding as others have pointed out. > So, I agree that it would be better, but it's non-trivial to do. If you are interested solving this, please jump on the packagekit mailinglist. See http://www.packagekit.org for details. Richard. From dwalsh at redhat.com Fri Jan 18 18:01:05 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 18 Jan 2008 13:01:05 -0500 Subject: SELinux removed from desktop cd spin? In-Reply-To: <20080118161236.GA61848@dspnet.fr.eu.org> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <478F857A.6030502@redhat.com> <20080117180251.GA77139@dspnet.fr.eu.org> <200801171920.32764.opensource@till.name> <1200594904.3259.143.camel@cassandra.boston.redhat.com> <478FA30A.6030405@redhat.com> <20080117191051.GB84707@dspnet.fr.eu.org> <4790AA04.2020409@redhat.com> <20080118161236.GA61848@dspnet.fr.eu.org> Message-ID: <4790E961.5030605@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Olivier Galibert wrote: > On Fri, Jan 18, 2008 at 08:30:44AM -0500, Daniel J Walsh wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Olivier Galibert wrote: >>> On Thu, Jan 17, 2008 at 01:48:42PM -0500, Daniel J Walsh wrote: >>>> >>>> >>>>

>>>> Allow unconfined executables to map a memory region as both executable >>>> and writable, this is dangerous and the executable should be reported in >>>> bugzilla") >>> That should be "to map a file in a memory region", as UD's page >>> explains. Otherwise anyone who knows a little about dynamic >>> recompilers/JITs is gonna go "huh?". >>> >>> OG. >>> >> Bad cut and paste. The one I pasted was for allow_execmem. Where the >> definition is correct. > > You mean Ulrich's page is incorrect then? I indeed had noticed it was > about execmem. > > >> java/mono apps are not confined by this, since >> they run under a different context. > > Java/Mono are not the only programs with dynamic code generators in > them. > > OG. > THe attached file is the file context of all files in Rawhide (Probably F8) that are marked as allowing execmem/execstack. If you know of others, we need to update this list. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkeQ6WEACgkQrlYvE4MpobNC1QCeJFwhjT7zZ4jWOeCQ2VnfTcI9 NI8AoLCClZU0lYdOAqwDNonnzDqReX34 =LqxN -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: execmem URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: execmem.sig Type: application/octet-stream Size: 72 bytes Desc: not available URL: From jakub.rusinek at gmail.com Fri Jan 18 18:15:30 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Fri, 18 Jan 2008 19:15:30 +0100 Subject: packaging: new spec filed idea In-Reply-To: <1200679026.12890.3.camel@hughsie-laptop> References: <5e92ee3f0801180724g7f2f2cd4i491d535a604e3fa8@mail.gmail.com> <20080118155155.GB26985@nostromo.devel.redhat.com> <1200671983.10767.140.camel@localhost.localdomain> <5e92ee3f0801180813s66422393x3cc90500eda5ad76@mail.gmail.com> <20080118162015.GC26753@nostromo.devel.redhat.com> <604aa7910801180841u1a8b509cg428df28ceb7db3a@mail.gmail.com> <5e92ee3f0801180849h3c978758ka91f4ccc70db5172@mail.gmail.com> <1200676952.24019.17.camel@solitude.devel.redhat.com> <1200679026.12890.3.camel@hughsie-laptop> Message-ID: <5e92ee3f0801181015v6c938d30vecc3b0ccfce17d44@mail.gmail.com> 2008/1/18, Richard Hughes : > > On Fri, 2008-01-18 at 12:22 -0500, Robin Norwood wrote: > > On Fri, 2008-01-18 at 17:49 +0100, Jakub 'Livio' Rusinek wrote: > > > Listen, PackageKit displays unuseful icons in his main package > > > browsing component. > > > Replacing them with appropriate icons from icon theme would be some > > > improvement. > > > > Well, FYI, the purpose of that particular column in the UI at the moment > > is 'is the package installed'. The icons used are pretty bad, and the > > whole UI is very much up for debate. > > Totally. I want to do something separate like gnome-app-install that > lets a new user just point and click. > > > I agree with you that there would be some value in adding the icons. > > Agreed. > > > But the implementation is > > non-trivial. I think the first step would be to get an 'icon' field > > added to the package metadata files that yum uses. However, if the icon > > field is the actual .png data, that makes the metadata files much > > bigger. > > Much, much bigger. > > > If the icon field is a name or label, then that label has to > > match something already on the system. It wouldn't be useful for > > packages that aren't installed yet because the icon data is...in the > > package. > > Sure, but we could ship a packagekit-icons package, although that sucks > as it requires constant rebuilding as others have pointed out. > > > So, I agree that it would be better, but it's non-trivial to do. > > If you are interested solving this, please jump on the packagekit > mailinglist. See http://www.packagekit.org for details. > > Richard. > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Should I jump to the PK's mailing list, if RPM doesn't provide "Icon: " field? -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Fri Jan 18 18:16:20 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 Jan 2008 13:16:20 -0500 Subject: An interesting read when discussing what to do about our bugs... Message-ID: <20080118131620.748606a0@redhat.com> http://glyphobet.net/blog/?p=140 -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Jan 18 18:27:55 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 18 Jan 2008 13:27:55 -0500 Subject: compilation architecture In-Reply-To: <5e92ee3f0801180719j831c136x8d12b4c3db2e8da@mail.gmail.com> References: <5e92ee3f0801161242w2e6c9340lee2eed34cfc3158f@mail.gmail.com> <20080118010324.b45bd216.mschwendt.tmp0701.nospam@arcor.de> <5e92ee3f0801180624w53c16622le1dd321b348c2efd@mail.gmail.com> <5e92ee3f0801180719j831c136x8d12b4c3db2e8da@mail.gmail.com> Message-ID: <20080118132755.167b74f4@redhat.com> On Fri, 18 Jan 2008 16:19:15 +0100 "Jakub 'Livio' Rusinek" wrote: > I'm not using desktop-effects. > I'm modifying /usr/bin/gnome-wm and using gnome-wm for starting WM. So you're doing it wrong, and then complaining about the results? Awesome. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From galibert at pobox.com Fri Jan 18 18:31:28 2008 From: galibert at pobox.com (Olivier Galibert) Date: Fri, 18 Jan 2008 19:31:28 +0100 Subject: SELinux removed from desktop cd spin? In-Reply-To: <4790E961.5030605@redhat.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <478F857A.6030502@redhat.com> <20080117180251.GA77139@dspnet.fr.eu.org> <200801171920.32764.opensource@till.name> <1200594904.3259.143.camel@cassandra.boston.redhat.com> <478FA30A.6030405@redhat.com> <20080117191051.GB84707@dspnet.fr.eu.org> <4790AA04.2020409@redhat.com> <20080118161236.GA61848@dspnet.fr.eu.org> <4790E961.5030605@redhat.com> Message-ID: <20080118183127.GB79879@dspnet.fr.eu.org> On Fri, Jan 18, 2008 at 01:01:05PM -0500, Daniel J Walsh wrote: > Olivier Galibert wrote: > > On Fri, Jan 18, 2008 at 08:30:44AM -0500, Daniel J Walsh wrote: > >> Bad cut and paste. The one I pasted was for allow_execmem. Where the > >> definition is correct. > > > > You mean Ulrich's page is incorrect then? I indeed had noticed it was > > about execmem. You forgot to reply to that part ^^^. Ulrich clearly says: - mmap PROT_EXEC without PROT_WRITE of anonymous memory - mmap PROT_EXEC|PROT_WRITE of files > >> java/mono apps are not confined by this, since > >> they run under a different context. > > > > Java/Mono are not the only programs with dynamic code generators in > > them. > > > > OG. > > > THe attached file is the file context of all files in Rawhide (Probably > F8) that are marked as allowing execmem/execstack. > > If you know of others, we need to update this list. The list will never cover the results of my own calls to make. Dynamic code generation is not such an unusual capability to add to a program and it's a very useful tool. While I can understand requesting not to do it on the stack, preventing it altogether, and in particular in areas mmapped explicitely for that purpose, seems rather excessive. OG. From limb at jcomserv.net Fri Jan 18 18:31:30 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 18 Jan 2008 12:31:30 -0600 (CST) Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <20080118131620.748606a0@redhat.com> References: <20080118131620.748606a0@redhat.com> Message-ID: <19426.63.85.68.164.1200681090.squirrel@mail.jcomserv.net> > http://glyphobet.net/blog/?p=140 Why would any maintainer NOT ask to see the fstab, but still blame it for the problem? Now, I've only RTFA and not RTFB, but that's just crap troubleshooting. I supervise a help desk and I don't let that sort of thing slide here, and I sure as . . .something certain. . .wouldn't put up with in a bug report. Why not just chase the bug down, and follow the evidence where it leads? > -- > Jesse Keating > Fedora -- All my bits are free, are yours? > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- novus ordo absurdum From ben.kreuter at gmail.com Fri Jan 18 18:36:43 2008 From: ben.kreuter at gmail.com (Benjamin Kreuter) Date: Fri, 18 Jan 2008 13:36:43 -0500 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <20080118131620.748606a0@redhat.com> References: <20080118131620.748606a0@redhat.com> Message-ID: <200801181336.48285.ben.kreuter@gmail.com> I've had a similar experience with Ubuntu guys -- they are not interested in discussing any serious problems with their distro. There was an STNYLug meeting at my school a few months back, and is was led by a Canonical employee. He wanted us to think up a list of Linux pros and cons -- but when I suggested that packages breaking between major releases was a con, I was completely shot down by him. He didn't even want to discuss it. Some other Ubuntu contributors in the room acted like it wasn't really a problem because other systems suffer from it as well. I walked out... -- Benjamin Kreuter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From jakub.rusinek at gmail.com Fri Jan 18 18:39:52 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Fri, 18 Jan 2008 19:39:52 +0100 Subject: compilation architecture In-Reply-To: <20080118132755.167b74f4@redhat.com> References: <5e92ee3f0801161242w2e6c9340lee2eed34cfc3158f@mail.gmail.com> <20080118010324.b45bd216.mschwendt.tmp0701.nospam@arcor.de> <5e92ee3f0801180624w53c16622le1dd321b348c2efd@mail.gmail.com> <5e92ee3f0801180719j831c136x8d12b4c3db2e8da@mail.gmail.com> <20080118132755.167b74f4@redhat.com> Message-ID: <5e92ee3f0801181039v8491c34x6afc7f63387c43ec@mail.gmail.com> 2008/1/18, Jesse Keating : > > On Fri, 18 Jan 2008 16:19:15 +0100 > "Jakub 'Livio' Rusinek" wrote: > > > I'm not using desktop-effects. > > I'm modifying /usr/bin/gnome-wm and using gnome-wm for starting WM. > > So you're doing it wrong, and then complaining about the results? > Awesome. > > -- > Jesse Keating > Fedora -- All my bits are free, are yours? > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > Did I say it's a problem for me? -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonstanley at gmail.com Fri Jan 18 18:55:17 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Fri, 18 Jan 2008 13:55:17 -0500 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <20080118131620.748606a0@redhat.com> References: <20080118131620.748606a0@redhat.com> Message-ID: 2008/1/18 Jesse Keating : > http://glyphobet.net/blog/?p=140 Read and taken to heart. While I *am* posting metrics on our bug situation, I also understand that doing things just to get those numbers down serves no goal that we want to achieve. Instead, the primary motivation for the metrics is to allow potential and current triagers to rise above the "suck threshold" as John Poelstra pointed out - contributors need to see the fact that they are making a difference. I think that my goals and those purportedly held by Ubuntu are two very different things - Ubuntu wants to close bugs for the sake of closing bugs, I want to make sure things get fixed and the distribution can improve because of that. The most important thing is that no users have the experience referenced in the above post. From notting at redhat.com Fri Jan 18 19:04:01 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 18 Jan 2008 14:04:01 -0500 Subject: packaging: new spec filed idea In-Reply-To: <5e92ee3f0801181015v6c938d30vecc3b0ccfce17d44@mail.gmail.com> References: <5e92ee3f0801180724g7f2f2cd4i491d535a604e3fa8@mail.gmail.com> <20080118155155.GB26985@nostromo.devel.redhat.com> <1200671983.10767.140.camel@localhost.localdomain> <5e92ee3f0801180813s66422393x3cc90500eda5ad76@mail.gmail.com> <20080118162015.GC26753@nostromo.devel.redhat.com> <604aa7910801180841u1a8b509cg428df28ceb7db3a@mail.gmail.com> <5e92ee3f0801180849h3c978758ka91f4ccc70db5172@mail.gmail.com> <1200676952.24019.17.camel@solitude.devel.redhat.com> <1200679026.12890.3.camel@hughsie-laptop> <5e92ee3f0801181015v6c938d30vecc3b0ccfce17d44@mail.gmail.com> Message-ID: <20080118190401.GA5084@nostromo.devel.redhat.com> Jakub 'Livio' Rusinek (jakub.rusinek at gmail.com) said: > Should I jump to the PK's mailing list, if RPM doesn't provide "Icon: " > field? RPM already does, it's the raw content of the file referenced in that field, and it's restricted to being in GIF format. Bill From jakub.rusinek at gmail.com Fri Jan 18 19:08:50 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Fri, 18 Jan 2008 20:08:50 +0100 Subject: packaging: new spec filed idea In-Reply-To: <20080118190401.GA5084@nostromo.devel.redhat.com> References: <5e92ee3f0801180724g7f2f2cd4i491d535a604e3fa8@mail.gmail.com> <1200671983.10767.140.camel@localhost.localdomain> <5e92ee3f0801180813s66422393x3cc90500eda5ad76@mail.gmail.com> <20080118162015.GC26753@nostromo.devel.redhat.com> <604aa7910801180841u1a8b509cg428df28ceb7db3a@mail.gmail.com> <5e92ee3f0801180849h3c978758ka91f4ccc70db5172@mail.gmail.com> <1200676952.24019.17.camel@solitude.devel.redhat.com> <1200679026.12890.3.camel@hughsie-laptop> <5e92ee3f0801181015v6c938d30vecc3b0ccfce17d44@mail.gmail.com> <20080118190401.GA5084@nostromo.devel.redhat.com> Message-ID: <5e92ee3f0801181108k249a527eg4be3828de3ba1cd3@mail.gmail.com> 2008/1/18, Bill Nottingham : > > Jakub 'Livio' Rusinek (jakub.rusinek at gmail.com) said: > > Should I jump to the PK's mailing list, if RPM doesn't provide "Icon: " > > field? > > RPM already does, it's the raw content of the file referenced in that > field, > and it's restricted to being in GIF format. > > Bill > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Image provided with RPM? Ble... -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.sourada at gmail.com Fri Jan 18 19:18:11 2008 From: martin.sourada at gmail.com (Martin Sourada) Date: Fri, 18 Jan 2008 20:18:11 +0100 Subject: packaging: new spec filed idea In-Reply-To: <5e92ee3f0801181015v6c938d30vecc3b0ccfce17d44@mail.gmail.com> References: <5e92ee3f0801180724g7f2f2cd4i491d535a604e3fa8@mail.gmail.com> <20080118155155.GB26985@nostromo.devel.redhat.com> <1200671983.10767.140.camel@localhost.localdomain> <5e92ee3f0801180813s66422393x3cc90500eda5ad76@mail.gmail.com> <20080118162015.GC26753@nostromo.devel.redhat.com> <604aa7910801180841u1a8b509cg428df28ceb7db3a@mail.gmail.com> <5e92ee3f0801180849h3c978758ka91f4ccc70db5172@mail.gmail.com> <1200676952.24019.17.camel@solitude.devel.redhat.com> <1200679026.12890.3.camel@hughsie-laptop> <5e92ee3f0801181015v6c938d30vecc3b0ccfce17d44@mail.gmail.com> Message-ID: <1200683891.2720.12.camel@pc-notebook> On Fri, 2008-01-18 at 19:15 +0100, Jakub 'Livio' Rusinek wrote: > Should I jump to the PK's mailing list, if RPM doesn't provide "Icon: " field? > > -- > Jakub 'Livio' Rusinek > http://liviopl.jogger.pl/ Nope, but you should jump to PK's mailing list and asking them for using saner icons. RPM and installed packages already provide enough info for that. IMHO for not-yet-installed packages the Group field is enough and it is more than likely that matching icon will already be installed (either in the hicolor theme or the icon theme you are using). For installed packages when it has some icon, than it most likely is displayed in menu, and the icon name is listed its desktop file. So, go and ask: "Can the PackageKit use for installed packages their icons listed in their desktop file (preferably using those provided by the selected icon theme) and if these are not available or the application is not installed yet, use generic icon matching the Group field of its rpm?" First, this needs only changes to PackageKit. Secondly, this does not need any additional resources (like some icon package with all the icons of all the packages available in fedora). And finally it helps the user to decide what is he trying to install/remove. Or, if the icon is intended to be displayed only for installed packages than it is even (a little) simpler... Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From vonbrand at inf.utfsm.cl Fri Jan 18 19:25:34 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Fri, 18 Jan 2008 16:25:34 -0300 Subject: packaging: new spec filed idea In-Reply-To: <20080118173350.GA630@nostromo.devel.redhat.com> References: <5e92ee3f0801180724g7f2f2cd4i491d535a604e3fa8@mail.gmail.com> <20080118155155.GB26985@nostromo.devel.redhat.com> <1200671983.10767.140.camel@localhost.localdomain> <5e92ee3f0801180813s66422393x3cc90500eda5ad76@mail.gmail.com> <20080118162015.GC26753@nostromo.devel.redhat.com> <604aa7910801180841u1a8b509cg428df28ceb7db3a@mail.gmail.com> <5e92ee3f0801180849h3c978758ka91f4ccc70db5172@mail.gmail.com> <1200676952.24019.17.camel@solitude.devel.redhat.com> <20080118173350.GA630@nostromo.devel.redhat.com> Message-ID: <200801181925.m0IJPYsA023016@laptop13.inf.utfsm.cl> Bill Nottingham wrote: [...] > The Icon tag in the package is the raw image data, not a name/identifier. Strongly against then. Different setups (DE, large/small screen, theme, distributions, ...) will want to use their own iconset. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From michel.sylvan at gmail.com Fri Jan 18 19:49:25 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Fri, 18 Jan 2008 14:49:25 -0500 Subject: rawhide broken dependency reports for today... In-Reply-To: References: <20080118155035.GA26985@nostromo.devel.redhat.com> Message-ID: On Jan 18, 2008 12:26 PM, Kevin Kofler wrote: > Michel Salim gmail.com> writes: > > Ugh. Is it possible to retract the rebuilds I've just done? (gai, > > gai-pal, grhino). > > koji untag-pkg dist-f9 name-version-release > But hurry up, untagging packages once they've been included in a Rawhide > compose is frowned upon. > Thanks, untagged. Was looking for a way to do that through the web interface, guess it's not there yet. -- Michel Salim http://hircus.jaiku.com/ From michel.sylvan at gmail.com Fri Jan 18 19:54:39 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Fri, 18 Jan 2008 14:54:39 -0500 Subject: SELinux removed from desktop cd spin? In-Reply-To: <20080118082704.GA29940@wolff.to> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116210016.GA10162@devserv.devel.redhat.com> <1200518035.5766.2.camel@localhost> <1200518850.3277.5.camel@localhost.localdomain> <64b14b300801161335o1f27cf76t3affe31e8aae02ab@mail.gmail.com> <604aa7910801161400k2e3ea6d6r3706a721a9106aed@mail.gmail.com> <478F018F.50009@gmail.com> <20080118082704.GA29940@wolff.to> Message-ID: On Jan 18, 2008 3:27 AM, Bruno Wolff III wrote: > On Thu, Jan 17, 2008 at 08:19:43 +0100, > Valent Turkovic wrote: > > > > Will fedora include virus scanners? If not why? > > Because virus scanners are resource sucking hogs that don't work very well. > If you want to go down that road you need to sign code and have a white list. I wonder what Valent is on. Fedora has ClamAV in the repositories; users who run a mail server that serves Windows users are free to install it. (Also, users who run Codeweavers' Crossover Office to run Windows binaries) -- Michel Salim http://hircus.jaiku.com/ From yaneti at declera.com Fri Jan 18 20:38:39 2008 From: yaneti at declera.com (Yanko Kaneti) Date: Fri, 18 Jan 2008 22:38:39 +0200 Subject: packaging: new spec filed idea In-Reply-To: <604aa7910801180841u1a8b509cg428df28ceb7db3a@mail.gmail.com> References: <5e92ee3f0801180724g7f2f2cd4i491d535a604e3fa8@mail.gmail.com> <20080118155155.GB26985@nostromo.devel.redhat.com> <1200671983.10767.140.camel@localhost.localdomain> <5e92ee3f0801180813s66422393x3cc90500eda5ad76@mail.gmail.com> <20080118162015.GC26753@nostromo.devel.redhat.com> <604aa7910801180841u1a8b509cg428df28ceb7db3a@mail.gmail.com> Message-ID: <1200688719.10464.10.camel@indigo.declera.com> On Fri, 2008-01-18 at 07:41 -0900, Jeff Spaleta wrote: > On Jan 18, 2008 7:20 AM, Bill Nottingham wrote: > > I think updating the hicolor-icon-theme package every time we add a new app to > > Fedora, or any time such an app changes its icon, is somewhere beyond impractical. > > I'm not sure I understand the value of icons when searching for > applications that you haven't already installed. But perhaps there is > value in using icons for updates. My reasoning is, most people should > have icon awareness for applications they use a lot. > > So is there a compromise here. Would it be worth embedding an icon > name into repodata for a package, and if they icon exists on the > system then the gui tools will use the icon in reference to a package > update? But I don't know how you would drive that information into > the repodata Is that something packagedb would have to do? For > applications not already on the system, an icon representing the comps > group or rpm group for which the package belongs is perhaps pulled > from the hi-color set on system and displayed instead? > > But the underlying question that I cannot answer is if there is a real > benefit to exposing icons at all. I'm not sure there is. And even if > there is, I'm not sure its worth the complexity of implementing it. Just a icon? I don't think its worth the trouble. But lets think of who would actually want to browse the collection and what information he'll expect to find there. Looking at the pie in the sky I see a software catalog like thingie. Think collection of screenshots, a screencast, detailed list of features, etc... all metadata that can be hosted by fedora and downloaded on demand, whenever some chap decides to actually use the graphical package management interface (and happens to have an internet connection) From Michael_E_Brown at dell.com Fri Jan 18 21:50:25 2008 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Fri, 18 Jan 2008 15:50:25 -0600 Subject: mock 0.8.9 will not build anything In-Reply-To: <4790691C.3080605@gmx.net> References: <4790691C.3080605@gmx.net> Message-ID: <20080118215024.GA9904@humbolt.us.dell.com> On Fri, Jan 18, 2008 at 09:53:48AM +0100, Frank B?ttner wrote: > Hello, > > when I try to build an package mock will fail with: > ERROR: Command(/usr/sbin/groupadd -g 102 mockbuild) failed. See logs for > output. > At the root.log: > 2008-01-18 09:48:01,860 - DEBUG trace_decorator.py, Line: 20: ENTER: > doChroot((, '/usr/sbin/grou > padd -g 102 mockbuild', ''), {}) > 2008-01-18 09:48:01,861 - DEBUG trace_decorator.py, Line: 20: ENTER: > do(('/usr/sbin/groupadd -g 102 mockbuild', '/var/lib/mock/fedora-de > velopment-i386/root', 0, True, 0, None, None, None, None), {}) > 2008-01-18 09:48:01,862 - DEBUG util.py, Line: 212: Run cmd: > /usr/sbin/groupadd -g 102 mockbuild > 2008-01-18 09:48:01,862 - DEBUG util.py, Line: 218: Executing > timeout(0): /usr/sbin/groupadd -g 102 mockbuild > 2008-01-18 09:48:01,866 - DEBUG trace_decorator.py, Line: 20: ENTER: > condPersonality((None,), {}) > 2008-01-18 09:48:01,869 - DEBUG trace_decorator.py, Line: 30: LEAVE > condPersonality --> None > > 2008-01-18 09:48:01,870 - DEBUG trace_decorator.py, Line: 20: ENTER: > condChroot(('/var/lib/mock/fedora-development-i386/root', None), {} > ) > 2008-01-18 09:48:01,871 - DEBUG trace_decorator.py, Line: 30: LEAVE > condChroot --> None > > 2008-01-18 03:48:01,872 - DEBUG trace_decorator.py, Line: 20: ENTER: > condDropPrivs((None, None, None), {}) > 2008-01-18 03:48:01,873 - DEBUG trace_decorator.py, Line: 30: LEAVE > condDropPrivs --> None > > 2008-01-18 09:48:01,973 - DEBUG util.py, Line: 234: groupadd: name > mockbuild is not unique > 2008-01-18 09:48:01,977 - DEBUG trace_decorator.py, Line: 27: > EXCEPTION: Command(/usr/sbin/groupadd -g 102 mockbuild) failed. See logs f > or output. > > Any ideas, what goes wrong?? The latest version of mock is 0.8.19. Have you tried upgrading? -- Michael From bruno at wolff.to Fri Jan 18 21:52:17 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Fri, 18 Jan 2008 15:52:17 -0600 Subject: Xorg radeon drivers In-Reply-To: <52636.192.168.0.1.1200654291.squirrel@mail.jcomserv.net> References: <1200631491.2150.2.camel@scrappy.miketc.com> <1200636379.29147.0.camel@localhost> <20080118084659.GB29940@wolff.to> <52636.192.168.0.1.1200654291.squirrel@mail.jcomserv.net> Message-ID: <20080118215217.GA6492@wolff.to> On Fri, Jan 18, 2008 at 05:04:51 -0600, Jon Ciesla wrote: > > > I have had problems with xorg-x11-drv-ati-6.7.196-5.fc8 and have reverted > > to > > using xorg-x11-drv-ati-6.7.196-2.fc8. Though in my case I have a 9200, so > > he might be better off with the updates-testing version, even though it > > doesn't work for me. > > Now that's funny, I have a 9200, and I use the same driver, and I've been > having bizarre symptoms that I've been trying to quanify properly for a > BZ. Some things won't launch locally, or crash right away, but if I run > the same app onthe same box remotely with either NX or X->ssh tunnelling, > it displays fine on the other box. Is that anything like what you've been > seeing? X doesn't properly start. I think there is an additional dependency in my case that my old LCD display doesn't send an identifier that newer ones do. I had problems when first upgrading to F8 that were solved with the -2 update. But when I upgraded to -5 then I had the problem reoccur. I didn't do anything to confirm it was really a regression and not a new bug. I just reverted to using -2. From hughsient at gmail.com Fri Jan 18 22:32:24 2008 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 18 Jan 2008 22:32:24 +0000 Subject: packaging: new spec filed idea In-Reply-To: <1200683891.2720.12.camel@pc-notebook> References: <5e92ee3f0801180724g7f2f2cd4i491d535a604e3fa8@mail.gmail.com> <20080118155155.GB26985@nostromo.devel.redhat.com> <1200671983.10767.140.camel@localhost.localdomain> <5e92ee3f0801180813s66422393x3cc90500eda5ad76@mail.gmail.com> <20080118162015.GC26753@nostromo.devel.redhat.com> <604aa7910801180841u1a8b509cg428df28ceb7db3a@mail.gmail.com> <5e92ee3f0801180849h3c978758ka91f4ccc70db5172@mail.gmail.com> <1200676952.24019.17.camel@solitude.devel.redhat.com> <1200679026.12890.3.camel@hughsie-laptop> <5e92ee3f0801181015v6c938d30vecc3b0ccfce17d44@mail.gmail.com> <1200683891.2720.12.camel@pc-notebook> Message-ID: <1200695544.2784.0.camel@hughsie-laptop> On Fri, 2008-01-18 at 20:18 +0100, Martin Sourada wrote: > On Fri, 2008-01-18 at 19:15 +0100, Jakub 'Livio' Rusinek wrote: > > Should I jump to the PK's mailing list, if RPM doesn't provide "Icon: " field? > > > > -- > > Jakub 'Livio' Rusinek > > http://liviopl.jogger.pl/ > > Nope, but you should jump to PK's mailing list and asking them for using > saner icons. Totally! > RPM and installed packages already provide enough info for > that. IMHO for not-yet-installed packages the Group field is enough and > it is more than likely that matching icon will already be installed > (either in the hicolor theme or the icon theme you are using). For > installed packages when it has some icon, than it most likely is > displayed in menu, and the icon name is listed its desktop file. So, go > and ask: Ahh, it's non trivial as some applications will have multiple icon files and/or desktop files. But yes, it's an easy fix if you can do it. Richard. From jakub.rusinek at gmail.com Fri Jan 18 23:33:19 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Sat, 19 Jan 2008 00:33:19 +0100 Subject: packaging: new spec filed idea In-Reply-To: <1200695544.2784.0.camel@hughsie-laptop> References: <5e92ee3f0801180724g7f2f2cd4i491d535a604e3fa8@mail.gmail.com> <5e92ee3f0801180813s66422393x3cc90500eda5ad76@mail.gmail.com> <20080118162015.GC26753@nostromo.devel.redhat.com> <604aa7910801180841u1a8b509cg428df28ceb7db3a@mail.gmail.com> <5e92ee3f0801180849h3c978758ka91f4ccc70db5172@mail.gmail.com> <1200676952.24019.17.camel@solitude.devel.redhat.com> <1200679026.12890.3.camel@hughsie-laptop> <5e92ee3f0801181015v6c938d30vecc3b0ccfce17d44@mail.gmail.com> <1200683891.2720.12.camel@pc-notebook> <1200695544.2784.0.camel@hughsie-laptop> Message-ID: <5e92ee3f0801181533r3dab659euae68696f13712b25@mail.gmail.com> > > On Fri, 2008-01-18 at 20:18 +0100, Martin Sourada wrote: > > On Fri, 2008-01-18 at 19:15 +0100, Jakub 'Livio' Rusinek wrote: > > > Should I jump to the PK's mailing list, if RPM doesn't provide "Icon: > " field? > > > > > > -- > > > Jakub 'Livio' Rusinek > > > http://liviopl.jogger.pl/ > > > > Nope, but you should jump to PK's mailing list and asking them for using > > saner icons. > > Totally! Tomorrow. > RPM and installed packages already provide enough info for > > that. IMHO for not-yet-installed packages the Group field is enough and > > it is more than likely that matching icon will already be installed > > (either in the hicolor theme or the icon theme you are using). For > > installed packages when it has some icon, than it most likely is > > displayed in menu, and the icon name is listed its desktop file. So, go > > and ask: > > Ahh, it's non trivial as some applications will have multiple icon files > and/or desktop files. But yes, it's an easy fix if you can do it. > > Richard. > Don't count on me. For now I have no programming skills. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank-buettner at gmx.net Sat Jan 19 08:26:24 2008 From: frank-buettner at gmx.net (=?ISO-8859-1?Q?Frank_B=FCttner?=) Date: Sat, 19 Jan 2008 09:26:24 +0100 Subject: mock 0.8.9 will not build anything In-Reply-To: <20080118215024.GA9904@humbolt.us.dell.com> References: <4790691C.3080605@gmx.net> <20080118215024.GA9904@humbolt.us.dell.com> Message-ID: <4791B430.9080706@gmx.net> Michael E Brown schrieb: tput. >> >> Any ideas, what goes wrong?? > > The latest version of mock is 0.8.19. Have you tried upgrading? > -- > Michael > Not at the EPEL 5 Repo, there is the last one 0.8.9, but I can try to install 0.8.19 from F-7/8. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5766 bytes Desc: S/MIME Cryptographic Signature URL: From Axel.Thimm at ATrpms.net Sat Jan 19 08:40:21 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 19 Jan 2008 10:40:21 +0200 Subject: blacklisted iwl4965 ?? In-Reply-To: <20080118080211.GM29887@angus.ind.WPI.EDU> References: <20080118080211.GM29887@angus.ind.WPI.EDU> Message-ID: <20080119084021.GA4680@puariko.nirvana> On Fri, Jan 18, 2008 at 03:02:11AM -0500, Chuck Anderson wrote: > I just did a fresh rawhide install and found this in > /etc/modprobe.d/blacklist: > > # don't load iwl4965 by default, bug 245379 > blacklist iwl4965 > > https://bugzilla.redhat.com/show_bug.cgi?id=245379 > > Does someone have any better explanation for this than the 6+ month > old bug report for RHEL 5? What are us iwl4965 users supposed to be > using? You can use the mac/iwl kmdls at ATrpms. I haven't started building for rawhide yet, but you can rebuild them yourself for any given kernel. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From frank-buettner at gmx.net Sat Jan 19 08:50:53 2008 From: frank-buettner at gmx.net (=?ISO-8859-1?Q?Frank_B=FCttner?=) Date: Sat, 19 Jan 2008 09:50:53 +0100 Subject: mock 0.8.9 will not build anything In-Reply-To: <4791B430.9080706@gmx.net> References: <4790691C.3080605@gmx.net> <20080118215024.GA9904@humbolt.us.dell.com> <4791B430.9080706@gmx.net> Message-ID: <4791B9ED.4060702@gmx.net> Frank B?ttner schrieb: > Michael E Brown schrieb: > tput. >>> >>> Any ideas, what goes wrong?? >> >> The latest version of mock is 0.8.19. Have you tried upgrading? >> -- >> Michael >> > Not at the EPEL 5 Repo, there is the last one 0.8.9, but I can try to > install 0.8.19 from F-7/8. > So tested, but the install fails, because of missing python deps. mock 0.8.19 will use python 2.5 but EPEL 5 comes with 2.4:( -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5766 bytes Desc: S/MIME Cryptographic Signature URL: From lkundrak at redhat.com Sat Jan 19 14:20:42 2008 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Sat, 19 Jan 2008 15:20:42 +0100 Subject: mock 0.8.9 will not build anything In-Reply-To: <4790691C.3080605@gmx.net> References: <4790691C.3080605@gmx.net> Message-ID: <1200752442.6945.3.camel@localhost.localdomain> On Fri, 2008-01-18 at 09:53 +0100, Frank B?ttner wrote: > Hello, > > when I try to build an package mock will fail with: ... > 2008-01-18 09:48:01,973 - DEBUG util.py, Line: 234: groupadd: name > mockbuild is not unique > 2008-01-18 09:48:01,977 - DEBUG trace_decorator.py, Line: 27: > EXCEPTION: Command(/usr/sbin/groupadd -g 102 mockbuild) failed. See logs f > or output. > > Any ideas, what goes wrong?? Please delete /var/mock/* and try again. In case you won't succeed, please open a bug report in bugzilla. Thanks, -- Lubomir Kundrak (Red Hat Security Response Team) From s0238762 at sms.ed.ac.uk Sat Jan 19 14:26:19 2008 From: s0238762 at sms.ed.ac.uk (Ioannis Nousias) Date: Sat, 19 Jan 2008 14:26:19 +0000 Subject: i386 popt static library in x86-64 Message-ID: <4792088B.6050504@sms.ed.ac.uk> Hi, The popt-static.i386 is missing from the x86-64 repositories and it seems I can't install it from the i386 ones, since it now conflicts with the x86-64 (I could before, but now something has changed). I need both the popt-static.x86_64 and the popt-static.i386 in my system. Any suggestions ? regards -Ioannis From lordmorgul at gmail.com Sat Jan 19 15:09:53 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sat, 19 Jan 2008 07:09:53 -0800 Subject: i386 popt static library in x86-64 In-Reply-To: <4792088B.6050504@sms.ed.ac.uk> References: <4792088B.6050504@sms.ed.ac.uk> Message-ID: <479212C1.5050708@gmail.com> Ioannis Nousias wrote: > Hi, > > The popt-static.i386 is missing from the x86-64 repositories and it > seems I can't install it from the i386 ones, since it now conflicts with > the x86-64 (I could before, but now something has changed). I need both > the popt-static.x86_64 and the popt-static.i386 in my system. Any > suggestions ? > > regards > -Ioannis > rawhide/f8/f7 ? http://koji.fedoraproject.org/koji/packageinfo?packageID=4924 There seem to be built popt-static packages in koji right now, ymmv -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From s0238762 at sms.ed.ac.uk Sat Jan 19 15:22:34 2008 From: s0238762 at sms.ed.ac.uk (Ioannis Nousias) Date: Sat, 19 Jan 2008 15:22:34 +0000 Subject: i386 popt static library in x86-64 In-Reply-To: <479212C1.5050708@gmail.com> References: <4792088B.6050504@sms.ed.ac.uk> <479212C1.5050708@gmail.com> Message-ID: <479215BA.50005@sms.ed.ac.uk> Andrew Farris wrote: > Ioannis Nousias wrote: >> Hi, >> >> The popt-static.i386 is missing from the x86-64 repositories and it >> seems I can't install it from the i386 ones, since it now conflicts >> with the x86-64 (I could before, but now something has changed). I >> need both the popt-static.x86_64 and the popt-static.i386 in my >> system. Any suggestions ? >> >> regards >> -Ioannis >> > > rawhide/f8/f7 ? > > http://koji.fedoraproject.org/koji/packageinfo?packageID=4924 There > seem to be built popt-static packages in koji right now, ymmv > Yes, forgot to mention I'm using F8. Thanks. Installing this http://koji.fedoraproject.org/packages/popt/1.13/1.fc8/i386/popt-static-1.13-1.fc8.i386.rpm worked. From laurent.rineau__fedora at normalesup.org Sat Jan 19 15:38:19 2008 From: laurent.rineau__fedora at normalesup.org (Laurent Rineau) Date: Sat, 19 Jan 2008 16:38:19 +0100 Subject: KDE and samba license change (GPLv3) Message-ID: <200801191638.19865@rineau.tsetse> On Tuesday 09 October 2007 15:33:13 Rex Dieter wrote: > Ville Skytt? wrote: > > On 10/3/07, Simo Sorce wrote: > >> Samba has changed it's license from GPLv2+ to GPLv3+ > >> The license change affects version 3.2.0 (still a pre-release now). > >> In F-8 we will still have 3.0.X so the change affects F-9 > > > > Looks like KDE may suffer from this, both kdebase and kdebase4 are > > labeled GPLv2 (no "+"). > > Yep, kde is stuck at GPLv2 for now(1), so looks like smb support will have > to be dropped, at least temporarily. > > (1) qt is GPLv2, trolltech is evaluating GPLv2+ or GPLv3, but that's all > behind closed doors with no visible movement. There is a proposal within > kde to move to (L)GPLv2+. All of this is slow, tedious work, often > blocking on lawyers, and we all know how fast they are. Well, it seems both Qt-3 and Qt-4 has been released under GPLv3 this week (in addition to GPLv2 (and maybe QPL). Let hope the relicencing of KDE will not stay stalled too long. http://techbase.kde.org/Projects/KDE_Relicensing -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From lordmorgul at gmail.com Sat Jan 19 15:41:17 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sat, 19 Jan 2008 07:41:17 -0800 Subject: i386 popt static library in x86-64 In-Reply-To: <479215BA.50005@sms.ed.ac.uk> References: <4792088B.6050504@sms.ed.ac.uk> <479212C1.5050708@gmail.com> <479215BA.50005@sms.ed.ac.uk> Message-ID: <47921A1D.5050409@gmail.com> Ioannis Nousias wrote: > Andrew Farris wrote: >> Ioannis Nousias wrote: >>> Hi, >>> >>> The popt-static.i386 is missing from the x86-64 repositories and it >>> seems I can't install it from the i386 ones, since it now conflicts >>> with the x86-64 (I could before, but now something has changed). I >>> need both the popt-static.x86_64 and the popt-static.i386 in my >>> system. Any suggestions ? >>> >>> regards >>> -Ioannis >>> >> >> rawhide/f8/f7 ? >> >> http://koji.fedoraproject.org/koji/packageinfo?packageID=4924 There >> seem to be built popt-static packages in koji right now, ymmv >> > Yes, forgot to mention I'm using F8. Thanks. Installing this > http://koji.fedoraproject.org/packages/popt/1.13/1.fc8/i386/popt-static-1.13-1.fc8.i386.rpm > > worked. > Ok, it seems 1.13-1 was pushed to F8 updates, and it is present on this mirror: http://mirror.lib.ucdavis.edu/fedora/linux/updates/8/i386/ and the x86_64 version is as well, but you're right there is no i386 popt-static here, although there are i386 versions for the other popt packages. http://mirror.lib.ucdavis.edu/fedora/linux/updates/8/x86_64/ I wonder if that failed to build and didn't get caught or was that intentional for the general user? -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From buildsys at redhat.com Sat Jan 19 17:11:38 2008 From: buildsys at redhat.com (Build System) Date: Sat, 19 Jan 2008 12:11:38 -0500 Subject: rawhide report: 20080118 changes Message-ID: <200801191711.m0JHBcSi017061@porkchop.devel.redhat.com> New package amora A mobile remote assistant New package gnome-settings-daemon The daemon sharing settings from GNOME to GTK+/KDE applications New package mono-addins Addins for mono New package okteta Binary editor New package perl-Convert-NLS_DATE_FORMAT Convert Oracle NLS_DATE_FORMAT <-> strftime Format Strings New package preload Preload is an adaptive readahead daemon New package python-pyasn1 ASN.1 tools for Python New package quarticurve-kwin-theme Unofficial port of the Bluecurve KWin decoration to KDE 4 Removed package bluecurve-kwin-theme Updated Packages: Miro-1.1-1.fc9 -------------- * Thu Jan 17 2008 Alex Lancaster - 1.1-1 - Update to upstream 1.1 release - BuildRequires: gecko-devel-unstable, openssl-devel ack-1.76-1.fc9 -------------- * Thu Jan 17 2008 Ian Burrell - 1.76-1 - Update to 1.76 anaconda-11.4.0.22-1 -------------------- * Wed Jan 16 2008 David L. Cantrell Jr. - 11.4.0.22-1 - Require the latest libdhcp (dcantrell) - Don't set currentMedia when we're on a network install (#428927, clumens) - Don't offer two reboot options (clumens) - Remove fsopts that are already defaults (#429039, clumens) - Remove isofs module to get rid of a FATAL message (clumens) - Add the crc32c kernel module for iscsi (#405911, clumens) - Add MAC address to the network device selection screen (#428229, clumens) - Initial support for network --bootproto=ask (#401531, clumens) - Remove an extra newline (clumens) - Add firstaidkit to the rescue image (jgranado) - Fix the progress bar to hit 100% on the last package (#428790, clumens) - Add some output so the startup delay doesn't seem quite so long (clumens) - Initial kickstart support for encrypted partitions (clumens) authconfig-5.3.20-1.fc9 ----------------------- * Fri Jan 18 2008 Tomas Mraz - 5.3.20-1 - update translations berusky-1.1-7.fc9 ----------------- * Fri Jan 18 2008 Martin Stransky 1.1-7 - rebuild blender-2.45-5.fc9 ------------------ * Thu Jan 17 2008 Jochen Schmitt 2.45-5 - Fix gcc-4.3 related issues childsplay-0.90.2-1.fc9 ----------------------- * Thu Jan 17 2008 Hans de Goede 0.90.2-1 - New upstream version 0.90.2 - Drop upstreamed replace-cfg patch cmake-2.4.8-0.rc12.fc9 ---------------------- * Wed Jan 16 2008 Orion Poplawski - 2.4.8-0.rc12 - Update to 2.4.8 RC-12 compiz-0.6.2-6.fc9 ------------------ * Thu Jan 17 2008 Kristian H??gsberg - 0.6.2-6 - Update to desktop-effects version 0.7.17 which include more translations and move desktop-effects translations to compiz-gnome. - Fix spelling in beryl-core obsoletes. * Mon Jan 07 2008 Adel Gadllah - 0.6.2-5 - Update buildrequires (kwd uses the kde3 api) * Tue Nov 06 2007 Stepan Kasal - 0.6.2-4 - Fix a typo in description of the main package. - All descriptions should end with a dot (unlike the summary line) coreutils-6.9-17.fc9 -------------------- * Wed Jan 16 2008 Ondrej Vasik - 6.9-17 - added several missing colored TERMs(including rxvt-unicode, screen-256color and xterm-256color) to DIR_COLORS and DIR_COLORS.xterm(#239266) createrepo-0.9.2-1.fc9 ---------------------- * Thu Jan 17 2008 Seth Vidal - 0.9.2-1 - remove all other patches - 0.9.2 cscope-15.5-16.fc9 ------------------ * Fri Jan 18 2008 Neil Horman -15.5-16.dist - Fix revision sillyness & bump rev for rebuild dbus-1.1.4-1.fc9 ---------------- * Thu Jan 17 2008 John (J5) Palmieri - 1.1.4-1 - new upstream version - fixes inotify patch which was consuming 100% cpu and memory * Wed Jan 16 2008 John (J5) Palmieri - 1.1.3-1 - new upstream version which obsoletes a number of our patches - doc section added for the devhelp docs * Thu Nov 15 2007 John (J5) Palmieri - 1.1.2-9 - clean up spec file as per the merge review (#225676) dbxml-perl-2.003-3.fc9 ---------------------- * Fri Jan 18 2008 Milan Zazrivec 2.003-3 - Fix db4 version check deskbar-applet-2.21.5-1.fc9 --------------------------- * Thu Jan 17 2008 Luke Macken - 2.21.5-` - 2.21.5 dhcp-12:4.0.0-5.fc9 ------------------- * Thu Jan 17 2008 David Cantrell - 12:4.0.0-5 - Patch read_function() to handle size_t from read() correctly (#429207) * Wed Jan 16 2008 David Cantrell - 12:4.0.0-4 - Fix dhclient.lease file parsing problems (#428785) - Disable IPv6 support for now as we already ship dhcpv6 (#428987) * Tue Jan 15 2008 David Cantrell - 12:4.0.0-3 - Fix segfault in next_iface4() and next_iface6() (#428870) dhcpv6-1.0.9-1.fc9 ------------------ * Thu Jan 17 2008 David Cantrell - 1.0.9-1 - Upgrade to dhcpv6-1.0.9 * Thu Jan 17 2008 David Cantrell - 1.0.8-1 - Upgrade to dhcpv6-1.0.8 dos2unix-3.1-30.fc9 ------------------- * Fri Jan 18 2008 Tim Waugh 3.1-30 - Applied patch from bug #292100 to fix segfault with missing -c argument. dstat-0.6.6-3.fc9 ----------------- * Fri Jan 18 2008 Radek Brich - 0.6.6-3 - Fix --nocolor and --raw (upstream patches) - Fix errors in man page evolution-data-server-2.21.5-3.fc9 ---------------------------------- * Thu Jan 17 2008 Matthew Barnes - 2.21.5-3.fc9 - Rename evolution-1.4.4-ldap-x86_64-hack.patch to avoid namespace collision with similarly named patch in evolution (RH bug #395551). expect-5.43.0-12.fc9 -------------------- * Mon Jan 14 2008 Wart - 5.43.0-12 - Update install locations to reflect updated auto_path in the tcl 8.5 package ez-ipupdate-3.0.11-0.15.b8.fc9 ------------------------------ * Sun Jul 15 2007 Jeff Layton - 3.0.11-0.15.b8 - initscript: add LSB header and fix return values - initscript: remove /var/lock/subsys references f-spot-0.4.1-2.fc9 ------------------ * Fri Jan 18 2008 Matthias Clasen - 0.4.1-2 - Add support for content-types findutils-1:4.2.31-3.fc9 ------------------------ * Fri Jan 18 2008 Vitezslav Crhonek - 1:4.2.31-3 - Rebuild fuse-convmvfs-0.2.4-5.fc9 ------------------------- * Fri Jan 18 2008 ZC Miao - 0.2.4-5 - rebuild gdm-1:2.21.2-0.2007.11.20.11.fc9 -------------------------------- * Thu Jan 17 2008 Jon McCann - 1:2.21.2-0.2007.11.20.11 - Rebuild * Tue Jan 15 2008 Dan Walsh - 1:2.21.2-0.2007.11.20.10 - Fix gdm.pam file so that session include system-auth happens after other session setup * Mon Jan 07 2008 Ray Strode - 1:2.21.2-0.2007.11.20.9 - hide guest account since it doesn't work gthumb-2.10.7-2.fc9 ------------------- * Fri Jan 18 2008 Matthias Clasen - 2.10.7-2 - Add content-type support gtk-recordmydesktop-0.3.7-1.fc9 ------------------------------- * Thu Jan 17 2008 Sindre Pedersen Bj??rdal - 0.3.7-1 - New upstream release gutenprint-5.0.2-1.fc9 ---------------------- * Fri Jan 18 2008 Tim Waugh 5.0.2-1 - 5.0.2. No longer need lpstat patch. * Mon Jan 07 2008 Tim Waugh - Own %{_datadir}/gutenprint (bug #427801). gzip-1.3.12-5.fc9 ----------------- * Fri Jan 18 2008 Ivana Varekova - 1.3.12-5 - rebuild hsqldb-1:1.8.0.9-1jpp.fc9 ------------------------- * Thu Jan 17 2008 Jon Prindiville 1.8.0.9-1jpp - Upgrade to 1.8.0.9 hwdata-0.214-1.fc9 ------------------ * Fri Jan 18 2008 Karsten Hopp 0.214-1 - remove MonitorsDB.generic as it isn't used anywhere - drop RHEL-5 blacklist patch in -devel icecream-0.8.0-8.20080117svn.fc9 -------------------------------- * Thu Jan 17 2008 Michal Schmidt - 0.8.0-8.20080117svn - Update to current icecream-make-it-cool branch. iozone-3-4.fc9 -------------- iputils-20070202-6.fc9 ---------------------- * Mon Jan 14 2008 Martin Nagy - 20070202-6 - fix absolute symlinks and character encoding for RELNOTES (#225909) - preserve file timestamps (#225909) - use %{?_smp_mflags} (#225909) - fix service rdisc stop removing of lock file kernel-2.6.24-0.157.rc8.fc9 --------------------------- * Thu Jan 17 2008 John W. Linville - More wireless fixes headed for 2.6.24 - More wireless updates headed for 2.6.25 * Wed Jan 16 2008 Kyle McMartin - 2.6.24-rc8 * Wed Jan 16 2008 Dave Airlie - update r500 patch to remove dup pciids. less-418-2.fc9 -------------- * Fri Jan 18 2008 Zdenek Prikryl - 418-2 - Fixed -F option - Resolves: #427551 libXfont-1.3.1-3.fc9 -------------------- * Fri Jan 18 2008 Dave Airlie 1.3.1-3 - cve-2008-0006.patch: XFS Integer Overflow Vulnerability * Sun Jan 13 2008 parag 1.3.1-2 - Merge-review #226073 Spec cleanups. * Mon Sep 24 2007 Adam Jackson 1.3.1-1 - libXfont 1.3.1 libdhcp-1.99.6-2.fc9 -------------------- * Wed Jan 16 2008 David Cantrell - 1.99.6-2 - Rebuild for new dhcpv6 and dhcp libvirt-cim-0.1-8.fc9 --------------------- * Thu Jan 17 2008 Dan Smith - 0.1-8 - Add ld.so.conf.d configuration linux-igd-1.0-4.fc9 ------------------- * Fri Jan 18 2008 Masahiro Hasegawa - 1.0-4 - Merge CVS 20070630 lvm2-2.02.30-6.fc9 ------------------ * Thu Jan 17 2008 Alasdair Kergon > - 2.02.30-6 - Remove static libraries and binaries and move most binaries out of /usr. - Fix a segfault if using pvs with --all argument. - Fix vgreduce PV list processing not to process every PV in the VG. - Reinstate VG extent size and stripe size defaults (halved). - Set default readahead to twice maximium stripe size. - Detect non-orphans without MDAs correctly. - Prevent pvcreate from overwriting MDA-less PVs belonging to active VGs. - Don't use block_on_error with mirror targets version 1.12 and above. - Change vgsplit -l (for unimplemented --list) into --maxlogicalvolumes. - Update vgsplit to accept vgcreate options when new VG is destination. - Update vgsplit to accept existing VG as destination. - Major restructuring of pvmove and lvconvert code, adding stacking support. - Add new convert_lv field to lvs output. - Permit LV segment fields with PV segment reports. - Extend lvconvert to use polldaemon and wait for completion of initial sync. - Add seg_start_pe and seg_pe_ranges to reports. - Add fsadm interface to filesystem resizing tools. - Update --uuid argument description in man pages. - Print warning when lvm tools are running as non-root. mash-0.3.0-1.fc9 ---------------- * Thu Jan 17 2008 Bill Nottingham 0.3.0-1 - use createrepo's python API - allow running without local koji storage mcpp-2.6.4-2.fc9 ---------------- mingetty-1.08-1.fc9 ------------------- * Fri Jan 18 2008 Florian La Roche - 1.08-1 - change Source: tag - Bernardo Innocenti bernie at codewiz.org: add LDFLAGS to opt patch to enable cross building on 64bit host - release 1.08 with loginpause option from Bernardo Innocenti bernie at codewiz.org mpfr-2.3.0-2.fc9 ---------------- * Fri Jan 18 2008 Ivana Varekova 2.3.0-2 - rebuilt mrtg-2.15.1-7.fc9 ----------------- * Fri Jan 18 2008 Vitezslav Crhonek - 2.15.1-7 - Rebuild muine-0.8.8-4.fc9 ----------------- * Fri Jan 18 2008 Sindre Pedersen Bj??rdal - 0.8.8-4 - Add ndesk-dbus dependencies, use system ndesk-dbus nautilus-cd-burner-2.20.0-5.fc9 ------------------------------- * Fri Jan 18 2008 Matthias Clasen - 2.20.0-5 - Also call update-desktop-database * Fri Jan 18 2008 Matthias Clasen - 2.20.0-4 - Add content-type support * Sun Dec 23 2007 Matthias Clasen - 2.20.0-3 - Rebuild against new nautilus nethack-3.4.3-16.fc9 -------------------- * Thu Jan 17 2008 Luke Macken 3.4.3-16 - Create a symlink to our fonts in /etc/X11/fontpath.d (Bug #221692) netpbm-10.35.37-1.fc9 --------------------- * Thu Jan 17 2008 Jindrich Novy 10.35.37-1 - update to 10.35.37 openoffice.org-1:2.4.0-3.1.fc9 ------------------------------ * Wed Jan 16 2008 Caolan McNamara - 1:2.4.0-3.1 - Resolves: rhbz#428655 workspace.sw8u10bf04.patch - Resolves: rhbz#428655 workspace.impress132.patch - fix word2 import - Lithuanian help content * Tue Jan 15 2008 Caolan McNamara - 1:2.4.0-2.2 - fix hyphenation * Tue Jan 15 2008 Caolan McNamara - 1:2.4.0-2.1 - drop integrated openoffice.org-2.3.0.ooo74751.bean.mawt.patch - drop integrated openoffice.org-1.9.88.rhXXXXXX.noxfonts.desktop.patch - next candidate openser-1.3.0-2.fc9 ------------------- * Thu Jan 17 2008 Jan ONDREJ (SAL) 1.3.0-2 - removed openser.init and replaced by upstream version - fixed configuration path for openserdbctl (#428799) * Sun Jan 13 2008 Peter Lemenkov 1.3.0-1.4 - 4th try to remove lm_sensors-devel from EL-[45] at ppc{64} openswan-2.6.03-6.fc9 --------------------- * Thu Jan 17 2008 Steve Conklin - 2.6.03-6 - Moved everything else out of /usr/lib - Added tmraz's patch to remove extra slashes in makefile - Removed macros from changelog entries * Thu Jan 17 2008 Steve Conklin - 2.6.03-5 - Removed userland macros from spec file * Thu Jan 17 2008 Steve Conklin - 2.6.03-4 - Removed use of xmlto and the BuildRequires - moved scripts from /usr/lib to /usr/libexec - removed man3 pages for libopenswan functions (we don't deliver) ovaldi-5.3-3.fc9 ---------------- pciutils-2.2.9-3.fc9 -------------------- * Fri Jan 18 2008 Harald Hoyer 2.2.9-3 - removed static library, preserve timestamps on install (rhbz#226236) - added modified patch from Michael E. Brown @ Dell, to also read all /usr/share/hwdata/pci.ids.d/*.ids files (rhbz#195327) perl-File-Next-1.02-1.fc9 ------------------------- * Thu Jan 17 2008 Ian Burrell - 1.02-1 - Update to 1.02 perl-File-chdir-0.09-1.fc9 -------------------------- * Thu Jan 17 2008 Ian Burrell - 0.09-1 - Update to 0.09 procps-3.2.7-19.1.fc9 --------------------- * Fri Jan 18 2008 Tomas Smetana 3.2.7-19.1 - rebuild because of errors on x86_64 * Fri Jan 18 2008 Tomas Smetana 3.2.7-19 - fix #296471 - update top man page - fix #226319 - merge review psacct-6.3.2-49.fc9 ------------------- * Fri Jan 18 2008 Ivana Varekova - 6.3.2-49 - rebuilt pykickstart-1.27-1.fc9 ---------------------- * Thu Jan 17 2008 Chris Lumens - 1.27-1 - The bootprotoList needs to be defined before it's used. (clumens) pylint-0.14.0-1.fc9 ------------------- * Thu Jan 17 2008 Konstantin Ryabitsev - 0.14.0-1 - Upstream 0.14.0 - Package the .egg-info files. * Mon Dec 24 2007 Konstantin Ryabitsev - 0.13.2-1 - Upstream 0.13.2 - Adjust license to a more precise version - Fix docs to be valid utf-8 python-2.5.1-21.fc9 ------------------- * Sun Jan 13 2008 Tom "spot" Callaway - 2.5.1-21 - rebuild for new tk in rawhide * Mon Jan 07 2008 James Antill - 2.5.1-20 - Add valgrind support files, as doc, to python-devel - Relates: rhbz#418621 - Add new API from 2.6, set_wakeup_fd ... use at own risk, presumably won't - change but I have no control to guarantee that. - Resolves: rhbz#427794 - Add gdbinit support file, as doc, to python-devel * Fri Jan 04 2008 Tom "spot" Callaway - 2.5.1-19 - rebuild for new tcl/tk in rawhide python-cherrypy-2.3.0-2.fc9 --------------------------- * Thu Jan 17 2008 Toshio Kuratomi 2.3.0-2 - EINTR Patch needed to be forwarded ported as well as it is only applied to CP trunk (3.x). * Thu Jan 17 2008 Toshio Kuratomi 2.3.0-1 - Update to new upstream which rolls in the backported security fix. - Refresh other patches to apply against new version. - Change to new canonical source URL. - Reenable tests. python-kerberos-1.0-5.fc9 ------------------------- * Wed Jan 16 2008 Rob Crittenden - 1.0-5 - Package the egg-info too * Wed Jan 16 2008 Rob Crittenden - 1.0-4 - Switch from python_sitelib macro to python_sitearch - Add python-setuptools to BuildRequires * Wed Jan 16 2008 Rob Crittenden - 1.0-3 - Use the setup.py install target in order to generate debuginfo. python-kiwi-1.9.19-2.fc9 ------------------------ * Thu Jan 17 2008 Konstantin Ryabitsev - 1.9.19-2 - Package the egg-info file. * Sun Dec 23 2007 Konstantin Ryabitsev - 1.9.19-1 - Upstream 1.9.19 python-logilab-astng-0.17.2-1.fc9 --------------------------------- * Thu Jan 17 2008 Konstantin Ryabitsev - 0.17.2-1 - Upstream 0.17.2 - Package .egg-info file * Mon Dec 24 2007 Konstantin Ryabitsev - 0.17.1-1 - Upstream 0.17.1 - Adjust license to a more specific GPLv2+ - Fix docs to be valid utf-8 python-logilab-common-0.26.1-1.fc9 ---------------------------------- * Thu Jan 17 2008 Konstantin Ryabitsev - 0.26.1-1 - Upstream 0.26.1 - Package egg-info and other files. * Mon Dec 24 2007 Konstantin Ryabitsev - 0.25.2-1 - Upstream 0.25.2 * Sun Nov 18 2007 Konstantin Ryabitsev - 0.24.0-1 - Upstream 0.24.0 - Adjust license to the new standard python-vobject-0.5.0-1.fc9 -------------------------- * Thu Jan 17 2008 James Bowes - 0.5.0-1 - Update to 0.5.0 quake3-1.34-0.8.rc4.fc9 ----------------------- * Thu Jan 17 2008 Hans de Goede 1.34-0.8.rc4 - Properly recognize the demo pak0 file instead of complaining that no valid pak0 was found ratpoison-1.4.1-1.fc9 --------------------- * Fri Jan 18 2008 John Berninger - 1.4.1-1 - rebuild for deps readline-5.2-10.fc9 ------------------- * Fri Jan 18 2008 Miroslav Lichvar 5.2-10 - move libreadline to /lib recordmydesktop-0.3.7-1.fc9 --------------------------- * Thu Jan 17 2008 Sindre Pedersen Bj??rdal - 0.3.7-1 - New upstream release rhythmbox-0.11.4-4.fc9 ---------------------- * Fri Jan 18 2008 Matthias Clasen - 0.11.4-4 - Add content-type support * Thu Jan 17 2008 - Bastien Nocera - 0.11.4-3 - Own the plugins dir (#389111) rsyslog-2.0.0-1.fc9 ------------------- * Thu Jan 17 2008 Peter Vrabec 2.0.0-1 - upgrade - fixing bad file descriptor (#428775) ruby-gnome2-0.16.0-24.fc9 ------------------------- * Fri Jan 18 2008 Mamoru Tasaka 0.16.0-24 - Remove workaround for ruby static archive (#428384 solved) - Add BR: gecko-devel-unstable scorched3d-41.2-1.fc9 --------------------- * Wed Jan 16 2008 Hans de Goede 41.2-1 - New upstream release 41.2 - No longer uses ode so stop BuildRequiring and linking to it scummvm-0.11.0-1.fc9 -------------------- * Wed Jan 16 2008 Hans de Goede 0.11.0-1 - New upstream version 0.11.0 - Drop no longer needed gcc 4.3 patch snake-0.10-0.3git.fc9 --------------------- * Thu Jan 17 2008 James Laska 0.10-0.3git - Add back python-devel for older Fedora building (jlaska) - Remove ListChoiceWindow in favor of snack.ListboxChoiceWindow (jlaska) sound-juicer-2.21.2-2.fc9 ------------------------- * Fri Jan 18 2008 Matthias Clasen - 2.21.2-2 - Add content-type support steghide-0.5.1-8.fc9 -------------------- * Thu Jan 17 2008 Jochen Schmitt 0.5.1-8 - Fix issues for compiling with gcc-4.3 talk-0.17-29.2.4 ---------------- * Fri Jan 18 2008 Vitezslav Crhonek - 0.17-29.2.4 - Rebuild tcsh-6.15-2.fc9 --------------- * Fri Jan 18 2008 Vitezslav Crhonek - 6.15-2 - Rebuild telepathy-butterfly-0.3.1-1.fc9 ------------------------------- * Thu Jan 17 2008 Brian Pepple - 0.3.1-1 - Update to 0.3.1. - Add patch to fix build. * Mon Jan 14 2008 Brian Pepple - 0.3.0-1 - Update to 0.3.0. * Sun Aug 05 2007 Brian Pepple - 0.1.4-2 - Update license tag. texlive-2007-12.fc9 ------------------- * Thu Jan 17 2008 Jindrich Novy - 2007-12 - remove all references to teTeX from the packaged man pages and update links to point correctly to upstream mailing list and web page - drop xpdf patch, we link against poppler now * Wed Jan 16 2008 Jindrich Novy - 2007-11 - temporary fix to pdflatex to not to warn verbosely because of ambiguous entries in pdflatex.map (#425804) - update post scriptlets, spec cleanup * Tue Jan 15 2008 Jindrich Novy - 2007-10 - don't build/package xdvik/pxdvik, it's now separated - fix texlive-doc requires, description - use virtual provides with parentheses to avoid clashes with real packages (#410401) texlive-texmf-2007-8.fc9 ------------------------ * Fri Jan 18 2008 Jindrich Novy - 2007-8 - update updmap.cfg so that pdftex map files are consistent with the current package set thewidgetfactory-0.2.1-5.fc9 ---------------------------- * Fri Jan 18 2008 Luya Tshimbalanga 0.2.1-5 - Rebuilt for dependencies tix-1:8.4.2-4.fc9 ----------------- * Thu Jan 17 2008 Jesse Keating - 1:8.4.2-4 - Rebuild, fix libTix.so link paths. usbutils-0.73-1 --------------- * Thu Jan 17 2008 Jiri Moskovcak 0.73-1 - new version 0.73 * Mon Sep 18 2006 Thomas Woerner 0.72-1 - new version 0.72 - videoterminal (vt) patch is now upstream, dropped vim-2:7.1.233-1.fc9 ------------------- * Fri Jan 18 2008 Karsten Hopp 7.1.233-1 - patchlevel 233 - fix ada patch xmlto-0.0.20-1.fc9 ------------------ * Thu Jan 17 2008 Ondrej Vasik - 0.0.20-1 - new version 0.0.20 - added experimental fop support(additional output formats) - possibility to read stylesheet from STDIN, using recursive cp in docbook formats, updated man pages xorg-x11-drv-fbdev-0.3.1-6.fc9 ------------------------------ * Fri Jan 18 2008 Dave Airlie 0.3.1-6 - rebuild for abi change. xorg-x11-drv-nv-2.1.6-5.fc9 --------------------------- * Fri Jan 18 2008 Dave Airlie 2.1.6-5 - fixup the fixup for fb vs XAA alignment * Fri Jan 18 2008 Dave Airlie 2.1.6-4 - Fixup fb vs XAA alignment xorg-x11-server-1.4.99.1-0.17.20080107.fc9 ------------------------------------------ * Fri Jan 18 2008 Dave Airlie 1.4.99.1-0.17 - cve-2007-5760.patch: XFree86-Misc Extension Invalid Array Index Vulnerability - cve-2007-6427.patch: XInput Extension Memory Corruption Vulnerability - cve-2007-6428.patch: TOG-CUP Extension Memory Corruption Vulnerability - cve-2007-6429.patch: EVI and MIT-SHM Extension Integer Overflow Vulnerability - cve-2008-0006-server-fixup.patch: PCF Font Vulnerability - this patch isn't strictly required with new version of libXfont. * Wed Jan 16 2008 Kristian H??gsberg 1.4.99.1-0.16 - Add xserver-1.4.99-engage-composite-crack-mode.patch to better hide protocol side effects such as loss of grabs and focus when redirecting/unredirecting windows (#350271). * Mon Jan 07 2008 Adam Jackson 1.4.99.1-0.15 - Today's git snapshot. X-SELinux! - Drop the code to migrate from /etc/X11/XF86Config*. - s/perl -p -i -e/sed -i/g xwrits-2.24-2.fc9 ----------------- Broken deps for i386 ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.i386 requires libgtkembedmoz.so epiphany-extensions - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.i386 requires libgtkembedmoz.so gnome-web-photo - 0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 icewm - 1.2.35-1.fc9.i386 requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 qt-recordmydesktop - 0.3.6-4.fc9.noarch requires recordmydesktop = 0:0.3.6 Broken deps for x86_64 ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) icewm - 1.2.35-1.fc9.x86_64 requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 qt-recordmydesktop - 0.3.6-4.fc9.noarch requires recordmydesktop = 0:0.3.6 Broken deps for ppc ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.ppc requires libgtkembedmoz.so epiphany-extensions - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.ppc requires libgtkembedmoz.so gnome-web-photo - 0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 icewm - 1.2.35-1.fc9.ppc requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 monodevelop - 0.17-4.fc9.ppc requires boo qt-recordmydesktop - 0.3.6-4.fc9.noarch requires recordmydesktop = 0:0.3.6 Broken deps for ppc64 ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) icewm - 1.2.35-1.fc9.ppc64 requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 perl-Test-AutoBuild-darcs - 1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 qt-recordmydesktop - 0.3.6-4.fc9.noarch requires recordmydesktop = 0:0.3.6 From kevin.kofler at chello.at Sat Jan 19 17:39:49 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 19 Jan 2008 17:39:49 +0000 (UTC) Subject: KDE and samba license change (GPLv3) References: <200801191638.19865@rineau.tsetse> Message-ID: Laurent Rineau normalesup.org> writes: > Well, it seems both Qt-3 and Qt-4 has been released under GPLv3 this week (in > addition to GPLv2 (and maybe QPL). Let hope the relicencing of KDE will not > stay stalled too long. > http://techbase.kde.org/Projects/KDE_Relicensing The kio_smb code is already GPLv2+, so I think we can reenable it as soon as we have the "GPLv2 or GPLv3" Qt in Rawhide. (LGPL libraries are not an issue for this purpose because the LGPLv2 (and 2.1) explicitly allows converting to any later version of the GPL.) I already sent a mail to kde-redhat-devel about this. Kevin Kofler From triad at df.lth.se Sat Jan 19 17:49:36 2008 From: triad at df.lth.se (Linus Walleij) Date: Sat, 19 Jan 2008 18:49:36 +0100 (CET) Subject: rawhide report: 20080118 changes In-Reply-To: <200801191711.m0JHBcSi017061@porkchop.devel.redhat.com> References: <200801191711.m0JHBcSi017061@porkchop.devel.redhat.com> Message-ID: On Sat, 19 Jan 2008, Build System wrote: > New package preload > Preload is an adaptive readahead daemon Heey, we talk around this things incarnation over at Novell and it turns out we have a thing boiling in BZ since october. The sheer size of the Fedora community makes it possible to miss such things, and that's good news! Now, some preload-testing. Linus From lsof at nodata.co.uk Sat Jan 19 18:08:17 2008 From: lsof at nodata.co.uk (nodata) Date: Sat, 19 Jan 2008 19:08:17 +0100 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <200801181336.48285.ben.kreuter@gmail.com> References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> Message-ID: <1200766097.2961.5.camel@sb-home> Am Freitag, den 18.01.2008, 13:36 -0500 schrieb Benjamin Kreuter: > I've had a similar experience with Ubuntu guys -- they are not > interested in > discussing any serious problems with their distro. There was an > STNYLug > meeting at my school a few months back, and is was led by a Canonical > employee. He wanted us to think up a list of Linux pros and cons -- > but when > I suggested that packages breaking between major releases was a con, I > was > completely shot down by him. He didn't even want to discuss it. Some > other > Ubuntu contributors in the room acted like it wasn't really a problem > because > other systems suffer from it as well. > > I walked out... > > -- Benjamin Kreuter Apart from security bugs, I have never had a bug fixed in Ubuntu, ever. The tactic seems to be to wait until Debian fix it, or wait until Debian fix it and then ask you to upgrade to the next release. Fedora does a lot better, much better, but probably the most annoying aspect of using Fedora's bugzilla is the attitude of some of the maintainers (not all) and the "closing, report upstream" attitude. Closing a bug report with "report it upstream" is a let down. It's repetitive boring work that a computer should be doing. It takes a lot of effort to report a bug, and by this I mean that I know a *lot* of people who find a bug, and maybe a fix, but don't bug report it. They should be, but I can see why they don't. From skvidal at fedoraproject.org Sat Jan 19 18:10:49 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Sat, 19 Jan 2008 13:10:49 -0500 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <1200766097.2961.5.camel@sb-home> References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> Message-ID: <1200766249.3275.14.camel@cutter> On Sat, 2008-01-19 at 19:08 +0100, nodata wrote: > Apart from security bugs, I have never had a bug fixed in Ubuntu, ever. > The tactic seems to be to wait until Debian fix it, or wait until Debian > fix it and then ask you to upgrade to the next release. > > Fedora does a lot better, much better, but probably the most annoying > aspect of using Fedora's bugzilla is the attitude of some of the > maintainers (not all) and the "closing, report upstream" attitude. > > Closing a bug report with "report it upstream" is a let down. It's > repetitive boring work that a computer should be doing. > > It takes a lot of effort to report a bug, and by this I mean that I know > a *lot* of people who find a bug, and maybe a fix, but don't bug report > it. They should be, but I can see why they don't. Hmm, is that what the 'upstream' close reason is for? Normally, I close things 'upstream' when I have checked a fix into the upstream code base. Which seems pretty reasonable time to close it to me. -sv From lsof at nodata.co.uk Sat Jan 19 18:23:00 2008 From: lsof at nodata.co.uk (nodata) Date: Sat, 19 Jan 2008 19:23:00 +0100 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <1200766249.3275.14.camel@cutter> References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> Message-ID: <1200766980.2961.8.camel@sb-home> Am Samstag, den 19.01.2008, 13:10 -0500 schrieb seth vidal: > On Sat, 2008-01-19 at 19:08 +0100, nodata wrote: > > > Apart from security bugs, I have never had a bug fixed in Ubuntu, ever. > > The tactic seems to be to wait until Debian fix it, or wait until Debian > > fix it and then ask you to upgrade to the next release. > > > > Fedora does a lot better, much better, but probably the most annoying > > aspect of using Fedora's bugzilla is the attitude of some of the > > maintainers (not all) and the "closing, report upstream" attitude. > > > > Closing a bug report with "report it upstream" is a let down. It's > > repetitive boring work that a computer should be doing. > > > > It takes a lot of effort to report a bug, and by this I mean that I know > > a *lot* of people who find a bug, and maybe a fix, but don't bug report > > it. They should be, but I can see why they don't. > > Hmm, is that what the 'upstream' close reason is for? Normally, I close > things 'upstream' when I have checked a fix into the upstream code base. > Which seems pretty reasonable time to close it to me. > > -sv > I'm talking about closing the bug and telling the reporter to report upstream, i.e. "go away". From buildsys at redhat.com Sat Jan 19 18:30:28 2008 From: buildsys at redhat.com (Build System) Date: Sat, 19 Jan 2008 13:30:28 -0500 Subject: rawhide report: 20080119 changes Message-ID: <200801191830.m0JIUSa8018590@porkchop.devel.redhat.com> New package mkelfimage Utility to create ELF boot images from Linux kernel images New package python-tgexpandingformwidget A repeating form widget for TurboGears New package wiggle A tool for applying patches with conflicts Updated Packages: adplug-2.1-3.fc9 ---------------- * Fri Jan 18 2008 Linus Walleij 2.1-3 - New glibc ABI needs rebuild. control-center-1:2.21.5-1.fc9 ----------------------------- * Thu Jan 17 2008 - Bastien Nocera - 2.21.5-1 - Update to 2.21.5 dbmail-2.2.8-1.fc9 ------------------ * Fri Jan 18 2008 Bernard Johnson - 2.2.8-1 - 2.2.8-1 esc-1.0.1-8.fc9 --------------- * Fri Jan 18 2008 Jack Magne - Fix tray icon menu issue #253248. * Thu Aug 30 2007 Jack Magne - License field change- 1.0.1-7 * Wed Aug 29 2007 Fedora Release Engineering - 1.0.1-6 - Rebuild for selinux ppc32 issue. gdm-1:2.21.5-1.fc9 ------------------ * Fri Jan 18 2008 Jon McCann - 1:2.21.5-1 - Update to 2.21.5 * Thu Jan 17 2008 Jon McCann - 1:2.21.2-0.2007.11.20.11 - Rebuild * Tue Jan 15 2008 Dan Walsh - 1:2.21.2-0.2007.11.20.10 - Fix gdm.pam file so that session include system-auth happens after other session setup glitz-0.5.6-5.fc9 ----------------- gobby-0.4.5-1.fc9 ----------------- gossip-0.28-2.fc9 ----------------- * Fri Jan 18 2008 Brian Pepple - 0.28-2 - Rebuild for new version of loudmouth. guile-cairo-1.4.0-4.fc9 ----------------------- hplip-2.7.12-2.fc9 ------------------ * Fri Jan 18 2008 Tim Waugh 2.7.12-2 - Ship installer directory (bug #428246). - Avoid multilib conflict (bug #341531). - The hpijs sub-package requires net-snmp (bug #376641). * Fri Jan 18 2008 Tim Waugh 2.7.12-1 - 2.7.12. No longer need ljdot4 patch. initscripts-8.61-1 ------------------ * Fri Jan 18 2008 Bill Nottingham - 8.61-1 - use lvm, not lvm.static (#429222) - ifup-eth: don't do something odd if we find a mac address that matches the user-set MACADDR (#251415) - rc.sysinit: fix root fs check to catch 'rw,ordered,noatime,etc.' properly (#334171) - rc.sysinit: Use proper invocations for authconfig, system-config-network (#426372, #428202) - service: handle unreadable scripts (#427767) - initscripts.spec: add requirements for stateless - fix perms on /etc/profile.d (#407531, ) - rename_device: handle quoted HWADDR, etc. in ifcfg scripts (#351291) - minor stateless fixes - Makefile cleanups (from OLPC, ) - translation updates: fr, ru, nb - don't endelessly loop on ifdown (#390271) - rc.sysinit: - fix encrypted swap partitions with random key () kernel-xen-2.6-2.6.21.7-2893.fc9 -------------------------------- * Fri Jan 18 2008 Daniel P. Berrange - Update to 3.2.0 final release lam-2:7.1.2-11.fc9 ------------------ * Fri Jan 18 2008 Doug Ledford - 2:7.1.2-11 - Bump and rebuild libbinio-1.4-8.fc9 ------------------ * Fri Jan 18 2008 Linus Walleij 1.4-8 - New glibc ABI wants a rebuild. libvirt-0.4.0-4.fc9 ------------------- * Fri Jan 18 2008 Daniel P. Berrange - 0.4.0-4.fc9 - Fix SSH tunnelling (rhbz #428743) - Fix back-compat for nodeinfo call changes. loudmouth-1.3.3-1.fc9 --------------------- * Fri Jan 18 2008 Brian Pepple - 1.3.3-1 - Update to 1.3.3. - Drop reconnect-failure patch. - Drop gnutls compression patch. fixed upstream. mash-0.3.1-1.fc9 ---------------- * Fri Jan 18 2008 Bill Nottingham 0.3.1-1 - fix typo that broke handling of unsigned packages mdadm-2.6.4-2.fc9 ----------------- * Fri Jan 18 2008 Doug Ledford - 2.6.4-2 - Bump version and rebuild * Fri Oct 19 2007 Doug Ledford - 2.6.4-1 - Update to latest upstream and remove patches upstream has taken mfiler2-4.0.8-1.fc9 ------------------- * Sat Jan 19 2008 Mamoru Tasaka - 4.0.8-1 - 4.0.8 mlton-20070826-11.fc9 --------------------- * Fri Jan 18 2008 Adam Goode - 20070826-11 - Rebuild for new GCC nedit-5.5-16.fc9 ---------------- * Sun Jan 06 2008 Patrice Dumas 5.5-16 - minor cleanups net6-1.3.5-2.fc9 ---------------- nickle-2.62-1.fc9 ----------------- * Fri Jan 18 2008 Michel Salim 2.62-1 - Update to 2.62 obby-0.4.4-2.fc9 ---------------- oprofile-0.9.3-15.fc9 --------------------- * Fri Jan 18 2008 Will Cohen - 0.9.3-15 - Deal with xenoprof conlficts with cell. Resolves: rhbz #250852 * Fri Jan 18 2008 Will Cohen - 0.9.3-14 - Bump format version. Check version properly. Resolves: rhbz #394571 * Fri Jan 18 2008 Will Cohen - 0.9.3-13 - Disable profiling in hypervisor on 970MP to prevent lost interrupts. Resolves: rhbz #391251 paraview-3.2.1-3.fc9 -------------------- * Fri Jan 18 2008 - Orion Poplawski - 3.2.1-3 - Add patch to fix parallel make - Obsolete demos package (bug #428528) plplot-5.8.0-10.fc9 ------------------- * Fri Jan 18 2008 - Orion Poplawski - 5.8.0-10 - Add Requries: libtool-ltdl-devel to devel package pork-0.99.8.1-7.fc9 ------------------- postgresql-8.3RC2-1.fc9 ----------------------- * Fri Jan 18 2008 Tom Lane 8.3RC2-1 - Update to PostgreSQL 8.3RC2 (not waiting for 8.3.0 because Fedora 9 alpha should be 8.3-based not 8.2-based). - Update to pgtcl 1.6.2 * Mon Jan 07 2008 Tom Lane 8.2.6-1 - Update to PostgreSQL 8.2.6 to fix CVE-2007-4769, CVE-2007-4772, CVE-2007-6067, CVE-2007-6600, CVE-2007-6601 - Make initscript and pam config files be installed unconditionally; seems new buildroots don't necessarily have those directories in place * Wed Dec 05 2007 Tom Lane 8.2.5-2 - Rebuild for new openssl python-TestGears-0.2-6.fc9 -------------------------- python-clientform-0.2.7-2.fc9 ----------------------------- python-formencode-0.7.1-2.fc9 ----------------------------- python-json-3.4-3.fc9 --------------------- python-mechanize-0.1.6-0.2.b.fc9 -------------------------------- python-numeric-24.2-7.fc9 ------------------------- * Fri Jan 18 2008 Matthew Barnes - 24.2-7 - Incorporate package review feedback from Parag AN (RH bug #226345). python-paste-1.4.2-1.fc9 ------------------------ python-paste-deploy-1.3.1-2.fc9 ------------------------------- python-paste-script-1.3.6-1.fc9 ------------------------------- python-tgfastdata-0.9a6-6.fc9 ----------------------------- shared-mime-info-0.23-2.fc9 --------------------------- * Fri Jan 18 2008 Matthias Clasen - 0.23-2 - Add defaults for content types system-config-date-1.9.21-1.fc9 ------------------------------- * Fri Jan 18 2008 Nils Philippsen - 1.9.21-1 - online help: reorg, make xmllint happy systemtap-0.6.1-1.fc9 --------------------- * Fri Jan 18 2008 Frank Ch. Eigler - 0.6.1-1 - Add crash-devel buildreq to build staplog.so crash(8) module. - Many robustness & functionality improvements: * Wed Dec 05 2007 Will Cohen - 0.6-2 - Correct Source to point to location contain code. teg-0.11.2-14.fc9 ----------------- * Fri Jan 18 2008 josef radinger - 0.11.2-14 - actually execute cosmetic fix in spec-description * Fri Jan 18 2008 josef radinger - 0.11.2-13 - cosmetic fix in spec-description telepathy-gabble-0.6.1-2.fc9 ---------------------------- * Fri Jan 18 2008 Brian Pepple - 0.6.1-2 - Rebuild for new version of loudmouth. texlive-2007-13.fc9 ------------------- * Fri Jan 18 2008 Jindrich Novy - 2007-13 - don't copy original pdftex map files but regenerate them with the correct updmap.cfg file updated in texlive-texmf (Related: #425804) - install mendex via libtool (#428507) * Thu Jan 17 2008 Jindrich Novy - 2007-12 - remove all references to teTeX from the packaged man pages and update links to point correctly to upstream mailing list and web page - drop xpdf patch, we link against poppler now * Wed Jan 16 2008 Jindrich Novy - 2007-11 - temporary fix to pdflatex to not to warn verbosely because of ambiguous entries in pdflatex.map (#425804) - update post scriptlets, spec cleanup totem-2.21.90-2.fc9 ------------------- * Fri Jan 18 2008 Matthias Clasen - 2.21.90-2 - Add content-type support * Mon Jan 07 2008 - Bastien Nocera - 2.21.90-1 - Update to 2.21.90 - Add patch to allow building against xulrunner * Mon Dec 10 2007 - Bastien Nocera - 2.21.5-4 - Add the (non-working yet, missing files in the tarball) publish plugin vim-2:7.1.233-2.fc9 ------------------- * Fri Jan 18 2008 Karsten Hopp 7.1.233-2 - silence taglist plugin (#429200) xchat-1:2.8.4-11.fc9 -------------------- * Sat Jan 19 2008 Kevin Kofler - 1:2.8.4-11 - fix bug in xchat-2.8.4-shm-pixmaps.patch (Adam Jackson, #429218) * Thu Jan 03 2008 Christopher Aillon 1:2.8.4-10 - Rebuild * Thu Dec 20 2007 Adam Jackson 1:2.8.4-9 - xchat-2.8.4-shm-pixmaps.patch: MIT-SHM pixmaps are optional, and when using EXA they are not available. Check that the server supports them before trying to create them so we don't crash. xdg-utils-1.0.2-3.fc9 --------------------- * Fri Jan 18 2008 Rex Dieter 1.0.2-3 - fix mimeopen support (#429280) - spec cosmetics: cleanup macro usage xdvik-22.84.13-7.fc9 -------------------- * Wed Jan 16 2008 Jonathan G. Underwood - 22.84.13-7 - Replace texlive-2007-xdvi-keepflag.patch with xdvik-22.84.13-keepflag-fixscroll.patch to fix - BZ 417461 (Michal Jaegermann) xen-3.2.0-1.fc9 --------------- * Fri Jan 18 2008 Daniel P. Berrange - 3.2.0-1.fc9 - Updated to 3.2.0 final release * Thu Jan 10 2008 Daniel P. Berrange - 3.2.0-0.fc9.rc5.dev16701.1 - Rebase to Xen 3.2 rc5 changeset 16701 * Thu Dec 13 2007 Daniel P. Berrange - 3.1.2-3.fc9 - Re-factor to make it easier to test dev trees in RPMs - Include hypervisor build if doing a dev RPM xorg-x11-drv-openchrome-0.2.901-5.fc9 ------------------------------------- * Sat Jan 19 2008 Xavier Bachelot - 0.2.901-5 - Add patch to replace xf86memcpy by plain memcpy. xorg-x11-server-1.4.99.1-0.18.20080107.fc9 ------------------------------------------ * Fri Jan 18 2008 Dave Airlie 1.4.99.1-0.18 - cve-2007-6429.patch: Fix patch to not break java apps * Fri Jan 18 2008 Dave Airlie 1.4.99.1-0.17 - cve-2007-5760.patch: XFree86-Misc Extension Invalid Array Index Vulnerability - cve-2007-6427.patch: XInput Extension Memory Corruption Vulnerability - cve-2007-6428.patch: TOG-CUP Extension Memory Corruption Vulnerability - cve-2007-6429.patch: EVI and MIT-SHM Extension Integer Overflow Vulnerability - cve-2008-0006-server-fixup.patch: PCF Font Vulnerability - this patch isn't strictly required with new version of libXfont. * Wed Jan 16 2008 Kristian H??gsberg 1.4.99.1-0.16 - Add xserver-1.4.99-engage-composite-crack-mode.patch to better hide protocol side effects such as loss of grabs and focus when redirecting/unredirecting windows (#350271). xprobe2-0.3-9.fc9 ----------------- Broken deps for i386 ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.i386 requires libgtkembedmoz.so epiphany-extensions - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.i386 requires libgtkembedmoz.so gnome-web-photo - 0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 icewm - 1.2.35-1.fc9.i386 requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 qt-recordmydesktop - 0.3.6-4.fc9.noarch requires recordmydesktop = 0:0.3.6 sepostgresql - 8.2.6-1.147.fc9.i386 requires postgresql-server = 0:8.2.6 Broken deps for x86_64 ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) icewm - 1.2.35-1.fc9.x86_64 requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 qt-recordmydesktop - 0.3.6-4.fc9.noarch requires recordmydesktop = 0:0.3.6 sepostgresql - 8.2.6-1.147.fc9.x86_64 requires postgresql-server = 0:8.2.6 Broken deps for ppc ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.ppc requires libgtkembedmoz.so epiphany-extensions - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.ppc requires libgtkembedmoz.so gnome-web-photo - 0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 icewm - 1.2.35-1.fc9.ppc requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 monodevelop - 0.17-4.fc9.ppc requires boo qt-recordmydesktop - 0.3.6-4.fc9.noarch requires recordmydesktop = 0:0.3.6 sepostgresql - 8.2.6-1.147.fc9.ppc requires postgresql-server = 0:8.2.6 Broken deps for ppc64 ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) icewm - 1.2.35-1.fc9.ppc64 requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 perl-Test-AutoBuild-darcs - 1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 qt-recordmydesktop - 0.3.6-4.fc9.noarch requires recordmydesktop = 0:0.3.6 sepostgresql - 8.2.6-1.147.fc9.ppc64 requires postgresql-server = 0:8.2.6 From j.w.r.degoede at hhs.nl Sat Jan 19 18:34:57 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 19 Jan 2008 19:34:57 +0100 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <1200766980.2961.8.camel@sb-home> References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> <1200766980.2961.8.camel@sb-home> Message-ID: <479242D1.8050800@hhs.nl> nodata wrote: > Am Samstag, den 19.01.2008, 13:10 -0500 schrieb seth vidal: >> On Sat, 2008-01-19 at 19:08 +0100, nodata wrote: >> >>> Apart from security bugs, I have never had a bug fixed in Ubuntu, ever. >>> The tactic seems to be to wait until Debian fix it, or wait until Debian >>> fix it and then ask you to upgrade to the next release. >>> >>> Fedora does a lot better, much better, but probably the most annoying >>> aspect of using Fedora's bugzilla is the attitude of some of the >>> maintainers (not all) and the "closing, report upstream" attitude. >>> >>> Closing a bug report with "report it upstream" is a let down. It's >>> repetitive boring work that a computer should be doing. >>> >>> It takes a lot of effort to report a bug, and by this I mean that I know >>> a *lot* of people who find a bug, and maybe a fix, but don't bug report >>> it. They should be, but I can see why they don't. >> Hmm, is that what the 'upstream' close reason is for? Normally, I close >> things 'upstream' when I have checked a fix into the upstream code base. >> Which seems pretty reasonable time to close it to me. >> >> -sv >> > > I'm talking about closing the bug and telling the reporter to report > upstream, i.e. "go away". > I agree that the above is bad. Sometimes (rarely) I do forward a bugreport upstream (using upstream's preferred bug tracking mechanism) and then kindly explain that I'm not intimate enough with the code to fix the issue at hand with a reasonable effort, point them to the upstream bug and add them to the CC there if possible. And then close with a resolution of upstream. Not very pretty, but honest and way better then letting bugs linger for months. Regards, Hans From tgl at redhat.com Sat Jan 19 18:37:18 2008 From: tgl at redhat.com (Tom Lane) Date: Sat, 19 Jan 2008 13:37:18 -0500 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <1200766249.3275.14.camel@cutter> References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> Message-ID: <26559.1200767838@sss.pgh.pa.us> seth vidal writes: > On Sat, 2008-01-19 at 19:08 +0100, nodata wrote: >> Closing a bug report with "report it upstream" is a let down. It's >> repetitive boring work that a computer should be doing. >> >> It takes a lot of effort to report a bug, and by this I mean that I know >> a *lot* of people who find a bug, and maybe a fix, but don't bug report >> it. They should be, but I can see why they don't. > Hmm, is that what the 'upstream' close reason is for? I believe what that's supposed to mean is "the bug *has been* reported upstream" --- either by the maintainer or the original reporter. Now if the maintainer can't fix it himself, I can see the point of asking the original reporter to report upstream: cutting out the middleman. If upstream wants more details they're likely to need to ask the original reporter anyway. But certainly the maintainer should be polite about asking that. regards, tom lane From berrange at redhat.com Sat Jan 19 18:39:14 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Sat, 19 Jan 2008 18:39:14 +0000 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <479242D1.8050800@hhs.nl> References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> <1200766980.2961.8.camel@sb-home> <479242D1.8050800@hhs.nl> Message-ID: <20080119183914.GJ6349@redhat.com> On Sat, Jan 19, 2008 at 07:34:57PM +0100, Hans de Goede wrote: > nodata wrote: > >Am Samstag, den 19.01.2008, 13:10 -0500 schrieb seth vidal: > >>On Sat, 2008-01-19 at 19:08 +0100, nodata wrote: > >> > >>>Apart from security bugs, I have never had a bug fixed in Ubuntu, ever. > >>>The tactic seems to be to wait until Debian fix it, or wait until Debian > >>>fix it and then ask you to upgrade to the next release. > >>> > >>>Fedora does a lot better, much better, but probably the most annoying > >>>aspect of using Fedora's bugzilla is the attitude of some of the > >>>maintainers (not all) and the "closing, report upstream" attitude. > >>> > >>>Closing a bug report with "report it upstream" is a let down. It's > >>>repetitive boring work that a computer should be doing. > >>> > >>>It takes a lot of effort to report a bug, and by this I mean that I know > >>>a *lot* of people who find a bug, and maybe a fix, but don't bug report > >>>it. They should be, but I can see why they don't. > >>Hmm, is that what the 'upstream' close reason is for? Normally, I close > >>things 'upstream' when I have checked a fix into the upstream code base. > >>Which seems pretty reasonable time to close it to me. > >> > >>-sv > >> > > > >I'm talking about closing the bug and telling the reporter to report > >upstream, i.e. "go away". > > > > I agree that the above is bad. > > Sometimes (rarely) I do forward a bugreport upstream (using upstream's > preferred bug tracking mechanism) and then kindly explain that I'm not > intimate enough with the code to fix the issue at hand with a reasonable > effort, point them to the upstream bug and add them to the CC there if > possible. And then close with a resolution of upstream. Not very pretty, > but honest and way better then letting bugs linger for months. It is possible to link tickets between the Red Hat bugzilla and other BZ instances. At the bottom there is a 'External Bugzilla References' form - simply add the number of the associated upstream BZ ticket. Rather than entering upstream and then closing the RH BZ ticket, I'd suggest using this linkage between BZ instances. Then when the upstream maintainer finds a fix, you still have a record of the fact that it needs to be pulled into Fedora. If you close the Fedora BZ, you'll never remember to pull in the fix from upstream. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From j.w.r.degoede at hhs.nl Sat Jan 19 18:47:00 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 19 Jan 2008 19:47:00 +0100 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <20080119183914.GJ6349@redhat.com> References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> <1200766980.2961.8.camel@sb-home> <479242D1.8050800@hhs.nl> <20080119183914.GJ6349@redhat.com> Message-ID: <479245A4.1080904@hhs.nl> Daniel P. Berrange wrote: > On Sat, Jan 19, 2008 at 07:34:57PM +0100, Hans de Goede wrote: >> nodata wrote: >>> Am Samstag, den 19.01.2008, 13:10 -0500 schrieb seth vidal: >>>> On Sat, 2008-01-19 at 19:08 +0100, nodata wrote: >>>> >>>>> Apart from security bugs, I have never had a bug fixed in Ubuntu, ever. >>>>> The tactic seems to be to wait until Debian fix it, or wait until Debian >>>>> fix it and then ask you to upgrade to the next release. >>>>> >>>>> Fedora does a lot better, much better, but probably the most annoying >>>>> aspect of using Fedora's bugzilla is the attitude of some of the >>>>> maintainers (not all) and the "closing, report upstream" attitude. >>>>> >>>>> Closing a bug report with "report it upstream" is a let down. It's >>>>> repetitive boring work that a computer should be doing. >>>>> >>>>> It takes a lot of effort to report a bug, and by this I mean that I know >>>>> a *lot* of people who find a bug, and maybe a fix, but don't bug report >>>>> it. They should be, but I can see why they don't. >>>> Hmm, is that what the 'upstream' close reason is for? Normally, I close >>>> things 'upstream' when I have checked a fix into the upstream code base. >>>> Which seems pretty reasonable time to close it to me. >>>> >>>> -sv >>>> >>> I'm talking about closing the bug and telling the reporter to report >>> upstream, i.e. "go away". >>> >> I agree that the above is bad. >> >> Sometimes (rarely) I do forward a bugreport upstream (using upstream's >> preferred bug tracking mechanism) and then kindly explain that I'm not >> intimate enough with the code to fix the issue at hand with a reasonable >> effort, point them to the upstream bug and add them to the CC there if >> possible. And then close with a resolution of upstream. Not very pretty, >> but honest and way better then letting bugs linger for months. > > It is possible to link tickets between the Red Hat bugzilla and other > BZ instances. At the bottom there is a 'External Bugzilla References' > form - simply add the number of the associated upstream BZ ticket. > Rather than entering upstream and then closing the RH BZ ticket, I'd > suggest using this linkage between BZ instances. Then when the upstream > maintainer finds a fix, you still have a record of the fact that it > needs to be pulled into Fedora. If you close the Fedora BZ, you'll > never remember to pull in the fix from upstream. > I know about the BZ link feature and I always use it when a bug is reported both upstream and in Fedora, but I've never ever seen any good come out of it, I would expect Fedora BZ to send out mails to those CC-ed on the Fedora bug when something happens in the upstream linked bug, maybe even add a comment when the upstream bug changes, but it does none of the above, so I wonder what is the added value of using the BZ link feature instead of just putting an url to upstream's ticket in a comment? Regards, Hans From berrange at redhat.com Sat Jan 19 18:55:16 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Sat, 19 Jan 2008 18:55:16 +0000 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <479245A4.1080904@hhs.nl> References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> <1200766980.2961.8.camel@sb-home> <479242D1.8050800@hhs.nl> <20080119183914.GJ6349@redhat.com> <479245A4.1080904@hhs.nl> Message-ID: <20080119185516.GN6349@redhat.com> On Sat, Jan 19, 2008 at 07:47:00PM +0100, Hans de Goede wrote: > Daniel P. Berrange wrote: > >On Sat, Jan 19, 2008 at 07:34:57PM +0100, Hans de Goede wrote: > >>nodata wrote: > >> > >>Sometimes (rarely) I do forward a bugreport upstream (using upstream's > >>preferred bug tracking mechanism) and then kindly explain that I'm not > >>intimate enough with the code to fix the issue at hand with a reasonable > >>effort, point them to the upstream bug and add them to the CC there if > >>possible. And then close with a resolution of upstream. Not very pretty, > >>but honest and way better then letting bugs linger for months. > > > >It is possible to link tickets between the Red Hat bugzilla and other > >BZ instances. At the bottom there is a 'External Bugzilla References' > >form - simply add the number of the associated upstream BZ ticket. > >Rather than entering upstream and then closing the RH BZ ticket, I'd > >suggest using this linkage between BZ instances. Then when the upstream > >maintainer finds a fix, you still have a record of the fact that it > >needs to be pulled into Fedora. If you close the Fedora BZ, you'll > >never remember to pull in the fix from upstream. > > > > I know about the BZ link feature and I always use it when a bug is reported > both upstream and in Fedora, but I've never ever seen any good come out of > it, I would expect Fedora BZ to send out mails to those CC-ed on the Fedora > bug when something happens in the upstream linked bug, maybe even add a > comment when the upstream bug changes, but it does none of the above, so I > wonder what is the added value of using the BZ link feature instead of just > putting an url to upstream's ticket in a comment? With some upstream BZ instances, we do actually get state updates from the upstream BZ fed back into the RH BZ, but I agree in 95% of scenarios it does very little. Which is a shame. At least by using the link feature we have the potential to write tools to do automatic analysis/reports/etc. But if you just add a URL, we have lost this formal linkage forever and don't even get the possibilty of writing tools to process it. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From kevin.kofler at chello.at Sat Jan 19 20:05:36 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 19 Jan 2008 20:05:36 +0000 (UTC) Subject: An interesting read when discussing what to do about our bugs... References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> Message-ID: nodata nodata.co.uk> writes: > Fedora does a lot better, much better, but probably the most annoying > aspect of using Fedora's bugzilla is the attitude of some of the > maintainers (not all) and the "closing, report upstream" attitude. > > Closing a bug report with "report it upstream" is a let down. It's > repetitive boring work that a computer should be doing. We're 4 maintainers for all of KDE in Fedora (and that's already 4 times as many as not too long ago). We get dozens of bug reports, many of which aren't specific to Fedora in any way. There's no way we can fix them all by ourselves, the only way to actually get things fixed is to report them to the actual upstream maintainers of the concrete application you're having issues with. And I don't think KDE is the only set of packages in this situation. Kevin Kofler From nicolas.mailhot at laposte.net Sat Jan 19 20:08:38 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 19 Jan 2008 21:08:38 +0100 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <1200766249.3275.14.camel@cutter> References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> Message-ID: <1200773318.26373.14.camel@rousalka.dyndns.org> Le samedi 19 janvier 2008 ? 13:10 -0500, seth vidal a ?crit : > Hmm, is that what the 'upstream' close reason is for? Normally, I close > things 'upstream' when I have checked a fix into the upstream code base. > Which seems pretty reasonable time to close it to me. There is a huge variance between maintainers. Some will only look at fedora bugs Others will tell you to open bugs upstream, but do nothing if a sister fedora bug is not opened Yet others will only look at upstream bugs, and complain if you open a fedora bug Others won't look at any bug and rely on upstream grapewine to know what need to be fixed. Complete disregard for tester efforts seems widespread. Complaining to reporters they didn't open an issue in the right place is common. So is ignoring bugs because supposedly they're not complete enough (without bothering to explain what complete would be). Even more annoying are maintainers that ask to do a lot of stuff then ignore completely the result. There are exceptions of course (in particular I nominate Caolan McNamara for being exceptionally responsive ad helpful on openoffice.org bugs). But most of the times fighting spirit and behaving like a bastard seems to be a requirement to get issues dealt with (for example forgetting to block the right fxblocker is a quick way to oblivion) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Sat Jan 19 20:10:31 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 19 Jan 2008 21:10:31 +0100 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <20080119183914.GJ6349@redhat.com> References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> <1200766980.2961.8.camel@sb-home> <479242D1.8050800@hhs.nl> <20080119183914.GJ6349@redhat.com> Message-ID: <1200773431.26373.16.camel@rousalka.dyndns.org> Le samedi 19 janvier 2008 ? 18:39 +0000, Daniel P. Berrange a ?crit : > Rather than entering upstream and then closing the RH BZ ticket, I'd > suggest using this linkage between BZ instances. Unfortunately some packagers will still yell at you for opening two bugs -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From berrange at redhat.com Sat Jan 19 20:13:19 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Sat, 19 Jan 2008 20:13:19 +0000 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <1200773431.26373.16.camel@rousalka.dyndns.org> References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> <1200766980.2961.8.camel@sb-home> <479242D1.8050800@hhs.nl> <20080119183914.GJ6349@redhat.com> <1200773431.26373.16.camel@rousalka.dyndns.org> Message-ID: <20080119201319.GT6349@redhat.com> On Sat, Jan 19, 2008 at 09:10:31PM +0100, Nicolas Mailhot wrote: > > Le samedi 19 janvier 2008 ? 18:39 +0000, Daniel P. Berrange a ?crit : > > > Rather than entering upstream and then closing the RH BZ ticket, I'd > > suggest using this linkage between BZ instances. > > Unfortunately some packagers will still yell at you for opening two > bugs I don't care about packagers yelling at me - I care about making the best effort to fix user's bugs. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From ben.kreuter at gmail.com Sat Jan 19 20:12:40 2008 From: ben.kreuter at gmail.com (Benjamin Kreuter) Date: Sat, 19 Jan 2008 15:12:40 -0500 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: References: <20080118131620.748606a0@redhat.com> <1200766097.2961.5.camel@sb-home> Message-ID: <200801191512.45321.ben.kreuter@gmail.com> On Saturday 19 January 2008 15:05:36 Kevin Kofler wrote: > We're 4 maintainers for all of KDE in Fedora (and that's already 4 times as > many as not too long ago). We get dozens of bug reports, many of which > aren't specific to Fedora in any way. There's no way we can fix them all by > ourselves, the only way to actually get things fixed is to report them to > the actual upstream maintainers of the concrete application you're having > issues with. And I don't think KDE is the only set of packages in this > situation. > > Kevin Kofler Yeah, but that is the reason why bugs are referred upstream. The problem is when a package maintainer tries to say that the problem is upstream in situations where the bug is caused by the way the package was compiled, or some conflicting configuration with another package, etc. -- Benjamin Kreuter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From kevin.kofler at chello.at Sat Jan 19 20:31:06 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 19 Jan 2008 20:31:06 +0000 (UTC) Subject: An interesting read when discussing what to do about our bugs... References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> <1200773318.26373.14.camel@rousalka.dyndns.org> Message-ID: Nicolas Mailhot laposte.net> writes: > Complete disregard for tester efforts seems widespread. Complaining to > reporters they didn't open an issue in the right place is common. So is > ignoring bugs because supposedly they're not complete enough (without > bothering to explain what complete would be). Even more annoying are > maintainers that ask to do a lot of stuff then ignore completely the > result. I can fully understand your frustration, reporting a bug can be hard sometimes. However, please also try to understand the maintainer's side. You're maintaining a few packages yourself, have you never felt frustrated about: * getting swamped with dozens of (non-Fedora-specific) bug reports against huge upstream projects, where technically you might be able to fix any of them, but you definitely don't have the time to fix them all? and/or * occasionally getting bug reports which are so vague that you don't have the slightest chance of ever figuring out what went wrong, let alone reproducing them? (This is not always the reporters fault, by the way, some applications love crashing, drawing things incorrectly etc. for no apparent reason. See e.g. XChat's occasional weird graphical glitches which have been there for years because nobody understands what's happening. These things can frustrate the maintainer at least as much as the reporter.) That's the situation of a lot of packages, and especially the first issue is a major one for KDE. We're doing what we can to fix KDE bugs. In our case, the preferred way to handle things is: * Please file bug reports both at Fedora and KDE, and cross-link them (use the upstream URL feature in our Bugzilla). Once you clicked through the "pick your component" wizard at bugs.kde.org, you can just copy&paste your entire formatted Fedora bug report into their freetext textbox. (Yes, it would be great if we could sync our bugzillas automatically, but unfortunately it's just not there, so someone has to do the copy&paste. It's better if the reporter does it because that way they'll get the bugmail. We know how to CC ourselves where it makes sense, CCing a reporter in a bug we file is harder because we can't know if you have a valid KDE bugzilla account nor if it's under the same e-mail address as the Fedora one.) * We'll try to track the upstream bug report, but pinging us if upstream comes up with a fix can't hurt. * The more urgent the bug, the more likely we are to apply a fix as soon as possible. Otherwise, we'll pick it up automatically once we upgrade to the next bugfix release of KDE. (We aren't pushing those updates just for fun, nor to sadistically break things as we're sometimes accused of.) Kevin Kofler From kevin.kofler at chello.at Sat Jan 19 20:33:58 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 19 Jan 2008 20:33:58 +0000 (UTC) Subject: An interesting read when discussing what to do about our bugs... References: <20080118131620.748606a0@redhat.com> <1200766097.2961.5.camel@sb-home> <200801191512.45321.ben.kreuter@gmail.com> Message-ID: Benjamin Kreuter gmail.com> writes: > Yeah, but that is the reason why bugs are referred upstream. The problem is > when a package maintainer tries to say that the problem is upstream in > situations where the bug is caused by the way the package was compiled, or > some conflicting configuration with another package, etc. Of course, if the maintainer(s) try blaming upstream for something which is actually their fault, that's bad. Unfortunately, it isn't always obvious who's at fault. Kevin Kofler From berrange at redhat.com Sat Jan 19 20:41:07 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Sat, 19 Jan 2008 20:41:07 +0000 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <1200773318.26373.14.camel@rousalka.dyndns.org> References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> <1200773318.26373.14.camel@rousalka.dyndns.org> Message-ID: <20080119204107.GV6349@redhat.com> On Sat, Jan 19, 2008 at 09:08:38PM +0100, Nicolas Mailhot wrote: > Complete disregard for tester efforts seems widespread. Complaining to > reporters they didn't open an issue in the right place is common. So is > ignoring bugs because supposedly they're not complete enough (without > bothering to explain what complete would be). Even more annoying are > maintainers that ask to do a lot of stuff then ignore completely the > result. For all Xen related bugs I always need to get /var/log/xen/xend.log and quite often the guest VM config file. At the same time I often do not have time to deal with a bug immediately. So I will take a quick look at request the info that will likely be required to diagnose the bug. So when I do finally have time to analyse the bug perhaps a month or more later, I will have most of the info neccessary. If I didn't request the data immediately, then the user would probably not still have the neccessary data the weeks/ month later and there'd be no chance to fix it. So I always as for as much information as possible the moment the bug is opened, since that's the time at which the user has it easily available. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From nicolas.mailhot at laposte.net Sat Jan 19 20:43:32 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 19 Jan 2008 21:43:32 +0100 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> <1200773318.26373.14.camel@rousalka.dyndns.org> Message-ID: <1200775412.26373.19.camel@rousalka.dyndns.org> Le samedi 19 janvier 2008 ? 20:31 +0000, Kevin Kofler a ?crit : > Nicolas Mailhot laposte.net> writes: > > Complete disregard for tester efforts seems widespread. Complaining to > > reporters they didn't open an issue in the right place is common. So is > > ignoring bugs because supposedly they're not complete enough (without > > bothering to explain what complete would be). Even more annoying are > > maintainers that ask to do a lot of stuff then ignore completely the > > result. > > I can fully understand your frustration, reporting a bug can be hard sometimes. > However, please also try to understand the maintainer's side. I completely understand maintainers. They reserve their right to be bastards (for very good reasons). So do I (ditto). However it does mean I won't ever suggest newbies to report bugs with good conscience, because most of them are not ready for such a ruthless system. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From opensource at till.name Sat Jan 19 20:48:15 2008 From: opensource at till.name (Till Maas) Date: Sat, 19 Jan 2008 21:48:15 +0100 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <20080119204107.GV6349@redhat.com> References: <20080118131620.748606a0@redhat.com> <1200773318.26373.14.camel@rousalka.dyndns.org> <20080119204107.GV6349@redhat.com> Message-ID: <200801192148.25042.opensource@till.name> On Saturday 19 January 2008 21:41:07 Daniel P. Berrange wrote: > For all Xen related bugs I always need to get /var/log/xen/xend.log > and quite often the guest VM config file. At the same time I often do > not have time to deal with a bug immediately. So I will take a quick > look at request the info that will likely be required to diagnose the > bug. So when I do finally have time to analyse the bug perhaps a month > or more later, I will have most of the info neccessary. If I didn't > request the data immediately, then the user would probably not still > have the neccessary data the weeks/ month later and there'd be no > chance to fix it. So I always as for as much information as possible > the moment the bug is opened, since that's the time at which the user > has it easily available. Maybe the bug reporter feels better, when you explain this in your comment, if you do not do this already. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From frank-buettner at gmx.net Sat Jan 19 21:02:27 2008 From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=) Date: Sat, 19 Jan 2008 22:02:27 +0100 Subject: mock 0.8.9 will not build anything In-Reply-To: <1200752442.6945.3.camel@localhost.localdomain> References: <4790691C.3080605@gmx.net> <1200752442.6945.3.camel@localhost.localdomain> Message-ID: <47926563.1040301@gmx.net> Lubomir Kundrak schrieb: > On Fri, 2008-01-18 at 09:53 +0100, Frank B?ttner wrote: >> Hello, >> >> when I try to build an package mock will fail with: > ... >> 2008-01-18 09:48:01,973 - DEBUG util.py, Line: 234: groupadd: name >> mockbuild is not unique >> 2008-01-18 09:48:01,977 - DEBUG trace_decorator.py, Line: 27: >> EXCEPTION: Command(/usr/sbin/groupadd -g 102 mockbuild) failed. See logs f >> or output. >> >> Any ideas, what goes wrong?? > > Please delete /var/mock/* and try again. In case you won't succeed, > please open a bug report in bugzilla. > > Thanks, The directory /var/mock* don't exist. Do you mean /var/lib/mock* ?? Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5766 bytes Desc: S/MIME Cryptographic Signature URL: From lsof at nodata.co.uk Sat Jan 19 21:17:22 2008 From: lsof at nodata.co.uk (nodata) Date: Sat, 19 Jan 2008 22:17:22 +0100 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> Message-ID: <1200777442.2961.10.camel@sb-home> Am Samstag, den 19.01.2008, 20:05 +0000 schrieb Kevin Kofler: > nodata nodata.co.uk> writes: > > Fedora does a lot better, much better, but probably the most annoying > > aspect of using Fedora's bugzilla is the attitude of some of the > > maintainers (not all) and the "closing, report upstream" attitude. > > > > Closing a bug report with "report it upstream" is a let down. It's > > repetitive boring work that a computer should be doing. > > We're 4 maintainers for all of KDE in Fedora (and that's already 4 times as > many as not too long ago). We get dozens of bug reports, many of which aren't > specific to Fedora in any way. There's no way we can fix them all by ourselves, > the only way to actually get things fixed is to report them to the actual > upstream maintainers of the concrete application you're having issues with. And > I don't think KDE is the only set of packages in this situation. > > Kevin Kofler > Then don't let people report the bugs into the Fedora bugzilla. From jonstanley at gmail.com Sat Jan 19 21:49:31 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Sat, 19 Jan 2008 16:49:31 -0500 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <1200777442.2961.10.camel@sb-home> References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200777442.2961.10.camel@sb-home> Message-ID: On Jan 19, 2008 4:17 PM, nodata wrote: > Then don't let people report the bugs into the Fedora bugzilla. That's not particularly an option, either, since there could be distro specific or packaging bugs that the 4 maintainers did introduce. In this case, I think that the best thing to do is to inform the triage community (wouldn't be me for KDE since I don't know anything about it) that the maintainers do not accept bugs which could be reported upstream, and that the triagers should go ahead and report them upstream. Leads to good results for all people - the users that get some sort of a response, and the maintainers who don't have to worry about non-packaging bugs. This is what a good triage team is meant to do - serve as a bridge between the end-user community and the community of maintainers for a given set of packages. From tromey at redhat.com Sat Jan 19 21:16:42 2008 From: tromey at redhat.com (Tom Tromey) Date: Sat, 19 Jan 2008 14:16:42 -0700 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: (Kevin Kofler's message of "Sat\, 19 Jan 2008 20\:05\:36 +0000 \(UTC\)") References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> Message-ID: >>>>> "Kevin" == Kevin Kofler writes: >> Closing a bug report with "report it upstream" is a let down. It's >> repetitive boring work that a computer should be doing. Kevin> There's no way we can fix them all by ourselves, the only way Kevin> to actually get things fixed is to report them to the actual Kevin> upstream maintainers of the concrete application you're having Kevin> issues with. And I don't think KDE is the only set of packages Kevin> in this situation. What would be good here is an easy way to push a report upstream. This would solve the Fedora maintainer's problem ("this is not our bug") without requiring extra work from the bug reporter (who is probably lazy like me, and anyway isn't in as good a position to triage a report as the Fedora maintainer). Tom From s0238762 at sms.ed.ac.uk Sat Jan 19 22:23:34 2008 From: s0238762 at sms.ed.ac.uk (Ioannis Nousias) Date: Sat, 19 Jan 2008 22:23:34 +0000 Subject: i386 popt static library in x86-64 In-Reply-To: <47921A1D.5050409@gmail.com> References: <4792088B.6050504@sms.ed.ac.uk> <479212C1.5050708@gmail.com> <479215BA.50005@sms.ed.ac.uk> <47921A1D.5050409@gmail.com> Message-ID: <47927866.9040204@sms.ed.ac.uk> Andrew Farris wrote: > Ioannis Nousias wrote: >> Andrew Farris wrote: >>> Ioannis Nousias wrote: >>>> Hi, >>>> >>>> The popt-static.i386 is missing from the x86-64 repositories and it >>>> seems I can't install it from the i386 ones, since it now conflicts >>>> with the x86-64 (I could before, but now something has changed). I >>>> need both the popt-static.x86_64 and the popt-static.i386 in my >>>> system. Any suggestions ? >>>> >>>> regards >>>> -Ioannis >>>> >>> >>> rawhide/f8/f7 ? >>> >>> http://koji.fedoraproject.org/koji/packageinfo?packageID=4924 There >>> seem to be built popt-static packages in koji right now, ymmv >>> >> Yes, forgot to mention I'm using F8. Thanks. Installing this >> http://koji.fedoraproject.org/packages/popt/1.13/1.fc8/i386/popt-static-1.13-1.fc8.i386.rpm >> >> worked. >> > > Ok, it seems 1.13-1 was pushed to F8 updates, and it is present on > this mirror: > http://mirror.lib.ucdavis.edu/fedora/linux/updates/8/i386/ > > and the x86_64 version is as well, but you're right there is no i386 > popt-static here, although there are i386 versions for the other popt > packages. > http://mirror.lib.ucdavis.edu/fedora/linux/updates/8/x86_64/ > > I wonder if that failed to build and didn't get caught or was that > intentional for the general user? > although my experience might not be sufficient 'verification', the above package works well here. For all I know, there is no reason why this package shouldn't be included in the x86-64 repo, especially since the rest i386 popt package are (as you mentioned). From markg85 at gmail.com Sat Jan 19 22:28:18 2008 From: markg85 at gmail.com (Mark) Date: Sat, 19 Jan 2008 23:28:18 +0100 Subject: Opinion: Preferred Applications & Removable Drives and Media Message-ID: <6e24a8e80801191428m45ecd472w788c4a88055f0455@mail.gmail.com> Hey, I would like to know the developers opinion about the double preferred applications. You have: "Preferred Applications" which does: - Internet - - Web Browser - - Mail Client - Multimedia - - Multimedia Player - System - - Terminal Emulator - Accessibility - - Visual - - Mobility And you have: "Removable Drives and Media" which does: - Storage - - Rem. Storage - - Blanc CD and DVD - Multimedia - - Audio CD discs - - Video DVD discs - - Portable Music players - Cameras O well.. you get the point till here. Now what i mean is that those 2 programs each manage there own preferred applications which is really confusion. I just spend a few hours to find out where to change the Autoplay for DVD's (and i'm close to a advanced linux/fedora user) which was set at totem and i wanted to have mplayer. My idea would be to drop the 2 existing applications completely and create 1 new application to handle the preferred applications for all programs (internet) and hardware (video dvd). The advantages --------------------- - One place for all preferred applications - Preferred apps can be found where they are expected - way more user friendly (that's what fedora wants right?) And i'm sure there are a lot more The disadvantages ------------------------ - A new application has to be made so time (and perhaps money) has to be put into this So.. what are your thoughts about this one? I'm probably gonna fill in a feature request on gnome's bugzilla but some feedback about this one would be nice. Mark From rdieter at math.unl.edu Sat Jan 19 22:28:57 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 19 Jan 2008 16:28:57 -0600 Subject: An interesting read when discussing what to do about our bugs... References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200777442.2961.10.camel@sb-home> Message-ID: Jon Stanley wrote: > On Jan 19, 2008 4:17 PM, nodata wrote: > >> Then don't let people report the bugs into the Fedora bugzilla. > > That's not particularly an option, either, since there could be distro > specific or packaging bugs that the 4 maintainers did introduce. +1 > > In > this case, I think that the best thing to do is to inform the triage > community (wouldn't be me for KDE since I don't know anything about > it) that the maintainers do not accept bugs which could be reported > upstream, and that the triagers should go ahead and report them > upstream. Leads to good results for all people - the users that get > some sort of a response, and the maintainers who don't have to worry > about non-packaging bugs. Yes and no, sometimes bugs cannot be reproduced by anyone other than the reporter. What then? Besides, encouraging users to work with upstream aligns well with fedora's values, which I consider to be a "good thing"(tm). -- Rex p.s. I *like* to see feedback that stuff has been upstreamed, and usually make sure I'm Cc'd there too, to track progress, etc.. From mcepl at redhat.com Sat Jan 19 22:19:56 2008 From: mcepl at redhat.com (Matej Cepl) Date: Sat, 19 Jan 2008 23:19:56 +0100 Subject: An interesting read when discussing what to do about our bugs... References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> Message-ID: On 2008-01-19, 18:10 GMT, seth vidal wrote: > Hmm, is that what the 'upstream' close reason is for? Normally, > I close things 'upstream' when I have checked a fix into the > upstream code base. Which seems pretty reasonable time to close > it to me. OK, this is something which should be well described in the http://fedoraproject.org/wiki/JonStanley/BugWorkflow (Jon?). Closing upstream is from the maintainer's point of view pretty difficult thing to do. First rule, which I try to always hold with Xorg bugs is that the bug should *NEVER* be closed as UPSTREAM unless I have number of the upstream bug in the External Bugzilla References (or in the comment, if the upstream bugzilla is not available among external bugzilla references; fortunately, that doesn't happen for the bugs I triage). So, even if I ask reporter to file the bug upstream (and I do it less and less), I put them in NEEDINFO, and close the bug as UPSTREAM only when they come bug with the number of the upstream bug. I totally understand the reasons why we ask reporters to file the bug, and why it is problematic to file a bug ourselves (after all, it is THEIR bug, they can reproduce it, test the fix, provide additional information, etc.), but still I do it less and less. Now I usually try to find a duplicate bug in the upstream bugzilla (trip into Mozilla bugzilla always cheers me up -- if our bugzilla is mess, and it is, I have no words to describe their bugzilla ;-)), and suggest to the reporter to comment on it and join the happy crowd around that bug in the upstream bugzilla. The reason is that asking them to file a bug upstream (internally called "a request for suicide") is very bad from the marketing point of view. I feel that we should treat the bug reporters as our most valuable asset (which they are), and to be very careful not to alieante them. If there is a person, who is willing to file a reasonably thought-through bug to our bugzilla, it is a person, which is extremely valuable to us (because that's the only QA we have in Fedora, and because open-source software is bug driven). However, I don't think it is necessary to close bug upstream only when I have actually fixed it (unless you are a primary developer of the particular component, as seth is). Whole point of upstreaming bugs (and you can read it in https://bugzilla.redhat.com/page.cgi?id=fields.html#upstream which is actually pretty good resource to read) is that everybody from all distributions can join their efforts about fixing the bug, so the issue doesn't have to be fixed multiple times in each distro independently. It is always a good idea to write something in such sense to the comment by which you either ask reporter to file a bug upstream, or by the one by which you close the bug. Just my 0.02 CZK ;-) Mat?j From mcepl at redhat.com Sat Jan 19 22:25:18 2008 From: mcepl at redhat.com (Matej Cepl) Date: Sat, 19 Jan 2008 23:25:18 +0100 Subject: An interesting read when discussing what to do about our bugs... References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> <1200766980.2961.8.camel@sb-home> <479242D1.8050800@hhs.nl> <20080119183914.GJ6349@redhat.com> <479245A4.1080904@hhs.nl> Message-ID: On 2008-01-19, 18:47 GMT, Hans de Goede wrote: > I would expect Fedora BZ to send out mails to those CC-ed on > the Fedora bug when something happens in the upstream linked > bug, maybe even add a comment when the upstream bug changes, > but it does none of the above, so I wonder what is the added > value of using the BZ link feature instead of just putting an > url to upstream's ticket in a comment? I am not sure, whether this bug https://bugzilla.redhat.com/show_bug.cgi?id=189813 is a good candidate for comment, or whether you should file a new bug, but I would love to Cc: on that. Mat?j From lordmorgul at gmail.com Sat Jan 19 23:11:16 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sat, 19 Jan 2008 15:11:16 -0800 Subject: Opinion: Preferred Applications & Removable Drives and Media In-Reply-To: <6e24a8e80801191428m45ecd472w788c4a88055f0455@mail.gmail.com> References: <6e24a8e80801191428m45ecd472w788c4a88055f0455@mail.gmail.com> Message-ID: <47928394.2010903@gmail.com> Mark wrote: > Hey, > > I would like to know the developers opinion about the double preferred > applications. > > You have: > "Preferred Applications" which does: > - Internet > - - Web Browser > - - Mail Client > - Multimedia > - - Multimedia Player > - System > - - Terminal Emulator > - Accessibility > - - Visual > - - Mobility > > And you have: > "Removable Drives and Media" which does: > - Storage > - - Rem. Storage > - - Blanc CD and DVD > - Multimedia > - - Audio CD discs > - - Video DVD discs > - - Portable Music players > - Cameras > O well.. you get the point till here. > > Now what i mean is that those 2 programs each manage there own > preferred applications which is really confusion. I just spend a few > hours to find out where to change the Autoplay for DVD's (and i'm > close to a advanced linux/fedora user) which was set at totem and i > wanted to have mplayer. > > My idea would be to drop the 2 existing applications completely and > create 1 new application to handle the preferred applications for all > programs (internet) and hardware (video dvd). > > The advantages > --------------------- > - One place for all preferred applications > - Preferred apps can be found where they are expected > - way more user friendly (that's what fedora wants right?) > And i'm sure there are a lot more IMO it would be better to keep the two applications, and simply move the choice of DVD player to Preferred Applications (where it really belongs). The removable media app would still decide *what to do* when the DVD is installed, i.e. play it or not, the preferred applications would decide what player to use. The configurable 'autoplay' type behavior for removable media is not intuitively a 'preferred applications' issue, so combining those becomes almost as non-obvious as the current situation. So the same change needs to be made for CDs, Cameras, etc, to separate what to do from what application will do it. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From mclasen at redhat.com Sat Jan 19 23:38:32 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Sat, 19 Jan 2008 18:38:32 -0500 Subject: Opinion: Preferred Applications & Removable Drives and Media In-Reply-To: <6e24a8e80801191428m45ecd472w788c4a88055f0455@mail.gmail.com> References: <6e24a8e80801191428m45ecd472w788c4a88055f0455@mail.gmail.com> Message-ID: <1200785912.2924.14.camel@localhost.localdomain> On Sat, 2008-01-19 at 23:28 +0100, Mark wrote: > My idea would be to drop the 2 existing applications completely and > create 1 new application to handle the preferred applications for all > programs (internet) and hardware (video dvd). gnome-volume-manager has long been on the desktop teams list of things to kill and redo in a better way. It started out as a way to configure what happens when removable media gets inserted, and then it grew more and more unrelated tabs, which largely ask you to enter commandlines that get executed at certain times, some of them pretty nonsensical. Who needs to run something when a mouse is plugged in ?! Instead, the mouse should just work... If you check out recent rawhide you will notice that we have finally made some progress towards killing g-v-m: the configuration for automounting/autorunning removable media has moved to nautilus (see the Media tab in nautilus-file-management-properties). I hope that David will soon post some more about the really cool stuff he has been doing there together with Alex. The remaining tabs in g-v-m will hopefully become more and more unnecessary over time. A good example is our printing system, which notices new printers and does the right thing without a manually entered command. Matthias From marc at mwiriadi.id.au Sat Jan 19 23:56:56 2008 From: marc at mwiriadi.id.au (Marc Wiriadisastra) Date: Sun, 20 Jan 2008 08:56:56 +0900 Subject: rawhide report: 20080118 changes In-Reply-To: References: <200801191711.m0JHBcSi017061@porkchop.devel.redhat.com> Message-ID: <1200787016.26735.0.camel@localhost.localdomain> On Sat, 2008-01-19 at 18:49 +0100, Linus Walleij wrote: > On Sat, 19 Jan 2008, Build System wrote: > > > New package preload > > Preload is an adaptive readahead daemon > > Heey, we talk around this things incarnation over at Novell and it turns > out we have a thing boiling in BZ since october. > > The sheer size of the Fedora community makes it possible to miss such > things, and that's good news! Now, some preload-testing. > > Linus > It was created by Behdad and surprisingly has been highly recommended in Ubuntu/Debian for awhile. Surprisingly that it didn't get into Fedora till now. Marc From lordmorgul at gmail.com Sun Jan 20 00:28:15 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sat, 19 Jan 2008 16:28:15 -0800 Subject: rawhide report: 20080118 changes In-Reply-To: <1200787016.26735.0.camel@localhost.localdomain> References: <200801191711.m0JHBcSi017061@porkchop.devel.redhat.com> <1200787016.26735.0.camel@localhost.localdomain> Message-ID: <4792959F.1060308@gmail.com> Marc Wiriadisastra wrote: > On Sat, 2008-01-19 at 18:49 +0100, Linus Walleij wrote: >> On Sat, 19 Jan 2008, Build System wrote: >> >>> New package preload >>> Preload is an adaptive readahead daemon >> Heey, we talk around this things incarnation over at Novell and it turns >> out we have a thing boiling in BZ since october. >> >> The sheer size of the Fedora community makes it possible to miss such >> things, and that's good news! Now, some preload-testing. >> >> Linus >> > > It was created by Behdad and surprisingly has been highly recommended in > Ubuntu/Debian for awhile. Surprisingly that it didn't get into Fedora > till now. There was a prior work called simply 'readahead' which was in Fedora and removed due to making almost no real difference. Hopefully the newer incarnation is effective. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From jonstanley at gmail.com Sun Jan 20 00:56:58 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Sat, 19 Jan 2008 19:56:58 -0500 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> Message-ID: On Jan 19, 2008 5:19 PM, Matej Cepl wrote: > OK, this is something which should be well described in the > http://fedoraproject.org/wiki/JonStanley/BugWorkflow (Jon?). I've added some stuff, instead of the novel here, I've put the Cliff's Notes version in :). Let me know if I got something wrong. From denis at poolshark.org Sun Jan 20 01:22:38 2008 From: denis at poolshark.org (Denis Leroy) Date: Sun, 20 Jan 2008 02:22:38 +0100 Subject: Experiment: an RPM that shows uninstalled apps in main menu Message-ID: <4792A25E.5020301@poolshark.org> This is an idea I've had about a year ago and gave some thought on and off since then, but Richard Hughes has mentioned a similar idea several times on this list as well. The idea is to show the (large number of) applications available to Fedora users through yum, but instead of a linear list displayed in pirut for example, show them directly in the main menu: that way the available apps are already categorized in a familiar way, and you can see the application icons and short descriptions through the menu tooltip. For kicks and giggles, I hacked up a proof-of-concept RPM here for F-8 : http://www.poolshark.org/src/fedora-apps-0.1-1.fc8.i386.rpm After installation, you'll have to restart the gnome-panel with a quick 'killall gnome-panel'. The rpm is 5 MB, which is not bad for almost 1000 apps (remember we're only talking about GUI apps here, i.e. apps that install a desktop file). Screenshots: http://www.poolshark.org/apps1.png The RPM comes with a 'fedora-apps-update' binary that updates the symlinks based on the apps already installed (so that an installed application doesn't show up on the uninstalled list). What command should this menu entries run ? i was hoping there would be a simple 'pirut --install foo' or 'pup --install foo' option, but apparently there isn't. Comments ? -denis From ivazqueznet at gmail.com Sun Jan 20 01:47:12 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sat, 19 Jan 2008 20:47:12 -0500 Subject: Experiment: an RPM that shows uninstalled apps in main menu In-Reply-To: <4792A25E.5020301@poolshark.org> References: <4792A25E.5020301@poolshark.org> Message-ID: <1200793632.27867.1.camel@ignacio.lan> On Sun, 2008-01-20 at 02:22 +0100, Denis Leroy wrote: > What command should this menu entries run ? i was hoping there would be > a simple 'pirut --install foo' or 'pup --install foo' option, but > apparently there isn't. system-install-packages is the command you're looking for. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed From lordmorgul at gmail.com Sun Jan 20 02:04:17 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sat, 19 Jan 2008 18:04:17 -0800 Subject: Experiment: an RPM that shows uninstalled apps in main menu In-Reply-To: <4792A25E.5020301@poolshark.org> References: <4792A25E.5020301@poolshark.org> Message-ID: <4792AC21.3060806@gmail.com> Denis Leroy wrote: > This is an idea I've had about a year ago and gave some thought on and > off since then, but Richard Hughes has mentioned a similar idea several > times on this list as well. > > The idea is to show the (large number of) applications available to > Fedora users through yum, but instead of a linear list displayed in > pirut for example, show them directly in the main menu: that way the > available apps are already categorized in a familiar way, and you can > see the application icons and short descriptions through the menu tooltip. > > For kicks and giggles, I hacked up a proof-of-concept RPM here for F-8 : > > http://www.poolshark.org/src/fedora-apps-0.1-1.fc8.i386.rpm > > After installation, you'll have to restart the gnome-panel with a quick > 'killall gnome-panel'. The rpm is 5 MB, which is not bad for almost 1000 > apps (remember we're only talking about GUI apps here, i.e. apps that > install a desktop file). > > Screenshots: > > http://www.poolshark.org/apps1.png > > The RPM comes with a 'fedora-apps-update' binary that updates the > symlinks based on the apps already installed (so that an installed > application doesn't show up on the uninstalled list). > > What command should this menu entries run ? i was hoping there would be > a simple 'pirut --install foo' or 'pup --install foo' option, but > apparently there isn't. > > Comments ? > > -denis > Given that this rpm would already be carrying the entire list of available software in official repos, their .desktop files, executable names, and information about which package contains them... I wonder if it would be feasible to start developing support for command line 'yum install foo' suggestions to users (ala apt on debian/ubuntu systems). For instance, user knows (from a friend or random webpage) that the program foo is neat, and tries to start it: > foo > Command not found: foo > This program is available for Fedora but is not currently installed. > To install this program type (as root): yum install FooPackage While the menu offering would be nice for many users who are very new, it is going to also be alot of clutter, the suggestion of what package to install could be helpful as well for cli. (I am aware yum search will tell the user which package might have the file, but its not anywhere near as intelligible to a new user as what apt provides for this) -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From denis at poolshark.org Sun Jan 20 02:20:21 2008 From: denis at poolshark.org (Denis Leroy) Date: Sun, 20 Jan 2008 03:20:21 +0100 Subject: Experiment: an RPM that shows uninstalled apps in main menu In-Reply-To: <1200793632.27867.1.camel@ignacio.lan> References: <4792A25E.5020301@poolshark.org> <1200793632.27867.1.camel@ignacio.lan> Message-ID: <4792AFE5.7000309@poolshark.org> Ignacio Vazquez-Abrams wrote: > On Sun, 2008-01-20 at 02:22 +0100, Denis Leroy wrote: >> What command should this menu entries run ? i was hoping there would be >> a simple 'pirut --install foo' or 'pup --install foo' option, but >> apparently there isn't. > > system-install-packages is the command you're looking for. Ah great thanks. Fixed. From notting at redhat.com Sun Jan 20 03:38:14 2008 From: notting at redhat.com (Bill Nottingham) Date: Sat, 19 Jan 2008 22:38:14 -0500 Subject: i386 popt static library in x86-64 In-Reply-To: <47927866.9040204@sms.ed.ac.uk> References: <4792088B.6050504@sms.ed.ac.uk> <479212C1.5050708@gmail.com> <479215BA.50005@sms.ed.ac.uk> <47921A1D.5050409@gmail.com> <47927866.9040204@sms.ed.ac.uk> Message-ID: <20080120033814.GA31518@nostromo.devel.redhat.com> Ioannis Nousias (s0238762 at sms.ed.ac.uk) said: > although my experience might not be sufficient 'verification', the above > package works well here. For all I know, there is no reason why this > package shouldn't be included in the x86-64 repo, especially since the rest > i386 popt package are (as you mentioned). Criteria is -devel and runtime packages and their deps. -static would rarely fit into this category. Bill From pemboa at gmail.com Sun Jan 20 04:46:33 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Sat, 19 Jan 2008 22:46:33 -0600 Subject: Experiment: an RPM that shows uninstalled apps in main menu In-Reply-To: <4792A25E.5020301@poolshark.org> References: <4792A25E.5020301@poolshark.org> Message-ID: <16de708d0801192046j102eb7d7sf64059e784b9bef3@mail.gmail.com> On Jan 19, 2008 7:22 PM, Denis Leroy wrote: > This is an idea I've had about a year ago and gave some thought on and > off since then, but Richard Hughes has mentioned a similar idea several > times on this list as well. > > The idea is to show the (large number of) applications available to > Fedora users through yum, but instead of a linear list displayed in > pirut for example, show them directly in the main menu: that way the > available apps are already categorized in a familiar way, and you can > see the application icons and short descriptions through the menu tooltip. > > For kicks and giggles, I hacked up a proof-of-concept RPM here for F-8 : > > http://www.poolshark.org/src/fedora-apps-0.1-1.fc8.i386.rpm > > After installation, you'll have to restart the gnome-panel with a quick > 'killall gnome-panel'. The rpm is 5 MB, which is not bad for almost 1000 > apps (remember we're only talking about GUI apps here, i.e. apps that > install a desktop file). > > Screenshots: > > http://www.poolshark.org/apps1.png > > The RPM comes with a 'fedora-apps-update' binary that updates the > symlinks based on the apps already installed (so that an installed > application doesn't show up on the uninstalled list). > > What command should this menu entries run ? i was hoping there would be > a simple 'pirut --install foo' or 'pup --install foo' option, but > apparently there isn't. > > Comments ? > > -denis While I don't think it should be exactly how you have it, an 'Uninstalled' submenu in every category, seems like a great idea to me. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From jspaleta at gmail.com Sun Jan 20 05:36:52 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 19 Jan 2008 20:36:52 -0900 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <1200766980.2961.8.camel@sb-home> References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> <1200766980.2961.8.camel@sb-home> Message-ID: <604aa7910801192136u754e6a4ex1c3c0113440c4e02@mail.gmail.com> On Jan 19, 2008 9:23 AM, nodata wrote: > I'm talking about closing the bug and telling the reporter to report > upstream, i.e. "go away". As a package maintainer, what would you like me to do in situations where I need the reporter to talk to upstream? Should I just pat you on the head and promise to fix it, even though I can't? If I can't even reproduce the problem with my hardware, or its a feature request that needs to be discussed as part of an upstream development what exactly are the better choices than encouraging you to take your case to upstream? -jef"I'm no Seth"spaleta From jspaleta at gmail.com Sun Jan 20 05:42:49 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 19 Jan 2008 20:42:49 -0900 Subject: Experiment: an RPM that shows uninstalled apps in main menu In-Reply-To: <16de708d0801192046j102eb7d7sf64059e784b9bef3@mail.gmail.com> References: <4792A25E.5020301@poolshark.org> <16de708d0801192046j102eb7d7sf64059e784b9bef3@mail.gmail.com> Message-ID: <604aa7910801192142y5266c0dfh2e82a91246483f69@mail.gmail.com> On Jan 19, 2008 7:46 PM, Arthur Pemberton wrote: > While I don't think it should be exactly how you have it, an > 'Uninstalled' submenu in every category, seems like a great idea to > me. Until someone decides to manually re-arrange the listings on the system using a menu editor :-> -jef From pemboa at gmail.com Sun Jan 20 05:56:21 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Sat, 19 Jan 2008 23:56:21 -0600 Subject: Experiment: an RPM that shows uninstalled apps in main menu In-Reply-To: <604aa7910801192142y5266c0dfh2e82a91246483f69@mail.gmail.com> References: <4792A25E.5020301@poolshark.org> <16de708d0801192046j102eb7d7sf64059e784b9bef3@mail.gmail.com> <604aa7910801192142y5266c0dfh2e82a91246483f69@mail.gmail.com> Message-ID: <16de708d0801192156w2fa69e76v7014057effe8aac4@mail.gmail.com> On Jan 19, 2008 11:42 PM, Jeff Spaleta wrote: > On Jan 19, 2008 7:46 PM, Arthur Pemberton wrote: > > While I don't think it should be exactly how you have it, an > > 'Uninstalled' submenu in every category, seems like a great idea to > > me. > > Until someone decides to manually re-arrange the listings on the > system using a menu editor :-> > > -jef > I personally think this should be a first level menu myself. An immutable one at that. And install of 'uninstalled' might want to say 'available' -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From michel.sylvan at gmail.com Sun Jan 20 06:41:51 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Sun, 20 Jan 2008 01:41:51 -0500 Subject: Cast your vote for the Fedora 9 Codename! In-Reply-To: <20080118105054.354c12e5@zod.rchland.ibm.com> References: <20080116184835.1bddf0f3@zod.rchland.ibm.com> <1200536182.920.64.camel@calliope.phig.org> <200801171318.m0HDGRqx011867@laptop13.inf.utfsm.cl> <1200591438.920.119.camel@calliope.phig.org> <80d7e4090801171805t3abb9651ie8ff1390267c51e@mail.gmail.com> <20080118022457.GA1991@nostromo.devel.redhat.com> <1200664543.10767.119.camel@localhost.localdomain> <20080118105054.354c12e5@zod.rchland.ibm.com> Message-ID: On Jan 18, 2008 11:50 AM, Josh Boyer wrote: > On Fri, 18 Jan 2008 08:55:43 -0500 > Simo Sorce wrote: > > > > > On Thu, 2008-01-17 at 21:24 -0500, Bill Nottingham wrote: > > > Stephen John Smoogen (smooge at gmail.com) said: > > > > Is campaigning for a name legal? > > > > > > I don't know. It probably depends on how the Campaign For the Chupacabra > > > Of the Future gets its funding. > > > > Aww what happened to my beloved Anubis (not on the list :/) ? > > It was pruned by legal. As were many other names. > And they did not prune Asperger and Tourette? Not sure that's the kind of image we want to project. -- Michel Salim http://hircus.jaiku.com/ From david at lovesunix.net Sun Jan 20 07:05:48 2008 From: david at lovesunix.net (David Nielsen) Date: Sun, 20 Jan 2008 08:05:48 +0100 Subject: Cast your vote for the Fedora 9 Codename! In-Reply-To: References: <20080116184835.1bddf0f3@zod.rchland.ibm.com> <1200536182.920.64.camel@calliope.phig.org> <200801171318.m0HDGRqx011867@laptop13.inf.utfsm.cl> <1200591438.920.119.camel@calliope.phig.org> <80d7e4090801171805t3abb9651ie8ff1390267c51e@mail.gmail.com> <20080118022457.GA1991@nostromo.devel.redhat.com> <1200664543.10767.119.camel@localhost.localdomain> <20080118105054.354c12e5@zod.rchland.ibm.com> Message-ID: <1200812748.4153.9.camel@localhost.localdomain> s?n, 20 01 2008 kl. 01:41 -0500, skrev Michel Salim: > On Jan 18, 2008 11:50 AM, Josh Boyer wrote: > > On Fri, 18 Jan 2008 08:55:43 -0500 > > Simo Sorce wrote: > > > > > > > > On Thu, 2008-01-17 at 21:24 -0500, Bill Nottingham wrote: > > > > Stephen John Smoogen (smooge at gmail.com) said: > > > > > Is campaigning for a name legal? > > > > > > > > I don't know. It probably depends on how the Campaign For the Chupacabra > > > > Of the Future gets its funding. > > > > > > Aww what happened to my beloved Anubis (not on the list :/) ? > > > > It was pruned by legal. As were many other names. > > > And they did not prune Asperger and Tourette? Not sure that's the kind > of image we want to project. Their concern is merely the legality, they are not taste judges. I personally suffer from Tourette's but the main issue I could see out be reviewers taking the piss out of the name instead of actually reviewing Fedora. - David Nielsen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From lordmorgul at gmail.com Sun Jan 20 08:05:41 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sun, 20 Jan 2008 00:05:41 -0800 Subject: Experiment: an RPM that shows uninstalled apps in main menu In-Reply-To: <16de708d0801192156w2fa69e76v7014057effe8aac4@mail.gmail.com> References: <4792A25E.5020301@poolshark.org> <16de708d0801192046j102eb7d7sf64059e784b9bef3@mail.gmail.com> <604aa7910801192142y5266c0dfh2e82a91246483f69@mail.gmail.com> <16de708d0801192156w2fa69e76v7014057effe8aac4@mail.gmail.com> Message-ID: <479300D5.5020208@gmail.com> Arthur Pemberton wrote: > On Jan 19, 2008 11:42 PM, Jeff Spaleta wrote: >> On Jan 19, 2008 7:46 PM, Arthur Pemberton wrote: >>> While I don't think it should be exactly how you have it, an >>> 'Uninstalled' submenu in every category, seems like a great idea to >>> me. >> Until someone decides to manually re-arrange the listings on the >> system using a menu editor :-> >> >> -jef >> > > > I personally think this should be a first level menu myself. An > immutable one at that. And install of 'uninstalled' might want to say > 'available' Immutable, and first level seems reasonable. The title is debatable, since 'available' has multiple meanings, and the software is not available to the person who wants to use it when they click on the menu... its acquirable, its not yet installed, its offered, but not yet available. If something like 'Repository Software' was used, that would be clear (but not very 'sophisticated'). -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From lsof at nodata.co.uk Sun Jan 20 10:39:42 2008 From: lsof at nodata.co.uk (nodata) Date: Sun, 20 Jan 2008 11:39:42 +0100 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <604aa7910801192136u754e6a4ex1c3c0113440c4e02@mail.gmail.com> References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> <1200766980.2961.8.camel@sb-home> <604aa7910801192136u754e6a4ex1c3c0113440c4e02@mail.gmail.com> Message-ID: <1200825582.2879.0.camel@sb-home> Am Samstag, den 19.01.2008, 20:36 -0900 schrieb Jeff Spaleta: > On Jan 19, 2008 9:23 AM, nodata wrote: > > I'm talking about closing the bug and telling the reporter to report > > upstream, i.e. "go away". > > > As a package maintainer, what would you like me to do in situations > where I need the reporter to talk to upstream? Should I just pat you > on the head and promise to fix it, even though I can't? If I can't > even reproduce the problem with my hardware, or its a feature request > that needs to be discussed as part of an upstream development what > exactly are the better choices than encouraging you to take your case > to upstream? > > -jef"I'm no Seth"spaleta > I'd like you to click the "transfer to upstream bugzilla" button :) From lkundrak at redhat.com Sun Jan 20 10:42:14 2008 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Sun, 20 Jan 2008 11:42:14 +0100 Subject: Experiment: an RPM that shows uninstalled apps in main menu In-Reply-To: <4792A25E.5020301@poolshark.org> References: <4792A25E.5020301@poolshark.org> Message-ID: <1200825734.6945.10.camel@localhost.localdomain> On Sun, 2008-01-20 at 02:22 +0100, Denis Leroy wrote: > This is an idea I've had about a year ago and gave some thought on and > off since then, but Richard Hughes has mentioned a similar idea several > times on this list as well. > > The idea is to show the (large number of) applications available to > Fedora users through yum, but instead of a linear list displayed in > pirut for example, show them directly in the main menu: that way the > available apps are already categorized in a familiar way, and you can > see the application icons and short descriptions through the menu tooltip. This just sounds like an awesome idea to me. I wonder how tightly could that be integrated into Gnome and the desktop file specification. It would be kind of elegant if the .desktop file contained a boolean stating if the application is installed. Then the gnome menu would contain something that would resemble the thing that expands personalized menus in Windows except for that it would unhide the uninstalled applications. And this could be turned off, of course :) In KDE4, the Search capability of the menu could be enough for user not to get lost in not-installed applications. -- Lubomir Kundrak (Red Hat Security Response Team) From fedora at leemhuis.info Sun Jan 20 10:54:27 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 20 Jan 2008 11:54:27 +0100 Subject: EPEL report week 03/2008 Message-ID: <47932863.1080809@leemhuis.info> http://fedoraproject.org/wiki/EPEL/Reports/Week03 = Weekly EPEL Summary = Week 03/2008 == Most important happenings == * about 170 packages were moved from EPEL4 testing to EPEL4 proper in the last monthly move; for details see [https://www.redhat.com/archives/epel-devel-list/2008-January/msg00093.html announcement] and [https://www.redhat.com/archives/epel-devel-list/2008-January/msg00109.html Build report]; next move for EPEL5 planed for early February * reminder: Fedora contributers that want to build for EPEL but don't have a RHEL/CentOS box/VM for testing: feel free to ask on the [https://www.redhat.com/mailman/listinfo/epel-devel-list epel-devel-list] for help or contact someone from the [http://fedoraproject.org/wiki/EPEL/SIG EPEL SIG] * second reminder: if you want to build you package in EPEL but can't because a package your package depends on is not available in EPEL then just add it to the [http://fedoraproject.org/wiki/EPEL/WishList EPEL wishlist]; someone (normally [:ThorstenLeemhuis:knurd]) will send a mail to the package owner then asking branch the package in question for EPEL. You can of course send a mail to the owner of the package in question directly as well; see http://fedoraproject.org/wiki/EPEL/AskForFedoraPackageInEPEL for details Note that not all Fedora contributers participate in EPEL and those "please branch for EPEL" mails often get ignored7fall of the table. In those cases you are free to claim ownership of the package you need yourself (just CC the Fedora owner in the bugzilla branch request to make sure he's aware of the fact that the package is in EPEL). For details see "EPEL branching if Fedora maintainer does not react" on http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies == Mailing list == === Noteworthy discussions === * [https://www.redhat.com/archives/epel-devel-list/2008-January/msg00094.html Zenoss Core for EPEL] == Meeting == === Next Meeting === Wednesday, 20080130 at 18:00 UTC in #fedora-meeting. === Last weeks meeting === Attendees: * [:RobMyers:_blah_] * [:Jonathan Steffan:daMaestro] * [:JesseKeating:f13] * [:JeffSheltren:Jeff_S] * [:ThorstenLeemhuis:knurd] * [:KevinFenzi:nirik] * [:KarstenWade:quaid] Summary: * next testing -> stable move | knurd | http://fedoraproject.org/wiki/EPEL/Tasks/NextTestingStableMove * being worked on (and realized already when this got published; see above) * knurd will write down how to actually prepare the move (happened in between as well; see http://fedoraproject.org/wiki/EPEL/Tasks/NextTestingStableMove) * EL-updates to the buildsys | mmcgrath | http://fedoraproject.org/wiki/EPEL/Tasks/Misc * skvidal made that happen * KojiAndBodhiForEpel | mmcgrath | http://fedoraproject.org/wiki/EPEL/Tasks/KojiAndBodhiForEpel * some progress; f13 reviewed an initial patch from _blah_; more work from _blah_ to come * permission to use spec files in other projects | http://fedoraproject.org/wiki/EPEL/Tasks/Misc * seems to be solved finally thx to spot; see http://fedoraproject.org/wiki/Licensing#LicenseOfFedoraSPECFiles * broken dep reports go to the list | http://fedoraproject.org/wiki/EPEL/Tasks/Misc * more discussion on the list * Free discussion around EPEL -- FUDCOn and EPEL? * there was no EPEL session on FUDCOn * f13> | I talked to the zenoss guy there, whom I've talked with before. He wasn't actually aware of EPEL and will be directing his folks to get ZenOSS packages ready for EPEL * Free discussion around EPEL -- get more contributers for EPEL * nirik> | I was thinking we should do a monthly or so email to the fedora-devel list asking people to consider branching for epel... I think many of the new maintainers aren't aware it exists... * knurd> | nirik, maybe we should mail the contributers directly that don't have a single EPEL package * some Fedora contributers might be willing to build for EPEL, but don't have a RHEL/CentOS box for testing; it was discussed if we need a group of people that can help in such situations; it was agreed that the EPEL SIG is that group * some more discussion around this; see 00:11:09 and later; * Free discussion around EPEL -- broken deps * nirk will try to file bugs for those broken deps that are around for more than just a few days * Free discussion around EPEL * nirik> | note that there are 26 open epel bugs... most of them are the broken deps stuff... a few others tho * clamav status: silug has agreed to maintain the fedora clamav in epel. == Stats == === General === Number of EPEL Contributors: 166 We welcome 1 new contributors: gospo === EPEL 5 === Number of source packages: 991 Number of binary packages: 1841 There are 13 new Packages: * ack | Grep-like text finder * bwm-ng | Bandwidth Monitor NG * jigdo | Ease distribution of large files over the Internet * libgdiplus | libgdiplus: An Open Source implementation of the GDI+ API * libstatgrab | Make system statistics * mono | a .NET runtime environment * perl-Devel-Leak | Utility for looking for perl objects that are not reclaimed * perl-File-Copy-Recursive | Extension for recursively copying files and directories * perl-File-Next | File::Next Perl module * perl-Module-Install | Standalone, extensible Perl module installer * postgresql-plruby | PostgreSQL Ruby Procedural Language * vnstat | Console-based network traffic monitor * wiggle | A tool for applying patches with conflicts === EPEL 4 === Number of source packages: 600 Number of binary packages: 1129 There are 15 new Packages: * ack | Grep-like text finder * bwm-ng | Bandwidth Monitor NG * jigdo | Ease distribution of large files over the Internet * libstatgrab | Make system statistics * perl-BSD-Resource | BSD process resource limit and priority functions * perl-Class-Inspector | Get information about a class and its structure * perl-Devel-Leak | Utility for looking for perl objects that are not reclaimed * perl-File-Copy-Recursive | Extension for recursively copying files and directories * perl-File-Next | File::Next Perl module * perl-Module-CoreList | Perl core modules indexed by perl versions * perl-Module-Install | Standalone, extensible Perl module installer * perl-Module-Pluggable | Automatically give your module the ability to have plugins * perl-Module-ScanDeps | Recursively scan Perl code for dependencies * pstoedit | Translates PostScript and PDF graphics into other vector formats * vnstat | Console-based network traffic monitor ---- ["CategoryEPELReports"] From triad at df.lth.se Sun Jan 20 13:51:39 2008 From: triad at df.lth.se (Linus Walleij) Date: Sun, 20 Jan 2008 14:51:39 +0100 (CET) Subject: rawhide report: 20080118 changes In-Reply-To: <4792959F.1060308@gmail.com> References: <200801191711.m0JHBcSi017061@porkchop.devel.redhat.com> <1200787016.26735.0.camel@localhost.localdomain> <4792959F.1060308@gmail.com> Message-ID: On Sat, 19 Jan 2008, Andrew Farris wrote: > There was a prior work called simply 'readahead' which was in Fedora and > removed due to making almost no real difference. Hopefully the newer > incarnation is effective. I built it for F-8 from CVS and has been running it since yesterday, and I'm already noting differences, but will run it for some time to see just how effective it is. Linus From jkeating at redhat.com Sun Jan 20 14:25:19 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 20 Jan 2008 09:25:19 -0500 Subject: Unplanned system outage Message-ID: <20080120092519.79e4393f@redhat.com> It appears that we have lost one of our Xen servers for reasons not yet discovered. Systems affected seem to include bodhi, koji, account system, and possibly others. The reason for the outage is still being investigated, as well as attempts to restore service. We're sorry for any inconvenience this may cause. More announcements will be made as services come back on-line. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From markg85 at gmail.com Sun Jan 20 14:41:39 2008 From: markg85 at gmail.com (Mark) Date: Sun, 20 Jan 2008 15:41:39 +0100 Subject: Opinion: Preferred Applications & Removable Drives and Media In-Reply-To: <1200785912.2924.14.camel@localhost.localdomain> References: <6e24a8e80801191428m45ecd472w788c4a88055f0455@mail.gmail.com> <1200785912.2924.14.camel@localhost.localdomain> Message-ID: <6e24a8e80801200641m64febab5v5f1bbc1fa1977e19@mail.gmail.com> Filled: http://bugzilla.gnome.org/show_bug.cgi?id=510806 From jkeating at redhat.com Sun Jan 20 15:28:57 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 20 Jan 2008 10:28:57 -0500 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <604aa7910801192136u754e6a4ex1c3c0113440c4e02@mail.gmail.com> References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> <1200766980.2961.8.camel@sb-home> <604aa7910801192136u754e6a4ex1c3c0113440c4e02@mail.gmail.com> Message-ID: <20080120102857.25926a80@redhat.com> On Sat, 19 Jan 2008 20:36:52 -0900 "Jeff Spaleta" wrote: > As a package maintainer, what would you like me to do in situations > where I need the reporter to talk to upstream? You file the bug upstream for them, and add them to the cc list if possible, or you file it upstream, and respond in our bugzilla with a link to the upstream bug and ask them to attach themselves to that upstream bug. I get the sense that we need to come up with a 'How to appropriately respond to bugzilla entries' guideline for new maintainers... -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From berrange at redhat.com Sun Jan 20 15:38:42 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Sun, 20 Jan 2008 15:38:42 +0000 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <200801192148.25042.opensource@till.name> References: <20080118131620.748606a0@redhat.com> <1200773318.26373.14.camel@rousalka.dyndns.org> <20080119204107.GV6349@redhat.com> <200801192148.25042.opensource@till.name> Message-ID: <20080120153842.GC13223@redhat.com> On Sat, Jan 19, 2008 at 09:48:15PM +0100, Till Maas wrote: > On Saturday 19 January 2008 21:41:07 Daniel P. Berrange wrote: > > > For all Xen related bugs I always need to get /var/log/xen/xend.log > > and quite often the guest VM config file. At the same time I often do > > not have time to deal with a bug immediately. So I will take a quick > > look at request the info that will likely be required to diagnose the > > bug. So when I do finally have time to analyse the bug perhaps a month > > or more later, I will have most of the info neccessary. If I didn't > > request the data immediately, then the user would probably not still > > have the neccessary data the weeks/ month later and there'd be no > > chance to fix it. So I always as for as much information as possible > > the moment the bug is opened, since that's the time at which the user > > has it easily available. > > Maybe the bug reporter feels better, when you explain this in your comment, if > you do not do this already. Sometimes I do, sometimes I don't - its hard to generalize the response since it depends on a thousand & one different factors. One thing I think would be helpful though, would be for bugzilla to show people a list of required data when entering a bug on a per component level. eg, for a virt-manager bug I always want $HOME/.virt-manager.log eg, for a Xen bug I always want /var/log/xen/xend.log, and the config file of the associated guest VM eg, for an perl-Test-AutoBuild bug I always want /var/lib/builder/auto-build.log Even if the user thinks they are providing enough info that they don't need the logs, history has taught me that people frequently supply incorrect data, either accidentally or delibrately. It shouldn't be outside the realms of possibility to be able to associate a short snippet of HTML with each BZ component, so the 'create bug' form can tell users the component-specific data required upfront. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From sean.bruno at dsl-only.net Sun Jan 20 15:41:38 2008 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Sun, 20 Jan 2008 07:41:38 -0800 Subject: [Fwd: [Bug 338211] alsa-plugins-pulseaudio needs 32 bit libs on x86_64 platform] Message-ID: <1200843698.12683.0.camel@home-desk> Can someone advise the ticket owner on how to resolve this issue? Sean -------------- next part -------------- An embedded message was scrubbed... From: bugzilla at redhat.com Subject: [Bug 338211] alsa-plugins-pulseaudio needs 32 bit libs on x86_64 platform Date: Sun, 20 Jan 2008 03:16:39 -0500 Size: 2971 URL: From michel.sylvan at gmail.com Sun Jan 20 15:49:04 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Sun, 20 Jan 2008 10:49:04 -0500 Subject: [Fwd: [Bug 338211] alsa-plugins-pulseaudio needs 32 bit libs on x86_64 platform] In-Reply-To: <1200843698.12683.0.camel@home-desk> References: <1200843698.12683.0.camel@home-desk> Message-ID: 2008/1/20 Sean Bruno : > Can someone advise the ticket owner on how to resolve this issue? > I commented that he probably needs to find a way to contact one of the repository administrators. Anyone knows how to do this that's more formal than dropping by on IRC? I suggested marking the package CVSNeeded=? but that might not be the correct way of doing things. (As noted earlier in the package, nothing else needs changing, the package is multilib-ready already) -- Michel > Sean > > > ---------- Forwarded message ---------- > From: bugzilla at redhat.com > To: sean.bruno at dsl-only.net > Date: Sun, 20 Jan 2008 03:16:39 -0500 > Subject: [Bug 338211] alsa-plugins-pulseaudio needs 32 bit libs on x86_64 platform > Please do not reply directly to this email. All additional > comments should be made in the comments box of this bug report. > > Summary: alsa-plugins-pulseaudio needs 32 bit libs on x86_64 platform > > > https://bugzilla.redhat.com/show_bug.cgi?id=338211 > > > eric.moret at epita.fr changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|NEW |NEEDINFO > Flag| |needinfo? > > > > > ------- Additional Comments From eric.moret at epita.fr 2008-01-20 03:16 EST ------- > Forgive my ignorance, but I don't know how to make an i386 package available to > the x86_64 repository. Not having a 64 bits box around does not help either. Any > hints as to what needs to happen? > > -- > Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Michel Salim http://hircus.jaiku.com/ From lkundrak at redhat.com Sun Jan 20 17:06:07 2008 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Sun, 20 Jan 2008 18:06:07 +0100 Subject: mock 0.8.9 will not build anything In-Reply-To: <47926563.1040301@gmx.net> References: <4790691C.3080605@gmx.net> <1200752442.6945.3.camel@localhost.localdomain> <47926563.1040301@gmx.net> Message-ID: <1200848768.6945.12.camel@localhost.localdomain> On Sat, 2008-01-19 at 22:02 +0100, Frank B?ttner wrote: > Lubomir Kundrak schrieb: > > On Fri, 2008-01-18 at 09:53 +0100, Frank B?ttner wrote: > >> Hello, > >> > >> when I try to build an package mock will fail with: > > ... > >> 2008-01-18 09:48:01,973 - DEBUG util.py, Line: 234: groupadd: name > >> mockbuild is not unique > >> 2008-01-18 09:48:01,977 - DEBUG trace_decorator.py, Line: 27: > >> EXCEPTION: Command(/usr/sbin/groupadd -g 102 mockbuild) failed. See logs f > >> or output. > >> > >> Any ideas, what goes wrong?? > > > > Please delete /var/mock/* and try again. In case you won't succeed, > > please open a bug report in bugzilla. > > > > Thanks, > The directory /var/mock* don't exist. > Do you mean /var/lib/mock* ?? Yes, you're right, I've mistaken. -- Lubomir Kundrak (Red Hat Security Response Team) From cjdahlin at ncsu.edu Sun Jan 20 17:06:49 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Sun, 20 Jan 2008 12:06:49 -0500 Subject: Experiment: an RPM that shows uninstalled apps in main menu In-Reply-To: <479300D5.5020208@gmail.com> References: <4792A25E.5020301@poolshark.org> <16de708d0801192046j102eb7d7sf64059e784b9bef3@mail.gmail.com> <604aa7910801192142y5266c0dfh2e82a91246483f69@mail.gmail.com> <16de708d0801192156w2fa69e76v7014057effe8aac4@mail.gmail.com> <479300D5.5020208@gmail.com> Message-ID: <47937FA9.2050309@ncsu.edu> Andrew Farris wrote: > Arthur Pemberton wrote: >> On Jan 19, 2008 11:42 PM, Jeff Spaleta wrote: >>> On Jan 19, 2008 7:46 PM, Arthur Pemberton wrote: >>>> While I don't think it should be exactly how you have it, an >>>> 'Uninstalled' submenu in every category, seems like a great idea to >>>> me. >>> Until someone decides to manually re-arrange the listings on the >>> system using a menu editor :-> >>> >>> -jef >>> >> >> >> I personally think this should be a first level menu myself. An >> immutable one at that. And install of 'uninstalled' might want to say >> 'available' > > Immutable, and first level seems reasonable. The title is debatable, > since 'available' has multiple meanings, and the software is not > available to the person who wants to use it when they click on the > menu... its acquirable, its not yet installed, its offered, but not > yet available. If something like 'Repository Software' was used, that > would be clear (but not very 'sophisticated'). > You know how on mswin you open a menu and you get the most recently used menu items and an arrow that expands the menu to show everything? Maybe we could do that only instead of distinguishing by frequency of use we could distinguish by installed/not installed. So at the bottom of every menu would be a "show uninstalled apps" option (though hopefully not so verbosely stated. --CJD From dennis at ausil.us Sun Jan 20 17:11:31 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 20 Jan 2008 11:11:31 -0600 Subject: Unplanned system outage In-Reply-To: <20080120092519.79e4393f@redhat.com> References: <20080120092519.79e4393f@redhat.com> Message-ID: <200801201111.36790.dennis@ausil.us> On Sunday 20 January 2008, Jesse Keating wrote: > It appears that we have lost one of our Xen servers for reasons not yet > discovered. Systems affected seem to include bodhi, koji, account > system, and possibly others. > > The reason for the outage is still being investigated, as well as > attempts to restore service. We're sorry for any inconvenience this > may cause. More announcements will be made as services come back > on-line. Service should now be restored to all services. Please let us know if you have issues. We are still investigating the cause of the outage. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From frank-buettner at gmx.net Sun Jan 20 17:31:14 2008 From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=) Date: Sun, 20 Jan 2008 18:31:14 +0100 Subject: mock 0.8.9 will not build anything In-Reply-To: <1200848768.6945.12.camel@localhost.localdomain> References: <4790691C.3080605@gmx.net> <1200752442.6945.3.camel@localhost.localdomain> <47926563.1040301@gmx.net> <1200848768.6945.12.camel@localhost.localdomain> Message-ID: <47938562.6040109@gmx.net> Lubomir Kundrak schrieb: > On Sat, 2008-01-19 at 22:02 +0100, Frank B?ttner wrote: >> Lubomir Kundrak schrieb: >>> On Fri, 2008-01-18 at 09:53 +0100, Frank B?ttner wrote: >>>> Hello, >>>> >>>> when I try to build an package mock will fail with: >>> ... >>>> 2008-01-18 09:48:01,973 - DEBUG util.py, Line: 234: groupadd: name >>>> mockbuild is not unique >>>> 2008-01-18 09:48:01,977 - DEBUG trace_decorator.py, Line: 27: >>>> EXCEPTION: Command(/usr/sbin/groupadd -g 102 mockbuild) failed. See logs f >>>> or output. >>>> >>>> Any ideas, what goes wrong?? >>> Please delete /var/mock/* and try again. In case you won't succeed, >>> please open a bug report in bugzilla. >>> >>> Thanks, >> The directory /var/mock* don't exist. >> Do you mean /var/lib/mock* ?? > > Yes, you're right, I've mistaken. > Ok testet, now an mock init fails with: mock -r fedora-4-i386-epel init INFO: mock.py version 0.8.9 starting... State Changed: init plugins State Changed: start State Changed: lock buildroot State Changed: clean State Changed: init ERROR: Could not create dir /var/lib/mock/epel-4-i386/result. Error: [Errno 13] Permission denied: '/var/lib/mock/epel-4-i386/result' Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/mock/util.py", line 42, in mkdirIfAbsent os.makedirs(dir) File "/usr/lib/python2.4/os.py", line 159, in makedirs mkdir(name, mode) OSError: [Errno 13] Permission denied: '/var/lib/mock/epel-4-i386/result' ERROR: Could not create dir /var/lib/mock/epel-4-i386/result. Error: [Errno 13] Permission denied: '/var/lib/mock/epel-4-i386/result' -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5766 bytes Desc: S/MIME Cryptographic Signature URL: From drago01 at gmail.com Sun Jan 20 17:33:53 2008 From: drago01 at gmail.com (drago01) Date: Sun, 20 Jan 2008 18:33:53 +0100 Subject: [Fwd: [Bug 338211] alsa-plugins-pulseaudio needs 32 bit libs on x86_64 platform] In-Reply-To: <1200843698.12683.0.camel@home-desk> References: <1200843698.12683.0.camel@home-desk> Message-ID: 2008/1/20 Sean Bruno : > Can someone advise the ticket owner on how to resolve this issue? > > Sean > > > ---------- Forwarded message ---------- > From: bugzilla at redhat.com > To: sean.bruno at dsl-only.net > Date: Sun, 20 Jan 2008 03:16:39 -0500 > Subject: [Bug 338211] alsa-plugins-pulseaudio needs 32 bit libs on x86_64 platform > Please do not reply directly to this email. All additional > comments should be made in the comments box of this bug report. > > Summary: alsa-plugins-pulseaudio needs 32 bit libs on x86_64 platform I already sent a patch yesterday to rel-end to add alsa-plugins-pulseaudio and pulseaudio-utils to the multilib whitelist (ie make the i386 package available on x86_64), but got no response yet. From lkundrak at redhat.com Sun Jan 20 17:45:37 2008 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Sun, 20 Jan 2008 18:45:37 +0100 Subject: mock 0.8.9 will not build anything In-Reply-To: <47938562.6040109@gmx.net> References: <4790691C.3080605@gmx.net> <1200752442.6945.3.camel@localhost.localdomain> <47926563.1040301@gmx.net> <1200848768.6945.12.camel@localhost.localdomain> <47938562.6040109@gmx.net> Message-ID: <1200851137.6945.15.camel@localhost.localdomain> Hi Frank, On Sun, 2008-01-20 at 18:31 +0100, Frank B?ttner wrote: ... > Ok testet, now an mock init fails with: > mock -r fedora-4-i386-epel init > INFO: mock.py version 0.8.9 starting... > State Changed: init plugins > State Changed: start > State Changed: lock buildroot > State Changed: clean > State Changed: init > ERROR: Could not create dir /var/lib/mock/epel-4-i386/result. Error: > [Errno 13] Permission denied: '/var/lib/mock/epel-4-i386/result' > Traceback (most recent call last): > File "/usr/lib/python2.4/site-packages/mock/util.py", line 42, in > mkdirIfAbsent > os.makedirs(dir) > File "/usr/lib/python2.4/os.py", line 159, in makedirs > mkdir(name, mode) > OSError: [Errno 13] Permission denied: '/var/lib/mock/epel-4-i386/result' > ERROR: Could not create dir /var/lib/mock/epel-4-i386/result. Error: > [Errno 13] Permission denied: '/var/lib/mock/epel-4-i386/result' Does your /var/lib/mock have correct permissions? If you deleted it and recreated it, please make sure that it is owned by "mock" group, is group writable, and has a setgid bit set: drwxrwsr-x 2 root mock 4096 2008-01-20 13:54 /var/lib/mock Thanks, -- Lubomir Kundrak (Red Hat Security Response Team) From frank-buettner at gmx.net Sun Jan 20 17:50:42 2008 From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=) Date: Sun, 20 Jan 2008 18:50:42 +0100 Subject: mock 0.8.9 will not build anything In-Reply-To: <47938562.6040109@gmx.net> References: <4790691C.3080605@gmx.net> <1200752442.6945.3.camel@localhost.localdomain> <47926563.1040301@gmx.net> <1200848768.6945.12.camel@localhost.localdomain> <47938562.6040109@gmx.net> Message-ID: <479389F2.6050108@gmx.net> Frank B?ttner schrieb: > Ok testet, now an mock init fails with: > mock -r fedora-4-i386-epel init > INFO: mock.py version 0.8.9 starting... > State Changed: init plugins > State Changed: start > State Changed: lock buildroot > State Changed: clean > State Changed: init > ERROR: Could not create dir /var/lib/mock/epel-4-i386/result. Error: > [Errno 13] Permission denied: '/var/lib/mock/epel-4-i386/result' > Traceback (most recent call last): > File "/usr/lib/python2.4/site-packages/mock/util.py", line 42, in > mkdirIfAbsent > os.makedirs(dir) > File "/usr/lib/python2.4/os.py", line 159, in makedirs > mkdir(name, mode) > OSError: [Errno 13] Permission denied: '/var/lib/mock/epel-4-i386/result' > ERROR: Could not create dir /var/lib/mock/epel-4-i386/result. Error: > [Errno 13] Permission denied: '/var/lib/mock/epel-4-i386/result' > > This was resolved.(the permission of /var/lib/mock) But now I get this: ERROR: Bad build req: No Package Found for ccache. Exiting. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5766 bytes Desc: S/MIME Cryptographic Signature URL: From lkundrak at redhat.com Sun Jan 20 18:05:18 2008 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Sun, 20 Jan 2008 19:05:18 +0100 Subject: mock 0.8.9 will not build anything In-Reply-To: <479389F2.6050108@gmx.net> References: <4790691C.3080605@gmx.net> <1200752442.6945.3.camel@localhost.localdomain> <47926563.1040301@gmx.net> <1200848768.6945.12.camel@localhost.localdomain> <47938562.6040109@gmx.net> <479389F2.6050108@gmx.net> Message-ID: <1200852318.6945.21.camel@localhost.localdomain> On Sun, 2008-01-20 at 18:50 +0100, Frank B?ttner wrote: > Frank B?ttner schrieb: > > Ok testet, now an mock init fails with: > > mock -r fedora-4-i386-epel init > > INFO: mock.py version 0.8.9 starting... > > State Changed: init plugins > > State Changed: start > > State Changed: lock buildroot > > State Changed: clean > > State Changed: init > > ERROR: Could not create dir /var/lib/mock/epel-4-i386/result. Error: > > [Errno 13] Permission denied: '/var/lib/mock/epel-4-i386/result' > > Traceback (most recent call last): > > File "/usr/lib/python2.4/site-packages/mock/util.py", line 42, in > > mkdirIfAbsent > > os.makedirs(dir) > > File "/usr/lib/python2.4/os.py", line 159, in makedirs > > mkdir(name, mode) > > OSError: [Errno 13] Permission denied: '/var/lib/mock/epel-4-i386/result' > > ERROR: Could not create dir /var/lib/mock/epel-4-i386/result. Error: > > [Errno 13] Permission denied: '/var/lib/mock/epel-4-i386/result' > > > > > This was resolved.(the permission of /var/lib/mock) > But now I get this: > ERROR: Bad build req: No Package Found for ccache. Exiting. I (on Fedora 8) and also mock-0.8.9 have the following in /etc/mock/fedora-4-i386-epel.cfg: > # ccache not available on epel4 > config_opts['plugin_conf']['ccache_enable'] = False Do you see it in your configuration file? If not, please compare it with distribution one and make the appropriate changes. In case the lines are present, please upload your complete build logs somewhere, so we can try to find you what was trying to pull ccache in. Thanks, -- Lubomir Kundrak (Red Hat Security Response Team) From frank-buettner at gmx.net Sun Jan 20 18:35:40 2008 From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=) Date: Sun, 20 Jan 2008 19:35:40 +0100 Subject: mock 0.8.9 will not build anything In-Reply-To: <1200852318.6945.21.camel@localhost.localdomain> References: <4790691C.3080605@gmx.net> <1200752442.6945.3.camel@localhost.localdomain> <47926563.1040301@gmx.net> <1200848768.6945.12.camel@localhost.localdomain> <47938562.6040109@gmx.net> <479389F2.6050108@gmx.net> <1200852318.6945.21.camel@localhost.localdomain> Message-ID: <4793947C.9050202@gmx.net> Lubomir Kundrak schrieb: : Bad build req: No Package Found for ccache. Exiting. > > I (on Fedora 8) and also mock-0.8.9 have the following > in /etc/mock/fedora-4-i386-epel.cfg: >> # ccache not available on epel4 >> config_opts['plugin_conf']['ccache_enable'] = False > > Do you see it in your configuration file? If not, please compare it with > distribution one and make the appropriate changes. In case the lines are > present, please upload your complete build logs somewhere, so we can try > to find you what was trying to pull ccache in. > > Thanks, So, this line was missing, so I add this. Now I get this error: ERROR: Error performing yum command: /usr/bin/yum --installroot /var/lib/mock/epel-4-i386/root update Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/mock/backend.py", line 448, in _yum output = mock.util.do(cmd, returnOutput=returnOutput, personality=self.personality) File "", line 1, in File "/usr/lib/python2.4/site-packages/mock/trace_decorator.py", line 24, in trace result = f(*args, **kw) File "/usr/lib/python2.4/site-packages/mock/util.py", line 260, in do raise mock.exception.Error, "Command(%s) failed. See logs for output." % command Error: Command(/usr/bin/yum --installroot /var/lib/mock/epel-4-i386/root update) failed. See logs for output. In the log I see only the same line. I have append the log file. Thanks for your help. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: root.log URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5766 bytes Desc: S/MIME Cryptographic Signature URL: From lkundrak at redhat.com Sun Jan 20 18:53:05 2008 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Sun, 20 Jan 2008 19:53:05 +0100 Subject: mock 0.8.9 will not build anything In-Reply-To: <4793947C.9050202@gmx.net> References: <4790691C.3080605@gmx.net> <1200752442.6945.3.camel@localhost.localdomain> <47926563.1040301@gmx.net> <1200848768.6945.12.camel@localhost.localdomain> <47938562.6040109@gmx.net> <479389F2.6050108@gmx.net> <1200852318.6945.21.camel@localhost.localdomain> <4793947C.9050202@gmx.net> Message-ID: <1200855185.6945.24.camel@localhost.localdomain> On Sun, 2008-01-20 at 19:35 +0100, Frank B?ttner wrote: > So, this line was missing, so I add this. Now I get this error: > ERROR: Error performing yum command: /usr/bin/yum --installroot > /var/lib/mock/epel-4-i386/root update Have you removed the buildroot and the cache from /var/lib/mock after changing the configuration file? -- Lubomir Kundrak (Red Hat Security Response Team) From frank-buettner at gmx.net Sun Jan 20 18:59:06 2008 From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=) Date: Sun, 20 Jan 2008 19:59:06 +0100 Subject: mock 0.8.9 will not build anything In-Reply-To: <1200855185.6945.24.camel@localhost.localdomain> References: <4790691C.3080605@gmx.net> <1200752442.6945.3.camel@localhost.localdomain> <47926563.1040301@gmx.net> <1200848768.6945.12.camel@localhost.localdomain> <47938562.6040109@gmx.net> <479389F2.6050108@gmx.net> <1200852318.6945.21.camel@localhost.localdomain> <4793947C.9050202@gmx.net> <1200855185.6945.24.camel@localhost.localdomain> Message-ID: <479399FA.9040709@gmx.net> Lubomir Kundrak schrieb: > On Sun, 2008-01-20 at 19:35 +0100, Frank B?ttner wrote: > >> So, this line was missing, so I add this. Now I get this error: >> ERROR: Error performing yum command: /usr/bin/yum --installroot >> /var/lib/mock/epel-4-i386/root update > > Have you removed the buildroot and the cache from /var/lib/mock after > changing the configuration file? > No, but after do that I get the same error when try to run mock -r fedora-4-i386-epel init: mock -r fedora-4-i386-epel init INFO: mock.py version 0.8.9 starting... State Changed: init plugins State Changed: start State Changed: lock buildroot State Changed: clean State Changed: init State Changed: lock buildroot State Changed: enabled yum cache, cleaning yum metadata State Changed: enabled root cache State Changed: running yum ERROR: Error performing yum command: /usr/bin/yum --installroot /var/lib/mock/epel-4-i386/root install buildsys-build Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/mock/backend.py", line 448, in _yum output = mock.util.do(cmd, returnOutput=returnOutput, personality=self.personality) File "", line 1, in File "/usr/lib/python2.4/site-packages/mock/trace_decorator.py", line 24, in trace result = f(*args, **kw) File "/usr/lib/python2.4/site-packages/mock/util.py", line 260, in do raise mock.exception.Error, "Command(%s) failed. See logs for output." % command Error: Command(/usr/bin/yum --installroot /var/lib/mock/epel-4-i386/root install buildsys-build) failed. See logs for output. ERROR: Error performing yum command: /usr/bin/yum --installroot /var/lib/mock/epel-4-i386/root install buildsys-build -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5766 bytes Desc: S/MIME Cryptographic Signature URL: From ville.skytta at iki.fi Sun Jan 20 19:05:22 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sun, 20 Jan 2008 21:05:22 +0200 Subject: Rebuilds for new Perl? Message-ID: <200801202105.23463.ville.skytta@iki.fi> There have been some "Rebuild for new Perl" commits lately for perl-* packages, apparently using the dist-f9-perl koji tag. Some questions: - Is Perl 5.10 scheduled for F-9? - Does Perl 5.10 require rebuilds of all/some/which packages? - Should all maintainers of perl-* be doing these rebuilds? Thanks in advance. From tcallawa at redhat.com Sun Jan 20 19:27:52 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 20 Jan 2008 14:27:52 -0500 Subject: Rebuilds for new Perl? In-Reply-To: <200801202105.23463.ville.skytta@iki.fi> References: <200801202105.23463.ville.skytta@iki.fi> Message-ID: <1200857272.7579.27.camel@localhost.localdomain> On Sun, 2008-01-20 at 21:05 +0200, Ville Skytt? wrote: > There have been some "Rebuild for new Perl" commits lately for perl-* > packages, apparently using the dist-f9-perl koji tag. > > Some questions: > > - Is Perl 5.10 scheduled for F-9? Yes. > - Does Perl 5.10 require rebuilds of all/some/which packages? Yes, some. > - Should all maintainers of perl-* be doing these rebuilds? Not at first. Because everything that depends on perl needs to be rebuilt, its not a straightforward "rebuild what I own" process. I've got the first 300 or so dependencies in a list, and I'm chainbuilding them in the dist-f9-perl tag, as not to completely break rawhide. Once I get those done, the plan is to merge the packages in dist-f9-perl back into rawhide. Then, the individual maintainers for whatever remains broken in rawhide will be able to rebuild them. ~spot From buildsys at fedoraproject.org Sun Jan 20 19:45:33 2008 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 20 Jan 2008 14:45:33 -0500 (EST) Subject: Package EVR problems in Fedora 2008-01-20 Message-ID: <20080120194533.8437D152130@buildsys.fedoraproject.org> Broken upgrade path report for repositories FC5, FC5-updates, FE5, FC6, FC6-updates, FE6, F7, F7-updates, F7-updates-testing, F8, F8-updates, F8-updates-testing, F9 ajackson AT redhat com: gstreamer-plugins-base F8-updates-testing > F9 (0:0.10.15-3.fc8 > 0:0.10.15-2.fc9) alexl AT redhat com: gtk-sharp2 F7-updates-testing > F9 (0:2.10.2-1.fc7 > 0:2.10.0-6.fc8) F8-updates-testing > F9 (0:2.10.2-1.fc8 > 0:2.10.0-6.fc8) sabayon F8-updates > F9 (0:2.20.1-5.fc8 > 0:2.20.1-4.fc9) andreas bierfert AT lowlatency de: claws-mail F7-updates-testing > F9 (0:3.2.0-3.fc7 > 0:3.2.0-2.fc9) F8-updates-testing > F9 (0:3.2.0-3.fc8 > 0:3.2.0-2.fc9) besfahbo AT redhat com: gthumb F8-updates-testing > F9 (0:2.10.8-1.fc8 > 0:2.10.7-2.fc9) bos AT serpentine com: ghc F8-updates > F9 (0:6.8.2-8.fc8 > 0:6.8.2-2.fc9) caillon AT redhat com: epiphany-extensions F8-updates > F9 (0:2.20.1-4.fc8 > 0:2.20.1-3.fc9) davidz AT redhat com: dbus-python F7-updates > F8 (0:0.82.3-1.fc7 > 0:0.82.0-3.fc9) F7-updates > F9 (0:0.82.3-1.fc7 > 0:0.82.0-3.fc9) debarshi ray AT gmail com: redet-doc F7-updates > F8 (0:8.23-2 > 0:8.22-1.fc8) F7-updates > F9 (0:8.23-2 > 0:8.22-1.fc8) denis AT poolshark org: glom F8-updates > F9 (0:1.6.5-1.fc8 > 0:1.6.4-1.fc9) dmaley AT redhat com: wavbreaker F8-updates > F9 (0:0.9-2.fc8 > 0:0.9-1.fc9) enrico scholz AT informatik tu-chemnitz de: libextractor FE6 > F7 (0:0.5.18a-1.fc6 > 0:0.5.17a-1.fc7) libtasn1 FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE6 > F7 (0:1.1-1.fc6 > 0:0.3.9-1.fc7) mimetic FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7) FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7) util-vserver FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7) FE6 > F7 (0:0.30.214-2 > 0:0.30.212-3.fc7) giallu AT gmail com: sysprof-kmod F7-updates > F8-updates (0:1.0.8-1.2.6.23.12_52.fc7 > 0:1.0.8-1.2.6.23.9_85.fc8) green AT redhat com: liblrdf FE6 > F7-updates (0:0.4.0-12.fc6 > 0:0.4.0-11.fc7) phasex FE6 > F9 (0:0.11.1-4.fc6 > 0:0.11.1-3.fc9) F7-updates > F9 (0:0.11.1-4.fc7 > 0:0.11.1-3.fc9) F8-updates > F9 (0:0.11.1-4.fc8 > 0:0.11.1-3.fc9) zynaddsubfx FE6 > F7 (0:2.2.1-15.fc6 > 0:2.2.1-14.fc7) jeff AT ocjtech us: jrtplib FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) jjohnstn AT redhat com: eclipse-cdt F8-updates-testing > F9 (1:4.0.1-3.fc8 > 1:4.0.1-2.fc9) eclipse-changelog F8-updates-testing > F9 (1:2.6.0-1.fc8 > 1:2.5.1-2.fc8) josef AT toxicpanda com: tilda F8-updates-testing > F9 (0:0.9.4-6.fc8 > 0:0.9.4-6.fc7) karen-pease AT uiowa edu: fortune-firefly FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6) FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6) nethack-vultures FE6 > F7 (0:2.1.0-10.fc6 > 0:2.1.0-9.fc7) karlikt AT gmail com: fusion-icon F8-updates > F9 (0:0-0.3.20071206git.fc8 > 0:0-0.2.20071206git.fc9) lemenkov AT gmail com: fuse-python FE6 > F8 (0:0.2-6.fc6 > 0:0.2-5.fc8) FE6 > F9 (0:0.2-6.fc6 > 0:0.2-5.fc8) F7-updates > F8 (0:0.2-6.fc7 > 0:0.2-5.fc8) F7-updates > F9 (0:0.2-6.fc7 > 0:0.2-5.fc8) lmacken AT redhat com: python-TurboMail F8-updates > F9 (0:2.1-2.fc8 > 0:2.1-1.fc9) lxtnow AT gmail com: specto FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8) FE6 > F9 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8) F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8) F7-updates > F9 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8) wammu FE6 > F8 (0:0.23-1.fc6 > 0:0.19-3.fc8) FE6 > F9 (0:0.23-1.fc6 > 0:0.19-3.fc8) F7-updates > F8 (0:0.23-1.fc7 > 0:0.19-3.fc8) F7-updates > F9 (0:0.23-1.fc7 > 0:0.19-3.fc8) matthias AT rpmforge net: linux_logo F8-updates-testing > F9 (0:5.02-1.fc8 > 0:5.01-3.fc8) mclasen AT redhat com: zenity F8-updates > F9 (0:2.20.1-2.fc8 > 0:2.20.1-1.fc9) mdehaan AT redhat com: func F7-updates > F9 (0:0.14-1.fc7 > 0:0.13-3.fc9) F8-updates > F9 (0:0.14-1.fc8 > 0:0.13-3.fc9) mfarrellee AT redhat com: gsoap F8-updates-testing > F9 (0:2.7.9-0.3.l > 0:2.7.9-0.1.l) mfleming+rpm AT enlartenment com: mcabber FE6 > F9 (0:0.9.5-1.fc6 > 0:0.9.4-1.fc9) F7-updates > F9 (0:0.9.5-1.fc7 > 0:0.9.4-1.fc9) F8-updates > F9 (0:0.9.5-1.fc8 > 0:0.9.4-1.fc9) michel sylvan AT gmail com: python-nltk FE5 > F8 (0:1.4.4-3.fc5 > 0:0.9-0.2.b2.fc8) FE5 > F9 (0:1.4.4-3.fc5 > 0:0.9-0.2.b2.fc8) FE6 > F8 (0:1.4.4-3.fc6 > 0:0.9-0.2.b2.fc8) FE6 > F9 (0:1.4.4-3.fc6 > 0:0.9-0.2.b2.fc8) mikeb AT redhat com: python-cheetah FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) mnagy AT redhat com: quagga F8-updates > F9 (0:0.99.9-3.fc8 > 0:0.99.9-2.fc9) mpg AT redhat com: xapian-core F7-updates > F9 (0:1.0.5-2.fc7 > 0:1.0.5-1.fc9) F8-updates > F9 (0:1.0.5-2.fc8 > 0:1.0.5-1.fc9) mwringe AT redhat com: cryptix F8-updates-testing > F9 (0:3.2.0-9jpp.3.fc8 > 0:3.2.0-9jpp.2) nhorman AT redhat com: irqbalance FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6) FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7) ondrejj AT salstar sk: aspell-sk FE6 > F9 (0:2.00-3.fc6 > 0:0.52-3.fc9) F7-updates > F9 (0:2.00-3.fc7 > 0:0.52-3.fc9) F8-updates > F9 (0:2.00-3.fc8 > 0:0.52-3.fc9) opensource AT till name: offlineimap F8-updates-testing > F9 (0:5.99.4-2.fc8 > 0:5.99.4-1.fc9) paul AT xelerance com: driftnet F7-updates > F9 (0:0.1.6-18.20040426cvs.fc7 > 0:0.1.6-15.20040426cvs.fc9) F8-updates > F9 (0:0.1.6-19.20040426cvs.fc8 > 0:0.1.6-15.20040426cvs.fc9) ldns FE6 > F7 (0:1.2.2-1.fc6 > 0:1.0.1-4.fc6) peter AT thecodergeek com: gnome-theme-clearlooks-bigpack F7-updates-testing > F9 (0:0.6-7.fc7 > 0:0.6-6.fc8) F8-updates-testing > F9 (0:0.6-7.fc8 > 0:0.6-6.fc8) phuang AT redhat com: awn-extras-applets F8-updates > F9 (0:0.2.1-3.fc8 > 0:0.2.1-1.fc9) scim-pinyin F8-updates > F9 (0:0.5.91-24.fc8 > 0:0.5.91-23.fc9) pmachata AT redhat com: dejagnu F8-updates > F9 (1:1.4.4-11.fc8 > 1:1.4.4-11) rnorwood AT redhat com: perl F8-updates > F9 (4:5.8.8-32.fc8 > 4:5.8.8-31.fc9) perl-XML-LibXML F7 > F8 (0:1.62001-2.fc7 > 0:1.65-1.fc9) F7 > F9 (0:1.62001-2.fc7 > 0:1.65-1.fc9) rpm AT timj co uk: alsa-tools FE6 > F7 (0:1.0.14-2.fc6 > 0:1.0.12-4.fc7) sandmann AT redhat com: libgtop2 FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7) seg AT haxxed com: openjpeg F7-updates-testing > F9 (0:1.3-1.fc7 > 0:1.2-4.20071211svn484.fc9) F8-updates-testing > F9 (0:1.3-1.fc8 > 0:1.2-4.20071211svn484.fc9) skasal AT redhat com: cairo-java F8-updates-testing > F9 (0:1.0.5-8.fc8 > 0:1.0.5-7.fc7) libgconf-java F8-updates-testing > F9 (0:2.12.4-9.fc8 > 0:2.12.4-8.fc7) libglade-java F8-updates-testing > F9 (0:2.12.5-7.fc8 > 0:2.12.5-6.fc7) libgnome-java F8-updates-testing > F9 (0:2.12.4-7.fc8 > 0:2.12.4-6.fc7) libgtk-java F8-updates-testing > F9 (0:2.8.7-5.fc8 > 0:2.8.7-4.fc7) splinux25 AT gmail com: lostirc FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) steve AT silug org: perl-Kwiki-Revisions F7-updates-testing > F9 (0:0.15-6.fc7 > 0:0.15-5.fc7) F8-updates-testing > F9 (0:0.15-6.fc8 > 0:0.15-5.fc7) tmraz AT redhat com: authconfig FC6-updates > F7-updates (0:5.3.18-0.1.fc6 > 0:5.3.15-1.fc7) veillard AT redhat com: libxml2 F7-updates > F9 (0:2.6.31-1.fc7 > 0:2.6.31-1) F8-updates > F9 (0:2.6.31-1.fc8 > 0:2.6.31-1) wjhns174 AT hardakers net: perl-QWizard F7-updates > F9 (0:3.13-2.fc7 > 0:3.12-2.fc9) F8-updates > F9 (0:3.13-2.fc8 > 0:3.12-2.fc9) ---------------------------------------------------------------------- alsa-tools: rpm AT timj co uk FE6 > F7 (0:1.0.14-2.fc6 > 0:1.0.12-4.fc7) aspell-sk: ondrejj AT salstar sk FE6 > F9 (0:2.00-3.fc6 > 0:0.52-3.fc9) F7-updates > F9 (0:2.00-3.fc7 > 0:0.52-3.fc9) F8-updates > F9 (0:2.00-3.fc8 > 0:0.52-3.fc9) authconfig: tmraz AT redhat com FC6-updates > F7-updates (0:5.3.18-0.1.fc6 > 0:5.3.15-1.fc7) awn-extras-applets: phuang AT redhat com F8-updates > F9 (0:0.2.1-3.fc8 > 0:0.2.1-1.fc9) cairo-java: skasal AT redhat com F8-updates-testing > F9 (0:1.0.5-8.fc8 > 0:1.0.5-7.fc7) claws-mail: andreas bierfert AT lowlatency de F7-updates-testing > F9 (0:3.2.0-3.fc7 > 0:3.2.0-2.fc9) F8-updates-testing > F9 (0:3.2.0-3.fc8 > 0:3.2.0-2.fc9) cryptix: mwringe AT redhat com F8-updates-testing > F9 (0:3.2.0-9jpp.3.fc8 > 0:3.2.0-9jpp.2) dbus-python: davidz AT redhat com F7-updates > F8 (0:0.82.3-1.fc7 > 0:0.82.0-3.fc9) F7-updates > F9 (0:0.82.3-1.fc7 > 0:0.82.0-3.fc9) dejagnu: pmachata AT redhat com F8-updates > F9 (1:1.4.4-11.fc8 > 1:1.4.4-11) driftnet: paul AT xelerance com F7-updates > F9 (0:0.1.6-18.20040426cvs.fc7 > 0:0.1.6-15.20040426cvs.fc9) F8-updates > F9 (0:0.1.6-19.20040426cvs.fc8 > 0:0.1.6-15.20040426cvs.fc9) eclipse-cdt: jjohnstn AT redhat com F8-updates-testing > F9 (1:4.0.1-3.fc8 > 1:4.0.1-2.fc9) eclipse-changelog: jjohnstn AT redhat com F8-updates-testing > F9 (1:2.6.0-1.fc8 > 1:2.5.1-2.fc8) epiphany-extensions: caillon AT redhat com F8-updates > F9 (0:2.20.1-4.fc8 > 0:2.20.1-3.fc9) fortune-firefly: karen-pease AT uiowa edu FE5 > F7 (0:2.1.2-2.fc5 > 0:2.1.1-2.fc6) FE6 > F7 (0:2.1.2-4.fc6 > 0:2.1.1-2.fc6) func: mdehaan AT redhat com F7-updates > F9 (0:0.14-1.fc7 > 0:0.13-3.fc9) F8-updates > F9 (0:0.14-1.fc8 > 0:0.13-3.fc9) fuse-python: lemenkov AT gmail com FE6 > F8 (0:0.2-6.fc6 > 0:0.2-5.fc8) FE6 > F9 (0:0.2-6.fc6 > 0:0.2-5.fc8) F7-updates > F8 (0:0.2-6.fc7 > 0:0.2-5.fc8) F7-updates > F9 (0:0.2-6.fc7 > 0:0.2-5.fc8) fusion-icon: karlikt AT gmail com F8-updates > F9 (0:0-0.3.20071206git.fc8 > 0:0-0.2.20071206git.fc9) ghc: bos AT serpentine com F8-updates > F9 (0:6.8.2-8.fc8 > 0:6.8.2-2.fc9) glom: denis AT poolshark org F8-updates > F9 (0:1.6.5-1.fc8 > 0:1.6.4-1.fc9) gnome-theme-clearlooks-bigpack: peter AT thecodergeek com F7-updates-testing > F9 (0:0.6-7.fc7 > 0:0.6-6.fc8) F8-updates-testing > F9 (0:0.6-7.fc8 > 0:0.6-6.fc8) gsoap: mfarrellee AT redhat com F8-updates-testing > F9 (0:2.7.9-0.3.l > 0:2.7.9-0.1.l) gstreamer-plugins-base: ajackson AT redhat com F8-updates-testing > F9 (0:0.10.15-3.fc8 > 0:0.10.15-2.fc9) gthumb: besfahbo AT redhat com F8-updates-testing > F9 (0:2.10.8-1.fc8 > 0:2.10.7-2.fc9) gtk-sharp2: alexl AT redhat com F7-updates-testing > F9 (0:2.10.2-1.fc7 > 0:2.10.0-6.fc8) F8-updates-testing > F9 (0:2.10.2-1.fc8 > 0:2.10.0-6.fc8) irqbalance: nhorman AT redhat com FC5-updates > FC6-updates (2:0.55-4.fc5 > 2:0.55-2.fc6) FC5-updates > F7 (2:0.55-4.fc5 > 2:0.55-2.fc7) jrtplib: jeff AT ocjtech us FE6 > F7 (0:3.7.1-1.fc6 > 0:3.7.0-1.fc7) ldns: paul AT xelerance com FE6 > F7 (0:1.2.2-1.fc6 > 0:1.0.1-4.fc6) libextractor: enrico scholz AT informatik tu-chemnitz de FE6 > F7 (0:0.5.18a-1.fc6 > 0:0.5.17a-1.fc7) libgconf-java: skasal AT redhat com F8-updates-testing > F9 (0:2.12.4-9.fc8 > 0:2.12.4-8.fc7) libglade-java: skasal AT redhat com F8-updates-testing > F9 (0:2.12.5-7.fc8 > 0:2.12.5-6.fc7) libgnome-java: skasal AT redhat com F8-updates-testing > F9 (0:2.12.4-7.fc8 > 0:2.12.4-6.fc7) libgtk-java: skasal AT redhat com F8-updates-testing > F9 (0:2.8.7-5.fc8 > 0:2.8.7-4.fc7) libgtop2: sandmann AT redhat com FC6-updates > F7 (0:2.14.9-1.fc6 > 0:2.14.8-1.fc7) liblrdf: green AT redhat com FE6 > F7-updates (0:0.4.0-12.fc6 > 0:0.4.0-11.fc7) libtasn1: enrico scholz AT informatik tu-chemnitz de FE5 > F7 (0:0.3.10-1.fc5 > 0:0.3.9-1.fc7) FE6 > F7 (0:1.1-1.fc6 > 0:0.3.9-1.fc7) libxml2: veillard AT redhat com F7-updates > F9 (0:2.6.31-1.fc7 > 0:2.6.31-1) F8-updates > F9 (0:2.6.31-1.fc8 > 0:2.6.31-1) linux_logo: matthias AT rpmforge net F8-updates-testing > F9 (0:5.02-1.fc8 > 0:5.01-3.fc8) lostirc: splinux25 AT gmail com FE6 > F7-updates (0:0.4.6-3.fc6 > 0:0.4.6-2.fc7) mcabber: mfleming+rpm AT enlartenment com FE6 > F9 (0:0.9.5-1.fc6 > 0:0.9.4-1.fc9) F7-updates > F9 (0:0.9.5-1.fc7 > 0:0.9.4-1.fc9) F8-updates > F9 (0:0.9.5-1.fc8 > 0:0.9.4-1.fc9) mimetic: enrico scholz AT informatik tu-chemnitz de FE5 > F7 (0:0.9.3-1.fc5 > 0:0.9.2-1.fc7) FE6 > F7 (0:0.9.3-1.fc6 > 0:0.9.2-1.fc7) nethack-vultures: karen-pease AT uiowa edu FE6 > F7 (0:2.1.0-10.fc6 > 0:2.1.0-9.fc7) offlineimap: opensource AT till name F8-updates-testing > F9 (0:5.99.4-2.fc8 > 0:5.99.4-1.fc9) openjpeg: seg AT haxxed com F7-updates-testing > F9 (0:1.3-1.fc7 > 0:1.2-4.20071211svn484.fc9) F8-updates-testing > F9 (0:1.3-1.fc8 > 0:1.2-4.20071211svn484.fc9) perl: rnorwood AT redhat com F8-updates > F9 (4:5.8.8-32.fc8 > 4:5.8.8-31.fc9) perl-Kwiki-Revisions: steve AT silug org F7-updates-testing > F9 (0:0.15-6.fc7 > 0:0.15-5.fc7) F8-updates-testing > F9 (0:0.15-6.fc8 > 0:0.15-5.fc7) perl-QWizard: wjhns174 AT hardakers net F7-updates > F9 (0:3.13-2.fc7 > 0:3.12-2.fc9) F8-updates > F9 (0:3.13-2.fc8 > 0:3.12-2.fc9) perl-XML-LibXML: rnorwood AT redhat com F7 > F8 (0:1.62001-2.fc7 > 0:1.65-1.fc9) F7 > F9 (0:1.62001-2.fc7 > 0:1.65-1.fc9) phasex: green AT redhat com FE6 > F9 (0:0.11.1-4.fc6 > 0:0.11.1-3.fc9) F7-updates > F9 (0:0.11.1-4.fc7 > 0:0.11.1-3.fc9) F8-updates > F9 (0:0.11.1-4.fc8 > 0:0.11.1-3.fc9) python-cheetah: mikeb AT redhat com FE6 > F7 (0:2.0-0.6.rc8.fc6 > 0:2.0-0.5.rc8.fc7) python-nltk: michel sylvan AT gmail com FE5 > F8 (0:1.4.4-3.fc5 > 0:0.9-0.2.b2.fc8) FE5 > F9 (0:1.4.4-3.fc5 > 0:0.9-0.2.b2.fc8) FE6 > F8 (0:1.4.4-3.fc6 > 0:0.9-0.2.b2.fc8) FE6 > F9 (0:1.4.4-3.fc6 > 0:0.9-0.2.b2.fc8) python-TurboMail: lmacken AT redhat com F8-updates > F9 (0:2.1-2.fc8 > 0:2.1-1.fc9) quagga: mnagy AT redhat com F8-updates > F9 (0:0.99.9-3.fc8 > 0:0.99.9-2.fc9) redet-doc: debarshi ray AT gmail com F7-updates > F8 (0:8.23-2 > 0:8.22-1.fc8) F7-updates > F9 (0:8.23-2 > 0:8.22-1.fc8) sabayon: alexl AT redhat com F8-updates > F9 (0:2.20.1-5.fc8 > 0:2.20.1-4.fc9) scim-pinyin: phuang AT redhat com F8-updates > F9 (0:0.5.91-24.fc8 > 0:0.5.91-23.fc9) specto: lxtnow AT gmail com FE6 > F8 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8) FE6 > F9 (0:0.2.2-1.fc6 > 0:0.2.0-4.fc8) F7-updates > F8 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8) F7-updates > F9 (0:0.2.2-1.fc7 > 0:0.2.0-4.fc8) sysprof-kmod: giallu AT gmail com F7-updates > F8-updates (0:1.0.8-1.2.6.23.12_52.fc7 > 0:1.0.8-1.2.6.23.9_85.fc8) tilda: josef AT toxicpanda com F8-updates-testing > F9 (0:0.9.4-6.fc8 > 0:0.9.4-6.fc7) util-vserver: enrico scholz AT informatik tu-chemnitz de FE5 > F7 (0:0.30.213-1.fc5 > 0:0.30.212-3.fc7) FE6 > F7 (0:0.30.214-2 > 0:0.30.212-3.fc7) wammu: lxtnow AT gmail com FE6 > F8 (0:0.23-1.fc6 > 0:0.19-3.fc8) FE6 > F9 (0:0.23-1.fc6 > 0:0.19-3.fc8) F7-updates > F8 (0:0.23-1.fc7 > 0:0.19-3.fc8) F7-updates > F9 (0:0.23-1.fc7 > 0:0.19-3.fc8) wavbreaker: dmaley AT redhat com F8-updates > F9 (0:0.9-2.fc8 > 0:0.9-1.fc9) xapian-core: mpg AT redhat com F7-updates > F9 (0:1.0.5-2.fc7 > 0:1.0.5-1.fc9) F8-updates > F9 (0:1.0.5-2.fc8 > 0:1.0.5-1.fc9) zenity: mclasen AT redhat com F8-updates > F9 (0:2.20.1-2.fc8 > 0:2.20.1-1.fc9) zynaddsubfx: green AT redhat com FE6 > F7 (0:2.2.1-15.fc6 > 0:2.2.1-14.fc7) From ville.skytta at iki.fi Sun Jan 20 19:50:28 2008 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 20 Jan 2008 21:50:28 +0200 Subject: Rebuilds for new Perl? In-Reply-To: <1200857272.7579.27.camel@localhost.localdomain> References: <200801202105.23463.ville.skytta@iki.fi> <1200857272.7579.27.camel@localhost.localdomain> Message-ID: <200801202150.29395.ville.skytta@iki.fi> On Sunday 20 January 2008, Tom "spot" Callaway wrote: > Because everything that depends on perl needs to be rebuilt, Hmm, that sounds odd to me, could you confirm this? I'd assume that all packages that ship files in /usr/lib*/perl5 or things linked with libperl.so would require a rebuild, but that'd be about it. > I've got the first 300 or so dependencies in a list, and I'm > chainbuilding them in the dist-f9-perl tag, as not to completely break > rawhide. > > Once I get those done, the plan is to merge the packages in dist-f9-perl > back into rawhide. Then, the individual maintainers for whatever remains > broken in rawhide will be able to rebuild them. Ok, thanks. From tcallawa at redhat.com Sun Jan 20 19:54:20 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 20 Jan 2008 14:54:20 -0500 Subject: Rebuilds for new Perl? In-Reply-To: <200801202150.29395.ville.skytta@iki.fi> References: <200801202105.23463.ville.skytta@iki.fi> <1200857272.7579.27.camel@localhost.localdomain> <200801202150.29395.ville.skytta@iki.fi> Message-ID: <1200858860.7579.31.camel@localhost.localdomain> On Sun, 2008-01-20 at 21:50 +0200, Ville Skytt? wrote: > On Sunday 20 January 2008, Tom "spot" Callaway wrote: > > > Because everything that depends on perl needs to be rebuilt, > > Hmm, that sounds odd to me, could you confirm this? > > I'd assume that all packages that ship files in /usr/lib*/perl5 or things > linked with libperl.so would require a rebuild, but that'd be about it. perl packages have: Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version)) (As an aside, I thought this might be autogenerated, but it isn't.) This means that they all depend on perl(:MODULE_COMPAT_5.8.8), thus, need to be rebuilt against perl 5.10.0. ~spot From lordmorgul at gmail.com Sun Jan 20 19:58:38 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sun, 20 Jan 2008 11:58:38 -0800 Subject: Unplanned system outage In-Reply-To: <200801201111.36790.dennis@ausil.us> References: <20080120092519.79e4393f@redhat.com> <200801201111.36790.dennis@ausil.us> Message-ID: <4793A7EE.1030807@gmail.com> Dennis Gilmore wrote: > On Sunday 20 January 2008, Jesse Keating wrote: >> It appears that we have lost one of our Xen servers for reasons not yet >> discovered. Systems affected seem to include bodhi, koji, account >> system, and possibly others. >> >> The reason for the outage is still being investigated, as well as >> attempts to restore service. We're sorry for any inconvenience this >> may cause. More announcements will be made as services come back >> on-line. > > Service should now be restored to all services. Please let us know if you have > issues. > > We are still investigating the cause of the outage. > > Dennis > Just for reference, Jesse's email is at 625am pst, and I know koji was unresponsive at 12am pst today up to 4am (thought hopefully you're able to trace that down a little better). -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From kevin.kofler at chello.at Sun Jan 20 19:59:59 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 20 Jan 2008 19:59:59 +0000 (UTC) Subject: Package EVR problems in Fedora 2008-01-20 References: <20080120194533.8437D152130@buildsys.fedoraproject.org> Message-ID: fedoraproject.org> writes: > ondrejj AT salstar sk: > aspell-sk > FE6 > F9 (0:2.00-3.fc6 > 0:0.52-3.fc9) > F7-updates > F9 (0:2.00-3.fc7 > 0:0.52-3.fc9) > F8-updates > F9 (0:2.00-3.fc8 > 0:0.52-3.fc9) This one appears to need an Epoch bump. The other stuff just needs the latest version or release synced. Kevin Kofler From darrellpf at gmail.com Sun Jan 20 20:06:41 2008 From: darrellpf at gmail.com (darrell pfeifer) Date: Sun, 20 Jan 2008 12:06:41 -0800 Subject: F8 to rawhide upgrade Message-ID: Yesterday I did a fresh install of F8 on a new machine. Then I attempted to upgrade it to rawhide. I generally update by hand, doing about 4 chunks of packages to do the upgrade. I usually start by upgrading rpm and yum. In current rawhide, yum (or yum utils) has a dependency on a particular python module, but it the python chunk isn't pulled in by the yum upgrade. After upgrading yum, yum won't run any more. I downgraded the yum packages, did the upgrade, this time with rpm and yum going last. I was too grouchy to record the exact message. So, the short moral, if doing an F8 to rawhide upgrade, leave rpm/yum for the last. darrell -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominik at greysector.net Sun Jan 20 20:10:24 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 20 Jan 2008 21:10:24 +0100 Subject: Unplanned system outage In-Reply-To: <200801201111.36790.dennis@ausil.us> References: <20080120092519.79e4393f@redhat.com> <200801201111.36790.dennis@ausil.us> Message-ID: <20080120201023.GA11397@ryvius.greysector.net> On Sunday, 20 January 2008 at 18:11, Dennis Gilmore wrote: > On Sunday 20 January 2008, Jesse Keating wrote: > > It appears that we have lost one of our Xen servers for reasons not yet > > discovered. Systems affected seem to include bodhi, koji, account > > system, and possibly others. > > > > The reason for the outage is still being investigated, as well as > > attempts to restore service. We're sorry for any inconvenience this > > may cause. More announcements will be made as services come back > > on-line. > > Service should now be restored to all services. Please let us know if you have > issues. koji website is (still?) unresponsive as of 20:09 UTC. Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From seg at haxxed.com Sun Jan 20 20:14:51 2008 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 20 Jan 2008 14:14:51 -0600 Subject: Experiment: an RPM that shows uninstalled apps in main menu In-Reply-To: <479300D5.5020208@gmail.com> References: <4792A25E.5020301@poolshark.org> <16de708d0801192046j102eb7d7sf64059e784b9bef3@mail.gmail.com> <604aa7910801192142y5266c0dfh2e82a91246483f69@mail.gmail.com> <16de708d0801192156w2fa69e76v7014057effe8aac4@mail.gmail.com> <479300D5.5020208@gmail.com> Message-ID: <1200860091.20890.70.camel@localhost> On Sun, 2008-01-20 at 00:05 -0800, Andrew Farris wrote: > > I personally think this should be a first level menu myself. An > > immutable one at that. And install of 'uninstalled' might want to say > > 'available' > > Immutable, and first level seems reasonable. The title is debatable, since > 'available' has multiple meanings, and the software is not available to the > person who wants to use it when they click on the menu... its acquirable, its > not yet installed, its offered, but not yet available. If something like > 'Repository Software' was used, that would be clear (but not very 'sophisticated'). Steam refers to this state as "Not Installed". "uninstalled" sounds wrong to me, to me it means "This was installed but now it is not" which is not always true. Are the "Gnome Online Desktop" people looking at Steam at all? I think they're way ahead of us there. Though it only works with games, and only "steam" games at that. And doesn't integrate with existing services, it introduces yet ANOTHER goddamn IM service/client... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ville.skytta at iki.fi Sun Jan 20 20:20:04 2008 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 20 Jan 2008 22:20:04 +0200 Subject: Rebuilds for new Perl? In-Reply-To: <1200858860.7579.31.camel@localhost.localdomain> References: <200801202105.23463.ville.skytta@iki.fi> <200801202150.29395.ville.skytta@iki.fi> <1200858860.7579.31.camel@localhost.localdomain> Message-ID: <200801202220.05126.ville.skytta@iki.fi> On Sunday 20 January 2008, Tom "spot" Callaway wrote: > On Sun, 2008-01-20 at 21:50 +0200, Ville Skytt? wrote: > > On Sunday 20 January 2008, Tom "spot" Callaway wrote: > > > Because everything that depends on perl needs to be rebuilt, > > > > Hmm, that sounds odd to me, could you confirm this? > > > > I'd assume that all packages that ship files in /usr/lib*/perl5 or things > > linked with libperl.so would require a rebuild, but that'd be about it. > > perl packages have: > Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo > $version)) > > (As an aside, I thought this might be autogenerated, but it isn't.) > > This means that they all depend on perl(:MODULE_COMPAT_5.8.8), thus, > need to be rebuilt against perl 5.10.0. Sure, but that "Requires: perl(:MODULE_COMPAT_5.8.8)" should only be in packages that install files to /usr/lib*/perl5/[...] . If other packages have it, the likelihood of a packaging bug is pretty high I think, but nevertheless they do need a rebuild, understood. But surely not *everything* in the distro that depends on perl needs a rebuild? Eg. stuff that just needs /usr/bin/perl or installs some *.pm to their application specific paths and nothing to perl's paths (and nothing that links with libperl.so)? From tcallawa at redhat.com Sun Jan 20 20:31:37 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 20 Jan 2008 15:31:37 -0500 Subject: Rebuilds for new Perl? In-Reply-To: <200801202220.05126.ville.skytta@iki.fi> References: <200801202105.23463.ville.skytta@iki.fi> <200801202150.29395.ville.skytta@iki.fi> <1200858860.7579.31.camel@localhost.localdomain> <200801202220.05126.ville.skytta@iki.fi> Message-ID: <1200861097.7579.36.camel@localhost.localdomain> On Sun, 2008-01-20 at 22:20 +0200, Ville Skytt? wrote: > Sure, but that "Requires: perl(:MODULE_COMPAT_5.8.8)" should only be in > packages that install files to /usr/lib*/perl5/[...] . If other packages > have it, the likelihood of a packaging bug is pretty high I think, but > nevertheless they do need a rebuild, understood. > > But surely not *everything* in the distro that depends on perl needs a > rebuild? Eg. stuff that just needs /usr/bin/perl or installs some *.pm to > their application specific paths and nothing to perl's paths (and nothing > that links with libperl.so)? Everything that has that Requires needs a rebuild, but that Requires may not be needed in all the packages where it is present. I'm not sorting that out right now, just doing a series of rebuilds. :) ~spot From lordmorgul at gmail.com Sun Jan 20 20:38:34 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sun, 20 Jan 2008 12:38:34 -0800 Subject: Unplanned system outage In-Reply-To: <20080120201023.GA11397@ryvius.greysector.net> References: <20080120092519.79e4393f@redhat.com> <200801201111.36790.dennis@ausil.us> <20080120201023.GA11397@ryvius.greysector.net> Message-ID: <4793B14A.5000000@gmail.com> Dominik 'Rathann' Mierzejewski wrote: > On Sunday, 20 January 2008 at 18:11, Dennis Gilmore wrote: >> On Sunday 20 January 2008, Jesse Keating wrote: >>> It appears that we have lost one of our Xen servers for reasons not yet >>> discovered. Systems affected seem to include bodhi, koji, account >>> system, and possibly others. >>> >>> The reason for the outage is still being investigated, as well as >>> attempts to restore service. We're sorry for any inconvenience this >>> may cause. More announcements will be made as services come back >>> on-line. >> Service should now be restored to all services. Please let us know if you have >> issues. > > koji website is (still?) unresponsive as of 20:09 UTC. > > Regards, > R. > Alive to west coast as of 12:38 pst. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From mcepl at redhat.com Sun Jan 20 20:45:36 2008 From: mcepl at redhat.com (Matej Cepl) Date: Sun, 20 Jan 2008 21:45:36 +0100 Subject: An interesting read when discussing what to do about our bugs... References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> Message-ID: On 2008-01-20, 00:56 GMT, Jon Stanley wrote: > On Jan 19, 2008 5:19 PM, Matej Cepl wrote: > >> OK, this is something which should be well described in the >> http://fedoraproject.org/wiki/JonStanley/BugWorkflow (Jon?). > > I've added some stuff, instead of the novel here, I've put the Cliff's > Notes version in :). Let me know if I got something wrong. Thanks, I am sorry to employ as my Cliff ;-), but I would really add as an iron rule, that there always have to be the upstream bug number in the External Bugzilla References, before the bug is closed as UPSTREAM. Matej From peter at thecodergeek.com Sun Jan 20 21:18:05 2008 From: peter at thecodergeek.com (Peter Gordon) Date: Sun, 20 Jan 2008 13:18:05 -0800 Subject: Package EVR problems in Fedora 2008-01-20 In-Reply-To: <20080120194533.8437D152130@buildsys.fedoraproject.org> References: <20080120194533.8437D152130@buildsys.fedoraproject.org> Message-ID: <1200863885.2989.18.camel@tuxhugs> On Sun, 2008-01-20 at 14:45 -0500, buildsys at fedoraproject.org wrote: > caillon AT redhat com: > epiphany-extensions > F8-updates > F9 (0:2.20.1-4.fc8 > 0:2.20.1-3.fc9) Unfortunately, the extensions currently don't build against xulrunner (and 2.20.x extensions won't work with Ephy 2.21.x due to API changes). [1,2] Once this is fixed, the extensions will be updated and rebuilt accordingly. [1] https://bugzilla.redhat.com/show_bug.cgi?id=356731 [2] https://bugzilla.gnome.org/show_bug.cgi?id=508369 > peter AT thecodergeek com: > gnome-theme-clearlooks-bigpack > F7-updates-testing > F9 (0:0.6-7.fc7 > 0:0.6-6.fc8) > F8-updates-testing > F9 (0:0.6-7.fc8 > 0:0.6-6.fc8) This one is a false positive. gnome-theme-clearlooks-bigpack was retired for Fedora 9+ over two months ago (Nov 02) due to lack of upstream activity. I've emailed rel-eng to block this from further dist-f9 inclusion. Thanks. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Sun Jan 20 21:45:49 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Sun, 20 Jan 2008 16:45:49 -0500 Subject: F8 to rawhide upgrade In-Reply-To: References: Message-ID: <1200865549.3275.23.camel@cutter> On Sun, 2008-01-20 at 12:06 -0800, darrell pfeifer wrote: > Yesterday I did a fresh install of F8 on a new machine. Then I > attempted to upgrade it to rawhide. > > I generally update by hand, doing about 4 chunks of packages to do the > upgrade. I usually start by upgrading rpm and yum. > > In current rawhide, yum (or yum utils) has a dependency on a > particular python module, but it the python chunk isn't pulled in by > the yum upgrade. After upgrading yum, yum won't run any more. > > I downgraded the yum packages, did the upgrade, this time with rpm and > yum going last. I was too grouchy to record the exact message. > > So, the short moral, if doing an F8 to rawhide upgrade, leave rpm/yum > for the last. > No dependencies have changed in yum for rawhide. It's the exact same version as that which is in f8. -sv From darrellpf at gmail.com Sun Jan 20 22:04:24 2008 From: darrellpf at gmail.com (darrell pfeifer) Date: Sun, 20 Jan 2008 14:04:24 -0800 Subject: F8 to rawhide upgrade In-Reply-To: <1200865549.3275.23.camel@cutter> References: <1200865549.3275.23.camel@cutter> Message-ID: On Jan 20, 2008 1:45 PM, seth vidal wrote: > > > No dependencies have changed in yum for rawhide. It's the exact same > version as that which is in f8. > > > Darn, I should have written down the message. Is it possible that the rawhide yum uses something in the python libraries that isn't in the older F8 version of python? darrell -------------- next part -------------- An HTML attachment was scrubbed... URL: From lordmorgul at gmail.com Sun Jan 20 22:18:55 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sun, 20 Jan 2008 14:18:55 -0800 Subject: F8 to rawhide upgrade In-Reply-To: References: <1200865549.3275.23.camel@cutter> Message-ID: <8b14d9940801201418p660d223fpd265e8a118056908@mail.gmail.com> 2008/1/20 darrell pfeifer : > > > On Jan 20, 2008 1:45 PM, seth vidal wrote: > > > > > > > No dependencies have changed in yum for rawhide. It's the exact same > > version as that which is in f8. > > > > > > > Darn, I should have written down the message. > > Is it possible that the rawhide yum uses something in the python libraries > that isn't in the older F8 version of python? > > darrell > This is an F8 updates-testing box. 13:17:31 |lordmorgul.CirithUngol:3| |43 files:2.9M@~| |0 jobs| -> rpm -q yum yum-3.2.8-2.fc8.noarch 14:13:45 |lordmorgul.CirithUngol:3| |43 files:2.9M@~| |0 jobs| -> cat /etc/fedora-release Fedora release 8 (Werewolf) 14:11:57 |root:0| |96 files:309M at tmp| |1 jobs| - yum --enablerepo development update yum updates-testing 100% |=========================| 2.3 kB 00:00 livna 100% |=========================| 2.1 kB 00:00 fedora 100% |=========================| 2.1 kB 00:00 development 100% |=========================| 2.2 kB 00:00 primary.sqlite.bz2 100% |=========================| 5.7 MB 00:11 updates 100% |=========================| 2.3 kB 00:00 fusion 100% |=========================| 951 B 00:00 Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package yum.noarch 0:3.2.8-2.fc9 set to be updated --> Finished Dependency Resolution Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Updating: yum noarch 3.2.8-2.fc9 development 509 k Transaction Summary ============================================================================= Install 0 Package(s) Update 1 Package(s) Remove 0 Package(s) Total download size: 509 k Is this ok [y/N]: y Downloading Packages: (1/1): yum-3.2.8-2.fc9.no 100% |=========================| 509 kB 00:01 Running rpm_check_debug Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Updating : yum ######################### [1/2] Cleanup : yum ######################### [2/2] Jan 20 14:14:14 localhost avahi-daemon[2314]:last message repeated 4 times Jan 20 14:14:14 localhost yum: Updated: yum - 3.2.8-2.fc9.noarch Updated: yum.noarch 0:3.2.8-2.fc9 Complete! 14:14:16 |root:0| |96 files:309M at tmp| |1 jobs| - yum list updates Updated Packages buildsys-build-rpmfusion.i686 23-1.lvn8 livna buildsys-build-rpmfusion-kerneldevpkgs-c 23-1.lvn8 livna buildsys-build-rpmfusion-kerneldevpkgs-n 23-1.lvn8 livna kmod-nvidia.i686 169.07-1.lvn8 livna xorg-x11-drv-nvidia.i386 169.07-4.lvn8 livna 14:14:31 |root:0| |96 files:309M at tmp| |1 jobs| No problems with current devel yum on F8 updated (maybe on a base F8 install). -------------- next part -------------- An HTML attachment was scrubbed... URL: From jspaleta at gmail.com Sun Jan 20 23:54:51 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 20 Jan 2008 14:54:51 -0900 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <1200825582.2879.0.camel@sb-home> References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> <1200766980.2961.8.camel@sb-home> <604aa7910801192136u754e6a4ex1c3c0113440c4e02@mail.gmail.com> <1200825582.2879.0.camel@sb-home> Message-ID: <604aa7910801201554v4cd59c92n7b3e1c7c1b393093@mail.gmail.com> On Jan 20, 2008 1:39 AM, nodata wrote: > I'd like you to click the "transfer to upstream bugzilla" button :) That button exists? -jef From ivazqueznet at gmail.com Mon Jan 21 00:12:34 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sun, 20 Jan 2008 19:12:34 -0500 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <604aa7910801201554v4cd59c92n7b3e1c7c1b393093@mail.gmail.com> References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> <1200766980.2961.8.camel@sb-home> <604aa7910801192136u754e6a4ex1c3c0113440c4e02@mail.gmail.com> <1200825582.2879.0.camel@sb-home> <604aa7910801201554v4cd59c92n7b3e1c7c1b393093@mail.gmail.com> Message-ID: <1200874354.11392.0.camel@ignacio.lan> On Sun, 2008-01-20 at 14:54 -0900, Jeff Spaleta wrote: > On Jan 20, 2008 1:39 AM, nodata wrote: > > I'd like you to click the "transfer to upstream bugzilla" button :) > > That button exists? I'm sure if we poke mkanat long/hard enough... -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed From jonstanley at gmail.com Mon Jan 21 00:13:35 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Sun, 20 Jan 2008 19:13:35 -0500 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <604aa7910801201554v4cd59c92n7b3e1c7c1b393093@mail.gmail.com> References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> <1200766980.2961.8.camel@sb-home> <604aa7910801192136u754e6a4ex1c3c0113440c4e02@mail.gmail.com> <1200825582.2879.0.camel@sb-home> <604aa7910801201554v4cd59c92n7b3e1c7c1b393093@mail.gmail.com> Message-ID: It does. It is used when a maintainer (or someone) reports a bug to an upstream bz or whatever. I agree that there needs to be something in the 'External Bugzilla Reference' part when this is used. I'm out watching (American) football at the moment, so if someone could make this change it would be appreciated. On 1/20/08, Jeff Spaleta wrote: > On Jan 20, 2008 1:39 AM, nodata wrote: > > I'd like you to click the "transfer to upstream bugzilla" button :) > > That button exists? > > -jef > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Jon Stanley Fedora Ambassador jstanley at fedoraproject.org From jkeating at redhat.com Mon Jan 21 01:39:10 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 20 Jan 2008 20:39:10 -0500 Subject: Unplanned system outage In-Reply-To: <4793A7EE.1030807@gmail.com> References: <20080120092519.79e4393f@redhat.com> <200801201111.36790.dennis@ausil.us> <4793A7EE.1030807@gmail.com> Message-ID: <20080120203910.44f327d9@redhat.com> On Sun, 20 Jan 2008 11:58:38 -0800 Andrew Farris wrote: > Just for reference, Jesse's email is at 625am pst, and I know koji > was unresponsive at 12am pst today up to 4am (thought hopefully > you're able to trace that down a little better). We've had multiple failures of the Xen host from what I can gather :/ -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mclasen at redhat.com Mon Jan 21 01:52:58 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Sun, 20 Jan 2008 20:52:58 -0500 Subject: Unplanned system outage In-Reply-To: <20080120203910.44f327d9@redhat.com> References: <20080120092519.79e4393f@redhat.com> <200801201111.36790.dennis@ausil.us> <4793A7EE.1030807@gmail.com> <20080120203910.44f327d9@redhat.com> Message-ID: <1200880378.10515.0.camel@localhost.localdomain> On Sun, 2008-01-20 at 20:39 -0500, Jesse Keating wrote: > On Sun, 20 Jan 2008 11:58:38 -0800 > Andrew Farris wrote: > > > Just for reference, Jesse's email is at 625am pst, and I know koji > > was unresponsive at 12am pst today up to 4am (thought hopefully > > you're able to trace that down a little better). > > We've had multiple failures of the Xen host from what I can gather :/ And while koji responds now, it doesn't appear to build anything... From vonbrand at inf.utfsm.cl Mon Jan 21 02:02:23 2008 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Sun, 20 Jan 2008 23:02:23 -0300 Subject: Cast your vote for the Fedora 9 Codename! In-Reply-To: References: <20080116184835.1bddf0f3@zod.rchland.ibm.com> <1200536182.920.64.camel@calliope.phig.org> <200801171318.m0HDGRqx011867@laptop13.inf.utfsm.cl> <1200591438.920.119.camel@calliope.phig.org> <80d7e4090801171805t3abb9651ie8ff1390267c51e@mail.gmail.com> <20080118022457.GA1991@nostromo.devel.redhat.com> <1200664543.10767.119.camel@localhost.localdomain> <20080118105054.354c12e5@zod.rchland.ibm.com> Message-ID: <200801210202.m0L22N3u002984@pincoya.inf.utfsm.cl> Michel Salim wrote: > On Jan 18, 2008 11:50 AM, Josh Boyer wrote: > > On Fri, 18 Jan 2008 08:55:43 -0500 > > Simo Sorce wrote: [...] > > > Aww what happened to my beloved Anubis (not on the list :/) ? > > > > It was pruned by legal. As were many other names. > > > And they did not prune Asperger and Tourette? Not sure that's the kind > of image we want to project. Fully agree. If anything, I'd want to move *away* from an Asperger-syndrome image... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From jkeating at redhat.com Mon Jan 21 02:13:49 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 20 Jan 2008 21:13:49 -0500 Subject: Unplanned system outage In-Reply-To: <1200880378.10515.0.camel@localhost.localdomain> References: <20080120092519.79e4393f@redhat.com> <200801201111.36790.dennis@ausil.us> <4793A7EE.1030807@gmail.com> <20080120203910.44f327d9@redhat.com> <1200880378.10515.0.camel@localhost.localdomain> Message-ID: <20080120211349.44e9406d@redhat.com> On Sun, 20 Jan 2008 20:52:58 -0500 Matthias Clasen wrote: > And while koji responds now, it doesn't appear to build anything... I just fixed that. The builder daemon needed to be restarted after the prolonged hub outage. The builders are now picking up jobs again and will chew through the backlog. In fact 5 builds have just completed. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From raven at themaw.net Mon Jan 21 03:54:43 2008 From: raven at themaw.net (Ian Kent) Date: Mon, 21 Jan 2008 12:54:43 +0900 Subject: blacklisted iwl4965 ?? In-Reply-To: <20080119084021.GA4680@puariko.nirvana> References: <20080118080211.GM29887@angus.ind.WPI.EDU> <20080119084021.GA4680@puariko.nirvana> Message-ID: <1200887683.10357.46.camel@raven.themaw.net> On Sat, 2008-01-19 at 10:40 +0200, Axel Thimm wrote: > On Fri, Jan 18, 2008 at 03:02:11AM -0500, Chuck Anderson wrote: > > I just did a fresh rawhide install and found this in > > /etc/modprobe.d/blacklist: > > > > # don't load iwl4965 by default, bug 245379 > > blacklist iwl4965 > > > > https://bugzilla.redhat.com/show_bug.cgi?id=245379 > > > > Does someone have any better explanation for this than the 6+ month > > old bug report for RHEL 5? What are us iwl4965 users supposed to be > > using? > > You can use the mac/iwl kmdls at ATrpms. I haven't started building > for rawhide yet, but you can rebuild them yourself for any given > kernel. Last time (quite a while ago) I tried to build ATrpms packages I found I was missing something and the packages wouldn't build. What actually is needed to be able to build the srpms from ATrpms? Ian From lkundrak at redhat.com Mon Jan 21 07:10:14 2008 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Mon, 21 Jan 2008 08:10:14 +0100 Subject: mock 0.8.9 will not build anything In-Reply-To: <479399FA.9040709@gmx.net> References: <4790691C.3080605@gmx.net> <1200752442.6945.3.camel@localhost.localdomain> <47926563.1040301@gmx.net> <1200848768.6945.12.camel@localhost.localdomain> <47938562.6040109@gmx.net> <479389F2.6050108@gmx.net> <1200852318.6945.21.camel@localhost.localdomain> <4793947C.9050202@gmx.net> <1200855185.6945.24.camel@localhost.localdomain> <479399FA.9040709@gmx.net> Message-ID: <1200899414.6945.39.camel@localhost.localdomain> On Sun, 2008-01-20 at 19:59 +0100, Frank B?ttner wrote: > Lubomir Kundrak schrieb: > > On Sun, 2008-01-20 at 19:35 +0100, Frank B?ttner wrote: > > > >> So, this line was missing, so I add this. Now I get this error: > >> ERROR: Error performing yum command: /usr/bin/yum --installroot > >> /var/lib/mock/epel-4-i386/root update > > > > Have you removed the buildroot and the cache from /var/lib/mock after > > changing the configuration file? > > > No, > but after do that I get the same error when try to run > mock -r fedora-4-i386-epel init: > mock -r fedora-4-i386-epel init What is in /var/lib/mock/epel-4-i386/root -- is there an installed buildroot? What happens when you run the following by hand (as root)?: /usr/bin/yum --installroot /var/lib/mock/epel-4-i386/root update -- Lubomir Kundrak (Red Hat Security Response Team) From zboszor at freemail.hu Mon Jan 21 08:00:14 2008 From: zboszor at freemail.hu (Zoltan Boszormenyi) Date: Mon, 21 Jan 2008 09:00:14 +0100 Subject: rawhide report: 20080118 changes In-Reply-To: <200801191711.m0JHBcSi017061@porkchop.devel.redhat.com> References: <200801191711.m0JHBcSi017061@porkchop.devel.redhat.com> Message-ID: <4794510E.70409@freemail.hu> Build System ?rta: > kernel-2.6.24-0.157.rc8.fc9 > --------------------------- > * Thu Jan 17 2008 John W. Linville > - More wireless fixes headed for 2.6.24 > - More wireless updates headed for 2.6.25 > > * Wed Jan 16 2008 Kyle McMartin > - 2.6.24-rc8 > > * Wed Jan 16 2008 Dave Airlie > - update r500 patch to remove dup pciids. > > I cannot compile this kernel on Fedora 8 from src.rpm because the install phase errors out saying that "Argument list too long". The attached patch tries to fix it. -------------- next part -------------- A non-text attachment was scrubbed... Name: kernel.spec.patch Type: text/x-patch Size: 706 bytes Desc: not available URL: From andreas.bierfert at lowlatency.de Mon Jan 21 08:06:11 2008 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Mon, 21 Jan 2008 09:06:11 +0100 Subject: Package EVR problems in Fedora 2008-01-20 In-Reply-To: <20080120194533.8437D152130@buildsys.fedoraproject.org> References: <20080120194533.8437D152130@buildsys.fedoraproject.org> Message-ID: <20080121090611.6bf30c00@alkaid.a.lan> On Sun, 20 Jan 2008 14:45:33 -0500 (EST) buildsys at fedoraproject.org wrote: > andreas bierfert AT lowlatency de: > claws-mail > F7-updates-testing > F9 (0:3.2.0-3.fc7 > 0:3.2.0-2.fc9) > F8-updates-testing > F9 (0:3.2.0-3.fc8 > 0:3.2.0-2.fc9) Fixed. - Andreas -- Andreas Bierfert, B.Sc. | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From frank-buettner at gmx.net Mon Jan 21 08:14:09 2008 From: frank-buettner at gmx.net (=?ISO-8859-15?Q?Frank_B=FCttner?=) Date: Mon, 21 Jan 2008 09:14:09 +0100 Subject: mock 0.8.9 will not build anything In-Reply-To: <1200899414.6945.39.camel@localhost.localdomain> References: <4790691C.3080605@gmx.net> <1200752442.6945.3.camel@localhost.localdomain> <47926563.1040301@gmx.net> <1200848768.6945.12.camel@localhost.localdomain> <47938562.6040109@gmx.net> <479389F2.6050108@gmx.net> <1200852318.6945.21.camel@localhost.localdomain> <4793947C.9050202@gmx.net> <1200855185.6945.24.camel@localhost.localdomain> <479399FA.9040709@gmx.net> <1200899414.6945.39.camel@localhost.localdomain> Message-ID: <47945451.4040606@gmx.net> Lubomir Kundrak schrieb: > > What is in /var/lib/mock/epel-4-i386/root -- is there an installed > buildroot? What happens when you run the following by hand (as root)?: No, it is incomplete > /usr/bin/yum --installroot /var/lib/mock/epel-4-i386/root update > fails with: CRITICAL:yum.cli:Config Error: Parsing file failed: File contains no section headers. file: file:///var/lib/mock/epel-4-i386/root//etc/yum.conf, line: 2 "config_opts['plugin_conf']['ccache_enable'] = False\n" -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5766 bytes Desc: S/MIME Cryptographic Signature URL: From tim at niemueller.de Mon Jan 21 08:24:21 2008 From: tim at niemueller.de (Tim Niemueller) Date: Mon, 21 Jan 2008 09:24:21 +0100 Subject: firewall changes for F-9+ In-Reply-To: <1200596751.29217.87.camel@vincent52.localdomain> References: <478E4460.8040805@redhat.com> <1200528472.26259.63.camel@cookie.hadess.net> <20080117131211.GA3940@evileye.atkac.englab.brq.redhat.com> <478F7EA0.30508@niemueller.de> <1200596751.29217.87.camel@vincent52.localdomain> Message-ID: <479456B5.8010104@niemueller.de> Matthew Saltzman schrieb: > On Thu, 2008-01-17 at 17:13 +0100, Tim Niemueller wrote: >> Adam Tkac schrieb: >>>> IpSec and IPP as services don't sound very much like desktop >>>> applications. >> They do if you have a desktop machine sharing a printer. If the >> system-config-printer tool would open up the IPP port automatically when >> you share a printer that would be fine though. > > Does the "sharee" also need the IPP ports open? So a user would need to > explicitly set "show printers shared by other systems" in > s-c-printers--it couldn't be the default. The one who shares has to have the ports open for others to be able to open a connection. For the "Show printers shared by other systems" you need to have udp:631 open or mDNS (not currently the default to use mDNS, but cups broadcast is used instead. Tim -- Tim Niemueller www.niemueller.de ================================================================= Imagination is more important than knowledge. (Albert Einstein) From lkundrak at redhat.com Mon Jan 21 08:36:22 2008 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Mon, 21 Jan 2008 09:36:22 +0100 Subject: mock 0.8.9 will not build anything In-Reply-To: <47945451.4040606@gmx.net> References: <4790691C.3080605@gmx.net> <1200752442.6945.3.camel@localhost.localdomain> <47926563.1040301@gmx.net> <1200848768.6945.12.camel@localhost.localdomain> <47938562.6040109@gmx.net> <479389F2.6050108@gmx.net> <1200852318.6945.21.camel@localhost.localdomain> <4793947C.9050202@gmx.net> <1200855185.6945.24.camel@localhost.localdomain> <479399FA.9040709@gmx.net> <1200899414.6945.39.camel@localhost.localdomain> <47945451.4040606@gmx.net> Message-ID: <1200904582.6945.41.camel@localhost.localdomain> On Mon, 2008-01-21 at 09:14 +0100, Frank B?ttner wrote: > Lubomir Kundrak schrieb: > > > > What is in /var/lib/mock/epel-4-i386/root -- is there an installed > > buildroot? What happens when you run the following by hand (as root)?: > > No, it is incomplete > > /usr/bin/yum --installroot /var/lib/mock/epel-4-i386/root update > > > fails with: > CRITICAL:yum.cli:Config Error: Parsing file failed: File contains no > section headers. > file: file:///var/lib/mock/epel-4-i386/root//etc/yum.conf, line: 2 > "config_opts['plugin_conf']['ccache_enable'] = False\n" Soo... did you really compare your configuration with stock distribution one? Please show me your /etc/mock/fedora-4-i386-epel.cfg. Thanks, -- Lubomir Kundrak (Red Hat Security Response Team) From tim at niemueller.de Mon Jan 21 08:40:45 2008 From: tim at niemueller.de (Tim Niemueller) Date: Mon, 21 Jan 2008 09:40:45 +0100 Subject: firewall changes for F-9+ In-Reply-To: <1200596751.29217.87.camel@vincent52.localdomain> References: <478E4460.8040805@redhat.com> <1200528472.26259.63.camel@cookie.hadess.net> <20080117131211.GA3940@evileye.atkac.englab.brq.redhat.com> <478F7EA0.30508@niemueller.de> <1200596751.29217.87.camel@vincent52.localdomain> Message-ID: <47945A8D.7010000@niemueller.de> I just realized that my previous email was rather short. The current setup for printing and mDNS is perfect for our desktop machines. Let me give you a few impressions of the scenario why it fits so well: We have a central Fedora-based print-server. This uses cups broadcast messages to announce printers. A freshly installed desktop or laptop with udp:631 open will catch these messages and have the printer available, no configuration needed at all! So this port has to be open on the clients to get these auto-configure messages! On our network we make use of mDNS. For example our robots announce there services on the network. So in the control application you can just choose any of the currently available robots and start working, no typing of a robot name needed. For servicing it is also good to see VNC hosts in vinagre. No typing, it just works. About IPSec I'm not completely sure. But we are using a Cisco VPN Concentrator with vpnc. I don't know for sure atm if that is tunneled via UDP or if this needs AH/ESP at all. This should be investigated as this is a service provided by default via NetworkManager-vpnc! So I think having these ports open on a freshly installed desktop in fact makes a lot of sense, because it complements the "just works" ambitions the desktop has. For the IPSec more investigation would be needed if the protocols actually need to be open to establish a client connection. Tim -- Tim Niemueller www.niemueller.de ================================================================= Imagination is more important than knowledge. (Albert Einstein) From frank-buettner at gmx.net Mon Jan 21 08:47:59 2008 From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=) Date: Mon, 21 Jan 2008 09:47:59 +0100 Subject: mock 0.8.9 will not build anything In-Reply-To: <1200904582.6945.41.camel@localhost.localdomain> References: <4790691C.3080605@gmx.net> <1200752442.6945.3.camel@localhost.localdomain> <47926563.1040301@gmx.net> <1200848768.6945.12.camel@localhost.localdomain> <47938562.6040109@gmx.net> <479389F2.6050108@gmx.net> <1200852318.6945.21.camel@localhost.localdomain> <4793947C.9050202@gmx.net> <1200855185.6945.24.camel@localhost.localdomain> <479399FA.9040709@gmx.net> <1200899414.6945.39.camel@localhost.localdomain> <47945451.4040606@gmx.net> <1200904582.6945.41.camel@localhost.localdomain> Message-ID: <47945C3F.7040109@gmx.net> Lubomir Kundrak schrieb: > On Mon, 2008-01-21 at 09:14 +0100, Frank B?ttner wrote: >> Lubomir Kundrak schrieb: >>> What is in /var/lib/mock/epel-4-i386/root -- is there an installed >>> buildroot? What happens when you run the following by hand (as root)?: >> No, it is incomplete >>> /usr/bin/yum --installroot /var/lib/mock/epel-4-i386/root update >>> >> fails with: >> CRITICAL:yum.cli:Config Error: Parsing file failed: File contains no >> section headers. >> file: file:///var/lib/mock/epel-4-i386/root//etc/yum.conf, line: 2 >> "config_opts['plugin_conf']['ccache_enable'] = False\n" > > Soo... did you really compare your configuration with stock distribution > one? Please show me your /etc/mock/fedora-4-i386-epel.cfg. > > Thanks, So here the file for /etc/mock/fedora-4-i386-epel.cfg #!/usr/bin/python -tt import os config_opts['root'] = 'epel-4-i386' config_opts['target_arch'] = 'i386' config_opts['yum.conf'] = """ config_opts['plugin_conf']['ccache_enable'] = False [main] cachedir=/var/cache/yum debuglevel=1 logfile=/var/log/yum.log reposdir=/dev/null retries=20 obsoletes=1 gpgcheck=0 assumeyes=1 # repos [core] name=base #mirrorlist=http://mirrorlist.centos.org/?release=4&arch=i386&repo=os baseurl=file:///Linux/CentOS/4/os/i386/ [update] name=updates #mirrorlist=http://mirrorlist.centos.org/?release=4&arch=i386&repo=updates baseurl=file:///Linux/CentOS/4/updates/i386/ [groups] name=groups baseurl=http://buildsys.fedoraproject.org/buildgroups/rhel4/i386/ [extras] name=epel #mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=epel-4&arch=i386 baseurl=file:///Linux/Fedora/epel/4/i386/ [local] name=local baseurl=http://buildsys.fedoraproject.org/plague-results/fedora-4-epel/ """ I have only change the baseurl to use an local rsync repo in the SAN. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5766 bytes Desc: S/MIME Cryptographic Signature URL: From airlied at redhat.com Mon Jan 21 08:58:50 2008 From: airlied at redhat.com (Dave Airlie) Date: Mon, 21 Jan 2008 18:58:50 +1000 Subject: updated cirrus driver for qemu users.. Message-ID: <1200905930.30347.0.camel@localhost> Someone asked about getting cirrus working again last week, I just got F9 installed into a kvm and fixed up the last bits of it, so it should be in rawhide rsn.. Dave. From jdieter at gmail.com Mon Jan 21 09:19:59 2008 From: jdieter at gmail.com (Jonathan Dieter) Date: Mon, 21 Jan 2008 11:19:59 +0200 Subject: network manager command-line control? In-Reply-To: <1196699870.2447.4.camel@localhost.localdomain> References: <20071203154332.GA13878@jadzia.bu.edu> <1196699870.2447.4.camel@localhost.localdomain> Message-ID: <1200907199.24450.8.camel@jndwidescreen.lesbg.loc> On Mon, 2007-12-03 at 11:37 -0500, Dan Williams wrote: > On Mon, 2007-12-03 at 10:43 -0500, Matthew Miller wrote: > > I want to make sure I'm not missing something before I file an RFE. I'd like > > to be able to enable/disable wireless (or wired, for that matter) networking > > from scripts. The nm-tool program seems like the logical place for this > > functionality, but it doesn't appear to actually have it at this point. > > All the functionality is currently available with dbus-send. However, > since that's the case, it would be nice to have a CLI tool that > interfaces in a nicer manner than dbus-send. I'd like to have something > like that too, but haven't had time to look into it. It would be a > great opportunity for somebody to jump in. Is there a list of (important) dbus methods exported by NM? I'm trying to work out a way of bringing up a wireless network early in the boot process in F8 and have been unable to even get a list of devices. Trying to run (which looks like it's supposed to work in 0.6): >>> import dbus >>> bus = dbus.SystemBus() >>> iface = bus.get_object('org.freedesktop.NetworkManager', '/org/freedesktop/NetworkManager') >>> devs = iface.getDevices(dbus_interface='org.freedesktop.NetworkManager') or >>> devs = iface.getDevices(dbus_interface='org.freedesktop.NetworkManager.Devices') gives me: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method "getDevices" with signature "" on interface "org.freedesktop.NetworkManager" doesn't exist What am I missing? Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From valent.turkovic at gmail.com Mon Jan 21 10:47:39 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Mon, 21 Jan 2008 11:47:39 +0100 Subject: fedora users contribution Message-ID: <64b14b300801210247m3d2b49b3hd80c1be7a8c3630d@mail.gmail.com> Hi, I'm not aware of a better mailing list to bring this issue so if there is please point me to it (fedora-advisory-board? fedora-marketing?). I as a fedora users contribute in ways I can; mainly bug reporting on issues I discover while just using fedora. I don't go actively looking for bugs but I just post ones I find using fedora. I try to use fedora in the most conservative way possible - not installing any rpm outside official repositories if possible (I still need a few that are from livna). I have changed my behavior (I previously installed from wide range of 3rd party repos and custom twaked fedora much more) so that I can be a responsible bug reporter. When I posted RFE[1] "Abillity to remove unwanted partition icons from gnome desktop" I got an answer from Jef Spaleta that was really helpful to me but I recognized that some of less knowledgeable fedora users wouldn't find that answer helpful. Thank you Jef once more for a really informative answer. Coming from a regular fedora desktop user point of view this looks like wrong way of doing things. Knowledgeable fedora users and contributers usually don't have problems with following instructions that experienced fedora devels give them, but still there are others that have. There are fedora users that I believe can be involved in some part making fedora better but aren't because of high learning curve and the lack of knowledge of inner workings of fedora and general linux distros. Take me for example - if Jef haven't told me about 20-storage-methods.fdi I wouldn't know exactly where to look. I have some basic knowledge about hal but that is it. I love getting involved and learning new things in linux but my work and other commitment (running a NGO, local LUG and municipal wireless project) don't give me time needed to get to know in detail all the inner workings of linux and it's sub systems. I also believe that there lots of other users that don't know anything about how linux and fedora work but that also have some suggestion about how to make Fedora and general linux experience better for them (and problaly other people also). I believe that they wouldn't go beyond posting to mailing list or maybe, maybe to bugzilla. I know that this is not up to you, but is there somebody that ordinary users could go and ask for their issues to be looked at and then decided if there is a case for it to be dealt with. When I mean dealt with I mean that that person then contacts the ones responsible for the issue at hand. Fedora devels give really informative responses and I can work with but there are others that can't. What I suggest is that with slight different approach and different organization effort much more of such issues would be dealt in faster way and things would go forward faster and make everybody happy. I don't know in detail how fedora is organized, but I guess that one volonteer or one redhat developer working part time on such issues would make a huge difference. Please let's discuss this and thank you in advance, Valent. [1] https://bugzilla.redhat.com/show_bug.cgi?id=426907 -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From lkundrak at redhat.com Mon Jan 21 11:13:32 2008 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Mon, 21 Jan 2008 12:13:32 +0100 Subject: mock 0.8.9 will not build anything In-Reply-To: <47945C3F.7040109@gmx.net> References: <4790691C.3080605@gmx.net> <1200752442.6945.3.camel@localhost.localdomain> <47926563.1040301@gmx.net> <1200848768.6945.12.camel@localhost.localdomain> <47938562.6040109@gmx.net> <479389F2.6050108@gmx.net> <1200852318.6945.21.camel@localhost.localdomain> <4793947C.9050202@gmx.net> <1200855185.6945.24.camel@localhost.localdomain> <479399FA.9040709@gmx.net> <1200899414.6945.39.camel@localhost.localdomain> <47945451.4040606@gmx.net> <1200904582.6945.41.camel@localhost.localdomain> <47945C3F.7040109@gmx.net> Message-ID: <1200914012.6945.58.camel@localhost.localdomain> Hi Fran, On Mon, 2008-01-21 at 09:47 +0100, Frank B?ttner wrote: > config_opts['yum.conf'] = """ > config_opts['plugin_conf']['ccache_enable'] = False Please switch these two lines. """ marks beginning of a multi-line string, yum.conf in this case, so you added the ccache_enable option line to mock's yum.conf. Thanks, -- Lubomir Kundrak (Red Hat Security Response Team) From choeger at cs.tu-berlin.de Mon Jan 21 11:13:53 2008 From: choeger at cs.tu-berlin.de (=?ISO-8859-1?Q?Christoph_H=F6ger?=) Date: Mon, 21 Jan 2008 12:13:53 +0100 Subject: fedora users contribution In-Reply-To: <64b14b300801210247m3d2b49b3hd80c1be7a8c3630d@mail.gmail.com> References: <64b14b300801210247m3d2b49b3hd80c1be7a8c3630d@mail.gmail.com> Message-ID: <47947E71.708@cs.tu-berlin.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Valent Turkovic schrieb: > Hi, I'm not aware of a better mailing list to bring this issue so if > there is please point me to it (fedora-advisory-board? > fedora-marketing?). > > I as a fedora users contribute in ways I can; mainly bug reporting on > issues I discover while just using fedora. I don't go actively looking > for bugs but I just post ones I find using fedora. I try to use fedora > in the most conservative way possible - not installing any rpm outside > official repositories if possible (I still need a few that are from > livna). I have changed my behavior (I previously installed from wide > range of 3rd party repos and custom twaked fedora much more) so that I > can be a responsible bug reporter. > > When I posted RFE[1] "Abillity to remove unwanted partition icons from > gnome desktop" I got an answer from Jef Spaleta that was really > helpful to me but I recognized that some of less knowledgeable fedora > users wouldn't find that answer helpful. > > Thank you Jef once more for a really informative answer. > > Coming from a regular fedora desktop user point of view this looks > like wrong way of doing things. Knowledgeable fedora users and > contributers usually don't have problems with following instructions > that experienced fedora devels give them, but still there are others > that have. There are fedora users that I believe can be involved in > some part making fedora better but aren't because of high learning > curve and the lack of knowledge of inner workings of fedora and > general linux distros. > > Take me for example - if Jef haven't told me about > 20-storage-methods.fdi I wouldn't know exactly where to look. I have > some basic knowledge about hal but that is it. I love getting involved > and learning new things in linux but my work and other commitment > (running a NGO, local LUG and municipal wireless project) don't give > me time needed to get to know in detail all the inner workings of > linux and it's sub systems. > > I also believe that there lots of other users that don't know anything > about how linux and fedora work but that also have some suggestion > about how to make Fedora and general linux experience better for them > (and problaly other people also). I believe that they wouldn't go > beyond posting to mailing list or maybe, maybe to bugzilla. > > I know that this is not up to you, but is there somebody that ordinary > users could go and ask for their issues to be looked at and then > decided if there is a case for it to be dealt with. When I mean dealt > with I mean that that person then contacts the ones responsible for > the issue at hand. > > Fedora devels give really informative responses and I can work with > but there are others that can't. What I suggest is that with slight > different approach and different organization effort much more of such > issues would be dealt in faster way and things would go forward faster > and make everybody happy. > > I don't know in detail how fedora is organized, but I guess that one > volonteer or one redhat developer working part time on such issues > would make a huge difference. > > Please let's discuss this and thank you in advance, > Valent. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=426907 > Hi, these are problems you are probably always going to have, because the wast majority of people is just not interested in "how things work". This is not wrong from a user friendly point of view but leads to the fact that most users are even unable to ask the right questions or unwilling to read some guidelines. So if you open up a BB or something for newbies, you will probably get 99.9% of questions which are correctly answered by RTFM or are even not understandable. Best way to help those users in particular problems is IMO a direct personal approach with really friendly (and patient) supporters. So I think the best solution would be to encourage those supporters everywhere to translate the problems into geekish and send them to the right points. Although some polls or stuff could help too. christoph -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHlH5xhMBO4cVSGS8RAqJcAJ9gf0+nlw6YyAEg8G2Nvk58lTDG2gCglTRK MFolswliQ2KRWQqQq/3u4f4= =Fx7G -----END PGP SIGNATURE----- From valent.turkovic at gmail.com Mon Jan 21 11:40:51 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Mon, 21 Jan 2008 12:40:51 +0100 Subject: fedora users contribution In-Reply-To: <47947E71.708@cs.tu-berlin.de> References: <64b14b300801210247m3d2b49b3hd80c1be7a8c3630d@mail.gmail.com> <47947E71.708@cs.tu-berlin.de> Message-ID: <64b14b300801210340y18cd39f5ubc2af32667afc10d@mail.gmail.com> > Hi, > > these are problems you are probably always going to have, because the > wast majority of people is just not interested in "how things work". > This is not wrong from a user friendly point of view but leads to the > fact that most users are even unable to ask the right questions or > unwilling to read some guidelines. > So if you open up a BB or something for newbies, you will probably get > 99.9% of questions which are correctly answered by RTFM or are even not > understandable. > Best way to help those users in particular problems is IMO a direct > personal approach with really friendly (and patient) supporters. > So I think the best solution would be to encourage those supporters > everywhere to translate the problems into geekish and send them to the > right points. Although some polls or stuff could help too. > > christoph Geekish LOL :) Back to topic at hand. Are there some efforts from fedora and red hat that do this? I listen to Novell podcast and I hear there that they have user usability studies - I think that fedora and rad hat if aren't doing them already should start doing them ASAP. If there are such efforts please point me in the right direction because I have a few ideas and would like to contribute. Valent -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From lordmorgul at gmail.com Mon Jan 21 11:52:18 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Mon, 21 Jan 2008 03:52:18 -0800 Subject: fedora users contribution In-Reply-To: <47947E71.708@cs.tu-berlin.de> References: <64b14b300801210247m3d2b49b3hd80c1be7a8c3630d@mail.gmail.com> <47947E71.708@cs.tu-berlin.de> Message-ID: <47948772.7080208@gmail.com> Christoph H?ger wrote: > these are problems you are probably always going to have, because the > wast majority of people is just not interested in "how things work". > This is not wrong from a user friendly point of view but leads to the > fact that most users are even unable to ask the right questions or > unwilling to read some guidelines. > So if you open up a BB or something for newbies, you will probably get > 99.9% of questions which are correctly answered by RTFM or are even not > understandable. > Best way to help those users in particular problems is IMO a direct > personal approach with really friendly (and patient) supporters. > So I think the best solution would be to encourage those supporters > everywhere to translate the problems into geekish and send them to the > right points. Although some polls or stuff could help too. The other method that works VERY well for getting feedback with users new to linux is the basic 'HOWTO' wiki or forum that has comments... Thats an area that fedora is lacking compared to many other distros. There is an ever increasing community at fedoraforum.org, which is good, but good howto docs (with ability for users to comment/ask questions) is behind. These docs don't have to be exhaustive, just accurate and specific about doing one thing with specific hardware/software. The people helping out with posting on fedoraforum do need to keep in mind though, anything that really should be brought to devs attention (bz, mailing lists, etc) needs to be done by the person with the answers on the forum, not the guy with the questions. Getting new users into irc is one of the first and best steps as well... Most people that are new wouldn't know what to do with bug reports, followups, closing when they are finished, so thats not really a good format for that kind of info dissemination. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From atkac at redhat.com Mon Jan 21 11:57:38 2008 From: atkac at redhat.com (Adam Tkac) Date: Mon, 21 Jan 2008 12:57:38 +0100 Subject: BIND less restrictive modes and policy Message-ID: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> Hi all, I'm going to do major revision of bind's file modes. Currenly We have many files readable only by root and I can't see any reason why keep binaries unreadable and unexecutable by other users. Also there isn't any reason why keep configuration private. Only this files should not be readable by other users: - /etc/rndc.key - who has it may control server through rndc utility - /var/log/named.log - will have sensitive information All other will be readable for all. Also complete /var/named/* subtree will be writable by named (for generating core files, DDNS updates, secondary servers, generally for easier configuration). Has anyone arguments against such change? Regards, Adam -- Adam Tkac, Red Hat, Inc. From lordmorgul at gmail.com Mon Jan 21 12:13:14 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Mon, 21 Jan 2008 04:13:14 -0800 Subject: BIND less restrictive modes and policy In-Reply-To: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> References: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> Message-ID: <47948C5A.40401@gmail.com> Adam Tkac wrote: > Hi all, > > I'm going to do major revision of bind's file modes. Currenly We have > many files readable only by root and I can't see any reason why keep > binaries unreadable and unexecutable by other users. Also there isn't > any reason why keep configuration private. Only this files should not > be readable by other users: > - /etc/rndc.key - who has it may control server through rndc utility > - /var/log/named.log - will have sensitive information > > All other will be readable for all. Also complete /var/named/* subtree > will be writable by named (for generating core files, DDNS updates, > secondary servers, generally for easier configuration). > > Has anyone arguments against such change? > > Regards, Adam Just a comment, that probably needs to accompany selinux policy adjustments (or rather, without change in policy other users won't have access even with mode changes)? -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From atkac at redhat.com Mon Jan 21 12:15:23 2008 From: atkac at redhat.com (Adam Tkac) Date: Mon, 21 Jan 2008 13:15:23 +0100 Subject: BIND less restrictive modes and policy In-Reply-To: <47948C5A.40401@gmail.com> References: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> <47948C5A.40401@gmail.com> Message-ID: <20080121121523.GA21790@evileye.atkac.englab.brq.redhat.com> On Mon, Jan 21, 2008 at 04:13:14AM -0800, Andrew Farris wrote: > Adam Tkac wrote: >> Hi all, >> >> I'm going to do major revision of bind's file modes. Currenly We have >> many files readable only by root and I can't see any reason why keep >> binaries unreadable and unexecutable by other users. Also there isn't >> any reason why keep configuration private. Only this files should not >> be readable by other users: >> - /etc/rndc.key - who has it may control server through rndc utility >> - /var/log/named.log - will have sensitive information >> >> All other will be readable for all. Also complete /var/named/* subtree >> will be writable by named (for generating core files, DDNS updates, >> secondary servers, generally for easier configuration). >> >> Has anyone arguments against such change? >> >> Regards, Adam > > Just a comment, that probably needs to accompany selinux policy adjustments > (or rather, without change in policy other users won't have access even > with mode changes)? > Definitely. SELinux policy will be changed appropriately. Adam -- Adam Tkac, Red Hat, Inc. From valent.turkovic at gmail.com Mon Jan 21 12:29:08 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Mon, 21 Jan 2008 13:29:08 +0100 Subject: wiki strangeness Message-ID: <64b14b300801210429u91c8fc5tb2813b0f67c5eb76@mail.gmail.com> Hi, is there a mailing list for wiki related issues? If there is please tell me where to go because I couldn't find any reference to it on communicate page. Please look at this link: -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From valent.turkovic at gmail.com Mon Jan 21 12:33:14 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Mon, 21 Jan 2008 13:33:14 +0100 Subject: wiki strangeness In-Reply-To: <64b14b300801210429u91c8fc5tb2813b0f67c5eb76@mail.gmail.com> References: <64b14b300801210429u91c8fc5tb2813b0f67c5eb76@mail.gmail.com> Message-ID: <64b14b300801210433m19599eecodc8627dbeb1accaa@mail.gmail.com> On Jan 21, 2008 1:29 PM, Valent Turkovic wrote: > Hi, > is there a mailing list for wiki related issues? If there is please > tell me where to go because I couldn't find any reference to it on > communicate page. > > Please look at this link: Sorry email got sent out prematurely by mistake. If you look at wiki link [1] you can see that by looking at that page it seams that Fedora 9 has released test 1-4. AFAIK that isn't the case. And if you click on Annonuncement link [2] there Fedora 7 is mentioned and not Fedora 9. This is really confusing. [1] http://fedoraproject.org/wiki/Releases/9/Test [2] http://fedoraproject.org/wiki/Releases/9/Test/F9Test1/Announcement ps. is there a way to get an iso snapshot of current rawhide before test 1 comes out? Cheers, Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From vlada at fedora.org.nz Mon Jan 21 13:01:04 2008 From: vlada at fedora.org.nz (Vladimir N Kosovac) Date: Tue, 22 Jan 2008 02:01:04 +1300 Subject: wiki strangeness In-Reply-To: <64b14b300801210433m19599eecodc8627dbeb1accaa@mail.gmail.com> References: <64b14b300801210429u91c8fc5tb2813b0f67c5eb76@mail.gmail.com> <64b14b300801210433m19599eecodc8627dbeb1accaa@mail.gmail.com> Message-ID: <1200920464.19265.7.camel@nebula> On Mon, 2008-01-21 at 13:33 +0100, Valent Turkovic wrote: > On Jan 21, 2008 1:29 PM, Valent Turkovic wrote: > > Hi, > > is there a mailing list for wiki related issues? If there is please > > tell me where to go because I couldn't find any reference to it on > > communicate page. > > > > Please look at this link: > > Sorry email got sent out prematurely by mistake. > > If you look at wiki link [1] you can see that by looking at that page > it seams that Fedora 9 has released test 1-4. AFAIK that isn't the > case. > And if you click on Annonuncement link [2] there Fedora 7 is mentioned > and not Fedora 9. This is really confusing. > > [1] http://fedoraproject.org/wiki/Releases/9/Test > [2] http://fedoraproject.org/wiki/Releases/9/Test/F9Test1/Announcement > It hasn't been released yet and I believe the schedule is pushed for 1 week. Pages you are looking at must be copies of the old release pages, waiting editing for f9. http://fedoraproject.org/wiki/Releases/9 most likely contains current information. The best way to find answers related to wiki would be to send an email to: fedora-docs-list at redhat.com Cheers, Vladimir > ps. is there a way to get an iso snapshot of current rawhide before > test 1 comes out? > > Cheers, > Valent. > > -- > http://kernelreloaded.blog385.com/ > linux, blog, anime, spirituality, windsurf, wireless > registered as user #367004 with the Linux Counter, http://counter.li.org. > ICQ: 2125241, Skype: valent.turkovic > From laroche at redhat.com Mon Jan 21 13:19:02 2008 From: laroche at redhat.com (Florian La Roche) Date: Mon, 21 Jan 2008 14:19:02 +0100 Subject: BIND less restrictive modes and policy In-Reply-To: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> References: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> Message-ID: <20080121131902.GA12493@dudweiler.stuttgart.redhat.com> Hello Adam, On Mon, Jan 21, 2008 at 12:57:38PM +0100, Adam Tkac wrote: > Hi all, > > I'm going to do major revision of bind's file modes. Currenly We have > many files readable only by root and I can't see any reason why keep > binaries unreadable and unexecutable by other users. Also there isn't > any reason why keep configuration private. Only this files should not > be readable by other users: > - /etc/rndc.key - who has it may control server through rndc utility > - /var/log/named.log - will have sensitive information ok > > All other will be readable for all. Also complete /var/named/* subtree > will be writable by named (for generating core files, DDNS updates, > secondary servers, generally for easier configuration). > > Has anyone arguments against such change? Would it be possible to keep write access within subdirs, so that it e.g. is possible to keep master named files owned by root.root? (Not sure this buys anything, but still looks good...) regards, Florian La Roche From jwboyer at gmail.com Mon Jan 21 13:23:59 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 21 Jan 2008 07:23:59 -0600 Subject: wiki strangeness In-Reply-To: <64b14b300801210433m19599eecodc8627dbeb1accaa@mail.gmail.com> References: <64b14b300801210429u91c8fc5tb2813b0f67c5eb76@mail.gmail.com> <64b14b300801210433m19599eecodc8627dbeb1accaa@mail.gmail.com> Message-ID: <20080121072359.0838303b@zod.rchland.ibm.com> On Mon, 21 Jan 2008 13:33:14 +0100 "Valent Turkovic" wrote: > ps. is there a way to get an iso snapshot of current rawhide before > test 1 comes out? You can use pungi to create your own. And there is not going to be a test 1. It's been dubbed Alpha. Followed by Beta, and then ReleaseCandidate(s) (RC). josh From frank-buettner at gmx.net Mon Jan 21 13:36:22 2008 From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=) Date: Mon, 21 Jan 2008 14:36:22 +0100 Subject: [solved]Re: mock 0.8.9 will not build anything In-Reply-To: <1200914012.6945.58.camel@localhost.localdomain> References: <4790691C.3080605@gmx.net> <1200752442.6945.3.camel@localhost.localdomain> <47926563.1040301@gmx.net> <1200848768.6945.12.camel@localhost.localdomain> <47938562.6040109@gmx.net> <479389F2.6050108@gmx.net> <1200852318.6945.21.camel@localhost.localdomain> <4793947C.9050202@gmx.net> <1200855185.6945.24.camel@localhost.localdomain> <479399FA.9040709@gmx.net> <1200899414.6945.39.camel@localhost.localdomain> <47945451.4040606@gmx.net> <1200904582.6945.41.camel@localhost.localdomain> <47945C3F.7040109@gmx.net> <1200914012.6945.58.camel@localhost.localdomain> Message-ID: <47949FD6.7070300@gmx.net> Lubomir Kundrak schrieb: > Hi Fran, > > On Mon, 2008-01-21 at 09:47 +0100, Frank B?ttner wrote: >> config_opts['yum.conf'] = """ >> config_opts['plugin_conf']['ccache_enable'] = False > > Please switch these two lines. > > """ marks beginning of a multi-line string, yum.conf in this case, so > you added the ccache_enable option line to mock's yum.conf. > > Thanks, Yes now it work's. The goal is, that for /etc/mock/fedora-4-i386-epel.cfg the line config_opts['plugin_conf']['ccache_enable'] = False must be included, because by default at /etc/mock/defaults.cfg ccaache is enabled, but at the epel 4 repo ccache is not available. ccache is only available for EPEL5,F7,F8 and devel. Thanks for the help:) Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5766 bytes Desc: S/MIME Cryptographic Signature URL: From buildsys at redhat.com Mon Jan 21 13:47:13 2008 From: buildsys at redhat.com (Build System) Date: Mon, 21 Jan 2008 08:47:13 -0500 Subject: rawhide report: 20080121 changes Message-ID: <200801211347.m0LDlDdL003678@porkchop.devel.redhat.com> New package R-affyio Tools for parsing Affymetrix data files New package R-hgu95av2probe Probe sequence data for microarrays of type hgu95av2 New package R-maanova Analysis of N-dye Micro Array using mixed model effect New package R-pls Multivariate regression by PLSR and PCR New package kscope KDE front-end to Cscope New package libdc1394 1394-based digital camera control library New package libfishsound Simple programming interface for Xiph.Org codecs New package libical Reference implementation of the iCalendar data type and serialization format New package metacafe-dl Command-line program to download videos from metacafe.com New package mogilefs-server Server part of the MogileFS distributed filesystem New package trac-monotone-plugin Monotone version control plugin for Trac New package wklej A wklej.org submitter Removed package gnome-theme-clearlooks-bigpack Updated Packages: PackageKit-0.1.6-1.fc9 ---------------------- * Sat Jan 19 2008 Robin Norwood - 0.1.6-1 - Update to latest upstream version: 0.1.6 adplay-1.6-3.fc9 ---------------- * Sat Jan 19 2008 Linus Walleij 1.6-3 - Rebuild to match new glibc ABI. alsa-plugins-1.0.15-1.fc9 ------------------------- * Fri Jan 18 2008 Eric Moret - 1.0.15-1 - Update to upstream 1.0.15 (#429249) - Add "Requires: pulseaudio" to alsa-plugins-pulseaudio (#368891) - Fix pulse_hw_params() when state is SND_PCM_STATE_PREPARED (#428030) - run /sbin/ldconfig on post and postun macros * Thu Oct 18 2007 Lennart Poettering - 1.0.14-6 - Merge the whole /etc/alsa/pcm/pulseaudio.conf stuff into /etc/alsa/pulse-default.conf, because the former is practically always ignored, since it is not referenced for inclusion by any other configuration file fragment (#251943) The other fragments installed in /etc/alsa/pcm/ are useless, too. But since we are in a freeze and they are not that important, I am not fixing this now. aspell-sk-2.00-3.fc9 -------------------- * Thu Nov 01 2007 Jan ONDREJ (SAL) - 2.00-3 - update upstream - updated license to upstream - inspired by aspell-en (used aspellversion macro) audio-convert-mod-3.45.2-3.fc9 ------------------------------ * Sat Jan 19 2008 Stewart Adam 3.45.2-3 - Rebuild audit-1.6.6-1.fc9 ----------------- * Sat Jan 19 2008 Steve Grubb 1.6.6-1 - Add prelude IDS plugin for IDMEF alerts - Add --user option to aulastlog command - Use desktop-file-install for system-config-audit - Avoid touching auditd.conf most of the time (#408501) autofs-1:5.0.3-3 ---------------- * Mon Jan 21 2008 Ian Kent - 5.0.3-3 - catch "-xfn" map type and issue "no supported" message. - another correction for handling of LDAP base dns with spaces. dbus-python-0.82.4-1.fc9 ------------------------ * Sun Jan 20 2008 Matthias Clasen - 0.82.4-1 - Update to 0.82.4 dejavu-fonts-2.23-1.fc9 ----------------------- * Sun Jan 20 2008 ??? 2.23-1 ??? 2.23 final deluge-0.5.8.1-1.fc9 -------------------- * Sat Jan 19 2008 Peter Gordon - 0.5.8.1-1 - Update to new upstream bugfix release (0.5.8.1) diveintopython-5.4-8.fc9 ------------------------ * Sat Jan 19 2008 Marc Wiriadisastra - 5.4-8 - Removed multiple desktop-files - Made the default version the pdf version - Added build requires check so it can build on F7 * Sat Jan 19 2008 Marc Wiriadisastra - 5.4-7 - Fixed spec file to install the txt version in the txt folder (bug #429239) - Added diveintopython.png to desktop file in txt version - Fixed desktop files to relate to each individual package more. (bug #429239) extrema-4.3.4-1.fc9 ------------------- * Sun Jan 06 2008 Terje Rosten - 4.3.4-1 - 4.3.4 - Drop gcc43 patch, upstream now * Sun Jan 06 2008 Terje Rosten - 4.3.1-1 - 4.3.1 - Add patch to build with gcc 4.3 * Sun Nov 18 2007 Terje Rosten - 4.2.10-3 - Add req. on help subpackage fbreader-0.8.12-1.fc9 --------------------- * Sun Jan 20 2008 Michel Salim - 0.8.12-1 - Update to 0.8.12 gdesklets-calendar-0.60-1.fc9 ----------------------------- * Sat Jan 19 2008 Tyler Owen - 0.60-1 - Updated to 0.6 (naming package 0.60 for EVR to be newer) gdesklets-quote-of-the-day-1.1-1.fc9 ------------------------------------ * Sat Jan 19 2008 Tyler Owen - 1.1-1 - Update to 1.1 - Update license tag gg2-2.3.0-6.fc9 --------------- * Sun Jan 20 2008 Dominik Mierzejewski 2.3.0-6 - fixed missing BR gnome-applets-1:2.21.4-2.fc9 ---------------------------- * Sun Jan 20 2008 Matthias Clasen - 1:2.21.4-2 - Make the weather applet find locations.xml again gnome-packagekit-0.1.6-1.fc9 ---------------------------- * Sat Jan 19 2008 Robin Norwood - 0.1.6-1 - Update to latest upstream version: 0.1.6 gnomesword-2.3.3-1.fc9 ---------------------- * Sun Jan 20 2008 Deji Akingunola - 2.3.3-1 - Update to 2.3.3 gstreamer-plugins-base-0.10.15-3.fc9 ------------------------------------ * Sun Jan 20 2008 Matthias Clasen - 0.10.15-3 - Fix upgrade path gthumb-2.10.8-1.fc9 ------------------- * Sun Jan 20 2008 Matthias Clasen - 2.10.8-1 - Update to 2.10.8 haproxy-1.3.14.2-1.fc9 ---------------------- * Sun Jan 20 2008 Jeremy Hinegardner - 1.3.14.2-1 - update to 1.3.14.2 - update make flags that changed with this upstream release - added man page installation icewm-1.2.35-2.fc9 ------------------ * Sat Jan 19 2008 - 1.2.35-2 - 1.2.35. - Disable xorg-x11-fonts-truetype in -devel. jabbim-0.3-1.fc9 ---------------- * Thu Jan 17 2008 Michal Schmidt - 0.3-1 - Upstream release 0.3 "PERUN". kde-settings-4.0-9.fc9 ---------------------- * Sat Jan 19 2008 Kevin Kofler - 4.0-9 - kdeglobals: also set K3Spell_Client=4 and K3Spell_Encoding=11 kdelibs-6:4.0.0-2.fc9 --------------------- * Sat Jan 19 2008 Kevin Kofler 4.0.0-2 - patch K3Spell for hunspell support on F9+ (FeatureDictionary, kde#154561) libnetfilter_conntrack-0.0.82-1.fc9 ----------------------------------- * Sun Jan 20 2008 Paul P. Komkoff Jr - 0.0.82-1 - new upstream version librsvg2-2.20.0-1.fc9 --------------------- * Sun Jan 20 2008 Matthias Clasen - 2.20.0-1 - Update to 2.20.0 lvm2-2.02.31-7.fc9 ------------------ * Sat Jan 19 2008 Alasdair Kergon > - 2.02.31-7 - Avoid readahead error message when using default setting of lvcreate -M1. - Fix lvcreate --nosync not to wait for non-happening sync. - Add very_verbose lvconvert messages. mantis-1.1.1-1.fc9 ------------------ * Sat Jan 19 2008 Gianluca Sforna - 1.1.1-1 - new upstream release - Add more info in README.Fedora about configuration, upgrades and SELinux mkinitrd-6.0.28-3.fc9 --------------------- * Sat Jan 19 2008 Jeremy Katz - 6.0.28-3 - Don't call lvm.static -- it no longer exists nginx-0.5.35-1.fc9 ------------------ * Sat Jan 19 2008 Jeremy Hinegardner - 0.5.35-1 - update to 0.5.35 obexftp-0.22-0.7.rc9.fc9 ------------------------ * Sun Jan 20 2008 Dominik Mierzejewski - 0.22-0.7.rc9 - include python egg-info in the file list * Tue Jan 01 2008 Dominik Mierzejewski - 0.22-0.6.rc9 - updated to 0.22-rc9 openoffice.org-1:2.4.0-3.2.fc9 ------------------------------ * Sat Jan 19 2008 Caolan McNamara - 1:2.4.0-3.2 - Resolves: rhbz#429258 openoffice.org-2.4.0.ooo85385.svtools.a11ycrash.patch * Wed Jan 16 2008 Caolan McNamara - 1:2.4.0-3.1 - Resolves: rhbz#428655 workspace.sw8u10bf04.patch - Resolves: rhbz#428655 workspace.impress132.patch - fix word2 import - Lithuanian help content * Tue Jan 15 2008 Caolan McNamara - 1:2.4.0-2.2 - fix hyphenation pam_mysql-1:0.7-0.4.rc1.fc9 --------------------------- * Sat Jan 19 2008 Paul P. Komkoff Jr - 0.7-0.4.rc1.1 - more packaging fixes and one segfault bugfix * Wed Jan 09 2008 lonely wolf - 0.7-0.3.rc1.1 - couple of fixes * Thu Dec 06 2007 Release Engineering - 0.7-0.2.rc1 - Rebuild for deps perl-PDF-API2-0.69-1.fc9 ------------------------ * Fri Jan 18 2008 Bernard Johnson - 0.69-1 - 0.69 perl-XML-LibXSLT-1.63-2.fc9 --------------------------- * Sat Jan 19 2008 Zing - 1.63-2 - build requires gdbm-devel * Fri Jan 18 2008 Zing - 1.63-1 - update to 1.63 postgresql-pgpool-II-2.0.1-2.fc9 -------------------------------- * Sat Jan 19 2008 Devrim Gunduz 2.0.1-2 - Fix Requires of -devel package, per bz#429436 * Sun Jan 13 2008 Devrim Gunduz 2.0.1-1 - Update to 2.0.1 - Add a temp patch that will disappear in 2.0.2 * Tue Oct 23 2007 Devrim Gunduz 1.3-1 - Update to 1.3 prelude-manager-0.9.10-2.fc9 ---------------------------- * Sat Jan 19 2008 Steve Grubb 0.9.10-2 - Adjust start/stop priority python-exif-1.0.7-2.fc9 ----------------------- * Sat Jan 19 2008 Terje Rosten - 1.0.7-2 - Improve setup.py python-pyblock-0.30-2 --------------------- * Sat Jan 19 2008 Peter Jones - 0.30-2 - Rebuild for broken deps. quarticurve-kwin-theme-0.0-0.3.beta3.fc9 ---------------------------------------- ragel-6.0-1.fc9 --------------- * Sat Jan 19 2008 Jeremy Hinegardner - 6.0-1 - update to 6.0 * Sun Jan 06 2008 Jeremy Hinegardner - 5.25-1 - update to 5.25 * Tue Sep 18 2007 Jeremy Hinegardner - 5.24-1 - update to 5.24 - update License tag remind-03.01.03-1.fc9 --------------------- * Sun Jan 20 2008 Ray Van Dolson - 03.01.03-1 - Updated to version 03.01.03 rss2email-2.62-1.1 ------------------ * Sat Jan 19 2008 Thorsten Leemhuis - 2.62-1 - Update to 2.62 sabayon-2.21.0-1.fc9 -------------------- * Sun Jan 20 2008 Matthias Clasen - 2.21.0-1 - Update to 2.21.0 sepostgresql-8.3RC2-2.52.beta.fc9 --------------------------------- * Sun Jan 20 2008 - sepostgresql-8.3RC2-2.52 - shares /usr/lib/pgsql/*.so libraries, with original postgresql. * Thu Jan 10 2008 - sepostgresql-8.3RC1-2.37 - add sepg_dump/sepg_dumpall support for 8.3base package. * Mon Nov 26 2007 - 8.3beta3-2.0 - Branch from 8.2.x tree slim-1.3.0-2.fc9 ---------------- * Sat Jan 19 2008 Anders F Bjorklund 1.3.0-2 - rebuild synce-sync-engine-0.11-5.fc9 ---------------------------- * Sat Jan 19 2008 Andreas Bierfert - 0.11-5 - fix obsoletes * Fri Jan 18 2008 Andreas Bierfert - 0.11-4 - split opensync plugin - include a default config.xml in doc system-config-nfs-1.3.36-1.fc9 ------------------------------ * Fri Jan 18 2008 Nils Philippsen - 1.3.36-1 - migrate online help to yelp/Docbook XML translate-toolkit-1.0.1-1.fc9 ----------------------------- * Mon Jan 21 2008 Jens Petersen - 1.0.1-1 - update license field to GPLv2+ - update to 1.0.1 with changes from Dwayne Bailey (#315021): * Thu Dec 20 2007 Dwayne Bailey - Update spec to upstream 1.0.1 - Update patch for Python 2.5 ElementTree - Cleanup the doc installation - Create man pages - Update description * Sat May 05 2007 Roozbeh Pournader - 0.11-1 - Update to upstream 0.11, adding HTML documentation vala-0.1.6-1.fc9 ---------------- * Sat Jan 19 2008 Michel Salim - 0.1.6-1 - Update to 0.1.6 - Revert vapi addition, needed declarations have been inlined (r846) - Rename -docs subpackage to -doc, to comply with guidelines vdr-1.4.7-7.fc9 --------------- * Sat Jan 12 2008 Ville Skytt?? - 1.4.7-7 - Include Udo Richter's hard link cutter patch v0.2.0 (see README-HLCUTTER). - Add some plugins to the default plugin order list in sysconfig. - Minor runvdr cleanups. * Wed Oct 17 2007 Ville Skytt?? - 1.4.7-6 - Add patch to start playback from recordings menu with the play button. * Fri Oct 12 2007 Ville Skytt?? - 1.4.7-5 - Fix init script not to start a new vdr if it's already running (#247089). - Update subtitles+ttxtsubs patch to Rolf's latest revision. vdr-femon-1.1.5-1.fc9 --------------------- * Sun Jan 20 2008 Ville Skytt?? - 1.1.5-1 - 1.1.5. veusz-1.0-2.fc9 --------------- * Sat Dec 20 2008 Jeremy Sanders - 1.0-2 - Package egg file * Sat Dec 20 2008 Jeremy Sanders - 1.0-1 - Update to Veusz-1.0 (now based on PyQt4/numpy) wf-0.41-1.fc9 ------------- xdvik-22.84.13-9.fc9 -------------------- * Mon Jan 21 2008 Jonathan G. Underwood - 22.84.13-9 - Add patch to fix segfault on double full screen toggle BZ 429429 (Michal Jaegermann) * Sat Jan 19 2008 Jonathan G. Underwood - 22.84.13-8 - Add patch to fix spelling errors in manpage, derived from patch by A. Costa (BZ 429396) xmms-adplug-1.2-6.fc9 --------------------- * Sat Jan 19 2008 Linus Walleij 1.2-6 - Rebuild for new glibc ABI. xtide-2.10-0.1.RC1.fc9 ---------------------- * Sat Jan 19 2008 Mamoru Tasaka - 2.10-0.1.RC1 - Try 2.10 RC1 zenity-2.20.1-2.fc9 ------------------- * Sun Jan 20 2008 Matthias Clasen - 2.20.1-2 - Rebuild to fix upgrade path Broken deps for i386 ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.i386 requires libgtkembedmoz.so epiphany-extensions - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.i386 requires libgtkembedmoz.so gnome-web-photo - 0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 icewm - 1.2.35-2.fc9.i386 requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 qt-recordmydesktop - 0.3.6-4.fc9.noarch requires recordmydesktop = 0:0.3.6 Broken deps for x86_64 ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) icewm - 1.2.35-2.fc9.x86_64 requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 qt-recordmydesktop - 0.3.6-4.fc9.noarch requires recordmydesktop = 0:0.3.6 Broken deps for ppc ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.ppc requires libgtkembedmoz.so epiphany-extensions - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.ppc requires libgtkembedmoz.so gnome-web-photo - 0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 icewm - 1.2.35-2.fc9.ppc requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 monodevelop - 0.17-4.fc9.ppc requires boo qt-recordmydesktop - 0.3.6-4.fc9.noarch requires recordmydesktop = 0:0.3.6 Broken deps for ppc64 ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) icewm - 1.2.35-2.fc9.ppc64 requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 perl-Test-AutoBuild-darcs - 1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 qt-recordmydesktop - 0.3.6-4.fc9.noarch requires recordmydesktop = 0:0.3.6 From valent.turkovic at gmail.com Mon Jan 21 13:53:08 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Mon, 21 Jan 2008 14:53:08 +0100 Subject: wiki strangeness In-Reply-To: <20080121072359.0838303b@zod.rchland.ibm.com> References: <64b14b300801210429u91c8fc5tb2813b0f67c5eb76@mail.gmail.com> <64b14b300801210433m19599eecodc8627dbeb1accaa@mail.gmail.com> <20080121072359.0838303b@zod.rchland.ibm.com> Message-ID: <64b14b300801210553h302e635cnf095459cfe8c6c04@mail.gmail.com> On Jan 21, 2008 2:23 PM, Josh Boyer wrote: > On Mon, 21 Jan 2008 13:33:14 +0100 > "Valent Turkovic" wrote: > > > ps. is there a way to get an iso snapshot of current rawhide before > > test 1 comes out? > > You can use pungi to create your own. > Easier said than done. I looked at man page and at pungi online documentation and I can't find relevant info on how to make rawhide just how to make fedora 8 custom versions. Also I can't find any resource (google included) with relevant info - how much space is needed to make "default" build of latest fedora and of latest rawhide. Are there any blogs that are under google's radar that you know of that show the process of making iso files using pungi. Thank you, Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From valent.turkovic at gmail.com Mon Jan 21 13:53:53 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Mon, 21 Jan 2008 14:53:53 +0100 Subject: wiki strangeness In-Reply-To: <64b14b300801210553h302e635cnf095459cfe8c6c04@mail.gmail.com> References: <64b14b300801210429u91c8fc5tb2813b0f67c5eb76@mail.gmail.com> <64b14b300801210433m19599eecodc8627dbeb1accaa@mail.gmail.com> <20080121072359.0838303b@zod.rchland.ibm.com> <64b14b300801210553h302e635cnf095459cfe8c6c04@mail.gmail.com> Message-ID: <64b14b300801210553p5fa9f39bw9b303f85e8900d15@mail.gmail.com> On Jan 21, 2008 2:53 PM, Valent Turkovic wrote: > On Jan 21, 2008 2:23 PM, Josh Boyer wrote: > > On Mon, 21 Jan 2008 13:33:14 +0100 > > "Valent Turkovic" wrote: > > > > > ps. is there a way to get an iso snapshot of current rawhide before > > > test 1 comes out? > > > > You can use pungi to create your own. > > > > Easier said than done. > I looked at man page and at pungi online documentation and I can't > find relevant info on how to make rawhide just how to make fedora 8 > custom versions. > Also I can't find any resource (google included) with relevant info - > how much space is needed to make "default" build of latest fedora and > of latest rawhide. Are there any blogs that are under google's radar > that you know of that show the process of making iso files using > pungi. > > Thank you, > > Valent. Also how can I make rawhide version of Fedora Desktop spin? -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From sgrubb at redhat.com Mon Jan 21 13:55:55 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Mon, 21 Jan 2008 08:55:55 -0500 Subject: BIND less restrictive modes and policy In-Reply-To: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> References: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> Message-ID: <200801210855.56090.sgrubb@redhat.com> On Monday 21 January 2008 06:57:38 Adam Tkac wrote: > I'm going to do major revision of bind's file modes. Currenly We have > many files readable only by root and I can't see any reason why keep > binaries unreadable and unexecutable by other users. What other users would be sharing a DNS server? named is traditionally used only on servers. It is a high value target for hackers. If they can get the DNS server, they can alter where all users go when they are surfing the web (think mega-phishing attack). If an intruder gets access to the DNS server, they are going after named. DNS servers are constantly under attack. > Also there isn't any reason why keep configuration private. Only this files > should not be readable by other users: > - /etc/rndc.key - who has it may control server through rndc utility > - /var/log/named.log - will have sensitive information I'd keep all the configuration private. For what reason would you make a high value target less secure? -Steve From valent.turkovic at gmail.com Mon Jan 21 14:04:14 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Mon, 21 Jan 2008 15:04:14 +0100 Subject: wiki strangeness In-Reply-To: <64b14b300801210553p5fa9f39bw9b303f85e8900d15@mail.gmail.com> References: <64b14b300801210429u91c8fc5tb2813b0f67c5eb76@mail.gmail.com> <64b14b300801210433m19599eecodc8627dbeb1accaa@mail.gmail.com> <20080121072359.0838303b@zod.rchland.ibm.com> <64b14b300801210553h302e635cnf095459cfe8c6c04@mail.gmail.com> <64b14b300801210553p5fa9f39bw9b303f85e8900d15@mail.gmail.com> Message-ID: <64b14b300801210604u5e4c79f0rea540d44058389c5@mail.gmail.com> http://fedoraproject.org/wiki/Releases/FeatureUsePungi unfortunately wiki isn't too helpful :( -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From atkac at redhat.com Mon Jan 21 14:30:01 2008 From: atkac at redhat.com (Adam Tkac) Date: Mon, 21 Jan 2008 15:30:01 +0100 Subject: BIND less restrictive modes and policy In-Reply-To: <200801210855.56090.sgrubb@redhat.com> References: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> <200801210855.56090.sgrubb@redhat.com> Message-ID: <20080121143001.GA22823@evileye.atkac.englab.brq.redhat.com> On Mon, Jan 21, 2008 at 08:55:55AM -0500, Steve Grubb wrote: > On Monday 21 January 2008 06:57:38 Adam Tkac wrote: > > I'm going to do major revision of bind's file modes. Currenly We have > > many files readable only by root and I can't see any reason why keep > > binaries unreadable and unexecutable by other users. > > What other users would be sharing a DNS server? named is traditionally used > only on servers. It is a high value target for hackers. If they can get the > DNS server, they can alter where all users go when they are surfing the web > (think mega-phishing attack). If an intruder gets access to the DNS server, > they are going after named. DNS servers are constantly under attack. Yes I know it. But I really don't know why We should keep binaries non-readable for users. Source is open so why you need non-readable binaries? > > > Also there isn't any reason why keep configuration private. Only this files > > should not be readable by other users: > > - /etc/rndc.key - who has it may control server through rndc utility > > - /var/log/named.log - will have sensitive information > > I'd keep all the configuration private. For what reason would you make a high > value target less secure? Generally on production servers only administrators have access so I don't think this is security issue. I think it's only feeling that configuration has to be private but I'm ready keep config files private if you think it really makes sence. But if some flaw is found and exploited it can't protect you. Adam -- Adam Tkac, Red Hat, Inc. From cmadams at hiwaay.net Mon Jan 21 14:34:02 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 21 Jan 2008 08:34:02 -0600 Subject: BIND less restrictive modes and policy In-Reply-To: <20080121143001.GA22823@evileye.atkac.englab.brq.redhat.com> References: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> <200801210855.56090.sgrubb@redhat.com> <20080121143001.GA22823@evileye.atkac.englab.brq.redhat.com> Message-ID: <20080121143402.GB1491367@hiwaay.net> Once upon a time, Adam Tkac said: > Generally on production servers only administrators have access so I > don't think this is security issue. I think it's only feeling that > configuration has to be private but I'm ready keep config files private > if you think it really makes sence. But if some flaw is found and > exploited it can't protect you. Many servers don't just run one service (e.g. shared web hosting servers will run HTTP, SMTP, DNS, etc.), so the config should be protected. Anything else might as well be world-readable though (and this is really true for any non-config/non-log file in any RPM), since they can easily be downloaded through "teh intertubes". -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jakub.rusinek at gmail.com Mon Jan 21 14:47:19 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Mon, 21 Jan 2008 15:47:19 +0100 Subject: rpmlint: "non-conffile-in-etc" Message-ID: <5e92ee3f0801210647g7f8ce2f9x6c25f6ee2ac34e2b@mail.gmail.com> Hi, I'm packaging gnome-main-menu applet from SVN and have only one issue displayed by rpmlint. gnome-main-menu.i386: W: non-conffile-in-etc /etc/gconf/schemas/application-browser.schemas gnome-main-menu.i386: W: non-conffile-in-etc /etc/gconf/schemas/slab.schemas In bugzilla's review request [1] non-conffile-in-etc was fixed by marking file as %config. compiz [2] has gconf schemas files too, but it has no %config and schemas normally in %files. Please, tell me, what should I do. My SPEC [3]. 1| https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188359 2| http://cvs.fedoraproject.org/viewcvs/rpms/compiz/F-8/compiz.spec?view=markup 3| http://phpfi.com/291200 -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ From vonbrand at inf.utfsm.cl Mon Jan 21 14:50:38 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Mon, 21 Jan 2008 11:50:38 -0300 Subject: rawhide report: 20080118 changes In-Reply-To: <4794510E.70409@freemail.hu> References: <200801191711.m0JHBcSi017061@porkchop.devel.redhat.com> <4794510E.70409@freemail.hu> Message-ID: <200801211450.m0LEoc40016678@laptop13.inf.utfsm.cl> Zoltan Boszormenyi wrote: > Build System ??rta: > > kernel-2.6.24-0.157.rc8.fc9 > > --------------------------- > > * Thu Jan 17 2008 John W. Linville > > - More wireless fixes headed for 2.6.24 > > - More wireless updates headed for 2.6.25 > > > > * Wed Jan 16 2008 Kyle McMartin > > - 2.6.24-rc8 > > > > * Wed Jan 16 2008 Dave Airlie > > - update r500 patch to remove dup pciids. > I cannot compile this kernel on Fedora 8 from src.rpm > because the install phase errors out saying that > "Argument list too long". The attached patch tries to fix it. Kernel (+ xargs, IMHO) bug. Can be worked around by, e.g.: echo 128 > /proc/sys/kernel/audit_argv_kb See This "fixes" xargs (and others) going south with long ARGV. In any case, AFAIU xargs(1) should negotiate/ask for the size of ARGV, and doing it wrong. I.e.: $ xargs --show-limits Your environment variables take up 2509 bytes POSIX lower and upper limits on argument length: 2048, 129024 Maximum length of command we could actually use: 126515 Size of command buffer we are actually using: 126515 -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From limb at jcomserv.net Mon Jan 21 15:25:29 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 21 Jan 2008 09:25:29 -0600 (CST) Subject: Experiment: an RPM that shows uninstalled apps in main menu In-Reply-To: <1200825734.6945.10.camel@localhost.localdomain> References: <4792A25E.5020301@poolshark.org> <1200825734.6945.10.camel@localhost.localdomain> Message-ID: <22459.63.85.68.164.1200929129.squirrel@mail.jcomserv.net> > > On Sun, 2008-01-20 at 02:22 +0100, Denis Leroy wrote: >> This is an idea I've had about a year ago and gave some thought on and >> off since then, but Richard Hughes has mentioned a similar idea several >> times on this list as well. >> >> The idea is to show the (large number of) applications available to >> Fedora users through yum, but instead of a linear list displayed in >> pirut for example, show them directly in the main menu: that way the >> available apps are already categorized in a familiar way, and you can >> see the application icons and short descriptions through the menu >> tooltip. > > This just sounds like an awesome idea to me. I wonder how tightly could > that be integrated into Gnome and the desktop file specification. It > would be kind of elegant if the .desktop file contained a boolean > stating if the application is installed. If the app isn't installed, there would be no .desktop. No? > Then the gnome menu would contain something that would resemble the > thing that expands personalized menus in Windows except for that it > would unhide the uninstalled applications. And this could be turned off, > of course :) In KDE4, the Search capability of the menu could be enough > for user not to get lost in not-installed applications. > > -- > Lubomir Kundrak (Red Hat Security Response Team) > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From atkac at redhat.com Mon Jan 21 15:36:36 2008 From: atkac at redhat.com (Adam Tkac) Date: Mon, 21 Jan 2008 16:36:36 +0100 Subject: BIND less restrictive modes and policy In-Reply-To: <20080121131902.GA12493@dudweiler.stuttgart.redhat.com> References: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> <20080121131902.GA12493@dudweiler.stuttgart.redhat.com> Message-ID: <20080121153636.GA2893@evileye.atkac.englab.brq.redhat.com> On Mon, Jan 21, 2008 at 02:19:02PM +0100, Florian La Roche wrote: > > All other will be readable for all. Also complete /var/named/* subtree > > will be writable by named (for generating core files, DDNS updates, > > secondary servers, generally for easier configuration). > > > > Has anyone arguments against such change? > > > Would it be possible to keep write access within subdirs, so that > it e.g. is possible to keep master named files owned by root.root? > (Not sure this buys anything, but still looks good...) > We should make /var/named directory writable for named (upstream has same opinion, see https://bugzilla.redhat.com/show_bug.cgi?id=400461#c17). So if We have this directory writable it is not needed ship /var/named/{data,slaves,dynamic} subdirectories because non-writable /var/named directory is only one reason for them. Master zones installed by default will be root:named 644 (so no write access) and other perms will be controlled by administrator. So in the end new schema will be: - /etc/{named.conf,rndc.conf,rndc.key} + logfile non-readable for others (ok, world readable named.conf is quite suspicious so leave it private as is) - /var/named will be writable and read-only permissions will be set per-zone by admin - /var/named/* subdirectories will stop exist and files will be moved to /var/named/ Adam -- Adam Tkac, Red Hat, Inc. From cmadams at hiwaay.net Mon Jan 21 15:48:53 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 21 Jan 2008 09:48:53 -0600 Subject: BIND less restrictive modes and policy In-Reply-To: <20080121153636.GA2893@evileye.atkac.englab.brq.redhat.com> References: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> <20080121131902.GA12493@dudweiler.stuttgart.redhat.com> <20080121153636.GA2893@evileye.atkac.englab.brq.redhat.com> Message-ID: <20080121154853.GC1491367@hiwaay.net> Once upon a time, Adam Tkac said: > - /var/named will be writable and read-only permissions will be set > per-zone by admin If the directory is writable, read-only file permissions are meaningless. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From atkac at redhat.com Mon Jan 21 15:57:21 2008 From: atkac at redhat.com (Adam Tkac) Date: Mon, 21 Jan 2008 16:57:21 +0100 Subject: BIND less restrictive modes and policy In-Reply-To: <20080121154853.GC1491367@hiwaay.net> References: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> <20080121131902.GA12493@dudweiler.stuttgart.redhat.com> <20080121153636.GA2893@evileye.atkac.englab.brq.redhat.com> <20080121154853.GC1491367@hiwaay.net> Message-ID: <20080121155721.GA30491@evileye.atkac.englab.brq.redhat.com> On Mon, Jan 21, 2008 at 09:48:53AM -0600, Chris Adams wrote: > Once upon a time, Adam Tkac said: > > - /var/named will be writable and read-only permissions will be set > > per-zone by admin > > If the directory is writable, read-only file permissions are > meaningless. > Maybe but what other solution will be better? I could create separate read-only directory inside /var/named (called "masters" for example) and put all read-only zones there but I'm not sure if admins will like it and use it. Adam -- Adam Tkac, Red Hat, Inc. From laroche at redhat.com Mon Jan 21 16:10:58 2008 From: laroche at redhat.com (Florian La Roche) Date: Mon, 21 Jan 2008 17:10:58 +0100 Subject: BIND less restrictive modes and policy In-Reply-To: <20080121155721.GA30491@evileye.atkac.englab.brq.redhat.com> References: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> <20080121131902.GA12493@dudweiler.stuttgart.redhat.com> <20080121153636.GA2893@evileye.atkac.englab.brq.redhat.com> <20080121154853.GC1491367@hiwaay.net> <20080121155721.GA30491@evileye.atkac.englab.brq.redhat.com> Message-ID: <20080121161058.GA19325@dudweiler.stuttgart.redhat.com> On Mon, Jan 21, 2008 at 04:57:21PM +0100, Adam Tkac wrote: > On Mon, Jan 21, 2008 at 09:48:53AM -0600, Chris Adams wrote: > > Once upon a time, Adam Tkac said: > > > - /var/named will be writable and read-only permissions will be set > > > per-zone by admin > > > > If the directory is writable, read-only file permissions are > > meaningless. > > > > Maybe but what other solution will be better? I could create separate > read-only directory inside /var/named (called "masters" for example) > and put all read-only zones there but I'm not sure if admins will like > it and use it. That's why the root-only /var/named with writable subdirs was very nice. Your points about allowing core-dumps and other things like a non-complex setup are also valid, that's why I think we should stay thinking about this some more before reducing the security of bind. regards, Florian La Roche From loupgaroublond at gmail.com Mon Jan 21 16:12:01 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Mon, 21 Jan 2008 11:12:01 -0500 Subject: Experiment: an RPM that shows uninstalled apps in main menu In-Reply-To: <22459.63.85.68.164.1200929129.squirrel@mail.jcomserv.net> References: <4792A25E.5020301@poolshark.org> <1200825734.6945.10.camel@localhost.localdomain> <22459.63.85.68.164.1200929129.squirrel@mail.jcomserv.net> Message-ID: <7f692fec0801210812u16e7b402r4e7a8f30c06d737b@mail.gmail.com> On Jan 21, 2008 10:25 AM, Jon Ciesla wrote: > > On Sun, 2008-01-20 at 02:22 +0100, Denis Leroy wrote: > >> This is an idea I've had about a year ago and gave some thought on and > >> off since then, but Richard Hughes has mentioned a similar idea several > >> times on this list as well. > >> > >> The idea is to show the (large number of) applications available to > >> Fedora users through yum, but instead of a linear list displayed in > >> pirut for example, show them directly in the main menu: that way the > >> available apps are already categorized in a familiar way, and you can > >> see the application icons and short descriptions through the menu > >> tooltip. > > > > This just sounds like an awesome idea to me. I wonder how tightly could > > that be integrated into Gnome and the desktop file specification. It > > would be kind of elegant if the .desktop file contained a boolean > > stating if the application is installed. > > If the app isn't installed, there would be no .desktop. No? I don't remember offhand who posted this to a Fedora mailing list, but he mentioned a pie-in-the-sky idea, where we maintain a package database complete with icons and other rich metadata. It would be a separate package with it's own data to manage, that no one but the maintainers would be responsible for. It seems to me that this seems to be the sanest answer to handling such a database of apps that aren't actually installed. Anything else would probably be a gross ugly hack, and I can imagine the complaining there'll be all the way down the road until the finished product comes out. Just my (increasingly devalued) 0.02 USD -Yaakov From frank-buettner at gmx.net Mon Jan 21 16:15:20 2008 From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=) Date: Mon, 21 Jan 2008 17:15:20 +0100 Subject: [reopen]Re: mock 0.8.9 will not build anything In-Reply-To: <47949FD6.7070300@gmx.net> References: <4790691C.3080605@gmx.net> <1200752442.6945.3.camel@localhost.localdomain> <47926563.1040301@gmx.net> <1200848768.6945.12.camel@localhost.localdomain> <47938562.6040109@gmx.net> <479389F2.6050108@gmx.net> <1200852318.6945.21.camel@localhost.localdomain> <4793947C.9050202@gmx.net> <1200855185.6945.24.camel@localhost.localdomain> <479399FA.9040709@gmx.net> <1200899414.6945.39.camel@localhost.localdomain> <47945451.4040606@gmx.net> <1200904582.6945.41.camel@localhost.localdomain> <47945C3F.7040109@gmx.net> <1200914012.6945.58.camel@localhost.localdomain> <47949FD6.7070300@gmx.net> Message-ID: <4794C518.1010307@gmx.net> Frank B?ttner schrieb: > Lubomir Kundrak schrieb: >> Hi Fran, >> >> On Mon, 2008-01-21 at 09:47 +0100, Frank B?ttner wrote: >>> config_opts['yum.conf'] = """ >>> config_opts['plugin_conf']['ccache_enable'] = False >> >> Please switch these two lines. >> >> """ marks beginning of a multi-line string, yum.conf in this case, so >> you added the ccache_enable option line to mock's yum.conf. >> >> Thanks, > Yes now it work's. > The goal is, that for /etc/mock/fedora-4-i386-epel.cfg > the line config_opts['plugin_conf']['ccache_enable'] = False must be > included, because by default at /etc/mock/defaults.cfg ccaache is > enabled, but at the epel 4 repo ccache is not available. > ccache is only available for EPEL5,F7,F8 and devel. > > Thanks for the help:) > Frank > Now I have try to build it for another arch and I have the same problem like at the beginning. mock -r fedora-4-i386-epel work. but fedora-5-i386-epel, fedora-7-i386, fedora-8-i386 and fedora-devel-i386 will fail again with: INFO: Results and/or logs in: /var/lib/mock/fedora-development-i386/result ERROR: Command(/usr/sbin/groupadd -g 102 mockbuild) failed. See logs for output. I can see that mock tries to call it twice: 2008-01-21 17:05:41,201 - DEBUG trace_decorator.py, Line: 20: ENTER: doChroot((, '/usr/sbin/groupadd -g 102 mockbuild', ''), {}) 2008-01-21 17:05:41,202 - DEBUG trace_decorator.py, Line: 20: ENTER: do(('/usr/sbin/groupadd -g 102 mockbuild', '/var/lib/mock/fedora-development-i386/root', 0, True, 0, None, None, None, None), {}) 2008-01-21 17:05:41,202 - DEBUG util.py, Line: 212: Run cmd: /usr/sbin/groupadd -g 102 mockbuild 2008-01-21 17:05:41,203 - DEBUG util.py, Line: 218: Executing timeout(0): /usr/sbin/groupadd -g 102 mockbuild 2008-01-21 17:05:41,207 - DEBUG trace_decorator.py, Line: 20: ENTER: condPersonality((None,), {}) 2008-01-21 17:05:41,209 - DEBUG trace_decorator.py, Line: 30: LEAVE condPersonality --> None 2008-01-21 17:05:41,210 - DEBUG trace_decorator.py, Line: 20: ENTER: condChroot(('/var/lib/mock/fedora-development-i386/root', None), {}) 2008-01-21 17:05:41,210 - DEBUG trace_decorator.py, Line: 30: LEAVE condChroot --> None 2008-01-21 11:05:41,211 - DEBUG trace_decorator.py, Line: 20: ENTER: condDropPrivs((None, None, None), {}) 2008-01-21 11:05:41,212 - DEBUG trace_decorator.py, Line: 30: LEAVE condDropPrivs --> None 2008-01-21 17:05:41,277 - DEBUG util.py, Line: 234: groupadd: name mockbuild is not unique 2008-01-21 17:05:41,279 - DEBUG trace_decorator.py, Line: 27: EXCEPTION: Command(/usr/sbin/groupadd -g 102 mockbuild) failed. See logs for output. Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/mock/trace_decorator.py", line 24, in trace result = f(*args, **kw) File "/usr/lib/python2.4/site-packages/mock/util.py", line 260, in do raise mock.exception.Error, "Command(%s) failed. See logs for output." % command Error: Command(/usr/sbin/groupadd -g 102 mockbuild) failed. See logs for output. 2008-01-21 17:05:41,318 - DEBUG trace_decorator.py, Line: 30: LEAVE do --> EXCEPTION RAISED 2008-01-21 17:05:41,319 - DEBUG trace_decorator.py, Line: 27: EXCEPTION: Command(/usr/sbin/groupadd -g 102 mockbuild) failed. See logs for output. Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/mock/trace_decorator.py", line 24, in trace result = f(*args, **kw) File "/usr/lib/python2.4/site-packages/mock/backend.py", line 277, in doChroot return mock.util.do( command, personality=self.personality, chrootPath=self.rootdir, *args, **kargs ) File "", line 1, in File "/usr/lib/python2.4/site-packages/mock/trace_decorator.py", line 24, in trace result = f(*args, **kw) File "/usr/lib/python2.4/site-packages/mock/util.py", line 260, in do raise mock.exception.Error, "Command(%s) failed. See logs for output." % command Error: Command(/usr/sbin/groupadd -g 102 mockbuild) failed. See logs for output. 2008-01-21 17:05:41,322 - DEBUG trace_decorator.py, Line: 30: LEAVE doChroot --> EXCEPTION RAISED 2008-01-21 17:05:41,323 - DEBUG trace_decorator.py, Line: 27: EXCEPTION: Command(/usr/sbin/groupadd -g 102 mockbuild) failed. See logs for output. Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/mock/trace_decorator.py", line 24, in trace result = f(*args, **kw) File "/usr/lib/python2.4/site-packages/mock/backend.py", line 467, in _makeBuildUser self.doChroot('/usr/sbin/groupadd -g %(gid)s %(group)s' % dets) File "", line 1, in File "/usr/lib/python2.4/site-packages/mock/trace_decorator.py", line 24, in trace result = f(*args, **kw) File "/usr/lib/python2.4/site-packages/mock/backend.py", line 277, in doChroot return mock.util.do( command, personality=self.personality, chrootPath=self.rootdir, *args, **kargs ) File "", line 1, in File "/usr/lib/python2.4/site-packages/mock/trace_decorator.py", line 24, in trace result = f(*args, **kw) File "/usr/lib/python2.4/site-packages/mock/util.py", line 260, in do raise mock.exception.Error, "Command(%s) failed. See logs for output." % command Error: Command(/usr/sbin/groupadd -g 102 mockbuild) failed. See logs for output. 2008-01-21 17:05:41,324 - DEBUG trace_decorator.py, Line: 30: LEAVE _makeBuildUser --> EXCEPTION RAISED 2008-01-21 17:05:41,325 - DEBUG trace_decorator.py, Line: 27: EXCEPTION: Command(/usr/sbin/groupadd -g 102 mockbuild) failed. See logs for output. Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/mock/trace_decorator.py", line 24, in trace result = f(*args, **kw) File "/usr/lib/python2.4/site-packages/mock/backend.py", line 266, in init self._makeBuildUser() File "", line 1, in File "/usr/lib/python2.4/site-packages/mock/trace_decorator.py", line 24, in trace result = f(*args, **kw) File "/usr/lib/python2.4/site-packages/mock/backend.py", line 467, in _makeBuildUser self.doChroot('/usr/sbin/groupadd -g %(gid)s %(group)s' % dets) File "", line 1, in File "/usr/lib/python2.4/site-packages/mock/trace_decorator.py", line 24, in trace result = f(*args, **kw) File "/usr/lib/python2.4/site-packages/mock/backend.py", line 277, in doChroot return mock.util.do( command, personality=self.personality, chrootPath=self.rootdir, *args, **kargs ) File "", line 1, in File "/usr/lib/python2.4/site-packages/mock/trace_decorator.py", line 24, in trace result = f(*args, **kw) File "/usr/lib/python2.4/site-packages/mock/util.py", line 260, in do raise mock.exception.Error, "Command(%s) failed. See logs for output." % command Error: Command(/usr/sbin/groupadd -g 102 mockbuild) failed. See logs for output. 2008-01-21 17:05:41,327 - DEBUG trace_decorator.py, Line: 30: LEAVE init --> EXCEPTION RAISED 2008-01-21 17:05:41,331 - DEBUG trace_decorator.py, Line: 20: ENTER: orphansKill(('/var/lib/mock/fedora-development-i386/root',), {}) 2008-01-21 17:05:41,361 - DEBUG trace_decorator.py, Line: 30: LEAVE orphansKill --> None -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5766 bytes Desc: S/MIME Cryptographic Signature URL: From pertusus at free.fr Mon Jan 21 16:27:48 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 21 Jan 2008 17:27:48 +0100 Subject: wiki strangeness In-Reply-To: <64b14b300801210553h302e635cnf095459cfe8c6c04@mail.gmail.com> References: <64b14b300801210429u91c8fc5tb2813b0f67c5eb76@mail.gmail.com> <64b14b300801210433m19599eecodc8627dbeb1accaa@mail.gmail.com> <20080121072359.0838303b@zod.rchland.ibm.com> <64b14b300801210553h302e635cnf095459cfe8c6c04@mail.gmail.com> Message-ID: <20080121162747.GF3465@free.fr> On Mon, Jan 21, 2008 at 02:53:08PM +0100, Valent Turkovic wrote: > > Easier said than done. > I looked at man page and at pungi online documentation and I can't > find relevant info on how to make rawhide just how to make fedora 8 > custom versions. > Also I can't find any resource (google included) with relevant info - > how much space is needed to make "default" build of latest fedora and > of latest rawhide. Are there any blogs that are under google's radar > that you know of that show the process of making iso files using > pungi. I didn't find many docs either when I wanted to try to do a spin. the process is rather straightforward, however. Install pungi. Copy /usr/share/pungi/rawhide-fedora.ks. Tweak it to your liking. And then run pungi -c myksfile.ks in an empty directory where everything (except the cache in /var/cache) will be created. The disk space required is big. I am not user that asome data about this size makes much sense since it is subject to changes. The pungi man page explains how to customize the strings associated with the iso. -- Pat From pertusus at free.fr Mon Jan 21 16:29:37 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 21 Jan 2008 17:29:37 +0100 Subject: rpmlint: "non-conffile-in-etc" In-Reply-To: <5e92ee3f0801210647g7f8ce2f9x6c25f6ee2ac34e2b@mail.gmail.com> References: <5e92ee3f0801210647g7f8ce2f9x6c25f6ee2ac34e2b@mail.gmail.com> Message-ID: <20080121162937.GG3465@free.fr> On Mon, Jan 21, 2008 at 03:47:19PM +0100, Jakub 'Livio' Rusinek wrote: > Hi, > > I'm packaging gnome-main-menu applet from SVN and have only one issue > displayed by rpmlint. > > gnome-main-menu.i386: W: non-conffile-in-etc > /etc/gconf/schemas/application-browser.schemas > gnome-main-menu.i386: W: non-conffile-in-etc /etc/gconf/schemas/slab.schemas > > In bugzilla's review request [1] non-conffile-in-etc was fixed by > marking file as %config. > > compiz [2] has gconf schemas files too, but it has no %config and > schemas normally in %files. The gconf schemas are not config files, so should not be marked as %config and the rpmlint warning can be ignored. The bug is certainly in gnome/gconf since those files should certainly be in /usr/share (with a possible override in /etc). -- Pat From paul at city-fan.org Mon Jan 21 16:32:31 2008 From: paul at city-fan.org (Paul Howarth) Date: Mon, 21 Jan 2008 16:32:31 +0000 Subject: SELinux removed from desktop cd spin? In-Reply-To: <4790E961.5030605@redhat.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <478F857A.6030502@redhat.com> <20080117180251.GA77139@dspnet.fr.eu.org> <200801171920.32764.opensource@till.name> <1200594904.3259.143.camel@cassandra.boston.redhat.com> <478FA30A.6030405@redhat.com> <20080117191051.GB84707@dspnet.fr.eu.org> <4790AA04.2020409@redhat.com> <20080118161236.GA61848@dspnet.fr.eu.org> <4790E961.5030605@redhat.com> Message-ID: <4794C91F.9080204@city-fan.org> Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Olivier Galibert wrote: >> On Fri, Jan 18, 2008 at 08:30:44AM -0500, Daniel J Walsh wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Olivier Galibert wrote: >>>> On Thu, Jan 17, 2008 at 01:48:42PM -0500, Daniel J Walsh wrote: >>>>> >>>>> >>>>>

>>>>> Allow unconfined executables to map a memory region as both executable >>>>> and writable, this is dangerous and the executable should be reported in >>>>> bugzilla") >>>> That should be "to map a file in a memory region", as UD's page >>>> explains. Otherwise anyone who knows a little about dynamic >>>> recompilers/JITs is gonna go "huh?". >>>> >>>> OG. >>>> >>> Bad cut and paste. The one I pasted was for allow_execmem. Where the >>> definition is correct. >> You mean Ulrich's page is incorrect then? I indeed had noticed it was >> about execmem. >> >> >>> java/mono apps are not confined by this, since >>> they run under a different context. >> Java/Mono are not the only programs with dynamic code generators in >> them. >> >> OG. >> > THe attached file is the file context of all files in Rawhide (Probably > F8) that are marked as allowing execmem/execstack. > > If you know of others, we need to update this list. Shouldn't this list also include things labelled as unconfined_notrans_exec_t such as mock and sysreport? Paul. From jakub.rusinek at gmail.com Mon Jan 21 16:33:46 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Mon, 21 Jan 2008 17:33:46 +0100 Subject: rpmlint: "non-conffile-in-etc" In-Reply-To: <20080121162937.GG3465@free.fr> References: <5e92ee3f0801210647g7f8ce2f9x6c25f6ee2ac34e2b@mail.gmail.com> <20080121162937.GG3465@free.fr> Message-ID: <5e92ee3f0801210833q37fb20f6pc611491f8d79b35f@mail.gmail.com> 2008/1/21, Patrice Dumas : > On Mon, Jan 21, 2008 at 03:47:19PM +0100, Jakub 'Livio' Rusinek wrote: > > Hi, > > > > I'm packaging gnome-main-menu applet from SVN and have only one issue > > displayed by rpmlint. > > > > gnome-main-menu.i386: W: non-conffile-in-etc > > /etc/gconf/schemas/application-browser.schemas > > gnome-main-menu.i386: W: non-conffile-in-etc /etc/gconf/schemas/slab.schemas > > > > In bugzilla's review request [1] non-conffile-in-etc was fixed by > > marking file as %config. > > > > compiz [2] has gconf schemas files too, but it has no %config and > > schemas normally in %files. > > The gconf schemas are not config files, so should not be marked as > %config and the rpmlint warning can be ignored. > > The bug is certainly in gnome/gconf since those files should certainly > be in /usr/share (with a possible override in /etc). > > -- > Pat > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Thanks for reply. My package is ready for repo inclusion :> . -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ From denis at poolshark.org Mon Jan 21 16:48:24 2008 From: denis at poolshark.org (Denis Leroy) Date: Mon, 21 Jan 2008 17:48:24 +0100 Subject: Experiment: an RPM that shows uninstalled apps in main menu In-Reply-To: <4792AC21.3060806@gmail.com> References: <4792A25E.5020301@poolshark.org> <4792AC21.3060806@gmail.com> Message-ID: <4794CCD8.3050008@poolshark.org> Andrew Farris wrote: > Given that this rpm would already be carrying the entire list of > available software in official repos, their .desktop files, executable > names, and information about which package contains them... > > I wonder if it would be feasible to start developing support for command > line 'yum install foo' suggestions to users (ala apt on debian/ubuntu > systems). > > For instance, user knows (from a friend or random webpage) that the > program foo is neat, and tries to start it: > > foo > > Command not found: foo > > This program is available for Fedora but is not currently installed. > > To install this program type (as root): yum install FooPackage That'd be nice to have also, and i think is fairly orthogonal to the fedora-apps RPM idea. After all this targets terminal users, while the uninstalled icons target all users, especially those that never use a terminal app (i.e. those for whom the only way to install additional software is with the 'Add/Remove Software' menu entry, aka pirut). From jakub.rusinek at gmail.com Mon Jan 21 16:47:55 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Mon, 21 Jan 2008 17:47:55 +0100 Subject: Experiment: an RPM that shows uninstalled apps in main menu In-Reply-To: <4794CCD8.3050008@poolshark.org> References: <4792A25E.5020301@poolshark.org> <4792AC21.3060806@gmail.com> <4794CCD8.3050008@poolshark.org> Message-ID: <1200934075.7168.2.camel@geeko> > > For instance, user knows (from a friend or random webpage) that the > > program foo is neat, and tries to start it: > > > foo > > > Command not found: foo > > > This program is available for Fedora but is not currently installed. > > > To install this program type (as root): yum install FooPackage > > That'd be nice to have also, and i think is fairly orthogonal to the > fedora-apps RPM idea. After all this targets terminal users, while the > uninstalled icons target all users, especially those that never use a > terminal app (i.e. those for whom the only way to install additional > software is with the 'Add/Remove Software' menu entry, aka pirut). command-not-found if I remember good did that in Ubuntu. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? wiadomo?ci podpisana cyfrowo URL: From pemboa at gmail.com Mon Jan 21 16:55:07 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 21 Jan 2008 10:55:07 -0600 Subject: Experiment: an RPM that shows uninstalled apps in main menu In-Reply-To: <4794CCD8.3050008@poolshark.org> References: <4792A25E.5020301@poolshark.org> <4792AC21.3060806@gmail.com> <4794CCD8.3050008@poolshark.org> Message-ID: <16de708d0801210855l1d6c87cfxef4c6b225824a32d@mail.gmail.com> On Jan 21, 2008 10:48 AM, Denis Leroy wrote: > > For instance, user knows (from a friend or random webpage) that the > > program foo is neat, and tries to start it: > > > foo > > > Command not found: foo > > > This program is available for Fedora but is not currently installed. > > > To install this program type (as root): yum install FooPackage > > That'd be nice to have also, and i think is fairly orthogonal to the > fedora-apps RPM idea. After all this targets terminal users, while the > uninstalled icons target all users, especially those that never use a > terminal app (i.e. those for whom the only way to install additional > software is with the 'Add/Remove Software' menu entry, aka pirut). this particular idea was discussed thoroughly a few months ago. I think it died when the consensus became that it may break apps/scripts that rely on command not being found if the command really doesn't exist. For the sake of the success of the original idea, lets separate out this new one. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From notting at redhat.com Mon Jan 21 16:55:58 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 21 Jan 2008 11:55:58 -0500 Subject: Experiment: an RPM that shows uninstalled apps in main menu In-Reply-To: <4792A25E.5020301@poolshark.org> References: <4792A25E.5020301@poolshark.org> Message-ID: <20080121165558.GA14866@nostromo.devel.redhat.com> Denis Leroy (denis at poolshark.org) said: > For kicks and giggles, I hacked up a proof-of-concept RPM here for F-8 : > > http://www.poolshark.org/src/fedora-apps-0.1-1.fc8.i386.rpm > > After installation, you'll have to restart the gnome-panel with a quick > 'killall gnome-panel'. The rpm is 5 MB, which is not bad for almost 1000 > apps (remember we're only talking about GUI apps here, i.e. apps that > install a desktop file). Interesting idea. You're setting yourself up for a lot of pain on the package maintenance side, I fear. Bill From denis at poolshark.org Mon Jan 21 17:18:36 2008 From: denis at poolshark.org (Denis Leroy) Date: Mon, 21 Jan 2008 18:18:36 +0100 Subject: Experiment: an RPM that shows uninstalled apps in main menu In-Reply-To: <20080121165558.GA14866@nostromo.devel.redhat.com> References: <4792A25E.5020301@poolshark.org> <20080121165558.GA14866@nostromo.devel.redhat.com> Message-ID: <4794D3EC.50804@poolshark.org> Bill Nottingham wrote: > Denis Leroy (denis at poolshark.org) said: >> For kicks and giggles, I hacked up a proof-of-concept RPM here for F-8 : >> >> http://www.poolshark.org/src/fedora-apps-0.1-1.fc8.i386.rpm >> >> After installation, you'll have to restart the gnome-panel with a quick >> 'killall gnome-panel'. The rpm is 5 MB, which is not bad for almost 1000 >> apps (remember we're only talking about GUI apps here, i.e. apps that >> install a desktop file). > > Interesting idea. You're setting yourself up for a lot of pain on the > package maintenance side, I fear. Well that all depends on how much scripting I'm prepared to make :-) I used a number of scripts to extract the desktop and icon files out of the RPMs, parse the desktop files, etc... in theory it's 100% scriptable. Now, things would be considerably easier if this was integrated into packagedb: flag packages that have desktop entries, add information such as short description and icon. Then we could push the idea further and add things such as screenshots, for example. Then we'd have all the raw data necessary to create a real "fedora software installation assistant". There are some challenges to providing this through a regular package review though: may need collaboration with redhat-menus (integration into main menu) and/or desktop-utils owners (to update list of uninstalled apps after an RPM is installed manually). From lfarkas at bppiac.hu Mon Jan 21 17:26:40 2008 From: lfarkas at bppiac.hu (Farkas Levente) Date: Mon, 21 Jan 2008 18:26:40 +0100 Subject: hdX vs sdX on redhat/centos 5.x with ata_piix Message-ID: <4794D5D0.8080508@bppiac.hu> hi, on redhat 5.x and fedora 6 there are hdX and sdX while from fedora 7 (and probably from redhat 6.x) there will be only sdX. is it possible with the latest redhat kernel-2.6.18-53.1.4.el5 to use the same libata driver to handle all disk (ie. both pata and sata) so we've only sdX disk devices like it's the current setup on newer fedora release. we try to disable ide0=noprobe etc. which really disable hdX but even if the kernel load the libata and ata_piix driver it's still not load these disks. thanks in advance. -- Levente "Si vis pacem para bellum!" From dcbw at redhat.com Mon Jan 21 17:26:01 2008 From: dcbw at redhat.com (Dan Williams) Date: Mon, 21 Jan 2008 12:26:01 -0500 Subject: network manager command-line control? In-Reply-To: <1200907199.24450.8.camel@jndwidescreen.lesbg.loc> References: <20071203154332.GA13878@jadzia.bu.edu> <1196699870.2447.4.camel@localhost.localdomain> <1200907199.24450.8.camel@jndwidescreen.lesbg.loc> Message-ID: <1200936361.8260.7.camel@localhost.localdomain> On Mon, 2008-01-21 at 11:19 +0200, Jonathan Dieter wrote: > On Mon, 2007-12-03 at 11:37 -0500, Dan Williams wrote: > > On Mon, 2007-12-03 at 10:43 -0500, Matthew Miller wrote: > > > I want to make sure I'm not missing something before I file an RFE. I'd like > > > to be able to enable/disable wireless (or wired, for that matter) networking > > > from scripts. The nm-tool program seems like the logical place for this > > > functionality, but it doesn't appear to actually have it at this point. > > > > All the functionality is currently available with dbus-send. However, > > since that's the case, it would be nice to have a CLI tool that > > interfaces in a nicer manner than dbus-send. I'd like to have something > > like that too, but haven't had time to look into it. It would be a > > great opportunity for somebody to jump in. > > Is there a list of (important) dbus methods exported by NM? I'm trying > to work out a way of bringing up a wireless network early in the boot > process in F8 and have been unable to even get a list of devices. Hmm, I'm about to land that functionality in F8 and rawhide in the next few weeks anyway... Dan > Trying to run (which looks like it's supposed to work in 0.6): > >>> import dbus > >>> bus = dbus.SystemBus() > >>> iface = bus.get_object('org.freedesktop.NetworkManager', '/org/freedesktop/NetworkManager') > >>> devs = iface.getDevices(dbus_interface='org.freedesktop.NetworkManager') > or > >>> devs = iface.getDevices(dbus_interface='org.freedesktop.NetworkManager.Devices') > > gives me: > > dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod: > Method "getDevices" with signature "" on interface > "org.freedesktop.NetworkManager" doesn't exist > > What am I missing? > > Jonathan > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From denis at poolshark.org Mon Jan 21 17:28:18 2008 From: denis at poolshark.org (Denis Leroy) Date: Mon, 21 Jan 2008 18:28:18 +0100 Subject: Experiment: an RPM that shows uninstalled apps in main menu In-Reply-To: <479300D5.5020208@gmail.com> References: <4792A25E.5020301@poolshark.org> <16de708d0801192046j102eb7d7sf64059e784b9bef3@mail.gmail.com> <604aa7910801192142y5266c0dfh2e82a91246483f69@mail.gmail.com> <16de708d0801192156w2fa69e76v7014057effe8aac4@mail.gmail.com> <479300D5.5020208@gmail.com> Message-ID: <4794D632.1010308@poolshark.org> Andrew Farris wrote: > Arthur Pemberton wrote: >> On Jan 19, 2008 11:42 PM, Jeff Spaleta wrote: >>> On Jan 19, 2008 7:46 PM, Arthur Pemberton wrote: >>>> While I don't think it should be exactly how you have it, an >>>> 'Uninstalled' submenu in every category, seems like a great idea to >>>> me. >>> Until someone decides to manually re-arrange the listings on the >>> system using a menu editor :-> >>> >>> -jef >>> >> >> >> I personally think this should be a first level menu myself. An >> immutable one at that. And install of 'uninstalled' might want to say >> 'available' > > Immutable, and first level seems reasonable. The title is debatable, > since 'available' has multiple meanings, and the software is not > available to the person who wants to use it when they click on the > menu... its acquirable, its not yet installed, its offered, but not yet > available. If something like 'Repository Software' was used, that would > be clear (but not very 'sophisticated'). How about if the current "Add/Remove Software" was a directory instead of a link to pirut. It would open up a submenu with the regular pirut link on top, followed by a separator then a mirror of the main application categories containing all uninstalled apps ? From kevin.kofler at chello.at Mon Jan 21 17:37:28 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 21 Jan 2008 17:37:28 +0000 (UTC) Subject: rpmlint: "non-conffile-in-etc" References: <5e92ee3f0801210647g7f8ce2f9x6c25f6ee2ac34e2b@mail.gmail.com> <20080121162937.GG3465@free.fr> Message-ID: Patrice Dumas free.fr> writes: > The bug is certainly in gnome/gconf since those files should certainly > be in /usr/share (with a possible override in /etc). Interestingly, KConfig gets it wrong the opposite way, it puts the schemas into /usr/share/config.kcfg (OK) and the config files into /usr/share/config (not so OK). Kevin Kofler From alan at redhat.com Mon Jan 21 17:41:40 2008 From: alan at redhat.com (Alan Cox) Date: Mon, 21 Jan 2008 12:41:40 -0500 Subject: hdX vs sdX on redhat/centos 5.x with ata_piix In-Reply-To: <4794D5D0.8080508@bppiac.hu> References: <4794D5D0.8080508@bppiac.hu> Message-ID: <20080121174140.GB5373@devserv.devel.redhat.com> On Mon, Jan 21, 2008 at 06:26:40PM +0100, Farkas Levente wrote: > disk devices like it's the current setup on newer fedora release. we try > to disable ide0=noprobe etc. which really disable hdX but even if the > kernel load the libata and ata_piix driver it's still not load these disks. > thanks in advance. Not without recompiling currently. From j.w.r.degoede at hhs.nl Mon Jan 21 17:44:27 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 21 Jan 2008 18:44:27 +0100 Subject: Experiment: an RPM that shows uninstalled apps in main menu In-Reply-To: <4794D632.1010308@poolshark.org> References: <4792A25E.5020301@poolshark.org> <16de708d0801192046j102eb7d7sf64059e784b9bef3@mail.gmail.com> <604aa7910801192142y5266c0dfh2e82a91246483f69@mail.gmail.com> <16de708d0801192156w2fa69e76v7014057effe8aac4@mail.gmail.com> <479300D5.5020208@gmail.com> <4794D632.1010308@poolshark.org> Message-ID: <4794D9FB.7020704@hhs.nl> Denis Leroy wrote: > Andrew Farris wrote: >> Arthur Pemberton wrote: >>> On Jan 19, 2008 11:42 PM, Jeff Spaleta wrote: >>>> On Jan 19, 2008 7:46 PM, Arthur Pemberton wrote: >>>>> While I don't think it should be exactly how you have it, an >>>>> 'Uninstalled' submenu in every category, seems like a great idea to >>>>> me. >>>> Until someone decides to manually re-arrange the listings on the >>>> system using a menu editor :-> >>>> >>>> -jef >>>> >>> >>> >>> I personally think this should be a first level menu myself. An >>> immutable one at that. And install of 'uninstalled' might want to say >>> 'available' >> >> Immutable, and first level seems reasonable. The title is debatable, >> since 'available' has multiple meanings, and the software is not >> available to the person who wants to use it when they click on the >> menu... its acquirable, its not yet installed, its offered, but not >> yet available. If something like 'Repository Software' was used, that >> would be clear (but not very 'sophisticated'). > > How about if the current "Add/Remove Software" was a directory instead > of a link to pirut. It would open up a submenu with the regular pirut > link on top, followed by a separator then a mirror of the main > application categories containing all uninstalled apps ? > That sounds like a great plan! Regards, Hans p.s, Please take a look at the games-menus package and consider doing something similar for the add remove programs games sub menu (and maybe other submenus too). From Michael_E_Brown at dell.com Mon Jan 21 17:50:48 2008 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Mon, 21 Jan 2008 11:50:48 -0600 Subject: [reopen]Re: mock 0.8.9 will not build anything In-Reply-To: <4794C518.1010307@gmx.net> References: <4793947C.9050202@gmx.net> <1200855185.6945.24.camel@localhost.localdomain> <479399FA.9040709@gmx.net> <1200899414.6945.39.camel@localhost.localdomain> <47945451.4040606@gmx.net> <1200904582.6945.41.camel@localhost.localdomain> <47945C3F.7040109@gmx.net> <1200914012.6945.58.camel@localhost.localdomain> <47949FD6.7070300@gmx.net> <4794C518.1010307@gmx.net> Message-ID: <20080121175047.GA28272@humbolt.us.dell.com> On Mon, Jan 21, 2008 at 05:15:20PM +0100, Frank B?ttner wrote: > Frank B?ttner schrieb: > >Lubomir Kundrak schrieb: > >>Hi Fran, > >> > >>On Mon, 2008-01-21 at 09:47 +0100, Frank B?ttner wrote: > >>>config_opts['yum.conf'] = """ > >>>config_opts['plugin_conf']['ccache_enable'] = False > >> > >>Please switch these two lines. > >> > >>""" marks beginning of a multi-line string, yum.conf in this case, so > >>you added the ccache_enable option line to mock's yum.conf. > >> > >>Thanks, > >Yes now it work's. > >The goal is, that for /etc/mock/fedora-4-i386-epel.cfg > >the line config_opts['plugin_conf']['ccache_enable'] = False must be > >included, because by default at /etc/mock/defaults.cfg ccaache is > >enabled, but at the epel 4 repo ccache is not available. > >ccache is only available for EPEL5,F7,F8 and devel. Wasnt checking email over the weekend, so jumping in again: We intend to upgrade mock in EPEL5 to 0.9.x come Feb. The dependencies are now all mostly available. Python-ctypes is in the -testing repository for EPEL-5. The fedora builders are all running RHEL5 with this version, so it is well-tested. If you want to use it, grab the mock 0.9.x SRPM from fedora rawhide and rebuild it and grab the python-ctypes RPM from epel testing repo. All of the configs in 0.9.x have been tested. ccache is disabled in all of the configs where it is not available in the upstream repos. -- Michael From jdieter at gmail.com Mon Jan 21 17:49:37 2008 From: jdieter at gmail.com (Jonathan Dieter) Date: Mon, 21 Jan 2008 19:49:37 +0200 Subject: network manager command-line control? In-Reply-To: <1200936361.8260.7.camel@localhost.localdomain> References: <20071203154332.GA13878@jadzia.bu.edu> <1196699870.2447.4.camel@localhost.localdomain> <1200907199.24450.8.camel@jndwidescreen.lesbg.loc> <1200936361.8260.7.camel@localhost.localdomain> Message-ID: <1200937777.3567.6.camel@localhost.localdomain> On Mon, 2008-01-21 at 12:26 -0500, Dan Williams wrote: > On Mon, 2008-01-21 at 11:19 +0200, Jonathan Dieter wrote: > > Is there a list of (important) dbus methods exported by NM? I'm trying > > to work out a way of bringing up a wireless network early in the boot > > process in F8 and have been unable to even get a list of devices. > > Hmm, I'm about to land that functionality in F8 and rawhide in the next > few weeks anyway... > > Dan Brilliant. I guess I'll just wait, then. Thanks, Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From lsof at nodata.co.uk Mon Jan 21 18:09:44 2008 From: lsof at nodata.co.uk (nodata) Date: Mon, 21 Jan 2008 19:09:44 +0100 Subject: BIND less restrictive modes and policy In-Reply-To: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> References: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> Message-ID: <1200938984.2940.2.camel@sb-home> Am Montag, den 21.01.2008, 12:57 +0100 schrieb Adam Tkac: > Hi all, > > I'm going to do major revision of bind's file modes. Currenly We have > many files readable only by root and I can't see any reason why keep > binaries unreadable and unexecutable by other users. Also there isn't > any reason why keep configuration private. Only this files should not > be readable by other users: > - /etc/rndc.key - who has it may control server through rndc utility > - /var/log/named.log - will have sensitive information > > All other will be readable for all. Also complete /var/named/* subtree > will be writable by named (for generating core files, DDNS updates, > secondary servers, generally for easier configuration). > > Has anyone arguments against such change? What are the arguments for the change? From mclasen at redhat.com Mon Jan 21 18:41:21 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 21 Jan 2008 13:41:21 -0500 Subject: Experiment: an RPM that shows uninstalled apps in main menu In-Reply-To: <4794D632.1010308@poolshark.org> References: <4792A25E.5020301@poolshark.org> <16de708d0801192046j102eb7d7sf64059e784b9bef3@mail.gmail.com> <604aa7910801192142y5266c0dfh2e82a91246483f69@mail.gmail.com> <16de708d0801192156w2fa69e76v7014057effe8aac4@mail.gmail.com> <479300D5.5020208@gmail.com> <4794D632.1010308@poolshark.org> Message-ID: <1200940881.8042.7.camel@localhost.localdomain> On Mon, 2008-01-21 at 18:28 +0100, Denis Leroy wrote: > How about if the current "Add/Remove Software" was a directory instead > of a link to pirut. It would open up a submenu with the regular pirut > link on top, followed by a separator then a mirror of the main > application categories containing all uninstalled apps ? > Once you move away from having the uninstalled entries in the same submenus where they will end up eventually, a lot of the elegance and usefulness of abusing the regular menus for this is lost, and you can just as well use a dedicated installer app to display the hierarchy. From lordmorgul at gmail.com Mon Jan 21 19:28:01 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Mon, 21 Jan 2008 11:28:01 -0800 Subject: Experiment: an RPM that shows uninstalled apps in main menu In-Reply-To: <4794D3EC.50804@poolshark.org> References: <4792A25E.5020301@poolshark.org> <20080121165558.GA14866@nostromo.devel.redhat.com> <4794D3EC.50804@poolshark.org> Message-ID: <4794F241.8040905@gmail.com> Denis Leroy wrote: > Bill Nottingham wrote: >> Denis Leroy (denis at poolshark.org) said: >>> For kicks and giggles, I hacked up a proof-of-concept RPM here for F-8 : >>> >>> http://www.poolshark.org/src/fedora-apps-0.1-1.fc8.i386.rpm >>> >>> After installation, you'll have to restart the gnome-panel with a >>> quick 'killall gnome-panel'. The rpm is 5 MB, which is not bad for >>> almost 1000 apps (remember we're only talking about GUI apps here, >>> i.e. apps that install a desktop file). >> >> Interesting idea. You're setting yourself up for a lot of pain on the >> package maintenance side, I fear. > > Well that all depends on how much scripting I'm prepared to make :-) > > I used a number of scripts to extract the desktop and icon files out of > the RPMs, parse the desktop files, etc... in theory it's 100% > scriptable. Now, things would be considerably easier if this was > integrated into packagedb: flag packages that have desktop entries, add > information such as short description and icon. Then we could push the > idea further and add things such as screenshots, for example. Then we'd > have all the raw data necessary to create a real "fedora software > installation assistant". > > There are some challenges to providing this through a regular package > review though: may need collaboration with redhat-menus (integration > into main menu) and/or desktop-utils owners (to update list of > uninstalled apps after an RPM is installed manually). One issue right now is that all those applications show up as options in the 'open with' menus of Gnome right now, even the not installed apps. If you try to open an image with gimp while the fedora-apps rpm is installed the menu will show many image editors and viewers you don't have installed. That obviously needs to be prevented. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From denis at poolshark.org Mon Jan 21 19:36:28 2008 From: denis at poolshark.org (Denis Leroy) Date: Mon, 21 Jan 2008 20:36:28 +0100 Subject: Experiment: an RPM that shows uninstalled apps in main menu In-Reply-To: <4794F241.8040905@gmail.com> References: <4792A25E.5020301@poolshark.org> <20080121165558.GA14866@nostromo.devel.redhat.com> <4794D3EC.50804@poolshark.org> <4794F241.8040905@gmail.com> Message-ID: <4794F43C.3000808@poolshark.org> Andrew Farris wrote: > Denis Leroy wrote: >> Bill Nottingham wrote: >>> Denis Leroy (denis at poolshark.org) said: >>>> For kicks and giggles, I hacked up a proof-of-concept RPM here for >>>> F-8 : >>>> >>>> http://www.poolshark.org/src/fedora-apps-0.1-1.fc8.i386.rpm >>>> >>>> After installation, you'll have to restart the gnome-panel with a >>>> quick 'killall gnome-panel'. The rpm is 5 MB, which is not bad for >>>> almost 1000 apps (remember we're only talking about GUI apps here, >>>> i.e. apps that install a desktop file). >>> >>> Interesting idea. You're setting yourself up for a lot of pain on the >>> package maintenance side, I fear. >> >> Well that all depends on how much scripting I'm prepared to make :-) >> >> I used a number of scripts to extract the desktop and icon files out >> of the RPMs, parse the desktop files, etc... in theory it's 100% >> scriptable. Now, things would be considerably easier if this was >> integrated into packagedb: flag packages that have desktop entries, >> add information such as short description and icon. Then we could push >> the idea further and add things such as screenshots, for example. Then >> we'd have all the raw data necessary to create a real "fedora software >> installation assistant". >> >> There are some challenges to providing this through a regular package >> review though: may need collaboration with redhat-menus (integration >> into main menu) and/or desktop-utils owners (to update list of >> uninstalled apps after an RPM is installed manually). > > One issue right now is that all those applications show up as options in > the 'open with' menus of Gnome right now, even the not installed apps. > If you try to open an image with gimp while the fedora-apps rpm is > installed the menu will show many image editors and viewers you don't > have installed. That obviously needs to be prevented. Yes I noticed also. I think it's just a matter of filtering the Mime entries out of the desktop files... From jkeating at redhat.com Mon Jan 21 20:20:22 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 21 Jan 2008 15:20:22 -0500 Subject: rescue isos for use with today's rawhide Message-ID: <20080121152022.749b6b0e@redhat.com> In anticipation of the Alpha freeze tonight, I created a couple rescue isos with an updated dhcpv6client package. Using these rescue.isos you can install today's rawhide. Just choose to install vs rescue, and pick the URL method and point to your friendly rawhide mirror (or nfs and your local mirror). Please yell and scream if you have issues with your install (: -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Jan 21 20:24:37 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 21 Jan 2008 15:24:37 -0500 Subject: rescue isos for use with today's rawhide In-Reply-To: <20080121152022.749b6b0e@redhat.com> References: <20080121152022.749b6b0e@redhat.com> Message-ID: <20080121152437.01585f15@redhat.com> On Mon, 21 Jan 2008 15:20:22 -0500 Jesse Keating wrote: > In anticipation of the Alpha freeze tonight, I created a couple rescue > isos with an updated dhcpv6client package. Using these rescue.isos > you can install today's rawhide. Just choose to install vs rescue, > and pick the URL method and point to your friendly rawhide mirror (or > nfs and your local mirror). Please yell and scream if you have > issues with your install (: It would help if I provided a URL. http://koji.fedoraproject.org/rel-eng/trees/ -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Mon Jan 21 20:49:55 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 21 Jan 2008 21:49:55 +0100 Subject: rescue isos for use with today's rawhide In-Reply-To: <20080121152022.749b6b0e@redhat.com> References: <20080121152022.749b6b0e@redhat.com> Message-ID: <47950573.4020207@hhs.nl> Jesse Keating wrote: > In anticipation of the Alpha freeze tonight I guess this would be a bad time to introduce a soname change into rawhide then, so I'll wait a bit with doing that, when would be a better time? For more on this see my other mail which I'll send shortly. Regards, Hans From jkeating at redhat.com Mon Jan 21 20:52:01 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 21 Jan 2008 15:52:01 -0500 Subject: rescue isos for use with today's rawhide In-Reply-To: <47950573.4020207@hhs.nl> References: <20080121152022.749b6b0e@redhat.com> <47950573.4020207@hhs.nl> Message-ID: <20080121155201.1f6c303d@redhat.com> On Mon, 21 Jan 2008 21:49:55 +0100 Hans de Goede wrote: > I guess this would be a bad time to introduce a soname change into > rawhide then, so I'll wait a bit with doing that, when would be a > better time? > > For more on this see my other mail which I'll send shortly. Tomorrow would probably be OK. Rawhide will truck on, the alpha freeze is non-blocking. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Mon Jan 21 20:58:56 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 21 Jan 2008 21:58:56 +0100 Subject: Headsup: new (soname changing) glew headed for devel Message-ID: <47950790.8070300@hhs.nl> Hi All, I've prepared a new glew release (1.5.0) to push to rawhide, nothing special really just a bugfix release, but still upstream decided to bump the version from 1.5.0 to 1.4.0 and even though there is no ABI breakage, thus change the soname from libGLEW.so.1.4 to libGLEW.so.1.5 causing explicit ABI breakage :( I've considered patching things to keep the soname the same, but that would be too ugly. Anyways since nothing special has changed, a simple rebuild should suffice to fix all soname breakage. The following packages are affected (note I ran the query against F-8, for some reason it returns an empty list against devel) sdljava-0:0.9.1-5.fc8.x86_64 openmsx-0:0.6.3-1.fc8.x86_64 amanith-0:0.3-5.fc8.x86_64 raydium-0:1.2-4.fc8.x86_64 TnL-0:070909-2.fc8.x86_64 enblend-0:3.0-6.fc8.x86_64 And I know the following 2 are using it too in devel: ogre-1.4.6-2.fc9.x86_64 scorched3d-41.2-1.fc9.x86_64 I myself will be taking care of rebuilding: sdljava-0:0.9.1-5.fc8.x86_64 raydium-0:1.2-4.fc8.x86_64 TnL-0:070909-2.fc8.x86_64 ogre-1.4.6-2.fc9.x86_64 scorched3d-41.2-1.fc9.x86_64 Note that due to the alpha release we're about todo I'll postpone the actual building of the new glew till tomorrow. Thanks & Regards, Hans From zcerza at redhat.com Mon Jan 21 21:00:31 2008 From: zcerza at redhat.com (Zack Cerza) Date: Mon, 21 Jan 2008 16:00:31 -0500 Subject: Experiment: an RPM that shows uninstalled apps in main menu In-Reply-To: <4794F43C.3000808@poolshark.org> References: <4792A25E.5020301@poolshark.org> <20080121165558.GA14866@nostromo.devel.redhat.com> <4794D3EC.50804@poolshark.org> <4794F241.8040905@gmail.com> <4794F43C.3000808@poolshark.org> Message-ID: <479507EF.5080302@redhat.com> Denis Leroy wrote: > Andrew Farris wrote: >> Denis Leroy wrote: >>> Bill Nottingham wrote: >>>> Denis Leroy (denis at poolshark.org) said: >>>>> For kicks and giggles, I hacked up a proof-of-concept RPM here for >>>>> F-8 : >>>>> >>>>> http://www.poolshark.org/src/fedora-apps-0.1-1.fc8.i386.rpm >>>>> >>>>> After installation, you'll have to restart the gnome-panel with a >>>>> quick 'killall gnome-panel'. The rpm is 5 MB, which is not bad for >>>>> almost 1000 apps (remember we're only talking about GUI apps here, >>>>> i.e. apps that install a desktop file). >>>> >>>> Interesting idea. You're setting yourself up for a lot of pain on the >>>> package maintenance side, I fear. >>> >>> Well that all depends on how much scripting I'm prepared to make :-) >>> >>> I used a number of scripts to extract the desktop and icon files out >>> of the RPMs, parse the desktop files, etc... in theory it's 100% >>> scriptable. Now, things would be considerably easier if this was >>> integrated into packagedb: flag packages that have desktop entries, >>> add information such as short description and icon. Then we could >>> push the idea further and add things such as screenshots, for >>> example. Then we'd have all the raw data necessary to create a real >>> "fedora software installation assistant". >>> >>> There are some challenges to providing this through a regular package >>> review though: may need collaboration with redhat-menus (integration >>> into main menu) and/or desktop-utils owners (to update list of >>> uninstalled apps after an RPM is installed manually). >> >> One issue right now is that all those applications show up as options >> in the 'open with' menus of Gnome right now, even the not installed >> apps. If you try to open an image with gimp while the fedora-apps rpm >> is installed the menu will show many image editors and viewers you >> don't have installed. That obviously needs to be prevented. > > Yes I noticed also. I think it's just a matter of filtering the Mime > entries out of the desktop files... Or instead causing the desktop file to do: "system-install-packages $package && $binary $file" or similar. :) Zack From lordmorgul at gmail.com Mon Jan 21 21:06:56 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Mon, 21 Jan 2008 13:06:56 -0800 Subject: Experiment: an RPM that shows uninstalled apps in main menu In-Reply-To: <479507EF.5080302@redhat.com> References: <4792A25E.5020301@poolshark.org> <20080121165558.GA14866@nostromo.devel.redhat.com> <4794D3EC.50804@poolshark.org> <4794F241.8040905@gmail.com> <4794F43C.3000808@poolshark.org> <479507EF.5080302@redhat.com> Message-ID: <47950970.90909@gmail.com> Zack Cerza wrote: > Denis Leroy wrote: >> Andrew Farris wrote: >>> Denis Leroy wrote: >>>> Bill Nottingham wrote: >>>>> Interesting idea. You're setting yourself up for a lot of pain on the >>>>> package maintenance side, I fear. >>>> >>>> Well that all depends on how much scripting I'm prepared to make :-) >>>> >>>> I used a number of scripts to extract the desktop and icon files out >>>> of the RPMs, parse the desktop files, etc... in theory it's 100% >>>> scriptable. Now, things would be considerably easier if this was >>>> integrated into packagedb: flag packages that have desktop entries, >>>> add information such as short description and icon. Then we could >>>> push the idea further and add things such as screenshots, for >>>> example. Then we'd have all the raw data necessary to create a real >>>> "fedora software installation assistant". >>>> >>>> There are some challenges to providing this through a regular >>>> package review though: may need collaboration with redhat-menus >>>> (integration into main menu) and/or desktop-utils owners (to update >>>> list of uninstalled apps after an RPM is installed manually). >>> >>> One issue right now is that all those applications show up as options >>> in the 'open with' menus of Gnome right now, even the not installed >>> apps. If you try to open an image with gimp while the fedora-apps >>> rpm is installed the menu will show many image editors and viewers >>> you don't have installed. That obviously needs to be prevented. >> >> Yes I noticed also. I think it's just a matter of filtering the Mime >> entries out of the desktop files... > > Or instead causing the desktop file to do: "system-install-packages > $package && $binary $file" or similar. :) A variety of tricks could be employed I'm sure, but at minimum the applications actually available to open the file (installed apps) need to be the most accessible; if the other apps were still listed that'd be fine as long as its clear they are not installed yet and are in a separate sorted list (i.e. installed at the top of the menu, not installed below). -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From dwalsh at redhat.com Mon Jan 21 21:40:48 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 21 Jan 2008 16:40:48 -0500 Subject: SELinux removed from desktop cd spin? In-Reply-To: <4794C91F.9080204@city-fan.org> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <478F857A.6030502@redhat.com> <20080117180251.GA77139@dspnet.fr.eu.org> <200801171920.32764.opensource@till.name> <1200594904.3259.143.camel@cassandra.boston.redhat.com> <478FA30A.6030405@redhat.com> <20080117191051.GB84707@dspnet.fr.eu.org> <4790AA04.2020409@redhat.com> <20080118161236.GA61848@dspnet.fr.eu.org> <4790E961.5030605@redhat.com> <4794C91F.9080204@city-fan.org> Message-ID: <47951160.2050906@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Howarth wrote: > Daniel J Walsh wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Olivier Galibert wrote: >>> On Fri, Jan 18, 2008 at 08:30:44AM -0500, Daniel J Walsh wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> Olivier Galibert wrote: >>>>> On Thu, Jan 17, 2008 at 01:48:42PM -0500, Daniel J Walsh wrote: >>>>>> >>>>>> >>>>>>

>>>>>> Allow unconfined executables to map a memory region as both >>>>>> executable >>>>>> and writable, this is dangerous and the executable should be >>>>>> reported in >>>>>> bugzilla") >>>>> That should be "to map a file in a memory region", as UD's page >>>>> explains. Otherwise anyone who knows a little about dynamic >>>>> recompilers/JITs is gonna go "huh?". >>>>> >>>>> OG. >>>>> >>>> Bad cut and paste. The one I pasted was for allow_execmem. Where the >>>> definition is correct. >>> You mean Ulrich's page is incorrect then? I indeed had noticed it was >>> about execmem. >>> >>> >>>> java/mono apps are not confined by this, since >>>> they run under a different context. >>> Java/Mono are not the only programs with dynamic code generators in >>> them. >>> >>> OG. >>> >> THe attached file is the file context of all files in Rawhide (Probably >> F8) that are marked as allowing execmem/execstack. >> >> If you know of others, we need to update this list. > > Shouldn't this list also include things labelled as > unconfined_notrans_exec_t such as mock and sysreport? > > Paul. > Yes. And prelink. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkeVEWAACgkQrlYvE4MpobOAawCgm4ZSw+jBJ+e2oaxi9p+GE6FO PvYAnRwwYfsM0AsFQR5/6TzxnZ1d3rco =zZcF -----END PGP SIGNATURE----- From ajackson at redhat.com Mon Jan 21 22:09:45 2008 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 21 Jan 2008 17:09:45 -0500 Subject: Headsup: new (soname changing) glew headed for devel In-Reply-To: <47950790.8070300@hhs.nl> References: <47950790.8070300@hhs.nl> Message-ID: <1200953385.23041.0.camel@localhost.localdomain> On Mon, 2008-01-21 at 21:58 +0100, Hans de Goede wrote: > Hi All, > > I've prepared a new glew release (1.5.0) to push to rawhide, nothing special > really just a bugfix release, but still upstream decided to bump the version > from 1.5.0 to 1.4.0 and even though there is no ABI breakage, thus change the > soname from libGLEW.so.1.4 to libGLEW.so.1.5 causing explicit ABI breakage :( Ick. Perhaps consider beating upstream into using DT_SONAME of libGLEW.so.1 ? - ajax From gary at mlbassoc.com Mon Jan 21 21:58:01 2008 From: gary at mlbassoc.com (Gary Thomas) Date: Mon, 21 Jan 2008 14:58:01 -0700 Subject: rescue isos for use with today's rawhide In-Reply-To: <20080121152437.01585f15@redhat.com> References: <20080121152022.749b6b0e@redhat.com> <20080121152437.01585f15@redhat.com> Message-ID: <47951569.2050904@mlbassoc.com> Jesse Keating wrote: > On Mon, 21 Jan 2008 15:20:22 -0500 > Jesse Keating wrote: > >> In anticipation of the Alpha freeze tonight, I created a couple rescue >> isos with an updated dhcpv6client package. Using these rescue.isos >> you can install today's rawhide. Just choose to install vs rescue, >> and pick the URL method and point to your friendly rawhide mirror (or >> nfs and your local mirror). Please yell and scream if you have >> issues with your install (: > > > It would help if I provided a URL. > > http://koji.fedoraproject.org/rel-eng/trees/ Not working very well [at all for me] - anaconda dies after/during dependency analysis. What should I file this against? anaconda+rawhide seems a bit broad brushed (there are 139 bugs there, some as old as F7T1) -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ From ville.skytta at iki.fi Mon Jan 21 22:00:51 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 22 Jan 2008 00:00:51 +0200 Subject: Experiment: an RPM that shows uninstalled apps in main menu In-Reply-To: <4794F43C.3000808@poolshark.org> References: <4792A25E.5020301@poolshark.org> <4794F241.8040905@gmail.com> <4794F43C.3000808@poolshark.org> Message-ID: <200801220000.51905.ville.skytta@iki.fi> On Monday 21 January 2008, Denis Leroy wrote: > Andrew Farris wrote: > > > One issue right now is that all those applications show up as options in > > the 'open with' menus of Gnome right now, even the not installed apps. > > If you try to open an image with gimp while the fedora-apps rpm is > > installed the menu will show many image editors and viewers you don't > > have installed. That obviously needs to be prevented. > > Yes I noticed also. I think it's just a matter of filtering the Mime > entries out of the desktop files... While at it, you may want to filter TryExec entries too. From jkeating at redhat.com Mon Jan 21 22:04:00 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 21 Jan 2008 17:04:00 -0500 Subject: rescue isos for use with today's rawhide In-Reply-To: <47951569.2050904@mlbassoc.com> References: <20080121152022.749b6b0e@redhat.com> <20080121152437.01585f15@redhat.com> <47951569.2050904@mlbassoc.com> Message-ID: <20080121170400.623a50f1@redhat.com> On Mon, 21 Jan 2008 14:58:01 -0700 Gary Thomas wrote: > Not working very well [at all for me] - anaconda dies after/during > dependency analysis. > > What should I file this against? anaconda+rawhide seems a bit > broad brushed (there are 139 bugs there, some as old as F7T1) Depends on how it 'dies'. But anaconda is a good starting point, provided you provide all the right kind of information. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From marc at mwiriadi.id.au Mon Jan 21 22:08:04 2008 From: marc at mwiriadi.id.au (Marc Wiriadisastra) Date: Tue, 22 Jan 2008 07:08:04 +0900 Subject: anyone willing to package libmspack? In-Reply-To: <364d303b0801180453m289a1f6aue030b6fa89dd3c29@mail.gmail.com> References: <20080117214803.GA2568@free.fr> <364d303b0801180453m289a1f6aue030b6fa89dd3c29@mail.gmail.com> Message-ID: <1200953284.3569.27.camel@localhost.localdomain> On Fri, 2008-01-18 at 12:53 +0000, Christopher Brown wrote: > On 17/01/2008, Patrice Dumas wrote: > > Hello, > > > > Some packages use internal versions of libmspack, according to > > https://bugzilla.redhat.com/show_bug.cgi?id=427638 > > samba, clamav. And cabextract. > > > > I don't want to maintain one more package but would review it. > > Did anyone else think this was a request to package Max Spevack's libraries? > > (sorry Patrice, couldn't resist) > > -- > Christopher Brown > > http://www.chruz.com > Just a note it has been uploaded to koji. http://koji.fedoraproject.org/koji/search?terms=libmspack-0.0-0.4.20060920alpha.fc8&type=build&match=glob Cheers, Marc From j.w.r.degoede at hhs.nl Mon Jan 21 22:14:22 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 21 Jan 2008 23:14:22 +0100 Subject: Headsup: new (soname changing) glew headed for devel In-Reply-To: <1200953385.23041.0.camel@localhost.localdomain> References: <47950790.8070300@hhs.nl> <1200953385.23041.0.camel@localhost.localdomain> Message-ID: <4795193E.8060300@hhs.nl> Adam Jackson wrote: > On Mon, 2008-01-21 at 21:58 +0100, Hans de Goede wrote: >> Hi All, >> >> I've prepared a new glew release (1.5.0) to push to rawhide, nothing special >> really just a bugfix release, but still upstream decided to bump the version >> from 1.5.0 to 1.4.0 and even though there is no ABI breakage, thus change the >> soname from libGLEW.so.1.4 to libGLEW.so.1.5 causing explicit ABI breakage :( > > Ick. Perhaps consider beating upstream into using DT_SONAME of > libGLEW.so.1 ? In my experience upstream doesn't answer mail, not ever, don't ask why, thats just how things are. Note that I'm all for this change, and I'm also in contact with the debian glew maintainer, so I could even coordinate it with Debian, but I don't feel like even trying to ask upstream. Regards, Hans From pertusus at free.fr Mon Jan 21 22:17:34 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 21 Jan 2008 23:17:34 +0100 Subject: anyone willing to package libmspack? In-Reply-To: <1200953284.3569.27.camel@localhost.localdomain> References: <20080117214803.GA2568@free.fr> <364d303b0801180453m289a1f6aue030b6fa89dd3c29@mail.gmail.com> <1200953284.3569.27.camel@localhost.localdomain> Message-ID: <20080121221734.GB3303@free.fr> On Tue, Jan 22, 2008 at 07:08:04AM +0900, Marc Wiriadisastra wrote: > > > Just a note it has been uploaded to koji. > http://koji.fedoraproject.org/koji/search?terms=libmspack-0.0-0.4.20060920alpha.fc8&type=build&match=glob Thanks a lot. I have send a patch to cabextract upstream to use external libmspack. -- Pat From bruno at wolff.to Mon Jan 21 22:24:06 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 21 Jan 2008 16:24:06 -0600 Subject: rescue isos for use with today's rawhide In-Reply-To: <20080121152022.749b6b0e@redhat.com> References: <20080121152022.749b6b0e@redhat.com> Message-ID: <20080121222406.GA10142@wolff.to> On Mon, Jan 21, 2008 at 15:20:22 -0500, Jesse Keating wrote: > In anticipation of the Alpha freeze tonight, I created a couple rescue > isos with an updated dhcpv6client package. Using these rescue.isos you > can install today's rawhide. Just choose to install vs rescue, and > pick the URL method and point to your friendly rawhide mirror (or nfs > and your local mirror). Please yell and scream if you have issues with > your install (: I am entering some bugs now. Having compat-openldap, curl-devel or k3b-devel installed will block an upgrade from F8. My guess is that there are some "obsoletes" declarations missing. This would probably be nice to fix before the alpha. From bruno at wolff.to Mon Jan 21 22:33:18 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 21 Jan 2008 16:33:18 -0600 Subject: rescue isos for use with today's rawhide In-Reply-To: <20080121222406.GA10142@wolff.to> References: <20080121152022.749b6b0e@redhat.com> <20080121222406.GA10142@wolff.to> Message-ID: <20080121223318.GA13123@wolff.to> On Mon, Jan 21, 2008 at 16:24:06 -0600, Bruno Wolff III wrote: > > I am entering some bugs now. Having compat-openldap, curl-devel or k3b-devel > installed will block an upgrade from F8. My guess is that there are some > "obsoletes" declarations missing. This would probably be nice to fix before > the alpha. I should be more specific. These are blocking yum upgrades. I didn't test using anaconda. From tcallawa at redhat.com Mon Jan 21 22:39:13 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 21 Jan 2008 17:39:13 -0500 Subject: KSCSOPE Support in Fedora In-Reply-To: References: Message-ID: <1200955153.3375.0.camel@localhost.localdomain> On Thu, 2008-01-17 at 20:03 +0530, Kiran Patil wrote: > We would like to see it in Fedora as soon as possible. kscope is in Fedora now. ~spot From lfarkas at bppiac.hu Mon Jan 21 23:24:05 2008 From: lfarkas at bppiac.hu (Farkas Levente) Date: Tue, 22 Jan 2008 00:24:05 +0100 Subject: hdX vs sdX on redhat/centos 5.x with ata_piix In-Reply-To: <20080121174140.GB5373@devserv.devel.redhat.com> References: <4794D5D0.8080508@bppiac.hu> <20080121174140.GB5373@devserv.devel.redhat.com> Message-ID: <47952995.9010706@bppiac.hu> Alan Cox wrote: > On Mon, Jan 21, 2008 at 06:26:40PM +0100, Farkas Levente wrote: >> disk devices like it's the current setup on newer fedora release. we try >> to disable ide0=noprobe etc. which really disable hdX but even if the >> kernel load the libata and ata_piix driver it's still not load these disks. >> thanks in advance. > > Not without recompiling currently. can you tell what should i recompile? (i assume kernel:-) but change which kernel config to same behavior as on fedora? thanks. -- Levente "Si vis pacem para bellum!" From bpepple at fedoraproject.org Mon Jan 21 23:42:46 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 21 Jan 2008 18:42:46 -0500 Subject: FESCo Meeting Summary for 2008-01-17 Message-ID: <1200958966.1829.2.camel@kennedy> = Members Present = * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Dennis Gilmore (dgilmore) * Bill Nottingham (notting) * Warren Togami (warren) * Kevin Fenzi (nirik) * Tom Callaway (spot) * Josh Boyer (jwb) * Jesse Keating (f13) = Absent = * Christopher Aillon (caillon) * David Woodhouse (dwmw2) * Christian Iseli (c4chris) * Jeremy Katz (jeremy) = Summary = == New Package Maintainer Sponsor == * FESCo approved Manuel Wolfshant's request to become a sponsor. == F9 Feature Process == * FESCo approved the following feature for F9: * http://fedoraproject.org/wiki/Releases/FeatureDictionary * http://fedoraproject.org/wiki/Features/XenPvops * http://fedoraproject.org/wiki/Features/GoodHaskellSupport * http://fedoraproject.org/wiki/Features/freeIPA * FESCo asked for more information on the Input Method and Desktop Integration proposal before approving it. http://fedoraproject.org/wiki/Features/IMDesktopIntegration * FESCo felt the common-lisp-controller support proposal should go thru the Fedora Packaging Committee first, before being considered as a new feature. http://fedoraproject.org/wiki/Features/CommonLispController * FESCo decided that the Adding Cross Compilers proposal needed to include packaging guidelines before being considered as a new feature. http://fedoraproject.org/wiki/Features/AddingCrossCompilers IRC log can be found at: http://bpepple.fedorapeople.org/fesco/FESCo-2008-01-17.html Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From enrico.scholz at informatik.tu-chemnitz.de Tue Jan 22 00:18:51 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 22 Jan 2008 01:18:51 +0100 Subject: BIND less restrictive modes and policy In-Reply-To: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> (Adam Tkac's message of "Mon, 21 Jan 2008 12:57:38 +0100") References: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> Message-ID: <87ve5mbtlg.fsf@kosh.bigo.ensc.de> Adam Tkac writes: > Also complete /var/named/* subtree will be writable by named This is bad. Only the slaves/ and data/ (for DDNS) dirs must be writable. pz/ and the other parts of the chroot filesystem must be read-only for named. Enrico From poelstra at redhat.com Tue Jan 22 00:30:57 2008 From: poelstra at redhat.com (John Poelstra) Date: Mon, 21 Jan 2008 16:30:57 -0800 Subject: Fedora Rel-Eng Meeting Recap 2008-JAN-21 Message-ID: <47953941.6080001@redhat.com> Recap and full IRC transcript found here: http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-jan-21 Please make corrections and clarifications to the wiki page. == Meeting Summary == * Rawhide non-blocking freeze for Alpha late tonight * Alpha packages will NOT be signed with the testing key 1. would add several days of additional delay to alpha release 1. there is no checking at install time to verifiy signatures so it doesn't matter anyway * f13's plan for the day 1. get a spin done with fixed dhcp6client 1. publish the rescue.isos so that other people can test with it 1. create the freeze tag and do the intial clone over to it so that the clone tonight will be quick == IRC Transcript == From lordmorgul at gmail.com Tue Jan 22 00:32:39 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Mon, 21 Jan 2008 16:32:39 -0800 Subject: KSCSOPE Support in Fedora In-Reply-To: <1200955153.3375.0.camel@localhost.localdomain> References: <1200955153.3375.0.camel@localhost.localdomain> Message-ID: <479539A7.4040900@gmail.com> Tom "spot" Callaway wrote: > On Thu, 2008-01-17 at 20:03 +0530, Kiran Patil wrote: >> We would like to see it in Fedora as soon as possible. > > kscope is in Fedora now. > > ~spot > I think what spot meant was in Fedora 'very soon'. :) Its been submitted and built by spot, but not in repositories yet, if you've got a Fedora box and wish to grab it immediately you'll have to get it from the buildsystem (koji) here: http://koji.fedoraproject.org/koji/packageinfo?packageID=5639 And comments about whether it works wouldn't hurt, here: https://admin.fedoraproject.org/updates/search/kscope -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From bloch at verdurin.com Tue Jan 22 00:33:29 2008 From: bloch at verdurin.com (bloch at verdurin.com) Date: Tue, 22 Jan 2008 00:33:29 -0000 (UTC) Subject: rescue isos for use with today's rawhide In-Reply-To: <20080121152022.749b6b0e@redhat.com> References: <20080121152022.749b6b0e@redhat.com> Message-ID: <51320.87.194.100.54.1200962009.squirrel@webmail.cream.org> > In anticipation of the Alpha freeze tonight, I created a couple rescue > isos with an updated dhcpv6client package. Using these rescue.isos you > can install today's rawhide. Just choose to install vs rescue, and > pick the URL method and point to your friendly rawhide mirror (or nfs > and your local mirror). Please yell and scream if you have issues with > your install (: > Is there a mirror known to be appropriate for that rescue image? I've tried two UK mirrors and download.fedora.redhat.com and in each case Anaconda complains that the packages in the directory don't match the boot media (the rescue .iso on a USB stick). Adam From lordmorgul at gmail.com Tue Jan 22 00:39:57 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Mon, 21 Jan 2008 16:39:57 -0800 Subject: rescue isos for use with today's rawhide In-Reply-To: <51320.87.194.100.54.1200962009.squirrel@webmail.cream.org> References: <20080121152022.749b6b0e@redhat.com> <51320.87.194.100.54.1200962009.squirrel@webmail.cream.org> Message-ID: <47953B5D.4080600@gmail.com> bloch at verdurin.com wrote: > >> In anticipation of the Alpha freeze tonight, I created a couple rescue >> isos with an updated dhcpv6client package. Using these rescue.isos you >> can install today's rawhide. Just choose to install vs rescue, and >> pick the URL method and point to your friendly rawhide mirror (or nfs >> and your local mirror). Please yell and scream if you have issues with >> your install (: >> > > Is there a mirror known to be appropriate for that rescue image? I've > tried two UK mirrors and download.fedora.redhat.com and in each case > Anaconda complains that the packages in the directory don't match the boot > media (the rescue .iso on a USB stick). > > Adam I would expect any mirror that is current to development *should* work for that.. make sure you're getting the full path to the top of the devel repo, i.e. http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os/ (or change architecture) -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From bos at serpentine.com Tue Jan 22 01:11:13 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Mon, 21 Jan 2008 17:11:13 -0800 Subject: Package EVR problems in Fedora 2008-01-20 In-Reply-To: <20080120194533.8437D152130@buildsys.fedoraproject.org> References: <20080120194533.8437D152130@buildsys.fedoraproject.org> Message-ID: <479542B1.3020608@serpentine.com> buildsys at fedoraproject.org wrote: > bos AT serpentine com: > ghc > F8-updates > F9 (0:6.8.2-8.fc8 > 0:6.8.2-2.fc9) Fixed. From lordmorgul at gmail.com Tue Jan 22 01:17:08 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Mon, 21 Jan 2008 17:17:08 -0800 Subject: BIND less restrictive modes and policy In-Reply-To: <87ve5mbtlg.fsf@kosh.bigo.ensc.de> References: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> <87ve5mbtlg.fsf@kosh.bigo.ensc.de> Message-ID: <47954414.5060406@gmail.com> Enrico Scholz wrote: > Adam Tkac writes: > >> Also complete /var/named/* subtree will be writable by named > > This is bad. Only the slaves/ and data/ (for DDNS) dirs must be writable. > pz/ and the other parts of the chroot filesystem must be read-only for > named. And why exactly is that? Any reference or reason? What becomes exploitable if that is changed? -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From wolfy at nobugconsulting.ro Tue Jan 22 02:18:10 2008 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Tue, 22 Jan 2008 04:18:10 +0200 Subject: BIND less restrictive modes and policy In-Reply-To: <47954414.5060406@gmail.com> References: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> <87ve5mbtlg.fsf@kosh.bigo.ensc.de> <47954414.5060406@gmail.com> Message-ID: <47955262.3040805@nobugconsulting.ro> On 01/22/2008 03:17 AM, Andrew Farris wrote: > Enrico Scholz wrote: >> Adam Tkac writes: >> >>> Also complete /var/named/* subtree will be writable by named >> >> This is bad. Only the slaves/ and data/ (for DDNS) dirs must be >> writable. >> pz/ and the other parts of the chroot filesystem must be read-only for >> named. > > And why exactly is that? Any reference or reason? What becomes > exploitable if that is changed? > Bind DID have security issues in the past, providing remote root. Just because we have selinux and that as far as we know NOW there are no atack methods is not a reason to lower the difficulty bar. Just give any application the minimum rights needed to do what it has to do. Any method which raises the difficulty bar for a potential attacker -- especially when it is already available and taking into consideration potential DNS poisoning attacks -- is good. Lowering the bar with no real gain is bad. From lordmorgul at gmail.com Tue Jan 22 02:57:20 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Mon, 21 Jan 2008 18:57:20 -0800 Subject: BIND less restrictive modes and policy In-Reply-To: <47955262.3040805@nobugconsulting.ro> References: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> <87ve5mbtlg.fsf@kosh.bigo.ensc.de> <47954414.5060406@gmail.com> <47955262.3040805@nobugconsulting.ro> Message-ID: <47955B90.2000405@gmail.com> Manuel Wolfshant wrote: > On 01/22/2008 03:17 AM, Andrew Farris wrote: >> Enrico Scholz wrote: >>> Adam Tkac writes: >>> >>>> Also complete /var/named/* subtree will be writable by named >>> >>> This is bad. Only the slaves/ and data/ (for DDNS) dirs must be >>> writable. >>> pz/ and the other parts of the chroot filesystem must be read-only for >>> named. >> >> And why exactly is that? Any reference or reason? What becomes >> exploitable if that is changed? >> > Bind DID have security issues in the past, providing remote root. Just > because we have selinux and that as far as we know NOW there are no > atack methods is not a reason to lower the difficulty bar. Just give any > application the minimum rights needed to do what it has to do. > Any method which raises the difficulty bar for a potential attacker -- > especially when it is already available and taking into consideration > potential DNS poisoning attacks -- is good. Lowering the bar with no > real gain is bad. Absolutely agreed as to the best practice ideas there, generally... but you didn't say it was just 'bad' you said it 'must be read-only'. This is very different. I was asking for clarification as to why it must be, not why it would be better not to be. (but I think you answered that now in a way) I'm assuming now that: >>> This is bad. Only the slaves/ and data/ (for DDNS) dirs must be >>> writable. is necessary to function >>> pz/ and the other parts of the chroot filesystem must be read-only for >>> named. is not necessary, only 'a good idea', a change to which you are against -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From jkeating at redhat.com Tue Jan 22 03:34:54 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 21 Jan 2008 22:34:54 -0500 Subject: Fedora 9 Alpha freeze tonight Message-ID: <20080121223454.169ca5a3@redhat.com> In roughly 4 hours we will snapshot the dist-f9 collection in Koji for Fedora 9 alpha. The timing is such so that tomorrow's rawhide (20080122) will be the same package set as the alpha. Our plan is to test it up a bit and have a set of packages ready by Thursday/Friday. We will be taking tag requests, but since this is Alpha, and since rawhide will continue on unblocked we'd rather it be a pretty important reason to do the tagging. We're mostly concentrating on being able to install, and from there get updates. Cheers all! -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From cra at WPI.EDU Tue Jan 22 05:44:31 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 22 Jan 2008 00:44:31 -0500 Subject: rescue isos for use with today's rawhide In-Reply-To: <20080121152022.749b6b0e@redhat.com> References: <20080121152022.749b6b0e@redhat.com> Message-ID: <20080122054431.GA1002@angus.ind.WPI.EDU> On Mon, Jan 21, 2008 at 03:20:22PM -0500, Jesse Keating wrote: > In anticipation of the Alpha freeze tonight, I created a couple rescue > isos with an updated dhcpv6client package. Using these rescue.isos you > can install today's rawhide. Just choose to install vs rescue, and > pick the URL method and point to your friendly rawhide mirror (or nfs > and your local mirror). Please yell and scream if you have issues with > your install (: Installed fine to an encrypted PV, rhgb works fine, firstboot came up okay (but rootpassword.py crashed: bz #429243) but when X starts, I get a black screen with a bit of graphical detrius along the top inch or so, gdm doesn't display, and the console locks up hard. The mouse still moves, though. Can't change VTs. X refuses to be killed from a remote SSH session. chvt hangs. I think this bug needs some love before Alpha is released, as a lot of us have Radeon chips: https://bugzilla.redhat.com/show_bug.cgi?id=427000 From airlied at redhat.com Tue Jan 22 06:19:18 2008 From: airlied at redhat.com (Dave Airlie) Date: Tue, 22 Jan 2008 16:19:18 +1000 Subject: rescue isos for use with today's rawhide In-Reply-To: <20080122054431.GA1002@angus.ind.WPI.EDU> References: <20080121152022.749b6b0e@redhat.com> <20080122054431.GA1002@angus.ind.WPI.EDU> Message-ID: <1200982758.809.0.camel@localhost> On Tue, 2008-01-22 at 00:44 -0500, Chuck Anderson wrote: > On Mon, Jan 21, 2008 at 03:20:22PM -0500, Jesse Keating wrote: > > In anticipation of the Alpha freeze tonight, I created a couple rescue > > isos with an updated dhcpv6client package. Using these rescue.isos you > > can install today's rawhide. Just choose to install vs rescue, and > > pick the URL method and point to your friendly rawhide mirror (or nfs > > and your local mirror). Please yell and scream if you have issues with > > your install (: > > Installed fine to an encrypted PV, rhgb works fine, firstboot came up > okay (but rootpassword.py crashed: bz #429243) but when X starts, I > get a black screen with a bit of graphical detrius along the top inch > or so, gdm doesn't display, and the console locks up hard. The mouse > still moves, though. Can't change VTs. X refuses to be killed from a > remote SSH session. chvt hangs. I think this bug needs some love > before Alpha is released, as a lot of us have Radeon chips: > > https://bugzilla.redhat.com/show_bug.cgi?id=427000 Its only x600s that seem to have this problem, so you aren't a major amount of people as you'd think :) ajax reverted the kernel and libdrm pieces we think caused this in any case.. hopefully they make it in to the alpha.. Dave. From enrico.scholz at informatik.tu-chemnitz.de Tue Jan 22 08:27:14 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 22 Jan 2008 09:27:14 +0100 Subject: BIND less restrictive modes and policy In-Reply-To: <47954414.5060406@gmail.com> (Andrew Farris's message of "Mon, 21 Jan 2008 17:17:08 -0800") References: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> <87ve5mbtlg.fsf@kosh.bigo.ensc.de> <47954414.5060406@gmail.com> Message-ID: <87r6gab6zh.fsf@kosh.bigo.ensc.de> Andrew Farris writes: >> pz/ and the other parts of the chroot filesystem must be read-only >> for named. > > And why exactly is that? To give only the required rights is a common and working practice for years to secure daemons. Fedora should not forget classical ways (own uid, chroot environments, restrictive permissions) just to give something like "easier configuration" (where I can not see how mixing all and everything into a single dir can ease configuration). Enrico From lordmorgul at gmail.com Tue Jan 22 08:50:16 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Tue, 22 Jan 2008 00:50:16 -0800 Subject: BIND less restrictive modes and policy In-Reply-To: <87r6gab6zh.fsf@kosh.bigo.ensc.de> References: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> <87ve5mbtlg.fsf@kosh.bigo.ensc.de> <47954414.5060406@gmail.com> <87r6gab6zh.fsf@kosh.bigo.ensc.de> Message-ID: <4795AE48.70300@gmail.com> Enrico Scholz wrote: > Andrew Farris writes: > >>> pz/ and the other parts of the chroot filesystem must be read-only >>> for named. >> And why exactly is that? > > To give only the required rights is a common and working practice for > years to secure daemons. Fedora should not forget classical ways > (own uid, chroot environments, restrictive permissions) just to give > something like "easier configuration" (where I can not see how mixing > all and everything into a single dir can ease configuration). I understand the idea behind minimum access restrictions; my reply/question was in regard to the use of the word 'must' which I assumed to be more than suggestion based on best practice (i.e. it won't work unless..). Manuel Wolfshant said much the same that you (Enrico) did above in his reply that I replied to... (btw.. to Manuel, sorry I did misread and reply 'to you' when 'you' and 'Enrico' were not one in the same, been a long day). Anyway, that common practice is certainly not something that should be ignored lightly, but lets not confuse whether it is suggestion or necessity. (that is all I was asking) If anyone has reason to believe real *breakage* occurs due to the change Adam Tkac was suggesting I hope they speak up. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From laurent.rineau__fedora at normalesup.org Tue Jan 22 09:03:53 2008 From: laurent.rineau__fedora at normalesup.org (Laurent Rineau) Date: Tue, 22 Jan 2008 10:03:53 +0100 Subject: rpmlint: "non-conffile-in-etc" In-Reply-To: References: <5e92ee3f0801210647g7f8ce2f9x6c25f6ee2ac34e2b@mail.gmail.com> <20080121162937.GG3465@free.fr> Message-ID: <200801221003.53571@rineau.tsetse> On Monday 21 January 2008 18:37:28 Kevin Kofler wrote: > Patrice Dumas free.fr> writes: > > The bug is certainly in gnome/gconf since those files should certainly > > be in /usr/share (with a possible override in /etc). > > Interestingly, KConfig gets it wrong the opposite way, it puts the schemas > into /usr/share/config.kcfg (OK) and the config files into > /usr/share/config (not so OK). lrineau at schtroumpf ~ $ kde-config --path config /home/lrineau/.kde/share/config/:/etc/kde/:/usr/share/kde-settings/kde-profile/default/share/config/:/usr/share/config/ That means that /usr/share/config is searched *last*. Config options are first searched in my home directory, then in /etc/kde, then in /usr/share/kde-settings/kde-profile/default/share/config/, then eventually in /usr/share/config/. So KConfig does it the right way. :-) -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From wolfy at nobugconsulting.ro Tue Jan 22 09:28:48 2008 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Tue, 22 Jan 2008 11:28:48 +0200 Subject: BIND less restrictive modes and policy In-Reply-To: <4795AE48.70300@gmail.com> References: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> <87ve5mbtlg.fsf@kosh.bigo.ensc.de> <47954414.5060406@gmail.com> <87r6gab6zh.fsf@kosh.bigo.ensc.de> <4795AE48.70300@gmail.com> Message-ID: <4795B750.6040203@nobugconsulting.ro> Andrew Farris wrote: > Enrico Scholz wrote: >> Andrew Farris writes: >> >>>> pz/ and the other parts of the chroot filesystem must be read-only >>>> for named. >>> And why exactly is that? >> >> To give only the required rights is a common and working practice for >> years to secure daemons. Fedora should not forget classical ways >> (own uid, chroot environments, restrictive permissions) just to give >> something like "easier configuration" (where I can not see how mixing >> all and everything into a single dir can ease configuration). > > I understand the idea behind minimum access restrictions; my > reply/question was in regard to the use of the word 'must' which I > assumed to be more than suggestion based on best practice (i.e. it > won't work unless..). No, Enrico's reply was based on best practices and common sense, not on "mandatory, otherwise it will break things". Adam's suggestion will just lower an already existing level of security. > Anyway, that common practice is certainly not something that should be > ignored lightly, but lets not confuse whether it is suggestion or > necessity. (that is all I was asking) > > If anyone has reason to believe real *breakage* occurs due to the > change Adam Tkac was suggesting I hope they speak up. It will not break anything but best security practices, but will bring no benefit either. I support 1000.00 % Enrico's view. Having a single directory with all zone files will not bring anything useful. OTOH (this is a digression, I know) it WOULD be useful if bind would include support for real database backends. FWIW: Ever since 2000 I do "split DNS" by running two different daemons, chrooted each one it its own directory, rather then "different external / internal" views. If someone is to break my external named, (s)he will (or should) be chroot-ed to external named's directory and hopefully will not be able to find out information about my internal networks. From mike at miketc.com Tue Jan 22 10:41:04 2008 From: mike at miketc.com (Mike Chambers) Date: Tue, 22 Jan 2008 04:41:04 -0600 Subject: rescue isos for use with today's rawhide In-Reply-To: <1200982758.809.0.camel@localhost> References: <20080121152022.749b6b0e@redhat.com> <20080122054431.GA1002@angus.ind.WPI.EDU> <1200982758.809.0.camel@localhost> Message-ID: <1200998464.14913.3.camel@scrappy.miketc.com> On Tue, 2008-01-22 at 16:19 +1000, Dave Airlie wrote: > On Tue, 2008-01-22 at 00:44 -0500, Chuck Anderson wrote: > > On Mon, Jan 21, 2008 at 03:20:22PM -0500, Jesse Keating wrote: > > > In anticipation of the Alpha freeze tonight, I created a couple rescue > > > isos with an updated dhcpv6client package. Using these rescue.isos you > > > can install today's rawhide. Just choose to install vs rescue, and > > > pick the URL method and point to your friendly rawhide mirror (or nfs > > > and your local mirror). Please yell and scream if you have issues with > > > your install (: > > > > Installed fine to an encrypted PV, rhgb works fine, firstboot came up > > okay (but rootpassword.py crashed: bz #429243) but when X starts, I > > get a black screen with a bit of graphical detrius along the top inch > > or so, gdm doesn't display, and the console locks up hard. The mouse > > still moves, though. Can't change VTs. X refuses to be killed from a > > remote SSH session. chvt hangs. I think this bug needs some love > > before Alpha is released, as a lot of us have Radeon chips: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=427000 > > Its only x600s that seem to have this problem, so you aren't a major > amount of people as you'd think :) > > ajax reverted the kernel and libdrm pieces we think caused this in any > case.. hopefully they make it in to the alpha.. This (the fix) is already related to the below bug as well correct? https://bugzilla.redhat.com/show_bug.cgi?id=428813 -- Mike Chambers Madisonville, KY "The best lil town on Earth!" From dtimms at iinet.net.au Tue Jan 22 10:56:10 2008 From: dtimms at iinet.net.au (David Timms) Date: Tue, 22 Jan 2008 21:56:10 +1100 Subject: F8 to rawhide upgrade - yum python mismatch - repeatable In-Reply-To: References: Message-ID: <4795CBCA.3070007@iinet.net.au> darrell pfeifer wrote: > In current rawhide, yum (or yum utils) has a dependency on a particular > python module, but it the python chunk isn't pulled in by the yum upgrade. > After upgrading yum, yum won't run any more. I had a minimal F8 vmware VM, and yesterday intended to do a yum upgrade to get to rawhide. I installed fedora-release which gets me the fedora-development.repo and fedora-release files. I then tried a yum check-update, and saw the heap of updates. Next I yum update rpm* yum*, which seemed OK. After that yum didn't work anymore. rpm was still working, so I upgraded groups of packages at a time. I managed to kill it in this process by running out of disk space while upgrading glibc, and others ;( and now she doesn't run commands or boot, I'm going to try again to get the error message. DaveT. From lordmorgul at gmail.com Tue Jan 22 11:53:51 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Tue, 22 Jan 2008 03:53:51 -0800 Subject: F8 to rawhide upgrade - yum python mismatch - repeatable In-Reply-To: <4795CBCA.3070007@iinet.net.au> References: <4795CBCA.3070007@iinet.net.au> Message-ID: <4795D94F.1030505@gmail.com> David Timms wrote: > darrell pfeifer wrote: >> In current rawhide, yum (or yum utils) has a dependency on a particular >> python module, but it the python chunk isn't pulled in by the yum >> upgrade. >> After upgrading yum, yum won't run any more. > > I had a minimal F8 vmware VM, and yesterday intended to do a yum upgrade > to get to rawhide. I installed fedora-release which gets me the > fedora-development.repo and fedora-release files. > I then tried a yum check-update, and saw the heap of updates. > Next I yum update rpm* yum*, which seemed OK. > After that yum didn't work anymore. > rpm was still working, so I upgraded groups of packages at a time. > > I managed to kill it in this process by running out of disk space while > upgrading glibc, and others ;( and now she doesn't run commands or > boot, I'm going to try again to get the error message. > > DaveT. Ok that definitely sounds like an issue that needs looked at deeper. Upgrading rpm and yum first off should not break yum right away! Doing just yum works fine for an updated machine as I showed, but maybe the base versions of rpm and yum for F8 have issues with that update. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From jwboyer at gmail.com Tue Jan 22 12:02:01 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 22 Jan 2008 06:02:01 -0600 Subject: rescue isos for use with today's rawhide In-Reply-To: <1200998464.14913.3.camel@scrappy.miketc.com> References: <20080121152022.749b6b0e@redhat.com> <20080122054431.GA1002@angus.ind.WPI.EDU> <1200982758.809.0.camel@localhost> <1200998464.14913.3.camel@scrappy.miketc.com> Message-ID: <20080122060201.5000a122@zod.rchland.ibm.com> On Tue, 22 Jan 2008 04:41:04 -0600 Mike Chambers wrote: > On Tue, 2008-01-22 at 16:19 +1000, Dave Airlie wrote: > > On Tue, 2008-01-22 at 00:44 -0500, Chuck Anderson wrote: > > > On Mon, Jan 21, 2008 at 03:20:22PM -0500, Jesse Keating wrote: > > > > In anticipation of the Alpha freeze tonight, I created a couple rescue > > > > isos with an updated dhcpv6client package. Using these rescue.isos you > > > > can install today's rawhide. Just choose to install vs rescue, and > > > > pick the URL method and point to your friendly rawhide mirror (or nfs > > > > and your local mirror). Please yell and scream if you have issues with > > > > your install (: > > > > > > Installed fine to an encrypted PV, rhgb works fine, firstboot came up > > > okay (but rootpassword.py crashed: bz #429243) but when X starts, I > > > get a black screen with a bit of graphical detrius along the top inch > > > or so, gdm doesn't display, and the console locks up hard. The mouse > > > still moves, though. Can't change VTs. X refuses to be killed from a > > > remote SSH session. chvt hangs. I think this bug needs some love > > > before Alpha is released, as a lot of us have Radeon chips: > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=427000 > > > > Its only x600s that seem to have this problem, so you aren't a major > > amount of people as you'd think :) > > > > ajax reverted the kernel and libdrm pieces we think caused this in any > > case.. hopefully they make it in to the alpha.. > > This (the fix) is already related to the below bug as well correct? > > https://bugzilla.redhat.com/show_bug.cgi?id=428813 They seem to be related in symptom, yes. josh From jnovy at redhat.com Tue Jan 22 12:12:06 2008 From: jnovy at redhat.com (Jindrich Novy) Date: Tue, 22 Jan 2008 13:12:06 +0100 Subject: rescue isos for use with today's rawhide In-Reply-To: <20080121222406.GA10142@wolff.to> References: <20080121152022.749b6b0e@redhat.com> <20080121222406.GA10142@wolff.to> Message-ID: <20080122121206.GA2690@dhcp-lab-186.brq.redhat.com> On Mon, Jan 21, 2008 at 04:24:06PM -0600, Bruno Wolff III wrote: > On Mon, Jan 21, 2008 at 15:20:22 -0500, > Jesse Keating wrote: > > In anticipation of the Alpha freeze tonight, I created a couple rescue > > isos with an updated dhcpv6client package. Using these rescue.isos you > > can install today's rawhide. Just choose to install vs rescue, and > > pick the URL method and point to your friendly rawhide mirror (or nfs > > and your local mirror). Please yell and scream if you have issues with > > your install (: > > I am entering some bugs now. Having compat-openldap, curl-devel or k3b-devel > installed will block an upgrade from F8. My guess is that there are some > "obsoletes" declarations missing. This would probably be nice to fix before > the alpha. curl-devel -> libcurl, libcurl-devel upgrade in rawhide should work fine now with curl-7.17.1-6. Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From valent.turkovic at gmail.com Tue Jan 22 12:29:03 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 22 Jan 2008 13:29:03 +0100 Subject: selinux breaks revisor Message-ID: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> Hi, I tested revisor and wanted to make an up to date version of Fedora 8 Live CD - but selinux put a stop to that. If there was only one bug I would report it to bugzilla but if you look at my screenshots you will see that this is a much bigger issue and I guess that it would be better that revisor and selinux guys sit together and look why it makes so many AVC Denials. http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser-revisor.png http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser-revisor-2.png Cheers, Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From lkundrak at redhat.com Tue Jan 22 12:38:30 2008 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Tue, 22 Jan 2008 13:38:30 +0100 Subject: selinux breaks revisor In-Reply-To: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> Message-ID: <1201005510.7153.29.camel@localhost.localdomain> On Tue, 2008-01-22 at 13:29 +0100, Valent Turkovic wrote: > Hi, > I tested revisor and wanted to make an up to date version of Fedora 8 > Live CD - but selinux put a stop to that. > > If there was only one bug I would report it to bugzilla but if you > look at my screenshots you will see that this is a much bigger issue > and I guess that it would be better that revisor and selinux guys sit > together and look why it makes so many AVC Denials. > > http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser-revisor.png > http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser-revisor-2.png Valent, please report to Bugzilla. Please. Thanks, -- Lubomir Kundrak (Red Hat Security Response Team) From j.w.r.degoede at hhs.nl Tue Jan 22 13:00:53 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 22 Jan 2008 14:00:53 +0100 Subject: Headsup: new (soname changing) glew headed for devel In-Reply-To: <47950790.8070300@hhs.nl> References: <47950790.8070300@hhs.nl> Message-ID: <4795E905.7060002@hhs.nl> Hi All, Ok the new glew is in the devel repo and devel buildroot now, so fire of your rebuilds! Regards, Hans Hans de Goede wrote: > Hi All, > > I've prepared a new glew release (1.5.0) to push to rawhide, nothing > special really just a bugfix release, but still upstream decided to bump > the version from 1.5.0 to 1.4.0 and even though there is no ABI > breakage, thus change the soname from libGLEW.so.1.4 to libGLEW.so.1.5 > causing explicit ABI breakage :( > > I've considered patching things to keep the soname the same, but that > would be too ugly. Anyways since nothing special has changed, a simple > rebuild should suffice to fix all soname breakage. > > The following packages are affected (note I ran the query against F-8, > for some reason it returns an empty list against devel) > sdljava-0:0.9.1-5.fc8.x86_64 > openmsx-0:0.6.3-1.fc8.x86_64 > amanith-0:0.3-5.fc8.x86_64 > raydium-0:1.2-4.fc8.x86_64 > TnL-0:070909-2.fc8.x86_64 > enblend-0:3.0-6.fc8.x86_64 > > And I know the following 2 are using it too in devel: > ogre-1.4.6-2.fc9.x86_64 > scorched3d-41.2-1.fc9.x86_64 > > > I myself will be taking care of rebuilding: > sdljava-0:0.9.1-5.fc8.x86_64 > raydium-0:1.2-4.fc8.x86_64 > TnL-0:070909-2.fc8.x86_64 > ogre-1.4.6-2.fc9.x86_64 > scorched3d-41.2-1.fc9.x86_64 > > Note that due to the alpha release we're about todo I'll postpone the > actual building of the new glew till tomorrow. > > Thanks & Regards, > > Hans > From jdennis at redhat.com Tue Jan 22 13:05:02 2008 From: jdennis at redhat.com (John Dennis) Date: Tue, 22 Jan 2008 08:05:02 -0500 Subject: selinux breaks revisor In-Reply-To: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> Message-ID: <4795E9FE.60501@redhat.com> Valent Turkovic wrote: > Hi, > I tested revisor and wanted to make an up to date version of Fedora 8 > Live CD - but selinux put a stop to that. > > If there was only one bug I would report it to bugzilla but if you > look at my screenshots you will see that this is a much bigger issue > and I guess that it would be better that revisor and selinux guys sit > together and look why it makes so many AVC Denials. > > http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser-revisor.png > http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser-revisor-2.png Screenshots are not a good way to pass information. The text of the alert in setroubleshoot can be copied to the clipboard by going to the Edit menus and selecting "Copy Alert", or you can save the text in a file by going to the File menu and selecting "Save Alert". Either of these methods give you the full text of the alert for inclusion in a bugzilla or sharing in an email message. -- John Dennis From valent.turkovic at gmail.com Tue Jan 22 13:16:22 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 22 Jan 2008 14:16:22 +0100 Subject: selinux breaks revisor In-Reply-To: <1201005510.7153.29.camel@localhost.localdomain> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <1201005510.7153.29.camel@localhost.localdomain> Message-ID: <64b14b300801220516t391313e7n66b922cdf96bd04d@mail.gmail.com> On Jan 22, 2008 1:38 PM, Lubomir Kundrak wrote: > > On Tue, 2008-01-22 at 13:29 +0100, Valent Turkovic wrote: > > Hi, > > I tested revisor and wanted to make an up to date version of Fedora 8 > > Live CD - but selinux put a stop to that. > > > > If there was only one bug I would report it to bugzilla but if you > > look at my screenshots you will see that this is a much bigger issue > > and I guess that it would be better that revisor and selinux guys sit > > together and look why it makes so many AVC Denials. > > > > http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser-revisor.png > > http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser-revisor-2.png > > Valent, please report to Bugzilla. > Please. > > Thanks, > -- > Lubomir Kundrak (Red Hat Security Response Team) I entered these bugs: https://bugzilla.redhat.com/show_bug.cgi?id=429681 https://bugzilla.redhat.com/show_bug.cgi?id=429676 https://bugzilla.redhat.com/show_bug.cgi?id=429677 https://bugzilla.redhat.com/show_bug.cgi?id=429678 https://bugzilla.redhat.com/show_bug.cgi?id=429682 https://bugzilla.redhat.com/show_bug.cgi?id=429683 https://bugzilla.redhat.com/show_bug.cgi?id=429684 and now bugzilla says it is busy, looks I broke the bugzilla also :) Do I get a cookie now? :) Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From valent.turkovic at gmail.com Tue Jan 22 13:18:40 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 22 Jan 2008 14:18:40 +0100 Subject: selinux breaks revisor In-Reply-To: <4795E9FE.60501@redhat.com> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <4795E9FE.60501@redhat.com> Message-ID: <64b14b300801220518u6fc2598ew40d333aec99b12ce@mail.gmail.com> On Jan 22, 2008 2:05 PM, John Dennis wrote: > Valent Turkovic wrote: > > Hi, > > I tested revisor and wanted to make an up to date version of Fedora 8 > > Live CD - but selinux put a stop to that. > > > > If there was only one bug I would report it to bugzilla but if you > > look at my screenshots you will see that this is a much bigger issue > > and I guess that it would be better that revisor and selinux guys sit > > together and look why it makes so many AVC Denials. > > > > http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser-revisor.png > > http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser-revisor-2.png > > Screenshots are not a good way to pass information. The text of the > alert in setroubleshoot can be copied to the clipboard by going to the > Edit menus and selecting "Copy Alert", or you can save the text in a > file by going to the File menu and selecting "Save Alert". > > Either of these methods give you the full text of the alert for > inclusion in a bugzilla or sharing in an email message. > > -- > John Dennis That is why I suggested that you (devels and mainainers of selinux and revisor) try for your self and look at the number of AVC Denials... This looks like a pattern in fedora, looks like nobody actually does testing of these new features. If anybody tried to make a spin just to test if revisor works these errors should have sufaced... no? Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From valent.turkovic at gmail.com Tue Jan 22 13:24:01 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 22 Jan 2008 14:24:01 +0100 Subject: selinux breaks revisor In-Reply-To: <64b14b300801220516t391313e7n66b922cdf96bd04d@mail.gmail.com> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <1201005510.7153.29.camel@localhost.localdomain> <64b14b300801220516t391313e7n66b922cdf96bd04d@mail.gmail.com> Message-ID: <64b14b300801220524v787f4ee5v45b874ce42162e4e@mail.gmail.com> On Jan 22, 2008 2:16 PM, Valent Turkovic wrote: > On Jan 22, 2008 1:38 PM, Lubomir Kundrak wrote: > > > > On Tue, 2008-01-22 at 13:29 +0100, Valent Turkovic wrote: > > > Hi, > > > I tested revisor and wanted to make an up to date version of Fedora 8 > > > Live CD - but selinux put a stop to that. > > > > > > If there was only one bug I would report it to bugzilla but if you > > > look at my screenshots you will see that this is a much bigger issue > > > and I guess that it would be better that revisor and selinux guys sit > > > together and look why it makes so many AVC Denials. > > > > > > http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser-revisor.png > > > http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser-revisor-2.png > > > > Valent, please report to Bugzilla. > > Please. > > > > Thanks, > > -- > > Lubomir Kundrak (Red Hat Security Response Team) > > I entered these bugs: > https://bugzilla.redhat.com/show_bug.cgi?id=429681 > https://bugzilla.redhat.com/show_bug.cgi?id=429676 > https://bugzilla.redhat.com/show_bug.cgi?id=429677 > https://bugzilla.redhat.com/show_bug.cgi?id=429678 > https://bugzilla.redhat.com/show_bug.cgi?id=429682 > https://bugzilla.redhat.com/show_bug.cgi?id=429683 > https://bugzilla.redhat.com/show_bug.cgi?id=429684 > > and now bugzilla says it is busy, looks I broke the bugzilla also :) > > Do I get a cookie now? :) > > > Valent. and two new ones: https://bugzilla.redhat.com/show_bug.cgi?id=429685 https://bugzilla.redhat.com/show_bug.cgi?id=429686 -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From dtimms at iinet.net.au Tue Jan 22 13:24:41 2008 From: dtimms at iinet.net.au (David Timms) Date: Wed, 23 Jan 2008 00:24:41 +1100 Subject: F8 to rawhide upgrade - yum python mismatch - repeatable In-Reply-To: <4795D94F.1030505@gmail.com> References: <4795CBCA.3070007@iinet.net.au> <4795D94F.1030505@gmail.com> Message-ID: <4795EE99.3000209@iinet.net.au> Andrew Farris wrote: > David Timms wrote: >> Next I yum update rpm* yum*, which seemed OK. >> After that yum didn't work anymore. ... > Ok that definitely sounds like an issue that needs looked at deeper. > Upgrading rpm and yum first off should not break yum right away! Doing > just yum works fine for an updated machine as I showed, but maybe the > base versions of rpm and yum for F8 have issues with that update. OK, made that install work again: $ rpm -qa yum\* rpm\* python\* sql\*|sort python-2.5.1-21.fc9 python-iniparse-0.2.3-3.fc9 python-libs-2.5.1-21.fc9 python-numeric-24.2-6.fc8 python-setuptools-0.6c7-2.fc8 python-urlgrabber-3.0.0-3.fc8 rpm-4.4.2.2-13.fc9 rpm-libs-4.4.2.2-13.fc9 rpm-python-4.4.2.2-13.fc9 rpm -qa|sort sqlite-3.5.4-2.fc9 yum-3.2.8-2.fc8 yum-metadata-parser-1.1.2-4.fc9 [davidt at localhost ~]$ yum --help There was a problem importing one of the Python modules required to run yum. The error leading to this problem was: /usr/lib/python2.5/site-packages/_sqlitecache.so: undefined symbol: g_assertion_message_expr Please install a package which provides this module, or verify that the module is installed correctly. It's possible that the above module doesn't match the current version of Python, which is: 2.5.1 (r251:54863, Jan 17 2008, 11:02:11) [GCC 4.1.2 20071124 (Red Hat 4.1.2-36)] If you cannot solve this problem yourself, please go to the yum faq at: http://wiki.linux.duke.edu/YumFaq $ uname -a Linux localhost.localdomain 2.6.23.9-85.fc8 #1 SMP Fri Dec 7 15:49:59 EST 2007 i686 athlon i386 GNU/Linux Is this a "silly" on my part / would a bugzilla be appreciated ? DaveT From ajackson at redhat.com Tue Jan 22 13:43:20 2008 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 22 Jan 2008 08:43:20 -0500 Subject: rescue isos for use with today's rawhide In-Reply-To: <20080122060201.5000a122@zod.rchland.ibm.com> References: <20080121152022.749b6b0e@redhat.com> <20080122054431.GA1002@angus.ind.WPI.EDU> <1200982758.809.0.camel@localhost> <1200998464.14913.3.camel@scrappy.miketc.com> <20080122060201.5000a122@zod.rchland.ibm.com> Message-ID: <1201009400.23041.25.camel@localhost.localdomain> On Tue, 2008-01-22 at 06:02 -0600, Josh Boyer wrote: > On Tue, 22 Jan 2008 04:41:04 -0600 > Mike Chambers wrote: > > On Tue, 2008-01-22 at 16:19 +1000, Dave Airlie wrote: > > > On Tue, 2008-01-22 at 00:44 -0500, Chuck Anderson wrote: > > > > Installed fine to an encrypted PV, rhgb works fine, firstboot came up > > > > okay (but rootpassword.py crashed: bz #429243) but when X starts, I > > > > get a black screen with a bit of graphical detrius along the top inch > > > > or so, gdm doesn't display, and the console locks up hard. The mouse > > > > still moves, though. Can't change VTs. X refuses to be killed from a > > > > remote SSH session. chvt hangs. I think this bug needs some love > > > > before Alpha is released, as a lot of us have Radeon chips: > > > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=427000 > > > > > > Its only x600s that seem to have this problem, so you aren't a major > > > amount of people as you'd think :) > > > > > > ajax reverted the kernel and libdrm pieces we think caused this in any > > > case.. hopefully they make it in to the alpha.. > > > > This (the fix) is already related to the below bug as well correct? > > > > https://bugzilla.redhat.com/show_bug.cgi?id=428813 > > They seem to be related in symptom, yes. X not launching at all is definitely the libdrm+kernel change. VT switch might be a secondary bug. - ajax From skvidal at fedoraproject.org Tue Jan 22 13:27:53 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 22 Jan 2008 08:27:53 -0500 Subject: F8 to rawhide upgrade - yum python mismatch - repeatable In-Reply-To: <4795EE99.3000209@iinet.net.au> References: <4795CBCA.3070007@iinet.net.au> <4795D94F.1030505@gmail.com> <4795EE99.3000209@iinet.net.au> Message-ID: <1201008473.6218.2.camel@cutter> On Wed, 2008-01-23 at 00:24 +1100, David Timms wrote: > Andrew Farris wrote: > > David Timms wrote: > >> Next I yum update rpm* yum*, which seemed OK. > >> After that yum didn't work anymore. > ... > > > Ok that definitely sounds like an issue that needs looked at deeper. > > Upgrading rpm and yum first off should not break yum right away! Doing > > just yum works fine for an updated machine as I showed, but maybe the > > base versions of rpm and yum for F8 have issues with that update. > OK, made that install work again: > $ rpm -qa yum\* rpm\* python\* sql\*|sort > python-2.5.1-21.fc9 > python-iniparse-0.2.3-3.fc9 > python-libs-2.5.1-21.fc9 > python-numeric-24.2-6.fc8 > python-setuptools-0.6c7-2.fc8 > python-urlgrabber-3.0.0-3.fc8 > rpm-4.4.2.2-13.fc9 > rpm-libs-4.4.2.2-13.fc9 > rpm-python-4.4.2.2-13.fc9 > rpm -qa|sort > sqlite-3.5.4-2.fc9 > yum-3.2.8-2.fc8 > yum-metadata-parser-1.1.2-4.fc9 > [davidt at localhost ~]$ yum --help > There was a problem importing one of the Python modules > required to run yum. The error leading to this problem was: > > /usr/lib/python2.5/site-packages/_sqlitecache.so: undefined symbol: > g_assertion_message_expr > > Please install a package which provides this module, or > verify that the module is installed correctly. > > It's possible that the above module doesn't match the > current version of Python, which is: > 2.5.1 (r251:54863, Jan 17 2008, 11:02:11) > [GCC 4.1.2 20071124 (Red Hat 4.1.2-36)] > > If you cannot solve this problem yourself, please go to > the yum faq at: > http://wiki.linux.duke.edu/YumFaq > > $ uname -a > Linux localhost.localdomain 2.6.23.9-85.fc8 #1 SMP Fri Dec 7 15:49:59 > EST 2007 i686 athlon i386 GNU/Linux > > Is this a "silly" on my part / would a bugzilla be appreciated ? > bugzilla would be appreciated, yes, thanks. -sv From ssorce at redhat.com Tue Jan 22 13:32:25 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 22 Jan 2008 08:32:25 -0500 Subject: BIND less restrictive modes and policy In-Reply-To: <87ve5mbtlg.fsf@kosh.bigo.ensc.de> References: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> <87ve5mbtlg.fsf@kosh.bigo.ensc.de> Message-ID: <1201008745.10767.203.camel@localhost.localdomain> On Tue, 2008-01-22 at 01:18 +0100, Enrico Scholz wrote: > Adam Tkac writes: > > > Also complete /var/named/* subtree will be writable by named > > This is bad. Only the slaves/ and data/ (for DDNS) dirs must be writable. > pz/ and the other parts of the chroot filesystem must be read-only for > named. Enrico can you explain what would that prevent/change ? Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From lordmorgul at gmail.com Tue Jan 22 13:32:15 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Tue, 22 Jan 2008 05:32:15 -0800 Subject: F8 to rawhide upgrade - yum python mismatch - repeatable In-Reply-To: <4795EE99.3000209@iinet.net.au> References: <4795CBCA.3070007@iinet.net.au> <4795D94F.1030505@gmail.com> <4795EE99.3000209@iinet.net.au> Message-ID: <4795F05F.6010700@gmail.com> David Timms wrote: > Andrew Farris wrote: >> David Timms wrote: >>> Next I yum update rpm* yum*, which seemed OK. >>> After that yum didn't work anymore. > ... > >> Ok that definitely sounds like an issue that needs looked at deeper. >> Upgrading rpm and yum first off should not break yum right away! >> Doing just yum works fine for an updated machine as I showed, but >> maybe the base versions of rpm and yum for F8 have issues with that >> update. > OK, made that install work again: > $ rpm -qa yum\* rpm\* python\* sql\*|sort > python-2.5.1-21.fc9 > python-iniparse-0.2.3-3.fc9 > python-libs-2.5.1-21.fc9 > python-numeric-24.2-6.fc8 > python-setuptools-0.6c7-2.fc8 > python-urlgrabber-3.0.0-3.fc8 > rpm-4.4.2.2-13.fc9 > rpm-libs-4.4.2.2-13.fc9 > rpm-python-4.4.2.2-13.fc9 > rpm -qa|sort > sqlite-3.5.4-2.fc9 > yum-3.2.8-2.fc8 > yum-metadata-parser-1.1.2-4.fc9 > [davidt at localhost ~]$ yum --help > There was a problem importing one of the Python modules > required to run yum. The error leading to this problem was: > > /usr/lib/python2.5/site-packages/_sqlitecache.so: undefined symbol: > g_assertion_message_expr > > Please install a package which provides this module, or > verify that the module is installed correctly. > > It's possible that the above module doesn't match the > current version of Python, which is: > 2.5.1 (r251:54863, Jan 17 2008, 11:02:11) > [GCC 4.1.2 20071124 (Red Hat 4.1.2-36)] > > If you cannot solve this problem yourself, please go to > the yum faq at: > http://wiki.linux.duke.edu/YumFaq > > $ uname -a > Linux localhost.localdomain 2.6.23.9-85.fc8 #1 SMP Fri Dec 7 15:49:59 > EST 2007 i686 athlon i386 GNU/Linux > > Is this a "silly" on my part / would a bugzilla be appreciated ? > > DaveT > Yes, python-urlgrabber should have been upgraded to fc9 as should the other python rpms. It looks like there could be a requires missing to get those to move up to the fc9 version. Did you see anything about that when updating python? Do you have the yumskipbroken plugin when doing that upgrade? -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From sundaram at fedoraproject.org Tue Jan 22 13:43:01 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 22 Jan 2008 19:13:01 +0530 Subject: selinux breaks revisor In-Reply-To: <64b14b300801220518u6fc2598ew40d333aec99b12ce@mail.gmail.com> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <4795E9FE.60501@redhat.com> <64b14b300801220518u6fc2598ew40d333aec99b12ce@mail.gmail.com> Message-ID: <4795F2E5.1040409@fedoraproject.org> Valent Turkovic wrote: > > This looks like a pattern in fedora, looks like nobody actually does > testing of these new features. If anybody tried to make a spin just to > test if revisor works these errors should have sufaced... no? Such assumptions are frequently wrong. Revisor or SELinux policy packages might get updated. We could have tried different things in revisor. System SELinux labeling might be wrong because you disabled it in between and so on. Rahul From ben.kreuter at gmail.com Tue Jan 22 13:34:24 2008 From: ben.kreuter at gmail.com (Benjamin Kreuter) Date: Tue, 22 Jan 2008 08:34:24 -0500 Subject: selinux breaks revisor In-Reply-To: <64b14b300801220516t391313e7n66b922cdf96bd04d@mail.gmail.com> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <1201005510.7153.29.camel@localhost.localdomain> <64b14b300801220516t391313e7n66b922cdf96bd04d@mail.gmail.com> Message-ID: <200801220834.29206.ben.kreuter@gmail.com> On Tuesday 22 January 2008 08:16:22 Valent Turkovic wrote: > > Do I get a cookie now? :) > > Valent. > No, sorry, no cookies today. Some of those appear to be duplicates; did you receive the same SELinux denial multiple times? -- Benjamin Kreuter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From skvidal at fedoraproject.org Tue Jan 22 13:49:55 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 22 Jan 2008 08:49:55 -0500 Subject: F8 to rawhide upgrade - yum python mismatch - repeatable In-Reply-To: <4795EE99.3000209@iinet.net.au> References: <4795CBCA.3070007@iinet.net.au> <4795D94F.1030505@gmail.com> <4795EE99.3000209@iinet.net.au> Message-ID: <1201009795.6218.4.camel@cutter> On Wed, 2008-01-23 at 00:24 +1100, David Timms wrote: > Andrew Farris wrote: > > David Timms wrote: > >> Next I yum update rpm* yum*, which seemed OK. > >> After that yum didn't work anymore. > ... > > > Ok that definitely sounds like an issue that needs looked at deeper. > > Upgrading rpm and yum first off should not break yum right away! Doing > > just yum works fine for an updated machine as I showed, but maybe the > > base versions of rpm and yum for F8 have issues with that update. > OK, made that install work again: > $ rpm -qa yum\* rpm\* python\* sql\*|sort > python-2.5.1-21.fc9 > python-iniparse-0.2.3-3.fc9 > python-libs-2.5.1-21.fc9 > python-numeric-24.2-6.fc8 > python-setuptools-0.6c7-2.fc8 > python-urlgrabber-3.0.0-3.fc8 > rpm-4.4.2.2-13.fc9 > rpm-libs-4.4.2.2-13.fc9 > rpm-python-4.4.2.2-13.fc9 > rpm -qa|sort > sqlite-3.5.4-2.fc9 > yum-3.2.8-2.fc8 > yum-metadata-parser-1.1.2-4.fc9 > [davidt at localhost ~]$ yum --help > There was a problem importing one of the Python modules > required to run yum. The error leading to this problem was: > > /usr/lib/python2.5/site-packages/_sqlitecache.so: undefined symbol: > g_assertion_message_expr > > Please install a package which provides this module, or > verify that the module is installed correctly. > > It's possible that the above module doesn't match the > current version of Python, which is: > 2.5.1 (r251:54863, Jan 17 2008, 11:02:11) > [GCC 4.1.2 20071124 (Red Hat 4.1.2-36)] > > If you cannot solve this problem yourself, please go to > the yum faq at: > http://wiki.linux.duke.edu/YumFaq > > $ uname -a > Linux localhost.localdomain 2.6.23.9-85.fc8 #1 SMP Fri Dec 7 15:49:59 > EST 2007 i686 athlon i386 GNU/Linux > > Is this a "silly" on my part / would a bugzilla be appreciated ? > remove yum-metadata-parser via rpm -e, please and then try running yum. if yum works then yum install yum-metadata-parser and tell me if it still balks. -sv From valent.turkovic at gmail.com Tue Jan 22 13:52:57 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 22 Jan 2008 14:52:57 +0100 Subject: selinux breaks revisor In-Reply-To: <200801220834.29206.ben.kreuter@gmail.com> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <1201005510.7153.29.camel@localhost.localdomain> <64b14b300801220516t391313e7n66b922cdf96bd04d@mail.gmail.com> <200801220834.29206.ben.kreuter@gmail.com> Message-ID: <64b14b300801220552u32a3cbd6wa085ae5017d5faf3@mail.gmail.com> 2008/1/22 Benjamin Kreuter : > On Tuesday 22 January 2008 08:16:22 Valent Turkovic wrote: > > > > Do I get a cookie now? :) > > > > Valent. > > > > No, sorry, no cookies today. Some of those appear to be duplicates; did you > receive the same SELinux denial multiple times? > > -- Benjamin Kreuter http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser-errors-galore.png Please look at this screenshot - these AVC Denials are only from running revisor. Bold ones are the ones I still didn't report to bugzilla. This is ridiculous - I can sit for next hour and just copy/paste errors selinux spits out... and I have to do my work also :) If it is crucial tell me and I'll post them tomorrow, but I still urge you to look for your self why so much errors are occurring. Cheers, Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From ben.kreuter at gmail.com Tue Jan 22 14:04:19 2008 From: ben.kreuter at gmail.com (Benjamin Kreuter) Date: Tue, 22 Jan 2008 09:04:19 -0500 Subject: selinux breaks revisor In-Reply-To: <64b14b300801220552u32a3cbd6wa085ae5017d5faf3@mail.gmail.com> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <200801220834.29206.ben.kreuter@gmail.com> <64b14b300801220552u32a3cbd6wa085ae5017d5faf3@mail.gmail.com> Message-ID: <200801220904.23465.ben.kreuter@gmail.com> On Tuesday 22 January 2008 08:52:57 Valent Turkovic wrote: > > http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser- >errors-galore.png > Sorry, no luck with that image -- just a broken image icon and some text from uploadgeek. I'm not an active Revisor contributor, so I am probably not in a position to advise you on this. I was only noting that many of those bug reports appeared to be duplicates, which could be the result of some erroneous code in a loop. -- Benjamin Kreuter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From cra at WPI.EDU Tue Jan 22 14:19:02 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 22 Jan 2008 09:19:02 -0500 Subject: BIND less restrictive modes and policy In-Reply-To: <20080121153636.GA2893@evileye.atkac.englab.brq.redhat.com> References: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> <20080121131902.GA12493@dudweiler.stuttgart.redhat.com> <20080121153636.GA2893@evileye.atkac.englab.brq.redhat.com> Message-ID: <20080122141902.GJ26108@angus.ind.WPI.EDU> On Mon, Jan 21, 2008 at 04:36:36PM +0100, Adam Tkac wrote: > On Mon, Jan 21, 2008 at 02:19:02PM +0100, Florian La Roche wrote: > > > All other will be readable for all. Also complete /var/named/* subtree > > > will be writable by named (for generating core files, DDNS updates, > > > secondary servers, generally for easier configuration). > > We should make /var/named directory writable for named (upstream has > same opinion, see > https://bugzilla.redhat.com/show_bug.cgi?id=400461#c17). So if We have > > - /etc/{named.conf,rndc.conf,rndc.key} + logfile non-readable for > others (ok, world readable named.conf is quite suspicious so leave > it private as is) > - /var/named will be writable and read-only permissions will be set > per-zone by admin > - /var/named/* subdirectories will stop exist and files will be moved > to /var/named/ I think we just need to have the directory specified by "directory" in /etc/named.conf be writeable. That is the CWD of the named process, and is where any coredumps would be written. So perhaps instead of doing this overhaul of directory layout and permissions, we can just change the default directory to "/var/named/data" instead: options { directory "/var/named/data"; This will affect zone file configurations--they will need to use either the full path to the zone file, or perhaps a relative path like "../slaves/foo.zone" which I've not tested to see if it works, e.g.: zone "localhost" { type master; file "../localhost"; }; From jonathan.underwood at gmail.com Tue Jan 22 14:21:26 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 22 Jan 2008 14:21:26 +0000 Subject: Should vim-X11 conflict with vim-enhanced ? In-Reply-To: <668bb39a0801150919j192c0d97r1d5b482da749dd75@mail.gmail.com> References: <478CB7A3.8000206@redhat.com> <668bb39a0801150750g5360417bvc208b7d87587c4ed@mail.gmail.com> <200801151702.12768.opensource@till.name> <668bb39a0801150919j192c0d97r1d5b482da749dd75@mail.gmail.com> Message-ID: <645d17210801220621i649128aak87203e8a73025f19@mail.gmail.com> On 15/01/2008, Micha? Bentkowski wrote: > 15-01-08, Till Maas napisa?(a): > > Alternatives (man alternatives) can be used for this, there is no need to > > write a wrapper. Still the question why someone would want to run vim from > > the vim-enhanced package if vim-X11 is also installed is not answered. > > But it's possible that someone might like to do so. We shouldn't force > anybody to do anything. If someone wants to have -X11 and -enhanced > installed and use the second one - that's his business, he ought not > be prevented from doing that. Right - isn't this exactly the same situation as with emacs and emacs-nox - there a wrapper script and alternatives is used. From valent.turkovic at gmail.com Tue Jan 22 14:22:14 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 22 Jan 2008 15:22:14 +0100 Subject: selinux breaks revisor In-Reply-To: <200801220904.23465.ben.kreuter@gmail.com> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <200801220834.29206.ben.kreuter@gmail.com> <64b14b300801220552u32a3cbd6wa085ae5017d5faf3@mail.gmail.com> <200801220904.23465.ben.kreuter@gmail.com> Message-ID: <64b14b300801220622r3d0c9e72l671f4ff755920c65@mail.gmail.com> 2008/1/22 Benjamin Kreuter : > On Tuesday 22 January 2008 08:52:57 Valent Turkovic wrote: > > > > http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser- > >errors-galore.png > > > > Sorry, no luck with that image -- just a broken image icon and some text from > uploadgeek. > > I'm not an active Revisor contributor, so I am probably not in a position to > advise you on this. I was only noting that many of those bug reports > appeared to be duplicates, which could be the result of some erroneous code > in a loop. > > -- Benjamin Kreuter > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > This should work: http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot browser-errors-galore.png -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From valent.turkovic at gmail.com Tue Jan 22 14:25:58 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 22 Jan 2008 15:25:58 +0100 Subject: selinux breaks revisor In-Reply-To: <64b14b300801220622r3d0c9e72l671f4ff755920c65@mail.gmail.com> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <200801220834.29206.ben.kreuter@gmail.com> <64b14b300801220552u32a3cbd6wa085ae5017d5faf3@mail.gmail.com> <200801220904.23465.ben.kreuter@gmail.com> <64b14b300801220622r3d0c9e72l671f4ff755920c65@mail.gmail.com> Message-ID: <64b14b300801220625m1e5ec00et31e21d57abe1e1df@mail.gmail.com> On Jan 22, 2008 3:22 PM, Valent Turkovic wrote: > 2008/1/22 Benjamin Kreuter : > > > On Tuesday 22 January 2008 08:52:57 Valent Turkovic wrote: > > > > > > http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser- > > >errors-galore.png > > > > > > > Sorry, no luck with that image -- just a broken image icon and some text from > > uploadgeek. > > > > I'm not an active Revisor contributor, so I am probably not in a position to > > advise you on this. I was only noting that many of those bug reports > > appeared to be duplicates, which could be the result of some erroneous code > > in a loop. > > > > -- Benjamin Kreuter > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > This should work: > http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot > browser-errors-galore.png > http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browser-errors-galore.png third time is the charm :) -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From cra at WPI.EDU Tue Jan 22 14:26:33 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 22 Jan 2008 09:26:33 -0500 Subject: BIND less restrictive modes and policy In-Reply-To: <20080121155721.GA30491@evileye.atkac.englab.brq.redhat.com> References: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> <20080121131902.GA12493@dudweiler.stuttgart.redhat.com> <20080121153636.GA2893@evileye.atkac.englab.brq.redhat.com> <20080121154853.GC1491367@hiwaay.net> <20080121155721.GA30491@evileye.atkac.englab.brq.redhat.com> Message-ID: <20080122142633.GK26108@angus.ind.WPI.EDU> On Mon, Jan 21, 2008 at 04:57:21PM +0100, Adam Tkac wrote: > On Mon, Jan 21, 2008 at 09:48:53AM -0600, Chris Adams wrote: > > Once upon a time, Adam Tkac said: > > > - /var/named will be writable and read-only permissions will be set > > > per-zone by admin > > > > If the directory is writable, read-only file permissions are > > meaningless. > > > > Maybe but what other solution will be better? I could create separate > read-only directory inside /var/named (called "masters" for example) > and put all read-only zones there but I'm not sure if admins will like > it and use it. If directory layout changes are necessary, I'd rather that very minimal changes be made, but this seems like a good change to make to allow having master zone files that aren't writeable by the named user. So I propose to keep the existing directory split and add the masters/ subdirectory if and only if it ends up being necessary to change permissions on /var/named/ to be writeable by the named process. I think we should investigate whether using 'directory "/var/named/data";' like I mentioned in my other email works first. How would people feel about needing full or ../ relative paths in zone "file" statements? I'll test this setup now to see if it helps with coredumps, but I don't think this is the root cause of the coredump failure. I tried running BIND in various ways to allow coredumps to work, and even when running it as root with SELinux set to permissive it failed to dump core. I think there are problems with the logic of the code that sets the Linux Capability bits. From bpepple at fedoraproject.org Tue Jan 22 14:41:05 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 22 Jan 2008 09:41:05 -0500 Subject: New Sponsor Request: Ruben Kerkhof Message-ID: <1201012865.4918.12.camel@nixon> Ruben Kerkhof(1) has requested to be made a sponsor. FESCo will vote on his request at the 2008-01-31 meeting. Here are links to some of work: https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&version=&component=&query_format=advanced&bug_status=CLOSED&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&fixed_in_type=allwordssubstr&fixed_in=&qa_whiteboard_type=allwordssubstr&qa_whiteboard=&keywords_type=allwords&keywords=&emailassigned_to1=1&emailtype1=exact&email1=ruben%40rubenkerkhof.com&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= (1) http://fedoraproject.org/wiki/RubenKerkhof BTW, any Fedora packager that wishes to become a sponsor, please contact me or go directly to: http://fedoraproject.org/wiki/Extras/Schedule/NewSponsors Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Tue Jan 22 14:51:52 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 22 Jan 2008 09:51:52 -0500 Subject: selinux breaks revisor In-Reply-To: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> Message-ID: <20080122095152.73f3fab5@redhat.com> On Tue, 22 Jan 2008 13:29:03 +0100 "Valent Turkovic" wrote: > I tested revisor and wanted to make an up to date version of Fedora 8 > Live CD - but selinux put a stop to that. Selinux is not going to work at all for things like revisor (and pungi/livecd-creator). Both make use of chroots to install packages into, and in certain cases you can wind up causing lots of harm to your host system (installing a new policy in the chroot will actually cause that policy to activate on the running kernel and then you have policy that doesn't match labels, watch the fun!). It is strongly recommended that you disable SELinux or at least put it in permissive if you're going to be doing composes. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From paul at city-fan.org Tue Jan 22 15:25:33 2008 From: paul at city-fan.org (Paul Howarth) Date: Tue, 22 Jan 2008 15:25:33 +0000 Subject: selinux breaks revisor In-Reply-To: <20080122095152.73f3fab5@redhat.com> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <20080122095152.73f3fab5@redhat.com> Message-ID: <47960AED.8010405@city-fan.org> Jesse Keating wrote: > On Tue, 22 Jan 2008 13:29:03 +0100 > "Valent Turkovic" wrote: > >> I tested revisor and wanted to make an up to date version of Fedora 8 >> Live CD - but selinux put a stop to that. > > Selinux is not going to work at all for things like revisor (and > pungi/livecd-creator). Both make use of chroots to install packages > into, and in certain cases you can wind up causing lots of harm to your > host system (installing a new policy in the chroot will actually cause > that policy to activate on the running kernel and then you have policy > that doesn't match labels, watch the fun!). > > It is strongly recommended that you disable SELinux or at least put it > in permissive if you're going to be doing composes. Would it not be possible for apps like these compose tools to use an LD_PRELOAD libselinux hack like mock used to do in order to avoid these pitfalls? I happily use selinux in enforcing mode on my desktop and would be loathed to disable it in order to run one of these tools if I needed to do so simply because of the long time it would take to relabel my system afterwards to get it back to the state it started in. That's not to mention the obvious disadvantage from a security perspective, and the impression it gives that two of Fedora's top features (SELinux and the custom respin tools) conflict with each other. Paul. From valent.turkovic at gmail.com Tue Jan 22 15:42:00 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 22 Jan 2008 16:42:00 +0100 Subject: selinux breaks revisor In-Reply-To: <20080122095152.73f3fab5@redhat.com> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <20080122095152.73f3fab5@redhat.com> Message-ID: <64b14b300801220742n10de35cbs587f419f5b000347@mail.gmail.com> 2008/1/22 Jesse Keating : > On Tue, 22 Jan 2008 13:29:03 +0100 > "Valent Turkovic" wrote: > > > I tested revisor and wanted to make an up to date version of Fedora 8 > > Live CD - but selinux put a stop to that. > > Selinux is not going to work at all for things like revisor (and > pungi/livecd-creator). Both make use of chroots to install packages > into, and in certain cases you can wind up causing lots of harm to your > host system (installing a new policy in the chroot will actually cause > that policy to activate on the running kernel and then you have policy > that doesn't match labels, watch the fun!). > > It is strongly recommended that you disable SELinux or at least put it > in permissive if you're going to be doing composes. Is there a was to make selinux aware of that or atleast put a notification window saying that you need to disable selinux in order to use revisor? One more issue for removing selinux as I said in an earlier thread :) Selinux breaks features by desing and in a bad way, and I as a user see more trouble from selinux than it is worth (just MHO). Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From opensource at till.name Tue Jan 22 15:46:26 2008 From: opensource at till.name (Till Maas) Date: Tue, 22 Jan 2008 16:46:26 +0100 Subject: selinux breaks revisor In-Reply-To: <47960AED.8010405@city-fan.org> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <20080122095152.73f3fab5@redhat.com> <47960AED.8010405@city-fan.org> Message-ID: <200801221646.32144.opensource@till.name> On Tue January 22 2008, Paul Howarth wrote: > Would it not be possible for apps like these compose tools to use an > LD_PRELOAD libselinux hack like mock used to do in order to avoid these > pitfalls? Maybe it is possible to use revisor with fakeroot and fakechroot to make sure it does no harm to your system. Or maybe with e.g. lguest as a virtual machine. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From laurent.rineau__fedora at normalesup.org Tue Jan 22 15:56:14 2008 From: laurent.rineau__fedora at normalesup.org (Laurent Rineau) Date: Tue, 22 Jan 2008 16:56:14 +0100 Subject: selinux breaks revisor In-Reply-To: <200801220904.23465.ben.kreuter@gmail.com> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <64b14b300801220552u32a3cbd6wa085ae5017d5faf3@mail.gmail.com> <200801220904.23465.ben.kreuter@gmail.com> Message-ID: <200801221656.14282@rineau.tsetse> On Tuesday 22 January 2008 15:04:19 Benjamin Kreuter wrote: > On Tuesday 22 January 2008 08:52:57 Valent Turkovic wrote: > > http://www.uploadgeek.com/uploads456/0/Screenshot-setroubleshoot%20browse > >r- errors-galore.png > > Sorry, no luck with that image -- just a broken image icon and some text > from uploadgeek. I have the same problem as you if I use Konqueror as web browser. With Firefox I can see the image. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From buildsys at redhat.com Tue Jan 22 15:58:44 2008 From: buildsys at redhat.com (Build System) Date: Tue, 22 Jan 2008 10:58:44 -0500 Subject: rawhide report: 20080122 changes Message-ID: <200801221558.m0MFwi2e020429@porkchop.devel.redhat.com> New package coriander Control a 1394 digital camera interactively New package fantasdic Dictionary application using Ruby New package libmspack Library for CAB and related files compression and decompression New package llvm The Low Level Virtual Machine New package mypaint A simple paint program New package o3read Standalone converter for OpenOffice.org documents New package python-xmltramp Pythonic API for XML New package samyak-fonts Samyak Font for Indic Script Updated Packages: GConf2-2.21.2-1.fc9 ------------------- * Mon Jan 21 2008 Matthias Clasen - 2.21.2-1 - Update to 2.21.2 NetworkManager-1:0.7.0-0.8.svn3261.fc9 -------------------------------------- * Mon Jan 21 2008 Dan Williams - 1:0.7.0-0.8.svn3261 - Add CDMA mobile broadband support (if supported by HAL) - Rework applet connection and icon handling - Enable connection editor (only for deleting connections) * Fri Jan 11 2008 Dan Williams - 1:0.7.0-0.8.svn3235 - Fix crash when activating a mobile broadband connection - Better handling of non-SSID-broadcasting APs on kernels that support it (gnome.org #464215) (rh #373841) - Honor DHCP-server provided MTU if present (gnome.org #332953) - Use previous DNS settings if the VPN concentrator doesn't provide any (gnome.org #346833) * Fri Jan 04 2008 Dan Williams - 1:0.7.0-0.8.svn3204 - Fix WPA passphrase hashing on big endian (PPC, Sparc, etc) (rh #426233) anaconda-11.4.0.23-1 -------------------- * Mon Jan 21 2008 David Cantrell - 11.4.0.23-1 - Try to fix a problem creating users via kickstart (#428891, clumens) - Fix a loader segfault doing kickstart nfs installs (clumens) - Move more interactive steps ahead of partitioning (clumens) - If we can't possibly add advanced devices, don't offer it (#429210, clumens) - Don't flush after rescanning so recently attached disks are available (clumens) - If bootproto is dhcp, unset any static settings (#218489, dcantrell) - Add some groups to pkgorder to make the CDs come out right (pjones) - Fix traceback when using non-encrypted RAID (notting) - Complete the patch for dhcptimeout (#198147, #254032, msivak) b43-fwcutter-010-2.fc9 ---------------------- bluefish-1.0.7-3.fc9 -------------------- * Mon Jan 21 2008 Paul Howarth - 1.0.7-3 - include patch from upstream VCS to work around problem editing syntax highlighting patterns (#390871) bluez-gnome-0.15-3.fc9 ---------------------- * Mon Jan 21 2008 - Bastien Nocera - 0.15-3 - Add requires on obex-data-server for bluetooth-sendto * Mon Jan 21 2008 - Bastien Nocera - 0.15-2 - Add patch to update the sendto binary bsh-0:1.3.0-11jpp.1.fc9 ----------------------- * Mon Jan 21 2008 Permaine Cheung 0:1.3.0-11jpp.1 - Merge with upstream * Thu Jul 12 2007 Ralph Apel 0:1.3.0-11jpp - Fix aot build - Add pom and depmap frags - Restore all jars - Add webapps * Fri Mar 16 2007 Permaine Cheung 0:1.3.0-10jpp.1 - Merge with upstream - Removed unapplied patch and moved buildroot removal from prep to install, and other rpmlint cleanup claws-mail-3.2.0-3.fc9 ---------------------- * Mon Jan 21 2008 Andreas Bierfert - 3.2.0-3 - bump concurrent-0:1.3.4-7jpp.1.fc9 ----------------------------- * Thu Jan 10 2008 Permaine Cheung - 0:1.3.4-7jpp.1 - Merge with upstream version cups-1:1.3.5-2.fc9 ------------------ * Mon Jan 21 2008 Tim Waugh 1:1.3.5-2 - Main package requires libs sub-package of the same release. * Thu Jan 10 2008 Tim Waugh - Apply patch to fix busy looping in the backends (bug #426653, STR #2664). * Wed Jan 09 2008 Tim Waugh - Apply patch to prevent overlong PPD lines from causing failures except in strict mode (bug #405061). Needed for compatibility with older versions of foomatic (e.g. Red Hat Enterprise Linux 3/4). - Applied upstream patch to fix cupsctl --remote-any (bug #421411, STR #2650). dhcpv6-1.0.10-1.fc9 ------------------- * Mon Jan 21 2008 David Cantrell - 1.0.10-1 - Upgrade to dhcpv6-1.0.10 eclipse-changelog-1:2.6.0-1.fc8 ------------------------------- * Tue Dec 18 2007 Jeff Johnston 2.6.0-1 - 2.6.0 - Remove CVS dependency for plugin - Create team-neutral solution (e.g. SVN now supported) - Add removed file support for PrepareChangeLog action - Remove project selection dialog - Support CTRL+ALT+P from any view that has selected IResource - For SynchronizeView, support "remove from view" items being ignored - Fix match recognition for finding existing entries - For PrepareChangeLog, categorize New, Removed, and Changed entries and alphabetically sort them in the ChangeLog entry - Resolves Bugzilla #210144 elfutils-0.132-3.fc9 -------------------- * Mon Jan 21 2008 Roland McGrath - 0.132-3 - Update to 0.132 - libelf: Use loff_t instead of off64_t in libelf.h header. (#377241) - eu-readelf: Fix handling of ET_REL files in archives. - libcpu: Implement x86 and x86-64 disassembler. - libasm: Add interface for disassembler. - all programs: add debugging of branch prediction. - libelf: new function elf_scnshndx. frysk-0.0.1.2008.01.18.rh1-1.fc9 -------------------------------- * Sun Jan 20 2008 Andrew Cagney - 0.0.1.2008.01.18.rh1-1 - Import frysk-0.0.1.2008.01.18.rh1 (4cff0daa2996b28274985fa4674160f15e5fd9e2) - Delete run_make_check code. - Add patch4, frysk-0.0.1.2008.01.18.rh1-no-sysroot.patch to not build sysroot tests. - Add patch5, frysk-0.0.1.2008.01.18.rh1-line-npe.patch to prevent NPE in source window. - Enable ppc64 build; disable alpha build (bug 416961). - Move dogtail testing requirements to devel package. - Delete stray ChangeLog, gen-type-funit-tests, and test-exe-x86.c.source files. glib2-2.15.3-1.fc9 ------------------ * Mon Jan 21 2008 Matthias Clasen - 2.15.3-1 - Update to 2.15.3 gnome-applets-1:2.21.4-3.fc9 ---------------------------- * Mon Jan 21 2008 Matthias Clasen - 1:2.21.4-3 - Fix the invest applet on vertical panels gnome-bluetooth-0.11.0-1.fc9 ---------------------------- * Mon Jan 21 2008 - Bastien Nocera - 0.11.0 - Update to 0.11.0 * Mon Jan 21 2008 - Bastien Nocera - 0.10.0 - Update to 0.10.0 gnome-do-0.3.0.1-2.fc9 ---------------------- * Tue Jan 22 2008 David Nielsen - 0.3.0.1-1 - Fix BuildRequires * Tue Jan 22 2008 David Nielsen - 0.3.0.1-1 - bump to 0.3.0.1 - update patches * Sat Nov 17 2007 David Nielsen - 0.0.2-2 - updated libdir patch - cleaned up desktop-file-install invocation - correct BuildRequires gnome-keyring-2.21.5-2.fc9 -------------------------- * Mon Jan 21 2008 Matthew Barnes - 2.21.5-2 - Fix a race condition that was causing Evolution to hang (#429097) gnome-spell-1.0.8-3.fc9 ----------------------- * Mon Jan 21 2008 Matthew Barnes - 1.0.8-3.fc9 - Incorporate package review feedback from Parag AN (RH bug #225837). gnu-smalltalk-3.0-1.fc9 ----------------------- * Mon Jan 21 2008 Jochen Schmitt 3.0-1 - New upstream release gsoap-2.7.9-0.4.l ----------------- * Fri Nov 30 2007 - 2.7.9-0.4.l - Added OpenSSL requirement gtkspell-2.0.11-7.fc9 --------------------- * Mon Jan 21 2008 Matthew Barnes - 2.0.11-7.fc9 - Incorporate package review feedback from Parag AN (RH bug #225876). gvfs-0.1.4-2.fc9 ---------------- * Mon Jan 21 2008 Alexander Larsson - 0.1.4-2 - Remove the http/dav stuff for now, as we don't have the latest libsoup gwave-2-5.20070514snap.fc9 -------------------------- * Mon Jan 21 2008 Chitlesh Goorah - 2-5.20070514snap - rebuilt due to dependency breakage highlight-2.6.7-2.fc9 --------------------- * Mon Jan 21 2008 Jochen Schmitt 2.6.7-2 - New upstream release - Fix gcc-4.3 issues initscripts-8.62-1 ------------------ * Mon Jan 21 2008 Bill Nottingham - 8.62-1 - rc.d/rc.sysinit: fix syntax error (#429556) - migrate sr at Latn -> sr at latin () jack-audio-connection-kit-0.109.0-1.fc9 --------------------------------------- * Mon Jan 21 2008 Andy Shevchenko 0.109.0-1 - update to the last official release (#429162) - shut up the postinstall script (#359291) java-1.5.0-gcj-1.5.0.0-19.fc9 ----------------------------- * Mon Jan 21 2008 Thomas Fitzsimmons - 1.5.0.0-19 - Include python egg-info file. - Work around rhbz#404981 - Inline rebuild-security-providers. - Resolves: rhbz#260161 * Tue Nov 27 2007 Thomas Fitzsimmons - 1.5.0.0-18 - Import java-gcj-compat 1.0.77. kaffeine-0.8.6-1.fc9 -------------------- * Sun Jan 20 2008 Rex Dieter 0.8.6-1 - kaffeine-0.8.6 * Sun Jan 13 2008 Ville Skytt?? - 0.8.5-7 - Require kdelibs3-devel instead of kdelibs-devel in -devel. * Sat Dec 08 2007 Rex Dieter 0.8.5-6 - BR: kdelibs3-devel kdenetwork-7:4.0.0-2.fc9 ------------------------ * Mon Jan 21 2008 Rex Dieter 4.0.0-2 - BR: avahi-compat-libdns_sd-devel glib2-devel openslp-devel libxslt-devel xmms-devel kdepim-6:3.5.8-16.svn20080109.ent.fc9 ------------------------------------- * Mon Jan 21 2008 Kevin Kofler 6:3.5.8-16.20071204.ent - add patch from kitchensync-OpenSync0.30API branch to build KitchenSync again (F9+) * Wed Jan 09 2008 Rex Dieter 6:3.5.8-15.20080109.ent - 20080109 snapshot (sync with F-7/8 branches) * Tue Jan 08 2008 Rex Dieter 6:3.5.8-14.20071204.ent - omit kpalmdoc.png icons too (f9+) kernel-2.6.24-0.164.rc8.git4.fc9 -------------------------------- * Mon Jan 21 2008 Chuck Ebbert - Linux 2.6.24-rc8-git4 * Mon Jan 21 2008 Adam Jackson - Disable MODULE_DEVICE_TABLE patch for i915 and radeon, it makes things very unhappy. * Mon Jan 21 2008 Eric Sandeen - Update ext4 patch to latest stable patch queue libast-0.7.1-0.3.20060818cvs.fc9 -------------------------------- * Sun Jan 20 2008 Terje R??sten - 0.7.1-0.3.20060818cvs - Fix multiarch stuff - Some style cleanup libdrm-2.4.0-0.3.fc9 -------------------- * Mon Jan 21 2008 Adam Jackson 2.4.0-0.3 - libdrm-2.4.0-no-freaking-mknod.patch: Disable. Deep voodoo. libselinux-2.0.47-4.fc9 ----------------------- * Mon Jan 21 2008 Dan Walsh - 2.0.47-4 - Update to use libsepol-static library * Wed Jan 16 2008 Adel Gadllah - 2.0.47-3 - Move libselinux.a to -static package - Spec cleanups libsepol-2.0.18-2.fc9 --------------------- * Mon Jan 21 2008 Dan Walsh 2.0.18-2 - Fixed for spec review * Fri Jan 11 2008 Dan Walsh 2.0.18-1 - Upgrade to latest from NSA * Added support for policy capabilities from Todd Miller. * Prevent generation of policy.18 with MLS enabled from Todd Miller. logrotate-3.7.6-2.2.fc9 ----------------------- * Mon Jan 21 2008 Tomas Smetana 3.7.6-2.2 - fix #429454 - logrotate fails due to invalid pointer logwatch-7.3.6-17.fc9 --------------------- * Mon Jan 21 2008 Ivana Varekova 7.3.6-17 - Resolves: #427734 fix amavis script - Resolves: #429452 fix openvpn script nautilus-2.21.6-1.fc9 --------------------- * Mon Jan 21 2008 Matthias Clasen - 2.21.6-1 - Update to 2.21.6 * Mon Jan 14 2008 Matthias Clasen - 2.21.5-1 - Update to 2.21.5 * Tue Jan 08 2008 Matthias Clasen - 2.21.2-1 - Update to 2.21.2 nautilus-cd-burner-2.21.5-1.fc9 ------------------------------- * Mon Jan 21 2008 Jon McCann - 2.21.5-1 - Update to 2.21.5 nautilus-sendto-0.13.1-1.fc9 ---------------------------- * Mon Jan 21 2008 - Bastien Nocera - 0.13.1-1 - Remove 0.13.1 * Sun Jan 20 2008 - Bastien Nocera - 0.13-1 - Update to 0.13 ntfs-3g-2:1.2121-0.1.RC.fc9 --------------------------- pango-1.19.3-1.fc9 ------------------ * Mon Jan 21 2008 Behdad Esfahbod - 1.19.3-1 - Update to 1.19.3 pciutils-2.2.9-4.fc9 -------------------- * Mon Jan 21 2008 Harald Hoyer 2.2.9-4 - fixed segfault, if subdir does not exists perl-Algorithm-Dependency-1.106-1.fc9 ------------------------------------- * Mon Jan 21 2008 Ralf Cors??pius - 1.106-1 - Upstream update. perl-Class-Std-0.0.8-2.fc9 -------------------------- perl-DBIx-SearchBuilder-1.51-1.fc9 ---------------------------------- * Mon Jan 21 2008 Ralf Cors??pius - 1.51-1 - Upstream update. * Sun Nov 25 2007 Ralf Cors??pius - 1.50-1 - Upstream update. perl-PDF-API2-0.69-2.fc9 ------------------------ * Mon Jan 21 2008 Bernard Johnson - 0.69-2 - patch .orig files packaged (bz #427762) phasex-0.11.1-4.fc9 ------------------- * Mon Oct 22 2007 Anthony Green - 0.11.1-4 - Fix tagging problem. photoml-0.25-1.fc9 ------------------ * Tue Jan 15 2008 Brendt Wohlberg - 0.25-1 - New release version policycoreutils-2.0.35-3.fc9 ---------------------------- * Mon Jan 21 2008 Dan Walsh 2.0.35-3 - Allow files with spaces to be used by setfiles postgis-1.3.2-2.fc9.1 --------------------- * Mon Jan 21 2008 - Devrim GUNDUZ 1.3.2-2.1 - Rebuilt against PostgreSQL 8.3 postgresql-pgpool-3.4.1-1.fc9.1 ------------------------------- * Mon Jan 21 2008 - Devrim GUNDUZ 3.4.1-1.1 - Rebuilt against PostgreSQL 8.3 * Tue Oct 16 2007 - Devrim GUNDUZ 3.4.1-1 - Update to 3.4.1 * Sun Aug 05 2007 - Devrim GUNDUZ 3.4-2 - Added an init script for pgpool - Added /etc/sysconfig/pgpool postgresql-pgpool-II-2.0.1-2.fc9.1 ---------------------------------- * Mon Jan 21 2008 Devrim GUNDUZ 2.0.1-2.1 - Rebuilt against PostgreSQL 8.3 postgresql-table_log-0.4.4-3.fc9.1 ---------------------------------- * Mon Jan 21 2008 - Devrim GUNDUZ 0.4.4-3.1 - Rebuilt against PostgreSQL 8.3 pygtksourceview-2.1.0-1.fc9 --------------------------- * Mon Jan 21 2008 Matthew Barnes - 2.1.0-1.fc9 - Update to 2.1.0 python-numeric-24.2-8.fc9 ------------------------- * Mon Jan 21 2008 Matthew Barnes - 24.2-8 - Use a full URL for Source tag (RH bug #226345). python-psycopg2-2.0.6-3.fc9.1 ----------------------------- * Mon Jan 21 2008 - Devrim GUNDUZ 2.0.6-3.1 - Rebuilt against PostgreSQL 8.3 scim-1.4.7-8.fc9 ---------------- * Mon Jan 21 2008 Jens Petersen - 1.4.7-8 - change the default Simplied Chinese IME to scim-python Pinyin - do not set the trigger hotkey for all locale by default - remove unused ChangeFactoryGlobally key from system config * Fri Oct 19 2007 Jens Petersen - 1.4.7-7.fc8 - quote backquotes in xinput config file (#339271) * Fri Oct 12 2007 Jens Petersen - 1.4.7-6 - make scim-lang-*.x86_64 require scim-bridge-gtk multilib (#327151) selinux-policy-3.2.5-15.fc9 --------------------------- * Mon Jan 21 2008 Dan Walsh 3.2.5-15 - Allow login programs to talk dbus to oddjob * Thu Jan 17 2008 Dan Walsh 3.2.5-14 - Add procmail_log support - Lots of fixes for munin * Tue Jan 15 2008 Dan Walsh 3.2.5-13 - Allow setroubleshoot to read policy config and send audit messages subcommander-1.2.2-10.fc9 ------------------------- * Mon Jan 21 2008 Jochen Schmitt 1.2.2-10 - Fix gcc-4.3 issues synce-sync-engine-0.11-6.fc9 ---------------------------- * Mon Jan 21 2008 Andreas Bierfert - 0.11-6 - obsolete syncekonnector for clean upgrade path system-config-rootpassword-1.99.3-2.fc9 --------------------------------------- * Mon Jan 21 2008 Lubomir Kundrak - 1.99.3-2 - Add dependency on cracklib (#428880) tar-2:1.19-2.fc9 ---------------- * Mon Jan 21 2008 Radek Brich 2:1.19-2 - fix errors in man page * fix definition of --occurrence (bz#416661, patch by Jonathan Wakely) * update meaning of -l: it has changed from --one-filesystem to --check-links (bz#426717) - update license tag, tar 1.19 is GPLv3+ tog-pegasus-2:2.7.0-5.fc9 ------------------------- * Mon Jan 21 2008 Vitezslav Crhonek - 2:2.7.0-5 - No snmp tests in Test RPM * Thu Jan 10 2008 Vitezslav Crhonek - 2:2.7.0-4 - Fix Test RPM totem-pl-parser-2.21.91-1.fc9 ----------------------------- tracker-0.6.4-4.fc9 ------------------- * Mon Jan 21 2008 Deji Akingunola - 0.6.4-4 - Now require the externally packaged o3read to provide o3totxt ulogd-1.24-8.fc9 ---------------- * Wed Jan 09 2008 Leopold Aichinger 1.24-8 - Support for libpcap added unpaper-0.3-1.fc9 ----------------- vdr-skinsoppalusikka-1.0.6-1.fc9 -------------------------------- * Mon Jan 21 2008 Ville-Pekka Vainio - 1.0.6-1 - Upstream released a new version - Change Source0 to be a complete URL of the source vdr-wapd-0.9-1.fc9 ------------------ * Tue Jan 22 2008 Ville Skytt?? - 0.9-1 - 0.9, license changed to GPLv2+. - Patch to improve translations. - Patch to fix port conversion in accepted/denied syslog messages. - Patch to fix missing HTTP headers on access denied responses. winpdb-1.3.4-1.fc9.1 -------------------- * Mon Jan 21 2008 Tom "spot" Callaway - 1.3.4-1.1 - bump to 1.3.4 - actually finish writing the changelog xen-3.2.0-2.fc9 --------------- * Mon Jan 21 2008 Daniel P. Berrange - 3.2.0-2.fc9 - Added XSM header files to -devel RPM * Fri Jan 18 2008 Daniel P. Berrange - 3.2.0-1.fc9 - Updated to 3.2.0 final release * Thu Jan 10 2008 Daniel P. Berrange - 3.2.0-0.fc9.rc5.dev16701.1 - Rebase to Xen 3.2 rc5 changeset 16701 xfsprogs-2.9.5-1.fc9 -------------------- * Mon Jan 21 2008 Eric Sandeen 2.9.5-1 - Update to xfsprogs 2.9.5 - Contains more optimal mkfs defaults - specfile cleanup, & don't restate config defaults xmlunit-0:1.0-5jpp.1.fc9 ------------------------ * Thu Jan 17 2008 Permaine Cheung - 0:1.0-5jpp.1 - Update to the same version as upstream Tue Dec 18 2007 Ralph Apel - 0:1.0-5jpp - Add poms and depmap frags - Make Vendor, Distribution based on macro - Add gcj_support option xorg-x11-drv-cirrus-1.1.0-7.fc9 ------------------------------- * Mon Jan 21 2008 Dave Airlie - 1.1.0-7 - make cirrus work with pciaccess in qemu xulrunner-1.9-0.beta2.12.nightly20080121.fc9 -------------------------------------------- * Mon Jan 21 2008 Christopher Aillon 1.9-0.beta2.12 - Update to latest trunk (2008-01-21) Broken deps for i386 ---------------------------------------------------------- bluez-gnome - 0.15-3.fc9.i386 requires obex-data-server epiphany-extensions - 2.20.1-3.fc9.i386 requires libgtkembedmoz.so epiphany-extensions - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.i386 requires libgtkembedmoz.so gnome-web-photo - 0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 icewm - 1.2.35-2.fc9.i386 requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 qt-recordmydesktop - 0.3.6-4.fc9.noarch requires recordmydesktop = 0:0.3.6 Broken deps for x86_64 ---------------------------------------------------------- bluez-gnome - 0.15-3.fc9.x86_64 requires obex-data-server epiphany-extensions - 2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) icewm - 1.2.35-2.fc9.x86_64 requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 qt-recordmydesktop - 0.3.6-4.fc9.noarch requires recordmydesktop = 0:0.3.6 Broken deps for ppc ---------------------------------------------------------- bluez-gnome - 0.15-3.fc9.ppc requires obex-data-server epiphany-extensions - 2.20.1-3.fc9.ppc requires libgtkembedmoz.so epiphany-extensions - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.ppc requires libgtkembedmoz.so gnome-web-photo - 0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 icewm - 1.2.35-2.fc9.ppc requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 monodevelop - 0.17-4.fc9.ppc requires boo qt-recordmydesktop - 0.3.6-4.fc9.noarch requires recordmydesktop = 0:0.3.6 Broken deps for ppc64 ---------------------------------------------------------- bluez-gnome - 0.15-3.fc9.ppc64 requires obex-data-server epiphany-extensions - 2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) icewm - 1.2.35-2.fc9.ppc64 requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 perl-Test-AutoBuild-darcs - 1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 qt-recordmydesktop - 0.3.6-4.fc9.noarch requires recordmydesktop = 0:0.3.6 From atkac at redhat.com Tue Jan 22 16:04:11 2008 From: atkac at redhat.com (Adam Tkac) Date: Tue, 22 Jan 2008 17:04:11 +0100 Subject: BIND less restrictive modes and policy In-Reply-To: <20080122142633.GK26108@angus.ind.WPI.EDU> References: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> <20080121131902.GA12493@dudweiler.stuttgart.redhat.com> <20080121153636.GA2893@evileye.atkac.englab.brq.redhat.com> <20080121154853.GC1491367@hiwaay.net> <20080121155721.GA30491@evileye.atkac.englab.brq.redhat.com> <20080122142633.GK26108@angus.ind.WPI.EDU> Message-ID: <20080122160410.GA2673@evileye.atkac.englab.brq.redhat.com> On Tue, Jan 22, 2008 at 09:26:33AM -0500, Chuck Anderson wrote: > On Mon, Jan 21, 2008 at 04:57:21PM +0100, Adam Tkac wrote: > > On Mon, Jan 21, 2008 at 09:48:53AM -0600, Chris Adams wrote: > > > Once upon a time, Adam Tkac said: > > > > - /var/named will be writable and read-only permissions will be set > > > > per-zone by admin > > > > > > If the directory is writable, read-only file permissions are > > > meaningless. > > > > > > > Maybe but what other solution will be better? I could create separate > > read-only directory inside /var/named (called "masters" for example) > > and put all read-only zones there but I'm not sure if admins will like > > it and use it. > > If directory layout changes are necessary, I'd rather that very > minimal changes be made, but this seems like a good change to make to > allow having master zone files that aren't writeable by the named > user. > > So I propose to keep the existing directory split and add the masters/ > subdirectory if and only if it ends up being necessary to change > permissions on /var/named/ to be writeable by the named process. > > I think we should investigate whether using 'directory > "/var/named/data";' like I mentioned in my other email works first. > How would people feel about needing full or ../ relative paths in zone > "file" statements? This doesn't sound well for me. This will be very annoying. > > I'll test this setup now to see if it helps with coredumps, but I > don't think this is the root cause of the coredump failure. I tried > running BIND in various ways to allow coredumps to work, and even when > running it as root with SELinux set to permissive it failed to dump > core. I think there are problems with the logic of the code that sets > the Linux Capability bits. I don't think so. As I wrote in https://bugzilla.redhat.com/show_bug.cgi?id=400461#c21 named is able to produce core file after setuid when /var/named directory is writable by named user. This is main reason why I want this directory writable. It means that you will have always core file when named gets sigsegv (no additional setup is needed, only writable /var/named). This change means lower security on the one hand but on the other hand we will always get core file. Adam -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Tue Jan 22 16:08:17 2008 From: atkac at redhat.com (Adam Tkac) Date: Tue, 22 Jan 2008 17:08:17 +0100 Subject: BIND less restrictive modes and policy In-Reply-To: <20080122141902.GJ26108@angus.ind.WPI.EDU> References: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> <20080121131902.GA12493@dudweiler.stuttgart.redhat.com> <20080121153636.GA2893@evileye.atkac.englab.brq.redhat.com> <20080122141902.GJ26108@angus.ind.WPI.EDU> Message-ID: <20080122160817.GB2673@evileye.atkac.englab.brq.redhat.com> On Tue, Jan 22, 2008 at 09:19:02AM -0500, Chuck Anderson wrote: > I think we just need to have the directory specified by "directory" in > /etc/named.conf be writeable. That is the CWD of the named process, > and is where any coredumps would be written. So perhaps instead of > doing this overhaul of directory layout and permissions, we can just > change the default directory to "/var/named/data" instead: > > options { > directory "/var/named/data"; > > This will affect zone file configurations--they will need to use > either the full path to the zone file, or perhaps a relative path like > "../slaves/foo.zone" which I've not tested to see if it works, e.g.: > > zone "localhost" { > type master; > file "../localhost"; > }; > It works as expected, relative paths are allowed. Adam -- Adam Tkac, Red Hat, Inc. From opensource at till.name Tue Jan 22 16:10:33 2008 From: opensource at till.name (Till Maas) Date: Tue, 22 Jan 2008 17:10:33 +0100 Subject: BIND less restrictive modes and policy In-Reply-To: <47955B90.2000405@gmail.com> References: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> <47955262.3040805@nobugconsulting.ro> <47955B90.2000405@gmail.com> Message-ID: <200801221710.38553.opensource@till.name> On Tue January 22 2008, Andrew Farris wrote: > Manuel Wolfshant wrote: > > On 01/22/2008 03:17 AM, Andrew Farris wrote: > >> Enrico Scholz wrote: > >>> Adam Tkac writes: > I'm assuming now that: > >>> This is bad. Only the slaves/ and data/ (for DDNS) dirs must be > >>> writable. > > is necessary to function > > >>> pz/ and the other parts of the chroot filesystem must be read-only for > >>> named. > > is not necessary, only 'a good idea', a change to which you are against Making / read-only for bind is also not necessary for bind to work and also a good idea. The problem is, that it is a very rare case that something needs to be restricted to make something work. Therefore the best approach is to disallow/restrict everthing by default and only allow what is necessary to make it work, but not more. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From lordmorgul at gmail.com Tue Jan 22 16:22:03 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Tue, 22 Jan 2008 08:22:03 -0800 Subject: BIND less restrictive modes and policy In-Reply-To: <200801221710.38553.opensource@till.name> References: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> <47955262.3040805@nobugconsulting.ro> <47955B90.2000405@gmail.com> <200801221710.38553.opensource@till.name> Message-ID: <4796182B.10800@gmail.com> Till Maas wrote: > On Tue January 22 2008, Andrew Farris wrote: >> Manuel Wolfshant wrote: >>> On 01/22/2008 03:17 AM, Andrew Farris wrote: >>>> Enrico Scholz wrote: >>>>> Adam Tkac writes: > >> I'm assuming now that: >> >>> This is bad. Only the slaves/ and data/ (for DDNS) dirs must be >> >>> writable. >> >> is necessary to function >> >> >>> pz/ and the other parts of the chroot filesystem must be read-only for >> >>> named. >> >> is not necessary, only 'a good idea', a change to which you are against > > Making / read-only for bind is also not necessary for bind to work and also a > good idea. The problem is, that it is a very rare case that something needs > to be restricted to make something work. Which is precisely why I asked for clarification when it sounds like he was claiming it needed to be restricted (not likely to be needed). > Therefore the best approach is to > disallow/restrict everthing by default and only allow what is necessary to > make it work, but not more. > No arguments here. > Regards, > Till > -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From atkac at redhat.com Tue Jan 22 16:26:37 2008 From: atkac at redhat.com (Adam Tkac) Date: Tue, 22 Jan 2008 17:26:37 +0100 Subject: BIND less restrictive modes and policy In-Reply-To: <87r6gab6zh.fsf@kosh.bigo.ensc.de> References: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> <87ve5mbtlg.fsf@kosh.bigo.ensc.de> <47954414.5060406@gmail.com> <87r6gab6zh.fsf@kosh.bigo.ensc.de> Message-ID: <20080122162637.GC2673@evileye.atkac.englab.brq.redhat.com> On Tue, Jan 22, 2008 at 09:27:14AM +0100, Enrico Scholz wrote: > Andrew Farris writes: > > >> pz/ and the other parts of the chroot filesystem must be read-only > >> for named. > > > > And why exactly is that? > > To give only the required rights is a common and working practice for > years to secure daemons. Fedora should not forget classical ways > (own uid, chroot environments, restrictive permissions) just to give > something like "easier configuration" (where I can not see how mixing > all and everything into a single dir can ease configuration). > Main reason why I want /var/named writable is because named is designed that this directory is supossed to be writable, not easier configuration. It really make problems sometimes when it is not writable. And add some option to initscript which will make that directory writable is suspicious for me. Adam -- Adam Tkac, Red Hat, Inc. From cra at WPI.EDU Tue Jan 22 16:30:05 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 22 Jan 2008 11:30:05 -0500 Subject: BIND less restrictive modes and policy In-Reply-To: <20080122160410.GA2673@evileye.atkac.englab.brq.redhat.com> References: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> <20080121131902.GA12493@dudweiler.stuttgart.redhat.com> <20080121153636.GA2893@evileye.atkac.englab.brq.redhat.com> <20080121154853.GC1491367@hiwaay.net> <20080121155721.GA30491@evileye.atkac.englab.brq.redhat.com> <20080122142633.GK26108@angus.ind.WPI.EDU> <20080122160410.GA2673@evileye.atkac.englab.brq.redhat.com> Message-ID: <20080122163005.GP26108@angus.ind.WPI.EDU> On Tue, Jan 22, 2008 at 05:04:11PM +0100, Adam Tkac wrote: > > I think we should investigate whether using 'directory > > "/var/named/data";' like I mentioned in my other email works first. > > How would people feel about needing full or ../ relative paths in zone > > "file" statements? > > This doesn't sound well for me. This will be very annoying. IMO, "annoying" is trumped by "more secure". SELinux is annoying too, but we still use it. I have verified that relative paths work, as well as symlinks from the data/ dir (not that I recommend doing it this way): #ls -l /var/named/data total 4 lrwxrwxrwx 1 root root 9 2008-01-22 09:30 slaves -> ../slaves/ I think we need a new feature in BIND...one where the CWD can stay at /var/named/data regardless of the "directory" option so that zone file paths don't have to be changed--perhaps a new option. > I don't think so. As I wrote in > https://bugzilla.redhat.com/show_bug.cgi?id=400461#c21 named is able > to produce core file after setuid when /var/named directory is > writable by named user. This is main reason why I want this directory > writable. It means that you will have always core file when named > gets sigsegv (no additional setup is needed, only writable > /var/named). This change means lower security on the one hand but on > the other hand we will always get core file. Ok, I'll try this. But I don't think we should change the default setup just to be able to generate coredumps at the expense of security, especially if we are still going to require SELinux to be put into permissive mode to make it actually work. We should just document the changes one needs to make to generate coredumps since we already require some changes anyway, i.e.: /etc/sysconfig/named: DAEMON_COREFILE_LIMIT=unlimited sysctl -w fs.suid_dumpable=1 chmod 755 /usr/sbin/named chmod 775 /var/named setenforce 0 service named restart (which of these aren't required?) If we are going to make changes to allow coredumps by default, then SELinux policy should be adjusted to allow this as well because running your system in permissive mode for long periods of time makes it a royal pain to switch back--I had to boot into single user mode with selinux=0 and run "fixfiles restore" manually since rc.sysinit couldn't do it automatically (see https://www.redhat.com/archives/fedora-selinux-list/2008-January/msg00079.html for the problems I had). I just don't think it is a good idea to implement this by making /var/named writeable, undoing the extra layer of security we have for master zone files now. We should find some other way to mitigate this. It's not like coredumps are frequent, and daemons aren't allowed to coredump with our default config anyway... From ben.kreuter at gmail.com Tue Jan 22 16:32:16 2008 From: ben.kreuter at gmail.com (Benjamin Kreuter) Date: Tue, 22 Jan 2008 11:32:16 -0500 Subject: Package request: MICO or OmniORB Message-ID: <200801221132.23026.ben.kreuter@gmail.com> Hi everyone -- I noticed that there aren't any C++ ORBs packages with Fedora. Although there is a C++ binding for ORBit2, it is not package, and worse than that, it is broken (the code it generates is not valid C++ and does not compile). MICO and OmniORB are both working and licensed under LGPL. Perhaps we should include one of them? MICO is stable and well known, and several books have been written about it, so it would seem to be a good first choice. However, OmniORB has both C++ and Python bindings, and so it might be more useful for Fedora (although ORBit also has Python bindings, so that point may be moot). -- Benjamin Kreuter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From atkac at redhat.com Tue Jan 22 16:50:53 2008 From: atkac at redhat.com (Adam Tkac) Date: Tue, 22 Jan 2008 17:50:53 +0100 Subject: BIND less restrictive modes and policy In-Reply-To: <20080122163005.GP26108@angus.ind.WPI.EDU> References: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> <20080121131902.GA12493@dudweiler.stuttgart.redhat.com> <20080121153636.GA2893@evileye.atkac.englab.brq.redhat.com> <20080121154853.GC1491367@hiwaay.net> <20080121155721.GA30491@evileye.atkac.englab.brq.redhat.com> <20080122142633.GK26108@angus.ind.WPI.EDU> <20080122160410.GA2673@evileye.atkac.englab.brq.redhat.com> <20080122163005.GP26108@angus.ind.WPI.EDU> Message-ID: <20080122165053.GA3435@evileye.atkac.englab.brq.redhat.com> On Tue, Jan 22, 2008 at 11:30:05AM -0500, Chuck Anderson wrote: > On Tue, Jan 22, 2008 at 05:04:11PM +0100, Adam Tkac wrote: > > > I think we should investigate whether using 'directory > > > "/var/named/data";' like I mentioned in my other email works first. > > > How would people feel about needing full or ../ relative paths in zone > > > "file" statements? > > > > This doesn't sound well for me. This will be very annoying. > > IMO, "annoying" is trumped by "more secure". SELinux is annoying too, > but we still use it. > > I have verified that relative paths work, as well as symlinks from the > data/ dir (not that I recommend doing it this way): > > #ls -l /var/named/data > total 4 > lrwxrwxrwx 1 root root 9 2008-01-22 09:30 slaves -> ../slaves/ > > I think we need a new feature in BIND...one where the CWD can stay at > /var/named/data regardless of the "directory" option so that zone file > paths don't have to be changed--perhaps a new option. It is very hard to pass any new option or feature to main source. Upstream is very very conservative. (as expected from server developers...) > > I don't think so. As I wrote in > > https://bugzilla.redhat.com/show_bug.cgi?id=400461#c21 named is able > > to produce core file after setuid when /var/named directory is > > writable by named user. This is main reason why I want this directory > > writable. It means that you will have always core file when named > > gets sigsegv (no additional setup is needed, only writable > > /var/named). This change means lower security on the one hand but on > > the other hand we will always get core file. > > Ok, I'll try this. But I don't think we should change the default > setup just to be able to generate coredumps at the expense of > security, especially if we are still going to require SELinux to be > put into permissive mode to make it actually work. We should just > document the changes one needs to make to generate coredumps since we > already require some changes anyway, i.e.: > > /etc/sysconfig/named: > DAEMON_COREFILE_LIMIT=unlimited > > sysctl -w fs.suid_dumpable=1 > chmod 755 /usr/sbin/named ^^^ not needed ^^^ > chmod 775 /var/named > setenforce 0 > service named restart ^^^ should be sufficient ^^^ > > If we are going to make changes to allow coredumps by default, then > SELinux policy should be adjusted to allow this as well because > running your system in permissive mode for long periods of time makes > it a royal pain to switch back--I had to boot into single user mode > with selinux=0 and run "fixfiles restore" manually since rc.sysinit > couldn't do it automatically (see > https://www.redhat.com/archives/fedora-selinux-list/2008-January/msg00079.html > for the problems I had). > > I just don't think it is a good idea to implement this by making > /var/named writeable, undoing the extra layer of security we have for > master zone files now. We should find some other way to mitigate > this. It's not like coredumps are frequent, and daemons aren't > allowed to coredump with our default config anyway... Ok, so it seems that potential option to initscript which will temporary modify /var/named perms and SELinux (for example we will have some boolean for this) for gain such ability looks like the best (despite I don't like it much :) ) Adam -- Adam Tkac, Red Hat, Inc. From jspaleta at gmail.com Tue Jan 22 16:54:32 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 22 Jan 2008 07:54:32 -0900 Subject: selinux breaks revisor In-Reply-To: <64b14b300801220518u6fc2598ew40d333aec99b12ce@mail.gmail.com> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <4795E9FE.60501@redhat.com> <64b14b300801220518u6fc2598ew40d333aec99b12ce@mail.gmail.com> Message-ID: <604aa7910801220854u5e54f89dt7f5b5ab09f1a83f4@mail.gmail.com> On Jan 22, 2008 4:18 AM, Valent Turkovic wrote: > This looks like a pattern in fedora, looks like nobody actually does > testing of these new features. If anybody tried to make a spin just to > test if revisor works these errors should have sufaced... no? Just to be clear, revisor is not used internally by the fedora project to create spins. So It's not clear to me that there is an expectation that this should have priority over other things when it comes to testing. -jef From cjdahlin at ncsu.edu Tue Jan 22 16:49:50 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Tue, 22 Jan 2008 11:49:50 -0500 Subject: selinux breaks revisor In-Reply-To: <64b14b300801220742n10de35cbs587f419f5b000347@mail.gmail.com> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <20080122095152.73f3fab5@redhat.com> <64b14b300801220742n10de35cbs587f419f5b000347@mail.gmail.com> Message-ID: <47961EAE.60207@ncsu.edu> Valent Turkovic wrote: > 2008/1/22 Jesse Keating : > >> On Tue, 22 Jan 2008 13:29:03 +0100 >> "Valent Turkovic" wrote: >> >> >>> I tested revisor and wanted to make an up to date version of Fedora 8 >>> Live CD - but selinux put a stop to that. >>> >> Selinux is not going to work at all for things like revisor (and >> pungi/livecd-creator). Both make use of chroots to install packages >> into, and in certain cases you can wind up causing lots of harm to your >> host system (installing a new policy in the chroot will actually cause >> that policy to activate on the running kernel and then you have policy >> that doesn't match labels, watch the fun!). >> >> It is strongly recommended that you disable SELinux or at least put it >> in permissive if you're going to be doing composes. >> > > Is there a was to make selinux aware of that or atleast put a > notification window saying that you need to disable selinux in order > to use revisor? > One more issue for removing selinux as I said in an earlier thread :) > Selinux breaks features by desing and in a bad way, and I as a user > see more trouble from selinux than it is worth (just MHO). > > Valent. > > > This all started when open source coders heard proprietary vendors insisting bugs were features, and they got so sick of it that in retaliation they wrote a program to insist that features were bugs :) selinux is a good thing, but the problem is most of the time users aren't aware of it when its working properly. Few users are ever going to see selinux stop a real vulnerability. That's just the nature of the vulnerabilities themselves. They're rare. --CJD From cjdahlin at ncsu.edu Tue Jan 22 16:52:00 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Tue, 22 Jan 2008 11:52:00 -0500 Subject: selinux breaks revisor In-Reply-To: <604aa7910801220854u5e54f89dt7f5b5ab09f1a83f4@mail.gmail.com> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <4795E9FE.60501@redhat.com> <64b14b300801220518u6fc2598ew40d333aec99b12ce@mail.gmail.com> <604aa7910801220854u5e54f89dt7f5b5ab09f1a83f4@mail.gmail.com> Message-ID: <47961F30.4040003@ncsu.edu> Jeff Spaleta wrote: > On Jan 22, 2008 4:18 AM, Valent Turkovic wrote: > >> This looks like a pattern in fedora, looks like nobody actually does >> testing of these new features. If anybody tried to make a spin just to >> test if revisor works these errors should have sufaced... no? >> > > Just to be clear, revisor is not used internally by the fedora project > to create spins. > So It's not clear to me that there is an expectation that this should > have priority over other things when it comes to testing. > > -jef > > We're advertising it in a very public way. More people are expecting it to work. --CJD From jkeating at redhat.com Tue Jan 22 17:10:12 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 22 Jan 2008 12:10:12 -0500 Subject: selinux breaks revisor In-Reply-To: <47961F30.4040003@ncsu.edu> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <4795E9FE.60501@redhat.com> <64b14b300801220518u6fc2598ew40d333aec99b12ce@mail.gmail.com> <604aa7910801220854u5e54f89dt7f5b5ab09f1a83f4@mail.gmail.com> <47961F30.4040003@ncsu.edu> Message-ID: <20080122121012.39ac2e59@redhat.com> On Tue, 22 Jan 2008 11:52:00 -0500 Casey Dahlin wrote: > We're advertising it in a very public way. More people are expecting > it to work. "We" cannot help what some other parts of the project choose to tout (: -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Tue Jan 22 17:16:59 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 22 Jan 2008 08:16:59 -0900 Subject: selinux breaks revisor In-Reply-To: <47961F30.4040003@ncsu.edu> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <4795E9FE.60501@redhat.com> <64b14b300801220518u6fc2598ew40d333aec99b12ce@mail.gmail.com> <604aa7910801220854u5e54f89dt7f5b5ab09f1a83f4@mail.gmail.com> <47961F30.4040003@ncsu.edu> Message-ID: <604aa7910801220916l4b0ce21ak9129f5dc56ad81b2@mail.gmail.com> On Jan 22, 2008 7:52 AM, Casey Dahlin wrote: > We're advertising it in a very public way. More people are expecting it > to work. But we aren't using it internally, we aren't dogfooding it with our spins, and I want to make sure Valent and anyone reading the thread understands that. My reading of Valent's comment informed me that he was assuming we were seeing these problems as part of spin release and implied an assumption that we were using revisor. We aren't. Now that being said, I think any spin generation toolchain which we are offering, should be packaged in a way that informs people that selinux needs to be disabled to use correctly. And since I don't think spin creation falls into a desktop usage case of any rational merit, but falls instead into development usage, then I don't think such a tool should automatically disable selinux even temporarily. Selinux when interacting with any chroot-like apparatus is still a problem. Perhaps its time to take stock of all the packages that rely on chroot-like behavior which are similarly affected by selinux, so that a common technical solution can be found and applied. -jef -jef From jdennis at redhat.com Tue Jan 22 17:24:50 2008 From: jdennis at redhat.com (John Dennis) Date: Tue, 22 Jan 2008 12:24:50 -0500 Subject: selinux breaks revisor In-Reply-To: <64b14b300801220742n10de35cbs587f419f5b000347@mail.gmail.com> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <20080122095152.73f3fab5@redhat.com> <64b14b300801220742n10de35cbs587f419f5b000347@mail.gmail.com> Message-ID: <479626E2.1080607@redhat.com> Valent Turkovic wrote: > 2008/1/22 Jesse Keating : >> On Tue, 22 Jan 2008 13:29:03 +0100 >> "Valent Turkovic" wrote: >> >>> I tested revisor and wanted to make an up to date version of Fedora 8 >>> Live CD - but selinux put a stop to that. >> Selinux is not going to work at all for things like revisor (and >> pungi/livecd-creator). Both make use of chroots to install packages >> into, and in certain cases you can wind up causing lots of harm to your >> host system (installing a new policy in the chroot will actually cause >> that policy to activate on the running kernel and then you have policy >> that doesn't match labels, watch the fun!). >> >> It is strongly recommended that you disable SELinux or at least put it >> in permissive if you're going to be doing composes. > > Is there a was to make selinux aware of that or atleast put a > notification window saying that you need to disable selinux in order > to use revisor? Revisor could be aware of SELinux and provide a warning, SELinux cannot do this. > One more issue for removing selinux as I said in an earlier thread :) > Selinux breaks features by desing and in a bad way, and I as a user > see more trouble from selinux than it is worth (just MHO). Your dissatisfaction with SELinux has been duly noted by the list, you are free to disable it. However, we would prefer contributions to make the distribution more robust and smooth out the bumps rather than disabling the technology. Your choice. -- John Dennis From galibert at pobox.com Tue Jan 22 17:32:26 2008 From: galibert at pobox.com (Olivier Galibert) Date: Tue, 22 Jan 2008 18:32:26 +0100 Subject: Why is the time removed from the package intallation window Message-ID: <20080122173226.GB46223@dspnet.fr.eu.org> I noticed now that I'm starting to actually install systems with f8 that the time used/remaining indication has been removed from the text installation screen. I'm curious, why is that? OG. From jwilson at redhat.com Tue Jan 22 17:46:10 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 22 Jan 2008 12:46:10 -0500 Subject: Belated FUDCon Boston 2007 video postings Message-ID: <47962BE2.2060905@redhat.com> a few things, but the videos were captured using dvgrab on a powerpc system, wh= ich resulted in byte-swapped audio, which sounds rather HORRIFIC to the ears.= Someone was kind enough to figure out how to fix it, but it took me forev= er to get around to actually fixing and compressing the videos, but they're now= available on torrent.fedoraproject.org. Of course, I was dumb enough to compress them with a codec that I don't believe is available in Fedora proper, and the A/V sync is terrible, but = its marginally better than nothing, I guess... dwalsh-selinux Red Hat's Dan Walsh discusses how to debug problems with selinux and write your own selinux rules. fedora-board Max Spevack's State of the Fedora presentation. hackfest-details Quick overviews of the weekend's various hackfests. katzj-virtualization Red Hat's Jeremy Katz shows off the kernel-based virtual machine (aka kvm= ). --=20 Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From notting at redhat.com Tue Jan 22 17:54:15 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 22 Jan 2008 12:54:15 -0500 Subject: Why is the time removed from the package intallation window In-Reply-To: <20080122173226.GB46223@dspnet.fr.eu.org> References: <20080122173226.GB46223@dspnet.fr.eu.org> Message-ID: <20080122175415.GA18331@nostromo.devel.redhat.com> Olivier Galibert (galibert at pobox.com) said: > I noticed now that I'm starting to actually install systems with f8 > that the time used/remaining indication has been removed from the text > installation screen. I'm curious, why is that? It's non-trivial to render accurately (it wasn't particularly accurate before...) Bill From jwilson at redhat.com Tue Jan 22 17:58:45 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 22 Jan 2008 12:58:45 -0500 Subject: Belated FUDCon Boston 2007 video postings In-Reply-To: <47962BE2.2060905@redhat.com> References: <47962BE2.2060905@redhat.com> Message-ID: <47962ED5.2060508@redhat.com> Holy crap, enigmail mangled the sense right out of this email. Jarod Wilson wrote: > a few > things, but the videos were captured using dvgrab on a powerpc system, wh= > ich > resulted in byte-swapped audio, which sounds rather HORRIFIC to the ears.= [snip] Should have started out: So I had a dv camera at FUDCon Boston 2007 (last February), and recorded a few things, but the videos were captured using dvgrab on a powerpc system, which resulted in byte-swapped audio, which sounds rather HORRIFIC to the ears. Someone was kind enough to figure out how to fix it, but it took me forever to get around to actually fixing and compressing the videos, but they're now available on torrent.fedoraproject.org. Of course, I was dumb enough to compress them with a codec that I don't believe is available in Fedora proper, and the A/V sync is terrible, but its marginally better than nothing, I guess... -- Jarod Wilson jwilson at redhat.com From loupgaroublond at gmail.com Tue Jan 22 18:01:01 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Tue, 22 Jan 2008 13:01:01 -0500 Subject: selinux breaks revisor In-Reply-To: <604aa7910801220916l4b0ce21ak9129f5dc56ad81b2@mail.gmail.com> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <4795E9FE.60501@redhat.com> <64b14b300801220518u6fc2598ew40d333aec99b12ce@mail.gmail.com> <604aa7910801220854u5e54f89dt7f5b5ab09f1a83f4@mail.gmail.com> <47961F30.4040003@ncsu.edu> <604aa7910801220916l4b0ce21ak9129f5dc56ad81b2@mail.gmail.com> Message-ID: <7f692fec0801221001h1f4b3a27h83adb8351f7d2bc0@mail.gmail.com> On Jan 22, 2008 12:16 PM, Jeff Spaleta wrote: > Selinux when interacting with any chroot-like apparatus is still a > problem. Perhaps its time to take stock of all the packages that rely > on chroot-like behavior which are similarly affected by selinux, so > that a common technical solution can be found and applied. +1 This is just a bug between SELinux and any chrooting program. It is not a reason to fetch torches and pitchforks or to complain that SELinux sucks, or any of that nonsense. Fixing the interaction between SELinux and chroot is one of those things that can only get better the more real world usage SELinux sees. -Yaakov From ssorce at redhat.com Tue Jan 22 18:04:26 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 22 Jan 2008 13:04:26 -0500 Subject: selinux breaks revisor In-Reply-To: <7f692fec0801221001h1f4b3a27h83adb8351f7d2bc0@mail.gmail.com> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <4795E9FE.60501@redhat.com> <64b14b300801220518u6fc2598ew40d333aec99b12ce@mail.gmail.com> <604aa7910801220854u5e54f89dt7f5b5ab09f1a83f4@mail.gmail.com> <47961F30.4040003@ncsu.edu> <604aa7910801220916l4b0ce21ak9129f5dc56ad81b2@mail.gmail.com> <7f692fec0801221001h1f4b3a27h83adb8351f7d2bc0@mail.gmail.com> Message-ID: <1201025066.10767.220.camel@localhost.localdomain> On Tue, 2008-01-22 at 13:01 -0500, Yaakov Nemoy wrote: > On Jan 22, 2008 12:16 PM, Jeff Spaleta wrote: > > Selinux when interacting with any chroot-like apparatus is still a > > problem. Perhaps its time to take stock of all the packages that rely > > on chroot-like behavior which are similarly affected by selinux, so > > that a common technical solution can be found and applied. > > +1 > > This is just a bug between SELinux and any chrooting program. It is > not a reason to fetch torches and pitchforks or to complain that > SELinux sucks, or any of that nonsense. Fixing the interaction between > SELinux and chroot is one of those things that can only get better the > more real world usage SELinux sees. It seem to me that SELinux can provide for the same (or better) "features" of chroot without actually requiring a chrooted environment. So shouldn't we simply provide targeted policies and not use chroot for known services ? Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From sundaram at fedoraproject.org Tue Jan 22 18:17:51 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 22 Jan 2008 23:47:51 +0530 Subject: selinux breaks revisor In-Reply-To: <1201025066.10767.220.camel@localhost.localdomain> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <4795E9FE.60501@redhat.com> <64b14b300801220518u6fc2598ew40d333aec99b12ce@mail.gmail.com> <604aa7910801220854u5e54f89dt7f5b5ab09f1a83f4@mail.gmail.com> <47961F30.4040003@ncsu.edu> <604aa7910801220916l4b0ce21ak9129f5dc56ad81b2@mail.gmail.com> <7f692fec0801221001h1f4b3a27h83adb8351f7d2bc0@mail.gmail.com> <1201025066.10767.220.camel@localhost.localdomain> Message-ID: <4796334F.8090807@fedoraproject.org> Simo Sorce wrote: > On Tue, 2008-01-22 at 13:01 -0500, Yaakov Nemoy wrote: >> On Jan 22, 2008 12:16 PM, Jeff Spaleta wrote: >>> Selinux when interacting with any chroot-like apparatus is still a >>> problem. Perhaps its time to take stock of all the packages that rely >>> on chroot-like behavior which are similarly affected by selinux, so >>> that a common technical solution can be found and applied. >> +1 >> >> This is just a bug between SELinux and any chrooting program. It is >> not a reason to fetch torches and pitchforks or to complain that >> SELinux sucks, or any of that nonsense. Fixing the interaction between >> SELinux and chroot is one of those things that can only get better the >> more real world usage SELinux sees. > > It seem to me that SELinux can provide for the same (or better) > "features" of chroot without actually requiring a chrooted environment. > So shouldn't we simply provide targeted policies and not use chroot for > known services ? That wouldn't work. You shouldn't rely on SELinux but only take advantage of it if it is enabled. Rahul From jspaleta at gmail.com Tue Jan 22 18:10:22 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 22 Jan 2008 09:10:22 -0900 Subject: selinux breaks revisor In-Reply-To: <1201025066.10767.220.camel@localhost.localdomain> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <4795E9FE.60501@redhat.com> <64b14b300801220518u6fc2598ew40d333aec99b12ce@mail.gmail.com> <604aa7910801220854u5e54f89dt7f5b5ab09f1a83f4@mail.gmail.com> <47961F30.4040003@ncsu.edu> <604aa7910801220916l4b0ce21ak9129f5dc56ad81b2@mail.gmail.com> <7f692fec0801221001h1f4b3a27h83adb8351f7d2bc0@mail.gmail.com> <1201025066.10767.220.camel@localhost.localdomain> Message-ID: <604aa7910801221010h5f247dvb239cee92952c65a@mail.gmail.com> On Jan 22, 2008 9:04 AM, Simo Sorce wrote: > It seem to me that SELinux can provide for the same (or better) > "features" of chroot without actually requiring a chrooted environment. > So shouldn't we simply provide targeted policies and not use chroot for > known services ? If that works...then great. But I think you might want to look around first and take stock of the packages which are doing the chroots and start with something..sane. -jef From loupgaroublond at gmail.com Tue Jan 22 18:14:00 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Tue, 22 Jan 2008 13:14:00 -0500 Subject: selinux breaks revisor In-Reply-To: <1201025066.10767.220.camel@localhost.localdomain> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <4795E9FE.60501@redhat.com> <64b14b300801220518u6fc2598ew40d333aec99b12ce@mail.gmail.com> <604aa7910801220854u5e54f89dt7f5b5ab09f1a83f4@mail.gmail.com> <47961F30.4040003@ncsu.edu> <604aa7910801220916l4b0ce21ak9129f5dc56ad81b2@mail.gmail.com> <7f692fec0801221001h1f4b3a27h83adb8351f7d2bc0@mail.gmail.com> <1201025066.10767.220.camel@localhost.localdomain> Message-ID: <7f692fec0801221014p331a18bbxf512f056111ef866@mail.gmail.com> On Jan 22, 2008 1:04 PM, Simo Sorce wrote: > > > On Tue, 2008-01-22 at 13:01 -0500, Yaakov Nemoy wrote: > > On Jan 22, 2008 12:16 PM, Jeff Spaleta wrote: > > > Selinux when interacting with any chroot-like apparatus is still a > > > problem. Perhaps its time to take stock of all the packages that rely > > > on chroot-like behavior which are similarly affected by selinux, so > > > that a common technical solution can be found and applied. > > > > +1 > > > > This is just a bug between SELinux and any chrooting program. It is > > not a reason to fetch torches and pitchforks or to complain that > > SELinux sucks, or any of that nonsense. Fixing the interaction between > > SELinux and chroot is one of those things that can only get better the > > more real world usage SELinux sees. > > It seem to me that SELinux can provide for the same (or better) > "features" of chroot without actually requiring a chrooted environment. > So shouldn't we simply provide targeted policies and not use chroot for > known services ? Chroot provides a bunch of other 'features' (actually lack thereof) that SELinux on its own can't provide itself. SELinux can block a program from accessing certain files, or doing certain things on the machine, which is great for security. SELinux would have a harder time telling a program that a certain file doesn't exist, such as in a mock chroot. Furthermore, the chroot could be used to provide a more dynamic environment that is dissimilar to the host environment, such as using mock to build many different kinds of packages in a 'clean room'. The SELinux policy for that would have to be incredibly flexible. I don't think it's a sane idea. (I could be wrong.) I think what you really want is SELinux to be in some ways chroot aware, so that it can handle a policy within a policy, something that would let you chroot a policy into SELinux. You'd probably want a meta-chroot-policy as well, to define who or what can or cannot use chroot. It might even make doing certain things like running mock or revisor easier to implement so that they don't neet root access, or if they do, they are better confined. Honestly, I wish i knew more about writing policies to suggest what a better solution could be tough. -Yaakov From cra at WPI.EDU Tue Jan 22 18:13:48 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 22 Jan 2008 13:13:48 -0500 Subject: rescue mode has issues Message-ID: <20080122181348.GA10541@angus.ind.WPI.EDU> I have a dual-boot system running F7 on one VolumeGroup and rawhide on another, with two separate /boot partitions. There were a few problems with this setup: 1. Anaconda labeled /dev/sda3 as /boot even though /dev/sda2 already has this label. 2. The rescue image doesn't offer to mount the rawhide partition, which is installed to an encrypted PV. Perhaps it should offer to open encrypted volumes so it can search them for Fedora installs to mount. 3. I did a manual cryptsetup/vgchange/mount for the rawhide install. I needed to add entries to /etc/grub.conf and run "grub-install" to put grub on the boot sector of /dev/sda3. My first attempt was to chroot to /mnt/sysimage and run grub-install there: sh-3.2# grub-install /dev/sda3 Could not find device for /boot 4. I thought the filesystem label was the problem, so I tried to check the labels: sh-3.2# e2label /dev/sda2 /boot sh-3.2# e2label /dev/sda3 e2label: Filesystem has unsupported feature(s) while trying to open /dev/sda3 Couldn't find valid filesystem superblock. 5. Interesting. So I tried from outside the chroot. Same results: sh-3.2# exit exit sh-3.2# e2label /dev/sda2 /boot sh-3.2# e2label /dev/sda3 e2label: Filesystem has unsupported feature(s) while trying to open /dev/sda3 Couldn't find valid filesystem superblock. 6. I thought maybe the filesystem was corrupted, so I tried a manual fsck: sh-3.2# umount /mnt/sysimage/boot sh-3.2# fsck /dev/sda3 fsck 1.40.4 (31-Dec-2007) WARNING: couldn't open /etc/fstab: No such file or directory e2fsck 1.40.4 (31-Dec-2007) fsck.ext3: Filesystem has unsupported feature(s) while trying to open /dev/sda3 The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 7. Weird. I thought I'd try to do the grub-install from outside the chroot anyway: sh-3.2# grub-install /dev/sda3 /sbin/grub: Not found. 8. It appears that grub was moved to /usr/sbin and grub-install wasn't updated. Symlinking fixes it: sh-3.2# ln -s /usr/sbin/grub /sbin/grub sh-3.2# mount /dev/sda3 /mnt/sysimage/boot sh-3.2# grub-install --root-directory=/mnt/sysimage /dev/sda3 The file /mnt/sysimage/boot/grub/stage1 not read correctly. Shall I file bugs on all these issues? From jkeating at redhat.com Tue Jan 22 18:14:54 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 22 Jan 2008 13:14:54 -0500 Subject: selinux breaks revisor In-Reply-To: <1201025066.10767.220.camel@localhost.localdomain> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <4795E9FE.60501@redhat.com> <64b14b300801220518u6fc2598ew40d333aec99b12ce@mail.gmail.com> <604aa7910801220854u5e54f89dt7f5b5ab09f1a83f4@mail.gmail.com> <47961F30.4040003@ncsu.edu> <604aa7910801220916l4b0ce21ak9129f5dc56ad81b2@mail.gmail.com> <7f692fec0801221001h1f4b3a27h83adb8351f7d2bc0@mail.gmail.com> <1201025066.10767.220.camel@localhost.localdomain> Message-ID: <20080122131454.351adedf@redhat.com> On Tue, 22 Jan 2008 13:04:26 -0500 Simo Sorce wrote: > It seem to me that SELinux can provide for the same (or better) > "features" of chroot without actually requiring a chrooted > environment. So shouldn't we simply provide targeted policies and not > use chroot for known services ? That's not the point of many chroot usages. Frequently chroots are used to gain access to content from a different release or arch than what you have installed. EG we use RHEL5 to create chroots of f9 and build packages within that chroot using F9 content. Likewise we do a pure i386 package set on x86_64 to accomplish our i386 build. These types of usages cannot be easily replaced with an selinux policy. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From galibert at pobox.com Tue Jan 22 18:20:20 2008 From: galibert at pobox.com (Olivier Galibert) Date: Tue, 22 Jan 2008 19:20:20 +0100 Subject: Why is the time removed from the package intallation window In-Reply-To: <20080122175415.GA18331@nostromo.devel.redhat.com> References: <20080122173226.GB46223@dspnet.fr.eu.org> <20080122175415.GA18331@nostromo.devel.redhat.com> Message-ID: <20080122182020.GA52994@dspnet.fr.eu.org> On Tue, Jan 22, 2008 at 12:54:15PM -0500, Bill Nottingham wrote: > Olivier Galibert (galibert at pobox.com) said: > > I noticed now that I'm starting to actually install systems with f8 > > that the time used/remaining indication has been removed from the text > > installation screen. I'm curious, why is that? > > It's non-trivial to render accurately (it wasn't particularly accurate > before...) T'was better than nothing though. The time at the end at least was accurate and gave you an idea on how long the next installation would take. I didn't realize I'd have to time it by hand. OG. From limb at jcomserv.net Tue Jan 22 18:14:52 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 22 Jan 2008 12:14:52 -0600 (CST) Subject: Belated FUDCon Boston 2007 video postings In-Reply-To: <47962ED5.2060508@redhat.com> References: <47962BE2.2060905@redhat.com> <47962ED5.2060508@redhat.com> Message-ID: <63300.63.85.68.164.1201025692.squirrel@mail.jcomserv.net> > Holy crap, enigmail mangled the sense right out of this email. > > Jarod Wilson wrote: >> a few >> things, but the videos were captured using dvgrab on a powerpc system, >> wh= >> ich >> resulted in byte-swapped audio, which sounds rather HORRIFIC to the >> ears.= > [snip] > > Should have started out: > > So I had a dv camera at FUDCon Boston 2007 (last February), and recorded a > few > things, but the videos were captured using dvgrab on a powerpc system, > which > resulted in byte-swapped audio, which sounds rather HORRIFIC to the ears. > > Someone was kind enough to figure out how to fix it, but it took me > forever to > get around to actually fixing and compressing the videos, but they're now > available on torrent.fedoraproject.org. I don't see a link. . . > Of course, I was dumb enough to compress them with a codec that I don't > believe is available in Fedora proper, and the A/V sync is terrible, but > its > marginally better than nothing, I guess... > > > -- > Jarod Wilson > jwilson at redhat.com > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From sgrubb at redhat.com Tue Jan 22 18:22:20 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Tue, 22 Jan 2008 13:22:20 -0500 Subject: BIND less restrictive modes and policy In-Reply-To: <20080122160410.GA2673@evileye.atkac.englab.brq.redhat.com> References: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> <20080122142633.GK26108@angus.ind.WPI.EDU> <20080122160410.GA2673@evileye.atkac.englab.brq.redhat.com> Message-ID: <200801221322.20945.sgrubb@redhat.com> On Tuesday 22 January 2008 11:04:11 Adam Tkac wrote: > I don't think so. As I wrote in > https://bugzilla.redhat.com/show_bug.cgi?id=400461#c21 named is able > to produce core file after setuid when /var/named directory is > writable by named user. This is main reason why I want this directory > writable. It means that you will have always core file when named > gets sigsegv (no additional setup is needed, only writable > /var/named). To me, that is not enough reason. You have to do some work to allow coredumps at all. So, the admin may as well use /proc/sys/kernel/core_name_format to tell the kernel where to put the file. -Steve From valent.turkovic at gmail.com Tue Jan 22 18:22:40 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 22 Jan 2008 19:22:40 +0100 Subject: selinux breaks revisor In-Reply-To: <479626E2.1080607@redhat.com> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <20080122095152.73f3fab5@redhat.com> <64b14b300801220742n10de35cbs587f419f5b000347@mail.gmail.com> <479626E2.1080607@redhat.com> Message-ID: <47963470.70009@gmail.com> John Dennis wrote: > Valent Turkovic wrote: >> 2008/1/22 Jesse Keating : >>> On Tue, 22 Jan 2008 13:29:03 +0100 >>> "Valent Turkovic" wrote: >>> >>>> I tested revisor and wanted to make an up to date version of Fedora 8 >>>> Live CD - but selinux put a stop to that. >>> Selinux is not going to work at all for things like revisor (and >>> pungi/livecd-creator). Both make use of chroots to install packages >>> into, and in certain cases you can wind up causing lots of harm to your >>> host system (installing a new policy in the chroot will actually cause >>> that policy to activate on the running kernel and then you have policy >>> that doesn't match labels, watch the fun!). >>> >>> It is strongly recommended that you disable SELinux or at least put it >>> in permissive if you're going to be doing composes. >> >> Is there a was to make selinux aware of that or atleast put a >> notification window saying that you need to disable selinux in order >> to use revisor? > > Revisor could be aware of SELinux and provide a warning, SELinux cannot > do this. > >> One more issue for removing selinux as I said in an earlier thread :) >> Selinux breaks features by desing and in a bad way, and I as a user >> see more trouble from selinux than it is worth (just MHO). > > Your dissatisfaction with SELinux has been duly noted by the list, you > are free to disable it. However, we would prefer contributions to make > the distribution more robust and smooth out the bumps rather than > disabling the technology. Your choice. > I started to like selinux because all of you great fedora devels said nothing but praises for it, but still it seams that any "feature" I test seams to break because of selinux. But don't worry you all convinced me that selinux has a good reason to stay. Valent. From ssorce at redhat.com Tue Jan 22 18:24:20 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 22 Jan 2008 13:24:20 -0500 Subject: selinux breaks revisor In-Reply-To: <20080122131454.351adedf@redhat.com> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <4795E9FE.60501@redhat.com> <64b14b300801220518u6fc2598ew40d333aec99b12ce@mail.gmail.com> <604aa7910801220854u5e54f89dt7f5b5ab09f1a83f4@mail.gmail.com> <47961F30.4040003@ncsu.edu> <604aa7910801220916l4b0ce21ak9129f5dc56ad81b2@mail.gmail.com> <7f692fec0801221001h1f4b3a27h83adb8351f7d2bc0@mail.gmail.com> <1201025066.10767.220.camel@localhost.localdomain> <20080122131454.351adedf@redhat.com> Message-ID: <1201026260.10767.227.camel@localhost.localdomain> On Tue, 2008-01-22 at 13:14 -0500, Jesse Keating wrote: > On Tue, 22 Jan 2008 13:04:26 -0500 > Simo Sorce wrote: > > > It seem to me that SELinux can provide for the same (or better) > > "features" of chroot without actually requiring a chrooted > > environment. So shouldn't we simply provide targeted policies and not > > use chroot for known services ? > > That's not the point of many chroot usages. Frequently chroots are > used to gain access to content from a different release or arch than > what you have installed. EG we use RHEL5 to create chroots of f9 and > build packages within that chroot using F9 content. Likewise we do a > pure i386 package set on x86_64 to accomplish our i386 build. These > types of usages cannot be easily replaced with an selinux policy. I am sorry, I was thinking only about the security usage of chroots. I have been using chroots for "mock like" usage myself to release samba packages for older Debian releases for many years, should have just been thinking harder :-) What Yakoov wrote in the other emails makes a lot of sense indeed. Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From cra at WPI.EDU Tue Jan 22 18:27:18 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 22 Jan 2008 13:27:18 -0500 Subject: BIND less restrictive modes and policy In-Reply-To: <200801221322.20945.sgrubb@redhat.com> References: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> <20080122142633.GK26108@angus.ind.WPI.EDU> <20080122160410.GA2673@evileye.atkac.englab.brq.redhat.com> <200801221322.20945.sgrubb@redhat.com> Message-ID: <20080122182718.GA10978@angus.ind.WPI.EDU> On Tue, Jan 22, 2008 at 01:22:20PM -0500, Steve Grubb wrote: > On Tuesday 22 January 2008 11:04:11 Adam Tkac wrote: > > I don't think so. As I wrote in > > https://bugzilla.redhat.com/show_bug.cgi?id=400461#c21 named is able > > to produce core file after setuid when /var/named directory is > > writable by named user. This is main reason why I want this directory > > writable. It means that you will have always core file when named > > gets sigsegv (no additional setup is needed, only writable > > /var/named). > > To me, that is not enough reason. You have to do some work to allow coredumps > at all. So, the admin may as well use /proc/sys/kernel/core_name_format to > tell the kernel where to put the file. Ah. I wasn't aware that you could change the coredump path with this mechanism. It sounds like that is worth investigating, but won't you run into the same problems with permissions on whatever directory you choose? How can you choose one system-wide directory for coredumps if each process runs as a different user? From ssorce at redhat.com Tue Jan 22 18:30:44 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 22 Jan 2008 13:30:44 -0500 Subject: BIND less restrictive modes and policy In-Reply-To: <20080122182718.GA10978@angus.ind.WPI.EDU> References: <20080121115738.GA3512@evileye.atkac.englab.brq.redhat.com> <20080122142633.GK26108@angus.ind.WPI.EDU> <20080122160410.GA2673@evileye.atkac.englab.brq.redhat.com> <200801221322.20945.sgrubb@redhat.com> <20080122182718.GA10978@angus.ind.WPI.EDU> Message-ID: <1201026644.10767.228.camel@localhost.localdomain> On Tue, 2008-01-22 at 13:27 -0500, Chuck Anderson wrote: > On Tue, Jan 22, 2008 at 01:22:20PM -0500, Steve Grubb wrote: > > On Tuesday 22 January 2008 11:04:11 Adam Tkac wrote: > > > I don't think so. As I wrote in > > > https://bugzilla.redhat.com/show_bug.cgi?id=400461#c21 named is able > > > to produce core file after setuid when /var/named directory is > > > writable by named user. This is main reason why I want this directory > > > writable. It means that you will have always core file when named > > > gets sigsegv (no additional setup is needed, only writable > > > /var/named). > > > > To me, that is not enough reason. You have to do some work to allow coredumps > > at all. So, the admin may as well use /proc/sys/kernel/core_name_format to > > tell the kernel where to put the file. > > Ah. I wasn't aware that you could change the coredump path with this > mechanism. It sounds like that is worth investigating, but won't you > run into the same problems with permissions on whatever directory you > choose? How can you choose one system-wide directory for coredumps if > each process runs as a different user? /tmp ... Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From sundaram at fedoraproject.org Tue Jan 22 18:48:17 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 23 Jan 2008 00:18:17 +0530 Subject: Virtual provides for window managers Message-ID: <47963A71.7030207@fedoraproject.org> Hi System-config-display has a hard dependency on metacity while it is not required at all in say the KDE or Xfce spin. I believe the ideal solution would be to have add a virtual provides to all the window managers and then depend on it from system-config-display https://bugzilla.redhat.com/show_bug.cgi?id=427814 What would be the best way to move ahead with this now? File individual bug reports against each of them? Rahul From valent.turkovic at gmail.com Tue Jan 22 18:39:43 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 22 Jan 2008 19:39:43 +0100 Subject: revisor - is this a bug or is it me? Message-ID: <64b14b300801221039l1f3969cdkc7093876c75e74db@mail.gmail.com> I'm not sure if this is a bug so that is why I'm writing here first. I would like to respin Fedora 8 Live CD, and I read documentation from pungi and revisor and it seams straightforward. But this is my fist time using it so I can't deny that the issue could be between the keyboard and the chair :) So these are my steps: 1. Put selinux to permissive mode 2. Launch revisor 3. after being prompted for root password I type it in 4. on first screen "show advanced options" is grayed out so I click only thing I can - "Get Started" 5. On second screen [1] I choose "DVD Set" and "Optical Live Media" (I choose DVD despite Fedora 8 Live is a CD and not a DVD because on second screen it showed it needs 777MB of data and AFAIK CDs can't store more than 700MB) and clicked "Forward" 6. on third screen [2] I left "Revisor Configuration" by default to "/etc/revisor/revisor.conf" for "Configuration Section to Use" I choose "f8-i386" and clicked on apply (is apply necessary? repositories should change automatically as you choose configuration you want), I left destination directory to it's default "/srv/revisor/f8-i386" and I clicked forward 7. on fourth screen [3] for "Kickstart Configuration File" I choose "/usr/share/fedora-release/livecd-fedora-desktop.ks" and I checked these options: use repositories configured in the kickstart file use package manifest from kickstart data include kickstart file on installation media set installer to boot with kickstart by default My intention was to recreate respin that was identical to official one, only with never packages, that is why I didn't choose any customization options. then I click forward and then I came across this bug [4] and you can see the screenshot [5] 8. after clicking all those warnings for missing files I came to fifth screen and clicked forward 9. and again warnings about missing files [6], and after clicking the last one respining statred. I saw lots of messages in revisor window "stat: cannot stat `chroot': No such file or directory" and also posted a bug [7] regarding that in bugzilla. 10. I got another error [8] because of some conflicts :( This one I didn't put on bugzilla. Can you please check if I am doing something wrong or are all these legitimate bugs and revisor is broken temporarily? Cheers, Valent. [1] http://www.uploadgeek.com/uploads456/0/Screenshot-Revisor-1.png - second screen [2] http://www.uploadgeek.com/uploads456/0/Screenshot-Revisor-livecd-1.png - third screen [3] http://www.uploadgeek.com/uploads456/0/Screenshot-Revisor-livecd-2.png - fourth screen [4] https://bugzilla.redhat.com/show_bug.cgi?id=429681 - revisor missing files bug [5] https://bugzilla.redhat.com/attachment.cgi?id=292502 - revisor missing files #1 [6] https://bugzilla.redhat.com/attachment.cgi?id=292503 - revisor missing files #2 [7] https://bugzilla.redhat.com/show_bug.cgi?id=429689 - cp: cannot stat 'chroot' [8] http://www.uploadgeek.com/uploads456/0/Screenshot-Revisor-error.png -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From skvidal at fedoraproject.org Tue Jan 22 18:42:06 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 22 Jan 2008 13:42:06 -0500 Subject: Belated FUDCon Boston 2007 video postings In-Reply-To: <63300.63.85.68.164.1201025692.squirrel@mail.jcomserv.net> References: <47962BE2.2060905@redhat.com> <47962ED5.2060508@redhat.com> <63300.63.85.68.164.1201025692.squirrel@mail.jcomserv.net> Message-ID: <1201027326.6218.10.camel@cutter> On Tue, 2008-01-22 at 12:14 -0600, Jon Ciesla wrote: > > Holy crap, enigmail mangled the sense right out of this email. > > > > Jarod Wilson wrote: > >> a few > >> things, but the videos were captured using dvgrab on a powerpc system, > >> wh= > >> ich > >> resulted in byte-swapped audio, which sounds rather HORRIFIC to the > >> ears.= > > [snip] > > > > Should have started out: > > > > So I had a dv camera at FUDCon Boston 2007 (last February), and recorded a > > few > > things, but the videos were captured using dvgrab on a powerpc system, > > which > > resulted in byte-swapped audio, which sounds rather HORRIFIC to the ears. > > > > Someone was kind enough to figure out how to fix it, but it took me > > forever to > > get around to actually fixing and compressing the videos, but they're now > > available on torrent.fedoraproject.org. > > I don't see a link. . . > > > scroll down to fudcon 2007 videos -sv From mclasen at redhat.com Tue Jan 22 18:45:41 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 22 Jan 2008 13:45:41 -0500 Subject: Virtual provides for window managers In-Reply-To: <47963A71.7030207@fedoraproject.org> References: <47963A71.7030207@fedoraproject.org> Message-ID: <1201027541.2791.2.camel@localhost.localdomain> On Wed, 2008-01-23 at 00:18 +0530, Rahul Sundaram wrote: > Hi > > System-config-display has a hard dependency on metacity while it is not > required at all in say the KDE or Xfce spin. I believe the ideal > solution would be to have add a virtual provides to all the window > managers and then depend on it from system-config-display > > https://bugzilla.redhat.com/show_bug.cgi?id=427814 > > What would be the best way to move ahead with this now? File individual > bug reports against each of them? Have you checked why s-c-d has a dependency on metacity ?! It is there because it runs metacity if there is no X server/wm around. Having twm installed will help little for that... From jakub.rusinek at gmail.com Tue Jan 22 18:43:32 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Tue, 22 Jan 2008 19:43:32 +0100 Subject: Virtual provides for window managers In-Reply-To: <1201027541.2791.2.camel@localhost.localdomain> References: <47963A71.7030207@fedoraproject.org> <1201027541.2791.2.camel@localhost.localdomain> Message-ID: <1201027412.5468.0.camel@geeko> Dnia 22-01-2008, wto o godzinie 13:45 -0500, Matthias Clasen pisze: > On Wed, 2008-01-23 at 00:18 +0530, Rahul Sundaram wrote: > > Hi > > > > System-config-display has a hard dependency on metacity while it is not > > required at all in say the KDE or Xfce spin. I believe the ideal > > solution would be to have add a virtual provides to all the window > > managers and then depend on it from system-config-display > > > > https://bugzilla.redhat.com/show_bug.cgi?id=427814 > > > > What would be the best way to move ahead with this now? File individual > > bug reports against each of them? > > Have you checked why s-c-d has a dependency on metacity ?! > > It is there because it runs metacity if there is no X server/wm around. > Having twm installed will help little for that... > What about eg. fvwm instead of twm? twm doesn't look familiar for GNOME/KDE user at all... -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? wiadomo?ci podpisana cyfrowo URL: From jspaleta at gmail.com Tue Jan 22 19:06:12 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 22 Jan 2008 10:06:12 -0900 Subject: revisor - is this a bug or is it me? In-Reply-To: <64b14b300801221039l1f3969cdkc7093876c75e74db@mail.gmail.com> References: <64b14b300801221039l1f3969cdkc7093876c75e74db@mail.gmail.com> Message-ID: <604aa7910801221106q2b356c36ta9fdd91c305c4bad@mail.gmail.com> On Jan 22, 2008 9:39 AM, Valent Turkovic wrote: > My intention was to recreate respin that was identical to official > one, only with never packages, that is why I didn't choose any > customization options. Fedora Unity people are doing this sort of re-spin already. The best people to talk to in terms of revisor usage are the Fedora Unity folks since they are most likely the people who are using it most frequently. Fedoraunity.org and #fedora-unity on freenode irc network -jef From dmc.fedora at filteredperception.org Tue Jan 22 19:08:45 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 22 Jan 2008 13:08:45 -0600 Subject: selinux breaks revisor In-Reply-To: <604aa7910801220916l4b0ce21ak9129f5dc56ad81b2@mail.gmail.com> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <4795E9FE.60501@redhat.com> <64b14b300801220518u6fc2598ew40d333aec99b12ce@mail.gmail.com> <604aa7910801220854u5e54f89dt7f5b5ab09f1a83f4@mail.gmail.com> <47961F30.4040003@ncsu.edu> <604aa7910801220916l4b0ce21ak9129f5dc56ad81b2@mail.gmail.com> Message-ID: <47963F3D.3000901@filteredperception.org> Jeff Spaleta wrote: > On Jan 22, 2008 7:52 AM, Casey Dahlin wrote: >> We're advertising it in a very public way. More people are expecting it >> to work. > > But we aren't using it internally, we aren't dogfooding it with our > spins, and I want to make sure Valent and anyone reading the thread > understands that. My reading of Valent's comment informed me that he > was assuming we were seeing these problems as part of spin release and > implied an assumption that we were using revisor. We aren't. > > > Now that being said, I think any spin generation toolchain which we > are offering, should be packaged in a way that informs people that > selinux needs to be disabled to use correctly. > And since I don't think spin creation falls into a desktop usage case > of any rational merit, but falls instead into development usage, then > I don't think such a tool should automatically disable selinux even > temporarily. > > Selinux when interacting with any chroot-like apparatus is still a > problem. Except for perhaps *cough* qfakeroot (disclaimer: the below urls are about 12 hours old, and the tools in question are still a couple days away from being actually testable from the tutorial which also is only about 12 hours old) http://filteredperception.org/smiley/projects/viros/viros-0.5/tools/scripts/qfakeroot.html http://filteredperception.org/smiley/projects/viros/docs/faq/index.html#viros_differences_from_livecdtools Note, that one reason I went down this rather convoluted non-traditional architecture for a compose tool, was to quite explicitly not have any dependence on host build system state such as selinux (and not require root priveleges to run is the other related big one) -dmc Perhaps its time to take stock of all the packages that rely > on chroot-like behavior which are similarly affected by selinux, so > that a common technical solution can be found and applied. > > -jef > -jef > From limb at jcomserv.net Tue Jan 22 19:30:50 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 22 Jan 2008 13:30:50 -0600 (CST) Subject: Belated FUDCon Boston 2007 video postings In-Reply-To: <1201027326.6218.10.camel@cutter> References: <47962BE2.2060905@redhat.com> <47962ED5.2060508@redhat.com> <63300.63.85.68.164.1201025692.squirrel@mail.jcomserv.net> <1201027326.6218.10.camel@cutter> Message-ID: <20158.63.85.68.164.1201030250.squirrel@mail.jcomserv.net> > > On Tue, 2008-01-22 at 12:14 -0600, Jon Ciesla wrote: >> > Holy crap, enigmail mangled the sense right out of this email. >> > >> > Jarod Wilson wrote: >> >> a few >> >> things, but the videos were captured using dvgrab on a powerpc >> system, >> >> wh= >> >> ich >> >> resulted in byte-swapped audio, which sounds rather HORRIFIC to the >> >> ears.= >> > [snip] >> > >> > Should have started out: >> > >> > So I had a dv camera at FUDCon Boston 2007 (last February), and >> recorded a >> > few >> > things, but the videos were captured using dvgrab on a powerpc system, >> > which >> > resulted in byte-swapped audio, which sounds rather HORRIFIC to the >> ears. >> > >> > Someone was kind enough to figure out how to fix it, but it took me >> > forever to >> > get around to actually fixing and compressing the videos, but they're >> now >> > available on torrent.fedoraproject.org. >> >> I don't see a link. . . >> >> >> > > scroll down to fudcon 2007 videos Oops, my bad, I thought he meant 2008 at Raliegh. Ignore me. :) > -sv > > -- novus ordo absurdum From valent.turkovic at gmail.com Tue Jan 22 19:48:27 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 22 Jan 2008 20:48:27 +0100 Subject: revisor - is this a bug or is it me? In-Reply-To: <604aa7910801221106q2b356c36ta9fdd91c305c4bad@mail.gmail.com> References: <64b14b300801221039l1f3969cdkc7093876c75e74db@mail.gmail.com> <604aa7910801221106q2b356c36ta9fdd91c305c4bad@mail.gmail.com> Message-ID: <64b14b300801221148q7b06592bu1d64d0dc22362dc2@mail.gmail.com> On 1/22/08, Jeff Spaleta wrote: > On Jan 22, 2008 9:39 AM, Valent Turkovic wrote: > > My intention was to recreate respin that was identical to official > > one, only with never packages, that is why I didn't choose any > > customization options. > > > Fedora Unity people are doing this sort of re-spin already. The best > people to talk to in terms of revisor usage are the Fedora Unity folks > since they are most likely the people who are using it most > frequently. > > Fedoraunity.org and #fedora-unity on freenode irc network > > > -jef > Ok, for usage I will go to them, but what about the bugs I reported about? Fedora unity people aren't developing revisor AFAIK, or are they? Valent -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From sundaram at fedoraproject.org Tue Jan 22 20:04:38 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 23 Jan 2008 01:34:38 +0530 Subject: revisor - is this a bug or is it me? In-Reply-To: <64b14b300801221148q7b06592bu1d64d0dc22362dc2@mail.gmail.com> References: <64b14b300801221039l1f3969cdkc7093876c75e74db@mail.gmail.com> <604aa7910801221106q2b356c36ta9fdd91c305c4bad@mail.gmail.com> <64b14b300801221148q7b06592bu1d64d0dc22362dc2@mail.gmail.com> Message-ID: <47964C56.9060404@fedoraproject.org> Valent Turkovic wrote: > Ok, for usage I will go to them, but what about the bugs I reported > about? Fedora unity people aren't developing revisor AFAIK, or are > they? Yes. They are. The best list for revisor questions is http://lists.fedoraunity.org/mailman/listinfo/revisor-users Rahul From jspaleta at gmail.com Tue Jan 22 20:23:35 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 22 Jan 2008 11:23:35 -0900 Subject: revisor - is this a bug or is it me? In-Reply-To: <64b14b300801221148q7b06592bu1d64d0dc22362dc2@mail.gmail.com> References: <64b14b300801221039l1f3969cdkc7093876c75e74db@mail.gmail.com> <604aa7910801221106q2b356c36ta9fdd91c305c4bad@mail.gmail.com> <64b14b300801221148q7b06592bu1d64d0dc22362dc2@mail.gmail.com> Message-ID: <604aa7910801221223p63da1654nb698a7d41b964eb5@mail.gmail.com> On Jan 22, 2008 10:48 AM, Valent Turkovic wrote: > Ok, for usage I will go to them, but what about the bugs I reported > about? Fedora unity people aren't developing revisor AFAIK, or are > they? Here's where we talk about what it means to be a Fedora developer, versus just a developer. In actually, very little is developed as part of fedora directly. There are multiple pieces of technology where fedora contributors are also significant upstream developers, but for most packages fedora!=upstream. Even when the project source code is hosted at hosted.fedoraproject.org, its still not necessarily appropriate to think of that project as a 'Fedora' At the most naive level, it might be best to think of people building pieces of Fedora infrastructure as Fedora developers, and you'd mostly be right, since the infrastructure that Fedora project uses is in large part motivated by internal project needs. But other people do use those bits so they do have some upstream context that isn't completely defined by Fedora. Outside of that it gets much harder to define when someone is Fedora developer specifically. Some examples.... The kernel is important to Fedora, but are the Fedora contributors Fedora developers...or are they kernel developers? I'd like to think of them as kernel developers who contribute to Fedora.. because in all the ways that matter they are driving important enhancements into the kernel base, so that all linux kernel users potentially benefit. Fedora as a project helps them do that more effectively by being an easy way for user to get access to kernel builds as part of an integrated whole. Can Fedora as a project change to be even an even more effective conduit to connect kernel developers and users... yes..now and forever. The gnome desktop is important to Fedora, but are the gnome desktop contributors Fedora developers... or are the gnome developers? I'd like to think of them as gnome desktop developers who contribute to Fedora.. because in all the ways that matter they are driving important enhancements into the gnome codebase so that all gnome users potentially benefit. Fedora as a project helps them do that more effectively by being an easy way for user to get access to gnome builds as part of an integrated whole. Can Fedora as a project change to be even an even more effective conduit to connect gnome developers and users... yes..now and forever. Similarly, revisor is its own upstream project with its own developers. We as a project are lucky enough to count some if not all of the developers of the tool as Fedora contributors. And hopefully the revisor developers see Fedora as a project an effective conduit to get users, using their bits. Can Fedora as a project change to be even an even more effective conduit to connect revisor developers and users... yes..now and forever. -jef"Holy crap its above freezing here! I love global warming!"spaleta From valent.turkovic at gmail.com Tue Jan 22 20:25:57 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Tue, 22 Jan 2008 21:25:57 +0100 Subject: revisor - is this a bug or is it me? In-Reply-To: <47964C56.9060404@fedoraproject.org> References: <64b14b300801221039l1f3969cdkc7093876c75e74db@mail.gmail.com> <604aa7910801221106q2b356c36ta9fdd91c305c4bad@mail.gmail.com> <64b14b300801221148q7b06592bu1d64d0dc22362dc2@mail.gmail.com> <47964C56.9060404@fedoraproject.org> Message-ID: <64b14b300801221225sac61bc4o912738c636adb995@mail.gmail.com> On 1/22/08, Rahul Sundaram wrote: > Valent Turkovic wrote: > > > Ok, for usage I will go to them, but what about the bugs I reported > > about? Fedora unity people aren't developing revisor AFAIK, or are > > they? > > Yes. They are. The best list for revisor questions is > > http://lists.fedoraunity.org/mailman/listinfo/revisor-users > > Rahul Oh, thank you, I wasn't aware of that. I thought since I'm using a really loudly advertised fedora feature, and config files which all of them are provided from fedora and not some 3rd party that this is the correct list. Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From jkeating at redhat.com Tue Jan 22 20:30:17 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 22 Jan 2008 15:30:17 -0500 Subject: revisor - is this a bug or is it me? In-Reply-To: <64b14b300801221225sac61bc4o912738c636adb995@mail.gmail.com> References: <64b14b300801221039l1f3969cdkc7093876c75e74db@mail.gmail.com> <604aa7910801221106q2b356c36ta9fdd91c305c4bad@mail.gmail.com> <64b14b300801221148q7b06592bu1d64d0dc22362dc2@mail.gmail.com> <47964C56.9060404@fedoraproject.org> <64b14b300801221225sac61bc4o912738c636adb995@mail.gmail.com> Message-ID: <20080122153017.6fff9c0a@redhat.com> On Tue, 22 Jan 2008 21:25:57 +0100 "Valent Turkovic" wrote: > Oh, thank you, I wasn't aware of that. > > I thought since I'm using a really loudly advertised fedora feature, > and config files which all of them are provided from fedora and not > some 3rd party that this is the correct list. You are aware that the vast majority of software in Fedora is developed and discussed at their respective upstream locations, right? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From orion at cora.nwra.com Tue Jan 22 22:04:15 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 22 Jan 2008 15:04:15 -0700 Subject: rescue mode has issues In-Reply-To: <20080122181348.GA10541@angus.ind.WPI.EDU> References: <20080122181348.GA10541@angus.ind.WPI.EDU> Message-ID: <4796685F.2070607@cora.nwra.com> Chuck Anderson wrote: > > Shall I file bugs on all these issues? > I filed https://bugzilla.redhat.com/show_bug.cgi?id=429758 against the installer not being able to access F7 filesystem labels. This prevents upgrade installs as well. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From sandeen at redhat.com Tue Jan 22 22:20:35 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Tue, 22 Jan 2008 16:20:35 -0600 Subject: rescue mode has issues In-Reply-To: <20080122181348.GA10541@angus.ind.WPI.EDU> References: <20080122181348.GA10541@angus.ind.WPI.EDU> Message-ID: <47966C33.6090205@redhat.com> Chuck Anderson wrote: > I have a dual-boot system running F7 on one VolumeGroup and rawhide on > another, with two separate /boot partitions. There were a few > problems with this setup: ... > 5. Interesting. So I tried from outside the chroot. Same results: > > sh-3.2# exit > exit > sh-3.2# e2label /dev/sda2 > /boot > sh-3.2# e2label /dev/sda3 > e2label: Filesystem has unsupported feature(s) while trying to open > /dev/sda3 > Shall I file bugs on all these issues? > Sure, at least for the extents flag problem, please do & assign to me. It may have an anaconda component but I'd assign to kernel for now. Thanks, -Eric (btw I also saw the duplicate label problem...) From Michael_E_Brown at dell.com Tue Jan 22 22:23:04 2008 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 22 Jan 2008 16:23:04 -0600 Subject: selinux breaks revisor In-Reply-To: <1201025066.10767.220.camel@localhost.localdomain> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <4795E9FE.60501@redhat.com> <64b14b300801220518u6fc2598ew40d333aec99b12ce@mail.gmail.com> <604aa7910801220854u5e54f89dt7f5b5ab09f1a83f4@mail.gmail.com> <47961F30.4040003@ncsu.edu> <604aa7910801220916l4b0ce21ak9129f5dc56ad81b2@mail.gmail.com> <7f692fec0801221001h1f4b3a27h83adb8351f7d2bc0@mail.gmail.com> <1201025066.10767.220.camel@localhost.localdomain> Message-ID: <20080122222304.GA22254@humbolt.us.dell.com> On Tue, Jan 22, 2008 at 01:04:26PM -0500, Simo Sorce wrote: > > On Tue, 2008-01-22 at 13:01 -0500, Yaakov Nemoy wrote: > > On Jan 22, 2008 12:16 PM, Jeff Spaleta wrote: > > > Selinux when interacting with any chroot-like apparatus is still a > > > problem. Perhaps its time to take stock of all the packages that rely > > > on chroot-like behavior which are similarly affected by selinux, so > > > that a common technical solution can be found and applied. > > > > +1 > > > > This is just a bug between SELinux and any chrooting program. It is > > not a reason to fetch torches and pitchforks or to complain that > > SELinux sucks, or any of that nonsense. Fixing the interaction between > > SELinux and chroot is one of those things that can only get better the > > more real world usage SELinux sees. > > It seem to me that SELinux can provide for the same (or better) > "features" of chroot without actually requiring a chrooted environment. > So shouldn't we simply provide targeted policies and not use chroot for > known services ? You miss the point. Things like pungi, mock, livecd-creator... Their whole existence in life relies heavily on creating a chroot to do their business. This is not a problem we can just say "dont do that", it needs to be fixed, as mentioned by other posters. -- Michael From snecklifter at gmail.com Tue Jan 22 22:48:17 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Tue, 22 Jan 2008 22:48:17 +0000 Subject: Belated FUDCon Boston 2007 video postings In-Reply-To: <20158.63.85.68.164.1201030250.squirrel@mail.jcomserv.net> References: <47962BE2.2060905@redhat.com> <47962ED5.2060508@redhat.com> <63300.63.85.68.164.1201025692.squirrel@mail.jcomserv.net> <1201027326.6218.10.camel@cutter> <20158.63.85.68.164.1201030250.squirrel@mail.jcomserv.net> Message-ID: <364d303b0801221448v2bf54e18y28bad2ebcd766d23@mail.gmail.com> On 22/01/2008, Jon Ciesla wrote: > > > > > On Tue, 2008-01-22 at 12:14 -0600, Jon Ciesla wrote: > >> > Holy crap, enigmail mangled the sense right out of this email. > >> > > >> > Jarod Wilson wrote: > >> >> a few > >> >> things, but the videos were captured using dvgrab on a powerpc > >> system, > >> >> wh= > >> >> ich > >> >> resulted in byte-swapped audio, which sounds rather HORRIFIC to the > >> >> ears.= > >> > [snip] > >> > > >> > Should have started out: > >> > > >> > So I had a dv camera at FUDCon Boston 2007 (last February), and > >> recorded a > >> > few > >> > things, but the videos were captured using dvgrab on a powerpc system, > >> > which > >> > resulted in byte-swapped audio, which sounds rather HORRIFIC to the > >> ears. > >> > > >> > Someone was kind enough to figure out how to fix it, but it took me > >> > forever to > >> > get around to actually fixing and compressing the videos, but they're > >> now > >> > available on torrent.fedoraproject.org. > >> > >> I don't see a link. . . > >> > >> > >> > > > > scroll down to fudcon 2007 videos > > Oops, my bad, I thought he meant 2008 at Raliegh. Ignore me. :) Any chance of videos from 2008? Or was the profanity and voodoo too much and it all got censored? -- Christopher Brown http://www.chruz.com From skvidal at fedoraproject.org Tue Jan 22 22:51:39 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 22 Jan 2008 17:51:39 -0500 Subject: Belated FUDCon Boston 2007 video postings In-Reply-To: <364d303b0801221448v2bf54e18y28bad2ebcd766d23@mail.gmail.com> References: <47962BE2.2060905@redhat.com> <47962ED5.2060508@redhat.com> <63300.63.85.68.164.1201025692.squirrel@mail.jcomserv.net> <1201027326.6218.10.camel@cutter> <364d303b0801221448v2bf54e18y28bad2ebcd766d23@mail.gmail.com> Message-ID: <1201042299.6218.41.camel@cutter> On Tue, 2008-01-22 at 22:48 +0000, Christopher Brown wrote: > On 22/01/2008, Jon Ciesla wrote: > > > > > > > > On Tue, 2008-01-22 at 12:14 -0600, Jon Ciesla wrote: > > >> > Holy crap, enigmail mangled the sense right out of this email. > > >> > > > >> > Jarod Wilson wrote: > > >> >> a few > > >> >> things, but the videos were captured using dvgrab on a powerpc > > >> system, > > >> >> wh= > > >> >> ich > > >> >> resulted in byte-swapped audio, which sounds rather HORRIFIC to the > > >> >> ears.= > > >> > [snip] > > >> > > > >> > Should have started out: > > >> > > > >> > So I had a dv camera at FUDCon Boston 2007 (last February), and > > >> recorded a > > >> > few > > >> > things, but the videos were captured using dvgrab on a powerpc system, > > >> > which > > >> > resulted in byte-swapped audio, which sounds rather HORRIFIC to the > > >> ears. > > >> > > > >> > Someone was kind enough to figure out how to fix it, but it took me > > >> > forever to > > >> > get around to actually fixing and compressing the videos, but they're > > >> now > > >> > available on torrent.fedoraproject.org. > > >> > > >> I don't see a link. . . > > >> > > >> > > >> > > > > > > scroll down to fudcon 2007 videos > > > > Oops, my bad, I thought he meant 2008 at Raliegh. Ignore me. :) > > Any chance of videos from 2008? Or was the profanity and voodoo too > much and it all got censored? > I asked this this morning - "they are being prepared" was the answer I got. -sv From ssorce at redhat.com Tue Jan 22 22:56:03 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 22 Jan 2008 17:56:03 -0500 Subject: selinux breaks revisor In-Reply-To: <20080122222304.GA22254@humbolt.us.dell.com> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <4795E9FE.60501@redhat.com> <64b14b300801220518u6fc2598ew40d333aec99b12ce@mail.gmail.com> <604aa7910801220854u5e54f89dt7f5b5ab09f1a83f4@mail.gmail.com> <47961F30.4040003@ncsu.edu> <604aa7910801220916l4b0ce21ak9129f5dc56ad81b2@mail.gmail.com> <7f692fec0801221001h1f4b3a27h83adb8351f7d2bc0@mail.gmail.com> <1201025066.10767.220.camel@localhost.localdomain> <20080122222304.GA22254@humbolt.us.dell.com> Message-ID: <1201042563.10767.245.camel@localhost.localdomain> On Tue, 2008-01-22 at 16:23 -0600, Michael E Brown wrote: > On Tue, Jan 22, 2008 at 01:04:26PM -0500, Simo Sorce wrote: > > > > On Tue, 2008-01-22 at 13:01 -0500, Yaakov Nemoy wrote: > > > On Jan 22, 2008 12:16 PM, Jeff Spaleta wrote: > > > > Selinux when interacting with any chroot-like apparatus is still a > > > > problem. Perhaps its time to take stock of all the packages that rely > > > > on chroot-like behavior which are similarly affected by selinux, so > > > > that a common technical solution can be found and applied. > > > > > > +1 > > > > > > This is just a bug between SELinux and any chrooting program. It is > > > not a reason to fetch torches and pitchforks or to complain that > > > SELinux sucks, or any of that nonsense. Fixing the interaction between > > > SELinux and chroot is one of those things that can only get better the > > > more real world usage SELinux sees. > > > > It seem to me that SELinux can provide for the same (or better) > > "features" of chroot without actually requiring a chrooted environment. > > So shouldn't we simply provide targeted policies and not use chroot for > > known services ? > > You miss the point. > > Things like pungi, mock, livecd-creator... Their whole existence in life > relies heavily on creating a chroot to do their business. > > This is not a problem we can just say "dont do that", it needs to be > fixed, as mentioned by other posters. And you come in late :-) Already apologized in another mail. Simo. -- | Simo S Sorce | | Sr.Soft.Eng. | | Red Hat, Inc | | New York, NY | From kevin.kofler at chello.at Tue Jan 22 23:17:18 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 22 Jan 2008 23:17:18 +0000 (UTC) Subject: SELinux removed from desktop cd spin? References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116200333.GE15623@redhat.com> <64b14b300801161219q355d93b0jb57f91f48615591a@mail.gmail.com> <20080116202554.GF15623@redhat.com> <64b14b300801161235i4a4ed432h4f7b81ecefaf292b@mail.gmail.com> <7f692fec0801161717x3b0d77b9n9cd4a2dd939c6398@mail.gmail.com> <478F6C07.2050108@gmail.com> <1200617202.920.156.camel@calliope.phig.org> Message-ID: Karsten 'quaid' Wade redhat.com> writes: > > "As a final note, I follow the logic of the grsecurity team, who claim > > that LSM and SELinux are backdoors waiting to happen." [snip] > But when it comes to who knows how to implement IT security, I'll take > the US's National Security Agency over just about any group in the > history of the world. Are you seriously trying to imply that the NSA, of all organizations, never backdoors anything? Kevin Kofler From sundaram at fedoraproject.org Tue Jan 22 23:30:47 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 23 Jan 2008 05:00:47 +0530 Subject: SELinux removed from desktop cd spin? In-Reply-To: References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116200333.GE15623@redhat.com> <64b14b300801161219q355d93b0jb57f91f48615591a@mail.gmail.com> <20080116202554.GF15623@redhat.com> <64b14b300801161235i4a4ed432h4f7b81ecefaf292b@mail.gmail.com> <7f692fec0801161717x3b0d77b9n9cd4a2dd939c6398@mail.gmail.com> <478F6C07.2050108@gmail.com> <1200617202.920.156.camel@calliope.phig.org> Message-ID: <47967CA7.3000604@fedoraproject.org> Kevin Kofler wrote: > Karsten 'quaid' Wade redhat.com> writes: >>> "As a final note, I follow the logic of the grsecurity team, who claim >>> that LSM and SELinux are backdoors waiting to happen." > [snip] >> But when it comes to who knows how to implement IT security, I'll take >> the US's National Security Agency over just about any group in the >> history of the world. > > Are you seriously trying to imply that the NSA, of all organizations, never > backdoors anything? They would have to pretty stupid to try to do something like that with free and open source software. Rahul From kevin.kofler at chello.at Tue Jan 22 23:24:44 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 22 Jan 2008 23:24:44 +0000 (UTC) Subject: SELinux removed from desktop cd spin? References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080117034056.GG18982@zoidtechnologies.com> <478EDAFB.7090506@filteredperception.org> <478EEC16.9010902@gmail.com> <478EF22A.2090406@filteredperception.org> <478EFB7D.1060508@gmail.com> <478EFC8C.7060208@filteredperception.org> <478F00B5.60306@gmail.com> Message-ID: Andrew Farris gmail.com> writes: > This may be a minor semantic difference, but I see no reason why the > distribution should produce official spins without selinux *available*... Disk space? CDs or even DVDs only have finite size. Kevin Kofler From skvidal at fedoraproject.org Tue Jan 22 23:25:27 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 22 Jan 2008 18:25:27 -0500 Subject: F8 to rawhide upgrade - yum python mismatch - repeatable In-Reply-To: <1201009795.6218.4.camel@cutter> References: <4795CBCA.3070007@iinet.net.au> <4795D94F.1030505@gmail.com> <4795EE99.3000209@iinet.net.au> <1201009795.6218.4.camel@cutter> Message-ID: <1201044327.6218.43.camel@cutter> On Tue, 2008-01-22 at 08:49 -0500, seth vidal wrote: > remove yum-metadata-parser via rpm -e, please > > and then try running yum. > > if yum works then yum install yum-metadata-parser and tell me if it > still balks. > I rebuild yum-metadata-parser into rawhide. Nothing changed in it - just a rebuild - let's see if that makes things better. -sv From markg85 at gmail.com Tue Jan 22 23:26:50 2008 From: markg85 at gmail.com (Mark) Date: Wed, 23 Jan 2008 00:26:50 +0100 Subject: Opinion: Preferred Applications & Removable Drives and Media In-Reply-To: <6e24a8e80801200641m64febab5v5f1bbc1fa1977e19@mail.gmail.com> References: <6e24a8e80801191428m45ecd472w788c4a88055f0455@mail.gmail.com> <1200785912.2924.14.camel@localhost.localdomain> <6e24a8e80801200641m64febab5v5f1bbc1fa1977e19@mail.gmail.com> Message-ID: <6e24a8e80801221526y4caac2c5g3522773b5dfb7ca5@mail.gmail.com> Oke i installed the nautillus from rawhide now and that's looking promising! good job so far! Just one question: how can i change the media autorun behavior? i can see the settings but am not able to change them [1]. [1] http://img120.imageshack.us/img120/6528/screenshotfilemanagemeneu9.png Thanx, Mark From lesmikesell at gmail.com Tue Jan 22 23:47:13 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 22 Jan 2008 17:47:13 -0600 Subject: SELinux removed from desktop cd spin? In-Reply-To: <47967CA7.3000604@fedoraproject.org> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116200333.GE15623@redhat.com> <64b14b300801161219q355d93b0jb57f91f48615591a@mail.gmail.com> <20080116202554.GF15623@redhat.com> <64b14b300801161235i4a4ed432h4f7b81ecefaf292b@mail.gmail.com> <7f692fec0801161717x3b0d77b9n9cd4a2dd939c6398@mail.gmail.com> <478F6C07.2050108@gmail.com> <1200617202.920.156.camel@calliope.phig.org> <47967CA7.3000604@fedoraproject.org> Message-ID: <47968081.5050903@gmail.com> Rahul Sundaram wrote: >> Are you seriously trying to imply that the NSA, of all organizations, >> never backdoors anything? > > They would have to pretty stupid to try to do something like that with > free and open source software. Was that the straight line for a joke? -- Les Mikesell lesmikesell at gmail.com From mclasen at redhat.com Tue Jan 22 23:45:49 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 22 Jan 2008 18:45:49 -0500 Subject: Opinion: Preferred Applications & Removable Drives and Media In-Reply-To: <6e24a8e80801221526y4caac2c5g3522773b5dfb7ca5@mail.gmail.com> References: <6e24a8e80801191428m45ecd472w788c4a88055f0455@mail.gmail.com> <1200785912.2924.14.camel@localhost.localdomain> <6e24a8e80801200641m64febab5v5f1bbc1fa1977e19@mail.gmail.com> <6e24a8e80801221526y4caac2c5g3522773b5dfb7ca5@mail.gmail.com> Message-ID: <1201045549.2858.4.camel@localhost.localdomain> On Wed, 2008-01-23 at 00:26 +0100, Mark wrote: > Oke i installed the nautillus from rawhide now and that's looking > promising! good job so far! > Just one question: how can i change the media autorun behavior? i can > see the settings but am not able to change them [1]. > > [1] http://img120.imageshack.us/img120/6528/screenshotfilemanagemeneu9.png > If you have the latest builds of apps like gthumb, nautilus-cd-burner, etc installed, it should look like this: http://people.redhat.com/mclasen/media-handling.png What does grep x-content /usr/share/applications/* say ? From sundaram at fedoraproject.org Wed Jan 23 00:05:10 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 23 Jan 2008 05:35:10 +0530 Subject: SELinux removed from desktop cd spin? In-Reply-To: <47968081.5050903@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116200333.GE15623@redhat.com> <64b14b300801161219q355d93b0jb57f91f48615591a@mail.gmail.com> <20080116202554.GF15623@redhat.com> <64b14b300801161235i4a4ed432h4f7b81ecefaf292b@mail.gmail.com> <7f692fec0801161717x3b0d77b9n9cd4a2dd939c6398@mail.gmail.com> <478F6C07.2050108@gmail.com> <1200617202.920.156.camel@calliope.phig.org> <47967CA7.3000604@fedoraproject.org> <47968081.5050903@gmail.com> Message-ID: <479684B6.8090405@fedoraproject.org> Les Mikesell wrote: > Rahul Sundaram wrote: > >>> Are you seriously trying to imply that the NSA, of all organizations, >>> never backdoors anything? >> >> They would have to pretty stupid to try to do something like that with >> free and open source software. > > Was that the straight line for a joke? No. Rahul From jspaleta at gmail.com Tue Jan 22 23:58:00 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 22 Jan 2008 14:58:00 -0900 Subject: Belated FUDCon Boston 2007 video postings In-Reply-To: <1201042299.6218.41.camel@cutter> References: <47962BE2.2060905@redhat.com> <47962ED5.2060508@redhat.com> <63300.63.85.68.164.1201025692.squirrel@mail.jcomserv.net> <1201027326.6218.10.camel@cutter> <364d303b0801221448v2bf54e18y28bad2ebcd766d23@mail.gmail.com> <1201042299.6218.41.camel@cutter> Message-ID: <604aa7910801221558w22116b95kf3fb966e74a3beb2@mail.gmail.com> On Jan 22, 2008 1:51 PM, seth vidal wrote: > I asked this this morning - "they are being prepared" was the answer I > got. They needed to be redubbed. Max wanted to sound like Mr. T and Paul wanted to sound like Alvin the chipmunk. Fearless leadership comes at a high price of whimsy. -jef From markg85 at gmail.com Wed Jan 23 00:38:11 2008 From: markg85 at gmail.com (Mark) Date: Wed, 23 Jan 2008 01:38:11 +0100 Subject: Opinion: Preferred Applications & Removable Drives and Media In-Reply-To: <1201045549.2858.4.camel@localhost.localdomain> References: <6e24a8e80801191428m45ecd472w788c4a88055f0455@mail.gmail.com> <1200785912.2924.14.camel@localhost.localdomain> <6e24a8e80801200641m64febab5v5f1bbc1fa1977e19@mail.gmail.com> <6e24a8e80801221526y4caac2c5g3522773b5dfb7ca5@mail.gmail.com> <1201045549.2858.4.camel@localhost.localdomain> Message-ID: <6e24a8e80801221638v11b6a247wd6fc60d5feefb8a7@mail.gmail.com> 2008/1/23, Matthias Clasen : > > On Wed, 2008-01-23 at 00:26 +0100, Mark wrote: > > Oke i installed the nautillus from rawhide now and that's looking > > promising! good job so far! > > Just one question: how can i change the media autorun behavior? i can > > see the settings but am not able to change them [1]. > > > > [1] http://img120.imageshack.us/img120/6528/screenshotfilemanagemeneu9.png > > > > If you have the latest builds of apps like gthumb, nautilus-cd-burner, > etc installed, it should look like this: > > http://people.redhat.com/mclasen/media-handling.png > > What does > > grep x-content /usr/share/applications/* > > say ? That gives me: [mark at localhost nautilus-2.21.5]# grep x-content /usr/share/applications/* /usr/share/applications/gthumb.desktop:MimeType=image/bmp;image/jpeg;image/gif;image/png;image/tiff;image/x-bmp;image/x-ico;image/x-png;image/x-pcx;image/x-tga;image/xpm;image/svg+xml;x-content/image-dcf;x-content/image-picturecd; /usr/share/applications/mimeinfo.cache:x-content/image-dcf=gthumb.desktop /usr/share/applications/mimeinfo.cache:x-content/image-picturecd=gthumb.desktop [mark at localhost nautilus-2.21.5]# But i guess i need to update all media apps in order to get that list fully working ^_^ now only gthumb works. o well.. i rather don't upgrade all media apps to F9 while i'm still running F8.. But thanx for the help. now i know what i have to do. From markg85 at gmail.com Wed Jan 23 00:49:03 2008 From: markg85 at gmail.com (Mark) Date: Wed, 23 Jan 2008 01:49:03 +0100 Subject: Opinion: Preferred Applications & Removable Drives and Media In-Reply-To: <6e24a8e80801221638v11b6a247wd6fc60d5feefb8a7@mail.gmail.com> References: <6e24a8e80801191428m45ecd472w788c4a88055f0455@mail.gmail.com> <1200785912.2924.14.camel@localhost.localdomain> <6e24a8e80801200641m64febab5v5f1bbc1fa1977e19@mail.gmail.com> <6e24a8e80801221526y4caac2c5g3522773b5dfb7ca5@mail.gmail.com> <1201045549.2858.4.camel@localhost.localdomain> <6e24a8e80801221638v11b6a247wd6fc60d5feefb8a7@mail.gmail.com> Message-ID: <6e24a8e80801221649h2602ad0cjcc7a1c9e22ceb24c@mail.gmail.com> > But thanx for the help. now i know what i have to do. Hmm.. just a minor issue. I've just updated totem and now i can choose that a few times in the media list as well (including dvd video) but i don't see a option there to run a command. Isn't it handy to have that option there if none of the other options suit you? Or what else do i have to do to get another application to show up in that list? and is this conforming a standard from freedesktop? if so: which one? That's the only thing i miss Btw. SVG rendering really improved a lot in this nautilus! now my svg's aren't tiny anymore but just the same size as all other icons. Mark. From mclasen at redhat.com Wed Jan 23 00:50:08 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 22 Jan 2008 19:50:08 -0500 Subject: Opinion: Preferred Applications & Removable Drives and Media In-Reply-To: <6e24a8e80801221638v11b6a247wd6fc60d5feefb8a7@mail.gmail.com> References: <6e24a8e80801191428m45ecd472w788c4a88055f0455@mail.gmail.com> <1200785912.2924.14.camel@localhost.localdomain> <6e24a8e80801200641m64febab5v5f1bbc1fa1977e19@mail.gmail.com> <6e24a8e80801221526y4caac2c5g3522773b5dfb7ca5@mail.gmail.com> <1201045549.2858.4.camel@localhost.localdomain> <6e24a8e80801221638v11b6a247wd6fc60d5feefb8a7@mail.gmail.com> Message-ID: <1201049408.2858.8.camel@localhost.localdomain> On Wed, 2008-01-23 at 01:38 +0100, Mark wrote: > > But i guess i need to update all media apps in order to get that list > fully working ^_^ now only gthumb works. o well.. i rather don't > upgrade all media apps to F9 while i'm still running F8.. > > But thanx for the help. now i know what i have to do. > No need to update all apps to try out the new dialog. You can just add the x-content types to the relevant MimeType fields, and run update-desktop-database. I've posted a list of "known" content types to fedora-desktop-list earlier today. From mclasen at redhat.com Wed Jan 23 00:55:17 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 22 Jan 2008 19:55:17 -0500 Subject: Opinion: Preferred Applications & Removable Drives and Media In-Reply-To: <6e24a8e80801221649h2602ad0cjcc7a1c9e22ceb24c@mail.gmail.com> References: <6e24a8e80801191428m45ecd472w788c4a88055f0455@mail.gmail.com> <1200785912.2924.14.camel@localhost.localdomain> <6e24a8e80801200641m64febab5v5f1bbc1fa1977e19@mail.gmail.com> <6e24a8e80801221526y4caac2c5g3522773b5dfb7ca5@mail.gmail.com> <1201045549.2858.4.camel@localhost.localdomain> <6e24a8e80801221638v11b6a247wd6fc60d5feefb8a7@mail.gmail.com> <6e24a8e80801221649h2602ad0cjcc7a1c9e22ceb24c@mail.gmail.com> Message-ID: <1201049717.2858.12.camel@localhost.localdomain> On Wed, 2008-01-23 at 01:49 +0100, Mark wrote: > > But thanx for the help. now i know what i have to do. > > Hmm.. just a minor issue. > I've just updated totem and now i can choose that a few times in the > media list as well (including dvd video) but i don't see a option > there to run a command. Isn't it handy to have that option there if > none of the other options suit you? > > Or what else do i have to do to get another application to show up in that list? > and is this conforming a standard from freedesktop? if so: which one? > > That's the only thing i miss > Entries in which you manually enter commandlines are what we are hoping to leave behind in gnome-volume-manager... If none of the entries suit you, you can create a small desktop file having the command you want to run in the Exec field, and the suitable content type in the MimeType field. From markg85 at gmail.com Wed Jan 23 01:03:45 2008 From: markg85 at gmail.com (Mark) Date: Wed, 23 Jan 2008 02:03:45 +0100 Subject: Opinion: Preferred Applications & Removable Drives and Media In-Reply-To: <1201049717.2858.12.camel@localhost.localdomain> References: <6e24a8e80801191428m45ecd472w788c4a88055f0455@mail.gmail.com> <1200785912.2924.14.camel@localhost.localdomain> <6e24a8e80801200641m64febab5v5f1bbc1fa1977e19@mail.gmail.com> <6e24a8e80801221526y4caac2c5g3522773b5dfb7ca5@mail.gmail.com> <1201045549.2858.4.camel@localhost.localdomain> <6e24a8e80801221638v11b6a247wd6fc60d5feefb8a7@mail.gmail.com> <6e24a8e80801221649h2602ad0cjcc7a1c9e22ceb24c@mail.gmail.com> <1201049717.2858.12.camel@localhost.localdomain> Message-ID: <6e24a8e80801221703g3fae6626w1ec86868d4e60481@mail.gmail.com> 2008/1/23, Matthias Clasen : > > On Wed, 2008-01-23 at 01:49 +0100, Mark wrote: > > > But thanx for the help. now i know what i have to do. > > > > Hmm.. just a minor issue. > > I've just updated totem and now i can choose that a few times in the > > media list as well (including dvd video) but i don't see a option > > there to run a command. Isn't it handy to have that option there if > > none of the other options suit you? > > > > Or what else do i have to do to get another application to show up in that list? > > and is this conforming a standard from freedesktop? if so: which one? > > > > That's the only thing i miss > > > > Entries in which you manually enter commandlines are what we are hoping > to leave behind in gnome-volume-manager... > > If none of the entries suit you, you can create a small desktop file > having the command you want to run in the Exec field, and the suitable > content type in the MimeType field. Seems logical and looks better. and i still wouldn't mind having the option to do just that ^_^ putting it in .desktop files is really something you need to search for before you find out that it needs to be in there. O well.. thanx a lot for the help. All my problems (regarding this issue) are fixed now. From mmcgrath at redhat.com Wed Jan 23 02:15:48 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 22 Jan 2008 20:15:48 -0600 (CST) Subject: Outage Notification - 2008-01-25 02:00 UTC Message-ID: There will be an outage starting at 2008-01-25 02:00 UTC, which will last approximately 6 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2008-01-25 02:00 UTC' Affected Services: Websites (pkgdb, updates) Buildsystem Unaffected Services: CVS / Source Control Database DNS Mail Torrent Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/352 Reason for Outage: We are moving from our current netapp storage (2.4T) to a powervault (10T). The whole buildsystem will be out during this outage. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From lesmikesell at gmail.com Wed Jan 23 02:50:46 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 22 Jan 2008 20:50:46 -0600 Subject: SELinux removed from desktop cd spin? In-Reply-To: <479684B6.8090405@fedoraproject.org> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116200333.GE15623@redhat.com> <64b14b300801161219q355d93b0jb57f91f48615591a@mail.gmail.com> <20080116202554.GF15623@redhat.com> <64b14b300801161235i4a4ed432h4f7b81ecefaf292b@mail.gmail.com> <7f692fec0801161717x3b0d77b9n9cd4a2dd939c6398@mail.gmail.com> <478F6C07.2050108@gmail.com> <1200617202.920.156.camel@calliope.phig.org> <47967CA7.3000604@fedoraproject.org> <47968081.5050903@gmail.com> <479684B6.8090405@fedoraproject.org> Message-ID: <4796AB86.5000107@gmail.com> Rahul Sundaram wrote: >> >>>> Are you seriously trying to imply that the NSA, of all >>>> organizations, never backdoors anything? >>> >>> They would have to pretty stupid to try to do something like that >>> with free and open source software. >> >> Was that the straight line for a joke? > > No. There has to be one somewhere, but the point is that we can't possibly know if they would try something stupid or not - and I usually guess the worst. -- Les Mikesell lesmikesell at gmail.com From stickster at gmail.com Wed Jan 23 03:13:58 2008 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 22 Jan 2008 22:13:58 -0500 Subject: Belated FUDCon Boston 2007 video postings In-Reply-To: <604aa7910801221558w22116b95kf3fb966e74a3beb2@mail.gmail.com> References: <47962BE2.2060905@redhat.com> <47962ED5.2060508@redhat.com> <63300.63.85.68.164.1201025692.squirrel@mail.jcomserv.net> <1201027326.6218.10.camel@cutter> <364d303b0801221448v2bf54e18y28bad2ebcd766d23@mail.gmail.com> <1201042299.6218.41.camel@cutter> <604aa7910801221558w22116b95kf3fb966e74a3beb2@mail.gmail.com> Message-ID: <1201058038.24675.4.camel@localhost.localdomain> On Tue, 2008-01-22 at 14:58 -0900, Jeff Spaleta wrote: > On Jan 22, 2008 1:51 PM, seth vidal wrote: > > I asked this this morning - "they are being prepared" was the answer I > > got. > > They needed to be redubbed. Max wanted to sound like Mr. T and Paul > wanted to sound like Alvin the chipmunk. Fearless leadership comes at > a high price of whimsy. You jest now, but wait till you hear our duet of "You Don't Bring Me Flowers Anymore." -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at dm.cobite.com Wed Jan 23 03:16:51 2008 From: fedora at dm.cobite.com (David Mansfield) Date: Tue, 22 Jan 2008 22:16:51 -0500 Subject: long term support release Message-ID: <1201058211.3001.79.camel@gandalf.cobite.com> I'm fairly new to this list so if this is flame-bait, then I apologize. I was wondering whether there is any possibility of having the occasional 'long term support' (LTS) release of Fedora (say one every two years or something) so that users can settle down with the distro and actually become productive with it. Say the LTS cycle is one release every two years (every fourth Fedora release), and that the 'long term' for support only lasts for two years (which is pretty short to use the term long for, I realize), then there would only be one LTS release, and also the most current release to worry about at any given time. If there is simply not enough teampower to do this, then that's understood. Thanks, David From tcallawa at redhat.com Wed Jan 23 03:19:26 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 22 Jan 2008 22:19:26 -0500 Subject: KSCSOPE Support in Fedora In-Reply-To: <479539A7.4040900@gmail.com> References: <1200955153.3375.0.camel@localhost.localdomain> <479539A7.4040900@gmail.com> Message-ID: <1201058366.3413.10.camel@localhost.localdomain> On Mon, 2008-01-21 at 16:32 -0800, Andrew Farris wrote: > Tom "spot" Callaway wrote: > > On Thu, 2008-01-17 at 20:03 +0530, Kiran Patil wrote: > >> We would like to see it in Fedora as soon as possible. > > > > kscope is in Fedora now. > > > > ~spot > > > > I think what spot meant was in Fedora 'very soon'. :) > > Its been submitted and built by spot, but not in repositories yet, if you've got > a Fedora box and wish to grab it immediately you'll have to get it from the > buildsystem (koji) here: > http://koji.fedoraproject.org/koji/packageinfo?packageID=5639 Hmm. I coulda sworn I saw bodhi push it into the repos. Oh well. :) ~spot From sean.bruno at dsl-only.net Wed Jan 23 03:25:00 2008 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Tue, 22 Jan 2008 19:25:00 -0800 Subject: long term support release In-Reply-To: <1201058211.3001.79.camel@gandalf.cobite.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> Message-ID: <1201058700.3221.21.camel@home-desk> On Tue, 2008-01-22 at 22:16 -0500, David Mansfield wrote: > I'm fairly new to this list so if this is flame-bait, then I apologize. > I was wondering whether there is any possibility of having the > occasional 'long term support' (LTS) release of Fedora (say one every > two years or something) so that users can settle down with the distro > and actually become productive with it. > > Say the LTS cycle is one release every two years (every fourth Fedora > release), and that the 'long term' for support only lasts for two years > (which is pretty short to use the term long for, I realize), then there > would only be one LTS release, and also the most current release to > worry about at any given time. > > To be honest, that's more or less what RHEL and the free rebuild CentOS are. Fedora is a sandbox of sorts. It's a place where applications come together and sometimes, where they come to die. :) Sean From loupgaroublond at gmail.com Wed Jan 23 03:42:02 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Tue, 22 Jan 2008 22:42:02 -0500 Subject: long term support release In-Reply-To: <1201058211.3001.79.camel@gandalf.cobite.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> Message-ID: <7f692fec0801221942x715523cal70423262eb09b4c0@mail.gmail.com> On Jan 22, 2008 10:16 PM, David Mansfield wrote: > I'm fairly new to this list so if this is flame-bait, then I apologize. > I was wondering whether there is any possibility of having the > occasional 'long term support' (LTS) release of Fedora (say one every > two years or something) so that users can settle down with the distro > and actually become productive with it. > > Say the LTS cycle is one release every two years (every fourth Fedora > release), and that the 'long term' for support only lasts for two years > (which is pretty short to use the term long for, I realize), then there > would only be one LTS release, and also the most current release to > worry about at any given time. > > If there is simply not enough teampower to do this, then that's > understood. Just like every other Fedora related project, teampower is always an issue. That alone could shoot down the idea. RHEL and CentOS are certainly there if you do need something more stable, with I think nearly 7 years support per release. I'm not sure how Fedora and its Community would benefit from a direct Fedora LTS release. That "Other Well Known Distro Maker" releases their LTS product with a similar target audience that RHEL and CentOS serves. The people that use Fedora directly enjoy having a rapidly developing distro with the latest features every six months, with just some semblance of crash-proofness. With EPEL, you can even enjoy the variety and quantity of Fedora packages, built for RHEL/CentOS. If you have a slightly different goal in mind, then let's hear it :). If it's reasonable, you might want to consider a SIG (Special Interest Group) of people who are willing to contribute said manpower. There will be a vote on the SIG, so if you have a great idea you want to contribute, that's your best shot to sell it to us. -Yaakov From fedora at dm.cobite.com Wed Jan 23 03:53:27 2008 From: fedora at dm.cobite.com (David Mansfield) Date: Tue, 22 Jan 2008 22:53:27 -0500 Subject: long term support release In-Reply-To: <1201058700.3221.21.camel@home-desk> References: <1201058211.3001.79.camel@gandalf.cobite.com> <1201058700.3221.21.camel@home-desk> Message-ID: <1201060407.3001.91.camel@gandalf.cobite.com> On Tue, 2008-01-22 at 19:25 -0800, Sean Bruno wrote: > On Tue, 2008-01-22 at 22:16 -0500, David Mansfield wrote: > > I'm fairly new to this list so if this is flame-bait, then I apologize. > > I was wondering whether there is any possibility of having the > > occasional 'long term support' (LTS) release of Fedora (say one every > > two years or something) so that users can settle down with the distro > > and actually become productive with it. > > > > Say the LTS cycle is one release every two years (every fourth Fedora > > release), and that the 'long term' for support only lasts for two years > > (which is pretty short to use the term long for, I realize), then there > > would only be one LTS release, and also the most current release to > > worry about at any given time. > > > > > > To be honest, that's more or less what RHEL and the free rebuild CentOS > are. > > Fedora is a sandbox of sorts. It's a place where applications come > together and sometimes, where they come to die. :) > I use RHEL/CentOS extensively at work (versions 3, 4 and 5), and I'd have to disagree about that. Tons of the 'cool' stuff that's in fedora gets left out of RHEL/CentOS. I don't know who decides what 'makes the cut' for RHEL, but it certainly isn't the Fedora team. For example, gnumeric and git, both 'everyday' tools, are missing from CentOS 5, AFAIK, but I'm talking about tons of other goodies. The RHEL package selection process is too restrictive it would seem. And I'm not really complaining about that. I think RHEL hits the target exactly and I don't want it to change, but it's not a real recreational desktop system, never was, never(?) will be. It's a server os and possibly business 'productivity' desktop os. Plus, by having an LTS release, it would encourage the value-add packagers like livna and rpmforge to get on the bandwagon, and 'go long' as well, so it would be possible to have a multimedia enabled system that lasts more than 6 months. David From cjdahlin at ncsu.edu Wed Jan 23 03:55:36 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Tue, 22 Jan 2008 22:55:36 -0500 Subject: long term support release In-Reply-To: <1201060407.3001.91.camel@gandalf.cobite.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <1201058700.3221.21.camel@home-desk> <1201060407.3001.91.camel@gandalf.cobite.com> Message-ID: <4796BAB8.2070800@ncsu.edu> David Mansfield wrote: > On Tue, 2008-01-22 at 19:25 -0800, Sean Bruno wrote: > >> On Tue, 2008-01-22 at 22:16 -0500, David Mansfield wrote: >> >>> I'm fairly new to this list so if this is flame-bait, then I apologize. >>> I was wondering whether there is any possibility of having the >>> occasional 'long term support' (LTS) release of Fedora (say one every >>> two years or something) so that users can settle down with the distro >>> and actually become productive with it. >>> >>> Say the LTS cycle is one release every two years (every fourth Fedora >>> release), and that the 'long term' for support only lasts for two years >>> (which is pretty short to use the term long for, I realize), then there >>> would only be one LTS release, and also the most current release to >>> worry about at any given time. >>> >>> >> To be honest, that's more or less what RHEL and the free rebuild CentOS >> are. >> >> Fedora is a sandbox of sorts. It's a place where applications come >> together and sometimes, where they come to die. :) >> >> > > I use RHEL/CentOS extensively at work (versions 3, 4 and 5), and I'd > have to disagree about that. Tons of the 'cool' stuff that's in fedora > gets left out of RHEL/CentOS. I don't know who decides what 'makes the > cut' for RHEL, but it certainly isn't the Fedora team. > > For example, gnumeric and git, both 'everyday' tools, are missing from > CentOS 5, AFAIK, but I'm talking about tons of other goodies. The RHEL > package selection process is too restrictive it would seem. > > And I'm not really complaining about that. I think RHEL hits the target > exactly and I don't want it to change, but it's not a real recreational > desktop system, never was, never(?) will be. It's a server os and > possibly business 'productivity' desktop os. > > Plus, by having an LTS release, it would encourage the value-add > packagers like livna and rpmforge to get on the bandwagon, and 'go long' > as well, so it would be possible to have a multimedia enabled system > that lasts more than 6 months. > > David > > > Have I got the product for you! http://fedoraproject.org/wiki/EPEL --CJD From mmcgrath at redhat.com Wed Jan 23 03:57:04 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 22 Jan 2008 21:57:04 -0600 (CST) Subject: long term support release In-Reply-To: <1201058211.3001.79.camel@gandalf.cobite.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> Message-ID: On Tue, 22 Jan 2008, David Mansfield wrote: > I'm fairly new to this list so if this is flame-bait, then I apologize. > I was wondering whether there is any possibility of having the > occasional 'long term support' (LTS) release of Fedora (say one every > two years or something) so that users can settle down with the distro > and actually become productive with it. > > Say the LTS cycle is one release every two years (every fourth Fedora > release), and that the 'long term' for support only lasts for two years > (which is pretty short to use the term long for, I realize), then there > would only be one LTS release, and also the most current release to > worry about at any given time. > > If there is simply not enough teampower to do this, then that's > understood. The best way to do this, I think, is similar to what was tried before with Fedora Legacy (google knows what that is). The problem is there weren't enough people to do the work. The long term support work is far more difficult then it initially sounds. Our engineers are more focused on implementing new features, etc. Needless to say there is something to be said for longer support for Fedora, its just a matter of getting the critical mass of people to do it. -Mike From fedora at dm.cobite.com Wed Jan 23 03:59:17 2008 From: fedora at dm.cobite.com (David Mansfield) Date: Tue, 22 Jan 2008 22:59:17 -0500 Subject: long term support release In-Reply-To: <7f692fec0801221942x715523cal70423262eb09b4c0@mail.gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <7f692fec0801221942x715523cal70423262eb09b4c0@mail.gmail.com> Message-ID: <1201060757.3001.96.camel@gandalf.cobite.com> On Tue, 2008-01-22 at 22:42 -0500, Yaakov Nemoy wrote: > On Jan 22, 2008 10:16 PM, David Mansfield wrote: > > I'm fairly new to this list so if this is flame-bait, then I apologize. > > I was wondering whether there is any possibility of having the > > occasional 'long term support' (LTS) release of Fedora (say one every > > two years or something) so that users can settle down with the distro > > and actually become productive with it. > > > > Say the LTS cycle is one release every two years (every fourth Fedora > > release), and that the 'long term' for support only lasts for two years > > (which is pretty short to use the term long for, I realize), then there > > would only be one LTS release, and also the most current release to > > worry about at any given time. > > > > If there is simply not enough teampower to do this, then that's > > understood. > > Just like every other Fedora related project, teampower is always an > issue. That alone could shoot down the idea. RHEL and CentOS are > certainly there if you do need something more stable, with I think > nearly 7 years support per release. I'm not sure how Fedora and its > Community would benefit from a direct Fedora LTS release. That "Other > Well Known Distro Maker" releases their LTS product with a similar > target audience that RHEL and CentOS serves. The people that use You're not suggesting I use the 'Other Well Known Distro' are you? Seriously, though, on my latest laptop I tried CentOS 5, and it was awful on a laptop. Synaptic problems, networkmanager problems, crappy wireless support (out of date) etc. I killed it in about a week. I also tried the Other distro and as a Fedora (and Red Hat Linux before that) guy, it just doesn't do it for me. Old dog, new tricks. It lasted about a month. That said, updating every 6 months doesn't do it for me either. What's a Fedora lover to do? David From skvidal at fedoraproject.org Wed Jan 23 04:00:43 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 22 Jan 2008 23:00:43 -0500 Subject: long term support release In-Reply-To: <1201060407.3001.91.camel@gandalf.cobite.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <1201058700.3221.21.camel@home-desk> <1201060407.3001.91.camel@gandalf.cobite.com> Message-ID: <1201060843.6218.54.camel@cutter> On Tue, 2008-01-22 at 22:53 -0500, David Mansfield wrote: > I use RHEL/CentOS extensively at work (versions 3, 4 and 5), and I'd > have to disagree about that. Tons of the 'cool' stuff that's in fedora > gets left out of RHEL/CentOS. I don't know who decides what 'makes the > cut' for RHEL, but it certainly isn't the Fedora team. RHEL is based on fedora. They have to streamline a bit for support reasons. > > For example, gnumeric and git, both 'everyday' tools, are missing from > CentOS 5, AFAIK, but I'm talking about tons of other goodies. The RHEL > package selection process is too restrictive it would seem. > git is in epel - extras packages for enterprise linux - the repositories are maintained by fedora contributors. -sv From pemboa at gmail.com Wed Jan 23 04:02:25 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 22 Jan 2008 22:02:25 -0600 Subject: long term support release In-Reply-To: <1201058211.3001.79.camel@gandalf.cobite.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> Message-ID: <16de708d0801222002o51b7d771jaa8606128a11f93b@mail.gmail.com> On Jan 22, 2008 9:16 PM, David Mansfield wrote: > I'm fairly new to this list so if this is flame-bait, then I apologize. > I was wondering whether there is any possibility of having the > occasional 'long term support' (LTS) release of Fedora (say one every > two years or something) so that users can settle down with the distro > and actually become productive with it. I'm somewhat curious as to what prevents you from being productive with it? I'm pretty happy with mine. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From airlied at redhat.com Wed Jan 23 04:13:08 2008 From: airlied at redhat.com (Dave Airlie) Date: Wed, 23 Jan 2008 14:13:08 +1000 Subject: long term support release In-Reply-To: <1201060757.3001.96.camel@gandalf.cobite.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <7f692fec0801221942x715523cal70423262eb09b4c0@mail.gmail.com> <1201060757.3001.96.camel@gandalf.cobite.com> Message-ID: <1201061588.3897.1.camel@localhost> On Tue, 2008-01-22 at 22:59 -0500, David Mansfield wrote: > On Tue, 2008-01-22 at 22:42 -0500, Yaakov Nemoy wrote: > > On Jan 22, 2008 10:16 PM, David Mansfield wrote: > > > I'm fairly new to this list so if this is flame-bait, then I apologize. > > > I was wondering whether there is any possibility of having the > > > occasional 'long term support' (LTS) release of Fedora (say one every > > > two years or something) so that users can settle down with the distro > > > and actually become productive with it. > > > > > > Say the LTS cycle is one release every two years (every fourth Fedora > > > release), and that the 'long term' for support only lasts for two years > > > (which is pretty short to use the term long for, I realize), then there > > > would only be one LTS release, and also the most current release to > > > worry about at any given time. > > > > > > If there is simply not enough teampower to do this, then that's > > > understood. > > > > Just like every other Fedora related project, teampower is always an > > issue. That alone could shoot down the idea. RHEL and CentOS are > > certainly there if you do need something more stable, with I think > > nearly 7 years support per release. I'm not sure how Fedora and its > > Community would benefit from a direct Fedora LTS release. That "Other > > Well Known Distro Maker" releases their LTS product with a similar > > target audience that RHEL and CentOS serves. The people that use > > You're not suggesting I use the 'Other Well Known Distro' are you? > Seriously, though, on my latest laptop I tried CentOS 5, and it was > awful on a laptop. Synaptic problems, networkmanager problems, crappy > wireless support (out of date) etc. I killed it in about a week. I > also tried the Other distro and as a Fedora (and Red Hat Linux before > that) guy, it just doesn't do it for me. Old dog, new tricks. It > lasted about a month. That said, updating every 6 months doesn't do it > for me either. What's a Fedora lover to do? But new hardware will always be a problem for older distros, try installing the last Ubuntu LTS on your laptop... when we next do a Fedora/RHEL split which will be RHEL6 all the hw that is supported in Fedora will follow across.. Dave. From loupgaroublond at gmail.com Wed Jan 23 04:18:41 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Tue, 22 Jan 2008 23:18:41 -0500 Subject: long term support release In-Reply-To: <1201060757.3001.96.camel@gandalf.cobite.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <7f692fec0801221942x715523cal70423262eb09b4c0@mail.gmail.com> <1201060757.3001.96.camel@gandalf.cobite.com> Message-ID: <7f692fec0801222018n16e7279cg804162ca52064120@mail.gmail.com> On Jan 22, 2008 10:59 PM, David Mansfield wrote: > > On Tue, 2008-01-22 at 22:42 -0500, Yaakov Nemoy wrote: > > On Jan 22, 2008 10:16 PM, David Mansfield wrote: > > > I'm fairly new to this list so if this is flame-bait, then I apologize. > > > I was wondering whether there is any possibility of having the > > > occasional 'long term support' (LTS) release of Fedora (say one every > > > two years or something) so that users can settle down with the distro > > > and actually become productive with it. > > > > > > Say the LTS cycle is one release every two years (every fourth Fedora > > > release), and that the 'long term' for support only lasts for two years > > > (which is pretty short to use the term long for, I realize), then there > > > would only be one LTS release, and also the most current release to > > > worry about at any given time. > > > > > > If there is simply not enough teampower to do this, then that's > > > understood. > > > > Just like every other Fedora related project, teampower is always an > > issue. That alone could shoot down the idea. RHEL and CentOS are > > certainly there if you do need something more stable, with I think > > nearly 7 years support per release. I'm not sure how Fedora and its > > Community would benefit from a direct Fedora LTS release. That "Other > > Well Known Distro Maker" releases their LTS product with a similar > > target audience that RHEL and CentOS serves. The people that use > > You're not suggesting I use the 'Other Well Known Distro' are you? > Seriously, though, on my latest laptop I tried CentOS 5, and it was > awful on a laptop. Synaptic problems, networkmanager problems, crappy > wireless support (out of date) etc. I killed it in about a week. I > also tried the Other distro and as a Fedora (and Red Hat Linux before > that) guy, it just doesn't do it for me. Old dog, new tricks. It > lasted about a month. That said, updating every 6 months doesn't do it > for me either. What's a Fedora lover to do? Run Fedora of course :P. You won't get the lastest hardware support, or even the relatively best hardware support in RHEL anymore. It gets certified for a bunch of machines that existed back then, as you probably already know, having worked with it before. If you go LTS, you have to make some tradeoffs. One of those tradeoffs is that the hardware compatibility will really suck towards the end of the life cycle. It will seem outdated and quaint, and you might even find yourself longing for all the cool things that Fedora has to offer. ;) You mentioned you wanted a certain stability. You also want certain critical updates for hardware and other fun random things. Thas is a really really really tough goal to achieve. Not even Red Hat is willing to provide that in RHEL. -Yaakov From myfedora at richip.dhs.org Wed Jan 23 04:21:24 2008 From: myfedora at richip.dhs.org (Richi Plana) Date: Tue, 22 Jan 2008 21:21:24 -0700 Subject: long term support release In-Reply-To: <1201058211.3001.79.camel@gandalf.cobite.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> Message-ID: <1201062084.8306.3.camel@localhost6.localdomain6> On Tue, 2008-01-22 at 22:16 -0500, David Mansfield wrote: > Say the LTS cycle is one release every two years (every fourth Fedora > release), and that the 'long term' for support only lasts for two years > (which is pretty short to use the term long for, I realize), then there > would only be one LTS release, and also the most current release to > worry about at any given time. I was about to say that that is exactly what RHEL-to-CentOS is for, but thinking about it, I think I know what your problem is with CentOS. One thing not factored with CentOS is how old it is compared to the version of Fedora that it's supposed to be based upon. If I understand you correctly, your concept of LTS is based on the Final stable release of Fedora and will be supported for two years as opposed to some version of CentOS which upon release is probably years behind the final release of rawhide it was based on and therefore obsolete with hardware (which also has a fast release cycle). (Could someone do the math?) Did I understand your problem correctly? -- Richi Plana From lordmorgul at gmail.com Wed Jan 23 04:24:47 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Tue, 22 Jan 2008 20:24:47 -0800 Subject: long term support release In-Reply-To: <1201058211.3001.79.camel@gandalf.cobite.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> Message-ID: <4796C18F.7070807@gmail.com> David Mansfield wrote: > I'm fairly new to this list so if this is flame-bait, then I apologize. > I was wondering whether there is any possibility of having the > occasional 'long term support' (LTS) release of Fedora (say one every > two years or something) so that users can settle down with the distro > and actually become productive with it. > > Say the LTS cycle is one release every two years (every fourth Fedora > release), and that the 'long term' for support only lasts for two years > (which is pretty short to use the term long for, I realize), then there > would only be one LTS release, and also the most current release to > worry about at any given time. > > If there is simply not enough teampower to do this, then that's > understood. > > Thanks, > David That is essentially what was tried with the fedora legacy project (supporting eol fedora releases for a longer term) but there was not enough interest and support to keep it going. It did support RH9 and FC releases up to FC5 I think? -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From lordmorgul at gmail.com Wed Jan 23 04:25:53 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Tue, 22 Jan 2008 20:25:53 -0800 Subject: KSCSOPE Support in Fedora In-Reply-To: <1201058366.3413.10.camel@localhost.localdomain> References: <1200955153.3375.0.camel@localhost.localdomain> <479539A7.4040900@gmail.com> <1201058366.3413.10.camel@localhost.localdomain> Message-ID: <4796C1D1.6050300@gmail.com> Tom "spot" Callaway wrote: > On Mon, 2008-01-21 at 16:32 -0800, Andrew Farris wrote: >> Tom "spot" Callaway wrote: >>> On Thu, 2008-01-17 at 20:03 +0530, Kiran Patil wrote: >>>> We would like to see it in Fedora as soon as possible. >>> kscope is in Fedora now. >>> >>> ~spot >>> >> I think what spot meant was in Fedora 'very soon'. :) >> >> Its been submitted and built by spot, but not in repositories yet, if you've got >> a Fedora box and wish to grab it immediately you'll have to get it from the >> buildsystem (koji) here: >> http://koji.fedoraproject.org/koji/packageinfo?packageID=5639 > > Hmm. I coulda sworn I saw bodhi push it into the repos. Oh well. :) > > ~spot > You were simply looking into the future. Its a dangerous passtime! -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From sundaram at fedoraproject.org Wed Jan 23 04:41:51 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 23 Jan 2008 10:11:51 +0530 Subject: SELinux removed from desktop cd spin? In-Reply-To: <4796AB86.5000107@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116200333.GE15623@redhat.com> <64b14b300801161219q355d93b0jb57f91f48615591a@mail.gmail.com> <20080116202554.GF15623@redhat.com> <64b14b300801161235i4a4ed432h4f7b81ecefaf292b@mail.gmail.com> <7f692fec0801161717x3b0d77b9n9cd4a2dd939c6398@mail.gmail.com> <478F6C07.2050108@gmail.com> <1200617202.920.156.camel@calliope.phig.org> <47967CA7.3000604@fedoraproject.org> <47968081.5050903@gmail.com> <479684B6.8090405@fedoraproject.org> <4796AB86.5000107@gmail.com> Message-ID: <4796C58F.3070300@fedoraproject.org> Les Mikesell wrote: > Rahul Sundaram wrote: > >>> >>>>> Are you seriously trying to imply that the NSA, of all >>>>> organizations, never backdoors anything? >>>> >>>> They would have to pretty stupid to try to do something like that >>>> with free and open source software. >>> >>> Was that the straight line for a joke? >> >> No. > > There has to be one somewhere, but the point is that we can't possibly > know if they would try something stupid or not - and I usually guess the > worst. It's not merely a question of belief. The long standing best defense against trojan horses are open implementations which PGP or SELinux is. If there is a risk, the risk is definitely higher for proprietary software. Rahul From lesmikesell at gmail.com Wed Jan 23 05:13:59 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 22 Jan 2008 23:13:59 -0600 Subject: SELinux removed from desktop cd spin? In-Reply-To: <4796C58F.3070300@fedoraproject.org> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116200333.GE15623@redhat.com> <64b14b300801161219q355d93b0jb57f91f48615591a@mail.gmail.com> <20080116202554.GF15623@redhat.com> <64b14b300801161235i4a4ed432h4f7b81ecefaf292b@mail.gmail.com> <7f692fec0801161717x3b0d77b9n9cd4a2dd939c6398@mail.gmail.com> <478F6C07.2050108@gmail.com> <1200617202.920.156.camel@calliope.phig.org> <47967CA7.3000604@fedoraproject.org> <47968081.5050903@gmail.com> <479684B6.8090405@fedoraproject.org> <4796AB86.5000107@gmail.com> <4796C58F.3070300@fedoraproject.org> Message-ID: <4796CD17.9010706@gmail.com> Rahul Sundaram wrote: >>>>>> Are you seriously trying to imply that the NSA, of all >>>>>> organizations, never backdoors anything? >>>>> >>>>> They would have to pretty stupid to try to do something like that >>>>> with free and open source software. >>>> >>>> Was that the straight line for a joke? >>> >>> No. >> >> There has to be one somewhere, but the point is that we can't possibly >> know if they would try something stupid or not - and I usually guess >> the worst. > > It's not merely a question of belief. The long standing best defense > against trojan horses are open implementations which PGP or SELinux is. > If there is a risk, the risk is definitely higher for proprietary software. But the NSA would be at least as capable of introducing a hack that you could examine but not see as Ken Thompson: http://www.everything2.com/index.pl?node=Reflections%20On%20Trusting%20Trust I'd expect them to even be able to conspire with the CPU vendors to have certain undocumented opcode sequences do magical things. I don't see any reason to trust proprietary software either. -- Les Mikesell lesmikesell at gmail.com From sundaram at fedoraproject.org Wed Jan 23 05:32:22 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 23 Jan 2008 11:02:22 +0530 Subject: SELinux removed from desktop cd spin? In-Reply-To: <4796CD17.9010706@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116200333.GE15623@redhat.com> <64b14b300801161219q355d93b0jb57f91f48615591a@mail.gmail.com> <20080116202554.GF15623@redhat.com> <64b14b300801161235i4a4ed432h4f7b81ecefaf292b@mail.gmail.com> <7f692fec0801161717x3b0d77b9n9cd4a2dd939c6398@mail.gmail.com> <478F6C07.2050108@gmail.com> <1200617202.920.156.camel@calliope.phig.org> <47967CA7.3000604@fedoraproject.org> <47968081.5050903@gmail.com> <479684B6.8090405@fedoraproject.org> <4796AB86.5000107@gmail.com> <4796C58F.3070300@fedoraproject.org> <4796CD17.9010706@gmail.com> Message-ID: <4796D166.8060908@fedoraproject.org> Les Mikesell wrote: > > But the NSA would be at least as capable of introducing a hack that you > could examine but not see as Ken Thompson: > http://www.everything2.com/index.pl?node=Reflections%20On%20Trusting%20Trust > > I'd expect them to even be able to conspire with the CPU vendors to have > certain undocumented opcode sequences do magical things. Sure. You can believe whatever you want to. I am merely stating a fact that the bar to do this with open source software is way higher than proprietary software and in fact is the highest that anyone can practically go. Rahul From lesmikesell at gmail.com Wed Jan 23 05:26:37 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 22 Jan 2008 23:26:37 -0600 Subject: long term support release In-Reply-To: <1201062084.8306.3.camel@localhost6.localdomain6> References: <1201058211.3001.79.camel@gandalf.cobite.com> <1201062084.8306.3.camel@localhost6.localdomain6> Message-ID: <4796D00D.2020708@gmail.com> Richi Plana wrote: >> Say the LTS cycle is one release every two years (every fourth Fedora >> release), and that the 'long term' for support only lasts for two years >> (which is pretty short to use the term long for, I realize), then there >> would only be one LTS release, and also the most current release to >> worry about at any given time. > > I was about to say that that is exactly what RHEL-to-CentOS is for, but > thinking about it, I think I know what your problem is with CentOS. The problem with CentOS is that updates aren't really updates with new features as you would have in fedora updates. They are security/bugfixes backed into the same old versions. > One thing not factored with CentOS is how old it is compared to the > version of Fedora that it's supposed to be based upon. If I understand > you correctly, your concept of LTS is based on the Final stable release > of Fedora and will be supported for two years as opposed to some version > of CentOS which upon release is probably years behind the final release > of rawhide it was based on and therefore obsolete with hardware (which > also has a fast release cycle). (Could someone do the math?) I'm not sure I understand the hardware issue. If you need to keep something running a long time, you must have already had the system on hardware with working support. What's missing is an option to upgrade apps to versions with current features. I think the best you can do is run the latest version of CentOS, pick the few apps that you really care about and rebuild new versions yourself periodically either from the upstream source or fedora src rpms when possible. -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Wed Jan 23 05:32:43 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 22 Jan 2008 23:32:43 -0600 Subject: long term support release In-Reply-To: <1201060407.3001.91.camel@gandalf.cobite.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <1201058700.3221.21.camel@home-desk> <1201060407.3001.91.camel@gandalf.cobite.com> Message-ID: <4796D17B.2030809@gmail.com> David Mansfield wrote: > For example, gnumeric and git, both 'everyday' tools, are missing from > CentOS 5, AFAIK, but I'm talking about tons of other goodies. The RHEL > package selection process is too restrictive it would seem. There are 3rd party rpm repositories that have pretty much everything you could find for fedora. > And I'm not really complaining about that. I think RHEL hits the target > exactly and I don't want it to change, but it's not a real recreational > desktop system, never was, never(?) will be. What does that mean? Vlc, etc.? Fedora doesn't have that either unless you go to 3rd party repos. -- Les Mikesell lesmikesell at gmail.com From lordmorgul at gmail.com Wed Jan 23 05:57:58 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Tue, 22 Jan 2008 21:57:58 -0800 Subject: long term support release In-Reply-To: <1201060757.3001.96.camel@gandalf.cobite.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <7f692fec0801221942x715523cal70423262eb09b4c0@mail.gmail.com> <1201060757.3001.96.camel@gandalf.cobite.com> Message-ID: <4796D766.8070009@gmail.com> David Mansfield wrote: > You're not suggesting I use the 'Other Well Known Distro' are you? > Seriously, though, on my latest laptop I tried CentOS 5, and it was > awful on a laptop. Synaptic problems, networkmanager problems, crappy > wireless support (out of date) etc. I killed it in about a week. I > also tried the Other distro and as a Fedora (and Red Hat Linux before > that) guy, it just doesn't do it for me. Old dog, new tricks. It > lasted about a month. That said, updating every 6 months doesn't do it > for me either. What's a Fedora lover to do? You could skip every other Fedora release and get a full year between your upgrades, still getting the lastest security patches the whole time. F7 doesn't go to EOL until F9 releases. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From jspaleta at gmail.com Wed Jan 23 05:59:48 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 22 Jan 2008 20:59:48 -0900 Subject: long term support release In-Reply-To: <1201058211.3001.79.camel@gandalf.cobite.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> Message-ID: <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> On Jan 22, 2008 6:16 PM, David Mansfield wrote: > Say the LTS cycle is one release every two years (every fourth Fedora > release), and that the 'long term' for support only lasts for two years > (which is pretty short to use the term long for, I realize), then there > would only be one LTS release, and also the most current release to > worry about at any given time. > > If there is simply not enough teampower to do this, then that's > understood. This has come up a lot recently. it seems the LTS acronym has gained an impressive foothold in the collective psyche. I think its time I put things in perspective for people who are requesting that Fedora as a community project make the investment in this sort of thing. There seems to be a general lack of understanding that the Ubuntu LTS exists ONLY because there is a business entity which is attempting to make money from selling support services around the LTS release. That entity is called Canonical. Canonical has a direct and compelling business interest in selling support services for the Ubuntu LTS release. That LTS offering is NOT a community volunteer coordinated offering. This not so subtle fact is very important to consider when making a request to see a similar offering in the Fedora space. Especially considering that Fedora Legacy was charted to feel this very void. Here's what we learned, demand doesn't match willingness to contribute. And thus, business opportunity is born. Is there room in the Fedora project for an LTS release? I can say with utmost sincerity that yes there is room. As a board member I would very much welcome it to expand the depth of Fedora ecosystem. Making room for this has never been an issue. The real issue is who has a compelling interest in doing the work necessary for it to flourish. The is a harder question, that none of the requests like yours for a Fedora LTS have even thought to ask is this: Where is the business interest that will drive an LTS release in the Fedora ecosystem? So far Red Hat isn't the business entity, they charted a course that doesn't include a Fedora LTS. That is Red Hat's call and if you have a problem with that, I'm pretty sure Red Hat has some sort of sales structure through which you can attempt to convince them to change their sales offerings by madly waving money in front of them while you talk about what you'd like to see them sell you in terms of services. But failing that, If you want an LTS in Fedora space, patterned on the LTS that Canonical is offering then you need to find a business interest willing to support it and make it happen. If you can find an entity who wants to make a serious effort at building a business on a Fedora LTS, point me to them and I'll do my best to bring them in to the Fedora process so they can get a running start on it. I challenge you to find that entity. -jef"branes"spaleta From smooge at gmail.com Wed Jan 23 06:12:22 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 22 Jan 2008 23:12:22 -0700 Subject: long term support release In-Reply-To: <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> Message-ID: <80d7e4090801222212y77462018te92a2b08e130b6fc@mail.gmail.com> On Jan 22, 2008 10:59 PM, Jeff Spaleta wrote: > The is a harder question, that none of the requests like yours for a > Fedora LTS have even thought to ask is this: Where is the business > interest that will drive an LTS release in the Fedora ecosystem? So > far Red Hat isn't the business entity, they charted a course that > doesn't include a Fedora LTS. That is Red Hat's call and if you have > a problem with that, I'm pretty sure Red Hat has some sort of sales > structure through which you can attempt to convince them to change > their sales offerings by madly waving money in front of them while you > talk about what you'd like to see them sell you in terms of services. > > But failing that, If you want an LTS in Fedora space, patterned on the > LTS that Canonical is offering then you need to find a business > interest willing to support it and make it happen. If you can find an > entity who wants to make a serious effort at building a business on a > Fedora LTS, point me to them and I'll do my best to bring them in to > the Fedora process so they can get a running start on it. I challenge > you to find that entity. > > -jef"branes"spaleta > I worked out the numbers for doing that at one time.. and it wasn't pretty... especially when people want all of Fedora to be supported for 2 years. The best price I came to was 2x what Red Hat charges for an RHEL license to cover basic costs.. if a company wanted to actually stay in business it was a lot more... especially when you would need to make sure you had at least 200 paying customers. Cutting down the supported packages basically brought it down to a much smaller segment than what is in RHEL before you could get what most fedora users would consider reasonable (say 50/year). It also makes it hard in that half the customers want the latest stuff compiled for their older OS and the other half want only backports. Brrrrraaaaaiiiinnnnnzzzz -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From jspaleta at gmail.com Wed Jan 23 06:24:54 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 22 Jan 2008 21:24:54 -0900 Subject: long term support release In-Reply-To: <80d7e4090801222212y77462018te92a2b08e130b6fc@mail.gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <80d7e4090801222212y77462018te92a2b08e130b6fc@mail.gmail.com> Message-ID: <604aa7910801222224i31460362qac428b542bdc4ad2@mail.gmail.com> On Jan 22, 2008 9:12 PM, Stephen John Smoogen wrote: > I worked out the numbers for doing that at one time.. and it wasn't > pretty... especially when people want all of Fedora to be supported > for 2 years. The best price I came to was 2x what Red Hat charges for > an RHEL license to cover basic costs.. if a company wanted to actually > stay in business it was a lot more... especially when you would need > to make sure you had at least 200 paying customers. Cutting down the > supported packages basically brought it down to a much smaller segment > than what is in RHEL before you could get what most fedora users would > consider reasonable (say 50/year). There's a lesson here. Did you do the same calculation assuming you incorporated your company on the Isle of Man for tax benefit purposes to see if the numbers became profittable? What if you started off with a multi-million dollar venture capital injection and had 10 years to get to profitability? -jef From marc at mwiriadi.id.au Wed Jan 23 06:59:40 2008 From: marc at mwiriadi.id.au (Marc Wiriadisastra) Date: Wed, 23 Jan 2008 15:59:40 +0900 Subject: preload Message-ID: <1201071580.6050.20.camel@localhost.localdomain> Those people running preload can we get some benchmarks to see whether there is a benefit and if so how much of a benefit there is. I ask this because I got a post on the from Rahul asking whether there was any significant benefit running preload. I personally don't have any numbers so I'm going to try and start to benchmark the information. Those other people running it if you could be so kind to benchmark your system in normal every day applications and email me the results. I'll compile them up on the wiki when I have gathered some. Cheers, Marc From vlada at fedora.org.nz Wed Jan 23 07:05:53 2008 From: vlada at fedora.org.nz (Vladimir N Kosovac) Date: Wed, 23 Jan 2008 20:05:53 +1300 Subject: long term support release In-Reply-To: <604aa7910801222224i31460362qac428b542bdc4ad2@mail.gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <80d7e4090801222212y77462018te92a2b08e130b6fc@mail.gmail.com> <604aa7910801222224i31460362qac428b542bdc4ad2@mail.gmail.com> Message-ID: <1201071954.29624.15.camel@nebula> On Tue, 2008-01-22 at 21:24 -0900, Jeff Spaleta wrote: > On Jan 22, 2008 9:12 PM, Stephen John Smoogen wrote: > > I worked out the numbers for doing that at one time.. and it wasn't > > pretty... especially when people want all of Fedora to be supported > > for 2 years. The best price I came to was 2x what Red Hat charges for > > an RHEL license to cover basic costs.. if a company wanted to actually > > stay in business it was a lot more... especially when you would need > > to make sure you had at least 200 paying customers. Cutting down the > > supported packages basically brought it down to a much smaller segment > > than what is in RHEL before you could get what most fedora users would > > consider reasonable (say 50/year). > > There's a lesson here. Did you do the same calculation assuming you > incorporated your company on the Isle of Man for tax benefit purposes > to see if the numbers became profittable? What if you started off with > a multi-million dollar venture capital injection and had 10 years to > get to profitability? > 'Multi' is a very wild definition when trying to struck a deal with the venture capitalist :o) Other than that any sane person would be really hard pressed to come up with the business model of successful competition against Red Hat, who kind of invented the product we are talking about and employs pretty much everybody (well, maybe not but certainly lot of them) who figures as an authority in this technology space. If it is a matter of building Fedora LTS business in the Desktop market, probably the only real shot at it would have a major PC builder. None of them showed enough guts to break out of MS stranglehold yet but maybe some day they will. Vladimir > -jef > From valent.turkovic at gmail.com Wed Jan 23 07:51:09 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 23 Jan 2008 08:51:09 +0100 Subject: revisor - is this a bug or is it me? In-Reply-To: <20080122153017.6fff9c0a@redhat.com> References: <64b14b300801221039l1f3969cdkc7093876c75e74db@mail.gmail.com> <604aa7910801221106q2b356c36ta9fdd91c305c4bad@mail.gmail.com> <64b14b300801221148q7b06592bu1d64d0dc22362dc2@mail.gmail.com> <47964C56.9060404@fedoraproject.org> <64b14b300801221225sac61bc4o912738c636adb995@mail.gmail.com> <20080122153017.6fff9c0a@redhat.com> Message-ID: <64b14b300801222351j46ffb5d5o5de0da863613aced@mail.gmail.com> 2008/1/22 Jesse Keating : > On Tue, 22 Jan 2008 21:25:57 +0100 > "Valent Turkovic" wrote: > > > Oh, thank you, I wasn't aware of that. > > > > I thought since I'm using a really loudly advertised fedora feature, > > and config files which all of them are provided from fedora and not > > some 3rd party that this is the correct list. > > You are aware that the vast majority of software in Fedora is developed > and discussed at their respective upstream locations, right? > > -- > Jesse Keating > Fedora -- All my bits are free, are yours? I am aware of that for stuff like gnome, but I thought that fedora is the upstream for revisor, sorry my mistake. Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From valent.turkovic at gmail.com Wed Jan 23 07:51:55 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 23 Jan 2008 08:51:55 +0100 Subject: revisor - is this a bug or is it me? In-Reply-To: <604aa7910801221223p63da1654nb698a7d41b964eb5@mail.gmail.com> References: <64b14b300801221039l1f3969cdkc7093876c75e74db@mail.gmail.com> <604aa7910801221106q2b356c36ta9fdd91c305c4bad@mail.gmail.com> <64b14b300801221148q7b06592bu1d64d0dc22362dc2@mail.gmail.com> <604aa7910801221223p63da1654nb698a7d41b964eb5@mail.gmail.com> Message-ID: <64b14b300801222351s5c4218d4he2d16d8e467e7c42@mail.gmail.com> On Jan 22, 2008 9:23 PM, Jeff Spaleta wrote: > On Jan 22, 2008 10:48 AM, Valent Turkovic wrote: > > Ok, for usage I will go to them, but what about the bugs I reported > > about? Fedora unity people aren't developing revisor AFAIK, or are > > they? > Here's where we talk about what it means to be a Fedora developer, > versus just a developer. > > In actually, very little is developed as part of fedora directly. > There are multiple pieces of technology where fedora contributors are > also significant upstream developers, but for most packages > fedora!=upstream. Even when the project source code is hosted at > hosted.fedoraproject.org, its still not necessarily appropriate to > think of that project as a 'Fedora' > > At the most naive level, it might be best to think of people building > pieces of Fedora infrastructure as Fedora developers, and you'd mostly > be right, since the infrastructure that Fedora project uses is in > large part motivated by internal project needs. But other people do > use those bits so they do have some upstream context that isn't > completely defined by Fedora. > > Outside of that it gets much harder to define when someone is Fedora > developer specifically. Some examples.... > > The kernel is important to Fedora, but are the Fedora contributors > Fedora developers...or are they kernel developers? I'd like to think > of them as kernel developers who contribute to Fedora.. because in all > the ways that matter they are driving important enhancements into the > kernel base, so that all linux kernel users potentially benefit. > Fedora as a project helps them do that more effectively by being an > easy way for user to get access to kernel builds as part of an > integrated whole. Can Fedora as a project change to be even an even > more effective conduit to connect kernel developers and users... > yes..now and forever. > > The gnome desktop is important to Fedora, but are the gnome desktop > contributors Fedora developers... or are the gnome developers? I'd > like to think of them as gnome desktop developers who contribute to > Fedora.. because in all the ways that matter they are driving > important enhancements into the gnome codebase so that all gnome users > potentially benefit. Fedora as a project helps them do that more > effectively by being an easy way for user to get access to gnome > builds as part of an integrated whole. Can Fedora as a project change > to be even an even more effective conduit to connect gnome developers > and users... yes..now and forever. > > Similarly, revisor is its own upstream project with its own > developers. We as a project are lucky enough to count some if not all > of the developers of the tool as Fedora contributors. And hopefully > the revisor developers see Fedora as a project an effective conduit to > get users, using their bits. Can Fedora as a project change to be > even an even more effective conduit to connect revisor developers and > users... yes..now and forever. > > -jef"Holy crap its above freezing here! I love global warming!"spaleta Thanks Jeff for great reply! Valent -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From ml at deadbabylon.de Wed Jan 23 08:56:50 2008 From: ml at deadbabylon.de (Sebastian Vahl) Date: Wed, 23 Jan 2008 09:56:50 +0100 Subject: KDE-SIG weekly report (04/2008) Message-ID: <200801230956.55932.ml@deadbabylon.de> This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply ?to this email or add it to the related meeting page. ---------------------------------------------------------------------------------- = Weekly KDE Summary = Week: 04/2008 Time: 2008-01-22 16:00 UTC Meeting page: http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-01-22 Meeting log: http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-01-22?action=AttachFile&do=get&target=fedora-kde-sig-2008-01-22.txt ---------------------------------------------------------------------------------- = Participants = - KevinKofler - LukasTinkl - RexDieter - SebastianVahl ---------------------------------------------------------------------------------- = Agenda = * topics to discuss: - Preparing for Fedora 9 Alpha - Upgrade path to KDE-4.0.0 (experiences from kde-redhat) - Compiz and KWin decorations (Compiz still uses old KWin 3 decorations) - Dropping compiz-kde support entirely? [1] - comps-f9.xml * recent bugs: - 428212: unable to mount partitions in dolphin (Update) [2] - 378041: unable to mount removable/ntfs (Update) [3] = Summary = o Preparing for Fedora 9 Alpha: - rawhide is now frozen and kde should be ready for Fedora 9 Alpha o Upgrade path to KDE-4.0.0 (experiences from kde-redhat): - kdebase-workspace should be installed automatically during an upgrade (either in @kde-desktop or with Obsoletes: kdebase < 4) - Some upgraders seems to have problems with kdelibs/kdelibs4 -> kdelibs3/kdelibs o Compiz and KWin decorations (Compiz still uses old KWin 3 decorations): - Release Notes for kwin-4.0.0: http://techbase.kde.org/Projects/KWin/4.0-release-notes#Why_not_Compiz.3F - Compiz' kde-window-decorator is using KWin 3 API and libkdecoration will be removed from kdebase3 soon - kde-desktop-effects should either be removed or reworked to also include kwin's desktop effects and compiz (with emerald) o comps-f9.xml: - Packages that are obsolete now: d3lphin, kdeaddons, marble, ksudoku - Missing packages: extragear-plasma, kaider, okteta, kdegames3, kdeaddons-atlantikdesigner o Open discussion: - Kubuntu is workarounding #378041 and #428212 for KDE3 with hacks. - These patches needs to be ported to KDE4. But there is enough time until F9 to allow some time for hal to get fixed - LukasTinkl mentioned that upstream KDE would probably never support PolicyKit - knetworkmanager-0.7 branch (for NetworkManager-0.7) isn't compiling yet ---------------------------------------------------------------------------------- = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-01-29 ---------------------------------------------------------------------------------- = Links = [1] http://techbase.kde.org/Projects/KWin/4.0-release-notes#Why_not_Compiz.3F [2] https://bugzilla.redhat.com/show_bug.cgi?id=428212 [3] https://bugzilla.redhat.com/show_bug.cgi?id=378041 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From mjs at CLEMSON.EDU Wed Jan 23 09:45:56 2008 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Wed, 23 Jan 2008 09:45:56 +0000 Subject: SELinux removed from desktop cd spin? In-Reply-To: <4796D166.8060908@fedoraproject.org> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116200333.GE15623@redhat.com> <64b14b300801161219q355d93b0jb57f91f48615591a@mail.gmail.com> <20080116202554.GF15623@redhat.com> <64b14b300801161235i4a4ed432h4f7b81ecefaf292b@mail.gmail.com> <7f692fec0801161717x3b0d77b9n9cd4a2dd939c6398@mail.gmail.com> <478F6C07.2050108@gmail.com> <1200617202.920.156.camel@calliope.phig.org> <47967CA7.3000604@fedoraproject.org> <47968081.5050903@gmail.com> <479684B6.8090405@fedoraproject.org> <4796AB86.5000107@gmail.com> <4796C58F.3070300@fedoraproject.org> <4796CD17.9010706@gmail.com> <4796D166.8060908@fedoraproject.org> Message-ID: <1201081556.17926.30.camel@vincent52.localdomain> On Wed, 2008-01-23 at 11:02 +0530, Rahul Sundaram wrote: > Les Mikesell wrote: > > > > But the NSA would be at least as capable of introducing a hack that you > > could examine but not see as Ken Thompson: > > http://www.everything2.com/index.pl?node=Reflections%20On%20Trusting%20Trust > > > > I'd expect them to even be able to conspire with the CPU vendors to have > > certain undocumented opcode sequences do magical things. > > Sure. You can believe whatever you want to. I am merely stating a fact > that the bar to do this with open source software is way higher than > proprietary software and in fact is the highest that anyone can > practically go. Also, in order to carry out a hack like that, you have to infect the toolchain somewhere along the line, so that everyone building the code is doing so with infected compilers.. With open-source code and an open-source toolchain, that seems pretty unlikely. Or are you suggesting, Les, that everyone's copy of gcc is derived from one built by the NSA and smuggled into RMS's lab at some point in its early history? > > Rahul > > -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From triad at df.lth.se Wed Jan 23 09:48:35 2008 From: triad at df.lth.se (Linus Walleij) Date: Wed, 23 Jan 2008 10:48:35 +0100 (CET) Subject: preload In-Reply-To: <1201071580.6050.20.camel@localhost.localdomain> References: <1201071580.6050.20.camel@localhost.localdomain> Message-ID: On Wed, 23 Jan 2008, Marc Wiriadisastra wrote: > Those people running preload can we get some benchmarks to see whether > there is a benefit and if so how much of a benefit there is. How? I only you know, just run it. I notice launch speedups for my commonly used apps, but I have no idea how to benchmark that in hard figures. Linus From che666 at gmail.com Wed Jan 23 10:08:59 2008 From: che666 at gmail.com (Rudolf Kastl) Date: Wed, 23 Jan 2008 11:08:59 +0100 Subject: preload In-Reply-To: References: <1201071580.6050.20.camel@localhost.localdomain> Message-ID: On Jan 23, 2008 10:48 AM, Linus Walleij wrote: > On Wed, 23 Jan 2008, Marc Wiriadisastra wrote: > > > Those people running preload can we get some benchmarks to see whether > > there is a benefit and if so how much of a benefit there is. > > How? I only you know, just run it. I notice launch speedups for my > commonly used apps, but I have no idea how to benchmark that in hard > figures. > > Linus try the time command: time ;) > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From lordmorgul at gmail.com Wed Jan 23 10:12:50 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 23 Jan 2008 02:12:50 -0800 Subject: preload In-Reply-To: References: <1201071580.6050.20.camel@localhost.localdomain> Message-ID: <47971322.8000009@gmail.com> Linus Walleij wrote: > On Wed, 23 Jan 2008, Marc Wiriadisastra wrote: > >> Those people running preload can we get some benchmarks to see whether >> there is a benefit and if so how much of a benefit there is. > > How? I only you know, just run it. I notice launch speedups for my > commonly used apps, but I have no idea how to benchmark that in hard > figures. > > Linus I would imagine just installing bootchart and getting the result with and without preload for whatever typical services setup you use on that machine? -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From marc at mwiriadi.id.au Wed Jan 23 10:38:09 2008 From: marc at mwiriadi.id.au (Marc Wiriadisastra) Date: Wed, 23 Jan 2008 19:38:09 +0900 Subject: preload In-Reply-To: <47971322.8000009@gmail.com> References: <1201071580.6050.20.camel@localhost.localdomain> <47971322.8000009@gmail.com> Message-ID: <1201084689.5542.6.camel@localhost.localdomain> On Wed, 2008-01-23 at 02:12 -0800, Andrew Farris wrote: > Linus Walleij wrote: > > On Wed, 23 Jan 2008, Marc Wiriadisastra wrote: > > > >> Those people running preload can we get some benchmarks to see whether > >> there is a benefit and if so how much of a benefit there is. > > > > How? I only you know, just run it. I notice launch speedups for my > > commonly used apps, but I have no idea how to benchmark that in hard > > figures. > > > > Linus > > I would imagine just installing bootchart and getting the result with and > without preload for whatever typical services setup you use on that machine? Bootchart doesn't work it actually slows down the boot up because it's preloading stuff. Loading stuff up using time doesn't work either. That's why I'm asking as well. The benefit of preload is actually in loading apps not in startup since it is spending it's time loading things. Cheers, Marc From buc at odusz.so-cdu.ru Wed Jan 23 11:48:16 2008 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Wed, 23 Jan 2008 14:48:16 +0300 Subject: long term support release In-Reply-To: <1201058211.3001.79.camel@gandalf.cobite.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> Message-ID: <47972980.7000804@odu.neva.ru> David Mansfield wrote: > I'm fairly new to this list so if this is flame-bait, then I apologize. > I was wondering whether there is any possibility of having the > occasional 'long term support' (LTS) release of Fedora (say one every > two years or something) so that users can settle down with the distro > and actually become productive with it. > Well, I actually use Fedora in a strong production environment (power control office). The current policy (the EOL of F is one month after the F) provides me one year LTS (assuming the release is per half-year). Thus I just skip one release, i.e. FC1-->FC3-->FC5-->F7 . One-year LTS is an acceptable compromise for me. But ideally, from the "production" point of view, I would prefer 9-month cycle (and hence 1.5year LTS) ... Dmitry Butskoy http://www.fedoraproject.org/wiki/DmitryButskoy From rc040203 at freenet.de Mon Jan 21 07:36:37 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 21 Jan 2008 08:36:37 +0100 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <604aa7910801192136u754e6a4ex1c3c0113440c4e02@mail.gmail.com> References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> <1200766980.2961.8.camel@sb-home> <604aa7910801192136u754e6a4ex1c3c0113440c4e02@mail.gmail.com> Message-ID: <1200900997.2845.12.camel@beck.corsepiu.local> On Sat, 2008-01-19 at 20:36 -0900, Jeff Spaleta wrote: > On Jan 19, 2008 9:23 AM, nodata wrote: > > I'm talking about closing the bug and telling the reporter to report > > upstream, i.e. "go away". > > > As a package maintainer, what would you like me to do in situations > where I need the reporter to talk to upstream? A reporter should never be supposed to talk upstream, because he is reporting an issue a problem with the product (your package) you are supposed to be responsible for, not against the product an upstream ships to you (the source tarball). > Should I just pat you > on the head and promise to fix it, even though I can't? What prevents you from simply telling the truth? > If I can't > even reproduce the problem with my hardware, or its a feature request > that needs to be discussed as part of an upstream development what > exactly are the better choices than encouraging you to take your case > to upstream? Communicate such issues upstream and provide upstream a link to the original issue, such they can investigate? Ralf From billcrawford1970 at gmail.com Wed Jan 23 12:24:32 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 23 Jan 2008 12:24:32 +0000 Subject: Replacing the boot kernel in the installer Message-ID: <544eb990801230424q79f27bek99ccd6905c645f6@mail.gmail.com> I successfully installed F8 at home, but I've been unable to get the installer to run on my Aspire here at work. It fails due a problem with the sata_sis driver, which is fixed in the latest F7 kernel update so I assume the current F8 kernel is fine too. Is it possible to simply boot from a different kernel (and update the modules in the initrd, of course) and run the installer? Or, if I need to update the stage 2 image as well, how do I point at the updated stage 2, and can I do so while still proceeding to fetch the install packages off the network? From jwboyer at gmail.com Wed Jan 23 12:39:32 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 23 Jan 2008 06:39:32 -0600 Subject: Replacing the boot kernel in the installer In-Reply-To: <544eb990801230424q79f27bek99ccd6905c645f6@mail.gmail.com> References: <544eb990801230424q79f27bek99ccd6905c645f6@mail.gmail.com> Message-ID: <20080123063932.32f77328@zod.rchland.ibm.com> On Wed, 23 Jan 2008 12:24:32 +0000 "Bill Crawford" wrote: > I successfully installed F8 at home, but I've been unable to get the > installer to run on my Aspire here at work. It fails due a problem > with the sata_sis driver, which is fixed in the latest F7 kernel > update so I assume the current F8 kernel is fine too. Is it possible > to simply boot from a different kernel (and update the modules in the > initrd, of course) and run the installer? Or, if I need to update the > stage 2 image as well, how do I point at the updated stage 2, and can > I do so while still proceeding to fetch the install packages off the > network? You could just try the Fedora Unity respins. josh From billcrawford1970 at gmail.com Wed Jan 23 12:46:08 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 23 Jan 2008 12:46:08 +0000 Subject: Replacing the boot kernel in the installer In-Reply-To: <20080123063932.32f77328@zod.rchland.ibm.com> References: <544eb990801230424q79f27bek99ccd6905c645f6@mail.gmail.com> <20080123063932.32f77328@zod.rchland.ibm.com> Message-ID: <544eb990801230446h7c83b021me8db4c6e82171991@mail.gmail.com> Sure, I was just looking for a way to avoid downloading a DVD iso ... On 23/01/2008, Josh Boyer wrote: > On Wed, 23 Jan 2008 12:24:32 +0000 > "Bill Crawford" wrote: > > > I successfully installed F8 at home, but I've been unable to get the > > installer to run on my Aspire here at work. It fails due a problem > > with the sata_sis driver, which is fixed in the latest F7 kernel > > update so I assume the current F8 kernel is fine too. Is it possible > > to simply boot from a different kernel (and update the modules in the > > initrd, of course) and run the installer? Or, if I need to update the > > stage 2 image as well, how do I point at the updated stage 2, and can > > I do so while still proceeding to fetch the install packages off the > > network? > > You could just try the Fedora Unity respins. > > josh > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From triad at df.lth.se Wed Jan 23 12:48:50 2008 From: triad at df.lth.se (Linus Walleij) Date: Wed, 23 Jan 2008 13:48:50 +0100 (CET) Subject: preload In-Reply-To: References: <1201071580.6050.20.camel@localhost.localdomain> Message-ID: On Wed, 23 Jan 2008, Rudolf Kastl wrote: > try the time command: > time ;) Load time is something time does not measure AFAIK. Linus From lordmorgul at gmail.com Wed Jan 23 12:54:13 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 23 Jan 2008 04:54:13 -0800 Subject: Replacing the boot kernel in the installer In-Reply-To: <544eb990801230424q79f27bek99ccd6905c645f6@mail.gmail.com> References: <544eb990801230424q79f27bek99ccd6905c645f6@mail.gmail.com> Message-ID: <479738F5.6060001@gmail.com> Bill Crawford wrote: > I successfully installed F8 at home, but I've been unable to get the > installer to run on my Aspire here at work. It fails due a problem > with the sata_sis driver, which is fixed in the latest F7 kernel > update so I assume the current F8 kernel is fine too. Is it possible > to simply boot from a different kernel (and update the modules in the > initrd, of course) and run the installer? Or, if I need to update the > stage 2 image as well, how do I point at the updated stage 2, and can > I do so while still proceeding to fetch the install packages off the > network? > I've never tried, but I suppose it might be possible to boot a F9 devel boot.iso, and try a network install, but point it at an F8 repo to fetch the stage2.img and packages. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From lkundrak at redhat.com Wed Jan 23 13:04:58 2008 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Wed, 23 Jan 2008 14:04:58 +0100 Subject: Replacing the boot kernel in the installer In-Reply-To: <479738F5.6060001@gmail.com> References: <544eb990801230424q79f27bek99ccd6905c645f6@mail.gmail.com> <479738F5.6060001@gmail.com> Message-ID: <1201093498.7153.49.camel@localhost.localdomain> On Wed, 2008-01-23 at 04:54 -0800, Andrew Farris wrote: > Bill Crawford wrote: > > I successfully installed F8 at home, but I've been unable to get the > > installer to run on my Aspire here at work. It fails due a problem > > with the sata_sis driver, which is fixed in the latest F7 kernel > > update so I assume the current F8 kernel is fine too. Is it possible > > to simply boot from a different kernel (and update the modules in the > > initrd, of course) and run the installer? Or, if I need to update the > > stage 2 image as well, how do I point at the updated stage 2, and can > > I do so while still proceeding to fetch the install packages off the > > network? > > > > I've never tried, but I suppose it might be possible to boot a F9 devel > boot.iso, and try a network install, but point it at an F8 repo to fetch the > stage2.img and packages. As far as I know, installer will complain that he stage2.img doesn't match the currently booted version. -- Lubomir Kundrak (Red Hat Security Response Team) From billcrawford1970 at gmail.com Wed Jan 23 13:06:04 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 23 Jan 2008 13:06:04 +0000 Subject: Replacing the boot kernel in the installer In-Reply-To: <479738F5.6060001@gmail.com> References: <544eb990801230424q79f27bek99ccd6905c645f6@mail.gmail.com> <479738F5.6060001@gmail.com> Message-ID: <544eb990801230506o731b716r33d7436b9edfb646@mail.gmail.com> On 23/01/2008, Andrew Farris wrote: > I've never tried, but I suppose it might be possible to boot a F9 devel > boot.iso, and try a network install, but point it at an F8 repo to fetch the > stage2.img and packages. That's the sort of thing I had in mind. Anyone tried this? From lkundrak at redhat.com Wed Jan 23 13:07:11 2008 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Wed, 23 Jan 2008 14:07:11 +0100 Subject: Replacing the boot kernel in the installer In-Reply-To: <544eb990801230446h7c83b021me8db4c6e82171991@mail.gmail.com> References: <544eb990801230424q79f27bek99ccd6905c645f6@mail.gmail.com> <20080123063932.32f77328@zod.rchland.ibm.com> <544eb990801230446h7c83b021me8db4c6e82171991@mail.gmail.com> Message-ID: <1201093632.7153.52.camel@localhost.localdomain> On Wed, 2008-01-23 at 12:46 +0000, Bill Crawford wrote: > Sure, I was just looking for a way to avoid downloading a DVD iso ... I thought Fedora Unity provides jigdo templates, at last it used to. You can use packages from your existing Fedora DVD then, and just let jigdo download the updated packages. > On 23/01/2008, Josh Boyer wrote: > > On Wed, 23 Jan 2008 12:24:32 +0000 > > "Bill Crawford" wrote: > > > > > I successfully installed F8 at home, but I've been unable to get the > > > installer to run on my Aspire here at work. It fails due a problem > > > with the sata_sis driver, which is fixed in the latest F7 kernel > > > update so I assume the current F8 kernel is fine too. Is it possible > > > to simply boot from a different kernel (and update the modules in the > > > initrd, of course) and run the installer? Or, if I need to update the > > > stage 2 image as well, how do I point at the updated stage 2, and can > > > I do so while still proceeding to fetch the install packages off the > > > network? > > > > You could just try the Fedora Unity respins. > > > > josh > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > -- Lubomir Kundrak (Red Hat Security Response Team) From billcrawford1970 at gmail.com Wed Jan 23 13:06:38 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 23 Jan 2008 13:06:38 +0000 Subject: Replacing the boot kernel in the installer In-Reply-To: <1201093498.7153.49.camel@localhost.localdomain> References: <544eb990801230424q79f27bek99ccd6905c645f6@mail.gmail.com> <479738F5.6060001@gmail.com> <1201093498.7153.49.camel@localhost.localdomain> Message-ID: <544eb990801230506o1f908f1cq958cfdf9073984b0@mail.gmail.com> On 23/01/2008, Lubomir Kundrak wrote: > As far as I know, installer will complain that he stage2.img doesn't > match the currently booted version. Ah. mm. ok. any way around this? What does it check for? .buildstamp? From markg85 at gmail.com Wed Jan 23 13:07:55 2008 From: markg85 at gmail.com (Mark) Date: Wed, 23 Jan 2008 14:07:55 +0100 Subject: preload In-Reply-To: References: <1201071580.6050.20.camel@localhost.localdomain> Message-ID: <6e24a8e80801230507n3a176c40rf5f3b0a5c18a9bb1@mail.gmail.com> 2008/1/23, Linus Walleij : > On Wed, 23 Jan 2008, Rudolf Kastl wrote: > > > try the time command: > > time ;) > > Load time is something time does not measure AFAIK. > > Linus With the time command you can measure the time it takes an ap to start. When preload is installed that time should be lower. But note that if you need to do a benchmark you will have to do a time when the app first starts (like first firefox start after a reboot) and than perhaps a second bench when it was already opened.. that all compared with and without preload. I'm gonna do some benching now. From dgboles at gmail.com Wed Jan 23 13:07:20 2008 From: dgboles at gmail.com (David Boles) Date: Wed, 23 Jan 2008 08:07:20 -0500 Subject: Replacing the boot kernel in the installer In-Reply-To: <544eb990801230446h7c83b021me8db4c6e82171991@mail.gmail.com> References: <544eb990801230424q79f27bek99ccd6905c645f6@mail.gmail.com> <20080123063932.32f77328@zod.rchland.ibm.com> <544eb990801230446h7c83b021me8db4c6e82171991@mail.gmail.com> Message-ID: <47973C08.2090807@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bill Crawford wrote: | Sure, I was just looking for a way to avoid downloading a DVD iso ... You don't have to. The Fedora Unity respins are jigdo. They take the packages from your original Fedora 8 DVD that have not changed, download the updates, and then makes you a new iso with those combined. Then you burn your new DVD. You only download the updates. Which you would have to do after the install anyway. - -- ~ David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) iEYEARECAAYFAkeXPAgACgkQAO0wNI1X4QE8bQCffmftvorVSWqtPAmE/nio0Ggp KrsAoMCp2vU40kMi/izqXwRg3mZhqEPS =RLpj -----END PGP SIGNATURE----- From jkeating at redhat.com Wed Jan 23 13:10:09 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 23 Jan 2008 08:10:09 -0500 Subject: Replacing the boot kernel in the installer In-Reply-To: <544eb990801230506o1f908f1cq958cfdf9073984b0@mail.gmail.com> References: <544eb990801230424q79f27bek99ccd6905c645f6@mail.gmail.com> <479738F5.6060001@gmail.com> <1201093498.7153.49.camel@localhost.localdomain> <544eb990801230506o1f908f1cq958cfdf9073984b0@mail.gmail.com> Message-ID: <20080123081009.50b11fc3@redhat.com> On Wed, 23 Jan 2008 13:06:38 +0000 "Bill Crawford" wrote: > Ah. mm. ok. any way around this? What does it check for? .buildstamp? The best way around it is to use rescue.iso instead. Since rescue.iso has stage2 on it, you can point it at any repo to do the install, like your original F8 repo. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lkundrak at redhat.com Wed Jan 23 13:13:12 2008 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Wed, 23 Jan 2008 14:13:12 +0100 Subject: Replacing the boot kernel in the installer In-Reply-To: <544eb990801230506o1f908f1cq958cfdf9073984b0@mail.gmail.com> References: <544eb990801230424q79f27bek99ccd6905c645f6@mail.gmail.com> <479738F5.6060001@gmail.com> <1201093498.7153.49.camel@localhost.localdomain> <544eb990801230506o1f908f1cq958cfdf9073984b0@mail.gmail.com> Message-ID: <1201093992.7153.57.camel@localhost.localdomain> On Wed, 2008-01-23 at 13:06 +0000, Bill Crawford wrote: > On 23/01/2008, Lubomir Kundrak wrote: > > > As far as I know, installer will complain that he stage2.img doesn't > > match the currently booted version. > > Ah. mm. ok. any way around this? What does it check for? .buildstamp? I do not know why was it so, but I assumed there was a good reason for it. If you don't want to use fedora unity respins, I'd suggest booting off rawhide live, if you have it handy, and install by hand. There's little work you have to do then, apart from yum --installroot installgroup; probably just adjusting /etc/fstab, and setting up shadow passwords, probably using authconfig. -- Lubomir Kundrak (Red Hat Security Response Team) From ljuwaida at fedoraproject.org Wed Jan 23 13:15:50 2008 From: ljuwaida at fedoraproject.org (Laith Juwaidah) Date: Wed, 23 Jan 2008 17:15:50 +0400 Subject: long term support release In-Reply-To: <1201058211.3001.79.camel@gandalf.cobite.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> Message-ID: On Jan 23, 2008 7:16 AM, David Mansfield wrote: > I'm fairly new to this list so if this is flame-bait, then I apologize. > I was wondering whether there is any possibility of having the > occasional 'long term support' (LTS) release of Fedora (say one every > two years or something) so that users can settle down with the distro > and actually become productive with it. > > Say the LTS cycle is one release every two years (every fourth Fedora > release), and that the 'long term' for support only lasts for two years > (which is pretty short to use the term long for, I realize), then there > would only be one LTS release, and also the most current release to > worry about at any given time. > > If there is simply not enough teampower to do this, then that's > understood. > > Thanks, > David > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > IMVHO: The word Enterprise in RHEL makes it less appealing for home users, I wouldn't use it, for no reason other than it has the word Enterprise in it... To be fair, my first distro was SLED. Why do we have to look for other business partners when we have RH? RH could release a "filtered" version of Fedora and call it RHHL (Red Hat Home Linux). By filtered here I mean carefully selected versions of the packages, for example, though KDE 4.0.0 is released, RHHL should ship with KDE 3.5.8instead since it is still not complete, in other words, it doesn't have to be so cutting edge, yet, not so outdated. For the support, they can hire people to do that, these people can try to fix users' problems themselves, ask the package maintainers, or simply report bugs... Finance wise, the license should be much cheaper, since it is targeted at home users and not enterprises. I just want to say that I wouldn't use that, simply because I don't really care if I have support or not, I can fix my system from the command prompt, but normal users don't want to learn the "geeky stuff". That is one reason why many of the people don't want to even give Linux a shot: What if I have a problem? Who will help me with it? When I say the community does, I usually get an answer like "It's not always available", "What if they can't help me?", "What if I don't get any answer? They don't have to help me anyways", or simply "If my computer is broken I can't use it to access IRC" :-| That's all I have to say -- Laith Juwaidah http://www.ljuwaidah.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From skasal at redhat.com Thu Jan 24 13:14:53 2008 From: skasal at redhat.com (Stepan Kasal) Date: Thu, 24 Jan 2008 14:14:53 +0100 Subject: preload In-Reply-To: References: <1201071580.6050.20.camel@localhost.localdomain> Message-ID: <20080124131453.GA31330@camelia.ucw.cz> Hello, On Wed, Jan 23, 2008 at 01:48:50PM +0100, Linus Walleij wrote: > Load time is something time does not measure AFAIK. time can measure real wall time. If it is supposed that the user will actually _notice_ (and appreciate) the difference, then it should really be measurable as a difference in real time. So script the application to exit as soon as it starts and then do the measurement. (After a reboot, of course.) For application which cannot be scripted to exit, use a trained monkey, real (your son?) or virtual (expect). In this case, you really should do multiple measurements. The number of measurements depends on the spread of the monkey's reaction time. (Make it so that the mean-root-square error is significantly smaller than the mean value of the measured difference.) Happy reboots! Stepan Kasal From sundaram at fedoraproject.org Wed Jan 23 13:48:46 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 23 Jan 2008 19:18:46 +0530 Subject: long term support release In-Reply-To: References: <1201058211.3001.79.camel@gandalf.cobite.com> Message-ID: <479745BE.2030500@fedoraproject.org> Laith Juwaidah wrote: > By filtered here I mean carefully selected versions of the packages, for > example, though KDE 4.0.0 is released, RHHL should ship with KDE 3.5.8 > instead since it is still not complete, in other words, it doesn't have > to be so cutting edge, yet, not so outdated. http://www.redhat.com/about/news/prarchive/2007/global_desktop.html Rahul From buildsys at redhat.com Wed Jan 23 14:00:09 2008 From: buildsys at redhat.com (Build System) Date: Wed, 23 Jan 2008 09:00:09 -0500 Subject: rawhide report: 20080123 changes Message-ID: <200801231400.m0NE09vU004998@porkchop.devel.redhat.com> New package emacs-common-ebib A BibTeX database manager that runs in Emacs and XEmacs New package hunspell-ne Nepali hunspell dictionaries New package obex-data-server D-Bus service for Obex access New package python-cherrypy2 A pythonic, object-oriented web development framework New package twitux Twitux is a Twitter client for the Gnome desktop Removed package chkfontpath Updated Packages: TnL-071111-3.fc9 ---------------- * Tue Jan 22 2008 Hans de Goede 071111-3 - Rebuild for new glew allegro-4.2.2-7.fc9 ------------------- * Mon Jan 21 2008 Hans de Goede 4.2.2-7 - Add makedoc utility to allegro-devel as allegro-makedoc (bz 429450) - Fix sound when using pulseaudio - Fix compilation of inline asm with gcc 4.3 amanith-0.3-6.fc9 ----------------- * Tue Jan 22 2008 Tom "spot" Callaway 0.3-6 - rebuild against new glew anaconda-11.4.0.24-1 -------------------- * Tue Jan 22 2008 Chris Lumens - 11.4.0.24-1 - Avoid possible SIGSEGV from empty loaderData values. (dcantrell) - Do not require glib2-devel for building. (dcantrell) - Use libnl to get interface MAC and IP addresses (dcantrell) - Don't refer to the libuser.conf when creating users (#428891). (clumens) - pcspkr works (or isn't even present), per testing on #fedora-devel (notting) - Inline spufs loading for ppc. (notting) - Load iscsi_tcp, so that iSCSI actually works (notting) - inline ipv6 module loading (notting) - If we execWith a program, require the package containing it. (clumens) - Add a repository editor. (clumens) - Add the default repo to the UI so it can be edited later. (clumens) - Fix non-latin-1 locale display in the loader. (notting) - Make sure anaconda has precedence in the search path (#331091). (clumens) - When starting RAID arrays, the device node may not already exist. (notting) - Fix a typo that's breaking kickstart network installs. (clumens) - Don't allow backing up to partitioning (#429618). (clumens) - Update font paths. (clumens) ardour-2.2-3.fc9 ---------------- * Wed Jan 23 2008 Anthony Green 2.2-3 - Fix tagging glitch. * Tue Jan 22 2008 Anthony Green 2.2-2 - Fix wrapper script. * Thu Jan 17 2008 Anthony Green 2.2-1 - Upgrade to ardour 2.2. Wrap executable in a script. asm2-0:2.2.3-2jpp.1.fc9 ----------------------- * Tue Jan 22 2008 Permaine Cheung - 0:2.2.3-2jpp.1 - Merge with upstream * Tue Dec 18 2007 Ralph Apel 0:2.2.3-2jpp - Fix parent pom filename * Fri Oct 12 2007 Ralph Apel 0:2.2.3-1jpp - Upgrade to 2.2.3 - Add asm2-all jar file - Add manual subpackage - Optionally run tests (need lots of time, cpu, mem) - Add maven2 poms and depmap frags - Add gcj_support option - Make Vendor, Distribution based on macro aspell-12:0.60.5-4.fc9 ---------------------- * Tue Jan 22 2008 Ivana Varekova - 12:0.60.5-4 - add gcc43 patch * Thu Feb 08 2007 Ivana Varekova - 12:0.60.5-3 - incorporate package review feedback * Mon Jan 22 2007 Ivana Varekova - 12:0.60.5-2 - Resolves: 223676 fix non-failsafe install-info problem bcel-0:5.2-3jpp.2.fc9 --------------------- * Tue Jan 22 2008 Permaine Cheung 0:5.2-3jpp.1 - Merge with upstream bind-32:9.5.0-24.b1.fc9 ----------------------- * Tue Jan 22 2008 Adam Tkac 32:9.5.0-24.b1 - removed bind-9.3.2-prctl_set_dumpable.patch (upstream) - allow parallel building of libdns library - CVE-2008-0122 bootchart-0.9-7.fc9 ------------------- * Tue Jan 22 2008 Adam Jackson 0.9-7 - Only munge the grub config for the currently-running kernel; otherwise, if you dual-boot between multiple Linuxes, installing bootchart on one will break boot of the other. Note that if you have multiple roots running the same kernel, this will still break. bzr-1.1-1.fc9 ------------- * Mon Jan 21 2008 Toshio Kuratomi - 1.1-1 - Upstream 1.1 bugfix and performance enhancement release. - Enable bash completion script from the contrib directory. * Thu Dec 13 2007 Toshio Kuratomi - 1.0-1 - Update to 1.0 final. * Tue Dec 11 2007 Toshio Kuratomi - 1.0-0.1.rc3 - Update to 1.0rc3 - The new rawhide python package generates egg-info files. bzrtools-1.1.0-1.fc9 -------------------- * Mon Jan 21 2008 Toshio Kuratomi 1.1.0-1 - Update to 1.1. cmake-2.4.8-1.fc9 ----------------- * Tue Jan 22 2008 Orion Poplawski - 2.4.8-1 - Update to 2.4.8 control-center-1:2.21.5-2.fc9 ----------------------------- * Tue Jan 22 2008 Matthias Clasen - 2.21.5-2 - Disable font folder support createrepo-0.9.3-1.fc9 ---------------------- * Tue Jan 22 2008 Seth Vidal - 0.9.3 - 0.9.3 curl-7.17.1-6.fc9 ----------------- * Tue Jan 22 2008 Jindrich Novy 7.17.1-6 - fix curl-devel obsoletes so that we don't break F8->F9 upgrade path (#429612) dhcp-12:4.0.0-6.fc9 ------------------- * Tue Jan 22 2008 David Cantrell - 12:4.0.0-6 - read_function() comes from the LDAP patch, so fix it there - Init new struct universe structs in libdhcp4client so we don't crash on multiple DHCP attempts (#428203) enblend-3.1-0.1.20080121cvs.fc9 ------------------------------- * Mon Jan 21 2008 Bruno Postle 3.1-0.1.20090106cvs - CVS snapshot, 3.1 beta, switch to fedora cvs naming * Sun Jan 06 2008 Bruno Postle 3.1-0cvs20090106 - CVS snapshot, 3.1 beta firefox-3.0-0.beta2.12.nightly20080121.fc9 ------------------------------------------ * Mon Jan 21 2008 Christopher Aillon 3.0-0.beta2.12 - Update to latest trunk (2008-01-21) fontmatrix-0.3.1-1.fc9 ---------------------- * Wed Jan 23 2008 Parag - 0.3.1-1 - Update to 0.3.1 fuse-encfs-1.4.1.1-1.fc9 ------------------------ * Wed Jan 23 2008 Peter Lemenkov 1.4.1.1-1 - Ver. 1.4.1.1 - Changed License tag according to Fedora policy - Added new BR - boost-devel - Proper locale handling - Some other cosmetic changes fusion-icon-0-0.4.20071206git.1.fc9 ----------------------------------- * Tue Jan 22 2008 Karol Trzcionka - 0-0.4.20071206git.1 - Fix name of egg-info g2clib-1.0.5-3.fc9 ------------------ * Tue Jan 22 2008 Orion Poplawski 1.0.5-3 - Remove %{?_smp_mflags}, makefile is not parallel make safe gcin-1.3.8-1.fc9 ---------------- * Wed Jan 23 2008 Chung-Yen Chang - 1.3.8-1 - update to 1.3.8 geda-docs-20071231-1.fc9 ------------------------ * Tue Jan 22 2008 Chitlesh Goorah - 20071231-1 - New upstream release geda-examples-20071231-1.fc9 ---------------------------- * Tue Jan 22 2008 Chitlesh Goorah - 20071231-1 - New upstream release geda-gattrib-20071231-1.fc9 --------------------------- * Tue Jan 22 2008 Chitlesh Goorah - 20071231-1 - New upstream release geda-gnetlist-20071231-1.fc9 ---------------------------- * Tue Jan 22 2008 Chitlesh Goorah - 20071231-1 - New upstream release geda-symbols-20071231-1.fc9 --------------------------- * Tue Jan 22 2008 Chitlesh Goorah - 20071231-1 - New upstream release - added transfig as BR for fig2dev glew-1.5.0-1.fc9 ---------------- * Mon Jan 21 2008 Hans de Goede 1.5.0-1 - New upstream version, now SGI licensed stuff free out of the box! - Unfortunately some of the included docs are under a non free license, therefor this package is based on a modified tarbal with these files removed gnome-user-share-0.20-1.fc9 --------------------------- * Tue Jan 22 2008 - Bastien Nocera - 0.20-1 - Update to 0.20 - Remove obsolete patches hedgewars-0.9.2-1.fc9 --------------------- * Tue Jan 22 2008 Hans de Goede 0.9.2-1 - New upstream release 0.9.2 hsqldb-1:1.8.0.9-1jpp.1.fc9 --------------------------- * Tue Jan 22 2008 Jon Prindiville 1.8.0.9-1jpp.1 - Fix for bz# 428520: Defining JAVA_HOME in /etc/sysconfig/hsqldb httpd-2.2.8-2 ------------- * Tue Jan 22 2008 Joe Orton 2.2.8-2 - update to 2.2.8 - drop mod_imagemap hugin-0.7.0-0.2.20080121svn.fc9 ------------------------------- * Tue Jan 22 2008 Bruno Postle 0.7.0-0.2.20080121svn - SVN snapshot, 0.7 beta. move cli dependencies to hugin-base package * Mon Jan 21 2008 Bruno Postle 0.7.0-0.1.20080121svn - SVN snapshot, add LICENCE.manual * Sat Jan 19 2008 Bruno Postle 0.7.0-0.1.20080119svn - SVN snapshot, split to hugin and hugin-base packages jakarta-commons-io-0:1.3.2-1jpp.1.fc9 ------------------------------------- * Tue Jan 22 2008 Permaine Cheung - 0:1.3.2-1jpp.1 - Merge with upstream * Fri Jul 20 2007 Ralph Apel - 0:1.3.2-1jpp - Upgrade to 1.3.2 - Build with maven2 by default - Add pom and depmap frag * Tue May 15 2007 Ralph Apel - 0:1.2-4jpp - Make Vendor, Distribution based on macro jakarta-commons-lang-0:2.3-1jpp.1.fc9 ------------------------------------- * Tue Jan 22 2008 Permaine Cheung - 0:2.3-1jpp.1 - Merge with upstream * Mon Aug 13 2007 Ralph Apel - 0:2.3-1jpp - Upgrade to 2.3 - Build with maven by default - Add pom anf depmap frag - Make Vendor, Distribution based on macro joe-3.5-4.fc9 ------------- * Tue Jan 22 2008 Ivana Varekova 3.5-4 - rebuilt jpackage-utils-0:1.7.4-2jpp.2.fc9 --------------------------------- * Tue Jan 22 2008 Thomas Fitzsimmons - 0:1.7.4-2jpp.2 - Replace GCJ security directory. * Tue Jan 22 2008 Thomas Fitzsimmons - 0:1.7.4-2jpp.1 - Import jpackage-utils 1.7.4-2jpp. * Mon Jan 21 2008 Thomas Fitzsimmons - 0:1.7.3-1jpp.4 - Remove AutoReqProv. - Remove Requires and BuildRequires. - Wrap export, install and maven lines at 80 columns. - Add jre option to java.conf comment. - Related: rhbz#428520 - Remove commented jpackage.org sections. - Remove duplicate files from files list. - Remove trailing whitespace. - Remove rebuild-security-providers. - Resolves: rhbz#260161 kudzu-1.2.83-1 -------------- * Tue Jan 22 2008 Bill Nottingham 1.2.83-1 - don't configure sound cards libbtctl-0.10.0-1.fc9 --------------------- * Tue Jan 22 2008 - Bastien Nocera - 0.10.0-1 - Update to 0.10.0 libgeda-20071231-1.fc9 ---------------------- * Tue Jan 22 2008 Chitlesh Goorah - 20071231-1 - New upstream release libsemanage-2.0.15-2.fc9 ------------------------ * Tue Jan 22 2008 Dan Walsh - 2.0.15-2 - Stop differentiating on user for homedir labeling mailcap-2.1.26-1.fc9 -------------------- * Tue Jan 22 2008 Miroslav Lichvar 2.1.26-1 - use xdg-open (Ville Skytt??) (#388481) - spec cleanup (#226116) maniadrive-1.2-7.fc9 -------------------- * Tue Jan 22 2008 Hans de Goede 1.2-7 - Rebuild for new glew mesa-7.1-0.8.fc9 ---------------- * Tue Jan 22 2008 Adam Jackson 7.1-0.8 - Enable i915 DRI on E7221. (Carlos Mart??n, #425790) * Mon Jan 21 2008 Adam Jackson - Make the demo seddery prettier. muine-0.8.8-5.fc9 ----------------- * Tue Jan 22 2008 Sindre Pedersen Bj??rdal - 0.8.8-5 - Remove bogus mono provides, #429171 nfs-utils-1:1.1.1-1.fc9 ----------------------- * Sat Jan 05 2008 Steve Dickson 1.1.1-1 - Updated to latest upstream release, nfs-utils-1.1.1 - Added the removal of sm-notify.pid to nfslock init script. - Changed spec file to use condrestart instead of condstop when calling init scripts. - Fixed typo in rpc.mountd man page - Turn on 'nohide' automatically for all refer exports (bz 313561) nspluginwrapper-0.9.91.5-21.fc9 ------------------------------- * Mon Jan 21 2008 Martin Stransky 0.9.91.5-21 - fixed #426618 - gcjwebplugin error: Failed to run (added to ignored plugins) ogre-1.4.6-3.fc9 ---------------- * Tue Jan 22 2008 Hans de Goede 1.4.6-3 - Rebuild for new glew openldap-2.4.7-3.fc9 -------------------- * Tue Jan 22 2008 Jan Safranek 2.4.7-3.fc9 - obsoleting compat-openldap properly again :) * Tue Jan 22 2008 Jan Safranek 2.4.7-2.fc9 - obsoleting compat-openldap properly (#429591) openmsx-0.6.3-2.fc9 ------------------- * Tue Jan 22 2008 Ian Chapman 0.6.3-2 - Rebuild for new glew version in devel openoffice.org-1:2.4.0-3.3.fc9 ------------------------------ * Mon Jan 21 2008 Caolan McNamara - 1:2.4.0-3.3 - fix openoffice.org-2.4.0.ooo85321.vcl.pixmapleak.patch for warren - fix openoffice.org-2.4.0.ooo85429.sw.a11ycrash.patch - Resolves: rhbz#428574 add workspace.sw24bf02.patch - Resolves: problem in rhbz#429550 openoffice.org-2.4.0.ooo85448.emptyrpath.patch paps-0.6.8-4.fc9 ---------------- * Wed Jan 23 2008 Akira TAGOH - 0.6.8-4 - Fix an exception on ghostscript. (#429275) pciutils-2.2.9-5.fc9 -------------------- * Tue Jan 22 2008 Bill Nottingham 2.2.9-5 - put library back plexus-i18n-0:1.0-0.b6.5jpp.1.fc9 --------------------------------- * Tue Jan 22 2008 Permaine Cheung - 0:1.0-0.b6.5jpp.1 - Update to the same version as upstream * Thu Apr 26 2007 Ralph Apel - 0:1.0-0.b6.5jpp - Reupload to fix metadata * Sat Mar 24 2007 Ralph Apel - 0:1.0-0.b6.4jpp - Optionally build without maven - Add gcj_support option powertop-1.9-2.fc9 ------------------ * Tue Jan 22 2008 Adam Jackson 1.9-2 - Use full path when invoking hciconfig. (Ville Skytt??, #426721) pungi-1.2.7-1.fc9 ----------------- * Tue Jan 22 2008 jkeating 1.2.7-1 - Rework how repodata gets generated for media. - use createrepo api pygtksourceview-2.1.0-2.fc9 --------------------------- * Tue Jan 22 2008 Matthew Barnes - 2.1.0-2.fc9 - Fix a typo. pykickstart-1.28-1.fc9 ---------------------- * Wed Jan 23 2008 Chris Lumens - 1.28-1 - Fix traceback on volgroup command. (clumens) python-cherrypy-3.0.3-2.fc9 --------------------------- * Tue Jan 22 2008 Toshio Kuratomi 3.0.3-2 - Forgot to upload the tarball. * Mon Jan 21 2008 Toshio Kuratomi 3.0.3-1 - Upgrade to 3.0.3. python-paramiko-1.7.2-1.fc9 --------------------------- * Tue Jan 22 2008 Jeffrey C. Ollie - 1.7.2-1 - Update to 1.7.2. - Remove upstreamed patch. qstat-2.11-4.fc9 ---------------- * Wed Jan 23 2008 Andy Shevchenko 2.11-4 - fix Source0 URL recordmydesktop-0.3.7-2.fc9 --------------------------- * Tue Jan 22 2008 Sindre Pedersen Bj??rdal - 0.3.7-2 - Add missing jack dependency rhgb-1:0.17.7-4.fc9 ------------------- * Tue Jan 22 2008 Adam Jackson 0.17.7-4 - rhgb-0.17.7-strict-exit.patch: Re-add, dropped during the epoch. - rhgb-0.17.7-dri.patch: Don't disable DRI durign rhgb. rsyslog-2.0.0-2.fc9 ------------------- * Tue Jan 22 2008 Peter Vrabec 2.0.0-2 - strerror fix (#428775) scorched3d-41.3-1.fc9 --------------------- * Mon Jan 21 2008 Hans de Goede 41.3-1 - New upstream release 41.3 - Rebuild for new glew sdljava-0.9.1-8.fc9 ------------------- * Tue Jan 22 2008 Hans de Goede 0.9.1-8 - Rebuild for new glew selinux-policy-3.2.5-17.fc9 --------------------------- * Mon Jan 21 2008 Dan Walsh 3.2.5-17 - Allow ptrace or user processes by users of same type - Add boolean for transition to nsplugin * Mon Jan 21 2008 Dan Walsh 3.2.5-16 - Allow nsplugin sys_nice, getsched, setsched sepostgresql-8.3RC2-2.56.beta.fc9 --------------------------------- * Tue Jan 22 2008 - sepostgresql-8.3RC2-2.56 - BUGFIX: lack of locks when refering buffer pages at update/delete hooks - BUGFIX: explicit labeling using SELECT ... INTO statement. stellarium-0.9.1-4.fc9 ---------------------- * Tue Jan 22 2008 Jochen Schmitt 0.9.1-3 - New upstream release system-config-display-1.0.51-5.fc9 ---------------------------------- * Tue Jan 22 2008 Adam Jackson 1.0.51-5 - scd-1.0.51-config-util.patch: Update for new usermode. (#428397) system-config-keyboard-1.2.11-4.fc9 ----------------------------------- * Tue Jan 22 2008 Jesse Keating - 1.2.11-4 - Patch to work with new firstboot (#424811) - Add requires for kudzu/newt (#177301) - Update url (#235072) - Remove obsolete no translation (#332301) texlive-2007-14.fc9 ------------------- * Tue Jan 22 2008 Jindrich Novy - 2007-14 - use xdg-open(1) in texdoctk (#429659) - fix bad syntax of texmfstart man page * Fri Jan 18 2008 Jindrich Novy - 2007-13 - don't copy original pdftex map files but regenerate them with the correct updmap.cfg file updated in texlive-texmf (Related: #425804) - install mendex via libtool (#428507) * Thu Jan 17 2008 Jindrich Novy - 2007-12 - remove all references to teTeX from the packaged man pages and update links to point correctly to upstream mailing list and web page - drop xpdf patch, we link against poppler now tftp-0.42-6 ----------- * Tue Jan 22 2008 Martin Nagy - 0.42-6 - changed the location of tftpboot directory to /var/lib/ unzip-5.52-6.fc9 ---------------- * Tue Jan 22 2008 Ivana Varekova - 5.52-6 - add >4GB patch (#429674) vavoom-1.26-1.fc9 ----------------- * Tue Jan 22 2008 Hans de Goede 1.26-1 - New upstream release 1.26 vnc-4.1.2-24.fc9 ---------------- * Wed Jan 09 2008 Adam Tkac 4.1.2-24 - start use F8 xserver codebase - compat patches and gcc 4.3 patches - use catalogue:/etc/X11/fontpath.d,built-ins as default fontpath (#390971) wavbreaker-0.9-2.fc9 -------------------- * Tue Jan 22 2008 Homer 0.9-2 - bump release for F8 -> F9 upgrade path wdfs-1.4.2-5.fc9 ---------------- * Tue Jan 22 2008 Adam Jackson 1.4.2-5 - Fix License tag. (#428962) xorg-x11-drv-nv-2.1.6-6.fc9 --------------------------- * Tue Jan 22 2008 Adam Jackson 2.1.6-6 - nv-2.1.6-starvation.patch: Avoid starving nv4-gen chips of memory bandwidth on huge modes. There's surely a better way to do this. (#383891) xorg-x11-drv-vmware-10.15.2-99.1.fc9 ------------------------------------ * Tue Jan 22 2008 Adam Jackson 10.15.2-99.1 - Update to git snapshot for pciaccess conversion. (#428613) yum-metadata-parser-1.1.2-5.fc9 ------------------------------- * Tue Jan 22 2008 Seth Vidal 1.1.2-5 - rebuild Broken deps for i386 ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.i386 requires libgtkembedmoz.so epiphany-extensions - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.i386 requires libgtkembedmoz.so gnome-web-photo - 0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 icewm - 1.2.35-2.fc9.i386 requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 muine - 0.8.8-5.fc9.i386 requires mono(muine-plugin) = 0:1.0.0.0 qt-recordmydesktop - 0.3.6-4.fc9.noarch requires recordmydesktop = 0:0.3.6 Broken deps for x86_64 ---------------------------------------------------------- epiphany-extensions - 2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) icewm - 1.2.35-2.fc9.x86_64 requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 muine - 0.8.8-5.fc9.x86_64 requires mono(muine-plugin) = 0:1.0.0.0 qt-recordmydesktop - 0.3.6-4.fc9.noarch requires recordmydesktop = 0:0.3.6 Broken deps for ppc ---------------------------------------------------------- anaconda - 11.4.0.24-1.ppc requires dmidecode anaconda - 11.4.0.24-1.ppc requires ntfsprogs epiphany-extensions - 2.20.1-3.fc9.ppc requires libgtkembedmoz.so epiphany-extensions - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.ppc requires libgtkembedmoz.so gnome-web-photo - 0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 icewm - 1.2.35-2.fc9.ppc requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 monodevelop - 0.17-4.fc9.ppc requires boo muine - 0.8.8-5.fc9.ppc requires mono(muine-plugin) = 0:1.0.0.0 qt-recordmydesktop - 0.3.6-4.fc9.noarch requires recordmydesktop = 0:0.3.6 Broken deps for ppc64 ---------------------------------------------------------- anaconda - 11.4.0.24-1.ppc64 requires ntfsprogs anaconda - 11.4.0.24-1.ppc64 requires dmidecode epiphany-extensions - 2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) icewm - 1.2.35-2.fc9.ppc64 requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 perl-Test-AutoBuild-darcs - 1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 qt-recordmydesktop - 0.3.6-4.fc9.noarch requires recordmydesktop = 0:0.3.6 From markg85 at gmail.com Wed Jan 23 14:02:28 2008 From: markg85 at gmail.com (Mark) Date: Wed, 23 Jan 2008 15:02:28 +0100 Subject: preload In-Reply-To: <20080124131453.GA31330@camelia.ucw.cz> References: <1201071580.6050.20.camel@localhost.localdomain> <20080124131453.GA31330@camelia.ucw.cz> Message-ID: <6e24a8e80801230602p4702e261k4b18a9f90a84da39@mail.gmail.com> Just a question about how to benchmark Gnome startup.. i tried adding this: echo "Timing START:" >> /home/mark/GnomeBench date '+%s.%N' >> /home/mark/GnomeBench the file GnomeBench is created (by hand) and has mark.mark permissions. to (just the top of the page) and around the lines that actually (should) start gnome: xinitrc Xsession But it doesn't seem to add a thing to the GnomeBench file... Any help would be welcome. And a list of the programs i intend to benchmark with and without preload: - Gnome - Nautilus - Firefox - Pidgin - Totem - Perhaps also OpenOffice Word I intend to bench every app 4 times: 1. right after a reboot (no preload) 2. than again (no preload) 3. right after reboot (with preload) 4. than again (with preload) And than put it in a graph. That should give a decent view of the performance increase (or even decrease). Thanx, Mark From lesmikesell at gmail.com Wed Jan 23 14:02:13 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 23 Jan 2008 08:02:13 -0600 Subject: SELinux removed from desktop cd spin? In-Reply-To: <1201081556.17926.30.camel@vincent52.localdomain> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116200333.GE15623@redhat.com> <64b14b300801161219q355d93b0jb57f91f48615591a@mail.gmail.com> <20080116202554.GF15623@redhat.com> <64b14b300801161235i4a4ed432h4f7b81ecefaf292b@mail.gmail.com> <7f692fec0801161717x3b0d77b9n9cd4a2dd939c6398@mail.gmail.com> <478F6C07.2050108@gmail.com> <1200617202.920.156.camel@calliope.phig.org> <47967CA7.3000604@fedoraproject.org> <47968081.5050903@gmail.com> <479684B6.8090405@fedoraproject.org> <4796AB86.5000107@gmail.com> <4796C58F.3070300@fedoraproject.org> <4796CD17.9010706@gmail.com> <4796D166.8060908@fedoraproject.org> <1201081556.17926.30.camel@vincent52.localdomain> Message-ID: <479748E5.4050401@gmail.com> Matthew Saltzman wrote: >>> But the NSA would be at least as capable of introducing a hack that you >>> could examine but not see as Ken Thompson: >>> http://www.everything2.com/index.pl?node=Reflections%20On%20Trusting%20Trust >>> >>> I'd expect them to even be able to conspire with the CPU vendors to have >>> certain undocumented opcode sequences do magical things. >> Sure. You can believe whatever you want to. I am merely stating a fact >> that the bar to do this with open source software is way higher than >> proprietary software and in fact is the highest that anyone can >> practically go. > > Also, in order to carry out a hack like that, you have to infect the > toolchain somewhere along the line, so that everyone building the code > is doing so with infected compilers.. With open-source code and an > open-source toolchain, that seems pretty unlikely. > > Or are you suggesting, Les, that everyone's copy of gcc is derived from > one built by the NSA and smuggled into RMS's lab at some point in its > early history? How many people have contributed code and how much do you know about them or their motives? But a more likely target would be the CPU companies since there are only a couple that matter and this could make the compiler portion pretty much invisible. Is that any more paranoid than thinking the major communication companies all have government taps for everything passing through or that cell phones are all rigged so the government can locate and listen at any time? -- Les Mikesell lesmikesell at gmail.com From dtimms at iinet.net.au Wed Jan 23 14:02:30 2008 From: dtimms at iinet.net.au (David Timms) Date: Thu, 24 Jan 2008 01:02:30 +1100 Subject: F8 to rawhide upgrade - yum python mismatch - repeatable In-Reply-To: <4795F05F.6010700@gmail.com> References: <4795CBCA.3070007@iinet.net.au> <4795D94F.1030505@gmail.com> <4795EE99.3000209@iinet.net.au> <4795F05F.6010700@gmail.com> Message-ID: <479748F6.5010209@iinet.net.au> Andrew Farris wrote: > David Timms wrote: >> /usr/lib/python2.5/site-packages/_sqlitecache.so: undefined symbol: >> g_assertion_message_expr >> ... > Yes, python-urlgrabber should have been upgraded to fc9 I don't have the .fc9 one at the moment, however: rpm -q --requires yum /usr/bin/python config(yum) = 3.2.8-2.fc9 python >= 2.4 python(abi) = 2.5 python-iniparse python-sqlite rpm >= 0:4.4.2 rpm-python rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 urlgrabber yum-metadata-parser >= 1.1.0 * note no version of urlgrabber mentioned so any should do. [davidt at localhost ~]$ rpm -q --whatprovides urlgrabber python-urlgrabber-3.0.0-3.fc8 * I have one installed. > as should the other python rpms. python and python-libs are part of python itself. The others are independent developments, with their own versions. > It looks like there could be a requires missing to > get those to move up to the fc9 version. I might be getting this wrong; the requires is trying to guarantee the packages work with each other, by requiring stuff provided by other packages, and specifying versions, if a specific version is required. I don't think it is necessary to have all packages with .fc9. for things to work normally. In any case, a later yum update would notice the things that have updates, and update them. > Did you see anything about that when updating python? no. > Do you have the yumskipbroken plugin when doing that upgrade? no. yum-skip-broken is not installed. DaveT. From dtimms at iinet.net.au Wed Jan 23 14:12:03 2008 From: dtimms at iinet.net.au (David Timms) Date: Thu, 24 Jan 2008 01:12:03 +1100 Subject: F8 to rawhide upgrade - yum python mismatch - repeatable In-Reply-To: <1201009795.6218.4.camel@cutter> References: <4795CBCA.3070007@iinet.net.au> <4795D94F.1030505@gmail.com> <4795EE99.3000209@iinet.net.au> <1201009795.6218.4.camel@cutter> Message-ID: <47974B33.5030401@iinet.net.au> seth vidal wrote: > On Wed, 2008-01-23 at 00:24 +1100, David Timms wrote: >> $ rpm -qa yum\* rpm\* python\* sql\*|sort >> yum-3.2.8-2.fc8 * this was .fc8. because I tried downgrading to see if yum would work again. current: yum-3.2.8-2.fc9 >> yum-metadata-parser-1.1.2-4.fc9 >> [davidt at localhost ~]$ yum --help ... >> /usr/lib/python2.5/site-packages/_sqlitecache.so: undefined symbol: >> g_assertion_message_expr > > remove yum-metadata-parser via rpm -e, please # rpm -e yum-metadata-parser error: Failed dependencies: yum-metadata-parser >= 1.1.0 is needed by (installed) yum-3.2.8-2.fc9.noarch # rpm -e yum-metadata-parser --nodeps > and then try running yum. # yum update There was a problem importing one of the Python modules required to run yum. The error leading to this problem was: No module named sqlitecachec Please install a package which provides this module, or verify that the module is installed correctly. It's possible that the above module doesn't match the current version of Python, which is: 2.5.1 (r251:54863, Jan 17 2008, 11:02:11) [GCC 4.1.2 20071124 (Red Hat 4.1.2-36)] * the module missing changed, but no go. > if yum works then yum install yum-metadata-parser and tell me if it > still balks. else: rpm -Uvh yum-metadata-parser-1.1.2-4.fc9.i386.rpm Preparing... ########################################### [100%] 1:yum-metadata-parser ########################################### [100%] [root at localhost packages]# yum There was a problem importing one of the Python modules required to run yum. The error leading to this problem was: /usr/lib/python2.5/site-packages/_sqlitecache.so: undefined symbol: g_assertion_message_expr * back to original message Will install the newer -metadata-parser when it becomes visible... DaveT. From billcrawford1970 at gmail.com Wed Jan 23 14:21:29 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 23 Jan 2008 14:21:29 +0000 Subject: Replacing the boot kernel in the installer In-Reply-To: <20080123081009.50b11fc3@redhat.com> References: <544eb990801230424q79f27bek99ccd6905c645f6@mail.gmail.com> <479738F5.6060001@gmail.com> <1201093498.7153.49.camel@localhost.localdomain> <544eb990801230506o1f908f1cq958cfdf9073984b0@mail.gmail.com> <20080123081009.50b11fc3@redhat.com> Message-ID: <544eb990801230621u1baa32afia8de7077cbf060d3@mail.gmail.com> On 23/01/2008, Jesse Keating wrote: > The best way around it is to use rescue.iso instead. Since rescue.iso > has stage2 on it, you can point it at any repo to do the install, like > your original F8 repo. Sounds good. I can't find a rescue.iso under development at the moment, though, so I'm going with (in order) trying to use rawhide vmlinuz + initrd.img (replacing .buildstamp with the one from F8); and if that doesn't work, actually replacing the F8 install kernel with the rawhide installer kernel and ditto the modules in the initrd ... From paul at city-fan.org Wed Jan 23 14:24:32 2008 From: paul at city-fan.org (Paul Howarth) Date: Wed, 23 Jan 2008 14:24:32 +0000 Subject: F8 to rawhide upgrade - yum python mismatch - repeatable In-Reply-To: <47974B33.5030401@iinet.net.au> References: <4795CBCA.3070007@iinet.net.au> <4795D94F.1030505@gmail.com> <4795EE99.3000209@iinet.net.au> <1201009795.6218.4.camel@cutter> <47974B33.5030401@iinet.net.au> Message-ID: <47974E20.5040108@city-fan.org> David Timms wrote: > seth vidal wrote: >> On Wed, 2008-01-23 at 00:24 +1100, David Timms wrote: >>> $ rpm -qa yum\* rpm\* python\* sql\*|sort >>> yum-3.2.8-2.fc8 > * this was .fc8. because I tried downgrading to see if yum would work > again. current: yum-3.2.8-2.fc9 > >>> yum-metadata-parser-1.1.2-4.fc9 >>> [davidt at localhost ~]$ yum --help > ... >>> /usr/lib/python2.5/site-packages/_sqlitecache.so: undefined >>> symbol: g_assertion_message_expr >> >> remove yum-metadata-parser via rpm -e, please > # rpm -e yum-metadata-parser > error: Failed dependencies: > yum-metadata-parser >= 1.1.0 is needed by (installed) > yum-3.2.8-2.fc9.noarch > # rpm -e yum-metadata-parser --nodeps > >> and then try running yum. > # yum update > There was a problem importing one of the Python modules > required to run yum. The error leading to this problem was: > > No module named sqlitecachec > > Please install a package which provides this module, or > verify that the module is installed correctly. > > It's possible that the above module doesn't match the > current version of Python, which is: > 2.5.1 (r251:54863, Jan 17 2008, 11:02:11) > [GCC 4.1.2 20071124 (Red Hat 4.1.2-36)] > > * the module missing changed, but no go. > >> if yum works then yum install yum-metadata-parser and tell me if it >> still balks. > else: > rpm -Uvh yum-metadata-parser-1.1.2-4.fc9.i386.rpm > Preparing... ########################################### > [100%] > 1:yum-metadata-parser ########################################### > [100%] > [root at localhost packages]# yum > There was a problem importing one of the Python modules > required to run yum. The error leading to this problem was: > > /usr/lib/python2.5/site-packages/_sqlitecache.so: undefined symbol: > g_assertion_message_expr > > > * back to original message > > Will install the newer -metadata-parser when it becomes visible... Does updating glib2 to the version in Rawhide help? Paul. From cra at WPI.EDU Wed Jan 23 14:50:53 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 23 Jan 2008 09:50:53 -0500 Subject: long term support release In-Reply-To: <4796D766.8070009@gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <7f692fec0801221942x715523cal70423262eb09b4c0@mail.gmail.com> <1201060757.3001.96.camel@gandalf.cobite.com> <4796D766.8070009@gmail.com> Message-ID: <20080123145053.GA23715@angus.ind.WPI.EDU> On Tue, Jan 22, 2008 at 09:57:58PM -0800, Andrew Farris wrote: > David Mansfield wrote: >> You're not suggesting I use the 'Other Well Known Distro' are you? >> Seriously, though, on my latest laptop I tried CentOS 5, and it was >> awful on a laptop. Synaptic problems, networkmanager problems, crappy >> wireless support (out of date) etc. I killed it in about a week. I >> also tried the Other distro and as a Fedora (and Red Hat Linux before >> that) guy, it just doesn't do it for me. Old dog, new tricks. It >> lasted about a month. That said, updating every 6 months doesn't do it >> for me either. What's a Fedora lover to do? > > You could skip every other Fedora release and get a full year between your > upgrades, still getting the lastest security patches the whole time. F7 > doesn't go to EOL until F9 releases. Not really. You have to wait ~6 months for the newest release to stabalize before upgrading to it, so that cuts down the maintained lifetime to only 6 months. From jkeating at redhat.com Wed Jan 23 14:54:43 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 23 Jan 2008 09:54:43 -0500 Subject: long term support release In-Reply-To: <20080123145053.GA23715@angus.ind.WPI.EDU> References: <1201058211.3001.79.camel@gandalf.cobite.com> <7f692fec0801221942x715523cal70423262eb09b4c0@mail.gmail.com> <1201060757.3001.96.camel@gandalf.cobite.com> <4796D766.8070009@gmail.com> <20080123145053.GA23715@angus.ind.WPI.EDU> Message-ID: <20080123095443.130b7230@redhat.com> On Wed, 23 Jan 2008 09:50:53 -0500 Chuck Anderson wrote: > Not really. You have to wait ~6 months for the newest release to > stabalize before upgrading to it, so that cuts down the maintained > lifetime to only 6 months. This is ridiculous BS that is self serving. If everybody waited until release+6M to try it out, the "safe" date would become release+12M, and so on. It's entirely a piss poor attitude and does nothing to better the project. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dtimms at iinet.net.au Wed Jan 23 15:06:09 2008 From: dtimms at iinet.net.au (David Timms) Date: Thu, 24 Jan 2008 02:06:09 +1100 Subject: F8 to partial rawhide upgrade - yum python mismatch - workaround In-Reply-To: <1201044327.6218.43.camel@cutter> References: <4795CBCA.3070007@iinet.net.au> <4795D94F.1030505@gmail.com> <4795EE99.3000209@iinet.net.au> <1201009795.6218.4.camel@cutter> <1201044327.6218.43.camel@cutter> Message-ID: <479757E1.9030302@iinet.net.au> seth vidal wrote: > On Tue, 2008-01-22 at 08:49 -0500, seth vidal wrote: > I rebuild yum-metadata-parser into rawhide. Nothing changed in it - just > a rebuild - let's see if that makes things better. actions and workaround at: https://bugzilla.redhat.com/show_bug.cgi?id=428847 DaveT. From cra at WPI.EDU Wed Jan 23 15:06:16 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 23 Jan 2008 10:06:16 -0500 Subject: long term support release In-Reply-To: <20080123095443.130b7230@redhat.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <7f692fec0801221942x715523cal70423262eb09b4c0@mail.gmail.com> <1201060757.3001.96.camel@gandalf.cobite.com> <4796D766.8070009@gmail.com> <20080123145053.GA23715@angus.ind.WPI.EDU> <20080123095443.130b7230@redhat.com> Message-ID: <20080123150616.GC23715@angus.ind.WPI.EDU> On Wed, Jan 23, 2008 at 09:54:43AM -0500, Jesse Keating wrote: > On Wed, 23 Jan 2008 09:50:53 -0500 > Chuck Anderson wrote: > > > Not really. You have to wait ~6 months for the newest release to > > stabalize before upgrading to it, so that cuts down the maintained > > lifetime to only 6 months. > > This is ridiculous BS that is self serving. If everybody waited until > release+6M to try it out, the "safe" date would become release+12M, and > so on. It's entirely a piss poor attitude and does nothing to better > the project. Shipping software in a stable Fedora release that upstream considers alpha-quality and not ready for production use contributes to a perception that the stable Fedora release itself isn't stable or ready for production. From jkeating at redhat.com Wed Jan 23 15:07:25 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 23 Jan 2008 10:07:25 -0500 Subject: long term support release In-Reply-To: <20080123150616.GC23715@angus.ind.WPI.EDU> References: <1201058211.3001.79.camel@gandalf.cobite.com> <7f692fec0801221942x715523cal70423262eb09b4c0@mail.gmail.com> <1201060757.3001.96.camel@gandalf.cobite.com> <4796D766.8070009@gmail.com> <20080123145053.GA23715@angus.ind.WPI.EDU> <20080123095443.130b7230@redhat.com> <20080123150616.GC23715@angus.ind.WPI.EDU> Message-ID: <20080123100725.06940eb6@redhat.com> On Wed, 23 Jan 2008 10:06:16 -0500 Chuck Anderson wrote: > Shipping software in a stable Fedora release that upstream considers > alpha-quality and not ready for production use contributes to a > perception that the stable Fedora release itself isn't stable or > ready for production. And now you're trying to use /one/ example that a Fedora maintainer made a conscious decision on a version of software to ship, with the expectation that they would be fast to respond to any issues, and applying it to the entire distribution. Cute. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jos at xos.nl Wed Jan 23 15:09:21 2008 From: jos at xos.nl (Jos Vos) Date: Wed, 23 Jan 2008 16:09:21 +0100 Subject: long term support release In-Reply-To: <47972980.7000804@odu.neva.ru> References: <1201058211.3001.79.camel@gandalf.cobite.com> <47972980.7000804@odu.neva.ru> Message-ID: <20080123150921.GB32532@jasmine.xos.nl> On Wed, Jan 23, 2008 at 02:48:16PM +0300, Dmitry Butskoy wrote: > Well, I actually use Fedora in a strong production environment (power > control office). The current policy (the EOL of F is one month after > the F) provides me one year LTS (assuming the release is per > half-year). Thus I just skip one release, i.e. FC1-->FC3-->FC5-->F7 . > > One-year LTS is an acceptable compromise for me. But ideally, from the > "production" point of view, I would prefer 9-month cycle (and hence > 1.5year LTS) ... Wondering what the difference with using RHEL/CentOS + EPEL is then... -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From fedora at dm.cobite.com Wed Jan 23 15:13:39 2008 From: fedora at dm.cobite.com (David Mansfield) Date: Wed, 23 Jan 2008 10:13:39 -0500 Subject: long term support release In-Reply-To: <4796C18F.7070807@gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> Message-ID: <1201101219.3001.98.camel@gandalf.cobite.com> On Tue, 2008-01-22 at 20:24 -0800, Andrew Farris wrote: > David Mansfield wrote: > > I'm fairly new to this list so if this is flame-bait, then I apologize. > > I was wondering whether there is any possibility of having the > > occasional 'long term support' (LTS) release of Fedora (say one every > > two years or something) so that users can settle down with the distro > > and actually become productive with it. > > > > Say the LTS cycle is one release every two years (every fourth Fedora > > release), and that the 'long term' for support only lasts for two years > > (which is pretty short to use the term long for, I realize), then there > > would only be one LTS release, and also the most current release to > > worry about at any given time. > > > > If there is simply not enough teampower to do this, then that's > > understood. > > > > Thanks, > > David > > That is essentially what was tried with the fedora legacy project (supporting > eol fedora releases for a longer term) but there was not enough interest and > support to keep it going. It did support RH9 and FC releases up to FC5 I think? Almost the same. A few differences: - that project was 'glued on' to an existing process instead of a part of it - they came into the game with a number of releases to support already - they wanted to support every release I think Fedora LTS would be: - planned and built into the Fedora cycle and finally implemented - only releases planned in advance to be LTS releases would be LTS - there would only be one (or two) outstanding LTS releases at a time David From fedora at dm.cobite.com Wed Jan 23 15:20:26 2008 From: fedora at dm.cobite.com (David Mansfield) Date: Wed, 23 Jan 2008 10:20:26 -0500 Subject: long term support release In-Reply-To: <1201062084.8306.3.camel@localhost6.localdomain6> References: <1201058211.3001.79.camel@gandalf.cobite.com> <1201062084.8306.3.camel@localhost6.localdomain6> Message-ID: <1201101626.3001.107.camel@gandalf.cobite.com> On Tue, 2008-01-22 at 21:21 -0700, Richi Plana wrote: > On Tue, 2008-01-22 at 22:16 -0500, David Mansfield wrote: > > Say the LTS cycle is one release every two years (every fourth Fedora > > release), and that the 'long term' for support only lasts for two years > > (which is pretty short to use the term long for, I realize), then there > > would only be one LTS release, and also the most current release to > > worry about at any given time. > > I was about to say that that is exactly what RHEL-to-CentOS is for, but > thinking about it, I think I know what your problem is with CentOS. > > One thing not factored with CentOS is how old it is compared to the > version of Fedora that it's supposed to be based upon. If I understand > you correctly, your concept of LTS is based on the Final stable release > of Fedora and will be supported for two years as opposed to some version > of CentOS which upon release is probably years behind the final release > of rawhide it was based on and therefore obsolete with hardware (which > also has a fast release cycle). (Could someone do the math?) > > Did I understand your problem correctly? That's certainly a big part of it. A big part. You're right, when Fedora comes out, it's at least current for the hardware of the day, but when CentOS does come out with a major release, it's not even going to work right on that same hardware, let alone new hardware that comes out later. Also, there are quirks that appear in the EL spins that weren't there in the Fedora releases. One example is some weird synaptic touchpad problem I had that was only on the EL kernels. Is that ever going to get fixed? No, it's not even a bug in the synaptic code, its somewhere else. That's just an example though. David From fedora at dm.cobite.com Wed Jan 23 15:29:42 2008 From: fedora at dm.cobite.com (David Mansfield) Date: Wed, 23 Jan 2008 10:29:42 -0500 Subject: long term support release In-Reply-To: <16de708d0801222002o51b7d771jaa8606128a11f93b@mail.gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <16de708d0801222002o51b7d771jaa8606128a11f93b@mail.gmail.com> Message-ID: <1201102182.3001.116.camel@gandalf.cobite.com> On Tue, 2008-01-22 at 22:02 -0600, Arthur Pemberton wrote: > On Jan 22, 2008 9:16 PM, David Mansfield wrote: > > I'm fairly new to this list so if this is flame-bait, then I apologize. > > I was wondering whether there is any possibility of having the > > occasional 'long term support' (LTS) release of Fedora (say one every > > two years or something) so that users can settle down with the distro > > and actually become productive with it. > > I'm somewhat curious as to what prevents you from being productive > with it? I'm pretty happy with mine. > > I've found it takes quite a while to find out the latest problems with the release (always wireless problems etc), get multimedia installed correctly, find out how the menus have been screwed up ;-) etc. Also, if you have any 'install from source' programs, it's hit-or-miss as to whether they'll need to be recompiled, reinstalled and reconfigured, and in my 10 years experience, I've learned to never bring precompiled code from another platform over, even if the other platform is Fedora $(current-1). All this is fine, and I do it. But I'd like to avoid it for, let's say, a HTPC where installing and configuring mythtv is going to take weeks to do. David From fedora at dm.cobite.com Wed Jan 23 15:30:48 2008 From: fedora at dm.cobite.com (David Mansfield) Date: Wed, 23 Jan 2008 10:30:48 -0500 Subject: long term support release In-Reply-To: <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> Message-ID: <1201102248.3001.118.camel@gandalf.cobite.com> On Tue, 2008-01-22 at 20:59 -0900, Jeff Spaleta wrote: > On Jan 22, 2008 6:16 PM, David Mansfield wrote: > > Say the LTS cycle is one release every two years (every fourth Fedora > > release), and that the 'long term' for support only lasts for two years > > (which is pretty short to use the term long for, I realize), then there > > would only be one LTS release, and also the most current release to > > worry about at any given time. > > > > If there is simply not enough teampower to do this, then that's > > understood. > > > This has come up a lot recently. it seems the LTS acronym has gained > an impressive foothold in the collective psyche. I think its time I > put things in perspective for people who are requesting that Fedora as > a community project make the investment in this sort of thing. > > There seems to be a general lack of understanding that the Ubuntu LTS > exists ONLY because there is a business entity which is attempting to > make money from selling support services around the LTS release. That > entity is called Canonical. Canonical has a direct and compelling > business interest in selling support services for the Ubuntu LTS > release. > That LTS offering is NOT a community volunteer coordinated offering. > This not so subtle fact is very important to consider when making a > request to see a similar offering in the Fedora space. Especially > considering that Fedora Legacy was charted to feel this very void. > Here's what we learned, demand doesn't match willingness to > contribute. And thus, business opportunity is born. > Fair enough. I wasn't aware of the commercial aspect of the Ubuntu LTS and that is important to understand. Just to be sure, though, your thesis argument is: community supported software can do many things (ie. invent a kernel, reverse engineer usb cameras etc), but community can not support an operating system for 2 years? I think that people are falling back on the 'fedora legacy failed' argument, but I don't think it applies. I think that having one LTS release could be made to work. Here is an additional proposal Proposal: After the LTS release, wait 1 year (instead of 6 months) for the next Fedora release. This would allow for: a) 1 deeper dev cycle every x shallow dev cycles b) a longer time to let the LTS 'steep' and become mature, focusing core group attention on the current release instead of having them chomp at the bit for the next go. c) mitigate the 'many simultaneous releases to support' issue David From jkeating at redhat.com Wed Jan 23 15:33:36 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 23 Jan 2008 10:33:36 -0500 Subject: long term support release In-Reply-To: <1201101219.3001.98.camel@gandalf.cobite.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> Message-ID: <20080123103336.6e24109f@redhat.com> On Wed, 23 Jan 2008 10:13:39 -0500 David Mansfield wrote: > I think Fedora LTS would be: > - planned and built into the Fedora cycle and finally implemented > - only releases planned in advance to be LTS releases would be LTS > - there would only be one (or two) outstanding LTS releases at a time And you create the same problem. They won't be frequent enough to support today's hardware, and also if you constantly just do new versions of everything you lose the ability to support it long term as too much churn breaks things. To be fair, RHEL/CentOS does do limited hardware enablement in the update releases, like 5.0, 5.1, etc... -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From loupgaroublond at gmail.com Wed Jan 23 15:43:34 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 23 Jan 2008 10:43:34 -0500 Subject: long term support release In-Reply-To: <1201102182.3001.116.camel@gandalf.cobite.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <16de708d0801222002o51b7d771jaa8606128a11f93b@mail.gmail.com> <1201102182.3001.116.camel@gandalf.cobite.com> Message-ID: <7f692fec0801230743q28540ce1l48a0e99f36cf8ac1@mail.gmail.com> On Jan 23, 2008 10:29 AM, David Mansfield wrote: > I've found it takes quite a while to find out the latest problems with > the release (always wireless problems etc), get multimedia installed > correctly, find out how the menus have been screwed up ;-) etc. Also, > if you have any 'install from source' programs, it's hit-or-miss as to > whether they'll need to be recompiled, reinstalled and reconfigured, and > in my 10 years experience, I've learned to never bring precompiled code > from another platform over, even if the other platform is Fedora > $(current-1). > > All this is fine, and I do it. But I'd like to avoid it for, let's say, > a HTPC where installing and configuring mythtv is going to take weeks to > do. E_WORKSFORME No, really. This is a problem you will get with any and every OS, whether it is Wintendo or some random Linux distribution. If this is your number one priority, you'd probably best be served using OS X ;) On the other hand, making RPMs for your own personal use, setting up a build server, and pushing them to a private repo is pretty easy. You could spend that week automating that troublesome process for once and for all. But you'll never shake the fact that someone's machine is going to break in between releases, and it's impossible to test every single machine in the world in two years, let alone six months. -Yaakov From loupgaroublond at gmail.com Wed Jan 23 15:46:07 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 23 Jan 2008 10:46:07 -0500 Subject: long term support release In-Reply-To: <1201102248.3001.118.camel@gandalf.cobite.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> Message-ID: <7f692fec0801230746s39f89de3u8bd7ffd08e6959c3@mail.gmail.com> On Jan 23, 2008 10:30 AM, David Mansfield wrote: > Just to be sure, though, your thesis argument is: community supported > software can do many things (ie. invent a kernel, reverse engineer usb > cameras etc), but community can not support an operating system for 2 > years? I think that people are falling back on the 'fedora legacy > failed' argument, but I don't think it applies. It's actually a very different creative process to create a product and to support a product. Many of the hacking community are smart enough to do it, so companies tend to hire them, but if they enjoy creating a kernel as a hobbyist experiment, why would they be interested in making it work on some obscure piece of hardware sold only in Estonia and Zimbabwe, when they could be hacking on more interesting features for everyone? -Yaakov From eparis at redhat.com Wed Jan 23 15:52:19 2008 From: eparis at redhat.com (Eric Paris) Date: Wed, 23 Jan 2008 10:52:19 -0500 Subject: long term support release In-Reply-To: <20080123103336.6e24109f@redhat.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <20080123103336.6e24109f@redhat.com> Message-ID: <1201103539.3295.6.camel@localhost.localdomain> On Wed, 2008-01-23 at 10:33 -0500, Jesse Keating wrote: > On Wed, 23 Jan 2008 10:13:39 -0500 > David Mansfield wrote: > > > I think Fedora LTS would be: > > - planned and built into the Fedora cycle and finally implemented > > - only releases planned in advance to be LTS releases would be LTS > > - there would only be one (or two) outstanding LTS releases at a time > > And you create the same problem. They won't be frequent enough to > support today's hardware, and also if you constantly just do new > versions of everything you lose the ability to support it long term as > too much churn breaks things. > > To be fair, RHEL/CentOS does do limited hardware enablement in the > update releases, like 5.0, 5.1, etc... Limited? 5.2 basically has the latest upstream wireless stack. I think e1000 was bumped to latest upstream, and I know IPSec support was almost completely rereved. I know some of the block device drives had gigantic updates. Hardware enablements are a big part of the early RHEL life cycle (first 3 or 5 years can't really remember I don't do sales) If you have hardware that works in fedora and doesn't work in CentOS 5 feel free to file a bug. It might not get a lot of attention if you are the only person on earth with that piece of hardware, but RHEL (although very slow) enables lots of hardware every release. Admittedly you need a lot of patience waiting for updates if you have the fedora speed mindset.... -Eric From jwilson at redhat.com Wed Jan 23 15:56:09 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 23 Jan 2008 10:56:09 -0500 Subject: long term support release In-Reply-To: <20080123103336.6e24109f@redhat.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <20080123103336.6e24109f@redhat.com> Message-ID: <47976399.3010709@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: > On Wed, 23 Jan 2008 10:13:39 -0500 > David Mansfield wrote: > >> I think Fedora LTS would be: >> - planned and built into the Fedora cycle and finally implemented >> - only releases planned in advance to be LTS releases would be LTS >> - there would only be one (or two) outstanding LTS releases at a time > > And you create the same problem. They won't be frequent enough to > support today's hardware, and also if you constantly just do new > versions of everything you lose the ability to support it long term as > too much churn breaks things. > > To be fair, RHEL/CentOS does do limited hardware enablement in the > update releases, like 5.0, 5.1, etc... We do more than just limited hardware enablement, we actually do quite extensive hardware enablement, at least at the motherboard and cpu level (and usually at the storage and networking level as well). For example, the latest RHEL4 supports quad-core processors and the motherboard chipsets you commonly find such processors on. Sometimes only the most recent RHEL gets the bulk of the hardware enablement, but we do try to have a RHEL available to install on the latest server systems from all the big vendors, as well as a fair number of workstations and laptops. Honestly, in my eyes, RHEL/CentOS + EPEL >= Ubuntu LTS, and a separate Fedora LTS is completely unwarranted. RHEL5 is basically FC6 LTS. RHEL6 will basically be F9 LTS. And so on. - -- Jarod Wilson jwilson at redhat.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHl2OZtO+bni+75QMRAldwAKDfY4doTGbP3NC/XncEiC4un7vVgwCeLluD SNm9YsKeU2sbNRn7DfN0RpM= =Qu1I -----END PGP SIGNATURE----- From mjs at CLEMSON.EDU Wed Jan 23 16:07:05 2008 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Wed, 23 Jan 2008 11:07:05 -0500 Subject: SELinux removed from desktop cd spin? In-Reply-To: <479748E5.4050401@gmail.com> References: <64b14b300801161157j5e94174bjcd567591a9f3f407@mail.gmail.com> <20080116200333.GE15623@redhat.com> <64b14b300801161219q355d93b0jb57f91f48615591a@mail.gmail.com> <20080116202554.GF15623@redhat.com> <64b14b300801161235i4a4ed432h4f7b81ecefaf292b@mail.gmail.com> <7f692fec0801161717x3b0d77b9n9cd4a2dd939c6398@mail.gmail.com> <478F6C07.2050108@gmail.com> <1200617202.920.156.camel@calliope.phig.org> <47967CA7.3000604@fedoraproject.org> <47968081.5050903@gmail.com> <479684B6.8090405@fedoraproject.org> <4796AB86.5000107@gmail.com> <4796C58F.3070300@fedoraproject.org> <4796CD17.9010706@gmail.com> <4796D166.8060908@fedoraproject.org> <1201081556.17926.30.camel@vincent52.localdomain> <479748E5.4050401@gmail.com> Message-ID: <1201104425.28419.9.camel@vincent52.localdomain> On Wed, 2008-01-23 at 08:02 -0600, Les Mikesell wrote: > Matthew Saltzman wrote: > > >>> But the NSA would be at least as capable of introducing a hack that you > >>> could examine but not see as Ken Thompson: > >>> http://www.everything2.com/index.pl?node=Reflections%20On%20Trusting%20Trust > >>> > >>> I'd expect them to even be able to conspire with the CPU vendors to have > >>> certain undocumented opcode sequences do magical things. > >> Sure. You can believe whatever you want to. I am merely stating a fact > >> that the bar to do this with open source software is way higher than > >> proprietary software and in fact is the highest that anyone can > >> practically go. > > > > Also, in order to carry out a hack like that, you have to infect the > > toolchain somewhere along the line, so that everyone building the code > > is doing so with infected compilers.. With open-source code and an > > open-source toolchain, that seems pretty unlikely. > > > > Or are you suggesting, Les, that everyone's copy of gcc is derived from > > one built by the NSA and smuggled into RMS's lab at some point in its > > early history? > > How many people have contributed code and how much do you know about > them or their motives? But a more likely target would be the CPU Rahul's point (as I take it) is that at least OSS code gets a fair amount of peer review by a wide variety of people who don't necessarily share the NSA's nefarious motives. Way more than can be expected from proprietary code. (Think Diebold...) My point is that infecting an open-source toolchain is much harder than infecting a proprietary one, for the same reason. I'll certainly acknowledge that there is no such thing as perfect security. > companies since there are only a couple that matter and this could make > the compiler portion pretty much invisible. Is that any more paranoid > than thinking the major communication companies all have government taps > for everything passing through or that cell phones are all rigged so the > government can locate and listen at any time? Probably not... > -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From jkeating at redhat.com Wed Jan 23 16:08:46 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 23 Jan 2008 11:08:46 -0500 Subject: long term support release In-Reply-To: <47976399.3010709@redhat.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <20080123103336.6e24109f@redhat.com> <47976399.3010709@redhat.com> Message-ID: <20080123110846.07a10d05@redhat.com> On Wed, 23 Jan 2008 10:56:09 -0500 Jarod Wilson wrote: > We do more than just limited hardware enablement, we actually do quite > extensive hardware enablement, at least at the motherboard and cpu > level (and usually at the storage and networking level as well). For > example, the latest RHEL4 supports quad-core processors and the > motherboard chipsets you commonly find such processors on. Sometimes > only the most recent RHEL gets the bulk of the hardware enablement, > but we do try to have a RHEL available to install on the latest > server systems from all the big vendors, as well as a fair number of > workstations and laptops. > > Honestly, in my eyes, RHEL/CentOS + EPEL >= Ubuntu LTS, and a > separate Fedora LTS is completely unwarranted. RHEL5 is basically FC6 > LTS. RHEL6 will basically be F9 LTS. And so on. I say limited because we're not likely to pull the 2.6.25 kernel into RHEL5 and replace the 2.6.18 kernel. Sure we'll backport lots of it, and by the end of RHEL5's life our 2.6.18 kernel won't look much like 2.6.18, but there is a limit to what we'll do there. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buc at odusz.so-cdu.ru Wed Jan 23 16:12:16 2008 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Wed, 23 Jan 2008 19:12:16 +0300 Subject: long term support release In-Reply-To: <20080123150921.GB32532@jasmine.xos.nl> References: <1201058211.3001.79.camel@gandalf.cobite.com> <47972980.7000804@odu.neva.ru> <20080123150921.GB32532@jasmine.xos.nl> Message-ID: <47976760.9020108@odu.neva.ru> Jos Vos wrote: > On Wed, Jan 23, 2008 at 02:48:16PM +0300, Dmitry Butskoy wrote: > > >> Well, I actually use Fedora in a strong production environment (power >> control office). The current policy (the EOL of F is one month after >> the F) provides me one year LTS (assuming the release is per >> half-year). Thus I just skip one release, i.e. FC1-->FC3-->FC5-->F7 . >> >> One-year LTS is an acceptable compromise for me. But ideally, from the >> "production" point of view, I would prefer 9-month cycle (and hence >> 1.5year LTS) ... >> > > Wondering what the difference with using RHEL/CentOS + EPEL is then... > > For example, I use tickless kernel now (which seems to be fine on old slow machines), whereas RHEL still use and will use the old kernel. Ans so on... ~buc From jwilson at redhat.com Wed Jan 23 16:15:17 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 23 Jan 2008 11:15:17 -0500 Subject: long term support release In-Reply-To: <47976399.3010709@redhat.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <20080123103336.6e24109f@redhat.com> <47976399.3010709@redhat.com> Message-ID: <47976815.2010409@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jarod Wilson wrote: > Honestly, in my eyes, RHEL/CentOS + EPEL >= Ubuntu LTS, and a separate Fedora > LTS is completely unwarranted. RHEL5 is basically FC6 LTS. RHEL6 will > basically be F9 LTS. And so on. I'm reminded that I really shouldn't say "RHEL6 will basically be F9 LTS", as it might be interpreted as a promise or a fact. It is not. Its just me, some dumb guy who happens to have a @redhat.com email address, doing some math and extrapolating. RHEL3 was branched somewhere between Red Hat Linux 9 and FC1, RHEL4 was branched somewhere between FC2 and FC3, RHEL5 was branched just before FC6, so it would suggest RHEL6 will be branched somewhere in the F8 to F10 time-frame (which F9 is right in the middle of), but so far as I know, it'll be based on F13. - -- Jarod Wilson jwilson at redhat.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHl2gUtO+bni+75QMRAn2TAJ4+ENsZJTIInUrL/JXBGtMwoBZu5gCguM3D oSGYBRTxRrDeOimddRDCGAo= =1o/r -----END PGP SIGNATURE----- From jkeating at redhat.com Wed Jan 23 16:19:36 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 23 Jan 2008 11:19:36 -0500 Subject: long term support release In-Reply-To: <47976815.2010409@redhat.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <20080123103336.6e24109f@redhat.com> <47976399.3010709@redhat.com> <47976815.2010409@redhat.com> Message-ID: <20080123111936.30eba16f@redhat.com> On Wed, 23 Jan 2008 11:15:17 -0500 Jarod Wilson wrote: > it'll be based on F13 That's going to be one ugly release (: -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buc at odusz.so-cdu.ru Wed Jan 23 16:22:02 2008 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Wed, 23 Jan 2008 19:22:02 +0300 Subject: long term support release In-Reply-To: <20080123145053.GA23715@angus.ind.WPI.EDU> References: <1201058211.3001.79.camel@gandalf.cobite.com> <7f692fec0801221942x715523cal70423262eb09b4c0@mail.gmail.com> <1201060757.3001.96.camel@gandalf.cobite.com> <4796D766.8070009@gmail.com> <20080123145053.GA23715@angus.ind.WPI.EDU> Message-ID: <479769AA.2050903@odu.neva.ru> Chuck Anderson wrote: > On Tue, Jan 22, 2008 at 09:57:58PM -0800, Andrew Farris wrote: > >> David Mansfield wrote: >> >>> You're not suggesting I use the 'Other Well Known Distro' are you? >>> Seriously, though, on my latest laptop I tried CentOS 5, and it was >>> awful on a laptop. Synaptic problems, networkmanager problems, crappy >>> wireless support (out of date) etc. I killed it in about a week. I >>> also tried the Other distro and as a Fedora (and Red Hat Linux before >>> that) guy, it just doesn't do it for me. Old dog, new tricks. It >>> lasted about a month. That said, updating every 6 months doesn't do it >>> for me either. What's a Fedora lover to do? >>> >> You could skip every other Fedora release and get a full year between your >> upgrades, still getting the lastest security patches the whole time. F7 >> doesn't go to EOL until F9 releases. >> > > Not really. You have to wait ~6 months for the newest release to > stabalize before upgrading to it How do you decide whether the release is stabilized or not? After the 6 months, the next release is shipped, and normally it causes the less updates rate for the previous release. IOW, less number of updates (per week etc.) for the old release does not mean that such a release is stable, it just mean that the contributors are focused on the next release now. Actually, "the stability poin" for me is about 3 month after the release. ~buc From bpepple at fedoraproject.org Wed Jan 23 16:26:18 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 23 Jan 2008 11:26:18 -0500 Subject: Plan for tomorrows (20080124) FESCO meeting Message-ID: <1201105578.11814.2.camel@nixon> Hi, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 18:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCo-Meeting -- jds2001 -- http://fedoraproject.org/wiki/JonStanley/BugWorkflow /topic FESCo-Meeting -- New Features - http://fedoraproject.org/wiki/Features/Dashboard - poelcat * http://fedoraproject.org/wiki/Features/Upstart /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow, since we have a pretty full schedule). You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pp at ee.oulu.fi Wed Jan 23 16:27:50 2008 From: pp at ee.oulu.fi (Pekka Pietikainen) Date: Wed, 23 Jan 2008 18:27:50 +0200 Subject: long term support release In-Reply-To: <1201103539.3295.6.camel@localhost.localdomain> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <20080123103336.6e24109f@redhat.com> <1201103539.3295.6.camel@localhost.localdomain> Message-ID: <20080123162750.GA31024@ee.oulu.fi> On Wed, Jan 23, 2008 at 10:52:19AM -0500, Eric Paris wrote: > Limited? 5.2 basically has the latest upstream wireless stack. I think > e1000 was bumped to latest upstream, and I know IPSec support was almost > completely rereved. I know some of the block device drives had gigantic > very slow) enables lots of hardware every release. Admittedly you need > a lot of patience waiting for updates if you have the fedora speed > mindset.... A nice thing would be to have a public yum repo for these as they happen and not after they've gone through the full QA/release process (I know they're sometimes on people.redhat.com). Could also just be something based on Fedora kernels. Just the kernel + userspace that's absolutely required for the new kernel to work no matter what kernel config options you enable/disable (hopefully close to zero). If you need it, you enable it. If you don't, then stick with the base EL kernels. You'd lose "Enterprise" stability, sure. But at least you'd only be forced to reinstall when the userspace starts feeling obsolete, not in 6-12 months _always_ like Fedora. And WAY less effort required than trying to do something that's between EL and Fedora. -- Pekka Pietikainen From alan at redhat.com Wed Jan 23 16:34:06 2008 From: alan at redhat.com (Alan Cox) Date: Wed, 23 Jan 2008 11:34:06 -0500 Subject: hdX vs sdX on redhat/centos 5.x with ata_piix In-Reply-To: <47952995.9010706@bppiac.hu> References: <4794D5D0.8080508@bppiac.hu> <20080121174140.GB5373@devserv.devel.redhat.com> <47952995.9010706@bppiac.hu> Message-ID: <20080123163406.GA10023@devserv.devel.redhat.com> On Tue, Jan 22, 2008 at 12:24:05AM +0100, Farkas Levente wrote: > > Not without recompiling currently. > > can you tell what should i recompile? (i assume kernel:-) but change > which kernel config to same behavior as on fedora? Turn off CONFIG_IDE and rebuild the kernel From rdieter at math.unl.edu Wed Jan 23 16:33:58 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 23 Jan 2008 10:33:58 -0600 Subject: rpms/qt/devel .cvsignore, 1.26, 1.27 qt.spec, 1.146, 1.147 sources, 1.27, 1.28 References: <200801231558.m0NFwsBJ027236@cvs-int.fedora.redhat.com> Message-ID: Than Ngo (than) wrote: > Index: qt.spec > =================================================================== > RCS file: /cvs/extras/rpms/qt/devel/qt.spec,v > retrieving revision 1.146 > retrieving revision 1.147 > diff -u -r1.146 -r1.147 > --- qt.spec 26 Nov 2007 15:32:22 -0000 1.146 > +++ qt.spec 23 Jan 2008 15:58:17 -0000 1.147 > @@ -1,9 +1,9 @@ > Summary: The shared library for the Qt GUI toolkit. > Name: qt > -Version: 3.3.8 > -Release: 11%{?dist} > +Version: 3.3.8b > +Release: 1%{?dist} > Epoch: 1 > -License: GPL/QPL > +License: GPLv3 Make that, License: GPLv2 or GPLv3 please, to match reality. qt is definitely not GPLv3 only. -- Rex From vonbrand at inf.utfsm.cl Wed Jan 23 15:57:39 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Wed, 23 Jan 2008 12:57:39 -0300 Subject: long term support release In-Reply-To: <1201101219.3001.98.camel@gandalf.cobite.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> Message-ID: <200801231557.m0NFvd8d017187@laptop13.inf.utfsm.cl> David Mansfield wrote: > On Tue, 2008-01-22 at 20:24 -0800, Andrew Farris wrote: > > David Mansfield wrote: > > > I'm fairly new to this list so if this is flame-bait, then I apologize. > > > I was wondering whether there is any possibility of having the > > > occasional 'long term support' (LTS) release of Fedora (say one every > > > two years or something) so that users can settle down with the distro > > > and actually become productive with it. > > > > > > Say the LTS cycle is one release every two years (every fourth Fedora > > > release), and that the 'long term' for support only lasts for two years > > > (which is pretty short to use the term long for, I realize), then there > > > would only be one LTS release, and also the most current release to > > > worry about at any given time. > > > > > > If there is simply not enough teampower to do this, then that's > > > understood. > > That is essentially what was tried with the fedora legacy project > > (supporting eol fedora releases for a longer term) but there was not > > enough interest and support to keep it going. It did support RH9 and > > FC releases up to FC5 I think? > Almost the same. A few differences: > - that project was 'glued on' to an existing process instead of a part > of it No... it was one of the projects of the (not-RedHat) Fedora almost from the start. They supported pre-Fedora Red Hats. > - they came into the game with a number of releases to support already True. > - they wanted to support every release The idea was to support only those versions where interest was high enough to support the longer term maintenance. Each version had its fans, but none had enough longer term interest (say, more than 6 months after official EOL) to keep them going. Perhaps the latest Red Hat (9) had a bit more, but I suspect that had more to do with the name change than any objective reason. > I think Fedora LTS would be: > - planned and built into the Fedora cycle and finally implemented > - only releases planned in advance to be LTS releases would be LTS > - there would only be one (or two) outstanding LTS releases at a time As was offered, propose a SIG and gather people (lots of them!) to do the (hard, non-glamorous) work. O just go with RHEL/CentOS. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From vonbrand at inf.utfsm.cl Wed Jan 23 16:03:17 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Wed, 23 Jan 2008 13:03:17 -0300 Subject: long term support release In-Reply-To: <1201102248.3001.118.camel@gandalf.cobite.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> Message-ID: <200801231603.m0NG3HvK022529@laptop13.inf.utfsm.cl> David Mansfield wrote: [...] > I think that having one LTS release could be made to work. Here is an > additional proposal > > Proposal: > > After the LTS release, wait 1 year (instead of 6 months) for the next > Fedora release. This would allow for: Strongly against. If I get a new machine in between, half of it won't work unless I am careful not to get "new hardware". Plus the accumulated new packages and patches will make LTS + 1 (year) a veritable mess, so you'd be advised to wait for LTS + 2... all while the whining about outdated software in Fedora won't stop. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From vonbrand at inf.utfsm.cl Wed Jan 23 14:31:13 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Wed, 23 Jan 2008 11:31:13 -0300 Subject: long term support release In-Reply-To: <1201058211.3001.79.camel@gandalf.cobite.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> Message-ID: <200801231431.m0NEVD2Z022611@laptop13.inf.utfsm.cl> David Mansfield wrote: > I'm fairly new to this list so if this is flame-bait, then I apologize. > I was wondering whether there is any possibility of having the > occasional 'long term support' (LTS) release of Fedora (say one every > two years or something) so that users can settle down with the distro > and actually become productive with it. For that you can use RHEL or one of its clones (CentOS is my favorite right now). Fedora has too much on its plate as is, the resources to handle a LTS version too just aren't there. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From vonbrand at inf.utfsm.cl Wed Jan 23 15:38:21 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Wed, 23 Jan 2008 12:38:21 -0300 Subject: long term support release In-Reply-To: <47972980.7000804@odu.neva.ru> References: <1201058211.3001.79.camel@gandalf.cobite.com> <47972980.7000804@odu.neva.ru> Message-ID: <200801231538.m0NFcLAE031126@laptop13.inf.utfsm.cl> Dmitry Butskoy wrote: > David Mansfield wrote: > > I'm fairly new to this list so if this is flame-bait, then I apologize. > > I was wondering whether there is any possibility of having the > > occasional 'long term support' (LTS) release of Fedora (say one every > > two years or something) so that users can settle down with the distro > > and actually become productive with it. > > Well, I actually use Fedora in a strong production environment (power > control office). The current policy (the EOL of F is one month > after the F) provides me one year LTS (assuming the release is > per half-year). Thus I just skip one release, > i.e. FC1-->FC3-->FC5-->F7 . > > One-year LTS is an acceptable compromise for me. But ideally, from the > "production" point of view, I would prefer 9-month cycle (and hence > 1.5year LTS) ... While others are screaming that the very-latest (kernel|gcc|Gnome|KDE|...) won't show up for some /months/yet! Can't have it both ways, 6 months is a (reasonably) happy compromise... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From vonbrand at inf.utfsm.cl Wed Jan 23 14:41:58 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Wed, 23 Jan 2008 11:41:58 -0300 Subject: long term support release In-Reply-To: <1201060407.3001.91.camel@gandalf.cobite.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <1201058700.3221.21.camel@home-desk> <1201060407.3001.91.camel@gandalf.cobite.com> Message-ID: <200801231442.m0NEfxRq027589@laptop13.inf.utfsm.cl> David Mansfield wrote: > On Tue, 2008-01-22 at 19:25 -0800, Sean Bruno wrote: [...] > > To be honest, that's more or less what RHEL and the free rebuild CentOS > > are. > > Fedora is a sandbox of sorts. It's a place where applications come > > together and sometimes, where they come to die. :) > I use RHEL/CentOS extensively at work (versions 3, 4 and 5), and I'd > have to disagree about that. Tons of the 'cool' stuff that's in fedora > gets left out of RHEL/CentOS. Have you looked at EPEL? Much cool Fedora stuff ends up there. And if not, grabbing the SRPM and rebuilding is not /that/ hard either... > I don't know who decides what 'makes the > cut' for RHEL, but it certainly isn't the Fedora team. Small wonder... that is in the hands of the RHEL team ;-) > For example, gnumeric and git, both 'everyday' tools, are missing from > CentOS 5, AFAIK, but I'm talking about tons of other goodies. The RHEL > package selection process is too restrictive it would seem. RHEL is for production use, has to be rock-solid. Implies long-time commitment to the (minimalistic) package set shipped (even longer than the lifetime of a particular version). Fedora is bleeding edge, for adventurous users. "The kitchen sink and then some" is acceptable, as is "Oops, this didn't work out too well, let's try another approach/package in paralell/next time". > And I'm not really complaining about that. I think RHEL hits the target > exactly and I don't want it to change, but it's not a real recreational > desktop system, never was, never(?) will be. It's a server os and > possibly business 'productivity' desktop os. Yep. > Plus, by having an LTS release, it would encourage the value-add > packagers like livna and rpmforge to get on the bandwagon, and 'go long' > as well, so it would be possible to have a multimedia enabled system > that lasts more than 6 months. Fedora is about /freely distributable/ software, making it easier for "others" to give you the tools to break the law isn't in Fedora's charter (quite the contrary). -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From vonbrand at inf.utfsm.cl Wed Jan 23 16:53:50 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Wed, 23 Jan 2008 13:53:50 -0300 Subject: long term support release In-Reply-To: <20080123162750.GA31024@ee.oulu.fi> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <20080123103336.6e24109f@redhat.com> <1201103539.3295.6.camel@localhost.localdomain> <20080123162750.GA31024@ee.oulu.fi> Message-ID: <200801231653.m0NGrpZf013634@laptop13.inf.utfsm.cl> Pekka Pietikainen wrote: > On Wed, Jan 23, 2008 at 10:52:19AM -0500, Eric Paris wrote: > > Limited? 5.2 basically has the latest upstream wireless stack. I think > > e1000 was bumped to latest upstream, and I know IPSec support was almost > > completely rereved. I know some of the block device drives had gigantic > > > very slow) enables lots of hardware every release. Admittedly you need > > a lot of patience waiting for updates if you have the fedora speed > > mindset.... > A nice thing would be to have a public yum repo for these as they happen > and not after they've gone through the full QA/release process > (I know they're sometimes on people.redhat.com). That would mean keeping "RHEL stable" + "RHEL + Fedora updates that make sense"; twice (or thereabouts) the work, no gain. Won't happen. > Could also just be something based on Fedora kernels. Just the kernel + > userspace that's absolutely required for the new kernel to work no matter > what kernel config options you enable/disable (hopefully close to zero). If > you need it, you enable it. If you don't, then stick with the base EL > kernels. Ditto. > You'd lose "Enterprise" stability, sure. But that is exactly /the/ selling point of RHEL... the old Red Hat model didn't work too well because the result wasn't stable enough. > But at least you'd only be > forced to reinstall when the userspace starts feeling obsolete, not in > 6-12 months _always_ like Fedora. And WAY less effort required than trying to > do something that's between EL and Fedora. If you want it, pay for it. I.e., join the "Fedora LTS SIG" that was proposed here, and work to make it happen. You will see it is /much/ harder to do than it looks, and thankless work to boot. It is easier just to upgrade from time to time. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From cra at WPI.EDU Wed Jan 23 16:59:47 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 23 Jan 2008 11:59:47 -0500 Subject: long term support release In-Reply-To: <20080123111936.30eba16f@redhat.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <20080123103336.6e24109f@redhat.com> <47976399.3010709@redhat.com> <47976815.2010409@redhat.com> <20080123111936.30eba16f@redhat.com> Message-ID: <20080123165947.GG12464@angus.ind.WPI.EDU> On Wed, Jan 23, 2008 at 11:19:36AM -0500, Jesse Keating wrote: > On Wed, 23 Jan 2008 11:15:17 -0500 > Jarod Wilson wrote: > > > it'll be based on F13 > > That's going to be one ugly release (: Perhaps we should skip right to F14, just like some old buildings skip floor 13. From Jochen at herr-schmitt.de Wed Jan 23 16:59:38 2008 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 23 Jan 2008 17:59:38 +0100 Subject: Plan for tomorrows (20080124) FESCO meeting In-Reply-To: <1201105578.11814.2.camel@nixon> References: <1201105578.11814.2.camel@nixon> Message-ID: <0ML25U-1JHiww0JkI-0004KE@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 23 Jan 2008 11:26:18 -0500, you wrote: >/topic FESCo-Meeting -- New Features - >http://fedoraproject.org/wiki/Features/Dashboard - poelcat > * http://fedoraproject.org/wiki/Features/Upstart > I think you schould change the topic to "Which initscript replacement should we used for upcomming versions of Fedora" - From my point of view approving of this feature sound like make a dicission for use upstart as the new initscript replacement in Fedora. But when I read the article "Call To Choose An Initscript Replacement" on http://fedoraproject.org/wiki/FWN/Issue115 upstart will no be the canidate tor this task. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) Charset: us-ascii wj8DBQFHl3J6T2AHK6txfgwRAv73AKCN4YKlzR/AISRS+OgRGdsKHi+69gCgll8V hOoB1tYHJP/eRe6MepeiuZw= =sT8g -----END PGP SIGNATURE----- From vonbrand at inf.utfsm.cl Wed Jan 23 16:58:19 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Wed, 23 Jan 2008 13:58:19 -0300 Subject: rpms/qt/devel .cvsignore, 1.26, 1.27 qt.spec, 1.146, 1.147 sources, 1.27, 1.28 In-Reply-To: References: <200801231558.m0NFwsBJ027236@cvs-int.fedora.redhat.com> Message-ID: <200801231658.m0NGwJCP014115@laptop13.inf.utfsm.cl> Rex Dieter wrote: > Than Ngo (than) wrote: > > > Index: qt.spec > > =================================================================== > > RCS file: /cvs/extras/rpms/qt/devel/qt.spec,v > > retrieving revision 1.146 > > retrieving revision 1.147 > > diff -u -r1.146 -r1.147 > > --- qt.spec 26 Nov 2007 15:32:22 -0000 1.146 > > +++ qt.spec 23 Jan 2008 15:58:17 -0000 1.147 > > @@ -1,9 +1,9 @@ > > Summary: The shared library for the Qt GUI toolkit. > > Name: qt > > -Version: 3.3.8 > > -Release: 11%{?dist} > > +Version: 3.3.8b > > +Release: 1%{?dist} > > Epoch: 1 > > -License: GPL/QPL > > +License: GPLv3 > > Make that, > License: GPLv2 or GPLv3 > please, to match reality. qt is definitely not GPLv3 only. I understand it is QPL/GPLv2/GPLv3 now... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From rdieter at math.unl.edu Wed Jan 23 17:05:08 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 23 Jan 2008 11:05:08 -0600 Subject: rpms/qt/devel .cvsignore, 1.26, 1.27 qt.spec, 1.146, 1.147 sources, 1.27, 1.28 In-Reply-To: <200801231658.m0NGwJCP014115@laptop13.inf.utfsm.cl> References: <200801231558.m0NFwsBJ027236@cvs-int.fedora.redhat.com> <200801231658.m0NGwJCP014115@laptop13.inf.utfsm.cl> Message-ID: <479773C4.1020106@math.unl.edu> Horst H. von Brand wrote: > Rex Dieter wrote: >> Than Ngo (than) wrote: >> >>> Index: qt.spec >>> =================================================================== >>> RCS file: /cvs/extras/rpms/qt/devel/qt.spec,v >>> retrieving revision 1.146 >>> retrieving revision 1.147 >>> diff -u -r1.146 -r1.147 >>> --- qt.spec 26 Nov 2007 15:32:22 -0000 1.146 >>> +++ qt.spec 23 Jan 2008 15:58:17 -0000 1.147 >>> @@ -1,9 +1,9 @@ >>> Summary: The shared library for the Qt GUI toolkit. >>> Name: qt >>> -Version: 3.3.8 >>> -Release: 11%{?dist} >>> +Version: 3.3.8b >>> +Release: 1%{?dist} >>> Epoch: 1 >>> -License: GPL/QPL >>> +License: GPLv3 >> Make that, >> License: GPLv2 or GPLv3 >> please, to match reality. qt is definitely not GPLv3 only. > I understand it is QPL/GPLv2/GPLv3 now... True (applies to qt4 as well), I forget the reason why we chose to omit QPL from the License: field before. There was one, I just don't recall atm. -- Rex From drago01 at gmail.com Wed Jan 23 17:05:31 2008 From: drago01 at gmail.com (drago01) Date: Wed, 23 Jan 2008 18:05:31 +0100 Subject: preload In-Reply-To: <1201071580.6050.20.camel@localhost.localdomain> References: <1201071580.6050.20.camel@localhost.localdomain> Message-ID: <479773DB.1010707@gmail.com> Marc Wiriadisastra wrote: > Those people running preload can we get some benchmarks to see whether > there is a benefit and if so how much of a benefit there is. > > I ask this because I got a post on the from Rahul asking whether there > was any significant benefit running preload. I personally don't have any > numbers so I'm going to try and start to benchmark the information. > Well I tryed it and benchmarked it using bootchart and its even _worse_ then readahead that we decided to disable. No preload: 57 sec With preload: 1m 25sec ie. ~50% slowdown From dcbw at redhat.com Wed Jan 23 17:05:48 2008 From: dcbw at redhat.com (Dan Williams) Date: Wed, 23 Jan 2008 12:05:48 -0500 Subject: long term support release In-Reply-To: <200801231442.m0NEfxRq027589@laptop13.inf.utfsm.cl> References: <1201058211.3001.79.camel@gandalf.cobite.com> <1201058700.3221.21.camel@home-desk> <1201060407.3001.91.camel@gandalf.cobite.com> <200801231442.m0NEfxRq027589@laptop13.inf.utfsm.cl> Message-ID: <1201107948.4929.28.camel@localhost.localdomain> On Wed, 2008-01-23 at 11:41 -0300, Horst H. von Brand wrote: > David Mansfield wrote: > > On Tue, 2008-01-22 at 19:25 -0800, Sean Bruno wrote: > > [...] > > > > To be honest, that's more or less what RHEL and the free rebuild CentOS > > > are. > > > > Fedora is a sandbox of sorts. It's a place where applications come > > > together and sometimes, where they come to die. :) > > > I use RHEL/CentOS extensively at work (versions 3, 4 and 5), and I'd > > have to disagree about that. Tons of the 'cool' stuff that's in fedora > > gets left out of RHEL/CentOS. > > Have you looked at EPEL? Much cool Fedora stuff ends up there. And if not, > grabbing the SRPM and rebuilding is not /that/ hard either... > > > I don't know who decides what 'makes the > > cut' for RHEL, but it certainly isn't the Fedora team. > > Small wonder... that is in the hands of the RHEL team ;-) > > > For example, gnumeric and git, both 'everyday' tools, are missing from > > CentOS 5, AFAIK, but I'm talking about tons of other goodies. The RHEL > > package selection process is too restrictive it would seem. > > RHEL is for production use, has to be rock-solid. Implies long-time > commitment to the (minimalistic) package set shipped (even longer than the > lifetime of a particular version). Fedora is bleeding edge, for adventurous > users. "The kitchen sink and then some" is acceptable, as is "Oops, this > didn't work out too well, let's try another approach/package in > paralell/next time". Right; having the latest "cool stuff" and support for the latest hardware _by_definition_ is not going to be as stable as something that moves more slowly and waits for the bugs to get shaken out. You can't have it both ways. Either you pick "latest and greatest" or you pick "rock solid". If you try to compromise too much, you loose most of what makes both of those desirable. So you must essentially choose to focus on one of those two, and the other one will understandably suffer. Dan From fedora at dm.cobite.com Wed Jan 23 17:10:50 2008 From: fedora at dm.cobite.com (David Mansfield) Date: Wed, 23 Jan 2008 12:10:50 -0500 Subject: long term support release In-Reply-To: <200801231557.m0NFvd8d017187@laptop13.inf.utfsm.cl> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <200801231557.m0NFvd8d017187@laptop13.inf.utfsm.cl> Message-ID: <1201108250.3001.130.camel@gandalf.cobite.com> On Wed, 2008-01-23 at 12:57 -0300, Horst H. von Brand wrote: > David Mansfield wrote: > > On Tue, 2008-01-22 at 20:24 -0800, Andrew Farris wrote: > > > David Mansfield wrote: > > > > I'm fairly new to this list so if this is flame-bait, then I apologize. > > > > I was wondering whether there is any possibility of having the > > > > occasional 'long term support' (LTS) release of Fedora (say one every > > > > two years or something) so that users can settle down with the distro > > > > and actually become productive with it. > > > > > > > > Say the LTS cycle is one release every two years (every fourth Fedora > > > > release), and that the 'long term' for support only lasts for two years > > > > (which is pretty short to use the term long for, I realize), then there > > > > would only be one LTS release, and also the most current release to > > > > worry about at any given time. > > > > > > > > If there is simply not enough teampower to do this, then that's > > > > understood. > > > > That is essentially what was tried with the fedora legacy project > > > (supporting eol fedora releases for a longer term) but there was not > > > enough interest and support to keep it going. It did support RH9 and > > > FC releases up to FC5 I think? > > > Almost the same. A few differences: > > - that project was 'glued on' to an existing process instead of a part > > of it > > No... it was one of the projects of the (not-RedHat) Fedora almost from the > start. They supported pre-Fedora Red Hats. > > > - they came into the game with a number of releases to support already > > True. > > > - they wanted to support every release > > The idea was to support only those versions where interest was high enough > to support the longer term maintenance. Each version had its fans, but none > had enough longer term interest (say, more than 6 months after official > EOL) to keep them going. Perhaps the latest Red Hat (9) had a bit more, but > I suspect that had more to do with the name change than any objective > reason. > > > I think Fedora LTS would be: > > - planned and built into the Fedora cycle and finally implemented > > - only releases planned in advance to be LTS releases would be LTS > > - there would only be one (or two) outstanding LTS releases at a time > > As was offered, propose a SIG and gather people (lots of them!) to do the > (hard, non-glamorous) work. If such a proposal was made, it would involve changes to the workflow and cycle management of the core releases, even if the bulk of the support work is to be done by a separate group. Would such a proposal have a chance? David From jakub.rusinek at gmail.com Wed Jan 23 17:06:41 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Wed, 23 Jan 2008 18:06:41 +0100 Subject: preload In-Reply-To: <479773DB.1010707@gmail.com> References: <1201071580.6050.20.camel@localhost.localdomain> <479773DB.1010707@gmail.com> Message-ID: <1201108001.10189.20.camel@geeko> Dnia 23-01-2008, ?ro o godzinie 18:05 +0100, drago01 pisze: > Marc Wiriadisastra wrote: > > Those people running preload can we get some benchmarks to see whether > > there is a benefit and if so how much of a benefit there is. > > > > I ask this because I got a post on the from Rahul asking whether there > > was any significant benefit running preload. I personally don't have any > > numbers so I'm going to try and start to benchmark the information. > > > Well I tryed it and benchmarked it using bootchart and its even _worse_ > then readahead that we decided to disable. > > No preload: 57 sec > With preload: 1m 25sec > > ie. ~50% slowdown Strange... Preload shouldn't slow system down, but make it load faster... -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? wiadomo?ci podpisana cyfrowo URL: From jkeating at redhat.com Wed Jan 23 17:14:09 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 23 Jan 2008 12:14:09 -0500 Subject: long term support release In-Reply-To: <1201108250.3001.130.camel@gandalf.cobite.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <200801231557.m0NFvd8d017187@laptop13.inf.utfsm.cl> <1201108250.3001.130.camel@gandalf.cobite.com> Message-ID: <20080123121409.03a201c8@redhat.com> On Wed, 23 Jan 2008 12:10:50 -0500 David Mansfield wrote: > Would such a proposal > have a chance? Not likely, but I can't say that without a proposal in front of me. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dcbw at redhat.com Wed Jan 23 17:14:40 2008 From: dcbw at redhat.com (Dan Williams) Date: Wed, 23 Jan 2008 12:14:40 -0500 Subject: long term support release In-Reply-To: <1201108250.3001.130.camel@gandalf.cobite.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <200801231557.m0NFvd8d017187@laptop13.inf.utfsm.cl> <1201108250.3001.130.camel@gandalf.cobite.com> Message-ID: <1201108480.4929.40.camel@localhost.localdomain> On Wed, 2008-01-23 at 12:10 -0500, David Mansfield wrote: > On Wed, 2008-01-23 at 12:57 -0300, Horst H. von Brand wrote: > > David Mansfield wrote: > > > On Tue, 2008-01-22 at 20:24 -0800, Andrew Farris wrote: > > > > David Mansfield wrote: > > > > > I'm fairly new to this list so if this is flame-bait, then I apologize. > > > > > I was wondering whether there is any possibility of having the > > > > > occasional 'long term support' (LTS) release of Fedora (say one every > > > > > two years or something) so that users can settle down with the distro > > > > > and actually become productive with it. > > > > > > > > > > Say the LTS cycle is one release every two years (every fourth Fedora > > > > > release), and that the 'long term' for support only lasts for two years > > > > > (which is pretty short to use the term long for, I realize), then there > > > > > would only be one LTS release, and also the most current release to > > > > > worry about at any given time. > > > > > > > > > > If there is simply not enough teampower to do this, then that's > > > > > understood. > > > > > > That is essentially what was tried with the fedora legacy project > > > > (supporting eol fedora releases for a longer term) but there was not > > > > enough interest and support to keep it going. It did support RH9 and > > > > FC releases up to FC5 I think? > > > > > Almost the same. A few differences: > > > - that project was 'glued on' to an existing process instead of a part > > > of it > > > > No... it was one of the projects of the (not-RedHat) Fedora almost from the > > start. They supported pre-Fedora Red Hats. > > > > > - they came into the game with a number of releases to support already > > > > True. > > > > > - they wanted to support every release > > > > The idea was to support only those versions where interest was high enough > > to support the longer term maintenance. Each version had its fans, but none > > had enough longer term interest (say, more than 6 months after official > > EOL) to keep them going. Perhaps the latest Red Hat (9) had a bit more, but > > I suspect that had more to do with the name change than any objective > > reason. > > > > > I think Fedora LTS would be: > > > - planned and built into the Fedora cycle and finally implemented > > > - only releases planned in advance to be LTS releases would be LTS > > > - there would only be one (or two) outstanding LTS releases at a time > > > > As was offered, propose a SIG and gather people (lots of them!) to do the > > (hard, non-glamorous) work. > > If such a proposal was made, it would involve changes to the workflow > and cycle management of the core releases, even if the bulk of the > support work is to be done by a separate group. Would such a proposal > have a chance? I wouldn't expect it to have that many changes on the core cycle, because core would simply keep going on 6-month releases, while the LTS team could continue to handle the backports for the LTS release for another year after normal support was discontinued after about 12 - 15 months. Moving from a 6-month release cycle to a 1 year release cycle for even just one release isn't going to fly. Keeping the core release cycle constant and extending one particular release update lifetime might. Dan From fedora at dm.cobite.com Wed Jan 23 17:21:06 2008 From: fedora at dm.cobite.com (David Mansfield) Date: Wed, 23 Jan 2008 12:21:06 -0500 Subject: long term support release In-Reply-To: <20080123121409.03a201c8@redhat.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <200801231557.m0NFvd8d017187@laptop13.inf.utfsm.cl> <1201108250.3001.130.camel@gandalf.cobite.com> <20080123121409.03a201c8@redhat.com> Message-ID: <1201108866.3001.139.camel@gandalf.cobite.com> On Wed, 2008-01-23 at 12:14 -0500, Jesse Keating wrote: > On Wed, 23 Jan 2008 12:10:50 -0500 > David Mansfield wrote: > > > Would such a proposal > > have a chance? > > Not likely, but I can't say that without a proposal in front of me. > Ok. Thanks for listening. David From jwilson at redhat.com Wed Jan 23 17:29:23 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 23 Jan 2008 12:29:23 -0500 Subject: Wanted: FireWire testers In-Reply-To: <4787F211.3010402@redhat.com> References: <4787F211.3010402@redhat.com> Message-ID: <47977973.9020308@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jarod Wilson wrote: > If you're among those who have voiced concerns with the FireWire support in > Fedora, particularly in the audio/video area, please do try to test out the > latest rawhide kernels (2.6.24-0.149.fc7.git2.fc9 or later) and/or the > 2.6.23.13 kernel working its way through koji right now[1]. > > For the most part, dvgrab should be functional with these kernels, on all but > Via VT630x chipsets in OHCI 1.0 mode[2]. IIDC video streaming (such as > coriander + libdc1394 v2) should be fully functional on all OHCI 1.0 and 1.1 > FireWire controllers. > > As yet untested with this latest kernel is FireWire video capture off a cable > box[3], but that's on my todo list for the weekend. (There's reason to believe > this might be working now with the addition of dynamic buffer allocation). > > Additional feedback on other open FireWire bugs would be appreciated as > well[4][5]. Note that most of the enhancements added to the latest kernels are > on the a/v side, but I plan to start looking at storage more soon as well... > > [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=343219 > [2] https://bugzilla.redhat.com/show_bug.cgi?id=415841 > [3] https://bugzilla.redhat.com/show_bug.cgi?id=240774 > [4] https://bugzilla.redhat.com/show_bug.cgi?id=243081 > [5] https://bugzilla.redhat.com/show_bug.cgi?id=370931 Okay, we've made some significant progress on the storage front in the past week and a half now as well. The fixes aren't all yet into rawhide, but locally, I've now got multiple drives that used to hit either 'failed to login[6]' or 'giving up on config rom[7]' (both of which render the drive useless) now working perfectly. [6] https://bugzilla.redhat.com/show_bug.cgi?id=238606 [7] https://bugzilla.redhat.com/show_bug.cgi?id=429598 Stay tuned for test kernels if you've got storage issues... - -- Jarod Wilson jwilson at redhat.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHl3lztO+bni+75QMRAtSpAJ9bEvShYmXgmkGKHDTThz8vRMA0UgCgzx+X WuZs8BpSWifkLSWjyK1+DPs= =OxXm -----END PGP SIGNATURE----- From markg85 at gmail.com Wed Jan 23 17:31:36 2008 From: markg85 at gmail.com (Mark) Date: Wed, 23 Jan 2008 18:31:36 +0100 Subject: preload In-Reply-To: <1201108001.10189.20.camel@geeko> References: <1201071580.6050.20.camel@localhost.localdomain> <479773DB.1010707@gmail.com> <1201108001.10189.20.camel@geeko> Message-ID: <6e24a8e80801230931r70f98286sa8575bde3ef44b07@mail.gmail.com> 2008/1/23, Jakub 'Livio' Rusinek : > Dnia 23-01-2008, ?ro o godzinie 18:05 +0100, drago01 pisze: > > Marc Wiriadisastra wrote: > > > Those people running preload can we get some benchmarks to see whether > > > there is a benefit and if so how much of a benefit there is. > > > > > > I ask this because I got a post on the from Rahul asking whether there > > > was any significant benefit running preload. I personally don't have any > > > numbers so I'm going to try and start to benchmark the information. > > > > > Well I tryed it and benchmarked it using bootchart and its even _worse_ > > then readahead that we decided to disable. > > > > No preload: 57 sec > > With preload: 1m 25sec > > > > ie. ~50% slowdown > > Strange... Preload shouldn't slow system down, but make it load > faster... I'm getting crazy of your reply's.. And it's right that preload is making things slower. it needs to load them in the memory sometime. that time is in the boot progress. if your preload "database" is big than you will notice the slowdown in the boot but you will also notice the speedup in the applications (like firefox). I personally rather have a slow boot and for the rest fast responding applications than just a "slow" and slow applications. Btw i'm currently busy with benching and that really is irritating... nearly all the apps that i want to bench can't be benched with "time appname"! O well.. expect some results soon From atkac at redhat.com Wed Jan 23 17:35:34 2008 From: atkac at redhat.com (Adam Tkac) Date: Wed, 23 Jan 2008 18:35:34 +0100 Subject: long term support release In-Reply-To: <20080123150616.GC23715@angus.ind.WPI.EDU> References: <1201058211.3001.79.camel@gandalf.cobite.com> <7f692fec0801221942x715523cal70423262eb09b4c0@mail.gmail.com> <1201060757.3001.96.camel@gandalf.cobite.com> <4796D766.8070009@gmail.com> <20080123145053.GA23715@angus.ind.WPI.EDU> <20080123095443.130b7230@redhat.com> <20080123150616.GC23715@angus.ind.WPI.EDU> Message-ID: <20080123173534.GA10907@traged.englab.brq.redhat.com> On Wed, Jan 23, 2008 at 10:06:16AM -0500, Chuck Anderson wrote: > On Wed, Jan 23, 2008 at 09:54:43AM -0500, Jesse Keating wrote: > > On Wed, 23 Jan 2008 09:50:53 -0500 > > Chuck Anderson wrote: > > > > > Not really. You have to wait ~6 months for the newest release to > > > stabalize before upgrading to it, so that cuts down the maintained > > > lifetime to only 6 months. > > > > This is ridiculous BS that is self serving. If everybody waited until > > release+6M to try it out, the "safe" date would become release+12M, and > > so on. It's entirely a piss poor attitude and does nothing to better > > the project. > > Shipping software in a stable Fedora release that upstream considers > alpha-quality and not ready for production use contributes to a > perception that the stable Fedora release itself isn't stable or ready > for production. Please stop confusing people that F8 is unstable. If you have proof that some software in F8 is badly broken and is alpha version and stable release of that software is far more stable tell that sample here. We will tell to maintainer that this should never happen again. But blame something "because it is alpha" and only because alpha is very bad. Adam -- Adam Tkac, Red Hat, Inc. From jwboyer at gmail.com Wed Jan 23 17:33:21 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 23 Jan 2008 11:33:21 -0600 Subject: long term support release In-Reply-To: <1201108866.3001.139.camel@gandalf.cobite.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <200801231557.m0NFvd8d017187@laptop13.inf.utfsm.cl> <1201108250.3001.130.camel@gandalf.cobite.com> <20080123121409.03a201c8@redhat.com> <1201108866.3001.139.camel@gandalf.cobite.com> Message-ID: <20080123113321.22d4741c@zod.rchland.ibm.com> On Wed, 23 Jan 2008 12:21:06 -0500 David Mansfield wrote: > > On Wed, 2008-01-23 at 12:14 -0500, Jesse Keating wrote: > > On Wed, 23 Jan 2008 12:10:50 -0500 > > David Mansfield wrote: > > > > > Would such a proposal > > > have a chance? > > > > Not likely, but I can't say that without a proposal in front of me. > > > > Ok. > > Thanks for listening. He did. You said "changes to workflow and cycle management" without enumerating what those were. Since LTS is something that rel-eng isn't going to support, anything other than minor changes wouldn't likely be received well. But it's sort of hard to say "it might have a chance" when we don't even know what "it" is. We're willing to listen, but you have to actually say something first. josh From cjdahlin at ncsu.edu Wed Jan 23 17:44:39 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Wed, 23 Jan 2008 12:44:39 -0500 Subject: Virtual provides for window managers In-Reply-To: <1201027412.5468.0.camel@geeko> References: <47963A71.7030207@fedoraproject.org> <1201027541.2791.2.camel@localhost.localdomain> <1201027412.5468.0.camel@geeko> Message-ID: <47977D07.2060405@ncsu.edu> Jakub 'Livio' Rusinek wrote: > Dnia 22-01-2008, wto o godzinie 13:45 -0500, Matthias Clasen pisze: > >> On Wed, 2008-01-23 at 00:18 +0530, Rahul Sundaram wrote: >> >>> Hi >>> >>> System-config-display has a hard dependency on metacity while it is not >>> required at all in say the KDE or Xfce spin. I believe the ideal >>> solution would be to have add a virtual provides to all the window >>> managers and then depend on it from system-config-display >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=427814 >>> >>> What would be the best way to move ahead with this now? File individual >>> bug reports against each of them? >>> >> Have you checked why s-c-d has a dependency on metacity ?! >> >> It is there because it runs metacity if there is no X server/wm around. >> Having twm installed will help little for that... >> >> > > What about eg. fvwm instead of twm? twm doesn't look familiar for > GNOME/KDE user at all... > > Should we have a prefwm maybe? --CJD From fedora at dm.cobite.com Wed Jan 23 18:10:15 2008 From: fedora at dm.cobite.com (David Mansfield) Date: Wed, 23 Jan 2008 13:10:15 -0500 Subject: long term support release In-Reply-To: <20080123113321.22d4741c@zod.rchland.ibm.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <200801231557.m0NFvd8d017187@laptop13.inf.utfsm.cl> <1201108250.3001.130.camel@gandalf.cobite.com> <20080123121409.03a201c8@redhat.com> <1201108866.3001.139.camel@gandalf.cobite.com> <20080123113321.22d4741c@zod.rchland.ibm.com> Message-ID: <1201111815.3001.142.camel@gandalf.cobite.com> On Wed, 2008-01-23 at 11:33 -0600, Josh Boyer wrote: > On Wed, 23 Jan 2008 12:21:06 -0500 > David Mansfield wrote: > > > > > On Wed, 2008-01-23 at 12:14 -0500, Jesse Keating wrote: > > > On Wed, 23 Jan 2008 12:10:50 -0500 > > > David Mansfield wrote: > > > > > > > Would such a proposal > > > > have a chance? > > > > > > Not likely, but I can't say that without a proposal in front of me. > > > > > > > Ok. > > > > Thanks for listening. > > He did. You said "changes to workflow and cycle management" without > enumerating what those were. Since LTS is something that rel-eng isn't > going to support, anything other than minor changes wouldn't likely be > received well. But it's sort of hard to say "it might have a chance" > when we don't even know what "it" is. I was not being sarcastic. I have heard no additional support from my idea, and I'm just going to let it die. Almost every response was negative. I was literally thanking everyone for listening and taking the time to give honest and valid feedback. David From a.badger at gmail.com Wed Jan 23 18:12:50 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 23 Jan 2008 10:12:50 -0800 Subject: Plan for tomorrows (20080124) FESCO meeting In-Reply-To: <0ML25U-1JHiww0JkI-0004KE@mrelayeu.kundenserver.de> References: <1201105578.11814.2.camel@nixon> <0ML25U-1JHiww0JkI-0004KE@mrelayeu.kundenserver.de> Message-ID: <479783A2.5030901@gmail.com> Jochen Schmitt wrote: > On Wed, 23 Jan 2008 11:26:18 -0500, you wrote: > >> /topic FESCo-Meeting -- New Features - >> http://fedoraproject.org/wiki/Features/Dashboard - poelcat >> * http://fedoraproject.org/wiki/Features/Upstart > > > I think you schould change the topic to "Which initscript > replacement should we used for upcomming versions of Fedora" > > - From my point of view approving of this feature sound like make a > dicission for use upstart as the new initscript replacement in > Fedora. > It's not a feature unless a decision has been made and initscripts are replaced with something specific. > But when I read the article "Call To Choose An Initscript > Replacement" on http://fedoraproject.org/wiki/FWN/Issue115 > upstart will no be the canidate tor this task. > There is one thing lacking from that writeup and one additional point of information: 1) Looking into InitKit, people found that it is a specification for event-driven init systems and that upstart would be the main driver's implementation ground for that specification. So using upstart isn't as out-there as the writeup leaves it. 2) Casey Dahlin held a FUDCon session to discuss how to replace our current initsystem and is the driver of the feature. Perhaps Casey needs to tell us what was discussed at FUDCon so we are on the same page WRT where the discussion has gone. Casey? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jspaleta at gmail.com Wed Jan 23 18:16:30 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 23 Jan 2008 09:16:30 -0900 Subject: long term support release In-Reply-To: <1201102248.3001.118.camel@gandalf.cobite.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> Message-ID: <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> On Jan 23, 2008 6:30 AM, David Mansfield wrote: > Fair enough. I wasn't aware of the commercial aspect of the Ubuntu LTS > and that is important to understand. > > Just to be sure, though, your thesis argument is: community supported > software can do many things (ie. invent a kernel, reverse engineer usb > cameras etc), but community can not support an operating system for 2 > years? I think that people are falling back on the 'fedora legacy > failed' argument, but I don't think it applies. I would not say 'cannot'. I would say 'unwilling to'. This community is unwilling to devote enough effort to sustain an additional longer term branch. Every organization has its limits. One of the worst things a successful volunteer organization can do is overreach well past its available manpower and do too much with too little simply because they see a need in the community and want to make an impact. There are brick and mortar volunteer organization in my town right now that are learning the lesson the hard way. Watching a successful organization that is making a positive impact on the sorrounding community implode because the people in it care too much and don't know when to say 'we can't do this or that with the resources we have' is pretty painful to watch. I'll be damned if I sit on the Fedora project board and let this sort of unsustainable growth in responsibility doom the project. Legacy was not a failure... it was a key part of the process of defining what the limits are with the resources we have. Now that we have gone through that, the people who have survived the process have a much better idea of what it takes in terms of a resource commitment to pull it off. I have absolutely no problem with another attempt at community effort as a follow-up to what Legacy did. I just don't think its where this community of contributors wants to contribute. I think at a minimum there are 3rd support specialists out there with a business interest in a Fedora LTS, or perhaps niche hardware vendors in the embedded space which could be persuaded to leverage Fedora as a development platform. Lots of unexplored area. But I love being wrong, perhaps the community can go it alone now. Prove me wrong. if you seriously want it, then perhaps we can dig into institutional knowledge concerning Legacy's resource constraints as a starting point for you to starting putting the necessary resources together to make a serious stab at doing this. But it will take non-trivial effort. Legacy was a non-trivial affair and I'm not going to personal support an effort that isn't at least as organized and equipped as Legacy was. > > I think that having one LTS release could be made to work. Here is an > additional proposal > > Proposal: > > After the LTS release, wait 1 year (instead of 6 months) for the next > Fedora release. This would allow for: > > a) 1 deeper dev cycle every x shallow dev cycles > b) a longer time to let the LTS 'steep' and become mature, focusing core > group attention on the current release instead of having them chomp at > the bit for the next go. > c) mitigate the 'many simultaneous releases to support' issue I do not like this proposal. In fact I loath it. Why? because it delibrately takes focus away from the 'shallow' dev cycles. I do not think it is in the best interest to focus more attention on one release than another. Why? Because the components that we integrate all have their own timescales. We take a year out at one point and something like our Gnome or KDE ends up suffering as a result because that one component's development cycle isn't synced to our development cycle with a heart murmur. No, we must do all we can to hold the line on consistent time based releases so that upstream development projects can rely on us to be there and be ready to integrate their new bits every 6 months. The vast and varied development schedules of the upstream projects drives our need for consistency in release schedules. -jef From buc at odusz.so-cdu.ru Wed Jan 23 18:26:42 2008 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Wed, 23 Jan 2008 21:26:42 +0300 Subject: long term support release In-Reply-To: <20080123165947.GG12464@angus.ind.WPI.EDU> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <20080123103336.6e24109f@redhat.com> <47976399.3010709@redhat.com> <47976815.2010409@redhat.com> <20080123111936.30eba16f@redhat.com> <20080123165947.GG12464@angus.ind.WPI.EDU> Message-ID: <479786E2.2020004@odu.neva.ru> Chuck Anderson wrote: > > Perhaps we should skip right to F14, just like some old buildings skip > floor 13. > Don't expand your "locale" superstitions over all the World! :) By the way, the other locales can have their own superstitions... ~buc From jkeating at redhat.com Wed Jan 23 18:26:18 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 23 Jan 2008 13:26:18 -0500 Subject: long term support release In-Reply-To: <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> Message-ID: <20080123132618.0660f673@redhat.com> On Wed, 23 Jan 2008 09:16:30 -0900 "Jeff Spaleta" wrote: > Legacy was not a failure... it was a key part of the process of > defining what the limits are with the resources we have. Now that we > have gone through that, the people who have survived the process have > a much better idea of what it takes in terms of a resource commitment > to pull it off. > > I have absolutely no problem with another attempt at community effort > as a follow-up to what Legacy did. I just don't think its where this > community of contributors wants to contribute. I think at a minimum > there are 3rd support specialists out there with a business interest > in a Fedora LTS, or perhaps niche hardware vendors in the embedded > space which could be persuaded to leverage Fedora as a development > platform. Lots of unexplored area. It's perfectly OK to fail, in fact we should fail more often, and share the results of those failures. It's only by failure that we'll know the limits of our abilities. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at gmail.com Wed Jan 23 18:25:06 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 23 Jan 2008 12:25:06 -0600 Subject: long term support release In-Reply-To: <1201111815.3001.142.camel@gandalf.cobite.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <200801231557.m0NFvd8d017187@laptop13.inf.utfsm.cl> <1201108250.3001.130.camel@gandalf.cobite.com> <20080123121409.03a201c8@redhat.com> <1201108866.3001.139.camel@gandalf.cobite.com> <20080123113321.22d4741c@zod.rchland.ibm.com> <1201111815.3001.142.camel@gandalf.cobite.com> Message-ID: <20080123122506.5df53502@zod.rchland.ibm.com> On Wed, 23 Jan 2008 13:10:15 -0500 David Mansfield wrote: > > On Wed, 2008-01-23 at 11:33 -0600, Josh Boyer wrote: > > On Wed, 23 Jan 2008 12:21:06 -0500 > > David Mansfield wrote: > > > > > > > > On Wed, 2008-01-23 at 12:14 -0500, Jesse Keating wrote: > > > > On Wed, 23 Jan 2008 12:10:50 -0500 > > > > David Mansfield wrote: > > > > > > > > > Would such a proposal > > > > > have a chance? > > > > > > > > Not likely, but I can't say that without a proposal in front of me. > > > > > > > > > > Ok. > > > > > > Thanks for listening. > > > > He did. You said "changes to workflow and cycle management" without > > enumerating what those were. Since LTS is something that rel-eng isn't > > going to support, anything other than minor changes wouldn't likely be > > received well. But it's sort of hard to say "it might have a chance" > > when we don't even know what "it" is. > > I was not being sarcastic. I have heard no additional support from my > idea, and I'm just going to let it die. Almost every response was > negative. I was literally thanking everyone for listening and taking > the time to give honest and valid feedback. Ah, then in that case I apologize for my response. At times it is difficult to grasp subtle sarcasm from sincerity in emails, and I often lean towards sarcasm. I wouldn't walk away from your ideas. The reason people aren't falling head over heels for them is that LTS takes work. Lot's of unglamorous, often not fun work. If it's something you'd really like to see, then you'll have to really work at it to make it happen. If you do write up a proposal that takes the comments you've received so far into account then we'll listen. josh From rc040203 at freenet.de Wed Jan 23 18:35:31 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 23 Jan 2008 19:35:31 +0100 Subject: long term support release In-Reply-To: <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> Message-ID: <1201113331.17905.65.camel@beck.corsepiu.local> On Wed, 2008-01-23 at 09:16 -0900, Jeff Spaleta wrote: > On Jan 23, 2008 6:30 AM, David Mansfield wrote: > > Fair enough. I wasn't aware of the commercial aspect of the Ubuntu LTS > > and that is important to understand. > > > > > Just to be sure, though, your thesis argument is: community supported > > software can do many things (ie. invent a kernel, reverse engineer usb > > cameras etc), but community can not support an operating system for 2 > > years? I think that people are falling back on the 'fedora legacy > > failed' argument, but I don't think it applies. > > I would not say 'cannot'. I would say 'unwilling to'. This community > is unwilling to devote enough effort to sustain an additional longer > term branch. Well, what seem to missing: There are folks outside who believe to be able to maintain EPEL - I'd agree with you that they won't be able to provide the same quality as RH intends to do, esp. when RHEL will be heading towards their EOLs. Also: There had repeatedly expressed interest of volunteers to contribute to something like a Fedora LTS. Further: IMO, fedora legacy did not fail. It was discontinued by management, because it collided the certain business interests. Anyway, meanwhile, the "Fedora world" has changed. Technically, launching a Fedora LTS would not require uch more than introducing a community-accessible branch (formerly known as Fedora X) in CVS and to keep the buildsystem alive. > I have absolutely no problem with another attempt at community effort > as a follow-up to what Legacy did. I just don't think its where this > community of contributors wants to contribute. I disagree, c.f. above. In worst case, a Fedora LTS would end up as a rotten, broken, unstable distro, once having been "Fedora X". I don't see how this would be a regression of a discontinued "Fedora X". > I do not like this proposal. In fact I loath it. Why? because it > delibrately takes focus away from the 'shallow' dev cycles. If you're serious about this, you're probably better off to discontinue EPEL, because it "sucks off users" from Fedora. Ralf From atkac at redhat.com Wed Jan 23 18:36:24 2008 From: atkac at redhat.com (Adam Tkac) Date: Wed, 23 Jan 2008 19:36:24 +0100 Subject: long term support release In-Reply-To: <20080123165947.GG12464@angus.ind.WPI.EDU> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <20080123103336.6e24109f@redhat.com> <47976399.3010709@redhat.com> <47976815.2010409@redhat.com> <20080123111936.30eba16f@redhat.com> <20080123165947.GG12464@angus.ind.WPI.EDU> Message-ID: <20080123183624.GA13117@traged.englab.brq.redhat.com> On Wed, Jan 23, 2008 at 11:59:47AM -0500, Chuck Anderson wrote: > On Wed, Jan 23, 2008 at 11:19:36AM -0500, Jesse Keating wrote: > > On Wed, 23 Jan 2008 11:15:17 -0500 > > Jarod Wilson wrote: > > > > > it'll be based on F13 > > > > That's going to be one ugly release (: > > Perhaps we should skip right to F14, just like some old buildings skip > floor 13. > Yeah, don't try banter with such numbers :) Adam -- Adam Tkac, Red Hat, Inc. From lesmikesell at gmail.com Wed Jan 23 18:44:25 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 23 Jan 2008 12:44:25 -0600 Subject: long term support release In-Reply-To: <20080123173534.GA10907@traged.englab.brq.redhat.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <7f692fec0801221942x715523cal70423262eb09b4c0@mail.gmail.com> <1201060757.3001.96.camel@gandalf.cobite.com> <4796D766.8070009@gmail.com> <20080123145053.GA23715@angus.ind.WPI.EDU> <20080123095443.130b7230@redhat.com> <20080123150616.GC23715@angus.ind.WPI.EDU> <20080123173534.GA10907@traged.englab.brq.redhat.com> Message-ID: <47978B09.2020409@gmail.com> Adam Tkac wrote: > > Please stop confusing people that F8 is unstable. If you have proof > that some software in F8 is badly broken and is alpha version and > stable release of that software is far more stable tell that sample > here. We will tell to maintainer that this should never happen again. > But blame something "because it is alpha" and only because alpha is very > bad. Perhaps you missed the "long term" in the subject of this discussion... Even if today's version of F8 worked perfectly (which it probably doesn't, considering the complaints about audio on the list and the changes happening in firewire support) there is nothing long-term about it. One of the definitions of stable is 'unchanging' and no version of fedora has ever been stable in that respect. The other has to to with interface stability and not crashing - and fedora does not have a good history with these either. While most people probably care most about the latter type of stability here are reasons (like experience...) to expect the two concepts to be related and to expect new code to introduce new bugs. But, there are also two concepts relating to support, and I'm not quite sure which this thread is about. One is a stream of updates fixing the bugs in the code initially shipped - these are particularly important where security problems exist and have been made public. In fact it is unreasonable to even consider running a distribution past the time when you can get security updates on a machine exposed to the internet. Currently for enterprise versions with long term support, these updates introduce as little change as possible to avoid new bugs and unexpected behavior. However, that doesn't fit fedora's model of staying close to the upstream development work, so a fedora-style LTS might consist of building current-version replacements for anything that needs fixing and not involve a great deal of extra backporting effort. The other 'support' concept has to do with handholding and helping with individual user problems, which is what people really expect when they pay for free software. Which are we talking about here? -- Les Mikesell lesmikesell at gmail.com From cheese at nosuchhost.net Wed Jan 23 18:07:33 2008 From: cheese at nosuchhost.net (josef radinger) Date: Wed, 23 Jan 2008 19:07:33 +0100 Subject: pike packages Message-ID: <1201111653.4620.34.camel@cheese.daheim> Hello, I currently work on creating pike-packages. the next lines of text are shameless ripped from http://pike.ida.liu.se/about/ Pike is a general purpose programming language, which means that you can put it to use for almost any task. Its application domain spans anything from the world of the Net to the world of multimedia applications, or environments where your shell could use some spicy text processing or system administration tools. Your imagination sets the limit, but Pike will probably extend it far beyond what you previously considered within reach. the - in my opinion - main application using pike is caudium/roxen, which is a cool webserver, i personally use since years and love to use it. creating caudium-packages would be my next step. to be honest, there are problems too: there are not enough developers to keep up with new developments, but theses days this seems to improve and would improve further, if fedora-users would join in as deveopers AND as endusers (without the obstacle to compile pike). I would need someone willing to review the pike-packages. yours josef ps.: i did not send a link to the packages, as those are currently somewhat rough and i need to find some time to work around the biggestr problems, before showing them to the public. pps.: i wanted to send this after the packages where ready, but i never got to that point, and now i have to finish them, as hopefully i get some response from the list. ppps.: http://www.caudium.net is currently under rework From limb at jcomserv.net Wed Jan 23 19:18:38 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 23 Jan 2008 13:18:38 -0600 (CST) Subject: Xorg radeon drivers In-Reply-To: <20080118215217.GA6492@wolff.to> References: <1200631491.2150.2.camel@scrappy.miketc.com> <1200636379.29147.0.camel@localhost> <20080118084659.GB29940@wolff.to> <52636.192.168.0.1.1200654291.squirrel@mail.jcomserv.net> <20080118215217.GA6492@wolff.to> Message-ID: <57402.63.85.68.164.1201115918.squirrel@mail.jcomserv.net> > On Fri, Jan 18, 2008 at 05:04:51 -0600, > Jon Ciesla wrote: >> >> > I have had problems with xorg-x11-drv-ati-6.7.196-5.fc8 and have >> reverted >> > to >> > using xorg-x11-drv-ati-6.7.196-2.fc8. Though in my case I have a 9200, >> so >> > he might be better off with the updates-testing version, even though >> it >> > doesn't work for me. >> >> Now that's funny, I have a 9200, and I use the same driver, and I've >> been >> having bizarre symptoms that I've been trying to quanify properly for a >> BZ. Some things won't launch locally, or crash right away, but if I run >> the same app onthe same box remotely with either NX or X->ssh >> tunnelling, >> it displays fine on the other box. Is that anything like what you've >> been >> seeing? > > X doesn't properly start. I think there is an additional dependency in my > case that my old LCD display doesn't send an identifier that newer ones > do. > > I had problems when first upgrading to F8 that were solved with the -2 > update. > But when I upgraded to -5 then I had the problem reoccur. I didn't do > anything > to confirm it was really a regression and not a new bug. I just reverted > to > using -2. > Hmm. My problems were fixed by increasing my color depth. Very wierd. It displayed most things properly beforehand. -- novus ordo absurdum From fedora at leemhuis.info Wed Jan 23 19:24:32 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 23 Jan 2008 20:24:32 +0100 Subject: long term support release In-Reply-To: <47976399.3010709@redhat.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <20080123103336.6e24109f@redhat.com> <47976399.3010709@redhat.com> Message-ID: <47979470.6010507@leemhuis.info> On 23.01.2008 16:56, Jarod Wilson wrote: > Honestly, in my eyes, RHEL/CentOS + EPEL >= Ubuntu LTS, and a separate Fedora > LTS is completely unwarranted. Agreed. But the different names (Fedora != CentOS) make a very very big difference for a lot of people and the press. IOW: we might see RHEL/CentOS + EPEL as Fedora LTS, but for the world CentOS and Fedora are totally different things. CU knurd From behdad at behdad.org Wed Jan 23 19:31:52 2008 From: behdad at behdad.org (Behdad Esfahbod) Date: Wed, 23 Jan 2008 14:31:52 -0500 Subject: On preload In-Reply-To: <1201099357.25546.1.camel@localhost.localdomain> References: <1200838347.3569.2.camel@localhost.localdomain> <1200887077.18957.41.camel@behdad.behdad.org> <1201099357.25546.1.camel@localhost.localdomain> Message-ID: <1201116712.29177.24.camel@behdad.behdad.org> Hi all, Ok, I read the preload thread. Most of the questions asked are answered here: http://behdad.org/preload.pdf Chapters 6, 7, and 8 is what one needs to read. Random comments: - Yes, slows down boot. Can be "improved" by making preload less aggressive. In fact there are different knobs to allow setting aggressiveness at boot time and after separately. All documented in the config file and the above document. - Much of the slow down couldn't be avoided back in the day, but in the next version I'm using ionice to start preload. That should improve things. - One major thing that I'm not happy about in preload is that it doesn't readahead directories, nor does it readahead stat calls. And that's where the best bang for the memory is. Read Chapter 7. That's the advantage of SuSE preload over Fedora preload and Fedora readahead. SuSE preload uses a static list of course. There was a Google Summer of Code student working for Ubuntu this past summer trying to fix these and implement block reordering. Obviously that needs kernel patches. No idea where it got. - There's one place that no one can argue preloading is bad: after login screen is shown and before password entry is completed. GDM has a setting to hookup a prefetcher into it. It's worthwhile making preload be started then and shutdown for example 10 minutes after login. With some tricks and dances, one can make it do really awesome things in that idle period. - So far preload has been idling in kind of unmaintained state, though after Marc's interest in putting in Fedora I've now merged all the patches I received (ionice, merging requests, sorting based on block location, parallel fetching) and will make a new release sometime soonish. Note that also due to a silly bug, the current version doesn't sort request AT ALL. It's supposed to sort based on file name, but the compare function has a typo making it a noop. Anyway, people should read at least Chapter 7 and 8 of the PDF before discussing further. I'll try to get that release out in the mean time so measurements can be more meaningful. Cheers, behdad On Wed, 2008-01-23 at 23:42 +0900, Marc Wiriadisastra wrote: > Hey mate, > > Quick question do you have any data on benchmarks. Some people are > considering putting preload as a default application in Fedora. I agree > with them but I'm trying to benchmark some stuff and it's pretty hard to > actually get numbers. > > The other question which came from Rahul is " did you talk to behdad > about what improvements can be made to show some stats for example?" > Also any potential improvements in the next version? > > Cheers, > > Marc > On Sun, 2008-01-20 at 22:44 -0500, Behdad Esfahbod wrote: > > Thanks Marc. I unsubscribed from devel list and a slew of other ones a > > while ago when I figured that I'm not reading them anyway. > > > > Would be interesting to see what more people think of it. I have more > > of a reason to get that release out now :). > > > > Cheers, > > > > behdad > > > > On Sun, 2008-01-20 at 23:12 +0900, Marc Wiriadisastra wrote: > > > Hey Behdad, > > > > > > Not sure if you follow the devel list to much since I don't see you > > > posting to much. > > > > > > A preliminary review of preload from Linus. > > > > > > https://www.redhat.com/archives/fedora-devel-list/2008-January/msg01948.html > > > > > > Cheers, > > > > > > Marc -- behdad http://behdad.org/ "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin, 1759 From lesmikesell at gmail.com Wed Jan 23 19:47:19 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 23 Jan 2008 13:47:19 -0600 Subject: long term support release In-Reply-To: <47979470.6010507@leemhuis.info> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <20080123103336.6e24109f@redhat.com> <47976399.3010709@redhat.com> <47979470.6010507@leemhuis.info> Message-ID: <479799C7.8030400@gmail.com> Thorsten Leemhuis wrote: > On 23.01.2008 16:56, Jarod Wilson wrote: >> Honestly, in my eyes, RHEL/CentOS + EPEL >= Ubuntu LTS, and a separate Fedora >> LTS is completely unwarranted. > > Agreed. But the different names (Fedora != CentOS) make a very very big > difference for a lot of people and the press. IOW: we might see > RHEL/CentOS + EPEL as Fedora LTS, but for the world CentOS and Fedora > are totally different things. What I'd personally love to see is a split based on the odds of a problem crashing a previously working machine, picking the things that could crash the whole machine from the stable CentOS cut (kernel, device drivers, libc, etc.), then run the more current fedora versions of apps on top of that. If a single app crashes it is generally not a huge issue compared to kernel/driver breakage. I suppose the trendy way to accomplish this is with xen, but it seems like a waste to have to run two kernels just to keep one working. Perhaps a variation would be possible where you'd have a full, stock Centos installed, but by changing your PATH (which could be controlled per login) you'd actually run in an environment as fedora-like as possible on top of the CentOS kernel and libc. Disk space is cheap and I'd much prefer this kind of failsafe approach to a dual-boot system or running the experimental stuff under vmware or xen. -- Les Mikesell lesmikesell at gmail.com From ob.system at gmail.com Wed Jan 23 19:48:10 2008 From: ob.system at gmail.com (Oscar Victorio Calixto Bacho) Date: Wed, 23 Jan 2008 14:48:10 -0500 Subject: long term support release In-Reply-To: <47979470.6010507@leemhuis.info> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <20080123103336.6e24109f@redhat.com> <47976399.3010709@redhat.com> <47979470.6010507@leemhuis.info> Message-ID: <6a28481b0801231148ve792cbas6d5c60705e276544@mail.gmail.com> In the university we are building an fedora-based distribution (with new tool-chain fedora). LTS is one the goals. Oscar V Calixto -------------- next part -------------- An HTML attachment was scrubbed... URL: From skvidal at fedoraproject.org Wed Jan 23 19:55:47 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 23 Jan 2008 14:55:47 -0500 Subject: long term support release In-Reply-To: <1201113331.17905.65.camel@beck.corsepiu.local> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> Message-ID: <1201118147.6218.99.camel@cutter> On Wed, 2008-01-23 at 19:35 +0100, Ralf Corsepius wrote: > Further: IMO, fedora legacy did not fail. It was discontinued by > management, because it collided the certain business interests. Ralf, I know there's no way to convince you of this, however, this isn't at all what happened. Legacy just died. It wasn't decided or dictated by anyone other than the reality that nothing had happened for months. No one wanted to take on the rather large effort to keep it going. It stopped. There was no management who discontinued it. -sv From jspaleta at gmail.com Wed Jan 23 20:06:22 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 23 Jan 2008 11:06:22 -0900 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <1200900997.2845.12.camel@beck.corsepiu.local> References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> <1200766980.2961.8.camel@sb-home> <604aa7910801192136u754e6a4ex1c3c0113440c4e02@mail.gmail.com> <1200900997.2845.12.camel@beck.corsepiu.local> Message-ID: <604aa7910801231206x7d1a7471yf2158cefb68b0aeb@mail.gmail.com> On Jan 20, 2008 10:36 PM, Ralf Corsepius wrote: > A reporter should never be supposed to talk upstream, because he is > reporting an issue a problem with the product (your package) you are > supposed to be responsible for, not against the product an upstream > ships to you (the source tarball). I think you are wrong. Dead wrong. it does absolutely no good for me to attempt to act as a proxy for hardware breakage that I can't re-confirm with my own hardware. At some point the person experiencing the hardware problem has to be able to talk directly with a developer who is in a position to confirm and fix. Whether that means driving upstream developers to the fedora bugreport or driving users to upstream developers.... it doesn't matter. I refuse..REFUSE... to stop asking users with hardware specific breakage to be proactive and tap into the upstream resource when I can't confirm the problem. If there is a feature request that needs discussion, then why exactly should I as a maintainer be the one to champion it? If it's something i've no personal interest in it, nor have a personal need for it, then I'm certainly not in a position to argue for it. The stake holders for those sort of discussions are in the upstream development communication channels... that's where feature roadmapping happens...and that's where features have to be discussed and integrated. I'm not going to stand in proxy for someone else's ideas that do not resonate with me. Nor am I going to drop a request on the floor at the fedora package level, because I personally unmoved by a particular feature request. I'm not such an egotistical bastard that I'm going to assume that just because I'm not interested in the feature as the Fedora package maintainer that the upstream developers aren't. > What prevents you from simply telling the truth? I do tell the truth...sometimes upstream communication is a useful thing...and continuing to rely on me as the Fedora package maintainer to do all of it, is in fact a sub-optimal way of making sure things get done. I suck and I'll proudly and forthrightly tell people that. -jef From jspaleta at gmail.com Wed Jan 23 20:07:47 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 23 Jan 2008 11:07:47 -0900 Subject: long term support release In-Reply-To: <6a28481b0801231148ve792cbas6d5c60705e276544@mail.gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <20080123103336.6e24109f@redhat.com> <47976399.3010709@redhat.com> <47979470.6010507@leemhuis.info> <6a28481b0801231148ve792cbas6d5c60705e276544@mail.gmail.com> Message-ID: <604aa7910801231207o7d54d075k91a103114e801c6c@mail.gmail.com> 2008/1/23 Oscar Victorio Calixto Bacho : > In the university we are building an fedora-based distribution (with new > tool-chain fedora). > > LTS is one the goals. that's very interesting to here. Is there someone specifically at the University who is leading the project and would like to talk to the Fedora Board about it in more detail? -jef From mschwendt.tmp0701.nospam at arcor.de Wed Jan 23 20:10:55 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 23 Jan 2008 21:10:55 +0100 Subject: long term support release In-Reply-To: <1201113331.17905.65.camel@beck.corsepiu.local> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> Message-ID: <20080123211055.912fc3db.mschwendt.tmp0701.nospam@arcor.de> On Wed, 23 Jan 2008 19:35:31 +0100, Ralf Corsepius wrote: > Also: There had repeatedly expressed interest of volunteers to > contribute to something like a Fedora LTS. Maybe for packages in ex-Extras where you can upgrade versions as much as you like. But there are not enough volunteers to maintain core packages and do security-fixes. > Further: IMO, fedora legacy did not fail. It was discontinued by > management, because it collided the certain business interests. They failed because they couldn't keep up with the project's promises. Even copying patches from RHEL errata packages was too much work for the few volunteers. From limb at jcomserv.net Wed Jan 23 20:05:40 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 23 Jan 2008 14:05:40 -0600 (CST) Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <604aa7910801231206x7d1a7471yf2158cefb68b0aeb@mail.gmail.com> References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> <1200766980.2961.8.camel@sb-home> <604aa7910801192136u754e6a4ex1c3c0113440c4e02@mail.gmail.com> <1200900997.2845.12.camel@beck.corsepiu.local> <604aa7910801231206x7d1a7471yf2158cefb68b0aeb@mail.gmail.com> Message-ID: <45181.63.85.68.164.1201118740.squirrel@mail.jcomserv.net> > On Jan 20, 2008 10:36 PM, Ralf Corsepius wrote: >> A reporter should never be supposed to talk upstream, because he is >> reporting an issue a problem with the product (your package) you are >> supposed to be responsible for, not against the product an upstream >> ships to you (the source tarball). > > I think you are wrong. Dead wrong. > it does absolutely no good for me to attempt to act as a proxy for > hardware breakage that I can't re-confirm with my own hardware. At > some point the person experiencing the hardware problem has to be able > to talk directly with a developer who is in a position to confirm and > fix. Whether that means driving upstream developers to the fedora > bugreport or driving users to upstream developers.... it doesn't > matter. I refuse..REFUSE... to stop asking users with hardware > specific breakage to be proactive and tap into the upstream resource > when I can't confirm the problem. > > If there is a feature request that needs discussion, then why exactly > should I as a maintainer be the one to champion it? If it's something > i've no personal interest in it, nor have a personal need for it, then > I'm certainly not in a position to argue for it. The stake holders > for those sort of discussions are in the upstream development > communication channels... that's where feature roadmapping > happens...and that's where features have to be discussed and > integrated. I'm not going to stand in proxy for someone else's ideas > that do not resonate with me. Nor am I going to drop a request on the > floor at the fedora package level, because I personally unmoved by a > particular feature request. I'm not such an egotistical bastard that > I'm going to assume that just because I'm not interested in the > feature as the Fedora package maintainer that the upstream developers > aren't. > >> What prevents you from simply telling the truth? > > I do tell the truth...sometimes upstream communication is a useful > thing...and continuing to rely on me as the Fedora package maintainer > to do all of it, is in fact a sub-optimal way of making sure things > get done. I suck and I'll proudly and forthrightly tell people that. > > -jef I have to agree with jef. More communication is generally better. Some upstream devs are wonderful at troubleshooting bugs, and really make maintaining the package easier. Why not use all the resources available? > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From jkeating at redhat.com Wed Jan 23 20:18:18 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 23 Jan 2008 15:18:18 -0500 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <604aa7910801231206x7d1a7471yf2158cefb68b0aeb@mail.gmail.com> References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> <1200766980.2961.8.camel@sb-home> <604aa7910801192136u754e6a4ex1c3c0113440c4e02@mail.gmail.com> <1200900997.2845.12.camel@beck.corsepiu.local> <604aa7910801231206x7d1a7471yf2158cefb68b0aeb@mail.gmail.com> Message-ID: <20080123151818.02647429@redhat.com> On Wed, 23 Jan 2008 11:06:22 -0900 "Jeff Spaleta" wrote: > I think you are wrong. Dead wrong. > it does absolutely no good for me to attempt to act as a proxy for > hardware breakage that I can't re-confirm with my own hardware. At > some point the person experiencing the hardware problem has to be able > to talk directly with a developer who is in a position to confirm and > fix. Whether that means driving upstream developers to the fedora > bugreport or driving users to upstream developers.... it doesn't > matter. I refuse..REFUSE... to stop asking users with hardware > specific breakage to be proactive and tap into the upstream resource > when I can't confirm the problem. There is a huge difference between engaging the user and helping them to contact upstream, or getting upstream in contact with the user, basically facilitating that wonderful communication, and saying "Shut up, that's upstream, go away" and closing the bug. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From limb at jcomserv.net Wed Jan 23 20:20:01 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 23 Jan 2008 14:20:01 -0600 (CST) Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <20080123151818.02647429@redhat.com> References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> <1200766980.2961.8.camel@sb-home> <604aa7910801192136u754e6a4ex1c3c0113440c4e02@mail.gmail.com> <1200900997.2845.12.camel@beck.corsepiu.local> <604aa7910801231206x7d1a7471yf2158cefb68b0aeb@mail.gmail.com> <20080123151818.02647429@redhat.com> Message-ID: <62043.63.85.68.164.1201119601.squirrel@mail.jcomserv.net> > On Wed, 23 Jan 2008 11:06:22 -0900 > "Jeff Spaleta" wrote: > >> I think you are wrong. Dead wrong. >> it does absolutely no good for me to attempt to act as a proxy for >> hardware breakage that I can't re-confirm with my own hardware. At >> some point the person experiencing the hardware problem has to be able >> to talk directly with a developer who is in a position to confirm and >> fix. Whether that means driving upstream developers to the fedora >> bugreport or driving users to upstream developers.... it doesn't >> matter. I refuse..REFUSE... to stop asking users with hardware >> specific breakage to be proactive and tap into the upstream resource >> when I can't confirm the problem. > > There is a huge difference between engaging the user and helping them > to contact upstream, or getting upstream in contact with the user, > basically facilitating that wonderful communication, and saying "Shut > up, that's upstream, go away" and closing the bug. Very true, it MUST be a collaborative exercise. > -- > Jesse Keating > Fedora -- All my bits are free, are yours? > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- novus ordo absurdum From ob.system at gmail.com Wed Jan 23 20:31:07 2008 From: ob.system at gmail.com (Oscar Victorio Calixto Bacho) Date: Wed, 23 Jan 2008 15:31:07 -0500 Subject: long term support release In-Reply-To: <604aa7910801231207o7d54d075k91a103114e801c6c@mail.gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <20080123103336.6e24109f@redhat.com> <47976399.3010709@redhat.com> <47979470.6010507@leemhuis.info> <6a28481b0801231148ve792cbas6d5c60705e276544@mail.gmail.com> <604aa7910801231207o7d54d075k91a103114e801c6c@mail.gmail.com> Message-ID: <6a28481b0801231231r498453ect19540c3c10659297@mail.gmail.com> 2008/1/23, Jeff Spaleta : > > 2008/1/23 Oscar Victorio Calixto Bacho : > > In the university we are building an fedora-based distribution (with new > > tool-chain fedora). > > > > LTS is one the goals. > > that's very interesting to here. Is there someone specifically at the > University who is leading the project and would like to talk to the > Fedora Board about it in more detail? > > -jef > I am -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschwendt.tmp0701.nospam at arcor.de Wed Jan 23 20:47:36 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 23 Jan 2008 21:47:36 +0100 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <604aa7910801231206x7d1a7471yf2158cefb68b0aeb@mail.gmail.com> References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> <1200766980.2961.8.camel@sb-home> <604aa7910801192136u754e6a4ex1c3c0113440c4e02@mail.gmail.com> <1200900997.2845.12.camel@beck.corsepiu.local> <604aa7910801231206x7d1a7471yf2158cefb68b0aeb@mail.gmail.com> Message-ID: <20080123214736.d56c15a7.mschwendt.tmp0701.nospam@arcor.de> On Wed, 23 Jan 2008 11:06:22 -0900, Jeff Spaleta wrote: > On Jan 20, 2008 10:36 PM, Ralf Corsepius wrote: > > A reporter should never be supposed to talk upstream, because he is > > reporting an issue a problem with the product (your package) you are > > supposed to be responsible for, not against the product an upstream > > ships to you (the source tarball). > > I think you are wrong. Dead wrong. > it does absolutely no good for me to attempt to act as a proxy for > hardware breakage that I can't re-confirm with my own hardware. -snip- And with regard to many bugs you can reproduce, which do not require special hardware, Ralf is right. Even in the specific case you outline above you are supposed to notify upstream developers about the problem yourself. Because if you don't, and if the user does not report the problem upstream, the product *you* ship might remain broken. From smooge at gmail.com Wed Jan 23 20:47:52 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 23 Jan 2008 13:47:52 -0700 Subject: long term support release In-Reply-To: <604aa7910801222224i31460362qac428b542bdc4ad2@mail.gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <80d7e4090801222212y77462018te92a2b08e130b6fc@mail.gmail.com> <604aa7910801222224i31460362qac428b542bdc4ad2@mail.gmail.com> Message-ID: <80d7e4090801231247v2ebb8d33ue43d707394340100@mail.gmail.com> On Jan 22, 2008 11:24 PM, Jeff Spaleta wrote: > On Jan 22, 2008 9:12 PM, Stephen John Smoogen wrote: > > I worked out the numbers for doing that at one time.. and it wasn't > > pretty... especially when people want all of Fedora to be supported > > for 2 years. The best price I came to was 2x what Red Hat charges for > > an RHEL license to cover basic costs.. if a company wanted to actually > > stay in business it was a lot more... especially when you would need > > to make sure you had at least 200 paying customers. Cutting down the > > supported packages basically brought it down to a much smaller segment > > than what is in RHEL before you could get what most fedora users would > > consider reasonable (say 50/year). > > There's a lesson here. Did you do the same calculation assuming you > incorporated your company on the Isle of Man for tax benefit purposes > to see if the numbers became profittable? What if you started off with > a multi-million dollar venture capital injection and had 10 years to > get to profitability? > While I would love to have an office on the Isle of Man (my grandfather always said it was the best place for racing motorcycles, and the weather fits my temperment..) I didnt use it. Basically the make or break of it was how much capital I could have at the beginning and how long it was before I was 'profitable'. Even trying to do it non-profit still needed a large amount of core money before I could get a 'revenue stream'. The big issue is how many packages can an engineer handle in fixing bugs. There are over 4800 packages in 8.. which would be needing somewhere between 100-200 core coders, qa testers, tech support etc. Using very cheap engineers at an overhead cost of 100k (salary, benefits, housing, electricity, servers, etc) that came out as ~10 million a year in costs. At an online 'box' price of say $50.00/year I would need to clear 400,000 sales per year to be almost profitable. [While it might look like I need 200,000.. the fuzzy math of taxes, marketing, partner costs.. discounts for special users etc.. it cuts down to about 1/2 in most real world if you are doing good] I could cut down the number of packages that were supported but that would just make it so that there were less packages per developer (I mean who is able to code, bug-fix, triage 24-48 packages full time?) I would need to bring up the price and lower the number of packages down to the point were I was basically supporting RHEL :). Or just supporting the 'Extras' part of it. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From benny+usenet at amorsen.dk Wed Jan 23 20:48:20 2008 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Wed, 23 Jan 2008 21:48:20 +0100 Subject: long term support release References: <1201058211.3001.79.camel@gandalf.cobite.com> <47972980.7000804@odu.neva.ru> <20080123150921.GB32532@jasmine.xos.nl> Message-ID: Jos Vos writes: > On Wed, Jan 23, 2008 at 02:48:16PM +0300, Dmitry Butskoy wrote: >> One-year LTS is an acceptable compromise for me. But ideally, from the >> "production" point of view, I would prefer 9-month cycle (and hence >> 1.5year LTS) ... > > Wondering what the difference with using RHEL/CentOS + EPEL is then... RHEL and its derivatives, just like SUSE and Debian Stable, are comparatively conservative. I need e.g. working QinQ, and that means a 2.6.23 kernel. There's also a lot of software missing in RHEL -- like OpenSwan and Asterisk. If you update and add components to RHEL, you're going to lose out on support, as far as I know. (If I'm wrong and some enterprise distro maker is willing to offer support for OpenSwan and kernel 2.6.23, I'd be very happy to hear about it.) Fedora is very useful in production. It takes a bit more babysitting perhaps, but overall quality for server use is pretty good. /Benny From smooge at gmail.com Wed Jan 23 20:53:14 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 23 Jan 2008 13:53:14 -0700 Subject: long term support release In-Reply-To: <20080123095443.130b7230@redhat.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <7f692fec0801221942x715523cal70423262eb09b4c0@mail.gmail.com> <1201060757.3001.96.camel@gandalf.cobite.com> <4796D766.8070009@gmail.com> <20080123145053.GA23715@angus.ind.WPI.EDU> <20080123095443.130b7230@redhat.com> Message-ID: <80d7e4090801231253k354fe83ep74d1b067582be28b@mail.gmail.com> 2008/1/23 Jesse Keating : > On Wed, 23 Jan 2008 09:50:53 -0500 > Chuck Anderson wrote: > > > Not really. You have to wait ~6 months for the newest release to > > stabalize before upgrading to it, so that cuts down the maintained > > lifetime to only 6 months. > > This is ridiculous BS that is self serving. If everybody waited until > release+6M to try it out, the "safe" date would become release+12M, and > so on. It's entirely a piss poor attitude and does nothing to better > the project. > Well in a large scale enterprise setting it could be 6 months BUT NOT because of stability issues on Fedora side. Documenting, coming up with security plans, support procedures for internal help desk, testing that software works with internal applications etc usually took us 2 months on EL with a lot of stuff 'fluffed' over as done by upstream. In a Fedora setting it took a lot longer as we couldn't say that there was a commercial entity doing that testing for us. Of course that would also mean that the packages that came out for Fedora 8 would only get backported fixes etc versus getting updates to the latest and greatest. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From benny+usenet at amorsen.dk Wed Jan 23 20:54:09 2008 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Wed, 23 Jan 2008 21:54:09 +0100 Subject: long term support release References: <1201058211.3001.79.camel@gandalf.cobite.com> <7f692fec0801221942x715523cal70423262eb09b4c0@mail.gmail.com> <1201060757.3001.96.camel@gandalf.cobite.com> <4796D766.8070009@gmail.com> <20080123145053.GA23715@angus.ind.WPI.EDU> Message-ID: Chuck Anderson writes: > Not really. You have to wait ~6 months for the newest release to > stabalize before upgrading to it, so that cuts down the maintained > lifetime to only 6 months. Only if you expect others to do testing for you. Fedora requires you to be more vigilant with updates, and not just rely on someone else to find all the bugs before you do. On the other hand you get everything while it's still fresh and shiny! /Benny From smooge at gmail.com Wed Jan 23 20:56:30 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 23 Jan 2008 13:56:30 -0700 Subject: long term support release In-Reply-To: <1201101626.3001.107.camel@gandalf.cobite.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <1201062084.8306.3.camel@localhost6.localdomain6> <1201101626.3001.107.camel@gandalf.cobite.com> Message-ID: <80d7e4090801231256m4c930521g249d6ec7a238f2c0@mail.gmail.com> On Jan 23, 2008 8:20 AM, David Mansfield wrote: > > On Tue, 2008-01-22 at 21:21 -0700, Richi Plana wrote: > > On Tue, 2008-01-22 at 22:16 -0500, David Mansfield wrote: > > > Say the LTS cycle is one release every two years (every fourth Fedora > > > release), and that the 'long term' for support only lasts for two years > > > (which is pretty short to use the term long for, I realize), then there > > > would only be one LTS release, and also the most current release to > > > worry about at any given time. > > > > I was about to say that that is exactly what RHEL-to-CentOS is for, but > > thinking about it, I think I know what your problem is with CentOS. > > > > One thing not factored with CentOS is how old it is compared to the > > version of Fedora that it's supposed to be based upon. If I understand > > you correctly, your concept of LTS is based on the Final stable release > > of Fedora and will be supported for two years as opposed to some version > > of CentOS which upon release is probably years behind the final release > > of rawhide it was based on and therefore obsolete with hardware (which > > also has a fast release cycle). (Could someone do the math?) > > > > Did I understand your problem correctly? > > That's certainly a big part of it. A big part. You're right, when > Fedora comes out, it's at least current for the hardware of the day, but > when CentOS does come out with a major release, it's not even going to > work right on that same hardware, let alone new hardware that comes out > later. > > Also, there are quirks that appear in the EL spins that weren't there in > the Fedora releases. One example is some weird synaptic touchpad > problem I had that was only on the EL kernels. Is that ever going to > get fixed? No, it's not even a bug in the synaptic code, its somewhere > else. That's just an example though. > If its a bug in the kernel or EL shipped hardware it should be fixed (if Red Hat knows about it) I don't know what the problem is exactly as the few synaptics touchpads I have worked with 5.0 and 5.1. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From alan at redhat.com Wed Jan 23 21:06:18 2008 From: alan at redhat.com (Alan Cox) Date: Wed, 23 Jan 2008 16:06:18 -0500 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <62043.63.85.68.164.1201119601.squirrel@mail.jcomserv.net> References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> <1200766980.2961.8.camel@sb-home> <604aa7910801192136u754e6a4ex1c3c0113440c4e02@mail.gmail.com> <1200900997.2845.12.camel@beck.corsepiu.local> <604aa7910801231206x7d1a7471yf2158cefb68b0aeb@mail.gmail.com> <20080123151818.02647429@redhat.com> <62043.63.85.68.164.1201119601.squirrel@mail.jcomserv.net> Message-ID: <20080123210618.GA21303@devserv.devel.redhat.com> On Wed, Jan 23, 2008 at 02:20:01PM -0600, Jon Ciesla wrote: > >> specific breakage to be proactive and tap into the upstream resource > >> when I can't confirm the problem. > > > > There is a huge difference between engaging the user and helping them > > to contact upstream, or getting upstream in contact with the user, > > basically facilitating that wonderful communication, and saying "Shut > > up, that's upstream, go away" and closing the bug. > > Very true, it MUST be a collaborative exercise. I try to leave the RH bug open and even if I report it being an upstream problem then update it now and again with the status of things. That way people at least know something is happening and when it will be worth trying an update From cmadams at hiwaay.net Wed Jan 23 21:11:31 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 23 Jan 2008 15:11:31 -0600 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <20080123210618.GA21303@devserv.devel.redhat.com> References: <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> <1200766980.2961.8.camel@sb-home> <604aa7910801192136u754e6a4ex1c3c0113440c4e02@mail.gmail.com> <1200900997.2845.12.camel@beck.corsepiu.local> <604aa7910801231206x7d1a7471yf2158cefb68b0aeb@mail.gmail.com> <20080123151818.02647429@redhat.com> <62043.63.85.68.164.1201119601.squirrel@mail.jcomserv.net> <20080123210618.GA21303@devserv.devel.redhat.com> Message-ID: <20080123211131.GD1412626@hiwaay.net> Once upon a time, Alan Cox said: > I try to leave the RH bug open and even if I report it being an upstream > problem then update it now and again with the status of things. That way > people at least know something is happening and when it will be worth trying > an update Sometimes the RH bug owner _is_ upstream; I reported a bug in hal-info data and didn't get a response yet, so I opened a bug upstream. I think it ended up owned by the same person. One argument in favor of having the package owner report bugs upstream is they presumably have a better idea about how and where, have bugzilla accounts, etc. They can filter the reports (so when Fedora users open 10 RH bug entries for the same problem, upstream only has to deal with one report). The package owner will also need to know when the bug has been fixed to make an update (in some cases, end-users may need a package owner to help build test packages as well). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From cjdahlin at ncsu.edu Wed Jan 23 21:06:17 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Wed, 23 Jan 2008 16:06:17 -0500 Subject: preload In-Reply-To: <6e24a8e80801230931r70f98286sa8575bde3ef44b07@mail.gmail.com> References: <1201071580.6050.20.camel@localhost.localdomain> <479773DB.1010707@gmail.com> <1201108001.10189.20.camel@geeko> <6e24a8e80801230931r70f98286sa8575bde3ef44b07@mail.gmail.com> Message-ID: <4797AC49.2080205@ncsu.edu> Mark wrote: > 2008/1/23, Jakub 'Livio' Rusinek : > >> Dnia 23-01-2008, ?ro o godzinie 18:05 +0100, drago01 pisze: >> >>> Marc Wiriadisastra wrote: >>> >>>> Those people running preload can we get some benchmarks to see whether >>>> there is a benefit and if so how much of a benefit there is. >>>> >>>> I ask this because I got a post on the from Rahul asking whether there >>>> was any significant benefit running preload. I personally don't have any >>>> numbers so I'm going to try and start to benchmark the information. >>>> >>>> >>> Well I tryed it and benchmarked it using bootchart and its even _worse_ >>> then readahead that we decided to disable. >>> >>> No preload: 57 sec >>> With preload: 1m 25sec >>> >>> ie. ~50% slowdown >>> >> Strange... Preload shouldn't slow system down, but make it load >> faster... >> > > I'm getting crazy of your reply's.. > And it's right that preload is making things slower. it needs to load > them in the memory sometime. that time is in the boot progress. if > your preload "database" is big than you will notice the slowdown in > the boot but you will also notice the speedup in the applications > (like firefox). > > I personally rather have a slow boot and for the rest fast responding > applications than just a "slow" and slow applications. > > Btw i'm currently busy with benching and that really is irritating... > nearly all the apps that i want to bench can't be benched with "time > appname"! > > O well.. expect some results soon > > I just blogged a partial solution to your benching problem: http://screwyouenterpriseedition.blogspot.com/2008/01/timing-application-startup.html Tell me what you think. (Code format is due to blogger lacking some things I'd rather it had). --CJD From cebbert at redhat.com Wed Jan 23 21:22:46 2008 From: cebbert at redhat.com (Chuck Ebbert) Date: Wed, 23 Jan 2008 16:22:46 -0500 Subject: ConsoleKit vs udev, ACLs getting lost In-Reply-To: <1199362047.3744.32.camel@cyberelk.elk> References: <1199362047.3744.32.camel@cyberelk.elk> Message-ID: <4797B026.3040402@redhat.com> On 01/03/2008 07:07 AM, Tim Waugh wrote: > The problem I'm trying to solve is described in bug #424331: > https://bugzilla.redhat.com/show_bug.cgi?id=424331 > > The background is that HPLIP uses libusb to communicate with HP USB > printers, and both the printing system (running in group 'lp') and the > current console user (or uses) need access in that way. The console > user needs this access for ink-level checking and other status functions > provided by the hp-toolbox program, and potentially for using the > in-built scanner with libsane. > > When the printer is plugged in, the device node that libusb uses for it > is in /dev/bus/usb/.../... and we want it to have group read/write > access for 'lp', and user read/write access for each console user. > > The intention is to have udev rules set the group ownership to 'lp', and > to grant group read/write permissions, and to have the HAL rules grant a > 'rw' ACL for each console user. I originally described this approach > here: > > http://cyberelk.net/tim/2007/10/04/hplip-device-permissions-with-consolekit/ > > It worked well, but a recent kernel update seems to have revealed a race > condition. The ACL is granted (by hal-acl-tool) before the 'MODE=...' > udev rule is applied, and this ordering messes up the ACL permissions > (either the ACL mask or the group permissions end up being restricted). > > The problem boils down to this: How can I ensure that the ACL is granted > *after* the mode permissions have been set, i.e. after the udev rules > have completed, not before? > If you know what the incorrect udev permissions are, you could just sleep until they change. From jos at xos.nl Wed Jan 23 21:25:56 2008 From: jos at xos.nl (Jos Vos) Date: Wed, 23 Jan 2008 22:25:56 +0100 Subject: long term support release In-Reply-To: References: <1201058211.3001.79.camel@gandalf.cobite.com> <47972980.7000804@odu.neva.ru> <20080123150921.GB32532@jasmine.xos.nl> Message-ID: <20080123212556.GE6543@jasmine.xos.nl> On Wed, Jan 23, 2008 at 09:48:20PM +0100, Benny Amorsen wrote: > RHEL and its derivatives, just like SUSE and Debian Stable, are > comparatively conservative. I need e.g. working QinQ, and that means > a 2.6.23 kernel. There's also a lot of software missing in RHEL -- > like OpenSwan and Asterisk. For the latter you can use EPEL (but not all is there yet, of course). The first is true, but IMHO being (more) conservative in related to having a LTS release, so I don't see that much difference between a suggested Fedora LTS and RHEL/CentOS. > If you update and add components to RHEL, you're going to lose out on > support, as far as I know. (If I'm wrong and some enterprise distro Yes, but, comparing apples with apples, Fedora LTS would have no (official) support too, just like CentOS (in all cases I ignore third party support). > maker is willing to offer support for OpenSwan and kernel 2.6.23, I'd > be very happy to hear about it.) Yes, but this sounds a bit like wanting to have a bleeding-edge distro, with a huge amount of packages, and with long time support. Good luck finding a company wanting to build/maintain such a distro ;-). -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From marc at mwiriadi.id.au Wed Jan 23 21:28:08 2008 From: marc at mwiriadi.id.au (Marc Wiriadisastra) Date: Thu, 24 Jan 2008 06:28:08 +0900 Subject: preload In-Reply-To: <479773DB.1010707@gmail.com> References: <1201071580.6050.20.camel@localhost.localdomain> <479773DB.1010707@gmail.com> Message-ID: <1201123688.25546.3.camel@localhost.localdomain> On Wed, 2008-01-23 at 18:05 +0100, drago01 wrote: > Marc Wiriadisastra wrote: > > Those people running preload can we get some benchmarks to see whether > > there is a benefit and if so how much of a benefit there is. > > > > I ask this because I got a post on the from Rahul asking whether there > > was any significant benefit running preload. I personally don't have any > > numbers so I'm going to try and start to benchmark the information. > > > Well I tryed it and benchmarked it using bootchart and its even _worse_ > then readahead that we decided to disable. > > No preload: 57 sec > With preload: 1m 25sec > > ie. ~50% slowdown > That is expected since it has to as mentioned elsewhere preload everything so bootup is the logical place. Cheers, Marc From jwilson at redhat.com Wed Jan 23 21:53:23 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 23 Jan 2008 16:53:23 -0500 Subject: long term support release In-Reply-To: <20080123132618.0660f673@redhat.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <20080123132618.0660f673@redhat.com> Message-ID: <4797B753.4020309@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: > On Wed, 23 Jan 2008 09:16:30 -0900 > "Jeff Spaleta" wrote: > >> Legacy was not a failure... it was a key part of the process of >> defining what the limits are with the resources we have. Now that we >> have gone through that, the people who have survived the process have >> a much better idea of what it takes in terms of a resource commitment >> to pull it off. >> >> I have absolutely no problem with another attempt at community effort >> as a follow-up to what Legacy did. I just don't think its where this >> community of contributors wants to contribute. I think at a minimum >> there are 3rd support specialists out there with a business interest >> in a Fedora LTS, or perhaps niche hardware vendors in the embedded >> space which could be persuaded to leverage Fedora as a development >> platform. Lots of unexplored area. > > It's perfectly OK to fail, in fact we should fail more often, and share > the results of those failures. It's only by failure that we'll know > the limits of our abilities. Dude. That's deep. - -- Jarod Wilson jwilson at redhat.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHl7dTtO+bni+75QMRAjguAJwNYr51LtpO2To803vJrOgze6O7vQCfUjqL OJ3GbqiPVhjyCLMMmn/wmeo= =o6m0 -----END PGP SIGNATURE----- From tcallawa at redhat.com Wed Jan 23 22:18:42 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 23 Jan 2008 17:18:42 -0500 Subject: rpms/qt/devel .cvsignore, 1.26, 1.27 qt.spec, 1.146, 1.147 sources, 1.27, 1.28 In-Reply-To: <479773C4.1020106@math.unl.edu> References: <200801231558.m0NFwsBJ027236@cvs-int.fedora.redhat.com> <200801231658.m0NGwJCP014115@laptop13.inf.utfsm.cl> <479773C4.1020106@math.unl.edu> Message-ID: <1201126722.3368.49.camel@localhost.localdomain> On Wed, 2008-01-23 at 11:05 -0600, Rex Dieter wrote: > Horst H. von Brand wrote: > > Rex Dieter wrote: > >> Than Ngo (than) wrote: > >> > >>> Index: qt.spec > >>> =================================================================== > >>> RCS file: /cvs/extras/rpms/qt/devel/qt.spec,v > >>> retrieving revision 1.146 > >>> retrieving revision 1.147 > >>> diff -u -r1.146 -r1.147 > >>> --- qt.spec 26 Nov 2007 15:32:22 -0000 1.146 > >>> +++ qt.spec 23 Jan 2008 15:58:17 -0000 1.147 > >>> @@ -1,9 +1,9 @@ > >>> Summary: The shared library for the Qt GUI toolkit. > >>> Name: qt > >>> -Version: 3.3.8 > >>> -Release: 11%{?dist} > >>> +Version: 3.3.8b > >>> +Release: 1%{?dist} > >>> Epoch: 1 > >>> -License: GPL/QPL > >>> +License: GPLv3 > > >> Make that, > >> License: GPLv2 or GPLv3 > >> please, to match reality. qt is definitely not GPLv3 only. > > > I understand it is QPL/GPLv2/GPLv3 now... > > True (applies to qt4 as well), I forget the reason why we chose to omit > QPL from the License: field before. There was one, I just don't recall atm. It should be: License: GPLv2 or GPLv3 or QPL ~spot From jmorris at namei.org Wed Jan 23 22:19:43 2008 From: jmorris at namei.org (James Morris) Date: Thu, 24 Jan 2008 09:19:43 +1100 (EST) Subject: SELinux and chroot Message-ID: Did the SELinux vs. chroot issue get bugzilla'd ? It came up in discussion a couple of times, but I can't recall if the issue was captured there. - James -- James Morris From lordmorgul at gmail.com Wed Jan 23 22:30:56 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 23 Jan 2008 14:30:56 -0800 Subject: Replacing the boot kernel in the installer In-Reply-To: <544eb990801230621u1baa32afia8de7077cbf060d3@mail.gmail.com> References: <544eb990801230424q79f27bek99ccd6905c645f6@mail.gmail.com> <479738F5.6060001@gmail.com> <1201093498.7153.49.camel@localhost.localdomain> <544eb990801230506o1f908f1cq958cfdf9073984b0@mail.gmail.com> <20080123081009.50b11fc3@redhat.com> <544eb990801230621u1baa32afia8de7077cbf060d3@mail.gmail.com> Message-ID: <4797C020.6090901@gmail.com> Bill Crawford wrote: > On 23/01/2008, Jesse Keating wrote: > >> The best way around it is to use rescue.iso instead. Since rescue.iso >> has stage2 on it, you can point it at any repo to do the install, like >> your original F8 repo. > > Sounds good. I can't find a rescue.iso under development at the > moment, though, so I'm going with (in order) trying to use rawhide > vmlinuz + initrd.img (replacing .buildstamp with the one from F8); and > if that doesn't work, actually replacing the F8 install kernel with > the rawhide installer kernel and ditto the modules in the initrd ... > Rescue isos for rawhide that Jesse posted to install from the F8 repo. http://koji.fedoraproject.org/rel-eng/trees/ -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From vonbrand at inf.utfsm.cl Wed Jan 23 22:29:58 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Wed, 23 Jan 2008 19:29:58 -0300 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <1200900997.2845.12.camel@beck.corsepiu.local> References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> <1200766980.2961.8.camel@sb-home> <604aa7910801192136u754e6a4ex1c3c0113440c4e02@mail.gmail.com> <1200900997.2845.12.camel@beck.corsepiu.local> Message-ID: <200801232229.m0NMTwEf007941@laptop13.inf.utfsm.cl> Ralf Corsepius wrote: > On Sat, 2008-01-19 at 20:36 -0900, Jeff Spaleta wrote: > > On Jan 19, 2008 9:23 AM, nodata wrote: > > > I'm talking about closing the bug and telling the reporter to report > > > upstream, i.e. "go away". > > As a package maintainer, what would you like me to do in situations > > where I need the reporter to talk to upstream? > A reporter should never be supposed to talk upstream, because he is > reporting an issue a problem with the product (your package) you are > supposed to be responsible for, not against the product an upstream > ships to you (the source tarball). It might very well happen that the packager can't reproduce the problem (doesn't have the exact hardware, whatever). -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From ibmalone at gmail.com Wed Jan 23 22:41:34 2008 From: ibmalone at gmail.com (Ian Malone) Date: Wed, 23 Jan 2008 22:41:34 +0000 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> Message-ID: <4797C29E.5000001@gmail.com> Tom Tromey wrote: >>>>>> "Kevin" == Kevin Kofler writes: > >>> Closing a bug report with "report it upstream" is a let down. It's >>> repetitive boring work that a computer should be doing. > > Kevin> There's no way we can fix them all by ourselves, the only way > Kevin> to actually get things fixed is to report them to the actual > Kevin> upstream maintainers of the concrete application you're having > Kevin> issues with. And I don't think KDE is the only set of packages > Kevin> in this situation. > > What would be good here is an easy way to push a report upstream. > > This would solve the Fedora maintainer's problem ("this is not our > bug") without requiring extra work from the bug reporter (who is > probably lazy like me, and anyway isn't in as good a position to > triage a report as the Fedora maintainer). > Seconded. As a Fedora end user, rather than a developer, if I report a bug to Fedora BZ and get told to put it upstream I then have to go and get a BZ account for upstream. That may seem trivial but I now have accounts on quite a few BZs, each of which was only used to report one or two bugs. No, the maintainer shouldn't have to act as a proxy, but it would be nice to have some automated mechanism that would. -- imalone From ml at deadbabylon.de Wed Jan 23 23:29:35 2008 From: ml at deadbabylon.de (Sebastian Vahl) Date: Thu, 24 Jan 2008 00:29:35 +0100 Subject: Live images and fonts Message-ID: <200801240029.35792.ml@deadbabylon.de> Hi. After some time I've done a new test spin of my kde live images today. What I've experienced is that most of the former installed fonts are missing. A diff between my released rawhide live image for KDE 4 and my current one is: baekmuk-ttf-fonts-common baekmuk-ttf-fonts-gulim cjkunifonts-uming dejavu-lgc-fonts jomolhari-fonts kacst-fonts liberation-fonts lohit-fonts-bengali lohit-fonts-gujarati lohit-fonts-hindi lohit-fonts-kannada lohit-fonts-oriya lohit-fonts-punjabi lohit-fonts-tamil lohit-fonts-telugu paktype-fonts sazanami-fonts-gothic The full diff is available here: http://pastebin.org/16733 In the past they were pulled in from comps.xml (or livecd-fedora-base-desktop.ks). So my question here is: Is this intended? My full package list of my current live image: http://fedoraproject.org/wiki/SebastianVahl/CurrentPackageList For the record: I'm using this comps version: http://ftp.tu-chemnitz.de/pub/linux/fedora-enchilada/linux/development/i386/os/repodata/comps.xml Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From limb at jcomserv.net Wed Jan 23 23:25:58 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 23 Jan 2008 17:25:58 -0600 (CST) Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <20080123211131.GD1412626@hiwaay.net> References: <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> <1200766980.2961.8.camel@sb-home> <604aa7910801192136u754e6a4ex1c3c0113440c4e02@mail.gmail.com> <1200900997.2845.12.camel@beck.corsepiu.local> <604aa7910801231206x7d1a7471yf2158cefb68b0aeb@mail.gmail.com> <20080123151818.02647429@redhat.com> <62043.63.85.68.164.1201119601.squirrel@mail.jcomserv.net> <20080123210618.GA21303@devserv.devel.redhat.com> <20080123211131.GD1412626@hiwaay.net> Message-ID: <2239.192.168.0.1.1201130758.squirrel@mail.chuzibooks.com> > Once upon a time, Alan Cox said: >> I try to leave the RH bug open and even if I report it being an upstream >> problem then update it now and again with the status of things. That way >> people at least know something is happening and when it will be worth >> trying >> an update > > Sometimes the RH bug owner _is_ upstream; I reported a bug in hal-info > data and didn't get a response yet, so I opened a bug upstream. I think > it ended up owned by the same person. > > One argument in favor of having the package owner report bugs upstream > is they presumably have a better idea about how and where, have bugzilla > accounts, etc. They can filter the reports (so when Fedora users open > 10 RH bug entries for the same problem, upstream only has to deal with > one report). The package owner will also need to know when the bug has > been fixed to make an update (in some cases, end-users may need a > package owner to help build test packages as well). I do exactly what Alan does. Making the RH bug a coordinating point is helpful for users, so they don't necessarily have to dig too far to find out what's going on. I have this going on with a roundcubemail security bug going on right now. I have a reference to the upstream bug in the RH bug, so users can see for themselves why it's not updated yet. :/ > -- > Chris Adams > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From cjdahlin at ncsu.edu Wed Jan 23 23:45:29 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Wed, 23 Jan 2008 18:45:29 -0500 Subject: Plan for tomorrows (20080124) FESCO meeting In-Reply-To: <479783A2.5030901@gmail.com> References: <1201105578.11814.2.camel@nixon> <0ML25U-1JHiww0JkI-0004KE@mrelayeu.kundenserver.de> <479783A2.5030901@gmail.com> Message-ID: <4797D199.3070105@ncsu.edu> Toshio Kuratomi wrote: > Jochen Schmitt wrote: >> On Wed, 23 Jan 2008 11:26:18 -0500, you wrote: >> >>> /topic FESCo-Meeting -- New Features - >>> http://fedoraproject.org/wiki/Features/Dashboard - poelcat >>> * http://fedoraproject.org/wiki/Features/Upstart >> >> >> I think you schould change the topic to "Which initscript >> replacement should we used for upcomming versions of Fedora" >> >> - From my point of view approving of this feature sound like make a >> dicission for use upstart as the new initscript replacement in >> Fedora. >> > It's not a feature unless a decision has been made and initscripts are > replaced with something specific. > >> But when I read the article "Call To Choose An Initscript >> Replacement" on http://fedoraproject.org/wiki/FWN/Issue115 >> upstart will no be the canidate tor this task. >> > There is one thing lacking from that writeup and one additional point > of information: > 1) Looking into InitKit, people found that it is a specification for > event-driven init systems and that upstart would be the main driver's > implementation ground for that specification. So using upstart isn't > as out-there as the writeup leaves it. > > 2) Casey Dahlin held a FUDCon session to discuss how to replace our > current initsystem and is the driver of the feature. Perhaps Casey > needs to tell us what was discussed at FUDCon so we are on the same > page WRT where the discussion has gone. > > Casey? > > -Toshio > I was hoping the video tape of the session would be out before now (if anyone has it, haaalp!), but here's roughly what happened: We began by ennumerating a few init systems that were available. We listed (unless I forget): SysV (our current implementation) prcsys rrn (my own rewrite of prcsys) initng Upstart murdur I mentioned InitKit and pointed out the fact that it was not an actual software project, but a specification. Murdur we eliminated immediately on the grounds that it is tightly integrated with the package system of Pardus, and, by upstream's own admittance, is not really suited to integration with other distros. Next up was prcsys. I pointed out that the code was rather inferior and ill suited to some of the modifications we had been pondering for this style of init system, and that rrn would be more flexible and would likely achieve feature parity with prcsys by the following day's hackfest. A brief outline of how prcsys worked internally had most people in agreement, and prcsys was stricken down. SysV at this point was put aside. I proposed that we assume we would pick a new system, and then once we had selected one, weight that one alone against staying where we were. With the initial culling out of the way, we began to get into the benefits of each individual init system. Upstart and its operation got the most explanation. Upstart is designed as an event-driven init system, where services are spawned in reaction to events rather than en masse when runlevel transitions occur (in fact an Upstart system may not have any concept of runlevels at all, though it can. More on that later). This allows for many advantages (allowing HAL to drive service activation, running services only as they are needed, etc). Upstart is also a service manager. It keeps track of the processes it spawns, can restart them automatically, and keeps the system notified of their state. Upstart's roadmap also includes integrating cron functionality, and session-level service management (so users' individual login services can be handled by the same faculties). We then took a look at initng. Several points were made against initng's code quality, and it came to light that of the two people there who had attempted to use initng (myself being one of them) neither had actually gotten it to work. The only real advantage to moving to initng at the moment was parallelization, which most agreed would not result in a large gain in boot time. The room agreed to strike initng from the list of options. We were left with Upstart and rrn. I explained the basic structure of rrn, a parallelizing service starter that would drop into the current init system somewhere within /etc/rc. One of the design goals had been not to replace the original sysvinit daemon, which I had been told was desirable in a new init system, but no one in the room really felt compelled by this. I also detailed how rrn might plug into dbus to notify the system about service activations and respond to activation requests by being installed as an on-demand dbus service. I pointed out that actual service management was unfortunately impossible from this stateless design pattern. The room seemed intrigued by the initkit standard, and the fact that Upstart would likely be the first to realize new features in it. Being on board with a standard was generally preferred to creating another NIH product, and rrn's design, it was admitted, would be hard pressed to adopt the full set of upstart's features. There was a little amusement when I, rrn's author, was the one who pushed to strike it. I pointed out that rrn was coded to meet a spec I had been told had been agreed upon by the community, and that I had no personal stock in the architecture itself. With the other new choices gone I put SysV back up on the board, but most seemed excited about the new features in Upstart. We talked about migration path, and I pointed out that Upstart's ability to behave as a sysv compatible init daemon meant things could be done incrementally and the initial change could take place easily. We agreed on Upstart, and I promised to start packaging it the next day. I went to Spot's talk on RPM packaging, then the talk on Func, I had CentOS birthday cake, and then I went out and proceeded to get what Jon Stanley described as "very drunk." --CJD From wtogami at redhat.com Thu Jan 24 00:02:59 2008 From: wtogami at redhat.com (Warren Togami) Date: Wed, 23 Jan 2008 19:02:59 -0500 Subject: InstantMirror needs a rethink Message-ID: <4797D5B3.7030002@redhat.com> Today InstantMirror is pretty useful for home and small office mirrors, but its limitations make it unsustainable without manual intervention of the sysadmin. I've been beginning to think that perhaps InstantMirror is heading down the wrong path and we seriously need to rethink it. There are simply too many limitations of the current "stateless" operation of InstantMirror where it runs only on-demand as mod_python script: - Synchronization/locking of multiple connections downloading the same file is awkward and broken. - There is no good way to clean up aborted tmp files. - There is no good way to know what are old files that need pruning. - There is no good way of keeping track of the "Big Picture" of its own cache, "least recently used" knowing what files were unpopular locally and should be pruned. https://fedorahosted.org/InstantMirror/wiki/InstantMirrorDaemon We need a daemon to handle all this. Perhaps the daemon could allow socket connections from a mod_python script for accesses. Or perhaps it might be better for the daemon itself to handle serving connections. Stepping back, what we really need is: A reverse proxy caching server with all the logic of squid or varnish, except it stores its cache with file and directory names intact. How do we get there? 1) Write a new daemon from scratch? 2) Write a new backend storage engine for squid or varnish? (Store files in target directory structure, store metadata elsewhere.) 3) ??? Any thoughts? Warren Togami wtogami at redhat.com From dmc.fedora at filteredperception.org Thu Jan 24 00:14:29 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Wed, 23 Jan 2008 18:14:29 -0600 Subject: InstantMirror needs a rethink In-Reply-To: <4797D5B3.7030002@redhat.com> References: <4797D5B3.7030002@redhat.com> Message-ID: <4797D865.1050300@filteredperception.org> Warren Togami wrote: > Stepping back, what we really need is: > A reverse proxy caching server with all the logic of squid or varnish, > except it stores its cache with file and directory names intact. > > How do we get there? > 1) Write a new daemon from scratch? > 2) Write a new backend storage engine for squid or varnish? (Store > files in target directory structure, store metadata elsewhere.) > 3) ??? > > Any thoughts? I suspect that I don't quite understand the total problem-space you are attacking, but... When I was playing around with squid, what seemed to bite me was that I couldn't do an http kickstart install, because I didn't see any way to get anaconda to use an http proxy configuration. I asked on either the anaconda or kickstart list, and never got an answer. I'm just wondering if anaconda could easily (does it already?) input an http proxy config to use, that would solve my needs just using the simplest squid config. -dmc From wtogami at redhat.com Thu Jan 24 00:26:00 2008 From: wtogami at redhat.com (Warren Togami) Date: Wed, 23 Jan 2008 19:26:00 -0500 Subject: InstantMirror needs a rethink In-Reply-To: <4797D865.1050300@filteredperception.org> References: <4797D5B3.7030002@redhat.com> <4797D865.1050300@filteredperception.org> Message-ID: <4797DB18.5070903@redhat.com> Douglas McClendon wrote: > > When I was playing around with squid, what seemed to bite me was that I > couldn't do an http kickstart install, because I didn't see any way to > get anaconda to use an http proxy configuration. I asked on either the > anaconda or kickstart list, and never got an answer. I'm just wondering > if anaconda could easily (does it already?) input an http proxy config > to use, that would solve my needs just using the simplest squid config. > > -dmc > You are thinking squid proxy server. I am talking reverse proxy or "accelerator" mode. Read up. =) Warren From cra at WPI.EDU Thu Jan 24 00:43:57 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 23 Jan 2008 19:43:57 -0500 Subject: Replacing the boot kernel in the installer In-Reply-To: <4797C020.6090901@gmail.com> References: <544eb990801230424q79f27bek99ccd6905c645f6@mail.gmail.com> <479738F5.6060001@gmail.com> <1201093498.7153.49.camel@localhost.localdomain> <544eb990801230506o1f908f1cq958cfdf9073984b0@mail.gmail.com> <20080123081009.50b11fc3@redhat.com> <544eb990801230621u1baa32afia8de7077cbf060d3@mail.gmail.com> <4797C020.6090901@gmail.com> Message-ID: <20080124004357.GJ12464@angus.ind.WPI.EDU> On Wed, Jan 23, 2008 at 02:30:56PM -0800, Andrew Farris wrote: > Bill Crawford wrote: >> On 23/01/2008, Jesse Keating wrote: >> >>> The best way around it is to use rescue.iso instead. Since rescue.iso >>> has stage2 on it, you can point it at any repo to do the install, like >>> your original F8 repo. >> >> Sounds good. I can't find a rescue.iso under development at the >> moment, though, so I'm going with (in order) trying to use rawhide >> vmlinuz + initrd.img (replacing .buildstamp with the one from F8); and >> if that doesn't work, actually replacing the F8 install kernel with >> the rawhide installer kernel and ditto the modules in the initrd ... >> > > Rescue isos for rawhide that Jesse posted to install from the F8 repo. > > http://koji.fedoraproject.org/rel-eng/trees/ I'd be *VERY* careful with those images due to this bug: Bugzilla Bug 429782: "extents" flag appeared on ext3 filesystem, can't mount filesystem You don't want to accidentally mess up your ext3 filesystems and make them very hard to recover. From lordmorgul at gmail.com Thu Jan 24 00:57:34 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 23 Jan 2008 16:57:34 -0800 Subject: long term support release In-Reply-To: <80d7e4090801231253k354fe83ep74d1b067582be28b@mail.gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <7f692fec0801221942x715523cal70423262eb09b4c0@mail.gmail.com> <1201060757.3001.96.camel@gandalf.cobite.com> <4796D766.8070009@gmail.com> <20080123145053.GA23715@angus.ind.WPI.EDU> <20080123095443.130b7230@redhat.com> <80d7e4090801231253k354fe83ep74d1b067582be28b@mail.gmail.com> Message-ID: <4797E27E.8070607@gmail.com> Stephen John Smoogen wrote: > 2008/1/23 Jesse Keating : >> On Wed, 23 Jan 2008 09:50:53 -0500 >> Chuck Anderson wrote: >> >>> Not really. You have to wait ~6 months for the newest release to >>> stabalize before upgrading to it, so that cuts down the maintained >>> lifetime to only 6 months. >> This is ridiculous BS that is self serving. If everybody waited until >> release+6M to try it out, the "safe" date would become release+12M, and >> so on. It's entirely a piss poor attitude and does nothing to better >> the project. >> > > Well in a large scale enterprise setting it could be 6 months BUT NOT > because of stability issues on Fedora side. Documenting, coming up > with security plans, support procedures for internal help desk, > testing that software works with internal applications etc usually > took us 2 months on EL with a lot of stuff 'fluffed' over as done by > upstream. In a Fedora setting it took a lot longer as we couldn't say > that there was a commercial entity doing that testing for us. Of > course that would also mean that the packages that came out for Fedora > 8 would only get backported fixes etc versus getting updates to the > latest and greatest. Which is a prime example of why its not *targeted as* a distribution for that use. Fedora is a showcase of advancing technologies in the linux space, thats what it is, a distribution for developers and innovators. With that understanding firmly set in place it makes sense that reviewing it for an enterprise setting would take longer. Alot of people lose sight of what Fedora is I think (and this is not about your comments Stephen); it is a good distro for desktop use *only because* it showcases the newest improvements in UI, features, and capabilities.. making sure it competes^w out performs the windows space in usability and features. Fedora is not meant to be everybody's best desktop all the time, and alot of the complaints about the release cycle and 'alpha'ness of some software included stem directly from the assumption that Fedora is meant to be rock solid workhorse for people who don't want to pay for RHEL. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From lordmorgul at gmail.com Thu Jan 24 01:01:31 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 23 Jan 2008 17:01:31 -0800 Subject: Replacing the boot kernel in the installer In-Reply-To: <20080124004357.GJ12464@angus.ind.WPI.EDU> References: <544eb990801230424q79f27bek99ccd6905c645f6@mail.gmail.com> <479738F5.6060001@gmail.com> <1201093498.7153.49.camel@localhost.localdomain> <544eb990801230506o1f908f1cq958cfdf9073984b0@mail.gmail.com> <20080123081009.50b11fc3@redhat.com> <544eb990801230621u1baa32afia8de7077cbf060d3@mail.gmail.com> <4797C020.6090901@gmail.com> <20080124004357.GJ12464@angus.ind.WPI.EDU> Message-ID: <4797E36B.9050100@gmail.com> Chuck Anderson wrote: > On Wed, Jan 23, 2008 at 02:30:56PM -0800, Andrew Farris wrote: >> Bill Crawford wrote: >>> On 23/01/2008, Jesse Keating wrote: >>> >>>> The best way around it is to use rescue.iso instead. Since rescue.iso >>>> has stage2 on it, you can point it at any repo to do the install, like >>>> your original F8 repo. >>> Sounds good. I can't find a rescue.iso under development at the >>> moment, though, so I'm going with (in order) trying to use rawhide >>> vmlinuz + initrd.img (replacing .buildstamp with the one from F8); and >>> if that doesn't work, actually replacing the F8 install kernel with >>> the rawhide installer kernel and ditto the modules in the initrd ... >>> >> Rescue isos for rawhide that Jesse posted to install from the F8 repo. >> >> http://koji.fedoraproject.org/rel-eng/trees/ > > I'd be *VERY* careful with those images due to this bug: > > Bugzilla Bug 429782: "extents" flag appeared on ext3 filesystem, can't mount filesystem > > You don't want to accidentally mess up your ext3 filesystems and make > them very hard to recover. Good point, although If doing clean installs this bug doesn't bite you, shouldn't be a problem (as long as you're not sharing filesystems). https://bugzilla.redhat.com/show_bug.cgi?id=429782 But for Valent, maybe using those is a bad idea then (since he will be sharing filesystems). -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From mcepl at redhat.com Thu Jan 24 01:05:29 2008 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 24 Jan 2008 02:05:29 +0100 Subject: long term support release References: <1201058211.3001.79.camel@gandalf.cobite.com> Message-ID: On 2008-01-23, 13:15 GMT, Laith Juwaidah wrote: > Why do we have to look for other business partners when we have > RH? RH could release a "filtered" version of Fedora and call it > RHHL (Red Hat Home Linux). It exists and it is called CentOS (although it is not created by Red Hat). Mat?j From vonbrand at inf.utfsm.cl Thu Jan 24 01:09:50 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Wed, 23 Jan 2008 22:09:50 -0300 Subject: Why is the time removed from the package intallation window In-Reply-To: <20080122175415.GA18331@nostromo.devel.redhat.com> References: <20080122173226.GB46223@dspnet.fr.eu.org> <20080122175415.GA18331@nostromo.devel.redhat.com> Message-ID: <200801240109.m0O19oOw016077@laptop13.inf.utfsm.cl> Bill Nottingham wrote: > Olivier Galibert (galibert at pobox.com) said: > > I noticed now that I'm starting to actually install systems with f8 > > that the time used/remaining indication has been removed from the text > > installation screen. I'm curious, why is that? > It's non-trivial to render accurately (it wasn't particularly accurate > before...) Make that "Mostly wildly off" ;-) -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From poelstra at redhat.com Wed Jan 23 23:49:18 2008 From: poelstra at redhat.com (John Poelstra) Date: Wed, 23 Jan 2008 15:49:18 -0800 Subject: Accepted Fedora Features Needing Updates Message-ID: <4797D27E.5090307@redhat.com> Dear Accepted Feature Owners, We are nearing the Alpha release for Fedora 9... currently scheduled for January 31, 2008. If you have not updated the status and % completion of your feature in the last few days, please do so now. Keeping this information current helps the people interested in testing new functionality and marketing folks who want to start getting up to speed with what is coming in Fedora 9. This would also be a great time to start filling out the "Release Notes" and "Documentation" sections of your feature page--particularly if it is presently blank. The Documentation Team is eager to start preparing the release notes and documentation for Fedora 9 so the sooner you get that information in the sooner they start working on it. The following accepted features have not been recently updated OR have empty "Release Notes" and/or "Documentation" sections. Please update this information at your earliest convenience. http://fedoraproject.org/wiki/Releases/FeatureBluetooth http://fedoraproject.org/wiki/Releases/FeatureClockApplet http://fedoraproject.org/wiki/Releases/FeatureDictionary http://fedoraproject.org/wiki/Features/OneSecondX http://fedoraproject.org/wiki/Releases/FeatureFingerprint http://fedoraproject.org/wiki/Features/freeIPA http://fedoraproject.org/wiki/Features/GoodHaskellSupport http://fedoraproject.org/wiki/Features/K12Linux http://fedoraproject.org/wiki/Releases/FeatureMoreNetworkManager http://fedoraproject.org/wiki/Features/PackageKit http://fedoraproject.org/wiki/Features/PartitionResizing http://fedoraproject.org/wiki/Releases/FeaturePresto http://fedoraproject.org/wiki/Features/ServerProvides http://fedoraproject.org/wiki/Releases/FeatureTexLive http://fedoraproject.org/wiki/Features/XserverOnePointFive http://fedoraproject.org/wiki/Features/VirtAuthentication http://fedoraproject.org/wiki/Features/VirtPolicyKit http://fedoraproject.org/wiki/Features/VirtStorage http://fedoraproject.org/wiki/Features/XenPvops http://fedoraproject.org/wiki/Features/Ext4 Thank you, John _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From poelstra at redhat.com Wed Jan 23 23:49:21 2008 From: poelstra at redhat.com (John Poelstra) Date: Wed, 23 Jan 2008 15:49:21 -0800 Subject: Requesting feedback for unaccepted Fedora features Message-ID: <4797D281.2040808@redhat.com> Dear Proposed Feature Owners, The following feature pages are in CategoryProposedFedora9 which indicates that the feature owner is requesting that FESCo vote on them at the next meeting. I have not raised these features to FESCo for a vote because certain parts of the pages are incomplete and it doesn't make sense for FESCo to review a feature when all the information is not present. 1) http://fedoraproject.org/wiki/Features/GCC4.3 -- need a link to owner contact information; contingency plan and release notes sections are blank; need to discuss impact on mass rebuild of Fedora 9 (2008-01-02) 2) http://fedoraproject.org/wiki/Features/EFI -- a few sections still need to be completed (2007-01-14) 3) http://fedoraproject.org/wiki/Features/JigdoRelease -- some of the TBDs need to be completed, particularly "contingency plan" and "dependencies" (2008-01-03) 4) http://fedoraproject.org/wiki/Releases/FeatureEncryptedFilesystems -- documentation and release notes sections are empty (2008-01-14) In addition, the following features are targeted for Fedora 9 in their writeup, but are not in CategoryProposedFedora9. If you have no intention of completing them for Fedora 9, please remove Fedora 9 as the targeted release so that there is no confusion that it will not be in Fedora 9. These features will never be raised for acceptance by FESCo. http://fedoraproject.org/wiki/Releases/FeatureXULRunner http://fedoraproject.org/wiki/Releases/FeatureVolumeControl http://fedoraproject.org/wiki/Releases/FeatureRPMYumEnhancements http://fedoraproject.org/wiki/Features/NewGdm http://fedoraproject.org/wiki/Features/RandrSupport http://fedoraproject.org/wiki/ChristophWickert/FedoraLite http://fedoraproject.org/wiki/Releases/FeatureFirstboot http://fedoraproject.org/wiki/Features/SecurityAudit http://fedoraproject.org/wiki/Features/PreUpgrade http://fedoraproject.org/wiki/Features/NetworkManager-MobileBroadband http://fedoraproject.org/wiki/Features/HandwritingRecognizer Thank you, John _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From buytenh at wantstofly.org Thu Jan 24 01:28:28 2008 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Thu, 24 Jan 2008 02:28:28 +0100 Subject: Fedora 8/ARM available In-Reply-To: <20080116203330.787a06dc@zod.rchland.ibm.com> References: <20080114233331.GL17358@xi.wantstofly.org> <20080116203330.787a06dc@zod.rchland.ibm.com> Message-ID: <20080124012828.GA12776@xi.wantstofly.org> On Wed, Jan 16, 2008 at 08:33:30PM -0600, Josh Boyer wrote: > > We are proud to announce the availability of a(n unofficial) > > Fedora 8 package repository for the ARM architecture. > > > > The package repository has been built for ARMv5 EABI, soft-float, > > little endian. The majority of the important and frequently used > > Fedora packages have been built for ARM. > > > > The Fedora/ARM architecture wiki page has more info: > > http://fedoraproject.org/wiki/Architectures/ARM > > > > The easiest way to start using Fedora 8/ARM is to download the > > prebuilt root filesystem, which can be booted in QEMU, or chroot'ed > > into or booted from on any ARMv5 or later processor running in little > > endian mode. Additional packages can be installed by using yum, > > which is provided in the filesystem. > > > > A HOWTO which describes getting Fedora/ARM running in QEMU is here: > > http://fedoraproject.org/wiki/Architectures/ARM/HowToQemu > > > > There currently are a handful of known issues, which are described at: > > http://fedoraproject.org/wiki/Architectures/ARM/TODO > > > > Please help us by using the Fedora/ARM port and reporting any issues > > you run into so that we can fix them. > > How long until you have instructions on installing Fedora on the > n800/n810? :) An unmodified Fedora/ARM root filesystem is probably too big to fit inside the flash of an n800/n810. We have a bunch of tools for footprint optimisation, but those need some more work before we'll make them generally available. Of course, if you really want, you could run the NFS-enabled kernel images on your n800/n810 and chroot into a Fedora/ARM filesystem mounted over NFS. :-) From mcepl at redhat.com Thu Jan 24 01:22:07 2008 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 24 Jan 2008 02:22:07 +0100 Subject: long term support release References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> Message-ID: On 2008-01-23, 15:30 GMT, David Mansfield wrote: > [...] community can not support an operating system for 2 > years? No, it cannot, because backporting patches back to the 2 years old mostly obsolete software won't get you laid (http://www.jwz.org/doc/groupware.html). It is really complicated, really difficult, and really boring. Ideal stuff for which people get paid. Mat?j From buytenh at wantstofly.org Thu Jan 24 01:31:55 2008 From: buytenh at wantstofly.org (Lennert Buytenhek) Date: Thu, 24 Jan 2008 02:31:55 +0100 Subject: Fedora 8/ARM available In-Reply-To: References: <20080114233331.GL17358@xi.wantstofly.org> <20080116203330.787a06dc@zod.rchland.ibm.com> Message-ID: <20080124013155.GB12776@xi.wantstofly.org> On Thu, Jan 17, 2008 at 08:13:05AM -0600, Jima wrote: > >>>A HOWTO which describes getting Fedora/ARM running in QEMU is here: > >>> http://fedoraproject.org/wiki/Architectures/ARM/HowToQemu > >> > >>How long until you have instructions on installing Fedora on the > >>n800/n810? :) > > > >Don't forget about my Linksys NSLU2... > > I'd love to get Fedora on my NSLU2 -- although that'll probably require > me to find/buy a USB hard drive. :-) That would certainly be the easiest way. There are ways of reducing footprint so that your fs will fit in flash (some of which used internally), but the more effective ones are generally one-way, and things like 'yum update' are rather hard to keep working after you've slimmed your filesystem down to 4MB. :-) From dmc.fedora at filteredperception.org Thu Jan 24 01:28:55 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Wed, 23 Jan 2008 19:28:55 -0600 Subject: InstantMirror needs a rethink In-Reply-To: <4797DB18.5070903@redhat.com> References: <4797D5B3.7030002@redhat.com> <4797D865.1050300@filteredperception.org> <4797DB18.5070903@redhat.com> Message-ID: <4797E9D7.4000804@filteredperception.org> Warren Togami wrote: > Douglas McClendon wrote: >> >> When I was playing around with squid, what seemed to bite me was that >> I couldn't do an http kickstart install, because I didn't see any way >> to get anaconda to use an http proxy configuration. I asked on either >> the anaconda or kickstart list, and never got an answer. I'm just >> wondering if anaconda could easily (does it already?) input an http >> proxy config to use, that would solve my needs just using the simplest >> squid config. >> >> -dmc >> > > You are thinking squid proxy server. I am talking reverse proxy or > "accelerator" mode. Read up. =) I thought I was being clear, I guess you didn't understand me. I understand the difference. My point was that perhaps a big part of your problem space disappears if a squid proxy server can solve that portion of the problem space. I understand the desire to make the mirror server require even less configuration on the client. But for my problem, adding the proxy config required for a non-reverse squid proxy was not a big impact. -dmc From tibbs at math.uh.edu Thu Jan 24 01:51:37 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 23 Jan 2008 19:51:37 -0600 Subject: pike packages In-Reply-To: <1201111653.4620.34.camel@cheese.daheim> References: <1201111653.4620.34.camel@cheese.daheim> Message-ID: >>>>> "jr" == josef radinger writes: jr> I would need someone willing to review the pike-packages. All I can say is, first submit pike itself and get it reviewed. If you have many library packages which will need review, submit a couple of them along with a set of packaging guidelines so that the packaging committee can help you to get them to an acceptable state. Then start submitting the rest of your addon packages according to those guidelines. Honestly, there is very little chance that anyone in the pool of reviewers is going to know anything at all about pike, and so it is an absolute must that we have proper guidelines that will enable us to review those packages. - J< From cra at WPI.EDU Thu Jan 24 02:00:03 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 23 Jan 2008 21:00:03 -0500 Subject: Requesting feedback for unaccepted Fedora features In-Reply-To: <4797D281.2040808@redhat.com> References: <4797D281.2040808@redhat.com> Message-ID: <20080124020003.GK12464@angus.ind.WPI.EDU> On Wed, Jan 23, 2008 at 03:49:21PM -0800, John Poelstra wrote: > In addition, the following features are targeted for Fedora 9 in their > writeup, but are not in CategoryProposedFedora9. If you have no intention > of completing them for Fedora 9, > please remove Fedora 9 as the targeted release so that there is no > confusion that it will not be in Fedora 9. These features will never be > raised for acceptance by FESCo. > > http://fedoraproject.org/wiki/Releases/FeatureXULRunner > http://fedoraproject.org/wiki/Features/NewGdm So what happens if these never get officially "accepted" as Fedora 9 features? Do we rip out XULRunner and back down to the old GDM? Who is going to enforce that? From cjdahlin at ncsu.edu Thu Jan 24 02:16:34 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Wed, 23 Jan 2008 21:16:34 -0500 Subject: Requesting feedback for unaccepted Fedora features In-Reply-To: <20080124020003.GK12464@angus.ind.WPI.EDU> References: <4797D281.2040808@redhat.com> <20080124020003.GK12464@angus.ind.WPI.EDU> Message-ID: <4797F502.8030903@ncsu.edu> Chuck Anderson wrote: > On Wed, Jan 23, 2008 at 03:49:21PM -0800, John Poelstra wrote: > >> In addition, the following features are targeted for Fedora 9 in their >> writeup, but are not in CategoryProposedFedora9. If you have no intention >> of completing them for Fedora 9, >> please remove Fedora 9 as the targeted release so that there is no >> confusion that it will not be in Fedora 9. These features will never be >> raised for acceptance by FESCo. >> >> http://fedoraproject.org/wiki/Releases/FeatureXULRunner >> http://fedoraproject.org/wiki/Features/NewGdm >> > > So what happens if these never get officially "accepted" as Fedora 9 > features? Do we rip out XULRunner and back down to the old GDM? Who > is going to enforce that? > > This is a good point. A couple of these features have kind of happened anyway, and are now easier to run with than they are to revert. What do we do about this? --CJD From ndbecker2 at gmail.com Thu Jan 24 02:23:21 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 23 Jan 2008 21:23:21 -0500 Subject: Help with packaging igraph (stuck on debuginfo) Message-ID: I put together a package for igraph-0.4.5 and python bindings. Unfortunately, the upstream is a bit messed up. The python package is called exactly the same name (the original C is called ipython-0.4.5 and so is the python package). The upstream python package included it's own copy of the c code. I fixed that problem so the python package would use the installed ipython c devel package. Only 1 little problem. I renamed the python source to python-igraph-{version}.tar.gz. I did: %setup -q -n igraph-%{version} Now it builds fine, but: sudo rpm -U ~/RPM/RPMS/x86_64/python-igraph-* file /usr/src/debug/igraph-0.4.5/src/error.c from install of python-igraph-debuginfo-0.4.5-1.fc8.x86_64 conflicts with file from package igraph-debuginfo-0.4.5-1.fc8.x86_64 file /usr/src/debug/igraph-0.4.5/src/error.h from install of python-igraph-debuginfo-0.4.5-1.fc8.x86_64 conflicts with file from package igraph-debuginfo-0.4.5-1.fc8.x86_64 Any ideas how to fix this? From jkeating at redhat.com Thu Jan 24 02:28:59 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 23 Jan 2008 21:28:59 -0500 Subject: Requesting feedback for unaccepted Fedora features In-Reply-To: <4797F502.8030903@ncsu.edu> References: <4797D281.2040808@redhat.com> <20080124020003.GK12464@angus.ind.WPI.EDU> <4797F502.8030903@ncsu.edu> Message-ID: <20080123212859.06128b67@redhat.com> On Wed, 23 Jan 2008 21:16:34 -0500 Casey Dahlin wrote: > > So what happens if these never get officially "accepted" as Fedora > > 9 features? Do we rip out XULRunner and back down to the old GDM? > > Who is going to enforce that? > > > > > This is a good point. A couple of these features have kind of > happened anyway, and are now easier to run with than they are to > revert. What do we do about this? Well, depends on the feature really. When we talked about this last time we said we'd handle it on a case by case basis. I feel that xul and gdm really just needs the feature owner to fill in some blanks to complete the feature so that we have stuff to properly tout and shout and beat Ubuntu to the punch with. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mclasen at redhat.com Thu Jan 24 02:37:47 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 23 Jan 2008 21:37:47 -0500 Subject: Requesting feedback for unaccepted Fedora features In-Reply-To: <4797F502.8030903@ncsu.edu> References: <4797D281.2040808@redhat.com> <20080124020003.GK12464@angus.ind.WPI.EDU> <4797F502.8030903@ncsu.edu> Message-ID: <1201142267.2755.14.camel@localhost.localdomain> On Wed, 2008-01-23 at 21:16 -0500, Casey Dahlin wrote: > Chuck Anderson wrote: > > On Wed, Jan 23, 2008 at 03:49:21PM -0800, John Poelstra wrote: > > > >> In addition, the following features are targeted for Fedora 9 in their > >> writeup, but are not in CategoryProposedFedora9. If you have no intention > >> of completing them for Fedora 9, > >> please remove Fedora 9 as the targeted release so that there is no > >> confusion that it will not be in Fedora 9. These features will never be > >> raised for acceptance by FESCo. > >> > >> http://fedoraproject.org/wiki/Releases/FeatureXULRunner > >> http://fedoraproject.org/wiki/Features/NewGdm > >> > > > > So what happens if these never get officially "accepted" as Fedora 9 > > features? Do we rip out XULRunner and back down to the old GDM? Who > > is going to enforce that? > > > > > This is a good point. A couple of these features have kind of happened > anyway, and are now easier to run with than they are to revert. What do > we do about this? We are not at feature freeze time yet, so it is not time to talk about reverting anything yet. Also, not being accepted is not the same as being rejected to the point of reversal. First and foremost it means that the feature will not be touted as one of the major breakthroughs of F9. Looking at the two features that have been cited, we have every intention to finish them for F9. I assume that finishing the feature itself takes priority over keeping the wiki page uptodate... From wtogami at redhat.com Thu Jan 24 02:41:40 2008 From: wtogami at redhat.com (Warren Togami) Date: Wed, 23 Jan 2008 21:41:40 -0500 Subject: Yum, Proxy Cache Safety, Storage Backend Message-ID: <4797FAE4.80602@redhat.com> I just had an in-depth discussion with Henrik Nordstr?m of the Squid project about how HTTP mirrors and the yum tool itself could be improved to safely handle proxy caches. He gave me lots of good advice about how HTTP mirrors can be configured for cache safety, Squid can be configured for yum metadata cache safety, and yum itself can be improved to be more robust in dealing with proxy caches. (It turns out that Henrik is an avid Fedora user, and I might have convinced him to come onboard the Fedora Project to contribute another useful tool and become co-maintainer of his own package. It would be an honor to have him onboard as a Fedora Developer. =) Yum and Proxy Caches: Current Dangers ===================================== Users may be using proxy servers in 3 (or more) ways: 1) Many users today are behind a transparent proxy cache, either instituted by their ISP, school, or business network. 2) Other users might have Internet access *only* through a proxy server. 3) Other users might be using a reverse proxy server on their local network as a caching yum mirror. There are two cases where yum has problems with proxy caches: 1) A RPM package changes content without changing filename. This usually happens only in instances where a package was pushed unsigned then was later signed. A simple workaround within yum is discussed later in this mail. 2) yum currently has problems with proxy caches due to common cases where metadata can become partially out of sync. This happens because repomd.xml is grabbed often while other repodata files are grabbed less often. repomd.xml is then checked for origin "freshness" more often. When repodata changes on the origin, repomd.xml is refreshed on the cache before other repodata files. yum clients seeing the new repomd.xml but old primary.sqlite.bz2 error out. Ideal Solution for #2 Partial Repodata Sync Problem =================================================== Henrik highly suggests using versioned repodata files as the ideal solution to this problem. This way caches can serve repodata without fear of the sync problem, and also without querying the origin server upon every client download. repomd.xml would contain changing filenames perhaps with timestamp or something in their filenames. i.e. primary-1201140584.sqlite.bz2 This would be an elegant solution, but will it be possible for us to migrate to because older clients wouldn't be able to handle it? I'm guessing not, so here are other less efficient but workable solutions. "Cache-Control: max-age=0" ========================== This HTTP header directive can be either in the request or response. This instructs the proxy cache server to always query the origin HTTP server to check if the requested file has changed. It compares the origin's reported Last-Modified or ETag to what Squid knows in its own cache. This means that each and every request for repodata/* files will trigger a query to the origin server. This is a relatively quick operation and an acceptable compromise if we cannot make repodata filenames versioned. This HTTP directive can be done for repodata/* files at three levels: 1) Origin HTTP mirrors can be configured to serve "Cache-Control: max-age=0" in HTTP headers whenever they serve repodata/* files. This can become a standard recommendation for all Fedora mirrors. Does anyone know how to configure Apache to do this? 2) Squid refresh_pattern can use a regex to override max-age=0 for repodata/* files. I haven't figured out exactly what the syntax is for this. Anybody know squid.conf? 3) yum can always include the HTTP directive in its request for repodata/* files. Can we make this the default in future versions of yum? I personally don't see a drawback (unless repodata becomes versioned, then we don't want this.) Yum and "X-Cache: HIT" ====================== If you use wget --server-response and a target file, you see the raw HTTP headers of that request. If the file is already cached, you see a HTTP header like below: X-Cache: HIT from proxyserver.example.com Proposal: Improve yum with the following download logic: IF (a downloaded repodata/* file doesn't match the repomd.xml checksum OR a downloaded RPM doesn't match the expected checksum) AND "X-Cache: HIT from" was in its HTTP header THEN download it again with URLGrabber option: http_headers = (('Pragma', 'no-cache') This should solve the case where RPM files legitimately change contents without changing filenames, like RPM signing. This also correctly does NOT trigger additional downloads upon other errors like corrupted files. Squid Configuration Suggestion ============================== collapsed_forwarding This option is not default, but pretty useful for proxy servers of our type. This option makes multiple clients asking for the same file not yet in the server's cache to wait on the same origin download connection instead of spawning more downloads of the same thing. Upstream Squid on Adapting Squid's Storage Engine ================================================= Squid currently has an abstract index keyed on integers which makes this hard to implement, but we are planning to break that out from Squid allowing the cache to structure itself in whatever manner, with one possible approach to use store the URLs as-is in the filesystem (within certain bounds) Apache do not have this same abstract internal layer, and writing a mod_disk_cache replacement which keeps a mirror type file structure should be pretty easy thing to do. Its at least on my draft squid-2 roadmap for ~6 months from now Since its going to be important for people running squid in environments where high number sof lookups for large objects isn't required, but they want to cache gigabytes/terabytes of $LARGE objects without having huge amounts of RAM involved So unfortunately squid currently cannot be adapted to be the perfect InstantMirror, but we might be able to achieve it quickly by adapting Apache's mod_disk_cache. Anybody touched this part of Apache before? Warren Togami wtogami at redhat.com From jkeating at redhat.com Thu Jan 24 03:04:51 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 23 Jan 2008 22:04:51 -0500 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <4797FAE4.80602@redhat.com> References: <4797FAE4.80602@redhat.com> Message-ID: <20080123220451.4984e818@redhat.com> On Wed, 23 Jan 2008 21:41:40 -0500 Warren Togami wrote: > i.e. > primary-1201140584.sqlite.bz2 > > This would be an elegant solution, but will it be possible for us to > migrate to because older clients wouldn't be able to handle it? > > I'm guessing not, so here are other less efficient but workable > solutions. Hrm, I would think that this would be possible for recentish clients (RHEL5 and later?). repomd.xml lists out what the other files are, and the checksums of them, so if the files are named slightly different yum should handle it I would think. In fact, I just tried this by hand. I edited repomd.xml and changed 'primary.sqlite.bz2' to 'primary-1234.sqlite.bz2' and then moved the file on the file system. Yum client didn't even blink, it happily downloaded the -1234 file. So if this method is possible, does that change things for the better for you? I think all it would require is slight modification to createrepo so that it could timestamp the repo files. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From roland at redhat.com Thu Jan 24 03:25:15 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 23 Jan 2008 19:25:15 -0800 (PST) Subject: Help with packaging igraph (stuck on debuginfo) In-Reply-To: Neal Becker's message of Wednesday, 23 January 2008 21:23:21 -0500 References: Message-ID: <20080124032515.0AD8326F9FD@magilla.localdomain> > I put together a package for igraph-0.4.5 and python bindings. > Unfortunately, the upstream is a bit messed up. The python package is > called exactly the same name (the original C is called ipython-0.4.5 and so > is the python package). > > The upstream python package included it's own copy of the c code. I fixed > that problem so the python package would use the installed ipython c devel > package. I'm guessing that the messed-up upstream is not quite as messed up as this description, and that actually everything is called "igraph-0.4.5" and nothing is called "ipython". > Only 1 little problem. > > I renamed the python source to python-igraph-{version}.tar.gz. I did: > > %setup -q -n igraph-%{version} > > Now it builds fine, but: > sudo rpm -U ~/RPM/RPMS/x86_64/python-igraph-* > file /usr/src/debug/igraph-0.4.5/src/error.c from install of > python-igraph-debuginfo-0.4.5-1.fc8.x86_64 conflicts with file from package The fact that this file exists in python-igraph-debuginfo suggests that you did not really manage to get rid of the included copy of the C code. If it didn't compile its own copy, wouldn't it only refer to the C headers installed by the igraph-devel package and not have any of its own? > igraph-debuginfo-0.4.5-1.fc8.x86_64 > file /usr/src/debug/igraph-0.4.5/src/error.h from install of > python-igraph-debuginfo-0.4.5-1.fc8.x86_64 conflicts with file from package > igraph-debuginfo-0.4.5-1.fc8.x86_64 > > Any ideas how to fix this? It is an issue with the debuginfo-generation setup that /usr/src/debug/FOO is used by all packages that unpacked their sources into %{_builddir}/FOO. But that is a complex can of worms I'd rather not get into just now. In your case it seems that this limitation has probably actually been a boon in catching for you something you didn't intend to be trying. Thanks, Roland From lesmikesell at gmail.com Thu Jan 24 03:28:01 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 23 Jan 2008 21:28:01 -0600 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <4797FAE4.80602@redhat.com> References: <4797FAE4.80602@redhat.com> Message-ID: <479805C1.4080005@gmail.com> Warren Togami wrote: > Yum and Proxy Caches: Current Dangers > ===================================== > Users may be using proxy servers in 3 (or more) ways: Is there a reasonable way to make yum automatically use files cached in these local proxies when run by multiple users that share the proxy but don't know about each other? Picking some random mirror for each will defeat the caching since they will have different URLs to get the same file. -- Les Mikesell lesmikesell at gmail.com From mtasaka at ioa.s.u-tokyo.ac.jp Thu Jan 24 03:39:24 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 24 Jan 2008 12:39:24 +0900 Subject: Help with packaging igraph (stuck on debuginfo) In-Reply-To: References: Message-ID: <4798086C.8050408@ioa.s.u-tokyo.ac.jp> Neal Becker wrote, at 01/24/2008 11:23 AM +9:00: > I put together a package for igraph-0.4.5 and python bindings. > Unfortunately, the upstream is a bit messed up. The python package is > called exactly the same name (the original C is called ipython-0.4.5 and so > is the python package). > > The upstream python package included it's own copy of the c code. I fixed > that problem so the python package would use the installed ipython c devel > package. > > Only 1 little problem. > > I renamed the python source to python-igraph-{version}.tar.gz. I did: > > %setup -q -n igraph-%{version} > > Now it builds fine, but: > sudo rpm -U ~/RPM/RPMS/x86_64/python-igraph-* > file /usr/src/debug/igraph-0.4.5/src/error.c from install of > python-igraph-debuginfo-0.4.5-1.fc8.x86_64 conflicts with file from package > igraph-debuginfo-0.4.5-1.fc8.x86_64 > file /usr/src/debug/igraph-0.4.5/src/error.h from install of > python-igraph-debuginfo-0.4.5-1.fc8.x86_64 conflicts with file from package > igraph-debuginfo-0.4.5-1.fc8.x86_64 > > Any ideas how to fix this? > A quick workaround is using "%setup -q -c" then executing "cd igraph-%{version}". Regards, Mamoru From wtogami at redhat.com Thu Jan 24 04:14:34 2008 From: wtogami at redhat.com (Warren Togami) Date: Wed, 23 Jan 2008 23:14:34 -0500 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <20080123220451.4984e818@redhat.com> References: <20080123220451.4984e818@redhat.com> Message-ID: <31b150b46dbc74c268e66f12632a4f13@togami.com> On Wed, 23 Jan 2008 22:04:51 -0500, Jesse Keating wrote: > On Wed, 23 Jan 2008 21:41:40 -0500 > Warren Togami wrote: > >> i.e. >> primary-1201140584.sqlite.bz2 >> >> This would be an elegant solution, but will it be possible for us to >> migrate to because older clients wouldn't be able to handle it? >> >> I'm guessing not, so here are other less efficient but workable >> solutions. > > Hrm, I would think that this would be possible for recentish clients > (RHEL5 and later?). repomd.xml lists out what the other files are, > and the checksums of them, so if the files are named slightly different > yum should handle it I would think. > > In fact, I just tried this by hand. I edited repomd.xml and changed > 'primary.sqlite.bz2' to 'primary-1234.sqlite.bz2' and then moved the > file on the file system. Yum client didn't even blink, it happily > downloaded the -1234 file. (away from my computer, can't test this until tomorrow) Oh cool! Can somebody please test how far back in yum versions this works and report back here? > > So if this method is possible, does that change things for the better > for you? I think all it would require is slight modification to > createrepo so that it could timestamp the repo files. > We need to think a bit more and do some testing to be sure there are no drawbacks in doing this. If our findings are good, are we comfortable changing this for the Fedora 7 and Fedora 8 updates repos? This would instantly make reverse proxy mirrors of Fedora less error prone and *WAY* easier to deploy. (Let us please do this on static-repos as well, the problem is even worse there.) Warren Togami wtogami at redhat.com From rc040203 at freenet.de Thu Jan 24 04:28:03 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 24 Jan 2008 05:28:03 +0100 Subject: long term support release In-Reply-To: <20080123212556.GE6543@jasmine.xos.nl> References: <1201058211.3001.79.camel@gandalf.cobite.com> <47972980.7000804@odu.neva.ru> <20080123150921.GB32532@jasmine.xos.nl> <20080123212556.GE6543@jasmine.xos.nl> Message-ID: <1201148883.17905.73.camel@beck.corsepiu.local> On Wed, 2008-01-23 at 22:25 +0100, Jos Vos wrote: > On Wed, Jan 23, 2008 at 09:48:20PM +0100, Benny Amorsen wrote: > > > RHEL and its derivatives, just like SUSE and Debian Stable, are > > comparatively conservative. I need e.g. working QinQ, and that means > > a 2.6.23 kernel. There's also a lot of software missing in RHEL -- > > like OpenSwan and Asterisk. > > For the latter you can use EPEL (but not all is there yet, of course). > > The first is true, but IMHO being (more) conservative in related to > having a LTS release, so I don't see that much difference between > a suggested Fedora LTS and RHEL/CentOS. The #1 difference is 1000's of packages. The #2 difference is RHEL being an ultra conservative distro. Wrt. life-time and features, in comparison to Fedora, it's the other extreme. > Yes, but this sounds a bit like wanting to have a bleeding-edge distro, > with a huge amount of packages, and with long time support. > > Good luck finding a company wanting to build/maintain such a distro ;-). It could be called Fedora - The only thing Fedora lacks is an extended life time. Ralf From lordmorgul at gmail.com Thu Jan 24 04:30:30 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 23 Jan 2008 20:30:30 -0800 Subject: RFE: prevent broken rawhide network install due to repo change Message-ID: <47981466.2030603@gmail.com> RFE: prevent broken rawhide network install due to repo change Problem: network installs will currently fail if the repository changes during the installation, which can take 2-4 hours or more, and changed files are removed from the repo, making anaconda fail to download the expected version of that changed file If a user has started a network install then any change in files not yet downloaded will completely break that install. The user will see anaconda fail to get the file 10 times, then suggest rebooting and starting the install again. This wastes time and network traffic, since the repository could have only changed the last file that installer needed... and they will subsequently download them all again (this time hopefully missing the period the repo changes). To solve the problem all that is necessary is for the repo to hold all changed files for a period (probably 3-4 hours for the typical install time) so that any installs that have begun before the changes to the repo data can finish. The depsolving in anaconda does not recognize a change in the repodata and attempt to resume the install with the new data, so either 1) that needs implemented, or 2) the mirrors need to hold the files for awhile even though the repodata no longer has them included. Would it be possible for the repository data to be created while excluding any files that were updated during that build, leaving the old files out of listings, but actually leave the file present and accessible by direct request? This would improve the network install experience because it is difficult to anticipate when the repo changes will break the install process for \insert random mirror\. The caveat to the solution is that the repository needs to be cleaned some time later by another process which would know which files are now old (not included in the repo data) and delete them. In the meantime (again suggesting 3-4 hour overlap) there will be a slightly larger disk space needed because of the duplication. Any mirrors that sync to rawhide while there are duplicated files should have those files already (from the day before) and would only fetch the new files. Those mirrors could either 1) keep the duplicate files all day until the next sync, or 2) have their own cleaning process such as a cron job. In either case, anyone requesting an installation while the duplicates are there would not be effected. I've run into this problem several times when doing network rawhide installs, especially if started late night in California (meaning the repo build and mirror syncs are likely to overlap the install). I am unaware obviously of where the infrastructure would need to be changed to handle this, though I assume a combination of koji and elsewhere (both in building the repo data and afterward in deleting the temporarily remaining files). If there is anything already in place to solve/work on this issue point me in the right direction, because its not working. ;) Also I think this is only an issue with rawhide since the release mirrors keep the original released files and then updates go elsewhere. Development on the other hand has issues with the changes because files disappear. I'd be happy to move this suggestion to where it belongs (bugzilla against ?) -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From warren at togami.com Thu Jan 24 04:45:09 2008 From: warren at togami.com (Warren Togami) Date: Wed, 23 Jan 2008 23:45:09 -0500 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <479805C1.4080005@gmail.com> References: <479805C1.4080005@gmail.com> Message-ID: <797f919ef07923e0bf0802fcfd35a458@togami.com> On Wed, 23 Jan 2008 21:28:01 -0600, Les Mikesell wrote: > Warren Togami wrote: > >> Yum and Proxy Caches: Current Dangers >> ===================================== >> Users may be using proxy servers in 3 (or more) ways: > > Is there a reasonable way to make yum automatically use files cached in > these local proxies when run by multiple users that share the proxy but > don't know about each other? Picking some random mirror for each will > defeat the caching since they will have different URLs to get the same > file. http://fedoraproject.org/wiki/Infrastructure/Mirroring/SiteLocalMirrors This page needs updating, but it sort of describes what you need to do. Use your Fedora account to login to MirrorManager and add a private mirror for yourself along with a site-local netblock in CIDR notation so the mirror master knows to serve to you when yum clients come from your network. After a few hours, mirror lists will serve your mirror first, then random other mirrors in your country/region. Example, I have InstantMirror running on my Buffalo Linkstation (hard drive + ethernet running embedded Linux) at home. I gave that box a private IP address and pointed a sub-domain name at that (so I could use Apache name-based VirtualHost for InstantMirror). I then added to MirrorManager "Warren's Private Home Mirror" which only I can see when I login to the management interface. In both cases it is REALLY handy when all of your local clients automatically begin using your local mirror. Oh, there might be one more complication. You may need to checkout the sources for MirrorManager and run the script that reports to MirrorManager that your mirror is populated. I think mdomsch mentioned that the checkbox on the MirrorManager interface isn't yet working. Matt, what's the status of this? Hopefully that last wrinkle should be gone soon. Warren Togami wtogami at redhat.com From lordmorgul at gmail.com Thu Jan 24 04:34:28 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 23 Jan 2008 20:34:28 -0800 Subject: RFE: prevent broken rawhide network install due to repo change In-Reply-To: <47981466.2030603@gmail.com> References: <47981466.2030603@gmail.com> Message-ID: <47981554.3090308@gmail.com> Andrew Farris wrote: > Any mirrors that sync to rawhide while there are duplicated files should > have those files already (from the day before) and would only fetch the > new files. Those mirrors could either 1) keep the duplicate files all > day until the next sync, or 2) have their own cleaning process such as a > cron job. In either case, anyone requesting an installation while the > duplicates are there would not be effected. To clarify 'cleaning process' I envisioned that koji would create a list of the files changed during that build, those that are then going to be removed, and include that in the repo top level directory. A cron job on the mirrors could just read that 'files removed during build' list and remove them after that 'overlap period'. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From cra at WPI.EDU Thu Jan 24 05:20:22 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 24 Jan 2008 00:20:22 -0500 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <31b150b46dbc74c268e66f12632a4f13@togami.com> References: <20080123220451.4984e818@redhat.com> <31b150b46dbc74c268e66f12632a4f13@togami.com> Message-ID: <20080124052022.GA31787@angus.ind.WPI.EDU> On Wed, Jan 23, 2008 at 11:14:34PM -0500, Warren Togami wrote: > > In fact, I just tried this by hand. I edited repomd.xml and changed > > 'primary.sqlite.bz2' to 'primary-1234.sqlite.bz2' and then moved the > > file on the file system. Yum client didn't even blink, it happily > > downloaded the -1234 file. > > (away from my computer, can't test this until tomorrow) > Oh cool! Can somebody please test how far back in yum versions this works > and report back here? Works on FC5, yum-2.6.1-0.fc5, ftp and http baseurls. I renamed all the xml files and tested yum install, yum search, yum info, yum provides. No problems. This change would help enormously with people stuck behind transparent proxies, often without their knowledge. From lesmikesell at gmail.com Thu Jan 24 05:39:54 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 23 Jan 2008 23:39:54 -0600 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <797f919ef07923e0bf0802fcfd35a458@togami.com> References: <479805C1.4080005@gmail.com> <797f919ef07923e0bf0802fcfd35a458@togami.com> Message-ID: <479824AA.3050108@gmail.com> Warren Togami wrote: > On Wed, 23 Jan 2008 21:28:01 -0600, Les Mikesell > wrote: >> Warren Togami wrote: >> >>> Yum and Proxy Caches: Current Dangers >>> ===================================== >>> Users may be using proxy servers in 3 (or more) ways: >> Is there a reasonable way to make yum automatically use files cached in >> these local proxies when run by multiple users that share the proxy but >> don't know about each other? Picking some random mirror for each will >> defeat the caching since they will have different URLs to get the same >> file. > > http://fedoraproject.org/wiki/Infrastructure/Mirroring/SiteLocalMirrors > This page needs updating, but it sort of describes what you need to do. > Use your Fedora account to login to MirrorManager and add a private mirror > for yourself along with a site-local netblock in CIDR notation so the > mirror master knows to serve to you when yum clients come from your > network. After a few hours, mirror lists will serve your mirror first, > then random other mirrors in your country/region. Interesting, but it still requires custom setup for any distro/version that the proxy admin would want to support. What I'd really like to happen is for yum to just always prefer the same URL when working through the same proxy so caching would work by default without needing to be aware of the cache content. This would work automatically if the target was a single site, RRDNS, or geo-ip managed DNS, but you probably can't arrange that for all the repo mirrors. There has to be some clever way to get the same effect even when using a mirrorlist - like making sure the mirrorlist itself is cached and always picking the same entry so any client will use the same URL that the mirrormanger gave to the first one that made a request. Of course you'd need a reasonable retry mechanism to pick something else if this choice fails but I'd guess it would be a big win in bandwidth use and load on the mirrors if it worked most of the time to take advantage of existing local caches with no modifications. -- Les Mikesell lesmikesell at gmail.com From michel.sylvan at gmail.com Thu Jan 24 05:44:47 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Thu, 24 Jan 2008 00:44:47 -0500 Subject: [fedora-arm] Re: Fedora 8/ARM available In-Reply-To: References: <20080114233331.GL17358@xi.wantstofly.org> Message-ID: On Jan 20, 2008 2:16 PM, Manas Saksena wrote: > On Jan 17, 2008 4:13 PM, Michel Salim wrote: > > On Jan 14, 2008 6:33 PM, Lennert Buytenhek wrote: > > > Hi all, > > > > > > We are proud to announce the availability of a(n unofficial) > > > Fedora 8 package repository for the ARM architecture. > > > > Great news! Would it be possible to install this on Scratchbox? > > Maemo's SDK is already using it. > > Are you, perhaps, thinking of QEMU? Scratchbox is a tool to build > packages. We dont use it for Fedora/ARM as we build the packages > natively. > I was thinking of Scratchbox -- it can actually use QEMU for CPU transparency, allowing someone to work on a normal terminal window without having to fire up an entire emulated OS. The one thing that is nice about Scratchbox is it lets you mix-and-match native and cross-platform binaries -- I've used it when I needed to run some Intel-only tools when developing for ARM. Will have to look up the Scratchbox documentation more closely to see if it can be easily adapted to use any root FS images. Thanks, -- Michel Salim From rc040203 at freenet.de Thu Jan 24 06:13:39 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 24 Jan 2008 07:13:39 +0100 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <4797C29E.5000001@gmail.com> References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <4797C29E.5000001@gmail.com> Message-ID: <1201155219.17905.84.camel@beck.corsepiu.local> On Wed, 2008-01-23 at 22:41 +0000, Ian Malone wrote: > Tom Tromey wrote: > >>>>>> "Kevin" == Kevin Kofler writes: > > > >>> Closing a bug report with "report it upstream" is a let down. It's > >>> repetitive boring work that a computer should be doing. > > > > Kevin> There's no way we can fix them all by ourselves, the only way > > Kevin> to actually get things fixed is to report them to the actual > > Kevin> upstream maintainers of the concrete application you're having > > Kevin> issues with. And I don't think KDE is the only set of packages > > Kevin> in this situation. > > > > What would be good here is an easy way to push a report upstream. > No, the maintainer shouldn't have to act as a proxy, Maintainers should "maintain" their packages, not simply "package them up" . > but it would > be nice to have some automated mechanism that would. IIRC, Debian once had tried this - It had never really worked. Those reports ended up being ignored. Ralf From rc040203 at freenet.de Thu Jan 24 06:31:27 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 24 Jan 2008 07:31:27 +0100 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <200801232229.m0NMTwEf007941@laptop13.inf.utfsm.cl> References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> <1200766980.2961.8.camel@sb-home> <604aa7910801192136u754e6a4ex1c3c0113440c4e02@mail.gmail.com> <1200900997.2845.12.camel@beck.corsepiu.local> <200801232229.m0NMTwEf007941@laptop13.inf.utfsm.cl> Message-ID: <1201156287.17905.97.camel@beck.corsepiu.local> On Wed, 2008-01-23 at 19:29 -0300, Horst H. von Brand wrote: > Ralf Corsepius wrote: > > On Sat, 2008-01-19 at 20:36 -0900, Jeff Spaleta wrote: > > > On Jan 19, 2008 9:23 AM, nodata wrote: > > > > I'm talking about closing the bug and telling the reporter to report > > > > upstream, i.e. "go away". > > > > As a package maintainer, what would you like me to do in situations > > > where I need the reporter to talk to upstream? > > > A reporter should never be supposed to talk upstream, because he is > > reporting an issue a problem with the product (your package) you are > > supposed to be responsible for, not against the product an upstream > > ships to you (the source tarball). > > It might very well happen that the packager can't reproduce the problem > (doesn't have the exact hardware, whatever). Yes, it _might_ happen, nobody denies this, but ... ... this is far from being the rule/norm. Often reporters are ordinary user, who actually don't have much clues about an application's internals, who "just reports something" he considers to be a "bug" or an application "misbehavior". Forcing them to "go upstream" would mean to push them into a forum they often aren't really interested to participate in nor competent enough to participate. Ralf From kevin.kofler at chello.at Thu Jan 24 06:34:25 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 24 Jan 2008 06:34:25 +0000 (UTC) Subject: long term support release References: <1201058211.3001.79.camel@gandalf.cobite.com> <16de708d0801222002o51b7d771jaa8606128a11f93b@mail.gmail.com> <1201102182.3001.116.camel@gandalf.cobite.com> Message-ID: David Mansfield dm.cobite.com> writes: > if you have any 'install from source' programs, it's hit-or-miss as to > whether they'll need to be recompiled, reinstalled and reconfigured, and > in my 10 years experience, I've learned to never bring precompiled code > from another platform over, even if the other platform is Fedora > $(current-1). Well, at http://repo.calcforge.org/fedora/ I only rebuild the packages which actually need rebuilding for the newer Fedora (but if I build a new version for another reason, it will be built on the newer Fedora), there's at least one package which was built on Fedora Core 5 and still runs fine on Fedora 8. Figuring out whether a package needs rebuilding is fairly easy: if it has broken dependencies, rebuild, if you try running it and it doesn't start up, rebuild, otherwise it's very likely not to need a rebuild, so just leave it as is and only rebuild if you (or somebody else using your builds, if any) notice any breakage. Kevin Kofler From mmcgrath at redhat.com Thu Jan 24 06:37:31 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 24 Jan 2008 00:37:31 -0600 (CST) Subject: Outage Notification - 2008-01-24 06:34 UTC Message-ID: There will be an outage starting at UTC, which lasted approximately .5 hour. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2008-01-24 06:34 UTC' Affected Services: Websites Buildsystem Database Unaffected Services: DNS Mail Torrent CVS / Source Control Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/353 Reason for Outage: Db2 seems to have OOMed which is very unusual for it, we've seen poor performance recently but never an OOM. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From rc040203 at freenet.de Thu Jan 24 06:42:35 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 24 Jan 2008 07:42:35 +0100 Subject: An interesting read when discussing what to do about our bugs... In-Reply-To: <20080123210618.GA21303@devserv.devel.redhat.com> References: <20080118131620.748606a0@redhat.com> <200801181336.48285.ben.kreuter@gmail.com> <1200766097.2961.5.camel@sb-home> <1200766249.3275.14.camel@cutter> <1200766980.2961.8.camel@sb-home> <604aa7910801192136u754e6a4ex1c3c0113440c4e02@mail.gmail.com> <1200900997.2845.12.camel@beck.corsepiu.local> <604aa7910801231206x7d1a7471yf2158cefb68b0aeb@mail.gmail.com> <20080123151818.02647429@redhat.com> <62043.63.85.68.164.1201119601.squirrel@mail.jcomserv.net> <20080123210618.GA21303@devserv.devel.redhat.com> Message-ID: <1201156955.17905.102.camel@beck.corsepiu.local> On Wed, 2008-01-23 at 16:06 -0500, Alan Cox wrote: > On Wed, Jan 23, 2008 at 02:20:01PM -0600, Jon Ciesla wrote: > > >> specific breakage to be proactive and tap into the upstream resource > > >> when I can't confirm the problem. > > > > > > There is a huge difference between engaging the user and helping them > > > to contact upstream, or getting upstream in contact with the user, > > > basically facilitating that wonderful communication, and saying "Shut > > > up, that's upstream, go away" and closing the bug. Unfortunately, the latter also happens. > > Very true, it MUST be a collaborative exercise. > > I try to leave the RH bug open and even if I report it being an upstream > problem then update it now and again with the status of things. That way > people at least know something is happening and when it will be worth trying > an update Fully agreed, that's the only viable and reasonable approach. Ralf From kushaldas at gmail.com Thu Jan 24 07:20:56 2008 From: kushaldas at gmail.com (Kushal Das) Date: Thu, 24 Jan 2008 12:50:56 +0530 Subject: Where are the CD ISO's? In-Reply-To: <20080116111445.61320126@redhat.com> References: <1200497030.5174.321.camel@beck.corsepiu.local> <20080116111445.61320126@redhat.com> Message-ID: <200801241250.56801.kushaldas@gmail.com> Hi all, I tried livecd-iso-to-disk with livecd images, and it simply rocks. I can boot my system from my USB key. Kushal -- Fedora Ambassador, India http://kushaldas.in http://dgplug.org (Linux User Group of Durgapur) From wtogami at redhat.com Thu Jan 24 07:31:25 2008 From: wtogami at redhat.com (Warren Togami) Date: Thu, 24 Jan 2008 02:31:25 -0500 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <479824AA.3050108@gmail.com> References: <479805C1.4080005@gmail.com> <797f919ef07923e0bf0802fcfd35a458@togami.com> <479824AA.3050108@gmail.com> Message-ID: <47983ECD.8000304@redhat.com> Les Mikesell wrote: > > Interesting, but it still requires custom setup for any distro/version > that the proxy admin would want to support. What I'd really like to > happen is for yum to just always prefer the same URL when working > through the same proxy so caching would work by default without needing > to be aware of the cache content. This would work automatically if the > target was a single site, RRDNS, or geo-ip managed DNS, but you probably > can't arrange that for all the repo mirrors. There has to be some clever > way to get the same effect even when using a mirrorlist - like making > sure the mirrorlist itself is cached and always picking the same entry > so any client will use the same URL that the mirrormanger gave to the > first one that made a request. Of course you'd need a reasonable retry > mechanism to pick something else if this choice fails but I'd guess it > would be a big win in bandwidth use and load on the mirrors if it worked > most of the time to take advantage of existing local caches with no > modifications. > I am NOT SURE about this, and it might be NOT SAFE to do (might make a public mirror disappear from others?), but I suspect that adding your site-local netblock to one of the mirrors might make that mirror always appear first in your mirrorlist. Anyone else know how MirrorManager handles this? Currently only the mirror owner has access to add site-local netblocks so this isn't a self-serve solution for users yet. Warren Togami wtogami at redhat.com From lordmorgul at gmail.com Thu Jan 24 07:56:12 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 23 Jan 2008 23:56:12 -0800 Subject: RFE: prevent broken rawhide network install due to repo change In-Reply-To: <47981466.2030603@gmail.com> References: <47981466.2030603@gmail.com> Message-ID: <4798449C.3000904@gmail.com> Andrew Farris wrote: > RFE: prevent broken rawhide network install due to repo change I just love replying to myself so I'll do it again. I realized the fedora infrastructure trac is probably the place for this, so opened ticket: https://fedorahosted.org/fedora-infrastructure/ticket/354 -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From wtogami at redhat.com Thu Jan 24 07:52:37 2008 From: wtogami at redhat.com (Warren Togami) Date: Thu, 24 Jan 2008 02:52:37 -0500 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <479824AA.3050108@gmail.com> References: <479805C1.4080005@gmail.com> <797f919ef07923e0bf0802fcfd35a458@togami.com> <479824AA.3050108@gmail.com> Message-ID: <479843C5.7030800@redhat.com> Les Mikesell wrote: > > Interesting, but it still requires custom setup for any distro/version > that the proxy admin would want to support. What I'd really like to > happen is for yum to just always prefer the same URL when working > through the same proxy so caching would work by default without needing > to be aware of the cache content. This would work automatically if the > target was a single site, RRDNS, or geo-ip managed DNS, but you probably > can't arrange that for all the repo mirrors. There has to be some clever > way to get the same effect even when using a mirrorlist - like making > sure the mirrorlist itself is cached and always picking the same entry > so any client will use the same URL that the mirrormanger gave to the > first one that made a request. Of course you'd need a reasonable retry > mechanism to pick something else if this choice fails but I'd guess it > would be a big win in bandwidth use and load on the mirrors if it worked > most of the time to take advantage of existing local caches with no > modifications. > I just thought of a simple but gross solution for you. http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-$releasever&arch=$basearch It sounds like you are using a transparent proxy. Just redirect mirrors.fedoraproject.org to localhost at another port and serve files so the mirrorlist URL's hand back a single mirror of your choosing. Warren Togami wtogami at redhat.com From rc040203 at freenet.de Thu Jan 24 04:56:48 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 24 Jan 2008 05:56:48 +0100 Subject: long term support release In-Reply-To: <47979470.6010507@leemhuis.info> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <20080123103336.6e24109f@redhat.com> <47976399.3010709@redhat.com> <47979470.6010507@leemhuis.info> Message-ID: <1201150608.17905.78.camel@beck.corsepiu.local> On Wed, 2008-01-23 at 20:24 +0100, Thorsten Leemhuis wrote: > On 23.01.2008 16:56, Jarod Wilson wrote: > > Honestly, in my eyes, RHEL/CentOS + EPEL >= Ubuntu LTS, and a separate Fedora > > LTS is completely unwarranted. > > Agreed. But the different names (Fedora != CentOS) make a very very big > difference for a lot of people and the press. IOW: we Wrong: You, in your position as proponent of EPEL want to make it look as such. > might see > RHEL/CentOS + EPEL as Fedora LTS, but for the world CentOS and Fedora > are totally different things. Right. CentOS is a different distro. It is not RHEL nor Fedora. It's the same difference as between Debian and its recompile called Ubuntu. RHEL and CentOS just happen to be largely compatible, because they are derivatives from the same sources. Ralf From pertusus at free.fr Thu Jan 24 08:17:20 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 24 Jan 2008 09:17:20 +0100 Subject: long term support release In-Reply-To: <1201150608.17905.78.camel@beck.corsepiu.local> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <20080123103336.6e24109f@redhat.com> <47976399.3010709@redhat.com> <47979470.6010507@leemhuis.info> <1201150608.17905.78.camel@beck.corsepiu.local> Message-ID: <20080124081720.GA2636@free.fr> On Thu, Jan 24, 2008 at 05:56:48AM +0100, Ralf Corsepius wrote: > > > RHEL/CentOS + EPEL as Fedora LTS, but for the world CentOS and Fedora > > are totally different things. > Right. CentOS is a different distro. It is not RHEL nor Fedora. > It's the same difference as between Debian and its recompile called > Ubuntu. There are more difference between ubuntu and debian than between rhel and centos (and even more so in centos5/RHEL5 since yum is everywhere now). > RHEL and CentOS just happen to be largely compatible, because they are > derivatives from the same sources. They are more than largely compatible, they are almost similar. There are differences, but not really related to the bits (not the same entity behind, different support and price, additional channels for RHEL...). -- Pat From nicolas.mailhot at laposte.net Thu Jan 24 08:22:47 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 24 Jan 2008 09:22:47 +0100 (CET) Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <20080123220451.4984e818@redhat.com> References: <4797FAE4.80602@redhat.com> <20080123220451.4984e818@redhat.com> Message-ID: <38259.192.54.193.53.1201162967.squirrel@rousalka.dyndns.org> Le Jeu 24 janvier 2008 04:04, Jesse Keating a ?crit : > On Wed, 23 Jan 2008 21:41:40 -0500 > Warren Togami wrote: > In fact, I just tried this by hand. I edited repomd.xml and changed > 'primary.sqlite.bz2' to 'primary-1234.sqlite.bz2' and then moved the > file on the file system. Yum client didn't even blink, it happily > downloaded the -1234 file. > > So if this method is possible, does that change things for the better > for you? I made the same analysis several months ago when I setup my own local mod_proxy cache. I'm glad to see Warren is getting through better than me at the time. Changing file contents while keeping the same filename is the ultimate proxy sin. -- Nicolas Mailhot From nicolas.mailhot at laposte.net Thu Jan 24 08:30:40 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 24 Jan 2008 09:30:40 +0100 (CET) Subject: Live images and fonts In-Reply-To: <200801240029.35792.ml@deadbabylon.de> References: <200801240029.35792.ml@deadbabylon.de> Message-ID: <16144.192.54.193.53.1201163440.squirrel@rousalka.dyndns.org> Le Jeu 24 janvier 2008 00:29, Sebastian Vahl a ?crit : > Hi. Hi, > After some time I've done a new test spin of my kde live images today. > What > I've experienced is that most of the former installed fonts are > missing. A > diff between my released rawhide live image for KDE 4 and my current > one is: I know next to nothing about live images but I confirm that the fedora font landscape changed quite a bit since fedora 8 (new fonts, pulled fonts, renamed fonts, new defaults) so anything font-related done at F8 time probably needs to be revisited now Regards, -- Nicolas Mailhot From rc040203 at freenet.de Thu Jan 24 09:13:42 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 24 Jan 2008 10:13:42 +0100 Subject: long term support release In-Reply-To: <20080124081720.GA2636@free.fr> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <20080123103336.6e24109f@redhat.com> <47976399.3010709@redhat.com> <47979470.6010507@leemhuis.info> <1201150608.17905.78.camel@beck.corsepiu.local> <20080124081720.GA2636@free.fr> Message-ID: <1201166022.17905.109.camel@beck.corsepiu.local> On Thu, 2008-01-24 at 09:17 +0100, Patrice Dumas wrote: > On Thu, Jan 24, 2008 at 05:56:48AM +0100, Ralf Corsepius wrote: > > > > > RHEL/CentOS + EPEL as Fedora LTS, but for the world CentOS and Fedora > > > are totally different things. > > Right. CentOS is a different distro. It is not RHEL nor Fedora. > > It's the same difference as between Debian and its recompile called > > Ubuntu. > > There are more difference between ubuntu and debian than between > rhel and centos (and even more so in centos5/RHEL5 since yum is > everywhere now). Gotcha! RHEL and CentOS are different OSes. > > RHEL and CentOS just happen to be largely compatible, because they are > > derivatives from the same sources. > > They are more than largely compatible, they are almost similar. There > are differences, but not really related to the bits Unless you buy RHEL from RH, you will not be able to tell. Ralf From mmcgrath at redhat.com Thu Jan 24 11:02:18 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 24 Jan 2008 05:02:18 -0600 (CST) Subject: long term support release In-Reply-To: <1201166022.17905.109.camel@beck.corsepiu.local> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <20080123103336.6e24109f@redhat.com> <47976399.3010709@redhat.com> <47979470.6010507@leemhuis.info> <1201150608.17905.78.camel@beck.corsepiu.local> <20080124081720.GA2636@free.fr> <1201166022.17905.109.camel@beck.corsepiu.local> Message-ID: On Thu, 24 Jan 2008, Ralf Corsepius wrote: > > On Thu, 2008-01-24 at 09:17 +0100, Patrice Dumas wrote: > > On Thu, Jan 24, 2008 at 05:56:48AM +0100, Ralf Corsepius wrote: > > > > > > > RHEL/CentOS + EPEL as Fedora LTS, but for the world CentOS and Fedora > > > > are totally different things. > > > Right. CentOS is a different distro. It is not RHEL nor Fedora. > > > It's the same difference as between Debian and its recompile called > > > Ubuntu. > > > > There are more difference between ubuntu and debian than between > > rhel and centos (and even more so in centos5/RHEL5 since yum is > > everywhere now). > Gotcha! RHEL and CentOS are different OSes. > Any differences you find between RHEL and CentOS should be reported to the CentOS guys. They'd be very interested to know as I think a project goal of theirs is to be as binary compatible with RHEL as possible. We use both CentOS and RHEL in our environment. The same EPEL trees work fine with both and, at times, we've even cross used CentOS RPM's on RHEL without any issue (we had to for various reasons) /2 cents. -Mike From ndbecker2 at gmail.com Thu Jan 24 11:12:00 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 24 Jan 2008 06:12:00 -0500 Subject: Help with packaging igraph (stuck on debuginfo) References: <20080124032515.0AD8326F9FD@magilla.localdomain> Message-ID: Roland McGrath wrote: >> I put together a package for igraph-0.4.5 and python bindings. >> Unfortunately, the upstream is a bit messed up. The python package is >> called exactly the same name (the original C is called ipython-0.4.5 and >> so is the python package). >> >> The upstream python package included it's own copy of the c code. I >> fixed that problem so the python package would use the installed ipython >> c devel package. > > I'm guessing that the messed-up upstream is not quite as messed up as this > description, and that actually everything is called "igraph-0.4.5" and > nothing is called "ipython". Sorry, s/ipython/igraph > >> Only 1 little problem. >> >> I renamed the python source to python-igraph-{version}.tar.gz. I did: >> >> %setup -q -n igraph-%{version} >> >> Now it builds fine, but: >> sudo rpm -U ~/RPM/RPMS/x86_64/python-igraph-* >> file /usr/src/debug/igraph-0.4.5/src/error.c from install of >> python-igraph-debuginfo-0.4.5-1.fc8.x86_64 conflicts with file from >> package > > The fact that this file exists in python-igraph-debuginfo suggests that > you > did not really manage to get rid of the included copy of the C code. If > it didn't compile its own copy, wouldn't it only refer to the C headers > installed by the igraph-devel package and not have any of its own? > >> igraph-debuginfo-0.4.5-1.fc8.x86_64 >> file /usr/src/debug/igraph-0.4.5/src/error.h from install of >> python-igraph-debuginfo-0.4.5-1.fc8.x86_64 conflicts with file from >> package igraph-debuginfo-0.4.5-1.fc8.x86_64 >> >> Any ideas how to fix this? No, I _did_ get rid of included copy. The problem is, python-igraph has re-used the same path name. Both have a igraph-%{version}/src/error.c, but they are _different_ files. I think there are 2 options, but I don't know how to implement either one: 1) Build into python-igraph instead of igraph. 2) Find some way to fix debuginfo The other possibility: 3) Disable debuginfo (not very desirable) Any thoughts? From alan at redhat.com Thu Jan 24 11:17:07 2008 From: alan at redhat.com (Alan Cox) Date: Thu, 24 Jan 2008 06:17:07 -0500 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <4797FAE4.80602@redhat.com> References: <4797FAE4.80602@redhat.com> Message-ID: <20080124111707.GB10714@devserv.devel.redhat.com> On Wed, Jan 23, 2008 at 09:41:40PM -0500, Warren Togami wrote: > primary-1201140584.sqlite.bz2 > > This would be an elegant solution, but will it be possible for us to > migrate to because older clients wouldn't be able to handle it? Yes - keep the "current" sqlite database in two places (or linked if the server is set up to allow that). Old clients will fetch the db blindly new ones will fetch the versioned ones From alan at redhat.com Thu Jan 24 11:32:01 2008 From: alan at redhat.com (Alan Cox) Date: Thu, 24 Jan 2008 06:32:01 -0500 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <479843C5.7030800@redhat.com> References: <479805C1.4080005@gmail.com> <797f919ef07923e0bf0802fcfd35a458@togami.com> <479824AA.3050108@gmail.com> <479843C5.7030800@redhat.com> Message-ID: <20080124113201.GD10714@devserv.devel.redhat.com> On Thu, Jan 24, 2008 at 02:52:37AM -0500, Warren Togami wrote: > It sounds like you are using a transparent proxy. Just redirect > mirrors.fedoraproject.org to localhost at another port and serve files > so the mirrorlist URL's hand back a single mirror of your choosing. Actually thats another way to handle the caching problem with most proxies and static content servers. If you get http://....../....static.file?random-16-digits apache and most web servers will discard the query bits and the cache won't be able to decide if the content is the same ;) From mschwendt.tmp0701.nospam at arcor.de Thu Jan 24 11:35:13 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 24 Jan 2008 12:35:13 +0100 Subject: long term support release In-Reply-To: <20080123132618.0660f673@redhat.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <20080123132618.0660f673@redhat.com> Message-ID: <20080124123513.6399f7d3.mschwendt.tmp0701.nospam@arcor.de> On Wed, 23 Jan 2008 13:26:18 -0500, Jesse Keating wrote: > On Wed, 23 Jan 2008 09:16:30 -0900 > "Jeff Spaleta" wrote: > > > Legacy was not a failure... it was a key part of the process of > > defining what the limits are with the resources we have. Now that we > > have gone through that, the people who have survived the process have > > a much better idea of what it takes in terms of a resource commitment > > to pull it off. > > > > I have absolutely no problem with another attempt at community effort > > as a follow-up to what Legacy did. I just don't think its where this > > community of contributors wants to contribute. I think at a minimum > > there are 3rd support specialists out there with a business interest > > in a Fedora LTS, or perhaps niche hardware vendors in the embedded > > space which could be persuaded to leverage Fedora as a development > > platform. Lots of unexplored area. > > It's perfectly OK to fail, in fact we should fail more often, and share > the results of those failures. It's only by failure that we'll know > the limits of our abilities. It may be "OK" in general, but it was very disappointing. Fedora Legacy leadership was not willing to learn from mistakes. As you may remember, Fedora Legacy started inside bugzilla.fedora.us, copied also the fedora.us package submission/review/approval process, including the corresponding bugzilla keywords. It had one foot in the grave already at the start. This resulted in updates waiting several weeks for approval, simply because the people providing those updates were treated as completely untrusted or incapable and were not permitted to publish any updates without prior approval. They had to wait endlessly for another person to sign off the updates, and obviously, even fewer volunteers were interested enough to be responsible for approving updates. For a project where speed does matter this was inacceptable and drove away or scared off contributors. From roland at redhat.com Thu Jan 24 11:41:31 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 24 Jan 2008 03:41:31 -0800 (PST) Subject: Help with packaging igraph (stuck on debuginfo) In-Reply-To: Neal Becker's message of Thursday, 24 January 2008 06:12:00 -0500 References: <20080124032515.0AD8326F9FD@magilla.localdomain> Message-ID: <20080124114131.9613626F9FD@magilla.localdomain> > No, I _did_ get rid of included copy. The problem is, python-igraph has > re-used the same path name. Both have a igraph-%{version}/src/error.c, but > they are _different_ files. > > I think there are 2 options, but I don't know how to implement either one: > 1) Build into python-igraph instead of igraph. Yes, just use a better top-level directory name for the build tree. Something like: %prep %setup -c -a0 %build make %{?_smp_mflags} -C igraph-%{version} Then you should have %{_builddir}/python-igraph-%{version}/igraph-%{version} and /usr/src/debug/python-igraph-NNN/igraph-NNN/src/foo.c in the debuginfo rpm. > 2) Find some way to fix debuginfo Eventually it will change so that this conflict is avoided automatically. But not soon enough, for complex reasons. Thanks, Roland From benny+usenet at amorsen.dk Thu Jan 24 11:47:27 2008 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Thu, 24 Jan 2008 12:47:27 +0100 Subject: long term support release References: <1201058211.3001.79.camel@gandalf.cobite.com> <47972980.7000804@odu.neva.ru> <20080123150921.GB32532@jasmine.xos.nl> <20080123212556.GE6543@jasmine.xos.nl> Message-ID: Jos Vos writes: > Yes, but this sounds a bit like wanting to have a bleeding-edge distro, > with a huge amount of packages, and with long time support. Absolutely. A couple of years ago I thought that Linux would mature quickly so that I would no longer need bleeding-edge stuff. Alas, new business requirements seem to be popping up all the time, whenever Linux makes something possible. > Good luck finding a company wanting to build/maintain such a distro ;-). Heh, yes the price tag would probably be a bit excessive and that by itself would limit the market. /Benny From ndbecker2 at gmail.com Thu Jan 24 12:08:28 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 24 Jan 2008 07:08:28 -0500 Subject: Help with packaging igraph (stuck on debuginfo) References: <20080124032515.0AD8326F9FD@magilla.localdomain> <20080124114131.9613626F9FD@magilla.localdomain> Message-ID: OK, I got it. Basically: %prep %setup -a0 -c cd igraph-%{version} This unpacks into python-igraph-%version/igraph-%version In build and install, I need to do: cd igraph-%{version} And in %doc need: igraph-%{version}/LICENSE Is there a more elegant way? Specifically, I can set RPM_BUILD_ROOT, which probably should have been named RPM_INSTALL_ROOT, but can I set the dir for the build so I don't need to keep doing 'cd blah'? From fedora at leemhuis.info Thu Jan 24 12:12:59 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 24 Jan 2008 13:12:59 +0100 Subject: InstantMirror needs a rethink In-Reply-To: <4797D5B3.7030002@redhat.com> References: <4797D5B3.7030002@redhat.com> Message-ID: <479880CB.8020300@leemhuis.info> On 24.01.2008 01:02, Warren Togami wrote: > Today InstantMirror is pretty useful for home and small office mirrors, > but its limitations make it unsustainable without manual intervention of > the sysadmin. > > I've been beginning to think that perhaps InstantMirror is heading down > the wrong path and we seriously need to rethink it. > [...] > Any thoughts? Just a hint (not sure if it is not be helpful): ixs in #fedora-devel mentioned http://gertjan.freezope.org/replicator/ once when you started on InstantMirror. Looks interesting and maybe could be a nice base for a new/improved InstantMirror. CU knurd From james.antill at redhat.com Thu Jan 24 12:41:47 2008 From: james.antill at redhat.com (James Antill) Date: Thu, 24 Jan 2008 07:41:47 -0500 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <4797FAE4.80602@redhat.com> References: <4797FAE4.80602@redhat.com> Message-ID: <1201178507.10257.35.camel@code.and.org> On Wed, 2008-01-23 at 21:41 -0500, Warren Togami wrote: > I just had an in-depth discussion with Henrik Nordstr?m of the Squid > project about how HTTP mirrors and the yum tool itself could be improved > to safely handle proxy caches. He gave me lots of good advice about how > HTTP mirrors can be configured for cache safety, Squid can be configured > for yum metadata cache safety, and yum itself can be improved to be more > robust in dealing with proxy caches. > > (It turns out that Henrik is an avid Fedora user, and I might have > convinced him to come onboard the Fedora Project to contribute another > useful tool and become co-maintainer of his own package. It would be an > honor to have him onboard as a Fedora Developer. =) You might have had a small discussion on #yum then, as any of the regulars there know the answers to all of your questions. > Yum and Proxy Caches: Current Dangers > ===================================== > Users may be using proxy servers in 3 (or more) ways: > > 1) Many users today are behind a transparent proxy cache, either > instituted by their ISP, school, or business network. > 2) Other users might have Internet access *only* through a proxy server. > 3) Other users might be using a reverse proxy server on their local > network as a caching yum mirror. > > There are two cases where yum has problems with proxy caches: > > 1) A RPM package changes content without changing filename. This > usually happens only in instances where a package was pushed unsigned > then was later signed. A simple workaround within yum is discussed > later in this mail. > > 2) yum currently has problems with proxy caches due to common cases > where metadata can become partially out of sync. This happens because > repomd.xml is grabbed often while other repodata files are grabbed less > often. repomd.xml is then checked for origin "freshness" more often. > When repodata changes on the origin, repomd.xml is refreshed on the > cache before other repodata files. yum clients seeing the new > repomd.xml but old primary.sqlite.bz2 error out. #2 is worked around as good as is possible, in the upcoming 3.2.9, in that yum will basically create a transaction over the repomd.xml and the metadata itself. If you use mdpolicy=group:all ... this will always work, the downside is that you'll need to download all of the metadata so the default is not that. > Ideal Solution for #2 Partial Repodata Sync Problem > =================================================== > Henrik highly suggests using versioned repodata files as the ideal > solution to this problem. This way caches can serve repodata without > fear of the sync problem, and also without querying the origin server > upon every client download. repomd.xml would contain changing filenames > perhaps with timestamp or something in their filenames. > > i.e. > primary-1201140584.sqlite.bz2 > > This would be an elegant solution, but will it be possible for us to > migrate to because older clients wouldn't be able to handle it? > > I'm guessing not, so here are other less efficient but workable solutions. We've discussed this and think this is probably the best solution, but: 1. Don't use timestamps, use the sha1 of the file, because then multiple createrepo's runs will always create the same filenames. 2. This requires work inside yum as atm. yum doesn't do any cleanup on it's metadata downloads so /var/cache/yum would grow without bound (although "yum clean ..." will work). ...we can fix #2 for 3.2.9, so we could do this in Fedora 9 onwards. > "Cache-Control: max-age=0" > ========================== > This HTTP header directive can be either in the request or response. > This instructs the proxy cache server to always query the origin HTTP > server to check if the requested file has changed. It compares the > origin's reported Last-Modified or ETag to what Squid knows in its own > cache. > > This means that each and every request for repodata/* files will trigger > a query to the origin server. This is a relatively quick operation and > an acceptable compromise if we cannot make repodata filenames versioned. This is a horrible hack, IMO, and I can pretty much guarantee that not all of the mirrors will do this. If it was possible for us to control all of the mirrors then we could just require them all to setup ETags and use that ... but again, I think that's hoping for way too much. [...] > Yum and "X-Cache: HIT" > ====================== > If you use wget --server-response and a target file, you see the raw > HTTP headers of that request. If the file is already cached, you see a > HTTP header like below: > > X-Cache: HIT from proxyserver.example.com > > Proposal: > Improve yum with the following download logic: > > IF (a downloaded repodata/* file doesn't match the repomd.xml checksum > OR a downloaded RPM doesn't match the expected checksum) > AND "X-Cache: HIT from" was in its HTTP header > THEN download it again with URLGrabber option: http_headers = > (('Pragma', 'no-cache') > > This should solve the case where RPM files legitimately change contents > without changing filenames, like RPM signing. This also correctly does > NOT trigger additional downloads upon other errors like corrupted files. You'd have to do this change inside URLgrabber itself, as by the time yum could react to it URLgrabber would already have decided to remove that mirror from it's list and moved on. -- James Antill Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From james.antill at redhat.com Thu Jan 24 12:50:02 2008 From: james.antill at redhat.com (James Antill) Date: Thu, 24 Jan 2008 07:50:02 -0500 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <20080124113201.GD10714@devserv.devel.redhat.com> References: <479805C1.4080005@gmail.com> <797f919ef07923e0bf0802fcfd35a458@togami.com> <479824AA.3050108@gmail.com> <479843C5.7030800@redhat.com> <20080124113201.GD10714@devserv.devel.redhat.com> Message-ID: <1201179002.10257.41.camel@code.and.org> On Thu, 2008-01-24 at 06:32 -0500, Alan Cox wrote: > On Thu, Jan 24, 2008 at 02:52:37AM -0500, Warren Togami wrote: > > It sounds like you are using a transparent proxy. Just redirect > > mirrors.fedoraproject.org to localhost at another port and serve files > > so the mirrorlist URL's hand back a single mirror of your choosing. > > Actually thats another way to handle the caching problem with most proxies > and static content servers. If you get > > http://....../....static.file?random-16-digits > > apache and most web servers will discard the query bits and the cache won't > be able to decide if the content is the same ;) "most"? I'm guessing you don't mean that by number of web servers ... maybe by "most commonly deployed". Others can/do 301 redirect you to the actual URL, or 404, or... To mis-quote Henry Spencer: Thou shalt foreswear, renounce, and abjure the vile heresy which claimeth that "All the world's Apache-httpd", and have no commerce with the benighted heathens who cling to this barbarous belief, that the days of thy program may be long even though the days of thy current web-server be short. -- James Antill Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From karsten at redhat.com Thu Jan 24 13:52:16 2008 From: karsten at redhat.com (Karsten Hopp) Date: Thu, 24 Jan 2008 14:52:16 +0100 Subject: Requesting feedback for unaccepted Fedora features In-Reply-To: <4797D281.2040808@redhat.com> References: <4797D281.2040808@redhat.com> Message-ID: <47989810.5070309@redhat.com> John Poelstra schrieb: > Dear Proposed Feature Owners, > > The following feature pages are in CategoryProposedFedora9 which > indicates that the feature owner is requesting that FESCo vote on them > at the next meeting. I have not raised these features to FESCo for a > vote because certain parts of the pages are incomplete and it doesn't > make sense for FESCo to review a feature when all the information is not > present. > ... > 4) http://fedoraproject.org/wiki/Releases/FeatureEncryptedFilesystems -- > documentation and release notes sections are empty (2008-01-14) > I've added / moved some stuff to the documentation section and added some release notes. Karsten From buildsys at redhat.com Thu Jan 24 12:54:52 2008 From: buildsys at redhat.com (Build System) Date: Thu, 24 Jan 2008 07:54:52 -0500 Subject: rawhide report: 20080124 changes Message-ID: <200801241254.m0OCsqrB023485@porkchop.devel.redhat.com> New package cpipe Counting pipe New package guitone A frontend for Monotone New package monotone-viz GNOME application that visualizes Monotone ancestry graphs New package openoffice.org-voikko Finnish spellchecker and hyphenator extension for OpenOffice.org New package perl-MasonX-Request-WithApacheSession Add a session to the Mason Request object New package perl-Net-NBName NetBIOS Name Service Requests New package perl-SNMP-Info Object Oriented Perl5 Interface to Network devices and MIBs through SNMP New package perl-WWW-Search Virtual base class for WWW searches New package sectool A security audit system and intrusion detection system New package xenner Xen emulator for kvm Updated Packages: TurboGears-1.0.4.2-2.fc9 ------------------------ * Wed Jan 23 2008 Luke Macken 1.0.4.2-2 - Update setuptools patch to work with the CherryPy egg_info * Tue Jan 22 2008 Luke Macken 1.0.4.2-1 - 1.0.4.2 * Sun Jan 20 2008 Luke Macken 1.0.4-1 - 1.0.4 - Remove paginate patch - Update setuptools patch acpid-1.0.6-5.fc9 ----------------- * Wed Jan 23 2008 Zdenek Prikryl - 1.0.6-5.fc9 - Fixed managing of power button (#361501) - Fixed power script to check for KDE power manager (#419331) anaconda-11.4.0.25-1 -------------------- * Wed Jan 23 2008 David Cantrell - 11.4.0.25-1 - Include new firstboot module. (clumens) - Conditionalize ntfsprogs as not all arches include it. (clumens) - Remove kudzu-probe-stub. (clumens) - Remove rogue references to kudzu. (clumens) - Add dogtail support (#172891, #239024). (clumens) - Fix some error reporting tracebacks. (clumens) and-1.2.2-5.fc9 --------------- * Wed Jan 23 2008 Jochen Schmitt 1.2.2-5 - Rebuild apcupsd-3.14.3-1.fc9 -------------------- * Wed Jan 23 2008 Tomas Smetana - 3.14.3-1 - Update to 3.14.3 aplus-fsf-4.20.2-23.fc9 ----------------------- * Wed Jan 23 2008 Jochen Schmitt 4.20.2-23 - Rebuild bzip2-1.0.4-13.fc9 ------------------ * Wed Jan 23 2008 Ivana Varekova 1.0.4-13 - rebuild cairo-java-1.0.5-8.fc8 ---------------------- * Fri Apr 20 2007 Stepan Kasal - 1.0.5-8 - Adhere to packaging guidelines. - Resolves: #225636 checkpolicy-2.0.7-2.fc9 ----------------------- * Mon Jan 21 2008 Dan Walsh - 2.0.7-2 - Update to use libsepol-static library * Fri Jan 11 2008 Dan Walsh - 2.0.7-1 - Latest update from NSA * Added support for policy capabilities from Todd Miller. crash-4.0-5.0.3 --------------- * Wed Jan 23 2008 Dave Anderson - 4.0-5.0.3 - Updated crash.patch to match upstream version 4.0-5.0. crossvc-1.5.2-2.fc9 ------------------- * Wed Jan 23 2008 Jochen Schmitt 1.5.2-2 - Rebuild ddclient-3.7.3-1.fc9 -------------------- * Wed Jan 23 2008 Robert Scheck 3.7.3-1 - Upgrade to 3.7.3 (#429438) - Updated the license tag according to the guidelines dnsmasq-2.41-0.5.test30.fc9 --------------------------- * Wed Jan 23 2008 Patrick "Jima" Laughton 2.41-0.5.test30 - Bugfix update expat-2.0.1-4 ------------- * Wed Jan 23 2008 Joe Orton 2.0.1-4 - chmod 644 even more documentation (#429806) fuse-sshfs-1.9-2.fc9 -------------------- * Wed Jan 23 2008 Peter Lemenkov 1.9-2 - Added missing Requires and BuildRequires - openssh-clients >= 4.4 * Wed Jan 23 2008 Peter Lemenkov 1.9-1 - Ver. 1.9 - Added provides: sshfs - Modified License field according to Fedora policy. * Tue Sep 12 2006 Peter Lemenkov 1.7-2.fc9 - Rebuild for FC6 glibmm24-2.15.2-1.fc9 --------------------- * Wed Jan 23 2008 Denis Leroy - 2.15.2-1 - Update to upstream 2.15.2 glom-1.6.6-1.fc9 ---------------- * Wed Jan 23 2008 Denis Leroy - 1.6.6-1 - Update to upstream 1.6.6, with fix for database closing bug gnupg2-2.0.8-2.fc9 ------------------ * Wed Jan 23 2008 Rex Dieter 2.0.8-2 - avoid kde-filesystem dep (#427316) gpodder-0.10.4-1.fc9 -------------------- * Wed Jan 23 2008 Jef Spaleta 0.10.4-1 - New Upstream version. Minor desktop file patch needed. gprolog-1.3.0-12.fc9 -------------------- * Wed Jan 23 2008 Jochen Schmitt 1.3.0-12 - Rebuild grace-5.1.21-8.fc9 ------------------ * Wed Jan 23 2008 Patrice Dumas - 5.1.21-8 - correct netcdf detection patch, thanks Jos??. * Wed Jan 23 2008 Patrice Dumas - 5.1.21-7 - add support for previous netcdf version (in epel). - drop support for monolithic X. * Tue Jan 22 2008 Patrice Dumas - 5.1.21-6 - don't add the grace fonts to the X server fonts. Instead use the urw fonts. Regenerate the FontDataBase based on the urw fonts. - use xdg-utils instead of htmlview. - use relative links. - add links to doc and examples in GRACE_HOME to have correct help. - use debian patch. - clean docs. hotwire-0.700-1.fc9 ------------------- * Wed Jan 23 2008 Colin Walters - 0.700-1 - New upstream version * Wed Jan 23 2008 Colin Walters - 0.699.svn828-1 - upstream SVN snapshot (SVN r828) * Wed Jan 23 2008 Colin Walters - 0.699.svn826-1 - upstream SVN snapshot (SVN r826) - update files list hplip-2.7.12-3.fc9 ------------------ * Wed Jan 23 2008 Tim Waugh 2.7.12-3 - Really grant the ACL for the lp group (bug #424331). hwdata-0.215-1.fc9 ------------------ * Wed Jan 23 2008 Karsten Hopp 0.215-1 - add HP W2207 monitor - add oui.txt, a list of bluetooth device makers inadyn-1.96.2-2.fc9 ------------------- * Wed Jan 23 2008 Jochen Schmitt 1.96.2-2 - Rebuild - Make initscript LSB-Compilant jakarta-commons-net-0:1.4.1-4jpp.1.fc9 -------------------------------------- * Tue Jan 22 2008 Permaine Cheung - 0:1.4.1-4jpp.1 - Merge with upstream * Fri Aug 31 2007 Ralph Apel - 0:1.4.1-4jpp - Add oro Requires - Add pom and depmap frags - Make Vendor, Distribution based on macro * Thu May 03 2007 Ralph Apel - 0:1.4.1-3jpp - Fix project_properties.patch to meet new plugins - Add maven-plugin-* BRs java-1.7.0-icedtea-1.7.0.0-0.24.b24.fc9 --------------------------------------- * Mon Jan 21 2008 Thomas Fitzsimmons - 1.7.0.0-0.24.b24 - Remove cgibindir macro. - Remove icedtearelease. - Remove binfmt_misc support. - Remove .snapshot from changelog lines wider than 80 columns. * Tue Jan 08 2008 Lillian Angel - 1.7.0.0-0.23.b24.snapshot - Added xorg-x11-fonts-misc as a build requirement for Mauve. - Updated mauve_tests. * Mon Jan 07 2008 Lillian Angel - 1.7.0.0-0.23.b24.snapshot - Updated Mauve's build requirements. - Excluding Mauve tests that try to access the network. - Added Xvfb functionality to mauve tests to avoid display-related failures. - Resolves rhbz#427614 kde-settings-4.0-9.fc9.1 ------------------------ * Wed Jan 23 2008 Rex Dieter 4.0-9.1 - include gpg-agent scripts here (#427316) kdebase-workspace-4.0.0-6.fc9 ----------------------------- * Wed Jan 23 2008 Rex Dieter 4.0.0-6 - Obsoletes: kdebase < 6:4 kdebase3-3.5.8-34.fc9 --------------------- * Thu Jan 24 2008 Kevin Kofler - 3.5.8-34 - f9+: omit kcontrol/kicker and kcontrol/taskbar (don't build because kicker is omitted) - fix file list * Wed Jan 23 2008 Kevin Kofler - 3.5.8-33 - f9+: don't omit all of kcontrol (kcms are used by several applications) * Wed Jan 23 2008 Rex Dieter 3.5.8-32 - (re)enable --with-samba support (now that we have a GPLv3-compat qt) kdelibs-6:4.0.0-3.fc9 --------------------- * Wed Jan 23 2008 Rex Dieter 4.0.0-3 - openssl patch kernel-2.6.24-0.167.rc8.git4.fc9 -------------------------------- * Tue Jan 22 2008 John W. Linville - Latest wireless updates from upstream - Tidy-up wireless patches - Remove obsolete ath5k and rtl8180 patches - Add rndis_wext driver * Tue Jan 22 2008 Chuck Ebbert - Disable the p4-clockmod driver -- it causes system hangs. (F8#428895) * Mon Jan 21 2008 Dave Jones - Remove a boatload of dead CONFIG_ options. libdhcp-1.99.7-1.fc9 -------------------- * Wed Jan 23 2008 David Cantrell - 1.99.7-1 - Handle re-adding existing routing table entries correctly (#429763) libevent-1.3e-1.fc9 ------------------- * Tue Jan 22 2008 Steve Dickson 1.3e-1 - Updated to latest stable upstream version 1.3e libgconf-java-2.12.4-9.fc8 -------------------------- * Fri Apr 20 2007 Stepan Kasal - 2.12.4-9 - Adhere to packaging guidelines. - Resolves: #226007 libglade-java-2.12.5-7.fc8 -------------------------- * Fri Apr 20 2007 Stepan Kasal - 2.12.5-7 - Adhere to packaging guidelines. - Resolves: #226011 libgnome-java-2.12.4-7.fc8 -------------------------- * Fri Apr 20 2007 Stepan Kasal - 2.12.4-7 - Adhere to packaging guidelines. - Resolves: #226014 libgsasl-0.2.18-5.fc9 --------------------- libgtk-java-2.8.7-5.fc8 ----------------------- * Fri Apr 20 2007 Stepan Kasal - 2.8.7-5 - Adhere to packaging guidelines. - Resolves: #226025 libnl-1.1-1.fc9 --------------- * Wed Jan 23 2008 Dan Williams - 1.1-1 - Update to version 1.1 libntlm-0.4.1-1.fc9 ------------------- * Wed Jan 23 2008 Nikolay Vladimirov - 0.4.1-1 - new upstrem release libpciaccess-0.9.1-3.20071031.fc9 --------------------------------- * Wed Jan 23 2008 Adam Jackson 0.9.1-3.20071031 - libpciaccess-fd-cache.patch: Cache sysfs PCI config space file descriptors for great boot speed justice. libprelude-0.9.16.2-1.fc9 ------------------------- * Wed Jan 23 2008 Steve Grubb 0.9.16.2-1 - New upstream version * Mon Jan 14 2008 Steve Grubb 0.9.16.1-1 - moved to new upstream version 0.9.16.1 * Tue Feb 20 2007 Thorsten Scherf 0.9.13-1 - moved to new upstream version 0.9.13-1 libselinux-2.0.49-1.fc9 ----------------------- * Wed Jan 23 2008 Dan Walsh - 2.0.49-1 * Merged audit2why python binding from Dan Walsh. * Wed Jan 23 2008 Dan Walsh - 2.0.48-1 * Merged updated swig bindings from Dan Walsh, including typemap for pid_t. lightning-1.2-12.fc9 -------------------- * Wed Jan 23 2008 Jochen Schmitt 1.2-12 - Rebuild luma-2.3-14.fc9 --------------- * Wed Jan 23 2008 Jochen Schmitt 2.3-14 - Rebuild mfiler2-4.0.8b-1.fc9 -------------------- * Thu Jan 24 2008 Mamoru Tasaka - 4.0.8b-1 - 4.0.8b msmtp-1.4.13-3.fc9 ------------------ newt-0.52.8-1.fc9 ----------------- * Wed Jan 23 2008 Miroslav Lichvar - 0.52.8-1 - enable slang utf8 mode (#425992) - support --disable-nls option (patch by Natanael Copa) - redraw screen when using entry in euc encodings openvrml-0.17.3-2.fc9 --------------------- * Tue Jan 22 2008 Braden McDaniel - 0.17.3-2 - Do not configure with --disable-gecko-rpath. - Go back to having openvrml-xembed require gecko-libs = 1.9. * Thu Jan 17 2008 Braden McDaniel - 0.17.3-1 - Updated to 0.17.3. - configure with --disable-gecko-rpath. - openvrml-xembed can now require gecko-libs >= 1.9. pam-0.99.8.1-16.fc9 ------------------- * Tue Jan 22 2008 Tomas Mraz 0.99.8.1-16 - add auditing to pam_access, pam_limits, and pam_time - moved sanity testing code to check script * Mon Jan 14 2008 Tomas Mraz 0.99.8.1-15 - merge review fixes (#226228) * Tue Jan 08 2008 Tomas Mraz 0.99.8.1-14 - support for sha256 and sha512 password hashes - account expiry checks moved to unix_chkpwd helper policycoreutils-2.0.37-1.fc9 ---------------------------- * Wed Jan 23 2008 Dan Walsh 2.0.37-1 - Update to upstream * Merged replacement for audit2why from Dan Walsh. * Wed Jan 23 2008 Dan Walsh 2.0.36-2 - Cleanup fixfiles -f message in man page * Wed Jan 23 2008 Dan Walsh 2.0.36-1 - Update to upstream * Merged update to chcat, fixfiles, and semanage scripts from Dan Walsh. * Merged sepolgen fixes from Dan Walsh. pulseaudio-0.9.8-5.fc9 ---------------------- * Wed Jan 23 2008 Lubomir Kundrak 0.9.8-5 - Fix CVE-2008-0008 security issue (#425481) * Sun Jan 13 2008 Lubomir Kundrak 0.9.8-4.1 - Actually add content to pulseaudio-0.9.8-create-dot-pulse.patch - Make the Source0 tag point to URL instead of a local file - Drop the nochown patch; it's not applied at all and no longer needed qcad-2.0.5.0-6.fc9 ------------------ * Wed Jan 23 2008 Gerard Milmeister - 2.0.5.0-6 - added patch to add arc type tangential to menu quagga-0:0.99.9-3.fc9 --------------------- * Wed Jan 23 2008 Martin Nagy - 0.99.9-3 - rebuild roundup-1.4.1-1.fc9 ------------------- * Wed Jan 23 2008 Paul P. Komkoff Jr - 1.4.1-1 - new upstream version roxterm-1.10.0-1.fc9 -------------------- * Wed Jan 23 2008 Sebastian Vahl - 1.10.0-1 - new upstream version: 1.10.0 selinux-policy-3.2.5-18.fc9 --------------------------- * Wed Jan 23 2008 Dan Walsh 3.2.5-18 - Allow pam_selinux_permit to kill all processes setuptool-1.19.4-1.fc9 ---------------------- * Wed Jan 23 2008 Nalin Dahyabhai 1.19.4-1 - drop system-config-printer-tui from the list of things we search for as an option for printer configuration (#377401) squid-7:3.0.STABLE1-1.fc9 ------------------------- * Wed Jan 23 2008 Martin Nagy - 7:3.0.STABLE1-1 - upgrade to latest upstream 3.0.STABLE1 * Tue Dec 04 2007 Martin Bacovsky - 2.6.STABLE17-1 - upgrade to latest upstream 2.6.STABLE17 * Wed Oct 31 2007 Martin Bacovsky - 7:2.6.STABLE16-3 - arp-acl was enabled sylpheed-2.4.8-2 ---------------- * Wed Jan 23 2008 Michael Schwendt - 2.4.8-2 - Compile with deprecated OpenLDAP API to fix segfaults on 64-bit. * Sun Dec 23 2007 Michael Schwendt - 2.4.8-1 - Patch spell-checking support. Retrieve list of dictionaries from Enchant instead of Aspell, because GtkSpell no longer uses Aspell. - BR enchant-devel - Update to 2.4.8 (accumulated bug-fixes). * Mon Dec 17 2007 Michael Schwendt - 2.4.7-4 - Upstreamed patch lead to discovery of similar memory leaks in syldap.c system-config-printer-0.7.78-5.fc9 ---------------------------------- * Wed Jan 23 2008 Tim Waugh 0.7.78-5 - Updated to pycups-1.9.33. * Wed Jan 16 2008 Tim Waugh 0.7.78-4 - Use config-util from new usermode (bug #428406). * Thu Dec 20 2007 Tim Waugh - Requires notification-daemon (Ubuntu #176929). - Requires gnome-python2 for theme support (Ubuntu #176929). - Requires gnome-icon-theme for printer icon (Ubuntu #176929). tcpreplay-3.2.5-1.fc9 --------------------- * Thu Jan 24 2008 Bojan Smojver - 3.2.5-1 - bump up to 3.2.5 * Fri Jan 18 2008 Bojan Smojver - 3.2.4-1 - bump up to 3.2.4 - use --enable-tcpreplay-edit when building texlive-2007-15.fc9 ------------------- * Wed Jan 23 2008 Jindrich Novy - 2007-15 - dependency pruning: (#428489, #429753) - package XeTeX separately - move ghostscript utilities (a2ping, e2pall, epstopdf, gsftopk, pdfcrop, ps4pdf, thumbpdf) and metafont with X support to texlive-utils subpackage - move allcm, allec, allneeded to texlive-dvips - package xdvipdfmx in dvipdfmx subpackage - only texlive-doc now requires xdg-utils * Tue Jan 22 2008 Jindrich Novy - 2007-14 - use xdg-open(1) in texdoctk (#429659) - fix bad syntax of texmfstart man page * Fri Jan 18 2008 Jindrich Novy - 2007-13 - don't copy original pdftex map files but regenerate them with the correct updmap.cfg file updated in texlive-texmf (Related: #425804) - install mendex via libtool (#428507) transmission-1.02-1.fc9 ----------------------- * Wed Jan 23 2008 Denis Leroy - 1.02-1 - Update to upstream 1.02, bugfix release unzip-5.52-7.fc9 ---------------- * Wed Jan 23 2008 Ivana Varekova - 5.52-7 - fix another long file support problem uw-imap-2007-2.fc9 ------------------ * Wed Jan 23 2008 Rex Dieter 2007-2 - Obsoletes: libc-client2006 (#429796) - drop libc-client hacks for parallel-installability, fun while it lasted vdr-ttxtsubs-0.0.5-3.fc9 ------------------------ * Wed Jan 23 2008 Ville Skytt?? - 0.0.5-3 - Update raastinrauta patch to 2008-01-22. vnc-ltsp-config-4.0-4.fc9 ------------------------- * Wed Jan 23 2008 Rex Dieter 4.0-4 - vncts.sysconfig: remove -fp entries, use vnc defaults (#429792) - License: GPLv2+ - %config(noreplace) %_sysconfdir/xinetd.d/vncts - specfile cosmetics xdvik-22.84.13-10.fc9 --------------------- * Wed Jan 23 2008 Patrice Dumas - 22.84.13-10 - add xdg-utils, ghostscript requires - use virtual requires for dvips and tex xorg-x11-drv-nv-2.1.6-7.fc9 --------------------------- * Wed Jan 23 2008 Adam Jackson 2.1.6-7 - nv-2.1.6-starvation.patch: Typo fix. xorg-x11-drv-openchrome-0.2.901-6.fc9 ------------------------------------- * Wed Jan 23 2008 Xavier Bachelot - 0.2.901-6 - Add patch to properly set fifo on P4M900. xulrunner-1.9-0.beta2.13.nightly20080121.fc9 -------------------------------------------- * Wed Jan 23 2008 Martin Stransky 1.9-0.beta2.13 - fixed stable pkg-config files (#429654) - removed sqlite patch Broken deps for i386 ---------------------------------------------------------- Io-language-extras - 20071010-2.fc9.i386 requires libevent-1.3b.so.1 compiz-kde - 0.6.2-6.fc9.i386 requires libkdecorations.so.1 crystal - 1.0.5-1.fc8.i386 requires libkdecorations.so.1 dekorator - 0.3-3.fc7.i386 requires libkdecorations.so.1 epiphany-extensions - 2.20.1-3.fc9.i386 requires libgtkembedmoz.so epiphany-extensions - 2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.i386 requires libgtkembedmoz.so gnome-web-photo - 0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 icewm - 1.2.35-2.fc9.i386 requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 kdebase3 - 3.5.8-34.fc9.i386 requires libkdeinit_ksmserver.so kdebase3 - 3.5.8-34.fc9.i386 requires libkdeinit_kaccess.so kdebase3 - 3.5.8-34.fc9.i386 requires libkdeinit_konsole.so kdebase3 - 3.5.8-34.fc9.i386 requires libkdeinit_kprinter.so kdebase3 - 3.5.8-34.fc9.i386 requires libkdeinit_kcontrol.so kdebase3 - 3.5.8-34.fc9.i386 requires libkdeinit_kjobviewer.so kdebase3 - 3.5.8-34.fc9.i386 requires libkdeinit_kcminit.so kdebase3 - 3.5.8-34.fc9.i386 requires libkdeinit_kcminit_startup.so kdebluetooth - 1.0-0.39.beta8.fc9.i386 requires /usr/bin/kdesu kicker-compiz - 3.5.4-4.fc8.i386 requires libkickermain.so.1 kicker-compiz - 3.5.4-4.fc8.i386 requires libtaskmanager.so.1 kscope - 1.6.1-3.fc9.i386 requires libkateutils.so.0 kscope - 1.6.1-3.fc9.i386 requires libkateinterfaces.so.0 ksmarttray - 0.52-53.fc9.i386 requires /usr/bin/kdesu ksplash-engine-moodin - 0.4.2-4.fc7.i386 requires libksplashthemes.so.0 memcached - 1.2.4-2.fc9.i386 requires libevent-1.3b.so.1 muine - 0.8.8-5.fc9.i386 requires mono(muine-plugin) = 0:1.0.0.0 mysql-proxy - 0.6.0-1.fc9.i386 requires libevent-1.3b.so.1 nfs-utils - 1:1.1.1-1.fc9.i386 requires libevent-1.3b.so.1 qt-recordmydesktop - 0.3.6-4.fc9.noarch requires recordmydesktop = 0:0.3.6 scanssh - 2.1-14.fc8.i386 requires libevent-1.3b.so.1 smb4k - 0.8.7-3.fc9.i386 requires libkonqsidebarplugin.so.1 tor-core - 0.1.2.18-2.fc9.i386 requires libevent-1.3b.so.1 Broken deps for x86_64 ---------------------------------------------------------- Io-language-extras - 20071010-2.fc9.x86_64 requires libevent-1.3b.so.1()(64bit) compiz-kde - 0.6.2-6.fc9.x86_64 requires libkdecorations.so.1()(64bit) crystal - 1.0.5-1.fc8.x86_64 requires libkdecorations.so.1()(64bit) dekorator - 0.3-3.fc7.x86_64 requires libkdecorations.so.1()(64bit) epiphany-extensions - 2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) icewm - 1.2.35-2.fc9.x86_64 requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 kdebase3 - 3.5.8-34.fc9.x86_64 requires libkdeinit_ksmserver.so()(64bit) kdebase3 - 3.5.8-34.fc9.x86_64 requires libkdeinit_kcontrol.so()(64bit) kdebase3 - 3.5.8-34.fc9.x86_64 requires libkdeinit_kjobviewer.so()(64bit) kdebase3 - 3.5.8-34.fc9.x86_64 requires libkdeinit_konsole.so()(64bit) kdebase3 - 3.5.8-34.fc9.x86_64 requires libkdeinit_kcminit.so()(64bit) kdebase3 - 3.5.8-34.fc9.x86_64 requires libkdeinit_kcminit_startup.so()(64bit) kdebase3 - 3.5.8-34.fc9.x86_64 requires libkdeinit_kprinter.so()(64bit) kdebase3 - 3.5.8-34.fc9.x86_64 requires libkdeinit_kaccess.so()(64bit) kdebluetooth - 1.0-0.39.beta8.fc9.x86_64 requires /usr/bin/kdesu kicker-compiz - 3.5.4-4.fc8.x86_64 requires libkickermain.so.1()(64bit) kicker-compiz - 3.5.4-4.fc8.x86_64 requires libtaskmanager.so.1()(64bit) kscope - 1.6.1-3.fc9.x86_64 requires libkateutils.so.0()(64bit) kscope - 1.6.1-3.fc9.x86_64 requires libkateinterfaces.so.0()(64bit) ksmarttray - 0.52-53.fc9.x86_64 requires /usr/bin/kdesu ksplash-engine-moodin - 0.4.2-4.fc7.x86_64 requires libksplashthemes.so.0()(64bit) memcached - 1.2.4-2.fc9.x86_64 requires libevent-1.3b.so.1()(64bit) muine - 0.8.8-5.fc9.x86_64 requires mono(muine-plugin) = 0:1.0.0.0 mysql-proxy - 0.6.0-1.fc9.x86_64 requires libevent-1.3b.so.1()(64bit) nfs-utils - 1:1.1.1-1.fc9.x86_64 requires libevent-1.3b.so.1()(64bit) qt-recordmydesktop - 0.3.6-4.fc9.noarch requires recordmydesktop = 0:0.3.6 scanssh - 2.1-14.fc8.x86_64 requires libevent-1.3b.so.1()(64bit) smb4k - 0.8.7-3.fc9.x86_64 requires libkonqsidebarplugin.so.1()(64bit) smb4k - 0.8.7-3.fc9.i386 requires libkonqsidebarplugin.so.1 tor-core - 0.1.2.18-2.fc9.x86_64 requires libevent-1.3b.so.1()(64bit) Broken deps for ppc ---------------------------------------------------------- Io-language-extras - 20071010-2.fc9.ppc requires libevent-1.3b.so.1 anaconda - 11.4.0.25-1.ppc requires dmidecode compiz-kde - 0.6.2-6.fc9.ppc requires libkdecorations.so.1 crystal - 1.0.5-1.fc8.ppc requires libkdecorations.so.1 dekorator - 0.3-3.fc7.ppc requires libkdecorations.so.1 epiphany-extensions - 2.20.1-3.fc9.ppc requires libgtkembedmoz.so epiphany-extensions - 2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo - 0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo - 0.3-8.fc9.ppc requires libgtkembedmoz.so gnome-web-photo - 0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 icewm - 1.2.35-2.fc9.ppc requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 kdebase3 - 3.5.8-34.fc9.ppc requires libkdeinit_ksmserver.so kdebase3 - 3.5.8-34.fc9.ppc requires libkdeinit_kaccess.so kdebase3 - 3.5.8-34.fc9.ppc requires libkdeinit_konsole.so kdebase3 - 3.5.8-34.fc9.ppc requires libkdeinit_kprinter.so kdebase3 - 3.5.8-34.fc9.ppc requires libkdeinit_kcontrol.so kdebase3 - 3.5.8-34.fc9.ppc requires libkdeinit_kjobviewer.so kdebase3 - 3.5.8-34.fc9.ppc requires libkdeinit_kcminit.so kdebase3 - 3.5.8-34.fc9.ppc requires libkdeinit_kcminit_startup.so kdebluetooth - 1.0-0.39.beta8.fc9.ppc requires /usr/bin/kdesu kicker-compiz - 3.5.4-4.fc8.ppc requires libkickermain.so.1 kicker-compiz - 3.5.4-4.fc8.ppc requires libtaskmanager.so.1 kscope - 1.6.1-3.fc9.ppc requires libkateutils.so.0 kscope - 1.6.1-3.fc9.ppc requires libkateinterfaces.so.0 ksmarttray - 0.52-53.fc9.ppc requires /usr/bin/kdesu ksplash-engine-moodin - 0.4.2-4.fc7.ppc requires libksplashthemes.so.0 memcached - 1.2.4-2.fc9.ppc requires libevent-1.3b.so.1 monodevelop - 0.17-4.fc9.ppc requires boo muine - 0.8.8-5.fc9.ppc requires mono(muine-plugin) = 0:1.0.0.0 mysql-proxy - 0.6.0-1.fc9.ppc requires libevent-1.3b.so.1 nfs-utils - 1:1.1.1-1.fc9.ppc requires libevent-1.3b.so.1 qt-recordmydesktop - 0.3.6-4.fc9.noarch requires recordmydesktop = 0:0.3.6 scanssh - 2.1-14.fc8.ppc requires libevent-1.3b.so.1 smb4k - 0.8.7-3.fc9.ppc requires libkonqsidebarplugin.so.1 smb4k - 0.8.7-3.fc9.ppc64 requires libkonqsidebarplugin.so.1()(64bit) tor-core - 0.1.2.18-2.fc9.ppc requires libevent-1.3b.so.1 Broken deps for ppc64 ---------------------------------------------------------- Io-language-extras - 20071010-2.fc9.ppc64 requires libevent-1.3b.so.1()(64bit) anaconda - 11.4.0.25-1.ppc64 requires dmidecode crystal - 1.0.5-1.fc8.ppc64 requires libkdecorations.so.1()(64bit) dekorator - 0.3-3.fc7.ppc64 requires libkdecorations.so.1()(64bit) epiphany-extensions - 2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) epiphany-extensions - 2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo - 0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo - 0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) icewm - 1.2.35-2.fc9.ppc64 requires xorg-x11-fonts-truetype kazehakase - 0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 kdebase3 - 3.5.8-34.fc9.ppc64 requires libkdeinit_ksmserver.so()(64bit) kdebase3 - 3.5.8-34.fc9.ppc64 requires libkdeinit_kcontrol.so()(64bit) kdebase3 - 3.5.8-34.fc9.ppc64 requires libkdeinit_kjobviewer.so()(64bit) kdebase3 - 3.5.8-34.fc9.ppc64 requires libkdeinit_konsole.so()(64bit) kdebase3 - 3.5.8-34.fc9.ppc64 requires libkdeinit_kcminit.so()(64bit) kdebase3 - 3.5.8-34.fc9.ppc64 requires libkdeinit_kcminit_startup.so()(64bit) kdebase3 - 3.5.8-34.fc9.ppc64 requires libkdeinit_kprinter.so()(64bit) kdebase3 - 3.5.8-34.fc9.ppc64 requires libkdeinit_kaccess.so()(64bit) kdebluetooth - 1.0-0.39.beta8.fc9.ppc64 requires /usr/bin/kdesu kicker-compiz - 3.5.4-4.fc8.ppc64 requires libkickermain.so.1()(64bit) kicker-compiz - 3.5.4-4.fc8.ppc64 requires libtaskmanager.so.1()(64bit) kscope - 1.6.1-3.fc9.ppc64 requires libkateutils.so.0()(64bit) kscope - 1.6.1-3.fc9.ppc64 requires libkateinterfaces.so.0()(64bit) ksmarttray - 0.52-53.fc9.ppc64 requires /usr/bin/kdesu ksplash-engine-moodin - 0.4.2-4.fc7.ppc64 requires libksplashthemes.so.0()(64bit) memcached - 1.2.4-2.fc9.ppc64 requires libevent-1.3b.so.1()(64bit) mysql-proxy - 0.6.0-1.fc9.ppc64 requires libevent-1.3b.so.1()(64bit) nfs-utils - 1:1.1.1-1.fc9.ppc64 requires libevent-1.3b.so.1()(64bit) perl-Test-AutoBuild-darcs - 1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 qt-recordmydesktop - 0.3.6-4.fc9.noarch requires recordmydesktop = 0:0.3.6 scanssh - 2.1-14.fc8.ppc64 requires libevent-1.3b.so.1()(64bit) smb4k - 0.8.7-3.fc9.ppc64 requires libkonqsidebarplugin.so.1()(64bit) tor-core - 0.1.2.18-2.fc9.ppc64 requires libevent-1.3b.so.1()(64bit) From opensource at till.name Thu Jan 24 13:02:41 2008 From: opensource at till.name (Till Maas) Date: Thu, 24 Jan 2008 14:02:41 +0100 Subject: RFE: prevent broken rawhide network install due to repo change In-Reply-To: <47981466.2030603@gmail.com> References: <47981466.2030603@gmail.com> Message-ID: <200801241402.46682.opensource@till.name> On Thu January 24 2008, Andrew Farris wrote: > RFE: prevent broken rawhide network install due to repo change > > Problem: network installs will currently fail if the repository changes > during the installation, which can take 2-4 hours or more, and changed > files are removed from the repo, making anaconda fail to download the > expected version of that changed file > I'd be happy to move this suggestion to where it belongs (bugzilla against > ?) Imho this is something that can be improved in anacanda, e.g. make it use another mirror in case an rpm is missinga and in case an rpm is missing, it could update its metadata and recalculate which new rpms could be used to finish the installation, or it could first download every rpm and then install them. When anaconda supports adding repositories with updates, this problem could also occur for normal installs. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From valent.turkovic at gmail.com Thu Jan 24 13:17:11 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 24 Jan 2008 14:17:11 +0100 Subject: SELinux and chroot In-Reply-To: References: Message-ID: <64b14b300801240517k16726c68i7f92d20edb351784@mail.gmail.com> On Jan 23, 2008 11:19 PM, James Morris wrote: > Did the SELinux vs. chroot issue get bugzilla'd ? > > It came up in discussion a couple of times, but I can't recall if the > issue was captured there. > > > - James > -- > James Morris > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I can only tell you that my bug: https://bugzilla.redhat.com/show_bug.cgi?id=429678 is still open. I can't help much with chroot part because I really don't know anything about it. Cheers, Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From jmorris at namei.org Thu Jan 24 13:17:33 2008 From: jmorris at namei.org (James Morris) Date: Fri, 25 Jan 2008 00:17:33 +1100 (EST) Subject: SELinux and chroot In-Reply-To: References: Message-ID: On Thu, 24 Jan 2008, James Morris wrote: > Did the SELinux vs. chroot issue get bugzilla'd ? Created a bz # 430075. Please add any further requirements or issues there. As noted in the bz, we have also recently been discussing a related issue: better support for distributing policy with RPMS when the host and target have differing policies. - James -- James Morris From jima at beer.tclug.org Thu Jan 24 13:48:30 2008 From: jima at beer.tclug.org (Jima) Date: Thu, 24 Jan 2008 07:48:30 -0600 (CST) Subject: Fedora 8/ARM available In-Reply-To: <20080124013155.GB12776@xi.wantstofly.org> References: <20080114233331.GL17358@xi.wantstofly.org> <20080116203330.787a06dc@zod.rchland.ibm.com> <20080124013155.GB12776@xi.wantstofly.org> Message-ID: On Thu, 24 Jan 2008, Lennert Buytenhek wrote: > On Thu, Jan 17, 2008 at 08:13:05AM -0600, Jima wrote: >> I'd love to get Fedora on my NSLU2 -- although that'll probably require >> me to find/buy a USB hard drive. :-) > > That would certainly be the easiest way. > > There are ways of reducing footprint so that your fs will fit in flash > (some of which used internally), but the more effective ones are > generally one-way, and things like 'yum update' are rather hard to > keep working after you've slimmed your filesystem down to 4MB. :-) Well, the semi-obvious question to me is, could one use the flash for /boot (or such), and load the drivers for the USB et al via initrd? Or would that even fit? (Looking at x86_64, at least, my kernel is 1.9mb and my initrd is 3.8mb -- ouch.) Or is there some other intermediary that could load an OS wholly installed on a USB drive? I can't claim to be an expert with the NSLU2 -- I haven't really touched it since I got OpenWRT on it. (And before you ask why I even bought one: I got it secondhand. Cheap.) I would dream of trying to install/run Fedora without external media on the thing -- it was most certainly a joke. :-) Jima From jima at beer.tclug.org Thu Jan 24 13:53:22 2008 From: jima at beer.tclug.org (Jima) Date: Thu, 24 Jan 2008 07:53:22 -0600 (CST) Subject: Fedora 8/ARM available In-Reply-To: References: <20080114233331.GL17358@xi.wantstofly.org> <20080116203330.787a06dc@zod.rchland.ibm.com> <20080124013155.GB12776@xi.wantstofly.org> Message-ID: On Thu, 24 Jan 2008, Jima wrote: > I would dream of trying to install/run Fedora without external media on the > thing -- it was most certainly a joke. :-) Gah. Wouldn't. Need coffee. Now. Jima From mclasen at redhat.com Thu Jan 24 13:57:17 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 24 Jan 2008 08:57:17 -0500 Subject: Live images and fonts In-Reply-To: <16144.192.54.193.53.1201163440.squirrel@rousalka.dyndns.org> References: <200801240029.35792.ml@deadbabylon.de> <16144.192.54.193.53.1201163440.squirrel@rousalka.dyndns.org> Message-ID: <1201183037.2947.1.camel@localhost.localdomain> On Thu, 2008-01-24 at 09:30 +0100, Nicolas Mailhot wrote: > Le Jeu 24 janvier 2008 00:29, Sebastian Vahl a ?crit : > > Hi. > > Hi, > > > After some time I've done a new test spin of my kde live images today. > > What > > I've experienced is that most of the former installed fonts are > > missing. A > > diff between my released rawhide live image for KDE 4 and my current > > one is: > > I know next to nothing about live images but I confirm that the fedora > font landscape changed quite a bit since fedora 8 (new fonts, pulled > fonts, renamed fonts, new defaults) so anything font-related done at > F8 time probably needs to be revisited now Looking at a desktop spin, I see the following changes in the font area: +abyssinica-fonts -dejavu-lgc-fonts -fonts-arabic -fonts-bengali -fonts-chinese -fonts-gujarati -fonts-hebrew -fonts-hindi -fonts-kannada -fonts-korean -fonts-malayalam -fonts-oriya -fonts-punjabi -fonts-sinhala -fonts-tamil -fonts-telugu -liberation-fonts +samyak-fonts +VLGothic-fonts +VLGothic-fonts-proportional -xorg-x11-fonts-truetype It suspiciously looks like a lot more - than +, so I'd appreciate some input on what needs to be fixed here. From lesmikesell at gmail.com Thu Jan 24 14:05:23 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 24 Jan 2008 08:05:23 -0600 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <479843C5.7030800@redhat.com> References: <479805C1.4080005@gmail.com> <797f919ef07923e0bf0802fcfd35a458@togami.com> <479824AA.3050108@gmail.com> <479843C5.7030800@redhat.com> Message-ID: <47989B23.80902@gmail.com> Warren Togami wrote: > Les Mikesell wrote: >> >> Interesting, but it still requires custom setup for any distro/version >> that the proxy admin would want to support. What I'd really like to >> happen is for yum to just always prefer the same URL when working >> through the same proxy so caching would work by default without >> needing to be aware of the cache content. This would work >> automatically if the target was a single site, RRDNS, or geo-ip >> managed DNS, but you probably can't arrange that for all the repo >> mirrors. There has to be some clever way to get the same effect even >> when using a mirrorlist - like making sure the mirrorlist itself is >> cached and always picking the same entry so any client will use the >> same URL that the mirrormanger gave to the first one that made a >> request. Of course you'd need a reasonable retry mechanism to pick >> something else if this choice fails but I'd guess it would be a big >> win in bandwidth use and load on the mirrors if it worked most of the >> time to take advantage of existing local caches with no modifications. >> > > I just thought of a simple but gross solution for you. > > http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-$releasever&arch=$basearch > > > It sounds like you are using a transparent proxy. Just redirect > mirrors.fedoraproject.org to localhost at another port and serve files > so the mirrorlist URL's hand back a single mirror of your choosing. I think you are missing my point, which is that it would be a huge win if yum automatically used typical existing caching proxies with no extra setup on anyone's part, so that any number of people behind them would get the cached packages without knowing about each other or that they need to do something special to defeat the random URLs. I used to run a number of centos3 boxes in several locations and it always worked nicely to just: http_proxy=http://my_proxy.domain:port yum update pointing at a local squid because the mirrors used RRDNS so the URLs were the same among the machines - and this would have happened automatically with a transparent proxy or on machines set to use a proxy by default as they must be in many locations. Since yum started randomizing the requests with a mirrorlist, updates are a lot slower. Maybe yum needs to do some tricks with cache control headers or appending random arguments to ensure the repo data is fresh, but there has to be some way to make it re-use packages already downloaded in a local proxy cache without any local changes. We have several locations where everyone in a large building has to use the same proxy to get out, but the people who would be installing/updating their own linux boxes would not know what anyone else is doing or be likely to coordinate the choice of a URL if they had to change anything - and I'd guess that's a common situation. -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Thu Jan 24 14:12:41 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 24 Jan 2008 08:12:41 -0600 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <1201179002.10257.41.camel@code.and.org> References: <479805C1.4080005@gmail.com> <797f919ef07923e0bf0802fcfd35a458@togami.com> <479824AA.3050108@gmail.com> <479843C5.7030800@redhat.com> <20080124113201.GD10714@devserv.devel.redhat.com> <1201179002.10257.41.camel@code.and.org> Message-ID: <47989CD9.9030700@gmail.com> James Antill wrote: > >>> It sounds like you are using a transparent proxy. Just redirect >>> mirrors.fedoraproject.org to localhost at another port and serve files >>> so the mirrorlist URL's hand back a single mirror of your choosing. >> Actually thats another way to handle the caching problem with most proxies >> and static content servers. If you get >> >> http://....../....static.file?random-16-digits >> >> apache and most web servers will discard the query bits and the cache won't >> be able to decide if the content is the same ;) > > "most"? I'm guessing you don't mean that by number of web servers ... > maybe by "most commonly deployed". Others can/do 301 redirect you to the > actual URL, or 404, or... Will all of them work correctly if you send 'Pragma: no-cache' or http 1.1 Cache-control: headers? -- Les Mikesell lesmikesell at gmail.com From nicolas.mailhot at laposte.net Thu Jan 24 14:15:57 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 24 Jan 2008 15:15:57 +0100 (CET) Subject: Live images and fonts In-Reply-To: <1201183037.2947.1.camel@localhost.localdomain> References: <200801240029.35792.ml@deadbabylon.de> <16144.192.54.193.53.1201163440.squirrel@rousalka.dyndns.org> <1201183037.2947.1.camel@localhost.localdomain> Message-ID: <54256.192.54.193.53.1201184157.squirrel@rousalka.dyndns.org> Le Jeu 24 janvier 2008 14:57, Matthias Clasen a ?crit : > It suspiciously looks like a lot more - than +, so I'd appreciate some > input on what needs to be fixed here. You can check F8 and F9 changes in default fonts by diff-ing http://cvs.fedoraproject.org/viewcvs/comps/comps-f9.xml.in and http://cvs.fedoraproject.org/viewcvs/comps/comps-f8.xml.in and looking at the "fonts" group. You'll see what got bumped as default (dejavu-full), what got demoted (dejavu-lgc), what got renamed (all the indic font packages IIRC) (though it would be nice to tag the exact comps version that gets in a release, instead of diffing with post-release F8 comps changes) I think your problem is all those changes have not been integrated by the people in charge of the desktop spin package list, and you're filtering the old F8 package list with the new F9 comps (though the - before liberation is strange, it was not touched in any way except for a version bump) Regards, -- Nicolas Mailhot From lesmikesell at gmail.com Thu Jan 24 14:21:40 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 24 Jan 2008 08:21:40 -0600 Subject: long term support release In-Reply-To: <1201150608.17905.78.camel@beck.corsepiu.local> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <20080123103336.6e24109f@redhat.com> <47976399.3010709@redhat.com> <47979470.6010507@leemhuis.info> <1201150608.17905.78.camel@beck.corsepiu.local> Message-ID: <47989EF4.3000102@gmail.com> Ralf Corsepius wrote: > Right. CentOS is a different distro. It is not RHEL nor Fedora. > It's the same difference as between Debian and its recompile called > Ubuntu. > > RHEL and CentOS just happen to be largely compatible, because they are > derivatives from the same sources. The compatibility isn't accidental. Unlike Ubuntu, which exists to fix issues in Debian, Centos is modified as little as legally permitted. A yum repository for RHEL/Centos containing as many as possible of the additional packages available in fedora would pretty much fill the need being discussed here. Or several, if the primary one won't include Sun Java, vlc + codecs, and Nvidia/Ati drivers. -- Les Mikesell lesmikesell at gmail.com From james.antill at redhat.com Thu Jan 24 14:29:10 2008 From: james.antill at redhat.com (James Antill) Date: Thu, 24 Jan 2008 09:29:10 -0500 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <47989B23.80902@gmail.com> References: <479805C1.4080005@gmail.com> <797f919ef07923e0bf0802fcfd35a458@togami.com> <479824AA.3050108@gmail.com> <479843C5.7030800@redhat.com> <47989B23.80902@gmail.com> Message-ID: <1201184950.10257.50.camel@code.and.org> On Thu, 2008-01-24 at 08:05 -0600, Les Mikesell wrote: > I think you are missing my point, which is that it would be a huge win > if yum automatically used typical existing caching proxies with no extra > setup on anyone's part, so that any number of people behind them would > get the cached packages without knowing about each other or that they > need to do something special to defeat the random URLs. HTTP doesn't define a way to do this, much like the Pragma header suggestion is a pretty bad abuse of HTTP ... suddenly the origin server going down means you can't get the data from the proxy. Please don't assume half of a solution, that never works well. What you _actually want_ is: "On my group my machines X, try not to download data more than once." ...at the ISP level this is solved by getting your mirror into mirror manager directly. At the personal level this is likely better solved by having something like "Have a zero-conf like service to share pacakges across the local network". There has even been some work to do this. In neither case is "work around HTTPs design in yum" a good solution, IMNSHO. -- James Antill Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tim.lauridsen at googlemail.com Thu Jan 24 14:30:47 2008 From: tim.lauridsen at googlemail.com (Tim Lauridsen) Date: Thu, 24 Jan 2008 15:30:47 +0100 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <47989B23.80902@gmail.com> References: <479805C1.4080005@gmail.com> <797f919ef07923e0bf0802fcfd35a458@togami.com> <479824AA.3050108@gmail.com> <479843C5.7030800@redhat.com> <47989B23.80902@gmail.com> Message-ID: <4798A117.4000508@googlemail.com> Les Mikesell wrote: > Warren Togami wrote: >> Les Mikesell wrote: >>> >>> Interesting, but it still requires custom setup for any >>> distro/version that the proxy admin would want to support. What I'd >>> really like to happen is for yum to just always prefer the same URL >>> when working through the same proxy so caching would work by default >>> without needing to be aware of the cache content. This would work >>> automatically if the target was a single site, RRDNS, or geo-ip >>> managed DNS, but you probably can't arrange that for all the repo >>> mirrors. There has to be some clever way to get the same effect even >>> when using a mirrorlist - like making sure the mirrorlist itself is >>> cached and always picking the same entry so any client will use the >>> same URL that the mirrormanger gave to the first one that made a >>> request. Of course you'd need a reasonable retry mechanism to pick >>> something else if this choice fails but I'd guess it would be a big >>> win in bandwidth use and load on the mirrors if it worked most of the >>> time to take advantage of existing local caches with no modifications. >>> >> >> I just thought of a simple but gross solution for you. >> >> http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-$releasever&arch=$basearch >> >> >> It sounds like you are using a transparent proxy. Just redirect >> mirrors.fedoraproject.org to localhost at another port and serve files >> so the mirrorlist URL's hand back a single mirror of your choosing. > > I think you are missing my point, which is that it would be a huge win > if yum automatically used typical existing caching proxies with no extra > setup on anyone's part, so that any number of people behind them would > get the cached packages without knowing about each other or that they > need to do something special to defeat the random URLs. I used to run a > number of centos3 boxes in several locations and it always worked nicely > to just: > http_proxy=http://my_proxy.domain:port yum update > pointing at a local squid because the mirrors used RRDNS so the URLs > were the same among the machines - and this would have happened > automatically with a transparent proxy or on machines set to use a > proxy by default as they must be in many locations. Since yum started > randomizing the requests with a mirrorlist, updates are a lot slower. This has nothing to do with yum, it is the disto there decides how to give access to mirrors, yum just does what the distro repo contig tell it to do. "Don't blame the postman for the bad news" :) > > Maybe yum needs to do some tricks with cache control headers or > appending random arguments to ensure the repo data is fresh, but there > has to be some way to make it re-use packages already downloaded in a > local proxy cache without any local changes. We have several locations > where everyone in a large building has to use the same proxy to get out, > but the people who would be installing/updating their own linux boxes > would not know what anyone else is doing or be likely to coordinate the > choice of a URL if they had to change anything - and I'd guess that's a > common situation. This thread is upside down IMHO. The proxy don't do the right thing, so let us redesign yum, to fix the problems with the proxy. I seems to be the wrong approach IMHO. Tim "Proxies is nothing but trouble" :) From poelstra at redhat.com Thu Jan 24 14:35:56 2008 From: poelstra at redhat.com (John Poelstra) Date: Thu, 24 Jan 2008 06:35:56 -0800 Subject: Requesting feedback for unaccepted Fedora features In-Reply-To: <20080124020003.GK12464@angus.ind.WPI.EDU> References: <4797D281.2040808@redhat.com> <20080124020003.GK12464@angus.ind.WPI.EDU> Message-ID: <4798A24C.8040503@redhat.com> Chuck Anderson said the following on 01/23/2008 06:00 PM Pacific Time: > On Wed, Jan 23, 2008 at 03:49:21PM -0800, John Poelstra wrote: >> In addition, the following features are targeted for Fedora 9 in their >> writeup, but are not in CategoryProposedFedora9. If you have no intention >> of completing them for Fedora 9, >> please remove Fedora 9 as the targeted release so that there is no >> confusion that it will not be in Fedora 9. These features will never be >> raised for acceptance by FESCo. >> >> http://fedoraproject.org/wiki/Releases/FeatureXULRunner >> http://fedoraproject.org/wiki/Features/NewGdm > > So what happens if these never get officially "accepted" as Fedora 9 > features? Do we rip out XULRunner and back down to the old GDM? Who > is going to enforce that? > NOTHING. They stay there indefinitely. The important distinction here is that these features are in *CategoryProposedFeature*--which means they are NOT being proposed for acceptance for a release. I have been raising them here to bring attention to them because some people have not followed the complete process described here: http://fedoraproject.org/wiki/Features/Policy and had thought their feature was on the radar for acceptance to Fedora 9. For the Fedora 10 development process I will not send out these notifications as hopefully by then we will all understand the process :) John From fedora at dm.cobite.com Thu Jan 24 14:53:11 2008 From: fedora at dm.cobite.com (David Mansfield) Date: Thu, 24 Jan 2008 09:53:11 -0500 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <4797FAE4.80602@redhat.com> References: <4797FAE4.80602@redhat.com> Message-ID: <1201186391.3001.155.camel@gandalf.cobite.com> On Wed, 2008-01-23 at 21:41 -0500, Warren Togami wrote: > I just had an in-depth discussion with Henrik Nordstr?m of the Squid > project about how HTTP mirrors and the yum tool itself could be improved > to safely handle proxy caches. He gave me lots of good advice about how > HTTP mirrors can be configured for cache safety, Squid can be configured > for yum metadata cache safety, and yum itself can be improved to be more > robust in dealing with proxy caches. > "Cache-Control: max-age=0" > ========================== > This HTTP header directive can be either in the request or response. snip > 3) yum can always include the HTTP directive in its request for > repodata/* files. Can we make this the default in future versions of > yum? I personally don't see a drawback (unless repodata becomes > versioned, then we don't want this.) I recommend this strongly as an option (instead of 'always') but I'd love to be able to set this network wide (yum.conf over NIS? just kidding). I currently have numerous problems with this because all my systems sit behind a squid cache used only for caching yum packages, but we have in internal repo here, and if I push changes to it 'too fast' I get in trouble. I've created a shell script which 'invalidates' the squid cache for repos found in /etc/yum.repos.d using 'wget --no-cache' . Script attached for instructional purposes. Another problem not mentioned is the non-stable nature of mirrorlist. If you use one mirror on one update, and another on the next, the cache cannot help. This requires some non-trivial (in terms of setup cost) fiddling with the yum config on every host to change the way mirror (or baseurl) selection works, and is brittle w.r.t future change. David -------------- next part -------------- A non-text attachment was scrubbed... Name: refresh_squid_repo_data.sh Type: application/x-shellscript Size: 1197 bytes Desc: not available URL: From dwalsh at redhat.com Thu Jan 24 15:08:14 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 24 Jan 2008 10:08:14 -0500 Subject: selinux breaks revisor In-Reply-To: <47963470.70009@gmail.com> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <20080122095152.73f3fab5@redhat.com> <64b14b300801220742n10de35cbs587f419f5b000347@mail.gmail.com> <479626E2.1080607@redhat.com> <47963470.70009@gmail.com> Message-ID: <4798A9DE.3060402@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Valent Turkovic wrote: > John Dennis wrote: >> Valent Turkovic wrote: >>> 2008/1/22 Jesse Keating : >>>> On Tue, 22 Jan 2008 13:29:03 +0100 >>>> "Valent Turkovic" wrote: >>>> >>>>> I tested revisor and wanted to make an up to date version of Fedora 8 >>>>> Live CD - but selinux put a stop to that. >>>> Selinux is not going to work at all for things like revisor (and >>>> pungi/livecd-creator). Both make use of chroots to install packages >>>> into, and in certain cases you can wind up causing lots of harm to your >>>> host system (installing a new policy in the chroot will actually cause >>>> that policy to activate on the running kernel and then you have policy >>>> that doesn't match labels, watch the fun!). >>>> >>>> It is strongly recommended that you disable SELinux or at least put it >>>> in permissive if you're going to be doing composes. >>> >>> Is there a was to make selinux aware of that or atleast put a >>> notification window saying that you need to disable selinux in order >>> to use revisor? >> >> Revisor could be aware of SELinux and provide a warning, SELinux >> cannot do this. >> >>> One more issue for removing selinux as I said in an earlier thread :) >>> Selinux breaks features by desing and in a bad way, and I as a user >>> see more trouble from selinux than it is worth (just MHO). >> >> Your dissatisfaction with SELinux has been duly noted by the list, you >> are free to disable it. However, we would prefer contributions to make >> the distribution more robust and smooth out the bumps rather than >> disabling the technology. Your choice. >> > > I started to like selinux because all of you great fedora devels said > nothing but praises for it, but still it seams that any "feature" I test > seams to break because of selinux. > > But don't worry you all convinced me that selinux has a good reason to > stay. > > Valent. > As Jesse stated earlier, using SELinux on a machine where you are going to use a chroot and install packages without using a virtual machine currently will not work. You are using the same kernel for both the chroot and the host machine, so when a package loads new policy in the chroot (selinux-policy-*rpm) the new policy will effect the host machine. For example if you are building a Fedora 7 livecd on a Fedora 8 host machine, when the new selinux-policy package gets installed the Fedora 7 policy will load and replace the Fedora 8 policy. This will invalidate any contexts that existed in Fedora 8 and not in Fedora 7 causing them to become unlabeled_t. If this happens to a process, the process usually goes wild. We (SELinux engineering) is working on some solutions, but don't have a good one now. Virtual machines? Getting the chroot to run with a different kernel. Faking out /selinux in chroot to do nothing on policy load? Trying to stop Transitions? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEUEARECAAYFAkeYqd4ACgkQrlYvE4MpobPyMwCYwWwFtTnOQit/ENGWGGudTvGa mgCgkUEgkCrRDo/EVbwQq9Ax6ZCWCug= =Ol/k -----END PGP SIGNATURE----- From rhallyx at mindspring.com Thu Jan 24 15:17:41 2008 From: rhallyx at mindspring.com (Richard Hally) Date: Thu, 24 Jan 2008 10:17:41 -0500 Subject: kernel update not updating grup.conf correctly Message-ID: <4798AC15.60006@mindspring.com> Is this a bug? When updating the kernel on my rawhide installation yum/rpm adds the stanza to the grub.conf file but does not copy the root=LABEL=/1 parameter correctly as shown below. What could be wrong? Richard title Fedora (2.6.24-0.167.rc8.git4.fc9) root (hd0,5) kernel /vmlinuz-2.6.24-0.167.rc8.git4.fc9 ro root=LABEL=/ initrd /initrd-2.6.24-0.167.rc8.git4.fc9.img title Fedora (2.6.24-0.164.rc8.git4.fc9) root (hd0,5) kernel /vmlinuz-2.6.24-0.164.rc8.git4.fc9 ro root=LABEL=/1 initrd /initrd-2.6.24-0.164.rc8.git4.fc9.img From skvidal at fedoraproject.org Thu Jan 24 15:22:48 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 24 Jan 2008 10:22:48 -0500 Subject: kernel update not updating grup.conf correctly In-Reply-To: <4798AC15.60006@mindspring.com> References: <4798AC15.60006@mindspring.com> Message-ID: <1201188168.6218.125.camel@cutter> On Thu, 2008-01-24 at 10:17 -0500, Richard Hally wrote: > Is this a bug? When updating the kernel on my rawhide installation > yum/rpm adds the stanza to the grub.conf file but does not copy the > root=LABEL=/1 parameter correctly as shown below. What could be wrong? > Richard > > > title Fedora (2.6.24-0.167.rc8.git4.fc9) > root (hd0,5) > kernel /vmlinuz-2.6.24-0.167.rc8.git4.fc9 ro root=LABEL=/ > initrd /initrd-2.6.24-0.167.rc8.git4.fc9.img > title Fedora (2.6.24-0.164.rc8.git4.fc9) > root (hd0,5) > kernel /vmlinuz-2.6.24-0.164.rc8.git4.fc9 ro root=LABEL=/1 > initrd /initrd-2.6.24-0.164.rc8.git4.fc9.img yum/rpm don't do it. Grubby - which is run when the kernel is updated does it. -sv From tjb at unh.edu Thu Jan 24 15:33:29 2008 From: tjb at unh.edu (Thomas J. Baker) Date: Thu, 24 Jan 2008 10:33:29 -0500 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <797f919ef07923e0bf0802fcfd35a458@togami.com> References: <479805C1.4080005@gmail.com> <797f919ef07923e0bf0802fcfd35a458@togami.com> Message-ID: <1201188809.18570.13.camel@raptor.sr.unh.edu> On Wed, 2008-01-23 at 23:45 -0500, Warren Togami wrote: > On Wed, 23 Jan 2008 21:28:01 -0600, Les Mikesell > wrote: > > Warren Togami wrote: > > > >> Yum and Proxy Caches: Current Dangers > >> ===================================== > >> Users may be using proxy servers in 3 (or more) ways: > > > > Is there a reasonable way to make yum automatically use files cached in > > these local proxies when run by multiple users that share the proxy but > > don't know about each other? Picking some random mirror for each will > > defeat the caching since they will have different URLs to get the same > > file. > > http://fedoraproject.org/wiki/Infrastructure/Mirroring/SiteLocalMirrors > This page needs updating, but it sort of describes what you need to do. > Use your Fedora account to login to MirrorManager and add a private mirror > for yourself along with a site-local netblock in CIDR notation so the > mirror master knows to serve to you when yum clients come from your > network. After a few hours, mirror lists will serve your mirror first, > then random other mirrors in your country/region. > > Example, I have InstantMirror running on my Buffalo Linkstation (hard drive > + ethernet running embedded Linux) at home. I gave that box a private IP > address and pointed a sub-domain name at that (so I could use Apache > name-based VirtualHost for InstantMirror). I then added to MirrorManager > "Warren's Private Home Mirror" which only I can see when I login to the > management interface. In both cases it is REALLY handy when all of your > local clients automatically begin using your local mirror. > > Oh, there might be one more complication. You may need to checkout the > sources for MirrorManager and run the script that reports to MirrorManager > that your mirror is populated. I think mdomsch mentioned that the checkbox > on the MirrorManager interface isn't yet working. Matt, what's the status > of this? > > Hopefully that last wrinkle should be gone soon. > > Warren Togami > wtogami at redhat.com > Slightly off topic but, could you elaborate on the MirrorManager setup for this? I've got a local mirror at home and would like to set up automatic usage from my local hosts on my private NATed network. Did you set up a single host netblock for your public ip address? I have cable internet and my public ip stays the same for several months at a time but it does change. Is there any way to have a more dynamic set up, like a netblock on a domain name so I only have to change my DNS and mirrormanager picks that up? Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From rhally at mindspring.com Thu Jan 24 15:49:26 2008 From: rhally at mindspring.com (Richard Hally) Date: Thu, 24 Jan 2008 10:49:26 -0500 Subject: kernel update not updating grup.conf correctly In-Reply-To: <1201188168.6218.125.camel@cutter> References: <4798AC15.60006@mindspring.com> <1201188168.6218.125.camel@cutter> Message-ID: <4798B386.30909@mindspring.com> seth vidal wrote: > On Thu, 2008-01-24 at 10:17 -0500, Richard Hally wrote: >> Is this a bug? When updating the kernel on my rawhide installation >> yum/rpm adds the stanza to the grub.conf file but does not copy the >> root=LABEL=/1 parameter correctly as shown below. What could be wrong? >> Richard >> >> >> title Fedora (2.6.24-0.167.rc8.git4.fc9) >> root (hd0,5) >> kernel /vmlinuz-2.6.24-0.167.rc8.git4.fc9 ro root=LABEL=/ >> initrd /initrd-2.6.24-0.167.rc8.git4.fc9.img >> title Fedora (2.6.24-0.164.rc8.git4.fc9) >> root (hd0,5) >> kernel /vmlinuz-2.6.24-0.164.rc8.git4.fc9 ro root=LABEL=/1 >> initrd /initrd-2.6.24-0.164.rc8.git4.fc9.img > > yum/rpm don't do it. Grubby - which is run when the kernel is updated > does it. > > -sv > > Thanks Seth, Hi ho Hi ho it's off to bugzilla we go. From tcallawa at redhat.com Thu Jan 24 15:58:17 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 24 Jan 2008 10:58:17 -0500 Subject: Live images and fonts In-Reply-To: <1201183037.2947.1.camel@localhost.localdomain> References: <200801240029.35792.ml@deadbabylon.de> <16144.192.54.193.53.1201163440.squirrel@rousalka.dyndns.org> <1201183037.2947.1.camel@localhost.localdomain> Message-ID: <1201190297.5001.21.camel@localhost.localdomain> On Thu, 2008-01-24 at 08:57 -0500, Matthias Clasen wrote: > -xorg-x11-fonts-truetype Had to go due to licensing issues. See: 317641 ~spot From opensource at till.name Thu Jan 24 16:11:59 2008 From: opensource at till.name (Till Maas) Date: Thu, 24 Jan 2008 17:11:59 +0100 Subject: selinux breaks revisor In-Reply-To: <4798A9DE.3060402@redhat.com> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <47963470.70009@gmail.com> <4798A9DE.3060402@redhat.com> Message-ID: <200801241712.04994.opensource@till.name> On Thu January 24 2008, Daniel J Walsh wrote: > machine. For example if you are building a Fedora 7 livecd on a Fedora > 8 host machine, when the new selinux-policy package gets installed the > Fedora 7 policy will load and replace the Fedora 8 policy. This will > invalidate any contexts that existed in Fedora 8 and not in Fedora 7 > causing them to become unlabeled_t. If this happens to a process, the > process usually goes wild. We (SELinux engineering) is working on some > solutions, but don't have a good one now. > > Virtual machines? Getting the chroot to run with a different kernel. > Faking out /selinux in chroot to do nothing on policy load? > Trying to stop Transitions? Imho it would be nice if it was possible to mark (label) a directory from the outside to be the root of the chroot. Then everything within the chroot directory should have a label for the outside selinux and a label for the inside selinux. The selinus from the outside should allow everything within the chroot to to whatever it wants within the chroot (this could be configure within the policy), but should restrict access to everything outside the chroot. The selinux within the chroot then should act like there is only the inside policy and enforce it like it was the only one. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From sds at tycho.nsa.gov Thu Jan 24 16:22:33 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 24 Jan 2008 11:22:33 -0500 Subject: selinux breaks revisor In-Reply-To: <200801241712.04994.opensource@till.name> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <47963470.70009@gmail.com> <4798A9DE.3060402@redhat.com> <200801241712.04994.opensource@till.name> Message-ID: <1201191753.21288.66.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2008-01-24 at 17:11 +0100, Till Maas wrote: > On Thu January 24 2008, Daniel J Walsh wrote: > > > machine. For example if you are building a Fedora 7 livecd on a Fedora > > 8 host machine, when the new selinux-policy package gets installed the > > Fedora 7 policy will load and replace the Fedora 8 policy. This will > > invalidate any contexts that existed in Fedora 8 and not in Fedora 7 > > causing them to become unlabeled_t. If this happens to a process, the > > process usually goes wild. We (SELinux engineering) is working on some > > solutions, but don't have a good one now. > > > > Virtual machines? Getting the chroot to run with a different kernel. > > Faking out /selinux in chroot to do nothing on policy load? > > Trying to stop Transitions? > > Imho it would be nice if it was possible to mark (label) a directory from the > outside to be the root of the chroot. Then everything within the chroot > directory should have a label for the outside selinux and a label for the > inside selinux. The selinus from the outside should allow everything within > the chroot to to whatever it wants within the chroot (this could be configure > within the policy), but should restrict access to everything outside the > chroot. The selinux within the chroot then should act like there is only the > inside policy and enforce it like it was the only one. I think it would be a property of the chroot'd process and its descendants, not of the directory, as processes operating non-chroot'd may still access the contents of that directory and should still be handled by the host policy. So a per-task policy attribute that would usually always refer to the host/global policy, but could be unshared and then have a private policy loaded for it and its descendants. The main problem is detecting and handling accesses that cross the policy boundary (non-chroot'd process attempts to access file within the directory, chroot'd process manages to break out of the chroot and attempts to access file outside of chroot). -- Stephen Smalley National Security Agency From lesmikesell at gmail.com Thu Jan 24 16:31:07 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 24 Jan 2008 10:31:07 -0600 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <4798A117.4000508@googlemail.com> References: <479805C1.4080005@gmail.com> <797f919ef07923e0bf0802fcfd35a458@togami.com> <479824AA.3050108@gmail.com> <479843C5.7030800@redhat.com> <47989B23.80902@gmail.com> <4798A117.4000508@googlemail.com> Message-ID: <4798BD4B.6080609@gmail.com> Tim Lauridsen wrote: > > This has nothing to do with yum, it is the disto there decides how to > give access to mirrors, yum just does what the distro repo contig tell > it to do. Yes, as I said, the CentOS 3.x setup was just great where they used RRDNS or a geo-ip enabled dns server to keep the URL's consistent. However I don't think it is realistic to expect all mirrors to be able to work that way - and if you don't have dynamic checking on the DNS side (like an F5 Global Load Balancer) or clients that know to retry multiple IPs in the returned list, you can end up stuck trying to access a dead site. > "Don't blame the postman for the bad news" :) Even a postman is going to have trouble when you randomize the addresses... >> Maybe yum needs to do some tricks with cache control headers or >> appending random arguments to ensure the repo data is fresh, but there >> has to be some way to make it re-use packages already downloaded in a >> local proxy cache without any local changes. We have several >> locations where everyone in a large building has to use the same proxy >> to get out, but the people who would be installing/updating their own >> linux boxes would not know what anyone else is doing or be likely to >> coordinate the choice of a URL if they had to change anything - and >> I'd guess that's a common situation. > > This thread is upside down IMHO. > The proxy don't do the right thing, so let us redesign yum, to fix the > problems with the proxy. I seems to be the wrong approach IMHO. Yum is the piece you can fix, so making it do something reasonable in the presence of proxies sounds like not only the right approach but the only one possible. Unless, of course, you'd like to re-invent caching proxies to work the way you like and replace all of the existing ones. > Tim "Proxies is nothing but trouble" :) Note that if yum acted intelligently with proxies, the whole concept of mirror management could be replaced by appropriately placed squid (or similar) proxies with no configuration/maintenance other than setting them to cache large files and restricting public ones to certain targets. Then if yum noticed that no local proxy was being used, it could use some mirrorlist-like mechanism to find one nearby and use it explicitly, eliminating any need for a reverse-proxy setup on the proxy server side. -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Thu Jan 24 16:50:48 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 24 Jan 2008 10:50:48 -0600 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <1201184950.10257.50.camel@code.and.org> References: <479805C1.4080005@gmail.com> <797f919ef07923e0bf0802fcfd35a458@togami.com> <479824AA.3050108@gmail.com> <479843C5.7030800@redhat.com> <47989B23.80902@gmail.com> <1201184950.10257.50.camel@code.and.org> Message-ID: <4798C1E8.4090701@gmail.com> James Antill wrote: >> I think you are missing my point, which is that it would be a huge win >> if yum automatically used typical existing caching proxies with no extra >> setup on anyone's part, so that any number of people behind them would >> get the cached packages without knowing about each other or that they >> need to do something special to defeat the random URLs. > > HTTP doesn't define a way to do this, much like the Pragma header > suggestion is a pretty bad abuse of HTTP ... It's worked for years in browsers. If you have a stale copy in an intermediate cache, a ctl-refresh pulls a fresh one. > suddenly the origin server > going down means you can't get the data from the proxy. Only if the DNS for the origin server points to a single dead IP or the client is too dumb to retry the alternates. Even IE can handle this, so it can't be all that difficult... And yum could have some other retry strategy too. > Please don't assume half of a solution, that never works well. What you > _actually want_ is: > > "On my group my machines X, try not to download data more than once." Add in "by default, with no prearrangement other than configuring a proxy cache to handle large files" and you are close. The other piece is that the same solution should work for all duplicate http downloads. > ...at the ISP level this is solved by getting your mirror into mirror > manager directly. Per-disto, per location setup just isn't going to happen. > At the personal level this is likely better solved by having something > like "Have a zero-conf like service to share pacakges across the local > network". There has even been some work to do this. What does 'local' mean in this context? Many of the machines sharing local proxies would not be in broadcast or multicast range of each other. > In neither case is "work around HTTPs design in yum" a good solution, > IMNSHO. I'd rather call it "using existing infrastructure and protocols intelligently" - instead of cluttering everyone's caches with randomized URLs to get duplicate files. -- Les Mikesell lesmikesell at gmail.com From opensource at till.name Thu Jan 24 16:48:20 2008 From: opensource at till.name (Till Maas) Date: Thu, 24 Jan 2008 17:48:20 +0100 Subject: selinux breaks revisor In-Reply-To: <1201191753.21288.66.camel@moss-spartans.epoch.ncsc.mil> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <200801241712.04994.opensource@till.name> <1201191753.21288.66.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200801241748.24780.opensource@till.name> On Thu January 24 2008, Stephen Smalley wrote: > I think it would be a property of the chroot'd process and its > descendants, not of the directory, as processes operating non-chroot'd > may still access the contents of that directory and should still be > handled by the host policy. So a per-task policy attribute that would Yes, I did not think about this direction. > usually always refer to the host/global policy, but could be unshared > and then have a private policy loaded for it and its descendants. > > The main problem is detecting and handling accesses that cross the > policy boundary (non-chroot'd process attempts to access file within the > directory, chroot'd process manages to break out of the chroot and > attempts to access file outside of chroot). When there were different "namespaces" for the inner and outer selinux, then the outer selinux could handle the access trough the chroot bondary using the normal host namespace and the inner selinux would only handle the access within the chroot, using its own namespace. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From kevin.kofler at chello.at Thu Jan 24 16:52:03 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 24 Jan 2008 16:52:03 +0000 (UTC) Subject: kdebase3-related broken dependencies (was: Re: rawhide report: 20080124 changes) References: <200801241254.m0OCsqrB023485@porkchop.devel.redhat.com> Message-ID: Build System redhat.com> writes: > kdebase3 - 3.5.8-34.fc9.i386 requires libkdeinit_ksmserver.so > kdebase3 - 3.5.8-34.fc9.i386 requires libkdeinit_kaccess.so > kdebase3 - 3.5.8-34.fc9.i386 requires libkdeinit_konsole.so > kdebase3 - 3.5.8-34.fc9.i386 requires libkdeinit_kprinter.so > kdebase3 - 3.5.8-34.fc9.i386 requires libkdeinit_kcontrol.so > kdebase3 - 3.5.8-34.fc9.i386 requires libkdeinit_kjobviewer.so > kdebase3 - 3.5.8-34.fc9.i386 requires libkdeinit_kcminit.so > kdebase3 - 3.5.8-34.fc9.i386 requires libkdeinit_kcminit_startup.so > kdebluetooth - 1.0-0.39.beta8.fc9.i386 requires /usr/bin/kdesu > kscope - 1.6.1-3.fc9.i386 requires libkateutils.so.0 > kscope - 1.6.1-3.fc9.i386 requires libkateinterfaces.so.0 > ksmarttray - 0.52-53.fc9.i386 requires /usr/bin/kdesu These should be back in kdebase3-3.5.8-35.fc9. So you don't have to do anything if your package is in the list _above_. However, the following packages are either partly or entirely obsolete: > compiz-kde - 0.6.2-6.fc9.i386 requires libkdecorations.so.1 (see also the discussion at http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-01-22 for details about this one) > crystal - 1.0.5-1.fc8.i386 requires libkdecorations.so.1 > dekorator - 0.3-3.fc7.i386 requires libkdecorations.so.1 > kicker-compiz - 3.5.4-4.fc8.i386 requires libkickermain.so.1 > kicker-compiz - 3.5.4-4.fc8.i386 requires libtaskmanager.so.1 > ksplash-engine-moodin - 0.4.2-4.fc7.i386 requires libksplashthemes.so.0 > smb4k - 0.8.7-3.fc9.i386 requires libkonqsidebarplugin.so.1 (There is no KWin 3, Kicker, KSplash 3 or Konqueror 3 in Fedora 9. The libraries were still there, but not actually useful.) Packages which are entirely obsolete should be retired according to the procedure at: http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife (Or, if there's a KDE 4 version available, they should get upgraded as soon as possible. If a package is retired and a KDE 4 version becomes available later, it can always be resurrected.) Packages which are only partly obsolete should be fixed to have the obsolete parts removed. Kevin Kofler From cra at WPI.EDU Thu Jan 24 17:05:08 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 24 Jan 2008 12:05:08 -0500 Subject: selinux breaks revisor In-Reply-To: <200801241748.24780.opensource@till.name> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <200801241712.04994.opensource@till.name> <1201191753.21288.66.camel@moss-spartans.epoch.ncsc.mil> <200801241748.24780.opensource@till.name> Message-ID: <20080124170508.GD31787@angus.ind.WPI.EDU> On Thu, Jan 24, 2008 at 05:48:20PM +0100, Till Maas wrote: > > The main problem is detecting and handling accesses that cross the > > policy boundary (non-chroot'd process attempts to access file within the > > directory, chroot'd process manages to break out of the chroot and > > attempts to access file outside of chroot). > > When there were different "namespaces" for the inner and outer selinux, then > the outer selinux could handle the access trough the chroot bondary using the > normal host namespace and the inner selinux would only handle the access > within the chroot, using its own namespace. What do you do if the outside namespace wants to label a file differently than the inner namespace? Create separate namespaces for the on-disk xattrs? From kevin.kofler at chello.at Thu Jan 24 17:09:26 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 24 Jan 2008 17:09:26 +0000 (UTC) Subject: long term support release References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <20080123132618.0660f673@redhat.com> <20080124123513.6399f7d3.mschwendt.tmp0701.nospam@arcor.de> Message-ID: Michael Schwendt arcor.de> writes: > It may be "OK" in general, but it was very disappointing. Fedora Legacy > leadership was not willing to learn from mistakes. As you may remember, > Fedora Legacy started inside bugzilla.fedora.us, copied also the fedora.us > package submission/review/approval process, including the corresponding > bugzilla keywords. It had one foot in the grave already at the start. This > resulted in updates waiting several weeks for approval, simply because the > people providing those updates were treated as completely untrusted or > incapable and were not permitted to publish any updates without prior > approval. They had to wait endlessly for another person to sign off the > updates, and obviously, even fewer volunteers were interested enough to be > responsible for approving updates. For a project where speed does matter > this was inacceptable and drove away or scared off contributors. I pretty much agree it was the extremely burdensome QA which killed Fedora Legacy (it got relaxed a bit later on, but it was still too big of a burden and most of the potential contributors had already given up). Insistence on not trusting Bugzilla's authentication (requiring GPG signatures of Bugzilla messages) didn't help streamline the process either. I think a FL-like project with _no_ QA (i.e. working like FE used to (as soon as the package is built, it gets signed and released in the next push), but without ACLs or even a honor-based concept of maintainership like in the old FE) would be more likely to work. If someone wants to fix a security issue in a package, let them do it and push the package immediately as soon as it's available. Kevin Kofler From opensource at till.name Thu Jan 24 17:11:50 2008 From: opensource at till.name (Till Maas) Date: Thu, 24 Jan 2008 18:11:50 +0100 Subject: selinux breaks revisor In-Reply-To: <20080124170508.GD31787@angus.ind.WPI.EDU> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <200801241748.24780.opensource@till.name> <20080124170508.GD31787@angus.ind.WPI.EDU> Message-ID: <200801241811.54567.opensource@till.name> On Thu January 24 2008, Chuck Anderson wrote: > What do you do if the outside namespace wants to label a file > differently than the inner namespace? Create separate namespaces for > the on-disk xattrs? Yes, this is what I meant with different namespaces, seperate namespaces for the xattrs within the filesystem should be used. Maybe specifying the namespace for the labels of the inner selinux should be an option for chroot then. And it should be the normal situation that the labels differ, because the outside policy should more or less allow everthing for stuff inside the chroot directory, but the inside policy would enforce more restrictions. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From james.antill at redhat.com Thu Jan 24 17:20:41 2008 From: james.antill at redhat.com (James Antill) Date: Thu, 24 Jan 2008 12:20:41 -0500 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <4798C1E8.4090701@gmail.com> References: <479805C1.4080005@gmail.com> <797f919ef07923e0bf0802fcfd35a458@togami.com> <479824AA.3050108@gmail.com> <479843C5.7030800@redhat.com> <47989B23.80902@gmail.com> <1201184950.10257.50.camel@code.and.org> <4798C1E8.4090701@gmail.com> Message-ID: <1201195241.10257.62.camel@code.and.org> On Thu, 2008-01-24 at 10:50 -0600, Les Mikesell wrote: > James Antill wrote: > > >> I think you are missing my point, which is that it would be a huge win > >> if yum automatically used typical existing caching proxies with no extra > >> setup on anyone's part, so that any number of people behind them would > >> get the cached packages without knowing about each other or that they > >> need to do something special to defeat the random URLs. > > > > HTTP doesn't define a way to do this, much like the Pragma header > > suggestion is a pretty bad abuse of HTTP ... > > It's worked for years in browsers. If you have a stale copy in an > intermediate cache, a ctl-refresh pulls a fresh one. Sure, the _user_ has a single URL to work with and can make semi-intelligent decisions with only themselves to blame. Not quite the same as a program with multiple URLs to the same data. Now if you wanted to add ETag support in various places, patches are very likely to be accepted, then any program could make intelligent decisions. > > In neither case is "work around HTTPs design in yum" a good solution, > > IMNSHO. > > I'd rather call it "using existing infrastructure and protocols > intelligently" - instead of cluttering everyone's caches with randomized > URLs to get duplicate files. So you think the best thing to do is remove mirrorlist entirely, and just rely on proxies ... you are obviously free to your opinion, and you can do that today. -- James Antill Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From wtogami at redhat.com Thu Jan 24 17:21:58 2008 From: wtogami at redhat.com (Warren Togami) Date: Thu, 24 Jan 2008 12:21:58 -0500 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <4798BD4B.6080609@gmail.com> References: <479805C1.4080005@gmail.com> <797f919ef07923e0bf0802fcfd35a458@togami.com> <479824AA.3050108@gmail.com> <479843C5.7030800@redhat.com> <47989B23.80902@gmail.com> <4798A117.4000508@googlemail.com> <4798BD4B.6080609@gmail.com> Message-ID: <4798C936.3020802@redhat.com> Les Mikesell wrote: > > Even a postman is going to have trouble when you randomize the addresses... > The real solution that you need is within MirrorManager. Perhaps today MirrorManager will not do what you need. Let us define the functionality that you do need: "Users should be able to define their own site-local netblock and associate it with a preferred public mirror. That preferred public mirror will then *always* show up as the first mirror, followed by others in the region." https://fedorahosted.org/mirrormanager Want to help write this option into MirrorManager? The code is open. >> Tim "Proxies is nothing but trouble" :) The yum developers have an erroneous assumption that only "broken" proxies are at fault for yum problems. I have described at the beginning of this thread that this assumption is false. *Any* proxy server that does caching will occasionally cause the partial sync yum failure, or resigned RPMS will cause a failure. Fortunately, the yum developers were already thinking about using unique (probably SHA1) names of repodata as of yum-3.2.9 for other reasons. This should solve the common partial sync failure in Fedora 9+. However, there remains no good solution for the resigned RPMS case other than falling back to the next mirror. Fortunately this is a rare problem with our stable releases, it mainly effects our development and testers. > > Note that if yum acted intelligently with proxies, the whole concept of > mirror management could be replaced by appropriately placed squid (or > similar) proxies with no configuration/maintenance other than setting > them to cache large files and restricting public ones to certain > targets. Then if yum noticed that no local proxy was being used, it > could use some mirrorlist-like mechanism to find one nearby and use it > explicitly, eliminating any need for a reverse-proxy setup on the proxy > server side. > I can't begin to respond to this because of how misguided it is. Warren Togami wtogami at redhat.com From eswierk at arastra.com Thu Jan 24 17:32:30 2008 From: eswierk at arastra.com (Ed Swierk) Date: Thu, 24 Jan 2008 09:32:30 -0800 Subject: InstantMirror needs a rethink In-Reply-To: <479880CB.8020300@leemhuis.info> References: <4797D5B3.7030002@redhat.com> <479880CB.8020300@leemhuis.info> Message-ID: On Jan 24, 2008 4:12 AM, Thorsten Leemhuis wrote: > Just a hint (not sure if it is not be helpful): ixs in #fedora-devel > mentioned > http://gertjan.freezope.org/replicator/ > once when you started on InstantMirror. Looks interesting and maybe > could be a nice base for a new/improved InstantMirror. That link doesn't work for me, but this one does: http://sourceforge.net/projects/http-replicator/ I haven't had a chance to try it yet but from a quick glance at the code, http-replicator seems to deal with things like byte range requests that InstantMirror drops on the floor. Definitely worth a second look. --Ed From gilboad at gmail.com Thu Jan 24 17:38:41 2008 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 24 Jan 2008 19:38:41 +0200 Subject: kdebase3-related broken dependencies (was: Re: rawhide report: 20080124 changes) In-Reply-To: References: <200801241254.m0OCsqrB023485@porkchop.devel.redhat.com> Message-ID: <1201196321.8782.95.camel@gilboa-home-dev.localdomain> On Thu, 2008-01-24 at 16:52 +0000, Kevin Kofler wrote: > Build System redhat.com> writes: > > kdebase3 - 3.5.8-34.fc9.i386 requires libkdeinit_ksmserver.so > > kdebase3 - 3.5.8-34.fc9.i386 requires libkdeinit_kaccess.so > > kdebase3 - 3.5.8-34.fc9.i386 requires libkdeinit_konsole.so > > kdebase3 - 3.5.8-34.fc9.i386 requires libkdeinit_kprinter.so > > kdebase3 - 3.5.8-34.fc9.i386 requires libkdeinit_kcontrol.so > > kdebase3 - 3.5.8-34.fc9.i386 requires libkdeinit_kjobviewer.so > > kdebase3 - 3.5.8-34.fc9.i386 requires libkdeinit_kcminit.so > > kdebase3 - 3.5.8-34.fc9.i386 requires libkdeinit_kcminit_startup.so > > kdebluetooth - 1.0-0.39.beta8.fc9.i386 requires /usr/bin/kdesu > > kscope - 1.6.1-3.fc9.i386 requires libkateutils.so.0 > > kscope - 1.6.1-3.fc9.i386 requires libkateinterfaces.so.0 > > ksmarttray - 0.52-53.fc9.i386 requires /usr/bin/kdesu > > These should be back in kdebase3-3.5.8-35.fc9. So you don't have to do anything > if your package is in the list _above_. Thanks. Until kdebluetooth/4 is released (no idea when), we're left with kdebluetooth/3 and its KDE3 dependency chain. Hopefully upstream will be more forthcoming about their KDE4 plans. - Gilboa From lesmikesell at gmail.com Thu Jan 24 18:07:01 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 24 Jan 2008 12:07:01 -0600 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <1201195241.10257.62.camel@code.and.org> References: <479805C1.4080005@gmail.com> <797f919ef07923e0bf0802fcfd35a458@togami.com> <479824AA.3050108@gmail.com> <479843C5.7030800@redhat.com> <47989B23.80902@gmail.com> <1201184950.10257.50.camel@code.and.org> <4798C1E8.4090701@gmail.com> <1201195241.10257.62.camel@code.and.org> Message-ID: <4798D3C5.9010203@gmail.com> James Antill wrote: > >>> In neither case is "work around HTTPs design in yum" a good solution, >>> IMNSHO. >> I'd rather call it "using existing infrastructure and protocols >> intelligently" - instead of cluttering everyone's caches with randomized >> URLs to get duplicate files. > > So you think the best thing to do is remove mirrorlist entirely, and > just rely on proxies ... No, I think the best thing would be a mechanism that would make any set of yum's behind the same proxy use the cached mirrorlist and always pick the same first choice from it, with some appropriate alternates to retry only if the first choice doesn't respond. This doesn't 'rely' on the proxy but it will reduce load on the mirrors by the number of machines that happen to share a working proxy as well as speeding up all but the first update. > you are obviously free to your opinion, and you > can do that today. I can't do it usefully since I don't know what URL anyone else who is so inclined might have chosen. Or, for that matter, who else behind the same proxy might be using fedora. -- Les Mikesell lesmikesell at gmail.com From wtogami at redhat.com Thu Jan 24 18:06:01 2008 From: wtogami at redhat.com (Warren Togami) Date: Thu, 24 Jan 2008 13:06:01 -0500 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <4798D3C5.9010203@gmail.com> References: <479805C1.4080005@gmail.com> <797f919ef07923e0bf0802fcfd35a458@togami.com> <479824AA.3050108@gmail.com> <479843C5.7030800@redhat.com> <47989B23.80902@gmail.com> <1201184950.10257.50.camel@code.and.org> <4798C1E8.4090701@gmail.com> <1201195241.10257.62.camel@code.and.org> <4798D3C5.9010203@gmail.com> Message-ID: <4798D389.4070406@redhat.com> Les Mikesell wrote: > > I can't do it usefully since I don't know what URL anyone else who is so > inclined might have chosen. Or, for that matter, who else behind the > same proxy might be using fedora. > If you already run your own site's proxy, why not run another proxy but this one reverse in order to act as your site's Fedora mirror? Then you can solve your yum mirrorlist problem TODAY. Warren Togami wtogami at redhat.com From chasd at silveroaks.com Thu Jan 24 18:21:30 2008 From: chasd at silveroaks.com (chasd) Date: Thu, 24 Jan 2008 12:21:30 -0600 Subject: InstantMirror needs a rethink In-Reply-To: <20080124013235.27D9073053@hormel.redhat.com> References: <20080124013235.27D9073053@hormel.redhat.com> Message-ID: > Today InstantMirror is pretty useful for home and small office > mirrors, > but its limitations make it unsustainable without manual > intervention of > the sysadmin. I am using it now so our ~20 systems don't waste T-1 bandwidth. > - Synchronization/locking of multiple connections downloading the same > file is awkward and broken. My use is low enough volume I haven't run into that. > - There is no good way to clean up aborted tmp files. Haven't had any. > - There is no good way to know what are old files that need pruning. With disk space relatively cheap here in the USA, and a new Fedora every ~6 months, I just rm -rf the old release directories after I migrate to the new version. I don't worry about multiple updates to the same package, except for giant ones like OOo. Another outgrowth of the Fedora release cycle is I usually only apply security updates, or updates that fix specific problems I experience. There is no sense for me to download and apply updates for hardware I don't use, for example. I figure I'll pick up application updates in 6 months when the next release drops, I usually don't need the update _right now_. I don't need a rsync of a mirror, just a cache of the updates I choose to apply because those specific updates will be applied across multiple machines. > - There is no good way of keeping track of the "Big Picture" of its > own > cache, "least recently used" knowing what files were unpopular locally > and should be pruned. I don't have a need for that functionality with my usage. > Any thoughts? Ignoring the temp file and multiple connection issues, the synchronization part could be solved by InstantMirror writing some type of log file or access popularity file. A separate cron script could read in that data and prune the unpopular / duplicate files. From a separate message : > 1) Origin HTTP mirrors can be configured to serve "Cache-Control: > max-age=0" in HTTP headers whenever they serve repodata/* files. This > can become a standard recommendation for all Fedora mirrors. Does > anyone know how to configure Apache to do this? Header always set Cache-Control: max-age=0 Probably the best way would be to put this in a .htaccess file for each repodata directory as that directory is created. The .htaccess file would have a local directory directive instead of a full path ( createrepo ? ). Otherwise the main apache config ( or a file in conf.d ) would need to be updated / added each time a release is made ( or an arch is added). > 2) Squid refresh_pattern can use a regex to override max-age=0 for > repodata/* files. I haven't figured out exactly what the syntax is > for > this. Anybody know squid.conf? refresh_pattern \/repodata\/.* 0 0% 0 > Apache do not have this same abstract internal layer, and > writing > a mod_disk_cache replacement which keeps a mirror type file structure > should be pretty easy thing to do. This seems to best leverage existing code / apps, although I am not in a position to help here. Charles Dostale System Admin - Silver Oaks Communications http://www.silveroaks.com/ 824 17th Street, Moline IL 61265 From jkeating at redhat.com Thu Jan 24 18:24:57 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 24 Jan 2008 13:24:57 -0500 Subject: long term support release In-Reply-To: References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <20080123132618.0660f673@redhat.com> <20080124123513.6399f7d3.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20080124132457.2e524668@redhat.com> On Thu, 24 Jan 2008 17:09:26 +0000 (UTC) Kevin Kofler wrote: > I think a FL-like project with _no_ QA (i.e. working like FE used to > (as soon as the package is built, it gets signed and released in the > next push), but without ACLs or even a honor-based concept of > maintainership like in the old FE) would be more likely to work. If > someone wants to fix a security issue in a package, let them do it > and push the package immediately as soon as it's available. That's pretty terrible because now you have no trust that the issue was actually fixed. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From vonbrand at inf.utfsm.cl Thu Jan 24 15:28:10 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Thu, 24 Jan 2008 12:28:10 -0300 Subject: long term support release In-Reply-To: <47989EF4.3000102@gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <20080123103336.6e24109f@redhat.com> <47976399.3010709@redhat.com> <47979470.6010507@leemhuis.info> <1201150608.17905.78.camel@beck.corsepiu.local> <47989EF4.3000102@gmail.com> Message-ID: <200801241528.m0OFSAk8009592@laptop13.inf.utfsm.cl> Les Mikesell wrote: [...] > A yum repository for RHEL/Centos containing as many as possible of the > additional packages available in fedora would pretty much fill the > need being discussed here. EPEL (Extra Packages for Enterprise Linux) works on both. > Or several, if the primary one won't > include Sun Java, vlc + codecs, and Nvidia/Ati drivers. EPEL doesn't include software that can't be redistributed legally as open source, as it is part of Fedora. Fine with me, BTW. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From nicolas.mailhot at laposte.net Thu Jan 24 18:43:52 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 24 Jan 2008 19:43:52 +0100 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <4798A117.4000508@googlemail.com> References: <479805C1.4080005@gmail.com> <797f919ef07923e0bf0802fcfd35a458@togami.com> <479824AA.3050108@gmail.com> <479843C5.7030800@redhat.com> <47989B23.80902@gmail.com> <4798A117.4000508@googlemail.com> Message-ID: <1201200232.10938.7.camel@rousalka.dyndns.org> Le jeudi 24 janvier 2008 ? 15:30 +0100, Tim Lauridsen a ?crit : > This thread is upside down IMHO. > The proxy don't do the right thing, so let us redesign yum, to fix the > problems with the proxy. I seems to be the wrong approach IMHO. No, it's "yum metadata is proxy-unfriendly, someone finally acknowledged this, let's fix yum and createrepo to play well with existing internet infrastructure". -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From lesmikesell at gmail.com Thu Jan 24 18:49:35 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 24 Jan 2008 12:49:35 -0600 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <4798C936.3020802@redhat.com> References: <479805C1.4080005@gmail.com> <797f919ef07923e0bf0802fcfd35a458@togami.com> <479824AA.3050108@gmail.com> <479843C5.7030800@redhat.com> <47989B23.80902@gmail.com> <4798A117.4000508@googlemail.com> <4798BD4B.6080609@gmail.com> <4798C936.3020802@redhat.com> Message-ID: <4798DDBF.2050209@gmail.com> Warren Togami wrote: >> Even a postman is going to have trouble when you randomize the >> addresses... >> > > The real solution that you need is within MirrorManager. Perhaps today > MirrorManager will not do what you need. Let us define the > functionality that you do need: > > "Users should be able to define their own site-local netblock and > associate it with a preferred public mirror. That preferred public > mirror will then *always* show up as the first mirror, followed by > others in the region." Anything that requires coordination among any or all of the proxy manager or fedora users that happen to be behind the proxy just isn't going to happen here and I'm having trouble imagining an organization where it would. Can yum make this happen automatically, or without intervention, can the mirrormanager list always return the same first choice when requested from the same address? If that already happens, then maybe things aren't as bad as I thought. > https://fedorahosted.org/mirrormanager > Want to help write this option into MirrorManager? The code is open. > >>> Tim "Proxies is nothing but trouble" :) > > The yum developers have an erroneous assumption that only "broken" > proxies are at fault for yum problems. I have described at the > beginning of this thread that this assumption is false. *Any* proxy > server that does caching will occasionally cause the partial sync yum > failure, or resigned RPMS will cause a failure. I'm missing something here. A cache is only going to resend what it got the first time. If the first user got the right thing, so will the second. If the first user got something wrong, don't blame the cache for it. > Fortunately, the yum developers were already thinking about using unique > (probably SHA1) names of repodata as of yum-3.2.9 for other reasons. > This should solve the common partial sync failure in Fedora 9+. This should be needed to fix the first user's problem as much as subsequent ones. >> Note that if yum acted intelligently with proxies, the whole concept >> of mirror management could be replaced by appropriately placed squid >> (or similar) proxies with no configuration/maintenance other than >> setting them to cache large files and restricting public ones to >> certain targets. Then if yum noticed that no local proxy was being >> used, it could use some mirrorlist-like mechanism to find one nearby >> and use it explicitly, eliminating any need for a reverse-proxy setup >> on the proxy server side. >> > > I can't begin to respond to this because of how misguided it is. I think anything that needs individual per-distro, per-version, per-location management just to act like a working cache is even more misguided, but maybe there some other approach that would work. Perhaps you could ask the squid expert if a slightly more intelligent client could eliminate that need and make cascaded proxies work better. -- Les Mikesell lesmikesell at gmail.com From mjc at avtechpulse.com Thu Jan 24 18:53:01 2008 From: mjc at avtechpulse.com (Dr. Michael J. Chudobiak) Date: Thu, 24 Jan 2008 13:53:01 -0500 Subject: gnome jhbuild trouble Message-ID: <4798DE8D.4050203@avtechpulse.com> I can't get gnome jhbuild to install on F8: $ jhbuild sanitycheck Could not find DocBook XSL Stylesheets in XML catalog How can I fix that? An earlier version of jhbuild worked, and I believe I have all the required packages installed... - Mike From vonbrand at inf.utfsm.cl Thu Jan 24 15:20:15 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Thu, 24 Jan 2008 12:20:15 -0300 Subject: long term support release In-Reply-To: <1201166022.17905.109.camel@beck.corsepiu.local> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <20080123103336.6e24109f@redhat.com> <47976399.3010709@redhat.com> <47979470.6010507@leemhuis.info> <1201150608.17905.78.camel@beck.corsepiu.local> <20080124081720.GA2636@free.fr> <1201166022.17905.109.camel@beck.corsepiu.local> Message-ID: <200801241520.m0OFKFi0000499@laptop13.inf.utfsm.cl> Ralf Corsepius wrote: > On Thu, 2008-01-24 at 09:17 +0100, Patrice Dumas wrote: > > On Thu, Jan 24, 2008 at 05:56:48AM +0100, Ralf Corsepius wrote: [...] > > > RHEL and CentOS just happen to be largely compatible, because they are > > > derivatives from the same sources. One of CentOS' main objectives is to be binary compatible with RHEL. It mostly changes branding and artwork, but there are some extra packages too. > > They are more than largely compatible, they are almost similar. There > > are differences, but not really related to the bits > Unless you buy RHEL from RH, you will not be able to tell. Could you elaborate? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From wtogami at redhat.com Thu Jan 24 18:52:50 2008 From: wtogami at redhat.com (Warren Togami) Date: Thu, 24 Jan 2008 13:52:50 -0500 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <4798DDBF.2050209@gmail.com> References: <479805C1.4080005@gmail.com> <797f919ef07923e0bf0802fcfd35a458@togami.com> <479824AA.3050108@gmail.com> <479843C5.7030800@redhat.com> <47989B23.80902@gmail.com> <4798A117.4000508@googlemail.com> <4798BD4B.6080609@gmail.com> <4798C936.3020802@redhat.com> <4798DDBF.2050209@gmail.com> Message-ID: <4798DE82.4080602@redhat.com> Les Mikesell wrote: >> The yum developers have an erroneous assumption that only "broken" >> proxies are at fault for yum problems. I have described at the >> beginning of this thread that this assumption is false. *Any* proxy >> server that does caching will occasionally cause the partial sync yum >> failure, or resigned RPMS will cause a failure. > > I'm missing something here. A cache is only going to resend what it got > the first time. If the first user got the right thing, so will the > second. If the first user got something wrong, don't blame the cache > for it. > >> Fortunately, the yum developers were already thinking about using >> unique (probably SHA1) names of repodata as of yum-3.2.9 for other >> reasons. This should solve the common partial sync failure in Fedora 9+. > > This should be needed to fix the first user's problem as much as > subsequent ones. Read the original post of this thread again. You completely missed the point of that post, which was NOT your problem at all. Warren From walters at redhat.com Thu Jan 24 19:03:52 2008 From: walters at redhat.com (Colin Walters) Date: Thu, 24 Jan 2008 14:03:52 -0500 Subject: gnome jhbuild trouble In-Reply-To: <4798DE8D.4050203@avtechpulse.com> References: <4798DE8D.4050203@avtechpulse.com> Message-ID: <1201201432.7364.24.camel@space-ghost.verbum.private> On Thu, 2008-01-24 at 13:53 -0500, Dr. Michael J. Chudobiak wrote: > I can't get gnome jhbuild to install on F8: > > $ jhbuild sanitycheck > Could not find DocBook XSL Stylesheets in XML catalog https://bugzilla.redhat.com/show_bug.cgi?id=428531 From jkeating at redhat.com Thu Jan 24 19:02:18 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 24 Jan 2008 14:02:18 -0500 Subject: long term support release In-Reply-To: <200801241520.m0OFKFi0000499@laptop13.inf.utfsm.cl> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <20080123103336.6e24109f@redhat.com> <47976399.3010709@redhat.com> <47979470.6010507@leemhuis.info> <1201150608.17905.78.camel@beck.corsepiu.local> <20080124081720.GA2636@free.fr> <1201166022.17905.109.camel@beck.corsepiu.local> <200801241520.m0OFKFi0000499@laptop13.inf.utfsm.cl> Message-ID: <20080124140218.050a41be@redhat.com> On Thu, 24 Jan 2008 12:20:15 -0300 "Horst H. von Brand" wrote: > but there are some extra packages too. Which are kept in different repos and can be opted out of (aside from the artwork packages) -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From vonbrand at inf.utfsm.cl Thu Jan 24 19:15:56 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Thu, 24 Jan 2008 16:15:56 -0300 Subject: InstantMirror needs a rethink In-Reply-To: References: <20080124013235.27D9073053@hormel.redhat.com> Message-ID: <200801241915.m0OJFu85006602@laptop13.inf.utfsm.cl> chasd wrote: [...] > Another outgrowth of the Fedora release cycle is I usually only apply > security updates, or updates that fix specific problems I experience. > There is no sense for me to download and apply updates for hardware I > don't use, for example. I figure I'll pick up application updates in > 6 months when the next release drops, I usually don't need the update > _right now_. Very, very bad idea. You don't /know/ what the maintainer just happened not to mention in the ChangeLog (there you see everything from BZ-by-BZ and CVE details to just "Updated" (if that much). And more than once a fix for a "minor bug" happened to close a bad vulnerability... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From mschwendt.tmp0701.nospam at arcor.de Thu Jan 24 19:23:00 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 24 Jan 2008 20:23:00 +0100 Subject: long term support release In-Reply-To: <20080124132457.2e524668@redhat.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <20080123132618.0660f673@redhat.com> <20080124123513.6399f7d3.mschwendt.tmp0701.nospam@arcor.de> <20080124132457.2e524668@redhat.com> Message-ID: <20080124202300.3642a2b6.mschwendt.tmp0701.nospam@arcor.de> On Thu, 24 Jan 2008 13:24:57 -0500, Jesse Keating wrote: > On Thu, 24 Jan 2008 17:09:26 +0000 (UTC) > Kevin Kofler wrote: > > > I think a FL-like project with _no_ QA (i.e. working like FE used to > > (as soon as the package is built, it gets signed and released in the > > next push), but without ACLs or even a honor-based concept of > > maintainership like in the old FE) would be more likely to work. If > > someone wants to fix a security issue in a package, let them do it > > and push the package immediately as soon as it's available. > > That's pretty terrible because now you have no trust that the issue was > actually fixed. FL did not guarantee anything either. You can offer post-release reviews. That means, confirmation of fixes after publishing updates as soon as they are available. The queue of what to review might grow hopelessly. But meanwhile, the people who work on update packages can earn trust and stay productive. Only with lower hurdles you can find out whether a project fails because of lack of man-power. The opposite is even more "terrible". No fix to offer for several weeks because it sits somewhere in bugzilla waiting for a reviewer, who only is courageous enough to review on a single dist. Then perhaps only a test-build, and still nobody to approve it finally, so it could be moved to the stable updates repo. You can't grow a community if you have nothing to offer and if you can't raise interest because inappropriate policies and procedures are carved into stone already. From nicolas.mailhot at laposte.net Thu Jan 24 19:23:59 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 24 Jan 2008 20:23:59 +0100 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <4798DDBF.2050209@gmail.com> References: <479805C1.4080005@gmail.com> <797f919ef07923e0bf0802fcfd35a458@togami.com> <479824AA.3050108@gmail.com> <479843C5.7030800@redhat.com> <47989B23.80902@gmail.com> <4798A117.4000508@googlemail.com> <4798BD4B.6080609@gmail.com> <4798C936.3020802@redhat.com> <4798DDBF.2050209@gmail.com> Message-ID: <1201202640.10938.38.camel@rousalka.dyndns.org> Le jeudi 24 janvier 2008 ? 12:49 -0600, Les Mikesell a ?crit : > I'm missing something here. A cache is only going to resend what it got > the first time. If the first user got the right thing, so will the > second. No it won't. Common failures are: - T0: user A updates foo and in the course of doing it populates the proxy cache with yum T0 metadata and foo rpm only. - T1: upstream updates repo changing bar rpm version. Metadata is regenerated with the same filenames as before. For the proxy its T0 copy is still valid till the expiration delay it got in http headers the first time. - T2: user B wants to update bar. The proxy happily serves yum the cached T0 metadata (since yum didn't request any special treatment for it). It tells yum the T0 bar is available. Unfortunately it's not - user A didn't download it so it's not in the cache, and upstream moved to a new version - T0: user A updates foo and in the course of doing it populates the proxy cache with yum T0 metadata and foo rpm - T1: upstream signs foo rpm and regenerates the repo. Metadata is regenerated with the same filenames as before. For the proxy its T0 copy is still valid till the expiration delay it got in http headers the first time. - T2: proxy cache is contended, it evicts foo rpm since it takes a lot of room. T0 metadata is small so it's retained for now - T3: user B wants to update foo. The proxy happily serves yum the cached T0 metadata (since yum didn't request any special treatment for it). It tells yum foo is available with T0 checksum. Unfortunately it's not - T0 foo rpm was evicted from the cache, when user B requests the same URL as user A it gets T1 signed foo with a new checksum. (you can invert this case with a proxy which strategy is to keep big files which are expensive to download, and drop small metadata) In all those cases the proxy worked as designed and was fooled by yum/createrepo using the same URLs for different objects. A proxy will always serve you a set of files as they existed on the original location at some time. But there is zero insurance they were taken from this location at the same time, so you *must* take care new content is created with new filenames, or your web server tells the proxy when old data will be replaced by new one (via expires), or your system is able to cope with a mix of files from different times. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From lesmikesell at gmail.com Thu Jan 24 19:49:30 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 24 Jan 2008 13:49:30 -0600 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <1201202640.10938.38.camel@rousalka.dyndns.org> References: <479805C1.4080005@gmail.com> <797f919ef07923e0bf0802fcfd35a458@togami.com> <479824AA.3050108@gmail.com> <479843C5.7030800@redhat.com> <47989B23.80902@gmail.com> <4798A117.4000508@googlemail.com> <4798BD4B.6080609@gmail.com> <4798C936.3020802@redhat.com> <4798DDBF.2050209@gmail.com> <1201202640.10938.38.camel@rousalka.dyndns.org> Message-ID: <4798EBCA.7030704@gmail.com> Nicolas Mailhot wrote: > >> I'm missing something here. A cache is only going to resend what it got >> the first time. If the first user got the right thing, so will the >> second. > > No it won't. Common failures are: > > - T0: user A updates foo and in the course of doing it populates the > proxy cache with yum T0 metadata and foo rpm only. > - T1: upstream updates repo changing bar rpm version. Metadata is > regenerated with the same filenames as before. For the proxy its T0 copy > is still valid till the expiration delay it got in http headers the > first time. > - T2: user B wants to update bar. The proxy happily serves yum the > cached T0 metadata (since yum didn't request any special treatment for > it). It tells yum the T0 bar is available. Unfortunately it's not - user > A didn't download it so it's not in the cache, and upstream moved to a > new version Can't the T1->T2 transition happen while user A is in mid-update? I'm fairly sure I've seen something like that without any proxies involved. > - T0: user A updates foo and in the course of doing it populates the > proxy cache with yum T0 metadata and foo rpm > - T1: upstream signs foo rpm and regenerates the repo. Metadata is > regenerated with the same filenames as before. For the proxy its T0 copy > is still valid till the expiration delay it got in http headers the > first time. > - T2: proxy cache is contended, it evicts foo rpm since it takes a lot > of room. T0 metadata is small so it's retained for now > - T3: user B wants to update foo. The proxy happily serves yum the > cached T0 metadata (since yum didn't request any special treatment for > it). It tells yum foo is available with T0 checksum. Unfortunately it's > not - T0 foo rpm was evicted from the cache, when user B requests the > same URL as user A it gets T1 signed foo with a new checksum. > > (you can invert this case with a proxy which strategy is to keep big > files which are expensive to download, and drop small metadata) > > In all those cases the proxy worked as designed and was fooled by > yum/createrepo using the same URLs for different objects. Again, I think you'll still have the same issues if user A's update spans any of these arbitrary Tx designations - at least the ones where you've got metadata and the rpms are changed before you get them. > A proxy will always serve you a set of files as they existed on the > original location at some time. But there is zero insurance they were > taken from this location at the same time, so you *must* take care new > content is created with new filenames, or your web server tells the > proxy when old data will be replaced by new one (via expires), or your > system is able to cope with a mix of files from different times. But you are doing things that aren't guaranteed to work in the first place. All the cache does is expand the window for breakage a bit. -- Les Mikesell lesmikesell at gmal.com From jkeating at redhat.com Thu Jan 24 19:47:54 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 24 Jan 2008 14:47:54 -0500 Subject: long term support release In-Reply-To: <20080124202300.3642a2b6.mschwendt.tmp0701.nospam@arcor.de> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <20080123132618.0660f673@redhat.com> <20080124123513.6399f7d3.mschwendt.tmp0701.nospam@arcor.de> <20080124132457.2e524668@redhat.com> <20080124202300.3642a2b6.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20080124144754.6a681cd4@redhat.com> On Thu, 24 Jan 2008 20:23:00 +0100 Michael Schwendt wrote: > The opposite is even more "terrible". No fix to offer for several > weeks because it sits somewhere in bugzilla waiting for a reviewer, > who only is courageous enough to review on a single dist. Then > perhaps only a test-build, and still nobody to approve it finally, so > it could be moved to the stable updates repo. You can't grow a > community if you have nothing to offer and if you can't raise > interest because inappropriate policies and procedures are carved > into stone already. Yep, we failed. There was failure on the process, the people, the resources, and the changing community space. We're learning from those failures and trying not to repeat what can be avoided. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From james at fedoraproject.com Thu Jan 24 19:51:16 2008 From: james at fedoraproject.com (James Antill) Date: Thu, 24 Jan 2008 14:51:16 -0500 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <38259.192.54.193.53.1201162967.squirrel@rousalka.dyndns.org> References: <4797FAE4.80602@redhat.com> <20080123220451.4984e818@redhat.com> <38259.192.54.193.53.1201162967.squirrel@rousalka.dyndns.org> Message-ID: <1201204276.10257.100.camel@code.and.org> On Thu, 2008-01-24 at 09:22 +0100, Nicolas Mailhot wrote: > Le Jeu 24 janvier 2008 04:04, Jesse Keating a ?crit : > > On Wed, 23 Jan 2008 21:41:40 -0500 > > Warren Togami wrote: > > > In fact, I just tried this by hand. I edited repomd.xml and changed > > 'primary.sqlite.bz2' to 'primary-1234.sqlite.bz2' and then moved the > > file on the file system. Yum client didn't even blink, it happily > > downloaded the -1234 file. > > > > So if this method is possible, does that change things for the better > > for you? > > I made the same analysis several months ago when I setup my own local > mod_proxy cache. I'm glad to see Warren is getting through better than > me at the time. Changing file contents while keeping the same filename > is the ultimate proxy sin. Wow, yeh that's one possibility, let's put that down here: 1. Warren managed to finally get through to the stupid yum developers by having a flamewar on fedora-devel-list, they relented and have turned the "do all the correct proxy stuff" option on for 3.2.9. Damn them, infidels, if only they would have changed that option before! Now we'll have a look around and come up with another possibility, just as a control, and we'll put here: 2. Yum developers wanted to do transactions over the index and metadata, to solve a whole bunch of problems and so said developers discussed the details late-ish last year on #yum and yum-devel and even said it was going to be fixed when Jesse opened a related bug[1] at the end of November. It was then written and tested by all of said developers, over the next 6 weeks or so[2]. Then it was also discussed generating unique names for the metdata itself within the index, now that we could see both the old and new index and so do the right thing fairly easily. Again, more testing and discussion and some code. Then the release of 3.2.9. Now maybe it's just me, but I have an idea why #1 might not appear to work so well over the long term ... but feel free to continue using that method, if you think that's better. [1] 405201 [2] upstream git commit c3d6b04587499992a32caf36ff3c6f03f8ef2426 -- James Antill From nicolas.mailhot at laposte.net Thu Jan 24 20:04:26 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 24 Jan 2008 21:04:26 +0100 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <4798EBCA.7030704@gmail.com> References: <479805C1.4080005@gmail.com> <797f919ef07923e0bf0802fcfd35a458@togami.com> <479824AA.3050108@gmail.com> <479843C5.7030800@redhat.com> <47989B23.80902@gmail.com> <4798A117.4000508@googlemail.com> <4798BD4B.6080609@gmail.com> <4798C936.3020802@redhat.com> <4798DDBF.2050209@gmail.com> <1201202640.10938.38.camel@rousalka.dyndns.org> <4798EBCA.7030704@gmail.com> Message-ID: <1201205066.10938.45.camel@rousalka.dyndns.org> Le jeudi 24 janvier 2008 ? 13:49 -0600, Les Mikesell a ?crit : > Can't the T1->T2 transition happen while user A is in mid-update? I'm > fairly sure I've seen something like that without any proxies involved. ... > Again, I think you'll still have the same issues if user A's update > spans any of these arbitrary Tx designations - at least the ones where > you've got metadata and the rpms are changed before you get them. ... > But you are doing things that aren't guaranteed to work in the first > place. All the cache does is expand the window for breakage a bit. You're perfectly right. Smart web clients know the internet can shift under their feet and refresh files in case of problems instead of failing horribly on users (in the browser case you have a big refresh button for this reason). Though smart web designers know client refreshes are expensive and limit the refresh needs by avoiding to reuse the same filenames for different stuff. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From chasd at silveroaks.com Thu Jan 24 20:04:45 2008 From: chasd at silveroaks.com (chasd) Date: Thu, 24 Jan 2008 14:04:45 -0600 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <20080124184738.92E9D734A9@hormel.redhat.com> References: <20080124184738.92E9D734A9@hormel.redhat.com> Message-ID: <92EA9840-C120-4226-8F40-4FA11E790D08@silveroaks.com> Les Mikesell wrote: > I'm missing something here. A cache is only going to resend what > it got > the first time. If the first user got the right thing, so will the > second. If the first user got something wrong, don't blame the cache > for it. There can be a problem when the cache holds on to the "bad" data for too long, serving that to other clients that ask for it later. The way things are now, a cache has a good reason _not_ to look for fresh data when the end users would like it to. In that case, some blame is on the cache, and every once in a while I have to kick squid in the butt because of that. Adjusting the tools used to update machines and to create the repos in order to help the cache make better decisions is a Good Thing. General comments about this thread : The default update scheme is to use multiple mirrors managed by an intelligent script. Works for a lot of people, but not everyone. I think there needs to be an assumption that some kind of administrator is going to have to opt out of that default and opt into any caching scheme. At that point the issue is how easy do we make it for the administrator to do that ? What kind of changes need to be made on the clients, and what additional infrastructure changes need to be made ? Instant Mirror is very easy right now, at least if you have any chops as an admin. Install a rpm, twiddle the config, set up a host in DNS, distribute a repo file for the clients. My view on the intent of Mr. Togami's OP is to accept that level of ease-a-tude-inosity and make the solution less error prone. Making the opt-in easier would only be a bonus. The way I use and configure squid for general web access caching would not make it a good cache for updates. I would rather have a separate update caching mechanism rather than try to make our squid cache do double duty. I would want more control over that update cache than whatever squid would supply automatically. Charles Dostale From ml at deadbabylon.de Thu Jan 24 20:09:27 2008 From: ml at deadbabylon.de (Sebastian Vahl) Date: Thu, 24 Jan 2008 21:09:27 +0100 Subject: Live images and fonts In-Reply-To: <16144.192.54.193.53.1201163440.squirrel@rousalka.dyndns.org> References: <200801240029.35792.ml@deadbabylon.de> <16144.192.54.193.53.1201163440.squirrel@rousalka.dyndns.org> Message-ID: <20080124210927.411b1a50@deadbabylon.de> Am Thu, 24 Jan 2008 09:30:40 +0100 (CET) schrieb "Nicolas Mailhot" : > > Le Jeu 24 janvier 2008 00:29, Sebastian Vahl a ?crit : > > Hi. > > Hi, > > > After some time I've done a new test spin of my kde live images > > today. What > > I've experienced is that most of the former installed fonts are > > missing. A > > diff between my released rawhide live image for KDE 4 and my current > > one is: > > I know next to nothing about live images but I confirm that the fedora > font landscape changed quite a bit since fedora 8 (new fonts, pulled > fonts, renamed fonts, new defaults) so anything font-related done at > F8 time probably needs to be revisited now That's the point: For F8 I was relying on comps.xml to pull the most needed fonts in automatically. This was also working 2 weeks ago (for the kde4 image). But it seems that this has changed after that. I've re-included the fonts manually but IMHO I should talk to the fonts sig what fonts are really needed. My current list: baekmuk-ttf-fonts-common baekmuk-ttf-fonts-gulim bitmap-fonts cjkunifonts-uming dejavu-lgc-fonts ghostscript-fonts jomolhari-fonts kacst-fonts liberation-fonts lohit-fonts-bengali lohit-fonts-gujarati lohit-fonts-hindi lohit-fonts-kannada lohit-fonts-oriya lohit-fonts-punjabi lohit-fonts-tamil lohit-fonts-telugu paktype-fonts sazanami-fonts-gothic urw-fonts xorg-x11-fonts-100dpi xorg-x11-fonts-ISO8859-1-100dpi xorg-x11-fonts-misc xorg-x11-fonts-Type1 Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Thu Jan 24 20:13:56 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 24 Jan 2008 21:13:56 +0100 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <1201204276.10257.100.camel@code.and.org> References: <4797FAE4.80602@redhat.com> <20080123220451.4984e818@redhat.com> <38259.192.54.193.53.1201162967.squirrel@rousalka.dyndns.org> <1201204276.10257.100.camel@code.and.org> Message-ID: <1201205636.10938.53.camel@rousalka.dyndns.org> Le jeudi 24 janvier 2008 ? 14:51 -0500, James Antill a ?crit : > Now maybe it's just me, but I have an idea why #1 might not appear to > work so well over the long term ... I'd be impressed if the problem was first reported last november. Since it was reported many times before, and your reaction is the blame the messenger once again, I'm not. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From ianburrell at gmail.com Thu Jan 24 20:16:13 2008 From: ianburrell at gmail.com (Ian Burrell) Date: Thu, 24 Jan 2008 12:16:13 -0800 Subject: InstantMirror needs a rethink In-Reply-To: <4797D5B3.7030002@redhat.com> References: <4797D5B3.7030002@redhat.com> Message-ID: On Jan 23, 2008 4:02 PM, Warren Togami wrote: > > - Synchronization/locking of multiple connections downloading the same > file is awkward and broken. I think a locking scheme on the files could solve this problem. The normal file would always be the complete downloaded file. The first downloading process would create the temp file and lock it. When it finishes, it moves it to the real file and unlocks it. Any other downloading processes see the locked temp file and wait for it to be unlocked. An unlocked temp file indicates a download failure. Waiters would have to start over if there was a failure. Things would be more complicated if we want the waiters to stream the partial file as it is downloaded. > - There is no good way to clean up aborted tmp files. > - There is no good way to know what are old files that need pruning. > - There is no good way of keeping track of the "Big Picture" of its own > cache, "least recently used" knowing what files were unpopular locally > and should be pruned. > These could be solved with a cache cleaning script. The script would remove aborted (ie unlocked) tmp files. The least-recently-used can be determined with the atime of the files. An alternative is to store some metadata about the cached files in a separate database. Berkeley DB or SQLite would work as would per-directory or per-file data files. This would make the most sense if the Etag and Last-Modified-Tiome need to be stored for the caching to work correctly. It could also store the last-accessed-time. Locking on the entries would be required and that would provide the locking for simultaneous downloads. - Ian From lesmikesell at gmail.com Thu Jan 24 20:28:27 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 24 Jan 2008 14:28:27 -0600 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <1201205066.10938.45.camel@rousalka.dyndns.org> References: <479805C1.4080005@gmail.com> <797f919ef07923e0bf0802fcfd35a458@togami.com> <479824AA.3050108@gmail.com> <479843C5.7030800@redhat.com> <47989B23.80902@gmail.com> <4798A117.4000508@googlemail.com> <4798BD4B.6080609@gmail.com> <4798C936.3020802@redhat.com> <4798DDBF.2050209@gmail.com> <1201202640.10938.38.camel@rousalka.dyndns.org> <4798EBCA.7030704@gmail.com> <1201205066.10938.45.camel@rousalka.dyndns.org> Message-ID: <4798F4EB.3030308@gmail.com> Nicolas Mailhot wrote: > >> But you are doing things that aren't guaranteed to work in the first >> place. All the cache does is expand the window for breakage a bit. > > You're perfectly right. Smart web clients know the internet can shift > under their feet and refresh files in case of problems instead of > failing horribly on users (in the browser case you have a big refresh > button for this reason). Though smart web designers know client > refreshes are expensive and limit the refresh needs by avoiding to reuse > the same filenames for different stuff. Getting a bit off the original topic here, but the "other" thing I've always wished yum could do is "repeatable" updates. That is, the ability to update one machine, test some things, then update another and get only the same set of changes even if some newer packages had been subsequently added to the repos. Currently I believe the only way to do this is to mirror the entire set of repos in each state that you might want to re-use. Perhaps some transactioning info could fix both things at once. -- Les Mikesell lesmikesell at gmail.com From nicolas.mailhot at laposte.net Thu Jan 24 20:28:14 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 24 Jan 2008 21:28:14 +0100 Subject: Live images and fonts In-Reply-To: <20080124210927.411b1a50@deadbabylon.de> References: <200801240029.35792.ml@deadbabylon.de> <16144.192.54.193.53.1201163440.squirrel@rousalka.dyndns.org> <20080124210927.411b1a50@deadbabylon.de> Message-ID: <1201206494.10938.59.camel@rousalka.dyndns.org> Le jeudi 24 janvier 2008 ? 21:09 +0100, Sebastian Vahl a ?crit : > Am Thu, 24 Jan 2008 09:30:40 +0100 (CET) > > I know next to nothing about live images but I confirm that the fedora > > font landscape changed quite a bit since fedora 8 (new fonts, pulled > > fonts, renamed fonts, new defaults) so anything font-related done at > > F8 time probably needs to be revisited now > > That's the point: For F8 I was relying on comps.xml to pull the most > needed fonts in automatically. This was also working 2 weeks ago (for > the kde4 image). But it seems that this has changed after that. That's strange because comps/comps-f9.xml.in in cvs seems perfectly fine to me, and Jens and me have updated it with our font changes regularly. > I've re-included the fonts manually but IMHO I should talk to the fonts > sig what fonts are really needed. The SIG is likely to complain localization groups didn't fill http://fedoraproject.org/wiki/SIGs/Fonts/Triaging/L10N :p -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From james at fedoraproject.com Thu Jan 24 20:29:55 2008 From: james at fedoraproject.com (James Antill) Date: Thu, 24 Jan 2008 15:29:55 -0500 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <1201205636.10938.53.camel@rousalka.dyndns.org> References: <4797FAE4.80602@redhat.com> <20080123220451.4984e818@redhat.com> <38259.192.54.193.53.1201162967.squirrel@rousalka.dyndns.org> <1201204276.10257.100.camel@code.and.org> <1201205636.10938.53.camel@rousalka.dyndns.org> Message-ID: <1201206595.10257.107.camel@code.and.org> On Thu, 2008-01-24 at 21:13 +0100, Nicolas Mailhot wrote: > Le jeudi 24 janvier 2008 ? 14:51 -0500, James Antill a ?crit : > > > Now maybe it's just me, but I have an idea why #1 might not appear to > > work so well over the long term ... > > I'd be impressed if the problem was first reported last november. Since > it was reported many times before, and your reaction is the blame the > messenger once again, I'm not. I was _not_ saying you shouldn't report any problems you have, please do so and also request any features that you want. Seth esp. will often respond to a BZ within a frighteningly short amount of time. Just that there might be a good way of going about something, and a not so good way. But no, we don't have infinite resources, and depending on what you/whoever asked for it might well have been considered too hard or lower priority than something else. -- James Antill Fedora From skvidal at fedoraproject.org Thu Jan 24 20:30:40 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 24 Jan 2008 15:30:40 -0500 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <4798F4EB.3030308@gmail.com> References: <479805C1.4080005@gmail.com> <797f919ef07923e0bf0802fcfd35a458@togami.com> <479824AA.3050108@gmail.com> <479843C5.7030800@redhat.com> <47989B23.80902@gmail.com> <4798A117.4000508@googlemail.com> <4798BD4B.6080609@gmail.com> <4798C936.3020802@redhat.com> <4798DDBF.2050209@gmail.com> <1201202640.10938.38.camel@rousalka.dyndns.org> <4798EBCA.7030704@gmail.com> <1201205066.10938.45.camel@rousalka.dyndns.org> <4798F4EB.3030308@gmail.com> Message-ID: <1201206640.8834.1.camel@cutter> On Thu, 2008-01-24 at 14:28 -0600, Les Mikesell wrote: > Nicolas Mailhot wrote: > > > >> But you are doing things that aren't guaranteed to work in the first > >> place. All the cache does is expand the window for breakage a bit. > > > > You're perfectly right. Smart web clients know the internet can shift > > under their feet and refresh files in case of problems instead of > > failing horribly on users (in the browser case you have a big refresh > > button for this reason). Though smart web designers know client > > refreshes are expensive and limit the refresh needs by avoiding to reuse > > the same filenames for different stuff. > > Getting a bit off the original topic here, but the "other" thing I've > always wished yum could do is "repeatable" updates. That is, the > ability to update one machine, test some things, then update another and > get only the same set of changes even if some newer packages had been > subsequently added to the repos. Currently I believe the only way to do > this is to mirror the entire set of repos in each state that you might > want to re-use. Perhaps some transactioning info could fix both things > at once. If a newer set of pkgs has been added to the repo you can specify the one you want to install using the complete ver-rel string. If the older packages are no longer available there's not much yum can do. You can pass around sets of specific things to do from machine to machine using a 'yum shell' script. -sv From rc040203 at freenet.de Thu Jan 24 18:11:46 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 24 Jan 2008 19:11:46 +0100 Subject: long term support release In-Reply-To: References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <20080123103336.6e24109f@redhat.com> <47976399.3010709@redhat.com> <47979470.6010507@leemhuis.info> <1201150608.17905.78.camel@beck.corsepiu.local> <20080124081720.GA2636@free.fr> <1201166022.17905.109.camel@beck.corsepiu.local> Message-ID: <1201198306.17905.117.camel@beck.corsepiu.local> On Thu, 2008-01-24 at 05:02 -0600, Mike McGrath wrote: > On Thu, 24 Jan 2008, Ralf Corsepius wrote: > > > > > On Thu, 2008-01-24 at 09:17 +0100, Patrice Dumas wrote: > > > On Thu, Jan 24, 2008 at 05:56:48AM +0100, Ralf Corsepius wrote: > > > > > > > > > RHEL/CentOS + EPEL as Fedora LTS, but for the world CentOS and Fedora > > > > > are totally different things. > > > > Right. CentOS is a different distro. It is not RHEL nor Fedora. > > > > It's the same difference as between Debian and its recompile called > > > > Ubuntu. > > > > > > There are more difference between ubuntu and debian than between > > > rhel and centos (and even more so in centos5/RHEL5 since yum is > > > everywhere now). > > Gotcha! RHEL and CentOS are different OSes. > > > > Any differences you find between RHEL and CentOS should be reported to the > CentOS guys. How can I? If I'd buy RHEL, I wouldn't want to use CentOS, if I were using CentOS I wouldn't want to use RHEL. In both cases, I probably would not want to use Fedora :/ Ralf From james.antill at redhat.com Thu Jan 24 20:44:04 2008 From: james.antill at redhat.com (James Antill) Date: Thu, 24 Jan 2008 15:44:04 -0500 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <4798F4EB.3030308@gmail.com> References: <479805C1.4080005@gmail.com> <797f919ef07923e0bf0802fcfd35a458@togami.com> <479824AA.3050108@gmail.com> <479843C5.7030800@redhat.com> <47989B23.80902@gmail.com> <4798A117.4000508@googlemail.com> <4798BD4B.6080609@gmail.com> <4798C936.3020802@redhat.com> <4798DDBF.2050209@gmail.com> <1201202640.10938.38.camel@rousalka.dyndns.org> <4798EBCA.7030704@gmail.com> <1201205066.10938.45.camel@rousalka.dyndns.org> <4798F4EB.3030308@gmail.com> Message-ID: <1201207444.10257.116.camel@code.and.org> On Thu, 2008-01-24 at 14:28 -0600, Les Mikesell wrote: > Getting a bit off the original topic here, but the "other" thing I've > always wished yum could do is "repeatable" updates. That is, the > ability to update one machine, test some things, then update another and > get only the same set of changes even if some newer packages had been > subsequently added to the repos. Currently I believe the only way to do > this is to mirror the entire set of repos in each state that you might > want to re-use. Perhaps some transactioning info could fix both things > at once. The data isn't there to make this possible, atm., in Fedora: % sqlite3 /var/cache/yum/updates/primary.sqlite > SELECT name,count(*) AS num FROM packages GROUP BY name,arch HAVING num > 1; > ...and the primary reason for that is the the metadata download size would explode, but we do have features like that we are looking at (for situations where the data is there). But again, asking on this mailing list is not the best method of getting new features or bug fixes. I'd also note that a bunch of the utilities in yum-utils make creating complete local mirrors at a specific point in time, easier than you might think. -- James Antill Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Thu Jan 24 20:43:31 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 24 Jan 2008 15:43:31 -0500 Subject: long term support release In-Reply-To: <1201198306.17905.117.camel@beck.corsepiu.local> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <20080123103336.6e24109f@redhat.com> <47976399.3010709@redhat.com> <47979470.6010507@leemhuis.info> <1201150608.17905.78.camel@beck.corsepiu.local> <20080124081720.GA2636@free.fr> <1201166022.17905.109.camel@beck.corsepiu.local> <1201198306.17905.117.camel@beck.corsepiu.local> Message-ID: <20080124154331.7959ee6d@redhat.com> On Thu, 24 Jan 2008 19:11:46 +0100 Ralf Corsepius wrote: > How can I? If I'd buy RHEL, I wouldn't want to use CentOS, if I were > using CentOS I wouldn't want to use RHEL. In both cases, I probably > would not want to use Fedora :/ Nice strawman. In a previous job I used A) RHEL for various mission critical systems where we wanted a Support contract. B) CentOS for less critical systems and development systems. C) Fedora on the desktops/laptops/etc... I wanted and used all three. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wtogami at redhat.com Thu Jan 24 20:51:28 2008 From: wtogami at redhat.com (Warren Togami) Date: Thu, 24 Jan 2008 15:51:28 -0500 Subject: InstantMirror needs a rethink In-Reply-To: References: <4797D5B3.7030002@redhat.com> Message-ID: <4798FA50.8010307@redhat.com> Ian Burrell wrote: > On Jan 23, 2008 4:02 PM, Warren Togami wrote: >> - Synchronization/locking of multiple connections downloading the same >> file is awkward and broken. > > I think a locking scheme on the files could solve this problem. The > normal file would always be the complete downloaded file. The first > downloading process would create the temp file and lock it. When it > finishes, it moves it to the real file and unlocks it. Any other > downloading processes see the locked temp file and wait for it to be > unlocked. An unlocked temp file indicates a download failure. > Waiters would have to start over if there was a failure. Things would > be more complicated if we want the waiters to stream the partial file > as it is downloaded. > >> - There is no good way to clean up aborted tmp files. >> - There is no good way to know what are old files that need pruning. >> - There is no good way of keeping track of the "Big Picture" of its own >> cache, "least recently used" knowing what files were unpopular locally >> and should be pruned. >> > > These could be solved with a cache cleaning script. The script would > remove aborted (ie unlocked) tmp files. The least-recently-used can > be determined with the atime of the files. > > An alternative is to store some metadata about the cached files in a > separate database. Berkeley DB or SQLite would work as would > per-directory or per-file data files. This would make the most sense > if the Etag and Last-Modified-Tiome need to be stored for the caching > to work correctly. It could also store the last-accessed-time. > Locking on the entries would be required and that would provide the > locking for simultaneous downloads. > > - Ian > These might be good ideas, and many of which were theorized in the InstantMirror wiki. If you want to continue InstantMirror development then please submit patches to hosted project. If they look sane maybe you can take over development. Warren From lesmikesell at gmail.com Thu Jan 24 21:07:47 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 24 Jan 2008 15:07:47 -0600 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <1201206640.8834.1.camel@cutter> References: <479805C1.4080005@gmail.com> <797f919ef07923e0bf0802fcfd35a458@togami.com> <479824AA.3050108@gmail.com> <479843C5.7030800@redhat.com> <47989B23.80902@gmail.com> <4798A117.4000508@googlemail.com> <4798BD4B.6080609@gmail.com> <4798C936.3020802@redhat.com> <4798DDBF.2050209@gmail.com> <1201202640.10938.38.camel@rousalka.dyndns.org> <4798EBCA.7030704@gmail.com> <1201205066.10938.45.camel@rousalka.dyndns.org> <4798F4EB.3030308@gmail.com> <1201206640.8834.1.camel@cutter> Message-ID: <4798FE23.4030302@gmail.com> seth vidal wrote: > > If a newer set of pkgs has been added to the repo you can specify the > one you want to install using the complete ver-rel string. I suppose there is some variation of rpm -qa .. that would build the whole installed list to reproduce. Is that a reasonable thing to pass to yum on the command line? -- Les Mikesell lesmikesell at gmail.com From benny+usenet at amorsen.dk Thu Jan 24 21:12:09 2008 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Thu, 24 Jan 2008 22:12:09 +0100 Subject: Yum, Proxy Cache Safety, Storage Backend References: <479805C1.4080005@gmail.com> <797f919ef07923e0bf0802fcfd35a458@togami.com> <479824AA.3050108@gmail.com> <479843C5.7030800@redhat.com> <47989B23.80902@gmail.com> <1201184950.10257.50.camel@code.and.org> <4798C1E8.4090701@gmail.com> <1201195241.10257.62.camel@code.and.org> <4798D3C5.9010203@gmail.com> <4798D389.4070406@redhat.com> Message-ID: Warren Togami writes: > If you already run your own site's proxy, why not run another proxy > but this one reverse in order to act as your site's Fedora mirror? > Then you can solve your yum mirrorlist problem TODAY. That doesn't solve the problem of getting the machines to pick that mirror by default, without having to configure each one. /Benny From wtogami at redhat.com Thu Jan 24 21:11:04 2008 From: wtogami at redhat.com (Warren Togami) Date: Thu, 24 Jan 2008 16:11:04 -0500 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: References: <479805C1.4080005@gmail.com> <797f919ef07923e0bf0802fcfd35a458@togami.com> <479824AA.3050108@gmail.com> <479843C5.7030800@redhat.com> <47989B23.80902@gmail.com> <1201184950.10257.50.camel@code.and.org> <4798C1E8.4090701@gmail.com> <1201195241.10257.62.camel@code.and.org> <4798D3C5.9010203@gmail.com> <4798D389.4070406@redhat.com> Message-ID: <4798FEE8.6020300@redhat.com> Benny Amorsen wrote: > Warren Togami writes: > >> If you already run your own site's proxy, why not run another proxy >> but this one reverse in order to act as your site's Fedora mirror? >> Then you can solve your yum mirrorlist problem TODAY. > > That doesn't solve the problem of getting the machines to pick that > mirror by default, without having to configure each one. > > > /Benny > > *SMACK* Warren From skvidal at fedoraproject.org Thu Jan 24 21:16:10 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 24 Jan 2008 16:16:10 -0500 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <4798FE23.4030302@gmail.com> References: <479805C1.4080005@gmail.com> <797f919ef07923e0bf0802fcfd35a458@togami.com> <479824AA.3050108@gmail.com> <479843C5.7030800@redhat.com> <47989B23.80902@gmail.com> <4798A117.4000508@googlemail.com> <4798BD4B.6080609@gmail.com> <4798C936.3020802@redhat.com> <4798DDBF.2050209@gmail.com> <1201202640.10938.38.camel@rousalka.dyndns.org> <4798EBCA.7030704@gmail.com> <1201205066.10938.45.camel@rousalka.dyndns.org> <4798F4EB.3030308@gmail.com> <1201206640.8834.1.camel@cutter> <4798FE23.4030302@gmail.com> Message-ID: <1201209370.8834.3.camel@cutter> On Thu, 2008-01-24 at 15:07 -0600, Les Mikesell wrote: > seth vidal wrote: > > > > If a newer set of pkgs has been added to the repo you can specify the > > one you want to install using the complete ver-rel string. > > I suppose there is some variation of rpm -qa .. that would build the > whole installed list to reproduce. Is that a reasonable thing to pass > to yum on the command line? > you can do that, yah. There are prettier ways - but that could work. -sv From bpepple at fedoraproject.org Thu Jan 24 21:31:08 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 24 Jan 2008 16:31:08 -0500 Subject: FESCo Meeting Summary for 2008-01-24 Message-ID: <1201210268.12943.3.camel@kennedy> = Members Present = * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Dennis Gilmore (dgilmore) * Bill Nottingham (notting) * Warren Togami (warren) * Kevin Fenzi (nirik) * Tom Callaway (spot) * Josh Boyer (jwb) * Jesse Keating (f13) * Christian Iseli (c4chris) = Absent = * Christopher Aillon (caillon) * David Woodhouse (dwmw2) * Jeremy Katz (jeremy) == Summary == === Bug Work-flow Proposal === * FESCo approved Jon Stanley's bug work-flow proposal, although with a change to item #7 in the life-cycle of a bug section. Instead of setting NEEDINFO in some cases, all bugs that are pushed to stable will be closed. Luke Macken will be removing the ability to not close a bug on stable push in bodhi. === FedoraBugs Group === * Long discussion on what to require, and who sponsors people to the fedorabugs group. For now, it was decided that cla_done would be required, and that Jon Stanley & John Poelstra will handle the sponsoring. Once the Fedora Account System2 is implemented this will be revisited, since most of this could be automated. === F9 Feature Process === * FESCo approved the following feature for F9: * http://fedoraproject.org/wiki/Features/Upstart * http://fedoraproject.org/wiki/Features/GCC4.3 IRC log can be found at: http://bpepple.fedorapeople.org/fesco/FESCo-2008-01-24.html Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From smooge at gmail.com Thu Jan 24 21:46:00 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 24 Jan 2008 14:46:00 -0700 Subject: long term support release In-Reply-To: <20080124154331.7959ee6d@redhat.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <20080123103336.6e24109f@redhat.com> <47976399.3010709@redhat.com> <47979470.6010507@leemhuis.info> <1201150608.17905.78.camel@beck.corsepiu.local> <20080124081720.GA2636@free.fr> <1201166022.17905.109.camel@beck.corsepiu.local> <1201198306.17905.117.camel@beck.corsepiu.local> <20080124154331.7959ee6d@redhat.com> Message-ID: <80d7e4090801241346n22b58638tbc2b854ff4ac4fa0@mail.gmail.com> 2008/1/24 Jesse Keating : > On Thu, 24 Jan 2008 19:11:46 +0100 > Ralf Corsepius wrote: > > > How can I? If I'd buy RHEL, I wouldn't want to use CentOS, if I were > > using CentOS I wouldn't want to use RHEL. In both cases, I probably > > would not want to use Fedora :/ > > Nice strawman. > > In a previous job I used > > A) RHEL for various mission critical systems where we wanted a Support > contract. > > B) CentOS for less critical systems and development systems. > > C) Fedora on the desktops/laptops/etc... > > I wanted and used all three. > Thats pretty much how I see it working in the various non-regimented Enterprises I work with. The regimented ones aren't able to use Fedora due to the fact that the internal checks for various standards took about 6 months to get done and were only good for the base release and no updates. However, I don't think that every business is an ISO9000/etc place where you have to have a process for making coffee. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From jspaleta at gmail.com Thu Jan 24 22:11:46 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 24 Jan 2008 13:11:46 -0900 Subject: long term support release In-Reply-To: <80d7e4090801241346n22b58638tbc2b854ff4ac4fa0@mail.gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <47976399.3010709@redhat.com> <47979470.6010507@leemhuis.info> <1201150608.17905.78.camel@beck.corsepiu.local> <20080124081720.GA2636@free.fr> <1201166022.17905.109.camel@beck.corsepiu.local> <1201198306.17905.117.camel@beck.corsepiu.local> <20080124154331.7959ee6d@redhat.com> <80d7e4090801241346n22b58638tbc2b854ff4ac4fa0@mail.gmail.com> Message-ID: <604aa7910801241411l394b33bah9e6063e115d671d3@mail.gmail.com> On Jan 24, 2008 12:46 PM, Stephen John Smoogen wrote: > ISO9000/etc place where you have to have a process for making coffee. Consistent coffee quality is absolutely critical !!!!!!!! -jef From smooge at gmail.com Thu Jan 24 22:24:27 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 24 Jan 2008 15:24:27 -0700 Subject: long term support release In-Reply-To: <604aa7910801241411l394b33bah9e6063e115d671d3@mail.gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <47979470.6010507@leemhuis.info> <1201150608.17905.78.camel@beck.corsepiu.local> <20080124081720.GA2636@free.fr> <1201166022.17905.109.camel@beck.corsepiu.local> <1201198306.17905.117.camel@beck.corsepiu.local> <20080124154331.7959ee6d@redhat.com> <80d7e4090801241346n22b58638tbc2b854ff4ac4fa0@mail.gmail.com> <604aa7910801241411l394b33bah9e6063e115d671d3@mail.gmail.com> Message-ID: <80d7e4090801241424j75977005q4d9409363fc928c3@mail.gmail.com> On Jan 24, 2008 3:11 PM, Jeff Spaleta wrote: > On Jan 24, 2008 12:46 PM, Stephen John Smoogen wrote: > > ISO9000/etc place where you have to have a process for making coffee. > > Consistent coffee quality is absolutely critical !!!!!!!! > It went through the usual: All employee processes must be documented.. and so someone wrote it up (probably as a joke though they wish it wasn't after it got accepted). It then became a safety issue as someone got burned due to someone not following the procedure.. etc etc etc. For organizations that do classified or various government contract work you have to have additional steps that basically took us 6 months to cover. [Which was actually why buying an RHEL contract 'saved' us money.. as the 'we can sue someone' and 'they have existing internal methods to cover this' meant we could shortcut Software Security, Safety regs down to 1-2 months.] -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From jmorris at namei.org Thu Jan 24 22:52:50 2008 From: jmorris at namei.org (James Morris) Date: Fri, 25 Jan 2008 09:52:50 +1100 (EST) Subject: selinux breaks revisor In-Reply-To: <4798A9DE.3060402@redhat.com> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <20080122095152.73f3fab5@redhat.com> <64b14b300801220742n10de35cbs587f419f5b000347@mail.gmail.com> <479626E2.1080607@redhat.com> <47963470.70009@gmail.com> <4798A9DE.3060402@redhat.com> Message-ID: On Thu, 24 Jan 2008, Daniel J Walsh wrote: > Virtual machines? Something to consider perhaps is the use of lguest, which is currently i386 only, but does boot up nearly instantaneously, and can be scripted, as its console is the launching shell. Is there an efficient technique for mounting a disk image so that changes made to it are discarded? - James -- James Morris From berrange at redhat.com Thu Jan 24 22:55:53 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 24 Jan 2008 22:55:53 +0000 Subject: selinux breaks revisor In-Reply-To: References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <20080122095152.73f3fab5@redhat.com> <64b14b300801220742n10de35cbs587f419f5b000347@mail.gmail.com> <479626E2.1080607@redhat.com> <47963470.70009@gmail.com> <4798A9DE.3060402@redhat.com> Message-ID: <20080124225553.GE13888@redhat.com> On Fri, Jan 25, 2008 at 09:52:50AM +1100, James Morris wrote: > On Thu, 24 Jan 2008, Daniel J Walsh wrote: > > > Virtual machines? > > Something to consider perhaps is the use of lguest, which is currently > i386 only, but does boot up nearly instantaneously, and can be scripted, > as its console is the launching shell. > > Is there an efficient technique for mounting a disk image so that changes > made to it are discarded? Sure, just create an LVM writable snapshot of your master image, and boot with that instead, and throw away the snapshot when you're done. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From jmorris at namei.org Thu Jan 24 23:17:05 2008 From: jmorris at namei.org (James Morris) Date: Fri, 25 Jan 2008 10:17:05 +1100 (EST) Subject: selinux breaks revisor In-Reply-To: <20080124225553.GE13888@redhat.com> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <20080122095152.73f3fab5@redhat.com> <64b14b300801220742n10de35cbs587f419f5b000347@mail.gmail.com> <479626E2.1080607@redhat.com> <47963470.70009@gmail.com> <4798A9DE.3060402@redhat.com> <20080124225553.GE13888@redhat.com> Message-ID: On Thu, 24 Jan 2008, Daniel P. Berrange wrote: > > Something to consider perhaps is the use of lguest, which is currently > > i386 only, but does boot up nearly instantaneously, and can be scripted, > > as its console is the launching shell. > > > > Is there an efficient technique for mounting a disk image so that changes > > made to it are discarded? > > Sure, just create an LVM writable snapshot of your master image, and boot > with that instead, and throw away the snapshot when you're done. Cool. So if there was a RPM package which contained a barebones Fedora image and some management scripts, I don't imagine it would be too difficult to do things like build RPMs inside that with e.g. different SELinux policies to the host. Any supporting RPMS required inside the guest could be installed via a script either from host media or over the net, then the final RPM (or whatever is being created) could be copied back out to the host before discarding the guest instance. It would not be as fast or simple as chroot, but I suspect it would work pretty well, especially if the guest dispenses with all non-essential startup. - James -- James Morris From chasd at silveroaks.com Thu Jan 24 23:17:36 2008 From: chasd at silveroaks.com (chasd) Date: Thu, 24 Jan 2008 17:17:36 -0600 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <20080124214629.C8E7F73511@hormel.redhat.com> References: <20080124214629.C8E7F73511@hormel.redhat.com> Message-ID: <6CEA40CA-D5A6-46CE-8BF8-54165CAB3AD7@silveroaks.com> Les Mikesell wrote: > Getting a bit off the original topic here, but the "other" thing I've > always wished yum could do is "repeatable" updates. That is, the > ability to update one machine, test some things, then update > another and > get only the same set of changes even if some newer packages had > been > subsequently added to the repos. To me, that isn't functionality for the client, it is functionality for the server / cache. It is a feature of WSUS - the ability to approve updates and only allow clients to "see" the approved ones and not any other. Right now, there isn't a lot of intelligence built into the server end ( MirrorManager excepted ) of the update process. The repositories serve static files, that's it. Fedora can't ask any more from mirrors. If in your environment you want to control how clients get updated, then it makes sense to me that centralized control from the server side and keeping the client side "dumb" is better. You only have to distribute the repo configuration to use the controlled repo once, instead of distributing specific update lists continually. That control is one of the reasons why as an admin I am interested in InstantMirror and this discussion. Charles Dostale From berrange at redhat.com Thu Jan 24 23:24:17 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 24 Jan 2008 23:24:17 +0000 Subject: selinux breaks revisor In-Reply-To: References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <20080122095152.73f3fab5@redhat.com> <64b14b300801220742n10de35cbs587f419f5b000347@mail.gmail.com> <479626E2.1080607@redhat.com> <47963470.70009@gmail.com> <4798A9DE.3060402@redhat.com> <20080124225553.GE13888@redhat.com> Message-ID: <20080124232417.GF13888@redhat.com> On Fri, Jan 25, 2008 at 10:17:05AM +1100, James Morris wrote: > On Thu, 24 Jan 2008, Daniel P. Berrange wrote: > > > > Something to consider perhaps is the use of lguest, which is currently > > > i386 only, but does boot up nearly instantaneously, and can be scripted, > > > as its console is the launching shell. > > > > > > Is there an efficient technique for mounting a disk image so that changes > > > made to it are discarded? > > > > Sure, just create an LVM writable snapshot of your master image, and boot > > with that instead, and throw away the snapshot when you're done. > > Cool. So if there was a RPM package which contained a barebones Fedora > image and some management scripts, I don't imagine it would be too > difficult to do things like build RPMs inside that with e.g. different > SELinux policies to the host. Any supporting RPMS required inside the > guest could be installed via a script either from host media or over the > net, then the final RPM (or whatever is being created) could be copied > back out to the host before discarding the guest instance. > > It would not be as fast or simple as chroot, but I suspect it would work > pretty well, especially if the guest dispenses with all non-essential > startup. Actually you can do some tricks here too. You can boot the guest using the real disk image. Once it is up & running in desired state you can save the VM to disk (cf hibernate). Launching it just becomes a case of taking a snapshot of the disk, and restoring the VM state file. Much much quicker than normal startup - a matter of seconds - depending on guest RAM size. As long as you take care to always restore it against a snapshot of the disk from the same it was saved, you can repeat this restore process many times over. It is not entirely straightforward to do these steps in the general case, but if you want to mandate LVM storage only then it is a tractable problem Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From jan.kratochvil at redhat.com Thu Jan 24 23:32:58 2008 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Fri, 25 Jan 2008 00:32:58 +0100 Subject: Why does gdb now give lots of warnings? In-Reply-To: <4c4ba1530801041045y59d47210t63192b2e20f05b11@mail.gmail.com> <1199471227.23051.12.camel@code.and.org> References: <18302.18459.463805.56859@zebedee.pink> <20080104154915.GA28635@jadzia.bu.edu> <20080104105720.1f78b9dc@redhat.com> <20080104161201.GA17915@host0.dyn.jankratochvil.net> <18302.23710.710664.220708@zebedee.pink> <20080104164739.GA18173@host0.dyn.jankratochvil.net> <18302.25717.629111.664840@zebedee.pink> <20080104170807.GA19073@host0.dyn.jankratochvil.net> <18302.27028.83536.638113@zebedee.pink> <1199471227.23051.12.camel@code.and.org> Message-ID: <20080124233258.GA29188@host0.dyn.jankratochvil.net> Hi, the original problem: On Fri, 04 Jan 2008 15:44:12 +0100, Neal Becker wrote: > Here is an example: > > Starting program: /usr/bin/python > > warning: Missing the separate debug info file: /usr/lib/debug/.build-id/fa/841219472d35412ad631ad0f0fabb78e5c1957.debug > > warning: Missing the separate debug info file: /usr/lib/debug/.build-id/e8/abaa654dc4b17b75c06c866898a17ea06f2bcf.debug > [Thread debugging using libthread_db enabled] > [New process 16964] Sorry for the delay, it is now hopefully improved in updates-testing: Fedora 8: gdb-6.6-42.fc8 http://koji.fedoraproject.org/koji/buildinfo?buildID=32829 https://admin.fedoraproject.org/updates/F8/pending/gdb-6.6-42.fc8 Rawhide: gdb-6.7.1-11.fc9 http://koji.fedoraproject.org/koji/buildinfo?buildID=32798 On Fri, 04 Jan 2008 19:27:07 +0100, James Antill wrote: > On Fri, 2008-01-04 at 17:15 +0000, Andrew Haley wrote: ... > > Perfection would be: > > > > Missing debuginfo for /lib64/libnss_files-2.7.so > > Try "yum install /usr/lib/debug/.build-id/72/67a2ecd318b0f87a0747a6986d0d6dc01c6d8d.debug" It now prints: Missing separate debuginfo for /usr/lib64/libX11.so.6 Try: yum --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/5c/a8a05c48617a1c4a32acda9f5651f78b4fe005 (more cut-n-paste friendly) > > If we can't do that upstream, then the closer we get, the better. Or > > we have a local patch. Yes, it will have to be split now into two parts, upstream one + a distro one. > Well what we really want here is: > > Try "debuginfo-install glibc" (or "debuginfo-install python" if they > are running gdb on that), If some installed rpm matches the file it now prints the message: Getting all the debuginfos: debuginfo-install xorg-x11-apps (If the rpm database is locked it just prints a warning without waiting on it.) On Fri, 04 Jan 2008 19:45:04 +0100, Tom London wrote: ... > I tried 'debuginfo-install rhythmbox' and got a list of 43 packages..... cool. > > However, it looks like it wants to install 3 'real' packages: This problem was submitted as: https://bugzilla.redhat.com/show_bug.cgi?id=427579 Regards, Jan From mcepl at redhat.com Thu Jan 24 23:41:43 2008 From: mcepl at redhat.com (Matej Cepl) Date: Fri, 25 Jan 2008 00:41:43 +0100 Subject: long term support release References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <20080123103336.6e24109f@redhat.com> <47976399.3010709@redhat.com> <47979470.6010507@leemhuis.info> <1201150608.17905.78.camel@beck.corsepiu.local> <20080124081720.GA2636@free.fr> <1201166022.17905.109.camel@beck.corsepiu.local> <1201198306.17905.117.camel@beck.corsepiu.local> Message-ID: On 2008-01-24, 18:11 GMT, Ralf Corsepius wrote: > How can I? If I'd buy RHEL, I wouldn't want to use CentOS, if > I were using CentOS I wouldn't want to use RHEL. It might be your case, but there are many RH customers who have RHEL for some mission-critical applications (or for the software, where they need supported platform -- ehm, ehm, Oracle), but rest of their server needs are covered by CentOS. Mat?j From jkeating at redhat.com Thu Jan 24 23:57:32 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 24 Jan 2008 18:57:32 -0500 Subject: selinux breaks revisor In-Reply-To: <20080124232417.GF13888@redhat.com> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <20080122095152.73f3fab5@redhat.com> <64b14b300801220742n10de35cbs587f419f5b000347@mail.gmail.com> <479626E2.1080607@redhat.com> <47963470.70009@gmail.com> <4798A9DE.3060402@redhat.com> <20080124225553.GE13888@redhat.com> <20080124232417.GF13888@redhat.com> Message-ID: <20080124185732.06966542@redhat.com> On Thu, 24 Jan 2008 23:24:17 +0000 "Daniel P. Berrange" wrote: > On Fri, Jan 25, 2008 at 10:17:05AM +1100, James Morris wrote: > > On Thu, 24 Jan 2008, Daniel P. Berrange wrote: > > > > > > Something to consider perhaps is the use of lguest, which is > > > > currently i386 only, but does boot up nearly instantaneously, > > > > and can be scripted, as its console is the launching shell. > > > > > > > > Is there an efficient technique for mounting a disk image so > > > > that changes made to it are discarded? > > > > > > Sure, just create an LVM writable snapshot of your master image, > > > and boot with that instead, and throw away the snapshot when > > > you're done. > > > > Cool. So if there was a RPM package which contained a barebones > > Fedora image and some management scripts, I don't imagine it would > > be too difficult to do things like build RPMs inside that with e.g. > > different SELinux policies to the host. Any supporting RPMS > > required inside the guest could be installed via a script either > > from host media or over the net, then the final RPM (or whatever is > > being created) could be copied back out to the host before > > discarding the guest instance. > > > > It would not be as fast or simple as chroot, but I suspect it would > > work pretty well, especially if the guest dispenses with all > > non-essential startup. > > Actually you can do some tricks here too. You can boot the guest using > the real disk image. Once it is up & running in desired state you can > save the VM to disk (cf hibernate). Launching it just becomes a case > of taking a snapshot of the disk, and restoring the VM state file. > Much much quicker than normal startup - a matter of seconds - > depending on guest RAM size. As long as you take care to always > restore it against a snapshot of the disk from the same it was saved, > you can repeat this restore process many times over. It is not > entirely straightforward to do these steps in the general case, but > if you want to mandate LVM storage only then it is a tractable problem > > Dan. Yeah, it all sounds pretty exciting, but get back to me when it works on x86_64, ppc, ppc64, ia64, s390, s390x, sparc, sparc64, arm, alpha... -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lordmorgul at gmail.com Fri Jan 25 00:05:06 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Thu, 24 Jan 2008 16:05:06 -0800 Subject: RFE: prevent broken rawhide network install due to repo change In-Reply-To: <200801241402.46682.opensource@till.name> References: <47981466.2030603@gmail.com> <200801241402.46682.opensource@till.name> Message-ID: <479927B2.504@gmail.com> Till Maas wrote: > On Thu January 24 2008, Andrew Farris wrote: >> RFE: prevent broken rawhide network install due to repo change >> >> Problem: network installs will currently fail if the repository changes >> during the installation, which can take 2-4 hours or more, and changed >> files are removed from the repo, making anaconda fail to download the >> expected version of that changed file > >> I'd be happy to move this suggestion to where it belongs (bugzilla against >> ?) > > Imho this is something that can be improved in anacanda, e.g. make it use > another mirror in case an rpm is missinga and in case an rpm is missing, it > could update its metadata and recalculate which new rpms could be used to > finish the installation, or it could first download every rpm and then > install them. When anaconda supports adding repositories with updates, this > problem could also occur for normal installs. > > Regards, > Till > I think the problem really needs to be fixed BOTH in the mirror system and in anaconda. If someone were to attempt to get a single snapshot of a self-consistent repo, and happened to rsync during the mirror updating his repo would be inconsistent with itself. There is really no need for this to happen, since the only detriment to holding the obsolete files is diskspace (and time for infrastructure to develop the changes). Since every file is requested directly by name there should be no conflicts caused by a different version of some of the rpms to be there. The only conflict would occur if a file were replaced with the same name... something that should never happen anyway. The problem for anaconda is, I doubt its a trivial adjustment to make (yes I agree it would be a good thing though). Since anaconda is supposed to be able to handle external repos soon, its crucial that it is able to deal with the repo changing during install... it seems like it would need to: - try to fetch the file multiple times, try multiple mirrors if possible - realize the file is no longer available - remember what is already been installed, and what was supposed to be installed - refetch the repodata - depsolve, noting the files already installed which now need to be updated (any that changed since installed) - build new install list, keep going I suggested the changes to repository handling because that sounds non-trivial at best to get implemented into anaconda soonish. Essentially the problem is circumvented by just not deleting files from the repo so fast, at the cost of diskspace. -- Andrew Farris gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From billcrawford1970 at gmail.com Fri Jan 25 00:12:37 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Fri, 25 Jan 2008 00:12:37 +0000 Subject: Replacing the boot kernel in the installer In-Reply-To: <47973C08.2090807@gmail.com> References: <544eb990801230424q79f27bek99ccd6905c645f6@mail.gmail.com> <20080123063932.32f77328@zod.rchland.ibm.com> <544eb990801230446h7c83b021me8db4c6e82171991@mail.gmail.com> <47973C08.2090807@gmail.com> Message-ID: <544eb990801241612y4892a4edwd927ca260e542b57@mail.gmail.com> On 23/01/2008, David Boles wrote: > You don't have to. The Fedora Unity respins are jigdo. They take the > packages from your original Fedora 8 DVD that have not changed, download > the updates, and then makes you a new iso with those combined. Then you > burn your new DVD. That was the point, I didn't have a DVD, and wanted to do a minimal base install, then add the updates repo, and yum groupinstall the desktop and development tools (much less to download than the full DVD). > You only download the updates. Which you would have to do after the > install anyway. On the plus side, I had Everything plus the updates mirrored at home, so I did the jigdo dance last night and created an image. All bar 71 packages were found, I take it the others are superceded by newer updates ... Now, when I came to burn the DVD tonight, I had great fun. k3b (and by implication growisofs) have terrible trouble finishing a burn, and when they do it's quite slow. On the other hand xcdroast managed to burn the whole thing at 4x ... Thanks for the help guys, I have all I need now. Shame I couldn't get the boot disk to work :-) From dmc.fedora at filteredperception.org Fri Jan 25 00:18:26 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Thu, 24 Jan 2008 18:18:26 -0600 Subject: selinux breaks revisor In-Reply-To: <20080124185732.06966542@redhat.com> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <20080122095152.73f3fab5@redhat.com> <64b14b300801220742n10de35cbs587f419f5b000347@mail.gmail.com> <479626E2.1080607@redhat.com> <47963470.70009@gmail.com> <4798A9DE.3060402@redhat.com> <20080124225553.GE13888@redhat.com> <20080124232417.GF13888@redhat.com> <20080124185732.06966542@redhat.com> Message-ID: <47992AD2.7080904@filteredperception.org> Jesse Keating wrote: > On Thu, 24 Jan 2008 23:24:17 +0000 > "Daniel P. Berrange" wrote: > >> On Fri, Jan 25, 2008 at 10:17:05AM +1100, James Morris wrote: >>> On Thu, 24 Jan 2008, Daniel P. Berrange wrote: >>> >>>>> Something to consider perhaps is the use of lguest, which is >>>>> currently i386 only, but does boot up nearly instantaneously, >>>>> and can be scripted, as its console is the launching shell. >>>>> >>>>> Is there an efficient technique for mounting a disk image so >>>>> that changes made to it are discarded? >>>> Sure, just create an LVM writable snapshot of your master image, >>>> and boot with that instead, and throw away the snapshot when >>>> you're done. >>> Cool. So if there was a RPM package which contained a barebones >>> Fedora image and some management scripts, I don't imagine it would >>> be too difficult to do things like build RPMs inside that with e.g. >>> different SELinux policies to the host. Any supporting RPMS >>> required inside the guest could be installed via a script either >>> from host media or over the net, then the final RPM (or whatever is >>> being created) could be copied back out to the host before >>> discarding the guest instance. >>> >>> It would not be as fast or simple as chroot, but I suspect it would >>> work pretty well, especially if the guest dispenses with all >>> non-essential startup. >> Actually you can do some tricks here too. You can boot the guest using >> the real disk image. Once it is up & running in desired state you can >> save the VM to disk (cf hibernate). Launching it just becomes a case >> of taking a snapshot of the disk, and restoring the VM state file. >> Much much quicker than normal startup - a matter of seconds - >> depending on guest RAM size. As long as you take care to always >> restore it against a snapshot of the disk from the same it was saved, >> you can repeat this restore process many times over. It is not >> entirely straightforward to do these steps in the general case, but >> if you want to mandate LVM storage only then it is a tractable problem >> >> Dan. > > > Yeah, it all sounds pretty exciting, but get back to me when it works > on x86_64, ppc, ppc64, ia64, s390, s390x, sparc, sparc64, arm, alpha... > *cough* viros *cough* smirfgen *cough* qfakeroot No, doesn't work on those archs, by since all the infra is qemu, it may well get there in the foreseeable future. Basically smirfgen is my version of mkinitrd/mayflower, but in addition to generating initramfss that boot livecds, it generates ones which do nothing but set up sandbox so that qfakeroot can boot them up via qemu attached to one disk image used for input, one used for output (gets detarred), and one for scratch space, and one to optionally connect to a real disk device or image. There is also an option to automatically make that last one get a devicemapper snapshot layer of protection (same thing as the lvm described, but at a lower more generic layer). And qemu gets used in nographic with console going to tty which goes to stdout (redirected internally). The result is that it takes about a couple minutes to convert an arbitrary tarball to an ext3 filesystem image. (longer for bigger input) Currently it pulls in a copy of the host's selinux policy to use, though it is pretty trivial to make that an option to disable, or pull in an arbitrary selinux policy. Still very alpha, but maybe interesting to consider http://viros.org -dmc From jkeating at redhat.com Fri Jan 25 00:47:26 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 24 Jan 2008 19:47:26 -0500 Subject: selinux breaks revisor In-Reply-To: <47992AD2.7080904@filteredperception.org> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <20080122095152.73f3fab5@redhat.com> <64b14b300801220742n10de35cbs587f419f5b000347@mail.gmail.com> <479626E2.1080607@redhat.com> <47963470.70009@gmail.com> <4798A9DE.3060402@redhat.com> <20080124225553.GE13888@redhat.com> <20080124232417.GF13888@redhat.com> <20080124185732.06966542@redhat.com> <47992AD2.7080904@filteredperception.org> Message-ID: <20080124194726.22891018@redhat.com> On Thu, 24 Jan 2008 18:18:26 -0600 Douglas McClendon wrote: > *cough* viros *cough* smirfgen *cough* qfakeroot > > No, doesn't work on those archs, by since all the infra is qemu, it > may well get there in the foreseeable future. I've been waiting for qemu to work on ppc, the simple case right? Still waiting... -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dmc.fedora at filteredperception.org Fri Jan 25 00:47:56 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Thu, 24 Jan 2008 18:47:56 -0600 Subject: selinux breaks revisor In-Reply-To: <20080124194726.22891018@redhat.com> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <20080122095152.73f3fab5@redhat.com> <64b14b300801220742n10de35cbs587f419f5b000347@mail.gmail.com> <479626E2.1080607@redhat.com> <47963470.70009@gmail.com> <4798A9DE.3060402@redhat.com> <20080124225553.GE13888@redhat.com> <20080124232417.GF13888@redhat.com> <20080124185732.06966542@redhat.com> <47992AD2.7080904@filteredperception.org> <20080124194726.22891018@redhat.com> Message-ID: <479931BC.7000605@filteredperception.org> Jesse Keating wrote: > On Thu, 24 Jan 2008 18:18:26 -0600 > Douglas McClendon wrote: > >> *cough* viros *cough* smirfgen *cough* qfakeroot >> >> No, doesn't work on those archs, by since all the infra is qemu, it >> may well get there in the foreseeable future. > > I've been waiting for qemu to work on ppc, the simple case right? > Still waiting... ??? http://fabrice.bellard.free.fr/qemu/status.html -dmc From berrange at redhat.com Fri Jan 25 00:56:37 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 25 Jan 2008 00:56:37 +0000 Subject: selinux breaks revisor In-Reply-To: <47992AD2.7080904@filteredperception.org> References: <64b14b300801220742n10de35cbs587f419f5b000347@mail.gmail.com> <479626E2.1080607@redhat.com> <47963470.70009@gmail.com> <4798A9DE.3060402@redhat.com> <20080124225553.GE13888@redhat.com> <20080124232417.GF13888@redhat.com> <20080124185732.06966542@redhat.com> <47992AD2.7080904@filteredperception.org> Message-ID: <20080125005637.GK13888@redhat.com> On Thu, Jan 24, 2008 at 06:18:26PM -0600, Douglas McClendon wrote: > Jesse Keating wrote: > >On Thu, 24 Jan 2008 23:24:17 +0000 > >"Daniel P. Berrange" wrote: > > > >>On Fri, Jan 25, 2008 at 10:17:05AM +1100, James Morris wrote: > >>>On Thu, 24 Jan 2008, Daniel P. Berrange wrote: > >>> > >>>>>Something to consider perhaps is the use of lguest, which is > >>>>>currently i386 only, but does boot up nearly instantaneously, > >>>>>and can be scripted, as its console is the launching shell. > >>>>> > >>>>>Is there an efficient technique for mounting a disk image so > >>>>>that changes made to it are discarded? > >>>>Sure, just create an LVM writable snapshot of your master image, > >>>>and boot with that instead, and throw away the snapshot when > >>>>you're done. > >>>Cool. So if there was a RPM package which contained a barebones > >>>Fedora image and some management scripts, I don't imagine it would > >>>be too difficult to do things like build RPMs inside that with e.g. > >>>different SELinux policies to the host. Any supporting RPMS > >>>required inside the guest could be installed via a script either > >>>from host media or over the net, then the final RPM (or whatever is > >>>being created) could be copied back out to the host before > >>>discarding the guest instance. > >>> > >>>It would not be as fast or simple as chroot, but I suspect it would > >>>work pretty well, especially if the guest dispenses with all > >>>non-essential startup. > >>Actually you can do some tricks here too. You can boot the guest using > >>the real disk image. Once it is up & running in desired state you can > >>save the VM to disk (cf hibernate). Launching it just becomes a case > >>of taking a snapshot of the disk, and restoring the VM state file. > >>Much much quicker than normal startup - a matter of seconds - > >>depending on guest RAM size. As long as you take care to always > >>restore it against a snapshot of the disk from the same it was saved, > >>you can repeat this restore process many times over. It is not > >>entirely straightforward to do these steps in the general case, but > >>if you want to mandate LVM storage only then it is a tractable problem > >> > >>Dan. > > > > > >Yeah, it all sounds pretty exciting, but get back to me when it works > >on x86_64, ppc, ppc64, ia64, s390, s390x, sparc, sparc64, arm, alpha... > > > > *cough* viros *cough* smirfgen *cough* qfakeroot > > No, doesn't work on those archs, by since all the infra is qemu, it may > well get there in the foreseeable future. Plain QEMU is unusably slow for doing any real work - particularly compute and disk intensive stuff like builds / composes. You need KVM for it to be viable, which restricts you to i686 / x86_64 currently, and possibly adding ia64 & ppc64 in the medium-term future. No work on sparc/arm, and no clue about s390. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From dmc.fedora at filteredperception.org Fri Jan 25 00:59:47 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Thu, 24 Jan 2008 18:59:47 -0600 Subject: selinux breaks revisor In-Reply-To: <20080125005637.GK13888@redhat.com> References: <64b14b300801220742n10de35cbs587f419f5b000347@mail.gmail.com> <479626E2.1080607@redhat.com> <47963470.70009@gmail.com> <4798A9DE.3060402@redhat.com> <20080124225553.GE13888@redhat.com> <20080124232417.GF13888@redhat.com> <20080124185732.06966542@redhat.com> <47992AD2.7080904@filteredperception.org> <20080125005637.GK13888@redhat.com> Message-ID: <47993483.70804@filteredperception.org> Daniel P. Berrange wrote: > > Plain QEMU is unusably slow for doing any real work - particularly compute > and disk intensive stuff like builds / composes. Takes 12 hours to compose my 1G LiveDVD, involving a full anaconda http install under qemu, followed by mksquashfs of the result. Honestly I do a lot of data shuffling, and think that I could probably halve that time if I wasn't more interested in further functionality at the moment than I am in performance. I'll take that 12 hours over the 1hr for livecd-creator any day of the week, knowing that I'm not running about 1000 rpm post install scripts under the limited protection of a chroot with selinux disabled. Combined with the comfort of knowing that if I do a compose on a different piece of hardware, that those 1000 scripts will have no chance to sneakily incur any host build dependencies based on their access to a random /proc (as opposed to the consistency of always identical qemu /proc). You may call 12 hours for a compose unusably slow. I don't. And computers and software get improved all the time, so maybe in 3 years, that 12 hours will just become "order a pizza and wait for the results". works for me. $0.02 -dmc You need KVM for it to be > viable, which restricts you to i686 / x86_64 currently, and possibly adding > ia64 & ppc64 in the medium-term future. No work on sparc/arm, and no clue > about s390. > > Dan. From jkeating at redhat.com Fri Jan 25 01:02:57 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 24 Jan 2008 20:02:57 -0500 Subject: selinux breaks revisor In-Reply-To: <479931BC.7000605@filteredperception.org> References: <64b14b300801220429p36da4b42m91ce82a2c7dfac88@mail.gmail.com> <20080122095152.73f3fab5@redhat.com> <64b14b300801220742n10de35cbs587f419f5b000347@mail.gmail.com> <479626E2.1080607@redhat.com> <47963470.70009@gmail.com> <4798A9DE.3060402@redhat.com> <20080124225553.GE13888@redhat.com> <20080124232417.GF13888@redhat.com> <20080124185732.06966542@redhat.com> <47992AD2.7080904@filteredperception.org> <20080124194726.22891018@redhat.com> <479931BC.7000605@filteredperception.org> Message-ID: <20080124200257.1074fcd4@redhat.com> On Thu, 24 Jan 2008 18:47:56 -0600 Douglas McClendon wrote: > ??? > > http://fabrice.bellard.free.fr/qemu/status.html You can't boot an OS in it, you can only run some binaries in it. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Jan 25 01:06:24 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 24 Jan 2008 20:06:24 -0500 Subject: selinux breaks revisor In-Reply-To: <47993483.70804@filteredperception.org> References: <64b14b300801220742n10de35cbs587f419f5b000347@mail.gmail.com> <479626E2.1080607@redhat.com> <47963470.70009@gmail.com> <4798A9DE.3060402@redhat.com> <20080124225553.GE13888@redhat.com> <20080124232417.GF13888@redhat.com> <20080124185732.06966542@redhat.com> <47992AD2.7080904@filteredperception.org> <20080125005637.GK13888@redhat.com> <47993483.70804@filteredperception.org> Message-ID: <20080124200624.532ce1e7@redhat.com> On Thu, 24 Jan 2008 18:59:47 -0600 Douglas McClendon wrote: > I'll take that 12 hours over the 1hr for livecd-creator any day of > the week, knowing that I'm not running about 1000 rpm post install > scripts under the limited protection of a chroot with selinux > disabled. Combined with the comfort of knowing that if I do a compose > on a different piece of hardware, that those 1000 scripts will have > no chance to sneakily incur any host build dependencies based on > their access to a random /proc (as opposed to the consistency of > always identical qemu /proc). > > You may call 12 hours for a compose unusably slow. I don't. And > computers and software get improved all the time, so maybe in 3 > years, that 12 hours will just become "order a pizza and wait for the > results". Eh, if we really wanted to do this, we'd just re-kickstart the builder each time we wanted to do a build, and then just do the build in the freshly kickstart install, removing it when done. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From berrange at redhat.com Fri Jan 25 01:30:52 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 25 Jan 2008 01:30:52 +0000 Subject: selinux breaks revisor In-Reply-To: <47993483.70804@filteredperception.org> References: <47963470.70009@gmail.com> <4798A9DE.3060402@redhat.com> <20080124225553.GE13888@redhat.com> <20080124232417.GF13888@redhat.com> <20080124185732.06966542@redhat.com> <47992AD2.7080904@filteredperception.org> <20080125005637.GK13888@redhat.com> <47993483.70804@filteredperception.org> Message-ID: <20080125013052.GL13888@redhat.com> On Thu, Jan 24, 2008 at 06:59:47PM -0600, Douglas McClendon wrote: > Daniel P. Berrange wrote: > > > > >Plain QEMU is unusably slow for doing any real work - particularly compute > >and disk intensive stuff like builds / composes. > > Takes 12 hours to compose my 1G LiveDVD, involving a full anaconda http > install under qemu, followed by mksquashfs of the result. Honestly I do > a lot of data shuffling, and think that I could probably halve that time > if I wasn't more interested in further functionality at the moment than > I am in performance. A 12 hour compose time fundmanetally limits the quality / speedy delivery of LiveCDs because the turn around time between compose + QA cycles is being bottlenecked. You can only do one compose & QA cycle per day. If a chroot install takes < 1 hour you can get through 5 or more compose & QA cycles a day. > I'll take that 12 hours over the 1hr for livecd-creator any day of the > week, knowing that I'm not running about 1000 rpm post install scripts > under the limited protection of a chroot with selinux disabled. > Combined with the comfort of knowing that if I do a compose on a > different piece of hardware, that those 1000 scripts will have no chance > to sneakily incur any host build dependencies based on their access to a > random /proc (as opposed to the consistency of always identical qemu /proc). Do you inspect all these %post scripts ahead of time each time you do a 'yum update' for your host machine. Every time you yum update you're running the same scripts in your host without even the chroot protection. And if you don't trust the RPMs you're using to build the LiveCD images, why should any user trust the resulting LiveCD you're about to distribute. If you really don't trust the RPMs you're about to compose, then run the compose on a throw away host - just re-kickstart it after execution. > You may call 12 hours for a compose unusably slow. I don't. And > computers and software get improved all the time, so maybe in 3 years, > that 12 hours will just become "order a pizza and wait for the results". That's a fallacy. History shows that software increases its resource requirements to easily match increases in hardware speed. Compare total install time between RHL 5 and Fedora 8 - hardware has increased in performance dramatically, but install time is still effectivelly unchanged. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From jonathan.underwood at gmail.com Fri Jan 25 01:47:34 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 25 Jan 2008 01:47:34 +0000 Subject: koji problem? Message-ID: <645d17210801241747u634e8965u101ed0a67657e414@mail.gmail.com> Hi, I got this python backtrace this evening when doing a cvs commit - it all seemed to work ok, but thought I should mention it. $ cvs commit cvs commit: Examining . ? noarch ? emacs-common-ebib-1.5.2-2.fc9.src.rpm ? ebib-1.5.2-info-fix.patch ? ebib-1.5.2 ? clog ? .build-1.5.2-2.fc9.log **** Access allowed: jgu is in ACL for rpms/emacs-common-ebib/devel. Checking in emacs-common-ebib.spec; /cvs/extras/rpms/emacs-common-ebib/devel/emacs-common-ebib.spec,v <-- emacs-common-ebib.spec new revision: 1.3; previous revision: 1.2 done Traceback (most recent call last): File "/cvs/extras/CVSROOT/getnotifylist", line 70, in ? pkgPage = urllib2.urlopen(PKGDBURL + '/' + package + '?tg_format=json') File "/usr/lib64/python2.3/urllib2.py", line 129, in urlopen return _opener.open(url, data) File "/usr/lib64/python2.3/urllib2.py", line 326, in open '_open', req) File "/usr/lib64/python2.3/urllib2.py", line 306, in _call_chain result = func(*args) File "/usr/lib64/python2.3/urllib2.py", line 908, in https_open return self.do_open(httplib.HTTPS, req) File "/usr/lib64/python2.3/urllib2.py", line 895, in do_open return self.parent.error('http', req, fp, code, msg, hdrs) File "/usr/lib64/python2.3/urllib2.py", line 352, in error return self._call_chain(*args) File "/usr/lib64/python2.3/urllib2.py", line 306, in _call_chain result = func(*args) File "/usr/lib64/python2.3/urllib2.py", line 412, in http_error_default raise HTTPError(req.get_full_url(), code, msg, hdrs, fp) urllib2.HTTPError: HTTP Error 500: Internal error Running syncmail... Mailing cvsextras at fedora.redhat.com ... ...syncmail done. cvs diff: [01:44:53] waiting for jgu's lock in /cvs/extras/rpms/emacs-common-ebib/devel Running syncmail... Mailing relnotes at fedoraproject.org... ...syncmail done. cvs diff: [01:45:23] obtained lock in /cvs/extras/rpms/emacs-common-ebib/devel From bnocera at redhat.com Fri Jan 25 01:49:10 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Fri, 25 Jan 2008 01:49:10 +0000 Subject: Opinion: Preferred Applications & Removable Drives and Media In-Reply-To: <6e24a8e80801221649h2602ad0cjcc7a1c9e22ceb24c@mail.gmail.com> References: <6e24a8e80801191428m45ecd472w788c4a88055f0455@mail.gmail.com> <1200785912.2924.14.camel@localhost.localdomain> <6e24a8e80801200641m64febab5v5f1bbc1fa1977e19@mail.gmail.com> <6e24a8e80801221526y4caac2c5g3522773b5dfb7ca5@mail.gmail.com> <1201045549.2858.4.camel@localhost.localdomain> <6e24a8e80801221638v11b6a247wd6fc60d5feefb8a7@mail.gmail.com> <6e24a8e80801221649h2602ad0cjcc7a1c9e22ceb24c@mail.gmail.com> Message-ID: <1201225750.2389.4.camel@cookie.hadess.net> On Wed, 2008-01-23 at 01:49 +0100, Mark wrote: > > But thanx for the help. now i know what i have to do. > > Hmm.. just a minor issue. > I've just updated totem and now i can choose that a few times in the > media list as well (including dvd video) but i don't see a option > there to run a command. Isn't it handy to have that option there if > none of the other options suit you? Not really. If there are particular applications that you'd like to see listed (say, you wanted Thoggen or OGMRip to be launched instead of Totem when inserting a video DVD), then file a bug against the package or the upstream program. Entering commands by hand is for geeks. > Or what else do i have to do to get another application to show up in that list? > and is this conforming a standard from freedesktop? if so: which one? Only GNOME programs implement this right now, but all the Fedora GUI applications should be using this, just like they all have .desktop files, so say KDE apps can be integrated into Nautilus as well as GNOME apps. From jonathan.underwood at gmail.com Fri Jan 25 01:53:43 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 25 Jan 2008 01:53:43 +0000 Subject: koji problem? In-Reply-To: <645d17210801241747u634e8965u101ed0a67657e414@mail.gmail.com> References: <645d17210801241747u634e8965u101ed0a67657e414@mail.gmail.com> Message-ID: <645d17210801241753j5069f6e9oa102e24a80c31cc0@mail.gmail.com> And also: $ make build : [('SSL routines', 'SSL3_GET_RECORD', 'wrong version number')] make: *** [koji] Error 1 Am I doing something dumb, or is there a problem? Cheers, Jonathan From dmc.fedora at filteredperception.org Fri Jan 25 01:49:42 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Thu, 24 Jan 2008 19:49:42 -0600 Subject: selinux breaks revisor In-Reply-To: <20080125013052.GL13888@redhat.com> References: <47963470.70009@gmail.com> <4798A9DE.3060402@redhat.com> <20080124225553.GE13888@redhat.com> <20080124232417.GF13888@redhat.com> <20080124185732.06966542@redhat.com> <47992AD2.7080904@filteredperception.org> <20080125005637.GK13888@redhat.com> <47993483.70804@filteredperception.org> <20080125013052.GL13888@redhat.com> Message-ID: <47994036.7030000@filteredperception.org> Daniel P. Berrange wrote: > On Thu, Jan 24, 2008 at 06:59:47PM -0600, Douglas McClendon wrote: >> Daniel P. Berrange wrote: >> >>> Plain QEMU is unusably slow for doing any real work - particularly compute >>> and disk intensive stuff like builds / composes. >> Takes 12 hours to compose my 1G LiveDVD, involving a full anaconda http >> install under qemu, followed by mksquashfs of the result. Honestly I do >> a lot of data shuffling, and think that I could probably halve that time >> if I wasn't more interested in further functionality at the moment than >> I am in performance. > > A 12 hour compose time fundmanetally limits the quality / speedy delivery > of LiveCDs because the turn around time between compose + QA cycles is being > bottlenecked. You can only do one compose & QA cycle per day. If a chroot > install takes < 1 hour you can get through 5 or more compose & QA cycles > a day. I mean no offense, but it seems like every time I say anything on this list, people assume it means that I am advocating some change in the core infrastructure that everybody should use. When in reality, I'm merely trying to open the possibility to do something that just couldn't be done before. My livecd generation system is dog slow, but its something that joe-user could download/install, and then use to create a custom livecd for personal or very limited use, *WITHOUT* requiring them to su to root, then have selinux disabled while livecd-creator runs. Ok, so 99% of the people on this list can go ahead and think that that new functionality serves no useful purpose. I admit, I don't have a lot of users yet. But hey- I like it. Getting back to your point- what I'm saying is that I'm not saying my tool is the right tool for everyone's job. If you saw my anti-selinux rant a while back, you may have noticed that I wasn't saying that selinux shouldn't exist, just that maybe it isn't the right tool for *every* job. A while back on this list, I asked what parts of fedora required root privileges to be rebuilt. I.e. why you couldn't just rpmbuild --rebuild every last thing as a build user, never subjecting the build system to the impact of building as root. The answer seemed to come back that the only things that _really_ required root, were the creation of small filesystem-disk images. My tool qfakeroot provides a solution for that, and given the sizes of the images involved, will add but a few minutes to the rpmbuild--rebuild time. > >> I'll take that 12 hours over the 1hr for livecd-creator any day of the >> week, knowing that I'm not running about 1000 rpm post install scripts >> under the limited protection of a chroot with selinux disabled. >> Combined with the comfort of knowing that if I do a compose on a >> different piece of hardware, that those 1000 scripts will have no chance >> to sneakily incur any host build dependencies based on their access to a >> random /proc (as opposed to the consistency of always identical qemu /proc). > > Do you inspect all these %post scripts ahead of time each time you do > a 'yum update' for your host machine. No. Every time you yum update you're > running the same scripts in your host without even the chroot protection. > And if you don't trust the RPMs you're using to build the LiveCD images, > why should any user trust the resulting LiveCD you're about to distribute. Trust is not absolute. I may want to do all kinds of experimental things with a LiveCD, that I wouldn't want to put on the particular build system. And please, don't be obtuse like everyone seems to be on this list and think that I just argued 180degrees against you. Your point is fine, and one I agree with, and have considered before and already take well into account. I'm _only_ suggesting that _maybe_ there are some people out there that can appreciate the functionality I'm bringing to the table, even with it's relative costs. > > If you really don't trust the RPMs you're about to compose, then run the > compose on a throw away host - just re-kickstart it after execution. > >> You may call 12 hours for a compose unusably slow. I don't. And >> computers and software get improved all the time, so maybe in 3 years, >> that 12 hours will just become "order a pizza and wait for the results". > > That's a fallacy. History shows that software increases its resource > requirements to easily match increases in hardware speed. Compare total > install time between RHL 5 and Fedora 8 - hardware has increased in > performance dramatically, but install time is still effectivelly unchanged. Yeah yeah, go ahead and be like the rest of the people here with that attitude. Just focus on countering everything I say, instead of maybe, just maybe admitting that the functionality I'm bringing to the table might actually be useful for quite a few scenarios. "Fallacy". I mean Puhlease... Would it cause the world to end if some of the core fedora developers would try to actually be constructive? Was your comment there _really_ necessary? Yeah!!! you showed me how utterly wrong I was. What a 'fallacy' I uttered. Come on. Give me a break. -dmc From jkeating at redhat.com Fri Jan 25 02:01:00 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 24 Jan 2008 21:01:00 -0500 Subject: koji problem? In-Reply-To: <645d17210801241753j5069f6e9oa102e24a80c31cc0@mail.gmail.com> References: <645d17210801241747u634e8965u101ed0a67657e414@mail.gmail.com> <645d17210801241753j5069f6e9oa102e24a80c31cc0@mail.gmail.com> Message-ID: <20080124210100.029a1df4@redhat.com> On Fri, 25 Jan 2008 01:53:43 +0000 "Jonathan Underwood" wrote: > Am I doing something dumb, or is there a problem? We're in out scheduled outage for storage upgrade and DB maint. The outage effects koji, and pkgdb. Pkgdb is used to determine who should be notified of your cvs change. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Jan 25 02:06:58 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 24 Jan 2008 21:06:58 -0500 Subject: selinux breaks revisor In-Reply-To: <47994036.7030000@filteredperception.org> References: <47963470.70009@gmail.com> <4798A9DE.3060402@redhat.com> <20080124225553.GE13888@redhat.com> <20080124232417.GF13888@redhat.com> <20080124185732.06966542@redhat.com> <47992AD2.7080904@filteredperception.org> <20080125005637.GK13888@redhat.com> <47993483.70804@filteredperception.org> <20080125013052.GL13888@redhat.com> <47994036.7030000@filteredperception.org> Message-ID: <20080124210658.5b0bd524@redhat.com> On Thu, 24 Jan 2008 19:49:42 -0600 Douglas McClendon wrote: > A while back on this list, I asked what parts of fedora required root > privileges to be rebuilt. I.e. why you couldn't just rpmbuild > --rebuild every last thing as a build user, never subjecting the > build system to the impact of building as root. The answer seemed to > come back that the only things that _really_ required root, were the > creation of small filesystem-disk images. My tool qfakeroot provides > a solution for that, and given the sizes of the images involved, will > add but a few minutes to the rpmbuild--rebuild time. Maybe I missed that, but every /rpm/ is buildable by non-root. It's when you start talking about /composing/ releases and Live images that root privs are needed (or enoug privs to make loopback devices). Now, we could do something more sneaky and ship the livcd-creator and pungi python scripts setuid, but that's probably not what you're looking for. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lesmikesell at gmail.com Fri Jan 25 02:23:47 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 24 Jan 2008 20:23:47 -0600 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <6CEA40CA-D5A6-46CE-8BF8-54165CAB3AD7@silveroaks.com> References: <20080124214629.C8E7F73511@hormel.redhat.com> <6CEA40CA-D5A6-46CE-8BF8-54165CAB3AD7@silveroaks.com> Message-ID: <47994833.7020508@gmail.com> chasd wrote: > >> Getting a bit off the original topic here, but the "other" thing I've >> always wished yum could do is "repeatable" updates. That is, the >> ability to update one machine, test some things, then update another and >> get only the same set of changes even if some newer packages had been >> subsequently added to the repos. > > To me, that isn't functionality for the client, it is functionality for > the server / cache. > It is a feature of WSUS - the ability to approve updates and only allow > clients to "see" the approved ones and not any other. > > Right now, there isn't a lot of intelligence built into the server end ( > MirrorManager excepted ) of the update process. The repositories serve > static files, that's it. Fedora can't ask any more from mirrors. If in > your environment you want to control how clients get updated, then it > makes sense to me that centralized control from the server side and > keeping the client side "dumb" is better. You only have to distribute > the repo configuration to use the controlled repo once, instead of > distributing specific update lists continually. > > That control is one of the reasons why as an admin I am interested in > InstantMirror and this discussion. I was thinking that if the client were aware of all the packages in the repo, all you'd need is a timestamp or some sort of transaction id associating the last rebuild of repo data with the packages added then. That way you could tell the client the timestamp or latest id that you wanted it to duplicate, and it could just ignore any packages newer than that. I think the client normally only sees repo data for the latest version of each package that is available - but there must be some way to get the dependency info for older ones, given the ability to request them specifically. -- Les Mikesell lesmikesell at gmail.com From dmc.fedora at filteredperception.org Fri Jan 25 02:27:05 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Thu, 24 Jan 2008 20:27:05 -0600 Subject: selinux breaks revisor In-Reply-To: <20080124210658.5b0bd524@redhat.com> References: <47963470.70009@gmail.com> <4798A9DE.3060402@redhat.com> <20080124225553.GE13888@redhat.com> <20080124232417.GF13888@redhat.com> <20080124185732.06966542@redhat.com> <47992AD2.7080904@filteredperception.org> <20080125005637.GK13888@redhat.com> <47993483.70804@filteredperception.org> <20080125013052.GL13888@redhat.com> <47994036.7030000@filteredperception.org> <20080124210658.5b0bd524@redhat.com> Message-ID: <479948F9.7070709@filteredperception.org> Jesse Keating wrote: > On Thu, 24 Jan 2008 19:49:42 -0600 > Douglas McClendon wrote: > >> A while back on this list, I asked what parts of fedora required root >> privileges to be rebuilt. I.e. why you couldn't just rpmbuild >> --rebuild every last thing as a build user, never subjecting the >> build system to the impact of building as root. The answer seemed to >> come back that the only things that _really_ required root, were the >> creation of small filesystem-disk images. My tool qfakeroot provides >> a solution for that, and given the sizes of the images involved, will >> add but a few minutes to the rpmbuild--rebuild time. > > > Maybe I missed that, but every /rpm/ is buildable by non-root. It's > when you start talking about /composing/ releases and Live images that > root privs are needed (or enoug privs to make loopback devices). I did miss that (had thought that the anaconda rpm was spinning some disk images). But my target was recompiling every line of fedora source code into a new fedora release (isos too), without requiring root privs. I.e. that was the itch I wanted to scratch, and so the distinction between rpms and compose tools doesn't change the issue for me. > > Now, we could do something more sneaky and ship the livcd-creator and > pungi python scripts setuid, but that's probably not what you're > looking for. Correct. Nor a magical hal/dbus/whatever service that exposes some root capabilities. But again, I'm not suggesting that there aren't a few viable theoretical alternatives to the method I presented. Though I don't know of any that work already. But as you said, sure, you can just go suid and do whatever you want. I just am kind of proud of the fact that I can accomplish the task without root/suid. Along with as described, the relative ease of doing a very small containered alternate-selinux policy set up. It sort of sounded to me like a useful solution for the selinux-chroot issues brought up in this thread. I was disappointed googling and seeing your issues with qemu-ppc not being great for booting up full blown fedora-ppc. I too really hope that sees improvement soon. -dmc From jkeating at redhat.com Fri Jan 25 02:35:46 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 24 Jan 2008 21:35:46 -0500 Subject: selinux breaks revisor In-Reply-To: <479948F9.7070709@filteredperception.org> References: <47963470.70009@gmail.com> <4798A9DE.3060402@redhat.com> <20080124225553.GE13888@redhat.com> <20080124232417.GF13888@redhat.com> <20080124185732.06966542@redhat.com> <47992AD2.7080904@filteredperception.org> <20080125005637.GK13888@redhat.com> <47993483.70804@filteredperception.org> <20080125013052.GL13888@redhat.com> <47994036.7030000@filteredperception.org> <20080124210658.5b0bd524@redhat.com> <479948F9.7070709@filteredperception.org> Message-ID: <20080124213546.0f9b7e3c@redhat.com> On Thu, 24 Jan 2008 20:27:05 -0600 Douglas McClendon wrote: > But again, I'm not suggesting that there aren't a few viable > theoretical alternatives to the method I presented. Though I don't > know of any that work already. But as you said, sure, you can just > go suid and do whatever you want. I just am kind of proud of the > fact that I can accomplish the task without root/suid. That is pretty cool that you were able to accomplish that, even if it does take a long time to do. > > Along with as described, the relative ease of doing a very small > containered alternate-selinux policy set up. It sort of sounded to > me like a useful solution for the selinux-chroot issues brought up in > this thread. > > I was disappointed googling and seeing your issues with qemu-ppc not > being great for booting up full blown fedora-ppc. I too really hope > that sees improvement soon. I do too, but honestly it didn't seem like many people out there that A) had the knowledge necessary to fix it and B) were willing / interested / had time to work on it. It would certainly make the things you're trying to do easier, and it would vastly improve my ability to test out the composes I'm doing. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lesmikesell at gmail.com Fri Jan 25 04:47:13 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 24 Jan 2008 22:47:13 -0600 Subject: long term support release In-Reply-To: <200801241528.m0OFSAk8009592@laptop13.inf.utfsm.cl> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <20080123103336.6e24109f@redhat.com> <47976399.3010709@redhat.com> <47979470.6010507@leemhuis.info> <1201150608.17905.78.camel@beck.corsepiu.local> <47989EF4.3000102@gmail.com> <200801241528.m0OFSAk8009592@laptop13.inf.utfsm.cl> Message-ID: <479969D1.8010202@gmail.com> Horst H. von Brand wrote: > >> Or several, if the primary one won't >> include Sun Java, vlc + codecs, and Nvidia/Ati drivers. > > EPEL doesn't include software that can't be redistributed legally as open > source, as it is part of Fedora. Fine with me, BTW. If this repository is unwilling to provide all packages, is there a process in place to permit the other necessary repositories to be enabled without conflicts? Or is there another repository with a more inclusive policy? -- Les Mikesell lesmikesell at gmail.com From jspaleta at gmail.com Fri Jan 25 05:14:54 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 24 Jan 2008 20:14:54 -0900 Subject: selinux breaks revisor In-Reply-To: <20080124210658.5b0bd524@redhat.com> References: <47963470.70009@gmail.com> <20080124232417.GF13888@redhat.com> <20080124185732.06966542@redhat.com> <47992AD2.7080904@filteredperception.org> <20080125005637.GK13888@redhat.com> <47993483.70804@filteredperception.org> <20080125013052.GL13888@redhat.com> <47994036.7030000@filteredperception.org> <20080124210658.5b0bd524@redhat.com> Message-ID: <604aa7910801242114i36798306qa46a43ab83e233a3@mail.gmail.com> 2008/1/24 Jesse Keating : > Maybe I missed that, but every /rpm/ is buildable by non-root. It's > when you start talking about /composing/ releases and Live images that > root privs are needed (or enoug privs to make loopback devices). make loopback devices.... does fuse provide a non-root way to deal with this here? -jef From jkeating at redhat.com Fri Jan 25 05:21:03 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 25 Jan 2008 00:21:03 -0500 Subject: selinux breaks revisor In-Reply-To: <604aa7910801242114i36798306qa46a43ab83e233a3@mail.gmail.com> References: <47963470.70009@gmail.com> <20080124232417.GF13888@redhat.com> <20080124185732.06966542@redhat.com> <47992AD2.7080904@filteredperception.org> <20080125005637.GK13888@redhat.com> <47993483.70804@filteredperception.org> <20080125013052.GL13888@redhat.com> <47994036.7030000@filteredperception.org> <20080124210658.5b0bd524@redhat.com> <604aa7910801242114i36798306qa46a43ab83e233a3@mail.gmail.com> Message-ID: <20080125002103.4f300abf@redhat.com> On Thu, 24 Jan 2008 20:14:54 -0900 "Jeff Spaleta" wrote: > make loopback devices.... does fuse provide a non-root way to deal > with this here? Probably through some setuid crud. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Fri Jan 25 05:58:16 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 25 Jan 2008 06:58:16 +0100 Subject: long term support release In-Reply-To: <1201118147.6218.99.camel@cutter> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> Message-ID: <1201240697.17905.179.camel@beck.corsepiu.local> On Wed, 2008-01-23 at 14:55 -0500, seth vidal wrote: > On Wed, 2008-01-23 at 19:35 +0100, Ralf Corsepius wrote: > > > Further: IMO, fedora legacy did not fail. It was discontinued by > > management, because it collided the certain business interests. > > > Ralf, > I know there's no way to convince you of this, No there isn't. This thread added further to this. It once again made it clear that many parties being involved into Fedora aren't willing in implementing a Fedora LTS or simply extending the lifetime of Fedora for various reasons - We will see if Ubuntu LTS will be a success. I would assume it to further contribute to Fedora loosing ground. > however, this isn't at > all what happened. Legacy just died. As I see it, it died, because people wanted to let it to die for various different individual motivations. > It wasn't decided or dictated by > anyone other than the reality that nothing had happened for months. Yes, but not because the "product sucked", the project was poorly implemented and poorly lead. Anyway, meanwhile, things in Fedora-land have changed. What prevents Fedora from launching a "Fedora LTS" as part of Fedora, using the Fedora infrastructure, e.g. by simply imply declaring "Fedora 7" life time's extended for, say 2 years, when FC9 comes out? The price would be fairly small. In particular, the infrastructure already is in place. All what would have to be implemented would be some regulations/conventions concerning "ABI/APIs" and ACLs. After these 2 years, you'd have the results of a fair comparison to "Fedora". If it goes down the drain, so be it ... > No one wanted to take on the rather large effort to keep it going. It > stopped. There was no management who discontinued it. May-be there had not been an explicit RH management decision on letting it die. But there also had been no will to support it. However, I recall FESCO (or had it been FAB?) having decided on FC's short life-time and to support EPEL. Both decisions have been severe mistakes, IMO. Ralf From dmc.fedora at filteredperception.org Fri Jan 25 05:59:04 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Thu, 24 Jan 2008 23:59:04 -0600 Subject: selinux breaks revisor In-Reply-To: <604aa7910801242114i36798306qa46a43ab83e233a3@mail.gmail.com> References: <47963470.70009@gmail.com> <20080124232417.GF13888@redhat.com> <20080124185732.06966542@redhat.com> <47992AD2.7080904@filteredperception.org> <20080125005637.GK13888@redhat.com> <47993483.70804@filteredperception.org> <20080125013052.GL13888@redhat.com> <47994036.7030000@filteredperception.org> <20080124210658.5b0bd524@redhat.com> <604aa7910801242114i36798306qa46a43ab83e233a3@mail.gmail.com> Message-ID: <47997AA8.3020305@filteredperception.org> Jeff Spaleta wrote: > 2008/1/24 Jesse Keating : >> Maybe I missed that, but every /rpm/ is buildable by non-root. It's >> when you start talking about /composing/ releases and Live images that >> root privs are needed (or enoug privs to make loopback devices). > > make loopback devices.... does fuse provide a non-root way to deal > with this here? I think there are historical threads about the security/code-quality and how it related to the decision of requiring root to add users to the fuse group. Sounded like fuse might get the job done someday, but someday wasn't quite here yet. Still, for doing composes as non-root I like my qemu 'qfakeroot', as it handles everything nicely (but slowly). I.e. I imagine running into headaches getting rpm post scripts running as non-root in a target dir, using something like traditional fakeroot to deal with file ownerships. And of course coming full circle, then there would still be the selinux issues in this non-root fuse-using quasi-chroot hypothetical compose beast... -dmc From skvidal at fedoraproject.org Fri Jan 25 06:18:06 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 25 Jan 2008 01:18:06 -0500 Subject: long term support release In-Reply-To: <1201240697.17905.179.camel@beck.corsepiu.local> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> Message-ID: <1201241886.8834.27.camel@cutter> On Fri, 2008-01-25 at 06:58 +0100, Ralf Corsepius wrote: > On Wed, 2008-01-23 at 14:55 -0500, seth vidal wrote: > > On Wed, 2008-01-23 at 19:35 +0100, Ralf Corsepius wrote: > > > > > Further: IMO, fedora legacy did not fail. It was discontinued by > > > management, because it collided the certain business interests. > > > > > > Ralf, > > I know there's no way to convince you of this, > No there isn't. > Okay. Well, I hope you do continue to stick around fedora/red hat-ish distributions, your contributions to rpm, imo, have been very valuable. -sv From dmc.fedora at filteredperception.org Fri Jan 25 06:43:58 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 25 Jan 2008 00:43:58 -0600 Subject: selinux breaks revisor In-Reply-To: <20080125013052.GL13888@redhat.com> References: <47963470.70009@gmail.com> <4798A9DE.3060402@redhat.com> <20080124225553.GE13888@redhat.com> <20080124232417.GF13888@redhat.com> <20080124185732.06966542@redhat.com> <47992AD2.7080904@filteredperception.org> <20080125005637.GK13888@redhat.com> <47993483.70804@filteredperception.org> <20080125013052.GL13888@redhat.com> Message-ID: <4799852E.2090108@filteredperception.org> Daniel P. Berrange wrote: > If you really don't trust the RPMs you're about to compose, then run the > compose on a throw away host - just re-kickstart it after execution. Forgot to reply to this piece, which is quite relevant. What I'm doing is precisely that- but much less, and 100% automated. Instead of using a throwaway kickstarted host, I'm using a throwaway initramfs that has the minimal files needed to losetup/loadpolicy/mkfs/chroot. (and seperately boot rescue iso and do an http install from an http server running as the same user running qemu) And by doing it in qemu, I can do all of this with a command-line, run as non-root, perhaps on a headless remote server running centos/rhel, that if it had a soul, would feel slightly dirty having had hundreds of fedora rpms installed as root under a chroot. No doubt xen can be coaxed to do the same thing, but again, I love the simplicity and flexibility of qemu. -dmc From rc040203 at freenet.de Fri Jan 25 06:19:54 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 25 Jan 2008 07:19:54 +0100 Subject: long term support release In-Reply-To: <20080124154331.7959ee6d@redhat.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <20080123103336.6e24109f@redhat.com> <47976399.3010709@redhat.com> <47979470.6010507@leemhuis.info> <1201150608.17905.78.camel@beck.corsepiu.local> <20080124081720.GA2636@free.fr> <1201166022.17905.109.camel@beck.corsepiu.local> <1201198306.17905.117.camel@beck.corsepiu.local> <20080124154331.7959ee6d@redhat.com> Message-ID: <1201241994.17905.196.camel@beck.corsepiu.local> On Thu, 2008-01-24 at 15:43 -0500, Jesse Keating wrote: > On Thu, 24 Jan 2008 19:11:46 +0100 > Ralf Corsepius wrote: > > > How can I? If I'd buy RHEL, I wouldn't want to use CentOS, if I were > > using CentOS I wouldn't want to use RHEL. In both cases, I probably > > would not want to use Fedora :/ > > Nice strawman. > > In a previous job I used > > A) RHEL for various mission critical systems where we wanted a Support > contract. > > B) CentOS for less critical systems and development systems. > > C) Fedora on the desktops/laptops/etc... > > I wanted and used all three. My view is different. Running any OS comes at a price. It's only a matter of "whom to pay for what and how much" and on finding an individually acceptable/reasonable "price/performance" ratio. That said, all of the 3 above are candidates suitable for different scenarios. * For those with "competent and/or cheap manpower" (e.g. universities) CentOS and Fedora are suitable "construction kits". * Those with little competent and/or cheap manpower, will have to outsource/buy-in IT - With RHEL, money flows to RH, with CentOS/Fedora money flows to other parties. Ralf From pertusus at free.fr Fri Jan 25 08:16:20 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 25 Jan 2008 09:16:20 +0100 Subject: long term support release In-Reply-To: <1201240697.17905.179.camel@beck.corsepiu.local> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> Message-ID: <20080125081620.GA2750@free.fr> On Fri, Jan 25, 2008 at 06:58:16AM +0100, Ralf Corsepius wrote: > > Anyway, meanwhile, things in Fedora-land have changed. > > What prevents Fedora from launching a "Fedora LTS" as part of Fedora, > using the Fedora infrastructure, e.g. by simply imply declaring "Fedora > 7" life time's extended for, say 2 years, when FC9 comes out? > > The price would be fairly small. In particular, the infrastructure > already is in place. All what would have to be implemented would be some > regulations/conventions concerning "ABI/APIs" and ACLs. I think that you are partly right, that is the infrastructure is there. And I also think that there is just no reason not to let interested people maintain fedora for a longer time. But I also think that currently such an effort wouldn't be that succesful because there are still a lot of packages that haven't comaintainers interested in the long term fedora, especially for former core packages. But things are changing and maybe with more mixed involvment in former core packages this would certainly become more likely to be successful. > However, I recall FESCO (or had it been FAB?) having decided on FC's > short life-time and to support EPEL. Both decisions have been severe > mistakes, IMO. Supporting EPEL is a good idea, but not letting those who want to take care of long term fedora is in my opinion a mistake. In most cases epel spec files couuld be used for fedora long term, in my opinion there would certainly be synergies between the 2 projects. -- Pat From skvidal at fedoraproject.org Fri Jan 25 08:23:46 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 25 Jan 2008 03:23:46 -0500 Subject: long term support release In-Reply-To: <20080125081620.GA2750@free.fr> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> Message-ID: <1201249426.14800.19.camel@cutter> On Fri, 2008-01-25 at 09:16 +0100, Patrice Dumas wrote: > > However, I recall FESCO (or had it been FAB?) having decided on FC's > > short life-time and to support EPEL. Both decisions have been severe > > mistakes, IMO. > > Supporting EPEL is a good idea, but not letting those who want to take > care of long term fedora is in my opinion a mistake. In most cases epel > spec files couuld be used for fedora long term, in my opinion there > would certainly be synergies between the 2 projects. > Maybe I missed something. Who/What is stopping someone(s) from taking on Long term support for fedora if they choose to? I don't recall anyone stopping anyone from doing it. I mean we stopped spinning cd-sized iso releases. Fedora Unity didn't care for that and they started doing their own. Not only did no one stop them no one CAN stop them from doing it. -sv From opensource at till.name Fri Jan 25 08:24:24 2008 From: opensource at till.name (Till Maas) Date: Fri, 25 Jan 2008 09:24:24 +0100 Subject: long term support release In-Reply-To: <479969D1.8010202@gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <200801241528.m0OFSAk8009592@laptop13.inf.utfsm.cl> <479969D1.8010202@gmail.com> Message-ID: <200801250924.29871.opensource@till.name> On Fri January 25 2008, Les Mikesell wrote: > Horst H. von Brand wrote: > >> Or several, if the primary one won't > >> include Sun Java, vlc + codecs, and Nvidia/Ati drivers. > > > > EPEL doesn't include software that can't be redistributed legally as open > > source, as it is part of Fedora. Fine with me, BTW. > > If this repository is unwilling to provide all packages, is there a > process in place to permit the other necessary repositories to be > enabled without conflicts? Or is there another repository with a more > inclusive policy? With the yum-priorities plugin, you can give priorities to repositories. Repositories with a higher priority cannot overwrite packages from repositories with a lower priority. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From rc040203 at freenet.de Fri Jan 25 08:38:41 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 25 Jan 2008 09:38:41 +0100 Subject: long term support release In-Reply-To: <1201249426.14800.19.camel@cutter> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> Message-ID: <1201250321.17905.251.camel@beck.corsepiu.local> On Fri, 2008-01-25 at 03:23 -0500, seth vidal wrote: > On Fri, 2008-01-25 at 09:16 +0100, Patrice Dumas wrote: > > > However, I recall FESCO (or had it been FAB?) having decided on FC's > > > short life-time and to support EPEL. Both decisions have been severe > > > mistakes, IMO. > > > > Supporting EPEL is a good idea, but not letting those who want to take > > care of long term fedora is in my opinion a mistake. In most cases epel > > spec files couuld be used for fedora long term, in my opinion there > > would certainly be synergies between the 2 projects. > > > > Maybe I missed something. Who/What is stopping someone(s) from taking on > Long term support for fedora if they choose to? Lack of technical resources. RH/Fedora would have them, the costs would be very low, but Fedora's leadership (Or should I say the @RH's in Fedora's leadership) refuse to support this idea and block it off. > I don't recall anyone > stopping anyone from doing it. I mean we stopped spinning cd-sized iso > releases. Fedora Unity didn't care for that and they started doing their > own. Not only did no one stop them no one CAN stop them from doing it. Right. But ask yourself, isn't the fact Fedora Unity exists evidence of RH/Fedora not having meet the market's demand and having slipped through an opportunity? I say yes. Also, wouldn't you consider the fact Ubuntu launches "Ubuntu LTS" to be evidence enough that others see a market nice? I see it, too. Initially people chose Fedora as replacement for RHL. Fedora didn't fill this gap and still hasn't managed to fill this gap. Ralf From sundaram at fedoraproject.org Fri Jan 25 08:54:58 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 25 Jan 2008 14:24:58 +0530 Subject: long term support release In-Reply-To: <479969D1.8010202@gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <20080123103336.6e24109f@redhat.com> <47976399.3010709@redhat.com> <47979470.6010507@leemhuis.info> <1201150608.17905.78.camel@beck.corsepiu.local> <47989EF4.3000102@gmail.com> <200801241528.m0OFSAk8009592@laptop13.inf.utfsm.cl> <479969D1.8010202@gmail.com> Message-ID: <4799A3E2.4090206@fedoraproject.org> Les Mikesell wrote: > Horst H. von Brand wrote: >> >>> Or several, if the primary one won't >>> include Sun Java, vlc + codecs, and Nvidia/Ati drivers. >> >> EPEL doesn't include software that can't be redistributed legally as open >> source, as it is part of Fedora. Fine with me, BTW. > > If this repository is unwilling to provide all packages, is there a > process in place to permit the other necessary repositories to be > enabled without conflicts? Or is there another repository with a more > inclusive policy? rpmfusion has plans to. Rahul From jspaleta at gmail.com Fri Jan 25 08:47:07 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 24 Jan 2008 23:47:07 -0900 Subject: long term support release In-Reply-To: <1201250321.17905.251.camel@beck.corsepiu.local> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> Message-ID: <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> On Jan 24, 2008 11:38 PM, Ralf Corsepius wrote: > Also, wouldn't you consider the fact Ubuntu launches "Ubuntu LTS" to be > evidence enough that others see a market nice? I'm pretty sure that Ubuntu LTS is something that Canonical as a business entity as chosen to launch and leverages as part of its business model and is not in point of fact relying primarily on community manpower to make the LTS offering actually work. Find me a business entity who would like to do something similar in Fedora space and I'll gladly talk to them about making room in the project. -jef From jkeating at redhat.com Fri Jan 25 08:47:36 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 25 Jan 2008 03:47:36 -0500 Subject: long term support release In-Reply-To: <1201250321.17905.251.camel@beck.corsepiu.local> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> Message-ID: <20080125034736.1fe9c041@redhat.com> On Fri, 25 Jan 2008 09:38:41 +0100 Ralf Corsepius wrote: > I see it, too. Initially people chose Fedora as replacement for RHL. > Fedora didn't fill this gap and still hasn't managed to fill this gap. RHL was a failure on Red Hat's part. They flat out could not afford to continue it as it was. Any sort of Fedora effort that looks like LTS or looks like RHL is not going to get much RH resources after the 13 months we get now (and that even took some convincing). With lots of key resources pulling out after that time period, many of us struggle with the thought of seeing something continue on without those resources under the name of Fedora. Ubuntu LTS seems to exist because they have no RHEL/CentOS equiv. I feel that our efforts are far better spent making the RHEL/CentOS/EPEL experience better, so that there isn't a thought that we need a long term Fedora, because we'd already have it with the RHEL/CentOS/EPEL set. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Fri Jan 25 08:59:52 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 25 Jan 2008 09:59:52 +0100 Subject: long term support release In-Reply-To: <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> Message-ID: <1201251592.17905.255.camel@beck.corsepiu.local> On Thu, 2008-01-24 at 23:47 -0900, Jeff Spaleta wrote: > On Jan 24, 2008 11:38 PM, Ralf Corsepius wrote: > > Also, wouldn't you consider the fact Ubuntu launches "Ubuntu LTS" to be > > evidence enough that others see a market nice? > > I'm pretty sure that Ubuntu LTS is something that Canonical as a > business entity as chosen to launch and leverages as part of its > business model and is not in point of fact relying primarily on > community manpower to make the LTS offering actually work. Find me a > business entity who would like to do something similar in Fedora space > and I'll gladly talk to them about making room in the project. There is one difference between Fedora and Ubuntu: * Fedora is backed up by an actively contributing community. * RH/fedoraproject.org has the technical resources. There is only one thing missing: a culture of openness and a lack of confidence into the powers of open development. Ralf From pertusus at free.fr Fri Jan 25 09:08:50 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 25 Jan 2008 10:08:50 +0100 Subject: long term support release In-Reply-To: <1201249426.14800.19.camel@cutter> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> Message-ID: <20080125090850.GC2750@free.fr> On Fri, Jan 25, 2008 at 03:23:46AM -0500, seth vidal wrote: > > On Fri, 2008-01-25 at 09:16 +0100, Patrice Dumas wrote: > > > However, I recall FESCO (or had it been FAB?) having decided on FC's > > > short life-time and to support EPEL. Both decisions have been severe > > > mistakes, IMO. > > > > Supporting EPEL is a good idea, but not letting those who want to take > > care of long term fedora is in my opinion a mistake. In most cases epel > > spec files couuld be used for fedora long term, in my opinion there > > would certainly be synergies between the 2 projects. > > > > Maybe I missed something. Who/What is stopping someone(s) from taking on > Long term support for fedora if they choose to? I don't recall anyone Unless I am wrong new builds aren't allowed for EOL releases. And I also guess that at some point mirrors are shut down. Not doing those 2 things would really allow for a fedora LTS. Now there is also the bohdi pushes and the signing. For the signing this could be done like other releases, that is fedora lts packages signed at the same time that other packages. and for bodhi somebody interested in fedora LTS would have to do the push, but it shouldn't be that hard to find such volunteer if the project is enabled. As a side note, with bodhi, the fedora process looks very like former legacy project. Something that would help even more would be to have RHEL branches available in the cvs like fedora and EPEL branches (maybe only read-only). But I guess there are many reasons, some technical, but most linked with redhat management of RHEL that would render that possibility quite unlikely (I am not criticizing, only stating). -- Pat From emmanuel.seyman at club-internet.fr Fri Jan 25 09:06:54 2008 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Fri, 25 Jan 2008 10:06:54 +0100 Subject: long term support release In-Reply-To: <1201250321.17905.251.camel@beck.corsepiu.local> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> Message-ID: <20080125090654.GA3062@orient.maison.lan> * Ralf Corsepius [25/01/2008 09:51] : > > Lack of technical resources. Oh, please. Hardware is cheap and so is rack space. The bandwidth part of the equation is the hardest one to solve and even that can be worked about. > Right. But ask yourself, isn't the fact Fedora Unity exists evidence of > RH/Fedora not having meet the market's demand and having slipped through > an opportunity? I say yes. The market has dozens (if not hundreds) of demands, some of which are at odds the others. I don't remember Red Hat or Fedora promising they would address each and every one of them (and, in fact, I distinctly remember the opposite) and I suspect that neither do the people asking/demanding that LTS be implemented. Emmanuel From rc040203 at freenet.de Fri Jan 25 09:21:21 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 25 Jan 2008 10:21:21 +0100 Subject: long term support release In-Reply-To: <20080125034736.1fe9c041@redhat.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <20080125034736.1fe9c041@redhat.com> Message-ID: <1201252881.17905.272.camel@beck.corsepiu.local> On Fri, 2008-01-25 at 03:47 -0500, Jesse Keating wrote: > On Fri, 25 Jan 2008 09:38:41 +0100 > Ralf Corsepius wrote: > > > I see it, too. Initially people chose Fedora as replacement for RHL. > > Fedora didn't fill this gap and still hasn't managed to fill this gap. > > RHL was a failure on Red Hat's part. They flat out could not afford to > continue it as it was. Well, IMO RHL had been the "step into the door" which had caused people to getting into RH and had let RH gain the fame they are still profiting from today. Without RHL, I would expect Fedora probably not exist, or be an ignorable niche, like many other Linux distros. > Any sort of Fedora effort that looks like LTS > or looks like RHL is not going to get much RH resources after the 13 > months we get now (and that even took some convincing). Exactly this is the point. I claim the costs for RH to be almost minimal for a "Fedora LTS" project under the "Fedora hood". It would collide with Fedora as technology preview, collides with EPEL, and would not unlikely impose some security and stability drawbacks. But that's essentially all. > Ubuntu LTS seems to exist because they have no RHEL/CentOS equiv. May-be, not unlikely. > I > feel that our efforts are far better spent making the RHEL/CentOS/EPEL > experience better, so that there isn't a thought that we need a long > term Fedora, because we'd already have it with the RHEL/CentOS/EPEL set. Unless RH makes RHEL publicly available, instead of forcing people to recompile their packages, I refuse to support EPEL. Also, I consider EPEL as counterproductive to Fedora because it drains away users, developers and resources (RH money) from Fedora. Ralf From jspaleta at gmail.com Fri Jan 25 09:26:49 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 25 Jan 2008 00:26:49 -0900 Subject: long term support release In-Reply-To: <20080125090850.GC2750@free.fr> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> Message-ID: <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> On Jan 25, 2008 12:08 AM, Patrice Dumas wrote: > Unless I am wrong new builds aren't allowed for EOL releases. And I also > guess that at some point mirrors are shut down. Not doing those 2 things > would really allow for a fedora LTS. Until someone comes up with a sound plan for an LTS deliverable that communicates expectations on quality, I don't see a reason to just open up the trees for random people to update random packages whenever they want to. But if Jesse's koper idea becomes reality, then a randomly updated neverending repository might very well be possible inside the scope of kopers[1]. Though source distribution requirements will need to be thought out for kopers. [1]http://fedoraproject.org/wiki/JesseKeating/KojiPersonalRepos -jef From rc040203 at freenet.de Fri Jan 25 09:28:00 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 25 Jan 2008 10:28:00 +0100 Subject: long term support release In-Reply-To: <20080125090654.GA3062@orient.maison.lan> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <20080125090654.GA3062@orient.maison.lan> Message-ID: <1201253280.17905.280.camel@beck.corsepiu.local> On Fri, 2008-01-25 at 10:06 +0100, Emmanuel Seyman wrote: > * Ralf Corsepius [25/01/2008 09:51] : > > > > Lack of technical resources. > > Oh, please. > > Hardware is cheap and so is rack space. The bandwidth part of the > equation is the hardest one to solve and even that can be worked about. OK, where is it? Do you have the TBytes to host it, do you have dozens of mirrors, do you have the bandwidth, do you have the man-power to administrate the buildsystem? Have a look at rpmfusion - Despite they are working on it for months, AFAICT, trying to copy/reuse the fedoraproject.org infrastructure it's still not up. > > Right. But ask yourself, isn't the fact Fedora Unity exists evidence of > > RH/Fedora not having meet the market's demand and having slipped through > > an opportunity? I say yes. > > The market has dozens (if not hundreds) of demands, some of which are at odds > the others. I don't remember Red Hat or Fedora promising they would address > each and every one of them (and, in fact, I distinctly remember the opposite) Right, nevertheless this discussion reappears every couple of months. > and I suspect that neither do the people asking/demanding that LTS be > implemented. ?!? They would not ask if they wouldn't want it. Actually, I assume most people being in real need for a RHL replacement have quit Fedora long time ago. Ralf From pertusus at free.fr Fri Jan 25 09:35:17 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 25 Jan 2008 10:35:17 +0100 Subject: long term support release In-Reply-To: <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> References: <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> Message-ID: <20080125093517.GA16080@free.fr> On Fri, Jan 25, 2008 at 12:26:49AM -0900, Jeff Spaleta wrote: > On Jan 25, 2008 12:08 AM, Patrice Dumas wrote: > > Unless I am wrong new builds aren't allowed for EOL releases. And I also > > guess that at some point mirrors are shut down. Not doing those 2 things > > would really allow for a fedora LTS. > > Until someone comes up with a sound plan for an LTS deliverable that > communicates expectations on quality, I don't see a reason to just > open up the trees for random people to update random packages whenever > they want to. Random packages, maybe, but not random people, please. And there should not be any quality expectation just like for fedora itself. -- Pat From jspaleta at gmail.com Fri Jan 25 09:50:47 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 25 Jan 2008 00:50:47 -0900 Subject: long term support release In-Reply-To: <20080125093517.GA16080@free.fr> References: <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> Message-ID: <604aa7910801250150g3e2b6732we481ef783f83c240@mail.gmail.com> On Jan 25, 2008 12:35 AM, Patrice Dumas wrote: > And there should not be any quality expectation just like for fedora > itself. Maybe quality was the wrong word.... purpose would be better. If the point of an extended period is to make sure bugfixes get out for example.. then there needs to be some plan to actually make sure that happens so we don't mislead users. A purpose and scope defined well enough so that I can track some sort of performance metric. -jef From emmanuel.seyman at club-internet.fr Fri Jan 25 09:47:11 2008 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Fri, 25 Jan 2008 10:47:11 +0100 Subject: long term support release In-Reply-To: <1201253280.17905.280.camel@beck.corsepiu.local> References: <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <20080125090654.GA3062@orient.maison.lan> <1201253280.17905.280.camel@beck.corsepiu.local> Message-ID: <20080125094711.GA3298@orient.maison.lan> * Ralf Corsepius [25/01/2008 10:31] : > > Do you have the TBytes to host it, do you have dozens of mirrors, do you > have the bandwidth, do you have the man-power to administrate the > buildsystem? Were I interested in Fedora LTS, I'll start looking for server space and bandwidth (man-power isn't exactly a technical ressource). And, yes, I'm certain I could find enough to get started. > Have a look at rpmfusion - Despite they are working on it for months, > AFAICT, trying to copy/reuse the fedoraproject.org infrastructure it's > still not up. Is copying the Fedora infrastructure really the showstopper ? Last I heard, it was hardware problems and lack of man-power. > > the others. I don't remember Red Hat or Fedora promising they would address > > each and every one of them (and, in fact, I distinctly remember the opposite) > > and I suspect that neither do the people asking/demanding that LTS be > > implemented. > ?!? They would not ask if they wouldn't want it. Sorry, bad phrasing on my part. What I meant was : The people asking/demanding that LTS be implemented do not remember Red Hat or Fedora promising they would address all demands made of Fedora. > Actually, I assume most people being in real need for a RHL replacement > have quit Fedora long time ago. Well, I'm still here and Fedora fills my needs better than RHL ever did. Emmanuel "4.2 was nice, though" Seyman From markg85 at gmail.com Fri Jan 25 09:59:07 2008 From: markg85 at gmail.com (Mark) Date: Fri, 25 Jan 2008 10:59:07 +0100 Subject: Opinion: Preferred Applications & Removable Drives and Media In-Reply-To: <1201225750.2389.4.camel@cookie.hadess.net> References: <6e24a8e80801191428m45ecd472w788c4a88055f0455@mail.gmail.com> <1200785912.2924.14.camel@localhost.localdomain> <6e24a8e80801200641m64febab5v5f1bbc1fa1977e19@mail.gmail.com> <6e24a8e80801221526y4caac2c5g3522773b5dfb7ca5@mail.gmail.com> <1201045549.2858.4.camel@localhost.localdomain> <6e24a8e80801221638v11b6a247wd6fc60d5feefb8a7@mail.gmail.com> <6e24a8e80801221649h2602ad0cjcc7a1c9e22ceb24c@mail.gmail.com> <1201225750.2389.4.camel@cookie.hadess.net> Message-ID: <6e24a8e80801250159h4a3a8875p8164f2acacf1c5@mail.gmail.com> 2008/1/25, Bastien Nocera : > > On Wed, 2008-01-23 at 01:49 +0100, Mark wrote: > > > But thanx for the help. now i know what i have to do. > > > > Hmm.. just a minor issue. > > I've just updated totem and now i can choose that a few times in the > > media list as well (including dvd video) but i don't see a option > > there to run a command. Isn't it handy to have that option there if > > none of the other options suit you? > > Not really. If there are particular applications that you'd like to see > listed (say, you wanted Thoggen or OGMRip to be launched instead of > Totem when inserting a video DVD), then file a bug against the package > or the upstream program. > > Entering commands by hand is for geeks. > > > Or what else do i have to do to get another application to show up in that list? > > and is this conforming a standard from freedesktop? if so: which one? > > Only GNOME programs implement this right now, but all the Fedora GUI > applications should be using this, just like they all have .desktop > files, so say KDE apps can be integrated into Nautilus as well as GNOME > apps. The more i read about it the more i like it. But i doubt that all the applications will fill out those desktop files with the new mime types. They will ofcause get that done sometime but it will take a while. Specially for packages that can't be in the official fedora repo for whatever reason. I wonder how long it will take for all currently existing media payer apps that work on linux to get the .desktop file updated... i guess a year (after the F9 release) with the majority done within a month after the F9 release. From sundaram at fedoraproject.org Fri Jan 25 10:11:22 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 25 Jan 2008 15:41:22 +0530 Subject: Opinion: Preferred Applications & Removable Drives and Media In-Reply-To: <6e24a8e80801250159h4a3a8875p8164f2acacf1c5@mail.gmail.com> References: <6e24a8e80801191428m45ecd472w788c4a88055f0455@mail.gmail.com> <1200785912.2924.14.camel@localhost.localdomain> <6e24a8e80801200641m64febab5v5f1bbc1fa1977e19@mail.gmail.com> <6e24a8e80801221526y4caac2c5g3522773b5dfb7ca5@mail.gmail.com> <1201045549.2858.4.camel@localhost.localdomain> <6e24a8e80801221638v11b6a247wd6fc60d5feefb8a7@mail.gmail.com> <6e24a8e80801221649h2602ad0cjcc7a1c9e22ceb24c@mail.gmail.com> <1201225750.2389.4.camel@cookie.hadess.net> <6e24a8e80801250159h4a3a8875p8164f2acacf1c5@mail.gmail.com> Message-ID: <4799B5CA.2050500@fedoraproject.org> Mark wrote: > I wonder how long it will take for all currently existing media payer > apps that work on linux to get the .desktop file updated... i guess a > year (after the F9 release) with the majority done within a month > after the F9 release. Which repository do you have in mind? Many of them follow Fedora packaging guidelines. We probably need to update the guidelines and then anyone can file bugs against packages in the Fedora repositories including third party ones. Rahul From laurent.rineau__fedora at normalesup.org Fri Jan 25 10:22:41 2008 From: laurent.rineau__fedora at normalesup.org (Laurent Rineau) Date: Fri, 25 Jan 2008 11:22:41 +0100 Subject: kdebase3-related broken dependencies (was: Re: rawhide report: 20080124 changes) In-Reply-To: <1201196321.8782.95.camel@gilboa-home-dev.localdomain> References: <200801241254.m0OCsqrB023485@porkchop.devel.redhat.com> <1201196321.8782.95.camel@gilboa-home-dev.localdomain> Message-ID: <200801251122.41671@rineau.tsetse> On Thursday 24 January 2008 18:38:41 Gilboa Davara wrote: > On Thu, 2008-01-24 at 16:52 +0000, Kevin Kofler wrote: > > Build System redhat.com> writes: > > > kdebase3 - 3.5.8-34.fc9.i386 requires libkdeinit_ksmserver.so > > > kdebase3 - 3.5.8-34.fc9.i386 requires libkdeinit_kaccess.so > > > kdebase3 - 3.5.8-34.fc9.i386 requires libkdeinit_konsole.so > > > kdebase3 - 3.5.8-34.fc9.i386 requires libkdeinit_kprinter.so > > > kdebase3 - 3.5.8-34.fc9.i386 requires libkdeinit_kcontrol.so > > > kdebase3 - 3.5.8-34.fc9.i386 requires libkdeinit_kjobviewer.so > > > kdebase3 - 3.5.8-34.fc9.i386 requires libkdeinit_kcminit.so > > > kdebase3 - 3.5.8-34.fc9.i386 requires libkdeinit_kcminit_startup.so > > > kdebluetooth - 1.0-0.39.beta8.fc9.i386 requires /usr/bin/kdesu > > > kscope - 1.6.1-3.fc9.i386 requires libkateutils.so.0 > > > kscope - 1.6.1-3.fc9.i386 requires libkateinterfaces.so.0 > > > ksmarttray - 0.52-53.fc9.i386 requires /usr/bin/kdesu > > > > These should be back in kdebase3-3.5.8-35.fc9. So you don't have to do > > anything if your package is in the list _above_. > > Thanks. > Until kdebluetooth/4 is released (no idea when), we're left with > kdebluetooth/3 and its KDE3 dependency chain. Is kdeblutooth?3 really usable without Konqueror?3?? My uses of it were mainly through the bluetooth:// or obex:// protocol in Konqueror, defined in /usr/share/services/. I?assume that KDE4 cannot handle with KDE3 protocols. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From markg85 at gmail.com Fri Jan 25 10:25:58 2008 From: markg85 at gmail.com (Mark) Date: Fri, 25 Jan 2008 11:25:58 +0100 Subject: Opinion: Preferred Applications & Removable Drives and Media In-Reply-To: <4799B5CA.2050500@fedoraproject.org> References: <6e24a8e80801191428m45ecd472w788c4a88055f0455@mail.gmail.com> <1200785912.2924.14.camel@localhost.localdomain> <6e24a8e80801200641m64febab5v5f1bbc1fa1977e19@mail.gmail.com> <6e24a8e80801221526y4caac2c5g3522773b5dfb7ca5@mail.gmail.com> <1201045549.2858.4.camel@localhost.localdomain> <6e24a8e80801221638v11b6a247wd6fc60d5feefb8a7@mail.gmail.com> <6e24a8e80801221649h2602ad0cjcc7a1c9e22ceb24c@mail.gmail.com> <1201225750.2389.4.camel@cookie.hadess.net> <6e24a8e80801250159h4a3a8875p8164f2acacf1c5@mail.gmail.com> <4799B5CA.2050500@fedoraproject.org> Message-ID: <6e24a8e80801250225s43f14ad1tba831e3e28aabe3b@mail.gmail.com> 2008/1/25, Rahul Sundaram : > Mark wrote: > > I wonder how long it will take for all currently existing media payer > > apps that work on linux to get the .desktop file updated... i guess a > > year (after the F9 release) with the majority done within a month > > after the F9 release. > > Which repository do you have in mind? Many of them follow Fedora > packaging guidelines. We probably need to update the guidelines and then > anyone can file bugs against packages in the Fedora repositories > including third party ones. > > Rahul Livna at the moment. and in livna the mplayer package (what else ^_^). I've just send a mail to the package maintainers and a few of the mplayer development team to include this mime change in there .desktop file. it is something that has to be "fixed" upstream anyway. But let me get this right and take mplayer as a example. Fedora isn't allowed to add mplayer to there repo because of patent stuff in the usa but i am allowed to fill a bug against mplayer on bugzilla.redhat.com? that's strange! very good but strange. From sundaram at fedoraproject.org Fri Jan 25 10:37:08 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 25 Jan 2008 16:07:08 +0530 Subject: Opinion: Preferred Applications & Removable Drives and Media In-Reply-To: <6e24a8e80801250225s43f14ad1tba831e3e28aabe3b@mail.gmail.com> References: <6e24a8e80801191428m45ecd472w788c4a88055f0455@mail.gmail.com> <1200785912.2924.14.camel@localhost.localdomain> <6e24a8e80801200641m64febab5v5f1bbc1fa1977e19@mail.gmail.com> <6e24a8e80801221526y4caac2c5g3522773b5dfb7ca5@mail.gmail.com> <1201045549.2858.4.camel@localhost.localdomain> <6e24a8e80801221638v11b6a247wd6fc60d5feefb8a7@mail.gmail.com> <6e24a8e80801221649h2602ad0cjcc7a1c9e22ceb24c@mail.gmail.com> <1201225750.2389.4.camel@cookie.hadess.net> <6e24a8e80801250159h4a3a8875p8164f2acacf1c5@mail.gmail.com> <4799B5CA.2050500@fedoraproject.org> <6e24a8e80801250225s43f14ad1tba831e3e28aabe3b@mail.gmail.com> Message-ID: <4799BBD4.2060505@fedoraproject.org> Mark wrote: > But let me get this right and take mplayer as a example. Fedora isn't > allowed to add mplayer to there repo because of patent stuff in the > usa but i am allowed to fill a bug against mplayer on > bugzilla.redhat.com? that's strange! very good but strange. You must file a bug report with the repository including mplayer or whatever applications Fedora isn't including. Rahul From mschwendt.tmp0701.nospam at arcor.de Fri Jan 25 10:29:59 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 25 Jan 2008 11:29:59 +0100 Subject: long term support release In-Reply-To: <20080125094711.GA3298@orient.maison.lan> References: <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <20080125090654.GA3062@orient.maison.lan> <1201253280.17905.280.camel@beck.corsepiu.local> <20080125094711.GA3298@orient.maison.lan> Message-ID: <20080125112959.baaf72d3.mschwendt.tmp0701.nospam@arcor.de> On Fri, 25 Jan 2008 10:47:11 +0100, Emmanuel Seyman wrote: > * Ralf Corsepius [25/01/2008 10:31] : > > > > Do you have the TBytes to host it, do you have dozens of mirrors, do you > > have the bandwidth, do you have the man-power to administrate the > > buildsystem? > > Were I interested in Fedora LTS, I'll start looking for server space and > bandwidth (man-power isn't exactly a technical ressource). And, yes, > I'm certain I could find enough to get started. > > > Have a look at rpmfusion - Despite they are working on it for months, > > AFAICT, trying to copy/reuse the fedoraproject.org infrastructure it's > > still not up. > > Is copying the Fedora infrastructure really the showstopper ? > Last I heard, it was hardware problems and lack of man-power. Do you expect anyone outside the Fedora Project to duplicate existing Fedora Infrastructure, such as bugzilla, CVS+FAS, lookaside cache, buildsys for multiple architectures, master repos, introduce a new GPG key, switch mailing-lists, advertise the whole thing as a non-Fedora project? That would make it much more difficult. Well, I'm sceptical that there would be enough volunteers to offer Fedora LTS free of charge, even if the Fedora Project permitted use of their infrastructure. Fedora LTS would compete with CentOS+EPEL and would lead to even more mass-builds. Still, a discussion of Fedora LTS should start with outlining guarantees (or less strictly, the concrete project goals/promises), policies, procedures, and a gathering of people with strong interest in such a project. Long before determining whether infrastructure is the last thing that holds up the project. From markg85 at gmail.com Fri Jan 25 10:37:26 2008 From: markg85 at gmail.com (Mark) Date: Fri, 25 Jan 2008 11:37:26 +0100 Subject: Opinion: Preferred Applications & Removable Drives and Media In-Reply-To: <4799BBD4.2060505@fedoraproject.org> References: <6e24a8e80801191428m45ecd472w788c4a88055f0455@mail.gmail.com> <6e24a8e80801221526y4caac2c5g3522773b5dfb7ca5@mail.gmail.com> <1201045549.2858.4.camel@localhost.localdomain> <6e24a8e80801221638v11b6a247wd6fc60d5feefb8a7@mail.gmail.com> <6e24a8e80801221649h2602ad0cjcc7a1c9e22ceb24c@mail.gmail.com> <1201225750.2389.4.camel@cookie.hadess.net> <6e24a8e80801250159h4a3a8875p8164f2acacf1c5@mail.gmail.com> <4799B5CA.2050500@fedoraproject.org> <6e24a8e80801250225s43f14ad1tba831e3e28aabe3b@mail.gmail.com> <4799BBD4.2060505@fedoraproject.org> Message-ID: <6e24a8e80801250237h591b0df2g534df6ec83182fa5@mail.gmail.com> 2008/1/25, Rahul Sundaram : > Mark wrote: > > But let me get this right and take mplayer as a example. Fedora isn't > > allowed to add mplayer to there repo because of patent stuff in the > > usa but i am allowed to fill a bug against mplayer on > > bugzilla.redhat.com? that's strange! very good but strange. > > You must file a bug report with the repository including mplayer or > whatever applications Fedora isn't including. > > Rahul I will keep that in mind when having a issue with a third party app again that's not included in fedora by default ^_^ From mschwendt.tmp0701.nospam at arcor.de Fri Jan 25 10:51:03 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 25 Jan 2008 11:51:03 +0100 Subject: Tools to examine build logs? Message-ID: <20080125115103.2009a47a.mschwendt.tmp0701.nospam@arcor.de> What do you use to search build logs for the various warnings printed by "configure", the compiler and other tools? For a long time I've used the following simple shell function for building from source rpms and automatically collecting the output in log files: function rpmb { name=$(rpm -qp --qf %{name} $1) ver=$(rpm -q --whatprovides redhat-release --qf %{version}) logname=build.$name.$ver.log echo "Build for:" $(cat /etc/redhat-release) | tee -a $logname rpmbuild --rebuild $1 2>&1 | tee -a $logname #rpmblstrip.pl $logname > $logname.stripped } The last line tried to grep various warnings plus a few things like "yes/no" feature status output from configure scripts, saving the time needed to skim over build logs. I messed it up when adding to it commands to watch for PIC builds and no-%optflags builds. That's why it is disabled. So, what do you use to examine build logs from mock or plain rpmbuild? Do you always display the complete logs? From che666 at gmail.com Fri Jan 25 11:14:01 2008 From: che666 at gmail.com (Rudolf Kastl) Date: Fri, 25 Jan 2008 12:14:01 +0100 Subject: Tools to examine build logs? In-Reply-To: <20080125115103.2009a47a.mschwendt.tmp0701.nospam@arcor.de> References: <20080125115103.2009a47a.mschwendt.tmp0701.nospam@arcor.de> Message-ID: rpmbuild -ba blahblub 2> error.log just splitting stderr off the regular output. kind regards, Rudolf Kastl On Jan 25, 2008 11:51 AM, Michael Schwendt wrote: > What do you use to search build logs for the various warnings printed by > "configure", the compiler and other tools? > > For a long time I've used the following simple shell function for building > from source rpms and automatically collecting the output in log files: > > function rpmb { > name=$(rpm -qp --qf %{name} $1) > ver=$(rpm -q --whatprovides redhat-release --qf %{version}) > logname=build.$name.$ver.log > echo "Build for:" $(cat /etc/redhat-release) | tee -a $logname > rpmbuild --rebuild $1 2>&1 | tee -a $logname > #rpmblstrip.pl $logname > $logname.stripped > } > > The last line tried to grep various warnings plus a few things like > "yes/no" feature status output from configure scripts, saving the time > needed to skim over build logs. I messed it up when adding to it commands > to watch for PIC builds and no-%optflags builds. That's why it is disabled. > > So, what do you use to examine build logs from mock or plain rpmbuild? > Do you always display the complete logs? > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From vonbrand at inf.utfsm.cl Fri Jan 25 12:56:04 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Fri, 25 Jan 2008 09:56:04 -0300 Subject: long term support release In-Reply-To: <1201240697.17905.179.camel@beck.corsepiu.local> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> Message-ID: <200801251256.m0PCu4hR009704@laptop13.inf.utfsm.cl> Ralf Corsepius wrote: > On Wed, 2008-01-23 at 14:55 -0500, seth vidal wrote: > > On Wed, 2008-01-23 at 19:35 +0100, Ralf Corsepius wrote: > > > Further: IMO, fedora legacy did not fail. It was discontinued by > > > management, because it collided the certain business interests. > > Ralf, > > I know there's no way to convince you of this, > No there isn't. Sad. > This thread added further to this. It once again made it clear that many > parties being involved into Fedora aren't willing in implementing a > Fedora LTS or simply extending the lifetime of Fedora for various > reasons - We will see if Ubuntu LTS will be a success. I would assume it > to further contribute to Fedora loosing ground. The people who were supposed do do the work, didn't. That's how OSS projects die, > > however, this isn't at > > all what happened. Legacy just died. > As I see it, it died, because people wanted to let it to die for various > different individual motivations. ... and not enough people stepped up to keep it alive. This was /not/ the result of some "Red Hat conspiracy", Fedora Legacy could very well have gone its own way, /if there had been enough interest/. Much more irritating as competition than a "Fedora LTS" are projects like CentOS, and those are doing well. To give my own perspective: Yes, we do use Fedora day-to-day here, and sometimes the new version/EOL came at /very/ incovenient moments, so we used Fedora Legacy, but only for a couple of months. Then we moved our servers over to White Box and now CentOS (long enough lifetime to allow planing upgrades), the workstations at the computer labs (via kickstart) can usually be migrated over a weekend (after some testing on guinea pigs). So our (in any case very limited) need for Fedora Legacy went away. > > It wasn't decided or dictated by > > anyone other than the reality that nothing had happened for months. > Yes, but not because the "product sucked", the project was poorly > implemented and poorly lead. Maybe. Do it better this time around. > Anyway, meanwhile, things in Fedora-land have changed. > > What prevents Fedora from launching a "Fedora LTS" as part of Fedora, > using the Fedora infrastructure, e.g. by simply imply declaring "Fedora > 7" life time's extended for, say 2 years, when FC9 comes out? > > The price would be fairly small. s/fairly small/extremely large/ > In particular, the infrastructure > already is in place. All what would have to be implemented would be some > regulations/conventions concerning "ABI/APIs" and ACLs. And having /three/ branches of Fedora instead of /two/ means roughly 50% more manpower, a resource that is sorely lacking as things stand. Moreover, you need more of the (very scarce!) people willing to do the thankless job of backporting bugfixes to ancient codebases. This requires /much/ more expertise on the code than just taking the upstream package, following the discussions of the developers and applying urgent proposed patches to the current codebase. In essence, when you follow upstream, there are many eyes and hands upstream that do most of the hard work for the packager; when you maintain a legacy package, you are almost on your own. No, "then just get the newest package then and integrate it with the rest" doesn't cut it. If I want LTS it is exactly because I don't want ABI/API or configuration changes /at all/. And, again, if you really want LTS, RHEL or CentOS fill that niche nicely. Sure, it is not exactly Fedora, it doesn't have all the glitter, but it works. > After these 2 years, you'd have the results of a fair comparison to > "Fedora". If it goes down the drain, so be it ... > > No one wanted to take on the rather large effort to keep it going. It > > stopped. There was no management who discontinued it. > May-be there had not been an explicit RH management decision on letting > it die. But there also had been no will to support it. Because of the large effort required, that no one stepped up to commit? > However, I recall FESCO (or had it been FAB?) having decided on FC's > short life-time Very good idea, helps keeping the distribution focused on bleeding edge and minimizes spreadout of the (very limited!) developers. > and to support EPEL. Helps bridge the RHEL/CentOS <--> Fedora difference, nice idea. > Both decisions have been severe > mistakes, IMO. Disagree strongly. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From vonbrand at inf.utfsm.cl Fri Jan 25 12:58:15 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Fri, 25 Jan 2008 09:58:15 -0300 Subject: long term support release In-Reply-To: <1201250321.17905.251.camel@beck.corsepiu.local> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> Message-ID: <200801251258.m0PCwFr7012189@laptop13.inf.utfsm.cl> Ralf Corsepius wrote: [...] > Also, wouldn't you consider the fact Ubuntu launches "Ubuntu LTS" to be > evidence enough that others see a market nice? Ubuntu LTS is the counterpart to RHEL. > I see it, too. Initially people chose Fedora as replacement for RHL. > Fedora didn't fill this gap and still hasn't managed to fill this gap. Any hard numbers on this? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From vonbrand at inf.utfsm.cl Fri Jan 25 13:07:15 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Fri, 25 Jan 2008 10:07:15 -0300 Subject: long term support release In-Reply-To: <20080125093517.GA16080@free.fr> References: <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> Message-ID: <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> Patrice Dumas wrote: > On Fri, Jan 25, 2008 at 12:26:49AM -0900, Jeff Spaleta wrote: > > On Jan 25, 2008 12:08 AM, Patrice Dumas wrote: > > > Unless I am wrong new builds aren't allowed for EOL releases. And I also > > > guess that at some point mirrors are shut down. Not doing those 2 things > > > would really allow for a fedora LTS. > > > > Until someone comes up with a sound plan for an LTS deliverable that > > communicates expectations on quality, I don't see a reason to just > > open up the trees for random people to update random packages whenever > > they want to. > > Random packages, maybe, but not random people, please. The "non-random" people are in short supply... > And there should not be any quality expectation just like for fedora > itself. What is the point then? "Come, run FLTS, a slowly rotting heap of bits kept on long-term (on and off) life support just because" doesn't sound too inviting... Besides, Fedora users /have/ quality expectations. Perhaps somewhat lower than RHEL; and aiming in a different direction, so they are different just by that. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From valent.turkovic at gmail.com Fri Jan 25 13:27:12 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Fri, 25 Jan 2008 14:27:12 +0100 Subject: selinux breaks revisor In-Reply-To: <47997AA8.3020305@filteredperception.org> References: <47963470.70009@gmail.com> <20080124232417.GF13888@redhat.com> <20080124185732.06966542@redhat.com> <47992AD2.7080904@filteredperception.org> <20080125005637.GK13888@redhat.com> <47993483.70804@filteredperception.org> <20080125013052.GL13888@redhat.com> <47994036.7030000@filteredperception.org> <20080124210658.5b0bd524@redhat.com> <604aa7910801242114i36798306qa46a43ab83e233a3@mail.gmail.com> <47997AA8.3020305@filteredperception.org> Message-ID: <4799E3B0.2090407@gmail.com> Douglas McClendon wrote: > Jeff Spaleta wrote: >> 2008/1/24 Jesse Keating : >>> Maybe I missed that, but every /rpm/ is buildable by non-root. It's >>> when you start talking about /composing/ releases and Live images that >>> root privs are needed (or enoug privs to make loopback devices). >> >> make loopback devices.... does fuse provide a non-root way to deal >> with this here? > > I think there are historical threads about the security/code-quality and > how it related to the decision of requiring root to add users to the > fuse group. Sounded like fuse might get the job done someday, but > someday wasn't quite here yet. > > Still, for doing composes as non-root I like my qemu 'qfakeroot', as it > handles everything nicely (but slowly). I.e. I imagine running into What still prevents kqemu module being shipped with fedora? That speeds things tremendously! Valent. From emmanuel.seyman at club-internet.fr Fri Jan 25 13:28:10 2008 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Fri, 25 Jan 2008 14:28:10 +0100 Subject: long term support release In-Reply-To: <20080125112959.baaf72d3.mschwendt.tmp0701.nospam@arcor.de> References: <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <20080125090654.GA3062@orient.maison.lan> <1201253280.17905.280.camel@beck.corsepiu.local> <20080125094711.GA3298@orient.maison.lan> <20080125112959.baaf72d3.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20080125132810.GA4474@orient.maison.lan> * Michael Schwendt [25/01/2008 11:35] : > > Do you expect anyone outside the Fedora Project to duplicate existing > Fedora Infrastructure, such as bugzilla, CVS+FAS, lookaside cache, > buildsys for multiple architectures, master repos, introduce a new GPG > key, switch mailing-lists, advertise the whole thing as a non-Fedora > project? That would make it much more difficult. No, that's just the burden that rpmfusion.org has imposed on itself. IMHO, the minimal requirements are : - a bugtracker - a VCS - at least two mailing-lists (for users and developpers, respectively) - a web/ftp repo All of which shouldn't take more than a few hours to setup on Fedora, CentOS or RHEL. This doesn't scale well, if at all and you're going to run into bandwidth problems very soon if you're the slightest bit succesful but this should get you started. And, as you've pointed out, an LTS project will start having human problems long before it has infrastructure ones. Emmanuel From sundaram at fedoraproject.org Fri Jan 25 13:43:15 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 25 Jan 2008 19:13:15 +0530 Subject: selinux breaks revisor In-Reply-To: <4799E3B0.2090407@gmail.com> References: <47963470.70009@gmail.com> <20080124232417.GF13888@redhat.com> <20080124185732.06966542@redhat.com> <47992AD2.7080904@filteredperception.org> <20080125005637.GK13888@redhat.com> <47993483.70804@filteredperception.org> <20080125013052.GL13888@redhat.com> <47994036.7030000@filteredperception.org> <20080124210658.5b0bd524@redhat.com> <604aa7910801242114i36798306qa46a43ab83e233a3@mail.gmail.com> <47997AA8.3020305@filteredperception.org> <4799E3B0.2090407@gmail.com> Message-ID: <4799E773.9090001@fedoraproject.org> Valent Turkovic wrote: > > What still prevents kqemu module being shipped with fedora? That speeds > things tremendously! This question has been asked before. The module is not in the upstream kernel. You can check out kvm instead. Rahul From lesmikesell at gmail.com Fri Jan 25 13:35:37 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 25 Jan 2008 07:35:37 -0600 Subject: long term support release In-Reply-To: <20080125094711.GA3298@orient.maison.lan> References: <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <20080125090654.GA3062@orient.maison.lan> <1201253280.17905.280.camel@beck.corsepiu.local> <20080125094711.GA3298@orient.maison.lan> Message-ID: <4799E5A9.2080303@gmail.com> Emmanuel Seyman wrote: > >> Actually, I assume most people being in real need for a RHL replacement >> have quit Fedora long time ago. > > Well, I'm still here and Fedora fills my needs better than RHL ever did. > > Emmanuel "4.2 was nice, though" Seyman If you would be happy with a still-supported FC6, is there any reason you couldn't run CentOS 5.1 and be equally happy for several more years? As far as I can tell they are close enough... What's missing for you? -- Les Mikesell lesmikesell at gmail.com From berrange at redhat.com Fri Jan 25 13:48:38 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 25 Jan 2008 13:48:38 +0000 Subject: selinux breaks revisor In-Reply-To: <4799E3B0.2090407@gmail.com> References: <20080124185732.06966542@redhat.com> <47992AD2.7080904@filteredperception.org> <20080125005637.GK13888@redhat.com> <47993483.70804@filteredperception.org> <20080125013052.GL13888@redhat.com> <47994036.7030000@filteredperception.org> <20080124210658.5b0bd524@redhat.com> <604aa7910801242114i36798306qa46a43ab83e233a3@mail.gmail.com> <47997AA8.3020305@filteredperception.org> <4799E3B0.2090407@gmail.com> Message-ID: <20080125134838.GA7237@redhat.com> On Fri, Jan 25, 2008 at 02:27:12PM +0100, Valent Turkovic wrote: > Douglas McClendon wrote: > >Jeff Spaleta wrote: > >>2008/1/24 Jesse Keating : > >>>Maybe I missed that, but every /rpm/ is buildable by non-root. It's > >>>when you start talking about /composing/ releases and Live images that > >>>root privs are needed (or enoug privs to make loopback devices). > >> > >>make loopback devices.... does fuse provide a non-root way to deal > >>with this here? > > > >I think there are historical threads about the security/code-quality and > >how it related to the decision of requiring root to add users to the > >fuse group. Sounded like fuse might get the job done someday, but > >someday wasn't quite here yet. > > > >Still, for doing composes as non-root I like my qemu 'qfakeroot', as it > >handles everything nicely (but slowly). I.e. I imagine running into > > What still prevents kqemu module being shipped with fedora? That speeds > things tremendously! It is buggy as hell and no one is actively working on fixing it, and it is not guarenteed secure Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From lesmikesell at gmail.com Fri Jan 25 13:56:48 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 25 Jan 2008 07:56:48 -0600 Subject: long term support release In-Reply-To: <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> Message-ID: <4799EAA0.7030700@gmail.com> Jeff Spaleta wrote: > On Jan 24, 2008 11:38 PM, Ralf Corsepius wrote: >> Also, wouldn't you consider the fact Ubuntu launches "Ubuntu LTS" to be >> evidence enough that others see a market nice? > > I'm pretty sure that Ubuntu LTS is something that Canonical as a > business entity as chosen to launch and leverages as part of its > business model and is not in point of fact relying primarily on > community manpower to make the LTS offering actually work. Find me a > business entity who would like to do something similar in Fedora space > and I'll gladly talk to them about making room in the project. How about a slight variation on the fedora LTS plan that might vastly reduce the needed work and let people keep running without the dangers of going without security fixes? What if the versions supported were the ones used as the base of the RHEL cuts, and the subsequent updates were recompiled from the CentOS source RPM's? There's a certain amount of incest or irony there, depending on how you look at it, but isn't re-using work what free software is supposed to be all about? In some cases you might need to re-enable some features removed in RHEL (as CentosPlus does with the kernel) but the changes should all be pretty obvious to someone with both source packages. And it would be nice if additional feature-enabled packages made it into the Centosplus repo in the cases where a fedora packager wanted to maintain them. I could see why RH might oppose this for business reasons - but if that's the case they should just say so. -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Fri Jan 25 14:00:17 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 25 Jan 2008 08:00:17 -0600 Subject: long term support release In-Reply-To: <200801250924.29871.opensource@till.name> References: <1201058211.3001.79.camel@gandalf.cobite.com> <200801241528.m0OFSAk8009592@laptop13.inf.utfsm.cl> <479969D1.8010202@gmail.com> <200801250924.29871.opensource@till.name> Message-ID: <4799EB71.4010000@gmail.com> Till Maas wrote: >>>> Or several, if the primary one won't >>>> include Sun Java, vlc + codecs, and Nvidia/Ati drivers. >>> EPEL doesn't include software that can't be redistributed legally as open >>> source, as it is part of Fedora. Fine with me, BTW. >> If this repository is unwilling to provide all packages, is there a >> process in place to permit the other necessary repositories to be >> enabled without conflicts? Or is there another repository with a more >> inclusive policy? > > With the yum-priorities plugin, you can give priorities to repositories. > Repositories with a higher priority cannot overwrite packages from > repositories with a lower priority. I think you can end up with problems that are even harder to fix if you do this and then the wrong repo updates a library. -- Les Mikesell lesmikesell at gmail.com From rhally at mindspring.com Fri Jan 25 14:05:42 2008 From: rhally at mindspring.com (Richard Hally) Date: Fri, 25 Jan 2008 09:05:42 -0500 Subject: long term support release In-Reply-To: <604aa7910801250150g3e2b6732we481ef783f83c240@mail.gmail.com> References: <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <604aa7910801250150g3e2b6732we481ef783f83c240@mail.gmail.com> Message-ID: <4799ECB6.4070103@mindspring.com> Jeff Spaleta wrote: > On Jan 25, 2008 12:35 AM, Patrice Dumas wrote: snip > there needs to be some plan to actually make sure that > happens so we don't mislead users. A purpose and scope defined well > enough so that I can track some sort of performance metric. > > -jef > Does such a thing("some sort of performance metric") exist for Fedora itself? Richard From jwright at midlandscc.net Fri Jan 25 14:12:34 2008 From: jwright at midlandscc.net (john wright) Date: Fri, 25 Jan 2008 08:12:34 -0600 Subject: long term support release In-Reply-To: <4799EB71.4010000@gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <200801241528.m0OFSAk8009592@laptop13.inf.utfsm.cl> <479969D1.8010202@gmail.com> <200801250924.29871.opensource@till.name> <4799EB71.4010000@gmail.com> Message-ID: <4799EE52.4020904@midlandscc.net> I seem to have gotten into something I never intended. How do I dissenroll from this mailing list?? Sorry, it looks very interesting, but 100 emails a day is swamping my email box. Les Mikesell wrote: > Till Maas wrote: > >>>>> Or several, if the primary one won't >>>>> include Sun Java, vlc + codecs, and Nvidia/Ati drivers. >>>> EPEL doesn't include software that can't be redistributed legally >>>> as open >>>> source, as it is part of Fedora. Fine with me, BTW. >>> If this repository is unwilling to provide all packages, is there a >>> process in place to permit the other necessary repositories to be >>> enabled without conflicts? Or is there another repository with a more >>> inclusive policy? >> >> With the yum-priorities plugin, you can give priorities to >> repositories. Repositories with a higher priority cannot overwrite >> packages from repositories with a lower priority. > > I think you can end up with problems that are even harder to fix if > you do this and then the wrong repo updates a library. > From denis at poolshark.org Fri Jan 25 14:14:26 2008 From: denis at poolshark.org (Denis Leroy) Date: Fri, 25 Jan 2008 15:14:26 +0100 Subject: long term support release In-Reply-To: <200801251256.m0PCu4hR009704@laptop13.inf.utfsm.cl> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <200801251256.m0PCu4hR009704@laptop13.inf.utfsm.cl> Message-ID: <4799EEC2.3090500@poolshark.org> Horst H. von Brand wrote: > Ralf Corsepius wrote: >> On Wed, 2008-01-23 at 14:55 -0500, seth vidal wrote: >>> On Wed, 2008-01-23 at 19:35 +0100, Ralf Corsepius wrote: >>>> Further: IMO, fedora legacy did not fail. It was discontinued by >>>> management, because it collided the certain business interests. > >>> Ralf, >>> I know there's no way to convince you of this, > >> No there isn't. > > Sad. > >> This thread added further to this. It once again made it clear that many >> parties being involved into Fedora aren't willing in implementing a >> Fedora LTS or simply extending the lifetime of Fedora for various >> reasons - We will see if Ubuntu LTS will be a success. I would assume it >> to further contribute to Fedora loosing ground. > > The people who were supposed do do the work, didn't. That's how OSS > projects die, > >>> however, this isn't at >>> all what happened. Legacy just died. > >> As I see it, it died, because people wanted to let it to die for various >> different individual motivations. > > ... and not enough people stepped up to keep it alive. This was /not/ the > result of some "Red Hat conspiracy", Fedora Legacy could very well have > gone its own way, /if there had been enough interest/. Much more irritating > as competition than a "Fedora LTS" are projects like CentOS, and those are > doing well. My opinion also. There simply wasn't enough traction, and it's understandable as back-porting security fixes is not exactly a fun job. Certainly if enough people are interested, nothing is preventing a group of motivated contributors from starting again. Pick a Fedora version and build from there. Personally I would wait for critical projects such as NetworkManager and dbus to stabilize a bit before embarking on a project like that. -denis From naheemzaffar at gmail.com Fri Jan 25 14:21:33 2008 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Fri, 25 Jan 2008 14:21:33 +0000 Subject: long term support release In-Reply-To: <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> Message-ID: <3adc77210801250621r798f8049g5dd4cf3f0301472d@mail.gmail.com> On 25/01/2008, Jeff Spaleta wrote: > Until someone comes up with a sound plan for an LTS deliverable that > communicates expectations on quality, I don't see a reason to just > open up the trees for random people to update random packages whenever > they want to. Talking as end user (who will always like to be on the latest release -so not only is this), would it not be possible to have some natural limit to a releases life? Something like: Standard support - what we get now. Around 13 months depending on releases. + Reactive support - an additional time period where the community is willing to provide updates to key packages using the same structure for the standard updates. For this there MUST be a community member willing to provide updates for the key packages - even if it @RH for supported releases. Key packages to be covered should be kernel, SElinux, Firefox and a few other packages, probably server related such as apache as they will probably need the longer release cycles. As long as there is support for each and everyone of these key packages, the release should be supported. As soon as even one is dropped, the release is EOL. For this you will probably need to allow packages to be orphaned per release. There may be a need to limit which releases will follow this structure and have a maximum life span too. A good proposal or total crack? From mschwendt.tmp0701.nospam at arcor.de Fri Jan 25 14:26:39 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 25 Jan 2008 15:26:39 +0100 Subject: long term support release In-Reply-To: <20080125132810.GA4474@orient.maison.lan> References: <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <20080125090654.GA3062@orient.maison.lan> <1201253280.17905.280.camel@beck.corsepiu.local> <20080125094711.GA3298@orient.maison.lan> <20080125112959.baaf72d3.mschwendt.tmp0701.nospam@arcor.de> <20080125132810.GA4474@orient.maison.lan> Message-ID: <20080125152639.84488a66.mschwendt.tmp0701.nospam@arcor.de> On Fri, 25 Jan 2008 14:28:10 +0100, Emmanuel Seyman wrote: > * Michael Schwendt [25/01/2008 11:35] : > > > > Do you expect anyone outside the Fedora Project to duplicate existing > > Fedora Infrastructure, such as bugzilla, CVS+FAS, lookaside cache, > > buildsys for multiple architectures, master repos, introduce a new GPG > > key, switch mailing-lists, advertise the whole thing as a non-Fedora > > project? That would make it much more difficult. > > No, that's just the burden that rpmfusion.org has imposed on itself. > > IMHO, the minimal requirements are : > > - a bugtracker > - a VCS > - at least two mailing-lists (for users and developpers, respectively) > - a web/ftp repo And who builds the packages? Manual builds in mock done by a person with access to x86_64/i386 (and possibly another one for ppc)? You will quickly find that this is not just error-prone, it doesn't scale well and you will see the need to set up a buildsys (e.g. Plague with srpm upload enabled). From emmanuel.seyman at club-internet.fr Fri Jan 25 14:40:44 2008 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Fri, 25 Jan 2008 15:40:44 +0100 Subject: long term support release In-Reply-To: <20080125152639.84488a66.mschwendt.tmp0701.nospam@arcor.de> References: <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <20080125090654.GA3062@orient.maison.lan> <1201253280.17905.280.camel@beck.corsepiu.local> <20080125094711.GA3298@orient.maison.lan> <20080125112959.baaf72d3.mschwendt.tmp0701.nospam@arcor.de> <20080125132810.GA4474@orient.maison.lan> <20080125152639.84488a66.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20080125144044.GA5257@orient.maison.lan> * Michael Schwendt [25/01/2008 15:25] : > > And who builds the packages? My bad. Add a buildsystem to the list. This doesn't change my point that setting up a third-party repo to provide LTS for a specfic version of Fedora is not (in terms of technical ressources) complicated. Arguing that it is (as Ralf is doing) serves, IMHO, as a bad excuse for not trying. Emmanuel From pertusus at free.fr Fri Jan 25 15:26:14 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 25 Jan 2008 16:26:14 +0100 Subject: long term support release In-Reply-To: <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> References: <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> Message-ID: <20080125152614.GA2975@free.fr> On Fri, Jan 25, 2008 at 10:07:15AM -0300, Horst H. von Brand wrote: > > Besides, Fedora users /have/ quality expectations. Perhaps somewhat lower > than RHEL; and aiming in a different direction, so they are different just > by that. Users have no way to force packagers to provide for a given level of quality. So, if fedora users have quality expectation, it can only be false expectations. -- Pat From jkeating at redhat.com Fri Jan 25 15:26:16 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 25 Jan 2008 10:26:16 -0500 Subject: long term support release In-Reply-To: <4799EAA0.7030700@gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> <4799EAA0.7030700@gmail.com> Message-ID: <20080125102616.7605825b@redhat.com> On Fri, 25 Jan 2008 07:56:48 -0600 Les Mikesell wrote: > How about a slight variation on the fedora LTS plan that might vastly > reduce the needed work and let people keep running without the > dangers of going without security fixes? What if the versions > supported were the ones used as the base of the RHEL cuts, and the > subsequent updates were recompiled from the CentOS source RPM's? > There's a certain amount of incest or irony there, depending on how > you look at it, but isn't re-using work what free software is > supposed to be all about? > > In some cases you might need to re-enable some features removed in > RHEL (as CentosPlus does with the kernel) but the changes should all > be pretty obvious to someone with both source packages. And it would > be nice if additional feature-enabled packages made it into the > Centosplus repo in the cases where a fedora packager wanted to > maintain them. > > I could see why RH might oppose this for business reasons - but if > that's the case they should just say so. What's the point? Just the warm/fuzzy of being able to say "It's Fedora!" ? With EPEL you can get just about all the functionality you need, with a few minor exceptions. I'm not sure I get the point of rebuilding things again and pushing them out through a different update system. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Fri Jan 25 15:32:48 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 25 Jan 2008 16:32:48 +0100 (CET) Subject: [ANSWER] Fonts and Fedora spins Message-ID: <17444.192.54.193.53.1201275168.squirrel@rousalka.dyndns.org> Hi, To all the Fedora spin maintainers out there, please note the following: 1. The main fonts group was changed from base-x to fonts at Fedora 8 time. 2. This change may not have been obvious then because font packages were moved progressively, but it is pretty effective now. 3. Current fonts comps organisation is described in http://fedoraproject.org/wiki/SIGs/Fonts/Packaging/Policy (as reviewed by FESCO) Basically - distro-wide modern fonts are in the fonts group - distro-wide legacy fonts are in legacy-fonts - script-specific fonts are in the corresponding localization groups There are still some fonts leftovers in base-x that no one dared nuke yet, but they're only used by non-fontconfig legacy apps. Therefore if you only include base-x in your spin as in pre-Fedora 8 times your font selection is going to be underwhelming Regards, -- Nicolas Mailhot From jkeating at redhat.com Fri Jan 25 15:31:44 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 25 Jan 2008 10:31:44 -0500 Subject: long term support release In-Reply-To: <20080125093517.GA16080@free.fr> References: <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> Message-ID: <20080125103144.68eec1ff@redhat.com> On Fri, 25 Jan 2008 10:35:17 +0100 Patrice Dumas wrote: > And there should not be any quality expectation just like for fedora > itself. Except when you start throwing the term LTS out, people expect there to be long term stability and quality, or else why would they use it? And you know, there is a Fedora based release that promises long term stability and quality... -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Jan 25 15:33:35 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 25 Jan 2008 10:33:35 -0500 Subject: long term support release In-Reply-To: <20080125152614.GA2975@free.fr> References: <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> <20080125152614.GA2975@free.fr> Message-ID: <20080125103335.0d5adacf@redhat.com> On Fri, 25 Jan 2008 16:26:14 +0100 Patrice Dumas wrote: > Users have no way to force packagers to provide for a given level of > quality. > > So, if fedora users have quality expectation, it can only be false > expectations. Yet we have things like the Security team who have taken up the mantel of ensuring that security updates go out for the packages we shipped in "supported" releases, regardless of what happens to the owner of that package. They're having a hard enough time getting volunteers for this effort just for the 2 live releases, let along adding N number of LTS releases. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Jan 25 15:34:42 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 25 Jan 2008 10:34:42 -0500 Subject: long term support release In-Reply-To: <3adc77210801250621r798f8049g5dd4cf3f0301472d@mail.gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <3adc77210801250621r798f8049g5dd4cf3f0301472d@mail.gmail.com> Message-ID: <20080125103442.5611c0f5@redhat.com> On Fri, 25 Jan 2008 14:21:33 +0000 "Naheem Zaffar" wrote: > For this you will probably need to allow packages to be orphaned per > release. > > There may be a need to limit which releases will follow this structure > and have a maximum life span too. > > A good proposal or total crack? I challenge you to define a set of Key packages that will satisfy the users of an LTS release. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Fri Jan 25 15:37:47 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 25 Jan 2008 16:37:47 +0100 Subject: long term support release In-Reply-To: <20080125103144.68eec1ff@redhat.com> References: <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <20080125103144.68eec1ff@redhat.com> Message-ID: <20080125153747.GB2975@free.fr> On Fri, Jan 25, 2008 at 10:31:44AM -0500, Jesse Keating wrote: > On Fri, 25 Jan 2008 10:35:17 +0100 > Patrice Dumas wrote: > > > And there should not be any quality expectation just like for fedora > > itself. > > Except when you start throwing the term LTS out, people expect there to > be long term stability and quality, or else why would they use it? And They should not as long as it is based on volunteers work. > you know, there is a Fedora based release that promises long term > stability and quality... I know, but in that case there are customers, it is very different, there are contracts. -- Pat From pertusus at free.fr Fri Jan 25 15:41:27 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 25 Jan 2008 16:41:27 +0100 Subject: long term support release In-Reply-To: <20080125103335.0d5adacf@redhat.com> References: <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> <20080125152614.GA2975@free.fr> <20080125103335.0d5adacf@redhat.com> Message-ID: <20080125154127.GC2975@free.fr> On Fri, Jan 25, 2008 at 10:33:35AM -0500, Jesse Keating wrote: > > Yet we have things like the Security team who have taken up the mantel > of ensuring that security updates go out for the packages we shipped in > "supported" releases, regardless of what happens to the owner of that > package. They're having a hard enough time getting volunteers for this > effort just for the 2 live releases, let along adding N number of LTS > releases. It is not because there are institutional agreements aimed at reducing, for example, security issues, that it will work, since people are not paid for that and there is no contract. Nobody is asking Security team to do things in fedora LTS. -- Pat From vonbrand at inf.utfsm.cl Fri Jan 25 15:42:49 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Fri, 25 Jan 2008 12:42:49 -0300 Subject: long term support release In-Reply-To: <4799EAA0.7030700@gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> <4799EAA0.7030700@gmail.com> Message-ID: <200801251542.m0PFgnhQ014468@laptop13.inf.utfsm.cl> Les Mikesell wrote: > Jeff Spaleta wrote: > > On Jan 24, 2008 11:38 PM, Ralf Corsepius wrote: > >> Also, wouldn't you consider the fact Ubuntu launches "Ubuntu LTS" to be > >> evidence enough that others see a market nice? > > I'm pretty sure that Ubuntu LTS is something that Canonical as a > > business entity as chosen to launch and leverages as part of its > > business model and is not in point of fact relying primarily on > > community manpower to make the LTS offering actually work. Find me a > > business entity who would like to do something similar in Fedora space > > and I'll gladly talk to them about making room in the project. > How about a slight variation on the fedora LTS plan that might vastly > reduce the needed work and let people keep running without the dangers > of going without security fixes? What if the versions supported were > the ones used as the base of the RHEL cuts, and the subsequent updates > were recompiled from the CentOS source RPM's? There's a certain > amount of incest or irony there, depending on how you look at it, but > isn't re-using work what free software is supposed to be all about? I don't see how that is less work (for the distribution-hackers, that is) than just suggesting going with CentOS + CentOSPlus + EPEL... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From jkeating at redhat.com Fri Jan 25 15:43:07 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 25 Jan 2008 10:43:07 -0500 Subject: long term support release In-Reply-To: <20080125153747.GB2975@free.fr> References: <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <20080125103144.68eec1ff@redhat.com> <20080125153747.GB2975@free.fr> Message-ID: <20080125104307.382ce039@redhat.com> On Fri, 25 Jan 2008 16:37:47 +0100 Patrice Dumas wrote: > They should not as long as it is based on volunteers work. The greater mass of users just don't understand this. They don't care who is doing the work, if you term it LTS they expect LTS qualities. > > > you know, there is a Fedora based release that promises long term > > stability and quality... > > I know, but in that case there are customers, it is very different, > there are contracts. Not with CentOS there isn't. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dcbw at redhat.com Fri Jan 25 15:42:21 2008 From: dcbw at redhat.com (Dan Williams) Date: Fri, 25 Jan 2008 10:42:21 -0500 Subject: long term support release In-Reply-To: <20080125154127.GC2975@free.fr> References: <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> <20080125152614.GA2975@free.fr> <20080125103335.0d5adacf@redhat.com> <20080125154127.GC2975@free.fr> Message-ID: <1201275741.1163.1.camel@localhost.localdomain> On Fri, 2008-01-25 at 16:41 +0100, Patrice Dumas wrote: > On Fri, Jan 25, 2008 at 10:33:35AM -0500, Jesse Keating wrote: > > > > Yet we have things like the Security team who have taken up the mantel > > of ensuring that security updates go out for the packages we shipped in > > "supported" releases, regardless of what happens to the owner of that > > package. They're having a hard enough time getting volunteers for this > > effort just for the 2 live releases, let along adding N number of LTS > > releases. > > It is not because there are institutional agreements aimed at reducing, > for example, security issues, that it will work, since people are not > paid for that and there is no contract. > > Nobody is asking Security team to do things in fedora LTS. That kinda defeats the meaning of LTS then, I think. (unless some other security team would step up to the plate) If an "LTS" release doesn't guarantee stability and timely security updates, it shouldn't be called LTS. Maybe "Extended Support" or "More Volunteer Updates". But not LTS... Dan From pertusus at free.fr Fri Jan 25 15:47:49 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 25 Jan 2008 16:47:49 +0100 Subject: long term support release In-Reply-To: <1201275741.1163.1.camel@localhost.localdomain> References: <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> <20080125152614.GA2975@free.fr> <20080125103335.0d5adacf@redhat.com> <20080125154127.GC2975@free.fr> <1201275741.1163.1.camel@localhost.localdomain> Message-ID: <20080125154749.GD2975@free.fr> On Fri, Jan 25, 2008 at 10:42:21AM -0500, Dan Williams wrote: > > That kinda defeats the meaning of LTS then, I think. (unless some other > security team would step up to the plate) > > If an "LTS" release doesn't guarantee stability and timely security > updates, it shouldn't be called LTS. Maybe "Extended Support" or "More > Volunteer Updates". But not LTS... The name is not the issue, as long as it is understood that it is a volunteer based project. It isn't in the fedora name, but fedora is a volunteer based project. -- Pat From pertusus at free.fr Fri Jan 25 15:50:59 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 25 Jan 2008 16:50:59 +0100 Subject: long term support release In-Reply-To: <20080125104307.382ce039@redhat.com> References: <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <20080125103144.68eec1ff@redhat.com> <20080125153747.GB2975@free.fr> <20080125104307.382ce039@redhat.com> Message-ID: <20080125155059.GE2975@free.fr> On Fri, Jan 25, 2008 at 10:43:07AM -0500, Jesse Keating wrote: > On Fri, 25 Jan 2008 16:37:47 +0100 > Patrice Dumas wrote: > > > They should not as long as it is based on volunteers work. > > The greater mass of users just don't understand this. They don't care > who is doing the work, if you term it LTS they expect LTS qualities. I don't care about the name, in fact, if you think LTS is badly choosen, another name may be chosed, it is not the issue here. It corresponds with a product based on fedora infrastructure, but with th epossibility to update after the EOL. Call it fedora Updates after EOL if you like it better. > > > you know, there is a Fedora based release that promises long term > > > stability and quality... > > > > I know, but in that case there are customers, it is very different, > > there are contracts. > > Not with CentOS there isn't. I thought you were speaking about RHEL. But Centos is exactly in the same case that 'fedora LTS' or fedora itself. Volunteers, no warranty, no contract. -- Pat From jkeating at redhat.com Fri Jan 25 15:50:41 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 25 Jan 2008 10:50:41 -0500 Subject: long term support release In-Reply-To: <20080125154749.GD2975@free.fr> References: <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> <20080125152614.GA2975@free.fr> <20080125103335.0d5adacf@redhat.com> <20080125154127.GC2975@free.fr> <1201275741.1163.1.camel@localhost.localdomain> <20080125154749.GD2975@free.fr> Message-ID: <20080125105041.6605e470@redhat.com> On Fri, 25 Jan 2008 16:47:49 +0100 Patrice Dumas wrote: > > If an "LTS" release doesn't guarantee stability and timely security > > updates, it shouldn't be called LTS. Maybe "Extended Support" or > > "More Volunteer Updates". But not LTS... > > The name is not the issue, as long as it is understood that it is a > volunteer based project. It isn't in the fedora name, but fedora is a > volunteer based project. What earthly reason would you have to run some old code set, with not even close to guaranteed updates, let alone timely ones, with little man power behind it, and the opportunity to be ignored by most package owners? And why aren't those reasons satisfied with RHEL/CentOS which doesn't have these problems? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From emmanuel.seyman at club-internet.fr Fri Jan 25 15:51:24 2008 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Fri, 25 Jan 2008 16:51:24 +0100 Subject: long term support release In-Reply-To: <20080125155059.GE2975@free.fr> References: <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <20080125103144.68eec1ff@redhat.com> <20080125153747.GB2975@free.fr> <20080125104307.382ce039@redhat.com> <20080125155059.GE2975@free.fr> Message-ID: <20080125155124.GA5809@orient.maison.lan> * Patrice Dumas [25/01/2008 16:48] : > > I thought you were speaking about RHEL. But Centos is exactly in the > same case that 'fedora LTS' or fedora itself. Volunteers, no warranty, > no contract. CentOS doesn't actually do the work of backporting security fixes only. They take the work done by Red Hat and just rebuild the .rpms. If Fedora LTS happens, it will not have this option. Emmanuel From vonbrand at inf.utfsm.cl Fri Jan 25 16:00:50 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Fri, 25 Jan 2008 13:00:50 -0300 Subject: long term support release In-Reply-To: <3adc77210801250621r798f8049g5dd4cf3f0301472d@mail.gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <3adc77210801250621r798f8049g5dd4cf3f0301472d@mail.gmail.com> Message-ID: <200801251600.m0PG0oP3023684@laptop13.inf.utfsm.cl> Naheem Zaffar wrote: [...] > Talking as end user (who will always like to be on the latest release > -so not only is this), would it not be possible to have some natural > limit to a releases life? 13-ish months, right now. Something like 4 to 7 months more than the hackers would like to provide on their own. Yes, I'm running rawhide, and see this (and other) mailing lists and discussions re Fedora. Once version N is out, a few developers stay to get it working right, the rest flocks to the exciting world of shiny new packages, baby-munching and brand new bugs to fix that is rawhide. Same thing has always happened with the kernel, and Gnome. It is for this same reason that the kernel moved away from the "stable/development series" split. > Something like: > > Standard support - what we get now. Around 13 months depending on releases. > + Reactive support - an additional time period where the community is > willing It isn't. Experimental data point. Not just for Fedora, look around at other community-driven open source projects. The "old/stable/legacy" branch usually has trouble getting manpower. And there we are normally talking a couple of years at the most, not the lifetime of e.g. RHEL or Ubuntu LTS. > to provide updates to key packages using the same structure > for the standard updates. Your key package is useless baggage for me. Who decides? Some set of key packages (however that is decided) just doesn't find sponsors willing to keep them up to date. What then? Just letting them rot is bad for the image of the distribution... The package I might be interested in keeping alive a few years longer might interest almost nobody else (yes, has happened to me; kept upgrading it locally). > For this there MUST be a community member > willing to provide updates for the key packages - even if it @RH for > supported releases. There aren't any volunteers, as this thread has amply shown. [...] > A good proposal or total crack? Please tell /in detail/ what the advantage would be against going with CentOS + EPEL. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From sundaram at fedoraproject.org Fri Jan 25 16:12:05 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 25 Jan 2008 21:42:05 +0530 Subject: long term support release In-Reply-To: <20080125155124.GA5809@orient.maison.lan> References: <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <20080125103144.68eec1ff@redhat.com> <20080125153747.GB2975@free.fr> <20080125104307.382ce039@redhat.com> <20080125155059.GE2975@free.fr> <20080125155124.GA5809@orient.maison.lan> Message-ID: <479A0A55.60409@fedoraproject.org> Emmanuel Seyman wrote: > * Patrice Dumas [25/01/2008 16:48] : >> I thought you were speaking about RHEL. But Centos is exactly in the >> same case that 'fedora LTS' or fedora itself. Volunteers, no warranty, >> no contract. > > CentOS doesn't actually do the work of backporting security fixes only. > They take the work done by Red Hat and just rebuild the .rpms. > > If Fedora LTS happens, it will not have this option. .. unless Fedora LTS is a rebuild of RHEL SRPMS. There might be some advantages to this worth considering. Rahul From rc040203 at freenet.de Fri Jan 25 16:04:35 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 25 Jan 2008 17:04:35 +0100 Subject: long term support release In-Reply-To: <20080125105041.6605e470@redhat.com> References: <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> <20080125152614.GA2975@free.fr> <20080125103335.0d5adacf@redhat.com> <20080125154127.GC2975@free.fr> <1201275741.1163.1.camel@localhost.localdomain> <20080125154749.GD2975@free.fr> <20080125105041.6605e470@redhat.com> Message-ID: <1201277076.17905.362.camel@beck.corsepiu.local> On Fri, 2008-01-25 at 10:50 -0500, Jesse Keating wrote: > On Fri, 25 Jan 2008 16:47:49 +0100 > Patrice Dumas wrote: > > > > If an "LTS" release doesn't guarantee stability and timely security > > > updates, it shouldn't be called LTS. Maybe "Extended Support" or > > > "More Volunteer Updates". But not LTS... > > > > The name is not the issue, as long as it is understood that it is a > > volunteer based project. It isn't in the fedora name, but fedora is a > > volunteer based project. > > What earthly reason would you have to run some old code set, with not > even close to guaranteed updates, let alone timely ones, with little > man power behind it, and the opportunity to be ignored by most package > owners? Because that's still better and more effective than getting lost in the Fedora upgrade maelstrom and getting lost in the bureaucracy Fedora suffers from and better than continuing to use a completely discontinued distro. > And why aren't those reasons satisfied with RHEL/CentOS which doesn't > have these problems? For me, CentOS is an ultra conservative, stagnating distro not meeting my demands. It may-be suitable for those who want to set up a server and run it with minimal support for the next 4 years - To me it's non interesting. Ralf From skvidal at fedoraproject.org Fri Jan 25 16:05:29 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 25 Jan 2008 11:05:29 -0500 Subject: long term support release In-Reply-To: <479A0A55.60409@fedoraproject.org> References: <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <20080125103144.68eec1ff@redhat.com> <20080125153747.GB2975@free.fr> <20080125104307.382ce039@redhat.com> <20080125155059.GE2975@free.fr> <20080125155124.GA5809@orient.maison.lan> <479A0A55.60409@fedoraproject.org> Message-ID: <1201277129.14800.25.camel@cutter> On Fri, 2008-01-25 at 21:42 +0530, Rahul Sundaram wrote: > Emmanuel Seyman wrote: > > * Patrice Dumas [25/01/2008 16:48] : > >> I thought you were speaking about RHEL. But Centos is exactly in the > >> same case that 'fedora LTS' or fedora itself. Volunteers, no warranty, > >> no contract. > > > > CentOS doesn't actually do the work of backporting security fixes only. > > They take the work done by Red Hat and just rebuild the .rpms. > > > > If Fedora LTS happens, it will not have this option. > > .. unless Fedora LTS is a rebuild of RHEL SRPMS. There might be some > advantages to this worth considering. > do we need another centos but with a fedora brand? I think the centos guys are doing a good job, personally. -sv From emmanuel.seyman at club-internet.fr Fri Jan 25 16:02:47 2008 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Fri, 25 Jan 2008 17:02:47 +0100 Subject: long term support release In-Reply-To: <479A0A55.60409@fedoraproject.org> References: <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <20080125103144.68eec1ff@redhat.com> <20080125153747.GB2975@free.fr> <20080125104307.382ce039@redhat.com> <20080125155059.GE2975@free.fr> <20080125155124.GA5809@orient.maison.lan> <479A0A55.60409@fedoraproject.org> Message-ID: <20080125160247.GA5952@orient.maison.lan> * Rahul Sundaram [25/01/2008 17:01] : > > .. unless Fedora LTS is a rebuild of RHEL SRPMS. There might be some > advantages to this worth considering. as ooposed to just using CentOS ? I don't see any. Emmanuel From lesmikesell at gmail.com Fri Jan 25 16:20:59 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 25 Jan 2008 10:20:59 -0600 Subject: long term support release In-Reply-To: <20080125102616.7605825b@redhat.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> <4799EAA0.7030700@gmail.com> <20080125102616.7605825b@redhat.com> Message-ID: <479A0C6B.1050004@gmail.com> Jesse Keating wrote: > >> How about a slight variation on the fedora LTS plan that might vastly >> reduce the needed work and let people keep running without the >> dangers of going without security fixes? What if the versions >> supported were the ones used as the base of the RHEL cuts, and the >> subsequent updates were recompiled from the CentOS source RPM's? >> There's a certain amount of incest or irony there, depending on how >> you look at it, but isn't re-using work what free software is >> supposed to be all about? >> >> In some cases you might need to re-enable some features removed in >> RHEL (as CentosPlus does with the kernel) but the changes should all >> be pretty obvious to someone with both source packages. And it would >> be nice if additional feature-enabled packages made it into the >> Centosplus repo in the cases where a fedora packager wanted to >> maintain them. >> >> I could see why RH might oppose this for business reasons - but if >> that's the case they should just say so. > > What's the point? Just the warm/fuzzy of being able to say "It's > Fedora!" ? Yes, it would be a big win for the fedora 'brand' perception to make it actually usable instead of just a rolling alpha/beta for RHEL. If you are going to argue that such a perception shouldn't exist, just say so instead of claiming that it's too hard or that failed earlier attempts prove it can't be done. > With EPEL you can get just about all the functionality you > need, with a few minor exceptions. I'm not sure I get the point of > rebuilding things again and pushing them out through a different update > system. That's *if* you uninstall fedora and re-install RHEL or CentOS, and then locate and install all of the matching packages you had, which may or may not be possible and it's certainly not easy. Shouldn't you reward the people who survived the wild and crazy changes that fedora makes in the first 2 revs after the RHEL cuts with a version that continues to run for a while without security worries? I think this would attract a lot more fedora users and be a good thing all the way around. Now for a *really* warm/fuzzy about the free software community, you could just converge this version's update repo with the corresponding EPEL/centos/centosplus repo contents and make them end up the same without a re-install or any duplication of infrastructure at all. I haven't done a whole lot of cross-rebuilding, but off the top of my head I can't think of anything that wouldn't work unchanged between FC6/Centos5 and if there are any they are probably artifacts of post-cut fedora-side updates to FC6 that wouldn't have necessarily been done with a converged plan. -- Les Mikesell lesmikesell at gmail.com From pertusus at free.fr Fri Jan 25 16:20:05 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 25 Jan 2008 17:20:05 +0100 Subject: long term support release In-Reply-To: <20080125105041.6605e470@redhat.com> References: <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> <20080125152614.GA2975@free.fr> <20080125103335.0d5adacf@redhat.com> <20080125154127.GC2975@free.fr> <1201275741.1163.1.camel@localhost.localdomain> <20080125154749.GD2975@free.fr> <20080125105041.6605e470@redhat.com> Message-ID: <20080125162005.GG2975@free.fr> On Fri, Jan 25, 2008 at 10:50:41AM -0500, Jesse Keating wrote: > On Fri, 25 Jan 2008 16:47:49 +0100 > Patrice Dumas wrote: > > > > If an "LTS" release doesn't guarantee stability and timely security > > > updates, it shouldn't be called LTS. Maybe "Extended Support" or > > > "More Volunteer Updates". But not LTS... > > > > The name is not the issue, as long as it is understood that it is a > > volunteer based project. It isn't in the fedora name, but fedora is a > > volunteer based project. > > What earthly reason would you have to run some old code set, with not > even close to guaranteed updates, let alone timely ones, with little > man power behind it, and the opportunity to be ignored by most package > owners? You cannot say by advance how a project like that would be successful. I personally think that, today, the project would not be succesful. It is much better than before the merge, because now the infrastructure is not a real issue, procedures can be the same than in fedora proper (legacy having very different procedures was for me a real blocker), openness has improved. Still the lack of co-ownership will certainly lead to have packages left to packagers that have no will to keep on doing vital updates in an Updates after EOL fedora. But as time goes by I am seing a trend of more involvement in other people packages and correspondingly more expertise in other people packages and also co-maintainership is improving. This opens more possibility for a successful Updates after EOL Fedora. At the same time I guess that users who favor stability are less and less using fedora, so it is not obvious which of these process is the faster. As a side note all you say may also be true in fedora (no guaranteed updates, let alone timely ones, with insufficient man power behind it, and the opportunity to be ignored by most package owners). It is not the case for all packages but it happens, and, once again there is no guarantee. > And why aren't those reasons satisfied with RHEL/CentOS which doesn't > have these problems? I would help for those who want to deploy fedora but don't want to upgrade at the fedora pace. -- Pat From vonbrand at inf.utfsm.cl Fri Jan 25 16:23:37 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Fri, 25 Jan 2008 13:23:37 -0300 Subject: long term support release In-Reply-To: <20080125154127.GC2975@free.fr> References: <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> <20080125152614.GA2975@free.fr> <20080125103335.0d5adacf@redhat.com> <20080125154127.GC2975@free.fr> Message-ID: <200801251623.m0PGNbuJ012679@laptop13.inf.utfsm.cl> Patrice Dumas wrote: > On Fri, Jan 25, 2008 at 10:33:35AM -0500, Jesse Keating wrote: > > Yet we have things like the Security team who have taken up the mantel > > of ensuring that security updates go out for the packages we shipped in > > "supported" releases, regardless of what happens to the owner of that > > package. They're having a hard enough time getting volunteers for this > > effort just for the 2 live releases, let along adding N number of LTS > > releases. > It is not because there are institutional agreements aimed at reducing, > for example, security issues, that it will work, since people are not > paid for that and there is no contract. > > Nobody is asking Security team to do things in fedora LTS. Now, cross your heart: Would /you/ run a LTS where there was /no/ QA or security team? At most for a month or so, until it is convenient to upgrade would be my answer. Feeling uneasy all the time. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From jkeating at redhat.com Fri Jan 25 16:22:54 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 25 Jan 2008 11:22:54 -0500 Subject: long term support release In-Reply-To: <479A0C6B.1050004@gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> <4799EAA0.7030700@gmail.com> <20080125102616.7605825b@redhat.com> <479A0C6B.1050004@gmail.com> Message-ID: <20080125112254.382c9e13@redhat.com> On Fri, 25 Jan 2008 10:20:59 -0600 Les Mikesell wrote: > Yes, it would be a big win for the fedora 'brand' perception to make > it actually usable instead of just a rolling alpha/beta for RHEL. If > you are going to argue that such a perception shouldn't exist, just > say so instead of claiming that it's too hard or that failed earlier > attempts prove it can't be done. I think there would be some value to having CentOS associated with the Fedora brand... > > > With EPEL you can get just about all the functionality you > > need, with a few minor exceptions. I'm not sure I get the point of > > rebuilding things again and pushing them out through a different > > update system. > > That's *if* you uninstall fedora and re-install RHEL or CentOS, and > then locate and install all of the matching packages you had, which > may or may not be possible and it's certainly not easy. Shouldn't > you reward the people who survived the wild and crazy changes that > fedora makes in the first 2 revs after the RHEL cuts with a version > that continues to run for a while without security worries? I think > this would attract a lot more fedora users and be a good thing all > the way around. Now for a *really* warm/fuzzy about the free > software community, you could just converge this version's update > repo with the corresponding EPEL/centos/centosplus repo contents and > make them end up the same without a re-install or any duplication of > infrastructure at all. I haven't done a whole lot of > cross-rebuilding, but off the top of my head I can't think of > anything that wouldn't work unchanged between FC6/Centos5 and if > there are any they are probably artifacts of post-cut fedora-side > updates to FC6 that wouldn't have necessarily been done with a > converged plan. Now you're talking about something different, a migration plan for Fedora -> EL based on said release. That I could see some great value in, and it shouldn't be too difficult to start working down this path, and getting into the heads of the EL creators that this is something we'd like to see made possible, rather than difficult, by the EL development. Sounds like a SIG to me... -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwilson at redhat.com Fri Jan 25 16:27:47 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Fri, 25 Jan 2008 11:27:47 -0500 Subject: long term support release In-Reply-To: <1201277129.14800.25.camel@cutter> References: <1201240697.17905.179.camel@beck.corsepiu.local> <479A0A55.60409@fedoraproject.org> <1201277129.14800.25.camel@cutter> Message-ID: <200801251127.47467.jwilson@redhat.com> On Friday 25 January 2008 11:05:29 am seth vidal wrote: > On Fri, 2008-01-25 at 21:42 +0530, Rahul Sundaram wrote: > > Emmanuel Seyman wrote: > > > * Patrice Dumas [25/01/2008 16:48] : > > >> I thought you were speaking about RHEL. But Centos is exactly in the > > >> same case that 'fedora LTS' or fedora itself. Volunteers, no warranty, > > >> no contract. > > > > > > CentOS doesn't actually do the work of backporting security fixes only. > > > They take the work done by Red Hat and just rebuild the .rpms. > > > > > > If Fedora LTS happens, it will not have this option. > > > > .. unless Fedora LTS is a rebuild of RHEL SRPMS. There might be some > > advantages to this worth considering. > > do we need another centos but with a fedora brand? I think the centos > guys are doing a good job, personally. I believe the trick is to just have the CentOS folks rename CentOS to Fedora LTS and otherwise just keep on doing what they've been doing... :) -- Jarod Wilson jwilson at redhat.com From lmacken at redhat.com Fri Jan 25 16:28:35 2008 From: lmacken at redhat.com (Luke Macken) Date: Fri, 25 Jan 2008 11:28:35 -0500 Subject: F9 Alpha spinning Message-ID: <20080125162835.GA19048@crow> Here are some details on the current live bits for F9 Alpha. -rw-r--r-- 1 root root 1.6G 2008-01-24 16:00 F9-Alpha-Developer-20080124.0.iso -rw-r--r-- 1 root root 740M 2008-01-24 16:13 F9-Alpha-FEL-i686-20080124.0.iso -rw-r--r-- 1 root root 3.6G 2008-01-24 16:52 F9-Alpha-games-i686-20080124.0.iso -rw-r--r-- 1 root root 714M 2008-01-24 14:51 F9-Alpha-i686-20080124.0.iso -rw-r--r-- 1 root root 647M 2008-01-24 15:20 F9-Alpha-KDE-i686-20080124.0.iso -rw-r--r-- 1 root root 755M 2008-01-24 15:34 F9-Alpha-KDE-x86_64-20080124.0.iso -rw-r--r-- 1 root root 770M 2008-01-24 15:10 F9-Alpha-x86_64-20080124.0.iso Below is a diff between the F8-Live-i686 and F9-Alpha-Live-i686 Desktop spins. new package libgdiplus-devel: 8584 new package xorg-x11-server-common: 38863 new package PolicyKit-gnome-libs: 40188 new package kerneloops: 52570 new package swfdec-gtk: 55786 new package gnome-panel-libs: 56936 new package swfdec-mozilla: 75911 new package libconfig: 120055 new package obex-data-server: 136538 new package at-spi-python: 170868 new package ncurses-base: 176949 new package pixman: 209556 new package scim-python: 247730 new package libcurl: 258148 new package libggz: 289477 new package libmtp: 398952 new package xorg-x11-drv-openchrome: 415754 new package ggz-client-libs: 434830 new package samyak-fonts: 457144 new package perl-Date-Manip: 458629 new package libtasn1: 466849 new package python-crypto: 571535 new package elilo: 613010 new package abyssinica-fonts: 649794 new package ncurses-libs: 668620 new package swfdec: 958169 new package gvfs: 1700127 new package totem-pl-parser: 2627745 new package VLGothic-fonts: 3831447 new package VLGothic-fonts-proportional: 3831790 new package gnome-settings-daemon: 6218660 new package mesa-libOSMesa: 7248256 new package scim-python-chinese: 7621164 new package libgweather: 14592282 new package vim-common: 16294034 new package dasher: 22111835 new package xulrunner: 24481155 crontabs grew 144 bytes (6.83%) (2107->2251) libopenraw-gnome grew 348 bytes (7.94%) (4384->4732) xorg-x11-drv-fbdev grew 380 bytes (1.84%) (20597->20977) irqbalance grew 400 bytes (1.85%) (21595->21995) m17n-contrib grew 469 bytes (1.28%) (36757->37226) pam_ccreds grew 497 bytes (1.49%) (33428->33925) smolt-firstboot grew 655 bytes (6.01%) (10893->11548) pcsc-lite-libs grew 848 bytes (2.44%) (34696->35544) dbus-x11 grew 884 bytes (3.63%) (24353->25237) numactl grew 896 bytes (1.00%) (89239->90135) gnome-bluetooth-libs grew 1278 bytes (1.02%) (124866->126144) xorg-x11-drv-evdev grew 1445 bytes (4.05%) (35642->37087) m17n-db-hindi grew 1717 bytes (21.74%) (7899->9616) sysreport grew 1783 bytes (5.30%) (33620->35403) libpciaccess grew 1796 bytes (7.21%) (24901->26697) sg3_utils-libs grew 2156 bytes (1.97%) (109392->111548) pciutils grew 2464 bytes (1.36%) (180975->183439) setroubleshoot grew 2541 bytes (1.11%) (229578->232119) gnome-keyring-pam grew 2556 bytes (8.89%) (28760->31316) libcap grew 2618 bytes (5.79%) (45230->47848) apr grew 2823 bytes (1.04%) (271801->274624) bc grew 2861 bytes (1.50%) (190964->193825) libsepol grew 2992 bytes (1.33%) (224692->227684) e2fsprogs-libs grew 3076 bytes (1.23%) (250016->253092) lohit-fonts-telugu grew 3100 bytes (1.78%) (174487->177587) device-mapper-libs grew 3680 bytes (4.25%) (86516->90196) glx-utils grew 3704 bytes (10.98%) (33736->37440) scim-chewing grew 4072 bytes (3.22%) (126383->130455) dbus-libs grew 4100 bytes (1.63%) (251944->256044) nash grew 4128 bytes (1.74%) (237698->241826) scim-sinhala grew 4140 bytes (6.19%) (66881->71021) libjpeg grew 4420 bytes (1.61%) (275021->279441) authconfig-gtk grew 4808 bytes (2.75%) (175143->179951) mkinitrd grew 4854 bytes (4.84%) (100334->105188) m17n-contrib-sinhala grew 5443 bytes (48.05%) (11327->16770) linuxwacom grew 5518 bytes (1.10%) (502293->507811) desktop-file-utils grew 5523 bytes (4.50%) (122601->128124) gnome-python2-gnomeprint grew 5547 bytes (1.27%) (437641->443188) bluez-utils-alsa grew 5856 bytes (13.67%) (42824->48680) m17n-contrib-telugu grew 6114 bytes (28.08%) (21776->27890) rsyslog grew 6922 bytes (1.45%) (477587->484509) ustr grew 7531 bytes (3.12%) (241610->249141) rhpxl grew 7783 bytes (2.36%) (329907->337690) xorg-x11-drv-mga grew 8319 bytes (4.91%) (169473->177792) taglib grew 8368 bytes (1.71%) (489415->497783) gtk-nodoka-engine grew 8948 bytes (9.32%) (96057->105005) nscd grew 9484 bytes (6.73%) (140911->150395) exempi grew 9692 bytes (1.39%) (698782->708474) gnome-menus grew 9841 bytes (1.57%) (626493->636334) dbus-glib grew 9970 bytes (2.10%) (473790->483760) libdhcp6client grew 10524 bytes (6.30%) (166956->177480) openldap grew 10658 bytes (1.76%) (604986->615644) nss_ldap grew 12224 bytes (2.17%) (562402->574626) dmidecode grew 14466 bytes (10.46%) (138266->152732) NetworkManager-vpnc grew 14477 bytes (4.58%) (316033->330510) system-config-rootpassword grew 14962 bytes (16.07%) (93118->108080) gstreamer-python grew 15266 bytes (1.64%) (933175->948441) rarian grew 15824 bytes (4.99%) (316947->332771) at-spi grew 16072 bytes (2.38%) (674624->690696) isomd5sum grew 17146 bytes (36.61%) (46840->63986) usbutils grew 17192 bytes (19.31%) (89044->106236) acl grew 17907 bytes (11.99%) (149361->167268) hicolor-icon-theme grew 17992 bytes (79.30%) (22688->40680) gnome-python2-desktop grew 18187 bytes (7.44%) (244527->262714) libdhcp grew 18665 bytes (13.75%) (135727->154392) which grew 20480 bytes (65.05%) (31485->51965) NetworkManager-gnome grew 20604 bytes (2.90%) (710665->731269) pam_krb5 grew 20943 bytes (8.06%) (259736->280679) system-config-language grew 21674 bytes (8.55%) (253576->275250) libxcb grew 22328 bytes (5.40%) (413804->436132) bluez-utils grew 22572 bytes (1.76%) (1280277->1302849) pygtksourceview grew 23100 bytes (36.06%) (64064->87164) libgpg-error grew 23525 bytes (12.14%) (193728->217253) glibmm24 grew 24411 bytes (5.25%) (465396->489807) fribidi grew 24912 bytes (17.19%) (144894->169806) gmime grew 24916 bytes (4.24%) (587824->612740) libuser grew 25215 bytes (1.56%) (1616562->1641777) xterm grew 25999 bytes (3.24%) (802644->828643) httpd grew 28595 bytes (1.12%) (2551734->2580329) libdhcp4client grew 28996 bytes (5.81%) (499144->528140) m17n-lib grew 30893 bytes (10.14%) (304750->335643) rhpl grew 31037 bytes (3.99%) (778235->809272) bind-utils grew 33408 bytes (10.87%) (307362->340770) NetworkManager grew 33657 bytes (1.42%) (2377366->2411023) dbus-python grew 36266 bytes (5.11%) (710089->746355) gnome-mag grew 36431 bytes (7.21%) (504936->541367) libXpm grew 37746 bytes (52.09%) (72467->110213) libgnomekbd grew 38042 bytes (6.68%) (569521->607563) pm-utils grew 39200 bytes (117.36%) (33402->72602) nautilus-sendto grew 42489 bytes (16.21%) (262118->304607) dhclient grew 42699 bytes (8.59%) (497288->539987) gtksourceview2 grew 42895 bytes (2.00%) (2148753->2191648) krb5-libs grew 45052 bytes (2.96%) (1522532->1567584) system-config-printer grew 56236 bytes (5.99%) (939482->995718) gnutls grew 58282 bytes (5.99%) (972804->1031086) libthai grew 60142 bytes (17.40%) (345628->405770) bluez-gnome grew 60576 bytes (22.56%) (268531->329107) mono-data grew 61605 bytes (1.21%) (5087435->5149040) libwnck grew 62234 bytes (5.42%) (1148126->1210360) gtk2-engines grew 63679 bytes (6.09%) (1045391->1109070) system-config-users grew 64047 bytes (4.40%) (1455495->1519542) gnokii grew 68723 bytes (4.36%) (1575916->1644639) rsync grew 73058 bytes (18.04%) (404896->477954) hal-info grew 75029 bytes (20.94%) (358305->433334) mesa-libGLU grew 77812 bytes (17.12%) (454428->532240) mdadm grew 83417 bytes (4.79%) (1743098->1826515) shared-mime-info grew 85852 bytes (9.51%) (902332->988184) compiz-gnome grew 87904 bytes (7.16%) (1227682->1315586) PolicyKit-gnome grew 89123 bytes (126.49%) (70457->159580) GConf2 grew 89585 bytes (1.68%) (5342705->5432290) dhcpv6-client grew 94965 bytes (54.70%) (173599->268564) ntfs-3g grew 107185 bytes (36.31%) (295187->402372) f-spot grew 110065 bytes (1.44%) (7621883->7731948) PolicyKit grew 121200 bytes (71.93%) (168495->289695) gnupg grew 126829 bytes (2.62%) (4841029->4967858) libgcrypt grew 132376 bytes (38.24%) (346204->478580) libopenraw grew 136838 bytes (101.68%) (134583->271421) pykickstart grew 141694 bytes (17.92%) (790784->932478) gnome-python2-gnomevfs grew 142165 bytes (87.24%) (162958->305123) hwdata grew 144093 bytes (15.63%) (921699->1065792) shadow-utils grew 144973 bytes (5.29%) (2739389->2884362) gnome-volume-manager grew 158480 bytes (7.38%) (2146417->2304897) vbetool grew 162208 bytes (139.43%) (116340->278548) openssl grew 166448 bytes (4.81%) (3459831->3626279) libselinux-python grew 171323 bytes (118.46%) (144622->315945) libsilc grew 180620 bytes (17.41%) (1037560->1218180) sound-juicer grew 182617 bytes (5.86%) (3114050->3296667) gnome-system-monitor grew 186353 bytes (3.55%) (5244840->5431193) gdb grew 193437 bytes (3.11%) (6228176->6421613) evolution-data-server grew 208724 bytes (1.89%) (11029422->11238146) PyOpenGL grew 213779 bytes (4.86%) (4398157->4611936) tomboy grew 218900 bytes (3.63%) (6022535->6241435) parted grew 223507 bytes (15.16%) (1474368->1697875) selinux-policy-devel grew 229206 bytes (4.15%) (5522257->5751463) orca grew 231344 bytes (4.05%) (5718621->5949965) util-linux-ng grew 245524 bytes (5.17%) (4749959->4995483) iso-codes grew 269192 bytes (4.80%) (5605136->5874328) system-config-date grew 282500 bytes (10.09%) (2798572->3081072) xorg-x11-drv-ati grew 285328 bytes (35.75%) (798151->1083479) selinux-policy grew 292154 bytes (3.79%) (7707834->7999988) eog grew 292326 bytes (7.82%) (3740424->4032750) dbus grew 299134 bytes (58.75%) (509123->808257) totem grew 321458 bytes (5.87%) (5476956->5798414) gnome-keyring grew 333541 bytes (32.87%) (1014819->1348360) glibc grew 347221 bytes (2.59%) (13402107->13749328) sqlite grew 358672 bytes (76.12%) (471170->829842) setroubleshoot-server grew 363273 bytes (22.18%) (1637732->2001005) bind-libs grew 389872 bytes (17.27%) (2258064->2647936) gcalctool grew 496578 bytes (10.21%) (4862745->5359323) gnome-panel grew 509960 bytes (4.35%) (11714901->12224861) gutenprint grew 664813 bytes (15.07%) (4410340->5075153) rhythmbox grew 678314 bytes (6.41%) (10582223->11260537) mono-core grew 686301 bytes (2.01%) (34154946->34841247) nautilus grew 693197 bytes (5.04%) (13751211->14444408) mono-winforms grew 729754 bytes (7.47%) (9765822->10495576) totem-mozplugin grew 770229 bytes (136.17%) (565632->1335861) mono-web grew 797665 bytes (9.85%) (8097242->8894907) glib2 grew 849381 bytes (29.07%) (2922173->3771554) gnome-power-manager grew 934030 bytes (8.33%) (11214535->12148565) nss grew 937664 bytes (44.33%) (2114975->3052639) libsmbclient grew 1191360 bytes (50.53%) (2357736->3549096) gnome-games grew 1373569 bytes (4.65%) (29510057->30883626) kernel grew 1885068 bytes (4.01%) (47063671->48948739) gutenprint-foomatic grew 2393009 bytes (5.05%) (47405319->49798328) anaconda grew 2540426 bytes (17.58%) (14448198->16988624) removed package fonts-punjabi: 0 removed package aspell-en: 3567971 removed package fonts-gujarati: 0 removed package fonts-korean: 0 removed package fonts-arabic: 0 removed package xorg-x11-drv-via: 363192 removed package xorg-x11-drv-avivo: 107204 removed package fonts-oriya: 0 removed package xorg-x11-drv-chips: 154533 removed package fonts-chinese: 0 removed package fonts-kannada: 0 removed package xorg-x11-drv-s3: 58401 removed package fonts-bengali: 0 removed package fonts-hebrew: 0 removed package dejavu-lgc-fonts: 6293390 removed package beecrypt: 242015 removed package fonts-hindi: 0 removed package evince: 3452782 removed package totem-plparser: 70428 removed package libbeagle: 94092 removed package xorg-x11-drv-tseng: 52907 removed package db4o: 1414265 removed package fuse: 216231 removed package liberation-fonts: 1097162 removed package xorg-x11-fonts-truetype: 909077 removed package fonts-tamil: 0 removed package fonts-telugu: 0 removed package xorg-x11-drv-ark: 18888 removed package fonts-sinhala: 0 removed package firstboot-tui: 653472 removed package fonts-malayalam: 0 removed package curl: 514238 old has 896 packages new has 901 packages -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From vonbrand at inf.utfsm.cl Fri Jan 25 16:28:15 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Fri, 25 Jan 2008 13:28:15 -0300 Subject: long term support release In-Reply-To: <1201277076.17905.362.camel@beck.corsepiu.local> References: <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> <20080125152614.GA2975@free.fr> <20080125103335.0d5adacf@redhat.com> <20080125154127.GC2975@free.fr> <1201275741.1163.1.camel@localhost.localdomain> <20080125154749.GD2975@free.fr> <20080125105041.6605e470@redhat.com> <1201277076.17905.362.camel@beck.corsepiu.local> Message-ID: <200801251628.m0PGSF7Q013098@laptop13.inf.utfsm.cl> Ralf Corsepius wrote: > On Fri, 2008-01-25 at 10:50 -0500, Jesse Keating wrote: [...] > > What earthly reason would you have to run some old code set, with not > > even close to guaranteed updates, let alone timely ones, with little > > man power behind it, and the opportunity to be ignored by most package > > owners? > Because that's still better and more effective than getting lost in the > Fedora upgrade maelstrom OK, that can be an issue. > and getting lost in the bureaucracy Fedora > suffers from Examples? Suggestions to streamline? > and better than continuing to use a completely discontinued > distro. CentOS isn't "completely discontinued"... > > And why aren't those reasons satisfied with RHEL/CentOS which doesn't > > have these problems? > For me, CentOS is an ultra conservative, stagnating distro not meeting > my demands. It may-be suitable for those who want to set up a server and > run it with minimal support for the next 4 years - To me it's non > interesting. So you want bleeding-edge packages, ultra-conservative distribution version? Perhaps Debian unstable, with its rolling updates (and never, ever a new version) is what you are looking for? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From j.w.r.degoede at hhs.nl Fri Jan 25 16:25:45 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 25 Jan 2008 17:25:45 +0100 Subject: Headsup: new API breaking libgda on its way to rawhide Message-ID: <479A0D89.2050801@hhs.nl> Hi, I'm working on updating gnumeric to the stable 1.8.x version, however in true gnumeric fashion (they've done this before). This requires the development version of libgda-3.1.2. This sounds worse then it is as the development version has mainly received bugfix and for the mostly libgda-3.0.so.3 its fully compatible with the 3.0.x series, the main reason why its a development series is because the API of libgda-report-3.0.so.3 has changed (but not the soname ???). This probably affects the following packages: gnome-python2-gda-0:2.19.1-11.fc8.i386 libgdamm-0:2.9.8-1.fc8.i386 gnumeric-1:1.6.3-13.fc8.i386 libgnomedbmm-0:2.9.5-2.fc8.i386 glom-0:1.6.5-1.fc8.i386 gnumeric-1:1.6.3-12.fc8.i386 libgnomedb-1:3.0.0-3.fc8.i386 I say probably because there are false positives in this list, the libgda-3.0.1 .pc file contains: -lgda-report-3.0 -lgda-3.0 -lgdasql-3.0 Which causes all applications linking to libgda to depend on gda-report-3.0, even though they most likely in reality do not. One of the fixes in the new libgda-3.1.2, is that the .pc file now only contains: -lgda-3.0 -lgdasql-3.0 And a new seperate libgda-report-3.0.pc has been added. For example of a false positive caused by this, "rpmlint libgnomedb" gives the following on a system with libgnomedb installed: libgnomedb.i386: W: unused-direct-shlib-dependency /usr/lib/libgnomedb_graph-3.0.so.4.0.0 /usr/lib/libgda-report-3.0.so.3 So libngomedbmm most likely is a false positive to, still when in doubt do a rebuild. I'll send another mail once the new libgda is available in the buildroot. Thanks & Regards, Hans From lesmikesell at gmail.com Fri Jan 25 16:39:44 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 25 Jan 2008 10:39:44 -0600 Subject: long term support release In-Reply-To: <20080125105041.6605e470@redhat.com> References: <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> <20080125152614.GA2975@free.fr> <20080125103335.0d5adacf@redhat.com> <20080125154127.GC2975@free.fr> <1201275741.1163.1.camel@localhost.localdomain> <20080125154749.GD2975@free.fr> <20080125105041.6605e470@redhat.com> Message-ID: <479A10D0.7020301@gmail.com> Jesse Keating wrote: >>> If an "LTS" release doesn't guarantee stability and timely security >>> updates, it shouldn't be called LTS. Maybe "Extended Support" or >>> "More Volunteer Updates". But not LTS... >> The name is not the issue, as long as it is understood that it is a >> volunteer based project. It isn't in the fedora name, but fedora is a >> volunteer based project. > > What earthly reason would you have to run some old code set, with not > even close to guaranteed updates, let alone timely ones, with little > man power behind it, and the opportunity to be ignored by most package > owners? Here's the reason: you have a new computer with hardware supported in fedora but not the current RHEL/Centos release - or you need some software feature provided in the newer fedora apps so you install fedora. A year passes and you've installed an assortment of additional apps and perhaps written some of your own. Everything you need is working nicely, but now your security updates end. Your 'some old code set' description doesn't quite match what people care about - they want a code set that meets certain needs and once that is installed and working they don't care if a prettier new version with new bugs happens to be available. But people will be installing that on new computers or new situations where they need a feature. > And why aren't those reasons satisfied with RHEL/CentOS which doesn't > have these problems? After the RHEL/Centos version is released that includes the needed features, this can work. However, people probably have better things to do than reinstall their OS and duplicate a year or more's worth of tracking down 3rd party apps and tweaking their own. -- Les Mikesell lesmikesell at gmail.com From pertusus at free.fr Fri Jan 25 16:37:06 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 25 Jan 2008 17:37:06 +0100 Subject: long term support release In-Reply-To: <200801251623.m0PGNbuJ012679@laptop13.inf.utfsm.cl> References: <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> <20080125152614.GA2975@free.fr> <20080125103335.0d5adacf@redhat.com> <20080125154127.GC2975@free.fr> <200801251623.m0PGNbuJ012679@laptop13.inf.utfsm.cl> Message-ID: <20080125163706.GA3480@free.fr> On Fri, Jan 25, 2008 at 01:23:37PM -0300, Horst H. von Brand wrote: > > Now, cross your heart: Would /you/ run a LTS where there was /no/ QA or > security team? At most for a month or so, until it is convenient to > upgrade would be my answer. Feeling uneasy all the time. Yes, I would, if I know that I can trust the packagers. I don't care about QA and security team (though it is a nice bonus). I trust fedora contributors to do things right, though, when they are (even selfishely) interested in something. And it could happen that some fedora contributors are interested in doing Updates after the EOL. Although I wouldn't certainly use such a release, if there was some infrastructure, I would certainly try to fix critical issues in most of my own packages in such a setting (especially since I already do it in EPEL). I already do that for the stable releases I don't use, so... -- Pat From vonbrand at inf.utfsm.cl Fri Jan 25 16:38:37 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Fri, 25 Jan 2008 13:38:37 -0300 Subject: long term support release In-Reply-To: <20080125153747.GB2975@free.fr> References: <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <20080125103144.68eec1ff@redhat.com> <20080125153747.GB2975@free.fr> Message-ID: <200801251638.m0PGcbnL014079@laptop13.inf.utfsm.cl> Patrice Dumas wrote: > On Fri, Jan 25, 2008 at 10:31:44AM -0500, Jesse Keating wrote: [...] > > you know, there is a Fedora based release that promises long term > > stability and quality... > I know, but in that case there are customers, it is very different, > there are contracts. People associate a name (Fedora, or RHEL, or IBM) with a certain expectation. If I came along and offered you a support contract for RHEL at half the price, and promising the same level of support, would you take it? I would't... I trust RH, the contract with them is just in case something goes wrong (and I trust that /not/ to happen, going to court to enforce the contract etc is expensive, and not exactly helpful for my business). What you would be squandering here is Fedora's good name. All for "OK, let's LTS this one. But someone critical might get bored in a month or two and drop it with little warning, so take care"? Again, the offer was made repeatedly to (help) set up a SIG, contact interested parties in founding an LTS, ... and /nobody/ has stepped forward. Telling, ist't it? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From rc040203 at freenet.de Fri Jan 25 16:43:46 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 25 Jan 2008 17:43:46 +0100 Subject: long term support release In-Reply-To: <200801251628.m0PGSF7Q013098@laptop13.inf.utfsm.cl> References: <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> <20080125152614.GA2975@free.fr> <20080125103335.0d5adacf@redhat.com> <20080125154127.GC2975@free.fr> <1201275741.1163.1.camel@localhost.localdomain> <20080125154749.GD2975@free.fr> <20080125105041.6605e470@redhat.com> <1201277076.17905.362.camel@beck.corsepiu.local> <200801251628.m0PGSF7Q013098@laptop13.inf.utfsm.cl> Message-ID: <1201279426.17905.392.camel@beck.corsepiu.local> On Fri, 2008-01-25 at 13:28 -0300, Horst H. von Brand wrote: > Ralf Corsepius wrote: > > On Fri, 2008-01-25 at 10:50 -0500, Jesse Keating wrote: > > [...] > > > > What earthly reason would you have to run some old code set, with not > > > even close to guaranteed updates, let alone timely ones, with little > > > man power behind it, and the opportunity to be ignored by most package > > > owners? > > > Because that's still better and more effective than getting lost in the > > Fedora upgrade maelstrom > > OK, that can be an issue. Note: Upgrade, not update! The experience of upgrading from FC7 to FC8 had not been pleasant :/ > > and getting lost in the bureaucracy Fedora > > suffers from > > Examples? Suggestions to streamline? > > > and better than continuing to use a completely discontinued > > distro. > > CentOS isn't "completely discontinued"... I realize, some mails from me seem to be stuck in RH's spam filter :/ I have been proposing to extend the life-time of discontinued Fedora's on completely open and free, volunteered basis (similar to what Legacy once did). > > > And why aren't those reasons satisfied with RHEL/CentOS which doesn't > > > have these problems? > > > For me, CentOS is an ultra conservative, stagnating distro not meeting > > my demands. It may-be suitable for those who want to set up a server and > > run it with minimal support for the next 4 years - To me it's non > > interesting. > > So you want bleeding-edge packages, ultra-conservative distribution > version? No, I want a middle ground: E.g. the status quo of FC7 with the bug fixes from FC8+, but without the bugs and warts FC8 is currently suffering from. Or simpler: ATM, I can't recommend upgrading to FC8 to anybody. Upgrading to it is premature. Wait until FC9 is out, may-be then FC8 has become sufficiently usable. > Perhaps Debian unstable, with its rolling updates (and never, ever a new > version) is what you are looking for? If Debian was rpm-based, I probably would have switched to it long time ago ;) Ralf From vonbrand at inf.utfsm.cl Fri Jan 25 16:43:00 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Fri, 25 Jan 2008 13:43:00 -0300 Subject: long term support release In-Reply-To: <479A0A55.60409@fedoraproject.org> References: <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <20080125103144.68eec1ff@redhat.com> <20080125153747.GB2975@free.fr> <20080125104307.382ce039@redhat.com> <20080125155059.GE2975@free.fr> <20080125155124.GA5809@orient.maison.lan> <479A0A55.60409@fedoraproject.org> Message-ID: <200801251643.m0PGh0pn014531@laptop13.inf.utfsm.cl> Rahul Sundaram wrote: > Emmanuel Seyman wrote: [...] > > They take the work done by Red Hat and just rebuild the .rpms. > > If Fedora LTS happens, it will not have this option. > .. unless Fedora LTS is a rebuild of RHEL SRPMS. That isn't Fedora. And it exists, and is called CentOS. > There might be some > advantages to this worth considering. Which ones? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From pertusus at free.fr Fri Jan 25 16:44:13 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 25 Jan 2008 17:44:13 +0100 Subject: long term support release In-Reply-To: <200801251638.m0PGcbnL014079@laptop13.inf.utfsm.cl> References: <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <20080125103144.68eec1ff@redhat.com> <20080125153747.GB2975@free.fr> <200801251638.m0PGcbnL014079@laptop13.inf.utfsm.cl> Message-ID: <20080125164413.GB3480@free.fr> On Fri, Jan 25, 2008 at 01:38:37PM -0300, Horst H. von Brand wrote: > Patrice Dumas wrote: > > On Fri, Jan 25, 2008 at 10:31:44AM -0500, Jesse Keating wrote: > > [...] > > > > you know, there is a Fedora based release that promises long term > > > stability and quality... > > > I know, but in that case there are customers, it is very different, > > there are contracts. > > People associate a name (Fedora, or RHEL, or IBM) with a certain > expectation. The RHEL and IBM names are very different from the Fedora one. > If I came along and offered you a support contract for RHEL at > half the price, and promising the same level of support, would you take it? Here you are meaning that Fedora can offer support for free. It isn't the same issue. Of course reputation is important. And Fedora reputation may be good. And price doesn't make the reputation, but it creates obligations a reputation doesn't create. > I would't... I trust RH, the contract with them is just in case something > goes wrong (and I trust that /not/ to happen, going to court to enforce the > contract etc is expensive, and not exactly helpful for my business). But can be necessary, and in contrast to what would happen with fedora you should win. > What you would be squandering here is Fedora's good name. All for "OK, > let's LTS this one. But someone critical might get bored in a month or two > and drop it with little warning, so take care"? Don't call it fedora then. Once again the name is not the issue. > Again, the offer was made repeatedly to (help) set up a SIG, contact > interested parties in founding an LTS, ... and /nobody/ has stepped > forward. Telling, ist't it? It doesn't tell anything since it was also said repeatedly that people wanting to do it will have to do it against the will of the fedora rulers (the boards, infrastructure team...). -- Pat From jkeating at redhat.com Fri Jan 25 16:53:19 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 25 Jan 2008 11:53:19 -0500 Subject: long term support release In-Reply-To: <20080125164413.GB3480@free.fr> References: <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <20080125103144.68eec1ff@redhat.com> <20080125153747.GB2975@free.fr> <200801251638.m0PGcbnL014079@laptop13.inf.utfsm.cl> <20080125164413.GB3480@free.fr> Message-ID: <20080125115319.28d78ae6@redhat.com> On Fri, 25 Jan 2008 17:44:13 +0100 Patrice Dumas wrote: > It doesn't tell anything since it was also said repeatedly that people > wanting to do it will have to do it against the will of the fedora > rulers (the boards, infrastructure team...). Which isn't an issue if you don't call it Fedora. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lesmikesell at gmail.com Fri Jan 25 16:59:46 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 25 Jan 2008 10:59:46 -0600 Subject: long term support release In-Reply-To: <1201277076.17905.362.camel@beck.corsepiu.local> References: <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> <20080125152614.GA2975@free.fr> <20080125103335.0d5adacf@redhat.com> <20080125154127.GC2975@free.fr> <1201275741.1163.1.camel@localhost.localdomain> <20080125154749.GD2975@free.fr> <20080125105041.6605e470@redhat.com> <1201277076.17905.362.camel@beck.corsepiu.local> Message-ID: <479A1582.9090202@gmail.com> Ralf Corsepius wrote: > >> And why aren't those reasons satisfied with RHEL/CentOS which doesn't >> have these problems? > For me, CentOS is an ultra conservative, stagnating distro not meeting > my demands. It may-be suitable for those who want to set up a server and > run it with minimal support for the next 4 years - To me it's non > interesting. I don't think a kernel or libc should be "interesting" and the only reason to change them should be to get one that works with new hardware. Server apps also tend to be mostly feature-complete even in old versions. However desktop apps are evolving rapidly and there really is a missing spot in fedora/rhel style distributions since nothing provides both kernel/core library stability and current application versions. -- Les Mikesell lesmikesell at gmail.com From vonbrand at inf.utfsm.cl Fri Jan 25 17:01:46 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Fri, 25 Jan 2008 14:01:46 -0300 Subject: long term support release In-Reply-To: <20080125162005.GG2975@free.fr> References: <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> <20080125152614.GA2975@free.fr> <20080125103335.0d5adacf@redhat.com> <20080125154127.GC2975@free.fr> <1201275741.1163.1.camel@localhost.localdomain> <20080125154749.GD2975@free.fr> <20080125105041.6605e470@redhat.com> <20080125162005.GG2975@free.fr> Message-ID: <200801251701.m0PH1k4j015526@laptop13.inf.utfsm.cl> Patrice Dumas wrote: > On Fri, Jan 25, 2008 at 10:50:41AM -0500, Jesse Keating wrote: [...] > > And why aren't those reasons satisfied with RHEL/CentOS which doesn't > > have these problems? > I would help for those who want to deploy fedora but don't want to > upgrade at the fedora pace. Fedora's definition /is/ bleeding-edge, fast-moving; thus shortish lifetime. Why would anyone want anything else under the Fedora name is beyond me. And there /are/ workable alternatives for longer lifetime, as has been pointed out repeatedly. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From emmanuel.seyman at club-internet.fr Fri Jan 25 17:00:30 2008 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Fri, 25 Jan 2008 18:00:30 +0100 Subject: long term support release In-Reply-To: <1201279426.17905.392.camel@beck.corsepiu.local> References: <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> <20080125152614.GA2975@free.fr> <20080125103335.0d5adacf@redhat.com> <20080125154127.GC2975@free.fr> <1201275741.1163.1.camel@localhost.localdomain> <20080125154749.GD2975@free.fr> <20080125105041.6605e470@redhat.com> <1201277076.17905.362.camel@beck.corsepiu.local> <200801251628.m0PGSF7Q013098@laptop13.inf.utfsm.cl> <1201279426.17905.392.camel@beck.corsepiu.local> Message-ID: <20080125170030.GA6418@orient.maison.lan> * Ralf Corsepius [25/01/2008 17:41] : > > I have been proposing to extend the life-time of discontinued Fedora's > on completely open and free, volunteered basis (similar to what Legacy > once did). There have been 4 or 5 different proposals made in this thread, all with their own specifics (ABI/API compatibility, list of packages to maintain, third-party repo or not, ...) and there's really no way to tell where yours fits in all of this. This is why you should propose a SIG (being specific in its mission statement), lead it if it gets approved and form a third party repo if it doesn't. Emmanuel From lsof at nodata.co.uk Fri Jan 25 17:04:37 2008 From: lsof at nodata.co.uk (nodata) Date: Fri, 25 Jan 2008 18:04:37 +0100 Subject: bug gone bad: boot.log Message-ID: <1201280677.3696.5.camel@sb-home> I know the mailing list shouldn't turn into a bug spammers paradise, but this bug is perhaps a good example of a bug that could be handled a little better: https://bugzilla.redhat.com/show_bug.cgi?id=151238 Tthe short version: Me: Boot log is empty, I needed that BN: Oh we removed that, we want to do things differently, it will work again in a future version Me: Can't we keep it until the future version is available? BN: No. This bug was reported nine releases ago, in fc4test1 :/ From lsof at nodata.co.uk Fri Jan 25 17:07:58 2008 From: lsof at nodata.co.uk (nodata) Date: Fri, 25 Jan 2008 18:07:58 +0100 Subject: bug gone bad: boot.log In-Reply-To: <1201280677.3696.5.camel@sb-home> References: <1201280677.3696.5.camel@sb-home> Message-ID: <1201280878.3696.9.camel@sb-home> Am Freitag, den 25.01.2008, 18:04 +0100 schrieb nodata: > I know the mailing list shouldn't turn into a bug spammers paradise, but > this bug is perhaps a good example of a bug that could be handled a > little better: > https://bugzilla.redhat.com/show_bug.cgi?id=151238 > > Tthe short version: > > Me: Boot log is empty, I needed that > BN: Oh we removed that, we want to do things differently, it will work > again in a future version > Me: Can't we keep it until the future version is available? > BN: No. > > This bug was reported nine releases ago, in fc4test1 :/ > Nine releases ago? Well.. From pertusus at free.fr Fri Jan 25 17:07:56 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 25 Jan 2008 18:07:56 +0100 Subject: long term support release In-Reply-To: <20080125115319.28d78ae6@redhat.com> References: <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <20080125103144.68eec1ff@redhat.com> <20080125153747.GB2975@free.fr> <200801251638.m0PGcbnL014079@laptop13.inf.utfsm.cl> <20080125164413.GB3480@free.fr> <20080125115319.28d78ae6@redhat.com> Message-ID: <20080125170756.GA3785@free.fr> On Fri, Jan 25, 2008 at 11:53:19AM -0500, Jesse Keating wrote: > On Fri, 25 Jan 2008 17:44:13 +0100 > Patrice Dumas wrote: > > > It doesn't tell anything since it was also said repeatedly that people > > wanting to do it will have to do it against the will of the fedora > > rulers (the boards, infrastructure team...). > > > Which isn't an issue if you don't call it Fedora. Even if the fedora infrastructure is used? -- Pat From vonbrand at inf.utfsm.cl Fri Jan 25 17:09:44 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Fri, 25 Jan 2008 14:09:44 -0300 Subject: long term support release In-Reply-To: <479A10D0.7020301@gmail.com> References: <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> <20080125152614.GA2975@free.fr> <20080125103335.0d5adacf@redhat.com> <20080125154127.GC2975@free.fr> <1201275741.1163.1.camel@localhost.localdomain> <20080125154749.GD2975@free.fr> <20080125105041.6605e470@redhat.com> <479A10D0.7020301@gmail.com> Message-ID: <200801251709.m0PH9iV5015900@laptop13.inf.utfsm.cl> Les Mikesell wrote: > Jesse Keating wrote: [...] > > What earthly reason would you have to run some old code set, with not > > even close to guaranteed updates, let alone timely ones, with little > > man power behind it, and the opportunity to be ignored by most package > > owners? > Here's the reason: you have a new computer with hardware supported in > fedora but not the current RHEL/Centos release - Lack of care when buying a machine can't be cured by the distribution. > or you need some > software feature provided in the newer fedora apps so you install > fedora. I was perfectly happy with RH 6.2, and most of what I do now I could do there, so this can't really be an issue. > A year passes and you've installed an assortment of > additional apps and perhaps written some of your own. Upgrade to next Fedora. Gets easier each time around. A bit of foresight when installing originally helps much here. > Everything you > need is working nicely, but now your security updates end. Your 'some > old code set' description doesn't quite match what people care about - > they want a code set that meets certain needs and once that is > installed and working they don't care if a prettier new version with > new bugs happens to be available. But people will be installing that > on new computers or new situations where they need a feature. If they care for "working indefinitely" they aren't into "mint-fresh hardware" nor into "bleeding-edge software". This scenario isn't at all realistic. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From lesmikesell at gmail.com Fri Jan 25 17:14:55 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 25 Jan 2008 11:14:55 -0600 Subject: long term support release In-Reply-To: <20080125112254.382c9e13@redhat.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> <4799EAA0.7030700@gmail.com> <20080125102616.7605825b@redhat.com> <479A0C6B.1050004@gmail.com> <20080125112254.382c9e13@redhat.com> Message-ID: <479A190F.8010402@gmail.com> Jesse Keating wrote: >> Yes, it would be a big win for the fedora 'brand' perception to make >> it actually usable instead of just a rolling alpha/beta for RHEL. If >> you are going to argue that such a perception shouldn't exist, just >> say so instead of claiming that it's too hard or that failed earlier >> attempts prove it can't be done. > > I think there would be some value to having CentOS associated with the > Fedora brand... I believe the CentOS team has made some effort to isolate/generalize the 'rebranding' work they have to do. It might be easy to replace with fedora's even if they aren't interested in converging. >> Now for a *really* warm/fuzzy about the free >> software community, you could just converge this version's update >> repo with the corresponding EPEL/centos/centosplus repo contents and >> make them end up the same without a re-install or any duplication of >> infrastructure at all. > > Now you're talking about something different, a migration plan for > Fedora -> EL based on said release. It's not necessarily different, depending on what you imagined a fedora with LTS would be like. Having a centosplus-like kernel would be a key factor so as not to break on hardware or filesystems that RHEL doesn't support. > That I could see some great value > in, and it shouldn't be too difficult to start working down this path, > and getting into the heads of the EL creators that this is something > we'd like to see made possible, rather than difficult, by the EL > development. > > Sounds like a SIG to me... Going this direction will probably emphasize the already-existing need for an additional/optional variation of an EPEL-like repo that has newer replacement apps for RHEL/Centos. These are separate but equal needs. That is, some situations will require/prefer the frozen versions and feature set of the enterprise distro, but many, perhaps most, would really like to have a current firefox and openoffice without replacing their kernel and device drivers on working systems. The scheme that would make sense to me would be to make the update switch to 'stable mode' at end of life by default, retaining the app versions supported in the enterprise disto since this takes essentially no extra effort, and concentrate new volunteer effort on building current 'fedora-version' apps that could optionally be installed over the enterprise base. If the latter effort fails, you've still got a solid, working version. -- Les Mikesell lesmikesell at gmail.com From vonbrand at inf.utfsm.cl Fri Jan 25 17:16:03 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Fri, 25 Jan 2008 14:16:03 -0300 Subject: long term support release In-Reply-To: <20080125164413.GB3480@free.fr> References: <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <20080125103144.68eec1ff@redhat.com> <20080125153747.GB2975@free.fr> <200801251638.m0PGcbnL014079@laptop13.inf.utfsm.cl> <20080125164413.GB3480@free.fr> Message-ID: <200801251716.m0PHG3Ua016195@laptop13.inf.utfsm.cl> Patrice Dumas wrote: > On Fri, Jan 25, 2008 at 01:38:37PM -0300, Horst H. von Brand wrote: > > Patrice Dumas wrote: > > > On Fri, Jan 25, 2008 at 10:31:44AM -0500, Jesse Keating wrote: > > > > [...] > > > > > > you know, there is a Fedora based release that promises long term > > > > stability and quality... > > > > > I know, but in that case there are customers, it is very different, > > > there are contracts. > > > > People associate a name (Fedora, or RHEL, or IBM) with a certain > > expectation. > The RHEL and IBM names are very different from the Fedora one. No. All come with (hard-earned) reputations. Different ones, sure. But nevertheless valuable. > > If I came along and offered you a support contract for RHEL at > > half the price, and promising the same level of support, would you take it? > Here you are meaning that Fedora can offer support for free. It does! You trust them to fix bugs, and keep your system reasonably secure, don't you? > It isn't > the same issue. Of course reputation is important. And Fedora reputation > may be good. And price doesn't make the reputation, but it creates > obligations a reputation doesn't create. Keeping the reputation creates the obligation, price is besides the point. [...] > > What you would be squandering here is Fedora's good name. All for "OK, > > let's LTS this one. But someone critical might get bored in a month or two > > and drop it with little warning, so take care"? > Don't call it fedora then. Once again the name is not the issue. Great. All is missing now is the hordes of people interested in extending the life of e.g. Fedora 7 for 4 years more. Please, stand orderly in line, everybody will have their turn at helping out. > > Again, the offer was made repeatedly to (help) set up a SIG, contact > > interested parties in founding an LTS, ... and /nobody/ has stepped > > forward. Telling, ist't it? > It doesn't tell anything since it was also said repeatedly that people > wanting to do it will have to do it against the will of the fedora > rulers (the boards, infrastructure team...). What I've seen here is exactly the opposite... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From jkeating at redhat.com Fri Jan 25 17:13:57 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 25 Jan 2008 12:13:57 -0500 Subject: long term support release In-Reply-To: <20080125170756.GA3785@free.fr> References: <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <20080125103144.68eec1ff@redhat.com> <20080125153747.GB2975@free.fr> <200801251638.m0PGcbnL014079@laptop13.inf.utfsm.cl> <20080125164413.GB3480@free.fr> <20080125115319.28d78ae6@redhat.com> <20080125170756.GA3785@free.fr> Message-ID: <20080125121357.465a8a6f@redhat.com> On Fri, 25 Jan 2008 18:07:56 +0100 Patrice Dumas wrote: > Even if the fedora infrastructure is used? We have OLPC using our infrastructure... This is what Jeff has been saying over and over. Come up with a plan and people, and the board/releng/infrastructure will see what we can do to help, if we can help. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jos at xos.nl Fri Jan 25 17:24:05 2008 From: jos at xos.nl (Jos Vos) Date: Fri, 25 Jan 2008 18:24:05 +0100 Subject: long term support release In-Reply-To: <200801251716.m0PHG3Ua016195@laptop13.inf.utfsm.cl> References: <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <20080125103144.68eec1ff@redhat.com> <20080125153747.GB2975@free.fr> <200801251638.m0PGcbnL014079@laptop13.inf.utfsm.cl> <20080125164413.GB3480@free.fr> <200801251716.m0PHG3Ua016195@laptop13.inf.utfsm.cl> Message-ID: <20080125172405.GA827@jasmine.xos.nl> On Fri, Jan 25, 2008 at 02:16:03PM -0300, Horst H. von Brand wrote: > All is missing now is the hordes of people interested in extending the life > of e.g. Fedora 7 for 4 years more. Please, stand orderly in line, everybody > will have their turn at helping out. They exist and are using CentOS :-). -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From vonbrand at inf.utfsm.cl Fri Jan 25 17:27:40 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Fri, 25 Jan 2008 14:27:40 -0300 Subject: long term support release In-Reply-To: <479A190F.8010402@gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> <4799EAA0.7030700@gmail.com> <20080125102616.7605825b@redhat.com> <479A0C6B.1050004@gmail.com> <20080125112254.382c9e13@redhat.com> <479A190F.8010402@gmail.com> Message-ID: <200801251727.m0PHRe0O016727@laptop13.inf.utfsm.cl> Les Mikesell wrote: [...] > I believe the CentOS team has made some effort to isolate/generalize > the 'rebranding' work they have to do. It might be easy to replace > with fedora's even if they aren't interested in converging. Fedora and RHEL have done the work, mostly. [...] > Going this direction will probably emphasize the already-existing need > for an additional/optional variation of an EPEL-like repo that has > newer replacement apps for RHEL/Centos. These are separate but equal > needs. That is, some situations will require/prefer the frozen > versions and feature set of the enterprise distro, but many, perhaps > most, would really like to have a current firefox and openoffice > without replacing their kernel and device drivers on working systems. Others are talking exactly the opposite: Keep all userland the same, but make it work on new machines/take advantage of new hardware. > The scheme that would make sense to me would be to make the update > switch to 'stable mode' at end of life by default, retaining the app > versions supported in the enterprise disto since this takes > essentially no extra effort, Nonsense. The versions in Fedora have by then drifted far from the "enterprise distro". And keeping them up to date is /hard/ (that is what people are paying for RHEL, essentially). > and concentrate new volunteer effort on > building current 'fedora-version' apps that could optionally be > installed over the enterprise base. And said new versions require new infrastructure (new libc, new Gnome, new X, ...; yes, ABIs /do/ change without you being aware), and are built to different environments (font/icon/... files are now elsewhere, new SELinux layout, configuration conventions have changed, ...). > If the latter effort fails, > you've still got a solid, working version. If you want "solid, working", why are you messing around with "bleeding-edge apps"?! -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From emmanuel.seyman at club-internet.fr Fri Jan 25 17:25:29 2008 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Fri, 25 Jan 2008 18:25:29 +0100 Subject: long term support release In-Reply-To: <20080125112254.382c9e13@redhat.com> References: <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> <4799EAA0.7030700@gmail.com> <20080125102616.7605825b@redhat.com> <479A0C6B.1050004@gmail.com> <20080125112254.382c9e13@redhat.com> Message-ID: <20080125172529.GA6738@orient.maison.lan> * Jesse Keating [25/01/2008 17:23] : > > I think there would be some value to having CentOS associated with the > Fedora brand... I suspect that Fedora will find value to putting CentOS somewhere in the Fedora namespace but I'm not sure that the CentOS guys will like being associated with a name that implies "breaking edge". Emmanuel From notting at redhat.com Fri Jan 25 17:29:50 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 25 Jan 2008 12:29:50 -0500 Subject: bug gone bad: boot.log In-Reply-To: <1201280677.3696.5.camel@sb-home> References: <1201280677.3696.5.camel@sb-home> Message-ID: <20080125172950.GE28249@nostromo.devel.redhat.com> nodata (lsof at nodata.co.uk) said: > I know the mailing list shouldn't turn into a bug spammers paradise, but > this bug is perhaps a good example of a bug that could be handled a > little better: > https://bugzilla.redhat.com/show_bug.cgi?id=151238 Taking patches; the issue is that the system has changed enough in the interim (between udev, SELinux, etc.) that the old code no longer is a drop-in replacement. Further updates to the bug aren't really useful until work is being done on it. Bill From lsof at nodata.co.uk Fri Jan 25 17:34:08 2008 From: lsof at nodata.co.uk (nodata) Date: Fri, 25 Jan 2008 18:34:08 +0100 Subject: bug gone bad: boot.log In-Reply-To: <20080125172950.GE28249@nostromo.devel.redhat.com> References: <1201280677.3696.5.camel@sb-home> <20080125172950.GE28249@nostromo.devel.redhat.com> Message-ID: <1201282448.3696.13.camel@sb-home> Am Freitag, den 25.01.2008, 12:29 -0500 schrieb Bill Nottingham: > nodata (lsof at nodata.co.uk) said: > > I know the mailing list shouldn't turn into a bug spammers paradise, but > > this bug is perhaps a good example of a bug that could be handled a > > little better: > > https://bugzilla.redhat.com/show_bug.cgi?id=151238 > > Taking patches; the issue is that the system has changed enough in > the interim (between udev, SELinux, etc.) that the old code no longer > is a drop-in replacement. If it was kept in the distro, then the code would have been incremtally improved and fixed to keep it working. > Further updates to the bug aren't really > useful until work is being done on it. This is a moot point because support for boot.log should never have been dropped until the replacement was ready. > Bill From emmanuel.seyman at club-internet.fr Fri Jan 25 17:35:52 2008 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Fri, 25 Jan 2008 18:35:52 +0100 Subject: long term support release In-Reply-To: <20080125170756.GA3785@free.fr> References: <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <20080125103144.68eec1ff@redhat.com> <20080125153747.GB2975@free.fr> <200801251638.m0PGcbnL014079@laptop13.inf.utfsm.cl> <20080125164413.GB3480@free.fr> <20080125115319.28d78ae6@redhat.com> <20080125170756.GA3785@free.fr> Message-ID: <20080125173552.GA6832@orient.maison.lan> * Patrice Dumas [25/01/2008 18:28] : > > Even if the fedora infrastructure is used? What is it about the Fedora infrastruture that makes it a requirement to release updates for Fedora distributions that are more than 13 months old ? Is it the hacked-to-death bug tracker? The dated version control system? Emmanuel From notting at redhat.com Fri Jan 25 17:47:46 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 25 Jan 2008 12:47:46 -0500 Subject: bug gone bad: boot.log In-Reply-To: <1201282448.3696.13.camel@sb-home> References: <1201280677.3696.5.camel@sb-home> <20080125172950.GE28249@nostromo.devel.redhat.com> <1201282448.3696.13.camel@sb-home> Message-ID: <20080125174746.GA30691@nostromo.devel.redhat.com> nodata (lsof at nodata.co.uk) said: > > Taking patches; the issue is that the system has changed enough in > > the interim (between udev, SELinux, etc.) that the old code no longer > > is a drop-in replacement. > > If it was kept in the distro, then the code would have been incremtally > improved and fixed to keep it working. Right, but I don't have a time machine. Bill From jkeating at redhat.com Fri Jan 25 17:52:21 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 25 Jan 2008 12:52:21 -0500 Subject: long term support release In-Reply-To: <20080125173552.GA6832@orient.maison.lan> References: <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <20080125103144.68eec1ff@redhat.com> <20080125153747.GB2975@free.fr> <200801251638.m0PGcbnL014079@laptop13.inf.utfsm.cl> <20080125164413.GB3480@free.fr> <20080125115319.28d78ae6@redhat.com> <20080125170756.GA3785@free.fr> <20080125173552.GA6832@orient.maison.lan> Message-ID: <20080125125221.6b0705f7@redhat.com> On Fri, 25 Jan 2008 18:35:52 +0100 Emmanuel Seyman wrote: > Is it the hacked-to-death bug tracker? > The dated version control system? The ability to contribute without having to get another account, learn another scm, read other bugmail, etc... -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lesmikesell at gmail.com Fri Jan 25 18:01:58 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 25 Jan 2008 12:01:58 -0600 Subject: long term support release In-Reply-To: <200801251709.m0PH9iV5015900@laptop13.inf.utfsm.cl> References: <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> <20080125152614.GA2975@free.fr> <20080125103335.0d5adacf@redhat.com> <20080125154127.GC2975@free.fr> <1201275741.1163.1.camel@localhost.localdomain> <20080125154749.GD2975@free.fr> <20080125105041.6605e470@redhat.com> <479A10D0.7020301@gmail.com> <200801251709.m0PH9iV5015900@laptop13.inf.utfsm.cl> Message-ID: <479A2416.7010904@gmail.com> Horst H. von Brand wrote: >> Here's the reason: you have a new computer with hardware supported in >> fedora but not the current RHEL/Centos release - > > Lack of care when buying a machine can't be cured by the distribution. What do you mean 'lack of care'? I buy hardware based on price and capability, then pick an OS that will run on it. I can't afford to do it the other way around. > >> or you need some >> software feature provided in the newer fedora apps so you install >> fedora. > > I was perfectly happy with RH 6.2, and most of what I do now I could do > there, so this can't really be an issue. There were horrible problems in 6.2 - I find it hard to believe that anyone could have been happy with it. If you had said 7.3 I might have gone along with this line. >> A year passes and you've installed an assortment of >> additional apps and perhaps written some of your own. > > Upgrade to next Fedora. Gets easier each time around. A bit of foresight > when installing originally helps much here. Sorry, been there, done that, and I'm not buying it. Installing a new fedora version is entirely unpredictable. >> Everything you >> need is working nicely, but now your security updates end. Your 'some >> old code set' description doesn't quite match what people care about - >> they want a code set that meets certain needs and once that is >> installed and working they don't care if a prettier new version with >> new bugs happens to be available. But people will be installing that >> on new computers or new situations where they need a feature. > > If they care for "working indefinitely" they aren't into "mint-fresh > hardware" nor into "bleeding-edge software". This scenario isn't at all > realistic. If you don't use any new hardware or features I don't think you qualify as an expert on realistic scenarios. Pretty much every computer I've used has gone though exactly that evolutionary process where, when I first set it up I've got nothing to lose and don't mind experimenting with latest/greatest software. Then as dependencies accumulate and I've got time and effort invested in a working system, I'm less and less inclined to use it for someone else's beta testing. -- Les Mikesell lesmikesell at gmail.com From emmanuel.seyman at club-internet.fr Fri Jan 25 18:06:03 2008 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Fri, 25 Jan 2008 19:06:03 +0100 Subject: long term support release In-Reply-To: <20080125125221.6b0705f7@redhat.com> References: <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <20080125103144.68eec1ff@redhat.com> <20080125153747.GB2975@free.fr> <200801251638.m0PGcbnL014079@laptop13.inf.utfsm.cl> <20080125164413.GB3480@free.fr> <20080125115319.28d78ae6@redhat.com> <20080125170756.GA3785@free.fr> <20080125173552.GA6832@orient.maison.lan> <20080125125221.6b0705f7@redhat.com> Message-ID: <20080125180603.GB7087@orient.maison.lan> * Jesse Keating [25/01/2008 18:53] : > > The ability to contribute without having to get another account, learn > another scm, read other bugmail, etc... These are conveniences, not hard requirements. Emmanuel From lesmikesell at gmail.com Fri Jan 25 18:12:27 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 25 Jan 2008 12:12:27 -0600 Subject: long term support release In-Reply-To: <200801251727.m0PHRe0O016727@laptop13.inf.utfsm.cl> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> <4799EAA0.7030700@gmail.com> <20080125102616.7605825b@redhat.com> <479A0C6B.1050004@gmail.com> <20080125112254.382c9e13@redhat.com> <479A190F.8010402@gmail.com> <200801251727.m0PHRe0O016727@laptop13.inf.utfsm.cl> Message-ID: <479A268B.5070201@gmail.com> Horst H. von Brand wrote: > >> The scheme that would make sense to me would be to make the update >> switch to 'stable mode' at end of life by default, retaining the app >> versions supported in the enterprise disto since this takes >> essentially no extra effort, > > Nonsense. The versions in Fedora have by then drifted far from the > "enterprise distro". What do you mean 'by then'? What was different in FC6 at the time of the RHEL5 release? What difference would have been required if this transition had been planned? > And keeping them up to date is /hard/ (that is what > people are paying for RHEL, essentially). Or getting for free with CentOS - so why keep them from getting it for free with fedora? >> and concentrate new volunteer effort on >> building current 'fedora-version' apps that could optionally be >> installed over the enterprise base. > > And said new versions require new infrastructure (new libc, new Gnome, new > X, ...; yes, ABIs /do/ change without you being aware), and are built to > different environments (font/icon/... files are now elsewhere, new SELinux > layout, configuration conventions have changed, ...). Yes, there are transitions that wouldn't be possible - which is a huge problem itself that probably can't realistically be fixed, but what about the ones that would be possible? That is, can you build a current firefox and OpenOffice for FC6 or RHEL5 today, and if so, why can't they be in a repo somewhere? >> If the latter effort fails, >> you've still got a solid, working version. > > If you want "solid, working", why are you messing around with > "bleeding-edge apps"?! Why are people writing 'bleeding-edge' apps if there is no reason to use them? A desktop app that crashes once in a while is not a huge problem - and wouldn't be a problem at all if there were an option to drop back to a more stable version. A machine that won't boot or a device driver that no longer talks to my hardware is. -- Les Mikesell lesmikesell at gmail.com From jkeating at redhat.com Fri Jan 25 18:19:36 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 25 Jan 2008 13:19:36 -0500 Subject: long term support release In-Reply-To: <20080125180603.GB7087@orient.maison.lan> References: <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <20080125103144.68eec1ff@redhat.com> <20080125153747.GB2975@free.fr> <200801251638.m0PGcbnL014079@laptop13.inf.utfsm.cl> <20080125164413.GB3480@free.fr> <20080125115319.28d78ae6@redhat.com> <20080125170756.GA3785@free.fr> <20080125173552.GA6832@orient.maison.lan> <20080125125221.6b0705f7@redhat.com> <20080125180603.GB7087@orient.maison.lan> Message-ID: <20080125131936.3cc6bc81@redhat.com> On Fri, 25 Jan 2008 19:06:03 +0100 Emmanuel Seyman wrote: > > The ability to contribute without having to get another account, > > learn another scm, read other bugmail, etc... > > These are conveniences, not hard requirements. If we want to learn anything from the failure of Legacy, they are pretty near hard requirements if you want to tap into the vast Fedora contributor base. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mschwendt.tmp0701.nospam at arcor.de Fri Jan 25 18:25:43 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 25 Jan 2008 19:25:43 +0100 Subject: long term support release In-Reply-To: <1201279426.17905.392.camel@beck.corsepiu.local> References: <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> <20080125152614.GA2975@free.fr> <20080125103335.0d5adacf@redhat.com> <20080125154127.GC2975@free.fr> <1201275741.1163.1.camel@localhost.localdomain> <20080125154749.GD2975@free.fr> <20080125105041.6605e470@redhat.com> <1201277076.17905.362.camel@beck.corsepiu.local> <200801251628.m0PGSF7Q013098@laptop13.inf.utfsm.cl> <1201279426.17905.392.camel@beck.corsepiu.local> Message-ID: <20080125192543.19e928d0.mschwendt.tmp0701.nospam@arcor.de> On Fri, 25 Jan 2008 17:43:46 +0100, Ralf Corsepius wrote: > Or simpler: ATM, I can't recommend upgrading to FC8 to anybody. > Upgrading to it is premature. Wait until FC9 is out, may-be then FC8 has > become sufficiently usable. Not the first time I've heard that. It's an idea/suggestion that's making its round recently. From pertusus at free.fr Fri Jan 25 18:28:11 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 25 Jan 2008 19:28:11 +0100 Subject: long term support release In-Reply-To: <20080125121357.465a8a6f@redhat.com> References: <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <20080125103144.68eec1ff@redhat.com> <20080125153747.GB2975@free.fr> <200801251638.m0PGcbnL014079@laptop13.inf.utfsm.cl> <20080125164413.GB3480@free.fr> <20080125115319.28d78ae6@redhat.com> <20080125170756.GA3785@free.fr> <20080125121357.465a8a6f@redhat.com> Message-ID: <20080125182811.GA2656@free.fr> On Fri, Jan 25, 2008 at 12:13:57PM -0500, Jesse Keating wrote: > On Fri, 25 Jan 2008 18:07:56 +0100 > Patrice Dumas wrote: > > > Even if the fedora infrastructure is used? > > We have OLPC using our infrastructure... > > This is what Jeff has been saying over and over. Come up with a plan > and people, and the board/releng/infrastructure will see what we can do > to help, if we can help. Ok, I am very sorry for the noise, I didn't understood that. It satisfies me completely... I personnally don't need this so I won't lead it, but I could help and I would take care of my packages in that setting. -- Pat From smooge at gmail.com Fri Jan 25 18:33:32 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 25 Jan 2008 11:33:32 -0700 Subject: long term support release In-Reply-To: <1201251592.17905.255.camel@beck.corsepiu.local> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> <1201251592.17905.255.camel@beck.corsepiu.local> Message-ID: <80d7e4090801251033s1fce270akfcf6a73e882b0236@mail.gmail.com> On Jan 25, 2008 1:59 AM, Ralf Corsepius wrote: > > On Thu, 2008-01-24 at 23:47 -0900, Jeff Spaleta wrote: > > On Jan 24, 2008 11:38 PM, Ralf Corsepius wrote: > > > Also, wouldn't you consider the fact Ubuntu launches "Ubuntu LTS" to be > > > evidence enough that others see a market nice? > > > > I'm pretty sure that Ubuntu LTS is something that Canonical as a > > business entity as chosen to launch and leverages as part of its > > business model and is not in point of fact relying primarily on > > community manpower to make the LTS offering actually work. Find me a > > business entity who would like to do something similar in Fedora space > > and I'll gladly talk to them about making room in the project. > There is one difference between Fedora and Ubuntu: > > * Fedora is backed up by an actively contributing community. > * RH/fedoraproject.org has the technical resources. > > There is only one thing missing: a culture of openness and a lack of > confidence into the powers of open development. > Ralf, no one but yourself is stopping you from being the catalyst for getting people to do this. See a problem, be the agent to make it better. When Fedora Legacy was falling apart you could have taken it over.. but it would seem you just wanted to save up your problems for later emails. If you want to make an LTS, then start it up. If there is a market for it, you can find the people and money to do so. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From nalin at redhat.com Fri Jan 25 19:00:05 2008 From: nalin at redhat.com (Nalin Dahyabhai) Date: Fri, 25 Jan 2008 14:00:05 -0500 Subject: Heads up: cracklib license changed Message-ID: <20080125190005.GB6571@redhat.com> Heads up: the cracklib license has changed from "Artistic" to "GPLv2" in the version which is building now. The consumers I found using repoquery (netatalk, pam, revelation) should all be fine with that, but I'm sending this anyway just in case. Cheers, Nalin From j.w.r.degoede at hhs.nl Fri Jan 25 19:01:28 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 25 Jan 2008 20:01:28 +0100 Subject: Headsup: new API breaking libgda on its way to rawhide In-Reply-To: <479A0D89.2050801@hhs.nl> References: <479A0D89.2050801@hhs.nl> Message-ID: <479A3208.7030107@hhs.nl> Hi all, For those who have packages to rebuild because of the libgda change, libgda is in the F-9 buildroot now. Regards, Hans Hans de Goede wrote: > Hi, > > I'm working on updating gnumeric to the stable 1.8.x version, however in > true gnumeric fashion (they've done this before). This requires the > development version of libgda-3.1.2. > > This sounds worse then it is as the development version has mainly > received bugfix and for the mostly libgda-3.0.so.3 its fully compatible > with the 3.0.x series, the main reason why its a development series is > because the API of > libgda-report-3.0.so.3 has changed (but not the soname ???). > > This probably affects the following packages: > gnome-python2-gda-0:2.19.1-11.fc8.i386 > libgdamm-0:2.9.8-1.fc8.i386 > gnumeric-1:1.6.3-13.fc8.i386 > libgnomedbmm-0:2.9.5-2.fc8.i386 > glom-0:1.6.5-1.fc8.i386 > gnumeric-1:1.6.3-12.fc8.i386 > libgnomedb-1:3.0.0-3.fc8.i386 > > I say probably because there are false positives in this list, the > libgda-3.0.1 .pc file contains: > -lgda-report-3.0 -lgda-3.0 -lgdasql-3.0 > > Which causes all applications linking to libgda to depend on > gda-report-3.0, even though they most likely in reality do not. > > One of the fixes in the new libgda-3.1.2, is that the .pc file now only > contains: > -lgda-3.0 -lgdasql-3.0 > > And a new seperate libgda-report-3.0.pc has been added. For example of a > false positive caused by this, "rpmlint libgnomedb" gives the following > on a system with libgnomedb installed: > libgnomedb.i386: W: unused-direct-shlib-dependency > /usr/lib/libgnomedb_graph-3.0.so.4.0.0 /usr/lib/libgda-report-3.0.so.3 > > So libngomedbmm most likely is a false positive to, still when in doubt > do a rebuild. I'll send another mail once the new libgda is available in > the buildroot. > > Thanks & Regards, > > Hans > From jspaleta at gmail.com Fri Jan 25 19:02:00 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 25 Jan 2008 10:02:00 -0900 Subject: long term support release In-Reply-To: <4799EAA0.7030700@gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> <4799EAA0.7030700@gmail.com> Message-ID: <604aa7910801251102y3dcfa168mc9fb750661c9a9b8@mail.gmail.com> On Jan 25, 2008 4:56 AM, Les Mikesell wrote: > How about a slight variation on the fedora LTS plan that might vastly > reduce the needed work and let people keep running without the dangers > of going without security fixes? What if the versions supported were > the ones used as the base of the RHEL cuts, and the subsequent updates > were recompiled from the CentOS source RPM's? Anything involving how RHEL is put together is complete and utterly out of the control of Fedora governance. Even as a fedora board member I have zero impact on how RHEL is put together and positioned, so even at the board level I cannot plan to know which Fedora is actually the base for RHEL, nor can I drive any decision making there. Though I will say, that if I had the opportunity to be at the next Fudcon which is coordinated with the next Red Hat Summit and would be making it a point to talk to existing RHEL customers wandering around and asking them exactly how they feel about where and how they'd like to see RHEL and Fedora better aligned. Because at the end of the day, RHEL customers have to champion RHEL-Fedora interactions. But unfortunately it looks live I've got a conflict of commitments that week, another conference for my dayjob that I probably will be attending. And I am very very wary about relying on re-consuming CentOS materials just to make it easier for ourselves to their detriment. From the outside looking in, CentOS appears to have reach critical mass, and has momentum. I really don't want to disrupt that. I'd like to build more bridges with them, but not for the sake of pillaging them. In fact I'd welcome any offline ideas from prominent CentOS members concerning how Fedora can better work with them. > In some cases you might need to re-enable some features removed in RHEL > (as CentosPlus does with the kernel) but the changes should all be > pretty obvious to someone with both source packages. And it would be > nice if additional feature-enabled packages made it into the Centosplus > repo in the cases where a fedora packager wanted to maintain them. Anything like this, would really only make sense if we started sharing build infrastructure. I don't think our relationship with CentOS is strong enough for that to be a possibility. -jef From jakub.rusinek at gmail.com Fri Jan 25 19:00:51 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Fri, 25 Jan 2008 20:00:51 +0100 Subject: Replacing gnome-volume-control by pavucontrol Message-ID: <1201287651.3847.3.camel@geeko> Hi, I've found a way to replace GNOME's volume control with PA's volume control. I've used gnome-wm as basis and created /apps/gnome-volume-control/rh/volume_control key in GConf. Also, there's needed to rename %{_bindir}/gnome-volume-control by adding ".real" suffix. It still works ;) . I'm attaching a script to put in %{_bindir}/ and schema to put in %{_sysconfdir}/gconf/schemas/gnome-volume-control.schemas (by editing file and pasting XML tree). -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: gnome-volume-control Type: application/x-shellscript Size: 850 bytes Desc: not available URL: -------------- next part -------------- /schemas/apps/gnome-volume-control/rh/volume_control /apps/gnome-volume-control/rh/volume_control gnome-volume-control string gnome-volume-control Preferred volume control Volume control to be started by panel applet Preferowane narz?dzie do zarz?dzania g?o?no?ci? Narz?dzie do zarz?dzania g?o?no?ci? uruchamiane przez aplet panelu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? wiadomo?ci podpisana cyfrowo URL: From stickster at gmail.com Fri Jan 25 19:17:53 2008 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 25 Jan 2008 14:17:53 -0500 Subject: Plan for tomorrows (20080124) FESCO meeting In-Reply-To: <4797D199.3070105@ncsu.edu> References: <1201105578.11814.2.camel@nixon> <0ML25U-1JHiww0JkI-0004KE@mrelayeu.kundenserver.de> <479783A2.5030901@gmail.com> <4797D199.3070105@ncsu.edu> Message-ID: <1201288673.3949.99.camel@localhost.localdomain> On Wed, 2008-01-23 at 18:45 -0500, Casey Dahlin wrote: > I was hoping the video tape of the session would be out before now (if > anyone has it, haaalp!), but here's roughly what happened: Just so everyone knows, I taped this one, and the tape went to Colby. He has a LOT of video he has been working on at a fast and furious pace. Sorry for the lateness of this reply. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From twoerner at redhat.com Fri Jan 25 19:20:03 2008 From: twoerner at redhat.com (Thomas Woerner) Date: Fri, 25 Jan 2008 20:20:03 +0100 Subject: More firewall changes for F-9+ Message-ID: <479A3663.1060309@redhat.com> Hello, some minutes ago system-config-firewall-1.2.0 has been build for rawhide. Here are the most important changes: - New support for port forwarding. - The chain RH-Firewall-1-INPUT has been dropped. - Trusted hosts are also added to the FORWARD chain in the filter table. - The iptables firewall configuration has been optimized. - Several GUI enhancements. The TUI is not reflecting the new functionality currently, but will do in a few days. Happy testing, Thomas From j.w.r.degoede at hhs.nl Fri Jan 25 19:21:58 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 25 Jan 2008 20:21:58 +0100 Subject: F9 Alpha spinning In-Reply-To: <20080125162835.GA19048@crow> References: <20080125162835.GA19048@crow> Message-ID: <479A36D6.2060405@hhs.nl> Hi All, Some questions / suggestions to get the size down: * why is httpd on the livecd? * why is mesa-libOSMesa there, that seems a bug * gnome-games is getting quite large, maybe we should split it in gnome-games and gnome-games-extras, if we put glchess in gnome-games-extras, we also loose PyOpenGL and through that python-numeric and freeglut. If someone can draw the line between the main package and extras I'm willing to do the work to make this happen. * gnumeric includes a database data exchange plugin which drags in libgnomedb and libgda, I'm working on an update to 1.8.1, and I plan to put the database plugin (and other plugins which drag in additional deps if I find any) in gnumeric-plugins-extras, saving us the space of libgnomedb and libgda So if some others have some similar ideas, maybe we can shave of a nice amount of the livecd size, maybe making the x86_64 version fit on a CD and / or making room for some other stuff to add. Regards, Hans Luke Macken wrote: > Below is a diff between the F8-Live-i686 and F9-Alpha-Live-i686 Desktop spins. > > > new package libgdiplus-devel: 8584 > new package xorg-x11-server-common: 38863 > new package PolicyKit-gnome-libs: 40188 > new package kerneloops: 52570 > new package swfdec-gtk: 55786 > new package gnome-panel-libs: 56936 > new package swfdec-mozilla: 75911 > new package libconfig: 120055 > new package obex-data-server: 136538 > new package at-spi-python: 170868 > new package ncurses-base: 176949 > new package pixman: 209556 > new package scim-python: 247730 > new package libcurl: 258148 > new package libggz: 289477 > new package libmtp: 398952 > new package xorg-x11-drv-openchrome: 415754 > new package ggz-client-libs: 434830 > new package samyak-fonts: 457144 > new package perl-Date-Manip: 458629 > new package libtasn1: 466849 > new package python-crypto: 571535 > new package elilo: 613010 > new package abyssinica-fonts: 649794 > new package ncurses-libs: 668620 > new package swfdec: 958169 > new package gvfs: 1700127 > new package totem-pl-parser: 2627745 > new package VLGothic-fonts: 3831447 > new package VLGothic-fonts-proportional: 3831790 > new package gnome-settings-daemon: 6218660 > new package mesa-libOSMesa: 7248256 > new package scim-python-chinese: 7621164 > new package libgweather: 14592282 > new package vim-common: 16294034 > new package dasher: 22111835 > new package xulrunner: 24481155 > crontabs grew 144 bytes (6.83%) (2107->2251) > libopenraw-gnome grew 348 bytes (7.94%) (4384->4732) > xorg-x11-drv-fbdev grew 380 bytes (1.84%) (20597->20977) > irqbalance grew 400 bytes (1.85%) (21595->21995) > m17n-contrib grew 469 bytes (1.28%) (36757->37226) > pam_ccreds grew 497 bytes (1.49%) (33428->33925) > smolt-firstboot grew 655 bytes (6.01%) (10893->11548) > pcsc-lite-libs grew 848 bytes (2.44%) (34696->35544) > dbus-x11 grew 884 bytes (3.63%) (24353->25237) > numactl grew 896 bytes (1.00%) (89239->90135) > gnome-bluetooth-libs grew 1278 bytes (1.02%) (124866->126144) > xorg-x11-drv-evdev grew 1445 bytes (4.05%) (35642->37087) > m17n-db-hindi grew 1717 bytes (21.74%) (7899->9616) > sysreport grew 1783 bytes (5.30%) (33620->35403) > libpciaccess grew 1796 bytes (7.21%) (24901->26697) > sg3_utils-libs grew 2156 bytes (1.97%) (109392->111548) > pciutils grew 2464 bytes (1.36%) (180975->183439) > setroubleshoot grew 2541 bytes (1.11%) (229578->232119) > gnome-keyring-pam grew 2556 bytes (8.89%) (28760->31316) > libcap grew 2618 bytes (5.79%) (45230->47848) > apr grew 2823 bytes (1.04%) (271801->274624) > bc grew 2861 bytes (1.50%) (190964->193825) > libsepol grew 2992 bytes (1.33%) (224692->227684) > e2fsprogs-libs grew 3076 bytes (1.23%) (250016->253092) > lohit-fonts-telugu grew 3100 bytes (1.78%) (174487->177587) > device-mapper-libs grew 3680 bytes (4.25%) (86516->90196) > glx-utils grew 3704 bytes (10.98%) (33736->37440) > scim-chewing grew 4072 bytes (3.22%) (126383->130455) > dbus-libs grew 4100 bytes (1.63%) (251944->256044) > nash grew 4128 bytes (1.74%) (237698->241826) > scim-sinhala grew 4140 bytes (6.19%) (66881->71021) > libjpeg grew 4420 bytes (1.61%) (275021->279441) > authconfig-gtk grew 4808 bytes (2.75%) (175143->179951) > mkinitrd grew 4854 bytes (4.84%) (100334->105188) > m17n-contrib-sinhala grew 5443 bytes (48.05%) (11327->16770) > linuxwacom grew 5518 bytes (1.10%) (502293->507811) > desktop-file-utils grew 5523 bytes (4.50%) (122601->128124) > gnome-python2-gnomeprint grew 5547 bytes (1.27%) (437641->443188) > bluez-utils-alsa grew 5856 bytes (13.67%) (42824->48680) > m17n-contrib-telugu grew 6114 bytes (28.08%) (21776->27890) > rsyslog grew 6922 bytes (1.45%) (477587->484509) > ustr grew 7531 bytes (3.12%) (241610->249141) > rhpxl grew 7783 bytes (2.36%) (329907->337690) > xorg-x11-drv-mga grew 8319 bytes (4.91%) (169473->177792) > taglib grew 8368 bytes (1.71%) (489415->497783) > gtk-nodoka-engine grew 8948 bytes (9.32%) (96057->105005) > nscd grew 9484 bytes (6.73%) (140911->150395) > exempi grew 9692 bytes (1.39%) (698782->708474) > gnome-menus grew 9841 bytes (1.57%) (626493->636334) > dbus-glib grew 9970 bytes (2.10%) (473790->483760) > libdhcp6client grew 10524 bytes (6.30%) (166956->177480) > openldap grew 10658 bytes (1.76%) (604986->615644) > nss_ldap grew 12224 bytes (2.17%) (562402->574626) > dmidecode grew 14466 bytes (10.46%) (138266->152732) > NetworkManager-vpnc grew 14477 bytes (4.58%) (316033->330510) > system-config-rootpassword grew 14962 bytes (16.07%) (93118->108080) > gstreamer-python grew 15266 bytes (1.64%) (933175->948441) > rarian grew 15824 bytes (4.99%) (316947->332771) > at-spi grew 16072 bytes (2.38%) (674624->690696) > isomd5sum grew 17146 bytes (36.61%) (46840->63986) > usbutils grew 17192 bytes (19.31%) (89044->106236) > acl grew 17907 bytes (11.99%) (149361->167268) > hicolor-icon-theme grew 17992 bytes (79.30%) (22688->40680) > gnome-python2-desktop grew 18187 bytes (7.44%) (244527->262714) > libdhcp grew 18665 bytes (13.75%) (135727->154392) > which grew 20480 bytes (65.05%) (31485->51965) > NetworkManager-gnome grew 20604 bytes (2.90%) (710665->731269) > pam_krb5 grew 20943 bytes (8.06%) (259736->280679) > system-config-language grew 21674 bytes (8.55%) (253576->275250) > libxcb grew 22328 bytes (5.40%) (413804->436132) > bluez-utils grew 22572 bytes (1.76%) (1280277->1302849) > pygtksourceview grew 23100 bytes (36.06%) (64064->87164) > libgpg-error grew 23525 bytes (12.14%) (193728->217253) > glibmm24 grew 24411 bytes (5.25%) (465396->489807) > fribidi grew 24912 bytes (17.19%) (144894->169806) > gmime grew 24916 bytes (4.24%) (587824->612740) > libuser grew 25215 bytes (1.56%) (1616562->1641777) > xterm grew 25999 bytes (3.24%) (802644->828643) > httpd grew 28595 bytes (1.12%) (2551734->2580329) > libdhcp4client grew 28996 bytes (5.81%) (499144->528140) > m17n-lib grew 30893 bytes (10.14%) (304750->335643) > rhpl grew 31037 bytes (3.99%) (778235->809272) > bind-utils grew 33408 bytes (10.87%) (307362->340770) > NetworkManager grew 33657 bytes (1.42%) (2377366->2411023) > dbus-python grew 36266 bytes (5.11%) (710089->746355) > gnome-mag grew 36431 bytes (7.21%) (504936->541367) > libXpm grew 37746 bytes (52.09%) (72467->110213) > libgnomekbd grew 38042 bytes (6.68%) (569521->607563) > pm-utils grew 39200 bytes (117.36%) (33402->72602) > nautilus-sendto grew 42489 bytes (16.21%) (262118->304607) > dhclient grew 42699 bytes (8.59%) (497288->539987) > gtksourceview2 grew 42895 bytes (2.00%) (2148753->2191648) > krb5-libs grew 45052 bytes (2.96%) (1522532->1567584) > system-config-printer grew 56236 bytes (5.99%) (939482->995718) > gnutls grew 58282 bytes (5.99%) (972804->1031086) > libthai grew 60142 bytes (17.40%) (345628->405770) > bluez-gnome grew 60576 bytes (22.56%) (268531->329107) > mono-data grew 61605 bytes (1.21%) (5087435->5149040) > libwnck grew 62234 bytes (5.42%) (1148126->1210360) > gtk2-engines grew 63679 bytes (6.09%) (1045391->1109070) > system-config-users grew 64047 bytes (4.40%) (1455495->1519542) > gnokii grew 68723 bytes (4.36%) (1575916->1644639) > rsync grew 73058 bytes (18.04%) (404896->477954) > hal-info grew 75029 bytes (20.94%) (358305->433334) > mesa-libGLU grew 77812 bytes (17.12%) (454428->532240) > mdadm grew 83417 bytes (4.79%) (1743098->1826515) > shared-mime-info grew 85852 bytes (9.51%) (902332->988184) > compiz-gnome grew 87904 bytes (7.16%) (1227682->1315586) > PolicyKit-gnome grew 89123 bytes (126.49%) (70457->159580) > GConf2 grew 89585 bytes (1.68%) (5342705->5432290) > dhcpv6-client grew 94965 bytes (54.70%) (173599->268564) > ntfs-3g grew 107185 bytes (36.31%) (295187->402372) > f-spot grew 110065 bytes (1.44%) (7621883->7731948) > PolicyKit grew 121200 bytes (71.93%) (168495->289695) > gnupg grew 126829 bytes (2.62%) (4841029->4967858) > libgcrypt grew 132376 bytes (38.24%) (346204->478580) > libopenraw grew 136838 bytes (101.68%) (134583->271421) > pykickstart grew 141694 bytes (17.92%) (790784->932478) > gnome-python2-gnomevfs grew 142165 bytes (87.24%) (162958->305123) > hwdata grew 144093 bytes (15.63%) (921699->1065792) > shadow-utils grew 144973 bytes (5.29%) (2739389->2884362) > gnome-volume-manager grew 158480 bytes (7.38%) (2146417->2304897) > vbetool grew 162208 bytes (139.43%) (116340->278548) > openssl grew 166448 bytes (4.81%) (3459831->3626279) > libselinux-python grew 171323 bytes (118.46%) (144622->315945) > libsilc grew 180620 bytes (17.41%) (1037560->1218180) > sound-juicer grew 182617 bytes (5.86%) (3114050->3296667) > gnome-system-monitor grew 186353 bytes (3.55%) (5244840->5431193) > gdb grew 193437 bytes (3.11%) (6228176->6421613) > evolution-data-server grew 208724 bytes (1.89%) (11029422->11238146) > PyOpenGL grew 213779 bytes (4.86%) (4398157->4611936) > tomboy grew 218900 bytes (3.63%) (6022535->6241435) > parted grew 223507 bytes (15.16%) (1474368->1697875) > selinux-policy-devel grew 229206 bytes (4.15%) (5522257->5751463) > orca grew 231344 bytes (4.05%) (5718621->5949965) > util-linux-ng grew 245524 bytes (5.17%) (4749959->4995483) > iso-codes grew 269192 bytes (4.80%) (5605136->5874328) > system-config-date grew 282500 bytes (10.09%) (2798572->3081072) > xorg-x11-drv-ati grew 285328 bytes (35.75%) (798151->1083479) > selinux-policy grew 292154 bytes (3.79%) (7707834->7999988) > eog grew 292326 bytes (7.82%) (3740424->4032750) > dbus grew 299134 bytes (58.75%) (509123->808257) > totem grew 321458 bytes (5.87%) (5476956->5798414) > gnome-keyring grew 333541 bytes (32.87%) (1014819->1348360) > glibc grew 347221 bytes (2.59%) (13402107->13749328) > sqlite grew 358672 bytes (76.12%) (471170->829842) > setroubleshoot-server grew 363273 bytes (22.18%) (1637732->2001005) > bind-libs grew 389872 bytes (17.27%) (2258064->2647936) > gcalctool grew 496578 bytes (10.21%) (4862745->5359323) > gnome-panel grew 509960 bytes (4.35%) (11714901->12224861) > gutenprint grew 664813 bytes (15.07%) (4410340->5075153) > rhythmbox grew 678314 bytes (6.41%) (10582223->11260537) > mono-core grew 686301 bytes (2.01%) (34154946->34841247) > nautilus grew 693197 bytes (5.04%) (13751211->14444408) > mono-winforms grew 729754 bytes (7.47%) (9765822->10495576) > totem-mozplugin grew 770229 bytes (136.17%) (565632->1335861) > mono-web grew 797665 bytes (9.85%) (8097242->8894907) > glib2 grew 849381 bytes (29.07%) (2922173->3771554) > gnome-power-manager grew 934030 bytes (8.33%) (11214535->12148565) > nss grew 937664 bytes (44.33%) (2114975->3052639) > libsmbclient grew 1191360 bytes (50.53%) (2357736->3549096) > gnome-games grew 1373569 bytes (4.65%) (29510057->30883626) > kernel grew 1885068 bytes (4.01%) (47063671->48948739) > gutenprint-foomatic grew 2393009 bytes (5.05%) (47405319->49798328) > anaconda grew 2540426 bytes (17.58%) (14448198->16988624) > removed package fonts-punjabi: 0 > removed package aspell-en: 3567971 > removed package fonts-gujarati: 0 > removed package fonts-korean: 0 > removed package fonts-arabic: 0 > removed package xorg-x11-drv-via: 363192 > removed package xorg-x11-drv-avivo: 107204 > removed package fonts-oriya: 0 > removed package xorg-x11-drv-chips: 154533 > removed package fonts-chinese: 0 > removed package fonts-kannada: 0 > removed package xorg-x11-drv-s3: 58401 > removed package fonts-bengali: 0 > removed package fonts-hebrew: 0 > removed package dejavu-lgc-fonts: 6293390 > removed package beecrypt: 242015 > removed package fonts-hindi: 0 > removed package evince: 3452782 > removed package totem-plparser: 70428 > removed package libbeagle: 94092 > removed package xorg-x11-drv-tseng: 52907 > removed package db4o: 1414265 > removed package fuse: 216231 > removed package liberation-fonts: 1097162 > removed package xorg-x11-fonts-truetype: 909077 > removed package fonts-tamil: 0 > removed package fonts-telugu: 0 > removed package xorg-x11-drv-ark: 18888 > removed package fonts-sinhala: 0 > removed package firstboot-tui: 653472 > removed package fonts-malayalam: 0 > removed package curl: 514238 > old has 896 packages > new has 901 packages > From jkeating at redhat.com Fri Jan 25 19:27:22 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 25 Jan 2008 14:27:22 -0500 Subject: long term support release In-Reply-To: <604aa7910801251102y3dcfa168mc9fb750661c9a9b8@mail.gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> <4799EAA0.7030700@gmail.com> <604aa7910801251102y3dcfa168mc9fb750661c9a9b8@mail.gmail.com> Message-ID: <20080125142722.4ff13a36@redhat.com> On Fri, 25 Jan 2008 10:02:00 -0900 "Jeff Spaleta" wrote: > Anything involving how RHEL is put together is complete and utterly > out of the control of Fedora governance. Even as a fedora board > member I have zero impact on how RHEL is put together and positioned, > so even at the board level I cannot plan to know which Fedora is > actually the base for RHEL, nor can I drive any decision making there. This is not actually true. In fact, there is a lot of what RHEL does where it takes queues from what Fedora does. Perhaps this isn't very well communicated, but to state that as Fedora leadership you have no input/control into what RHEL does is pretty false. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dakingun at gmail.com Fri Jan 25 19:29:44 2008 From: dakingun at gmail.com (Deji Akingunola) Date: Fri, 25 Jan 2008 14:29:44 -0500 Subject: F9 Alpha spinning In-Reply-To: <20080125162835.GA19048@crow> References: <20080125162835.GA19048@crow> Message-ID: 2008/1/25 Luke Macken : > Here are some details on the current live bits for F9 Alpha. > > > > Below is a diff between the F8-Live-i686 and F9-Alpha-Live-i686 Desktop spins. > > removed package evince: 3452782 I wonder why evince is removed from the Desktop spin, an oversight? Deji From pertusus at free.fr Fri Jan 25 19:34:47 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 25 Jan 2008 20:34:47 +0100 Subject: F9 Alpha spinning In-Reply-To: References: <20080125162835.GA19048@crow> Message-ID: <20080125193447.GE2656@free.fr> On Fri, Jan 25, 2008 at 02:29:44PM -0500, Deji Akingunola wrote: > 2008/1/25 Luke Macken : > > Here are some details on the current live bits for F9 Alpha. > > > > > > > > > Below is a diff between the F8-Live-i686 and F9-Alpha-Live-i686 Desktop spins. > > > > > removed package evince: 3452782 > > I wonder why evince is removed from the Desktop spin, an oversight? It is because for dvi support it drags in most of texlive to have the fonts generated. Work is underway to reduce the dependency amount, but I doubt this will be enough. -- Pat From lkundrak at redhat.com Fri Jan 25 19:36:55 2008 From: lkundrak at redhat.com (Lubomir Kundrak) Date: Fri, 25 Jan 2008 20:36:55 +0100 Subject: F9 Alpha spinning In-Reply-To: <479A36D6.2060405@hhs.nl> References: <20080125162835.GA19048@crow> <479A36D6.2060405@hhs.nl> Message-ID: <1201289816.6898.21.camel@localhost.localdomain> Hi Hans, On Fri, 2008-01-25 at 20:21 +0100, Hans de Goede wrote: .. > Some questions / suggestions to get the size down: > * why is httpd on the livecd? I think it's the personal file sharing via DAV thing. -- Lubomir Kundrak (Red Hat Security Response Team) From mmcgrath at redhat.com Fri Jan 25 19:48:46 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Fri, 25 Jan 2008 13:48:46 -0600 (CST) Subject: long term support release In-Reply-To: <604aa7910801251102y3dcfa168mc9fb750661c9a9b8@mail.gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> <4799EAA0.7030700@gmail.com> <604aa7910801251102y3dcfa168mc9fb750661c9a9b8@mail.gmail.com> Message-ID: On Fri, 25 Jan 2008, Jeff Spaleta wrote: > On Jan 25, 2008 4:56 AM, Les Mikesell wrote: > > How about a slight variation on the fedora LTS plan that might vastly > > reduce the needed work and let people keep running without the dangers > > of going without security fixes? What if the versions supported were > > the ones used as the base of the RHEL cuts, and the subsequent updates > > were recompiled from the CentOS source RPM's? > > Anything involving how RHEL is put together is complete and utterly > out of the control of Fedora governance. Even as a fedora board > member I have zero impact on how RHEL is put together and positioned, > so even at the board level I cannot plan to know which Fedora is > actually the base for RHEL, nor can I drive any decision making there. > I think you're talking about "given power" and I think Jesse is more talking about "expert power". We cannot make mandates to RHEL, and in that way we have no control over it. But the quality of our work often speaks for itself and goes, unaltered, into RHEL. And in that way, we certainly shape the outcome of what RHEL is. -Mike From cmadams at hiwaay.net Fri Jan 25 19:56:57 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 25 Jan 2008 13:56:57 -0600 Subject: Minor (but easily fixed) bugs for someone? Message-ID: <20080125195656.GF1306470@hiwaay.net> I've got a few minor bugs in bugzilla that would be nice to have fixed before F9 (and in F7 and/or F8). These are minor things with fixes and/or patches included in the BZ entry, but nothing has apparently been done by the maintainers. I'm not a maintainer myself (one of these days when I get some round tuits and am not so lazy maybe I'll be one), but these all seem to be 5 minute or less fixes. - radiusclient-ng: bug in Fedora patch (fix attached) https://bugzilla.redhat.com/show_bug.cgi?id=236350 - hal-info: missing entry (in comment but not actual config) https://bugzilla.redhat.com/show_bug.cgi?id=425875 - NetworkManager/hal: changing system LC_COLLATE (and possibly other i18n settings) breaks startup https://bugzilla.redhat.com/show_bug.cgi?id=425876 Is there a better way to poke people on these other than BZ? I know everybody is busy, but I don't know if I should be doing something else to get these fixed. I'd be happy to help any way that I can. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jspaleta at gmail.com Fri Jan 25 19:57:42 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 25 Jan 2008 10:57:42 -0900 Subject: long term support release In-Reply-To: <20080125142722.4ff13a36@redhat.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> <4799EAA0.7030700@gmail.com> <604aa7910801251102y3dcfa168mc9fb750661c9a9b8@mail.gmail.com> <20080125142722.4ff13a36@redhat.com> Message-ID: <604aa7910801251157r26e3d6f7raa47da9c22029447@mail.gmail.com> 2008/1/25 Jesse Keating : > This is not actually true. In fact, there is a lot of what RHEL does > where it takes queues from what Fedora does. Perhaps this isn't very > well communicated, but to state that as Fedora leadership you have no > input/control into what RHEL does is pretty false. I have no...control. I've got input, yes.. but not control. Big difference. Of course there is a measure of alignment, since there is engineering resources that Red Hat makes available that crosses the fenceline. And I know that people who straddle that fence line are making a damn important effort to make the alignment better over time, to the benefit of everyone. But at the same time, everyone out here firmly planted in Fedora land who stands on tippy-toe to see over into the RHEL side of things, needs to understand that to effectively drive changes in how Fedora and RHEL interface requires some mutual benefit arguments. Something I'm not currently seeing a lot of in how externals are approaching the conversation. Which is why I want to go to the Summit, grab a few RHEL customer reps, put their head in a vice, and squeeze out some ideas from their perspective to add to my Fedora roadmap smoothie. -jef From jkeating at redhat.com Fri Jan 25 20:01:03 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 25 Jan 2008 15:01:03 -0500 Subject: More firewall changes for F-9+ In-Reply-To: <479A3663.1060309@redhat.com> References: <479A3663.1060309@redhat.com> Message-ID: <20080125150103.227ed678@redhat.com> On Fri, 25 Jan 2008 20:20:03 +0100 Thomas Woerner wrote: > some minutes ago system-config-firewall-1.2.0 has been build for > rawhide. FYI I have tagged this for Fedora 9 Alpha. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Fri Jan 25 20:09:47 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 25 Jan 2008 21:09:47 +0100 Subject: F9 Alpha spinning In-Reply-To: <1201289816.6898.21.camel@localhost.localdomain> References: <20080125162835.GA19048@crow> <479A36D6.2060405@hhs.nl> <1201289816.6898.21.camel@localhost.localdomain> Message-ID: <479A420B.9050609@hhs.nl> Lubomir Kundrak wrote: > Hi Hans, > > On Fri, 2008-01-25 at 20:21 +0100, Hans de Goede wrote: > .. >> Some questions / suggestions to get the size down: >> * why is httpd on the livecd? > > I think it's the personal file sharing via DAV thing. > Hmm, although a cool feature not really something we necessarily need on a livecd, any chance we could isolate that in some subpackage and exclude it from the livecd? Regards, Hans From j.w.r.degoede at hhs.nl Fri Jan 25 20:15:52 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 25 Jan 2008 21:15:52 +0100 Subject: Minor (but easily fixed) bugs for someone? In-Reply-To: <20080125195656.GF1306470@hiwaay.net> References: <20080125195656.GF1306470@hiwaay.net> Message-ID: <479A4378.6060205@hhs.nl> Chris Adams wrote: > I've got a few minor bugs in bugzilla that would be nice to have fixed > before F9 (and in F7 and/or F8). These are minor things with fixes > and/or patches included in the BZ entry, but nothing has apparently been > done by the maintainers. I'm not a maintainer myself (one of these days > when I get some round tuits and am not so lazy maybe I'll be one), but > these all seem to be 5 minute or less fixes. > > - radiusclient-ng: bug in Fedora patch (fix attached) > https://bugzilla.redhat.com/show_bug.cgi?id=236350 > > - hal-info: missing entry (in comment but not actual config) > https://bugzilla.redhat.com/show_bug.cgi?id=425875 > > - NetworkManager/hal: changing system LC_COLLATE (and possibly other > i18n settings) breaks startup > https://bugzilla.redhat.com/show_bug.cgi?id=425876 > > Is there a better way to poke people on these other than BZ? I know > everybody is busy, but I don't know if I should be doing something else > to get these fixed. I'd be happy to help any way that I can. > I'm always happy to spend some time fixing things like this. But I don't own any of these package. So if their resp. owners are ok with me jumping in and fixing these, let me know. In that case please also give me the necessary rights in packagedb (FAS account jwrdegoede) or open up the package to the cvsextras group. Regards, Hans From lesmikesell at gmail.com Fri Jan 25 20:25:08 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 25 Jan 2008 14:25:08 -0600 Subject: long term support release In-Reply-To: <604aa7910801251157r26e3d6f7raa47da9c22029447@mail.gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> <4799EAA0.7030700@gmail.com> <604aa7910801251102y3dcfa168mc9fb750661c9a9b8@mail.gmail.com> <20080125142722.4ff13a36@redhat.com> <604aa7910801251157r26e3d6f7raa47da9c22029447@mail.gmail.com> Message-ID: <479A45A4.1060801@gmail.com> Jeff Spaleta wrote: > 2008/1/25 Jesse Keating : >> This is not actually true. In fact, there is a lot of what RHEL does >> where it takes queues from what Fedora does. Perhaps this isn't very >> well communicated, but to state that as Fedora leadership you have no >> input/control into what RHEL does is pretty false. > > I have no...control. I've got input, yes.. but not control. Big > difference. Of course there is a measure of alignment, since there is > engineering resources that Red Hat makes available that crosses the > fenceline. And I know that people who straddle that fence line are > making a damn important effort to make the alignment better over time, > to the benefit of everyone. > > But at the same time, everyone out here firmly planted in Fedora land > who stands on tippy-toe to see over into the RHEL side of things, > needs to understand that to effectively drive changes in how Fedora > and RHEL interface requires some mutual benefit arguments. > Something I'm not currently seeing a lot of in how externals are > approaching the conversation. > > Which is why I want to go to the Summit, grab a few RHEL customer > reps, put their head in a vice, and squeeze out some ideas from their > perspective to add to my Fedora roadmap smoothie. > It's not so much a question of what goes into RHEL, but the feasibility of converting whatever that might be back into fedora updates after the fact, something that might not be possible to know until the time comes unless someone wants to try FC6->RHEL5 at this point. It might go more smoothly if it could be planned that way, though. -- Les Mikesell lesmikesell at gmail.com From rc040203 at freenet.de Fri Jan 25 11:24:25 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 25 Jan 2008 12:24:25 +0100 Subject: long term support release In-Reply-To: <20080125112959.baaf72d3.mschwendt.tmp0701.nospam@arcor.de> References: <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <20080125090654.GA3062@orient.maison.lan> <1201253280.17905.280.camel@beck.corsepiu.local> <20080125094711.GA3298@orient.maison.lan> <20080125112959.baaf72d3.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1201260265.17905.299.camel@beck.corsepiu.local> On Fri, 2008-01-25 at 11:29 +0100, Michael Schwendt wrote: > On Fri, 25 Jan 2008 10:47:11 +0100, Emmanuel Seyman wrote: > > > * Ralf Corsepius [25/01/2008 10:31] : > > > > > > Do you have the TBytes to host it, do you have dozens of mirrors, do you > > > have the bandwidth, do you have the man-power to administrate the > > > buildsystem? > > > > Were I interested in Fedora LTS, I'll start looking for server space and > > bandwidth (man-power isn't exactly a technical ressource). And, yes, > > I'm certain I could find enough to get started. > > > > > Have a look at rpmfusion - Despite they are working on it for months, > > > AFAICT, trying to copy/reuse the fedoraproject.org infrastructure it's > > > still not up. > > > > Is copying the Fedora infrastructure really the showstopper ? > > Last I heard, it was hardware problems and lack of man-power. All I know is what had been posted to the rpmfusion lists. I recall complaints about setting up FAS, I recall complaints on lack of stability, I recall pleas for help due to lack of knowledge and of man-power. > Do you expect anyone outside the Fedora Project to duplicate existing > Fedora Infrastructure, such as bugzilla, CVS+FAS, lookaside cache, > buildsys for multiple architectures, master repos, introduce a new GPG > key, switch mailing-lists, advertise the whole thing as a non-Fedora > project? Exactly this had been the reasons > That would make it much more difficult. > Well, I'm sceptical that there would be enough volunteers to offer Fedora > LTS free of charge, even if the Fedora Project permitted use of their > infrastructure. Which costs would * extending FC7's life time (and may-be re-branding/re-labeling it) * combined with lifting all ACLs (in particular "core"/RH ACLs such that community folks can intervene) * and keeping alive the infrastructure introduce? No doubt, it would introduce some costs, ... but most of it could be "bought-in" as side-effects of what already exists and needs to be maintained anyway (buildsys, build machines, bugzilla, mirrors etc.). > Fedora LTS would compete with CentOS+EPEL and would lead > to even more mass-builds. We are back to what IMO, this all obits around: questioning the "will" :/ > Still, a discussion of Fedora LTS should start > with outlining guarantees (or less strictly, the concrete project > goals/promises), policies, procedures, and a gathering of people with > strong interest in such a project. Agreed, this would be the actually critical, and the actually interesting part. > Long before determining whether > infrastructure is the last thing that holds up the project. ... but this is what would cause the real costs and what is building up the barriers preventing 3rd parties from jumping "onto this train". Ralf From sundaram at fedoraproject.org Fri Jan 25 20:47:19 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 26 Jan 2008 02:17:19 +0530 Subject: long term support release In-Reply-To: <20080125160247.GA5952@orient.maison.lan> References: <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <20080125103144.68eec1ff@redhat.com> <20080125153747.GB2975@free.fr> <20080125104307.382ce039@redhat.com> <20080125155059.GE2975@free.fr> <20080125155124.GA5809@orient.maison.lan> <479A0A55.60409@fedoraproject.org> <20080125160247.GA5952@orient.maison.lan> Message-ID: <479A4AD7.2000500@fedoraproject.org> Emmanuel Seyman wrote: > * Rahul Sundaram [25/01/2008 17:01] : >> .. unless Fedora LTS is a rebuild of RHEL SRPMS. There might be some >> advantages to this worth considering. > > as ooposed to just using CentOS ? I don't see any. * Make available binaries as part of Fedora brand and have some Fedora releases with a longer lifecycle * Kill the "beta" memo * Support coordination with EPEL more easily There are a lot of potential advantages. Otherwise discussions like these will likely continue every now and then. Rahul From sundaram at fedoraproject.org Fri Jan 25 21:00:06 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 26 Jan 2008 02:30:06 +0530 Subject: F9 Alpha spinning In-Reply-To: <20080125162835.GA19048@crow> References: <20080125162835.GA19048@crow> Message-ID: <479A4DD6.2060705@fedoraproject.org> Luke Macken wrote: > Here are some details on the current live bits for F9 Alpha. > > > -rw-r--r-- 1 root root 1.6G 2008-01-24 16:00 F9-Alpha-Developer-20080124.0.iso > -rw-r--r-- 1 root root 740M 2008-01-24 16:13 F9-Alpha-FEL-i686-20080124.0.iso > -rw-r--r-- 1 root root 3.6G 2008-01-24 16:52 F9-Alpha-games-i686-20080124.0.iso Are you sure, you are picking the latest content for the games live dvd from http://fedoraproject.org/wiki/SIGs/Games/GamesLive If I can get commit access, I can keep it updated in livecd-tools. Rahul From cra at WPI.EDU Fri Jan 25 20:52:49 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 25 Jan 2008 15:52:49 -0500 Subject: More firewall changes for F-9+ In-Reply-To: <479A3663.1060309@redhat.com> References: <479A3663.1060309@redhat.com> Message-ID: <20080125205249.GB31359@angus.ind.WPI.EDU> On Fri, Jan 25, 2008 at 08:20:03PM +0100, Thomas Woerner wrote: > some minutes ago system-config-firewall-1.2.0 has been build for rawhide. > - New support for port forwarding. > - The chain RH-Firewall-1-INPUT has been dropped. > - Trusted hosts are also added to the FORWARD chain in the filter table. > - The iptables firewall configuration has been optimized. > - Several GUI enhancements. Does it fix this bug? https://bugzilla.redhat.com/show_bug.cgi?id=426720 Masquerading doesn't allow packets to be forwarded by default From opensource at till.name Fri Jan 25 20:53:33 2008 From: opensource at till.name (Till Maas) Date: Fri, 25 Jan 2008 21:53:33 +0100 Subject: bug gone bad: boot.log In-Reply-To: <20080125172950.GE28249@nostromo.devel.redhat.com> References: <1201280677.3696.5.camel@sb-home> <20080125172950.GE28249@nostromo.devel.redhat.com> Message-ID: <200801252153.42174.opensource@till.name> On Fri January 25 2008, Bill Nottingham wrote: > Taking patches; the issue is that the system has changed enough in > the interim (between udev, SELinux, etc.) that the old code no longer > is a drop-in replacement. Further updates to the bug aren't really > useful until work is being done on it. Please write in the bug report, that you take patches, then everyone knows that writing a patch is worth the trouble. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From notting at redhat.com Fri Jan 25 20:55:01 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 25 Jan 2008 15:55:01 -0500 Subject: F9 Alpha spinning In-Reply-To: <479A4DD6.2060705@fedoraproject.org> References: <20080125162835.GA19048@crow> <479A4DD6.2060705@fedoraproject.org> Message-ID: <20080125205501.GA22974@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: > Luke Macken wrote: >> Here are some details on the current live bits for F9 Alpha. >> >> >> -rw-r--r-- 1 root root 1.6G 2008-01-24 16:00 F9-Alpha-Developer-20080124.0.iso >> -rw-r--r-- 1 root root 740M 2008-01-24 16:13 F9-Alpha-FEL-i686-20080124.0.iso >> -rw-r--r-- 1 root root 3.6G 2008-01-24 16:52 F9-Alpha-games-i686-20080124.0.iso > > Are you sure, you are picking the latest content for the games live dvd from > > http://fedoraproject.org/wiki/SIGs/Games/GamesLive > > If I can get commit access, I can keep it updated in livecd-tools. Long term, do we really want to store all contributed spin configs in livecd-tools itself? Bill From pertusus at free.fr Fri Jan 25 20:59:03 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 25 Jan 2008 21:59:03 +0100 Subject: long term support release In-Reply-To: <1201260265.17905.299.camel@beck.corsepiu.local> References: <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <20080125090654.GA3062@orient.maison.lan> <1201253280.17905.280.camel@beck.corsepiu.local> <20080125094711.GA3298@orient.maison.lan> <20080125112959.baaf72d3.mschwendt.tmp0701.nospam@arcor.de> <1201260265.17905.299.camel@beck.corsepiu.local> Message-ID: <20080125205903.GF2656@free.fr> On Fri, Jan 25, 2008 at 12:24:25PM +0100, Ralf Corsepius wrote: > Which costs would > * extending FC7's life time (and may-be re-branding/re-labeling it) > * combined with lifting all ACLs (in particular "core"/RH ACLs such that > community folks can intervene) > * and keeping alive the infrastructure > introduce? In another post JEsse told that Jeff was ready to accept a plan like that. -- Pat From rnorwood at redhat.com Fri Jan 25 21:00:10 2008 From: rnorwood at redhat.com (Robin Norwood) Date: Fri, 25 Jan 2008 16:00:10 -0500 Subject: Why is the time removed from the package intallation window In-Reply-To: <20080122182020.GA52994@dspnet.fr.eu.org> References: <20080122173226.GB46223@dspnet.fr.eu.org> <20080122175415.GA18331@nostromo.devel.redhat.com> <20080122182020.GA52994@dspnet.fr.eu.org> Message-ID: <1201294810.32009.1.camel@solitude.devel.redhat.com> On Tue, 2008-01-22 at 19:20 +0100, Olivier Galibert wrote: > On Tue, Jan 22, 2008 at 12:54:15PM -0500, Bill Nottingham wrote: > > Olivier Galibert (galibert at pobox.com) said: > > > I noticed now that I'm starting to actually install systems with f8 > > > that the time used/remaining indication has been removed from the text > > > installation screen. I'm curious, why is that? > > > > It's non-trivial to render accurately (it wasn't particularly accurate > > before...) > > T'was better than nothing though. The time at the end at least was > accurate and gave you an idea on how long the next installation would > take. I didn't realize I'd have to time it by hand. --- --- --- -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From sundaram at fedoraproject.org Fri Jan 25 21:09:59 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 26 Jan 2008 02:39:59 +0530 Subject: F9 Alpha spinning In-Reply-To: <20080125205501.GA22974@nostromo.devel.redhat.com> References: <20080125162835.GA19048@crow> <479A4DD6.2060705@fedoraproject.org> <20080125205501.GA22974@nostromo.devel.redhat.com> Message-ID: <479A5027.4040902@fedoraproject.org> Bill Nottingham wrote: > Rahul Sundaram (sundaram at fedoraproject.org) said: >> Luke Macken wrote: >>> Here are some details on the current live bits for F9 Alpha. >>> >>> >>> -rw-r--r-- 1 root root 1.6G 2008-01-24 16:00 F9-Alpha-Developer-20080124.0.iso >>> -rw-r--r-- 1 root root 740M 2008-01-24 16:13 F9-Alpha-FEL-i686-20080124.0.iso >>> -rw-r--r-- 1 root root 3.6G 2008-01-24 16:52 F9-Alpha-games-i686-20080124.0.iso >> Are you sure, you are picking the latest content for the games live dvd from >> >> http://fedoraproject.org/wiki/SIGs/Games/GamesLive >> >> If I can get commit access, I can keep it updated in livecd-tools. > > Long term, do we really want to store all contributed spin configs > in livecd-tools itself? I have no strong feelings about that but it is convenient that way. Maybe it won't be scalable in the future. I have more than a dozen spins I have created and proposed so far. Wherever they are stored, I would like to make sure that what is being currently kept updated in the wiki (because I don't have access to livecd-tools) is in sync with the copy in livecd-tools itself or where you want to keep it in the future that is considered the authoritative source. Rahul From jkeating at redhat.com Fri Jan 25 20:59:15 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 25 Jan 2008 15:59:15 -0500 Subject: F9 Alpha spinning In-Reply-To: <20080125205501.GA22974@nostromo.devel.redhat.com> References: <20080125162835.GA19048@crow> <479A4DD6.2060705@fedoraproject.org> <20080125205501.GA22974@nostromo.devel.redhat.com> Message-ID: <20080125155915.7ea8225a@redhat.com> On Fri, 25 Jan 2008 15:55:01 -0500 Bill Nottingham wrote: > Long term, do we really want to store all contributed spin configs > in livecd-tools itself? Likely not, but we haven't engineered an elegant solution to config storage yet. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ivazqueznet at gmail.com Fri Jan 25 21:10:00 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 25 Jan 2008 16:10:00 -0500 Subject: More firewall changes for F-9+ In-Reply-To: <479A3663.1060309@redhat.com> References: <479A3663.1060309@redhat.com> Message-ID: <1201295400.23391.0.camel@ignacio.lan> On Fri, 2008-01-25 at 20:20 +0100, Thomas Woerner wrote: > some minutes ago system-config-firewall-1.2.0 has been build for rawhide. OT: How badly would this blow up on EL4? -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mclasen at redhat.com Fri Jan 25 21:17:24 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 25 Jan 2008 16:17:24 -0500 Subject: F9 Alpha spinning In-Reply-To: <20080125193447.GE2656@free.fr> References: <20080125162835.GA19048@crow> <20080125193447.GE2656@free.fr> Message-ID: <1201295844.4858.1.camel@localhost.localdomain> On Fri, 2008-01-25 at 20:34 +0100, Patrice Dumas wrote: > On Fri, Jan 25, 2008 at 02:29:44PM -0500, Deji Akingunola wrote: > > 2008/1/25 Luke Macken : > > > Here are some details on the current live bits for F9 Alpha. > > > > > > > > > > > > > > Below is a diff between the F8-Live-i686 and F9-Alpha-Live-i686 Desktop spins. > > > > > > > > removed package evince: 3452782 > > > > I wonder why evince is removed from the Desktop spin, an oversight? > > It is because for dvi support it drags in most of texlive to have the > fonts generated. Work is underway to reduce the dependency amount, but I > doubt this will be enough. evince should not drag in anything beyond kpathsea, really. All that needs to happen is top drop the kpathsea -> texlive requires. From lmacken at redhat.com Fri Jan 25 21:27:01 2008 From: lmacken at redhat.com (Luke Macken) Date: Fri, 25 Jan 2008 16:27:01 -0500 Subject: F9 Alpha spinning In-Reply-To: <479A4DD6.2060705@fedoraproject.org> References: <20080125162835.GA19048@crow> <479A4DD6.2060705@fedoraproject.org> Message-ID: <20080125212701.GA1831@crow> On Sat, Jan 26, 2008 at 02:30:06AM +0530, Rahul Sundaram wrote: > Luke Macken wrote: >> Here are some details on the current live bits for F9 Alpha. >> >> >> -rw-r--r-- 1 root root 1.6G 2008-01-24 16:00 F9-Alpha-Developer-20080124.0.iso >> -rw-r--r-- 1 root root 740M 2008-01-24 16:13 F9-Alpha-FEL-i686-20080124.0.iso >> -rw-r--r-- 1 root root 3.6G 2008-01-24 16:52 F9-Alpha-games-i686-20080124.0.iso > > Are you sure, you are picking the latest content for the games live dvd from > > http://fedoraproject.org/wiki/SIGs/Games/GamesLive > > If I can get commit access, I can keep it updated in livecd-tools. I used the latest configs from the livecd-tools git repo. Unfortunately I don't have commit access to this either. I'll try and prod someone to give me access so I can update your config. luke From jspaleta at gmail.com Fri Jan 25 21:35:35 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 25 Jan 2008 12:35:35 -0900 Subject: long term support release In-Reply-To: <20080125182811.GA2656@free.fr> References: <20080125090850.GC2750@free.fr> <20080125093517.GA16080@free.fr> <20080125103144.68eec1ff@redhat.com> <20080125153747.GB2975@free.fr> <200801251638.m0PGcbnL014079@laptop13.inf.utfsm.cl> <20080125164413.GB3480@free.fr> <20080125115319.28d78ae6@redhat.com> <20080125170756.GA3785@free.fr> <20080125121357.465a8a6f@redhat.com> <20080125182811.GA2656@free.fr> Message-ID: <604aa7910801251335j4732ab7dke185bfcd96064335@mail.gmail.com> On Jan 25, 2008 9:28 AM, Patrice Dumas wrote: > Ok, I am very sorry for the noise, I didn't understood that. It > satisfies me completely... I personnally don't need this so I won't lead > it, but I could help and I would take care of my packages in that setting. Okay I'm going to be very very frank for a second. It frustrates the absolute crap out of me to see aggressively vocal proponents of an idea, falling back into the background after going through 3 or 4 rounds of painful discourse instead of stepping up and attempting to lead. I don't care if i personally agree with the ideas or not, but if I'm going to slug it out with someone in an effort to reach a forward looking compromise that stakeholders can live with, then I pretty much expect that person to continue to be a partner in driving things forward. It more than frustrates me, it hurts...deeply... because this kills forward momentum. I'm much more inclined to bend over backwards to grease the wheels, with my own blood even, for someone who is committed to making the effort to lead an idea, than I am to even hold a door open for someone who just wants to talk about it. This project has an infinite things that it 'could' do. But we absolute need people who will lead those efforts. People passionate about that area, who can build up communities of volunteers to keep the work moving. Please, I'm begging you, direct your passion on an area you can lead and if you do that I'll do what I can to help you recruit users and contributors to increase the impact of your efforts. -jef From walters at redhat.com Fri Jan 25 21:39:35 2008 From: walters at redhat.com (Colin Walters) Date: Fri, 25 Jan 2008 16:39:35 -0500 Subject: F9 Alpha spinning In-Reply-To: <20080125155915.7ea8225a@redhat.com> References: <20080125162835.GA19048@crow> <479A4DD6.2060705@fedoraproject.org> <20080125205501.GA22974@nostromo.devel.redhat.com> <20080125155915.7ea8225a@redhat.com> Message-ID: <1201297175.9568.2.camel@space-ghost.verbum.private> On Fri, 2008-01-25 at 15:59 -0500, Jesse Keating wrote: > On Fri, 25 Jan 2008 15:55:01 -0500 > Bill Nottingham wrote: > > > Long term, do we really want to store all contributed spin configs > > in livecd-tools itself? > > Likely not, but we haven't engineered an elegant solution to config > storage yet. How about putting them in the same CVS directory as comps? That way we can use the fedora ACL infrastructure for access and in addition, having them in the same place helps us notice overlap and will help motivation for merging the two. From jkeating at redhat.com Fri Jan 25 21:43:23 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 25 Jan 2008 16:43:23 -0500 Subject: F9 Alpha spinning In-Reply-To: <1201297175.9568.2.camel@space-ghost.verbum.private> References: <20080125162835.GA19048@crow> <479A4DD6.2060705@fedoraproject.org> <20080125205501.GA22974@nostromo.devel.redhat.com> <20080125155915.7ea8225a@redhat.com> <1201297175.9568.2.camel@space-ghost.verbum.private> Message-ID: <20080125164323.3696b94f@redhat.com> On Fri, 25 Jan 2008 16:39:35 -0500 Colin Walters wrote: > How about putting them in the same CVS directory as comps? That way > we can use the fedora ACL infrastructure for access and in addition, > having them in the same place helps us notice overlap and will help > motivation for merging the two. The elegant part of that comes from easily pulling that information out (: Our comps stuff isn't necessarily elegant, but I suppose it's better than nothing. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Fri Jan 25 16:13:09 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 25 Jan 2008 17:13:09 +0100 Subject: long term support release In-Reply-To: <20080125160247.GA5952@orient.maison.lan> References: <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <20080125103144.68eec1ff@redhat.com> <20080125153747.GB2975@free.fr> <20080125104307.382ce039@redhat.com> <20080125155059.GE2975@free.fr> <20080125155124.GA5809@orient.maison.lan> <479A0A55.60409@fedoraproject.org> <20080125160247.GA5952@orient.maison.lan> Message-ID: <1201277589.17905.369.camel@beck.corsepiu.local> On Fri, 2008-01-25 at 17:02 +0100, Emmanuel Seyman wrote: > * Rahul Sundaram [25/01/2008 17:01] : > > > > .. unless Fedora LTS is a rebuild of RHEL SRPMS. There might be some > > advantages to this worth considering. > > as ooposed to just using CentOS ? I don't see any. Do you want current packages or do you want the 3 year versions in RHEL? To me, Fedora has evolved into "unstable rawhide snapshots" while CentOS is yesterday's stuff. The mid-ground is missing. Ralf From lmacken at redhat.com Fri Jan 25 22:16:36 2008 From: lmacken at redhat.com (Luke Macken) Date: Fri, 25 Jan 2008 17:16:36 -0500 Subject: F9 Alpha spinning In-Reply-To: <20080125212701.GA1831@crow> References: <20080125162835.GA19048@crow> <479A4DD6.2060705@fedoraproject.org> <20080125212701.GA1831@crow> Message-ID: <20080125221636.GB1831@crow> On Fri, Jan 25, 2008 at 04:27:01PM -0500, Luke Macken wrote: > On Sat, Jan 26, 2008 at 02:30:06AM +0530, Rahul Sundaram wrote: > > Luke Macken wrote: > >> Here are some details on the current live bits for F9 Alpha. > >> > >> > >> -rw-r--r-- 1 root root 1.6G 2008-01-24 16:00 F9-Alpha-Developer-20080124.0.iso > >> -rw-r--r-- 1 root root 740M 2008-01-24 16:13 F9-Alpha-FEL-i686-20080124.0.iso > >> -rw-r--r-- 1 root root 3.6G 2008-01-24 16:52 F9-Alpha-games-i686-20080124.0.iso > > > > Are you sure, you are picking the latest content for the games live dvd from > > > > http://fedoraproject.org/wiki/SIGs/Games/GamesLive > > > > If I can get commit access, I can keep it updated in livecd-tools. > > I used the latest configs from the livecd-tools git repo. Unfortunately > I don't have commit access to this either. I'll try and prod someone to > give me access so I can update your config. I added livecd-fedora-games.ks, which is the latest kickstart file from the wiki, to the livecd-tools configs. luke From orion at cora.nwra.com Fri Jan 25 22:39:09 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 25 Jan 2008 15:39:09 -0700 Subject: F9 for Eeepc Message-ID: <479A650D.8060401@cora.nwra.com> I got myself an Eeepc to play around with and I'd love to get Fedora running on it. Issues that I'm aware of: - Ethernet driver. Controller is an Attansic Tech L2 100Mbit Ethernet Adapter (rev a0) (0200: 1969:2048). This uses the atl2 driver. Anyone have any ideas on the chances of this going upstream? Interestingly I see this in some of the 2.0.3 files: * Copyright(c) 2007 Chris Snook - Wireless driver. Controller is an Atheros AR5007EG 802.11 b/g Wireless PCI Express Adapter. (168c:001c rev 01). Distributed versions appears to use the madwifi drivers. Sounds like ath5k is the way forward though. - Flash drive. Want to minimize writes. One attempt (eeedora) uses the ext2 filesystem rather than ext3. Does that help? Are there things to take from stateless projects for minimizing writes to /var? other stuff? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From walters at redhat.com Fri Jan 25 22:47:55 2008 From: walters at redhat.com (Colin Walters) Date: Fri, 25 Jan 2008 17:47:55 -0500 Subject: F9 for Eeepc In-Reply-To: <479A650D.8060401@cora.nwra.com> References: <479A650D.8060401@cora.nwra.com> Message-ID: <1201301275.9568.6.camel@space-ghost.verbum.private> On Fri, 2008-01-25 at 15:39 -0700, Orion Poplawski wrote: > - Flash drive. Want to minimize writes. One attempt (eeedora) uses the > ext2 filesystem rather than ext3. Does that help? Are there things to > take from stateless projects for minimizing writes to /var? One approach is to say that actually the entire filesystem is read-only, kind of like a live OS except for /home, which is on the required SD card. There is certainly work on this that's been done in the context of the Stateless project in the past. The only time it needs to be made un-readonly is for software updates. Downside of this approach is that you can't use the SD card for reading photos from your camera. From pertusus at free.fr Fri Jan 25 22:51:40 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 25 Jan 2008 23:51:40 +0100 Subject: long term support release In-Reply-To: <604aa7910801251335j4732ab7dke185bfcd96064335@mail.gmail.com> References: <20080125093517.GA16080@free.fr> <20080125103144.68eec1ff@redhat.com> <20080125153747.GB2975@free.fr> <200801251638.m0PGcbnL014079@laptop13.inf.utfsm.cl> <20080125164413.GB3480@free.fr> <20080125115319.28d78ae6@redhat.com> <20080125170756.GA3785@free.fr> <20080125121357.465a8a6f@redhat.com> <20080125182811.GA2656@free.fr> <604aa7910801251335j4732ab7dke185bfcd96064335@mail.gmail.com> Message-ID: <20080125225140.GG2656@free.fr> On Fri, Jan 25, 2008 at 12:35:35PM -0900, Jeff Spaleta wrote: > On Jan 25, 2008 9:28 AM, Patrice Dumas wrote: > > Ok, I am very sorry for the noise, I didn't understood that. It > > satisfies me completely... I personnally don't need this so I won't lead > > it, but I could help and I would take care of my packages in that setting. > > > Okay I'm going to be very very frank for a second. > > It frustrates the absolute crap out of me to see aggressively vocal > proponents of an idea, falling back into the background after going > through 3 or 4 rounds of painful discourse instead of stepping up and > attempting to lead. I don't care if i personally agree with the ideas I was never an aggressively vocal proponent of that idea. I was agressively proponent of letting the fedora contributors decide for themselves if they want to contribute to an Update Distro after EOL. I think that it is important for the distro, and it is in itself a task that uses a lot of energy. Of course it would be better if I could lead that effort, but if you look at what I said it was never my point of view. I also had similar talks about diversity in fedora, though I won't lead every project that is not in 'mainstream' fedora direction (like this Update Distro after EOL). It may be frustrating to read what I say since I criticize when people say 'we should only do that' and I don't step up that often to help those who wnat to do differently, but I simply don't have time. > It more than frustrates me, it hurts...deeply... because this kills > forward momentum. Why? I was pretty clear that I would help as much as I could by maintaining all the packages I have interest in (just like what I do in EPEL), it involves packages from others and even some from former core. But once again I have already too much packages I follow I cannot additionally lead such an initiative, especially when I won't use the result. > I'm much more inclined to bend over backwards to > grease the wheels, with my own blood even, for someone who is > committed to making the effort to lead an idea, than I am to even hold > a door open for someone who just wants to talk about it. Once again I was mistakenly thinking that people in the boards didn't want to let the door open, and to me this was the first thing to agree on before anybody can move on, and I was devoting my time to convince fedora people to accept the initiative such that people who don't want to argue but are ready to do the work can actually do it. It looks like I lost everybody time because things were allready agreed and now all that remains is to do the work. > This project has an infinite things that it 'could' do. But we In that case, I was mistaken, but I was under the impression that there was some fundamental opposition, and that it wasn't only an issue of manpower. I was wrong, sorry. > absolute need people who will lead those efforts. People passionate > about that area, who can build up communities of volunteers to keep > the work moving. Please, I'm begging you, direct your passion on > an area you can lead and if you do that I'll do what I can to help you > recruit users and contributors to increase the impact of your efforts. I understand that it would be better if I had time to really do all the work corresponding with the ideas I support, but I think that arguing to help fedora (hopefully) go in the right direction is already an interesting task, and if I volunteer I don't think that it is wrong. -- Pat From j.w.r.degoede at hhs.nl Fri Jan 25 23:17:24 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 26 Jan 2008 00:17:24 +0100 Subject: Headsup: new API and ABI changing goffice update headed towards rawhide Message-ID: <479A6E04.5040502@hhs.nl> Hi All, I've been working on updating gnumeric to the 1.8.x tree, this needs the latest stable 0.6 series of goffice, therefor I'm also updating goffice from 0.2 to 0.6, which means a change in soname, and in API. The only other user is abiword, a patch for abiword for the 0.5 devel series of goffice, which lead to the 0.6 release is available here: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/abiword-goffice05.patch?rev=1.1 It should be trivial to adjust this patch to make abiword 's charting plugin work with goffice-0.6 (search replace 0.5 with 0.6). --- Another problem is that we also have the special goffice04 package as some packages needed goffice-0.4, while others where still using 0.2 . For now we can keep this package until the 0.4 users move over to 0.6, but there is a conflict between goffice04 and the new goffice-devel . The problem are a bunch of files under /usr/share/gtk-doc/html/goffice. Notice that this are API reference doc, so in the goffice04 case the are wrongly in the main package and they should be moved to the -devel package. This would make the conflict less severe as it then is a conflict between devel files, but still a conflict. Suggestion, move those files to the -devel package of goffice04 and put them under /usr/share/gtk-doc/html/goffice04 to avoid the conflict. Thanks & Regards, hans From johnp at redhat.com Fri Jan 25 23:42:49 2008 From: johnp at redhat.com (John (J5) Palmieri) Date: Fri, 25 Jan 2008 18:42:49 -0500 Subject: F9 for Eeepc In-Reply-To: <479A650D.8060401@cora.nwra.com> References: <479A650D.8060401@cora.nwra.com> Message-ID: <1201304569.2057.22.camel@localhost.localdomain> On Fri, 2008-01-25 at 15:39 -0700, Orion Poplawski wrote: > > - Flash drive. Want to minimize writes. One attempt (eeedora) uses the > ext2 filesystem rather than ext3. Does that help? Are there things to > take from stateless projects for minimizing writes to /var? > jffs2 is what we use on the OLPC, there is another FS in the works that is a lot better for large flash though. I forget the name. On modern flash you don't have to worry about rewrites as much though since the hardware randomizes writes. What kills the disk on older flash drives is writing to the journal in Ext3 and writing to the FAT on Fat disks. Both of those are fixed locations which stress out a small portion of the disk. Each flash device has only so many writes per bit before that bit dies. By distributing it over the whole disk it takes a lot longer to destroy. I would check the specs on the flash drive that came with the Eee. Another thing you might want to do is not have a swap partition. Apps run fine without swap, you just might run into OOM more frequently. -- John (J5) Palmieri From ruben at rubenkerkhof.com Sat Jan 26 00:02:46 2008 From: ruben at rubenkerkhof.com (Ruben Kerkhof) Date: Sat, 26 Jan 2008 01:02:46 +0100 Subject: F9 for Eeepc In-Reply-To: <1201304569.2057.22.camel@localhost.localdomain> References: <479A650D.8060401@cora.nwra.com> <1201304569.2057.22.camel@localhost.localdomain> Message-ID: <09A39F2F-8846-4D80-B6BC-AACDD37566DD@rubenkerkhof.com> On 26 jan 2008, at 00:42, John (J5) Palmieri wrote: > jffs2 is what we use on the OLPC, there is another FS in the works > that > is a lot better for large flash though. I forget the name Do you mean http://logfs.org/ ? Ruben From d.jacobfeuerborn at conversis.de Sat Jan 26 00:03:24 2008 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Sat, 26 Jan 2008 01:03:24 +0100 Subject: Disable Pulseaudio Message-ID: <479A78CC.5030509@conversis.de> Hi, Since my ICE1712 based card stopped working with recent kernel/pulseaudio version I'm trying to move to a plain ALSA setup again until the issue gets attention (https://bugzilla.redhat.com/show_bug.cgi?id=428537). I removed the alsa-pulseaudio plugin but now when I try to play a file in mplayer or audacious I get the following output: alsa-lib: pcm.c:2106:(snd_pcm_open_conf) Cannot open shared library /usr/lib/alsa-lib/libasound_module_pcm_pulse.so It seems ALSA is still trying to get through pulseaudio but how do I turn that off? Regards, Dennis From ml at deadbabylon.de Sat Jan 26 00:04:09 2008 From: ml at deadbabylon.de (Sebastian Vahl) Date: Sat, 26 Jan 2008 01:04:09 +0100 Subject: F9 Alpha spinning In-Reply-To: <20080125162835.GA19048@crow> References: <20080125162835.GA19048@crow> Message-ID: <20080126010409.31376a26@deadbabylon.de> Am Fri, 25 Jan 2008 11:28:35 -0500 schrieb Luke Macken : > -rw-r--r-- 1 root root 647M 2008-01-24 15:20 > F9-Alpha-KDE-i686-20080124.0.iso 15:20 I've encovered some problems with missing fonts yesterday and uploaded the new kicktart to git yesterday (please have a look at my thread about live images and fonts [1] and also the "answer" from Nicolas Mailhot). My actual size should be ~695 megs. My current package list is this one: http://fedoraproject.org/wiki/SebastianVahl/CurrentPackageList It would be great I a re-spin would be possible. If not many non-latin users would encounter problems. I'm sorry for the trouble. Sebastian [1] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg02338.html [2] https://www.redhat.com/archives/fedora-devel-list/2008-January/msg02551.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jonathan.underwood at gmail.com Sat Jan 26 00:29:37 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sat, 26 Jan 2008 00:29:37 +0000 Subject: F9 for Eeepc In-Reply-To: <1201304569.2057.22.camel@localhost.localdomain> References: <479A650D.8060401@cora.nwra.com> <1201304569.2057.22.camel@localhost.localdomain> Message-ID: <645d17210801251629y2811f3f7jf0886a166ffd2f8@mail.gmail.com> On 25/01/2008, John (J5) Palmieri wrote: > > On Fri, 2008-01-25 at 15:39 -0700, Orion Poplawski wrote: > > > > > - Flash drive. Want to minimize writes. One attempt (eeedora) uses the > > ext2 filesystem rather than ext3. Does that help? Are there things to > > take from stateless projects for minimizing writes to /var? > > > > jffs2 is what we use on the OLPC, there is another FS in the works that > is a lot better for large flash though. I forget the name. On modern > flash you don't have to worry about rewrites as much though since the > hardware randomizes writes. What kills the disk on older flash drives > is writing to the journal in Ext3 and writing to the FAT on Fat disks. > Both of those are fixed locations which stress out a small portion of > the disk. Each flash device has only so many writes per bit before that > bit dies. By distributing it over the whole disk it takes a lot longer > to destroy. I would check the specs on the flash drive that came with > the Eee. Another thing you might want to do is not have a swap > partition. Apps run fine without swap, you just might run into OOM more > frequently. > The eeepc drive has a FTL, so these drives don't appear as flash drives to the OS, so jffs, yaffs, logfs and the like aren't applicable to the eeepc, as I understand it. > -- > John (J5) Palmieri > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From jonathan.underwood at gmail.com Sat Jan 26 00:32:40 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sat, 26 Jan 2008 00:32:40 +0000 Subject: F9 for Eeepc In-Reply-To: <479A650D.8060401@cora.nwra.com> References: <479A650D.8060401@cora.nwra.com> Message-ID: <645d17210801251632g77dce090k5abfe56cc853b8fa@mail.gmail.com> On 25/01/2008, Orion Poplawski wrote: > - Flash drive. Want to minimize writes. One attempt (eeedora) uses the > ext2 filesystem rather than ext3. Does that help? Are there things to > take from stateless projects for minimizing writes to /var? > > other stuff? I think that most of the other distros that people have put together for the eeepc tend to not use a swap partition either, to reduce disk wear. Not sure if eeedora adopts that strategy or not. From michel.sylvan at gmail.com Sat Jan 26 00:42:04 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Fri, 25 Jan 2008 19:42:04 -0500 Subject: Disable Pulseaudio In-Reply-To: <479A78CC.5030509@conversis.de> References: <479A78CC.5030509@conversis.de> Message-ID: On Jan 25, 2008 7:03 PM, Dennis Jacobfeuerborn wrote: > Hi, > Since my ICE1712 based card stopped working with recent kernel/pulseaudio > version I'm trying to move to a plain ALSA setup again until the issue gets > attention (https://bugzilla.redhat.com/show_bug.cgi?id=428537). > I removed the alsa-pulseaudio plugin but now when I try to play a file in > mplayer or audacious I get the following output: > > alsa-lib: pcm.c:2106:(snd_pcm_open_conf) Cannot open shared library > /usr/lib/alsa-lib/libasound_module_pcm_pulse.so > > It seems ALSA is still trying to get through pulseaudio but how do I turn > that off? > That is weird; the /etc/alsa/pulse-default.conf that tells ALSA to use pulseaudio is part of alsa-plugins-pulseaudio, which you have removed. Do you have anything in ~/.asoundrc ? Regards, -- Michel Salim http://hircus.jaiku.com/ From rc040203 at freenet.de Fri Jan 25 16:35:27 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 25 Jan 2008 17:35:27 +0100 Subject: long term support release In-Reply-To: <200801251127.47467.jwilson@redhat.com> References: <1201240697.17905.179.camel@beck.corsepiu.local> <479A0A55.60409@fedoraproject.org> <1201277129.14800.25.camel@cutter> <200801251127.47467.jwilson@redhat.com> Message-ID: <1201278927.17905.382.camel@beck.corsepiu.local> On Fri, 2008-01-25 at 11:27 -0500, Jarod Wilson wrote: > On Friday 25 January 2008 11:05:29 am seth vidal wrote: > > On Fri, 2008-01-25 at 21:42 +0530, Rahul Sundaram wrote: > > > Emmanuel Seyman wrote: > > > > * Patrice Dumas [25/01/2008 16:48] : > > > >> I thought you were speaking about RHEL. But Centos is exactly in the > > > >> same case that 'fedora LTS' or fedora itself. Volunteers, no warranty, > > > >> no contract. > > > > > > > > CentOS doesn't actually do the work of backporting security fixes only. > > > > They take the work done by Red Hat and just rebuild the .rpms. > > > > > > > > If Fedora LTS happens, it will not have this option. > > > > > > .. unless Fedora LTS is a rebuild of RHEL SRPMS. There might be some > > > advantages to this worth considering. > > > > do we need another centos but with a fedora brand? I think the centos > > guys are doing a good job, personally. > > I believe the trick is to just have the CentOS folks rename CentOS to Fedora > LTS and otherwise just keep on doing what they've been doing... :) The trick would be RH to freely release RHEL instead of forcing others to recompile packages, such these guys can contribute to EPEL instead of having to waste their time and resources on rebuilding. Ralf From jkeating at redhat.com Sat Jan 26 00:51:36 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 25 Jan 2008 19:51:36 -0500 Subject: long term support release In-Reply-To: <1201278927.17905.382.camel@beck.corsepiu.local> References: <1201240697.17905.179.camel@beck.corsepiu.local> <479A0A55.60409@fedoraproject.org> <1201277129.14800.25.camel@cutter> <200801251127.47467.jwilson@redhat.com> <1201278927.17905.382.camel@beck.corsepiu.local> Message-ID: <20080125195136.02a98f3d@redhat.com> On Fri, 25 Jan 2008 17:35:27 +0100 Ralf Corsepius wrote: > The trick would be RH to freely release RHEL instead of forcing others > to recompile packages, such these guys can contribute to EPEL instead > of having to waste their time and resources on rebuilding. No disagreement here. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From d.jacobfeuerborn at conversis.de Sat Jan 26 01:09:17 2008 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Sat, 26 Jan 2008 02:09:17 +0100 Subject: Disable Pulseaudio In-Reply-To: References: <479A78CC.5030509@conversis.de> Message-ID: <479A883D.5080401@conversis.de> Michel Salim wrote: > On Jan 25, 2008 7:03 PM, Dennis Jacobfeuerborn > wrote: >> Hi, >> Since my ICE1712 based card stopped working with recent kernel/pulseaudio >> version I'm trying to move to a plain ALSA setup again until the issue gets >> attention (https://bugzilla.redhat.com/show_bug.cgi?id=428537). >> I removed the alsa-pulseaudio plugin but now when I try to play a file in >> mplayer or audacious I get the following output: >> >> alsa-lib: pcm.c:2106:(snd_pcm_open_conf) Cannot open shared library >> /usr/lib/alsa-lib/libasound_module_pcm_pulse.so >> >> It seems ALSA is still trying to get through pulseaudio but how do I turn >> that off? >> > That is weird; the /etc/alsa/pulse-default.conf that tells ALSA to use > pulseaudio is part of alsa-plugins-pulseaudio, which you have removed. > > Do you have anything in ~/.asoundrc ? That was it. I think I created that file some time ago to get skype working but then forgot about it. Now alsa works as it should, thanks! Now I just have to find out why pulseaudio from F8 works and 0.9.8 from rawhide doesn't. Lennart Poettering has quickly written this off as an alsa bug but that doesn't explain why 0.9.7 works and even if that is true it doesn't help me to file a decent bug report at the alsa site. Regards, Dennis From rc040203 at freenet.de Fri Jan 25 08:21:01 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 25 Jan 2008 09:21:01 +0100 Subject: long term support release In-Reply-To: References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <20080123103336.6e24109f@redhat.com> <47976399.3010709@redhat.com> <47979470.6010507@leemhuis.info> <1201150608.17905.78.camel@beck.corsepiu.local> <20080124081720.GA2636@free.fr> <1201166022.17905.109.camel@beck.corsepiu.local> <1201198306.17905.117.camel@beck.corsepiu.local> Message-ID: <1201249261.17905.239.camel@beck.corsepiu.local> On Fri, 2008-01-25 at 00:41 +0100, Matej Cepl wrote: > On 2008-01-24, 18:11 GMT, Ralf Corsepius wrote: > > How can I? If I'd buy RHEL, I wouldn't want to use CentOS, if > > I were using CentOS I wouldn't want to use RHEL. > > It might be your case, Yes. I have a university/research/engineering (EE/CS/IT) background, where flexibility/openness of the source-code and costs of the OS are the key points for choosing Linux (If choosing it at all!). > but there are many RH customers who have > RHEL for some mission-critical applications (or for the software, > where they need supported platform -- ehm, ehm, Oracle), Mission-critical is relative to the "mission" a system is deployed for. I wouldn't choose Linux to control a spacecraft or a nuclear power plant, but I didn't hesitate to chose Linux to control robots in a lab, nor do I hesitate to chose Fedora to host "my personal mission's" mission-critical data" ;) Of cause you are aiming at "big-businesses" combining deploying an OS with larger engineering tasks over longer time-frames (bookkeeping, billing, shop-systems etc.). True, that's not my domain ;) > but rest > of their server needs are covered by CentOS. Well, are you saying "CentOS + some engineering" aren't suitable for "mission-critical" purposes? How would that be different from using RHEL? OK, somebody else mentioned ISO9000 and other certifications, ... probably relevant in some cases, but probably irrelevant in many others. Ralf From jwboyer at gmail.com Sat Jan 26 02:56:19 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 25 Jan 2008 20:56:19 -0600 Subject: F9 for Eeepc In-Reply-To: <1201304569.2057.22.camel@localhost.localdomain> References: <479A650D.8060401@cora.nwra.com> <1201304569.2057.22.camel@localhost.localdomain> Message-ID: <20080125205619.404a53f5@zod.rchland.ibm.com> On Fri, 25 Jan 2008 18:42:49 -0500 "John (J5) Palmieri" wrote: > > On Fri, 2008-01-25 at 15:39 -0700, Orion Poplawski wrote: > > > > > - Flash drive. Want to minimize writes. One attempt (eeedora) uses the > > ext2 filesystem rather than ext3. Does that help? Are there things to > > take from stateless projects for minimizing writes to /var? > > > > jffs2 is what we use on the OLPC, there is another FS in the works that > is a lot better for large flash though. I forget the name. On modern Logfs. There's also UBIFS in the works. > flash you don't have to worry about rewrites as much though since the > hardware randomizes writes. What kills the disk on older flash drives Erm.. that's a function of a controller of some kind. Not the flash chip itself. josh From jwboyer at gmail.com Sat Jan 26 03:01:39 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 25 Jan 2008 21:01:39 -0600 Subject: long term support release In-Reply-To: <20080125195136.02a98f3d@redhat.com> References: <1201240697.17905.179.camel@beck.corsepiu.local> <479A0A55.60409@fedoraproject.org> <1201277129.14800.25.camel@cutter> <200801251127.47467.jwilson@redhat.com> <1201278927.17905.382.camel@beck.corsepiu.local> <20080125195136.02a98f3d@redhat.com> Message-ID: <20080125210139.7b750863@zod.rchland.ibm.com> On Fri, 25 Jan 2008 19:51:36 -0500 Jesse Keating wrote: > On Fri, 25 Jan 2008 17:35:27 +0100 > Ralf Corsepius wrote: > > > The trick would be RH to freely release RHEL instead of forcing others > > to recompile packages, such these guys can contribute to EPEL instead > > of having to waste their time and resources on rebuilding. > > No disagreement here. Give that as an item for the Board to take forward. josh From dcbw at redhat.com Sat Jan 26 03:23:21 2008 From: dcbw at redhat.com (Dan Williams) Date: Fri, 25 Jan 2008 22:23:21 -0500 Subject: F9 for Eeepc In-Reply-To: <479A650D.8060401@cora.nwra.com> References: <479A650D.8060401@cora.nwra.com> Message-ID: <1201317801.2756.10.camel@localhost.localdomain> On Fri, 2008-01-25 at 15:39 -0700, Orion Poplawski wrote: > I got myself an Eeepc to play around with and I'd love to get Fedora > running on it. Issues that I'm aware of: > > - Ethernet driver. Controller is an Attansic Tech L2 100Mbit Ethernet > Adapter (rev a0) (0200: 1969:2048). This uses the atl2 driver. Anyone > have any ideas on the chances of this going upstream? Interestingly I > see this in some of the 2.0.3 files: > > * Copyright(c) 2007 Chris Snook Chris posted patches upstream on netdev a few weeks ago. It's happening, though I forget if the driver had to go through another revision or what. Hopefully will hit 2.6.25, though it's not in garzik's netdev-2.6.25 yet so it might not. > - Wireless driver. Controller is an Atheros AR5007EG 802.11 b/g > Wireless PCI Express Adapter. (168c:001c rev 01). Distributed > versions appears to use the madwifi drivers. Sounds like ath5k is the > way forward though. ath5k is definitely the way forward. madwifi will _never_ get upstream (binary HAL, uses a different 802.11 stack). Unfortunately, ath5k doesn't yet support PCI-E, which is being worked on. So people will have to keep installing madwifi for the time being. Dan > - Flash drive. Want to minimize writes. One attempt (eeedora) uses the > ext2 filesystem rather than ext3. Does that help? Are there things to > take from stateless projects for minimizing writes to /var? > > other stuff? > > -- > Orion Poplawski > Technical Manager 303-415-9701 x222 > NWRA/CoRA Division FAX: 303-415-9702 > 3380 Mitchell Lane orion at cora.nwra.com > Boulder, CO 80301 http://www.cora.nwra.com > From rc040203 at freenet.de Fri Jan 25 13:52:38 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 25 Jan 2008 14:52:38 +0100 Subject: long term support release In-Reply-To: <200801251256.m0PCu4hR009704@laptop13.inf.utfsm.cl> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <200801251256.m0PCu4hR009704@laptop13.inf.utfsm.cl> Message-ID: <1201269158.17905.329.camel@beck.corsepiu.local> On Fri, 2008-01-25 at 09:56 -0300, Horst H. von Brand wrote: > Ralf Corsepius wrote: > > On Wed, 2008-01-23 at 14:55 -0500, seth vidal wrote: > > > On Wed, 2008-01-23 at 19:35 +0100, Ralf Corsepius wrote: > > > > Further: IMO, fedora legacy did not fail. It was discontinued by > > > > management, because it collided the certain business interests. > > > Anyway, meanwhile, things in Fedora-land have changed. > > > > What prevents Fedora from launching a "Fedora LTS" as part of Fedora, > > using the Fedora infrastructure, e.g. by simply imply declaring "Fedora > > 7" life time's extended for, say 2 years, when FC9 comes out? > > > > The price would be fairly small. > > s/fairly small/extremely large/ How? I am talking about entirely handing over a (discontinued) Fedora version to the community. Apart from individuals with an @RH address which of cause could continue to participate, RH's role would be to provide the infrastructure. > In particular, the infrastructure > > already is in place. All what would have to be implemented would be some > > regulations/conventions concerning "ABI/APIs" and ACLs. > > And having /three/ branches of Fedora instead of /two/ 6 instead of 5 (EL-4, EL-5, FC-7, FC-8, rawhide + soon EL-6), on an entirely volunteered basis. > No, "then just get the newest package then and integrate it with the rest" > doesn't cut it. If I want LTS it is exactly because I don't want ABI/API or > configuration changes /at all/. Then RHEL would be the appropriate choice for you. For a Fedora LTS I would like to see a "consistent ABI/API", but not stagnating/constant ones. > > However, I recall FESCO (or had it been FAB?) having decided on FC's > > short life-time > > Very good idea, helps keeping the distribution focused on bleeding edge and > minimizes spreadout of the (very limited!) developers. Well, IMO, it has helped degrading a once usable distro into what suspiciously resembles "rawhide snapshots". Ralf From loupgaroublond at gmail.com Sat Jan 26 04:35:45 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Fri, 25 Jan 2008 23:35:45 -0500 Subject: Smolt RFC: File System Information Message-ID: <7f692fec0801252035j66468790g47ddffb0d4479013@mail.gmail.com> Hey list, I'm looking to get some input on a feature that was requested of Smolt. One file system engineer wants to collect some basic data about file systems in use, for fine tuning the default settings in Fedora and RHEL. This is something that we can all benefit by, and the greater participation we give, the better the results are going to be for everyone. To hilight the information to be collected, actions speak louder than words: yankee at dao:~$ sudo stat -f /dev/main/fedora8 File: "/dev/main/fedora8" ID: 0 Namelen: 255 Type: tmpfs Block size: 4096 Fundamental block size: 4096 Blocks: Total: 258215 Free: 258199 Available: 258199 Inodes: Total: 223935 Free: 222932 (Actually I think something might be broken, that data doesn't look correct for me) In short, it will collect a list of file systems + types, and their usage stats. For the time being the stats won't be published on the web site. We're having some reporting issues, and I don't want to add another long running SQL query into the mix. However, anyone will be free to ask one of us to report on that information. Furthermore, this information will be enabled by default, for the time being, until we have thing set up to allow fine grained information hiding. Remember, all profiles will be anonymous as usual. Are there any underlying security or privacy issues here that would be a clear reason not to do this? Any other comments, or refinements? If not, i'll look at getting this done right away, so that it will be in the latest released pushed to Fedora 9 Beta. This means it will be tested and backported to other versions of Fedora, as we're going to have to break older clients for other reasons. In other words, speak up now before it finds its way into your systems along with all the other cool things that Smolt does. Cheers, Yaakov From loupgaroublond at gmail.com Sat Jan 26 04:38:55 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Fri, 25 Jan 2008 23:38:55 -0500 Subject: Smolt RFC: File System Information In-Reply-To: <7f692fec0801252035j66468790g47ddffb0d4479013@mail.gmail.com> References: <7f692fec0801252035j66468790g47ddffb0d4479013@mail.gmail.com> Message-ID: <7f692fec0801252038oa3a9eeeudca8d99396908d08@mail.gmail.com> On Jan 25, 2008 11:35 PM, Yaakov Nemoy wrote: > Hey list, > > yankee at dao:~$ sudo stat -f /dev/main/fedora8 > File: "/dev/main/fedora8" > ID: 0 Namelen: 255 Type: tmpfs > Block size: 4096 Fundamental block size: 4096 > Blocks: Total: 258215 Free: 258199 Available: 258199 > Inodes: Total: 223935 Free: 222932 > > (Actually I think something might be broken, that data doesn't look > correct for me) Never mind the bug, I just don't understand statvfs fully yet :) From loupgaroublond at gmail.com Sat Jan 26 04:42:53 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Fri, 25 Jan 2008 23:42:53 -0500 Subject: Haskell Packaging Guidelines Review Message-ID: <7f692fec0801252042g6809db2cp487b486d0892f20d@mail.gmail.com> Hi List, I've been working on writing up guidelines for packaging Haskell packages. I need some input from people who know their way around Fedora very well. Some of the issues involved nuances of Haskell, but many of them are questions because I don't know enough about Fedora myself. If any one has the time to give these a looking over, and comment on some of the points where I've left question marks, it would be very helpful so that hopefully I might have a few interesting things in for Fedora 9 Beta. You can find the draft in question here: http://fedoraproject.org/wiki/PackagingDrafts/Haskell Thanks for any advice. Cheers, Yaakov From rc040203 at freenet.de Sat Jan 26 06:44:29 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 26 Jan 2008 07:44:29 +0100 Subject: long term support release In-Reply-To: <80d7e4090801251033s1fce270akfcf6a73e882b0236@mail.gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> <1201251592.17905.255.camel@beck.corsepiu.local> <80d7e4090801251033s1fce270akfcf6a73e882b0236@mail.gmail.com> Message-ID: <1201329869.17905.554.camel@beck.corsepiu.local> On Fri, 2008-01-25 at 11:33 -0700, Stephen John Smoogen wrote: > On Jan 25, 2008 1:59 AM, Ralf Corsepius wrote: > > > > On Thu, 2008-01-24 at 23:47 -0900, Jeff Spaleta wrote: > > > On Jan 24, 2008 11:38 PM, Ralf Corsepius wrote: > > > > Also, wouldn't you consider the fact Ubuntu launches "Ubuntu LTS" to be > > > > evidence enough that others see a market nice? > > > > > > I'm pretty sure that Ubuntu LTS is something that Canonical as a > > > business entity as chosen to launch and leverages as part of its > > > business model and is not in point of fact relying primarily on > > > community manpower to make the LTS offering actually work. Find me a > > > business entity who would like to do something similar in Fedora space > > > and I'll gladly talk to them about making room in the project. > > There is one difference between Fedora and Ubuntu: > > > > * Fedora is backed up by an actively contributing community. > > * RH/fedoraproject.org has the technical resources. > > > > There is only one thing missing: a culture of openness and a lack of > > confidence into the powers of open development. > > > > Ralf, no one but yourself is stopping you from being the catalyst for > getting people to do this. See a problem, be the agent to make it > better. When Fedora Legacy was falling apart you could have taken it > over.. Sigh, I am repeating myself over and over again: Back then, I did offer to contribute to Fedora Legacy under the "Fedora hood" when if it had used the Fedora infrastructure. Unfortunately, FESCO/FAB/FPB and RH shot any such proposal down and insisted on keeping Legacy a separate project, using its own infrastructure etc. Someday, out of blue sky, Legacy had been closed down. > but it would seem you just wanted to save up your problems for > later emails. If you want to make an LTS, then start it up. If there > is a market for it, you can find the people and money to do so. Exactly this is not what I intend. I want to see Fedora's usability improved, because as a user I feel Fedora's usability has regressed into "rawhide snapshot". I tried to propose "extending Fedora's life time under community control" as a compromise which I consider to be easily bought-in. Unfortunately, I am facing fierce opposition and feel machine-gunned, by a Fedora leadership of which I feel hasn't comprehended the powers of community support in open source. I feel you guys, are thinking in terms of enterprise product cycles, corporite commitments/ownership/control, and fencing out "non-corporite members" and close your eyes in front of the additional opportunities treating OSS development as an continuous evolving process offers. Openly said, in front of this background, I feel this Fedora leadership, esp. the @RHs within it (probably due to their corporite background), are standing in their own way. Consider all proposals I made withdrawn - You shot them down. Ralf From rc040203 at freenet.de Sat Jan 26 06:49:59 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 26 Jan 2008 07:49:59 +0100 Subject: long term support release In-Reply-To: <479A268B.5070201@gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> <4799EAA0.7030700@gmail.com> <20080125102616.7605825b@redhat.com> <479A0C6B.1050004@gmail.com> <20080125112254.382c9e13@redhat.com> <479A190F.8010402@gmail.com> <200801251727.m0PHRe0O016727@laptop13.inf.utfsm.cl> <479A268B.5070201@gmail.com> Message-ID: <1201330199.17905.561.camel@beck.corsepiu.local> On Fri, 2008-01-25 at 12:12 -0600, Les Mikesell wrote: > Horst H. von Brand wrote: > >> If the latter effort fails, > >> you've still got a solid, working version. > > > > If you want "solid, working", why are you messing around with > > "bleeding-edge apps"?! > > Why are people writing 'bleeding-edge' apps if there is no reason to use > them? I guess no reasonable _user_ wants 'bleeding-edge'. I want/need a comprehensive, up2date distribution containing current/up2date (considered stable) versions of those packages I actually use. As a developer, it's not a major problem for _me_ having to cope with a couple of issues here and there, but how do you expect "Aunt Tillie" to cope with them? Also, with F8 I have been confronted with so many tiny issues, which all together render productive use of Fedora close to impossible and have caused me to have doubts on the project's sanity. Interestingly, it's not the "community-maintained packages" some seem to preferr to accuse to be of low quality, which are causing the trouble, it's the sum of issues with the "standard/default packages" which are piling up. > A desktop app that crashes once in a while is not a huge problem > - and wouldn't be a problem at all if there were an option to drop back > to a more stable version. > A machine that won't boot or a device driver > that no longer talks to my hardware is. Yep, that's one subset amongst several sets of issues I am facing ;) Fortunately, these happen to be the easy cases. The really nagging ones are those, one can't identify the cause of. Ralf From jos at xos.nl Sat Jan 26 08:13:43 2008 From: jos at xos.nl (Jos Vos) Date: Sat, 26 Jan 2008 09:13:43 +0100 Subject: long term support release In-Reply-To: <20080125195136.02a98f3d@redhat.com> References: <1201240697.17905.179.camel@beck.corsepiu.local> <479A0A55.60409@fedoraproject.org> <1201277129.14800.25.camel@cutter> <200801251127.47467.jwilson@redhat.com> <1201278927.17905.382.camel@beck.corsepiu.local> <20080125195136.02a98f3d@redhat.com> Message-ID: <20080126081343.GA9229@jasmine.xos.nl> On Fri, Jan 25, 2008 at 07:51:36PM -0500, Jesse Keating wrote: > Ralf Corsepius wrote: > > > The trick would be RH to freely release RHEL instead of forcing others > > to recompile packages, such these guys can contribute to EPEL instead > > of having to waste their time and resources on rebuilding. > > No disagreement here. They don't even need to release "RHEL", but only the packages except for the trademark packages (images etc.), so that Fedora can simply create a distro out of it. Havig said that, in the past I have heard RH people saying that they don't understand why people are rebuilding the binaries (except trademark packages etc. of course), as they (the single packages, not RHEL as a "composition") may be distributed freely. Either this is not true, or nobody has ever done the work to find this out in detail. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From rc040203 at freenet.de Sat Jan 26 08:19:42 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 26 Jan 2008 09:19:42 +0100 Subject: long term support release In-Reply-To: <20080125180603.GB7087@orient.maison.lan> References: <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <20080125103144.68eec1ff@redhat.com> <20080125153747.GB2975@free.fr> <200801251638.m0PGcbnL014079@laptop13.inf.utfsm.cl> <20080125164413.GB3480@free.fr> <20080125115319.28d78ae6@redhat.com> <20080125170756.GA3785@free.fr> <20080125173552.GA6832@orient.maison.lan> <20080125125221.6b0705f7@redhat.com> <20080125180603.GB7087@orient.maison.lan> Message-ID: <1201335582.17905.571.camel@beck.corsepiu.local> On Fri, 2008-01-25 at 19:06 +0100, Emmanuel Seyman wrote: > * Jesse Keating [25/01/2008 18:53] : > > > > The ability to contribute without having to get another account, learn > > another scm, read other bugmail, etc... > > These are conveniences, not hard requirements. Have you ever tried to implement a buildsystem? In practice, besides finding HW and bandwidth, the items above are the real issues any project is being confronted with. For contributors, using a unified infrastructure to some extend is convenience. A lack of convenience imposing barriers and burdens on users, which cause them to stay away from them. Also, both topic had been major advertising arguments when launching Fedora. Fedora.us and other 3rd party repos could easily have lived without a unified infrastructure. Ralf From rc040203 at freenet.de Sat Jan 26 08:22:03 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 26 Jan 2008 09:22:03 +0100 Subject: long term support release In-Reply-To: <20080125163706.GA3480@free.fr> References: <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> <20080125152614.GA2975@free.fr> <20080125103335.0d5adacf@redhat.com> <20080125154127.GC2975@free.fr> <200801251623.m0PGNbuJ012679@laptop13.inf.utfsm.cl> <20080125163706.GA3480@free.fr> Message-ID: <1201335723.17905.574.camel@beck.corsepiu.local> On Fri, 2008-01-25 at 17:37 +0100, Patrice Dumas wrote: > On Fri, Jan 25, 2008 at 01:23:37PM -0300, Horst H. von Brand wrote: > > > > Now, cross your heart: Would /you/ run a LTS where there was /no/ QA or > > security team? At most for a month or so, until it is convenient to > > upgrade would be my answer. Feeling uneasy all the time. > > Yes, I would, if I know that I can trust the packagers. So would I. I have no reason trust the community less than anybody else. Otherwise I also weren't using Fedora at all right now ;) > I don't care > about QA and security team (though it is a nice bonus). Well, Fedora 8 speaks a language of its own wrt. QA. I definitely appreciate their efforts, but ... Patrice put it quite nicely, it's a "nice bonus". No matter what they do, they can't compete with the QA provided through user feedback and necessarily must fail in circumstances they don't test. This kind of QA doesn't nicely fit into OSS development, it's "closed source school". > I trust fedora > contributors to do things right, though, when they are (even selfishely) > interested in something. And it could happen that some fedora contributors > are interested in doing Updates after the EOL. Although I wouldn't > certainly use such a release, if there was some infrastructure, I would > certainly try to fix critical issues in most of my own packages in such > a setting (especially since I already do it in EPEL). I already do that > for the stable releases I don't use, so... Very similar to what I would do. I probably would use "Fedora LTS" for a "grace period" on systems which still have "Fedora " installed when it's being discontinued, and when not being able to upgrade to "Fedora N" for whatever reasons. Ralf From Axel.Thimm at ATrpms.net Sat Jan 26 09:17:55 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 26 Jan 2008 11:17:55 +0200 Subject: blacklisted iwl4965 ?? In-Reply-To: <1200887683.10357.46.camel@raven.themaw.net> References: <20080118080211.GM29887@angus.ind.WPI.EDU> <20080119084021.GA4680@puariko.nirvana> <1200887683.10357.46.camel@raven.themaw.net> Message-ID: <20080126091755.GG7607@puariko.nirvana> On Mon, Jan 21, 2008 at 12:54:43PM +0900, Ian Kent wrote: > > On Sat, 2008-01-19 at 10:40 +0200, Axel Thimm wrote: > > On Fri, Jan 18, 2008 at 03:02:11AM -0500, Chuck Anderson wrote: > > > I just did a fresh rawhide install and found this in > > > /etc/modprobe.d/blacklist: > > > > > > # don't load iwl4965 by default, bug 245379 > > > blacklist iwl4965 > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=245379 > > > > > > Does someone have any better explanation for this than the 6+ month > > > old bug report for RHEL 5? What are us iwl4965 users supposed to be > > > using? > > > > You can use the mac/iwl kmdls at ATrpms. I haven't started building > > for rawhide yet, but you can rebuild them yourself for any given > > kernel. > > Last time (quite a while ago) I tried to build ATrpms packages I found I > was missing something and the packages wouldn't build. > > What actually is needed to be able to build the srpms from ATrpms? For kmdl you need kernel-devel (or some kernel headers/sources you want to build the kmdls for) and atrpms-rpm-config. Then just rpmbuild --rebuild foo-1.2.3-4.src.rpm -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Sat Jan 26 09:24:43 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sat, 26 Jan 2008 11:24:43 +0200 Subject: Disable Pulseaudio In-Reply-To: <479A883D.5080401@conversis.de> References: <479A78CC.5030509@conversis.de> <479A883D.5080401@conversis.de> Message-ID: <200801261124.44021.ville.skytta@iki.fi> On Saturday 26 January 2008, Dennis Jacobfeuerborn wrote: > Michel Salim wrote: > > > Do you have anything in ~/.asoundrc ? > > That was it. I think I created that file some time ago to get skype working > but then forgot about it. Now alsa works as it should, thanks! Hmm, I lost interest in trying to get Skype working with PA in F8 shortly after F8 release and found that getting rid of PA as much as possible was a quick "fix" for it; if you have good recipes for ~/.asoundrc that result in a working Skype+PA setup, those would be appreciated. I'm pretty sure I've already tried stuff at http://www.pulseaudio.org/wiki/PerfectSetup#Skype to no avail. From braden at endoframe.com Sat Jan 26 09:28:51 2008 From: braden at endoframe.com (Braden McDaniel) Date: Sat, 26 Jan 2008 04:28:51 -0500 Subject: Firefox 3 Beta 2 in Rawhide In-Reply-To: <476A2656.5060704@redhat.com> References: <476A2656.5060704@redhat.com> Message-ID: <1201339731.3311.8.camel@hinge.endoframe.net> On Thu, 2007-12-20 at 09:22 +0100, Martin Stransky wrote: [snip] > Gecko libraries are registered system wide by > /etc/ld.so.conf.d and rpath should not be necessary in rawhide. Does this also mean that rpm can be smart and "Requires: gecko-libs" is no longer necessary? -- Braden McDaniel e-mail: Jabber: From j.w.r.degoede at hhs.nl Sat Jan 26 10:30:23 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 26 Jan 2008 11:30:23 +0100 Subject: koji not running new repo anymore? Message-ID: <479B0BBF.5020706@hhs.nl> Hi, Yesterday evening (about 10 hours ago) I build goffice through a chainbuild and the chainbuild failed in wait repo because it hat waited for more then 2 hours. I tried building gnumeric again, but it failed as the new goffice still isn't included into the buildrepo. So it looks like for some reason koji has stopped running newrepo build-f9 at regular interviews. Regards, Hans From opensource at till.name Sat Jan 26 10:40:07 2008 From: opensource at till.name (Till Maas) Date: Sat, 26 Jan 2008 11:40:07 +0100 Subject: long term support release In-Reply-To: <479A0C6B.1050004@gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <20080125102616.7605825b@redhat.com> <479A0C6B.1050004@gmail.com> Message-ID: <200801261140.12327.opensource@till.name> On Fri January 25 2008, Les Mikesell wrote: > That's *if* you uninstall fedora and re-install RHEL or CentOS, and then > locate and install all of the matching packages you had, which may or > may not be possible and it's certainly not easy. Shouldn't you reward I "updated" two or three Fedora Core 5 systems without a problem to CentOS 5. One only needs to install two rpms (centos-release and centos-logos or similiar) to Fedora and then anaconda recognizes the installation. There were only some packages that were newer in Fedora than in CentOS. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From szaka at ntfs-3g.org Sat Jan 26 11:38:52 2008 From: szaka at ntfs-3g.org (Szabolcs Szakacsits) Date: Sat, 26 Jan 2008 11:38:52 +0000 (UTC) Subject: F9 Alpha spinning References: <20080125162835.GA19048@crow> Message-ID: Luke Macken redhat.com> writes: > ntfs-3g grew 107185 bytes (36.31%) (295187->402372) > removed package fuse: 216231 Sometimes things are a bit more subtle as they look like ;) The ntfs-3g size increase enabled the fuse package removal, so the real change is 109046 bytes less used (511418 -> 402372). Szaka -- NTFS-3G: http://ntfs-3g.org From joachim.frieben at googlemail.com Sat Jan 26 11:46:03 2008 From: joachim.frieben at googlemail.com (Joachim Frieben) Date: Sat, 26 Jan 2008 12:46:03 +0100 Subject: long term support release In-Reply-To: <1201277589.17905.369.camel@beck.corsepiu.local> References: <1201249426.14800.19.camel@cutter> <20080125093517.GA16080@free.fr> <20080125103144.68eec1ff@redhat.com> <20080125153747.GB2975@free.fr> <20080125104307.382ce039@redhat.com> <20080125155059.GE2975@free.fr> <20080125155124.GA5809@orient.maison.lan> <479A0A55.60409@fedoraproject.org> <20080125160247.GA5952@orient.maison.lan> <1201277589.17905.369.camel@beck.corsepiu.local> Message-ID: <1c252d490801260346r753734d9mb6038e1d3fa34449@mail.gmail.com> On Jan 25, 2008 5:13 PM, Ralf Corsepius wrote: > > Do you want current packages or do you want the 3 year versions in RHEL? > > Ralf Why would you have to use 3 year old package versions when the RHEL release cycle is 18 months? Honestly speaking, for people interested in actually using an OS to get some real -work- done instead of seeking a life on the bleeding edge for their own thrill, RHEL5 and respins of it are very well usable. The Fedora user community is much more biased towards software enthousiasts and early adopters, and in general, they wouldn't even stick to Fedora release N after release N+1 has been readied 6 months later. Accordingly, I would expect the interest of LTS for this group to be rather limited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lordmorgul at gmail.com Sat Jan 26 12:38:10 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sat, 26 Jan 2008 04:38:10 -0800 Subject: long term support release In-Reply-To: <200801251709.m0PH9iV5015900@laptop13.inf.utfsm.cl> References: <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> <20080125152614.GA2975@free.fr> <20080125103335.0d5adacf@redhat.com> <20080125154127.GC2975@free.fr> <1201275741.1163.1.camel@localhost.localdomain> <20080125154749.GD2975@free.fr> <20080125105041.6605e470@redhat.com> <479A10D0.7020301@gmail.com> <200801251709.m0PH9iV5015900@laptop13.inf.utfsm.cl> Message-ID: <479B29B2.1070407@gmail.com> Horst H. von Brand wrote: > Les Mikesell wrote: >> Jesse Keating wrote: > > [...] > >>> What earthly reason would you have to run some old code set, with not >>> even close to guaranteed updates, let alone timely ones, with little >>> man power behind it, and the opportunity to be ignored by most package >>> owners? > >> Here's the reason: you have a new computer with hardware supported in >> fedora but not the current RHEL/Centos release - > > Lack of care when buying a machine can't be cured by the distribution. > >> or you need some >> software feature provided in the newer fedora apps so you install >> fedora. > > I was perfectly happy with RH 6.2, and most of what I do now I could do > there, so this can't really be an issue. > >> A year passes and you've installed an assortment of >> additional apps and perhaps written some of your own. > > Upgrade to next Fedora. Gets easier each time around. A bit of foresight > when installing originally helps much here. Precisely. The update or upgrades are essentially very simple to handle when you've got a sane partitioning scheme setup. Anyone running Fedora (and especially anyone testing updates or rawhide) that does not have their home on a separate partition is nuts (or new to that concept). If you have /etc/ /root and /home where they can be safely backed up and restored, then nuking your entire system for a fresh install is a couple hours of work at best. I just fail to see how anyone interested in running Fedora at all cannot find a few hours every 6 months to handle that. -- Andrew Farris www.lordmorgul.net gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From lordmorgul at gmail.com Sat Jan 26 12:42:34 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sat, 26 Jan 2008 04:42:34 -0800 Subject: long term support release In-Reply-To: <20080125163706.GA3480@free.fr> References: <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> <20080125152614.GA2975@free.fr> <20080125103335.0d5adacf@redhat.com> <20080125154127.GC2975@free.fr> <200801251623.m0PGNbuJ012679@laptop13.inf.utfsm.cl> <20080125163706.GA3480@free.fr> Message-ID: <479B2ABA.7000404@gmail.com> Patrice Dumas wrote: > On Fri, Jan 25, 2008 at 01:23:37PM -0300, Horst H. von Brand wrote: >> Now, cross your heart: Would /you/ run a LTS where there was /no/ QA or >> security team? At most for a month or so, until it is convenient to >> upgrade would be my answer. Feeling uneasy all the time. > > Yes, I would, if I know that I can trust the packagers. I don't care > about QA and security team (though it is a nice bonus). You cannot trust packagers without any QA being done. Period. Simple mistakes happen to everyone, more frequently than we'd all like to admit. In a LTS type scenario the people are expecting the updates that do come out to not completely hose the system... 'trusting' the packagers would be a guaranteed way to have people asking for their money back or ditching the distro entirely the first time a major incident happened. All it takes is a broken mkinitrd, and a kernel improperly installed rather than upgraded. /byedatathecasualuserwillneverseeagain -- Andrew Farris www.lordmorgul.net gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From jkeating at redhat.com Sat Jan 26 13:14:57 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 26 Jan 2008 08:14:57 -0500 Subject: koji not running new repo anymore? In-Reply-To: <479B0BBF.5020706@hhs.nl> References: <479B0BBF.5020706@hhs.nl> Message-ID: <20080126081457.3eb22087@redhat.com> On Sat, 26 Jan 2008 11:30:23 +0100 Hans de Goede wrote: > Yesterday evening (about 10 hours ago) I build goffice through a > chainbuild and the chainbuild failed in wait repo because it hat > waited for more then 2 hours. > > I tried building gnumeric again, but it failed as the new goffice > still isn't included into the buildrepo. > > So it looks like for some reason koji has stopped running newrepo > build-f9 at regular interviews. Hrm, kojira (the daemon that notices builds and requests new repos) is running and I see newRepo tasks being completed. http://koji.fedoraproject.org/koji/taskinfo?taskID=374372 at 06:01 koji time http://koji.fedoraproject.org/koji/taskinfo?taskID=374317 at 05:38 koji time http://koji.fedoraproject.org/koji/taskinfo?taskID=374271 at 05:18 koji time and so on and so forth. Ah, however I see that there was a period of time between 15:20~ and 03:00~ that kojira wasn't firing off new repos. Strange, but it seems to be working again. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin.kofler at chello.at Sat Jan 26 13:35:11 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 26 Jan 2008 13:35:11 +0000 (UTC) Subject: F9 Alpha spinning References: <20080125162835.GA19048@crow> Message-ID: Szabolcs Szakacsits ntfs-3g.org> writes: > Sometimes things are a bit more subtle as they look like ;) > > The ntfs-3g size increase enabled the fuse package removal, so > the real change is 109046 bytes less used (511418 -> 402372). Aren't we supposed to be moving _away_ from static copies of system libraries in packages? Kevin Kofler From buildsys at redhat.com Sat Jan 26 13:58:15 2008 From: buildsys at redhat.com (Build System) Date: Sat, 26 Jan 2008 08:58:15 -0500 Subject: rawhide report: 20080126 changes Message-ID: <200801261358.m0QDwFM0010776@porkchop.devel.redhat.com> New package gnomecatalog Catalog Software for Gnome Desktop New package libvpd VPD Database access library for lsvpd New package mtpaint Painting program for creating icons and pixel-based artwork New package perl-ParseLex Generator of lexical analyzers New package perl-XML-TreeBuilder Parser that builds a tree of XML::Element objects New package postgresql-ip4r IPv4 and IPv4 range index types for PostgreSQL New package sagator SAGATOR - antivir/antispam gateway for smtp server Updated Packages: ConsoleKit-0.2.6-3.fc9 ---------------------- * Thu Jan 24 2008 Kevin Kofler - 0.2.6-3 - Fix Requires * Thu Jan 24 2008 Jon McCann - 0.2.6-2 - Require libz for log decompression * Thu Jan 24 2008 Jon McCann - 0.2.6-1 - Update to 0.2.6 Io-language-20071010-3.fc9 -------------------------- * Thu Jan 24 2008 Hans de Goede 20071010-3 - Rebuild for new libevent PolicyKit-0.7-5.fc9 ------------------- * Thu Jan 24 2008 Jon McCann - 0.7-5.fc9 - Remove Requires: ConsoleKit since ConsoleKit now requires PolicyKit * Thu Dec 06 2007 David Zeuthen - 0.7-4.fc9 - Only run bash completion script if using bash (#418471) * Thu Dec 06 2007 David Zeuthen - 0.7-3.fc9 - Conflict with older hal release SDL_image-1.2.6-4.fc9 --------------------- * Thu Jan 24 2008 Brian Pepple - 1.2.6-4 - Add patch to fix buffer-overflow. (#430238) TurboGears-1.0.4.2-3.fc9 ------------------------ * Sat Jan 26 2008 Luke Macken 1.0.4.2-3 - Require Genshi and Elixir anaconda-11.4.0.27-1 -------------------- * Fri Jan 25 2008 Chris Lumens - 11.4.0.27-1 - Fix generation of stage1 images. (notting) - Fix a typo in mk-images. (clumens) - Allow removing packages by glob now that yum supports it. (clumens) * Thu Jan 24 2008 Chris Lumens - 11.4.0.26-1 - Fix a traceback on the driver selection screen (#428810). (clumens) - Map 'nousb', 'nofirewire', etc. to be proper module blacklists. (notting) - Clean off leading and trailing whitespace from descriptions. (notting) - Write out /etc/rpm/platform on livecd installs. (clumens) aspell-ca-50:20040130-1.fc9 --------------------------- * Thu Jan 24 2008 Ivana Varekova - 50:20040130-1 - update to 20040130 aspell-ga-50:4.3-1.fc9 ---------------------- * Thu Jan 24 2008 Ivana Varekova - 50:4.3-1 - update to 4.3-1 autofs-1:5.0.3-4 ---------------- * Fri Jan 25 2008 Ian Kent - 5.0.3-4 - correction to the correction for handling of LDAP base dns with spaces. - avoid using UDP for probing NFSv4 mount requests. - use libldap instead of libldap_r. automake-1.10.1-1 ----------------- * Sat Jan 26 2008 Stepan Kasal 1.10.1-1 - automake-1.10.1 * Mon Oct 29 2007 Stepan Kasal 1.10-7 - keep amhello-1.0.tar.gz in the installed documentation * Thu Aug 09 2007 Karsten Hopp 1.10-6 - update license tag - add Debian man pages for aclocal and automake (#246087) avr-binutils-2.18-1.fc9 ----------------------- * Thu Jan 24 2008 John Voltz 2.18-1 - Bump to binutils 2.18 and add coff-avr patch for VMLAB (on Wine) bluez-utils-3.23-2.fc9 ---------------------- * Fri Jan 25 2008 - Bastien Nocera - 3.23-2 - Fix hcid trying to find the OUI file somewhere in /var (#428803) bodhi-0.4.10-2.fc9 ------------------ * Fri Jan 25 2008 Luke Macken - 0.4.10-2 - Add python-elixir to BuildRequires to make the new TG happy * Fri Jan 25 2008 Luke Macken - 0.4.10-1 - 0.4.10 - Remove yum-utils requirement from bodhi-server checkpolicy-2.0.8-1.fc9 ----------------------- * Fri Jan 25 2008 Dan Walsh - 2.0.8-1 - Latest update from NSA * Deprecate role dominance in parser. clusterssh-3.22-1.fc9 --------------------- * Thu Jan 24 2008 Patrick "Jima" Laughton 3.22-1 - New upstream version coreutils-6.10-1.fc9 -------------------- * Fri Jan 25 2008 Ondrej Vasik - 6.10-1 - New upstream release(changed %prep because of lack of lzma support in %setup macro) - License GPLv3+ - removed patches cp-i-u,du-ls-upstream,statsecuritycontext, futimens,getdateYYYYMMDD,ls-x - modified patches to be compilable after upstream changes - selinux patch reworked to have backward compatibility with F8(cp,ls and stat behaviour differ from upstream in SELinux options) - su-l/runuser-l pam file usage a bit documented(#368721) - more TERMs for DIR_COLORS, added colors for audio files, more image/compress file types(taken from upstream dircolors.hin) - new file DIR_COLORS.256color which takes advantage from 256color term types-not really used yet(#429121) cracklib-2.8.12-1 ----------------- * Fri Jan 25 2008 Nalin Dahyabhai - 2.8.12-1 - update to 2.8.12, which was relicensed to GPLv2 - package the now-bundled cracklib-small dictionary in cracklib-dicts cups-1:1.3.5-3.fc9 ------------------ * Thu Jan 24 2008 Tim Waugh 1:1.3.5-3 - Build requires autoconf. * Mon Jan 21 2008 Tim Waugh 1:1.3.5-2 - Main package requires libs sub-package of the same release. * Thu Jan 10 2008 Tim Waugh - Apply patch to fix busy looping in the backends (bug #426653, STR #2664). cyrus-sasl-2.1.22-11.fc9 ------------------------ * Fri Jan 25 2008 Steve Conklin - 2.1.22-11 - Cleanup after merge review bz #225673 - no longer mark /etc/rc.d/init.d/saslauthd as config file - removed -x permissions on include files - added devel package dependency on cyrus-sasl - removed some remaining .la files that were being delivered dtc-1.1.0-1.fc9 --------------- * Thu Jan 24 2008 Josh Boyer - Update to 1.1.0 e2fsprogs-1.40.4-7.fc9 ---------------------- * Thu Jan 24 2008 Eric Sandeen 1.40.4-7 - Fix sb flag comparisons properly this time (#428893) - Make 256-byte inodes for the [default] mkfs case. This will facilitate upgrades to ext4 later, and help xattr perf. * Wed Jan 23 2008 Eric Sandeen 1.40.4-6 - Completely clobber e2fsck.static build. * Wed Jan 23 2008 Eric Sandeen 1.40.4-5 - Ignore some primary/backup superblock flag differences (#428893) - Teach libblkid about ext4dev. emacs-common-ebib-1.5.2-3.fc9 ----------------------------- * Fri Jan 25 2008 Jonathan G. Underwood - 1.5.2-3 - Bump release eric-3.9.5-2.fc9 ---------------- * Thu Jan 17 2008 Johan Cwiklinski 3.9.5-2 - Add environment variable to set python, qt4 and qt docs path (bug #200856) - Requires python-doc, qt-designer, qt4-devel and qt4-doc - BR: PyQt-devel is already needeed by PyQt-qscintilla-devel file-4.21-5.fc9 --------------- * Thu Jan 24 2008 Tomas Smetana - 4.21-5 - build a separate python-magic package; thanks to Terje Rosten * Thu Dec 06 2007 Tomas Smetana - 4.21-4 - add PE32/PE32+ magic * Wed Aug 15 2007 Martin Bacovsky - 4.21-3 - resolves: #172015: no longer reports filename of crashed app when run on core files. - resolves: #249578: Weird output from "file -i" - resolves: #234817: file reports wrong filetype for microsoft word file freetds-0.64-8.fc9 ------------------ * Fri Jan 25 2008 Dmitry Butskoy - 0.64-8 - resolve multiarch conflicts (#341181): - split references to separate freetds-doc subpackage - add arch-specific suffixes for arch-specific filenames in -devel - add wrapper for tds_sysdep_public.h - add readline support (#430196) gammu-1.17.92-1.fc9 ------------------- * Sat Jan 26 2008 Xavier Lamien < lxtnow[at]gmail.com > - 1.17.92-1 - Updated Release. - Included new binary file. gcstar-1.3.2-1.fc9 ------------------ * Fri Jan 25 2008 Tian - 1.3.2-1 - New upstream version gdb-6.7.1-11.fc9 ---------------- * Thu Jan 24 2008 Jan Kratochvil - 6.7.1-11 - Improve the text UI messages for the build-id debug files locating. - Require now the rpm libraries. - Fix false `(no debugging symbols found)' on `-readnever' runs. - Extend the testcase `gdb.arch/powerpc-prologue.exp' for ppc64. * Sat Jan 12 2008 Jan Kratochvil - 6.7.1-10 - Compilation fixup (-9 was never released). * Sat Jan 12 2008 Jan Kratochvil - 6.7.1-9 - Fix also threaded inferiors for hardware watchpoints after the fork call. - Test debugging statically linked threaded inferiors (BZ 239652). - It requires recent glibc to work in this case properly. - Testcase cleanup fixup of the gcore memory and time requirements of 6.7.1-8. gettext-0.17-1.fc9 ------------------ * Thu Jan 24 2008 Jens Petersen - 0.17-1 - update to 0.17 release - update License field to GPLv3 - add gettext-0.17-open-args.patch to fix build from upstream - gettext-tools-tests-lang-gawk-fail.patch, gettext-php-headers.patch, gettext-php-prinf-output-237241.patch, and gettext-xglade-define-xml-major-version-285701.patch are no longer needed - drop superfluous po-mode-init.el source - no need to run autoconf and autoheader when building - pass -findirect-dispatch to gcj to make java binaries ABI independent (jakub,#427796) - move autopoint, gettextize, and /usr/share/gettext/ to main package - force removal of emacs/ so install does not fail when no emacs gnome-applets-1:2.21.4-4.fc9 ---------------------------- * Fri Jan 25 2008 Matthias Clasen - 1:2.21.4-4 - Port trash applet to gvfs - Remove gnome-vfs dependency in gweather gnome-do-0.3.0.1-3.fc9 ---------------------- * Fri Jan 25 2008 David Nielsen - 0.3.0.1-3 - autostart gnome-do in quiet mode with the user session - to invoke gnome-do use super+space * Tue Jan 22 2008 David Nielsen - 0.3.0.1-2 - Fix BuildRequires gnome-panel-2.21.5-2.fc9 ------------------------ * Fri Jan 25 2008 Jon McCann - 2.21.5-2 - Add ConsoleKit restart/shutdown support gnome-user-share-0.21-1.fc9 --------------------------- * Fri Jan 25 2008 - Bastien Nocera - 0.21-1 - Update to 0.21 goffice-0.6.1-1.fc9 ------------------- * Fri Jan 25 2008 Hans de Goede 0.6.1-1 - Jump to upstream version 0.6.1 for new gnumeric - Notice ABI and API changes! groff-1.18.1.4-12.fc9 --------------------- * Wed Jan 23 2008 Marcela Maslanova - 1.18.1.4-12 - rewrite nroff for using -Tencoding with main support of utf8 - Resolves: rhbz#251064 grub-0.97-21.fc9 ---------------- * Fri Jan 25 2008 Jesse Keating - 0.97-21 - Add a patch from esandeen to support booting from 256byte inodes. * Mon Nov 05 2007 Peter Jones - 0.97-20 - Add EFI support from Intel on x86_64 gstream-1.6-1.fc9 ----------------- hfsutils-3.2.6-13.fc9 --------------------- * Fri Jan 25 2008 Jesse Keating - 3.2.6-13 - Exclude hfssh, nobody really uses it and it drags in tcl to the base requires. - Drop the artificial tcl requirement, rpm will do it's job on reqs. hplip-2.7.12-4.fc9 ------------------ * Fri Jan 25 2008 Tim Waugh 2.7.12-4 - The hpijs compression module doesn't allocate enough memory (bug #428536). icewm-1.2.35-3.fc9 ------------------ * Thu Jan 24 2008 - 1.2.35-3 - Fix broken -devel BR (truetype). icu-3.8.1-3.fc9 --------------- * Fri Jan 25 2008 Caolan McNamara - 3.8.1-3 - CVE-2007-4770 CVE-2007-4771 add icu.regexp.patch - Resolves: rhbz#423211 fix malalayam stuff in light of syllable changes * Fri Jan 11 2008 Caolan McNamara - 3.8.1-2 - remove icu.icu5365.dependantvowels.patch and cleanup icu.icu5506.multiplevowels.patch as they patch and unpatch eachother (thanks George Rhoten for pointing out that madness) * Fri Jan 11 2008 Caolan McNamara - 3.8.1-1 - latest version - drop fixed icu.icu6084.zwnj.notdef.patch jd-1.9.8-2.svn1747_jd1.fc9 -------------------------- * Fri Jan 25 2008 Mamoru Tasaka - 1.9.8-2.svn1747_jd1 - svn jd-1 1747 kde-filesystem-4-7.fc9 ---------------------- * Fri Jan 25 2008 Kevin Kofler 4-7 - own %{_kde4_appsdir}/color-schemes kdebase3-3.5.8-35.fc9 --------------------- * Thu Jan 24 2008 Kevin Kofler - 3.5.8-35 - fix file list again (missing libkdeinit_* for f9+) - f9+: reenable kate (libkateutils and libkateinterfaces needed by kscope) - f9+: remove %{_datadir}/config/katerc - f9+: reenable kdesu for now (until we figure out what to do about it) kernel-2.6.24-2.fc9 ------------------- * Fri Jan 25 2008 Chuck Ebbert - Bump revision. * Fri Jan 25 2008 Kyle McMartin - Linux 2.6.24 * Thu Jan 24 2008 Chuck Ebbert - Linux 2.6.24-rc8-git7 kerneloops-0.10-2.fc9 --------------------- * Thu Jan 24 2008 Chuck Ebbert - 0.10-2 - Fix misnamed kerneloops man page file. (#430102) kvm-60-1.fc9 ------------ * Thu Jan 24 2008 Daniel P. Berrange - 60-1.fc9 - Updated to kvm-60 - Fix license tag to keep rpmlint quiet - Remove unused PPC, Sparc and PPC Video BIOS libgda-1:3.1.2-1.fc9 -------------------- * Fri Jan 25 2008 Hans de Goede 1:3.1.2-1 - New upstream release 3.1.2 (needed for new gnumeric) - Drop upstreamed / no longer needed patches libgdamm-2.9.81-1.fc9 --------------------- * Sat Jan 26 2008 Denis Leroy - 2.9.81-1 - Update to upstream 2.9.81, needed a rebuild for libgda anyway libselinux-2.0.49-2.fc9 ----------------------- * Fri Jan 25 2008 Dan Walsh - 2.0.49-2 - Fix audit2why to grab latest policy versus the one selected by the kernel libsemanage-2.0.16-1.fc9 ------------------------ * Tue Jan 22 2008 Dan Walsh - 2.0.16-1 - Update to upstream * Merged fix for genhomedircon handling of missing HOME_DIR or HOME_ROOT templates from Caleb Case. libtool-1.5.24-5.fc9 -------------------- * Wed Jan 23 2008 Karsten Hopp 1.5.24-5 - add missing define * Wed Jan 23 2008 Karsten Hopp 1.5.24-4 - require specific gcc version as that path is hardcoded in libtool (#429880) lohit-fonts-2.1.8-1.fc9 ----------------------- * Fri Jan 25 2008 Rahul Bhalerao - 2.1.8-1 - Updated version according to upstream to incorporate the bug fixes. m17n-contrib-1.1.5-2.fc9 ------------------------ * Thu Jan 24 2008 Parag Nemade -1.1.5-2 - Resolves:rh#430054 muine-0.8.8-6.fc9 ----------------- * Tue Jan 22 2008 Sindre Pedersen Bj??rdal - 0.8.8-6 - Don't remove mono provides after all, removes needed stuff mysql-proxy-0.6.0-2.fc9 ----------------------- * Thu Jan 24 2008 Ruben Kerkhof - 0.6.0-2 - Rebuild to pick up new libevent nfs-utils-1:1.1.1-3.fc9 ----------------------- * Thu Jan 24 2008 Steve Dickson 1.1.1-3 - Added in relatime mount option so mount.nfs stays compatible with the mount command in util-linux-ng (bz 274301) * Tue Jan 22 2008 Steve Dickson 1.1.1-2 - Added -S/--since to the nfsstat(1) manpage - The wording in the exportfs man page can be a bit confusing, implying that "exportfs -u :/foo" will unexport /foo from all hosts, which it won't - Removed nfsprog option since the kernel no longer supports it. - Removed mountprog option since the kernel no longer supports it. - Stop segfaults on amd64 during warnings messages. - Fix bug when both crossmnt and fsid are set. nfs-utils-lib-1.1.1-1.fc9 ------------------------- * Thu Jan 24 2008 Steve Dickson 1.1.1-1 - Updated librpcsecgss to the 0.17 release nspr-4.6.99.3-1.fc9 ------------------- * Thu Jan 24 2008 Kai Engert - 4.6.99.3-1 * NSPR 4.7 beta snapshot 20080120 nss-3.11.99.3-1.fc9 ------------------- * Thu Jan 24 2008 Kai Engert - 3.11.99.3-1 * NSS 3.12 Beta 1 * Mon Jan 07 2008 Kai Engert - 3.11.99.2b-3 - move .so files to /lib * Wed Dec 12 2007 Kai Engert - 3.11.99.2b-2 - NSS 3.12 alpha 2b ogre-1.4.6-4.fc9 ---------------- * Thu Jan 24 2008 Hans de Goede 1.4.6-4 - Install 2 additional header files for ogre4j (bz 429965) openldap-2.4.7-4.fc9 -------------------- * Fri Jan 25 2008 Jan Safranek 2.4.7-4 - fixed rpmlint warnings and errors * Tue Jan 22 2008 Jan Safranek 2.4.7-3 - obsoleting compat-openldap properly again :) * Tue Jan 22 2008 Jan Safranek 2.4.7-2 - obsoleting compat-openldap properly (#429591) openoffice.org-1:2.4.0-4.1.fc9 ------------------------------ * Wed Jan 23 2008 Caolan McNamara - 1:2.4.0-4.1 - next milestone - drop integrated openoffice.org-2.4.0.ooo83410.solenv.renameserbian.patch - drop integrated openoffice.org-2.3.1.ooo83877.sal.allowsoftlinkdelete.patch - drop integrated workspace.sw8u10bf04.patch - drop integrated workspace.impress132.patch - add openoffice.org-2.4.0.ooo85487.evoconnectivity.patch to make evoab2 build - new finnish autocorrect file - Resolves: rhbz#429897 one click print with lpr-only backend fix - Resolves: rhbz#426295 openoffice.org-2.4.0.ooo85470.vcl.cairotext.patch use export SAL_ENABLE_CAIROTEXT=1 to enable * Mon Jan 21 2008 Caolan McNamara - 1:2.4.0-3.3 - fix openoffice.org-2.4.0.ooo85321.vcl.pixmapleak.patch for warren - fix openoffice.org-2.4.0.ooo85429.sw.a11ycrash.patch - Resolves: rhbz#428574 add workspace.sw24bf02.patch - Resolves: problem in rhbz#429550 openoffice.org-2.4.0.ooo85448.emptyrpath.patch * Sat Jan 19 2008 Caolan McNamara - 1:2.4.0-3.2 - Resolves: rhbz#429258 openoffice.org-2.4.0.ooo85385.svtools.a11ycrash.patch openser-1.3.0-4.fc9 ------------------- * Fri Jan 25 2008 Jan ONDREJ (SAL) 1.3.0-4 - modify and apply forgotten patch4 openssl-0.9.8g-4.fc9 -------------------- * Thu Jan 24 2008 Tomas Mraz 0.9.8g-4 - merge review fixes (#226220) - adjust the SHLIB_VERSION_NUMBER to reflect library name (#429846) openswan-2.6.03-9.fc9 --------------------- * Thu Jan 24 2008 Steve Conklin - 2.6.03-9 - Added af_key module load to init script - Removed spurious warning about interfaces= * Mon Jan 21 2008 Steve Conklin - 2.6.03-8 Related: rhbz#235224 - rpmdiff spotted these: - Cleaned out unused man page - patch error in barf script * Fri Jan 18 2008 Steve Conklin - 2.6.03-7 - Addressed the last set of small changes for package review openvpn-2.1-0.22.rc6.fc9 ------------------------ * Thu Jan 24 2008 Steven Pritchard 2.1-0.22.rc6 - Update to 2.1_rc6 - Pass paths to ifconfig, ip, and route to configure - BR iproute and Require iproute and net-tools - Add BETA21-userpriv-fixups.patch from Alon Bar-Lev * Wed Jan 23 2008 Steven Pritchard 2.1-0.21.rc5 - Update to 2.1_rc5 openvrml-0.17.3-3.fc9 --------------------- * Thu Jan 24 2008 Braden McDaniel - 0.17.3-3 - Try again with --disable-gecko-rpath. ovaldi-5.3-5.fc9 ---------------- * Thu Jan 24 2008 Lubomir Kundrak 5.3-5 - Make the patch actually apply perl-Module-ScanDeps-0.81-1.fc9 ------------------------------- * Thu Jan 24 2008 Steven Pritchard 0.81-1 - Update to 0.81. - Use fixperms macro instead of our own chmod incantation. - Reformat to match cpanspec output. - BR ExtUtils::MakeMaker. perl-Text-Quoted-2.05-1.fc9 --------------------------- * Fri Jan 25 2008 Ralf Cors??pius - 2.05-1 - Upstream update. policycoreutils-2.0.39-1.fc9 ---------------------------- * Thu Jan 24 2008 Dan Walsh 2.0.39-1 - Don't initialize audit2allow for audit2why call. Use default - Update to upstream * Merged fixfiles -C fix from Marshall Miller. * Thu Jan 24 2008 Dan Walsh 2.0.38-1 - Update to upstream * Merged audit2allow cleanups and boolean descriptions from Dan Walsh. * Merged setfiles -0 support by Benny Amorsen via Dan Walsh. * Merged fixfiles fixes and support for ext4 and gfs2 from Dan Walsh. procps-3.2.7-19.2.fc9 --------------------- * Thu Jan 24 2008 Tomas Smetana 3.2.7-19.2 - install slabtop again: kernel was fixed pybliographer-1.2.11-2.fc9 -------------------------- * Fri Jan 25 2008 Zoltan Kota - 1.2.11-2 - add patch for fixing bug #428121 pygtk2-2.12.1-3.fc9 ------------------- * Thu Jan 24 2008 Matthew Barnes - 2.12.1-3.fc9 - Documentation files should not be executable (RH bug #430093). * Mon Jan 21 2008 Matthew Barnes - 2.12.1-2.fc9 - Update package description to match suggestions from Content Services. python-pyblock-0.31-1 --------------------- * Thu Jan 24 2008 Chris Lumens 0.31-1 - Fix traceback when scanning disks (#429713). * Mon Aug 27 2007 Peter Jones - 0.30-1 - Fix link error due to Makefile changes. * Thu Aug 23 2007 Peter Jones - 0.29-1 - Fix device mapper build deps. qt-1:3.3.8b-3.fc9 ----------------- * Thu Jan 24 2008 Than Ngo 3.3.8b-3 - add LICENSE.GPL2/GPL3 * Thu Jan 24 2008 Than Ngo 3.3.8b-2 - License: GPLv2 or GPLv3 - merged in 3.3.8b -> drop following patches: * qt-3.3.6-fontrendering-punjabi-209970.patch * qt-3.3.6-fontrendering-or_IN-209098.patch * qt-3.3.6-fontrendering-gu-228451.patch * qt-font-default-subst.diff * 0076-fix-qprocess.diff * 0082-fix-qdatetime-fromstring.diff * qt-x11-free-3.3.8-bz#243722-mysql.patch * qt3-CVE-2007-3388.patch * utf8-bug-qt3-CVE-2007-0242.diff * qt-3.3.6-bz#292941-CVE-2007-4137.patch * Wed Jan 23 2008 Than Ngo 3.3.8b-1 - update to 3.3.8b, fix License qt-recordmydesktop-0.3.7-1.fc9 ------------------------------ * Wed Jan 23 2008 Alex Lancaster - 0.3.7-1 - Update to latest upstream 0.3.7 to match recordmydesktop qt4-4.3.3-5.fc9 --------------- * Thu Jan 24 2008 Rex Dieter 4.3.3-5 - License: GPLv2 or QPL - qt-copy patches * Thu Jan 17 2008 Rex Dieter 4.3.3-4 - Qt.pc: fix typo for demosdir (use %_qt4_demosdir) qt4-theme-quarticurve-0.0-0.10.beta7.fc9 ---------------------------------------- * Fri Jan 25 2008 Kevin Kofler - 0.0-0.10.beta7 - Update to beta 7: - Added a color scheme for the KDE 4 color scheme selector - Updated the color section in readme.txt - BR kdelibs4-devel for kde4-config. - Require kde-filesystem >= 4-7 for directory ownership. - Update file list (add Quarticurve.colors). - Cleanup description. quota-1:3.15-1.fc9 ------------------ * Thu Jan 24 2008 Steve Dickson 3.15-1 - Upgraded to version 3.15 - Updated spec file per Merge Review (bz 226353) rpcbind-0.1.4-13.fc9 -------------------- * Thu Jan 24 2008 Steve Dickson 0.1.4-13 - Fixed connectivity with Mac OS clients by making sure handle_reply() sets the correct fromlen in its recvfrom() call (bz 244492) rpm-4.4.2.3-0.1.rc1 ------------------- * Fri Jan 25 2008 Panu Matilainen 4.4.2.3-0.1.rc1 - update to 4.4.2.3-rc1 - merge nss-related patches into one - change default queryformat to include arch - resolves (documentation): #159638, #233232, #332271, #350401 - resolves (build): #124300, #140597, #124995, #147383, #220449 - resolves (query): #244236, #323221, #60288 - resolves (general): #223931, #164021, #83006, #205080, #217258, #428979 * Fri Jan 11 2008 Panu Matilainen 4.4.2.2-13 - lose the useless rpm user+group, use root:root like everything else - install x86 arch macros on x86_64 (#194123) - dont mess up target os+arch on rpmrc include (#232429) - set pkg-config path based on target (#212522) - fix funky automake breakage from nss libraries moving to /lib* * Fri Jan 04 2008 Panu Matilainen 4.4.2.2-12 - fix segfault in devel symlink dependency generation from Mark Salter (#338971) - fix debugedit build with gcc 4.3 - drop popt-static build dependency rubyripper-0.5.0-2.fc9 ---------------------- * Thu Jan 24 2008 Sindre Pedersen Bj??rdal - 0.5.0-2 - New release - Minor spec cleanups selinux-policy-3.2.5-19.fc9 --------------------------- * Thu Jan 24 2008 Dan Walsh 3.2.5-19 - Fix nsplugin to allow flashplugin to work in enforcing mode slang-2.1.3-2.fc9 ----------------- * Thu Jan 24 2008 Miroslav Lichvar - 2.1.3-2 - drop lang patch - build oniguruma module (#226420) smb4k-0.9.2-3.fc9 ----------------- * Sat Jan 26 2008 Marcin Garski 0.9.2-3 - Update to 0.9.2 - Don't compile Konqueror plugin snake-0.10-0.4git.fc9 --------------------- * Thu Jan 24 2008 James Laska 0.10-0.4git - Bug#429479 - conditionally build the snake-server sub-package only when pykickstart.version is found (jlaska) - Move more constants to snake/constants.py (jlaska) - snake/tree.py - _fill_in_images() called when .treeinfo images are not found (jlaska) speex-1.2-0.4.beta3 ------------------- * Thu Jan 24 2008 Marcela Maslanova - 1.2-0.4.beta3 - update to beta 3 - review: rhbz#226428 sqlite-3.5.4-3.fc9 ------------------ * Fri Jan 25 2008 Panu Matilainen - 3.5.4-3 - enable column metadata API (#430258) system-config-firewall-1.2.0-1.fc9 ---------------------------------- * Fri Jan 25 2008 Thomas Woerner 1.2.0-1 - added port forwarding - using INPUT chain in table filter instead of RH-Firewall-1-INPUT - fixed masquerading - rewrite of firewall generation code - trusted hosts now also allowed for FORWARD - lots of bug fixes - gui enhancements system-config-printer-0.7.79-1.fc9 ---------------------------------- * Fri Jan 25 2008 Tim Waugh 0.7.79-1 - 0.7.79. trac-monotone-plugin-0.0.13-1.20080125mtn393b5412.fc9 ----------------------------------------------------- which-2.19-1.fc9 ---------------- * Fri Jan 25 2008 Than Ngo 2.19-1 - 2.19, fix #399551, #430159 wine-0.9.54-1.fc9 ----------------- * Fri Jan 25 2008 Andreas Bierfert - 0.9.54-1 - version upgrade - remove default pulseaudio workaround (#429420,#428745) - improve pulseaudio readme xbase-2.0.0-9.fc9 ----------------- * Fri Jan 25 2008 Hans de Goede 2.0.0-9 - Fix building with gcc 4.3 (also fixes building of xbase using packages) xdg-utils-1.0.2-4.fc9 --------------------- * Fri Jan 25 2008 Lubomir Kundrak 1.0.2-4 - Fix for CVE-2008-0386 (#429513) xenner-0.23-1.fc9 ----------------- * Fri Jan 25 2008 Gerd Hoffmann - 0.23-1.fc9 - update to version 0.23. - new -libvirt-caps cmd line switch. xulrunner-1.9-0.beta2.14.nightly20080121.fc9 -------------------------------------------- * Fri Jan 25 2008 Martin Stransky 1.9-0.beta2.14 - rebuild agains new nss - enabled gnome vfs ytalk-3.3.0-11.fc9 ------------------ * Thu Jan 24 2008 Mike McGrath - 3.3.9-11 - Release bump for rebuild (koji test) yum-3.2.10-2.fc9 ---------------- * Fri Jan 25 2008 Seth Vidal - 3.2.10-1 - 3.2.10 - add pygpgme dep * Wed Dec 05 2007 Seth Vidal - 3.2.8-2 - keep livecd working - patch from upstream until 3.2.9 comes out * Mon Dec 03 2007 Seth Vidal - 3.2.8-1 - 3.2.8 yum-metadata-parser-1.1.2-7.fc9 ------------------------------- * Fri Jan 25 2008 Seth Vidal 1.1.2-7 - apply exclusive lock patch * Thu Jan 24 2008 Seth Vidal 1.1.2-6 - add explicit dep on glib2 > 2.15 Broken deps for i386 ---------------------------------------------------------- 1:abiword-2.4.6-6.fc8.i386 requires libgoffice-1.so.2 blender-2.45-5.fc9.i386 requires libgettextlib-0.16.1.so compiz-kde-0.6.2-6.fc9.i386 requires libkdecorations.so.1 crystal-1.0.5-1.fc8.i386 requires libkdecorations.so.1 dekorator-0.3-3.fc7.i386 requires libkdecorations.so.1 epiphany-extensions-2.20.1-3.fc9.i386 requires libgtkembedmoz.so epiphany-extensions-2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 gambas-runtime-1.0.19-3.fc8.i386 requires libgettextlib-0.16.1.so gnome-web-photo-0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo-0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo-0.3-8.fc9.i386 requires libgtkembedmoz.so gnome-web-photo-0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 1:gnumeric-1.6.3-13.fc9.i386 requires libgoffice-1.so.2 kazehakase-0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 kicker-compiz-3.5.4-4.fc8.i386 requires libkickermain.so.1 kicker-compiz-3.5.4-4.fc8.i386 requires libtaskmanager.so.1 ksplash-engine-moodin-0.4.2-4.fc7.i386 requires libksplashthemes.so.0 memcached-1.2.4-2.fc9.i386 requires libevent-1.3b.so.1 muine-0.8.8-6.fc9.i386 requires mono(muine-plugin) = 0:1.0.0.0 scanssh-2.1-14.fc8.i386 requires libevent-1.3b.so.1 tor-core-0.1.2.18-2.fc9.i386 requires libevent-1.3b.so.1 Broken deps for x86_64 ---------------------------------------------------------- 1:abiword-2.4.6-6.fc8.x86_64 requires libgoffice-1.so.2()(64bit) blender-2.45-5.fc9.x86_64 requires libgettextlib-0.16.1.so()(64bit) compiz-kde-0.6.2-6.fc9.x86_64 requires libkdecorations.so.1()(64bit) crystal-1.0.5-1.fc8.x86_64 requires libkdecorations.so.1()(64bit) dekorator-0.3-3.fc7.x86_64 requires libkdecorations.so.1()(64bit) epiphany-extensions-2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) epiphany-extensions-2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo-0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) gnome-web-photo-0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo-0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo-0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) 1:gnumeric-1.6.3-13.fc9.i386 requires libgoffice-1.so.2 1:gnumeric-1.6.3-13.fc9.x86_64 requires libgoffice-1.so.2()(64bit) kazehakase-0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 kicker-compiz-3.5.4-4.fc8.x86_64 requires libkickermain.so.1()(64bit) kicker-compiz-3.5.4-4.fc8.x86_64 requires libtaskmanager.so.1()(64bit) ksplash-engine-moodin-0.4.2-4.fc7.x86_64 requires libksplashthemes.so.0()(64bit) memcached-1.2.4-2.fc9.x86_64 requires libevent-1.3b.so.1()(64bit) muine-0.8.8-6.fc9.x86_64 requires mono(muine-plugin) = 0:1.0.0.0 scanssh-2.1-14.fc8.x86_64 requires libevent-1.3b.so.1()(64bit) tor-core-0.1.2.18-2.fc9.x86_64 requires libevent-1.3b.so.1()(64bit) Broken deps for ppc ---------------------------------------------------------- 1:abiword-2.4.6-6.fc8.ppc requires libgoffice-1.so.2 anaconda-11.4.0.27-1.ppc requires dmidecode blender-2.45-5.fc9.ppc requires libgettextlib-0.16.1.so compiz-kde-0.6.2-6.fc9.ppc requires libkdecorations.so.1 crystal-1.0.5-1.fc8.ppc requires libkdecorations.so.1 dekorator-0.3-3.fc7.ppc requires libkdecorations.so.1 epiphany-extensions-2.20.1-3.fc9.ppc requires libgtkembedmoz.so epiphany-extensions-2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 gambas-runtime-1.0.19-3.fc8.ppc requires libgettextlib-0.16.1.so gnome-web-photo-0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo-0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo-0.3-8.fc9.ppc requires libgtkembedmoz.so gnome-web-photo-0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 1:gnumeric-1.6.3-13.fc9.ppc requires libgoffice-1.so.2 1:gnumeric-1.6.3-13.fc9.ppc64 requires libgoffice-1.so.2()(64bit) kazehakase-0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 kicker-compiz-3.5.4-4.fc8.ppc requires libkickermain.so.1 kicker-compiz-3.5.4-4.fc8.ppc requires libtaskmanager.so.1 ksplash-engine-moodin-0.4.2-4.fc7.ppc requires libksplashthemes.so.0 memcached-1.2.4-2.fc9.ppc requires libevent-1.3b.so.1 monodevelop-0.17-4.fc9.ppc requires boo muine-0.8.8-6.fc9.ppc requires mono(muine-plugin) = 0:1.0.0.0 scanssh-2.1-14.fc8.ppc requires libevent-1.3b.so.1 tor-core-0.1.2.18-2.fc9.ppc requires libevent-1.3b.so.1 Broken deps for ppc64 ---------------------------------------------------------- 1:abiword-2.4.6-6.fc8.ppc64 requires libgoffice-1.so.2()(64bit) anaconda-11.4.0.27-1.ppc64 requires dmidecode blender-2.45-5.fc9.ppc64 requires libgettextlib-0.16.1.so()(64bit) crystal-1.0.5-1.fc8.ppc64 requires libkdecorations.so.1()(64bit) dekorator-0.3-3.fc7.ppc64 requires libkdecorations.so.1()(64bit) epiphany-extensions-2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) epiphany-extensions-2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo-0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) gnome-web-photo-0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo-0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo-0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) 1:gnumeric-1.6.3-13.fc9.ppc64 requires libgoffice-1.so.2()(64bit) kazehakase-0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 kicker-compiz-3.5.4-4.fc8.ppc64 requires libkickermain.so.1()(64bit) kicker-compiz-3.5.4-4.fc8.ppc64 requires libtaskmanager.so.1()(64bit) ksplash-engine-moodin-0.4.2-4.fc7.ppc64 requires libksplashthemes.so.0()(64bit) memcached-1.2.4-2.fc9.ppc64 requires libevent-1.3b.so.1()(64bit) perl-Test-AutoBuild-darcs-1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 scanssh-2.1-14.fc8.ppc64 requires libevent-1.3b.so.1()(64bit) tor-core-0.1.2.18-2.fc9.ppc64 requires libevent-1.3b.so.1()(64bit) From twoerner at redhat.com Sat Jan 26 14:40:56 2008 From: twoerner at redhat.com (Thomas Woerner) Date: Sat, 26 Jan 2008 15:40:56 +0100 Subject: More firewall changes for F-9+ In-Reply-To: <20080125205249.GB31359@angus.ind.WPI.EDU> References: <479A3663.1060309@redhat.com> <20080125205249.GB31359@angus.ind.WPI.EDU> Message-ID: <479B4678.40700@redhat.com> Chuck Anderson wrote: > On Fri, Jan 25, 2008 at 08:20:03PM +0100, Thomas Woerner wrote: >> some minutes ago system-config-firewall-1.2.0 has been build for rawhide. >> - New support for port forwarding. >> - The chain RH-Firewall-1-INPUT has been dropped. >> - Trusted hosts are also added to the FORWARD chain in the filter table. >> - The iptables firewall configuration has been optimized. >> - Several GUI enhancements. > > Does it fix this bug? > > https://bugzilla.redhat.com/show_bug.cgi?id=426720 > > Masquerading doesn't allow packets to be forwarded by default > Yes, it fixes this bug. Next week I will work on the bugfix package for F8. Thomas From mschwendt.tmp0701.nospam at arcor.de Sat Jan 26 14:49:31 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 26 Jan 2008 15:49:31 +0100 Subject: long term support release In-Reply-To: <1201260265.17905.299.camel@beck.corsepiu.local> References: <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <20080125090654.GA3062@orient.maison.lan> <1201253280.17905.280.camel@beck.corsepiu.local> <20080125094711.GA3298@orient.maison.lan> <20080125112959.baaf72d3.mschwendt.tmp0701.nospam@arcor.de> <1201260265.17905.299.camel@beck.corsepiu.local> Message-ID: <20080126154931.e019bb6b.mschwendt.tmp0701.nospam@arcor.de> On Fri, 25 Jan 2008 12:24:25 +0100, Ralf Corsepius wrote: > > Fedora LTS would compete with CentOS+EPEL and would lead > > to even more mass-builds. > > We are back to what IMO, this all obits around: questioning the > "will" :/ Yes, I question the number of people with such a "will". Because the situation has changed. You cannot hope to win back any volunteers who have switched to CentOS, where a lot is easier to do -- also with regard to trademark issues. Updates can be copied from RHEL verbatim. You don't need to duplicate Red Hat's security team. Instead, you simply rely on it. There are no promises to fix bugs in CentOS until they are fixed in RHEL. CentOS is the road of least resistance for community volunteers. Fedora Legacy, on the other hand, was willing to sink its own ship while still in the harbour. That made it even easier for volunteers to find an excuse when wandering off, blaming the bureaucracy and insufficient infrastructure. If as many hurdles as possible had been removed, only then the project would have managed to find out whether there would have been enough volunteers to increase the life-time of a few distributions for N months and deal with every vulnerability in every package, also the big ones. For RHL it was possible to copy/port patches from their corresponding RHEL packages. For Fedora, you are in version upgrade hell. Perhaps a dry-run with Fedora 6 or 7 would tell. Get somebody to find out what security fixes would need to be published for those dists. This could happen in parallel with building a SIG, filled with people with strong interest in doing lots of thankless work and being held liable for mistakes later on, too. I think you will find out that you would benefit from or be in need of corporate backing (as not to duplicate a lot of work). From sebastian at when.com Sat Jan 26 15:02:02 2008 From: sebastian at when.com (sebastian at when.com) Date: Sat, 26 Jan 2008 16:02:02 +0100 Subject: Fedora Education Spin Message-ID: <479B4B6A.90805@when.com> Hi, I have built a Fedora live cd with educational apps. The kickstart file is here: http://fedoraproject.org/wiki/SebastianDziallas/Education Some feedback would be great, so maybe you could tell me, if you have any suggestions or recommendations. And would it be possible, to make an official spin of it? Sebastian From d.jacobfeuerborn at conversis.de Sat Jan 26 15:34:47 2008 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Sat, 26 Jan 2008 16:34:47 +0100 Subject: Disable Pulseaudio In-Reply-To: <200801261124.44021.ville.skytta@iki.fi> References: <479A78CC.5030509@conversis.de> <479A883D.5080401@conversis.de> <200801261124.44021.ville.skytta@iki.fi> Message-ID: <479B5317.4090402@conversis.de> Ville Skytt? wrote: > On Saturday 26 January 2008, Dennis Jacobfeuerborn wrote: >> Michel Salim wrote: >> >>> Do you have anything in ~/.asoundrc ? >> That was it. I think I created that file some time ago to get skype working >> but then forgot about it. Now alsa works as it should, thanks! > > Hmm, I lost interest in trying to get Skype working with PA in F8 shortly > after F8 release and found that getting rid of PA as much as possible was a > quick "fix" for it; if you have good recipes for ~/.asoundrc that result in a > working Skype+PA setup, those would be appreciated. I'm pretty sure I've > already tried stuff at http://www.pulseaudio.org/wiki/PerfectSetup#Skype to > no avail. > This is what I put in my .asoundrc to get things working at the time: pcm.!default { type pulse } ctl.!default { type pulse } pcm.pulse { type pulse } ctl.pulse { type pulse } This was a while ago though and I'm not sure what settings you have to choose in Skype but I can confirm that in the end I was able to use my headset properly. Maybe that helps. Regards, Dennis From szaka at ntfs-3g.org Sat Jan 26 15:51:37 2008 From: szaka at ntfs-3g.org (Szabolcs Szakacsits) Date: Sat, 26 Jan 2008 15:51:37 +0000 (UTC) Subject: F9 Alpha spinning References: <20080125162835.GA19048@crow> Message-ID: Kevin Kofler chello.at> writes: > Szabolcs Szakacsits ntfs-3g.org> writes: > > > > The ntfs-3g size increase enabled the fuse package removal, so > > the real change is 109046 bytes less used (511418 -> 402372). > > Aren't we supposed to be moving _away_ from static copies of system libraries > in packages? Ntfs-3g has no static copy of any library. If you're interested then you may read the text starting at "The big change this time is ..." at the below URL for the explanation why you're misunderstanding the situation: http://article.gmane.org/gmane.comp.file-systems.ntfs-3g.devel/392 Szaka -- NTFS-3G: http://ntfs-3g.org From kevin.kofler at chello.at Sat Jan 26 16:34:15 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 26 Jan 2008 16:34:15 +0000 (UTC) Subject: F9 Alpha spinning References: <20080125162835.GA19048@crow> Message-ID: Szabolcs Szakacsits ntfs-3g.org> writes: > Ntfs-3g has no static copy of any library. That's just a matter of terminology, what's sure is that your fuse-lite fork is there. > If you're interested then you may read the text starting at "The big > change this time is ..." at the below URL for the explanation why you're > misunderstanding the situation: > > http://article.gmane.org/gmane.comp.file-systems.ntfs-3g.devel/392 Well, your arguments are pretty unconvincing, and apply to a lot of application-library relationships, still usually library users won't fork a library just for that, or when they do, Fedora won't ship their fork. Your worries about old FUSE versions being used are also unfounded when it comes to Fedora, as Fedora upgrades such packages regularly, often within days of the upstream release, and if it's useful to improve ntfs-3g, the upgrade is even more likely to get pushed quickly. So I think ntfs-3g should really be built against the external FUSE in Fedora, as by our guidelines: http://fedoraproject.org/wiki/Packaging/Guidelines#head-17396a3b06ec849a7c0c6fc3243673b17e5fed90 Normally, if libraries need patches to make dependent packages to work well, we just apply the patches to the library rather than shipping a fork. Spot (Tom Callaway), if you're reading this, can you elaborate on the decision of defaulting to internal fuse-lite in the Fedora ntfs-3g package? To me, this decision appears to contradict your own guidelines. Kevin Kofler From jonstanley at gmail.com Sat Jan 26 16:35:13 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Sat, 26 Jan 2008 11:35:13 -0500 Subject: long term support release In-Reply-To: <1201329869.17905.554.camel@beck.corsepiu.local> References: <1201058211.3001.79.camel@gandalf.cobite.com> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> <1201251592.17905.255.camel@beck.corsepiu.local> <80d7e4090801251033s1fce270akfcf6a73e882b0236@mail.gmail.com> <1201329869.17905.554.camel@beck.corsepiu.local> Message-ID: On Jan 26, 2008 1:44 AM, Ralf Corsepius wrote: > Sigh, I am repeating myself over and over again: Back then, I did offer > to contribute to Fedora Legacy under the "Fedora hood" when if it had > used the Fedora infrastructure. Legacy, to my knowledge, never used the Fedora infrastructure, so I'm not sure what you're saying here. > > Unfortunately, FESCO/FAB/FPB and RH shot any such proposal down and > insisted on keeping Legacy a separate project, using its own > infrastructure etc. Someday, out of blue sky, Legacy had been closed > down. I dunno how many times we have to repeat ourselves here for you to get it. Jeff (a Fedora Board member) has repeatedly said on this thread "if you can get interested people together, then let's talk". Jesse Keating, of releng, said: "This is what Jeff has been saying over and over. Come up with a plan and people, and the board/releng/infrastructure will see what we can do to help, if we can help." I'm not sure how much more clear you can get that there is not "institutional opposition" to such an idea. I really hate to toot my own horn, in general, but I feel that it's an appropriate example in this case. I came to Fedora to do bug triage. I *very* quickly realized that there was a lack of a viable triage group within Fedora. Therefore, I complained. It went to FAB, where everyone agreed that there was lack of leadership in this area, so I volunteered to step up to the plate. This is the part that you're lacking, Ralf. I started to build a community around the problem, and while there is a lot of work yet to be done in order to say I've been even somewhat successful, it's well on it's way. The motto of the story? "Put up or shut up". I chose to put up. Will you? > I tried to propose "extending Fedora's life time under community > control" as a compromise which I consider to be easily bought-in. It is. > Unfortunately, I am facing fierce opposition and feel machine-gunned, by > a Fedora leadership of which I feel hasn't comprehended the powers of > community support in open source. I don't get it. I believe that the current Fedora leadership knows very well the value and power of community in open source. Just look at who was selected to be the next Fedora Project Leader - not someone who's been sitting inside Red Hat forever, but rather a trusted community leader. I feel you guys, are thinking in terms > Openly said, in front of this background, I feel this Fedora leadership, > esp. the @RHs within it (probably due to their corporite background), > are standing in their own way. I really don't see this from where I sit. > Consider all proposals I made withdrawn - You shot them down. I don't think that anyone has shot any of them down. I think what has occurred here is that it's been said that you are DRASTICALLY underestimating the level of effort required in order to make this work (which is true), and in fact you're sort of wishy-washy of the goals of such a project. Feel free to flame me. From mclasen at redhat.com Sat Jan 26 16:54:07 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Sat, 26 Jan 2008 11:54:07 -0500 Subject: space on the live cds Message-ID: <1201366447.3282.8.camel@localhost.localdomain> As usual, the live cd isos don't fit... I've spent some time last night looking for suspicious dependencies, etc. Here are some of the things I spotted: * Some devel packages get dragged in: - policycoreutils-gui pulls in selinux-policy-devel, which in turn pulls in checkpolicy. Why ? - mono-winforms pulls in libgdiplus-devel * Some other questionable dependencies: - man pulls in diffutils just so that man -a can optionally use /usr/binb/cmp - ekiga pulls in SDL ? * Packages which appear too large for other reasons - About half the size of mono-core seems to be .mdb files. Isn't that debuginfo and should go in a -debuginfo package ? - opal contains the largest shared library by far. Something must go really wrong with the autogenerated C++ code there. The library contains > 35.000 symbols... - ghostscript ships the next largest shared library. From the looks of it, this is because it includes copies of libpng, libjpeg, libjasper and libz.... Matthias From chitlesh.goorah at gmail.com Sat Jan 26 18:00:25 2008 From: chitlesh.goorah at gmail.com (Chitlesh GOORAH) Date: Sat, 26 Jan 2008 19:00:25 +0100 Subject: Fedora Education Spin In-Reply-To: <479B4B6A.90805@when.com> References: <479B4B6A.90805@when.com> Message-ID: <50baabb30801261000g690bfc40w80fdff6cca0efd35@mail.gmail.com> On Jan 26, 2008 4:02 PM, wrote: > Hi, > > I have built a Fedora live cd with educational apps. The kickstart file > is here: http://fedoraproject.org/wiki/SebastianDziallas/Education > > Some feedback would be great, so maybe you could tell me, if you have > any suggestions or recommendations. > > And would it be possible, to make an official spin of it? > > Sebastian I think for "Education" you are missing "kdeedu". Whether you are a gnome user or kde user, I think you should consider pulling kdeedu in your spin in favor of firefox, totem. The kdeedu of KDE4 (in rawhide) has a wonderful collection of applications for education. Gcompris also is to my eyes a wonderful application and is attractive to many educational institutions in Europe. Kdeedu applications and gcompris are a "must" on my list when I'm at a booth in "Science Days". regards, Chitlesh From lesmikesell at gmail.com Sat Jan 26 18:09:21 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sat, 26 Jan 2008 12:09:21 -0600 Subject: long term support release In-Reply-To: <479B29B2.1070407@gmail.com> References: <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> <20080125152614.GA2975@free.fr> <20080125103335.0d5adacf@redhat.com> <20080125154127.GC2975@free.fr> <1201275741.1163.1.camel@localhost.localdomain> <20080125154749.GD2975@free.fr> <20080125105041.6605e470@redhat.com> <479A10D0.7020301@gmail.com> <200801251709.m0PH9iV5015900@laptop13.inf.utfsm.cl> <479B29B2.1070407@gmail.com> Message-ID: <479B7751.4050503@gmail.com> Andrew Farris wrote: >> I was perfectly happy with RH 6.2, and most of what I do now I could do >> there, so this can't really be an issue. >> >>> A year passes and you've installed an assortment of >>> additional apps and perhaps written some of your own. >> >> Upgrade to next Fedora. Gets easier each time around. A bit of foresight >> when installing originally helps much here. > > Precisely. The update or upgrades are essentially very simple to handle > when you've got a sane partitioning scheme setup. I _really_ have to believe that you haven't run fedora over any span of time across a variety of hardware with an assortment of additional software installed. > Anyone running Fedora (and especially anyone testing updates or rawhide) > that does not have their home on a separate partition is nuts (or new to > that concept). If you have /etc/ /root and /home where they can be > safely backed up and restored, then nuking your entire system for a > fresh install is a couple hours of work at best. > > I just fail to see how anyone interested in running Fedora at all cannot > find a few hours every 6 months to handle that. Some people might have better things to do - unless that's an offer to come over and do the upgrades for me if you really believe it's that easy. The problem is that upgrades do not go smoothly, and if yours have so far it is a matter of luck. I've had disk controller drivers missing or broken, firewire access wildly unpredictable, and after finding hardware to move to, still had to spend days tracking down corresponding driver modules, perl modules, installing java, etc. to get back to where I was before. Maybe it's just old fashioned, but I'd prefer that the computer work for me instead of the other way around. -- Les Mikesell lesmikesell at gmail.com From khc at pm.waw.pl Sat Jan 26 18:42:52 2008 From: khc at pm.waw.pl (Krzysztof Halasa) Date: Sat, 26 Jan 2008 19:42:52 +0100 Subject: long term support release In-Reply-To: <1201277589.17905.369.camel@beck.corsepiu.local> (Ralf Corsepius's message of "Fri\, 25 Jan 2008 17\:13\:09 +0100") References: <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <20080125103144.68eec1ff@redhat.com> <20080125153747.GB2975@free.fr> <20080125104307.382ce039@redhat.com> <20080125155059.GE2975@free.fr> <20080125155124.GA5809@orient.maison.lan> <479A0A55.60409@fedoraproject.org> <20080125160247.GA5952@orient.maison.lan> <1201277589.17905.369.camel@beck.corsepiu.local> Message-ID: Ralf Corsepius writes: > To me, Fedora has evolved into "unstable rawhide snapshots" while CentOS > is yesterday's stuff. The mid-ground is missing. I think a continously-updated Fedora is the thing. I.e. no new release every X months, just continuous updates (including things like Gnome/KDE/kernel upgrades). And perhaps a (minimal) snapshot every X months so a fresh bootstrap isn't a PITA. Like the current kernel model, comparing to the old one. -- Krzysztof Halasa From opensource at till.name Sat Jan 26 18:57:36 2008 From: opensource at till.name (Till Maas) Date: Sat, 26 Jan 2008 19:57:36 +0100 Subject: long term support release In-Reply-To: References: <1201249426.14800.19.camel@cutter> <1201277589.17905.369.camel@beck.corsepiu.local> Message-ID: <200801261957.41090.opensource@till.name> On Sat January 26 2008, Krzysztof Halasa wrote: > I think a continously-updated Fedora is the thing. I.e. no new release > every X months, just continuous updates (including things like > Gnome/KDE/kernel upgrades). And perhaps a (minimal) snapshot every X > months so a fresh bootstrap isn't a PITA. Afaik, there are sometimes changes that cannot be done within the running system. Also the new releases are useful whenever an update of a package requires manual intervention, because then this can be documented in the release notes and then there are no unpleasent surprises. And the update cycles also allow to be sure that some update-paths do not need to be supported anymore, e.g. when a conversion of a config file is needed and the latest release with the old config file is old enough, the code within the spec can be skipped. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From lesmikesell at gmail.com Sat Jan 26 19:02:34 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sat, 26 Jan 2008 13:02:34 -0600 Subject: Fedora Education Spin In-Reply-To: <479B4B6A.90805@when.com> References: <479B4B6A.90805@when.com> Message-ID: <479B83CA.8090301@gmail.com> sebastian at when.com wrote: > Hi, > > I have built a Fedora live cd with educational apps. The kickstart file > is here: http://fedoraproject.org/wiki/SebastianDziallas/Education > > Some feedback would be great, so maybe you could tell me, if you have > any suggestions or recommendations. > > And would it be possible, to make an official spin of it? > Are you aware of the k12ltsp distribution (http://k12ltsp.org/mediawiki/index.php/Main_Page) that has been built as a fedora respin with additional content up through FC6? I believe the plan going forward is to merge the packages into the fedora repo instead of rebuilding as a separately maintained distro. There is probably quite a lot of overlapping content (there are more additions than ltsp) and k12ltsp has a fairly large installed base so it might be worthwhile to combine efforts. -- Les Mikesell lesmikesell at gmail.com From sebastian at when.com Sat Jan 26 19:11:25 2008 From: sebastian at when.com (sebastian at when.com) Date: Sat, 26 Jan 2008 20:11:25 +0100 Subject: Fedora Education Spin In-Reply-To: <50baabb30801261000g690bfc40w80fdff6cca0efd35@mail.gmail.com> References: <479B4B6A.90805@when.com> <50baabb30801261000g690bfc40w80fdff6cca0efd35@mail.gmail.com> Message-ID: <479B85DD.5090406@when.com> Chitlesh GOORAH wrote: > I think for "Education" you are missing "kdeedu". I had it in my first spins, but it blew everything up... with its dependencies, it brought several hundred megabytes of data to the cd. > The kdeedu of KDE4 (in rawhide) has a wonderful collection of > applications for education. > I totally agree with you, there is really great software in kdeedu; I have also thought of including marble and kalgebra, which are already in Fedora 8... > Gcompris also is to my eyes a wonderful application and is attractive > to many educational institutions in Europe. Gcompris is also great - and big. It has not so many dependencies, but it has its audio files for quite a lot of languages. It would be the smaller problem... You see, what my problem is: I think even a switch from Gnome to Xfce would not give me enough free space, to include all the software I would like to include. I had created a Xfce based test cd, but after having included GCompris, there was no further space available. I think, a possible solution would be, to kick out some other tools (like firefox and totem, but I think this would not be enough...) - or, to create a dvd... Thanks for your suggestions ;) - I will create some further builds and have a look at this... Sebastian From sundaram at fedoraproject.org Sat Jan 26 19:24:58 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 27 Jan 2008 00:54:58 +0530 Subject: Fedora Education Spin In-Reply-To: <479B85DD.5090406@when.com> References: <479B4B6A.90805@when.com> <50baabb30801261000g690bfc40w80fdff6cca0efd35@mail.gmail.com> <479B85DD.5090406@when.com> Message-ID: <479B890A.3030903@fedoraproject.org> sebastian at when.com wrote: > > You see, what my problem is: I think even a switch from Gnome to Xfce > would not give me enough free space, to include all the software I would > like to include. I had created a Xfce based test cd, but after having > included GCompris, there was no further space available. I think, a > possible solution would be, to kick out some other tools (like firefox > and totem, but I think this would not be enough...) - or, to create a > dvd... It is possible to file requests against specific packages to split them up further or drop unneeded dependencies. The audio files for gcompris could be split up for example. Rahul From sebastian at when.com Sat Jan 26 19:31:43 2008 From: sebastian at when.com (sebastian at when.com) Date: Sat, 26 Jan 2008 20:31:43 +0100 Subject: Fedora Education Spin In-Reply-To: <479B83CA.8090301@gmail.com> References: <479B4B6A.90805@when.com> <479B83CA.8090301@gmail.com> Message-ID: <479B8A9F.4020505@when.com> Les Mikesell wrote: > Are you aware of the k12ltsp distribution > (http://k12ltsp.org/mediawiki/index.php/Main_Page) that has been built > as a fedora respin with additional content up through FC6? I believe > the plan going forward is to merge the packages into the fedora repo > instead of rebuilding as a separately maintained distro. There is > probably quite a lot of overlapping content (there are more additions > than ltsp) and k12ltsp has a fairly large installed base so it might > be worthwhile to combine efforts. Well, sounds good ;)... I haven't tracked the development of k12ltsp, yet. But I agree, there is somehow overlapping content and combining efforts does not sound bad... Sebastian From lesmikesell at gmail.com Sat Jan 26 19:43:24 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sat, 26 Jan 2008 13:43:24 -0600 Subject: long term support release In-Reply-To: <1c252d490801260346r753734d9mb6038e1d3fa34449@mail.gmail.com> References: <1201249426.14800.19.camel@cutter> <20080125093517.GA16080@free.fr> <20080125103144.68eec1ff@redhat.com> <20080125153747.GB2975@free.fr> <20080125104307.382ce039@redhat.com> <20080125155059.GE2975@free.fr> <20080125155124.GA5809@orient.maison.lan> <479A0A55.60409@fedoraproject.org> <20080125160247.GA5952@orient.maison.lan> <1201277589.17905.369.camel@beck.corsepiu.local> <1c252d490801260346r753734d9mb6038e1d3fa34449@mail.gmail.com> Message-ID: <479B8D5C.4090203@gmail.com> Joachim Frieben wrote: > On Jan 25, 2008 5:13 PM, Ralf Corsepius wrote: > >> Do you want current packages or do you want the 3 year versions in RHEL? >> >> Ralf > > > Why would you have to use 3 year old package versions when the RHEL release > cycle is 18 months? Honestly speaking, for people interested in actually > using an OS to get some real -work- done instead of seeking a life on the > bleeding edge for their own thrill, RHEL5 and respins of it are very well > usable. Things are never that simple. It's easy to say you should use an enterprise version if you want to run some service for years - and hindsight is easy when someone gets that wrong. However when you are setting up something new you don't know if you'll want the same thing next week let alone years from now. So you start with fedora to have the latest tools, build something than happens to work nicely, then the security updates end. Or, the other way around, you start with a stale distro for stability but soon need a feature that is missing. There are thousands of programs involved in a distribution and you have to change them all and deal with an assortment of incompatible differences to get the one little thing you needed. > The Fedora user community is much more biased towards software > enthousiasts and early adopters, and in general, they wouldn't even stick to > Fedora release N after release N+1 has been readied 6 months later. > Accordingly, I would expect the interest of LTS for this group to be rather > limited. If you think Fedora users should be limited to people that have some particular interest in fedora rather than anyone being able to use it as a generally usable OS, that view makes sense, but I'd rather have the latter. As a case in point, consider the situation of k12ltsp users. K12ltsp is a fedora respin that includes the ltsp package configured to boot thin clients 'out of the box' and some additional packages and it is widely used in school classrooms and labs. The last fedora-based build is from FC6 and the people running them have just noticed that they aren't getting security updates anymore - probably a very bad thing in a hostile environment like a classroom. There is an alternative built on Centos5, but these are people with better things to do than rebuild their classroom infrastructure with the associated risks mid-year. While they probably should have known what to expect, I think the fedora-based version was released before the centos one, so for a certain time window (and probably the one that matters for schools) the decision on what to install would have involved the feature differences between FC6 and CentOS4 which are fairly large. -- Les Mikesell lesmikesell at gmail.com From jspaleta at gmail.com Sat Jan 26 19:45:01 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 26 Jan 2008 10:45:01 -0900 Subject: Fedora Education Spin In-Reply-To: <479B83CA.8090301@gmail.com> References: <479B4B6A.90805@when.com> <479B83CA.8090301@gmail.com> Message-ID: <604aa7910801261145n74ee9cbcj51926455ebf55861@mail.gmail.com> On Jan 26, 2008 10:02 AM, Les Mikesell wrote: > There is probably quite a lot of overlapping content (there are more additions > than ltsp) and k12ltsp has a fairly large installed base so it might be > worthwhile to combine efforts. I would encourage this. If Sebastian can take his spin work and collaborate with k12ltsp to produce something with them, then I think we have a much stronger team effort going forward. That being said, its pefectly okay to experiment with a cd and a DVD spin, and then we'll figure out how to make them better. Speaking of which, you know what would be cool... for some spins that we know are in the half-baked phase, it would be cool if there was an icon on the desktop that basically sent the spin user to a feedback questioniare about the spin. So we can get feedback from people who..took it for a spin..but don't plan to keep using it. I'll make a mental note to myself to remember to bring that up with people who could possibly make that possible. I need to get my head around everyone attempting to do something as part of Fedora in the 'educational' space. I know warren is driving technical packaging bits so we can get k12ltsp in to the distro (and I've failed to help there), but outside of that I'd like to hear about people attempting to make use of Fedora in any educational situation. For example learning more about Chitlesh's booth at 'Science Days' would be interesting. -jef From bruno at wolff.to Sat Jan 26 19:57:16 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Sat, 26 Jan 2008 13:57:16 -0600 Subject: long term support release In-Reply-To: <479A2416.7010904@gmail.com> References: <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> <20080125152614.GA2975@free.fr> <20080125103335.0d5adacf@redhat.com> <20080125154127.GC2975@free.fr> <1201275741.1163.1.camel@localhost.localdomain> <20080125154749.GD2975@free.fr> <20080125105041.6605e470@redhat.com> <479A10D0.7020301@gmail.com> <200801251709.m0PH9iV5015900@laptop13.inf.utfsm.cl> <479A2416.7010904@gmail.com> Message-ID: <20080126195716.GA25387@wolff.to> On Fri, Jan 25, 2008 at 12:01:58 -0600, Les Mikesell wrote: > > What do you mean 'lack of care'? I buy hardware based on price and > capability, then pick an OS that will run on it. I can't afford to do > it the other way around. That seems like an odd way to do things. Normally one starts with apps, then OS, then hardware. Even for the cost conscious, the extra cost of buying hardware that will work versus what won't is very minimal. There are issues related to this. Finding out what hardware works can be a pain. There are regressions, so that you can buy hardware that worked with the current version when you bought it, that stops working (at least for a while) with updates or worse later versions. From bruno at wolff.to Sat Jan 26 20:14:38 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Sat, 26 Jan 2008 14:14:38 -0600 Subject: Fedora Education Spin In-Reply-To: <479B83CA.8090301@gmail.com> References: <479B4B6A.90805@when.com> <479B83CA.8090301@gmail.com> Message-ID: <20080126201438.GC25387@wolff.to> On Sat, Jan 26, 2008 at 13:02:34 -0600, Les Mikesell wrote: > > Are you aware of the k12ltsp distribution > (http://k12ltsp.org/mediawiki/index.php/Main_Page) that has been built > as a fedora respin with additional content up through FC6? I believe > the plan going forward is to merge the packages into the fedora repo > instead of rebuilding as a separately maintained distro. There is > probably quite a lot of overlapping content (there are more additions > than ltsp) and k12ltsp has a fairly large installed base so it might be > worthwhile to combine efforts. http://fedoraproject.org/wiki/Features/K12Linux From jspaleta at gmail.com Sat Jan 26 20:15:37 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 26 Jan 2008 11:15:37 -0900 Subject: long term support release In-Reply-To: References: <1201058211.3001.79.camel@gandalf.cobite.com> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> <1201251592.17905.255.camel@beck.corsepiu.local> <80d7e4090801251033s1fce270akfcf6a73e882b0236@mail.gmail.com> <1201329869.17905.554.camel@beck.corsepiu.local> Message-ID: <604aa7910801261215u10c4e3dbxea2bd4e125975eb6@mail.gmail.com> On Jan 26, 2008 7:35 AM, Jon Stanley wrote: > I came to Fedora to do bug triage. I *very* quickly realized that > there was a lack of a viable triage group within Fedora. Therefore, I > complained. It went to FAB, where everyone agreed that there was lack > of leadership in this area, so I volunteered to step up to the plate. > This is the part that you're lacking, Ralf. I started to build a > community around the problem, and while there is a lot of work yet to > be done in order to say I've been even somewhat successful, it's well > on it's way. Triage is my secret shame. If you run into some sort of roadblock internally, or if you need someone taken out back and shot in order to keep forward momentum with triage... just ping me. -jef From bruno at wolff.to Sat Jan 26 20:16:37 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Sat, 26 Jan 2008 14:16:37 -0600 Subject: Is there a gdmsetup replacement yet for rawhide? Message-ID: <20080126201637.GD25387@wolff.to> I noticed that gdmsetup has gone away in rawhide, but I haven't been able to find its replacement yet. Can someone provide some guidance here? From lesmikesell at gmail.com Sat Jan 26 20:30:12 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sat, 26 Jan 2008 14:30:12 -0600 Subject: long term support release In-Reply-To: <20080126195716.GA25387@wolff.to> References: <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> <20080125152614.GA2975@free.fr> <20080125103335.0d5adacf@redhat.com> <20080125154127.GC2975@free.fr> <1201275741.1163.1.camel@localhost.localdomain> <20080125154749.GD2975@free.fr> <20080125105041.6605e470@redhat.com> <479A10D0.7020301@gmail.com> <200801251709.m0PH9iV5015900@laptop13.inf.utfsm.cl> <479A2416.7010904@gmail.com> <20080126195716.GA25387@wolff.to> Message-ID: <479B9854.9040304@gmail.com> Bruno Wolff III wrote: >> What do you mean 'lack of care'? I buy hardware based on price and >> capability, then pick an OS that will run on it. I can't afford to do >> it the other way around. > > That seems like an odd way to do things. Normally one starts with apps, > then OS, then hardware. Even for the cost conscious, the extra cost of > buying hardware that will work versus what won't is very minimal. Most hardware these days comes with a working OS and most apps can be built to run under all of the popular OS's. If fedora can't run as well or better, I just don't run fedora on it. The OS is generally the least interesting part of the equation. > There are issues related to this. Finding out what hardware works can be a > pain. There are regressions, so that you can buy hardware that worked > with the current version when you bought it, that stops working (at least > for a while) with updates or worse later versions. Yes, an OS that changes every few months isn't the place to start your long term decisions. -- Les Mikesell lesmikesell at gmail.com From markg85 at gmail.com Sat Jan 26 20:43:34 2008 From: markg85 at gmail.com (Mark) Date: Sat, 26 Jan 2008 21:43:34 +0100 Subject: Is there a gdmsetup replacement yet for rawhide? In-Reply-To: <20080126201637.GD25387@wolff.to> References: <20080126201637.GD25387@wolff.to> Message-ID: <6e24a8e80801261243k6ad00b6dr63eca34a1e3d6a8d@mail.gmail.com> 2008/1/26, Bruno Wolff III : > I noticed that gdmsetup has gone away in rawhide, but I haven't been > able to find its replacement yet. Can someone provide some guidance here? > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list I'm wondering the exact same thing. And the theme possibility of the new gdm in rawhide... From smooge at gmail.com Sat Jan 26 20:51:43 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Sat, 26 Jan 2008 13:51:43 -0700 Subject: long term support release In-Reply-To: <20080126081343.GA9229@jasmine.xos.nl> References: <1201240697.17905.179.camel@beck.corsepiu.local> <479A0A55.60409@fedoraproject.org> <1201277129.14800.25.camel@cutter> <200801251127.47467.jwilson@redhat.com> <1201278927.17905.382.camel@beck.corsepiu.local> <20080125195136.02a98f3d@redhat.com> <20080126081343.GA9229@jasmine.xos.nl> Message-ID: <80d7e4090801261251o4d08cefj217e18842f680357@mail.gmail.com> On Jan 26, 2008 1:13 AM, Jos Vos wrote: > On Fri, Jan 25, 2008 at 07:51:36PM -0500, Jesse Keating wrote: > > > Ralf Corsepius wrote: > > > > > The trick would be RH to freely release RHEL instead of forcing others > > > to recompile packages, such these guys can contribute to EPEL instead > > > of having to waste their time and resources on rebuilding. > > > > No disagreement here. > > They don't even need to release "RHEL", but only the packages except > for the trademark packages (images etc.), so that Fedora can simply > create a distro out of it. > > > > Havig said that, in the past I have heard RH people saying that they > don't understand why people are rebuilding the binaries (except > trademark packages etc. of course), as they (the single packages, > not RHEL as a "composition") may be distributed freely. > The issues usually come down to how many packages are covered by the trademark. CentOS has to make a lot patches to take out trademarks in documentation, programs etc... and even after spending 2 weeks on 5.0... we missed 10 or so packages. Then there are various things that are 'broken' if you don't use the RHN system (that was one or two issues). There is also the fact that RHEL sometimes doesn't supply all the packages from an RPM (this was much the case in 2 and 3, less than 4 & 5). Finally RH uses hidden build flags which have to be found out to get a package to match that.. which of course gets people wondering why they do it on this package etc which gets either conspiracy talking or people who will rebuild the package until they get a match. > Either this is not true, or nobody has ever done the work to find > this out in detail. > > > > -- > -- Jos Vos > -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 > -- Amsterdam, The Netherlands | Fax: +31 20 6948204 > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From kmaraas at broadpark.no Sat Jan 26 21:00:10 2008 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Sat, 26 Jan 2008 22:00:10 +0100 Subject: Is there a gdmsetup replacement yet for rawhide? In-Reply-To: <6e24a8e80801261243k6ad00b6dr63eca34a1e3d6a8d@mail.gmail.com> References: <20080126201637.GD25387@wolff.to> <6e24a8e80801261243k6ad00b6dr63eca34a1e3d6a8d@mail.gmail.com> Message-ID: <1201381210.2765.1.camel@localhost.localdomain> l?., 26.01.2008 kl. 21.43 +0100, skrev Mark: > 2008/1/26, Bruno Wolff III : > > I noticed that gdmsetup has gone away in rawhide, but I haven't been > > able to find its replacement yet. Can someone provide some guidance here? > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > I'm wondering the exact same thing. > And the theme possibility of the new gdm in rawhide... > Please look here: http://live.gnome.org/GDM/NewDesign and here ?http://live.gnome.org/GDM/ToDo Cheers Kjartan From mclasen at redhat.com Sat Jan 26 21:26:55 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Sat, 26 Jan 2008 16:26:55 -0500 Subject: Is there a gdmsetup replacement yet for rawhide? In-Reply-To: <20080126201637.GD25387@wolff.to> References: <20080126201637.GD25387@wolff.to> Message-ID: <1201382815.2940.5.camel@localhost.localdomain> On Sat, 2008-01-26 at 14:16 -0600, Bruno Wolff III wrote: > I noticed that gdmsetup has gone away in rawhide, but I haven't been > able to find its replacement yet. Can someone provide some guidance here? There is no replacement yet. What particular configuration were you looking for ? From jwilson at redhat.com Sat Jan 26 21:31:00 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Sat, 26 Jan 2008 16:31:00 -0500 Subject: blacklisted iwl4965 ?? In-Reply-To: <20080126091755.GG7607@puariko.nirvana> References: <20080118080211.GM29887@angus.ind.WPI.EDU> <1200887683.10357.46.camel@raven.themaw.net> <20080126091755.GG7607@puariko.nirvana> Message-ID: <200801261631.00323.jwilson@redhat.com> On Saturday 26 January 2008 04:17:55 am Axel Thimm wrote: > On Mon, Jan 21, 2008 at 12:54:43PM +0900, Ian Kent wrote: > > On Sat, 2008-01-19 at 10:40 +0200, Axel Thimm wrote: > > > On Fri, Jan 18, 2008 at 03:02:11AM -0500, Chuck Anderson wrote: > > > > I just did a fresh rawhide install and found this in > > > > /etc/modprobe.d/blacklist: > > > > > > > > # don't load iwl4965 by default, bug 245379 > > > > blacklist iwl4965 > > > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=245379 > > > > > > > > Does someone have any better explanation for this than the 6+ month > > > > old bug report for RHEL 5? What are us iwl4965 users supposed to be > > > > using? Odd, I've been using the kernel-rpm-provided iwl4965 without a problem on my laptop for quite a while... Including w/my current 2.6.24-3.fc9 kernel... -- Jarod Wilson jwilson at redhat.com From myfedora at richip.dhs.org Sat Jan 26 21:52:12 2008 From: myfedora at richip.dhs.org (Richi Plana) Date: Sat, 26 Jan 2008 14:52:12 -0700 Subject: Package Versioning Feedback Message-ID: <1201384332.32282.16.camel@localhost6.localdomain6> Hi, I wanted to start my own little project and wanted some feedback from the community who've had much dealings with versioning. My plan is to use a versioning system similar to most (digits separated by a dot character) with each successive number being less significant. The only change in semantics is that the most minor number would be interpreted as 0 = Alpha 1 = Beta 3+ = Stable I thought this might be a better way of dealing with projects which transition to a greater major number. Systems which use .99+ to designate "almost next major" aren't easy to test as the next major version (since the computer parses the major version and sees the previous major version. Some systems increase the major and tack on the word "alpha" or "beta" ... which screws up the computer's sorting mechanism (is alpha > 0?) My question is: will there be any problems with packaging systems like rpm and yum using such a scheme? -- Richi Plana From lordmorgul at gmail.com Sat Jan 26 21:59:27 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sat, 26 Jan 2008 13:59:27 -0800 Subject: long term support release In-Reply-To: <479B7751.4050503@gmail.com> References: <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> <20080125152614.GA2975@free.fr> <20080125103335.0d5adacf@redhat.com> <20080125154127.GC2975@free.fr> <1201275741.1163.1.camel@localhost.localdomain> <20080125154749.GD2975@free.fr> <20080125105041.6605e470@redhat.com> <479A10D0.7020301@gmail.com> <200801251709.m0PH9iV5015900@laptop13.inf.utfsm.cl> <479B29B2.1070407@gmail.com> <479B7751.4050503@gmail.com> Message-ID: <479BAD3F.7060700@gmail.com> Les Mikesell wrote: > Andrew Farris wrote: >>> I was perfectly happy with RH 6.2, and most of what I do now I could do >>> there, so this can't really be an issue. >>> >>>> A year passes and you've installed an assortment of >>>> additional apps and perhaps written some of your own. >>> >>> Upgrade to next Fedora. Gets easier each time around. A bit of foresight >>> when installing originally helps much here. >> >> Precisely. The update or upgrades are essentially very simple to >> handle when you've got a sane partitioning scheme setup. > > I _really_ have to believe that you haven't run fedora over any span of > time across a variety of hardware with an assortment of additional > software installed. Only since Fedora existed, on 4 machines (2 portables) and virtual machines. I'm well aware that there have been hardware issues, but I've never found them to be completely unresolvable, and usually get attention very rapidly when you report them adequately. I've had machines updating rawhide since FC1... one of them not being actually formatted from FC2->FC8, with a moving target of hardare in the machine. You can believe what you wish. The upgrade paths always end up working (with workarounds...) when the issues get reported. >> Anyone running Fedora (and especially anyone testing updates or >> rawhide) that does not have their home on a separate partition is nuts >> (or new to that concept). If you have /etc/ /root and /home where >> they can be safely backed up and restored, then nuking your entire >> system for a fresh install is a couple hours of work at best. >> >> I just fail to see how anyone interested in running Fedora at all >> cannot find a few hours every 6 months to handle that. > > Some people might have better things to do - unless that's an offer to > come over and do the upgrades for me if you really believe it's that > easy. The problem is that upgrades do not go smoothly, and if yours > have so far it is a matter of luck. I've had disk controller drivers > missing or broken, firewire access wildly unpredictable, and after > finding hardware to move to, still had to spend days tracking down > corresponding driver modules, perl modules, installing java, etc. to get > back to where I was before. > > Maybe it's just old fashioned, but I'd prefer that the computer work for > me instead of the other way around. Apparently better things to do includes not taking the steps to smooth out eventual problems. Computers are tools that work for you as hard as you work for them. They do not just work. This will never change until they are working at improving themselves and we are not even involved in the process. -- Andrew Farris www.lordmorgul.net gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From lmacken at redhat.com Sat Jan 26 22:05:23 2008 From: lmacken at redhat.com (Luke Macken) Date: Sat, 26 Jan 2008 17:05:23 -0500 Subject: F9 Alpha spinning In-Reply-To: <20080125162835.GA19048@crow> References: <20080125162835.GA19048@crow> Message-ID: <20080126220523.GA3054@crow> Here are some stats of todays re-spin against the latest f9-alpha bits and livecd configs. It looks like our desktop spin lost 2mb overnight, while everything else got bigger. In the diff below, I also include a list of packages that have shrunk since F8. -rw-r--r-- 1 root root 1.6G 2008-01-26 02:28 F9-Alpha-Developer-20080126.0.iso -rw-r--r-- 1 root root 767M 2008-01-26 02:42 F9-Alpha-FEL-i686-20080126.0.iso -rw-r--r-- 1 root root 4.0G 2008-01-26 15:25 F9-Alpha-games-i686-20080126.0.iso -rw-r--r-- 1 root root 712M 2008-01-26 01:18 F9-Alpha-i686-20080126.0.iso -rw-r--r-- 1 root root 688M 2008-01-26 01:46 F9-Alpha-KDE-i686-20080126.0.iso -rw-r--r-- 1 root root 801M 2008-01-26 02:02 F9-Alpha-KDE-x86_64-20080126.0.iso -rw-r--r-- 1 root root 768M 2008-01-26 01:35 F9-Alpha-x86_64-20080126.0.iso F8-Live-i686 has 896 packages F9-Alpha-i686 has 908 packages new package libgdiplus-devel: 8584 new package xorg-x11-server-common: 38863 new package PolicyKit-gnome-libs: 40188 new package kerneloops: 52570 new package swfdec-gtk: 55786 new package gnome-panel-libs: 56936 new package swfdec-mozilla: 75911 new package libconfig: 120055 new package obex-data-server: 136538 new package at-spi-python: 170868 new package ncurses-base: 176949 new package pixman: 209556 new package scim-python: 247730 new package libcurl: 258148 new package libggz: 289477 new package hfsutils: 362228 new package libmtp: 398952 new package xorg-x11-drv-openchrome: 415754 new package ggz-client-libs: 434830 new package samyak-fonts: 457144 new package perl-Date-Manip: 458629 new package libtasn1: 466849 new package python-crypto: 571535 new package elilo: 613010 new package abyssinica-fonts: 649794 new package gfs2-utils: 650707 new package ncurses-libs: 668620 new package swfdec: 958169 new package reiserfs-utils: 1022402 new package iscsi-initiator-utils: 1138529 new package jfsutils: 1138726 new package gvfs: 1700127 new package totem-pl-parser: 2627745 new package xfsprogs: 3408051 new package VLGothic-fonts: 3831447 new package VLGothic-fonts-proportional: 3831790 new package gnome-settings-daemon: 6218660 new package mesa-libOSMesa: 7248256 new package scim-python-chinese: 7621164 new package libgweather: 14592282 new package dejavu-fonts: 15593008 new package vim-common: 16294034 new package xulrunner: 24481155 ================================================================================ crontabs grew 144 bytes (6.83%) (2107->2251) libopenraw-gnome grew 348 bytes (7.94%) (4384->4732) xorg-x11-drv-fbdev grew 380 bytes (1.84%) (20597->20977) irqbalance grew 400 bytes (1.85%) (21595->21995) m17n-contrib grew 469 bytes (1.28%) (36757->37226) pam_ccreds grew 497 bytes (1.49%) (33428->33925) smolt-firstboot grew 655 bytes (6.01%) (10893->11548) pcsc-lite-libs grew 848 bytes (2.44%) (34696->35544) dbus-x11 grew 884 bytes (3.63%) (24353->25237) numactl grew 896 bytes (1.00%) (89239->90135) gnome-bluetooth-libs grew 1278 bytes (1.02%) (124866->126144) xorg-x11-drv-evdev grew 1445 bytes (4.05%) (35642->37087) m17n-db-hindi grew 1717 bytes (21.74%) (7899->9616) sysreport grew 1783 bytes (5.30%) (33620->35403) libpciaccess grew 1796 bytes (7.21%) (24901->26697) sg3_utils-libs grew 2156 bytes (1.97%) (109392->111548) pciutils grew 2464 bytes (1.36%) (180975->183439) setroubleshoot grew 2541 bytes (1.11%) (229578->232119) gnome-keyring-pam grew 2556 bytes (8.89%) (28760->31316) libcap grew 2618 bytes (5.79%) (45230->47848) apr grew 2823 bytes (1.04%) (271801->274624) bc grew 2861 bytes (1.50%) (190964->193825) libsepol grew 2992 bytes (1.33%) (224692->227684) lohit-fonts-telugu grew 3100 bytes (1.78%) (174487->177587) e2fsprogs-libs grew 3332 bytes (1.33%) (250016->253348) device-mapper-libs grew 3680 bytes (4.25%) (86516->90196) glx-utils grew 3704 bytes (10.98%) (33736->37440) scim-chewing grew 4072 bytes (3.22%) (126383->130455) dbus-libs grew 4100 bytes (1.63%) (251944->256044) nash grew 4128 bytes (1.74%) (237698->241826) scim-sinhala grew 4140 bytes (6.19%) (66881->71021) libjpeg grew 4420 bytes (1.61%) (275021->279441) authconfig-gtk grew 4808 bytes (2.75%) (175143->179951) mkinitrd grew 4854 bytes (4.84%) (100334->105188) m17n-contrib-sinhala grew 5443 bytes (48.05%) (11327->16770) linuxwacom grew 5518 bytes (1.10%) (502293->507811) desktop-file-utils grew 5523 bytes (4.50%) (122601->128124) gnome-python2-gnomeprint grew 5547 bytes (1.27%) (437641->443188) bluez-utils-alsa grew 5856 bytes (13.67%) (42824->48680) m17n-contrib-telugu grew 6114 bytes (28.08%) (21776->27890) rsyslog grew 6922 bytes (1.45%) (477587->484509) ustr grew 7531 bytes (3.12%) (241610->249141) rhpxl grew 7783 bytes (2.36%) (329907->337690) xorg-x11-drv-mga grew 8319 bytes (4.91%) (169473->177792) taglib grew 8368 bytes (1.71%) (489415->497783) gtk-nodoka-engine grew 8948 bytes (9.32%) (96057->105005) nscd grew 9484 bytes (6.73%) (140911->150395) exempi grew 9692 bytes (1.39%) (698782->708474) gnome-menus grew 9841 bytes (1.57%) (626493->636334) dbus-glib grew 9970 bytes (2.10%) (473790->483760) libdhcp6client grew 10524 bytes (6.30%) (166956->177480) openldap grew 10658 bytes (1.76%) (604986->615644) nss_ldap grew 12224 bytes (2.17%) (562402->574626) dmidecode grew 14466 bytes (10.46%) (138266->152732) NetworkManager-vpnc grew 14477 bytes (4.58%) (316033->330510) system-config-rootpassword grew 14962 bytes (16.07%) (93118->108080) gstreamer-python grew 15266 bytes (1.64%) (933175->948441) rarian grew 15824 bytes (4.99%) (316947->332771) at-spi grew 16072 bytes (2.38%) (674624->690696) isomd5sum grew 17146 bytes (36.61%) (46840->63986) usbutils grew 17192 bytes (19.31%) (89044->106236) acl grew 17907 bytes (11.99%) (149361->167268) hicolor-icon-theme grew 17992 bytes (79.30%) (22688->40680) gnome-python2-desktop grew 18187 bytes (7.44%) (244527->262714) libdhcp grew 19318 bytes (14.23%) (135727->155045) which grew 20480 bytes (65.05%) (31485->51965) NetworkManager-gnome grew 20604 bytes (2.90%) (710665->731269) pam_krb5 grew 20943 bytes (8.06%) (259736->280679) system-config-language grew 21674 bytes (8.55%) (253576->275250) libxcb grew 22328 bytes (5.40%) (413804->436132) bluez-utils grew 22572 bytes (1.76%) (1280277->1302849) pygtksourceview grew 23100 bytes (36.06%) (64064->87164) libgpg-error grew 23525 bytes (12.14%) (193728->217253) glibmm24 grew 24411 bytes (5.25%) (465396->489807) fribidi grew 24912 bytes (17.19%) (144894->169806) gmime grew 24916 bytes (4.24%) (587824->612740) libuser grew 25215 bytes (1.56%) (1616562->1641777) xterm grew 25999 bytes (3.24%) (802644->828643) httpd grew 28595 bytes (1.12%) (2551734->2580329) libdhcp4client grew 28996 bytes (5.81%) (499144->528140) m17n-lib grew 30893 bytes (10.14%) (304750->335643) rhpl grew 31037 bytes (3.99%) (778235->809272) bind-utils grew 33408 bytes (10.87%) (307362->340770) NetworkManager grew 33657 bytes (1.42%) (2377366->2411023) dbus-python grew 36266 bytes (5.11%) (710089->746355) gnome-mag grew 36431 bytes (7.21%) (504936->541367) libXpm grew 37746 bytes (52.09%) (72467->110213) libgnomekbd grew 38042 bytes (6.68%) (569521->607563) pm-utils grew 39200 bytes (117.36%) (33402->72602) nautilus-sendto grew 42489 bytes (16.21%) (262118->304607) dhclient grew 42699 bytes (8.59%) (497288->539987) gtksourceview2 grew 42895 bytes (2.00%) (2148753->2191648) krb5-libs grew 45052 bytes (2.96%) (1522532->1567584) system-config-printer grew 56236 bytes (5.99%) (939482->995718) gnutls grew 58282 bytes (5.99%) (972804->1031086) libthai grew 60142 bytes (17.40%) (345628->405770) bluez-gnome grew 60576 bytes (22.56%) (268531->329107) mono-data grew 61605 bytes (1.21%) (5087435->5149040) libwnck grew 62234 bytes (5.42%) (1148126->1210360) gtk2-engines grew 63679 bytes (6.09%) (1045391->1109070) system-config-users grew 64047 bytes (4.40%) (1455495->1519542) gnokii grew 68723 bytes (4.36%) (1575916->1644639) rsync grew 73058 bytes (18.04%) (404896->477954) hal-info grew 75029 bytes (20.94%) (358305->433334) mesa-libGLU grew 77812 bytes (17.12%) (454428->532240) mdadm grew 83417 bytes (4.79%) (1743098->1826515) shared-mime-info grew 85852 bytes (9.51%) (902332->988184) compiz-gnome grew 87904 bytes (7.16%) (1227682->1315586) PolicyKit-gnome grew 89123 bytes (126.49%) (70457->159580) GConf2 grew 89585 bytes (1.68%) (5342705->5432290) dhcpv6-client grew 94965 bytes (54.70%) (173599->268564) system-config-firewall grew 103528 bytes (4.50%) (2300495->2404023) ntfs-3g grew 107185 bytes (36.31%) (295187->402372) f-spot grew 110065 bytes (1.44%) (7621883->7731948) PolicyKit grew 121200 bytes (71.93%) (168495->289695) gnupg grew 126829 bytes (2.62%) (4841029->4967858) libgcrypt grew 132376 bytes (38.24%) (346204->478580) libopenraw grew 136838 bytes (101.68%) (134583->271421) pykickstart grew 141694 bytes (17.92%) (790784->932478) gnome-python2-gnomevfs grew 142165 bytes (87.24%) (162958->305123) hwdata grew 144093 bytes (15.63%) (921699->1065792) shadow-utils grew 144973 bytes (5.29%) (2739389->2884362) gnome-volume-manager grew 158480 bytes (7.38%) (2146417->2304897) vbetool grew 162208 bytes (139.43%) (116340->278548) openssl grew 166448 bytes (4.81%) (3459831->3626279) libselinux-python grew 171323 bytes (118.46%) (144622->315945) libsilc grew 180620 bytes (17.41%) (1037560->1218180) sound-juicer grew 182617 bytes (5.86%) (3114050->3296667) gnome-system-monitor grew 186353 bytes (3.55%) (5244840->5431193) gdb grew 193437 bytes (3.11%) (6228176->6421613) evolution-data-server grew 208724 bytes (1.89%) (11029422->11238146) PyOpenGL grew 213779 bytes (4.86%) (4398157->4611936) tomboy grew 218900 bytes (3.63%) (6022535->6241435) parted grew 223507 bytes (15.16%) (1474368->1697875) selinux-policy-devel grew 229206 bytes (4.15%) (5522257->5751463) orca grew 231344 bytes (4.05%) (5718621->5949965) util-linux-ng grew 245524 bytes (5.17%) (4749959->4995483) iso-codes grew 269192 bytes (4.80%) (5605136->5874328) system-config-date grew 282500 bytes (10.09%) (2798572->3081072) xorg-x11-drv-ati grew 285328 bytes (35.75%) (798151->1083479) selinux-policy grew 292154 bytes (3.79%) (7707834->7999988) eog grew 292326 bytes (7.82%) (3740424->4032750) dbus grew 299134 bytes (58.75%) (509123->808257) totem grew 321458 bytes (5.87%) (5476956->5798414) gnome-keyring grew 333541 bytes (32.87%) (1014819->1348360) glibc grew 347221 bytes (2.59%) (13402107->13749328) sqlite grew 358672 bytes (76.12%) (471170->829842) setroubleshoot-server grew 363273 bytes (22.18%) (1637732->2001005) bind-libs grew 389872 bytes (17.27%) (2258064->2647936) gcalctool grew 496578 bytes (10.21%) (4862745->5359323) gnome-panel grew 509960 bytes (4.35%) (11714901->12224861) gutenprint grew 664813 bytes (15.07%) (4410340->5075153) rhythmbox grew 678314 bytes (6.41%) (10582223->11260537) mono-core grew 686301 bytes (2.01%) (34154946->34841247) nautilus grew 693197 bytes (5.04%) (13751211->14444408) mono-winforms grew 729754 bytes (7.47%) (9765822->10495576) liberation-fonts grew 767468 bytes (69.95%) (1097162->1864630) totem-mozplugin grew 770229 bytes (136.17%) (565632->1335861) mono-web grew 797665 bytes (9.85%) (8097242->8894907) glib2 grew 849381 bytes (29.07%) (2922173->3771554) gnome-power-manager grew 934030 bytes (8.33%) (11214535->12148565) nss grew 937664 bytes (44.33%) (2114975->3052639) libsmbclient grew 1191360 bytes (50.53%) (2357736->3549096) gnome-games grew 1373569 bytes (4.65%) (29510057->30883626) kernel grew 2268304 bytes (4.82%) (47063671->49331975) gutenprint-foomatic grew 2393009 bytes (5.05%) (47405319->49798328) anaconda grew 2579101 bytes (17.85%) (14448198->17027299) ================================================================================ libtirpc shrunk 1 bytes (150301->150300) krb5-auth-dialog shrunk 1 bytes (53674->53673) gmime-sharp shrunk 6 bytes (197336->197330) gzip shrunk 6 bytes (219689->219683) gedit shrunk 8 bytes (13487572->13487564) system-config-network shrunk 8 bytes (1905298->1905290) perl shrunk 14 bytes (31645884->31645870) ntsysv shrunk 16 bytes (22156->22140) pavucontrol shrunk 23 bytes (169857->169834) libXfont shrunk 32 bytes (456948->456916) gnome-python2-canvas shrunk 32 bytes (48902->48870) xorg-x11-drv-vmmouse shrunk 32 bytes (16364->16332) mono-data-sqlite shrunk 33 bytes (457296->457263) groff shrunk 35 bytes (5390470->5390435) gnome-pilot shrunk 36 bytes (1930958->1930922) libflashsupport shrunk 40 bytes (11044->11004) nautilus-extensions shrunk 48 bytes (31308->31260) pulseaudio-utils shrunk 56 bytes (234499->234443) libselinux shrunk 61 bytes (148311->148250) gimp shrunk 64 bytes (38423455->38423391) libXrender shrunk 64 bytes (47254->47190) paps shrunk 64 bytes (51462->51398) pwlib shrunk 88 bytes (2423701->2423613) libxkbfile shrunk 96 bytes (146358->146262) librsvg2 shrunk 120 bytes (337750->337630) pulseaudio-libs shrunk 128 bytes (343843->343715) isdn4k-utils shrunk 144 bytes (9789025->9788881) less shrunk 171 bytes (176124->175953) urw-fonts shrunk 172 bytes (4389572->4389400) xorg-x11-drv-keyboard shrunk 256 bytes (26608->26352) anacron shrunk 274 bytes (56515->56241) libgtop2 shrunk 320 bytes (341012->340692) xorg-x11-drv-cirrus shrunk 355 bytes (77986->77631) cups-libs shrunk 356 bytes (336516->336160) gtkspell shrunk 400 bytes (56779->56379) pulseaudio-core-libs shrunk 416 bytes (439696->439280) libpcap shrunk 485 bytes (261897->261412) nspluginwrapper shrunk 495 bytes (311511->311016) udev shrunk 601 bytes (654430->653829) setroubleshoot-plugins shrunk 689 bytes (2422617->2421928) python-numeric shrunk 1040 bytes (1722779->1721739) xorg-x11-drv-vesa shrunk 1208 bytes (26099->24891) fedora-release shrunk 1450 bytes (46680->45230) gnome-spell shrunk 1568 bytes (377889->376321) gparted shrunk 1600 bytes (1569813->1568213) nspr shrunk 1856 bytes (248628->246772) dvd+rw-tools shrunk 1860 bytes (283930->282070) libdrm shrunk 1878 bytes (39456->37578) at shrunk 1892 bytes (83059->81167) synaptics shrunk 2072 bytes (113498->111426) m17n-contrib-hindi shrunk 2162 bytes (16757->14595) pango shrunk 3747 bytes (862572->858825) system-config-services shrunk 3768 bytes (561578->557810) libcdio shrunk 3961 bytes (555394->551433) audit-libs shrunk 4096 bytes (130447->126351) atmel-firmware shrunk 4458 bytes (732612->728154) fontconfig shrunk 4805 bytes (374336->369531) iwl4965-firmware shrunk 5572 bytes (389701->384129) checkpolicy shrunk 6752 bytes (510825->504073) xorg-x11-fonts-ethiopic shrunk 8087 bytes (437981->429894) ppp shrunk 8123 bytes (841674->833551) ntp shrunk 8426 bytes (2652615->2644189) procps shrunk 11625 bytes (374451->362826) iproute shrunk 11660 bytes (2152986->2141326) gnome-bluetooth shrunk 12179 bytes (545675->533496) smolt shrunk 13811 bytes (635219->621408) b43-fwcutter shrunk 17375 bytes (37123->19748) im-chooser shrunk 19198 bytes (208789->189591) evolution shrunk 30364 bytes (38160208->38129844) ntfsprogs shrunk 33559 bytes (1148797->1115238) zip shrunk 33692 bytes (302492->268800) vixie-cron shrunk 46771 bytes (673502->626731) logwatch shrunk 52401 bytes (1345913->1293512) compiz shrunk 57822 bytes (1846352->1788530) system-config-printer-libs shrunk 60765 bytes (2411303->2350538) cups shrunk 63488 bytes (10345708->10282220) eel2 shrunk 90562 bytes (848996->758434) yelp shrunk 99732 bytes (2559882->2460150) xorg-x11-drv-i810 shrunk 249946 bytes (655965->406019) gtk2 shrunk 308952 bytes (20696815->20387863) fedora-release-notes shrunk 329470 bytes (12271152->11941682) firstboot shrunk 373469 bytes (783521->410052) cairo shrunk 423604 bytes (1623706->1200102) control-center shrunk 492635 bytes (8945618->8452983) gnome-media shrunk 782217 bytes (4946507->4164290) e2fsprogs shrunk 904410 bytes (2366733->1462323) device-mapper shrunk 917957 bytes (1027430->109473) gnome-themes shrunk 1007647 bytes (4994173->3986526) xkeyboard-config shrunk 1188506 bytes (3043679->1855173) lvm2 shrunk 1386888 bytes (2186994->800106) xorg-x11-server-Xorg shrunk 1410978 bytes (7431876->6020898) python shrunk 1870258 bytes (18499208->16628950) xorg-x11-fonts-Type1 shrunk 1919814 bytes (2803806->883992) ncurses shrunk 2311863 bytes (2562051->250188) selinux-policy-targeted shrunk 3364847 bytes (27048093->23683246) gdm shrunk 6450348 bytes (14040436->7590088) gnome-applets shrunk 8005406 bytes (26478262->18472856) firefox shrunk 39666395 bytes (42009290->2342895) ================================================================================ removed package fonts-punjabi: 0 removed package fonts-gujarati: 0 removed package fonts-korean: 0 removed package fonts-arabic: 0 removed package fonts-oriya: 0 removed package fonts-chinese: 0 removed package fonts-kannada: 0 removed package fonts-bengali: 0 removed package fonts-hebrew: 0 removed package fonts-hindi: 0 removed package fonts-tamil: 0 removed package fonts-telugu: 0 removed package fonts-sinhala: 0 removed package fonts-malayalam: 0 removed package xorg-x11-drv-ark: 18888 removed package xorg-x11-drv-tseng: 52907 removed package xorg-x11-drv-s3: 58401 removed package totem-plparser: 70428 removed package libbeagle: 94092 removed package xorg-x11-drv-avivo: 107204 removed package xorg-x11-drv-chips: 154533 removed package fuse: 216231 removed package beecrypt: 242015 removed package xorg-x11-drv-via: 363192 removed package curl: 514238 removed package firstboot-tui: 653472 removed package xorg-x11-fonts-truetype: 909077 removed package db4o: 1414265 removed package evince: 3452782 removed package aspell-en: 3567971 removed package dejavu-lgc-fonts: 6293390 From bruno at wolff.to Sat Jan 26 22:23:26 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Sat, 26 Jan 2008 16:23:26 -0600 Subject: In rawhide prelink -avR doesn't work, switch to -avmR Message-ID: <20080126222326.GA24298@wolff.to> This might not really impact things. I didn't test using -av as the cron scripts do. But if the -R option doesn't use up address space faster (which I don't know), then the cron scripts may need to be modified. This is sample output that I got: [root at cerberus bruno]# /usr/sbin/prelink -vaR /usr/sbin/prelink: /usr/bin/kbabeldict.#prelink#.UJB6Nz: Could not find one of the dependencies /usr/sbin/prelink: /usr/bin/kbabel.#prelink#.PUsLOh: Could not find one of the dependencies /usr/sbin/prelink: /usr/bin/gnucash-bin: Could not find one of the dependencies /usr/sbin/prelink: /sbin/mdassemble.static: PT_INTERP segment not corresponding to .interp section /usr/sbin/prelink: /sbin/fence_xvmd: Could not find one of the dependencies Laying out 518 libraries in virtual address space 00101000-50000000 Random base 0x3b0f0000 /usr/sbin/prelink: Could not find virtual address slot for /usr/lib/libwireshark.so.0 The last message about wireshark is the fatal one. The other messages showed up when using the -m option, but did not prevent prelinking. From rdieter at math.unl.edu Sat Jan 26 22:35:55 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 26 Jan 2008 16:35:55 -0600 Subject: reviewers needed for kde-related pkgs Message-ID: Reviewers are needed for the following items: libvncserver: http://bugzilla.redhat.com/429749 xsettings-kde: http://bugzilla.redhat.com/427722 I'm willing to swap reviews. -- Rex From mschwendt.tmp0701.nospam at arcor.de Sat Jan 26 22:50:13 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 26 Jan 2008 23:50:13 +0100 Subject: Package Versioning Feedback In-Reply-To: <1201384332.32282.16.camel@localhost6.localdomain6> References: <1201384332.32282.16.camel@localhost6.localdomain6> Message-ID: <20080126235013.208dbc68.mschwendt.tmp0701.nospam@arcor.de> On Sat, 26 Jan 2008 14:52:12 -0700, Richi Plana wrote: > Hi, > > I wanted to start my own little project and wanted some feedback from > the community who've had much dealings with versioning. My plan is to > use a versioning system similar to most (digits separated by a dot > character) with each successive number being less significant. The only > change in semantics is that the most minor number would be interpreted > as > > 0 = Alpha > 1 = Beta > 3+ = Stable > > I thought this might be a better way of dealing with projects which > transition to a greater major number. Systems which use .99+ to > designate "almost next major" aren't easy to test as the next major > version (since the computer parses the major version and sees the > previous major version. > > Some systems increase the major and tack on the word "alpha" or > "beta" ... which screws up the computer's sorting mechanism (is alpha > > 0?) > > My question is: will there be any problems with packaging systems like > rpm and yum using such a scheme? It depends on what your numbers look like. Preferably, use only natural numbers (as they can be compared with each other in a well-defined way), and don't make up your own notation for the numbers. In particular, never use any numbers with 0 prefix, not in the least significant position either. For RPM, 2 and 02 and 000002 are equal. Hence 1.1 is smaller than 1.02, but equal to 1.01. And a 1.3001 release, which may look like a very minor release after 1.3, would be higher than all 1.X with X < 3001, including 1.4, 1.50, 1.99 and so on. As a side-note, adding non-numerical characters somewhere to a version number string not only compares numbers to characters, it alters the length of what is compared. Due to that, the longer version wins, as in 1.3.0 is lower than 1.3.0a or 1.3.0rc2 From michel.sylvan at gmail.com Sat Jan 26 22:53:43 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Sat, 26 Jan 2008 17:53:43 -0500 Subject: thinkpad-acpi upstream version? In-Reply-To: <47868933.6060008@redhat.com> References: <47852A26.4010609@fedoraproject.org> <364d303b0801091641y763baef2y12a95bde37547c42@mail.gmail.com> <47866320.1040606@redhat.com> <4786653C.5020204@fedoraproject.org> <47868933.6060008@redhat.com> Message-ID: 2008/1/10 Jarod Wilson : > Nicolas Antonio Corrarello wrote: > > Maybe you're in the same condition as I am (Also T61 user, great > > machine)... Can't make the volume > > up/down keys to work, and I can't change the volume through > > /proc/acpi/ibm/volume. I'll see if this is solved in the thinkpad-acpi > > changelog and file a bug... > > Ah yes, mine has the same issue with 2.6.23.12 right now, forgot about that. > Heck, *I* should have filed a bug already... But I'll let you. :) > > Also, the brightness keys don't do anything on mine, though that may be > resolved in rawhide via xbacklight, iirc. Rawhide was a bit too explodey for > me to want to upgrade to it just yet though. > Apologies if this is a silly question, but which Rawhide package contains xbacklight? I just did a yum search and it came up blank. I just compiled it by hand on F8 and it works fine. Like several others on this thread, the brightness controls do nothing on F8, and I've been getting barely three hours with the extended 7-cell battery on a 14" 1280x800 with Intel graphics -- going to jump to F9 alpha once that comes out. My suspend problems are almost identical to Matthew Saltzman's; I'd roll my own kernel if I have the time to experiment with different settings. -- Michel Salim http://hircus.jaiku.com/ From myfedora at richip.dhs.org Sat Jan 26 23:01:14 2008 From: myfedora at richip.dhs.org (Richi Plana) Date: Sat, 26 Jan 2008 16:01:14 -0700 Subject: Package Versioning Feedback In-Reply-To: <20080126235013.208dbc68.mschwendt.tmp0701.nospam@arcor.de> References: <1201384332.32282.16.camel@localhost6.localdomain6> <20080126235013.208dbc68.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1201388474.21660.1.camel@localhost6.localdomain6> On Sat, 2008-01-26 at 23:50 +0100, Michael Schwendt wrote: > On Sat, 26 Jan 2008 14:52:12 -0700, Richi Plana wrote: > > > Hi, > > > > I wanted to start my own little project and wanted some feedback from > > the community who've had much dealings with versioning. My plan is to > > use a versioning system similar to most (digits separated by a dot > > character) with each successive number being less significant. The only > > change in semantics is that the most minor number would be interpreted > > as > > > > 0 = Alpha > > 1 = Beta > > 3+ = Stable > > > > I thought this might be a better way of dealing with projects which > > transition to a greater major number. Systems which use .99+ to > > designate "almost next major" aren't easy to test as the next major > > version (since the computer parses the major version and sees the > > previous major version. > > > > Some systems increase the major and tack on the word "alpha" or > > "beta" ... which screws up the computer's sorting mechanism (is alpha > > > 0?) > > > > My question is: will there be any problems with packaging systems like > > rpm and yum using such a scheme? > > It depends on what your numbers look like. Preferably, use only natural > numbers (as they can be compared with each other in a well-defined way), > and don't make up your own notation for the numbers. In particular, never > use any numbers with 0 prefix, not in the least significant position > either. For RPM, 2 and 02 and 000002 are equal. Hence 1.1 is smaller than > 1.02, but equal to 1.01. And a 1.3001 release, which may look like a > very minor release after 1.3, would be higher than all 1.X with X < 3001, > including 1.4, 1.50, 1.99 and so on. > > As a side-note, adding non-numerical characters somewhere to a version > number string not only compares numbers to characters, it alters the > length of what is compared. Due to that, the longer version wins, as in > 1.3.0 is lower than 1.3.0a or 1.3.0rc2 That's exactly why I'm interested in adopting the aforementioned semantic. And yes, I'll be sticking to decimal digits. For example, 1.3.0 is the alpha of the 1.3 series. 1.3.1 is the beta and 1.3.2, 1.3.3, etc. are the stable. That way if I wanted to bump it up to 1.4, for testers they'd be using 1.4.0 as alpha. -- Richi Plana From michel.sylvan at gmail.com Sat Jan 26 23:11:30 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Sat, 26 Jan 2008 18:11:30 -0500 Subject: Package Versioning Feedback In-Reply-To: <1201388474.21660.1.camel@localhost6.localdomain6> References: <1201384332.32282.16.camel@localhost6.localdomain6> <20080126235013.208dbc68.mschwendt.tmp0701.nospam@arcor.de> <1201388474.21660.1.camel@localhost6.localdomain6> Message-ID: On Jan 26, 2008 6:01 PM, Richi Plana wrote: > > On Sat, 2008-01-26 at 23:50 +0100, Michael Schwendt wrote: > > On Sat, 26 Jan 2008 14:52:12 -0700, Richi Plana wrote: > > > > > Hi, > > > > > > I wanted to start my own little project and wanted some feedback from > > > the community who've had much dealings with versioning. My plan is to > > > use a versioning system similar to most (digits separated by a dot > > > character) with each successive number being less significant. The only > > > change in semantics is that the most minor number would be interpreted > > > as > > > > > > 0 = Alpha > > > 1 = Beta > > > 3+ = Stable > > > > > > I thought this might be a better way of dealing with projects which > > > transition to a greater major number. Systems which use .99+ to > > > designate "almost next major" aren't easy to test as the next major > > > version (since the computer parses the major version and sees the > > > previous major version. > > > > > > Some systems increase the major and tack on the word "alpha" or > > > "beta" ... which screws up the computer's sorting mechanism (is alpha > > > > 0?) > > > > > > My question is: will there be any problems with packaging systems like > > > rpm and yum using such a scheme? > > > > It depends on what your numbers look like. Preferably, use only natural > > numbers (as they can be compared with each other in a well-defined way), > > and don't make up your own notation for the numbers. In particular, never > > use any numbers with 0 prefix, not in the least significant position > > either. For RPM, 2 and 02 and 000002 are equal. Hence 1.1 is smaller than > > 1.02, but equal to 1.01. And a 1.3001 release, which may look like a > > very minor release after 1.3, would be higher than all 1.X with X < 3001, > > including 1.4, 1.50, 1.99 and so on. > > > > As a side-note, adding non-numerical characters somewhere to a version > > number string not only compares numbers to characters, it alters the > > length of what is compared. Due to that, the longer version wins, as in > > 1.3.0 is lower than 1.3.0a or 1.3.0rc2 > > That's exactly why I'm interested in adopting the aforementioned > semantic. And yes, I'll be sticking to decimal digits. > > For example, 1.3.0 is the alpha of the 1.3 series. 1.3.1 is the beta and > 1.3.2, 1.3.3, etc. are the stable. That way if I wanted to bump it up to > 1.4, for testers they'd be using 1.4.0 as alpha. So basically Apple's numbering system for Leopard :) Sounds fine, though you might want to make the version numbering system explicit somewhere, otherwise packagers might mistake an alpha of yours as a stable release. I quite like the {alpha,beta,rc}n system as well -- it's not that hard to tag the pre-release number in the release field, and it's more obvious to a lay person what the state of the software is. -- Michel Salim http://hircus.jaiku.com/ From mjs at CLEMSON.EDU Sat Jan 26 23:16:52 2008 From: mjs at CLEMSON.EDU (Matthew Saltzman) Date: Sat, 26 Jan 2008 18:16:52 -0500 Subject: thinkpad-acpi upstream version? In-Reply-To: References: <47852A26.4010609@fedoraproject.org> <364d303b0801091641y763baef2y12a95bde37547c42@mail.gmail.com> <47866320.1040606@redhat.com> <4786653C.5020204@fedoraproject.org> <47868933.6060008@redhat.com> Message-ID: <1201389412.12975.45.camel@vincent52.localdomain> On Sat, 2008-01-26 at 17:53 -0500, Michel Salim wrote: > 2008/1/10 Jarod Wilson : > > Nicolas Antonio Corrarello wrote: > > > Maybe you're in the same condition as I am (Also T61 user, great > > > machine)... Can't make the volume > > > up/down keys to work, and I can't change the volume through > > > /proc/acpi/ibm/volume. I'll see if this is solved in the thinkpad-acpi > > > changelog and file a bug... > > > > Ah yes, mine has the same issue with 2.6.23.12 right now, forgot about that. > > Heck, *I* should have filed a bug already... But I'll let you. :) > > > > Also, the brightness keys don't do anything on mine, though that may be > > resolved in rawhide via xbacklight, iirc. Rawhide was a bit too explodey for > > me to want to upgrade to it just yet though. > > > Apologies if this is a silly question, but which Rawhide package > contains xbacklight? I just did a yum search and it came up blank. I > just compiled it by hand on F8 and it works fine. > > Like several others on this thread, the brightness controls do nothing > on F8, and I've been getting barely three hours with the extended > 7-cell battery on a 14" 1280x800 with Intel graphics -- going to jump > to F9 alpha once that comes out. > > My suspend problems are almost identical to Matthew Saltzman's; I'd > roll my own kernel if I have the time to experiment with different > settings. For the spontaneous-resume-from-suspend issue, there turns out to be a workaround: http://www.ces.clemson.edu/linux/f8-nvidia-suspend.shtml For the power issues, make sure you have BIOS 1.22-1.06 or later. Battery life is still not great, but it is supposed to be better than earlier BIOSes Still can't resume from hibernate with the nVidia binary driver. nv driver still has issues (see another thread about that). vesa driver mostly works, except that the backlight never goes off. -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From michel.sylvan at gmail.com Sat Jan 26 23:24:25 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Sat, 26 Jan 2008 18:24:25 -0500 Subject: Reviewers needed (can swap) Message-ID: I need reviewers for the following requests: Audio processing: https://bugzilla.redhat.com/show_bug.cgi?id=429084 vamp-plugin-sdk https://bugzilla.redhat.com/show_bug.cgi?id=429086 sonic-visualiser (note: can't help the British English spelling, it's from upstream) Programming languages: https://bugzilla.redhat.com/show_bug.cgi?id=430307 Falcon (I reviewed this when upstream intended to handle packaging themselves, so it should be in good shape already) https://bugzilla.redhat.com/show_bug.cgi?id=430351 libgee A collection library based on GObject; can be used from C or Vala X https://bugzilla.redhat.com/show_bug.cgi?id=430367 xbacklight Command-line tool to control backlight using RandR. I've seen this mentioned on the list, but to my knowledge this has not been packaged for Fedora yet. Tested to work on my Thinkpad x86_64. Thanks, -- Michel Salim http://hircus.jaiku.com/ From jkeating at redhat.com Sun Jan 27 00:39:54 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 26 Jan 2008 19:39:54 -0500 Subject: long term support release In-Reply-To: <80d7e4090801261251o4d08cefj217e18842f680357@mail.gmail.com> References: <1201240697.17905.179.camel@beck.corsepiu.local> <479A0A55.60409@fedoraproject.org> <1201277129.14800.25.camel@cutter> <200801251127.47467.jwilson@redhat.com> <1201278927.17905.382.camel@beck.corsepiu.local> <20080125195136.02a98f3d@redhat.com> <20080126081343.GA9229@jasmine.xos.nl> <80d7e4090801261251o4d08cefj217e18842f680357@mail.gmail.com> Message-ID: <20080126193954.61e969fd@redhat.com> On Sat, 26 Jan 2008 13:51:43 -0700 "Stephen John Smoogen" wrote: > The issues usually come down to how many packages are covered by the > trademark. CentOS has to make a lot patches to take out trademarks in > documentation, programs etc... and even after spending 2 weeks on > 5.0... we missed 10 or so packages. Then there are various things that > are 'broken' if you don't use the RHN system (that was one or two > issues). There is also the fact that RHEL sometimes doesn't supply all > the packages from an RPM (this was much the case in 2 and 3, less than > 4 & 5). Finally RH uses hidden build flags which have to be found out > to get a package to match that.. which of course gets people wondering > why they do it on this package etc which gets either conspiracy > talking or people who will rebuild the package until they get a match. Much of this is changing for the better. The use of Koji internally helps greatly, as does the effort going on in Fedora right now to consolidate all the branding in easy to replace packages. We're learning, keep bringing these issues up to us. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Jan 27 00:42:13 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 26 Jan 2008 19:42:13 -0500 Subject: Fedora Education Spin In-Reply-To: <479B890A.3030903@fedoraproject.org> References: <479B4B6A.90805@when.com> <50baabb30801261000g690bfc40w80fdff6cca0efd35@mail.gmail.com> <479B85DD.5090406@when.com> <479B890A.3030903@fedoraproject.org> Message-ID: <20080126194213.1a466781@redhat.com> On Sun, 27 Jan 2008 00:54:58 +0530 Rahul Sundaram wrote: > It is possible to file requests against specific packages to split > them up further or drop unneeded dependencies. The audio files for > gcompris could be split up for example. Or we can just realize that a useful targeted spin like this may exceed the size of a CD. Big deal. There are other ways to deploy it than having a DVD drive in the target machine. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jeffreyt at fedoraproject.org Sun Jan 27 00:47:24 2008 From: jeffreyt at fedoraproject.org (Jeffrey Tadlock) Date: Sat, 26 Jan 2008 19:47:24 -0500 Subject: InstantMirror needs a rethink In-Reply-To: <4797D5B3.7030002@redhat.com> References: <4797D5B3.7030002@redhat.com> Message-ID: <10e0a9b00801261647u235f9e73q573f20c9d9f60dae@mail.gmail.com> On Jan 23, 2008 7:02 PM, Warren Togami wrote: > Today InstantMirror is pretty useful for home and small office mirrors, > but its limitations make it unsustainable without manual intervention of > the sysadmin. > > Any thoughts? Should InstantMirror be for more than home and small office mirrors? I've been using InstantMirror at home for several machines and even more test instances here and there and it has performed a valuable function for me without the need to mirror Fedora repos. I would be comfortable using InstantMirror in a small office setting as well. InstantMirror offered a quick way to cache updates used by the majority of my machines locally with only a few minutes of setup time. For home users or small office users this is a quick way to provide the benefit of locally cached updates without needing to consume large amount of bandwidth or time to setup a local mirror via rsync. At some point, a place that runs into some of the issues you outlined will have outgrown InstantMirror and want to move to a more traditional rsync'ed local mirror. Both to avoid issues with InstantMirror as they outgrow it and to make it easier to deal with the larger variation in packages needed by various local machines. --Jeffrey From sundaram at fedoraproject.org Sun Jan 27 00:56:39 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 27 Jan 2008 06:26:39 +0530 Subject: Fedora Education Spin In-Reply-To: <20080126194213.1a466781@redhat.com> References: <479B4B6A.90805@when.com> <50baabb30801261000g690bfc40w80fdff6cca0efd35@mail.gmail.com> <479B85DD.5090406@when.com> <479B890A.3030903@fedoraproject.org> <20080126194213.1a466781@redhat.com> Message-ID: <479BD6C7.3010608@fedoraproject.org> Jesse Keating wrote: > On Sun, 27 Jan 2008 00:54:58 +0530 > Rahul Sundaram wrote: > >> It is possible to file requests against specific packages to split >> them up further or drop unneeded dependencies. The audio files for >> gcompris could be split up for example. > > Or we can just realize that a useful targeted spin like this may exceed > the size of a CD. Big deal. There are other ways to deploy it than > having a DVD drive in the target machine. I think you are drastically underestimating the value of this fitting into a CD and more granularity in packages. It *is* a big deal. Rahul From jkeating at redhat.com Sun Jan 27 00:50:27 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 26 Jan 2008 19:50:27 -0500 Subject: Fedora Education Spin In-Reply-To: <479BD6C7.3010608@fedoraproject.org> References: <479B4B6A.90805@when.com> <50baabb30801261000g690bfc40w80fdff6cca0efd35@mail.gmail.com> <479B85DD.5090406@when.com> <479B890A.3030903@fedoraproject.org> <20080126194213.1a466781@redhat.com> <479BD6C7.3010608@fedoraproject.org> Message-ID: <20080126195027.0cefe0ad@redhat.com> On Sun, 27 Jan 2008 06:26:39 +0530 Rahul Sundaram wrote: > I think you are drastically underestimating the value of this fitting > into a CD and more granularity in packages. It *is* a big deal. And I think you're limited by the assumption that the only way to run or install a Live image is by running a CD sized media. It's not. There are a few ways now, and we can certainly put work into creating more and easier ways to consume these images. Software is only getting bigger, and the CD size is only going to further limit what we can do. Functionality of the CD sized image will only get worse, not better. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Sun Jan 27 01:13:08 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 27 Jan 2008 06:43:08 +0530 Subject: Fedora Education Spin In-Reply-To: <20080126195027.0cefe0ad@redhat.com> References: <479B4B6A.90805@when.com> <50baabb30801261000g690bfc40w80fdff6cca0efd35@mail.gmail.com> <479B85DD.5090406@when.com> <479B890A.3030903@fedoraproject.org> <20080126194213.1a466781@redhat.com> <479BD6C7.3010608@fedoraproject.org> <20080126195027.0cefe0ad@redhat.com> Message-ID: <479BDAA4.6070304@fedoraproject.org> Jesse Keating wrote: > On Sun, 27 Jan 2008 06:26:39 +0530 > Rahul Sundaram wrote: > >> I think you are drastically underestimating the value of this fitting >> into a CD and more granularity in packages. It *is* a big deal. > > > And I think you're limited by the assumption that the only way to run > or install a Live image is by running a CD sized media. It's not. The other ways aren't anywhere as easy or accessible to everyone. Look at the number of complaints we are getting about not releasing regular CD images or that live images aren't CD size for x86_64. Besides more granularity in packages is a good thing to have anyway if Fedora has to retain it's goal of being a good foundation to build things for OLPC or other resource constrained systems. > There are a few ways now, and we can certainly put work into creating > more and easier ways to consume these images. Software is only getting > bigger, and the CD size is only going to further limit what we can do. > Functionality of the CD sized image will only get worse, not better. That's a good challenge to have to prevent software from getting too bloated or packages from growing unneeded dependencies. Maybe CD's would get obsoleted completely sometime in the future. We haven't reached that point yet. Rahul From jkeating at redhat.com Sun Jan 27 01:09:25 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 26 Jan 2008 20:09:25 -0500 Subject: Fedora Education Spin In-Reply-To: <479BDAA4.6070304@fedoraproject.org> References: <479B4B6A.90805@when.com> <50baabb30801261000g690bfc40w80fdff6cca0efd35@mail.gmail.com> <479B85DD.5090406@when.com> <479B890A.3030903@fedoraproject.org> <20080126194213.1a466781@redhat.com> <479BD6C7.3010608@fedoraproject.org> <20080126195027.0cefe0ad@redhat.com> <479BDAA4.6070304@fedoraproject.org> Message-ID: <20080126200925.0da8e740@redhat.com> On Sun, 27 Jan 2008 06:43:08 +0530 Rahul Sundaram wrote: > The other ways aren't anywhere as easy or accessible to everyone. > Look at the number of complaints we are getting about not releasing > regular CD images or that live images aren't CD size for x86_64. > Besides more granularity in packages is a good thing to have anyway > if Fedora has to retain it's goal of being a good foundation to build > things for OLPC or other resource constrained systems. And at the same time, hugely granular packages lead to a horrible user experience, where none of the software works as advertised because you forgot to install the 50 addon packages to get the functionality you wanted. Not to mention the bloat in metadata size, that folks will have to download again and again, more delays in depsolving, longer and longer periods of time for composing releases/updates, etc... There is a balance to strike, and we have to ask ourselves if we care about being usable ourselves, or if all we care about is doing all the hardwork so that somebody /else/ can be useable, just based on us, but with a different name due to our draconian trademark policies. > > > There are a few ways now, and we can certainly put work into > > creating more and easier ways to consume these images. Software is > > only getting bigger, and the CD size is only going to further limit > > what we can do. Functionality of the CD sized image will only get > > worse, not better. > > That's a good challenge to have to prevent software from getting too > bloated or packages from growing unneeded dependencies. Maybe CD's > would get obsoleted completely sometime in the future. We haven't > reached that point yet. CD sized optical media has been obsoleted. Some parts of the world just hasn't noticed yet. When we're trying to be a bleeding edge distro it's rather hard to tie ourselves to multi-generation old hardware standards. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bruno at wolff.to Sun Jan 27 01:13:57 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Sat, 26 Jan 2008 19:13:57 -0600 Subject: Is there a gdmsetup replacement yet for rawhide? In-Reply-To: <1201382815.2940.5.camel@localhost.localdomain> References: <20080126201637.GD25387@wolff.to> <1201382815.2940.5.camel@localhost.localdomain> Message-ID: <20080127011357.GA20396@wolff.to> On Sat, Jan 26, 2008 at 16:26:55 -0500, Matthias Clasen wrote: > > On Sat, 2008-01-26 at 14:16 -0600, Bruno Wolff III wrote: > > I noticed that gdmsetup has gone away in rawhide, but I haven't been > > able to find its replacement yet. Can someone provide some guidance here? > > There is no replacement yet. > What particular configuration were you looking for ? Well I like to have Sauron's eye as my background. The other thing I wanted to do was get rid of the user list. It picks up some other accounts in rawhide that it didn't in f8 and after selecting the name I want the window changes in a clunky (and annoying to me) manner (which I have bugzilla'd) and wanted to get rid of it. I also don't want the restart nor shutdown options there. While people can reach the power button, I don't want to make it easy for people to do it without thinking. From sundaram at fedoraproject.org Sun Jan 27 01:32:29 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 27 Jan 2008 07:02:29 +0530 Subject: Fedora Education Spin In-Reply-To: <20080126200925.0da8e740@redhat.com> References: <479B4B6A.90805@when.com> <50baabb30801261000g690bfc40w80fdff6cca0efd35@mail.gmail.com> <479B85DD.5090406@when.com> <479B890A.3030903@fedoraproject.org> <20080126194213.1a466781@redhat.com> <479BD6C7.3010608@fedoraproject.org> <20080126195027.0cefe0ad@redhat.com> <479BDAA4.6070304@fedoraproject.org> <20080126200925.0da8e740@redhat.com> Message-ID: <479BDF2D.3040906@fedoraproject.org> Jesse Keating wrote: > On Sun, 27 Jan 2008 06:43:08 +0530 > Rahul Sundaram wrote: > >> The other ways aren't anywhere as easy or accessible to everyone. >> Look at the number of complaints we are getting about not releasing >> regular CD images or that live images aren't CD size for x86_64. >> Besides more granularity in packages is a good thing to have anyway >> if Fedora has to retain it's goal of being a good foundation to build >> things for OLPC or other resource constrained systems. > > And at the same time, hugely granular packages lead to a horrible user > experience, where none of the software works as advertised because you > forgot to install the 50 addon packages to get the functionality you > wanted. There are ways to solve this. Install them by default. Use meta packages, comps groups. We also seem to be only mainstream RPM based distribution not using soft dependencies. > CD sized optical media has been obsoleted. Some parts of the world > just hasn't noticed yet. It is question of what is available and affordable. The difference between CD drives/media and DVD drives/media is still pretty high in some regions. Rahul From vonbrand at inf.utfsm.cl Sun Jan 27 01:29:00 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sat, 26 Jan 2008 22:29:00 -0300 Subject: long term support release In-Reply-To: <1201330199.17905.561.camel@beck.corsepiu.local> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> <4799EAA0.7030700@gmail.com> <20080125102616.7605825b@redhat.com> <479A0C6B.1050004@gmail.com> <20080125112254.382c9e13@redhat.com> <479A190F.8010402@gmail.com> <200801251727.m0PHRe0O016727@laptop13.inf.utfsm.cl> <479A268B.5070201@gmail.com> <1201330199.17905.561.camel@beck.corsepiu.local> Message-ID: <200801270129.m0R1T0Eg000930@laptop13.inf.utfsm.cl> Ralf Corsepius wrote: > On Fri, 2008-01-25 at 12:12 -0600, Les Mikesell wrote: > > Horst H. von Brand wrote: > > >> If the latter effort fails, > > >> you've still got a solid, working version. > > > If you want "solid, working", why are you messing around with > > > "bleeding-edge apps"?! > > Why are people writing 'bleeding-edge' apps if there is no reason to use > > them? > I guess no reasonable _user_ wants 'bleeding-edge'. I consider myself "reasonable"... but sure, the evaluation comes from awfully close ;-) > I want/need a comprehensive, up2date distribution containing > current/up2date (considered stable) versions of those packages I > actually use. To get to the point of "considered stable" somebodies must do the "considering" (plus the attendant bug fixing)... > As a developer, it's not a major problem for _me_ having to cope with a > couple of issues here and there, but how do you expect "Aunt Tillie" to > cope with them? Perhaps Fedora isn't for her then. There are many alternatives; in the RH-ish range there is CentOS. > Also, with F8 I have been confronted with so many tiny issues, which all > together render productive use of Fedora close to impossible and have > caused me to have doubts on the project's sanity. Have you reported them? [BTW, most of the F8 timeline I was running rawhide, and I was reasonably productive al throughout, except for some short glitches. So I don't buy your "close to impossible to use".] > Interestingly, it's not the "community-maintained packages" some seem to > preferr to accuse to be of low quality, which are causing the trouble, > it's the sum of issues with the "standard/default packages" which are > piling up. Stands to reason, the "standard/default packages" are the foundation of the system. If some obscure game or some piece of glitter malfunctions, it isn't too nice; is the kernel, glibc, or Gnome fail it is fatal. > > A desktop app that crashes once in a while is not a huge problem > > - and wouldn't be a problem at all if there were an option to drop back > > to a more stable version. > > A machine that won't boot or a device driver > > that no longer talks to my hardware is. > Yep, that's one subset amongst several sets of issues I am facing ;) > Fortunately, these happen to be the easy cases. The really nagging ones > are those, one can't identify the cause of. And those get magically fixed by extending the life of a random version with an understaffed crew doing on-and-off bug fixing and backporting? In my experience, they end getting fixed by moving forward. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From vonbrand at inf.utfsm.cl Sun Jan 27 01:43:57 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sat, 26 Jan 2008 22:43:57 -0300 Subject: long term support release In-Reply-To: <479B7751.4050503@gmail.com> References: <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> <20080125152614.GA2975@free.fr> <20080125103335.0d5adacf@redhat.com> <20080125154127.GC2975@free.fr> <1201275741.1163.1.camel@localhost.localdomain> <20080125154749.GD2975@free.fr> <20080125105041.6605e470@redhat.com> <479A10D0.7020301@gmail.com> <200801251709.m0PH9iV5015900@laptop13.inf.utfsm.cl> <479B29B2.1070407@gmail.com> <479B7751.4050503@gmail.com> Message-ID: <200801270143.m0R1hvWa001619@laptop13.inf.utfsm.cl> Les Mikesell wrote: > Andrew Farris wrote: [...] > >> Upgrade to next Fedora. Gets easier each time around. A bit of foresight > >> when installing originally helps much here. > > Precisely. The update or upgrades are essentially very simple to > > handle when you've got a sane partitioning scheme setup. > I _really_ have to believe that you haven't run fedora over any span > of time across a variety of hardware I'm running Red Hat since Red Hat 3 or so, and then Fedora from 1. On an rather wide variety of machines (Alpha, SPARC and SPARC64, i386 to i686, x86_64, single/double/8x processor, ...). All the way as machines in a computer lab, day-to-day workstation, and servers. And yes, upgrading used to be a pain, but is is getting easier all the time. > with an assortment of additional > software installed. That I learned not to do in the RH 4-5 timeframe, especially not "self compiled from source". What limited stuff I have locally is packaged as self-built RPMs that I can update easily. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From fedora at camperquake.de Sun Jan 27 01:52:59 2008 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 27 Jan 2008 02:52:59 +0100 Subject: Fedora Education Spin In-Reply-To: <479BDAA4.6070304@fedoraproject.org> References: <479B4B6A.90805@when.com> <50baabb30801261000g690bfc40w80fdff6cca0efd35@mail.gmail.com> <479B85DD.5090406@when.com> <479B890A.3030903@fedoraproject.org> <20080126194213.1a466781@redhat.com> <479BD6C7.3010608@fedoraproject.org> <20080126195027.0cefe0ad@redhat.com> <479BDAA4.6070304@fedoraproject.org> Message-ID: <20080127025259.32e47cee@lain.camperquake.de> Hi. On Sun, 27 Jan 2008 06:43:08 +0530, Rahul Sundaram wrote > Look at the number of complaints we are getting about not releasing > regular CD images or that live images aren't CD size for x86_64. You are not going to argue that people can afford a x86_64 bit machine, but can not afford the upgrade from CD to DVD? From sundaram at fedoraproject.org Sun Jan 27 02:10:18 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 27 Jan 2008 07:40:18 +0530 Subject: Fedora Education Spin In-Reply-To: <20080127025259.32e47cee@lain.camperquake.de> References: <479B4B6A.90805@when.com> <50baabb30801261000g690bfc40w80fdff6cca0efd35@mail.gmail.com> <479B85DD.5090406@when.com> <479B890A.3030903@fedoraproject.org> <20080126194213.1a466781@redhat.com> <479BD6C7.3010608@fedoraproject.org> <20080126195027.0cefe0ad@redhat.com> <479BDAA4.6070304@fedoraproject.org> <20080127025259.32e47cee@lain.camperquake.de> Message-ID: <479BE80A.5080309@fedoraproject.org> Ralf Ertzinger wrote: > Hi. > > On Sun, 27 Jan 2008 06:43:08 +0530, Rahul Sundaram wrote > >> Look at the number of complaints we are getting about not releasing >> regular CD images or that live images aren't CD size for x86_64. > > You are not going to argue that people can afford a x86_64 bit machine, > but can not afford the upgrade from CD to DVD? I don't know whether they can. The point I was trying to make is that CD's are still in demand even on x86_64. Rahul From billcrawford1970 at gmail.com Sun Jan 27 02:03:17 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Sun, 27 Jan 2008 02:03:17 +0000 Subject: In rawhide prelink -avR doesn't work, switch to -avmR In-Reply-To: <20080126222326.GA24298@wolff.to> References: <20080126222326.GA24298@wolff.to> Message-ID: <544eb990801261803s5c7fdd08t897ee558b78b10a3@mail.gmail.com> On 26/01/2008, Bruno Wolff III wrote: ... > /usr/sbin/prelink: Could not find virtual address slot for /usr/lib/libwireshark.so.0 ... This usually just means you have too many (or too big) libraries to fit. I cheated and added the line: -b /usr/lib/openoffice.org to /etc/prelink.conf, as the openoffice programs are actually supplied as shared objects, are huge, and are only ever loaded once at a time due to the way OO works. From lesmikesell at gmail.com Sun Jan 27 02:14:57 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sat, 26 Jan 2008 20:14:57 -0600 Subject: long term support release In-Reply-To: <200801270143.m0R1hvWa001619@laptop13.inf.utfsm.cl> References: <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> <20080125152614.GA2975@free.fr> <20080125103335.0d5adacf@redhat.com> <20080125154127.GC2975@free.fr> <1201275741.1163.1.camel@localhost.localdomain> <20080125154749.GD2975@free.fr> <20080125105041.6605e470@redhat.com> <479A10D0.7020301@gmail.com> <200801251709.m0PH9iV5015900@laptop13.inf.utfsm.cl> <479B29B2.1070407@gmail.com> <479B7751.4050503@gmail.com> <200801270143.m0R1hvWa001619@laptop13.inf.utfsm.cl> Message-ID: <479BE921.8080700@gmail.com> Horst H. von Brand wrote: >>>> Upgrade to next Fedora. Gets easier each time around. A bit of foresight >>>> when installing originally helps much here. > >>> Precisely. The update or upgrades are essentially very simple to >>> handle when you've got a sane partitioning scheme setup. > >> I _really_ have to believe that you haven't run fedora over any span >> of time across a variety of hardware > > I'm running Red Hat since Red Hat 3 or so, and then Fedora from 1. On an > rather wide variety of machines (Alpha, SPARC and SPARC64, i386 to i686, > x86_64, single/double/8x processor, ...). All the way as machines in a > computer lab, day-to-day workstation, and servers. > > And yes, upgrading used to be a pain, but is is getting easier all the time. I'm not convinced this is a predictable trend. You are pretty much at the mercy of kernel development, which I thought was more reasonable back in its days of having an experimental branch for the wild changes that get thrown directly into fedora these days. >> with an assortment of additional >> software installed. > > That I learned not to do in the RH 4-5 timeframe, especially not "self > compiled from source". What limited stuff I have locally is packaged as > self-built RPMs that I can update easily. That doesn't matter a lot unless you are rolling it out across a lot of similar machines. And you can't just avoid locally built stuff - it may be the whole purpose of the machine. The hard part is finding the components you need to build in the first place that work together and with your new environment and you run into dependencies in strange places. For example, there's a forgotten machine under a desk somewhere in a Swiss office, set up by someone else years ago that no longer works there that has a CIPE vpn into the LAN in our office near Chicago. If I upgrade the machine in our office to something current (instead of RH 7.3 with a 4+ year uptime...), where am I going to find a working CIPE? Or for a simpler scenario, consider something that needs a few dozen perl modules that aren't in an RPM repository and may not all work together out of CPAN the day you need them. Even if you built RPMs the last time around, you probably want updated versions and in fact may need them to work with the rest of the system. -- Les Mikesell lesmikesell at gmail.com From bruno at wolff.to Sun Jan 27 02:33:46 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Sat, 26 Jan 2008 20:33:46 -0600 Subject: In rawhide prelink -avR doesn't work, switch to -avmR In-Reply-To: <544eb990801261803s5c7fdd08t897ee558b78b10a3@mail.gmail.com> References: <20080126222326.GA24298@wolff.to> <544eb990801261803s5c7fdd08t897ee558b78b10a3@mail.gmail.com> Message-ID: <20080127023346.GA17113@wolff.to> On Sun, Jan 27, 2008 at 02:03:17 +0000, Bill Crawford wrote: > On 26/01/2008, Bruno Wolff III wrote: > ... > > /usr/sbin/prelink: Could not find virtual address slot for /usr/lib/libwireshark.so.0 > ... > > This usually just means you have too many (or too big) libraries to > fit. I cheated and added the line: > > -b /usr/lib/openoffice.org > > to /etc/prelink.conf, as the openoffice programs are actually supplied > as shared objects, are huge, and are only ever loaded once at a time > due to the way OO works. Is that something that should be added to prelink.conf as shipped? (There already is a number of blacklisted libraries there.) From vonbrand at inf.utfsm.cl Sun Jan 27 02:50:19 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sat, 26 Jan 2008 23:50:19 -0300 Subject: F9 Alpha spinning In-Reply-To: References: <20080125162835.GA19048@crow> Message-ID: <200801270250.m0R2oJX0004841@laptop13.inf.utfsm.cl> Kevin Kofler wrote: > Szabolcs Szakacsits ntfs-3g.org> writes: [...] > > If you're interested then you may read the text starting at "The big > > change this time is ..." at the below URL for the explanation why you're > > misunderstanding the situation: > > > > http://article.gmane.org/gmane.comp.file-systems.ntfs-3g.devel/392 > Well, your arguments are pretty unconvincing, and apply to a lot of > application-library relationships, still usually library users won't fork a > library just for that, or when they do, Fedora won't ship their fork. AFAIU this is an /upstream/ decision, not a Fedora one. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From lordmorgul at gmail.com Sun Jan 27 02:53:28 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sat, 26 Jan 2008 18:53:28 -0800 Subject: Is there a gdmsetup replacement yet for rawhide? In-Reply-To: <20080127011357.GA20396@wolff.to> References: <20080126201637.GD25387@wolff.to> <1201382815.2940.5.camel@localhost.localdomain> <20080127011357.GA20396@wolff.to> Message-ID: <479BF228.9020108@gmail.com> Bruno Wolff III wrote: > On Sat, Jan 26, 2008 at 16:26:55 -0500, > Matthias Clasen wrote: >> On Sat, 2008-01-26 at 14:16 -0600, Bruno Wolff III wrote: >>> I noticed that gdmsetup has gone away in rawhide, but I haven't been >>> able to find its replacement yet. Can someone provide some guidance here? >> There is no replacement yet. >> What particular configuration were you looking for ? > > Well I like to have Sauron's eye as my background. > > The other thing I wanted to do was get rid of the user list. It picks up > some other accounts in rawhide that it didn't in f8 and after selecting > the name I want the window changes in a clunky (and annoying to me) manner > (which I have bugzilla'd) and wanted to get rid of it. > > I also don't want the restart nor shutdown options there. While people can > reach the power button, I don't want to make it easy for people to do it > without thinking. > Conveniently enough, the buttons don't do anything right now. :) -- Andrew Farris www.lordmorgul.net gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From kevin.kofler at chello.at Sun Jan 27 03:18:07 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 27 Jan 2008 03:18:07 +0000 (UTC) Subject: F9 Alpha spinning References: <20080125162835.GA19048@crow> <200801270250.m0R2oJX0004841@laptop13.inf.utfsm.cl> Message-ID: Horst H. von Brand inf.utfsm.cl> writes: > > Well, your arguments are pretty unconvincing, and apply to a lot of > > application-library relationships, still usually library users won't fork a > > library just for that, or when they do, Fedora won't ship their fork. > > AFAIU this is an /upstream/ decision, not a Fedora one. It is an upstream decision to ship that fuse-lite fork in the tarball and to support it. It is a Fedora decision to actually use this fork rather than using --with-fuse=external. (In many cases, we even _patch_ upstream projects to use system libraries where they don't support it at all, in this case, it would just be a configure option.) I'm complaining about both. Kevin Kofler From khc at pm.waw.pl Sun Jan 27 03:48:16 2008 From: khc at pm.waw.pl (Krzysztof Halasa) Date: Sun, 27 Jan 2008 04:48:16 +0100 Subject: long term support release In-Reply-To: <200801261957.41090.opensource@till.name> (Till Maas's message of "Sat\, 26 Jan 2008 19\:57\:36 +0100") References: <1201249426.14800.19.camel@cutter> <1201277589.17905.369.camel@beck.corsepiu.local> <200801261957.41090.opensource@till.name> Message-ID: Till Maas writes: > Afaik, there are sometimes changes that cannot be done within the running > system. They could be done next boot. > Also the new releases are useful whenever an update of a package > requires manual intervention, because then this can be documented in the > release notes and then there are no unpleasent surprises. If a package knows a manual intervention is needed it could postpone the upgrade. Release notes could be updated as needed. > And the update > cycles also allow to be sure that some update-paths do not need to be > supported anymore, e.g. when a conversion of a config file is needed and the > latest release with the old config file is old enough, the code within the > spec can be skipped. Continuous update doesn't mean ability to update from arbitrarily old package versions, the "supported" period could be shorter than now. You would have to be able to update from the last bootstrap disc, that's all. -- Krzysztof Halasa From smooge at gmail.com Sun Jan 27 03:54:54 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Sat, 26 Jan 2008 20:54:54 -0700 Subject: long term support release In-Reply-To: References: <1201249426.14800.19.camel@cutter> <1201277589.17905.369.camel@beck.corsepiu.local> <200801261957.41090.opensource@till.name> Message-ID: <80d7e4090801261954r22de23dbgc660d60af780f194@mail.gmail.com> On Jan 26, 2008 8:48 PM, Krzysztof Halasa wrote: > Till Maas writes: > > > Afaik, there are sometimes changes that cannot be done within the running > > system. > > They could be done next boot. > Not always... there have been several changes that could only be done via a chroot environment. If for example ext4 were to be chosen for Fedora XII it would need a chroot. Large changes in how glibc work are probably better examples.. > > Also the new releases are useful whenever an update of a package > > requires manual intervention, because then this can be documented in the > > release notes and then there are no unpleasent surprises. > > If a package knows a manual intervention is needed it could postpone the > upgrade. Release notes could be updated as needed. > > > And the update > > cycles also allow to be sure that some update-paths do not need to be > > supported anymore, e.g. when a conversion of a config file is needed and the > > latest release with the old config file is old enough, the code within the > > spec can be skipped. > > Continuous update doesn't mean ability to update from arbitrarily old > package versions, the "supported" period could be shorter than > now. You would have to be able to update from the last bootstrap disc, > that's all. > > -- > Krzysztof Halasa > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From kevin.kofler at chello.at Sun Jan 27 04:59:29 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 27 Jan 2008 04:59:29 +0000 (UTC) Subject: Is there a gdmsetup replacement yet for rawhide? References: <20080126201637.GD25387@wolff.to> Message-ID: Bruno Wolff III wolff.to> writes: > I noticed that gdmsetup has gone away in rawhide, but I haven't been > able to find its replacement yet. Can someone provide some guidance here? 1. su - 2. yum install kdebase-workspace 3. sed -i -e 's/^DISPLAYMANAGER=/#DISPLAYMANAGER=/g' /etc/sysconfig/desktop 4. echo 'DISPLAYMANAGER="KDE"' >>/etc/sysconfig/desktop 5. systemsettings 6. set up KDM to your liking 7. be thankful for us not drinking the "there should be only one" kool-aid 8. enjoy! Kevin Kofler From rc040203 at freenet.de Sun Jan 27 06:41:41 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 27 Jan 2008 07:41:41 +0100 Subject: long term support release In-Reply-To: <479BE921.8080700@gmail.com> References: <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> <20080125152614.GA2975@free.fr> <20080125103335.0d5adacf@redhat.com> <20080125154127.GC2975@free.fr> <1201275741.1163.1.camel@localhost.localdomain> <20080125154749.GD2975@free.fr> <20080125105041.6605e470@redhat.com> <479A10D0.7020301@gmail.com> <200801251709.m0PH9iV5015900@laptop13.inf.utfsm.cl> <479B29B2.1070407@gmail.com> <479B7751.4050503@gmail.com> <200801270143.m0R1hvWa001619@laptop13.inf.utfsm.cl> <479BE921.8080700@gmail.com> Message-ID: <1201416101.17905.780.camel@beck.corsepiu.local> On Sat, 2008-01-26 at 20:14 -0600, Les Mikesell wrote: > Horst H. von Brand wrote: > > >>>> Upgrade to next Fedora. Gets easier each time around. A bit of foresight > >>>> when installing originally helps much here. > > > >>> Precisely. The update or upgrades are essentially very simple to > >>> handle when you've got a sane partitioning scheme setup. > > > >> I _really_ have to believe that you haven't run fedora over any span > >> of time across a variety of hardware > > > > I'm running Red Hat since Red Hat 3 or so, and then Fedora from 1. On an > > rather wide variety of machines (Alpha, SPARC and SPARC64, i386 to i686, > > x86_64, single/double/8x processor, ...). All the way as machines in a > > computer lab, day-to-day workstation, and servers. I am running Linux since its earliest days. After short periods of using SLS and Slackware, I was using SuSE for many years. Switched over to RHL around RH-8.0. Now Fedora, since its first days. Similar deployment scenarios as you. > > And yes, upgrading used to be a pain, but is is getting easier all the time. In comparison to RHN, things have improved significantly, but ... when switching to RH8 I had been shocked how many years behind RH's installer had been in comparison to SuSE's :-/ [The issues with their distro had been elsewhere, otherwise I would not have switched to RHL.] > I'm not convinced this is a predictable trend. Agreed. I think, there is a long term trend, nevertheless the short term trend has a noteworthy amplitude. >From my experience, I am inclined to consider FC7->FC8 had been swing downwards. Ralf From ville.skytta at iki.fi Sun Jan 27 08:32:05 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sun, 27 Jan 2008 10:32:05 +0200 Subject: Problems with bodhi and security updates Message-ID: <200801271032.05902.ville.skytta@iki.fi> Hi, xine-lib 1.1.10, another recent xine-lib security release, was released yesterday. I tried to get it shipped ASAP, but bodhi does not let me file a request to push it directly to stable. All the "mark as stable" etc functionality is visible in the UI, but when invoked, bodhi turns the request into a testing one (including when it's already in testing!) and tells me that it's waiting for security team approval. So, the result is that if I had not marked the package as a security update, it would be now in the updates repo. Now it's only in testing. Bodhi seems to be entirely happy with requesting non-security updates directly to stable, but security ones need to go through testing. To me this logic is the exact opposite of what it should be (if we want to prevent pushing directly to stable in the first place). What am I expected to do now? Do I need to wait/watch when the security team approval comes and then go try request it to be pushed to stable or will that happen automatically? I'm tempted to revoke the current request and file it again as a regular bugfix one so it could go directly to stable updates ASAP... (only half kidding) Also, there used to be a text box where I could enter the CVE numbers of security issues fixed by an update. I don't see it any more, was it removed on purpose? From nicolas.mailhot at laposte.net Sun Jan 27 09:04:56 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 27 Jan 2008 10:04:56 +0100 Subject: InstantMirror needs a rethink In-Reply-To: <10e0a9b00801261647u235f9e73q573f20c9d9f60dae@mail.gmail.com> References: <4797D5B3.7030002@redhat.com> <10e0a9b00801261647u235f9e73q573f20c9d9f60dae@mail.gmail.com> Message-ID: <1201424696.12758.8.camel@rousalka.dyndns.org> Le samedi 26 janvier 2008 ? 19:47 -0500, Jeffrey Tadlock a ?crit : > On Jan 23, 2008 7:02 PM, Warren Togami wrote: > > Today InstantMirror is pretty useful for home and small office mirrors, > > but its limitations make it unsustainable without manual intervention of > > the sysadmin. > At some point, a place that runs into some of the issues you outlined > will have outgrown InstantMirror and want to move to a more > traditional rsync'ed local mirror. Most places will have a transparent proxy with no additionnal Linux or RH-specific setup. Instantmirror or rsync local mirrors assume the infrastructure is designed around Fedora, when in fact Fedora installs have often started unofficially bottom up. It is critical for Fedora market penetration that those initial stealth installations go well without someone bothering the IT teams with them (because their first reaction will be to ban anything unofficial that gives them more work). Therefore, efforts to create the perfect Fedora-specific mirroring setup fall IMHO wide of the mark. A less-than-perfect system that works as-is with existing infrastructure without any specific setup is much more preferable. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From kevin.kofler at chello.at Sun Jan 27 09:11:04 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 27 Jan 2008 09:11:04 +0000 (UTC) Subject: Problems with bodhi and security updates References: <200801271032.05902.ville.skytta@iki.fi> Message-ID: Ville Skytt? iki.fi> writes: > So, the result is that if I had not marked the package as a security update, > it would be now in the updates repo. Now it's only in testing. Bodhi seems > to be entirely happy with requesting non-security updates directly to stable, > but security ones need to go through testing. To me this logic is the exact > opposite of what it should be (if we want to prevent pushing directly to > stable in the first place). I also think this additional "security team approval" bureaucracy is useless, unnecessary, highly annoying and counterproductive... > What am I expected to do now? Do I need to wait/watch when the security team > approval comes and then go try request it to be pushed to stable or will that > happen automatically? I'm tempted to revoke the current request and file it > again as a regular bugfix one so it could go directly to stable updates > ASAP... (only half kidding) ... and that's exactly what this will cause to happen, and I've been saying that ever since this was first discussed (but my concern was dismissed). Kevin Kofler From kevin.kofler at chello.at Sun Jan 27 09:18:25 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 27 Jan 2008 09:18:25 +0000 (UTC) Subject: Problems with bodhi and security updates References: <200801271032.05902.ville.skytta@iki.fi> Message-ID: One thing you could try: * change the type to Bugfix, * request push to stable, * change it back to Security. Unless they fixed that, it'll bypass the security team approval process. ;-) I accidentally discovered that because when I pushed the qimageblitz execstack fix, I requested a push to stable as a regular update, then realized it has security implications so I set the security flag, the result is that they're now sitting in stable and have "Security team approval: False". Kevin Kofler From pemboa at gmail.com Sun Jan 27 09:42:15 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Sun, 27 Jan 2008 03:42:15 -0600 Subject: InstantMirror needs a rethink In-Reply-To: <4797D5B3.7030002@redhat.com> References: <4797D5B3.7030002@redhat.com> Message-ID: <16de708d0801270142u75dd7612r3d6522056df8c92f@mail.gmail.com> On Jan 23, 2008 6:02 PM, Warren Togami wrote: > Today InstantMirror is pretty useful for home and small office mirrors, > but its limitations make it unsustainable without manual intervention of > the sysadmin. > > I've been beginning to think that perhaps InstantMirror is heading down > the wrong path and we seriously need to rethink it. There are simply > too many limitations of the current "stateless" operation of > InstantMirror where it runs only on-demand as mod_python script: > > - Synchronization/locking of multiple connections downloading the same > file is awkward and broken. > - There is no good way to clean up aborted tmp files. > - There is no good way to know what are old files that need pruning. > - There is no good way of keeping track of the "Big Picture" of its own > cache, "least recently used" knowing what files were unpopular locally > and should be pruned. > > https://fedorahosted.org/InstantMirror/wiki/InstantMirrorDaemon > We need a daemon to handle all this. Perhaps the daemon could allow > socket connections from a mod_python script for accesses. Or perhaps it > might be better for the daemon itself to handle serving connections. > > Stepping back, what we really need is: > A reverse proxy caching server with all the logic of squid or varnish, > except it stores its cache with file and directory names intact. > > How do we get there? > 1) Write a new daemon from scratch? > 2) Write a new backend storage engine for squid or varnish? (Store > files in target directory structure, store metadata elsewhere.) > 3) ??? > > Any thoughts? Am about to investigate on-demand style mirroring as opposed to rsync/ftp myself, and came across InstantMirror. What I have not yet been able to determine is what is the benefit of InstantMirror over just running squid and having yum always use said proxy?? (yum really should be able to independently use an http proxy) -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From abo at kth.se Sun Jan 27 10:13:39 2008 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Sun, 27 Jan 2008 11:13:39 +0100 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <1201184950.10257.50.camel@code.and.org> References: <479805C1.4080005@gmail.com> <797f919ef07923e0bf0802fcfd35a458@togami.com> <479824AA.3050108@gmail.com> <479843C5.7030800@redhat.com> <47989B23.80902@gmail.com> <1201184950.10257.50.camel@code.and.org> Message-ID: <1201428820.20656.57.camel@home.alexander.bostrom.net> tor 2008-01-24 klockan 09:29 -0500 skrev James Antill: > At the personal level this is likely better solved by having something > like "Have a zero-conf like service to share pacakges across the local > network". There has even been some work to do this. Wild idea: A yum plugin that short-circuits any downloading where the expected checksum of the data is known beforehand. It would first ask on the local network for the file, providing: * The baseurl or mirrorlist url. * The path relative to the root of the repo. * The name of the file. * The expected checksum. If no yum cache service is available on the network, no such service has a suitable file or the request times out (a short timeout, 1 second perhaps), the plugin would fall back to the baseurl or mirrors as usual. It would check both the checksum of the file and the GPG key (unless you've disabled that) so security-wise it shouldn't be much worse than just downloading the file from somewhere via FTP/HTTP. For the client, just install/enable the plugin and you're done. The server part could just serve data out of /var/cache/yum if it's there and the repo has been marked as public in the yum repo config. Maybe just run it on all hosts as well, marking all fedora repos as public by default? /abo From lordmorgul at gmail.com Sun Jan 27 11:46:57 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sun, 27 Jan 2008 03:46:57 -0800 Subject: Problems with bodhi and security updates In-Reply-To: References: <200801271032.05902.ville.skytta@iki.fi> Message-ID: <479C6F31.6080200@gmail.com> Kevin Kofler wrote: > One thing you could try: > * change the type to Bugfix, > * request push to stable, > * change it back to Security. > Unless they fixed that, it'll bypass the security team approval process. ;-) > > I accidentally discovered that because when I pushed the qimageblitz execstack > fix, I requested a push to stable as a regular update, then realized it has > security implications so I set the security flag, the result is that they're > now sitting in stable and have "Security team approval: False". Thats a rather ironic breakdown in the process I would think; a security fix should get out as rapidly as possible, but it should be verified to actually fix the security flaw as well... holding up the release of the fix to try it while other seemingly innocuous updates go out is just steeped in 'brokenness'. A change in process to have the security team verifying that fixes actually close the bugs they are supposed to close after the update is released sounds (to a guy outside the security review process) like a better idea. 1. package that fixes security flaw is built 2. push fix to testing (does it install? does it break other stuff?) 3. push fix to stable 4. security team checks that the security hole is really fixed, mark it so 5. otherwise tell maintainer to go back and do it again Its only increase in bandwidth for people who get the update (that might get replaced soon, and maybe doesn't fix the flaw). I'd rather have a maybe fix than a definitely not fixed yet, as long as some basic testing is still done. -- Andrew Farris www.lordmorgul.net gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From buildsys at redhat.com Sun Jan 27 11:49:37 2008 From: buildsys at redhat.com (Build System) Date: Sun, 27 Jan 2008 06:49:37 -0500 Subject: rawhide report: 20080127 changes Message-ID: <200801271149.m0RBnbC1007414@porkchop.devel.redhat.com> New package wavextract Program for extracting embedded audio data from JPEG images New package youtube-dl Small command-line program to download videos from YouTube Updated Packages: Miro-1.1-2.fc9 -------------- * Fri Jan 25 2008 Michel Salim - 1.1-2 - Fix charset mismatch in download window - Remove shebangs from scripts - Sanitize end-of-line markers abcde-2.3.99.6-6 ---------------- * Sat Jan 19 2008 Ville Skytt?? - 2.3.99.6-6 - Include fixes from Ubuntu's 2.3.99.6-1ubuntu2: enables M4A and Speex tagging, fixes range code, and the -M option. - Fix Speex comment tagging. - Fix some usage message spelling errors. - Drop disttag. blender-2.45-6.fc9 ------------------ * Sat Jan 26 2008 Alex Lancaster - 2.45-6 - Rebuild for new gettext blktrace-0.0-0.8.20080103162505.fc9 ----------------------------------- * Sat Jan 26 2008 Eric Sandeen - 0.0-0.8.20080103162505git - New upstream version enchant-1:1.3.0-3.fc9 --------------------- * Sat Jan 26 2008 Caolan McNamara 1:1.3.0-3.fc9 - Resolves: rhbz#426402 use system hunspell not internal one and split out aspell backend. - See: rhbz#430354 hspell backend disabled until pic issue fixed freeciv-2.1.3-1.fc9 ------------------- * Sat Jan 26 2008 Brian Pepple - 2.1.3-1 - Update to 2.1.3. gambas-1.0.19-5.fc9 ------------------- * Sat Jan 26 2008 Alex Lancaster - 1.0.19-5 - BuildRequires: kdelibs-devel -> kdelibs3-devel * Sat Jan 26 2008 Alex Lancaster - 1.0.19-4 - Rebuild for new gettext geda-gsymcheck-20071231-1.fc9 ----------------------------- * Tue Jan 22 2008 Chitlesh Goorah - 20071231-1 - New upstream release geda-utils-20071231-1.fc9 ------------------------- * Tue Jan 22 2008 Chitlesh Goorah - 20071231-1 - New upstream release gnome-power-manager-2.21.1-2.fc9 -------------------------------- * Sat Jan 26 2008 Matthias Clasen - 2.21.1-2 - Save some space gnucash-2.2.3-2.fc9 ------------------- * Fri Jan 25 2008 Bill Nottingham - 2.2.3-2 - rebuild against new goffice gnumeric-1:1.8.1-1.fc9 ---------------------- * Fri Jan 25 2008 Hans de Goede 1:1.8.1-1 - New upstream release 1.8.1 - Split of perl and libgda/libgnomedb plugins into gnumeric-plugins-extras gtk-nodoka-engine-0.6.90.2-1.fc9 -------------------------------- * Sat Jan 26 2008 Martin Sourada - 0.6.90.2-1 - Update to 0.7. beta 2 release - mostly bug fixes gtkdatabox-0.8.2.2-1.fc9 ------------------------ * Sat Jan 26 2008 Eric Work 0.8.2.2-1 - new upstream version kdebase-workspace-4.0.0-7.fc9 ----------------------------- * Sat Jan 26 2008 Kevin Kofler 4.0.0-7 - backport simple menu enhancement to show .desktop Name from 4.1 (kde#155362) kmenu-gnome-0.7-1.fc9 --------------------- * Sun Jan 20 2008 Ariszlo - 0.7-1 - release 0.7 - Works with both KDE3 & KDE4 libgda-1:3.1.2-2.fc9 -------------------- * Sat Jan 26 2008 Hans de Goede 1:3.1.2-2 - Rebuid now that the system sqlite has column metadata enabled, so that we use the system version instead of our own private copy (bz 430258) * Fri Jan 25 2008 Hans de Goede 1:3.1.2-1 - New upstream release 3.1.2 (needed for new gnumeric) - Drop upstreamed / no longer needed patches * Thu Dec 06 2007 Release Engineering - 3.0.1-6 - Rebuild for deps libsilc-1.1.5-2.fc9 ------------------- * Sat Jan 26 2008 Stu Tomlinson 1.1.5-2 - Link to system libidn instead of statically linking our own copy (#215934) - Reintroduce documentation subpackage - spec file cleanups - fix encoding of CREDITS file to be UTF-8 - Patch to fix buffer overflow generating fingerprints (#372021) lua-5.1.3-1.fc9 --------------- * Sat Jan 26 2008 Hans de Goede 5.1.3-1 - New upstream release 5.1.3 mod_security-2.1.5-2.fc9 ------------------------ * Sun Jan 27 2008 Michael Fleming 2.1.5-2 - Update to 2.1.5 (bz#425986) - "blocking" -> "optional_rules" per tarball ;-) openser-1.3.0-7.fc9 ------------------- * Sat Jan 26 2008 Jan ONDREJ (SAL) 1.3.0-7 - Updated syntax error in default config * Sat Jan 26 2008 Peter Lemenkov 1.3.0-5 - Merge of acc module into main package openvpn-2.1-0.23.rc6.fc9 ------------------------ * Fri Jan 25 2008 Steven Pritchard 2.1-0.23.rc6 - Apply update to BETA21-userpriv-fixups.patch from Alon Bar-Lev openvrml-0.17.4-1.fc9 --------------------- * Sat Jan 26 2008 Braden McDaniel - 0.17.4-1 - Updated to 0.17.4. perl-DateTime-Format-Builder-0.7901-1.fc9 ----------------------------------------- * Sat Jan 26 2008 Chris Weyl 0.7901-1 - update to 0.7901 - additional docs - some spec rework * Thu Aug 31 2006 Chris Weyl 0.7807-4 - bump for mass rebuild * Tue Aug 08 2006 Chris Weyl 0.7807-3 - bump for release & build, not in that order php-pear-Log-1.9.16-1.fc9 ------------------------- * Sat Jan 26 2008 Remi Collet 1.9.16-1 - update to 1.9.16 - add examples in documentation - add levels.patch http://pear.php.net/bugs/bug.php?id=12933 pinot-0.82-1.fc9 ---------------- * Sat Jan 26 2008 Adel Gadllah 0.82-1 - Update to 0.82 - Build with smp_flags ruby-gnome2-0.16.0-25.fc9 ------------------------- * Sat Jan 26 2008 Allisson Azevedo 0.16.0-25 - Fix libglade2 Undefined method error (bugzilla #428781) rxvt-unicode-9.0-1.fc9 ---------------------- * Sat Jan 26 2008 Andreas Bierfert - 9.0-1 - version upgrade scanssh-2.1-15.fc9 ------------------ * Sat Jan 26 2008 Alex Lancaster - 2.1-15 - Rebuild for new libevent. tor-0.1.2.18-4.fc9 ------------------ * Sat Jan 26 2008 Alex Lancaster - 0.1.2.18-4 - Update BuildRequires: tex(latex), - BR: texlive-texmf-fonts seems also to be necessary * Sat Jan 26 2008 Alex Lancaster - 0.1.2.18-3 - Rebuild for new libevent. * Thu Dec 06 2007 Release Engineering - 0.1.2.18-2 - Rebuild for deps vim-2:7.1.242-1.fc9 ------------------- * Sun Jan 27 2008 Karsten Hopp 7.1.242-1 - patchlevel 242 * Fri Jan 18 2008 Karsten Hopp 7.1.233-2 - silence taglist plugin (#429200) * Fri Jan 18 2008 Karsten Hopp 7.1.233-1 - patchlevel 233 - fix ada patch wget-1.11-1.fc9 --------------- xine-lib-1.1.10-2.fc9 --------------------- * Sun Jan 27 2008 Ville Skytt?? - 1.1.10-2 - Include spu, spucc, and spucmml decoders (#213597). * Sun Jan 27 2008 Ville Skytt?? - 1.1.10-1 - 1.1.10 (security update). * Mon Jan 21 2008 Ville Skytt?? - 1.1.9.1-3 - Fix version number in libxine.pc (#429487). zeroinstall-injector-0.31-1.fc8 ------------------------------- * Fri Jan 18 2008 Michel Salim - 0.31-1 - Update to 0.31 Broken deps for i386 ---------------------------------------------------------- 1:abiword-2.4.6-6.fc8.i386 requires libgoffice-1.so.2 compiz-kde-0.6.2-6.fc9.i386 requires libkdecorations.so.1 crystal-1.0.5-1.fc8.i386 requires libkdecorations.so.1 dekorator-0.3-3.fc7.i386 requires libkdecorations.so.1 epiphany-extensions-2.20.1-3.fc9.i386 requires libgtkembedmoz.so epiphany-extensions-2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 gnome-web-photo-0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo-0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo-0.3-8.fc9.i386 requires libgtkembedmoz.so gnome-web-photo-0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 kazehakase-0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 kicker-compiz-3.5.4-4.fc8.i386 requires libkickermain.so.1 kicker-compiz-3.5.4-4.fc8.i386 requires libtaskmanager.so.1 ksplash-engine-moodin-0.4.2-4.fc7.i386 requires libksplashthemes.so.0 memcached-1.2.4-2.fc9.i386 requires libevent-1.3b.so.1 muine-0.8.8-6.fc9.i386 requires mono(muine-plugin) = 0:1.0.0.0 Broken deps for x86_64 ---------------------------------------------------------- 1:abiword-2.4.6-6.fc8.x86_64 requires libgoffice-1.so.2()(64bit) compiz-kde-0.6.2-6.fc9.x86_64 requires libkdecorations.so.1()(64bit) crystal-1.0.5-1.fc8.x86_64 requires libkdecorations.so.1()(64bit) dekorator-0.3-3.fc7.x86_64 requires libkdecorations.so.1()(64bit) epiphany-extensions-2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) epiphany-extensions-2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo-0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) gnome-web-photo-0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo-0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo-0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) kazehakase-0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 kicker-compiz-3.5.4-4.fc8.x86_64 requires libkickermain.so.1()(64bit) kicker-compiz-3.5.4-4.fc8.x86_64 requires libtaskmanager.so.1()(64bit) ksplash-engine-moodin-0.4.2-4.fc7.x86_64 requires libksplashthemes.so.0()(64bit) memcached-1.2.4-2.fc9.x86_64 requires libevent-1.3b.so.1()(64bit) muine-0.8.8-6.fc9.x86_64 requires mono(muine-plugin) = 0:1.0.0.0 Broken deps for ppc ---------------------------------------------------------- 1:abiword-2.4.6-6.fc8.ppc requires libgoffice-1.so.2 anaconda-11.4.0.27-1.ppc requires dmidecode compiz-kde-0.6.2-6.fc9.ppc requires libkdecorations.so.1 crystal-1.0.5-1.fc8.ppc requires libkdecorations.so.1 dekorator-0.3-3.fc7.ppc requires libkdecorations.so.1 epiphany-extensions-2.20.1-3.fc9.ppc requires libgtkembedmoz.so epiphany-extensions-2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 gnome-web-photo-0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo-0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo-0.3-8.fc9.ppc requires libgtkembedmoz.so gnome-web-photo-0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 kazehakase-0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 kicker-compiz-3.5.4-4.fc8.ppc requires libkickermain.so.1 kicker-compiz-3.5.4-4.fc8.ppc requires libtaskmanager.so.1 ksplash-engine-moodin-0.4.2-4.fc7.ppc requires libksplashthemes.so.0 memcached-1.2.4-2.fc9.ppc requires libevent-1.3b.so.1 monodevelop-0.17-4.fc9.ppc requires boo muine-0.8.8-6.fc9.ppc requires mono(muine-plugin) = 0:1.0.0.0 Broken deps for ppc64 ---------------------------------------------------------- 1:abiword-2.4.6-6.fc8.ppc64 requires libgoffice-1.so.2()(64bit) anaconda-11.4.0.27-1.ppc64 requires dmidecode crystal-1.0.5-1.fc8.ppc64 requires libkdecorations.so.1()(64bit) dekorator-0.3-3.fc7.ppc64 requires libkdecorations.so.1()(64bit) epiphany-extensions-2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) epiphany-extensions-2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo-0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) gnome-web-photo-0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo-0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo-0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) kazehakase-0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 kicker-compiz-3.5.4-4.fc8.ppc64 requires libkickermain.so.1()(64bit) kicker-compiz-3.5.4-4.fc8.ppc64 requires libtaskmanager.so.1()(64bit) ksplash-engine-moodin-0.4.2-4.fc7.ppc64 requires libksplashthemes.so.0()(64bit) memcached-1.2.4-2.fc9.ppc64 requires libevent-1.3b.so.1()(64bit) perl-Test-AutoBuild-darcs-1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 From fedora at leemhuis.info Sun Jan 27 11:55:18 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 27 Jan 2008 12:55:18 +0100 Subject: EPEL report week 04/2008 Message-ID: <479C7126.3000803@leemhuis.info> http://fedoraproject.org/wiki/EPEL/Reports/Week04 = Weekly EPEL Summary = Week 04/2008 == Most important happenings == * We have now more then 1000 different software packages (counting SRPMs) in the EPEL5 repositories for RHEL5/CentOS5. Thanks to all Fedora contributers that participate in EPEL! You made this happen! == Mailing list == === Noteworthy discussions === * [https://www.redhat.com/archives/epel-devel-list/2008-January/msg00156.html livecd-tools for EPEL] * [https://www.redhat.com/archives/epel-devel-list/2008-January/msg00130.html Conflicts in EPEL] * [https://www.redhat.com/archives/epel-devel-list/2008-January/msg00115.html Package EVR problems in EPEL] == Meeting == === Next Meeting === Wednesday, 20080130 at 18:00 UTC in #fedora-meeting. === Last weeks meeting === There was no meeting scheduled for the past week. == Stats == === General === Number of EPEL Contributors: 169 We welcome 3 new contributors: emunson gouldwp jfearn === EPEL 5 === Number of source packages: 1019 Number of binary packages: 1913 There are 27 new Packages: * ddclient | Client to update dynamic DNS host entries * fftw2 | Fast Fourier Transform library * grace | Numerical Data Processing and Visualization Tool * kscope | KDE front-end to Cscope * libvpd | VPD Database access library for lsvpd * mimetex | Easily embed LaTeX math in web pages * mogilefs-server | Server part of the MogileFS distributed filesystem * nedit | A GUI text editor for systems with X * nickle | A programming language-based prototyping environment * openser | Open Source SIP Server * ovaldi | Reference implementation of the OVAL interpreter * pam_mysql | PAM module for auth UNIX users using MySQL data base * perl-Alien-wxWidgets | Building, finding and using wxWidgets binaries * perl-DBIx-ContextualFetch | Add contextual fetches to DBI * perl-ExtUtils-PkgConfig | Simplistic interface to pkg-config * perl-File-Tail | Perl extension for reading from continously updated files * perl-Net-NBName | NetBIOS Name Service Requests * perl-SNMP-Info | Object Oriented Perl5 Interface to Network devices and MIBs through SNMP * perl-Sub-Uplevel | Run a perl function in an upper stack frame * perl-Test-Exception | Library of test functions for exception based Perl code * perl-Test-MockModule | Override subroutines in a module for unit testing * perl-Tie-IxHash | Ordered associative arrays for Perl * perl-UNIVERSAL-can | Hack around people calling UNIVERSAL::can() as a function * perl-UNIVERSAL-isa | Hack around module authors using UNIVERSAL::isa as a function * postgresql-ip4r | IPv4 and IPv4 range index types for PostgreSQL * unpaper | Post-processing of scanned and photocopied book pages * vnc-ltsp-config | Easy Enabler of VNC remote LTSP desktops === EPEL 4 === Number of source packages: 618 Number of binary packages: 1150 There are 18 new Packages: * ddclient | Client to update dynamic DNS host entries * kscope | KDE front-end to Cscope * libevent | Abstract asynchronous event notification library * libvpd | VPD Database access library for lsvpd * mimetex | Easily embed LaTeX math in web pages * ovaldi | Reference implementation of the OVAL interpreter * pam_mysql | PAM module for auth UNIX users using MySQL data base * perl-Alien-wxWidgets | Building, finding and using wxWidgets binaries * perl-DBIx-ContextualFetch | Add contextual fetches to DBI * perl-ExtUtils-PkgConfig | Simplistic interface to pkg-config * perl-File-Remove | Convenience module for removing files and directories * perl-File-Tail | Perl extension for reading from continously updated files * perl-Sub-Uplevel | Run a perl function in an upper stack frame * perl-Test-Exception | Library of test functions for exception based Perl code * perl-Test-Manifest | Test case module for Perl * perl-Test-MockModule | Override subroutines in a module for unit testing * perl-Tie-IxHash | Ordered associative arrays for Perl * perl-UNIVERSAL-isa | Hack around module authors using UNIVERSAL::isa as a function ---- ["CategoryEPELReports"] From sebastian at when.com Sun Jan 27 12:00:59 2008 From: sebastian at when.com (sebastian at when.com) Date: Sun, 27 Jan 2008 13:00:59 +0100 Subject: Fedora Education Spin In-Reply-To: <479BE80A.5080309@fedoraproject.org> References: <479B4B6A.90805@when.com> <50baabb30801261000g690bfc40w80fdff6cca0efd35@mail.gmail.com> <479B85DD.5090406@when.com> <479B890A.3030903@fedoraproject.org> <20080126194213.1a466781@redhat.com> <479BD6C7.3010608@fedoraproject.org> <20080126195027.0cefe0ad@redhat.com> <479BDAA4.6070304@fedoraproject.org> <20080127025259.32e47cee@lain.camperquake.de> <479BE80A.5080309@fedoraproject.org> Message-ID: <479C727B.7060308@when.com> Rahul Sundaram wrote: >>> I think you are drastically underestimating the value of this >>> fitting into a CD and more granularity in packages. It *is* a big deal. >> And I think you're limited by the assumption that the only way to run >> or install a Live image is by running a CD sized media. It's not. I agree with Rahul, that there are cases, in which the cds are the better solution. And I think, if it's possible to put a spin on a cd, we should do so. This prevents us - by the way - from bloating the spin with packages with the same function ;). But have a look at kdeedu - even together with a small Gnome desktop, the spin has approx. 1 GB! And that's the point where you need to rethink, what you want to do. If you want to have an educational spin with all the well known apps (kdeedu, gcompris, stellarium,...) on it, then it's clear, that you'll will need a dvd, because this are the larger apps. But that's not a huge problem, because we are in a time, where a dvd is nearly the normal case (ok, this might not be true for the whole world...). But then, you must still have a look at the software you are going to include. For example the openSUSE project has an educational part, which creates repos and isos with educational content: Their dvd has currently approx. 5.1 GB! If we want to include everything, which has to do with education on a disc, we should consider to refer the user to some kind of documentation, what which software does, so that newcomers have a chance of getting into the whole thing. Otherwise, they will be lost in the number of packages... I think, in our case, both (a cd and a dvd) is possible: We could create a dvd, e.g. in collaboration with k12ltsp, which could then include a terminal server, and put educational apps on it. But I would also suggest a cd with a selection (!) of educational software, which might for example also be given to pupils by their teachers... therefore the cd should not be too bloated (e.g. only contain one program per category - not three periodic systems for chemistry!). I will have a look at a new build, which could probably include gcompris... And Jeff: > Speaking of which, you know what would be cool... for some spins that > we know are in the half-baked phase, it would be cool if there was an > icon on the desktop that basically sent the spin user to a feedback > questioniare about the spin. So we can get feedback from people > who..took it for a spin..but don't plan to keep using it. > I really like this idea! Sounds like a really nice way, to get some suggestions from the users 'out there' ;)... Sebastian From mschwendt.tmp0701.nospam at arcor.de Sun Jan 27 12:38:03 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 27 Jan 2008 13:38:03 +0100 Subject: EPEL report week 04/2008 In-Reply-To: <479C7126.3000803@leemhuis.info> References: <479C7126.3000803@leemhuis.info> Message-ID: <20080127133803.c96df191.mschwendt.tmp0701.nospam@arcor.de> On Sun, 27 Jan 2008 12:55:18 +0100, Thorsten Leemhuis wrote: > http://fedoraproject.org/wiki/EPEL/Reports/Week04 > > = Weekly EPEL Summary = > > Week 04/2008 > > == Most important happenings == > > * We have now more then 1000 different software packages (counting SRPMs) in the EPEL5 repositories for RHEL5/CentOS5. Thanks to all Fedora contributers that participate in EPEL! You made this happen! > $ pwd /srv/rpmbuild/epel/tree/epel/5/SRPMS $ rpm -qp --qf %{name}\\n *.src.rpm|sort|uniq|wc -l 808 $ pwd /srv/rpmbuild/epel/tree/epel/4/SRPMS $ rpm -qp --qf %{name}\\n *.src.rpm|sort|uniq|wc -l 567 -- Michael Schwendt Fedora release 8 (Werewolf) - Linux 2.6.23.14-107.fc8 loadavg: 1.05 1.18 1.09 From fedora at leemhuis.info Sun Jan 27 12:40:52 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 27 Jan 2008 13:40:52 +0100 Subject: EPEL report week 04/2008 In-Reply-To: <20080127133803.c96df191.mschwendt.tmp0701.nospam@arcor.de> References: <479C7126.3000803@leemhuis.info> <20080127133803.c96df191.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <479C7BD4.7040303@leemhuis.info> On 27.01.2008 13:38, Michael Schwendt wrote: > On Sun, 27 Jan 2008 12:55:18 +0100, Thorsten Leemhuis wrote: > >> http://fedoraproject.org/wiki/EPEL/Reports/Week04 >> >> = Weekly EPEL Summary = >> >> Week 04/2008 >> >> == Most important happenings == >> >> * We have now more then 1000 different software packages (counting SRPMs) in the EPEL5 repositories for RHEL5/CentOS5. Thanks to all Fedora contributers that participate in EPEL! You made this happen! > $ pwd > /srv/rpmbuild/epel/tree/epel/5/SRPMS > $ rpm -qp --qf %{name}\\n *.src.rpm|sort|uniq|wc -l > 808 That number includes testing. CU knurd From mschwendt.tmp0701.nospam at arcor.de Sun Jan 27 12:51:14 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 27 Jan 2008 13:51:14 +0100 Subject: EPEL report week 04/2008 In-Reply-To: <479C7BD4.7040303@leemhuis.info> References: <479C7126.3000803@leemhuis.info> <20080127133803.c96df191.mschwendt.tmp0701.nospam@arcor.de> <479C7BD4.7040303@leemhuis.info> Message-ID: <20080127135114.73334cad.mschwendt.tmp0701.nospam@arcor.de> On Sun, 27 Jan 2008 13:40:52 +0100, Thorsten Leemhuis wrote: > > > On 27.01.2008 13:38, Michael Schwendt wrote: > > On Sun, 27 Jan 2008 12:55:18 +0100, Thorsten Leemhuis wrote: > > > >> http://fedoraproject.org/wiki/EPEL/Reports/Week04 > >> > >> = Weekly EPEL Summary = > >> > >> Week 04/2008 > >> > >> == Most important happenings == > >> > >> * We have now more then 1000 different software packages (counting SRPMs) in the EPEL5 repositories for RHEL5/CentOS5. Thanks to all Fedora contributers that participate in EPEL! You made this happen! > > $ pwd > > /srv/rpmbuild/epel/tree/epel/5/SRPMS > > $ rpm -qp --qf %{name}\\n *.src.rpm|sort|uniq|wc -l > > 808 > > That number includes testing. Ah! ;) From sgrubb at redhat.com Sun Jan 27 13:23:56 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Sun, 27 Jan 2008 08:23:56 -0500 Subject: space on the live cds In-Reply-To: <1201366447.3282.8.camel@localhost.localdomain> References: <1201366447.3282.8.camel@localhost.localdomain> Message-ID: <200801270823.56608.sgrubb@redhat.com> On Saturday 26 January 2008 11:54:07 Matthias Clasen wrote: > ? - policycoreutils-gui pulls in selinux-policy-devel, which in turn > ? ? pulls in checkpolicy. Why ? In the SE Linux management interface, you can create a custom policy module or make adjustments to user roles. Its uses macros and interfaces defined in the main policy. So, you need the policy source and policy compiler in case you want to do this. -Steve From szaka at ntfs-3g.org Sun Jan 27 13:35:33 2008 From: szaka at ntfs-3g.org (Szabolcs Szakacsits) Date: Sun, 27 Jan 2008 13:35:33 +0000 (UTC) Subject: F9 Alpha spinning References: <20080125162835.GA19048@crow> Message-ID: Kevin Kofler chello.at> writes: > Szabolcs Szakacsits ntfs-3g.org> writes: > > > > http://article.gmane.org/gmane.comp.file-systems.ntfs-3g.devel/392 > > Well, your arguments are pretty unconvincing, and apply to a lot of > application-library relationships, still usually library users won't fork a > library just for that, or when they do, Fedora won't ship their fork. This is the only way currently we can afford to assure best reliability, which is the highest priority for the project. If a file system driver fails then a reboot, package upgrade/downgrade, or fsck won't guarantee users will get back their lost data. We prefer to avoid such scenarios, or if they still happen then solve them as fast as possible. We have worked hard not to make the above mandatory, so if one prefers to use --with-fuse=external and take the responsibility then he is able to do so. > Your worries about old FUSE versions being used are also unfounded The reliability problems weren't only coming from the old FUSE versions. That's a pretty easy case: upgrade. But they were also coming from the always current one and potentially from future ones untested with the driver. The main point is that we can guarantee now at least this http://ntfs-3g.org/quality.html independently of the used old, current or future FUSE user space. Szaka -- NTFS-3G: http://ntfs-3g.org From kevin.kofler at chello.at Sun Jan 27 15:09:28 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 27 Jan 2008 15:09:28 +0000 (UTC) Subject: Problems with bodhi and security updates References: <200801271032.05902.ville.skytta@iki.fi> Message-ID: One more thing: you're quick to blame the security team approval process when it delays your Fedora 8 update, but this is already the third update you're pushing to Fedora 7 updates-testing, with now 2 CVEs fixed, and you appear not to have requested a push to stable for any. I know you can't personally test the package on all distributions, but this is the case of a security update, which should be pushed as soon as possible, not held for testing. If you're using the same specfile, chances are the security fix will work on all distros if it works on one, and that's really the most important thing in a security update. But also in other cases, distro-version-specific breakage is rare, it usually only happens if the different Fedora versions are patched differently and for one the patch is broken or not applied properly. In this case, everything is updated to the latest upstream version (which includes the patches already), so any breakage will (usually) be seen the same way everywhere, it doesn't make sense to make it wait longer for some versions than for others. Many maintainers don't even test their NON-security updates on all Fedora versions before they push them. (Hey, you're lucky if they even tested it on ANY distro. ;-) ) You may think that's a bad idea, but at least for security updates, I think getting it out quickly is more important. Kevin Kofler From jeffreyt at fedoraproject.org Sun Jan 27 15:30:13 2008 From: jeffreyt at fedoraproject.org (Jeffrey Tadlock) Date: Sun, 27 Jan 2008 10:30:13 -0500 Subject: InstantMirror needs a rethink In-Reply-To: <1201424696.12758.8.camel@rousalka.dyndns.org> References: <4797D5B3.7030002@redhat.com> <10e0a9b00801261647u235f9e73q573f20c9d9f60dae@mail.gmail.com> <1201424696.12758.8.camel@rousalka.dyndns.org> Message-ID: <10e0a9b00801270730y187eb33csc3fb4621ee392fae@mail.gmail.com> 2008/1/27 Nicolas Mailhot : > Most places will have a transparent proxy with no additionnal Linux or > RH-specific setup. Instantmirror or rsync local mirrors assume the > infrastructure is designed around Fedora, when in fact Fedora installs > have often started unofficially bottom up. It is critical for Fedora > market penetration that those initial stealth installations go well > without someone bothering the IT teams with them (because their first > reaction will be to ban anything unofficial that gives them more work). I can see larger networks having transparent proxies and such setup, but the home user enthusiast or small business? I don't think they would be as likely. I see InstantMirror of filling a niche for the small office or home user enthusiast as a low barrier entry into caching updates locally. There is a thread on fedora-list now with a Fedora user looking to setup some form of caching for updates and such [1]. InstantMirror seems an option to fit these need well. > Therefore, efforts to create the perfect Fedora-specific mirroring setup > fall IMHO wide of the mark. A less-than-perfect system that works as-is > with existing infrastructure without any specific setup is much more > preferable. This is more to the point I was trying to make. Should InstantMirror be trying to be the perfect Fedora-specific mirroring setup? I think it is a good tool for the small office and home user enthusiast niche. The ones just looking to cache updates locally with minimal fuss without the need to maintain a full fledged local mirror or implement a transparent proxy. Maintaining as such a tool might be a better goal for the InstantMirror project than trying to grow it into a tool that it is not. Best Regards, Jeffrey [1] https://www.redhat.com/archives/fedora-list/2008-January/msg04152.html From warren at togami.com Sun Jan 27 16:05:57 2008 From: warren at togami.com (Warren Togami) Date: Sun, 27 Jan 2008 11:05:57 -0500 Subject: InstantMirror needs a rethink In-Reply-To: <10e0a9b00801270730y187eb33csc3fb4621ee392fae@mail.gmail.com> References: <4797D5B3.7030002@redhat.com> <10e0a9b00801261647u235f9e73q573f20c9d9f60dae@mail.gmail.com> <1201424696.12758.8.camel@rousalka.dyndns.org> <10e0a9b00801270730y187eb33csc3fb4621ee392fae@mail.gmail.com> Message-ID: <479CABE5.1030808@togami.com> Jeffrey Tadlock wrote: > > This is more to the point I was trying to make. Should InstantMirror > be trying to be the perfect Fedora-specific mirroring setup? I think > it is a good tool for the small office and home user enthusiast niche. > The ones just looking to cache updates locally with minimal fuss > without the need to maintain a full fledged local mirror or implement > a transparent proxy. Maintaining as such a tool might be a better > goal for the InstantMirror project than trying to grow it into a tool > that it is not. Today: Hey great! I installed InstantMirror and it is working great! That was easy! 3 months from now: Hey, why did all my applications stop working? Warren From a.badger at gmail.com Sun Jan 27 16:16:09 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 27 Jan 2008 08:16:09 -0800 Subject: Package Versioning Feedback In-Reply-To: <1201388474.21660.1.camel@localhost6.localdomain6> References: <1201384332.32282.16.camel@localhost6.localdomain6> <20080126235013.208dbc68.mschwendt.tmp0701.nospam@arcor.de> <1201388474.21660.1.camel@localhost6.localdomain6> Message-ID: <479CAE49.1090207@gmail.com> Richi Plana wrote: > On Sat, 2008-01-26 at 23:50 +0100, Michael Schwendt wrote: >> On Sat, 26 Jan 2008 14:52:12 -0700, Richi Plana wrote: >> >>> Hi, >>> >>> I wanted to start my own little project and wanted some feedback from >>> the community who've had much dealings with versioning. My plan is to >>> use a versioning system similar to most (digits separated by a dot >>> character) with each successive number being less significant. The only >>> change in semantics is that the most minor number would be interpreted >>> as >>> >>> 0 = Alpha >>> 1 = Beta >>> 3+ = Stable >>> >>> I thought this might be a better way of dealing with projects which >>> transition to a greater major number. Systems which use .99+ to >>> designate "almost next major" aren't easy to test as the next major >>> version (since the computer parses the major version and sees the >>> previous major version. >>> >>> Some systems increase the major and tack on the word "alpha" or >>> "beta" ... which screws up the computer's sorting mechanism (is alpha > >>> 0?) >>> >>> My question is: will there be any problems with packaging systems like >>> rpm and yum using such a scheme? >> It depends on what your numbers look like. Preferably, use only natural >> numbers (as they can be compared with each other in a well-defined way), >> and don't make up your own notation for the numbers. In particular, never >> use any numbers with 0 prefix, not in the least significant position >> either. For RPM, 2 and 02 and 000002 are equal. Hence 1.1 is smaller than >> 1.02, but equal to 1.01. And a 1.3001 release, which may look like a >> very minor release after 1.3, would be higher than all 1.X with X < 3001, >> including 1.4, 1.50, 1.99 and so on. >> >> As a side-note, adding non-numerical characters somewhere to a version >> number string not only compares numbers to characters, it alters the >> length of what is compared. Due to that, the longer version wins, as in >> 1.3.0 is lower than 1.3.0a or 1.3.0rc2 > > That's exactly why I'm interested in adopting the aforementioned > semantic. And yes, I'll be sticking to decimal digits. > > For example, 1.3.0 is the alpha of the 1.3 series. 1.3.1 is the beta and > 1.3.2, 1.3.3, etc. are the stable. That way if I wanted to bump it up to > 1.4, for testers they'd be using 1.4.0 as alpha. rpm will order this correctly. However, it is highly non-standard and will confuse a lot of people. (Just think about when you release 1.0.0 To the rest of the world this would signify a major milestone has been reached but for your project it would mean you're just getting started.) I would actually ask you not to do this as the world doesn't need another versioning scheme. The use of a high number to denote a prerelease actually works well if you do it right. Look at this sequence, for instance: 1.0 <= stable 1.0.1 <= 1.0 bugfix 1.0.2 <= 1.0 bugfix2 1.0.90.0 <= alpha 1.0.90.1 <= alpha2 1.0.90.2 <= alpha3 1.0.95.0 <= beta 1.0.95.1 <= beta2 1.0.99.0 <= release candidate 1.1 <= final This is easily read by both a human and a computer. As long as you don't have 90 bugfix releases between 1.0 and 1.1 you won't collide. (And you can either use a larger number .900, .950, .999 right off or add another dot and number if you find out too late: 1.0.89.1, 1.0.89.2, etc) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From lesmikesell at gmail.com Sun Jan 27 16:36:51 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sun, 27 Jan 2008 10:36:51 -0600 Subject: InstantMirror needs a rethink In-Reply-To: <10e0a9b00801270730y187eb33csc3fb4621ee392fae@mail.gmail.com> References: <4797D5B3.7030002@redhat.com> <10e0a9b00801261647u235f9e73q573f20c9d9f60dae@mail.gmail.com> <1201424696.12758.8.camel@rousalka.dyndns.org> <10e0a9b00801270730y187eb33csc3fb4621ee392fae@mail.gmail.com> Message-ID: <479CB323.8040304@gmail.com> Jeffrey Tadlock wrote: >> Most places will have a transparent proxy with no additionnal Linux or >> RH-specific setup. Instantmirror or rsync local mirrors assume the >> infrastructure is designed around Fedora, when in fact Fedora installs >> have often started unofficially bottom up. It is critical for Fedora >> market penetration that those initial stealth installations go well >> without someone bothering the IT teams with them (because their first >> reaction will be to ban anything unofficial that gives them more work). > > I can see larger networks having transparent proxies and such setup, > but the home user enthusiast or small business? I don't think they > would be as likely. I see InstantMirror of filling a niche for the > small office or home user enthusiast as a low barrier entry into > caching updates locally. There is a thread on fedora-list now with a > Fedora user looking to setup some form of caching for updates and such > [1]. InstantMirror seems an option to fit these need well. Anyone who could set up InstantMirror could just as easily start a squid and run: http_proxy=http://my_proxy:3128 yum update The issue that squid is somewhat more complicated to configure is offset by the fact that it is also generally useful for other caching/proxy tasks. > This is more to the point I was trying to make. Should InstantMirror > be trying to be the perfect Fedora-specific mirroring setup? I think > it is a good tool for the small office and home user enthusiast niche. What's the point of a fedora-specific anything? Extra work just to make fedora behave in a real-world infrastructure? Why not make a configuration tool for squid and make yum behave better with proxies instead? That way things 'just work' in the many locations that already have local caching proxies without storing yet another copy and places that don't have one could easily. Fedora could be providing a generally useful tool to a small office instead of requiring the extra work of a distro-specific package setup. > The ones just looking to cache updates locally with minimal fuss > without the need to maintain a full fledged local mirror or implement > a transparent proxy. The proxy doesn't have to be configured to be transparent, but that can be a useful option too. -- Les Mikesell lesmikesell at gmail.com From nicolas.mailhot at laposte.net Sun Jan 27 17:04:08 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 27 Jan 2008 18:04:08 +0100 Subject: InstantMirror needs a rethink In-Reply-To: <10e0a9b00801270730y187eb33csc3fb4621ee392fae@mail.gmail.com> References: <4797D5B3.7030002@redhat.com> <10e0a9b00801261647u235f9e73q573f20c9d9f60dae@mail.gmail.com> <1201424696.12758.8.camel@rousalka.dyndns.org> <10e0a9b00801270730y187eb33csc3fb4621ee392fae@mail.gmail.com> Message-ID: <1201453448.13299.7.camel@rousalka.dyndns.org> Le dimanche 27 janvier 2008 ? 10:30 -0500, Jeffrey Tadlock a ?crit : > 2008/1/27 Nicolas Mailhot : > I can see larger networks having transparent proxies and such setup, > but the home user enthusiast or small business? I don't think they > would be as likely. Open your eyes then. A transparent proxy is a general purpose tool many entities use, it may come in an appliance, have been installed by a third-party years ago, depend on a different department, etc Just because one or several users have the access needed to deploy Fedora on a few computers does not mean they can touch the associated infrastructure > I see InstantMirror of filling a niche for the > small office or home user enthusiast as a low barrier entry into > caching updates locally. It only fills a niche for entities which have already decided to invest heavily in Fedora (and it does not change with entity size, since a huge corp will have to pass all sorts of internal procedures & budget reviews to deploy it, and a single home user will have to devote comparatively a lot of time to find and set it up). Ergo in terms of market penetration help it's useless. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From lesmikesell at gmail.com Sun Jan 27 17:11:05 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sun, 27 Jan 2008 11:11:05 -0600 Subject: InstantMirror needs a rethink In-Reply-To: <16de708d0801270142u75dd7612r3d6522056df8c92f@mail.gmail.com> References: <4797D5B3.7030002@redhat.com> <16de708d0801270142u75dd7612r3d6522056df8c92f@mail.gmail.com> Message-ID: <479CBB29.9050904@gmail.com> Arthur Pemberton wrote: > Am about to investigate on-demand style mirroring as opposed to > rsync/ftp myself, and came across InstantMirror. What I have not yet > been able to determine is what is the benefit of InstantMirror over > just running squid and having yum always use said proxy?? (yum really > should be able to independently use an http proxy) Yum can/does use an http proxy if you either explicitly configure it or export http_proxy=http://my_proxy:port in the environment. However the default mirrorlist behavior will randomize the URLs so different machines behind the proxy will make different requests that will be cached but not reused. And an assortment of things can go wrong if repo files are changed, but these problems could also happen in the time span of a single update without a proxy. -- Les Mikesell lesmikesell at gmail.com From lmacken at redhat.com Sun Jan 27 17:27:42 2008 From: lmacken at redhat.com (Luke Macken) Date: Sun, 27 Jan 2008 12:27:42 -0500 Subject: Problems with bodhi and security updates In-Reply-To: <200801271032.05902.ville.skytta@iki.fi> References: <200801271032.05902.ville.skytta@iki.fi> Message-ID: <20080127172742.GB3054@crow> On Sun, Jan 27, 2008 at 10:32:05AM +0200, Ville Skytt? wrote: > Hi, > > xine-lib 1.1.10, another recent xine-lib security release, was released > yesterday. I tried to get it shipped ASAP, but bodhi does not let me file a > request to push it directly to stable. All the "mark as stable" etc > functionality is visible in the UI, but when invoked, bodhi turns the request > into a testing one (including when it's already in testing!) and tells me > that it's waiting for security team approval. > > So, the result is that if I had not marked the package as a security update, > it would be now in the updates repo. Now it's only in testing. Bodhi seems > to be entirely happy with requesting non-security updates directly to stable, > but security ones need to go through testing. To me this logic is the exact > opposite of what it should be (if we want to prevent pushing directly to > stable in the first place). This extra security approval step exists to ensure that someone on the security team looks at your update and makes sure that it contains all of the relevant bugs, that those bugs are properly cloned across releases, that a CVE is requested if it doesn't exist, that the parent bug is properly marked/aliased, that your update notes are accurate, and so on... See our security bug tracking procedure[0] for more details on the process. > What am I expected to do now? Do I need to wait/watch when the security team > approval comes and then go try request it to be pushed to stable or will that > happen automatically? I'm tempted to revoke the current request and file it > again as a regular bugfix one so it could go directly to stable updates > ASAP... (only half kidding) You're expected to go off and do something productive. Once the security team approves your update, it will go straight to stable. This "feature" doesn't add any extra steps in your workflow, it simply incorporates the workflow of our security team into the updates process. > Also, there used to be a text box where I could enter the CVE numbers of > security issues fixed by an update. I don't see it any more, was it removed > on purpose? Yes. We track CVEs using bugzilla now[0]. luke [0]: http://fedoraproject.org/wiki/Security/TrackingBugs From lesmikesell at gmail.com Sun Jan 27 17:29:03 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sun, 27 Jan 2008 11:29:03 -0600 Subject: Fedora Education Spin In-Reply-To: <479C727B.7060308@when.com> References: <479B4B6A.90805@when.com> <50baabb30801261000g690bfc40w80fdff6cca0efd35@mail.gmail.com> <479B85DD.5090406@when.com> <479B890A.3030903@fedoraproject.org> <20080126194213.1a466781@redhat.com> <479BD6C7.3010608@fedoraproject.org> <20080126195027.0cefe0ad@redhat.com> <479BDAA4.6070304@fedoraproject.org> <20080127025259.32e47cee@lain.camperquake.de> <479BE80A.5080309@fedoraproject.org> <479C727B.7060308@when.com> Message-ID: <479CBF5F.80807@gmail.com> sebastian at when.com wrote: > I think, in our case, both (a cd and a dvd) is possible: We could create > a dvd, e.g. in collaboration with k12ltsp, which could then include a > terminal server, and put educational apps on it. But I would also > suggest a cd with a selection (!) of educational software, which might > for example also be given to pupils by their teachers... therefore the > cd should not be too bloated (e.g. only contain one program per category > - not three periodic systems for chemistry!). Would it be possible to build a 1-CD base install that would then give you the option of doing a 'yum groupinstall some_big_set' if you have a good internet connection, or installing that set from a separate CD that does not have any of the base system on it? That way you don't have to respin a bazillion copies of the base system just to get some slightly customized variations, and people with decent internet connections don't have to download and install images that will always be out of date anyway. If you don't want to bother setting up the infrastructure for yum groupinstall, just provide a script that puts the whole list on the yum command line - or make a metapackage with all the others as dependencies. -- Les Mikesell lesmikesell at gmail.com From michel.sylvan at gmail.com Sun Jan 27 17:39:13 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Sun, 27 Jan 2008 12:39:13 -0500 Subject: [Guideline] Release number for rebuilds Message-ID: Hi all, I just noticed a mismatch in multisync: F8's 0.91.0-3 removes an unneeded build dependency, but F9's 0.91.0-3 is just a rebuild against a newer version of libopensync (and never appeared in Rawhide, for some reason). Do we have a guideline for how to bump revision numbers for rebuilds? It would seem to me that standardizing on adding a 'build number' to the release number works better: i.e. 3%{?dist} -> 3%{?dist}.1, 3%{?dist}.2, etc. That way, when someone updates the stable version and forgot to update in -devel (ideally this won't happen anyway), sooner or later we'll notice the N-V-R problem. Thoughts? Regards, -- Michel Salim http://hircus.jaiku.com/ From nicolas.mailhot at laposte.net Sun Jan 27 17:40:03 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 27 Jan 2008 18:40:03 +0100 Subject: InstantMirror needs a rethink In-Reply-To: <479CBB29.9050904@gmail.com> References: <4797D5B3.7030002@redhat.com> <16de708d0801270142u75dd7612r3d6522056df8c92f@mail.gmail.com> <479CBB29.9050904@gmail.com> Message-ID: <1201455603.13299.14.camel@rousalka.dyndns.org> Le dimanche 27 janvier 2008 ? 11:11 -0600, Les Mikesell a ?crit : > Yum can/does use an http proxy if you either explicitly configure it or > export http_proxy=http://my_proxy:port in the environment. However the > default mirrorlist behavior will randomize the URLs so different > machines behind the proxy will make different requests that will be > cached but not reused. This particular bit could be solved by replacing the current mirrorlist interface http://mirrors.fedoraproject.org/mirrorlist?repo=rawhide&arch=$basearch with REST-like URLs (using redirects in Apache, whatever) http://mirrors.fedoraproject.org/mirrorlist/rawhide/$basearch In the first case the proxy knows the mirrorlist is dynamic and won't cache it (causing different clients in the network to use different mirrors) In the second case it will cache it as any other static page, directing every client behind the proxy to the same source. Bonus points for figuring what is the right expire value to send with those pages to control proxy source balancing. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From rc040203 at freenet.de Sun Jan 27 18:06:57 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 27 Jan 2008 19:06:57 +0100 Subject: [Guideline] Release number for rebuilds In-Reply-To: References: Message-ID: <1201457217.17905.834.camel@beck.corsepiu.local> On Sun, 2008-01-27 at 12:39 -0500, Michel Salim wrote: > Hi all, > > I just noticed a mismatch in multisync: F8's 0.91.0-3 removes an > unneeded build dependency, but F9's 0.91.0-3 is just a rebuild against > a newer version of libopensync (and never appeared in Rawhide, for > some reason). Had the package maintainer used a %{dist} tag suffix, this clash would not have occured ;) > Do we have a guideline for how to bump revision numbers for rebuilds? There is no guideline for rebuilds, because the concept of "rebuilds" isn't covered by Fedora's workflow. Handling NEVRs on them is left to the discretion of each individual packager. > It would seem to me that standardizing on adding a 'build number' to > the release number works better: > > i.e. > 3%{?dist} -> 3%{?dist}.1, 3%{?dist}.2, etc. Are your referring to a "devel" rebuild or a F-8 rebuild? Using a numerical suffix is common practice to avoid NEVR clashes between release branches, when building packages on released branches only. For "devel" any such suffixes are superflous. Simply increment %{release}, instead. Ralf From kevin.kofler at chello.at Sun Jan 27 18:11:15 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 27 Jan 2008 18:11:15 +0000 (UTC) Subject: [Guideline] Release number for rebuilds References: Message-ID: Michel Salim gmail.com> writes: > unneeded build dependency, but F9's 0.91.0-3 is just a rebuild against > a newer version of libopensync (and never appeared in Rawhide, for > some reason). Because it failed to build. The API changed, so you can't just rebuild the package, you have to upgrade it to a version which is compatible with the new libopensync. (There's currently no multisync in Rawhide at all because of this issue, by the way.) > 3%{?dist} -> 3%{?dist}.1, 3%{?dist}.2, etc. That's the recommended way to handle branch-only changes. But changes like removing unneeded BRs should normally be implemented in Rawhide first, then synced to the release branches. Kevin Kofler From michel.sylvan at gmail.com Sun Jan 27 18:14:28 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Sun, 27 Jan 2008 13:14:28 -0500 Subject: [Guideline] Release number for rebuilds In-Reply-To: References: Message-ID: On Jan 27, 2008 1:11 PM, Kevin Kofler wrote: > Because it failed to build. The API changed, so you can't just rebuild the > package, you have to upgrade it to a version which is compatible with the new > libopensync. (There's currently no multisync in Rawhide at all because of this > issue, by the way.) > Aha! I guess there's Kitchensync for that. -- Michel Salim http://hircus.jaiku.com/ From mschwendt.tmp0701.nospam at arcor.de Sun Jan 27 18:18:19 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 27 Jan 2008 19:18:19 +0100 Subject: [Guideline] Release number for rebuilds In-Reply-To: <1201457217.17905.834.camel@beck.corsepiu.local> References: <1201457217.17905.834.camel@beck.corsepiu.local> Message-ID: <20080127191819.8acb031e.mschwendt.tmp0701.nospam@arcor.de> On Sun, 27 Jan 2008 19:06:57 +0100, Ralf Corsepius wrote: > > On Sun, 2008-01-27 at 12:39 -0500, Michel Salim wrote: > > Hi all, > > > > I just noticed a mismatch in multisync: F8's 0.91.0-3 removes an > > unneeded build dependency, but F9's 0.91.0-3 is just a rebuild against > > a newer version of libopensync (and never appeared in Rawhide, for > > some reason). > Had the package maintainer used a %{dist} tag suffix, this clash would > not have occured ;) But of course! The multisync spec uses %{?dist} already. It's just that at some point of time you end up with devel: 2%{?dist} F-8: 2%{?dist} F-7: 2%{?dist} and you can patch and bump F-8 to 3%{?dist} without updating "devel". Your branches get out-of-sync. And next time you bump release in "devel", the release value may become the same as in older branches, but nothing guarantees that the spec file becomes the same. From tibbs at math.uh.edu Sun Jan 27 18:17:43 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 27 Jan 2008 12:17:43 -0600 Subject: Fedora Education Spin In-Reply-To: <479CBF5F.80807@gmail.com> References: <479B4B6A.90805@when.com> <50baabb30801261000g690bfc40w80fdff6cca0efd35@mail.gmail.com> <479B85DD.5090406@when.com> <479B890A.3030903@fedoraproject.org> <20080126194213.1a466781@redhat.com> <479BD6C7.3010608@fedoraproject.org> <20080126195027.0cefe0ad@redhat.com> <479BDAA4.6070304@fedoraproject.org> <20080127025259.32e47cee@lain.camperquake.de> <479BE80A.5080309@fedoraproject.org> <479C727B.7060308@when.com> <479CBF5F.80807@gmail.com> Message-ID: How about shipping a DVD which can be used on one machine to bring up a bunch of machines that can only boot from some smaller medium? If you're really concerned for the educational market, try to think about how it tends to work. Think donated machines that might not even have CD drives much less DVDs, and talk to Warren, Eric, and the other LTSP folks. - J< From kevin.kofler at chello.at Sun Jan 27 18:26:14 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 27 Jan 2008 18:26:14 +0000 (UTC) Subject: [Guideline] Release number for rebuilds References: Message-ID: Michel Salim gmail.com> writes: > Aha! I guess there's Kitchensync for that. Hopefully. I had to upgrade KitchenSync to an experimental work branch too, the new libopensync is still a development version and I haven't been able to test anything at all. I don't know what the roadmap/schedule for a stable libopensync 0.40 is. KitchenSync support for libopensync 0.3/0.4 is being worked on for KDE 4.1 and in a work branch for the KDE 3.5 version, I don't know if or when merging it into 3.5 is planned. (On the other hand, KDE 4.1 will require the new version.) Kevin Kofler From lmacken at redhat.com Fri Jan 25 20:54:37 2008 From: lmacken at redhat.com (Luke Macken) Date: Fri, 25 Jan 2008 15:54:37 -0500 Subject: bodhi 0.4.10 features Message-ID: <20080125205437.GA3993@crow> Some noteworthy features with the latest bodhi update: - Security updates now require approval from the security team before they hit stable. They are still able to go into testing in the mean time. - Compliance with the new Security Bug Tracking Policy[0]. - Bugs will get set to ON_QA when your update hits updates-testing. - Bugs will [optionally] get closed as CURRENTRELEASE once they are stable. - New updates will automatically obsolete any older updates that are pending/testing. - Checksums are no longer displayed in update notices (Ticket #262) - Metrics improvements and enhancements. Added a 'packages with best karma' graph. - ...and many more bug fixes & enhancements. As always, please send all patches, bug reports, suggestions, and criticism to: http://fedorahosted.org/bodhi luke [0]: http://fedoraproject.org/wiki/Security/TrackingBugs [1]: https://fedorahosted.org/fedora-infrastructure/ticket/262 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From kevin.kofler at chello.at Sun Jan 27 18:39:26 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 27 Jan 2008 18:39:26 +0000 (UTC) Subject: bodhi 0.4.10 features References: <20080125205437.GA3993@crow> Message-ID: Luke Macken redhat.com> writes: > - Bugs will [optionally] get closed as CURRENTRELEASE once they are stable. What's the rationale for using CURRENTRELEASE over ERRATA? (I don't mean to be complaining, just asking.) Kevin Kofler From twaugh at redhat.com Sun Jan 27 18:46:00 2008 From: twaugh at redhat.com (Tim Waugh) Date: Sun, 27 Jan 2008 18:46:00 +0000 Subject: bodhi 0.4.10 features In-Reply-To: <20080125205437.GA3993@crow> References: <20080125205437.GA3993@crow> Message-ID: <1201459560.4270.14.camel@cyberelk.elk> On Fri, 2008-01-25 at 15:54 -0500, Luke Macken wrote: > Some noteworthy features with the latest bodhi update: > > - Bugs will get set to ON_QA when your update hits updates-testing. I like. The URLs in the test update bug comments don't seem to be working at the moment though -- I get a 404 page. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From lmacken at redhat.com Sun Jan 27 19:46:18 2008 From: lmacken at redhat.com (Luke Macken) Date: Sun, 27 Jan 2008 14:46:18 -0500 Subject: bodhi 0.4.10 features In-Reply-To: <1201459560.4270.14.camel@cyberelk.elk> References: <20080125205437.GA3993@crow> <1201459560.4270.14.camel@cyberelk.elk> Message-ID: <20080127194618.GC3054@crow> On Sun, Jan 27, 2008 at 06:46:00PM +0000, Tim Waugh wrote: > On Fri, 2008-01-25 at 15:54 -0500, Luke Macken wrote: > > Some noteworthy features with the latest bodhi update: > > > > - Bugs will get set to ON_QA when your update hits updates-testing. > > I like. > > > The URLs in the test update bug comments don't seem to be working at the > moment though -- I get a 404 page. This has been fixed. luke From michel.sylvan at gmail.com Sun Jan 27 19:54:34 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Sun, 27 Jan 2008 14:54:34 -0500 Subject: Koji problems? Message-ID: I've just requested, and been granted, the addition of xbacklight to the package repositories. However, trying to build on both devel and F8 failed: 376349 build (dist-f9, devel:xbacklight-1_1-1_fc9): open (xenbuilder4.fedora.phx.redhat.com) -> FAILED: BuildError: package xbacklight not in list for tag dist-f9 376351 build (dist-f8-updates-candidate, F-8:xbacklight-1_1-1_fc8): open (xenbuilder2.fedora.redhat.com) -> FAILED: BuildError: package xbacklight not in list for tag dist-f8-updates-candidate Anyone knows what is causing this? Thanks, -- Michel Salim http://hircus.jaiku.com/ From jreiser at BitWagon.com Sun Jan 27 20:06:11 2008 From: jreiser at BitWagon.com (John Reiser) Date: Sun, 27 Jan 2008 12:06:11 -0800 Subject: space on the live cds In-Reply-To: <1201366447.3282.8.camel@localhost.localdomain> References: <1201366447.3282.8.camel@localhost.localdomain> Message-ID: <479CE433.2000505@BitWagon.com> Matthias Clasen wrote: > As usual, the live cd isos don't fit... Please give the raw data: ls -l *.iso The amount of overage can influence the attempted remedies (drop packages, etc.) Also, older burners can become unreliable near the outer edge, so the difference between MiB and MB matters: 700MiB 734,003,200 bytes (700*1024*1024) 700MB 700,000,000 bytes (667MiB) Some users choose a 1GB USB flash memory device instead of a physical CD-ROM, and often they don't care about a 700MB limit. Besides, USB2.0 flash memory is faster; time from auto boot to login for Fedora-8-LiveCD: 139 sec "32x" CD-ROM (4.5MB/s max, 110 milliseconds/seek) 50 sec USB2.0 flash memory (10MB/s read, 15 microseconds/seek) After that, why does Fedora not use compression like KNOPPIX? Using the cloop device with gzip fits a filesystem of about 1.2GB onto a CD-ROM, while lzma often can squeeze in another 15% or more. -- From ville.skytta at iki.fi Sun Jan 27 20:30:48 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sun, 27 Jan 2008 22:30:48 +0200 Subject: Problems with bodhi and security updates In-Reply-To: References: <200801271032.05902.ville.skytta@iki.fi> Message-ID: <200801272230.49327.ville.skytta@iki.fi> On Sunday 27 January 2008, Kevin Kofler wrote: > One more thing: you're quick to blame the security team approval process > when it delays your Fedora 8 update, This is not about any particular update, and I don't know why you're pointing fingers back at me about something different. I saw something that smelled like a broken process and tried to provide as accurate an example as possible to illustrate my observations, hence used the xine-lib case with what I experienced it with, hoping to get feedback from those who have designed it and are applying it saying whether it works as intended (and if, why). I also asked for instructions in case there was something I should have done differently. > but this is already the third update > you're pushing to Fedora 7 updates-testing, Ok, I'll bite. The first one went to testing because in addition to a security fix it was a version bump from version 1.1.7 to 1.1.9.1. I now think this was a mistake and I should not have touched F-7 at all. The second one (trivial non-security 1.1.9+ regression fixes) went also to testing because nobody had notified me whether the previous testing update worked or not. The 3rd one was an update to 1.1.10 which contained a security fix and some other pretty harmless looking changes - I decided to push that directly to stable because of the nature of those changes and more importantly because meanwhile a confirmation comment arrived that the latest 1.1.9.1 incarnation worked for some people. Bodhi turned that into the 3rd testing request. At the time of filing the 3rd request (more precisely a bit before that) I also revoked the existing 1.1.9.1 testing->stable update request because I had no idea I wouldn't be able to push the new one directly to stable and thought it'd take the same time for the 1.1.9.1 testing->stable to be processed as the 1.1.10 directly to stable one. > and you appear not to have requested a push to stable for any. Yes, I have. I filed that request immediately after the first comment arrived in Bodhi that someone had tested the F-7 update and found it working (thanks, Rex!). > Many maintainers don't even test their NON-security updates on all Fedora > versions before they push them. (Hey, you're lucky if they even tested it > on ANY distro. ;-) ) You may think that's a bad idea, VERY much so, and I will not participate in that madness, but that's a rant for another day. > but at least for > security updates, I think getting it out quickly is more important. For easily reviewable security fix updates only, agreed. From tibbs at math.uh.edu Sun Jan 27 20:40:01 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 27 Jan 2008 14:40:01 -0600 Subject: Koji problems? In-Reply-To: References: Message-ID: >>>>> "MS" == Michel Salim writes: MS> I've just requested, and been granted, the addition of xbacklight MS> to the package repositories. However, trying to build on both MS> devel and F8 failed: MS> 376349 build (dist-f9, devel:xbacklight-1_1-1_fc9): open MS> (xenbuilder4.fedora.phx.redhat.com) -> FAILED: BuildError: package MS> xbacklight not in list for tag dist-f9 Koji is synchronized with pkgdb twice per hour unless an admin does it manually. A sync should have happened since you sent your message; are you still seeing failures? - J< From lmacken at redhat.com Sun Jan 27 21:06:46 2008 From: lmacken at redhat.com (Luke Macken) Date: Sun, 27 Jan 2008 16:06:46 -0500 Subject: TurboGears-1.0.4.3 & SQLAlchemy Message-ID: <20080127210646.GE3054@crow> TurboGears-1.0.4.2 has just been pushed into updates-testing for F7/F8. For Fedora 8 users, this update will pull in python-sqlalchemy-0.4.1-1.fc8. Ideally, this should be a transparent update for the majority of TG apps out there, however if your application utilizes deprecated SQLAlchemy 0.3. functionality, it may cause some issues. Some possible solutions to potential incompatibility problems: - Add a SQLAlchemy<0.4 requirement to your applications setup.py - Simply remove the python-sqlalchemy package, which cause your application to use python-sqlalchemy0.3 instead. Please speak up if you notice any other issues regarding this update. Any testing and feedback you can provide will be appreciated. http://admin.fedoraproject.org/updates/F8/FEDORA-2008-1107 Thanks, luke -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Sun Jan 27 21:09:08 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sun, 27 Jan 2008 23:09:08 +0200 Subject: Problems with bodhi and security updates In-Reply-To: <20080127172742.GB3054@crow> References: <200801271032.05902.ville.skytta@iki.fi> <20080127172742.GB3054@crow> Message-ID: <200801272309.09438.ville.skytta@iki.fi> On Sunday 27 January 2008, Luke Macken wrote: > > This extra security approval step exists to ensure that someone on the > security team looks at your update and makes sure that it contains all > of the relevant bugs, [...] Thanks Luke, this is helpful. If it's desirable to get all those things done for security updates before they enter repos, I understand that it will slow them down. I still don't like it though. Is there an estimate how much that is/will be on the average? BTW, should I have been aware of the process change, was it announced somewhere? > > What am I expected to do now? Do I need to wait/watch when the security > > team approval comes and then go try request it to be pushed to stable or > > will that happen automatically? I'm tempted to revoke the current > > request and file it again as a regular bugfix one so it could go directly > > to stable updates ASAP... (only half kidding) > > You're expected to go off and do something productive. Once the > security team approves your update, it will go straight to stable. Ok. Could something like this be added to Security/TrackingBugs in Wiki? > [0]: http://fedoraproject.org/wiki/Security/TrackingBugs Link to this page added in PackageMaintainers/UpdatingPackageHowTo. From jeffreyt at fedoraproject.org Sun Jan 27 21:10:35 2008 From: jeffreyt at fedoraproject.org (Jeffrey Tadlock) Date: Sun, 27 Jan 2008 16:10:35 -0500 Subject: InstantMirror needs a rethink In-Reply-To: <479CABE5.1030808@togami.com> References: <4797D5B3.7030002@redhat.com> <10e0a9b00801261647u235f9e73q573f20c9d9f60dae@mail.gmail.com> <1201424696.12758.8.camel@rousalka.dyndns.org> <10e0a9b00801270730y187eb33csc3fb4621ee392fae@mail.gmail.com> <479CABE5.1030808@togami.com> Message-ID: <10e0a9b00801271310p4442b48v4782e4b4b1b3c787@mail.gmail.com> On Jan 27, 2008 11:05 AM, Warren Togami wrote: > Today: > Hey great! I installed InstantMirror and it is working great! That was > easy! > > 3 months from now: > Hey, why did all my applications stop working? So the wiki page is going to be updated to reflect that everyone should stop using the tool now as in three months there will be catastrophic failure? I was not suggesting that there be no improvements made to the tool to clean up some of the issues you outlined, including these two: - There is no good way to clean up aborted tmp files. - There is no good way to know what are old files that need pruning. I was replying to your initial email requesting folks thoughts on InstantMirror and its direction, in which I asked should it really be trying to solve all situations or focus on what you called "pretty useful for home and small office mirrors". I suggested that it should focus on what it is good at - home enthusiasts and small office mirrors. Can you explain to me why my applications are going to stop working in three months? Is it due to the lack of clean-up routines? Will this problem go away if there were clean-up routines implemented? Regards, Jeffrey From sebastian at when.com Sun Jan 27 21:13:12 2008 From: sebastian at when.com (sebastian at when.com) Date: Sun, 27 Jan 2008 22:13:12 +0100 Subject: Fedora Education Spin In-Reply-To: <479CBF5F.80807@gmail.com> References: <479B4B6A.90805@when.com> <50baabb30801261000g690bfc40w80fdff6cca0efd35@mail.gmail.com> <479B85DD.5090406@when.com> <479B890A.3030903@fedoraproject.org> <20080126194213.1a466781@redhat.com> <479BD6C7.3010608@fedoraproject.org> <20080126195027.0cefe0ad@redhat.com> <479BDAA4.6070304@fedoraproject.org> <20080127025259.32e47cee@lain.camperquake.de> <479BE80A.5080309@fedoraproject.org> <479C727B.7060308@when.com> <479CBF5F.80807@gmail.com> Message-ID: <479CF3E8.1080902@when.com> Les Mikesell wrote: > Would it be possible to build a 1-CD base install that would then give > you the option of doing a 'yum groupinstall some_big_set' if you have > a good internet connection, or installing that set from a separate CD > that does not have any of the base system on it? That way you don't > have to respin a bazillion copies of the base system just to get some > slightly customized variations, and people with decent internet > connections don't have to download and install images that will always > be out of date anyway. If you don't want to bother setting up the > infrastructure for yum groupinstall, just provide a script that puts > the whole list on the yum command line - or make a metapackage with > all the others as dependencies. Yep... I think this would be a nice solution for the problem. I am going prepare such a build and post the results here... Sebastian From jspaleta at gmail.com Sun Jan 27 21:25:29 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 27 Jan 2008 12:25:29 -0900 Subject: Problems with bodhi and security updates In-Reply-To: <200801272309.09438.ville.skytta@iki.fi> References: <200801271032.05902.ville.skytta@iki.fi> <20080127172742.GB3054@crow> <200801272309.09438.ville.skytta@iki.fi> Message-ID: <604aa7910801271325k216125b0r4e94f49f09320381@mail.gmail.com> On Jan 27, 2008 12:09 PM, Ville Skytt? wrote: > Thanks Luke, this is helpful. If it's desirable to get all those things done > for security updates before they enter repos, I understand that it will slow > them down. I still don't like it though. Is there an estimate how much that > is/will be on the average? Since security updates are time-sensitive, a ticking clock here would be very good. Does the process include a trackable metric for response times? I know its a new process, but I'd like to be able to trend best.worst,mean,median response time so we can know how we are progressing in keeping the delays reasonable. -jef From andreas.bierfert at lowlatency.de Sun Jan 27 21:47:07 2008 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Sun, 27 Jan 2008 22:47:07 +0100 Subject: [Guideline] Release number for rebuilds In-Reply-To: <20080127191819.8acb031e.mschwendt.tmp0701.nospam@arcor.de> References: <1201457217.17905.834.camel@beck.corsepiu.local> <20080127191819.8acb031e.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20080127224707.0fa5a1d6@alkaid.a.lan> On Sun, 27 Jan 2008 19:18:19 +0100 Michael Schwendt wrote: > and you can patch and bump F-8 to 3%{?dist} without updating "devel". > Your branches get out-of-sync. And next time you bump release in "devel", > the release value may become the same as in older branches, but nothing > guarantees that the spec file becomes the same. Well as noticed earlier, there is no multisync in devel so this is not an issue at all. Since upstream does not know if there and when there will be a replacement I have split out msynctool as its own package a while back. The multisync gui never was really stable or usable anyway. - Andreas -- Andreas Bierfert, B.Sc. | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dmc.fedora at filteredperception.org Sun Jan 27 21:46:41 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 27 Jan 2008 15:46:41 -0600 Subject: space on the live cds In-Reply-To: <479CE433.2000505@BitWagon.com> References: <1201366447.3282.8.camel@localhost.localdomain> <479CE433.2000505@BitWagon.com> Message-ID: <479CFBC1.7050409@filteredperception.org> John Reiser wrote: > > After that, why does Fedora not use compression like KNOPPIX? > Using the cloop device with gzip fits a filesystem of about 1.2GB > onto a CD-ROM, while lzma often can squeeze in another 15% or more. Boot up the f8 livecd and do a df -h. 2+G. Fedora uses squashfs on an ext3 fsimg. Ubuntu gets a bit better because they use unionfs with squashfs native (but only about 5% better). I'm sure fedora will use lzma if/when that squashfs patch gets into fedora's packages. (and in the name of full disclosure, when I recently complained about the size of selinux, I said something like 100MB. I think that may actually be true, given experiments I made removing it, and related dependencies, though 50M is what I see with packages named selin*&setro*. And those numbers are from the uncompressed (out of 2.1G) size of the livecd, not the compressed size). -dmc From dmc.fedora at filteredperception.org Sun Jan 27 21:55:23 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 27 Jan 2008 15:55:23 -0600 Subject: InstantMirror needs a rethink In-Reply-To: <479CBB29.9050904@gmail.com> References: <4797D5B3.7030002@redhat.com> <16de708d0801270142u75dd7612r3d6522056df8c92f@mail.gmail.com> <479CBB29.9050904@gmail.com> Message-ID: <479CFDCB.6090608@filteredperception.org> Les Mikesell wrote: > Arthur Pemberton wrote: > >> Am about to investigate on-demand style mirroring as opposed to >> rsync/ftp myself, and came across InstantMirror. What I have not yet >> been able to determine is what is the benefit of InstantMirror over >> just running squid and having yum always use said proxy?? (yum really >> should be able to independently use an http proxy) > > Yum can/does use an http proxy if you either explicitly configure it or > export http_proxy=http://my_proxy:port in the environment. However the > default mirrorlist behavior will randomize the URLs so different > machines behind the proxy will make different requests that will be > cached but not reused. And an assortment of things can go wrong if repo > files are changed, but these problems could also happen in the time span > of a single update without a proxy. I'm still waiting for someone to tell me how to accomplish the same thing for an anaconda install (kickstart or regular). -dmc From vonbrand at inf.utfsm.cl Sun Jan 27 22:21:11 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sun, 27 Jan 2008 19:21:11 -0300 Subject: long term support release In-Reply-To: <1201410189.17905.709.camel@beck.corsepiu.local> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> <4799EAA0.7030700@gmail.com> <20080125102616.7605825b@redhat.com> <479A0C6B.1050004@gmail.com> <20080125112254.382c9e13@redhat.com> <479A190F.8010402@gmail.com> <200801251727.m0PHRe0O016727@laptop13.inf.utfsm.cl> <479A268B.5070201@gmail.com> <1201330199.17905.561.camel@beck.corsepiu.local> <200801270129.m0R1T0Eg000930@laptop13.inf.utfsm.cl> <1201410189.17905.709.camel@beck.corsepiu.local> Message-ID: <200801272221.m0RMLBhk010404@laptop13.inf.utfsm.cl> Ralf Corsepius wrote: > On Sat, 2008-01-26 at 22:29 -0300, Horst H. von Brand wrote: > > Ralf Corsepius wrote: > > > On Fri, 2008-01-25 at 12:12 -0600, Les Mikesell wrote: > > > > Horst H. von Brand wrote: [...] > > > I guess no reasonable _user_ wants 'bleeding-edge'. > > I consider myself "reasonable"... but sure, the evaluation comes from > > awfully close ;-) > I guess your objective is "development of the distro" itself. No. > My objective is application development, the distro itself is secondary > and is a vehicle. OK, mine too. > > > As a developer, it's not a major problem for _me_ having to cope with a > > > couple of issues here and there, but how do you expect "Aunt Tillie" to > > > cope with them? > > Perhaps Fedora isn't for her then. > We are back to the point of questioning Fedora's target audience. As it > currently seem to me the target audience is "RH distro developers". If so, how is that wrong? > > > Also, with F8 I have been confronted with so many tiny issues, which all > > > together render productive use of Fedora close to impossible and have > > > caused me to have doubts on the project's sanity. > > Have you reported them? > Many of those I could identify the cause of, many have been reported by > others before, many have not yet been reported, ... many are not > reportable. I for one have reported many bugs for which I didn't have the foggiest idea what the cause coukd be. And most of them got fixed (either by taking up my report, or in course of other updates). > > [BTW, most of the F8 timeline I was running rawhide, and I was reasonably > > productive al throughout, except for some short glitches. So I don't buy > > your "close to impossible to use".] > Just to mention a few: > - The yum on F8's DVD is broken. It produces incorrect results. Fixed by an update? Can you use a respin? > - The DVD's packaging only contains a subset of packages. Complain to the DVD Forum , they /have/ to understand the needs of "everything and the kitchen sink" Linux distribution install media. > It doesn't > allow upgrading from FC7+updates at all. Fixed in updates/respin? > - F7 updates had a couple of nasty packaging bugs (e.g. avahi), which > cause the F8 upgrade process to break. Happens, nobody is perfect. > Another issue: the kernel. > For me, Fedora 8 doesn't boot without carefully handcrafted boot > parameters on 3 out of 4 machines. Aunt Tillie would never have been > able to fix them. Again, have you reported it? Are they in any way strange machines? > > > Interestingly, it's not the "community-maintained packages" some seem to > > > preferr to accuse to be of low quality, which are causing the trouble, > > > it's the sum of issues with the "standard/default packages" which are > > > piling up. > > Stands to reason, the "standard/default packages" are the foundation of the > > system. > Yes, while this is true, consider "other packages" are equally important > to an individual's installation. They affect only the subset of people who use them. Sure, it is hard on the victims, but less important overall than breakage in something shared by all. > This is likely the cause the majority of community maintainers to be > tending to apply different strategies on bug fixing: They often use > their packages themselves, therefore they fix bugs inside of their > packages themselves for all Fedoras. They probably are in position to check/fix for /their/ Fedora, not for other versions. To be a maintainer doesn't include having 3 or more machines around to check other versions (today that would be F7, F8, rawhide; then there are at least i686, x86_64 and PPC right now). > @RH maintained "standard/default packages" on the other hand often > appear to be maintained by people who "have been ordered to take an > unloved job/duty". And don't use them personally at all? Strange. Have you got any data to support this (i.e., at the very least split of RH vs community maintainer by package plus bugs outstanding, say, more than a month)? Besides, they probably /do/ have access to the full range of guinea pigs. > > > > A desktop app that crashes once in a while is not a huge problem > > > > - and wouldn't be a problem at all if there were an option to drop back > > > > to a more stable version. > > > > A machine that won't boot or a device driver > > > > that no longer talks to my hardware is. > > > Yep, that's one subset amongst several sets of issues I am facing ;) > > > > > Fortunately, these happen to be the easy cases. The really nagging ones > > > are those, one can't identify the cause of. > > > > And those get magically fixed by extending the life of a random version > > with an understaffed crew doing on-and-off bug fixing and > > backporting? > In not too rare cases, yes, because backporting closes "one case" from > the "pile of bugs". But it is a lot of work, for very little gain. > It could be the bug which has caused the damage in > an individual's situation. It is the place where the "magic" happens > which causes "magic bug fixes" to happen. No. > > In my experience, they end getting fixed by moving forward. > A bug is only fixed if it takes place in the current release. Strange definition of bug fix. > Fixing > bugs by moving forward on "rawhide", "upstream", or "sitting bugs out" > doesn't fix anything for the current release and doesn't help users of > the current release. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From lmacken at redhat.com Sun Jan 27 22:54:06 2008 From: lmacken at redhat.com (Luke Macken) Date: Sun, 27 Jan 2008 17:54:06 -0500 Subject: bodhi 0.4.10 features In-Reply-To: References: <20080125205437.GA3993@crow> Message-ID: <20080127225406.GG3054@crow> On Sun, Jan 27, 2008 at 06:39:26PM +0000, Kevin Kofler wrote: > Luke Macken redhat.com> writes: > > - Bugs will [optionally] get closed as CURRENTRELEASE once they are stable. > > What's the rationale for using CURRENTRELEASE over ERRATA? (I don't mean to be > complaining, just asking.) It's actually NEXTRELEASE, instead of CURRENTRELEASE (correction sent to devel-announce). As for rationale behind this decision, I'm not quite sure, I just wrote the code :) Jon Stanley/QA/FESCo could probably shed more light on this. luke From lmacken at redhat.com Sun Jan 27 23:08:37 2008 From: lmacken at redhat.com (Luke Macken) Date: Sun, 27 Jan 2008 18:08:37 -0500 Subject: Problems with bodhi and security updates In-Reply-To: <200801272309.09438.ville.skytta@iki.fi> References: <200801271032.05902.ville.skytta@iki.fi> <20080127172742.GB3054@crow> <200801272309.09438.ville.skytta@iki.fi> Message-ID: <20080127230837.GH3054@crow> On Sun, Jan 27, 2008 at 11:09:08PM +0200, Ville Skytt? wrote: > On Sunday 27 January 2008, Luke Macken wrote: > > > > This extra security approval step exists to ensure that someone on the > > security team looks at your update and makes sure that it contains all > > of the relevant bugs, [...] > > Thanks Luke, this is helpful. If it's desirable to get all those things done > for security updates before they enter repos, I understand that it will slow > them down. I still don't like it though. Is there an estimate how much that > is/will be on the average? I have no idea how much this will slow things down, we'll find out though. At the moment the security team uses lots of black magic to get their job done, from maintaining a flat file in CVS to track issues, to writing a Bugzilla perl module to do bug cloning. I'm hoping that this integration with our update process will help improve this process and open it up to more contributors. The biggest bottleneck in the process currently is not waiting for security approval, but waiting for releng to sign the updates. We're hoping to have the signing server in place by F9 or shortly thereafter, so that will definitely help speed things up *alot*. > BTW, should I have been aware of the process change, was it announced > somewhere? I'm not quite sure. The TrackingBugs page went from Lubomir's namespace to Security, so I'm assuming it went through FESCo approval? > > [0]: http://fedoraproject.org/wiki/Security/TrackingBugs > > Link to this page added in PackageMaintainers/UpdatingPackageHowTo. Awesome, thanks for that. luke From lmacken at redhat.com Sun Jan 27 23:10:26 2008 From: lmacken at redhat.com (Luke Macken) Date: Sun, 27 Jan 2008 18:10:26 -0500 Subject: Problems with bodhi and security updates In-Reply-To: <604aa7910801271325k216125b0r4e94f49f09320381@mail.gmail.com> References: <200801271032.05902.ville.skytta@iki.fi> <20080127172742.GB3054@crow> <200801272309.09438.ville.skytta@iki.fi> <604aa7910801271325k216125b0r4e94f49f09320381@mail.gmail.com> Message-ID: <20080127231026.GI3054@crow> On Sun, Jan 27, 2008 at 12:25:29PM -0900, Jeff Spaleta wrote: > On Jan 27, 2008 12:09 PM, Ville Skytt? wrote: > > Thanks Luke, this is helpful. If it's desirable to get all those things done > > for security updates before they enter repos, I understand that it will slow > > them down. I still don't like it though. Is there an estimate how much that > > is/will be on the average? > > Since security updates are time-sensitive, a ticking clock here would > be very good. > Does the process include a trackable metric for response times? I > know its a new process, but I'd like to be able to trend > best.worst,mean,median response time so we can know how we are > progressing in keeping the delays reasonable. Currently, no. However, I will change the 'approved' flag from a boolean to a timestamp, so we will be able to easily track this. luke From jspaleta at gmail.com Sun Jan 27 23:20:23 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 27 Jan 2008 14:20:23 -0900 Subject: Problems with bodhi and security updates In-Reply-To: <20080127231026.GI3054@crow> References: <200801271032.05902.ville.skytta@iki.fi> <20080127172742.GB3054@crow> <200801272309.09438.ville.skytta@iki.fi> <604aa7910801271325k216125b0r4e94f49f09320381@mail.gmail.com> <20080127231026.GI3054@crow> Message-ID: <604aa7910801271520l304398b1oec8517dea40729b3@mail.gmail.com> On Jan 27, 2008 2:10 PM, Luke Macken wrote: > Currently, no. However, I will change the 'approved' flag from a > boolean to a timestamp, so we will be able to easily track this. What else would be good to timestamp? Releng signing? I'm really interested in being to watch for bottlenecks, so when we develop one we know where it is as quickly as possible so we can prioritize work. -jef From michel.sylvan at gmail.com Sun Jan 27 23:42:35 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Sun, 27 Jan 2008 18:42:35 -0500 Subject: Koji problems? In-Reply-To: References: Message-ID: On 27 Jan 2008 14:40:01 -0600, Jason L Tibbitts III wrote: > Koji is synchronized with pkgdb twice per hour unless an admin does it > manually. A sync should have happened since you sent your message; > are you still seeing failures? > Aha. Works know, thanks. -- Michel Salim http://hircus.jaiku.com/ From michel.sylvan at gmail.com Mon Jan 28 01:21:49 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Sun, 27 Jan 2008 20:21:49 -0500 Subject: Is there a gdmsetup replacement yet for rawhide? In-Reply-To: References: <20080126201637.GD25387@wolff.to> Message-ID: On Jan 26, 2008 11:59 PM, Kevin Kofler wrote: > Bruno Wolff III wolff.to> writes: > > I noticed that gdmsetup has gone away in rawhide, but I haven't been > > able to find its replacement yet. Can someone provide some guidance here? > > 1. su - > 2. yum install kdebase-workspace > 3. sed -i -e 's/^DISPLAYMANAGER=/#DISPLAYMANAGER=/g' /etc/sysconfig/desktop > 4. echo 'DISPLAYMANAGER="KDE"' >>/etc/sysconfig/desktop > 5. systemsettings > 6. set up KDM to your liking > 7. be thankful for us not drinking the "there should be only one" kool-aid > 8. enjoy! > Speaking of KDM, any reason why installing it requires installing XDM? -- Michel Salim http://hircus.jaiku.com/ From loupgaroublond at gmail.com Mon Jan 28 01:30:53 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Sun, 27 Jan 2008 20:30:53 -0500 Subject: Is there a gdmsetup replacement yet for rawhide? In-Reply-To: References: <20080126201637.GD25387@wolff.to> Message-ID: <7f692fec0801271730i44cbb4c8rd4c4bd35291e9095@mail.gmail.com> On Jan 27, 2008 8:21 PM, Michel Salim wrote: > Speaking of KDM, any reason why installing it requires installing XDM? Because there must be more than one "kool-aid" ;) From tcallawa at redhat.com Mon Jan 28 01:32:51 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 27 Jan 2008 20:32:51 -0500 Subject: F9 Alpha spinning In-Reply-To: References: <20080125162835.GA19048@crow> <200801270250.m0R2oJX0004841@laptop13.inf.utfsm.cl> Message-ID: <1201483971.11332.5.camel@localhost.localdomain> On Sun, 2008-01-27 at 03:18 +0000, Kevin Kofler wrote: > Horst H. von Brand inf.utfsm.cl> writes: > > > Well, your arguments are pretty unconvincing, and apply to a lot of > > > application-library relationships, still usually library users won't fork a > > > library just for that, or when they do, Fedora won't ship their fork. > > > > AFAIU this is an /upstream/ decision, not a Fedora one. > > It is an upstream decision to ship that fuse-lite fork in the tarball and to > support it. It is a Fedora decision to actually use this fork rather than > using --with-fuse=external. (In many cases, we even _patch_ upstream projects > to use system libraries where they don't support it at all, in this case, it > would just be a configure option.) I'm complaining about both. The ntfs-3g spec file is currently conditionalized to use fuse-lite by default, because: A) I'm concerned that future ntfs-3g specific functionality in fuse-lite won't go into FUSE. B) The upstream FUSE lead developer thinks that fuse-lite is a good idea in ntfs-3g. C) I'm comaintaining FUSE in Fedora, so I should be able to handle any security issues that might need to be doublechecked. With that said, I'm not entirely convinced that fuse-lite is the right decision. I might change my mind, and make the default be --with-fuse=external, but it will be still conditionalized so that the SRPM can be easily rebuilt to the opposite. ~spot From khc at pm.waw.pl Mon Jan 28 02:29:08 2008 From: khc at pm.waw.pl (Krzysztof Halasa) Date: Mon, 28 Jan 2008 03:29:08 +0100 Subject: long term support release In-Reply-To: <80d7e4090801261954r22de23dbgc660d60af780f194@mail.gmail.com> (Stephen John Smoogen's message of "Sat\, 26 Jan 2008 20\:54\:54 -0700") References: <1201249426.14800.19.camel@cutter> <1201277589.17905.369.camel@beck.corsepiu.local> <200801261957.41090.opensource@till.name> <80d7e4090801261954r22de23dbgc660d60af780f194@mail.gmail.com> Message-ID: "Stephen John Smoogen" writes: >> They could be done next boot. >> > > Not always... there have been several changes that could only be done > via a chroot environment. If for example ext4 were to be chosen for > Fedora XII it would need a chroot. Sure, fdisk also needs "chroot", even when the system version stays the same. > Large changes in how glibc work are > probably better examples.. I think everything related to glibc can be done early in the init sequence. Even before /sbin/init is started, if needed. BTW: init can be reloaded without rebooting. -- Krzysztof Halasa From mtasaka at ioa.s.u-tokyo.ac.jp Mon Jan 28 02:38:48 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Mon, 28 Jan 2008 11:38:48 +0900 Subject: bodhi 0.4.10 features In-Reply-To: <20080127225406.GG3054@crow> References: <20080125205437.GA3993@crow> <20080127225406.GG3054@crow> Message-ID: <479D4038.1020402@ioa.s.u-tokyo.ac.jp> Luke Macken wrote, at 01/28/2008 07:54 AM +9:00: > On Sun, Jan 27, 2008 at 06:39:26PM +0000, Kevin Kofler wrote: >> Luke Macken redhat.com> writes: >>> - Bugs will [optionally] get closed as CURRENTRELEASE once they are stable. >> What's the rationale for using CURRENTRELEASE over ERRATA? (I don't mean to be >> complaining, just asking.) > > It's actually NEXTRELEASE, instead of CURRENTRELEASE (correction sent to > devel-announce). As for rationale behind this decision, I'm not quite > sure, I just wrote the code :) Jon Stanley/QA/FESCo could probably shed more > light on this. > > luke I disagree. https://bugzilla.redhat.com/page.cgi?id=bug_status.html#status says: ---------------------------------------------------------------------- NEXTRELEASE The problem described has been fixed in the next release of the product, and *is not planned to be fixed* in the release against which the bug was filed. Include information on the release in which this was fixed in the summary when a bug is closed to this resolution. ---------------------------------------------------------------------- If the new release of the package which contains the fix for a related bug is released on the product, the bug must be closed with ERRATA, not NEXTRELEASE. Regards, Mamoru From kevin.kofler at chello.at Mon Jan 28 03:27:46 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 28 Jan 2008 03:27:46 +0000 (UTC) Subject: Is there a gdmsetup replacement yet for rawhide? References: <20080126201637.GD25387@wolff.to> Message-ID: Michel Salim gmail.com> writes: > Speaking of KDM, any reason why installing it requires installing XDM? Because some data/configuration files are shared. Kevin Kofler From tgl at redhat.com Mon Jan 28 03:50:36 2008 From: tgl at redhat.com (Tom Lane) Date: Sun, 27 Jan 2008 22:50:36 -0500 Subject: bodhi 0.4.10 features In-Reply-To: <479D4038.1020402@ioa.s.u-tokyo.ac.jp> References: <20080125205437.GA3993@crow> <20080127225406.GG3054@crow> <479D4038.1020402@ioa.s.u-tokyo.ac.jp> Message-ID: <17179.1201492236@sss.pgh.pa.us> Mamoru Tasaka writes: > Luke Macken wrote, at 01/28/2008 07:54 AM +9:00: >> It's actually NEXTRELEASE, instead of CURRENTRELEASE (correction sent to >> devel-announce). As for rationale behind this decision, I'm not quite >> sure, I just wrote the code :) Jon Stanley/QA/FESCo could probably shed more >> light on this. > I disagree. https://bugzilla.redhat.com/page.cgi?id=bug_status.html#status > says: Yes, this choice is surely 100% broken. I could see either CURRENTRELEASE or ERRATA as sane. regards, tom lane From smooge at gmail.com Mon Jan 28 04:05:55 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Sun, 27 Jan 2008 21:05:55 -0700 Subject: long term support release In-Reply-To: References: <1201249426.14800.19.camel@cutter> <1201277589.17905.369.camel@beck.corsepiu.local> <200801261957.41090.opensource@till.name> <80d7e4090801261954r22de23dbgc660d60af780f194@mail.gmail.com> Message-ID: <80d7e4090801272005t6d542663rc99d616bef281589@mail.gmail.com> On Jan 27, 2008 7:29 PM, Krzysztof Halasa wrote: > "Stephen John Smoogen" writes: > > >> They could be done next boot. > >> > > > > Not always... there have been several changes that could only be done > > via a chroot environment. If for example ext4 were to be chosen for > > Fedora XII it would need a chroot. > > Sure, fdisk also needs "chroot", even when the system version stays > the same. > > > Large changes in how glibc work are > > probably better examples.. > > I think everything related to glibc can be done early in the init > sequence. Even before /sbin/init is started, if needed. > > BTW: init can be reloaded without rebooting. theoretically one could update a kernel without technically rebooting... but at what point are you just being silly to just say you have the longest uptime (and is it uptime if you have dropped all your services to do your update?) -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From lmacken at redhat.com Mon Jan 28 04:26:16 2008 From: lmacken at redhat.com (Luke Macken) Date: Sun, 27 Jan 2008 23:26:16 -0500 Subject: bodhi 0.4.10 features In-Reply-To: <17179.1201492236@sss.pgh.pa.us> References: <20080125205437.GA3993@crow> <20080127225406.GG3054@crow> <479D4038.1020402@ioa.s.u-tokyo.ac.jp> <17179.1201492236@sss.pgh.pa.us> Message-ID: <20080128042616.GA23022@crow> On Sun, Jan 27, 2008 at 10:50:36PM -0500, Tom Lane wrote: > Mamoru Tasaka writes: > > Luke Macken wrote, at 01/28/2008 07:54 AM +9:00: > >> It's actually NEXTRELEASE, instead of CURRENTRELEASE (correction sent to > >> devel-announce). As for rationale behind this decision, I'm not quite > >> sure, I just wrote the code :) Jon Stanley/QA/FESCo could probably shed more > >> light on this. > > > I disagree. https://bugzilla.redhat.com/page.cgi?id=bug_status.html#status > > says: > > Yes, this choice is surely 100% broken. I could see either > CURRENTRELEASE or ERRATA as sane. Agreed. Waiting to hear back from Jon as to what he meant by it; in the mean time, I've reverted bodhi back to using CURRENTRELEASE. Sorry for the confusion. Jon's proposal[0] was approved at the last FESCo meeting, but it doesn't specify what to close the bugs as. John Poelstra's bug workflow[1] page illustrates Jon's proposal, but specifies that bugs be closed as RAWHIDE. I agree with Tom that either ERRATA or CURRENTRELEASE are probably the most sane, but we definitely need to come to a consensus, and make it official. luke [0]: http://fedoraproject.org/wiki/JonStanley/BugWorkflow [1]: http://fedoraproject.org/wiki/JohnPoelstra/BugLifeCycle From tgl at redhat.com Mon Jan 28 04:45:38 2008 From: tgl at redhat.com (Tom Lane) Date: Sun, 27 Jan 2008 23:45:38 -0500 Subject: bodhi 0.4.10 features In-Reply-To: <20080128042616.GA23022@crow> References: <20080125205437.GA3993@crow> <20080127225406.GG3054@crow> <479D4038.1020402@ioa.s.u-tokyo.ac.jp> <17179.1201492236@sss.pgh.pa.us> <20080128042616.GA23022@crow> Message-ID: <17705.1201495538@sss.pgh.pa.us> Luke Macken writes: > I agree with Tom that either ERRATA or CURRENTRELEASE are probably the most > sane, but we definitely need to come to a consensus, and make it official. FWIW, while the bug status definitions don't make it perfectly clear, I get the following subtext from them: ERRATA: yessir, this is a bug, I just fixed it. CURRENTRELEASE: yessir, this is a bug, but it was fixed already. Why aren't you up2date? So ERRATA seems to more nearly match the implications of a bug that is to be closed upon release of an update. The main argument I can see for using CURRENTRELEASE is that it provides the opportunity to specify a fixed-in-which-version field ... but I've never understood why ERRATA doesn't require that same version info. regards, tom lane From jonstanley at gmail.com Mon Jan 28 05:06:08 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Mon, 28 Jan 2008 00:06:08 -0500 Subject: bodhi 0.4.10 features In-Reply-To: <20080128042616.GA23022@crow> References: <20080125205437.GA3993@crow> <20080127225406.GG3054@crow> <479D4038.1020402@ioa.s.u-tokyo.ac.jp> <17179.1201492236@sss.pgh.pa.us> <20080128042616.GA23022@crow> Message-ID: On Jan 27, 2008 11:26 PM, Luke Macken wrote: > Agreed. Waiting to hear back from Jon as to what he meant by it; in the > mean time, I've reverted bodhi back to using CURRENTRELEASE. Sorry for the lack of response here. CURRENTRELEASE or ERRATA sounds sane to me. NEXTRELEASE in my private mail to Luke was meant to be something of a joke (i.e. the next release of bodhi). Sorry that didn't make it through e-mail (as many jokes don't :/ ). I thought that we had agreed to CURRENTRELEASE - however either that or ERRATA makes sense, whatever the consensus is. RAWHIDE doesn't make any sense here, since there's nothing to do with rawhide. > > Sorry for the confusion. Jon's proposal[0] was approved at the last FESCo > meeting, but it doesn't specify what to close the bugs as. John > Poelstra's bug workflow[1] page illustrates Jon's proposal, but specifies > that bugs be closed as RAWHIDE. I'm not sure what the purpose of RAWHIDE here is....it's obviously not rawhide by the time that it hits stable. The important thing to take away from what was decided at FESCo is that the checkbox to not auto-close bugs is/will be no more. > I agree with Tom that either ERRATA or CURRENTRELEASE are probably the most > sane, but we definitely need to come to a consensus, and make it official. Either one of these work for me, but I personally lean towards ERRATA. Whatever people want among those two choices is fine :) From billcrawford1970 at gmail.com Mon Jan 28 05:13:10 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Mon, 28 Jan 2008 05:13:10 +0000 Subject: In rawhide prelink -avR doesn't work, switch to -avmR In-Reply-To: <20080127023346.GA17113@wolff.to> References: <20080126222326.GA24298@wolff.to> <544eb990801261803s5c7fdd08t897ee558b78b10a3@mail.gmail.com> <20080127023346.GA17113@wolff.to> Message-ID: <200801280513.11380.billcrawford1970@googlemail.com> On Sunday 27 January 2008 02:33:46 Bruno Wolff III wrote: > Is that something that should be added to prelink.conf as shipped? > (There already is a number of blacklisted libraries there.) In my opinion yes ;-) I'd suggest opening a bug against either openoffice.org or prelink, preferably the former. From tgl at redhat.com Mon Jan 28 05:19:30 2008 From: tgl at redhat.com (Tom Lane) Date: Mon, 28 Jan 2008 00:19:30 -0500 Subject: bodhi 0.4.10 features In-Reply-To: References: <20080125205437.GA3993@crow> <20080127225406.GG3054@crow> <479D4038.1020402@ioa.s.u-tokyo.ac.jp> <17179.1201492236@sss.pgh.pa.us> <20080128042616.GA23022@crow> Message-ID: <17951.1201497570@sss.pgh.pa.us> "Jon Stanley" writes: > ... The important thing to take > away from what was decided at FESCo is that the checkbox to not > auto-close bugs is/will be no more. Umm ... say what!? This is entirely not sane. It presumes that bodhi and the release bots always know better than the human maintainer whether or not a bug should be auto-closed. If you do this, it will result in maintainers omitting bug numbers from bodhi entries altogether, anytime they are not sure if the bug is definitely dealt with, or if it is related but not solely confined to the particular release being made. PLEASE do not do this. It has zero advantage and significant downside. The only real effect will be to force maintainers to omit relevant information from release announcements. regards, tom lane From tgl at redhat.com Mon Jan 28 06:08:33 2008 From: tgl at redhat.com (Tom Lane) Date: Mon, 28 Jan 2008 01:08:33 -0500 Subject: bodhi 0.4.10 features In-Reply-To: References: <20080125205437.GA3993@crow> <20080127225406.GG3054@crow> <479D4038.1020402@ioa.s.u-tokyo.ac.jp> <17179.1201492236@sss.pgh.pa.us> <20080128042616.GA23022@crow> Message-ID: <18385.1201500513@sss.pgh.pa.us> "Jon Stanley" writes: > On Jan 27, 2008 11:26 PM, Luke Macken wrote: >> Sorry for the confusion. Jon's proposal[0] was approved at the last FESCo >> meeting, but it doesn't specify what to close the bugs as. John >> Poelstra's bug workflow[1] page illustrates Jon's proposal, but specifies >> that bugs be closed as RAWHIDE. > I'm not sure what the purpose of RAWHIDE here is....it's obviously not > rawhide by the time that it hits stable. One other point here, if I haven't worn out my welcome. The previously-cited page defining bug closure states says that RAWHIDE "should not be used for RHEL bugs", but that is obviously a RHEL-centric definition. I argue that in the context of Fedora, RAWHIDE should only be used to close bugs filed against the current development version (ie, rawhide) that don't exist in any released version. If a bug has gotten into a release branch then it should get closed as ERRATA or CURRENTRELEASE, as appropriate. regards, tom lane From rc040203 at freenet.de Mon Jan 28 06:15:23 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 28 Jan 2008 07:15:23 +0100 Subject: long term support release In-Reply-To: <200801272221.m0RMLBhk010404@laptop13.inf.utfsm.cl> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> <4799EAA0.7030700@gmail.com> <20080125102616.7605825b@redhat.com> <479A0C6B.1050004@gmail.com> <20080125112254.382c9e13@redhat.com> <479A190F.8010402@gmail.com> <200801251727.m0PHRe0O016727@laptop13.inf.utfsm.cl> <479A268B.5070201@gmail.com> <1201330199.17905.561.camel@beck.corsepiu.local> <200801270129.m0R1T0Eg000930@laptop13.inf.utfsm.cl> <1201410189.17905.709.camel@beck.corsepiu.local> <200801272221.m0RMLBhk010404@laptop13.inf.utfsm.cl> Message-ID: <1201500923.3242.95.camel@beck.corsepiu.local> On Sun, 2008-01-27 at 19:21 -0300, Horst H. von Brand wrote: > Ralf Corsepius wrote: > > On Sat, 2008-01-26 at 22:29 -0300, Horst H. von Brand wrote: > > > Ralf Corsepius wrote: > > > > On Fri, 2008-01-25 at 12:12 -0600, Les Mikesell wrote: > > > > > Horst H. von Brand wrote: > > > > As a developer, it's not a major problem for _me_ having to cope with a > > > > couple of issues here and there, but how do you expect "Aunt Tillie" to > > > > cope with them? > > > > Perhaps Fedora isn't for her then. > > > We are back to the point of questioning Fedora's target audience. As it > > currently seem to me the target audience is "RH distro developers". > > If so, how is that wrong? Interests collide. "RH distro developers" interests are different from "end users" (even when putting "Aunt Tillie" aside) and "upstreams" and development. E.g. SELinux, NetworkManager, Pulseaudio are widely non-interesting to me. If they worked transparently and smoothlessly, I would simply use them and not waste a single word about them, like I do with many other packages on a distro. Fact is, they don't work smoothless. > > Another issue: the kernel. > > For me, Fedora 8 doesn't boot without carefully handcrafted boot > > parameters on 3 out of 4 machines. Aunt Tillie would never have been > > able to fix them. > > Again, have you reported it? Are they in any way strange machines? There is one machine amongst those, I would consider "exotic" and label "strange" these days: A 1997 standard i586-notebook with f00f bug, no usb, neomagic128-GPU, apm only. It tripped a couple of interesting non-critical issues in Fedora (The kernel's f00f-reporting is broken, nousb doesn't switch of ehci-hci, xorg.conf has made it hard to switch off glx, ...). > > > > Interestingly, it's not the "community-maintained packages" some seem to > > > > preferr to accuse to be of low quality, which are causing the trouble, > > > > it's the sum of issues with the "standard/default packages" which are > > > > piling up. > > > > Stands to reason, the "standard/default packages" are the foundation of the > > > system. > > > Yes, while this is true, consider "other packages" are equally important > > to an individual's installation. > > They affect only the subset of people who use them. Yes, ... and? Everybody only uses a (comparatively small) subset of applications, even from "Core". > > This is likely the cause the majority of community maintainers to be > > tending to apply different strategies on bug fixing: They often use > > their packages themselves, therefore they fix bugs inside of their > > packages themselves for all Fedoras. > > They probably are in position to check/fix for /their/ Fedora, not for > other versions. Yes, that's how open development of open source works. People develop in one environment, others will use it in other environments. If code lacks generality, then those using "strange machines", will have to report it back. > > @RH maintained "standard/default packages" on the other hand often > > appear to be maintained by people who "have been ordered to take an > > unloved job/duty". > > And don't use them personally at all? Strange. Check the merge reviews. It's eye-striking. In many cases, you see @RH's answering along the lines of "I inherited this package from my predecessor". I could give names, but consider it to be a matter of fairness not to do so at this place. > > > And those get magically fixed by extending the life of a random version > > > with an understaffed crew doing on-and-off bug fixing and > > > backporting? > > > In not too rare cases, yes, because backporting closes "one case" from > > the "pile of bugs". > > But it is a lot of work, for very little gain. It's a lot of work when being systematically exercised by an enterprise. In a community maintained distro it would be "demand priority driven". People would pick up those cases which nag them and will try to address them. Yes, it would be suboptimal, but it's still better than a bug not having been addressed at all. > > It could be the bug which has caused the damage in > > an individual's situation. It is the place where the "magic" happens > > which causes "magic bug fixes" to happen. > > No. ?!? You do not agree that fixing bugs in libraries and applications people tripped over when running application A in situation X, often bugs people trip over when running other applications in other situations? This has happened 1000s of times and will happen 1000s of times again. Actually, I would consider such cases to be the norm. > > > In my experience, they end getting fixed by moving forward. > > > A bug is only fixed if it takes place in the current release. > > Strange definition of bug fix. What's strange about this? In real-life manufacturers will be sued for "not fixing bugs in a current release" - Avoiding such situations is called "customer care". Customer: "Garage, when I turn on my car's head lights, the heating starts running at full power." Garage : "We reported it upstream to the car's manufacturer. You might try the next model available at your local dealer next year. Until then, open the windows." Ralf From alexl at users.sourceforge.net Mon Jan 28 06:48:22 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Sun, 27 Jan 2008 23:48:22 -0700 Subject: bodhi 0.4.10 features In-Reply-To: <20080125205437.GA3993__27993.9635926441$1201458494$gmane$org@crow> (Luke Macken's message of "Fri\, 25 Jan 2008 15\:54\:37 -0500") References: <20080125205437.GA3993__27993.9635926441$1201458494$gmane$org@crow> Message-ID: <6cr6g2wimh.fsf@allele2.eebweb.arizona.edu> >>>>> "LM" == Luke Macken writes: LM> Some noteworthy features with the latest bodhi update: [...] LM> - Bugs will get set to ON_QA when your update hits updates-testing. I know this isn't a bodhi problem per se, but another casualty of this change is that bugs that you were fixing (usually ASSIGNED to you) up until they were CLOSED would appear on "My Front Page" so you could keep track of them. Now once the bug goes to ON_QA, it disappears from the "My Front Page". It should remain on the "My Front Page" until it is closed under "Assigned to You" because the header says: "The bug has been assigned to you and it is not resolved or closed yet." and ON_QA falls into this category. Filed (appropriately enough) in bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=430383 Alex From trond.danielsen at gmail.com Mon Jan 28 07:14:19 2008 From: trond.danielsen at gmail.com (Trond Danielsen) Date: Mon, 28 Jan 2008 08:14:19 +0100 Subject: thinkpad-acpi upstream version? In-Reply-To: <4787AA76.4050105@poolshark.org> References: <47852A26.4010609@fedoraproject.org> <364d303b0801091641y763baef2y12a95bde37547c42@mail.gmail.com> <47866320.1040606@redhat.com> <4786653C.5020204@fedoraproject.org> <47868933.6060008@redhat.com> <1200010908.20425.6.camel@vincent52.localdomain> <478789EA.50302@redhat.com> <20080111165311.GU29887@angus.ind.WPI.EDU> <4787AA76.4050105@poolshark.org> Message-ID: <409676c70801272314q4ed6a57ch3a753e82f9563cf@mail.gmail.com> On Jan 11, 2008 6:42 PM, Denis Leroy wrote: > On my T61 (Nvidia Quadro NVS-140M), suspend works, but the brightness > keys and sound keys do not work. I also get the bar graph, but actual > brightness doesn't change at all I have almost the same laptop as you (T61p), and I have the same problem with the volume keys, but the brightness keys work just fine. However, I have tainted my computer with the proprietary driver from Nvidia, if that makes any difference... -- Trond Danielsen From huzaifas at redhat.com Mon Jan 28 07:22:36 2008 From: huzaifas at redhat.com (Huzaifa Sidhpurwala) Date: Mon, 28 Jan 2008 12:52:36 +0530 Subject: Educational spin of fedora Message-ID: <479D82BC.2040500@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All, I am interesting in working for an educational spin of fedora specially for school children. I have seen a lot of school children [ sp. in India, not sure about other places in the world ] fiddle with M$ crap. I also know a lot of schools which would be really excited in using this software instead of paying by their nose for licensing. My initial thoughts is something on the lines of edubuntu but with our own packages and many more. Any body out here who want to help me with this?. - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) Help Desk APAC Team Lead, Research and Development Lead, Global Help Desk, Pune Phone: +617 3514 8125 (UTC +5.5) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 Visit the Help Desk portal at : http://helpdesk.corp.redhat.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHnYK8zHDc8tpb2uURAjTpAJ91l2GvjF/MYSz81Sx4jf/QeEs9vwCgilRw aIaqQ6A/EHIICnYfEAO5ueM= =30oo -----END PGP SIGNATURE----- From lordmorgul at gmail.com Mon Jan 28 07:30:41 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Sun, 27 Jan 2008 23:30:41 -0800 Subject: Educational spin of fedora In-Reply-To: <479D82BC.2040500@redhat.com> References: <479D82BC.2040500@redhat.com> Message-ID: <479D84A1.9090808@gmail.com> Huzaifa Sidhpurwala wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi All, > I am interesting in working for an educational spin of fedora > specially for school children. > I have seen a lot of school children [ sp. in India, not sure about > other places in the world ] fiddle with M$ crap. > > I also know a lot of schools which would be really excited in using this > software instead of paying by their nose for licensing. > > My initial thoughts is something on the lines of edubuntu but with our > own packages and many more. > > Any body out here who want to help me with this?. Did you see this thread? http://www.redhat.com/archives/fedora-devel-list/2008-January/msg02686.html -- Andrew Farris www.lordmorgul.net gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From fedora at leemhuis.info Mon Jan 28 07:31:05 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 28 Jan 2008 08:31:05 +0100 Subject: Educational spin of fedora In-Reply-To: <479D82BC.2040500@redhat.com> References: <479D82BC.2040500@redhat.com> Message-ID: <479D84B9.6000306@leemhuis.info> On 28.01.2008 08:22, Huzaifa Sidhpurwala wrote: > I am interesting in working for an educational spin of fedora > specially for school children. > I have seen a lot of school children [ sp. in India, not sure about > other places in the world ] fiddle with M$ crap. > > I also know a lot of schools which would be really excited in using this > software instead of paying by their nose for licensing. > > My initial thoughts is something on the lines of edubuntu but with our > own packages and many more. > > Any body out here who want to help me with this?. Sebastian Dziallas is working on a Edu-Spin already; see: http://fedoraproject.org/wiki/SebastianDziallas/Education http://fedoraproject.org/wiki/SebastianDziallas/Education?action=AttachFile&do=get&target=livecd-fedora-8-education-beta-2.ks The spin was and still is being discussed on this list; please check the archives, in particular this thread (latest mail in that thread is just a few hours old ;-) ): https://www.redhat.com/archives/fedora-devel-list/2008-January/msg02686.html HTH CU knurd From huzaifas at redhat.com Mon Jan 28 07:43:43 2008 From: huzaifas at redhat.com (Huzaifa Sidhpurwala) Date: Mon, 28 Jan 2008 13:13:43 +0530 Subject: Educational spin of fedora In-Reply-To: <479D84B9.6000306@leemhuis.info> References: <479D82BC.2040500@redhat.com> <479D84B9.6000306@leemhuis.info> Message-ID: <479D87AF.3010402@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 You are right, i totally missed this email. However on seeing this link i think this contains very few edu apps. Probably i can directly contribute to this rather than start my own. Thorsten Leemhuis wrote: > On 28.01.2008 08:22, Huzaifa Sidhpurwala wrote: >> I am interesting in working for an educational spin of fedora >> specially for school children. >> I have seen a lot of school children [ sp. in India, not sure about >> other places in the world ] fiddle with M$ crap. >> >> I also know a lot of schools which would be really excited in using this >> software instead of paying by their nose for licensing. >> >> My initial thoughts is something on the lines of edubuntu but with our >> own packages and many more. >> >> Any body out here who want to help me with this?. > > Sebastian Dziallas is working on a Edu-Spin already; see: > > http://fedoraproject.org/wiki/SebastianDziallas/Education > http://fedoraproject.org/wiki/SebastianDziallas/Education?action=AttachFile&do=get&target=livecd-fedora-8-education-beta-2.ks > > The spin was and still is being discussed on this list; please check the > archives, in particular this thread (latest mail in that thread is just > a few hours old ;-) ): > > https://www.redhat.com/archives/fedora-devel-list/2008-January/msg02686.html > > HTH > > CU > knurd > - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) Help Desk APAC Team Lead, Research and Development Lead, Global Help Desk, Pune Phone: +617 3514 8125 (UTC +5.5) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 Visit the Help Desk portal at : http://helpdesk.corp.redhat.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHnYevzHDc8tpb2uURAsYbAJ0b8cl+mke0dKlBAC5pAFwPzWUlkACfcwv3 /4jfQSeD6az92BLh7T5AYCM= =4uO/ -----END PGP SIGNATURE----- From nicu_fedora at nicubunu.ro Mon Jan 28 08:40:52 2008 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Mon, 28 Jan 2008 10:40:52 +0200 Subject: Fedora Education Spin In-Reply-To: <479B4B6A.90805@when.com> References: <479B4B6A.90805@when.com> Message-ID: <479D9514.7060202@nicubunu.ro> sebastian at when.com wrote: > I have built a Fedora live cd with educational apps. The kickstart file > is here: http://fedoraproject.org/wiki/SebastianDziallas/Education > > Some feedback would be great, so maybe you could tell me, if you have > any suggestions or recommendations. I understand you used claws-mail as default due to size concerns, but if you look at our application usage statistics [1], will see Thunderbird is a much popular choice (and the package is not that big), maybe it is a better default? And how about some "advanced" applications, like Gimp and Inkscape? I think "education" should not be only about "absolute beginners" and having such applications available to learn is very useful. [1] - http://online.gnome.org/applications -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From kushaldas at gmail.com Mon Jan 28 09:12:32 2008 From: kushaldas at gmail.com (Kushal Das) Date: Mon, 28 Jan 2008 14:42:32 +0530 Subject: Fedora Education Spin In-Reply-To: <479D9514.7060202@nicubunu.ro> References: <479B4B6A.90805@when.com> <479D9514.7060202@nicubunu.ro> Message-ID: <200801281442.32739.kushaldas@gmail.com> On Monday 28 January 2008 02:10:52 pm Nicu Buculei wrote: > > And how about some "advanced" applications, like Gimp and Inkscape? I > think "education" should not be only about "absolute beginners" and > having such applications available to learn is very useful. +1 -- Fedora Ambassador, India http://kushaldas.in http://dgplug.org (Linux User Group of Durgapur) From snecklifter at gmail.com Mon Jan 28 10:06:56 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Mon, 28 Jan 2008 10:06:56 +0000 Subject: bodhi 0.4.10 features In-Reply-To: <18385.1201500513@sss.pgh.pa.us> References: <20080125205437.GA3993@crow> <20080127225406.GG3054@crow> <479D4038.1020402@ioa.s.u-tokyo.ac.jp> <17179.1201492236@sss.pgh.pa.us> <20080128042616.GA23022@crow> <18385.1201500513@sss.pgh.pa.us> Message-ID: <364d303b0801280206n4470f818y922e5315ed615b5f@mail.gmail.com> On 28/01/2008, Tom Lane wrote: > "Jon Stanley" writes: > > On Jan 27, 2008 11:26 PM, Luke Macken wrote: > >> Sorry for the confusion. Jon's proposal[0] was approved at the last FESCo > >> meeting, but it doesn't specify what to close the bugs as. John > >> Poelstra's bug workflow[1] page illustrates Jon's proposal, but specifies > >> that bugs be closed as RAWHIDE. > > > I'm not sure what the purpose of RAWHIDE here is....it's obviously not > > rawhide by the time that it hits stable. > > One other point here, if I haven't worn out my welcome. The > previously-cited page defining bug closure states says that RAWHIDE > "should not be used for RHEL bugs", but that is obviously a RHEL-centric > definition. I argue that in the context of Fedora, RAWHIDE should only > be used to close bugs filed against the current development version (ie, > rawhide) that don't exist in any released version. If a bug has gotten > into a release branch then it should get closed as ERRATA or > CURRENTRELEASE, as appropriate. Could I draw people's attention to the fact that bz requires a version for CURRENTRELEASE closure. I _far_ prefer this over ERRATA which I regard as a "Hell, I have no idea what resolution this should have so I'll close it as such". With CURRENTRELEASE the version field indicates for other people who can replicate the same bug what version it is fixed in - dupes etc. I'd go so far as to say ERRATA should be removed completely. Cheers -- Christopher Brown http://www.chruz.com From gemi at bluewin.ch Mon Jan 28 11:02:35 2008 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Mon, 28 Jan 2008 12:02:35 +0100 Subject: Build failure due to make -j8 Message-ID: <1201518155.3590.9.camel@localhost.localdomain> I was trying to build a new release of genius, but the build failed due to unsatisifed make dependencies on machines that use make -j8 or make -j4 instead of the usual make -j2 and indeed when I tried make -j8 on my (uni-processor) machine, it failed too. The package is automake based. Has this behavior been observed with other packages? Could it be a problem with make or automake, or would it be specific to the package only? G?rard From aph at redhat.com Mon Jan 28 11:09:42 2008 From: aph at redhat.com (Andrew Haley) Date: Mon, 28 Jan 2008 11:09:42 +0000 Subject: Build failure due to make -j8 In-Reply-To: <1201518155.3590.9.camel@localhost.localdomain> References: <1201518155.3590.9.camel@localhost.localdomain> Message-ID: <479DB7F6.3050606@redhat.com> G?rard Milmeister wrote: > I was trying to build a new release of genius, but the build failed due > to unsatisifed make dependencies on machines that use make -j8 or make > -j4 instead of the usual make -j2 and indeed when I tried make -j8 on > my (uni-processor) machine, it failed too. The package is automake > based. Has this behavior been observed with other packages? Could it be > a problem with make or automake, or would it be specific to the package > only? While automake may be at fault, it's almost certainly package-specific. Andrew. From debarshi.ray at gmail.com Mon Jan 28 11:16:01 2008 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Mon, 28 Jan 2008 16:46:01 +0530 Subject: Build failure due to make -j8 In-Reply-To: <1201518155.3590.9.camel@localhost.localdomain> References: <1201518155.3590.9.camel@localhost.localdomain> Message-ID: <3170f42f0801280316s4db1821bya5cae0ea4ab0a717@mail.gmail.com> Makefiles generated using older (<1.10) versions of Automake may have bugs causing failure of parallel builds. Also have a look at: http://fedoraproject.org/wiki/Packaging/Guidelines#head-525c7d76890cb22df33b759c65c35c82bf434d2e I have encountered such faulty Makefiles in some of my packages too. Cheers, Debarshi -- Free software for the Indian community: * ftp://fedora.glug-nith.org/ (Fedora) * http://gnu.glug-nith.org/ (GNU) * http://mirror.wbut.ac.in/ (CRAN, Fedora, Mozilla, TLDP) From kevin.kofler at chello.at Mon Jan 28 11:19:05 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 28 Jan 2008 11:19:05 +0000 (UTC) Subject: bodhi 0.4.10 features References: <20080125205437.GA3993@crow> <20080127225406.GG3054@crow> <479D4038.1020402@ioa.s.u-tokyo.ac.jp> <17179.1201492236@sss.pgh.pa.us> <20080128042616.GA23022@crow> <18385.1201500513@sss.pgh.pa.us> <364d303b0801280206n4470f818y922e5315ed615b5f@mail.gmail.com> Message-ID: Christopher Brown gmail.com> writes: > Could I draw people's attention to the fact that bz requires a version > for CURRENTRELEASE closure. I _far_ prefer this over ERRATA which I > regard as a "Hell, I have no idea what resolution this should have so > I'll close it as such". With CURRENTRELEASE the version field > indicates for other people who can replicate the same bug what version > it is fixed in - dupes etc. You can specify a version number for ERRATA and RAWHIDE too. I always fill one in whenever it makes sense. Kevin Kofler From buildsys at redhat.com Mon Jan 28 11:40:50 2008 From: buildsys at redhat.com (Build System) Date: Mon, 28 Jan 2008 06:40:50 -0500 Subject: rawhide report: 20080128 changes Message-ID: <200801281140.m0SBeoGG030579@porkchop.devel.redhat.com> New package glpi-data-injection Plugin for importing data into GLPI New package nec2c Translation of NEC2 antenna modeling tool from FORTRAN to C New package python-libgmail Library to provide access to Gmail via Python New package python-libgmail-docs Documents and examples for python-libgmail New package remctl Client/server for Kerberos-authenticated command execution New package xbacklight Adjust backlight brightness using RandR Updated Packages: glpi-0.70.2-1.fc9 ----------------- * Sun Jan 27 2008 Remi Collet - 0.70.2-1 - bugfixes update gnome-chemistry-utils-0.8.6-1.fc9 --------------------------------- * Sat Jan 26 2008 Julian Sikorski - 0.8.6-1 - Updated to 0.8.6 gocr-0.45-1.fc9 --------------- * Mon Jan 28 2008 Patrice Dumas - 0.45-1 - update to 0.45 - rename gocr-0.44-man.patch to gocr-0.45-perms.patch and fix library and header permissions goffice04-0.4.3-2.fc9 --------------------- * Sun Jan 27 2008 Julian Sikorski - 0.4.3-2 - Removed the API reference docs - Some spec cleanup gwget-0.99-4.fc9 ---------------- * Tue Jan 08 2008 Christoph Wickert - 0.99-4 - Build against epiphany 2.21 ikarus-0.0.2-1.fc9 ------------------ * Mon Dec 03 2007 Michel Salim 0.0.2-1 - Update to 0.0.2 kde-filesystem-4-8.fc9 ---------------------- * Sun Jan 27 2008 Rex Dieter 4-8 - should not own %_datadir/desktop-directories/ (#430420) libdvdnav-4.1.1-5.fc9 --------------------- * Sun Jan 27 2008 Dominik Mierzejewski 4.1.1-5 - fix missing include (bug 428910) * Sun Jan 06 2008 Dominik Mierzejewski 4.1.1-4 - make sure -devel requires our version of libdvdread-devel memcached-1.2.4-3.fc9 --------------------- * Sun Jan 27 2008 Paul Lindner - 1.2.4-3 - Adjust libevent dependencies * Sat Dec 22 2007 Paul Lindner - 1.2.4-2 - Upgrade to memcached-1.2.4 * Fri Sep 07 2007 Konstantin Ryabitsev - 1.2.3-8 - Add selinux policies - Create our own system user nntpgrab-0.2.2-1.fc9 -------------------- * Sun Jan 27 2008 Erik van Pienbroek - 0.2.2-1 - Update to 0.2.2, bugfix release which should solve some deadlocks and eternal loops perl-CGI-Session-4.20-3.fc9 --------------------------- perl-Class-Observable-1.04-3.fc9 -------------------------------- perl-Data-Password-1.07-2.fc9 ----------------------------- perl-Sys-SigAction-0.10-2.fc9 ----------------------------- perl-XML-SAX-Writer-0.50-3.fc9 ------------------------------ python-pp-1.5.2-1.fc9 --------------------- * Sun Jan 27 2008 Steve 'Ashcrow' Milner - 1.5.2-1 - Updated to upstream latest stable. python-twyt-0.8-1.fc9 --------------------- rawstudio-0.7-1.fc9 ------------------- * Thu Jan 24 2008 Gianluca Sforna - 0.7-1 - New upstream release - Improved package description - Add fix for PPC build shorewall-4.0.8-1.fc9 --------------------- * Sun Jan 27 2008 Jonathan G. Underwood - 4.0.8-1 - Update to version 4.0.8 - Remove 4.0.7 patches tracker-0.6.4-5.fc9 ------------------- * Thu Jan 24 2008 Deji Akingunola - 0.6.4-5 - Backport assorted fixes from upstream svn (Fix Fedora bug 426060) ultimatestunts-0.7.3-5.fc9 -------------------------- * Sun Jan 27 2008 Dan Horak 0.7.3-5 - add patch with gcc 4.3 support xfce4-fsguard-plugin-0.4.1-1.fc9 -------------------------------- * Sun Jan 27 2008 Christoph Wickert - 0.4.1-1 - Update to 0.4.1 yum-3.2.10-3.fc9 ---------------- * Sun Jan 27 2008 James Bowes 3.2.10-3 - Remove yumupd.py * Fri Jan 25 2008 Seth Vidal - 3.2.10-1 - 3.2.10 - add pygpgme dep * Wed Dec 05 2007 Seth Vidal - 3.2.8-2 - keep livecd working - patch from upstream until 3.2.9 comes out Broken deps for i386 ---------------------------------------------------------- 1:abiword-2.4.6-6.fc8.i386 requires libgoffice-1.so.2 compiz-kde-0.6.2-6.fc9.i386 requires libkdecorations.so.1 crystal-1.0.5-1.fc8.i386 requires libkdecorations.so.1 dekorator-0.3-3.fc7.i386 requires libkdecorations.so.1 epiphany-extensions-2.20.1-3.fc9.i386 requires libgtkembedmoz.so epiphany-extensions-2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 gnome-web-photo-0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo-0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo-0.3-8.fc9.i386 requires libgtkembedmoz.so gnome-web-photo-0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 kazehakase-0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 kicker-compiz-3.5.4-4.fc8.i386 requires libkickermain.so.1 kicker-compiz-3.5.4-4.fc8.i386 requires libtaskmanager.so.1 ksplash-engine-moodin-0.4.2-4.fc7.i386 requires libksplashthemes.so.0 muine-0.8.8-6.fc9.i386 requires mono(muine-plugin) = 0:1.0.0.0 Broken deps for x86_64 ---------------------------------------------------------- 1:abiword-2.4.6-6.fc8.x86_64 requires libgoffice-1.so.2()(64bit) compiz-kde-0.6.2-6.fc9.x86_64 requires libkdecorations.so.1()(64bit) crystal-1.0.5-1.fc8.x86_64 requires libkdecorations.so.1()(64bit) dekorator-0.3-3.fc7.x86_64 requires libkdecorations.so.1()(64bit) epiphany-extensions-2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) epiphany-extensions-2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo-0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) gnome-web-photo-0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo-0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo-0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) kazehakase-0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 kicker-compiz-3.5.4-4.fc8.x86_64 requires libkickermain.so.1()(64bit) kicker-compiz-3.5.4-4.fc8.x86_64 requires libtaskmanager.so.1()(64bit) ksplash-engine-moodin-0.4.2-4.fc7.x86_64 requires libksplashthemes.so.0()(64bit) muine-0.8.8-6.fc9.x86_64 requires mono(muine-plugin) = 0:1.0.0.0 Broken deps for ppc ---------------------------------------------------------- 1:abiword-2.4.6-6.fc8.ppc requires libgoffice-1.so.2 anaconda-11.4.0.27-1.ppc requires dmidecode compiz-kde-0.6.2-6.fc9.ppc requires libkdecorations.so.1 crystal-1.0.5-1.fc8.ppc requires libkdecorations.so.1 dekorator-0.3-3.fc7.ppc requires libkdecorations.so.1 epiphany-extensions-2.20.1-3.fc9.ppc requires libgtkembedmoz.so epiphany-extensions-2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 gnome-web-photo-0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo-0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo-0.3-8.fc9.ppc requires libgtkembedmoz.so gnome-web-photo-0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 kazehakase-0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 kicker-compiz-3.5.4-4.fc8.ppc requires libkickermain.so.1 kicker-compiz-3.5.4-4.fc8.ppc requires libtaskmanager.so.1 ksplash-engine-moodin-0.4.2-4.fc7.ppc requires libksplashthemes.so.0 monodevelop-0.17-4.fc9.ppc requires boo muine-0.8.8-6.fc9.ppc requires mono(muine-plugin) = 0:1.0.0.0 Broken deps for ppc64 ---------------------------------------------------------- 1:abiword-2.4.6-6.fc8.ppc64 requires libgoffice-1.so.2()(64bit) anaconda-11.4.0.27-1.ppc64 requires dmidecode crystal-1.0.5-1.fc8.ppc64 requires libkdecorations.so.1()(64bit) dekorator-0.3-3.fc7.ppc64 requires libkdecorations.so.1()(64bit) epiphany-extensions-2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) epiphany-extensions-2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo-0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) gnome-web-photo-0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo-0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo-0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) kazehakase-0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 kicker-compiz-3.5.4-4.fc8.ppc64 requires libkickermain.so.1()(64bit) kicker-compiz-3.5.4-4.fc8.ppc64 requires libtaskmanager.so.1()(64bit) ksplash-engine-moodin-0.4.2-4.fc7.ppc64 requires libksplashthemes.so.0()(64bit) perl-Test-AutoBuild-darcs-1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 From lmacken at redhat.com Sun Jan 27 22:46:57 2008 From: lmacken at redhat.com (Luke Macken) Date: Sun, 27 Jan 2008 17:46:57 -0500 Subject: bodhi 0.4.10 features In-Reply-To: <20080125205437.GA3993@crow> References: <20080125205437.GA3993@crow> Message-ID: <20080127224657.GF3054@crow> On Fri, Jan 25, 2008 at 03:54:37PM -0500, Luke Macken wrote: > Some noteworthy features with the latest bodhi update: [...] > - Bugs will [optionally] get closed as CURRENTRELEASE once they are stable. Correction: Bugs will get closed as NEXTRELEASE once the update is stable. This is no longer optional, as all bugs will undergo the same lifecycle. Also, you can now use Bugzilla aliases in the "Bugs" field, ie: CVE-2007-5201 luke _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From caillon at redhat.com Mon Jan 28 12:21:19 2008 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 28 Jan 2008 07:21:19 -0500 Subject: long term support release In-Reply-To: <1201249261.17905.239.camel@beck.corsepiu.local> References: <1201058211.3001.79.camel@gandalf.cobite.com> <4796C18F.7070807@gmail.com> <1201101219.3001.98.camel@gandalf.cobite.com> <20080123103336.6e24109f@redhat.com> <47976399.3010709@redhat.com> <47979470.6010507@leemhuis.info> <1201150608.17905.78.camel@beck.corsepiu.local> <20080124081720.GA2636@free.fr> <1201166022.17905.109.camel@beck.corsepiu.local> <1201198306.17905.117.camel@beck.corsepiu.local> <1201249261.17905.239.camel@beck.corsepiu.local> Message-ID: <479DC8BF.8090805@redhat.com> On 01/25/2008 03:21 AM, Ralf Corsepius wrote: > I wouldn't choose Linux to control a spacecraft or a nuclear power > plant, but I didn't hesitate to chose Linux to control robots in a lab, > nor do I hesitate to chose Fedora to host "my personal mission's" > mission-critical data" ;) That's just you. Some people[1] think it's okay to let Linux control a spacecraft[2]. [1] http://www.nasa.gov [2] http://www.linuxdevices.com/news/NS5714800202.html From jkeating at redhat.com Mon Jan 28 12:46:34 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 28 Jan 2008 07:46:34 -0500 Subject: bodhi 0.4.10 features In-Reply-To: References: <20080125205437.GA3993@crow> <20080127225406.GG3054@crow> <479D4038.1020402@ioa.s.u-tokyo.ac.jp> <17179.1201492236@sss.pgh.pa.us> <20080128042616.GA23022@crow> Message-ID: <20080128074634.162c0d77@redhat.com> On Mon, 28 Jan 2008 00:06:08 -0500 "Jon Stanley" wrote: > I'm not sure what the purpose of RAWHIDE here is....it's obviously not > rawhide by the time that it hits stable. The important thing to take > away from what was decided at FESCo is that the checkbox to not > auto-close bugs is/will be no more. WHAT? That's not what I voted for at all in FESCo. I voted that you can opt-out of auto bug handling, at which point all bets are off and we won't touch a bug at all. But if you stay opted in for bug handling, you get our handling, you don't get to pick and choose what happens. All or nothing. Not no choice at all. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jonstanley at gmail.com Mon Jan 28 12:56:51 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Mon, 28 Jan 2008 07:56:51 -0500 Subject: bodhi 0.4.10 features In-Reply-To: <17951.1201497570@sss.pgh.pa.us> References: <20080125205437.GA3993@crow> <20080127225406.GG3054@crow> <479D4038.1020402@ioa.s.u-tokyo.ac.jp> <17179.1201492236@sss.pgh.pa.us> <20080128042616.GA23022@crow> <17951.1201497570@sss.pgh.pa.us> Message-ID: On Jan 28, 2008 12:19 AM, Tom Lane wrote: > "Jon Stanley" writes: > > ... The important thing to take > > away from what was decided at FESCo is that the checkbox to not > > auto-close bugs is/will be no more. > > Umm ... say what!? > > This is entirely not sane. It presumes that bodhi and the release bots > always know better than the human maintainer whether or not a bug should > be auto-closed. When the human maintainer knows better, it was decided that there is nothing preventing them from clicking the "reopen" button in Bugzilla. There are times when that will be appropriate, but those really should be few and far between. What use case is there for NOT auto-closing once an update has been pushed (assuming that one bug is ONE problem in ONE release - which is something that this was designed to "enforce"? I'm really interested in hearing - Luke and I came up with no valid ones at FUDCon, > If you do this, it will result in maintainers omitting > bug numbers from bodhi entries altogether, anytime they are not sure if > the bug is definitely dealt with, or if it is related but not solely > confined to the particular release being made. Not quite following you here - if the bug turns out not to be dealt with, then the bug can always be re-opened. Remember - ONE bug == ONE problem in ONE release. You should be able to auto-close that, and re-open if that particular problem is not dealt with. > PLEASE do not do this. It has zero advantage and significant downside. The advantage is significantly improved reporter usability and brand perception - I can now say (which I could not before) - this is what happens to a bug once you file it, here is the states that are valid for it to be in. When the maintainer believes that it's fixed, the update system WILL auto-close this bug. I'm still not clear as to the downside, though. > The only real effect will be to force maintainers to omit relevant > information from release announcements. I *really* hope that doesn't happen From ffesti at redhat.com Mon Jan 28 13:01:34 2008 From: ffesti at redhat.com (Florian Festi) Date: Mon, 28 Jan 2008 14:01:34 +0100 Subject: More firewall changes for F-9+ In-Reply-To: <1201295400.23391.0.camel@ignacio.lan> References: <479A3663.1060309@redhat.com> <1201295400.23391.0.camel@ignacio.lan> Message-ID: <479DD22E.30409@redhat.com> Ignacio Vazquez-Abrams wrote: > On Fri, 2008-01-25 at 20:20 +0100, Thomas Woerner wrote: >> some minutes ago system-config-firewall-1.2.0 has been build for rawhide. > > OT: How badly would this blow up on EL4? > Here is the video: http://www.youtube.com/watch?v=HJVOUgCm5Jk From rc040203 at freenet.de Sun Jan 27 05:03:09 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 27 Jan 2008 06:03:09 +0100 Subject: long term support release In-Reply-To: <200801270129.m0R1T0Eg000930@laptop13.inf.utfsm.cl> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> <4799EAA0.7030700@gmail.com> <20080125102616.7605825b@redhat.com> <479A0C6B.1050004@gmail.com> <20080125112254.382c9e13@redhat.com> <479A190F.8010402@gmail.com> <200801251727.m0PHRe0O016727@laptop13.inf.utfsm.cl> <479A268B.5070201@gmail.com> <1201330199.17905.561.camel@beck.corsepiu.local> <200801270129.m0R1T0Eg000930@laptop13.inf.utfsm.cl> Message-ID: <1201410189.17905.709.camel@beck.corsepiu.local> On Sat, 2008-01-26 at 22:29 -0300, Horst H. von Brand wrote: > Ralf Corsepius wrote: > > On Fri, 2008-01-25 at 12:12 -0600, Les Mikesell wrote: > > > Horst H. von Brand wrote: > > > > >> If the latter effort fails, > > > >> you've still got a solid, working version. > > > > > If you want "solid, working", why are you messing around with > > > > "bleeding-edge apps"?! > > > > Why are people writing 'bleeding-edge' apps if there is no reason to use > > > them? > > > I guess no reasonable _user_ wants 'bleeding-edge'. > > I consider myself "reasonable"... but sure, the evaluation comes from > awfully close ;-) I guess your objective is "development of the distro" itself. My objective is application development, the distro itself is secondary and is a vehicle. > > As a developer, it's not a major problem for _me_ having to cope with a > > couple of issues here and there, but how do you expect "Aunt Tillie" to > > cope with them? > > Perhaps Fedora isn't for her then. We are back to the point of questioning Fedora's target audience. As it currently seem to me the target audience is "RH distro developers". > > Also, with F8 I have been confronted with so many tiny issues, which all > > together render productive use of Fedora close to impossible and have > > caused me to have doubts on the project's sanity. > > Have you reported them? Many of those I could identify the cause of, many have been reported by others before, many have not yet been reported, ... many are not reportable. > [BTW, most of the F8 timeline I was running rawhide, and I was reasonably > productive al throughout, except for some short glitches. So I don't buy > your "close to impossible to use".] Just to mention a few: - The yum on F8's DVD is broken. It produces incorrect results. - The DVD's packaging only contains a subset of packages. It doesn't allow upgrading from FC7+updates at all. - F7 updates had a couple of nasty packaging bugs (e.g. avahi), which cause the F8 upgrade process to break. Another issue: the kernel. For me, Fedora 8 doesn't boot without carefully handcrafted boot parameters on 3 out of 4 machines. Aunt Tillie would never have been able to fix them. > > Interestingly, it's not the "community-maintained packages" some seem to > > preferr to accuse to be of low quality, which are causing the trouble, > > it's the sum of issues with the "standard/default packages" which are > > piling up. > > Stands to reason, the "standard/default packages" are the foundation of the > system. Yes, while this is true, consider "other packages" are equally important to an individual's installation. This is likely the cause the majority of community maintainers to be tending to apply different strategies on bug fixing: They often use their packages themselves, therefore they fix bugs inside of their packages themselves for all Fedoras. @RH maintained "standard/default packages" on the other hand often appear to be maintained by people who "have been ordered to take an unloved job/duty". > > > A desktop app that crashes once in a while is not a huge problem > > > - and wouldn't be a problem at all if there were an option to drop back > > > to a more stable version. > > > A machine that won't boot or a device driver > > > that no longer talks to my hardware is. > > Yep, that's one subset amongst several sets of issues I am facing ;) > > > Fortunately, these happen to be the easy cases. The really nagging ones > > are those, one can't identify the cause of. > > And those get magically fixed by extending the life of a random version > with an understaffed crew doing on-and-off bug fixing and > backporting? In not too rare cases, yes, because backporting closes "one case" from the "pile of bugs". It could be the bug which has caused the damage in an individual's situation. It is the place where the "magic" happens which causes "magic bug fixes" to happen. > In my experience, they end getting fixed by moving forward. A bug is only fixed if it takes place in the current release. Fixing bugs by moving forward on "rawhide", "upstream", or "sitting bugs out" doesn't fix anything for the current release and doesn't help users of the current release. Ralf From twoerner at redhat.com Mon Jan 28 13:23:00 2008 From: twoerner at redhat.com (Thomas Woerner) Date: Mon, 28 Jan 2008 14:23:00 +0100 Subject: More firewall changes for F-9+ In-Reply-To: <479DD22E.30409@redhat.com> References: <479A3663.1060309@redhat.com> <1201295400.23391.0.camel@ignacio.lan> <479DD22E.30409@redhat.com> Message-ID: <479DD734.8060005@redhat.com> Florian Festi wrote: > Ignacio Vazquez-Abrams wrote: >> On Fri, 2008-01-25 at 20:20 +0100, Thomas Woerner wrote: >>> some minutes ago system-config-firewall-1.2.0 has been build for >>> rawhide. >> >> OT: How badly would this blow up on EL4? >> > > Here is the video: http://www.youtube.com/watch?v=HJVOUgCm5Jk > Ok, to be a little bit more realistic: gtk and pygtk is too old - same for python. I tried to make it working, but after some minutes I gave up. Thomas -- Thomas Woerner Software Engineer Phone: +49-711-96437-310 Red Hat GmbH Fax : +49-711-96437-111 Hauptstaetterstr. 58 Email: Thomas Woerner D-70178 Stuttgart Web : http://www.redhat.de/ From mtasaka at ioa.s.u-tokyo.ac.jp Mon Jan 28 13:40:03 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Mon, 28 Jan 2008 22:40:03 +0900 Subject: bodhi 0.4.10 features In-Reply-To: References: <20080125205437.GA3993@crow> <20080127225406.GG3054@crow> <479D4038.1020402@ioa.s.u-tokyo.ac.jp> <17179.1201492236@sss.pgh.pa.us> <20080128042616.GA23022@crow> <17951.1201497570@sss.pgh.pa.us> Message-ID: <479DDB33.3070002@ioa.s.u-tokyo.ac.jp> Jon Stanley wrote, at 01/28/2008 09:56 PM +9:00: > What use case is there for NOT auto-closing once an update has been > pushed (assuming that one bug is ONE problem in ONE release - which is > something that this was designed to "enforce"? I'm really interested > in hearing - Luke and I came up with no valid ones at FUDCon, There is a case like: - A bug is reported for F-7 foo package - The maintainer (assignee) easily find that the same problem exists on F-8 and devel - The maintainer fixes the bug on both F-7, F-8, request to push both on bodhi, referring to the same bug number - Bodhi pushes both (F-7, F-8) packages and sometimes the bug is closed with the EVR: XXXXX."fc8" due to race condition. Do you want to force the reporter/maintainer to "clone" the bug for different branch? Regards, Mamoru From limb at jcomserv.net Mon Jan 28 13:37:24 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 28 Jan 2008 07:37:24 -0600 (CST) Subject: Fedora Education Spin In-Reply-To: <479B4B6A.90805@when.com> References: <479B4B6A.90805@when.com> Message-ID: <59706.63.85.68.164.1201527444.squirrel@mail.jcomserv.net> > Hi, > > I have built a Fedora live cd with educational apps. The kickstart file > is here: http://fedoraproject.org/wiki/SebastianDziallas/Education > > Some feedback would be great, so maybe you could tell me, if you have > any suggestions or recommendations. Add genchemlab and gonvert. Not too big, would add value. > And would it be possible, to make an official spin of it? > > Sebastian > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From smooge at gmail.com Mon Jan 28 13:51:02 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 28 Jan 2008 06:51:02 -0700 Subject: long term support release In-Reply-To: <479DC8BF.8090805@redhat.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <47979470.6010507@leemhuis.info> <1201150608.17905.78.camel@beck.corsepiu.local> <20080124081720.GA2636@free.fr> <1201166022.17905.109.camel@beck.corsepiu.local> <1201198306.17905.117.camel@beck.corsepiu.local> <1201249261.17905.239.camel@beck.corsepiu.local> <479DC8BF.8090805@redhat.com> Message-ID: <80d7e4090801280551i27fcd04ete8917756766df9fc@mail.gmail.com> On Jan 28, 2008 5:21 AM, Christopher Aillon wrote: > On 01/25/2008 03:21 AM, Ralf Corsepius wrote: > > I wouldn't choose Linux to control a spacecraft or a nuclear power > > plant, but I didn't hesitate to chose Linux to control robots in a lab, > > nor do I hesitate to chose Fedora to host "my personal mission's" > > mission-critical data" ;) > > That's just you. Some people[1] think it's okay to let Linux control a > spacecraft[2]. > > [1] http://www.nasa.gov > [2] http://www.linuxdevices.com/news/NS5714800202.html > More than just NASA... a good many satellites from many countries (JP and I think 1 or 2 Euro countries) and some of the planned rovers use linux. Though none of them have been COTS as these articles say. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From jonstanley at gmail.com Mon Jan 28 13:54:47 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Mon, 28 Jan 2008 08:54:47 -0500 Subject: bodhi 0.4.10 features In-Reply-To: <479DDB33.3070002@ioa.s.u-tokyo.ac.jp> References: <20080125205437.GA3993@crow> <20080127225406.GG3054@crow> <479D4038.1020402@ioa.s.u-tokyo.ac.jp> <17179.1201492236@sss.pgh.pa.us> <20080128042616.GA23022@crow> <17951.1201497570@sss.pgh.pa.us> <479DDB33.3070002@ioa.s.u-tokyo.ac.jp> Message-ID: On Jan 28, 2008 8:40 AM, Mamoru Tasaka wrote: > Do you want to force the reporter/maintainer to "clone" the bug > for different branch? Yep. I just came up with a catchy slogan for this: "the rule of ones" (OK, maybe not so catchy :) ). ONE bug == ONE problem in ONE release (F7, F8, and rawhide). It's even got a big red box in http://fedoraproject.org/wiki/JohnPoelstra/BugLifeCycle :) From nphilipp at redhat.com Mon Jan 28 13:56:40 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 28 Jan 2008 14:56:40 +0100 Subject: Heads up: cracklib license changed In-Reply-To: <20080125190005.GB6571@redhat.com> References: <20080125190005.GB6571@redhat.com> Message-ID: <1201528600.31174.10.camel@gibraltar.str.redhat.com> Hi Nalin, On Fri, 2008-01-25 at 14:00 -0500, Nalin Dahyabhai wrote: > Heads up: the cracklib license has changed from "Artistic" to "GPLv2" in > the version which is building now. > > The consumers I found using repoquery (netatalk, pam, revelation) should > all be fine with that, but I'm sending this anyway just in case. the original author of the code only talks about GPL with no specific version in http://cracklib.svn.sourceforge.net/viewvc/cracklib/trunk/cracklib/README-LICENSE?revision=97&view=markup -- can you ask if they could make that GPLv2+ -- if not, I'd have to "downgrade" system-config-users from GPLv2+ to GPLv2 (or stop using cracklib). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From mtasaka at ioa.s.u-tokyo.ac.jp Mon Jan 28 13:58:11 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Mon, 28 Jan 2008 22:58:11 +0900 Subject: bodhi 0.4.10 features In-Reply-To: References: <20080125205437.GA3993@crow> <20080127225406.GG3054@crow> <479D4038.1020402@ioa.s.u-tokyo.ac.jp> <17179.1201492236@sss.pgh.pa.us> <20080128042616.GA23022@crow> <17951.1201497570@sss.pgh.pa.us> <479DDB33.3070002@ioa.s.u-tokyo.ac.jp> Message-ID: <479DDF73.2060305@ioa.s.u-tokyo.ac.jp> Jon Stanley wrote, at 01/28/2008 10:54 PM +9:00: > On Jan 28, 2008 8:40 AM, Mamoru Tasaka wrote: > >> Do you want to force the reporter/maintainer to "clone" the bug >> for different branch? > > Yep. I just came up with a catchy slogan for this: "the rule of ones" > (OK, maybe not so catchy :) ). ONE bug == ONE problem in ONE release > (F7, F8, and rawhide). It's even got a big red box in > http://fedoraproject.org/wiki/JohnPoelstra/BugLifeCycle :) I strongly disagree. It just increases the number of bugs and has almost no benefit. Mamoru From lesmikesell at gmail.com Mon Jan 28 14:09:38 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 28 Jan 2008 08:09:38 -0600 Subject: long term support release In-Reply-To: <80d7e4090801280551i27fcd04ete8917756766df9fc@mail.gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <47979470.6010507@leemhuis.info> <1201150608.17905.78.camel@beck.corsepiu.local> <20080124081720.GA2636@free.fr> <1201166022.17905.109.camel@beck.corsepiu.local> <1201198306.17905.117.camel@beck.corsepiu.local> <1201249261.17905.239.camel@beck.corsepiu.local> <479DC8BF.8090805@redhat.com> <80d7e4090801280551i27fcd04ete8917756766df9fc@mail.gmail.com> Message-ID: <479DE222.2060100@gmail.com> Stephen John Smoogen wrote: >>> I wouldn't choose Linux to control a spacecraft or a nuclear power >>> plant, but I didn't hesitate to chose Linux to control robots in a lab, >>> nor do I hesitate to chose Fedora to host "my personal mission's" >>> mission-critical data" ;) >> That's just you. Some people[1] think it's okay to let Linux control a >> spacecraft[2]. >> >> [1] http://www.nasa.gov >> [2] http://www.linuxdevices.com/news/NS5714800202.html >> > > More than just NASA... a good many satellites from many countries (JP > and I think 1 or 2 Euro countries) and some of the planned rovers use > linux. Though none of them have been COTS as these articles say. > There are plenty of heavy duty jobs on Linux these days - Avaya phone switches, F5's BigIP load balancers, etc. would be mission critical in a lot of places. But I don't think they use the fedora updates... And I doubt if they want linux to be "interesting". -- Les Mikesell lesmikesell at gmail.com From rc040203 at freenet.de Mon Jan 28 14:10:05 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 28 Jan 2008 15:10:05 +0100 Subject: bodhi 0.4.10 features In-Reply-To: References: <20080125205437.GA3993@crow> <20080127225406.GG3054@crow> <479D4038.1020402@ioa.s.u-tokyo.ac.jp> <17179.1201492236@sss.pgh.pa.us> <20080128042616.GA23022@crow> <17951.1201497570@sss.pgh.pa.us> <479DDB33.3070002@ioa.s.u-tokyo.ac.jp> Message-ID: <1201529405.3242.110.camel@beck.corsepiu.local> On Mon, 2008-01-28 at 08:54 -0500, Jon Stanley wrote: > On Jan 28, 2008 8:40 AM, Mamoru Tasaka wrote: > > > Do you want to force the reporter/maintainer to "clone" the bug > > for different branch? > > Yep. More bureaucracy. > I just came up with a catchy slogan for this: "the rule of ones" > (OK, maybe not so catchy :) ). ONE bug == ONE problem in ONE release > (F7, F8, and rawhide). It's even got a big red box in > http://fedoraproject.org/wiki/JohnPoelstra/BugLifeCycle :) > From smooge at gmail.com Mon Jan 28 14:12:53 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 28 Jan 2008 07:12:53 -0700 Subject: long term support release In-Reply-To: <1201500923.3242.95.camel@beck.corsepiu.local> References: <1201058211.3001.79.camel@gandalf.cobite.com> <20080125112254.382c9e13@redhat.com> <479A190F.8010402@gmail.com> <200801251727.m0PHRe0O016727@laptop13.inf.utfsm.cl> <479A268B.5070201@gmail.com> <1201330199.17905.561.camel@beck.corsepiu.local> <200801270129.m0R1T0Eg000930@laptop13.inf.utfsm.cl> <1201410189.17905.709.camel@beck.corsepiu.local> <200801272221.m0RMLBhk010404@laptop13.inf.utfsm.cl> <1201500923.3242.95.camel@beck.corsepiu.local> Message-ID: <80d7e4090801280612y78d012e0h725ed35a3299c11c@mail.gmail.com> On Jan 27, 2008 11:15 PM, Ralf Corsepius wrote: > > > > In my experience, they end getting fixed by moving forward. > > > > > A bug is only fixed if it takes place in the current release. > > > > Strange definition of bug fix. > What's strange about this? In real-life manufacturers will be sued for > "not fixing bugs in a current release" - Avoiding such situations is > called "customer care". > > Customer: "Garage, when I turn on my car's head lights, the heating > starts running at full power." > Garage : "We reported it upstream to the car's manufacturer. You might > try the next model available at your local dealer next year. Until then, > open the windows." > I think most of us have misparsed your original comment to be: Customer: "Garage, when I turn on my car's head lights, the heating starts running at full power." Garage : "You need to get the latest car. Otherwise we can't fix it." However, Linux is not cars. Each distro has its strengths and weaknesses. You seem to only see the weaknesses which has me questioning what you are trying to accomplish. Fedora is meant to showcase the latest applications so that various development groups in the world can show that their latest applications off. It is not meant to be a perfectly engineered distro with 7 9's of perfection that only a watchmaker could say "I could do better". Heck its not even meant to be a 3 9's because enough kernel security issues come out that you could miss that target. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From sundaram at fedoraproject.org Mon Jan 28 14:22:04 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 28 Jan 2008 19:52:04 +0530 Subject: long term support release In-Reply-To: <479DE222.2060100@gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <47979470.6010507@leemhuis.info> <1201150608.17905.78.camel@beck.corsepiu.local> <20080124081720.GA2636@free.fr> <1201166022.17905.109.camel@beck.corsepiu.local> <1201198306.17905.117.camel@beck.corsepiu.local> <1201249261.17905.239.camel@beck.corsepiu.local> <479DC8BF.8090805@redhat.com> <80d7e4090801280551i27fcd04ete8917756766df9fc@mail.gmail.com> <479DE222.2060100@gmail.com> Message-ID: <479DE50C.7010501@fedoraproject.org> Les Mikesell wrote: > > There are plenty of heavy duty jobs on Linux these days - Avaya phone > switches, F5's BigIP load balancers, etc. would be mission critical in a > lot of places. But I don't think they use the fedora updates... And I > doubt if they want linux to be "interesting". Some of them do use Fedora but these boxes are not ones that accept updates as it is. Rahul From dominik at greysector.net Mon Jan 28 14:28:35 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 28 Jan 2008 15:28:35 +0100 Subject: bodhi 0.4.10 features In-Reply-To: <479DDF73.2060305@ioa.s.u-tokyo.ac.jp> References: <20080127225406.GG3054@crow> <479D4038.1020402@ioa.s.u-tokyo.ac.jp> <17179.1201492236@sss.pgh.pa.us> <20080128042616.GA23022@crow> <17951.1201497570@sss.pgh.pa.us> <479DDB33.3070002@ioa.s.u-tokyo.ac.jp> <479DDF73.2060305@ioa.s.u-tokyo.ac.jp> Message-ID: <20080128142835.GB2713@ryvius.greysector.net> On Monday, 28 January 2008 at 14:58, Mamoru Tasaka wrote: > Jon Stanley wrote, at 01/28/2008 10:54 PM +9:00: >> On Jan 28, 2008 8:40 AM, Mamoru Tasaka wrote: >> >>> Do you want to force the reporter/maintainer to "clone" the bug >>> for different branch? >> >> Yep. I just came up with a catchy slogan for this: "the rule of ones" >> (OK, maybe not so catchy :) ). ONE bug == ONE problem in ONE release >> (F7, F8, and rawhide). It's even got a big red box in >> http://fedoraproject.org/wiki/JohnPoelstra/BugLifeCycle :) > > I strongly disagree. It just increases the number of bugs and has almost > no benefit. +1. One bug for one issue (even if it exists in more than one release) is quite sufficient. And helps to keep the buglist short. OTOH, if you want us (the package maintainers) to follow the rule of ones, please provide easy tools to do that. For example: one click "clone for release X" button and the ability to sort the bugs on bugzilla frontpage by Fedora release. I'm sure there are more ways to make this easier. Otherwise I strongly object to this unannounced change in bodhi behaviour. Regards, R. -- Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From markg85 at gmail.com Mon Jan 28 14:38:56 2008 From: markg85 at gmail.com (Mark) Date: Mon, 28 Jan 2008 15:38:56 +0100 Subject: Suggestion: Use Liberation fonts as default in Firefox 3 Message-ID: <6e24a8e80801280638q467ce226oeccce8b884c9f41b@mail.gmail.com> Hey, I have Firefox 3 now on Fedora rawhide and i really disliked the default fonts so i played a little with it till i got acceptable results. here are a few screenshots: 1: [1] Default Firefox 3 2: [2] Firefox 3 with Liberation fonts 3: [3] The settings i changed As you can see in [2] is that the fonts are looking just better. i can't make anything else out of it. I've also tested this font setting [3] on other sites like digg.com and the fedora wiki and it looks better everywhere. So i really hope this could be made default for Fedora 9 with Firefox 3. Side note: that extremely big close button in FF3 is extremely ugly! [1] http://img186.imageshack.us/img186/6141/firefoxdefaultpf5.png [2] http://img178.imageshack.us/img178/6871/firefoxliberationax1.png [3] http://img178.imageshack.us/img178/7083/firefoxfontsnu7.png From katzj at redhat.com Mon Jan 28 14:47:44 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 28 Jan 2008 09:47:44 -0500 Subject: long term support release In-Reply-To: <479A1582.9090202@gmail.com> References: <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> <20080125152614.GA2975@free.fr> <20080125103335.0d5adacf@redhat.com> <20080125154127.GC2975@free.fr> <1201275741.1163.1.camel@localhost.localdomain> <20080125154749.GD2975@free.fr> <20080125105041.6605e470@redhat.com> <1201277076.17905.362.camel@beck.corsepiu.local> <479A1582.9090202@gmail.com> Message-ID: <1201531664.5827.15.camel@aglarond.local> On Fri, 2008-01-25 at 10:59 -0600, Les Mikesell wrote: > Ralf Corsepius wrote: > > > >> And why aren't those reasons satisfied with RHEL/CentOS which doesn't > >> have these problems? > > For me, CentOS is an ultra conservative, stagnating distro not meeting > > my demands. It may-be suitable for those who want to set up a server and > > run it with minimal support for the next 4 years - To me it's non > > interesting. > > I don't think a kernel or libc should be "interesting" and the only > reason to change them should be to get one that works with new hardware. > Server apps also tend to be mostly feature-complete even in old > versions. However desktop apps are evolving rapidly and there really is > a missing spot in fedora/rhel style distributions since nothing provides > both kernel/core library stability and current application versions. Unfortunately as the desktop grows increasingly full-featured, the amount of the stack which needs to change for supporting newer desktop apps is increasing. Once upon a time (... in a galaxy far, far away) I used to build updated GNOME versions for older Red Hat Linux releases. It wasn't easy, but it was pretty constrained to a small set of packages. These days, I'd end up needing new hal which brings in ConsoleKit which ...[1] Jeremy [1] Note: this is an example. I am not saying this is bad. Hi davidz! :) From naheemzaffar at gmail.com Mon Jan 28 14:53:28 2008 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Mon, 28 Jan 2008 14:53:28 +0000 Subject: Suggestion: Use Liberation fonts as default in Firefox 3 In-Reply-To: <6e24a8e80801280638q467ce226oeccce8b884c9f41b@mail.gmail.com> References: <6e24a8e80801280638q467ce226oeccce8b884c9f41b@mail.gmail.com> Message-ID: <3adc77210801280653h3e2906dai7702cf081c52f0b3@mail.gmail.com> It is not as simple as that. >From my experience Liberation Sans is a good replacement for Arial. But for "Verdana", DejaVu Sans seems to do a better job. On 28/01/2008, Mark wrote: > Hey, > > I have Firefox 3 now on Fedora rawhide and i really disliked the > default fonts so i played a little with it till i got acceptable > results. here are a few screenshots: > > 1: [1] Default Firefox 3 > 2: [2] Firefox 3 with Liberation fonts > 3: [3] The settings i changed > > As you can see in [2] is that the fonts are looking just better. i > can't make anything else out of it. I've also tested this font setting > [3] on other sites like digg.com and the fedora wiki and it looks > better everywhere. So i really hope this could be made default for > Fedora 9 with Firefox 3. > > Side note: that extremely big close button in FF3 is extremely ugly! > > [1] http://img186.imageshack.us/img186/6141/firefoxdefaultpf5.png > [2] http://img178.imageshack.us/img178/6871/firefoxliberationax1.png > [3] http://img178.imageshack.us/img178/7083/firefoxfontsnu7.png > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From alexl at users.sourceforge.net Mon Jan 28 14:53:41 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Mon, 28 Jan 2008 07:53:41 -0700 Subject: bodhi 0.4.10 features In-Reply-To: <20080128142835.GB2713@ryvius.greysector.net> (Dominik Mierzejewski's message of "Mon\, 28 Jan 2008 15\:28\:35 +0100") References: <20080127225406.GG3054@crow> <479D4038.1020402@ioa.s.u-tokyo.ac.jp> <17179.1201492236@sss.pgh.pa.us> <20080128042616.GA23022@crow> <17951.1201497570@sss.pgh.pa.us> <479DDB33.3070002@ioa.s.u-tokyo.ac.jp> <479DDF73.2060305@ioa.s.u-tokyo.ac.jp> <20080128142835.GB2713@ryvius.greysector.net> Message-ID: >>>>> "DM" == Dominik 'Rathann' Mierzejewski writes: [...] >>>> Do you want to force the reporter/maintainer to "clone" the bug >>>> for different branch? >>> Yep. I just came up with a catchy slogan for this: "the rule of >>> ones" (OK, maybe not so catchy :) ). ONE bug == ONE problem in >>> ONE release (F7, F8, and rawhide). It's even got a big red box in >>> http://fedoraproject.org/wiki/JohnPoelstra/BugLifeCycle :) >> I strongly disagree. It just increases the number of bugs and has >> almost no benefit. DM> +1. One bug for one issue (even if it exists in more than one DM> release) is quite sufficient. And helps to keep the buglist DM> short. DM> OTOH, if you want us (the package maintainers) to follow the rule DM> of ones, please provide easy tools to do that. For example: one DM> click "clone for release X" button and the ability to sort the DM> bugs on bugzilla frontpage by Fedora release. DM> I'm sure there are more ways to make this easier. Otherwise I DM> strongly object to this unannounced change in bodhi behaviour. I also agree. It seems like overkill and increases the bug load unless there are tools as suggested above. Sometimes a bug is reported in F-7 but fixed in F-8 and there is nobody who can investigate whether the F-8 fix works in F-7. Is it really necessary to create a new bug just for that purpose? It's seems better to move the bug to F-8, and push a new update for both branches. If it doesn't fix things in the F-7 branch somebody will re-open the bug. No big deal. Alex From katzj at redhat.com Mon Jan 28 14:52:49 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 28 Jan 2008 09:52:49 -0500 Subject: InstantMirror needs a rethink In-Reply-To: <479CFDCB.6090608@filteredperception.org> References: <4797D5B3.7030002@redhat.com> <16de708d0801270142u75dd7612r3d6522056df8c92f@mail.gmail.com> <479CBB29.9050904@gmail.com> <479CFDCB.6090608@filteredperception.org> Message-ID: <1201531969.5827.17.camel@aglarond.local> On Sun, 2008-01-27 at 15:55 -0600, Douglas McClendon wrote: > I'm still waiting for someone to tell me how to accomplish the same > thing for an anaconda install (kickstart or regular). We'll hopefully be having some proxy support within the second stage[1] in Fedora 9 Jeremy [1] This means that you'll need to be booting from the to-be-renamed-rescuecd.iso as opposed to boot.iso or at least have a direct URL to a stage2.img. But packages via a proxy is part of the plan From sundaram at fedoraproject.org Mon Jan 28 15:06:13 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 28 Jan 2008 20:36:13 +0530 Subject: InstantMirror needs a rethink In-Reply-To: <1201531969.5827.17.camel@aglarond.local> References: <4797D5B3.7030002@redhat.com> <16de708d0801270142u75dd7612r3d6522056df8c92f@mail.gmail.com> <479CBB29.9050904@gmail.com> <479CFDCB.6090608@filteredperception.org> <1201531969.5827.17.camel@aglarond.local> Message-ID: <479DEF65.1080902@fedoraproject.org> Jeremy Katz wrote: > On Sun, 2008-01-27 at 15:55 -0600, Douglas McClendon wrote: >> I'm still waiting for someone to tell me how to accomplish the same >> thing for an anaconda install (kickstart or regular). > > We'll hopefully be having some proxy support within the second stage[1] > in Fedora 9 > > Jeremy > > [1] This means that you'll need to be booting from the > to-be-renamed-rescuecd.iso as opposed to boot.iso or at least have a > direct URL to a stage2.img. But packages via a proxy is part of the > plan Isn't it the plan to get rid of boot.iso entirely? Rahul From alan at redhat.com Mon Jan 28 15:01:14 2008 From: alan at redhat.com (Alan Cox) Date: Mon, 28 Jan 2008 10:01:14 -0500 Subject: Heads up: cracklib license changed In-Reply-To: <1201528600.31174.10.camel@gibraltar.str.redhat.com> References: <20080125190005.GB6571@redhat.com> <1201528600.31174.10.camel@gibraltar.str.redhat.com> Message-ID: <20080128150114.GB24414@devserv.devel.redhat.com> On Mon, Jan 28, 2008 at 02:56:40PM +0100, Nils Philippsen wrote: > the original author of the code only talks about GPL with no specific > version in > http://cracklib.svn.sourceforge.net/viewvc/cracklib/trunk/cracklib/README-LICENSE?revision=97&view=markup -- can you ask if they could make that GPLv2+ -- if not, I'd have to "downgrade" system-config-users from GPLv2+ to GPLv2 (or stop using cracklib). "If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation." From katzj at redhat.com Mon Jan 28 14:59:34 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 28 Jan 2008 09:59:34 -0500 Subject: InstantMirror needs a rethink In-Reply-To: <479DEF65.1080902@fedoraproject.org> References: <4797D5B3.7030002@redhat.com> <16de708d0801270142u75dd7612r3d6522056df8c92f@mail.gmail.com> <479CBB29.9050904@gmail.com> <479CFDCB.6090608@filteredperception.org> <1201531969.5827.17.camel@aglarond.local> <479DEF65.1080902@fedoraproject.org> Message-ID: <1201532374.5827.22.camel@aglarond.local> On Mon, 2008-01-28 at 20:36 +0530, Rahul Sundaram wrote: > Jeremy Katz wrote: > > On Sun, 2008-01-27 at 15:55 -0600, Douglas McClendon wrote: > >> I'm still waiting for someone to tell me how to accomplish the same > >> thing for an anaconda install (kickstart or regular). > > > > We'll hopefully be having some proxy support within the second stage[1] > > in Fedora 9 > > > > Jeremy > > > > [1] This means that you'll need to be booting from the > > to-be-renamed-rescuecd.iso as opposed to boot.iso or at least have a > > direct URL to a stage2.img. But packages via a proxy is part of the > > plan > > Isn't it the plan to get rid of boot.iso entirely? Yes, but pxe booting from the kernel + initrd is still going to be possible Jeremy From jkeating at redhat.com Mon Jan 28 14:59:41 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 28 Jan 2008 09:59:41 -0500 Subject: Heads up: cracklib license changed In-Reply-To: <1201528600.31174.10.camel@gibraltar.str.redhat.com> References: <20080125190005.GB6571@redhat.com> <1201528600.31174.10.camel@gibraltar.str.redhat.com> Message-ID: <20080128095941.03aad05d@redhat.com> On Mon, 28 Jan 2008 14:56:40 +0100 Nils Philippsen wrote: > the original author of the code only talks about GPL with no specific > version in > http://cracklib.svn.sourceforge.net/viewvc/cracklib/trunk/cracklib/README-LICENSE?revision=97&view=markup > -- can you ask if they could make that GPLv2+ -- if not, I'd have to > "downgrade" system-config-users from GPLv2+ to GPLv2 (or stop using > cracklib). If there is no version listed, it's GPL+ -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From chasd at silveroaks.com Mon Jan 28 15:09:15 2008 From: chasd at silveroaks.com (chasd) Date: Mon, 28 Jan 2008 09:09:15 -0600 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <20080127153043.7634A734DA@hormel.redhat.com> References: <20080127153043.7634A734DA@hormel.redhat.com> Message-ID: Alexander Bostr?m wrote: > Wild idea: > > A yum plugin that short-circuits any downloading where the expected > checksum of the data is known beforehand. It would first ask on the > local network for the file, providing: > > * The baseurl or mirrorlist url. > * The path relative to the root of the repo. > * The name of the file. > * The expected checksum. > > If no yum cache service is available on the network, no such > service has > a suitable file or the request times out (a short timeout, 1 second > perhaps), the plugin would fall back to the baseurl or mirrors as > usual. That looks to me like an ad-hoc peer-to-peer network. If you have a small network of machines and want to take advantage of caching, share the files yum has cached locally to other Fedora network nodes. Sounds like a project for me, eh ? Charles Dostale From nicolas.mailhot at laposte.net Mon Jan 28 15:13:27 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 28 Jan 2008 16:13:27 +0100 (CET) Subject: Suggestion: Use Liberation fonts as default in Firefox 3 In-Reply-To: <6e24a8e80801280638q467ce226oeccce8b884c9f41b@mail.gmail.com> References: <6e24a8e80801280638q467ce226oeccce8b884c9f41b@mail.gmail.com> Message-ID: <48074.192.54.193.53.1201533207.squirrel@rousalka.dyndns.org> Le Lun 28 janvier 2008 15:38, Mark a ?crit : > I have Firefox 3 now on Fedora rawhide and i really disliked the > default fonts That happens > so i played a little with it till i got acceptable > results. Thanksfully our font selection is large enough you can find alternatives (at least for latin) now > As you can see in [2] is that the fonts are looking just better. No we can't. I'm afraid that "looking better" is largely subjective when talking about fonts. In particular people exhibit a huge bias in favour of whatever font style they're used to. Take any decent modern font, force a user to use it exclusively for a month, and he'll systematically prefer it afterwards in tests. (hey, some people even ended up liking Luxi *shudder*) So the only thing you've proved is you're used to a style similar to Liberation Sans, probably Arial. Had you spent the time to accustom yourself to Fedora defaults you'd be finding Liberation Sans terrible. Given that Liberation and DejaVu are about similar quality-wise, and some people will hate one and others the reverse, other considerations like encoding coverage and upstream reactiveness prevail, and right now DejaVu wins those. P.S. Though you've still kept Serif as default Firefox family, which *is* an ass-backwards Firefox default we should change, since current screens do not have enough resolution to display satisfying Serif fonts. P.P.S. Likewise Mozilla developpers decided at some time monospace should be scaled down for no particular good reason, and site authors are still fighting this error back with CSS hacks P.P.P.S. Also your screenshot exhibits the fugly color fringing of subpixel hinting. It may have been your misguided choice, or the effect of rawhide currently ignoring user settings to use grayscale only. In any way it's not the fonts fault. Regards, -- Nicolas Mailhot From jos at xos.nl Mon Jan 28 15:28:39 2008 From: jos at xos.nl (Jos Vos) Date: Mon, 28 Jan 2008 16:28:39 +0100 Subject: Nokia wants to buy Trolltech Message-ID: <200801281528.m0SFSd2m014633@jasmine.xos.nl> FYI: Nokia wants to buy Trolltech: http://trolltech.com/company/newsroom/announcements/press.2008-01-28.4605718236 -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From pemboa at gmail.com Mon Jan 28 15:32:11 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 28 Jan 2008 09:32:11 -0600 Subject: Nokia wants to buy Trolltech In-Reply-To: <200801281528.m0SFSd2m014633@jasmine.xos.nl> References: <200801281528.m0SFSd2m014633@jasmine.xos.nl> Message-ID: <16de708d0801280732seb7d466o79745577e7156212@mail.gmail.com> On Jan 28, 2008 9:28 AM, Jos Vos wrote: > > FYI: Nokia wants to buy Trolltech: > > http://trolltech.com/company/newsroom/announcements/press.2008-01-28.4605718236 I think it is past-tense now, http://trolltech.com/28012008/28012008 -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From snecklifter at gmail.com Mon Jan 28 15:42:07 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Mon, 28 Jan 2008 15:42:07 +0000 Subject: bodhi 0.4.10 features In-Reply-To: References: <20080127225406.GG3054@crow> <20080128042616.GA23022@crow> <17951.1201497570@sss.pgh.pa.us> <479DDB33.3070002@ioa.s.u-tokyo.ac.jp> <479DDF73.2060305@ioa.s.u-tokyo.ac.jp> <20080128142835.GB2713@ryvius.greysector.net> Message-ID: <364d303b0801280742s767b6618yef71d58d923d2c5e@mail.gmail.com> On 28/01/2008, Alex Lancaster wrote: > >>>>> "DM" == Dominik 'Rathann' Mierzejewski writes: > > [...] > > >>>> Do you want to force the reporter/maintainer to "clone" the bug > >>>> for different branch? > > >>> Yep. I just came up with a catchy slogan for this: "the rule of > >>> ones" (OK, maybe not so catchy :) ). ONE bug == ONE problem in > >>> ONE release (F7, F8, and rawhide). It's even got a big red box in > >>> http://fedoraproject.org/wiki/JohnPoelstra/BugLifeCycle :) > > >> I strongly disagree. It just increases the number of bugs and has > >> almost no benefit. > > DM> +1. One bug for one issue (even if it exists in more than one > DM> release) is quite sufficient. And helps to keep the buglist > DM> short. > > DM> OTOH, if you want us (the package maintainers) to follow the rule > DM> of ones, please provide easy tools to do that. For example: one > DM> click "clone for release X" button and the ability to sort the > DM> bugs on bugzilla frontpage by Fedora release. > > DM> I'm sure there are more ways to make this easier. Otherwise I > DM> strongly object to this unannounced change in bodhi behaviour. > > I also agree. It seems like overkill and increases the bug load > unless there are tools as suggested above. Sometimes a bug is > reported in F-7 but fixed in F-8 and there is nobody who can > investigate whether the F-8 fix works in F-7. Is it really necessary > to create a new bug just for that purpose? It's seems better to move > the bug to F-8, and push a new update for both branches. If it > doesn't fix things in the F-7 branch somebody will re-open the bug. > No big deal. Actually it can be. Once a bug gets more than two or three people commenting and supplying feedback, things get awfully complicated and you end up in a situation where no-one knows what version someone is running and it becomes time-consuming to track back over closed bugs to review who is running what. Take the kernel for example. The Fedora 7, 8 and rawhide kernels carry differing patchsets and frequently the choice in point release upgrades is to move latest release, then previous release. How can one bug really be relevant to just one kernel? Do we make an exception for major projects like OpenOffice, Firefox, kernel etc? There are key arguments for both but although initially I leaned towards a single bug report across all versions, the case for separate bugs per version makes more sense in the long run as feedback from the reporter is clearer. Also consider that current policy indicates the bug with the most information wins. This will often be the older version (e.g. F7). However does the maintainer then attempt to resolve against the F8 version or F7? Essentially this has been thought through with some care by the triage team and I would recommend that this is the policy that is put into place. -- Christopher Brown http://www.chruz.com From ben.kreuter at gmail.com Mon Jan 28 15:44:54 2008 From: ben.kreuter at gmail.com (Benjamin Kreuter) Date: Mon, 28 Jan 2008 10:44:54 -0500 Subject: Nokia wants to buy Trolltech In-Reply-To: <200801281528.m0SFSd2m014633@jasmine.xos.nl> References: <200801281528.m0SFSd2m014633@jasmine.xos.nl> Message-ID: <200801281044.58268.ben.kreuter@gmail.com> On Monday 28 January 2008 10:28:39 Jos Vos wrote: > FYI: Nokia wants to buy Trolltech: > > http://trolltech.com/company/newsroom/announcements/press.2008-01-28.460571 >8236 > > -- > -- Jos Vos > -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 > -- Amsterdam, The Netherlands | Fax: +31 20 6948204 Cool, at least they will continue open source licensing. This could wind up being a net gain for us -- maybe Nokia's developers could bring some interesting ideas into Qt. -- Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From mrmazda at ij.net Mon Jan 28 16:01:07 2008 From: mrmazda at ij.net (Felix Miata) Date: Mon, 28 Jan 2008 11:01:07 -0500 Subject: Suggestion: Use Liberation fonts as default in Firefox 3 In-Reply-To: <48074.192.54.193.53.1201533207.squirrel@rousalka.dyndns.org> References: <6e24a8e80801280638q467ce226oeccce8b884c9f41b@mail.gmail.com> <48074.192.54.193.53.1201533207.squirrel@rousalka.dyndns.org> Message-ID: <479DFC43.9030706@ij.net> On 2008/01/28 16:13 (GMT+0100) Nicolas Mailhot apparently typed: > Le Lun 28 janvier 2008 15:38, Mark a ??crit : > Thanksfully our font selection is large enough you can find > alternatives (at least for latin) now >> As you can see in [2] is that the fonts are looking just better. > No we can't. With a suitable frame of reference, yes we can. > I'm afraid that "looking better" is largely subjective when talking > about fonts. If the goal in selecting particular default Firefox fonts is to match the ubiquitous platform's font metrics so that web pages viewed in Firefox on Fedora look as much as possible like the very same pages viewed in Firefox on doz, then Liberation does a far better job than DejaVu, as that was the precise goal of the Liberation Fonts project. http://www.press.redhat.com/2007/05/09/liberation-fonts/ > So the only thing you've proved is you're used to a style similar to > Liberation Sans, probably Arial. I believed he proved the goal of the Liberation project was achieved. Liberation Sans is the GPL metric equivalent of Arial. DejaVu Sans is an excellent substitute for Verdana, but the doz default in Firefox is Arial, not Verdana. -- "In the beginning was the Word, and the Word was with God, and the Word was God." John 1:1 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/ From nphilipp at redhat.com Mon Jan 28 16:06:12 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 28 Jan 2008 17:06:12 +0100 Subject: Heads up: cracklib license changed In-Reply-To: <20080128095941.03aad05d@redhat.com> References: <20080125190005.GB6571@redhat.com> <1201528600.31174.10.camel@gibraltar.str.redhat.com> <20080128095941.03aad05d@redhat.com> Message-ID: <1201536372.31174.16.camel@gibraltar.str.redhat.com> On Mon, 2008-01-28 at 09:59 -0500, Jesse Keating wrote: > On Mon, 28 Jan 2008 14:56:40 +0100 > Nils Philippsen wrote: > > > the original author of the code only talks about GPL with no specific > > version in > > http://cracklib.svn.sourceforge.net/viewvc/cracklib/trunk/cracklib/README-LICENSE?revision=97&view=markup > > -- can you ask if they could make that GPLv2+ -- if not, I'd have to > > "downgrade" system-config-users from GPLv2+ to GPLv2 (or stop using > > cracklib). > > > If there is no version listed, it's GPL+ "GPL" is what the original author told upstream (cracklib.sf.net), upstream mention "GPLv2". Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From bruno at wolff.to Mon Jan 28 16:07:20 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 28 Jan 2008 10:07:20 -0600 Subject: In rawhide prelink -avR doesn't work, switch to -avmR In-Reply-To: <200801280513.11380.billcrawford1970@googlemail.com> References: <20080126222326.GA24298@wolff.to> <544eb990801261803s5c7fdd08t897ee558b78b10a3@mail.gmail.com> <20080127023346.GA17113@wolff.to> <200801280513.11380.billcrawford1970@googlemail.com> Message-ID: <20080128160720.GA30813@wolff.to> On Mon, Jan 28, 2008 at 05:13:10 +0000, Bill Crawford wrote: > On Sunday 27 January 2008 02:33:46 Bruno Wolff III wrote: > > > Is that something that should be added to prelink.conf as shipped? > > (There already is a number of blacklisted libraries there.) > > In my opinion yes ;-) I'd suggest opening a bug against either openoffice.org > or prelink, preferably the former. After making sure that works in my case I'll file a bugzilla. I'll also refer back to the thread to explain why I am picking on Open Office as I am not in a position to argue that there isn't much point in prelinking the Open Office library. (I don't doubt you, but if I am asked why I am claiming that my only answer is because someone told me so.) From jakub at redhat.com Mon Jan 28 16:27:58 2008 From: jakub at redhat.com (Jakub Jelinek) Date: Mon, 28 Jan 2008 11:27:58 -0500 Subject: In rawhide prelink -avR doesn't work, switch to -avmR In-Reply-To: <20080126222326.GA24298@wolff.to> References: <20080126222326.GA24298@wolff.to> Message-ID: <20080128162758.GI30691@devserv.devel.redhat.com> On Sat, Jan 26, 2008 at 04:23:26PM -0600, Bruno Wolff III wrote: > This might not really impact things. I didn't test using -av as the cron > scripts do. But if the -R option doesn't use up address space faster (which > I don't know), then the cron scripts may need to be modified. > This is sample output that I got: > [root at cerberus bruno]# /usr/sbin/prelink -vaR > /usr/sbin/prelink: /usr/bin/kbabeldict.#prelink#.UJB6Nz: Could not find one of the dependencies > /usr/sbin/prelink: /usr/bin/kbabel.#prelink#.PUsLOh: Could not find one of the dependencies > /usr/sbin/prelink: /usr/bin/gnucash-bin: Could not find one of the dependencies > /usr/sbin/prelink: /sbin/mdassemble.static: PT_INTERP segment not corresponding to .interp section > /usr/sbin/prelink: /sbin/fence_xvmd: Could not find one of the dependencies > Laying out 518 libraries in virtual address space 00101000-50000000 > Random base 0x3b0f0000 > /usr/sbin/prelink: Could not find virtual address slot for /usr/lib/libwireshark.so.0 > > The last message about wireshark is the fatal one. The other messages showed > up when using the -m option, but did not prevent prelinking. Why are you leaving -m out? For 32-bit address space, if you have many shared libraries -m is very important, there isn't really enough address space in the default ranges to fit thousands of shared libraries. /etc/sysconfig/prelink has PRELINK_OPTS=-mR as the default... Jakub From fedora at leemhuis.info Mon Jan 28 16:56:10 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 28 Jan 2008 17:56:10 +0100 Subject: PackageMaintainers/RetiredPackages still needed (was: Update of "PackageMaintainers/RetiredPackages" by [...]) In-Reply-To: <20080128163822.24151.87040@app1.fedora.phx.redhat.com> References: <20080128163822.24151.87040@app1.fedora.phx.redhat.com> Message-ID: <479E092A.3060001@leemhuis.info> Hi all! On 28.01.2008 17:38, fedorawiki-noreply at fedoraproject.org wrote: > You have subscribed to a wiki page or wiki category on "Fedora Project Wiki" for change notification. > > The following page has been changed by [...]: > http://fedoraproject.org/wiki/PackageMaintainers/RetiredPackages?action=diff&rev2=97&rev1=96 Just saw one of those again. Made me wonder: do we still need this page? Orphaned packages are tracked in the package db and CVS should have a dead.package file explaining why a package was retired. Isn't that enough? I suppose parts of the wiki page are out of date anyway; that in my Fedora-experience always happens with manually maintained pages like this one. Seems to be the case here as well: > The comment on the change is: > Removed kgtk - should not be retired Cu knurd From lesmikesell at gmail.com Mon Jan 28 17:23:28 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 28 Jan 2008 11:23:28 -0600 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: References: <20080127153043.7634A734DA@hormel.redhat.com> Message-ID: <479E0F90.5070703@gmail.com> chasd wrote: > >> Wild idea: >> >> A yum plugin that short-circuits any downloading where the expected >> checksum of the data is known beforehand. It would first ask on the >> local network for the file, providing: >> >> * The baseurl or mirrorlist url. >> * The path relative to the root of the repo. >> * The name of the file. >> * The expected checksum. >> >> If no yum cache service is available on the network, no such service has >> a suitable file or the request times out (a short timeout, 1 second >> perhaps), the plugin would fall back to the baseurl or mirrors as usual. > > That looks to me like an ad-hoc peer-to-peer network. > If you have a small network of machines and want to take advantage of > caching, share the files yum has cached locally to other Fedora network > nodes. > > Sounds like a project for me, eh ? It sounds fairly horrible to me to have every single application you might run that could share something set up its own file sharing service and client - and I'd expect such things to be actively blocked by sensible firewall administrators. How about something that would act like a symlink of /var/cache/yum to an explicitly mapped shared directory common to the machines? One could offer to be the server, but that shouldn't be a requirement. -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Mon Jan 28 17:29:39 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 28 Jan 2008 11:29:39 -0600 Subject: long term support release In-Reply-To: <1201531664.5827.15.camel@aglarond.local> References: <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> <20080125152614.GA2975@free.fr> <20080125103335.0d5adacf@redhat.com> <20080125154127.GC2975@free.fr> <1201275741.1163.1.camel@localhost.localdomain> <20080125154749.GD2975@free.fr> <20080125105041.6605e470@redhat.com> <1201277076.17905.362.camel@beck.corsepiu.local> <479A1582.9090202@gmail.com> <1201531664.5827.15.camel@aglarond.local> Message-ID: <479E1103.7080809@gmail.com> Jeremy Katz wrote: >> I don't think a kernel or libc should be "interesting" and the only >> reason to change them should be to get one that works with new hardware. >> Server apps also tend to be mostly feature-complete even in old >> versions. However desktop apps are evolving rapidly and there really is >> a missing spot in fedora/rhel style distributions since nothing provides >> both kernel/core library stability and current application versions. > > Unfortunately as the desktop grows increasingly full-featured, the > amount of the stack which needs to change for supporting newer desktop > apps is increasing. Are you saying these desktops can't ever run on *bsd/solaris, etc. kernels and libc's because they need features unique to this month's linux? > Once upon a time (... in a galaxy far, far away) I used to build updated > GNOME versions for older Red Hat Linux releases. It wasn't easy, but it > was pretty constrained to a small set of packages. These days, I'd end > up needing new hal which brings in ConsoleKit which ...[1] > > Jeremy > > [1] Note: this is an example. I am not saying this is bad. Hi > davidz! :) I'd say anything at the application level that isn't portable across platforms is bad, let alone across kernel versions. -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Mon Jan 28 17:33:29 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 28 Jan 2008 11:33:29 -0600 Subject: InstantMirror needs a rethink In-Reply-To: <479DEF65.1080902@fedoraproject.org> References: <4797D5B3.7030002@redhat.com> <16de708d0801270142u75dd7612r3d6522056df8c92f@mail.gmail.com> <479CBB29.9050904@gmail.com> <479CFDCB.6090608@filteredperception.org> <1201531969.5827.17.camel@aglarond.local> <479DEF65.1080902@fedoraproject.org> Message-ID: <479E11E9.4090705@gmail.com> Rahul Sundaram wrote: >>> I'm still waiting for someone to tell me how to accomplish the same >>> thing for an anaconda install (kickstart or regular). >> >> We'll hopefully be having some proxy support within the second stage[1] >> in Fedora 9 >> >> Jeremy >> >> [1] This means that you'll need to be booting from the >> to-be-renamed-rescuecd.iso as opposed to boot.iso or at least have a >> direct URL to a stage2.img. But packages via a proxy is part of the >> plan > > Isn't it the plan to get rid of boot.iso entirely? What's the alternative? I normally prefer NFS installs from a nearby downloaded-but-not-burned image. But I might change my mind if there were a way to pre-load a cache for an http install. -- Les Mikesell lesmikesell at gmail.com From nicolas.mailhot at laposte.net Mon Jan 28 17:37:10 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 28 Jan 2008 18:37:10 +0100 (CET) Subject: Suggestion: Use Liberation fonts as default in Firefox 3 In-Reply-To: <479DFC43.9030706@ij.net> References: <6e24a8e80801280638q467ce226oeccce8b884c9f41b@mail.gmail.com> <48074.192.54.193.53.1201533207.squirrel@rousalka.dyndns.org> <479DFC43.9030706@ij.net> Message-ID: <37964.192.54.193.53.1201541830.squirrel@rousalka.dyndns.org> Le Lun 28 janvier 2008 17:01, Felix Miata a ?crit : > On 2008/01/28 16:13 (GMT+0100) Nicolas Mailhot apparently typed: >> I'm afraid that "looking better" is largely subjective when talking >> about fonts. > > If the goal in selecting particular default Firefox fonts is You're redefining the question > to match the ubiquitous platform's font metrics The ubiquitous platform fonts engine is very different from our font engine and does not give the same result with the same fonts, let alone clones (there are studies on the net about this, and there are legal reasons it is so). The ubiquitous platform's fonts were Arial, then Verdana, then something else again in Vista. And that's ignoring differences between ubiquitous platform on different locales. Which particular version of the ubiquitous platform do you want us to emulate for what locale and why will it achieve the "looking better" goal of the original poster? > so that web pages viewed in Firefox > on > Fedora look as much as possible like the very same pages viewed in > Firefox on > doz, then Liberation does a far better job than DejaVu, as that was > the > precise goal of the Liberation Fonts project. If you redefine the goal as looking like Arial, yes Liberation looks more like Arial (in latin). That's about the only hard fact everyone agrees on. Web sites authors that specify Arial or TNR will get Liberation now. Only sites that specify the platform default in their CSS rules will get the platform default. Given that the biggest factor in font appreciation is the exposure one had to this particular font having the browser default be the same as the platform default other apps use makes a lot of sense (even if this platform default is not the same as another platform default). Is Liberation a better font? Will users be better served by a different font default in the browser than in the UI? If not, do we gain more by changing the general UI font than we lose? On what locales? Who will extend which font long term? These are all the questions that need to be considered before hastily making changes > http://www.press.redhat.com/2007/05/09/liberation-fonts/ All press releases have an hot air component, Redhat press releases like others (IIRC this particular PR states Liberation will replace every common FLOSS font out there). Many people have stated that Linux was aimed at world domination. Is it ready for world domination yet? >> So the only thing you've proved is you're used to a style similar to >> Liberation Sans, probably Arial. > > I believed he proved the goal of the Liberation project was achieved. > Liberation Sans is the GPL metric equivalent of Arial. So what? > DejaVu Sans is an excellent substitute for Verdana, but the doz > default in Firefox is Arial, not Verdana. Unfortunately, any close look at Firefox font defaults reveals they're a pile of historic crap so that's not a particularly strong endorsement. The Mozilla foundation has turned a blind eye to font problems for years and its browser settings reflect this fact. It is sad to say that Microsoft did more for free fonts with its proprietary Core Web Fonts initiative than Mozilla ever did. Unfortunately for us Microsoft has moved to the next stage and we've got no clones for its new fonts so targetting core fonts is a dead end. Better to create our own solid font set than continue chasing the Microsoft tail indefinitely - it has the financial means to move way faster than us on the font creation front anyway. Also fontconfig substitution means the same defaults will have vastly different effects on Linux than on Windows. -- Nicolas Mailhot From markg85 at gmail.com Mon Jan 28 17:37:36 2008 From: markg85 at gmail.com (Mark) Date: Mon, 28 Jan 2008 18:37:36 +0100 Subject: Suggestion: Use Liberation fonts as default in Firefox 3 In-Reply-To: <48074.192.54.193.53.1201533207.squirrel@rousalka.dyndns.org> References: <6e24a8e80801280638q467ce226oeccce8b884c9f41b@mail.gmail.com> <48074.192.54.193.53.1201533207.squirrel@rousalka.dyndns.org> Message-ID: <6e24a8e80801280937w453b6f81haeaf4cd4ecb79bbc@mail.gmail.com> 2008/1/28, Nicolas Mailhot : > > Le Lun 28 janvier 2008 15:38, Mark a ?crit : > > > I have Firefox 3 now on Fedora rawhide and i really disliked the > > default fonts > > That happens > > > so i played a little with it till i got acceptable > > results. > > Thanksfully our font selection is large enough you can find > alternatives (at least for latin) now > > > As you can see in [2] is that the fonts are looking just better. > > No we can't. > > I'm afraid that "looking better" is largely subjective when talking > about fonts. In particular people exhibit a huge bias in favour of > whatever font style they're used to. Take any decent modern font, > force a user to use it exclusively for a month, and he'll > systematically prefer it afterwards in tests. (hey, some people even > ended up liking Luxi *shudder*) > > So the only thing you've proved is you're used to a style similar to > Liberation Sans, probably Arial. Had you spent the time to accustom > yourself to Fedora defaults you'd be finding Liberation Sans terrible. > > Given that Liberation and DejaVu are about similar quality-wise, and > some people will hate one and others the reverse, other considerations > like encoding coverage and upstream reactiveness prevail, and right > now DejaVu wins those. > > P.S. Though you've still kept Serif as default Firefox family, which > *is* an ass-backwards Firefox default we should change, since current > screens do not have enough resolution to display satisfying Serif > fonts. > > P.P.S. Likewise Mozilla developpers decided at some time monospace > should be scaled down for no particular good reason, and site authors > are still fighting this error back with CSS hacks > > P.P.P.S. Also your screenshot exhibits the fugly color fringing of > subpixel hinting. It may have been your misguided choice, or the > effect of rawhide currently ignoring user settings to use grayscale > only. In any way it's not the fonts fault. > > Regards, > > -- > Nicolas Mailhot Nice analyzing but your off by far. first: saying : "No we can't." is a very final answer which is, at this moment, only yours and not said by others. With the font changing i wasn't trying to mimic a well known other operating system that is used by about 90% of the desktops. I was trying to get it back the way it was in Firefox 2 on fedora. Firefox 3 seemed to change the fonts greatly and i wanted it back to the normal view of FF2. For the rest it is looking better with those Liberation fonts (i wonder why that isn't used throughout fedora..). And for: "Also your screenshot exhibits the fugly color fringing of subpixel hinting" i noticed.. that's since i updated to rawhide. i don't know what the issue is in that place. i tried playing with gnome's font settings but up till now haven't got good results. From jkeating at redhat.com Mon Jan 28 17:41:41 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 28 Jan 2008 12:41:41 -0500 Subject: long term support release In-Reply-To: <479E1103.7080809@gmail.com> References: <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> <20080125152614.GA2975@free.fr> <20080125103335.0d5adacf@redhat.com> <20080125154127.GC2975@free.fr> <1201275741.1163.1.camel@localhost.localdomain> <20080125154749.GD2975@free.fr> <20080125105041.6605e470@redhat.com> <1201277076.17905.362.camel@beck.corsepiu.local> <479A1582.9090202@gmail.com> <1201531664.5827.15.camel@aglarond.local> <479E1103.7080809@gmail.com> Message-ID: <20080128124141.698ffae9@redhat.com> On Mon, 28 Jan 2008 11:29:39 -0600 Les Mikesell wrote: > Are you saying these desktops can't ever run on *bsd/solaris, etc. > kernels and libc's because they need features unique to this month's > linux? > > > Once upon a time (... in a galaxy far, far away) I used to build > > updated GNOME versions for older Red Hat Linux releases. It wasn't > > easy, but it was pretty constrained to a small set of packages. > > These days, I'd end up needing new hal which brings in ConsoleKit > > which ...[1] They may needa ConsoleKit like thing doing the permission changes to the devices as necessary... -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Jan 28 17:43:07 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 28 Jan 2008 12:43:07 -0500 Subject: InstantMirror needs a rethink In-Reply-To: <479E11E9.4090705@gmail.com> References: <4797D5B3.7030002@redhat.com> <16de708d0801270142u75dd7612r3d6522056df8c92f@mail.gmail.com> <479CBB29.9050904@gmail.com> <479CFDCB.6090608@filteredperception.org> <1201531969.5827.17.camel@aglarond.local> <479DEF65.1080902@fedoraproject.org> <479E11E9.4090705@gmail.com> Message-ID: <20080128124307.0716bb70@redhat.com> On Mon, 28 Jan 2008 11:33:29 -0600 Les Mikesell wrote: > What's the alternative? I normally prefer NFS installs from a nearby > downloaded-but-not-burned image. But I might change my mind if there > were a way to pre-load a cache for an http install. pxe, boot grub with downloaded kernel+initrd. But I'm not quite getting what you mean by nearby but not burned image, that implies you're doing NFS+ISO install (IE the isos in an nfs directory), and you still have to boot a machine to start the installer. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sebastian at when.com Mon Jan 28 17:45:39 2008 From: sebastian at when.com (sebastian at when.com) Date: Mon, 28 Jan 2008 18:45:39 +0100 Subject: Fedora Education Spin In-Reply-To: <59706.63.85.68.164.1201527444.squirrel@mail.jcomserv.net> References: <479B4B6A.90805@when.com> <59706.63.85.68.164.1201527444.squirrel@mail.jcomserv.net> Message-ID: <479E14C3.6000605@when.com> Hi all. Jon Ciesla wrote: > Add genchemlab and gonvert. Not too big, would add value. Done! ;) Nicu Buculei wrote: > I understand you used claws-mail as default due to size concerns, but > if you look at our application usage statistics [1], will see > Thunderbird is a much popular choice (and the package is not that > big), maybe it is a better default? I agree, Thunderbird is clearly more popular. I have created a new build with it. Seems to fit... > And how about some "advanced" applications, like Gimp and Inkscape? I > think "education" should not be only about "absolute beginners" and > having such applications available to learn is very useful. In my first tries, I had included these apps, but I removed them due to space problems. I had also thought of blender, which might be useful. In the new version, gimp and blender are included by default. Inkscape pulls in some large dependencies, so I wasn't able to include it at the moment. But I think it could be a case for an installation directly from the internet or from a second cd (just like Les proposed)... Maybe, providing a script on the desktop, which then installs a list of further apps via yum, might be the easiest way to check this out. I have thought of an: 'echo "yum install something" > somewhere on the desktop' in the kickstart file But I think this is not really convincing. If you have any other ideas, how to realize this, please tell me. Huzaifa Sidhpurwala wrote: > You are right, i totally missed this email. > However on seeing this link i think this contains very few edu apps. > Probably i can directly contribute to this rather than start my own. Well, I could for example take a test run of the whole thing and give some feedback, if you want to. Or if you have further package suggestions or other ideas, please let me know... By the way: I have uploaded the new kickstart file and extended the table a bit (http://fedoraproject.org/wiki/SebastianDziallas/Education)... Sebastian From smooge at gmail.com Mon Jan 28 17:49:24 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 28 Jan 2008 10:49:24 -0700 Subject: Suggestion: Use Liberation fonts as default in Firefox 3 In-Reply-To: <48074.192.54.193.53.1201533207.squirrel@rousalka.dyndns.org> References: <6e24a8e80801280638q467ce226oeccce8b884c9f41b@mail.gmail.com> <48074.192.54.193.53.1201533207.squirrel@rousalka.dyndns.org> Message-ID: <80d7e4090801280949v54541bfbhd1fc3aa79ffdbf44@mail.gmail.com> On Jan 28, 2008 8:13 AM, Nicolas Mailhot wrote: > > As you can see in [2] is that the fonts are looking just better. > > No we can't. > > I'm afraid that "looking better" is largely subjective when talking > about fonts. In particular people exhibit a huge bias in favour of > whatever font style they're used to. Take any decent modern font, > force a user to use it exclusively for a month, and he'll > systematically prefer it afterwards in tests. (hey, some people even > ended up liking Luxi *shudder*) > > So the only thing you've proved is you're used to a style similar to > Liberation Sans, probably Arial. Had you spent the time to accustom > yourself to Fedora defaults you'd be finding Liberation Sans terrible. > Well I agree with everything except the above paragraph. I switched over to the Liberation ones when they were announced to see how they were.. and everytime I have switched back.. I find myself moving back to the Liberations ones in a day or 2. However, I realize that deep down inside this is probably a religious choice on my part. And any advocation of what fonts would look better without large-scale empirical evidence would not be good. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From dakingun at gmail.com Mon Jan 28 18:08:53 2008 From: dakingun at gmail.com (Deji Akingunola) Date: Mon, 28 Jan 2008 13:08:53 -0500 Subject: Suggestion: Use Liberation fonts as default in Firefox 3 In-Reply-To: <6e24a8e80801280937w453b6f81haeaf4cd4ecb79bbc@mail.gmail.com> References: <6e24a8e80801280638q467ce226oeccce8b884c9f41b@mail.gmail.com> <48074.192.54.193.53.1201533207.squirrel@rousalka.dyndns.org> <6e24a8e80801280937w453b6f81haeaf4cd4ecb79bbc@mail.gmail.com> Message-ID: On Jan 28, 2008 12:37 PM, Mark wrote: > > And for: "Also your screenshot exhibits the fugly color fringing of > subpixel hinting" i noticed.. that's since i updated to rawhide. i > don't know what the issue is in that place. i tried playing with > gnome's font settings but up till now haven't got good results. > https://bugzilla.redhat.com/show_bug.cgi?id=429442 Deji From michel.sylvan at gmail.com Mon Jan 28 18:09:23 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Mon, 28 Jan 2008 13:09:23 -0500 Subject: Headsup: new API and ABI changing goffice update headed towards rawhide In-Reply-To: <479A6E04.5040502@hhs.nl> References: <479A6E04.5040502@hhs.nl> Message-ID: On Jan 25, 2008 6:17 PM, Hans de Goede wrote: > Hi All, > > I've been working on updating gnumeric to the 1.8.x tree, this needs the latest > stable 0.6 series of goffice, therefor I'm also updating goffice from 0.2 to > 0.6, which means a change in soname, and in API. > > The only other user is abiword, a patch for abiword for the 0.5 devel series of > goffice, which lead to the 0.6 release is available here: > http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/abiword-goffice05.patch?rev=1.1 > > It should be trivial to adjust this patch to make abiword 's charting plugin > work with goffice-0.6 (search replace 0.5 with 0.6). > I'm working on rebuilding abiword (preliminary goffice patch in -devel; I have a newer patch that fixes the rest of the API changes, but more below), but am running into several instances of the same problem. Building abiword, with or without the goffice patch (without the patch, goffice won't be detected so it won't be compiled in anyway), fails in several places with the same symptom: FALSE and TRUE are not defined. I was resorting to patching them one by one to false and true, but after the third time it occured to me that it might just be some headers (e.g. glib.h) are not being included. Anyone familiar with Abiword's build system and can take a look? https://bugzilla.redhat.com/show_bug.cgi?id=430346 Thanks, -- Michel Salim http://hircus.jaiku.com/ From lesmikesell at gmail.com Mon Jan 28 18:13:42 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 28 Jan 2008 12:13:42 -0600 Subject: long term support release In-Reply-To: <1201500923.3242.95.camel@beck.corsepiu.local> References: <1201058211.3001.79.camel@gandalf.cobite.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> <4799EAA0.7030700@gmail.com> <20080125102616.7605825b@redhat.com> <479A0C6B.1050004@gmail.com> <20080125112254.382c9e13@redhat.com> <479A190F.8010402@gmail.com> <200801251727.m0PHRe0O016727@laptop13.inf.utfsm.cl> <479A268B.5070201@gmail.com> <1201330199.17905.561.camel@beck.corsepiu.local> <200801270129.m0R1T0Eg000930@laptop13.inf.utfsm.cl> <1201410189.17905.709.camel@beck.corsepiu.local> <200801272221.m0RMLBhk010404@laptop13.inf.utfsm.cl> <1201500923.3242.95.camel@beck.corsepiu.local> Message-ID: <479E1B56.1090702@gmail.com> Ralf Corsepius wrote: > ?!? You do not agree that fixing bugs in libraries and applications > people tripped over when running application A in situation X, often > bugs people trip over when running other applications in other > situations? > > This has happened 1000s of times and will happen 1000s of times again. > Actually, I would consider such cases to be the norm. > >>>> In my experience, they end getting fixed by moving forward. >>> A bug is only fixed if it takes place in the current release. >> Strange definition of bug fix. > What's strange about this? In real-life manufacturers will be sued for > "not fixing bugs in a current release" - Avoiding such situations is > called "customer care". > > Customer: "Garage, when I turn on my car's head lights, the heating > starts running at full power." > Garage : "We reported it upstream to the car's manufacturer. You might > try the next model available at your local dealer next year. Until then, > open the windows." Fedora has a unique situation in this respect though. By policy RHEL will not add new features in updates and since the upstream app developer generally only cares about going forward, that means someone has to do the work of backporting bugfixes minus features into something that sort-of resembles the originally shipped app version. Fedora, however is perfectly free to fix the fedora version by shipping an update to the current app version, accepting the upstream fix in it fully-featured form. While I'd like to see the final update of a fedora rev. slipstream itself into exactly the packages in RHEL/Centos (at least in the versions where that would make sense) so no extra work would be required to continue running safely with security/bugfix updates for several more years, it could be left up to the packager to decide if he wants to ship more advanced versions (and commit to maintaining them separately). For example, I don't think it made much sense other than following policy to maintain dovecot in it's pre-1.0 version as shipped in RHEL4 after upstream did a 1.x release. -- Les Mikesell lesmikesell at gmail.com From sundaram at fedoraproject.org Mon Jan 28 18:22:21 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 28 Jan 2008 23:52:21 +0530 Subject: long term support release In-Reply-To: <479E1B56.1090702@gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> <4799EAA0.7030700@gmail.com> <20080125102616.7605825b@redhat.com> <479A0C6B.1050004@gmail.com> <20080125112254.382c9e13@redhat.com> <479A190F.8010402@gmail.com> <200801251727.m0PHRe0O016727@laptop13.inf.utfsm.cl> <479A268B.5070201@gmail.com> <1201330199.17905.561.camel@beck.corsepiu.local> <200801270129.m0R1T0Eg000930@laptop13.inf.utfsm.cl> <1201410189.17905.709.camel@beck.corsepiu.local> <200801272221.m0RMLBhk010404@laptop13.inf.utfsm.cl> <1201500923.3242.95.camel@beck.corsepiu.local> <479E1B56.1090702@gmai! l.com> Message-ID: <479E1D5D.8010906@fedoraproject.org> Les Mikesell wrote: > > Fedora has a unique situation in this respect though. By policy RHEL > will not add new features in updates and since the upstream app > developer generally only cares about going forward, that means someone > has to do the work of backporting bugfixes minus features into something > that sort-of resembles the originally shipped app version. Fedora, > however is perfectly free to fix the fedora version by shipping an > update to the current app version, accepting the upstream fix in it > fully-featured form. The situation is not as black and white as you make it out to be. RHEL has occasionally pushed new features as updates and Fedora has done backports. Rahul From bruno at wolff.to Mon Jan 28 18:14:25 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 28 Jan 2008 12:14:25 -0600 Subject: In rawhide prelink -avR doesn't work, switch to -avmR In-Reply-To: <20080128162758.GI30691@devserv.devel.redhat.com> References: <20080126222326.GA24298@wolff.to> <20080128162758.GI30691@devserv.devel.redhat.com> Message-ID: <20080128181425.GA30924@wolff.to> On Mon, Jan 28, 2008 at 11:27:58 -0500, Jakub Jelinek wrote: > On Sat, Jan 26, 2008 at 04:23:26PM -0600, Bruno Wolff III wrote: > > Why are you leaving -m out? For 32-bit address space, if you have many > shared libraries -m is very important, there isn't really enough address > space in the default ranges to fit thousands of shared libraries. > /etc/sysconfig/prelink has > PRELINK_OPTS=-mR > as the default... OK. I missed that when prelink was called in /etc/cron.daily/prelink it was pulling in extra options. So eventually prelink would have been run correctly. I just did things wrong while trying to speed the process up. (In the past not using -m worked, but I suspect that it was pretty close to not working and things switched over the limit in F9.) So this was all user error. Thanks for the help. From katzj at redhat.com Mon Jan 28 18:16:45 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 28 Jan 2008 13:16:45 -0500 Subject: space on the live cds In-Reply-To: <1201366447.3282.8.camel@localhost.localdomain> References: <1201366447.3282.8.camel@localhost.localdomain> Message-ID: <1201544205.5827.26.camel@aglarond.local> On Sat, 2008-01-26 at 11:54 -0500, Matthias Clasen wrote: > * Some devel packages get dragged in: > - policycoreutils-gui pulls in selinux-policy-devel, which in turn > pulls in checkpolicy. Why ? When I talked with Dan about this last, he said that he wanted to rename selinux-policy-devel as "devel" is a bit of a misnomer > * Some other questionable dependencies: > - man pulls in diffutils just so that man -a can optionally > use /usr/binb/cmp grub also needs diffutils for cmp so that it can verify installation was successful Jeremy From lesmikesell at gmail.com Mon Jan 28 18:22:53 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 28 Jan 2008 12:22:53 -0600 Subject: InstantMirror needs a rethink In-Reply-To: <20080128124307.0716bb70@redhat.com> References: <4797D5B3.7030002@redhat.com> <16de708d0801270142u75dd7612r3d6522056df8c92f@mail.gmail.com> <479CBB29.9050904@gmail.com> <479CFDCB.6090608@filteredperception.org> <1201531969.5827.17.camel@aglarond.local> <479DEF65.1080902@fedoraproject.org> <479E11E9.4090705@gmail.com> <20080128124307.0716bb70@redhat.com> Message-ID: <479E1D7D.10400@gmail.com> Jesse Keating wrote: >> What's the alternative? I normally prefer NFS installs from a nearby >> downloaded-but-not-burned image. But I might change my mind if there >> were a way to pre-load a cache for an http install. > > pxe, boot grub with downloaded kernel+initrd. But I'm not quite > getting what you mean by nearby but not burned image, that implies > you're doing NFS+ISO install (IE the isos in an nfs directory), and you > still have to boot a machine to start the installer. Yes, I've always found it easiest to download new install isos into an existing NFS-exported directory and burn only the boot.iso to start the install. PXE would be possible in my location but inconvenient in some of our other offices where someone else controls the DHCP setup and it would be awkward to set up an alternate lan. -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Mon Jan 28 18:28:32 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 28 Jan 2008 12:28:32 -0600 Subject: long term support release In-Reply-To: <20080128124141.698ffae9@redhat.com> References: <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <200801251307.m0PD7Flq023827@laptop13.inf.utfsm.cl> <20080125152614.GA2975@free.fr> <20080125103335.0d5adacf@redhat.com> <20080125154127.GC2975@free.fr> <1201275741.1163.1.camel@localhost.localdomain> <20080125154749.GD2975@free.fr> <20080125105041.6605e470@redhat.com> <1201277076.17905.362.camel@beck.corsepiu.local> <479A1582.9090202@gmail.com> <1201531664.5827.15.camel@aglarond.local> <479E1103.7080809@gmail.com> <20080128124141.698ffae9@redhat.com> Message-ID: <479E1ED0.3070604@gmail.com> Jesse Keating wrote: > >> Are you saying these desktops can't ever run on *bsd/solaris, etc. >> kernels and libc's because they need features unique to this month's >> linux? >> >>> Once upon a time (... in a galaxy far, far away) I used to build >>> updated GNOME versions for older Red Hat Linux releases. It wasn't >>> easy, but it was pretty constrained to a small set of packages. >>> These days, I'd end up needing new hal which brings in ConsoleKit >>> which ...[1] > > They may needa ConsoleKit like thing doing the permission changes to > the devices as necessary... I think that concept is rather bizarre anyway since I think of permissions as being tied to who you are, not where you are. But I tend to not use the physical console much either, doing most work via freenx/NX with the session resumed at an assortment of locations and client platforms. -- Les Mikesell lesmikesell at gmail.com From csnook at redhat.com Mon Jan 28 18:27:04 2008 From: csnook at redhat.com (Chris Snook) Date: Mon, 28 Jan 2008 13:27:04 -0500 Subject: F9 for Eeepc In-Reply-To: <1201317801.2756.10.camel@localhost.localdomain> References: <479A650D.8060401@cora.nwra.com> <1201317801.2756.10.camel@localhost.localdomain> Message-ID: <479E1E78.9080804@redhat.com> Dan Williams wrote: > On Fri, 2008-01-25 at 15:39 -0700, Orion Poplawski wrote: >> I got myself an Eeepc to play around with and I'd love to get Fedora >> running on it. Issues that I'm aware of: >> >> - Ethernet driver. Controller is an Attansic Tech L2 100Mbit Ethernet >> Adapter (rev a0) (0200: 1969:2048). This uses the atl2 driver. Anyone >> have any ideas on the chances of this going upstream? Interestingly I >> see this in some of the 2.0.3 files: >> >> * Copyright(c) 2007 Chris Snook > > Chris posted patches upstream on netdev a few weeks ago. It's > happening, though I forget if the driver had to go through another > revision or what. Hopefully will hit 2.6.25, though it's not in > garzik's netdev-2.6.25 yet so it might not. We (Jay Cliburn, the other atl1 maintainer, and I) just got a huge code dump from Atheros. We're currently working to integrate it into a unified atlx codebase to support atl1, atl2, and future chips from Atheros that are based on the same hardware. We're hoping to get this in 2.6.25. Anyone with an atl2 chip who wants to help test should contact me off-list. -- Chris From vonbrand at inf.utfsm.cl Mon Jan 28 18:26:55 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Mon, 28 Jan 2008 15:26:55 -0300 Subject: bodhi 0.4.10 features In-Reply-To: <18385.1201500513@sss.pgh.pa.us> References: <20080125205437.GA3993@crow> <20080127225406.GG3054@crow> <479D4038.1020402@ioa.s.u-tokyo.ac.jp> <17179.1201492236@sss.pgh.pa.us> <20080128042616.GA23022@crow> <18385.1201500513@sss.pgh.pa.us> Message-ID: <200801281826.m0SIQtU8012589@laptop13.inf.utfsm.cl> Tom Lane wrote: > "Jon Stanley" writes: > > On Jan 27, 2008 11:26 PM, Luke Macken wrote: > >> Sorry for the confusion. Jon's proposal[0] was approved at the last FESCo > >> meeting, but it doesn't specify what to close the bugs as. John > >> Poelstra's bug workflow[1] page illustrates Jon's proposal, but specifies > >> that bugs be closed as RAWHIDE. > > > I'm not sure what the purpose of RAWHIDE here is....it's obviously not > > rawhide by the time that it hits stable. > > One other point here, if I haven't worn out my welcome. The > previously-cited page defining bug closure states says that RAWHIDE > "should not be used for RHEL bugs", but that is obviously a RHEL-centric > definition. I argue that in the context of Fedora, RAWHIDE should only > be used to close bugs filed against the current development version (ie, > rawhide) that don't exist in any released version. If a bug has gotten > into a release branch then it should get closed as ERRATA or > CURRENTRELEASE, as appropriate. To simplify things, if the current release for the package fixes the bug, CURRENTRELEASE. Doen't matter if the package is in F or rawhide. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From lesmikesell at gmail.com Mon Jan 28 18:35:47 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 28 Jan 2008 12:35:47 -0600 Subject: long term support release In-Reply-To: <479E1D5D.8010906@fedoraproject.org> References: <1201058211.3001.79.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> <4799EAA0.7030700@gmail.com> <20080125102616.7605825b@redhat.com> <479A0C6B.1050004@gmail.com> <20080125112254.382c9e13@redhat.com> <479A190F.8010402@gmail.com> <200801251727.m0PHRe0O016727@laptop13.inf.utfsm.cl> <479A268B.5070201@gmail.com> <1201330199.17905.561.camel@beck.corsepiu.local> <200801270129.m0R1T0Eg000930@laptop13.inf.utfsm.cl> <1201410189.17905.709.camel@beck.corsepiu.local> <200801272221.m0RMLBhk010404@laptop13.inf.utfsm.cl> <1201500923.3242.95.camel@beck.corsepiu.local> <479E1B56.1090702@gmai! l.com> <479E1D5D.8010906@fedoraproject.org> Message-ID: <479E2083.2020106@gmail.com> Rahul Sundaram wrote: >> Fedora has a unique situation in this respect though. By policy RHEL >> will not add new features in updates and since the upstream app >> developer generally only cares about going forward, that means someone >> has to do the work of backporting bugfixes minus features into >> something that sort-of resembles the originally shipped app version. >> Fedora, however is perfectly free to fix the fedora version by >> shipping an update to the current app version, accepting the upstream >> fix in it fully-featured form. > > The situation is not as black and white as you make it out to be. RHEL > has occasionally pushed new features as updates and Fedora has done > backports. > Agreed, but there is a general trend... And ideally, I'd like to see alternative update repos so both could be available for everything that could be built both ways so only the people with their own 'no new features' policies would be stuck with the downrev versions of applications they use. -- Les Mikesell lesmikesell at gmail.com From nicolas.mailhot at laposte.net Mon Jan 28 18:37:26 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 28 Jan 2008 19:37:26 +0100 Subject: Suggestion: Use Liberation fonts as default in Firefox 3 In-Reply-To: <80d7e4090801280949v54541bfbhd1fc3aa79ffdbf44@mail.gmail.com> References: <6e24a8e80801280638q467ce226oeccce8b884c9f41b@mail.gmail.com> <48074.192.54.193.53.1201533207.squirrel@rousalka.dyndns.org> <80d7e4090801280949v54541bfbhd1fc3aa79ffdbf44@mail.gmail.com> Message-ID: <1201545446.13777.10.camel@rousalka.dyndns.org> Le lundi 28 janvier 2008 ? 10:49 -0700, Stephen John Smoogen a ?crit : > Well I agree with everything except the above paragraph. I switched > over to the Liberation ones when they were announced to see how they > were.. and everytime I have switched back.. I find myself moving back > to the Liberations ones in a day or 2. > > However, I realize that deep down inside this is probably a religious > choice on my part. And any advocation of what fonts would look better > without large-scale empirical evidence would not be good. It's pretty sobering to read the net archives at about the time Microsoft released Arial. You find the very same arguments against Arial by people claiming Helvetica was the one and true font, that people used to Arial make against other fonts now. It shows how subjective the subject is. Arial will pass away like Helvetica did eventually. (now don't take me wrong there *are* bad fonts and you *can* make arguments against them but they need to be awfully more detailed than "this is obviously better" to have any weight). IMHO instead of bickering about firefox font defaults it would be way better to rip them out and have it use desktop font settings instead, so Liberation lovers can have a Liberation desktop, Luxi lovers a Luxi one, etc. The whole "it looks different in Windows" argument is flawed. If we aimed at windows emulation we'd have hard-coded a windows-alike them in Firefox instead of working hard to integrate in in our desktop. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From sundaram at fedoraproject.org Mon Jan 28 18:55:36 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 29 Jan 2008 00:25:36 +0530 Subject: long term support release In-Reply-To: <479E2083.2020106@gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> <4799EAA0.7030700@gmail.com> <20080125102616.7605825b@redhat.com> <479A0C6B.1050004@gmail.com> <20080125112254.382c9e13@redhat.com> <479A190F.8010402@gmail.com> <200801251727.m0PHRe0O016727@laptop13.inf.utfsm.cl> <479A268B.5070201@gmail.com> <1201330199.17905.561.camel@beck.corsepiu.local> <200801270129.m0R1T0Eg000930@laptop13.inf.utfsm.cl> <1201410189.17905.709.camel@beck.corsepiu.local> <200801272221.m0RMLBhk010404@laptop13.inf.utfsm.cl> <1201500923.3242.95.camel@beck.corsepiu.local> <479E1B56.1090702@gmai! l.com> <479E1D5D.8010906@fedoraproject.org> <479E2083.2020106@gmail.com> Message-ID: <479E2528.5030101@fedoraproject.org> Les Mikesell wrote: \ > Agreed, but there is a general trend... And ideally, I'd like to see > alternative update repos so both could be available for everything that > could be built both ways so only the people with their own 'no new > features' policies would be stuck with the downrev versions of > applications they use. There are alternative repos available for sometime and was even discussed in fedora-list before. If you missed it, post there and ask and contribute to them if you can. Rahul From nicolas.mailhot at laposte.net Mon Jan 28 18:50:08 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 28 Jan 2008 19:50:08 +0100 Subject: Suggestion: Use Liberation fonts as default in Firefox 3 In-Reply-To: <6e24a8e80801280937w453b6f81haeaf4cd4ecb79bbc@mail.gmail.com> References: <6e24a8e80801280638q467ce226oeccce8b884c9f41b@mail.gmail.com> <48074.192.54.193.53.1201533207.squirrel@rousalka.dyndns.org> <6e24a8e80801280937w453b6f81haeaf4cd4ecb79bbc@mail.gmail.com> Message-ID: <1201546208.13777.21.camel@rousalka.dyndns.org> Le lundi 28 janvier 2008 ? 18:37 +0100, Mark a ?crit : > 2008/1/28, Nicolas Mailhot : > > > > Le Lun 28 janvier 2008 15:38, Mark a ?crit : > > > As you can see in [2] is that the fonts are looking just better. > > > > No we can't. > Nice analyzing but your off by far. > first: saying : "No we can't." is a very final answer which is, at > this moment, only yours and not said by others. It don't need to claim [2] is worse for everyone to contradict your statement that in [2] "the fonts are looking just better". I just need to point one dissenting opinion to show things are not "just" so. > With the font changing i wasn't trying to mimic a well known other > operating system that is used by about 90% of the desktops. I was > trying to get it back the way it was in Firefox 2 on fedora. Firefox 3 > seemed to change the fonts greatly and i wanted it back to the normal > view of FF2. Firefox 3 uses a cairo based renderer. It's not going to look like Firefox 2 on any platform. This is not due to font settings changes. > For the rest it is looking better with those Liberation fonts (i > wonder why that isn't used throughout fedora..). Because opinions on Liberation vary, before this month update it had obvious flaws (and the update has its own problems), and no one really knows what will happen to Liberation once Red Hat stops contacting Ascender. We do ship Liberation by default on evary desktop with a pretty high priority (2nd highest right now) so it's not like it's being ignored. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From mcepl at redhat.com Mon Jan 28 18:50:52 2008 From: mcepl at redhat.com (Matej Cepl) Date: Mon, 28 Jan 2008 19:50:52 +0100 Subject: Nokia wants to buy Trolltech References: <200801281528.m0SFSd2m014633@jasmine.xos.nl> <16de708d0801280732seb7d466o79745577e7156212@mail.gmail.com> Message-ID: On 2008-01-28, 15:32 GMT, Arthur Pemberton wrote: > On Jan 28, 2008 9:28 AM, Jos Vos wrote: >> >> FYI: Nokia wants to buy Trolltech: >> >> http://trolltech.com/company/newsroom/announcements\ >> /press.2008-01-28.4605718236 > > I think it is past-tense now, http://trolltech.com/28012008/28012008 Isn't this weird -- what about their using Gnome in Maemo? Mat?j From lesmikesell at gmail.com Mon Jan 28 19:08:05 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 28 Jan 2008 13:08:05 -0600 Subject: long term support release In-Reply-To: <479E2528.5030101@fedoraproject.org> References: <1201058211.3001.79.camel@gandalf.cobite.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> <4799EAA0.7030700@gmail.com> <20080125102616.7605825b@redhat.com> <479A0C6B.1050004@gmail.com> <20080125112254.382c9e13@redhat.com> <479A190F.8010402@gmail.com> <200801251727.m0PHRe0O016727@laptop13.inf.utfsm.cl> <479A268B.5070201@gmail.com> <1201330199.17905.561.camel@beck.corsepiu.local> <200801270129.m0R1T0Eg000930@laptop13.inf.utfsm.cl> <1201410189.17905.709.camel@beck.corsepiu.local> <200801272221.m0RMLBhk010404@laptop13.inf.utfsm.cl> <1201500923.3242.95.camel@beck.corsepiu.local> <479E1B56.1090702@gmai! l.com> <479E1D5D.8010906@fedoraproject.org> <479E2083.2020106@gmail.com> <479E2528.5030101@fedoraproject.or! g> Message-ID: <479E2815.6050705@gmail.com> Rahul Sundaram wrote: > Les Mikesell wrote: > \ >> Agreed, but there is a general trend... And ideally, I'd like to see >> alternative update repos so both could be available for everything >> that could be built both ways so only the people with their own 'no >> new features' policies would be stuck with the downrev versions of >> applications they use. > > There are alternative repos available for sometime and was even > discussed in fedora-list before. If you missed it, post there and ask > and contribute to them if you can. The alternate repos I'm looking for would have current or fedora-rev apps built to install in RHEL/CentOS, hopefully with at least as much QA as fedora updates would have. If that exists I have missed it. -- Les Mikesell lesmikesell at gmail.com From sundaram at fedoraproject.org Mon Jan 28 19:19:15 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 29 Jan 2008 00:49:15 +0530 Subject: long term support release In-Reply-To: <479E2815.6050705@gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> <4799EAA0.7030700@gmail.com> <20080125102616.7605825b@redhat.com> <479A0C6B.1050004@gmail.com> <20080125112254.382c9e13@redhat.com> <479A190F.8010402@gmail.com> <200801251727.m0PHRe0O016727@laptop13.inf.utfsm.cl> <479A268B.5070201@gmail.com> <1201330199.17905.561.camel@beck.corsepiu.local> <200801270129.m0R1T0Eg000930@laptop13.inf.utfsm.cl> <1201410189.17905.709.camel@beck.corsepiu.local> <200801272221.m0RMLBhk010404@laptop13.inf.utfsm.cl> <1201500923.3242.95.camel@beck.corsepiu.local> <479E1B56.1090702@gmai! l.com> <479E1D5D.8010906@fedoraproject.org> <479E2083.2020106@gmail.com> <479E2528.5030101@fedoraproject.or! g> <479E2815.6050705@gmail.com> Message-ID: <479E2AB3.4000302@fedoraproject.org> Les Mikesell wrote: > > The alternate repos I'm looking for would have current or fedora-rev > apps built to install in RHEL/CentOS, hopefully with at least as much QA > as fedora updates would have. If that exists I have missed it. Yes. That was what was announced. I frequently delete the archives so look it up yourself or ask in the list. Rahul From loupgaroublond at gmail.com Mon Jan 28 19:16:11 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Mon, 28 Jan 2008 14:16:11 -0500 Subject: Nokia wants to buy Trolltech In-Reply-To: References: <200801281528.m0SFSd2m014633@jasmine.xos.nl> <16de708d0801280732seb7d466o79745577e7156212@mail.gmail.com> Message-ID: <7f692fec0801281116j2873b7e4i6f91bf172d6f19d3@mail.gmail.com> On Jan 28, 2008 1:50 PM, Matej Cepl wrote: > On 2008-01-28, 15:32 GMT, Arthur Pemberton wrote: > > On Jan 28, 2008 9:28 AM, Jos Vos wrote: > >> > >> FYI: Nokia wants to buy Trolltech: > >> > >> http://trolltech.com/company/newsroom/announcements\ > >> /press.2008-01-28.4605718236 > > > > I think it is past-tense now, http://trolltech.com/28012008/28012008 > > Isn't this weird -- what about their using Gnome in Maemo? Not to knock Gnome or GTK+, but QT is a more robust framework. QT in C++ is easier to program than GTK+ in C. QT has alot of constructs in it for data containers and multithreading, which if I understand correctly, are better than GTK+ on a technical standpoint. From a desktop perspective, things like application resizing and other graphical aspects 'perform better' than GTK+ programs. I'm sure Benjamin Kreuter is going to argue the flexibility of KParts as well. I think Nokia either might just be hedging their bets, or actually plan on using a QT framework for something. -Yaakov From joachim.frieben at googlemail.com Mon Jan 28 19:18:33 2008 From: joachim.frieben at googlemail.com (Joachim Frieben) Date: Mon, 28 Jan 2008 20:18:33 +0100 Subject: Suggestion: Use Liberation fonts as default in Firefox 3 In-Reply-To: References: <6e24a8e80801280638q467ce226oeccce8b884c9f41b@mail.gmail.com> <48074.192.54.193.53.1201533207.squirrel@rousalka.dyndns.org> <6e24a8e80801280937w453b6f81haeaf4cd4ecb79bbc@mail.gmail.com> Message-ID: <1c252d490801281118h37f671bcu22774c7c1374c0bf@mail.gmail.com> > > And for: "Also your screenshot exhibits the ugly color fringing of > > subpixel hinting" i noticed.. that's since i updated to rawhide. i > > don't know what the issue is in that place. i tried playing with > > gnome's font settings but up till now haven't got good results. > > > https://bugzilla.redhat.com/show_bug.cgi?id=429442 > > Deji This bug not only affects font hinting options (which are not taken into account anymore) but also GNOME system sounds which were muted until I removed gnome-settings-daemon and downgraded control-center and gdm according to rawhide as of 2008-01-17. gnome-settings-daemon had been introduced as a new package in rawhide on 2008-01-18. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Mon Jan 28 19:23:20 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 28 Jan 2008 14:23:20 -0500 Subject: InstantMirror needs a rethink In-Reply-To: <479E1D7D.10400@gmail.com> References: <4797D5B3.7030002@redhat.com> <16de708d0801270142u75dd7612r3d6522056df8c92f@mail.gmail.com> <479CBB29.9050904@gmail.com> <479CFDCB.6090608@filteredperception.org> <1201531969.5827.17.camel@aglarond.local> <479DEF65.1080902@fedoraproject.org> <479E11E9.4090705@gmail.com> <20080128124307.0716bb70@redhat.com> <479E1D7D.10400@gmail.com> Message-ID: <20080128142320.19a90ef4@redhat.com> On Mon, 28 Jan 2008 12:22:53 -0600 Les Mikesell wrote: > Yes, I've always found it easiest to download new install isos into > an existing NFS-exported directory and burn only the boot.iso to > start the install. PXE would be possible in my location but > inconvenient in some of our other offices where someone else controls > the DHCP setup and it would be awkward to set up an alternate lan. bootdisk.img will likely continue to exist, which is the same as boot.iso but designed to run on USB sticks. Who knows, boot.iso may not actually "go away" per se, but will no longer be the touted method to start your install. rescue.iso is much nicer in this regard as it has all the content you would have to download again anyway (stage2). -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mcepl at redhat.com Mon Jan 28 19:15:44 2008 From: mcepl at redhat.com (Matej Cepl) Date: Mon, 28 Jan 2008 20:15:44 +0100 Subject: Suggestion: Use Liberation fonts as default in Firefox 3 References: <6e24a8e80801280638q467ce226oeccce8b884c9f41b@mail.gmail.com> <48074.192.54.193.53.1201533207.squirrel@rousalka.dyndns.org> Message-ID: <08m175xlce.ln2@ppp1053.in.ipex.cz> On 2008-01-28, 15:13 GMT, Nicolas Mailhot wrote: >> As you can see in [2] is that the fonts are looking just >> better. > > No we can't. > > I'm afraid that "looking better" is largely subjective when talking > about fonts. In particular people exhibit a huge bias in favour of > whatever font style they're used to. Take any decent modern font, > force a user to use it exclusively for a month, and he'll > systematically prefer it afterwards in tests. (hey, some people even > ended up liking Luxi *shudder*) Yes we can, kind of. Of course, that there is a lot of "nice is what I am used to", but there is some real logic in it. One of the thing which is not whimsical is that Times in its original form was not meant to be a basic font for general use, but pretty specific one -- i.e., to be used in typesetting newspapers. That means pretty specific requirements, one of them is ability to fit into pretty narrow columns which happen in newspapers. Therefore, Times (and Times New Roman, and Liberation Serif) are much narrower than what's considered general use fonts. Deja Serif (and Palatino, Baskerville, Bembo, and many other fonts, which are used in general typesetting as a basic, Czech typographers call it bread, font) are slightly wider, and so more easy to read (the optimal width of the line is known to be approx. 60 characters per line, Times unless patologically large -- that's the reason, why people use so huge font sizes -- gives usually much much more than that). Note, that I am saying no word about Helvetica, Arial, Deja Sans, or Courier, Courier New, Deja Sans Mono, even though even here I prefer personally Deja ones. But that's my personal preference. Times is inappropriate as a default font even from rational (or semi-rational) point of view. Matej From notting at redhat.com Mon Jan 28 19:33:56 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 28 Jan 2008 14:33:56 -0500 Subject: Headsup: new API and ABI changing goffice update headed towards rawhide In-Reply-To: <479A6E04.5040502@hhs.nl> References: <479A6E04.5040502@hhs.nl> Message-ID: <20080128193356.GC23702@nostromo.devel.redhat.com> Hans de Goede (j.w.r.degoede at hhs.nl) said: > Another problem is that we also have the special goffice04 package as some > packages needed goffice-0.4, while others where still using 0.2 . For now > we can keep this package until the 0.4 users move over to 0.6, but there is > a conflict between goffice04 and the new goffice-devel . The problem are a > bunch of files under /usr/share/gtk-doc/html/goffice. Notice that this are > API reference doc, so in the goffice04 case the are wrongly in the main > package and they should be moved to the -devel package. This would make the > conflict less severe as it then is a conflict between devel files, but > still a conflict. Suggestion, move those files to the -devel package of > goffice04 and put them under /usr/share/gtk-doc/html/goffice04 to avoid the > conflict. gnucash rebuilt, so that's one less goffice04 user in rawhide. Bill From lesmikesell at gmail.com Mon Jan 28 20:03:36 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 28 Jan 2008 14:03:36 -0600 Subject: long term support release In-Reply-To: <479E2AB3.4000302@fedoraproject.org> References: <1201058211.3001.79.camel@gandalf.cobite.com> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> <4799EAA0.7030700@gmail.com> <20080125102616.7605825b@redhat.com> <479A0C6B.1050004@gmail.com> <20080125112254.382c9e13@redhat.com> <479A190F.8010402@gmail.com> <200801251727.m0PHRe0O016727@laptop13.inf.utfsm.cl> <479A268B.5070201@gmail.com> <1201330199.17905.561.camel@beck.corsepiu.local> <200801270129.m0R1T0Eg000930@laptop13.inf.utfsm.cl> <1201410189.17905.709.camel@beck.corsepiu.local> <200801272221.m0RMLBhk010404@laptop13.inf.utfsm.cl> <1201500923.3242.95.camel@beck.corsepiu.local> <479E1B56.1090702@gmai! l.com> <479E1D5D.8010906@fedoraproject.org> <479E2083.2020106@gmail.com> <479E2528.5030101@fedoraproject.or! g> <479E2815.6050705@gmail.com> <479E2AB3.4000302@fedoraproject.org> Message-ID: <479E3518.1090003@gmail.com> Rahul Sundaram wrote: >> >> The alternate repos I'm looking for would have current or fedora-rev >> apps built to install in RHEL/CentOS, hopefully with at least as much >> QA as fedora updates would have. If that exists I have missed it. > > Yes. That was what was announced. I frequently delete the archives so > look it up yourself or ask in the list. I've seen announcements like that over the years but they all looked like one-man shows instead of an actual project that you could count on continuing. On the other hand I guess freshrpms started that way ages ago and is still very usable. -- Les Mikesell lesmikesell at gmail.com From sundaram at fedoraproject.org Mon Jan 28 20:18:23 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 29 Jan 2008 01:48:23 +0530 Subject: long term support release In-Reply-To: <479E3518.1090003@gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> <4799EAA0.7030700@gmail.com> <20080125102616.7605825b@redhat.com> <479A0C6B.1050004@gmail.com> <20080125112254.382c9e13@redhat.com> <479A190F.8010402@gmail.com> <200801251727.m0PHRe0O016727@laptop13.inf.utfsm.cl> <479A268B.5070201@gmail.com> <1201330199.17905.561.camel@beck.corsepiu.local> <200801270129.m0R1T0Eg000930@laptop13.inf.utfsm.cl> <1201410189.17905.709.camel@beck.corsepiu.local> <200801272221.m0RMLBhk010404@laptop13.inf.utfsm.cl> <1201500923.3242.95.camel@beck.corsepiu.local> <479E1B56.1090702@gmai! l.com> <479E1D5D.8010906@fedoraproject.org> <479E2083.2020106@gmail.com> <479E2528.5030101@fedoraproject.or! g> <479E2815.6050705@gmail.com> <479E2AB3.4000302@fedoraproject.org> <479E3518.1090003@gmail.com> Message-ID: <479E388F.200@fedoraproject.org> Les Mikesell wrote: > I've seen announcements like that over the years but they all looked > like one-man shows instead of an actual project that you could count on > continuing. Apparently you are the person in need of it. So instead of complaining about "one man shows" which includes entire distributions like Slackware btw, you could contribute to them. Rahul From ibmalone at gmail.com Mon Jan 28 20:09:25 2008 From: ibmalone at gmail.com (Ian Malone) Date: Mon, 28 Jan 2008 20:09:25 +0000 Subject: Suggestion: Use Liberation fonts as default in Firefox 3 In-Reply-To: <1201545446.13777.10.camel@rousalka.dyndns.org> References: <6e24a8e80801280638q467ce226oeccce8b884c9f41b@mail.gmail.com> <48074.192.54.193.53.1201533207.squirrel@rousalka.dyndns.org> <80d7e4090801280949v54541bfbhd1fc3aa79ffdbf44@mail.gmail.com> <1201545446.13777.10.camel@rousalka.dyndns.org> Message-ID: <479E3675.7070004@gmail.com> Nicolas Mailhot wrote: > Le lundi 28 janvier 2008 ? 10:49 -0700, Stephen John Smoogen a ?crit : > >> Well I agree with everything except the above paragraph. I switched >> over to the Liberation ones when they were announced to see how they >> were.. and everytime I have switched back.. I find myself moving back >> to the Liberations ones in a day or 2. >> >> However, I realize that deep down inside this is probably a religious >> choice on my part. And any advocation of what fonts would look better >> without large-scale empirical evidence would not be good. > > It's pretty sobering to read the net archives at about the time > Microsoft released Arial. You find the very same arguments against Arial > by people claiming Helvetica was the one and true font, that people used The major argument against Arial is that it MS chose it because it looked like Helvetica. > to Arial make against other fonts now. It shows how subjective the > subject is. Arial will pass away like Helvetica did eventually. (now Helvetica has passed away? > don't take me wrong there *are* bad fonts and you *can* make arguments > against them but they need to be awfully more detailed than "this is > obviously better" to have any weight). > > IMHO instead of bickering about firefox font defaults it would be way > better to rip them out and have it use desktop font settings instead, so > Liberation lovers can have a Liberation desktop, Luxi lovers a Luxi one, > etc. This is a sound idea. -- imalone From ben.kreuter at gmail.com Mon Jan 28 20:14:13 2008 From: ben.kreuter at gmail.com (Benjamin Kreuter) Date: Mon, 28 Jan 2008 15:14:13 -0500 Subject: Nokia wants to buy Trolltech In-Reply-To: <7f692fec0801281116j2873b7e4i6f91bf172d6f19d3@mail.gmail.com> References: <200801281528.m0SFSd2m014633@jasmine.xos.nl> <7f692fec0801281116j2873b7e4i6f91bf172d6f19d3@mail.gmail.com> Message-ID: <200801281514.18358.ben.kreuter@gmail.com> On Monday 28 January 2008 14:16:11 Yaakov Nemoy wrote: > Not to knock Gnome or GTK+, but QT is a more robust framework. QT in > C++ is easier to program than GTK+ in C. QT has alot of constructs in > it for data containers and multithreading, which if I understand > correctly, are better than GTK+ on a technical standpoint. That much is true. The signals/slots mechanism is thread safe, and there is a mutex mechanism that is pretty easy to use. Also, Qt4 has STL support, so you can use standard containers and algorithms in an application (other toolkits will probably do this soon also; I know wxWidgets is moving in that direction). > From a > desktop perspective, things like application resizing and other > graphical aspects 'perform better' than GTK+ programs. I'm sure > Benjamin Kreuter is going to argue the flexibility of KParts as well. I've been trying to stay as far away from that topic as possible, in the hopes of avoiding a massive flamewar, but yes, KParts is one of the better OLE systems out there. However, KParts is not a Trolltech product, it is just related to it because the people who wrote KParts were using Qt. Nokia probably won't be buying the KDE project. -- Benjamin Kreuter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From caillon at redhat.com Mon Jan 28 20:19:25 2008 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 28 Jan 2008 15:19:25 -0500 Subject: Headsup: new API breaking libgda on its way to rawhide In-Reply-To: <479A0D89.2050801@hhs.nl> References: <479A0D89.2050801@hhs.nl> Message-ID: <479E38CD.9090904@redhat.com> On 01/25/2008 11:25 AM, Hans de Goede wrote: > the API of > libgda-report-3.0.so.3 has changed (but not the soname ???). We should make sure that gets resolved upstream. From nicolas.mailhot at laposte.net Mon Jan 28 20:28:45 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 28 Jan 2008 21:28:45 +0100 Subject: Suggestion: Use Liberation fonts as default in Firefox 3 In-Reply-To: <479E3675.7070004@gmail.com> References: <6e24a8e80801280638q467ce226oeccce8b884c9f41b@mail.gmail.com> <48074.192.54.193.53.1201533207.squirrel@rousalka.dyndns.org> <80d7e4090801280949v54541bfbhd1fc3aa79ffdbf44@mail.gmail.com> <1201545446.13777.10.camel@rousalka.dyndns.org> <479E3675.7070004@gmail.com> Message-ID: <1201552125.13777.27.camel@rousalka.dyndns.org> Le lundi 28 janvier 2008 ? 20:09 +0000, Ian Malone a ?crit : > Nicolas Mailhot wrote: > > It's pretty sobering to read the net archives at about the time > > Microsoft released Arial. You find the very same arguments against Arial > > by people claiming Helvetica was the one and true font, that people used > > The major argument against Arial is that it MS chose it because it > looked like Helvetica. And that it's ugly as a sin, and that users won't ever like it, and that fonts were meant to be drawn as Helvetica was. > > to Arial make against other fonts now. It shows how subjective the > > subject is. Arial will pass away like Helvetica did eventually. (now > > Helvetica has passed away? Passed away as ubiquituous font most everyone has certainly. I've no illusion about anything widespread disappearing in our current networked digital way (say hi to next decade's NSA archivist) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From caillon at redhat.com Mon Jan 28 21:02:39 2008 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 28 Jan 2008 16:02:39 -0500 Subject: Fedora Education Spin In-Reply-To: <479CBF5F.80807@gmail.com> References: <479B4B6A.90805@when.com> <50baabb30801261000g690bfc40w80fdff6cca0efd35@mail.gmail.com> <479B85DD.5090406@when.com> <479B890A.3030903@fedoraproject.org> <20080126194213.1a466781@redhat.com> <479BD6C7.3010608@fedoraproject.org> <20080126195027.0cefe0ad@redhat.com> <479BDAA4.6070304@fedoraproject.org> <20080127025259.32e47cee@lain.camperquake.de> <479BE80A.5080309@fedoraproject.org> <479C727B.7060308@when.com> <479CBF5F.80807@gmail.com> Message-ID: <479E42EF.7020206@redhat.com> On 01/27/2008 12:29 PM, Les Mikesell wrote: > Would it be possible to build a 1-CD base install that would then give > you the option of doing a 'yum groupinstall some_big_set' if you have a > good internet connection, or installing that set from a separate CD that > does not have any of the base system on it? We could even call it Fedora Core! From pemboa at gmail.com Mon Jan 28 21:07:33 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 28 Jan 2008 15:07:33 -0600 Subject: Nokia wants to buy Trolltech In-Reply-To: <7f692fec0801281116j2873b7e4i6f91bf172d6f19d3@mail.gmail.com> References: <200801281528.m0SFSd2m014633@jasmine.xos.nl> <16de708d0801280732seb7d466o79745577e7156212@mail.gmail.com> <7f692fec0801281116j2873b7e4i6f91bf172d6f19d3@mail.gmail.com> Message-ID: <16de708d0801281307m245687aawb716a22885084386@mail.gmail.com> On Jan 28, 2008 1:16 PM, Yaakov Nemoy wrote: > On Jan 28, 2008 1:50 PM, Matej Cepl wrote: > > On 2008-01-28, 15:32 GMT, Arthur Pemberton wrote: > > > On Jan 28, 2008 9:28 AM, Jos Vos wrote: > > >> > > >> FYI: Nokia wants to buy Trolltech: > > >> > > >> http://trolltech.com/company/newsroom/announcements\ > > >> /press.2008-01-28.4605718236 > > > > > > I think it is past-tense now, http://trolltech.com/28012008/28012008 > > > > Isn't this weird -- what about their using Gnome in Maemo? > > Not to knock Gnome or GTK+, but QT is a more robust framework. QT in > C++ is easier to program than GTK+ in C. QT has alot of constructs in > it for data containers and multithreading, which if I understand > correctly, are better than GTK+ on a technical standpoint. From a > desktop perspective, things like application resizing and other > graphical aspects 'perform better' than GTK+ programs. I'm sure > Benjamin Kreuter is going to argue the flexibility of KParts as well. > > I think Nokia either might just be hedging their bets, or actually > plan on using a QT framework for something. > > -Yaakov Also, Qt is _alot_ more than a GUI toolkit. As far as I understand, Gtk+ is just a GUI toolkit -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From behdad at behdad.org Mon Jan 28 21:13:34 2008 From: behdad at behdad.org (Behdad Esfahbod) Date: Mon, 28 Jan 2008 16:13:34 -0500 Subject: Nokia wants to buy Trolltech In-Reply-To: <16de708d0801281307m245687aawb716a22885084386@mail.gmail.com> References: <200801281528.m0SFSd2m014633@jasmine.xos.nl> <16de708d0801280732seb7d466o79745577e7156212@mail.gmail.com> <7f692fec0801281116j2873b7e4i6f91bf172d6f19d3@mail.gmail.com> <16de708d0801281307m245687aawb716a22885084386@mail.gmail.com> Message-ID: <1201554814.28890.22.camel@behdad.behdad.org> On Mon, 2008-01-28 at 15:07 -0600, Arthur Pemberton wrote: > Also, Qt is _alot_ more than a GUI toolkit. As far as I understand, > Gtk+ is just a GUI toolkit Is this discussion really relevant to this list? -- behdad http://behdad.org/ "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin, 1759 From lmacken at redhat.com Mon Jan 28 21:20:16 2008 From: lmacken at redhat.com (Luke Macken) Date: Mon, 28 Jan 2008 16:20:16 -0500 Subject: bodhi 0.4.10 features In-Reply-To: <20080128074634.162c0d77@redhat.com> References: <20080125205437.GA3993@crow> <20080127225406.GG3054@crow> <479D4038.1020402@ioa.s.u-tokyo.ac.jp> <17179.1201492236@sss.pgh.pa.us> <20080128042616.GA23022@crow> <20080128074634.162c0d77@redhat.com> Message-ID: <20080128212016.GJ23022@crow> On Mon, Jan 28, 2008 at 07:46:34AM -0500, Jesse Keating wrote: > On Mon, 28 Jan 2008 00:06:08 -0500 > "Jon Stanley" wrote: > > > I'm not sure what the purpose of RAWHIDE here is....it's obviously not > > rawhide by the time that it hits stable. The important thing to take > > away from what was decided at FESCo is that the checkbox to not > > auto-close bugs is/will be no more. > > WHAT? That's not what I voted for at all in FESCo. I voted that you > can opt-out of auto bug handling, at which point all bets are off and > we won't touch a bug at all. But if you stay opted in for bug > handling, you get our handling, you don't get to pick and choose what > happens. All or nothing. Not no choice at all. So, it seems as if there is lots of confusion as to what got approved during the last FESCo meeting. Until an official decision has been made, I've reverted bodhi back to it's previous behavior -- which allows devs to opt out of bodhi's bug-mangling. luke From martin at marquesminen.com.ar Mon Jan 28 21:23:53 2008 From: martin at marquesminen.com.ar (Martin Marques) Date: Mon, 28 Jan 2008 19:23:53 -0200 Subject: InstantMirror needs a rethink In-Reply-To: <479DEF65.1080902@fedoraproject.org> References: <4797D5B3.7030002@redhat.com> <16de708d0801270142u75dd7612r3d6522056df8c92f@mail.gmail.com> <479CBB29.9050904@gmail.com> <479CFDCB.6090608@filteredperception.org> <1201531969.5827.17.camel@aglarond.local> <479DEF65.1080902@fedoraproject.org> Message-ID: <479E47E9.1030307@marquesminen.com.ar> Rahul Sundaram escribi?: > Jeremy Katz wrote: >> On Sun, 2008-01-27 at 15:55 -0600, Douglas McClendon wrote: >>> I'm still waiting for someone to tell me how to accomplish the same >>> thing for an anaconda install (kickstart or regular). >> >> We'll hopefully be having some proxy support within the second stage[1] >> in Fedora 9 >> >> Jeremy >> >> [1] This means that you'll need to be booting from the >> to-be-renamed-rescuecd.iso as opposed to boot.iso or at least have a >> direct URL to a stage2.img. But packages via a proxy is part of the >> plan > > Isn't it the plan to get rid of boot.iso entirely? Can I ask where to get InstantMirror? yum doesn't find anything. From martin at marquesminen.com.ar Mon Jan 28 21:23:53 2008 From: martin at marquesminen.com.ar (Martin Marques) Date: Mon, 28 Jan 2008 19:23:53 -0200 Subject: InstantMirror needs a rethink In-Reply-To: <479DEF65.1080902@fedoraproject.org> References: <4797D5B3.7030002@redhat.com> <16de708d0801270142u75dd7612r3d6522056df8c92f@mail.gmail.com> <479CBB29.9050904@gmail.com> <479CFDCB.6090608@filteredperception.org> <1201531969.5827.17.camel@aglarond.local> <479DEF65.1080902@fedoraproject.org> Message-ID: <479E47E9.1030307@marquesminen.com.ar> Rahul Sundaram escribi?: > Jeremy Katz wrote: >> On Sun, 2008-01-27 at 15:55 -0600, Douglas McClendon wrote: >>> I'm still waiting for someone to tell me how to accomplish the same >>> thing for an anaconda install (kickstart or regular). >> >> We'll hopefully be having some proxy support within the second stage[1] >> in Fedora 9 >> >> Jeremy >> >> [1] This means that you'll need to be booting from the >> to-be-renamed-rescuecd.iso as opposed to boot.iso or at least have a >> direct URL to a stage2.img. But packages via a proxy is part of the >> plan > > Isn't it the plan to get rid of boot.iso entirely? Can I ask where to get InstantMirror? yum doesn't find anything. From vonbrand at inf.utfsm.cl Mon Jan 28 21:28:05 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Mon, 28 Jan 2008 18:28:05 -0300 Subject: long term support release In-Reply-To: <479E1B56.1090702@gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> <4799EAA0.7030700@gmail.com> <20080125102616.7605825b@redhat.com> <479A0C6B.1050004@gmail.com> <20080125112254.382c9e13@redhat.com> <479A190F.8010402@gmail.com> <200801251727.m0PHRe0O016727@laptop13.inf.utfsm.cl> <479A268B.5070201@gmail.com> <1201330199.17905.561.camel@beck.corsepiu.local> <200801270129.m0R1T0Eg000930@laptop13.inf.utfsm.cl> <1201410189.17905.709.camel@beck.corsepiu.local> <200801272221.m0RMLBhk010404@laptop13.inf.utfsm.cl> <1201500923.3242.95.camel@beck.corsepiu.local> <479E1B56.1090702@gmai! l.com> Message-ID: <200801282128.m0SLS5mN022321@laptop13.inf.utfsm.cl> Les Mikesell wrote: > Ralf Corsepius wrote: > > > ?!? You do not agree that fixing bugs in libraries and applications > > people tripped over when running application A in situation X, often > > bugs people trip over when running other applications in other > > situations? This has happened 1000s of times and will happen 1000s > > of times again. Sure. But what if fixing said bug creates other bugs? And if the affected applications/uses are far in between? What if the manpower to do the analysing, fixing, testing is scarce? > > Actually, I would consider such cases to be the norm. > >>>> In my experience, they end getting fixed by moving forward. > >>> A bug is only fixed if it takes place in the current release. > >> Strange definition of bug fix. > > What's strange about this? In real-life manufacturers will be sued for > > "not fixing bugs in a current release" - Avoiding such situations is > > called "customer care". > > Customer: "Garage, when I turn on my car's head lights, the heating > > starts running at full power." > > Garage : "We reported it upstream to the car's manufacturer. You might > > try the next model available at your local dealer next year. Until > > then, open the windows." Can be a quite reasonable position, depending on exactly how serious the bug is. And remember that you are getting Fedora for free, no guarantees attached. > Fedora has a unique situation in this respect though. By policy RHEL > will not add new features in updates and since the upstream app > developer generally only cares about going forward, that means someone > has to do the work of backporting bugfixes minus features into > something that sort-of resembles the originally shipped app > version. Fedora, however is perfectly free to fix the fedora version > by shipping an update to the current app version, accepting the > upstream fix in it fully-featured form. > While I'd like to see the final update of a fedora rev. slipstream > itself into exactly the packages in RHEL/Centos (at least in the > versions where that would make sense) so no extra work would be > required to continue running safely with security/bugfix updates for > several more years, it could be left up to the packager to decide if > he wants to ship more advanced versions (and commit to maintaining > them separately). For example, I don't think it made much sense other > than following policy to maintain dovecot in it's pre-1.0 version as > shipped in RHEL4 after upstream did a 1.x release. OK, let's recapitulate what I've seen on this thread Objectives for an LTS: ---------------------- - Keep base (kernel, libraries, DE, ...) the same, but please give me bleeding edge - Keep userland the same, but give support to newest hardware as soon as it comes out - Run Fedora for a longer period, so one doesn't get caught in the upgrade mill. Usually cited "for some years", but I get the impression on average it would be for a few months - Backport "only bug fixes" [Note that someone's "nasty new feature" could very well be the real fix for someone else's "bug"...] How to do it: ------------- - Just get some people at RH/some volunteers do it, it can't be /that/ hard [Yea, right] - Just freeze the Fedora from which RHEL is branched, and so use the updates for RHEL Why isn't CentOS + CentOS-Plus + EPEL enough: --------------------------------------------- [No, I haven't seen any real argument here] -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From tibbs at math.uh.edu Mon Jan 28 21:28:31 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 28 Jan 2008 15:28:31 -0600 Subject: InstantMirror needs a rethink In-Reply-To: <479E47E9.1030307@marquesminen.com.ar> References: <4797D5B3.7030002@redhat.com> <16de708d0801270142u75dd7612r3d6522056df8c92f@mail.gmail.com> <479CBB29.9050904@gmail.com> <479CFDCB.6090608@filteredperception.org> <1201531969.5827.17.camel@aglarond.local> <479DEF65.1080902@fedoraproject.org> <479E47E9.1030307@marquesminen.com.ar> Message-ID: >>>>> "MM" == Martin Marques writes: MM> Can I ask where to get InstantMirror? yum doesn't find anything. But google does.... https://hosted.fedoraproject.org/InstantMirror/wiki - J< From martin at marquesminen.com.ar Mon Jan 28 21:31:25 2008 From: martin at marquesminen.com.ar (Martin Marques) Date: Mon, 28 Jan 2008 19:31:25 -0200 Subject: InstantMirror needs a rethink In-Reply-To: References: <4797D5B3.7030002@redhat.com> <16de708d0801270142u75dd7612r3d6522056df8c92f@mail.gmail.com> <479CBB29.9050904@gmail.com> <479CFDCB.6090608@filteredperception.org> <1201531969.5827.17.camel@aglarond.local> <479DEF65.1080902@fedoraproject.org> <479E47E9.1030307@marquesminen.com.ar> Message-ID: <479E49AD.3080709@marquesminen.com.ar> Jason L Tibbitts III escribi?: >>>>>> "MM" == Martin Marques writes: > > MM> Can I ask where to get InstantMirror? yum doesn't find anything. > > But google does.... > https://hosted.fedoraproject.org/InstantMirror/wiki That I've seen, but why isn't it in the F8 repo? Is it in rawhide? From eric at vdmaarel.nl Mon Jan 28 12:22:13 2008 From: eric at vdmaarel.nl (Eric van der Maarel) Date: Mon, 28 Jan 2008 12:22:13 +0000 (UTC) Subject: Fedora 8 installation crash References: Message-ID: I'm having the exact same problem here on a Compag nc8000. Has somebody found the problem and a solution yet? From poelstra at redhat.com Mon Jan 28 21:58:33 2008 From: poelstra at redhat.com (John Poelstra) Date: Mon, 28 Jan 2008 13:58:33 -0800 Subject: Fedora Rel-Eng Meeting Recap 2008-JAN-29 Message-ID: <479E5009.4@redhat.com> Recap and full IRC transcript found here: http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-01-28 Please make corrections and clarifications to the wiki page. == Upcoming Alpha Release == * Still working on building Alpha * Most of Alpha blocker bugs have been addressed: https://bugzilla.redhat.com/showdependencytree.cgi?id=428703 * Unaddressed bugs will be added to ''known issues'' list for the Alpha release notes * If we do not have good trees to hand to IS by the evening of 2008-01-29 we slip alpha release again * slip just for pushing the bits around, but not for fixing anything else == IRC Transcript == From snecklifter at gmail.com Mon Jan 28 22:04:35 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Mon, 28 Jan 2008 22:04:35 +0000 Subject: Fedora Rel-Eng Meeting Recap 2008-JAN-29 In-Reply-To: <479E5009.4@redhat.com> References: <479E5009.4@redhat.com> Message-ID: <364d303b0801281404s7d29596fo8cf313054afda5b1@mail.gmail.com> On 28/01/2008, John Poelstra wrote: > Recap and full IRC transcript found here: > http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-01-28 Should be: http://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-jan-28 Cheers -- Christopher Brown http://www.chruz.com From snecklifter at gmail.com Mon Jan 28 22:25:28 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Mon, 28 Jan 2008 22:25:28 +0000 Subject: space on the live cds In-Reply-To: <1201366447.3282.8.camel@localhost.localdomain> References: <1201366447.3282.8.camel@localhost.localdomain> Message-ID: <364d303b0801281425j747383f9m51ef57eb62bb1a7f@mail.gmail.com> On 26/01/2008, Matthias Clasen wrote: > As usual, the live cd isos don't fit... > > I've spent some time last night looking for suspicious dependencies, > etc. Here are some of the things I spotted: > > * Some devel packages get dragged in: > - policycoreutils-gui pulls in selinux-policy-devel, which in turn > pulls in checkpolicy. Why ? > - mono-winforms pulls in libgdiplus-devel > > * Some other questionable dependencies: > - man pulls in diffutils just so that man -a can optionally > use /usr/binb/cmp > - ekiga pulls in SDL ? Just out of interest, what is the rationale for pulling in ekiga? Drop ekiga (and therefore SDL) and you're close to shaving off the 12-odd MB you need to lose for the live cd. Not having something close to debian popcon its difficult to guess the demand but you could always do this for Alpha and see what fuss gets kicked up? Or maybe I'm missing something obvious.... -- Christopher Brown http://www.chruz.com From opensource at till.name Mon Jan 28 22:33:42 2008 From: opensource at till.name (Till Maas) Date: Mon, 28 Jan 2008 23:33:42 +0100 Subject: PackageMaintainers/RetiredPackages still needed (was: Update of "PackageMaintainers/RetiredPackages" by [...]) In-Reply-To: <479E092A.3060001@leemhuis.info> References: <20080128163822.24151.87040@app1.fedora.phx.redhat.com> <479E092A.3060001@leemhuis.info> Message-ID: <200801282333.50815.opensource@till.name> On Mon January 28 2008, Thorsten Leemhuis wrote: > Just saw one of those again. Made me wonder: do we still need this page? > Orphaned packages are tracked in the package db and CVS should have a > dead.package file explaining why a package was retired. Isn't that enough? Imho the information should be in the Fedora Package Database, but I do not know how it can get in there, e.g. there is only one package listed as retired at https://admin.fedoraproject.org/pkgdb/users/packages/retired and there are also packages listed as orpaned, that are actually retired: https://admin.fedoraproject.org/pkgdb/packages/name/thinkpad-kmod (this is required according to the wiki). There is also a ticket about this at hosted: https://fedorahosted.org/packagedb/ticket/54 So just deleting the wiki page currently seems not to be a good decision, better wait till the information can be fed into the package database. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From billcrawford1970 at gmail.com Mon Jan 28 22:39:42 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Mon, 28 Jan 2008 22:39:42 +0000 Subject: In rawhide prelink -avR doesn't work, switch to -avmR In-Reply-To: <20080128160720.GA30813@wolff.to> References: <20080126222326.GA24298@wolff.to> <200801280513.11380.billcrawford1970@googlemail.com> <20080128160720.GA30813@wolff.to> Message-ID: <200801282239.43229.billcrawford1970@googlemail.com> On Monday 28 January 2008 16:07:20 Bruno Wolff III wrote: > After making sure that works in my case I'll file a bugzilla. I'll also > refer back to the thread to explain why I am picking on Open Office > as I am not in a position to argue that there isn't much point in > prelinking the Open Office library. (I don't doubt you, but if I am asked > why I am claiming that my only answer is because someone told me so.) Heehee. Someone's going to be after my blood ... In this case it really is just a case of "these are large, and normally only loaded the once" but it's a shame because prelinking *does* speed up loading of all libraries, especially large ones :) I'd also recommend (in case anyone really does thinking I'm picking on OO) doing the same for e.g. libuninamelist and libgucharmap ... they're big too. Just do "find /usr/lib -size +10M" for the worst offenders ;) Oo. In fact, yes, the eclipse jars are probably another good target ... Really the only good answer is to do the prelinking on demand, so you always know if there's a possible collision between two libraries (if a program loads a shared object - at launch, or via dlload - and it collides with another (loaded) one, pick a new address space slot and prelink it). And no, I don't have the gonads to do it myself :o) From chasd at silveroaks.com Mon Jan 28 22:57:44 2008 From: chasd at silveroaks.com (chasd) Date: Mon, 28 Jan 2008 16:57:44 -0600 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <20080128181544.2004772F57@hormel.redhat.com> References: <20080128181544.2004772F57@hormel.redhat.com> Message-ID: <665B860B-5E19-4E79-B52B-1300EFF619FE@silveroaks.com> Les Mikesell wrote: > It sounds fairly horrible to me to have every single application you > might run that could share something set up its own file sharing > service > and client As usual, I my idea didn't come out that well in words. My plan is as follows : 1) Configure yum to keep downloaded rpms. Put a file in /etc/httpd/conf.d to share the contents of /var/cache/ yum/updates-released/packages. 2) Publish a service via mdns-avahi-Bonjour that would allow yum to discover packages stored on nearby machines. 3) Write a yum plugin that looks for those published services and consumes them instead of from an Internet source. An occasional "yum clean all" ( monthly cron ? ) would clear out cruft. Instead of configuring and maintaining a server to store update rpms, any node that has installed an update can share it with another node. Charles Dostale From opensource at till.name Mon Jan 28 22:59:10 2008 From: opensource at till.name (Till Maas) Date: Mon, 28 Jan 2008 23:59:10 +0100 Subject: Fedora Rel-Eng Meeting Recap 2008-JAN-29 In-Reply-To: <479E5009.4@redhat.com> References: <479E5009.4@redhat.com> Message-ID: <200801282359.16003.opensource@till.name> On Mon January 28 2008, John Poelstra wrote: > * Unaddressed bugs will be added to ''known issues'' list for the > Alpha release notes How are the Alpha release notes written? They seem not to use the Doc/Beats namespace. Can I somehow add some information about changes in a package of mine or should this information only go to the final release notes of F9, i.e. into Doc/Beats on the wiki, once the F9 release notes will be written there? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From sundaram at fedoraproject.org Mon Jan 28 23:13:17 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 29 Jan 2008 04:43:17 +0530 Subject: Fedora Rel-Eng Meeting Recap 2008-JAN-29 In-Reply-To: <200801282359.16003.opensource@till.name> References: <479E5009.4@redhat.com> <200801282359.16003.opensource@till.name> Message-ID: <479E618D.3060508@fedoraproject.org> Till Maas wrote: > On Mon January 28 2008, John Poelstra wrote: > >> * Unaddressed bugs will be added to ''known issues'' list for the >> Alpha release notes > > How are the Alpha release notes written? They seem not to use the Doc/Beats > namespace. Alpha/Beta have only one page release notes. The Alpha version draft is at http://fedoraproject.org/wiki/Releases/9/Alpha/ReleaseNotes Can I somehow add some information about changes in a package of > mine or should this information only go to the final release notes of F9, > i.e. into Doc/Beats on the wiki, once the F9 release notes will be written > there? Depending on how important this is to Alpha users. A major change that users need to be aware of or test and provide feedback on needs to be in the alpha or beta release notes. Otherwise just update the package changes section in Docs/Beats and it would go directly in the general release notes for Fedora 9. Rahul From kevin.kofler at chello.at Mon Jan 28 23:23:28 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 28 Jan 2008 23:23:28 +0000 (UTC) Subject: bodhi 0.4.10 features References: <20080125205437.GA3993@crow> <20080127225406.GG3054@crow> <479D4038.1020402@ioa.s.u-tokyo.ac.jp> <17179.1201492236@sss.pgh.pa.us> <20080128042616.GA23022@crow> <17951.1201497570@sss.pgh.pa.us> <479DDB33.3070002@ioa.s.u-tokyo.ac.jp> Message-ID: Jon Stanley gmail.com> writes: > Yep. I just came up with a catchy slogan for this: "the rule of ones" > (OK, maybe not so catchy :) ). ONE bug == ONE problem in ONE release > (F7, F8, and rawhide). It's even got a big red box in > http://fedoraproject.org/wiki/JohnPoelstra/BugLifeCycle :) This is entirely unworkable in practice. I therefore agree with Mamuro Tasaka, Ralf Cors?pius and others and completely oppose this policy. The Bodhi feature of being able to not close bugs automatically was requested by several maintainers and implemented at their request, taking it back constitutes a huge regression. Kevin Kofler From khc at pm.waw.pl Mon Jan 28 23:38:43 2008 From: khc at pm.waw.pl (Krzysztof Halasa) Date: Tue, 29 Jan 2008 00:38:43 +0100 Subject: long term support release In-Reply-To: <80d7e4090801272005t6d542663rc99d616bef281589@mail.gmail.com> (Stephen John Smoogen's message of "Sun\, 27 Jan 2008 21\:05\:55 -0700") References: <1201249426.14800.19.camel@cutter> <1201277589.17905.369.camel@beck.corsepiu.local> <200801261957.41090.opensource@till.name> <80d7e4090801261954r22de23dbgc660d60af780f194@mail.gmail.com> <80d7e4090801272005t6d542663rc99d616bef281589@mail.gmail.com> Message-ID: "Stephen John Smoogen" writes: > theoretically one could update a kernel without technically > rebooting... but at what point are you just being silly to just say > you have the longest uptime (and is it uptime if you have dropped all > your services to do your update?) Think remote access, reboot is a dangerous operation. Anyway, if a reboot buys you nothing you don't reboot, do you? :-) -- Krzysztof Halasa From smooge at gmail.com Mon Jan 28 23:42:19 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 28 Jan 2008 16:42:19 -0700 Subject: long term support release In-Reply-To: References: <1201249426.14800.19.camel@cutter> <1201277589.17905.369.camel@beck.corsepiu.local> <200801261957.41090.opensource@till.name> <80d7e4090801261954r22de23dbgc660d60af780f194@mail.gmail.com> <80d7e4090801272005t6d542663rc99d616bef281589@mail.gmail.com> Message-ID: <80d7e4090801281542y561978acs41bccb857aa6de46@mail.gmail.com> On Jan 28, 2008 4:38 PM, Krzysztof Halasa wrote: > "Stephen John Smoogen" writes: > > > theoretically one could update a kernel without technically > > rebooting... but at what point are you just being silly to just say > > you have the longest uptime (and is it uptime if you have dropped all > > your services to do your update?) > > Think remote access, reboot is a dangerous operation. Anyway, if a > reboot buys you nothing you don't reboot, do you? :-) > I reboot religiously. What does 5110 days of uptime buy me anyway? Not even a cup of coffee. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From kevin.kofler at chello.at Mon Jan 28 23:50:56 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 28 Jan 2008 23:50:56 +0000 (UTC) Subject: PackageMaintainers/RetiredPackages still needed (was: Update of "PackageMaintainers/RetiredPackages" by [...]) References: <20080128163822.24151.87040@app1.fedora.phx.redhat.com> <479E092A.3060001@leemhuis.info> Message-ID: Thorsten Leemhuis leemhuis.info> writes: > > The comment on the change is: > > Removed kgtk - should not be retired kgtk was actually retired by mistake (it doesn't depend on KWin 3, only kdelibs3, which is still available), I discussed this with the maintainer and he resurrected it. So this is not an issue with being "out of date", just a corrected mistake. Kevin Kofler From kevin.kofler at chello.at Mon Jan 28 23:54:02 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 28 Jan 2008 23:54:02 +0000 (UTC) Subject: Headsup: new API breaking libgda on its way to rawhide References: <479A0D89.2050801@hhs.nl> <479E38CD.9090904@redhat.com> Message-ID: Christopher Aillon redhat.com> writes: > On 01/25/2008 11:25 AM, Hans de Goede wrote: > > the API of > > libgda-report-3.0.so.3 has changed (but not the soname ???). > > We should make sure that gets resolved upstream. It's quite common for prerelease software. KDE 4.0 betas had lots of API/ABI changes with the same soname (which is also the one used by the stable releases now, the API and the ABI are actually frozen now, of course). Kevin Kofler From jspaleta at gmail.com Mon Jan 28 23:58:47 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 28 Jan 2008 14:58:47 -0900 Subject: long term support release In-Reply-To: <80d7e4090801281542y561978acs41bccb857aa6de46@mail.gmail.com> References: <1201249426.14800.19.camel@cutter> <1201277589.17905.369.camel@beck.corsepiu.local> <200801261957.41090.opensource@till.name> <80d7e4090801261954r22de23dbgc660d60af780f194@mail.gmail.com> <80d7e4090801272005t6d542663rc99d616bef281589@mail.gmail.com> <80d7e4090801281542y561978acs41bccb857aa6de46@mail.gmail.com> Message-ID: <604aa7910801281558j6f65deb8mae8c35fab6b69a1e@mail.gmail.com> On Jan 28, 2008 2:42 PM, Stephen John Smoogen wrote: > I reboot religiously. So you reboot on Christmas and Easter? -jef From lesmikesell at gmail.com Tue Jan 29 00:02:29 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 28 Jan 2008 18:02:29 -0600 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <665B860B-5E19-4E79-B52B-1300EFF619FE@silveroaks.com> References: <20080128181544.2004772F57@hormel.redhat.com> <665B860B-5E19-4E79-B52B-1300EFF619FE@silveroaks.com> Message-ID: <479E6D15.5030709@gmail.com> chasd wrote: >> It sounds fairly horrible to me to have every single application you >> might run that could share something set up its own file sharing service >> and client > > As usual, I my idea didn't come out that well in words. > My plan is as follows : > > 1) > Configure yum to keep downloaded rpms. > Put a file in /etc/httpd/conf.d to share the contents of > /var/cache/yum/updates-released/packages. > 2) > Publish a service via mdns-avahi-Bonjour that would allow yum to > discover packages stored on nearby machines. > 3) > Write a yum plugin that looks for those published services and consumes > them instead of from an Internet source. > An occasional "yum clean all" ( monthly cron ? ) would clear out cruft. > > Instead of configuring and maintaining a server to store update rpms, > any node that has installed an update can share it with another node. This could work on a typical home network. In a larger office I'd expect subneting and firewalling to block most auto-discovery mechanisms between a lot of machines that would still have fast internal connections and share outbound internet traffic. Would there still be a way to explicitly provide the dns name or IP address of the server in this case? -- Les Mikesell lesmikesell at gmail.com From orion at cora.nwra.com Tue Jan 29 00:20:07 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 28 Jan 2008 17:20:07 -0700 Subject: F9 for Eeepc In-Reply-To: <645d17210801251629y2811f3f7jf0886a166ffd2f8@mail.gmail.com> References: <479A650D.8060401@cora.nwra.com> <1201304569.2057.22.camel@localhost.localdomain> <645d17210801251629y2811f3f7jf0886a166ffd2f8@mail.gmail.com> Message-ID: <479E7137.5020705@cora.nwra.com> Jonathan Underwood wrote: > On 25/01/2008, John (J5) Palmieri wrote: >> On Fri, 2008-01-25 at 15:39 -0700, Orion Poplawski wrote: >> >>> - Flash drive. Want to minimize writes. One attempt (eeedora) uses the >>> ext2 filesystem rather than ext3. Does that help? Are there things to >>> take from stateless projects for minimizing writes to /var? >>> >> jffs2 is what we use on the OLPC, there is another FS in the works that >> is a lot better for large flash though. I forget the name. On modern >> flash you don't have to worry about rewrites as much though since the >> hardware randomizes writes. What kills the disk on older flash drives >> is writing to the journal in Ext3 and writing to the FAT on Fat disks. >> Both of those are fixed locations which stress out a small portion of >> the disk. Each flash device has only so many writes per bit before that >> bit dies. By distributing it over the whole disk it takes a lot longer >> to destroy. I would check the specs on the flash drive that came with >> the Eee. Another thing you might want to do is not have a swap >> partition. Apps run fine without swap, you just might run into OOM more >> frequently. >> > > The eeepc drive has a FTL, so these drives don't appear as flash > drives to the OS, so jffs, yaffs, logfs and the like aren't applicable > to the eeepc, as I understand it. The drive appears as a standard IDE drive. dmesg reports the drive as a "SILICONMOTION SM223AC". Google doesn't seem to turn up much other than users' reports on their eeePC :-). -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From smooge at gmail.com Tue Jan 29 00:22:09 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 28 Jan 2008 17:22:09 -0700 Subject: long term support release In-Reply-To: <604aa7910801281558j6f65deb8mae8c35fab6b69a1e@mail.gmail.com> References: <1201249426.14800.19.camel@cutter> <200801261957.41090.opensource@till.name> <80d7e4090801261954r22de23dbgc660d60af780f194@mail.gmail.com> <80d7e4090801272005t6d542663rc99d616bef281589@mail.gmail.com> <80d7e4090801281542y561978acs41bccb857aa6de46@mail.gmail.com> <604aa7910801281558j6f65deb8mae8c35fab6b69a1e@mail.gmail.com> Message-ID: <80d7e4090801281622m6c113260o181b4c697ba92454@mail.gmail.com> On Jan 28, 2008 4:58 PM, Jeff Spaleta wrote: > On Jan 28, 2008 2:42 PM, Stephen John Smoogen wrote: > > > I reboot religiously. > > So you reboot on Christmas and Easter? > Orthodox and Western -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From lordmorgul at gmail.com Tue Jan 29 00:25:41 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Mon, 28 Jan 2008 16:25:41 -0800 Subject: Fedora 8 installation crash In-Reply-To: References: Message-ID: <479E7285.2010400@gmail.com> Eric van der Maarel wrote: > I'm having the exact same problem here on a Compag nc8000. > Has somebody found the problem and a solution yet? Eric, your email did not seem to refer to the previous thread correctly, so 'exact same problem' is not clear. Can you explain that, or check whether you replied to the wrong list? I cannot find a thread titled 'Fedora 8 installation crash' on any fedora lists at the moment, although there is 'Fedora 8 installation issue' on fedora-list, without replies. Fedora Unity respins do solve some installation problems, see: http://spins.fedoraunity.org/ -- Andrew Farris www.lordmorgul.net gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From lordmorgul at gmail.com Tue Jan 29 00:28:35 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Mon, 28 Jan 2008 16:28:35 -0800 Subject: Fedora 8 installation crash In-Reply-To: <479E7285.2010400@gmail.com> References: <479E7285.2010400@gmail.com> Message-ID: <479E7333.7050802@gmail.com> Andrew Farris wrote: > Eric van der Maarel wrote: >> I'm having the exact same problem here on a Compag nc8000. >> Has somebody found the problem and a solution yet? > > Eric, your email did not seem to refer to the previous thread correctly, > so 'exact same problem' is not clear. Can you explain that, or check > whether you replied to the wrong list? I cannot find a thread titled > 'Fedora 8 installation crash' on any fedora lists at the moment, > although there is 'Fedora 8 installation issue' on fedora-list, without > replies. > > Fedora Unity respins do solve some installation problems, see: > http://spins.fedoraunity.org/ Ah I did find it: http://www.redhat.com/archives/fedora-devel-list/2007-November/msg02433.html -- Andrew Farris www.lordmorgul.net gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From snecklifter at gmail.com Tue Jan 29 00:44:11 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Tue, 29 Jan 2008 00:44:11 +0000 Subject: bodhi 0.4.10 features In-Reply-To: References: <20080125205437.GA3993@crow> <479D4038.1020402@ioa.s.u-tokyo.ac.jp> <17179.1201492236@sss.pgh.pa.us> <20080128042616.GA23022@crow> <17951.1201497570@sss.pgh.pa.us> <479DDB33.3070002@ioa.s.u-tokyo.ac.jp> Message-ID: <364d303b0801281644r150483b1sb8ae15ee423328a1@mail.gmail.com> On 28/01/2008, Kevin Kofler wrote: > Jon Stanley gmail.com> writes: > > Yep. I just came up with a catchy slogan for this: "the rule of ones" > > (OK, maybe not so catchy :) ). ONE bug == ONE problem in ONE release > > (F7, F8, and rawhide). It's even got a big red box in > > http://fedoraproject.org/wiki/JohnPoelstra/BugLifeCycle :) > > This is entirely unworkable in practice. Care to flesh out that statement a bit? > I therefore agree with Mamuro Tasaka, > Ralf Cors?pius and others and completely oppose this policy. I've ignored some of the unhelpful comments by those above and I'd be grateful if you'd not follow down the same path. It would be good to know _why_ you oppose it. > The Bodhi feature of being able to not close bugs automatically was requested > by several maintainers and implemented at their request, taking it back > constitutes a huge regression. Agreed. Cheers -- Christopher Brown http://www.chruz.com From jon.nettleton at gmail.com Tue Jan 29 00:54:17 2008 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Mon, 28 Jan 2008 19:54:17 -0500 Subject: F9 for Eeepc In-Reply-To: <479E7137.5020705@cora.nwra.com> References: <479A650D.8060401@cora.nwra.com> <1201304569.2057.22.camel@localhost.localdomain> <645d17210801251629y2811f3f7jf0886a166ffd2f8@mail.gmail.com> <479E7137.5020705@cora.nwra.com> Message-ID: On Jan 28, 2008 7:20 PM, Orion Poplawski wrote: > Jonathan Underwood wrote: > > On 25/01/2008, John (J5) Palmieri wrote: > >> On Fri, 2008-01-25 at 15:39 -0700, Orion Poplawski wrote: > >> > >>> - Flash drive. Want to minimize writes. One attempt (eeedora) uses the > >>> ext2 filesystem rather than ext3. Does that help? Are there things to > >>> take from stateless projects for minimizing writes to /var? > >>> > >> jffs2 is what we use on the OLPC, there is another FS in the works that > >> is a lot better for large flash though. I forget the name. On modern > >> flash you don't have to worry about rewrites as much though since the > >> hardware randomizes writes. What kills the disk on older flash drives > >> is writing to the journal in Ext3 and writing to the FAT on Fat disks. > >> Both of those are fixed locations which stress out a small portion of > >> the disk. Each flash device has only so many writes per bit before that > >> bit dies. By distributing it over the whole disk it takes a lot longer > >> to destroy. I would check the specs on the flash drive that came with > >> the Eee. Another thing you might want to do is not have a swap > >> partition. Apps run fine without swap, you just might run into OOM more > >> frequently. > >> > > > > The eeepc drive has a FTL, so these drives don't appear as flash > > drives to the OS, so jffs, yaffs, logfs and the like aren't applicable > > to the eeepc, as I understand it. > > The drive appears as a standard IDE drive. dmesg reports the drive as a > "SILICONMOTION SM223AC". Google doesn't seem to turn up much other > than users' reports on their eeePC :-). > For other eeepc users I just wanted to mention that I hacked on devilspie to include matching on the geometry attributes of a window. Long story short you can use it now to say if a window is taller than 480 pixels you can either set it to resize smaller or maximize vertically. This still doesn't work for dialog's yet, I am looking at gtk and a few other places that I might hack around fixes to make them fit on the small resolution better. Jon From notting at redhat.com Tue Jan 29 02:55:15 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 28 Jan 2008 21:55:15 -0500 Subject: Headsup: new API breaking libgda on its way to rawhide In-Reply-To: References: <479A0D89.2050801@hhs.nl> <479E38CD.9090904@redhat.com> Message-ID: <20080129025515.GA21460@nostromo.devel.redhat.com> Kevin Kofler (kevin.kofler at chello.at) said: > Christopher Aillon redhat.com> writes: > > On 01/25/2008 11:25 AM, Hans de Goede wrote: > > > the API of > > > libgda-report-3.0.so.3 has changed (but not the soname ???). > > > > We should make sure that gets resolved upstream. > > It's quite common for prerelease software. KDE 4.0 betas had lots of API/ABI > changes with the same soname (which is also the one used by the stable releases > now, the API and the ABI are actually frozen now, of course). I've always thought it was better in a devel series to change the soname the first time you break it, to whatever it will be when the ABI freezes. Bill From skvidal at fedoraproject.org Tue Jan 29 02:56:46 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 28 Jan 2008 21:56:46 -0500 Subject: long term support release In-Reply-To: <80d7e4090801281542y561978acs41bccb857aa6de46@mail.gmail.com> References: <1201249426.14800.19.camel@cutter> <1201277589.17905.369.camel@beck.corsepiu.local> <200801261957.41090.opensource@till.name> <80d7e4090801261954r22de23dbgc660d60af780f194@mail.gmail.com> <80d7e4090801272005t6d542663rc99d616bef281589@mail.gmail.com> <80d7e4090801281542y561978acs41bccb857aa6de46@mail.gmail.com> Message-ID: <1201575406.7066.59.camel@cutter> On Mon, 2008-01-28 at 16:42 -0700, Stephen John Smoogen wrote: > On Jan 28, 2008 4:38 PM, Krzysztof Halasa wrote: > > "Stephen John Smoogen" writes: > > > > > theoretically one could update a kernel without technically > > > rebooting... but at what point are you just being silly to just say > > > you have the longest uptime (and is it uptime if you have dropped all > > > your services to do your update?) > > > > Think remote access, reboot is a dangerous operation. Anyway, if a > > reboot buys you nothing you don't reboot, do you? :-) > > > > I reboot religiously. What does 5110 days of uptime buy me anyway? Not > even a cup of coffee. > At my last job we put a policy in place where no system would have a greater than 150 day update, unless it had extenuating circumstances. What I discovered in general was this: - systems that haven't been rebooted in a while sometimes gather cruft that has not been properly laced into the startup. so it doesn't come up on its own. Rebooting frequently ensures that people remember to do that - any system that "MUST BE UP ALL THE TIME" should be redundant. If it is not redundant and it is that important then that service is a pretty precarious position. - reboots ferret out problems in hardware that you don't always see until a powercycle. Like a disk that will just keep on spinning provided it is never stopped. I agree with religiously rebooting boxes. -sv From jkeating at redhat.com Tue Jan 29 03:08:58 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 28 Jan 2008 22:08:58 -0500 Subject: long term support release In-Reply-To: <1201575406.7066.59.camel@cutter> References: <1201249426.14800.19.camel@cutter> <1201277589.17905.369.camel@beck.corsepiu.local> <200801261957.41090.opensource@till.name> <80d7e4090801261954r22de23dbgc660d60af780f194@mail.gmail.com> <80d7e4090801272005t6d542663rc99d616bef281589@mail.gmail.com> <80d7e4090801281542y561978acs41bccb857aa6de46@mail.gmail.com> <1201575406.7066.59.camel@cutter> Message-ID: <20080128220858.17c3e05d@redhat.com> On Mon, 28 Jan 2008 21:56:46 -0500 seth vidal wrote: > - systems that haven't been rebooted in a while sometimes gather cruft > that has not been properly laced into the startup. so it doesn't come > up on its own. Rebooting frequently ensures that people remember to > do that > > - any system that "MUST BE UP ALL THE TIME" should be redundant. If it > is not redundant and it is that important then that service is a > pretty precarious position. > > - reboots ferret out problems in hardware that you don't always see > until a powercycle. Like a disk that will just keep on spinning > provided it is never stopped. > > > I agree with religiously rebooting boxes. I've been bitten by too many of these things in the past to not agree as well. Now it wasn't as bad as the NT box that had to be rebooted weekly or else the services on it (like exchange) would start to fail randomly. But it was a good test for what would happen should this box go down and are we prepared for that. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lesmikesell at gmail.com Tue Jan 29 03:12:06 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 28 Jan 2008 21:12:06 -0600 Subject: long term support release In-Reply-To: <1201575406.7066.59.camel@cutter> References: <1201249426.14800.19.camel@cutter> <1201277589.17905.369.camel@beck.corsepiu.local> <200801261957.41090.opensource@till.name> <80d7e4090801261954r22de23dbgc660d60af780f194@mail.gmail.com> <80d7e4090801272005t6d542663rc99d616bef281589@mail.gmail.com> <80d7e4090801281542y561978acs41bccb857aa6de46@mail.gmail.com> <1201575406.7066.59.camel@cutter> Message-ID: <479E9986.6050209@gmail.com> seth vidal wrote: >>>> theoretically one could update a kernel without technically >>>> rebooting... but at what point are you just being silly to just say >>>> you have the longest uptime (and is it uptime if you have dropped all >>>> your services to do your update?) >>> Think remote access, reboot is a dangerous operation. Anyway, if a >>> reboot buys you nothing you don't reboot, do you? :-) >>> >> I reboot religiously. What does 5110 days of uptime buy me anyway? Not >> even a cup of coffee. >> > > At my last job we put a policy in place where no system would have a > greater than 150 day update, unless it had extenuating circumstances. > What I discovered in general was this: > > - systems that haven't been rebooted in a while sometimes gather cruft > that has not been properly laced into the startup. so it doesn't come up > on its own. Rebooting frequently ensures that people remember to do that > > - any system that "MUST BE UP ALL THE TIME" should be redundant. If it > is not redundant and it is that important then that service is a pretty > precarious position. > > - reboots ferret out problems in hardware that you don't always see > until a powercycle. Like a disk that will just keep on spinning provided > it is never stopped. > > > I agree with religiously rebooting boxes. Having had a machine up for 4+ years until I had to move it and was too lazy to drag along a UPS on one of its dual power supplies, I have to disagree. It is nice to have services like dhcp, dns, email, etc. running all the time and rebooting just covers up problems like memory leaks that should be fixed instead of worked around. If something isn't reliable, why do you want to use it at all? -- Les Mikesell lesmikesell at gmail.com From kevin.kofler at chello.at Tue Jan 29 03:14:19 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 29 Jan 2008 03:14:19 +0000 (UTC) Subject: bodhi 0.4.10 features References: <20080125205437.GA3993@crow> <479D4038.1020402@ioa.s.u-tokyo.ac.jp> <17179.1201492236@sss.pgh.pa.us> <20080128042616.GA23022@crow> <17951.1201497570@sss.pgh.pa.us> <479DDB33.3070002@ioa.s.u-tokyo.ac.jp> <364d303b0801281644r150483b1sb8ae15ee423328a1@mail.gmail.com> Message-ID: Christopher Brown gmail.com> writes: > > This is entirely unworkable in practice. > > Care to flesh out that statement a bit? The workflow I and many other maintainers are following is to track one bug per problem, and if we have a fix, fix it in all branches. Having one bug per branch is very unhelpful, it means: * 3 (4 in the month after a release) times as many bugs, for no good reason, * no good way to involve all users in the same discussion about their issue which is in no way specific to the Fedora version (a workaround would be a tracker bug, but 1. it would be yet another additional bug and 2. how are we to enforce that users use the tracker bug and not the distro version bug for discussion?), * having to clone bugs all the time, which is a PITA and serves no useful purpose, when the bugs are going to be closed at the same time or almost at the same time anyway. IMHO, the only cases it makes sense to clone a bug are: * if it turns out that there are significant differences in behavior between different Fedora releases, * if for some reason it's easier to fix the bug in some releases than in others (so the bug can be closed for those releases and a clone for the problematic ones left open), though even in this case, many maintainers will simply opt to work with a single bug report and keep it open until it's fixed everywhere, and both of these decisions have to be made on a case by case basis, cloning bugs upfront is pointless. I think the model currently used by the security team is something which needs to be fixed, not adopted for all bugs. Having a reference to "CVE-2008-xxxx (Tracker Bug)" with the real description and another to "CVE-2008-xxxx (Fedora n)" which just points to the tracker bug means there's a useless reference in the update message (only the tracker bug is actually useful as a reference). So I'd say there should be only the tracker bugs (and possibly RHEL clones, I don't care about these at all, but I'd like Fedora to be handled in a single bug per issue). Kevin Kofler From jkeating at redhat.com Tue Jan 29 03:12:11 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 28 Jan 2008 22:12:11 -0500 Subject: long term support release In-Reply-To: <479E9986.6050209@gmail.com> References: <1201249426.14800.19.camel@cutter> <1201277589.17905.369.camel@beck.corsepiu.local> <200801261957.41090.opensource@till.name> <80d7e4090801261954r22de23dbgc660d60af780f194@mail.gmail.com> <80d7e4090801272005t6d542663rc99d616bef281589@mail.gmail.com> <80d7e4090801281542y561978acs41bccb857aa6de46@mail.gmail.com> <1201575406.7066.59.camel@cutter> <479E9986.6050209@gmail.com> Message-ID: <20080128221211.00731b70@redhat.com> On Mon, 28 Jan 2008 21:12:06 -0600 Les Mikesell wrote: > Having had a machine up for 4+ years until I had to move it and was > too lazy to drag along a UPS on one of its dual power supplies, I > have to disagree. It is nice to have services like dhcp, dns, email, > etc. running all the time and rebooting just covers up problems like > memory leaks that should be fixed instead of worked around. If > something isn't reliable, why do you want to use it at all? Because it's not about the machine/software, often times it's about the people. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at fedoraproject.org Tue Jan 29 03:15:49 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 28 Jan 2008 22:15:49 -0500 Subject: long term support release In-Reply-To: <479E9986.6050209@gmail.com> References: <1201249426.14800.19.camel@cutter> <1201277589.17905.369.camel@beck.corsepiu.local> <200801261957.41090.opensource@till.name> <80d7e4090801261954r22de23dbgc660d60af780f194@mail.gmail.com> <80d7e4090801272005t6d542663rc99d616bef281589@mail.gmail.com> <80d7e4090801281542y561978acs41bccb857aa6de46@mail.gmail.com> <1201575406.7066.59.camel@cutter> <479E9986.6050209@gmail.com> Message-ID: <1201576549.7066.66.camel@cutter> On Mon, 2008-01-28 at 21:12 -0600, Les Mikesell wrote: > Having had a machine up for 4+ years until I had to move it and was too > lazy to drag along a UPS on one of its dual power supplies, I have to > disagree. It is nice to have services like dhcp, dns, email, etc. > running all the time and rebooting just covers up problems like memory > leaks that should be fixed instead of worked around. If something isn't > reliable, why do you want to use it at all? > You don't. You want to fix it. Regular Reboots didn't compensate for unreliability. It made sure you didn't have to remember a process you did once 4 years ago. Services like dhcp, dns and email should be failover redundant. If one particular server instance goes down the service should at WORST be dropped by half of its capacity. In the best case it should be entirely invisible from the user. -sv From rwwyatt01 at gmail.com Tue Jan 29 03:36:32 2008 From: rwwyatt01 at gmail.com (Randy Wyatt) Date: Mon, 28 Jan 2008 19:36:32 -0800 Subject: long term support release In-Reply-To: <1201576549.7066.66.camel@cutter> References: <1201249426.14800.19.camel@cutter> <80d7e4090801261954r22de23dbgc660d60af780f194@mail.gmail.com> <80d7e4090801272005t6d542663rc99d616bef281589@mail.gmail.com> <80d7e4090801281542y561978acs41bccb857aa6de46@mail.gmail.com> <1201575406.7066.59.camel@cutter> <479E9986.6050209@gmail.com> <1201576549.7066.66.camel@cutter> Message-ID: <34e52d0c0801281936n627db4f9j8bb8269bcba381b3@mail.gmail.com> There is a serious lack of understanding where Linux is, and where most want it to be in this thread. A presumptive reboot does not actually provide any benefit whatsoever, and in fact often exacerbates situations. I work in situations where downtime is measured in the millions of dollars per minute category, and we have never been able to accept such requirements as provided by certain vendors such as HP which mandated monthly downtime to install patches. I started out with the presumptive reboot issue. It was hard enough to get customers to agree to any modicum of a regular patch cycle. By the way, all processes and modifications to systems in the field I work, are heavily documented. The first time I saw a 3B2-80, I thought to myself what in the hell was that!, but using known procedures, I was able to recover what needed to be recovered. From rc040203 at freenet.de Mon Jan 28 14:40:37 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 28 Jan 2008 15:40:37 +0100 Subject: long term support release In-Reply-To: <80d7e4090801280612y78d012e0h725ed35a3299c11c@mail.gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <20080125112254.382c9e13@redhat.com> <479A190F.8010402@gmail.com> <200801251727.m0PHRe0O016727@laptop13.inf.utfsm.cl> <479A268B.5070201@gmail.com> <1201330199.17905.561.camel@beck.corsepiu.local> <200801270129.m0R1T0Eg000930@laptop13.inf.utfsm.cl> <1201410189.17905.709.camel@beck.corsepiu.local> <200801272221.m0RMLBhk010404@laptop13.inf.utfsm.cl> <1201500923.3242.95.camel@beck.corsepiu.local> <80d7e4090801280612y78d012e0h725ed35a3299c11c@mail.gmail.com> Message-ID: <1201531237.3242.132.camel@beck.corsepiu.local> On Mon, 2008-01-28 at 07:12 -0700, Stephen John Smoogen wrote: > On Jan 27, 2008 11:15 PM, Ralf Corsepius wrote: > > > > > > In my experience, they end getting fixed by moving forward. > > > > > > > A bug is only fixed if it takes place in the current release. > > > > > > Strange definition of bug fix. > > What's strange about this? In real-life manufacturers will be sued for > > "not fixing bugs in a current release" - Avoiding such situations is > > called "customer care". > > > > Customer: "Garage, when I turn on my car's head lights, the heating > > starts running at full power." > > Garage : "We reported it upstream to the car's manufacturer. You might > > try the next model available at your local dealer next year. Until then, > > open the windows." > > > > I think most of us have misparsed your original comment to be: > > Customer: "Garage, when I turn on my car's head lights, the heating > starts running at full power." > > Garage : "You need to get the latest car. Otherwise we can't fix it." > > However, Linux is not cars. Each distro has its strengths and > weaknesses. You seem to only see the weaknesses which has me > questioning what you are trying to accomplish. Once again: My objective is improving usability, by eliminating bugs ASAP, once you know about them. Fedora's bureacracy and work flow is are handicapping this by wasting resources. This causes "current fedora" to be of "suboptimal quality" and causes people to ask for "Fedora LTS". Ralf From lordmorgul at gmail.com Tue Jan 29 04:35:53 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Mon, 28 Jan 2008 20:35:53 -0800 Subject: long term support release In-Reply-To: <34e52d0c0801281936n627db4f9j8bb8269bcba381b3@mail.gmail.com> References: <1201249426.14800.19.camel@cutter> <80d7e4090801261954r22de23dbgc660d60af780f194@mail.gmail.com> <80d7e4090801272005t6d542663rc99d616bef281589@mail.gmail.com> <80d7e4090801281542y561978acs41bccb857aa6de46@mail.gmail.com> <1201575406.7066.59.camel@cutter> <479E9986.6050209@gmail.com> <1201576549.7066.66.camel@cutter> <34e52d0c0801281936n627db4f9j8bb8269bcba381b3@mail.gmail.com> Message-ID: <479EAD29.1070102@gmail.com> Randy Wyatt wrote: > There is a serious lack of understanding where Linux is, and where > most want it to be in this thread. A presumptive reboot does not > actually provide any benefit whatsoever, and in fact often exacerbates > situations. That is a pretty broad brush to stroke with. > By the way, all processes and modifications to systems in the field > I work, are heavily documented. The first time I saw a 3B2-80, I > thought to myself what in the hell was that!, but using known > procedures, I was able to recover what needed to be recovered. That is a scenario so deep into the 'it works fine leave it alone' region its comical. A machine running with no changes being made does not need rebooted because the reboot might just break what works; I don't really think that is what Seth was getting at. On the *far* other hand, a machine updating 10-20 packages a day (tracking rawhide for instance) does need rebooted regularly, otherwise what you're testing/operating is not the current state of development, but instead you're testing the result of an upgrade path across unstable packages you practically cannot duplicate (and never would want to). A whole different situation. Average Joe user does need somewhat regular reboots even if he really could keep the system alive without them, because 1) his changes being made are not well documented, 2) the changes from updates tend to be fairly frequent, and 3) there is much less care taken in making sure the updates completely take effect every time than on a high availability redundant service a team of engineers are managing. It would seem foolhardy for a guy running a small business office server not to at least verify his hardware is solid via power cycles at some regular interval (naturally backing up the data first which he does regularly). He certainly does not need to update for every single little thing like some systems may require. So the 'it works - leave it alone for two decades' and 'general use of linux for random purposes' are pretty dissimilar situations. -- Andrew Farris www.lordmorgul.net gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From mrmazda at ij.net Tue Jan 29 05:25:42 2008 From: mrmazda at ij.net (Felix Miata) Date: Tue, 29 Jan 2008 00:25:42 -0500 Subject: Suggestion: Use Liberation fonts as default in Firefox 3 In-Reply-To: <6e24a8e80801280638q467ce226oeccce8b884c9f41b@mail.gmail.com> References: <6e24a8e80801280638q467ce226oeccce8b884c9f41b@mail.gmail.com> Message-ID: <479EB8D6.3080100@ij.net> On 2008/01/28 15:38 (GMT+0100) Mark apparently typed: > I have Firefox 3 now on Fedora rawhide and i really disliked the > default fonts so i played a little with it till i got acceptable > results. here are a few screenshots: > 1: [1] Default Firefox 3 > 2: [2] Firefox 3 with Liberation fonts > 3: [3] The settings i changed > As you can see in [2] is that the fonts are looking just better. i > can't make anything else out of it. I've also tested this font setting > [3] on other sites like digg.com and the fedora wiki and it looks > better everywhere. So i really hope this could be made default for > Fedora 9 with Firefox 3. The Firefox 2 & 3 defaults are actually serif, sans-serif, and monospace, all generic families that render according to the system's mapping of specific named families to the generics. On SUSE and Mandriva, simple modifications (placing Liberation* at the tops of the alias lists) to a file or two in /etc/fonts/conf.avail were enough to change from the distro-specified families to the Liberation families so that the entire desktop, including Firefox, used them instead of DejaVu or Vera whenever generics were specified. The same ought to work in Rawhide and F8, though as to FF3 so far I haven't been successful trying. :-p > Side note: that extremely big close button in FF3 is extremely ugly! > > [1] http://img186.imageshack.us/img186/6141/firefoxdefaultpf5.png > [2] http://img178.imageshack.us/img178/6871/firefoxliberationax1.png > [3] http://img178.imageshack.us/img178/7083/firefoxfontsnu7.png -- "In the beginning was the Word, and the Word was with God, and the Word was God." John 1:1 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/ From jakub.rusinek at gmail.com Tue Jan 29 05:41:35 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Tue, 29 Jan 2008 06:41:35 +0100 Subject: Suggestion: Use Liberation fonts as default in Firefox 3 In-Reply-To: <479EB8D6.3080100@ij.net> References: <6e24a8e80801280638q467ce226oeccce8b884c9f41b@mail.gmail.com> <479EB8D6.3080100@ij.net> Message-ID: <1201585295.2230.0.camel@geeko> Hi, Interested people, please register yourself in Mozilla's bugzilla and CC yourself to track changes in feature request: https://bugzilla.mozilla.org/show_bug.cgi?id=414427 -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? wiadomo?ci podpisana cyfrowo URL: From alexl at users.sourceforge.net Tue Jan 29 06:01:43 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Mon, 28 Jan 2008 23:01:43 -0700 Subject: bodhi 0.4.10 features In-Reply-To: <364d303b0801280742s767b6618yef71d58d923d2c5e@mail.gmail.com> (Christopher Brown's message of "Mon\, 28 Jan 2008 15\:42\:07 +0000") References: <20080127225406.GG3054@crow> <20080128042616.GA23022@crow> <17951.1201497570@sss.pgh.pa.us> <479DDB33.3070002@ioa.s.u-tokyo.ac.jp> <479DDF73.2060305@ioa.s.u-tokyo.ac.jp> <20080128142835.GB2713@ryvius.greysector.net> <364d303b0801280742s767b6618yef71d58d923d2c5e@mail.gmail.com> Message-ID: <3g63xdw4oo.fsf@allele2.eebweb.arizona.edu> >>>>> "CB" == Christopher Brown writes: [...] >> I also agree. It seems like overkill and increases the bug load >> unless there are tools as suggested above. Sometimes a bug is >> reported in F-7 but fixed in F-8 and there is nobody who can >> investigate whether the F-8 fix works in F-7. Is it really >> necessary to create a new bug just for that purpose? It's seems >> better to move the bug to F-8, and push a new update for both >> branches. If it doesn't fix things in the F-7 branch somebody will >> re-open the bug. No big deal. CB> Actually it can be. Once a bug gets more than two or three people CB> commenting and supplying feedback, things get awfully complicated CB> and you end up in a situation where no-one knows what version CB> someone is running and it becomes time-consuming to track back CB> over closed bugs to review who is running what. [...] Agreed there are certainly many situations where you need to clone the bug and have separate bugs for each branch, especially, as you note for kernel bugs. I was simply arguing that it shouldn't be an absolute hard requirement to create a new bug in every instance when a bug is fixed in more than one branch. Alex From michel.sylvan at gmail.com Tue Jan 29 06:05:36 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Tue, 29 Jan 2008 01:05:36 -0500 Subject: Headsup: new API and ABI changing goffice update headed towards rawhide In-Reply-To: <479A6E04.5040502@hhs.nl> References: <479A6E04.5040502@hhs.nl> Message-ID: On Jan 25, 2008 6:17 PM, Hans de Goede wrote: > Hi All, > > I've been working on updating gnumeric to the 1.8.x tree, this needs the latest > stable 0.6 series of goffice, therefor I'm also updating goffice from 0.2 to > 0.6, which means a change in soname, and in API. > > The only other user is abiword, a patch for abiword for the 0.5 devel series of > goffice, which lead to the 0.6 release is available here: > http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/abiword-goffice05.patch?rev=1.1 > That patch does not really work. Priting support is missing (can be commented out, but with loss of functionality) and there is a weird bug: AbiGOChart.cpp: In member function 'void GOChartView::modify()': AbiGOChart.cpp:833: error: cannot convert 'GtkWindow*' to 'GClosure*' for argument '4' to 'GtkWidget* gog_guru(GogGraph*, GogDataAllocator*, GOCmdContext*, GClosure*)' (this is from the 2.6 branch, but the stable branch has an almost-identical error) Even Abiword trunk is still using goffice 0.4 . Per this debian-bugs post: http://www.mail-archive.com/debian-bugs-dist at lists.debian.org/msg427582.html The lack of printing support discussed seems to suggest updating Abiword to use 0.4 instead. I can just drop in the plugin from trunk in that case. -- Michel Salim http://hircus.jaiku.com/ From mrmazda at ij.net Tue Jan 29 06:24:22 2008 From: mrmazda at ij.net (Felix Miata) Date: Tue, 29 Jan 2008 01:24:22 -0500 Subject: Suggestion: Use Liberation fonts as default in Firefox 3 In-Reply-To: <37964.192.54.193.53.1201541830.squirrel@rousalka.dyndns.org> References: <6e24a8e80801280638q467ce226oeccce8b884c9f41b@mail.gmail.com> <48074.192.54.193.53.1201533207.squirrel@rousalka.dyndns.org> <479DFC43.9030706@ij.net> <37964.192.54.193.53.1201541830.squirrel@rousalka.dyndns.org> Message-ID: <479EC696.7080601@ij.net> On 2008/01/28 18:37 (GMT+0100) Nicolas Mailhot apparently typed: > The ubiquitous platform's fonts were Arial, then Verdana, then > something else again in Vista. I don't know if anything regarding defaults changed in Vista, but all the way from Windows 95 through Windows XP, Internet Explorer through v7 has defaulted to Arial for web page sans-serif text, and so have Netscape, Mozilla, Firefox and SeaMonkey. In the UI up through W2K, the default was MS Sans Serif (not a TTF). In XP the UI font was changed to Tahoma, but the web page default remained Times New Roman, with fallback to Arial if the generic sans-serif was called by the web page. At least as far back as Windows 95, all Windows systems have been equipped by default with both Arial and Verdana, but the only thing that makes Verdana ubiquitous on web pages is author specification. Regardless about legal ramifications and distro preferences about the best fonts to use on the desktop, if it means anything at all to have web browsers render pages designed by authors designing exclusively on Windows to look as much as possible on Linux like they do on Windows, then Linux vendors should make all reasonable efforts to provide fonts that are metric equivalents of those found on Windows. In the absence of Windows web fonts actually being installed on Linux systems, the priority fallbacks should be to whatever GPL fonts most closely match Times New Roman for serif, Arial for sans-serif, and Courier New for monospace. Because that's exactly what the Liberation fonts were designed for, Liberation is what Firefox, SeaMonkey, Epiphany & Konqueror should all default to until such time as the user specifies something else. Other fallbacks are another matter, DejaVu and Vera both are excellent Verdana substitutes, but none of the three are suitable defaults as Arial substitutes. Maybe fontconfig could provide DejaVu or Vera if Verdana is called for but not installed, but certainly not when Arial is called for and uninstalled, unless the browser settings are changed by the user to something other than a vendor set default metric equivalent to Arial. -- "In the beginning was the Word, and the Word was with God, and the Word was God." John 1:1 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/ From mrmazda at ij.net Tue Jan 29 06:42:16 2008 From: mrmazda at ij.net (Felix Miata) Date: Tue, 29 Jan 2008 01:42:16 -0500 Subject: Suggestion: Use Liberation fonts as default in Firefox 3 In-Reply-To: <479E3675.7070004@gmail.com> References: <6e24a8e80801280638q467ce226oeccce8b884c9f41b@mail.gmail.com> <48074.192.54.193.53.1201533207.squirrel@rousalka.dyndns.org> <80d7e4090801280949v54541bfbhd1fc3aa79ffdbf44@mail.gmail.com> <1201545446.13777.10.camel@rousalka.dyndns.org> <479E3675.7070004@gmail.com> Message-ID: <479ECAC8.90707@ij.net> On 2008/01/28 20:09 (GMT) Ian Malone apparently typed: > Nicolas Mailhot wrote: >> Arial will pass away like Helvetica did eventually. > Helvetica has passed away? Bitmap fonts have passed away from systems using only xft & fontconfig. Helvetica on Linux is/was a bitmap font. http://mrmazda.no-ip.com/auth/Font/font-helvetica.html#bitmap Helvetica isn't really gone of course, because Liberation Sans and Arial are so difficult to distinguish from it that as long as the latter two live on, most of us won't know any difference. -- "In the beginning was the Word, and the Word was with God, and the Word was God." John 1:1 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/ From lordmorgul at gmail.com Tue Jan 29 07:40:51 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Mon, 28 Jan 2008 23:40:51 -0800 Subject: long term support release In-Reply-To: <4799EE52.4020904@midlandscc.net> References: <1201058211.3001.79.camel@gandalf.cobite.com> <200801241528.m0OFSAk8009592@laptop13.inf.utfsm.cl> <479969D1.8010202@gmail.com> <200801250924.29871.opensource@till.name> <4799EB71.4010000@gmail.com> <4799EE52.4020904@midlandscc.net> Message-ID: <479ED883.4020800@gmail.com> john wright wrote: > I seem to have gotten into something I never intended. How do I > dissenroll from this mailing list?? > > Sorry, it looks very interesting, but 100 emails a day is swamping my > email box. Instructions at: https://www.redhat.com/mailman/listinfo/fedora-devel-list on the bottom of every email. ;) For your future 'when its interesting' reading you might just read at: http://fcp.surfsite.org/modules/newbb/index.php -- Andrew Farris www.lordmorgul.net gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From lordmorgul at gmail.com Tue Jan 29 07:43:31 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Mon, 28 Jan 2008 23:43:31 -0800 Subject: long term support release In-Reply-To: <4799ECB6.4070103@mindspring.com> References: <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <604aa7910801250150g3e2b6732we481ef783f83c240@mail.gmail.com> <4799ECB6.4070103@mindspring.com> Message-ID: <479ED923.8000202@gmail.com> Richard Hally wrote: > Jeff Spaleta wrote: >> On Jan 25, 2008 12:35 AM, Patrice Dumas wrote: > snip > >> there needs to be some plan to actually make sure that >> happens so we don't mislead users. A purpose and scope defined well >> enough so that I can track some sort of performance metric. >> >> -jef >> > Does such a thing("some sort of performance metric") exist for Fedora > itself? > > Richard That would be impossible... one cannot have a performance metric of something so vague as a whole project this size (except in politics). -- Andrew Farris www.lordmorgul.net gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From nicolas.mailhot at laposte.net Tue Jan 29 08:46:52 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 29 Jan 2008 09:46:52 +0100 (CET) Subject: Fedora 8 installation crash In-Reply-To: <479E7285.2010400@gmail.com> References: <479E7285.2010400@gmail.com> Message-ID: <14100.192.54.193.53.1201596412.squirrel@rousalka.dyndns.org> Le Mar 29 janvier 2008 01:25, Andrew Farris a ?crit : > Eric van der Maarel wrote: >> I'm having the exact same problem here on a Compag nc8000. >> Has somebody found the problem and a solution yet? > > Eric, your email did not seem to refer to the previous thread > correctly, so > 'exact same problem' is not clear. IIRC recent compaq laptops have a bios bug that require very recent kernels to work around (not even sure if 2.6.24 is ok). If the nc8000 is part of this batch, I doubt any pre-F9 release is going to work. -- Nicolas Mailhot From nicolas.mailhot at laposte.net Tue Jan 29 09:08:08 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 29 Jan 2008 10:08:08 +0100 (CET) Subject: Suggestion: Use Liberation fonts as default in Firefox 3 In-Reply-To: <479EC696.7080601@ij.net> References: <6e24a8e80801280638q467ce226oeccce8b884c9f41b@mail.gmail.com> <48074.192.54.193.53.1201533207.squirrel@rousalka.dyndns.org> <479DFC43.9030706@ij.net> <37964.192.54.193.53.1201541830.squirrel@rousalka.dyndns.org> <479EC696.7080601@ij.net> Message-ID: <11217.192.54.193.53.1201597688.squirrel@rousalka.dyndns.org> Le Mar 29 janvier 2008 07:24, Felix Miata a ?crit : > Regardless about legal ramifications and distro preferences about the > best fonts to use on the desktop, We can't disregard those. > if it means anything at all to have web browsers > render pages designed by authors designing exclusively on Windows to > look as much as possible on Linux like they do on Windows, That's a big if. We don't emulate windows windows widget style and size in Firefox, and Firefox 3 new full page zooming means there will be huge differences between our rendering and the rendering of most windows browsers even if we had the very same fonts with the very same font rendering libs (which we don't and can't). > the priority fallbacks should be to whatever GPL > fonts most closely match Times New Roman for serif, As was already explained Times New Roman metrics are terrible for screen viewing, because it was designed for very different use. > Arial for sans-serif, Liberation Sans is certainly the best of the lot and someone could make a case for it?. Though if this case was only "do like Windows" it would open a huge can of worms because Arial is not the default Sans Serif for every script, we don't have clones of all the other defaults, and the rules we follow to match scripts and fonts are not the same as on this platform > and Courier New for monospace. Courier New is so bad none of the clones even tried to emulate its style. And discussing Monospace metrics when we don't even use a sensible Monospace size baseline size strikes me as deeply futile. Lastly we do use the Liberation family when the site author explicitely asks for Arial, Times New Roman or Courier New. For other fonts to be used the site author has to declare its design does not care about the particular font used to render it. ? But likewise DejaVu Sans is the best of the DejaVu lot which only underlines the utter stupidity of having Serif the browser default. -- Nicolas Mailhot From nicolas.mailhot at laposte.net Tue Jan 29 09:41:48 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 29 Jan 2008 10:41:48 +0100 (CET) Subject: Suggestion: Use Liberation fonts as default in Firefox 3 In-Reply-To: <11217.192.54.193.53.1201597688.squirrel@rousalka.dyndns.org> References: <6e24a8e80801280638q467ce226oeccce8b884c9f41b@mail.gmail.com> <48074.192.54.193.53.1201533207.squirrel@rousalka.dyndns.org> <479DFC43.9030706@ij.net> <37964.192.54.193.53.1201541830.squirrel@rousalka.dyndns.org> <479EC696.7080601@ij.net> <11217.192.54.193.53.1201597688.squirrel@rousalka.dyndns.org> Message-ID: <32049.192.54.193.53.1201599708.squirrel@rousalka.dyndns.org> BTW if you're that convinced having the same font set on every platform is a must for web rendering, I suggest you ask the Mozilla Foundation to bless an official FLOSS font set for Firefox, distribute it with Firefox itself and set Firefox defaults to use this font set exclusively. Depending on proprietary fonts other platforms are hard-pressed to replicate is contrary to MoFo official "free web" objectives anyway. And MoFo has the resources either to coopt existing FLOSS fonts or contract a foundry to create a new set. If you can convince it to care about the problem in the first place, that is. -- Nicolas Mailhot From ibmalone at gmail.com Tue Jan 29 09:49:11 2008 From: ibmalone at gmail.com (Ian Malone) Date: Tue, 29 Jan 2008 09:49:11 +0000 Subject: Suggestion: Use Liberation fonts as default in Firefox 3 In-Reply-To: <479EC696.7080601@ij.net> References: <6e24a8e80801280638q467ce226oeccce8b884c9f41b@mail.gmail.com> <48074.192.54.193.53.1201533207.squirrel@rousalka.dyndns.org> <479DFC43.9030706@ij.net> <37964.192.54.193.53.1201541830.squirrel@rousalka.dyndns.org> <479EC696.7080601@ij.net> Message-ID: <479EF697.2010609@gmail.com> Felix Miata wrote: > On 2008/01/28 18:37 (GMT+0100) Nicolas Mailhot apparently typed: > >> The ubiquitous platform's fonts were Arial, then Verdana, then >> something else again in Vista. > > I don't know if anything regarding defaults changed in Vista, but all the way > from Windows 95 through Windows XP, Internet Explorer through v7 has > defaulted to Arial for web page sans-serif text, and so have Netscape, > Mozilla, Firefox and SeaMonkey. In the UI up through W2K, the default was MS > Sans Serif (not a TTF). In XP the UI font was changed to Tahoma, but the web > page default remained Times New Roman, with fallback to Arial if the generic > sans-serif was called by the web page. > Segoe UI is the new system font (sans), Calibri replaces Arial and is used as the default in MS Office (replacing the serifed TNR). It's a font for display on LCD monitors using MS's new rendering engine (or so Wikipedia's blurb goes), so expect to see it blown up to ridiculous sizes for posters and newsletters soon. (Though Segoe UI does its job well.) -- imalone From behdad at behdad.org Tue Jan 29 09:53:00 2008 From: behdad at behdad.org (Behdad Esfahbod) Date: Tue, 29 Jan 2008 04:53:00 -0500 Subject: Suggestion: Use Liberation fonts as default in Firefox 3 In-Reply-To: <32049.192.54.193.53.1201599708.squirrel@rousalka.dyndns.org> References: <6e24a8e80801280638q467ce226oeccce8b884c9f41b@mail.gmail.com> <48074.192.54.193.53.1201533207.squirrel@rousalka.dyndns.org> <479DFC43.9030706@ij.net> <37964.192.54.193.53.1201541830.squirrel@rousalka.dyndns.org> <479EC696.7080601@ij.net> <11217.192.54.193.53.1201597688.squirrel@rousalka.dyndns.org> <32049.192.54.193.53.1201599708.squirrel@rousalka.dyndns.org> Message-ID: <1201600380.28890.82.camel@behdad.behdad.org> I've not been following the thread closely, but if it helps ending the thread, lemme chime in. The subject of this thread makes no sense. A webpage either asks for generic fonts like specific fonts like Arial, Times New Roman, and Courier New, for which Liberations fonts are used if they are installed. If the page doesn't ask for specific fonts like that, it probably is as happy with Tahoma as it is with DejaVu Sans. Nothing to fix here. behdad On Tue, 2008-01-29 at 10:41 +0100, Nicolas Mailhot wrote: > BTW if you're that convinced having the same font set on every > platform is a must for web rendering, I suggest you ask the Mozilla > Foundation to bless an official FLOSS font set for Firefox, distribute > it with Firefox itself and set Firefox defaults to use this font set > exclusively. > > Depending on proprietary fonts other platforms are hard-pressed to > replicate is contrary to MoFo official "free web" objectives anyway. > And MoFo has the resources either to coopt existing FLOSS fonts or > contract a foundry to create a new set. If you can convince it to care > about the problem in the first place, that is. > > -- > Nicolas Mailhot > -- behdad http://behdad.org/ "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin, 1759 From lordmorgul at gmail.com Tue Jan 29 09:53:08 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Tue, 29 Jan 2008 01:53:08 -0800 Subject: long term support release In-Reply-To: <1201500923.3242.95.camel@beck.corsepiu.local> References: <1201058211.3001.79.camel@gandalf.cobite.com> <1201102248.3001.118.camel@gandalf.cobite.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <1201250321.17905.251.camel@beck.corsepiu.local> <604aa7910801250047y3e4cf425xda83f7f3ef4df111@mail.gmail.com> <4799EAA0.7030700@gmail.com> <20080125102616.7605825b@redhat.com> <479A0C6B.1050004@gmail.com> <20080125112254.382c9e13@redhat.com> <479A190F.8010402@gmail.com> <200801251727.m0PHRe0O016727@laptop13.inf.utfsm.cl> <479A268B.5070201@gmail.com> <1201330199.17905.561.camel@beck.corsepiu.local> <200801270129.m0R1T0Eg000930@laptop13.inf.utfsm.cl> <1201410189.17905.709.camel@beck.corsepiu.local> <200801272221.m0RMLBhk010404@laptop13.inf.utfsm.cl> <1201500923.3242.95.camel@beck.corsepiu.local> Message-ID: <479EF784.1080002@gmail.com> Ralf Corsepius wrote: > On Sun, 2008-01-27 at 19:21 -0300, Horst H. von Brand wrote: >> Ralf Corsepius wrote: >>> On Sat, 2008-01-26 at 22:29 -0300, Horst H. von Brand wrote: >>>> Ralf Corsepius wrote: >>>>> On Fri, 2008-01-25 at 12:12 -0600, Les Mikesell wrote: >>>>>> Horst H. von Brand wrote: > >>>>> As a developer, it's not a major problem for _me_ having to cope with a >>>>> couple of issues here and there, but how do you expect "Aunt Tillie" to >>>>> cope with them? >>>> Perhaps Fedora isn't for her then. >>> We are back to the point of questioning Fedora's target audience. As it >>> currently seem to me the target audience is "RH distro developers". >> If so, how is that wrong? > > Interests collide. "RH distro developers" interests are different from > "end users" (even when putting "Aunt Tillie" aside) and "upstreams" and > development. > > E.g. SELinux, NetworkManager, Pulseaudio are widely non-interesting to > me. If they worked transparently and smoothlessly, I would simply use > them and not waste a single word about them, like I do with many other > packages on a distro. Fact is, they don't work smoothless. Refer to http://www.fedoraproject.org. The purpose of the project is clearly stated as a technology showcase; things like pulseaudio and selinux not working smoothly is pretty much a given when you combine 'new technology' and 'showcase' together. The same would be true of any industry/sector/sport/hobby/etc... to make something work smoothly you have to develop it beyond brand new technology. I don't see how interests are colliding there unless your interests are just different than what the project was set out to do in the first place. What you're asking for seems to be a platform for your application development which has the latest technology but which is developed beyond those barriers to adoption already... -- Andrew Farris www.lordmorgul.net gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From francois.aucamp at gmail.com Tue Jan 29 10:47:31 2008 From: francois.aucamp at gmail.com (Francois Aucamp) Date: Tue, 29 Jan 2008 12:47:31 +0200 Subject: PackageMaintainers/RetiredPackages still needed (was: Update of "PackageMaintainers/RetiredPackages" by [...]) In-Reply-To: References: <20080128163822.24151.87040@app1.fedora.phx.redhat.com> <479E092A.3060001@leemhuis.info> Message-ID: <200801291247.31270.faucamp@csir.co.za> On Tuesday 29 January 2008 01:50:56 am Kevin Kofler wrote: > Thorsten Leemhuis leemhuis.info> writes: > > > The comment on the change is: > > > Removed kgtk - should not be retired > > kgtk was actually retired by mistake (it doesn't depend on KWin 3, only > kdelibs3, which is still available), I discussed this with the maintainer > and he resurrected it. So this is not an issue with being "out of date", > just a corrected mistake. > > Kevin Kofler In fact, I've updated kgtk to the latest version which now builds against kdelibs4 for f9. -Francois From francois.aucamp at gmail.com Tue Jan 29 11:09:03 2008 From: francois.aucamp at gmail.com (Francois Aucamp) Date: Tue, 29 Jan 2008 13:09:03 +0200 Subject: Request help with failing build: espeak Message-ID: <200801291309.03176.faucamp@csir.co.za> Hi, The espeak-1.31-(2 to 4) builds failed on devel, although I've been unable to consistently reproduce the problem locally using mock. For me, espeak builds in mock on f8/i386, f8/x86_64 and devel/x86_64. Mock with devel/i386 gave a similar error to koji, but the koji error consistently appears on the x86_64 arch: http://koji.fedoraproject.org/koji/taskinfo?taskID=380879 The relevant part of the build log is: /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/libportaudio.so: undefined reference to `jack_port_lock' /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/libportaudio.so: undefined reference to `jack_port_unlock' Forced linking to libjack doesn't solve this (wouldn't make sense anyway considering espeak itself is only linking to libportaudio (and this used to work) ). Am I missing something silly? Or does portaudio need a rebuild? ldd -r on the (mock) devel portaudio seems fine... Thanks! -Francois From mattdm at mattdm.org Tue Jan 29 11:48:40 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 29 Jan 2008 06:48:40 -0500 Subject: Suggestion: Use Liberation fonts as default in Firefox 3 In-Reply-To: <48074.192.54.193.53.1201533207.squirrel@rousalka.dyndns.org> References: <6e24a8e80801280638q467ce226oeccce8b884c9f41b@mail.gmail.com> <48074.192.54.193.53.1201533207.squirrel@rousalka.dyndns.org> Message-ID: <20080129114840.GA18536@jadzia.bu.edu> On Mon, Jan 28, 2008 at 04:13:27PM +0100, Nicolas Mailhot wrote: > P.S. Though you've still kept Serif as default Firefox family, which > *is* an ass-backwards Firefox default we should change, since current > screens do not have enough resolution to display satisfying Serif > fonts. Mine sure does. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From j.w.r.degoede at hhs.nl Tue Jan 29 12:25:03 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 29 Jan 2008 13:25:03 +0100 Subject: Headsup: new API and ABI changing goffice update headed towards rawhide In-Reply-To: References: <479A6E04.5040502@hhs.nl> Message-ID: <479F1B1F.60000@hhs.nl> Michel Salim wrote: > On Jan 25, 2008 6:17 PM, Hans de Goede wrote: >> Hi All, >> >> I've been working on updating gnumeric to the 1.8.x tree, this needs the latest >> stable 0.6 series of goffice, therefor I'm also updating goffice from 0.2 to >> 0.6, which means a change in soname, and in API. >> >> The only other user is abiword, a patch for abiword for the 0.5 devel series of >> goffice, which lead to the 0.6 release is available here: >> http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SOURCES/abiword-goffice05.patch?rev=1.1 >> > That patch does not really work. Priting support is missing (can be > commented out, but with loss of functionality) and there is a weird > bug: > > AbiGOChart.cpp: In member function 'void GOChartView::modify()': > AbiGOChart.cpp:833: error: cannot convert 'GtkWindow*' to 'GClosure*' > for argument '4' to 'GtkWidget* gog_guru(GogGraph*, GogDataAllocator*, > GOCmdContext*, GClosure*)' > > (this is from the 2.6 branch, but the stable branch has an > almost-identical error) > > Even Abiword trunk is still using goffice 0.4 . Per this debian-bugs post: > http://www.mail-archive.com/debian-bugs-dist at lists.debian.org/msg427582.html > > The lack of printing support discussed seems to suggest updating > Abiword to use 0.4 instead. I can just drop in the plugin from trunk > in that case. > Thats a good solution I think as we are still shipping 0.4 in goffice04, as that once was needed for gnucash, while abiword and gnumeric were still using 0.2. Regards, Jans From mschwendt.tmp0701.nospam at arcor.de Tue Jan 29 12:47:22 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 29 Jan 2008 13:47:22 +0100 Subject: Request help with failing build: espeak In-Reply-To: <200801291309.03176.faucamp@csir.co.za> References: <200801291309.03176.faucamp@csir.co.za> Message-ID: <20080129134722.e59fd376.mschwendt.tmp0701.nospam@arcor.de> On Tue, 29 Jan 2008 13:09:03 +0200, Francois Aucamp wrote: > Hi, > > The espeak-1.31-(2 to 4) builds failed on devel, although I've been unable to > consistently reproduce the problem locally using mock. For me, espeak builds > in mock on f8/i386, f8/x86_64 and devel/x86_64. Mock with devel/i386 gave a > similar error to koji, but the koji error consistently appears on the x86_64 > arch: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=380879 > > The relevant part of the build log is: > /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/libportaudio.so: > undefined reference to `jack_port_lock' > /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/libportaudio.so: > undefined reference to `jack_port_unlock' > > Forced linking to libjack doesn't solve this (wouldn't make sense anyway > considering espeak itself is only linking to libportaudio (and this used to > work) ). Am I missing something silly? Or does portaudio need a rebuild? > ldd -r on the (mock) devel portaudio seems fine... To me the new JACK in rawhide looks binary incompatible despite the unchanged SONAME. A very basic check shows that the two symbols from your build error are gone in Rawhide, and hence PortAudio ought to be updated: F-8: $ strings /usr/lib/libjack.so.0.0.23 | grep jack_port_.*lock jack_port_lock jack_port_unlock Rawhide: $ strings /usr/lib/libjack.so.0.0.28 | grep jack_port_.*lock $ From francois.aucamp at gmail.com Tue Jan 29 13:02:40 2008 From: francois.aucamp at gmail.com (Francois Aucamp) Date: Tue, 29 Jan 2008 15:02:40 +0200 Subject: Request help with failing build: espeak In-Reply-To: <20080129134722.e59fd376.mschwendt.tmp0701.nospam@arcor.de> References: <200801291309.03176.faucamp@csir.co.za> <20080129134722.e59fd376.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <200801291502.40217.faucamp@csir.co.za> On Tuesday 29 January 2008 02:47:22 pm Michael Schwendt wrote: > To me the new JACK in rawhide looks binary incompatible despite the > unchanged SONAME. A very basic check shows that the two symbols from your > build error are gone in Rawhide, and hence PortAudio ought to be updated: > > F-8: > $ strings /usr/lib/libjack.so.0.0.23 | grep jack_port_.*lock > jack_port_lock > jack_port_unlock > > Rawhide: > $ strings /usr/lib/libjack.so.0.0.28 | grep jack_port_.*lock > $ Aah great, thanks. Bugzilla'd: https://bugzilla.redhat.com/show_bug.cgi?id=430672 From buildsys at redhat.com Tue Jan 29 13:18:50 2008 From: buildsys at redhat.com (Build System) Date: Tue, 29 Jan 2008 08:18:50 -0500 Subject: rawhide report: 20080129 changes Message-ID: <200801291318.m0TDIoJE003345@porkchop.devel.redhat.com> New package R-BSgenome.Dmelanogaster.FlyBase.r51 Drosophila melanogaster genome (FlyBase r5.1) New package dbus-qt3 Qt3 DBus Bindings New package emacs-lua Lua major mode for GNU Emacs New package hgsvn A set of scripts to work locally on subversion checkouts using mercurial New package silkscreen-fonts Silkscreen four member type family Updated Packages: GeoIP-1.4.4-1.fc9 ----------------- * Mon Jan 28 2008 Michael Fleming 1.4.4-1 - New upstream release. GraphicsMagick-1.1.10-1.fc9 --------------------------- * Mon Jan 28 2008 Andreas Thienemann - 1.1.10-1 - Upgraded to 1.1.10 - Fixed linking problem with the Perl module. #365901 acl-2.2.45-3.fc9 ---------------- * Mon Jan 28 2008 Jiri Moskovcak 2.2.45-3 - Fixed segfault when using only "--" as parameter - Resolves: #430458 coreutils-6.10-2.fc9 -------------------- * Mon Jan 28 2008 Ondrej Vasik - 6.10-2 - some manpages improvements(#406981,#284881) - fix non-versioned obsoletes of mktemp(#430407) curl-7.18.0-1.fc9 ----------------- * Mon Jan 28 2008 Jindrich Novy 7.18.0-1 - update to curl-7.18.0 - drop sslgen patch -> applied upstream - fix typo in description * Tue Jan 22 2008 Jindrich Novy 7.17.1-6 - fix curl-devel obsoletes so that we don't break F8->F9 upgrade path (#429612) * Tue Jan 08 2008 Jindrich Novy 7.17.1-5 - do not attempt to close a bad socket (#427966), thanks to Caolan McNamara deluge-0.5.8.3-1.fc9 -------------------- * Mon Jan 28 2008 Peter Gordon - 0.5.8.3-1 - Update to new upstream security fix release (0.5.8.3), which includes a fix for a potential remotely-exploitable stack overflow with a malformed bencoded message. dirac-0.9.1-1.fc9 ----------------- * Mon Jan 28 2008 kwizart < kwizart at gmail.com > - 0.9.1-1 - Update to 0.9.1 * Fri Jan 04 2008 kwizart < kwizart at gmail.com > - 0.8.0-3 - Fix gcc43 eel2-2.21.90-1.fc9 ------------------ * Tue Jan 29 2008 Matthias Clasen - 2.21.90-1 - Update to 2.21.90 eric-4.0.4-2.fc9 ---------------- * Mon Jan 28 2008 Dennis Gilmore 4.0.4-2 - fix incorrect BuildRequires/Requires qscintilla-python * Mon Jan 28 2008 Dennis Gilmore 4.0.4-1 - update to eric4 evince-2.21.90-1.fc9 -------------------- * Mon Jan 28 2008 Matthias Clasen - 2.21.90-1 - Update to 2.21.90 evolution-2.21.90-1.fc9 ----------------------- * Mon Jan 28 2008 Matthew Barnes - 2.21.90-1.fc9 - Update to 2.21.90 - Update build requirements. - Remove patch for GNOME #363695 (obsolete/problematic). - Remove patch for GNOME #509741 (fixed upstream). evolution-data-server-2.21.90-1.fc9 ----------------------------------- * Mon Jan 28 2008 Matthew Barnes - 2.21.90-1.fc9 - Update to 2.21.90 - Remove patch for GNOME bug #509644 (fixed upstream). evolution-exchange-2.21.90-1.fc9 -------------------------------- * Mon Jan 28 2008 Matthew Barnes - 2.21.90-1.fc9 - Update to 2.21.90 - Update build requirements. evolution-zimbra-0.1.0-4.fc9 ---------------------------- * Mon Jan 28 2008 Matthew Barnes - 0.1.0-4.fc9 - Rebuild against newer Camel library. firstboot-1.91-2.fc9 -------------------- * Mon Jan 28 2008 Chris Lumens 1.91-2 - Put module in /usr/lib64 on 64-bit platforms. freetds-0.64-9.fc9 ------------------ * Mon Jan 28 2008 Dmitry Butskoy - 0.64-9 - drop "Obsoletes:" from -doc subpackage to avoid extra complexity. ftp-0.17-45.fc9 --------------- * Mon Jan 28 2008 Marcela Maslanova - 0.17-45 - changed bitrate from 1e+03 KBytes/sec to 1000 kBytes/sec - Resolves: rhbz#430457 gcalctool-5.21.90-1.fc9 ----------------------- * Mon Jan 28 2008 Matthias Clasen - 5.21.90-1 - Update to 5.21.90 genius-1.0.2-2.fc9 ------------------ * Mon Jan 28 2008 Gerard Milmeister - 1.0.2-2 - remove _smp_mflags * Sun Jan 27 2008 Gerard Milmeister - 1.0.2-1 - new release 1.0.2 ghostscript-8.61-7.fc9 ---------------------- * Mon Jan 28 2008 Tim Waugh 8.61-7 - Don't build with jasper support. - Remove bundled libraries. gimp-2:2.4.3-2.fc9 ------------------ * Mon Jan 28 2008 Nils Philippsen - 2:2.4.3-2 - don't package static libraries (#430330) - use %bcond_... macros for package options glabels-2.2.1-1.fc9 ------------------- * Mon Jan 28 2008 Peter Gordon - 2.2.1-1 - Update to new upstream bug-fix release (2.2.1). glib2-2.15.4-1.fc9 ------------------ * Mon Jan 28 2008 Matthias Clasen - 2.15.4-1 - Update to 2.15.4 glpi-0.70.2-2.fc9 ----------------- * Mon Jan 28 2008 Remi Collet - 0.70.2-2 - rebuild (fix sources tarball) gnomad2-2.9.1-1.fc9 ------------------- * Mon Jan 28 2008 Linus Walleij 2.9.1-1 - New upstream version, new nice features. gnome-desktop-2.21.90-1.fc9 --------------------------- gnome-keyring-2.21.5-3.fc9 -------------------------- * Mon Jan 28 2008 Ray Strode - 2.21.5-3 - Don't ask for a password...ever (bug 430525) gnome-menus-2.21.90-1.fc9 ------------------------- * Tue Jan 29 2008 Matthias Clasen - 2.21.90-1 - Update to 2.21.90 gnuplot-4.2.2-8.fc9 ------------------- * Mon Jan 28 2008 Ivana Varekova - 4.2.2-8 - fix 430335 - add wxGTK requires gsoap-2.7.10-1.fc9 ------------------ * Sun Jan 27 2008 - 2.7.10-1 - Upgraded to 2.7.10 release - Stopped hosting patches on grid.et.redhat.com - Removed import_dom_h patch, it was integrated - Removed large autotools patch, replaced with patch (use_libtool-2.7.10.patch) changing configure.in, gsoap/Makefile.am and gsoap/wsdl/Makefile.am, which enable libtool use, and a call to autoreconf - Changed soapcpp2 references to gsoap as per new layout of source distribution - Updated tru64_hp_up_c/pp patches to handle new source layout - Install of soapcpp2/import with cp removed in favor of a patch to gsoap/Makefile.am (install_soapcpp2_wsdl2h_aux-2.7.10.patch) - No pre-generated Makefiles are distributed, no longer removing them - stdsoap2_cpp.cpp not in distribution, no longer removing it - Added datadir_importpath-2.7.10.patch to set SOAPCPP2_IMPORT_PATH and WSDL2H_IMPORT_PATH, useful defaults, using ${datadir} instead of `pwd` - Added autoconf, automake and libtool to BuildRequires, because configure.in and gsoap/Makefile.am are patched - Added ?dist to Release gstreamer-0.10.16-1.fc9 ----------------------- * Tue Jan 29 2008 - Bastien Nocera - 0.10.16-1 - Update to 0.10.16 * Fri Nov 16 2007 - Bastien Nocera - 0.10.15-1 - Update to 0.10.15 * Mon Oct 01 2007 Matthias Clasen - 0.10.14-4 - Add missing Requires (#312671) gtk2-2.12.6-1.fc9 ----------------- * Tue Jan 29 2008 Matthias Clasen - 2.12.6-1 - Update to 2.12.6 * Tue Jan 08 2008 Matthias Clasen - 2.12.5-1 - Update to 2.12.5 * Tue Jan 08 2008 Matthias Clasen - 2.12.4-1 - Update to 2.12.4 - Drop obsolete patches gtk2-engines-2.13.4-1.fc9 ------------------------- * Mon Jan 28 2008 Matthias Clasen - 2.13.4-1 - Update to 2.13.4 gtkhtml3-3.17.90-1.fc9 ---------------------- * Mon Jan 28 2008 Matthew Barnes - 3.17.90-1.fc9 - Update to 3.17.90 * Mon Jan 14 2008 Matthew Barnes - 3.17.5-1.fc9 - Update to 3.17.5 * Mon Dec 17 2007 Matthew Barnes - 3.17.4-1.fc9 - Update to 3.17.4 gvfs-0.1.5-1.fc9 ---------------- * Mon Jan 28 2008 Matthias Clasen - 0.1.5-1 - Update to 0.1.5 - Reenable http/dav * Mon Jan 21 2008 Alexander Larsson - 0.1.4-2 - Remove the http/dav stuff for now, as we don't have the latest libsoup * Mon Jan 21 2008 Alexander Larsson - 0.1.4-1 - Update to 0.1.4 - Send USR1 in post to reload config kernel-2.6.24-7.fc9 ------------------- * Mon Jan 28 2008 Chuck Ebbert - Strip extra leading slashes in selinux filenames. - wireless: reject too-new b43 firmware * Mon Jan 28 2008 Chuck Ebbert - Build in the CMOS RTC driver. * Mon Jan 28 2008 Jarod Wilson - Update firewire with latest pending bits - Add epoll lockdep annotation (#323411) libIDL-0.8.9-2.fc9 ------------------ * Tue Jan 29 2008 Matthias Clasen - 0.8.9-2 - Don't use G_GNUC_PRETTY_FUNCTION libgdl-0.7.8-1.fc9 ------------------ libopensync-0.36-1.fc9 ---------------------- * Mon Jan 28 2008 Andreas Bierfert - 0.36-1 - version upgrade * Fri Dec 28 2007 Andreas Bierfert - 0.35-2 - use cmake macro * Thu Dec 27 2007 Andreas Bierfert - 0.35-1 - version upgrade libsoup-2.3.0-1.fc9 ------------------- * Mon Jan 28 2008 Matthew Barnes - 2.3.0-1 - Update to 2.3.0 - Bump glib2 requirement to >= 2.15.3. - Clean up some redundant dependencies. - Remove patch for RH bug #327871 (fixed in glibc). libupnp-1.6.4-1.fc9 ------------------- * Sun Jan 27 2008 Eric Tanguy - 1.6.4-1 - Update to version 1.6.4 libwnck-2.21.90-1.fc9 --------------------- * Mon Jan 28 2008 Matthias Clasen - 2.21.90-1 - Update to 2.21.90 logwatch-7.3.6-18.fc9 --------------------- * Mon Jan 28 2008 Ivana Varekova 7.3.6-18 - resolves: #429933 fix postfix script thanks Benjamin Gordon nautilus-2.21.90-1.fc9 ---------------------- * Tue Jan 29 2008 Matthias Clasen - 2.21.90-1 - Update to 2.21.90 * Mon Jan 21 2008 Matthias Clasen - 2.21.6-1 - Update to 2.21.6 * Mon Jan 14 2008 Matthias Clasen - 2.21.5-1 - Update to 2.21.5 net-snmp-1:5.4.1-8.fc9 ---------------------- * Mon Jan 28 2008 Jan Safranek 5.4.1-8 - init scripts made LSB compliant openldap-2.4.7-6.fc9 -------------------- * Mon Jan 28 2008 Jan Safranek 2.4.7-6 - init script fixes * Mon Jan 28 2008 Jan Safranek 2.4.7-5 - init script made LSB-compliant (#247012) openswan-2.6.04-1.fc9 --------------------- * Mon Jan 28 2008 Steve Conklin - 2.6.04-1 - Move to new upstream source pam-0.99.8.1-17.fc9 ------------------- * Mon Jan 28 2008 Tomas Mraz 0.99.8.1-17 - test for setkeycreatecon correctly - add exclusive login mode of operation to pam_selinux_permit (original patch by Dan Walsh) * Tue Jan 22 2008 Tomas Mraz 0.99.8.1-16 - add auditing to pam_access, pam_limits, and pam_time - moved sanity testing code to check script * Mon Jan 14 2008 Tomas Mraz 0.99.8.1-15 - merge review fixes (#226228) perl-Archive-Extract-0.26-1.fc9 ------------------------------- * Mon Jan 28 2008 Steven Pritchard 0.26-1 - Update to 0.26. - Update License tag. perl-BerkeleyDB-0.33-1.fc9 -------------------------- * Mon Jan 28 2008 Steven Pritchard 0.33-1 - Update to 0.33. - Update License tag. - BR Test::More. * Wed Aug 29 2007 Fedora Release Engineering - 0.32-2 - Rebuild for selinux ppc32 issue. perl-Devel-Caller-2.03-1.fc9 ---------------------------- perl-Error-1:0.17012-1.fc9 -------------------------- * Mon Jan 28 2008 Steven Pritchard 1:0.17012-1 - Update to 0.17012. perl-Log-Message-Simple-0.04-1.fc9 ---------------------------------- * Mon Jan 28 2008 Steven Pritchard 0.04-1 - Update to 0.04. perl-Module-CoreList-2.13-1.fc9 ------------------------------- * Mon Jan 28 2008 Steven Pritchard 2.13-1 - Update to 2.13. - Use fixperms macro instead of our own chmod incantation. - Reformat to match cpanspec output. - BR ExtUtils::MakeMaker. * Tue Jan 15 2008 Tom "spot" Callaway - 2.11-2 - license fix perl-Module-Install-0.68-1.fc9 ------------------------------ * Mon Jan 28 2008 Steven Pritchard 0.68-1 - Update to 0.68. - Explicitly require Archive::Tar and ExtUtils::ParseXS. perl-Module-Load-Conditional-0.24-1.fc9 --------------------------------------- * Mon Jan 28 2008 Steven Pritchard 0.24-1 - Update to 0.24. * Mon Oct 15 2007 Steven Pritchard 0.22-1 - Update to 0.22. - Update License tag. - Update BR Module::Load to >= 0.11. perl-Module-ScanDeps-0.82-1.fc9 ------------------------------- * Mon Jan 28 2008 Steven Pritchard 0.82-1 - Update to 0.82. - BR version. perl-Net-SCP-0.08-1.fc9 ----------------------- * Mon Jan 28 2008 Steven Pritchard 0.08-1 - Update to 0.08. - Update License tag. perl-PadWalker-1.6-1.fc9 ------------------------ * Mon Jan 28 2008 Steven Pritchard 1.6-1 - Update to 1.6. - Use fixperms macro instead of our own chmod incantation. - Reformat to match cpanspec output. * Sun Jan 13 2008 Tom "spot" Callaway - 1.5-2 - rebuild for new perl perl-Term-ReadPassword-0.11-1.fc9 --------------------------------- perl-Term-UI-0.18-1.fc9 ----------------------- * Mon Jan 28 2008 Steven Pritchard 0.18-1 - Update to 0.18. perl-Test-Class-0.28-1.fc9 -------------------------- perl-Test-Deep-0.100-1.fc9 -------------------------- * Mon Jan 28 2008 Steven Pritchard 0.100-1 - Update to 0.100. perl-YAML-Syck-1.01-1.fc9 ------------------------- * Mon Jan 28 2008 Steven Pritchard 1.01-1 - Update to 1.01. perl-YAML-Tiny-1.25-1.fc9 ------------------------- * Mon Jan 28 2008 Steven Pritchard 1.25-1 - Update to 1.25. qscintilla-2.1-3.fc9 -------------------- * Mon Jan 28 2008 Dennis Gilmore - 2.1-3 - fix typo in Obsoletes: on python package * Mon Jan 28 2008 Dennis Gilmore - 2.1-2 - remove dumb require on di from qscintilla-python * Mon Jan 28 2008 Dennis Gilmore - 2.1-1 - update to 2.1 branch remind-03.01.02-3.fc9 --------------------- * Mon Jan 28 2008 Ray Van Dolson - 03.01.02-3 - Copied rem2html to /usr/bin per bz #430502 - Using a few more macros in spec file * Wed Sep 19 2007 Ray Van Dolson - 03.01.02-2 - Added tcllib requires per bz #290761 * Thu Sep 13 2007 Ray Van Dolson - 03.01.02-1 - Updated to version 03.01.02 selinux-policy-3.2.5-20.fc9 --------------------------- * Fri Jan 25 2008 Dan Walsh 3.2.5-20 - Allow usertypes to read/write noxattr file systems snake-0.10-0.5.fc9 ------------------ * Mon Jan 28 2008 James Laska 0.10-0.5 - RHEL5 doesn't like when snake/tui.py calls screen.pop() multiple times texlive-2007-16.fc9 ------------------- * Mon Jan 28 2008 Jindrich Novy - 2007-16 - package Japanese separately -> texlive-japanese - add missing BR: texlive-texmf-fonts (#430338) - temporarily disable BR: texlive in kpathsea * Wed Jan 23 2008 Jindrich Novy - 2007-15 - dependency pruning: (#428489, #429753) - package XeTeX separately - move ghostscript utilities (a2ping, e2pall, epstopdf, gsftopk, pdfcrop, ps4pdf, thumbpdf) and metafont with X support to texlive-utils subpackage - move allcm, allec, allneeded to texlive-dvips - package xdvipdfmx in dvipdfmx subpackage - only texlive-doc now requires xdg-utils * Tue Jan 22 2008 Jindrich Novy - 2007-14 - use xdg-open(1) in texdoctk (#429659) - fix bad syntax of texmfstart man page texlive-texmf-2007-10.fc9 ------------------------- * Mon Jan 28 2008 Jindrich Novy - 2007-10 - BR: texinfo-tex - package Japanese separately -> texlive-texmf-japanese - prevent packaging patch backups - correct directory/file permissions in less wasteful way to increase build speed - run only brp-compress * Fri Jan 25 2008 Jindrich Novy - 2007-9 - remove $TEXMFMAIN/tex/texinfo to not to clash with texinfo (#226488) tftp-0.48-1.fc9 --------------- * Tue Jan 22 2008 Martin Nagy - 0.48-1 - upgrade to 0.48 - remove the old sigjmp patch (fixed in upstream) - make some changes in spec file (#226489) tk-1:8.5.0-4.fc9 ---------------- * Fri Jan 25 2008 Marcela Maslanova - 1:8.5.0-4 - attached upstream patch - similar to CVE-2006-4484, problem with GIF again #430100 * Tue Jan 15 2008 Marcela Maslanova - 1:8.5.0-3 - wish8.5 is here again for back compatibility * Sat Jan 05 2008 Marcela Maslanova - 1:8.5.0-2 - Obsolete the tile package that has been incorporated into the core tk source. util-linux-ng-2.13.1-3.fc9 -------------------------- * Mon Jan 28 2008 Karel Zak 2.13.1-3 - upgrade to new upstream release - fix #427874 - util-linux-ng gets "excess command line argument" on update xinetd-2:2.3.14-16.fc9 ---------------------- * Mon Jan 28 2008 Jan Safranek - 2:2.3.14-16 - xinetd.log man page is in the right section now (#428812) * Thu Sep 06 2007 Jan Safranek - 2:2.3.14-15 - initscript made LDB compliant (#247099) Broken deps for i386 ---------------------------------------------------------- PyQt-qscintilla-3.17.4-1.fc9.i386 requires libqscintilla.so.7 1:abiword-2.4.6-6.fc8.i386 requires libgoffice-1.so.2 bmpx-0.40.13-7.fc9.i386 requires libsoup-2.2.so.8 1:bug-buddy-2.20.1-1.fc9.i386 requires libsoup-2.2.so.8 buoh-0.8.2-2.fc7.i386 requires libsoup-2.2.so.8 compiz-kde-0.6.2-6.fc9.i386 requires libkdecorations.so.1 crystal-1.0.5-1.fc8.i386 requires libkdecorations.so.1 dekorator-0.3-3.fc7.i386 requires libkdecorations.so.1 drivel-2.1.1-0.3.20071130svn.fc9.i386 requires libsoup-2.2.so.8 epiphany-extensions-2.20.1-3.fc9.i386 requires libgtkembedmoz.so epiphany-extensions-2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 evolution-brutus-1.1.28.7-2.fc8.i386 requires libcamel-1.2.so.10 evolution-webcal-2.12.0-1.fc8.i386 requires libsoup-2.2.so.8 gnome-web-photo-0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo-0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo-0.3-8.fc9.i386 requires libgtkembedmoz.so gnome-web-photo-0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 hardinfo-0.4.2.3-1.fc9.i386 requires libsoup-2.2.so.8 kazehakase-0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 kicker-compiz-3.5.4-4.fc8.i386 requires libkickermain.so.1 kicker-compiz-3.5.4-4.fc8.i386 requires libtaskmanager.so.1 ksplash-engine-moodin-0.4.2-4.fc7.i386 requires libksplashthemes.so.0 libepc-0.3.3-1.fc9.i386 requires libsoup-2.2.so.8 libsyncml-0.4.5-1.fc9.i386 requires libsoup-2.2.so.8 libtranslate-0.99-12.fc9.i386 requires libsoup-2.2.so.8 1:logjam-4.5.3-9.fc8.3.i386 requires libsoup-2.2.so.8 mail-notification-evolution-plugin-5.0-0.2.rc1.fc9.i386 requires libcamel-provider-1.2.so.10 mail-notification-evolution-plugin-5.0-0.2.rc1.fc9.i386 requires libcamel-1.2.so.10 muine-0.8.8-6.fc9.i386 requires mono(muine-plugin) = 0:1.0.0.0 planner-eds-0.14.2-10.fc9.i386 requires libcamel-provider-1.2.so.10 planner-eds-0.14.2-10.fc9.i386 requires libcamel-1.2.so.10 rhythmbox-0.11.4-4.fc9.i386 requires libsoup-2.2.so.8 rt3-3.6.5-1.fc8.noarch requires perl(Text::Wrapper) seahorse-2.21.4-3.fc9.i386 requires libsoup-2.2.so.8 swfdec-gtk-0.5.5-2.fc9.i386 requires libsoup-2.2.so.8 totem-pl-parser-2.21.91-1.fc9.i386 requires libcamel-1.2.so.10 totem-publish-2.21.90-2.fc9.i386 requires libsoup-2.2.so.8 twitux-0.60-2.fc9.i386 requires libsoup-2.2.so.8 Broken deps for x86_64 ---------------------------------------------------------- PyQt-qscintilla-3.17.4-1.fc9.x86_64 requires libqscintilla.so.7()(64bit) 1:abiword-2.4.6-6.fc8.x86_64 requires libgoffice-1.so.2()(64bit) bmpx-0.40.13-7.fc9.x86_64 requires libsoup-2.2.so.8()(64bit) 1:bug-buddy-2.20.1-1.fc9.x86_64 requires libsoup-2.2.so.8()(64bit) buoh-0.8.2-2.fc7.x86_64 requires libsoup-2.2.so.8()(64bit) compiz-kde-0.6.2-6.fc9.x86_64 requires libkdecorations.so.1()(64bit) crystal-1.0.5-1.fc8.x86_64 requires libkdecorations.so.1()(64bit) dekorator-0.3-3.fc7.x86_64 requires libkdecorations.so.1()(64bit) drivel-2.1.1-0.3.20071130svn.fc9.x86_64 requires libsoup-2.2.so.8()(64bit) epiphany-extensions-2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) epiphany-extensions-2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 evolution-brutus-1.1.28.7-2.fc8.i386 requires libcamel-1.2.so.10 evolution-brutus-1.1.28.7-2.fc8.x86_64 requires libcamel-1.2.so.10()(64bit) evolution-webcal-2.12.0-1.fc8.x86_64 requires libsoup-2.2.so.8()(64bit) gnome-web-photo-0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) gnome-web-photo-0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo-0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo-0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) hardinfo-0.4.2.3-1.fc9.x86_64 requires libsoup-2.2.so.8()(64bit) kazehakase-0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 kicker-compiz-3.5.4-4.fc8.x86_64 requires libkickermain.so.1()(64bit) kicker-compiz-3.5.4-4.fc8.x86_64 requires libtaskmanager.so.1()(64bit) ksplash-engine-moodin-0.4.2-4.fc7.x86_64 requires libksplashthemes.so.0()(64bit) libepc-0.3.3-1.fc9.i386 requires libsoup-2.2.so.8 libepc-0.3.3-1.fc9.x86_64 requires libsoup-2.2.so.8()(64bit) libsyncml-0.4.5-1.fc9.i386 requires libsoup-2.2.so.8 libsyncml-0.4.5-1.fc9.x86_64 requires libsoup-2.2.so.8()(64bit) libtranslate-0.99-12.fc9.i386 requires libsoup-2.2.so.8 libtranslate-0.99-12.fc9.x86_64 requires libsoup-2.2.so.8()(64bit) 1:logjam-4.5.3-9.fc8.3.x86_64 requires libsoup-2.2.so.8()(64bit) mail-notification-evolution-plugin-5.0-0.2.rc1.fc9.x86_64 requires libcamel-1.2.so.10()(64bit) mail-notification-evolution-plugin-5.0-0.2.rc1.fc9.x86_64 requires libcamel-provider-1.2.so.10()(64bit) muine-0.8.8-6.fc9.x86_64 requires mono(muine-plugin) = 0:1.0.0.0 planner-eds-0.14.2-10.fc9.x86_64 requires libcamel-1.2.so.10()(64bit) planner-eds-0.14.2-10.fc9.x86_64 requires libcamel-provider-1.2.so.10()(64bit) rhythmbox-0.11.4-4.fc9.i386 requires libsoup-2.2.so.8 rhythmbox-0.11.4-4.fc9.x86_64 requires libsoup-2.2.so.8()(64bit) seahorse-2.21.4-3.fc9.i386 requires libsoup-2.2.so.8 seahorse-2.21.4-3.fc9.x86_64 requires libsoup-2.2.so.8()(64bit) swfdec-gtk-0.5.5-2.fc9.i386 requires libsoup-2.2.so.8 swfdec-gtk-0.5.5-2.fc9.x86_64 requires libsoup-2.2.so.8()(64bit) totem-pl-parser-2.21.91-1.fc9.i386 requires libcamel-1.2.so.10 totem-pl-parser-2.21.91-1.fc9.x86_64 requires libcamel-1.2.so.10()(64bit) totem-publish-2.21.90-2.fc9.x86_64 requires libsoup-2.2.so.8()(64bit) twitux-0.60-2.fc9.x86_64 requires libsoup-2.2.so.8()(64bit) Broken deps for ppc ---------------------------------------------------------- PyQt-qscintilla-3.17.4-1.fc9.ppc requires libqscintilla.so.7 1:abiword-2.4.6-6.fc8.ppc requires libgoffice-1.so.2 anaconda-11.4.0.27-1.ppc requires dmidecode bmpx-0.40.13-7.fc9.ppc requires libsoup-2.2.so.8 1:bug-buddy-2.20.1-1.fc9.ppc requires libsoup-2.2.so.8 buoh-0.8.2-2.fc7.ppc requires libsoup-2.2.so.8 compiz-kde-0.6.2-6.fc9.ppc requires libkdecorations.so.1 crystal-1.0.5-1.fc8.ppc requires libkdecorations.so.1 dekorator-0.3-3.fc7.ppc requires libkdecorations.so.1 drivel-2.1.1-0.3.20071130svn.fc9.ppc requires libsoup-2.2.so.8 epiphany-extensions-2.20.1-3.fc9.ppc requires libgtkembedmoz.so epiphany-extensions-2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 evolution-brutus-1.1.28.7-2.fc8.ppc requires libcamel-1.2.so.10 evolution-brutus-1.1.28.7-2.fc8.ppc64 requires libcamel-1.2.so.10()(64bit) evolution-webcal-2.12.0-1.fc8.ppc requires libsoup-2.2.so.8 gnome-web-photo-0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo-0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo-0.3-8.fc9.ppc requires libgtkembedmoz.so gnome-web-photo-0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 hardinfo-0.4.2.3-1.fc9.ppc requires libsoup-2.2.so.8 kazehakase-0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 kicker-compiz-3.5.4-4.fc8.ppc requires libkickermain.so.1 kicker-compiz-3.5.4-4.fc8.ppc requires libtaskmanager.so.1 ksplash-engine-moodin-0.4.2-4.fc7.ppc requires libksplashthemes.so.0 libepc-0.3.3-1.fc9.ppc requires libsoup-2.2.so.8 libepc-0.3.3-1.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) libsyncml-0.4.5-1.fc9.ppc requires libsoup-2.2.so.8 libsyncml-0.4.5-1.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) libtranslate-0.99-12.fc9.ppc requires libsoup-2.2.so.8 libtranslate-0.99-12.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) 1:logjam-4.5.3-9.fc8.3.ppc requires libsoup-2.2.so.8 mail-notification-evolution-plugin-5.0-0.2.rc1.fc9.ppc requires libcamel-provider-1.2.so.10 mail-notification-evolution-plugin-5.0-0.2.rc1.fc9.ppc requires libcamel-1.2.so.10 monodevelop-0.17-4.fc9.ppc requires boo muine-0.8.8-6.fc9.ppc requires mono(muine-plugin) = 0:1.0.0.0 planner-eds-0.14.2-10.fc9.ppc requires libcamel-provider-1.2.so.10 planner-eds-0.14.2-10.fc9.ppc requires libcamel-1.2.so.10 rhythmbox-0.11.4-4.fc9.ppc requires libsoup-2.2.so.8 rhythmbox-0.11.4-4.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) seahorse-2.21.4-3.fc9.ppc requires libsoup-2.2.so.8 seahorse-2.21.4-3.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) swfdec-gtk-0.5.5-2.fc9.ppc requires libsoup-2.2.so.8 swfdec-gtk-0.5.5-2.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) totem-pl-parser-2.21.91-1.fc9.ppc requires libcamel-1.2.so.10 totem-pl-parser-2.21.91-1.fc9.ppc64 requires libcamel-1.2.so.10()(64bit) totem-publish-2.21.90-2.fc9.ppc requires libsoup-2.2.so.8 twitux-0.60-2.fc9.ppc requires libsoup-2.2.so.8 Broken deps for ppc64 ---------------------------------------------------------- PyQt-qscintilla-3.17.4-1.fc9.ppc64 requires libqscintilla.so.7()(64bit) 1:abiword-2.4.6-6.fc8.ppc64 requires libgoffice-1.so.2()(64bit) anaconda-11.4.0.27-1.ppc64 requires dmidecode bmpx-0.40.13-7.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) 1:bug-buddy-2.20.1-1.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) buoh-0.8.2-2.fc7.ppc64 requires libsoup-2.2.so.8()(64bit) crystal-1.0.5-1.fc8.ppc64 requires libkdecorations.so.1()(64bit) dekorator-0.3-3.fc7.ppc64 requires libkdecorations.so.1()(64bit) drivel-2.1.1-0.3.20071130svn.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) epiphany-extensions-2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) epiphany-extensions-2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 evolution-brutus-1.1.28.7-2.fc8.ppc64 requires libcamel-1.2.so.10()(64bit) evolution-webcal-2.12.0-1.fc8.ppc64 requires libsoup-2.2.so.8()(64bit) gnome-web-photo-0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) gnome-web-photo-0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo-0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo-0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) hardinfo-0.4.2.3-1.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) kazehakase-0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 kicker-compiz-3.5.4-4.fc8.ppc64 requires libkickermain.so.1()(64bit) kicker-compiz-3.5.4-4.fc8.ppc64 requires libtaskmanager.so.1()(64bit) ksplash-engine-moodin-0.4.2-4.fc7.ppc64 requires libksplashthemes.so.0()(64bit) libepc-0.3.3-1.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) libsyncml-0.4.5-1.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) libtranslate-0.99-12.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) 1:logjam-4.5.3-9.fc8.3.ppc64 requires libsoup-2.2.so.8()(64bit) mail-notification-evolution-plugin-5.0-0.2.rc1.fc9.ppc64 requires libcamel-1.2.so.10()(64bit) mail-notification-evolution-plugin-5.0-0.2.rc1.fc9.ppc64 requires libcamel-provider-1.2.so.10()(64bit) perl-Test-AutoBuild-darcs-1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 planner-eds-0.14.2-10.fc9.ppc64 requires libcamel-1.2.so.10()(64bit) planner-eds-0.14.2-10.fc9.ppc64 requires libcamel-provider-1.2.so.10()(64bit) rhythmbox-0.11.4-4.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) seahorse-2.21.4-3.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) swfdec-gtk-0.5.5-2.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) totem-pl-parser-2.21.91-1.fc9.ppc64 requires libcamel-1.2.so.10()(64bit) totem-publish-2.21.90-2.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) twitux-0.60-2.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) From lesmikesell at gmail.com Tue Jan 29 13:29:43 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 29 Jan 2008 07:29:43 -0600 Subject: long term support release In-Reply-To: <479ED923.8000202@gmail.com> References: <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <604aa7910801250150g3e2b6732we481ef783f83c240@mail.gmail.com> <4799ECB6.4070103@mindspring.com> <479ED923.8000202@gmail.com> Message-ID: <479F2A47.3030209@gmail.com> Andrew Farris wrote: >> >>> there needs to be some plan to actually make sure that >>> happens so we don't mislead users. A purpose and scope defined well >>> enough so that I can track some sort of performance metric. >>> >>> -jef >>> >> Does such a thing("some sort of performance metric") exist for Fedora >> itself? >> >> Richard > > That would be impossible... one cannot have a performance metric of > something so vague as a whole project this size (except in politics). If you can't measure something, how can you ever improve it - or know whether you did? -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Tue Jan 29 13:36:58 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 29 Jan 2008 07:36:58 -0600 Subject: long term support release In-Reply-To: <1201531237.3242.132.camel@beck.corsepiu.local> References: <1201058211.3001.79.camel@gandalf.cobite.com> <20080125112254.382c9e13@redhat.com> <479A190F.8010402@gmail.com> <200801251727.m0PHRe0O016727@laptop13.inf.utfsm.cl> <479A268B.5070201@gmail.com> <1201330199.17905.561.camel@beck.corsepiu.local> <200801270129.m0R1T0Eg000930@laptop13.inf.utfsm.cl> <1201410189.17905.709.camel@beck.corsepiu.local> <200801272221.m0RMLBhk010404@laptop13.inf.utfsm.cl> <1201500923.3242.95.camel@beck.corsepiu.local> <80d7e4090801280612y78d012e0h725ed35a3299c11c@mail.gmail.com> <1201531237.3242.132.camel@beck.corsepiu.local> Message-ID: <479F2BFA.7050303@gmail.com> Ralf Corsepius wrote: > Once again: My objective is improving usability, by eliminating bugs > ASAP, once you know about them. > > Fedora's bureacracy and work flow is are handicapping this by wasting > resources. This causes "current fedora" to be of "suboptimal quality" > and causes people to ask for "Fedora LTS". That's not the only reason. There are also the issues that it is not always a smooth upgrade from one version to another (which may not be practical to fix) and if you don't upgrade you are left without security fixes which isn't good for either the user or the perception of fedora's quality. -- Les Mikesell lesmikesell at gmail.com From lordmorgul at gmail.com Tue Jan 29 14:02:08 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Tue, 29 Jan 2008 06:02:08 -0800 Subject: long term support release In-Reply-To: <479F2A47.3030209@gmail.com> References: <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <604aa7910801250150g3e2b6732we481ef783f83c240@mail.gmail.com> <4799ECB6.4070103@mindspring.com> <479ED923.8000202@gmail.com> <479F2A47.3030209@gmail.com> Message-ID: <479F31E0.8060100@gmail.com> Les Mikesell wrote: > Andrew Farris wrote: > >>> >>>> there needs to be some plan to actually make sure that >>>> happens so we don't mislead users. A purpose and scope defined well >>>> enough so that I can track some sort of performance metric. >>>> >>>> -jef >>>> >>> Does such a thing("some sort of performance metric") exist for Fedora >>> itself? >>> >>> Richard >> >> That would be impossible... one cannot have a performance metric of >> something so vague as a whole project this size (except in politics). > > If you can't measure something, how can you ever improve it - or know > whether you did? You can't. Thats the point I was making. It is impossible to measure against a 'metric' thats not observable/quantifiable/finite. So Richard asks about measuring Fedora; can't be done. Commits/day to cvs, package changes, users logged into systems, bug reported, etc, are measurable. So is the number of random unrelated emails sent to devel-list per hour! (ah the irony of this reply existing itself, with mostly pointless drivel) -- Andrew Farris www.lordmorgul.net gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From mclasen at redhat.com Tue Jan 29 14:04:12 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 29 Jan 2008 09:04:12 -0500 Subject: some package splits Message-ID: <1201615452.2793.6.camel@localhost.localdomain> Last night I built a new evince, and since evince backends are modular now, I've split off the dvi and djvu backends as subpackages, evince-dvi and evince-djvu. This allows us to avoid the extra dependencies on the live cd that those backends would drag in. I've made the new subpackages installed by default in comps, but you may have to manually install them if you are updating from an older version of evince. Another package split is that there is now a poppler-glib (and -glib-devel) package. Please adjust your dependencies accordingly. Matthias From vonbrand at inf.utfsm.cl Tue Jan 29 14:11:16 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Tue, 29 Jan 2008 11:11:16 -0300 Subject: long term support release In-Reply-To: <34e52d0c0801281936n627db4f9j8bb8269bcba381b3@mail.gmail.com> References: <1201249426.14800.19.camel@cutter> <80d7e4090801261954r22de23dbgc660d60af780f194@mail.gmail.com> <80d7e4090801272005t6d542663rc99d616bef281589@mail.gmail.com> <80d7e4090801281542y561978acs41bccb857aa6de46@mail.gmail.com> <1201575406.7066.59.camel@cutter> <479E9986.6050209@gmail.com> <1201576549.7066.66.camel@cutter> <34e52d0c0801281936n627db4f9j8bb8269bcba381b3@mail.gmail.com> Message-ID: <200801291411.m0TEBGor005216@laptop13.inf.utfsm.cl> Randy Wyatt wrote: > There is a serious lack of understanding where Linux is, and where > most want it to be in this thread. A presumptive reboot does not > actually provide any benefit whatsoever, and in fact often exacerbates > situations. I work in situations where downtime is measured in the > millions of dollars per minute category, and we have never been able > to accept such requirements as provided by certain vendors such as HP > which mandated monthly downtime to install patches. I started out > with the presumptive reboot issue. It was hard enough to get > customers to agree to any modicum of a regular patch cycle. If a minute downtime is millions of USD, you surely can afford a few thousands to set up several machines and failover, soy you /can/ do the patching and rebooting without visible downtime. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From nphilipp at redhat.com Tue Jan 29 14:20:15 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 29 Jan 2008 15:20:15 +0100 Subject: some package splits In-Reply-To: <1201615452.2793.6.camel@localhost.localdomain> References: <1201615452.2793.6.camel@localhost.localdomain> Message-ID: <1201616415.2362.19.camel@gibraltar.str.redhat.com> On Tue, 2008-01-29 at 09:04 -0500, Matthias Clasen wrote: > Last night I built a new evince, and since evince backends are modular > now, I've split off the dvi and djvu backends as subpackages, evince-dvi > and evince-djvu. This allows us to avoid the extra dependencies on the > live cd that those backends would drag in. I've made the new subpackages > installed by default in comps, but you may have to manually install them > if you are updating from an older version of evince. How about the following to let this get handled by obsoletes ($version == (e-)v-r where you introduced the split). [...] Obsoletes: evince < $version Conflicts: evince < $version [...] %package dvi Obsoletes: evince < $version Conflicts: evince < $version [...] %package djvu Obsoletes: evince < $version Conflicts: evince < $version [...] This way, an existing old version of evince will get replaced by the triplet evince, evince-dvi and evince-djvu but new installations won't be affected --> no need for mentioning in the release ntoes. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From martin.sourada at gmail.com Tue Jan 29 14:22:10 2008 From: martin.sourada at gmail.com (Martin Sourada) Date: Tue, 29 Jan 2008 15:22:10 +0100 Subject: Suggestion: Use Liberation fonts as default in Firefox 3 In-Reply-To: <20080129114840.GA18536@jadzia.bu.edu> References: <6e24a8e80801280638q467ce226oeccce8b884c9f41b@mail.gmail.com> <48074.192.54.193.53.1201533207.squirrel@rousalka.dyndns.org> <20080129114840.GA18536@jadzia.bu.edu> Message-ID: <1201616530.14683.29.camel@pc-notebook> On Tue, 2008-01-29 at 06:48 -0500, Matthew Miller wrote: > On Mon, Jan 28, 2008 at 04:13:27PM +0100, Nicolas Mailhot wrote: > > P.S. Though you've still kept Serif as default Firefox family, which > > *is* an ass-backwards Firefox default we should change, since current > > screens do not have enough resolution to display satisfying Serif > > fonts. > > Mine sure does. > > > -- > Matthew Miller mattdm at mattdm.org > Boston University Linux ------> > I'd disagree with that unless you have access to HW I have not to, or unless you use really big font sizes. For normal usage serif fonts won't be fit for screens at usual sizes (8 - 12 pt) until good DPI will be used (100 dpi is surely not enough, I'd think >= 150 dpi could be enough though). But I agree with some of the people here, that this thread is about non-existent problem. Firefox should use system default (in my case 8 pt DejaVu Sans/Serif/Mono with the sans one being default) fonts when generic family and relative font size is specified in CSS stylesheet, which is currently not. I still wonder why firefox default font is 16 pt from serif family. System default is usually smaller (unless you have big monitor and sit far from it, or have bad sight) and the webpages just look strange... And yes, liberation is perfect substitution for Arial, but Arial is certainly not the best font out there (like Times it's fit rather for newspapers than for screen). DejaVu have quite good proportions, quite good Unicode coverage (which is being increased gradually) and work good with some other fonts which we install by default and which are substituted when the glyph is not in DejaVu present (like Sazanami font family for Japanese writers). Btw. the best fonts I've seen so far are the TeX fonts (computer modern family), but they are usually too complex for screen, but work excellent when printed... Anyway, what my 2 cents are: please use system wide font settings in firefox instead of its own preferences, it really is strange as it is now. It is not our goal to look like windows. We provide FLOSS fonts that everyone can install on their windows/macos machine, and we give web designers enough choice to make it possible for them to have webpages with very similar look on various platforms. It's their decision whether they want to use some specific font (which can be e.g. for Arial substituted by Liberation Sans in out environment) or whether they want their pages to use system wide font settings (and thus better integrate into desktop). Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From vonbrand at inf.utfsm.cl Tue Jan 29 14:23:59 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Tue, 29 Jan 2008 11:23:59 -0300 Subject: long term support release In-Reply-To: <1201531237.3242.132.camel@beck.corsepiu.local> References: <1201058211.3001.79.camel@gandalf.cobite.com> <20080125112254.382c9e13@redhat.com> <479A190F.8010402@gmail.com> <200801251727.m0PHRe0O016727@laptop13.inf.utfsm.cl> <479A268B.5070201@gmail.com> <1201330199.17905.561.camel@beck.corsepiu.local> <200801270129.m0R1T0Eg000930@laptop13.inf.utfsm.cl> <1201410189.17905.709.camel@beck.corsepiu.local> <200801272221.m0RMLBhk010404@laptop13.inf.utfsm.cl> <1201500923.3242.95.camel@beck.corsepiu.local> <80d7e4090801280612y78d012e0h725ed35a3299c11c@mail.gmail.com> <1201531237.3242.132.camel@beck.corsepiu.local> Message-ID: <200801291424.m0TENxuo005784@laptop13.inf.utfsm.cl> Ralf Corsepius wrote: > On Mon, 2008-01-28 at 07:12 -0700, Stephen John Smoogen wrote: [...] > > However, Linux is not cars. Each distro has its strengths and > > weaknesses. You seem to only see the weaknesses which has me > > questioning what you are trying to accomplish. > Once again: My objective is improving usability, OK. > by eliminating bugs > ASAP, That is /not/ the same as the objective... > once you know about them. > Fedora's bureacracy and work flow is are handicapping this by wasting > resources. What do you suggest to fix that? What do you feel is wasting resources? > This causes "current fedora" to be of "suboptimal quality" Without concrete examples and measurements, it is very hard to fix this. > and causes people to ask for "Fedora LTS". Non sequitur. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From vonbrand at inf.utfsm.cl Tue Jan 29 14:33:59 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Tue, 29 Jan 2008 11:33:59 -0300 Subject: long term support release In-Reply-To: <479ED923.8000202@gmail.com> References: <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <604aa7910801250150g3e2b6732we481ef783f83c240@mail.gmail.com> <4799ECB6.4070103@mindspring.com> <479ED923.8000202@gmail.com> Message-ID: <200801291434.m0TEXxWc006234@laptop13.inf.utfsm.cl> Andrew Farris wrote: > Richard Hally wrote: > > Jeff Spaleta wrote: > >> On Jan 25, 2008 12:35 AM, Patrice Dumas wrote: > > snip > > > >> there needs to be some plan to actually make sure that > >> happens so we don't mislead users. A purpose and scope defined well > >> enough so that I can track some sort of performance metric. > > Does such a thing("some sort of performance metric") exist for > > Fedora itself? > > Richard > That would be impossible... one cannot have a performance metric of > something so vague as a whole project this size (except in politics). /One/ perhaps not, but one can certainly think of several performance metrics: - Number of open bugs - Average time from opening to closing bugs - Number of active community developers (and other categories of contributors) And this is just off the top of my head, a more careful analysis will probably come up with others. As always, "performance metrics" should be tailored to measure performance, and for that you have to first agree what performance to measure. And that must come from the goals of the project (the Fedora distribution, in this case). Mostly you won't be able to measure performance directly, but measure variables that you know are related to the performance you want to kwon about. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From chasd at silveroaks.com Tue Jan 29 14:35:47 2008 From: chasd at silveroaks.com (chasd) Date: Tue, 29 Jan 2008 08:35:47 -0600 Subject: Yum, Proxy Cache Safety, Storage Backend In-Reply-To: <20080129033702.3593473239@hormel.redhat.com> References: <20080129033702.3593473239@hormel.redhat.com> Message-ID: Les Mikesell wrote: > This could work on a typical home network. In a larger office I'd > expect subneting and firewalling to block most auto-discovery > mechanisms > between a lot of machines that would still have fast internal > connections and share outbound internet traffic. My presumption is that an entity where servers are "difficult" ( SOHO, education ) also probably has a flat network topology for this to work. My target was a rpm installation that would enable this, so anyone could set it up without much other intervention. Shoot, it might work if you had several Fedora users at the same Starbucks. > Would there still be a > way to explicitly provide the dns name or IP address of the server in > this case? I thought about that a little bit. If there was a server on the same subnet, it could use the same discovery and retrieve any rpms it didn't have from the various client nodes. That way as nodes appeared and disappeared from the network, there would be some stability of the cached rpms available. You could make that server the default repo in yum.repos.d, so that if the mdns-avahi-Bonjour thingy didn't work or wasn't installed on a node, yum would have a fallback to a "regular" repo that had many cached files. If the network had subnets etc., then the client nodes would have to "phone home" to a server giving the server a list of its cached rpms because the server would not be able to discover all client nodes. The server could then compare the list on the client node with its own list and retrieve any it was missing. A scheduled rsync from the client to the server might work too. That same cron script could dump the client cache because those rpms would still be available on the local network from the server it pushed them to. Integrating a server into this idea was secondary from my point of view. There's a bit of work just to get the clients talking to each other, at least with my skill set. Charles Dostale From lesmikesell at gmail.com Tue Jan 29 14:40:51 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 29 Jan 2008 08:40:51 -0600 Subject: long term support release In-Reply-To: <200801291424.m0TENxuo005784@laptop13.inf.utfsm.cl> References: <1201058211.3001.79.camel@gandalf.cobite.com> <20080125112254.382c9e13@redhat.com> <479A190F.8010402@gmail.com> <200801251727.m0PHRe0O016727@laptop13.inf.utfsm.cl> <479A268B.5070201@gmail.com> <1201330199.17905.561.camel@beck.corsepiu.local> <200801270129.m0R1T0Eg000930@laptop13.inf.utfsm.cl> <1201410189.17905.709.camel@beck.corsepiu.local> <200801272221.m0RMLBhk010404@laptop13.inf.utfsm.cl> <1201500923.3242.95.camel@beck.corsepiu.local> <80d7e4090801280612y78d012e0h725ed35a3299c11c@mail.gmail.com> <1201531237.3242.132.camel@beck.corsepiu.local> <200801291424.m0TENxuo005784@laptop13.inf.utfsm.cl> Message-ID: <479F3AF3.8020805@gmail.com> Horst H. von Brand wrote: > > What do you suggest to fix that? What do you feel is wasting resources? > >> This causes "current fedora" to be of "suboptimal quality" > > Without concrete examples and measurements, it is very hard to fix this. So, how would you obtain the measurements, which are the obvious first step? Some sort of interactive poll, either on a web site or a program that posts the results. >> and causes people to ask for "Fedora LTS". > > Non sequitur. On the contrary, it follows perfectly from developers that don't know/care about the end user perception/experience. -- Les Mikesell lesmikesell at gmail.com From nicolas.mailhot at laposte.net Tue Jan 29 14:50:35 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 29 Jan 2008 15:50:35 +0100 (CET) Subject: Suggestion: Use Liberation fonts as default in Firefox 3 In-Reply-To: <1201616530.14683.29.camel@pc-notebook> References: <6e24a8e80801280638q467ce226oeccce8b884c9f41b@mail.gmail.com> <48074.192.54.193.53.1201533207.squirrel@rousalka.dyndns.org> <20080129114840.GA18536@jadzia.bu.edu> <1201616530.14683.29.camel@pc-notebook> Message-ID: <22814.192.54.193.53.1201618235.squirrel@rousalka.dyndns.org> Le Mar 29 janvier 2008 15:22, Martin Sourada a ?crit : > Btw. the best fonts I've seen so far are the TeX fonts (computer > modern family), BTW (2) the Computer Modern Unicode OTF-isation of the TEX fonts is on the fonts SIG wishlist, so interested packagers are welcome (requires checking upstream conversion scripts work on Fedora TEX and putting them in a spec wrapper) => http://fedoraproject.org/wiki/SIGs/Fonts/Triaging/Pipeline#head-0c095bcbdccc0685d2d3f25242e05f3e098237a6 Though they are a bit too gracile to work well on current computer screesn (but good as print fonts) -- Nicolas Mailhot From jkeating at redhat.com Tue Jan 29 15:23:07 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 29 Jan 2008 10:23:07 -0500 Subject: long term support release In-Reply-To: <200801291411.m0TEBGor005216@laptop13.inf.utfsm.cl> References: <1201249426.14800.19.camel@cutter> <80d7e4090801261954r22de23dbgc660d60af780f194@mail.gmail.com> <80d7e4090801272005t6d542663rc99d616bef281589@mail.gmail.com> <80d7e4090801281542y561978acs41bccb857aa6de46@mail.gmail.com> <1201575406.7066.59.camel@cutter> <479E9986.6050209@gmail.com> <1201576549.7066.66.camel@cutter> <34e52d0c0801281936n627db4f9j8bb8269bcba381b3@mail.gmail.com> <200801291411.m0TEBGor005216@laptop13.inf.utfsm.cl> Message-ID: <20080129102307.29d44666@redhat.com> On Tue, 29 Jan 2008 11:11:16 -0300 "Horst H. von Brand" wrote: > If a minute downtime is millions of USD, you surely can afford a few > thousands to set up several machines and failover, soy you /can/ do > the patching and rebooting without visible downtime. And testing of your failover system, and practicing emergency drills, and.... -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mcepl at redhat.com Tue Jan 29 15:29:37 2008 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 29 Jan 2008 16:29:37 +0100 Subject: Bug reporting HOWTO Message-ID: <1ct375xt8b.ln2@ppp1053.in.ipex.cz> While thinking about other threads on bug triaging etc. and while reading http://www.linuxindex.com/2008/01/18/bryce-harrington-bug-reporting-in-Ubuntu/ I wrote some list of things which might help users to write better bug reports (and us to get them solved more quickly). It is currently on http://fedoraproject.org/wiki/Matej_Cepl/Bug_Triage/Bug_reporting_HOWTO but I plan to move it to BugTriage category once I will get enough feedback to be happy with it. Would you please comment on this, what could be helpful, what is missing, and what should be removed? Thank you, Mat?j Cepl From mschwendt.tmp0701.nospam at arcor.de Tue Jan 29 15:36:54 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 29 Jan 2008 16:36:54 +0100 Subject: Request help with failing build: espeak In-Reply-To: <200801291502.40217.faucamp@csir.co.za> References: <200801291309.03176.faucamp@csir.co.za> <20080129134722.e59fd376.mschwendt.tmp0701.nospam@arcor.de> <200801291502.40217.faucamp@csir.co.za> Message-ID: <20080129163654.ed6a92e7.mschwendt.tmp0701.nospam@arcor.de> On Tue, 29 Jan 2008 15:02:40 +0200, Francois Aucamp wrote: > On Tuesday 29 January 2008 02:47:22 pm Michael Schwendt wrote: > > To me the new JACK in rawhide looks binary incompatible despite the > > unchanged SONAME. A very basic check shows that the two symbols from your > > build error are gone in Rawhide, and hence PortAudio ought to be updated: > > > > F-8: > > $ strings /usr/lib/libjack.so.0.0.23 | grep jack_port_.*lock > > jack_port_lock > > jack_port_unlock > > > > Rawhide: > > $ strings /usr/lib/libjack.so.0.0.28 | grep jack_port_.*lock > > $ > > Aah great, thanks. > > Bugzilla'd: > https://bugzilla.redhat.com/show_bug.cgi?id=430672 > abicheck (from koji or tomorrow's rawhide) shall find these again, too: $ abicheck /usr/lib/libportaudio.so.2 /usr/lib/libportaudio.so.2: PRIVATE: (libc.so.6:GLIBC_2.3.4) __vfprintf_chk /usr/lib/libportaudio.so.2: PRIVATE: (libc.so.6:GLIBC_2.4) __stack_chk_fail /usr/lib/libportaudio.so.2: PRIVATE: (libc.so.6:GLIBC_2.3.4) __sprintf_chk /usr/lib/libportaudio.so.2: PRIVATE: (libc.so.6:GLIBC_2.3.4) __snprintf_chk /usr/lib/libportaudio.so.2: PRIVATE: (libc.so.6:GLIBC_2.7) __open_2 /usr/lib/libportaudio.so.2: UNBOUND_SYMBOLS: 2 (run ldd -r on binary for more info) $ LD_DEBUG=bindings ldd -r /usr/lib/libportaudio.so.2 2>&1|grep undef 4569: /usr/lib/libportaudio.so.2: error: symbol lookup error: undefined symbol: jack_port_lock (continued) undefined symbol: jack_port_lock (/usr/lib/libportaudio.so.2) 4569: /usr/lib/libportaudio.so.2: error: symbol lookup error: undefined symbol: jack_port_unlock (continued) undefined symbol: jack_port_unlock (/usr/lib/libportaudio.so.2) From berrange at redhat.com Tue Jan 29 15:42:39 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 29 Jan 2008 15:42:39 +0000 Subject: Bug reporting HOWTO In-Reply-To: <1ct375xt8b.ln2@ppp1053.in.ipex.cz> References: <1ct375xt8b.ln2@ppp1053.in.ipex.cz> Message-ID: <20080129154238.GB23788@redhat.com> On Tue, Jan 29, 2008 at 04:29:37PM +0100, Matej Cepl wrote: > While thinking about other threads on bug triaging etc. and while > reading > http://www.linuxindex.com/2008/01/18/bryce-harrington-bug-reporting-in-Ubuntu/ > I wrote some list of things which might help users to write > better bug reports (and us to get them solved more quickly). It > is currently on > http://fedoraproject.org/wiki/Matej_Cepl/Bug_Triage/Bug_reporting_HOWTO > but I plan to move it to BugTriage category once I will get > enough feedback to be happy with it. I added a footnote about log files / data required for virtualization install related problems. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From lesmikesell at gmail.com Tue Jan 29 16:01:18 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 29 Jan 2008 10:01:18 -0600 Subject: long term support release In-Reply-To: <20080129102307.29d44666@redhat.com> References: <1201249426.14800.19.camel@cutter> <80d7e4090801261954r22de23dbgc660d60af780f194@mail.gmail.com> <80d7e4090801272005t6d542663rc99d616bef281589@mail.gmail.com> <80d7e4090801281542y561978acs41bccb857aa6de46@mail.gmail.com> <1201575406.7066.59.camel@cutter> <479E9986.6050209@gmail.com> <1201576549.7066.66.camel@cutter> <34e52d0c0801281936n627db4f9j8bb8269bcba381b3@mail.gmail.com> <200801291411.m0TEBGor005216@laptop13.inf.utfsm.cl> <20080129102307.29d44666@redhat.com> Message-ID: <479F4DCE.8080907@gmail.com> Jesse Keating wrote: > >> If a minute downtime is millions of USD, you surely can afford a few >> thousands to set up several machines and failover, soy you /can/ do >> the patching and rebooting without visible downtime. > > And testing of your failover system, and practicing emergency drills, > and.... What process transformed mid/end life FC3 and FC6 into very stable, reliable OS's very much like the subsequent RHEL cut? I can't be the only person who sees the difference at those points from the previous fedora versions. -- Les Mikesell lesmikesell at gmail.com From snecklifter at gmail.com Tue Jan 29 16:36:24 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Tue, 29 Jan 2008 16:36:24 +0000 Subject: bodhi 0.4.10 features In-Reply-To: <3g63xdw4oo.fsf@allele2.eebweb.arizona.edu> References: <20080127225406.GG3054@crow> <17951.1201497570@sss.pgh.pa.us> <479DDB33.3070002@ioa.s.u-tokyo.ac.jp> <479DDF73.2060305@ioa.s.u-tokyo.ac.jp> <20080128142835.GB2713@ryvius.greysector.net> <364d303b0801280742s767b6618yef71d58d923d2c5e@mail.gmail.com> <3g63xdw4oo.fsf@allele2.eebweb.arizona.edu> Message-ID: <364d303b0801290836t3761d01fr4e06017573a5b6fa@mail.gmail.com> On 29/01/2008, Alex Lancaster wrote: > >>>>> "CB" == Christopher Brown writes: > > [...] > > >> I also agree. It seems like overkill and increases the bug load > >> unless there are tools as suggested above. Sometimes a bug is > >> reported in F-7 but fixed in F-8 and there is nobody who can > >> investigate whether the F-8 fix works in F-7. Is it really > >> necessary to create a new bug just for that purpose? It's seems > >> better to move the bug to F-8, and push a new update for both > >> branches. If it doesn't fix things in the F-7 branch somebody will > >> re-open the bug. No big deal. > > CB> Actually it can be. Once a bug gets more than two or three people > CB> commenting and supplying feedback, things get awfully complicated > CB> and you end up in a situation where no-one knows what version > CB> someone is running and it becomes time-consuming to track back > CB> over closed bugs to review who is running what. > > [...] > > Agreed there are certainly many situations where you need to clone the > bug and have separate bugs for each branch, especially, as you note > for kernel bugs. I was simply arguing that it shouldn't be an > absolute hard requirement to create a new bug in every instance when a > bug is fixed in more than one branch. You are right. Splitting bugs in the first instance into three (7,8,rawhide) serves no purpose as we are not sure that all three versions have the bug. We cannot expect reporters or even maintainers to test against all versions either. Basically, Duplicating bugs into all three version - bad Closing of same version dupes - good Closing of different version dupes - discretion of maintainer/triager This is what I would like to see and what I have up until now been doing. Cheers -- Christopher Brown http://www.chruz.com From cra at WPI.EDU Tue Jan 29 17:06:55 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 29 Jan 2008 12:06:55 -0500 Subject: rpcbind forced userdel/groupdel on package install/upgrade? Message-ID: <20080129170655.GA24000@angus.ind.WPI.EDU> Why does rpcbind do this? Shouldn't usermod be used instead of userdel/useradd? It means on every single rpcbind package upgrade, the user is deleted and re-added. #rpm -q --scripts rpcbind preinstall scriptlet (using /bin/sh): # if the rpc uid and gid is left over from the portmapper # remove both of them. /usr/sbin/userdel rpc 2> /dev/null || : /usr/sbin/groupdel rpc 2> /dev/null || : # Now re-add the rpc uid/gid /usr/sbin/groupadd -g 32 rpc > /dev/null 2>&1 /usr/sbin/useradd -l -c "Rpcbind Daemon" -d /var/lib/rpcbind -g 32 \ -M -s /sbin/nologin -u 32 rpc > /dev/null 2>&1 postinstall scriptlet (using /bin/sh): /sbin/chkconfig --add rpcbind preuninstall scriptlet (using /bin/sh): if [ $1 -eq 0 ]; then service rpcbind stop > /dev/null 2>&1 /sbin/chkconfig --del rpcbind /usr/sbin/userdel rpc 2>/dev/null || : /usr/sbin/groupdel rpc 2>/dev/null || : rm -rf /var/lib/rpcbind fi postuninstall scriptlet (using /bin/sh): if [ "$1" -ge "1" ]; then service rpcbind condrestart > /dev/null 2>&1 fi From mschwendt.tmp0701.nospam at arcor.de Tue Jan 29 17:31:07 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 29 Jan 2008 18:31:07 +0100 Subject: ppc64 with strange symptoms Message-ID: <20080129183107.01de6cfc.mschwendt.tmp0701.nospam@arcor.de> ppc64 build once again failed while the other archs succeeded (I think last time that happened I just submitted another build request). In the modified abicheck test suite it gives different results for the same check: + ../abicheck ./private1 ./private1: OK + ../abicheck ./private1 ./private1: NO_BINDINGS (run ldd -r on binary for more info) + : + ../abicheck ./private1 + grep 'PRIVATE:.*libc.*\(__open\|__nanosleep\)' ./private1: PRIVATE: (libc.so.6:GLIBC_PRIVATE) __open_catalog + echo true true Only the last one is good. "private1" is a dynamically linked exe built in the step before these tests. abicheck is Perl and runs ldd/ld-linux to examine the exe. It's hard to debug this without access to a rawhide ppc64 machine. I'm going to use koji scratch builds (long response-times) to do a few more tests. I hope to find out what early runs of ldd or ld-linux say about the file. Perhaps somebody has an idea meanwhile as what may be special about ppc64. From buc at odusz.so-cdu.ru Tue Jan 29 17:41:51 2008 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Tue, 29 Jan 2008 20:41:51 +0300 Subject: Libsoup troubles in rawhide (compat-libsoup22 needed) Message-ID: <479F655F.2010000@odu.neva.ru> The new "libsoup" library in rawhide, version 2.3.0, introduces a lot of API incompatibility, comparing with the previous 2.2.x versions. There are even some design changes, hence it seems impossible for package maintainers to do "just a monkey job" of renaming functions etc. In my case of "libtranslate" (which depends on libsoup), it requires a deep upstream intervention (which, surely, was not in upstream's todo list...) It could be fine to have "libsoup22" or "compat-libsoup-2.2" package in rawhide. Regards, Dmitry Butskoy http:://www.fedoraproject.org/wiki/DmitryButskoy From kevin.kofler at chello.at Tue Jan 29 18:12:01 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 29 Jan 2008 18:12:01 +0000 (UTC) Subject: some package splits References: <1201615452.2793.6.camel@localhost.localdomain> <1201616415.2362.19.camel@gibraltar.str.redhat.com> Message-ID: Nils Philippsen redhat.com> writes: > [...] > Obsoletes: evince < $version > Conflicts: evince < $version > [...] > %package dvi > Obsoletes: evince < $version > Conflicts: evince < $version > [...] > %package djvu > Obsoletes: evince < $version > Conflicts: evince < $version > [...] > > This way, an existing old version of evince will get replaced by the > triplet evince, evince-dvi and evince-djvu but new installations won't > be affected --> no need for mentioning in the release ntoes. This doesn't really work: in practice, depsolvers will just pick an arbitrary one out of the 3 packages in such a situation, not all 3. Kevin Kofler From ville.skytta at iki.fi Tue Jan 29 18:16:15 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Tue, 29 Jan 2008 20:16:15 +0200 Subject: Request help with failing build: espeak In-Reply-To: <20080129134722.e59fd376.mschwendt.tmp0701.nospam@arcor.de> References: <200801291309.03176.faucamp@csir.co.za> <20080129134722.e59fd376.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <200801292016.16059.ville.skytta@iki.fi> On Tuesday 29 January 2008, Michael Schwendt wrote: > To me the new JACK in rawhide looks binary incompatible despite the > unchanged SONAME. A very basic check shows that the two symbols from your > build error are gone in Rawhide, and hence PortAudio ought to be updated: > > F-8: > $ strings /usr/lib/libjack.so.0.0.23 | grep jack_port_.*lock > jack_port_lock > jack_port_unlock > > Rawhide: > $ strings /usr/lib/libjack.so.0.0.28 | grep jack_port_.*lock > $ rpmsodiff confirms: $ rpmsodiff jack-audio-connection-kit-0.103.0-5.fc8.x86_64.rpm jack-audio-connection-kit-0.109.0-1.fc9.x86_64.rpm common sonames: libjack.so.0 /usr/lib64/libjack.so.0.0.23 /usr/lib64/libjack.so.0.0.28 [...] 2 symbols removed T jack_port_lock T jack_port_unlock 11 symbols added T jack_frames_to_time T jack_get_time T jack_port_get_aliases T jack_port_name_equals T jack_port_set_alias T jack_port_unset_alias T jack_recompute_total_latency T jack_set_client_registration_callback T jack_set_port_connect_callback T jack_thread_wait T jack_time_to_frames From smooge at gmail.com Tue Jan 29 18:19:03 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 29 Jan 2008 11:19:03 -0700 Subject: long term support release In-Reply-To: <1201531237.3242.132.camel@beck.corsepiu.local> References: <1201058211.3001.79.camel@gandalf.cobite.com> <200801251727.m0PHRe0O016727@laptop13.inf.utfsm.cl> <479A268B.5070201@gmail.com> <1201330199.17905.561.camel@beck.corsepiu.local> <200801270129.m0R1T0Eg000930@laptop13.inf.utfsm.cl> <1201410189.17905.709.camel@beck.corsepiu.local> <200801272221.m0RMLBhk010404@laptop13.inf.utfsm.cl> <1201500923.3242.95.camel@beck.corsepiu.local> <80d7e4090801280612y78d012e0h725ed35a3299c11c@mail.gmail.com> <1201531237.3242.132.camel@beck.corsepiu.local> Message-ID: <80d7e4090801291019k372f9c50v1244131a79324245@mail.gmail.com> On Jan 28, 2008 7:40 AM, Ralf Corsepius wrote: > > On Mon, 2008-01-28 at 07:12 -0700, Stephen John Smoogen wrote: > > On Jan 27, 2008 11:15 PM, Ralf Corsepius wrote: > > > > > > > > In my experience, they end getting fixed by moving forward. > > > > > > > > > A bug is only fixed if it takes place in the current release. > > > > > > > > Strange definition of bug fix. > > > What's strange about this? In real-life manufacturers will be sued for > > > "not fixing bugs in a current release" - Avoiding such situations is > > > called "customer care". > > > > > > Customer: "Garage, when I turn on my car's head lights, the heating > > > starts running at full power." > > > Garage : "We reported it upstream to the car's manufacturer. You might > > > try the next model available at your local dealer next year. Until then, > > > open the windows." > > > > > > > I think most of us have misparsed your original comment to be: > > > > Customer: "Garage, when I turn on my car's head lights, the heating > > starts running at full power." > > > > Garage : "You need to get the latest car. Otherwise we can't fix it." > > > > However, Linux is not cars. Each distro has its strengths and > > weaknesses. You seem to only see the weaknesses which has me > > questioning what you are trying to accomplish. > > Once again: My objective is improving usability, by eliminating bugs > ASAP, once you know about them. > Then think about how you are communicating. Many of your posts are coming across as a curmudgeon, stick-in-the-mud, or mister negativity. Improvement requires carrots and vision more than whips.. and your salting wounds about mistakes made 3 years ago does not make people want to change. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From mschwendt.tmp0701.nospam at arcor.de Tue Jan 29 18:27:20 2008 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 29 Jan 2008 19:27:20 +0100 Subject: ppc64 with strange symptoms In-Reply-To: <20080129183107.01de6cfc.mschwendt.tmp0701.nospam@arcor.de> References: <20080129183107.01de6cfc.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20080129192720.0aa8ca4b.mschwendt.tmp0701.nospam@arcor.de> Fixed in CVS. From smooge at gmail.com Tue Jan 29 18:26:30 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 29 Jan 2008 11:26:30 -0700 Subject: long term support release In-Reply-To: <479F2A47.3030209@gmail.com> References: <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <604aa7910801250150g3e2b6732we481ef783f83c240@mail.gmail.com> <4799ECB6.4070103@mindspring.com> <479ED923.8000202@gmail.com> <479F2A47.3030209@gmail.com> Message-ID: <80d7e4090801291026y39f9fc6ex2b196997a9b5459e@mail.gmail.com> On Jan 29, 2008 6:29 AM, Les Mikesell wrote: > Andrew Farris wrote: > > >> > >>> there needs to be some plan to actually make sure that > >>> happens so we don't mislead users. A purpose and scope defined well > >>> enough so that I can track some sort of performance metric. > >>> > >>> -jef > >>> > >> Does such a thing("some sort of performance metric") exist for Fedora > >> itself? > >> > >> Richard > > > > That would be impossible... one cannot have a performance metric of > > something so vague as a whole project this size (except in politics). > > If you can't measure something, how can you ever improve it - or know > whether you did? > Wow management zen. Or as my boss once said "If you fart in your cubicle at lunch, does it smell?" You can only measure such large scale items with various statistical shenanigans. You are having to deal with multiple projects, multiple codebases and interactions that are probably on the order of 2^64 or greater. At which point you can only try to come up with the entropy of the entire system.. but with the inaccuracy that you are measuring from within the system and not outside. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From mrmazda at ij.net Tue Jan 29 18:32:19 2008 From: mrmazda at ij.net (Felix Miata) Date: Tue, 29 Jan 2008 13:32:19 -0500 Subject: Bug reporting HOWTO In-Reply-To: <1ct375xt8b.ln2@ppp1053.in.ipex.cz> References: <1ct375xt8b.ln2@ppp1053.in.ipex.cz> Message-ID: <479F7133.4060704@ij.net> On 2008/01/29 16:29 (GMT+0100) Matej Cepl apparently typed: > http://fedoraproject.org/wiki/Matej_Cepl/Bug_Triage/Bug_reporting_HOWTO > but I plan to move it to BugTriage category once I will get > enough feedback to be happy with it. > Would you please comment on this, what could be helpful, what is > missing, and what should be removed? The Anaconda page it refers to is deficient too, so including some of its missing information might help. http://fedoraproject.org/wiki/Anaconda/BugReporting refers to a problem I run into more than not trying to install anything post-F7. Only once have I succeeded in installing post-F7 (F8). At least 20 other tries failed anywhere from stage1 to stage3. On those systems only installing F6 or F7 works, requiring Yum upgrades to get to F8 or Rawhide. So, I'd like to look at that Anaconda log(s) myself, and maybe file bug(s) about these recurring failures. But, I have lots of broken and unreliable legacy devices (floppies), and no remote hosts ready to accept uploads. I do have plenty USB chips and hard disk partitions ready to accept log files. Why are there no buttons on the crash screen to upload the logs to a hard disk partition or memory stick? Does "Save to Floppy" really mean something else? If so, where's the doc? -- "In the beginning was the Word, and the Word was with God, and the Word was God." John 1:1 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/ From smooge at gmail.com Tue Jan 29 18:33:42 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 29 Jan 2008 11:33:42 -0700 Subject: long term support release In-Reply-To: <479F4DCE.8080907@gmail.com> References: <1201249426.14800.19.camel@cutter> <80d7e4090801281542y561978acs41bccb857aa6de46@mail.gmail.com> <1201575406.7066.59.camel@cutter> <479E9986.6050209@gmail.com> <1201576549.7066.66.camel@cutter> <34e52d0c0801281936n627db4f9j8bb8269bcba381b3@mail.gmail.com> <200801291411.m0TEBGor005216@laptop13.inf.utfsm.cl> <20080129102307.29d44666@redhat.com> <479F4DCE.8080907@gmail.com> Message-ID: <80d7e4090801291033y6bb0826amc49ed4882278780f@mail.gmail.com> On Jan 29, 2008 9:01 AM, Les Mikesell wrote: > Jesse Keating wrote: > > > >> If a minute downtime is millions of USD, you surely can afford a few > >> thousands to set up several machines and failover, soy you /can/ do > >> the patching and rebooting without visible downtime. > > > > And testing of your failover system, and practicing emergency drills, > > and.... > > What process transformed mid/end life FC3 and FC6 into very stable, > reliable OS's very much like the subsequent RHEL cut? I can't be the > only person who sees the difference at those points from the previous > fedora versions. > Nothing did. EL-4 and EL-5 were cut from pre-releases of FC3 and FC6... not mid/end-life versions. Fixes in final FC3/6 were pushed upstream and vice versa but the 2 diverged in a yellow wood at least a month before FC3 or 6 were released. So by the time FC3 and 6 were released EL-4 and EL-5 was already set in stone. You can get FC3/6 stuff to work on an EL-4/5 box but only to an extent. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From jspaleta at gmail.com Tue Jan 29 18:56:33 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 29 Jan 2008 09:56:33 -0900 Subject: long term support release In-Reply-To: <80d7e4090801291026y39f9fc6ex2b196997a9b5459e@mail.gmail.com> References: <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <604aa7910801250150g3e2b6732we481ef783f83c240@mail.gmail.com> <4799ECB6.4070103@mindspring.com> <479ED923.8000202@gmail.com> <479F2A47.3030209@gmail.com> <80d7e4090801291026y39f9fc6ex2b196997a9b5459e@mail.gmail.com> Message-ID: <604aa7910801291056p2ae52268qebb2df91a30483b6@mail.gmail.com> On Jan 29, 2008 9:26 AM, Stephen John Smoogen wrote: > Wow management zen. Or as my boss once said "If you fart in your > cubicle at lunch, does it smell?" You can only measure such large > scale items with various statistical shenanigans. You are having to > deal with multiple projects, multiple codebases and interactions that > are probably on the order of 2^64 or greater. At which point you can > only try to come up with the entropy of the entire system.. but with > the inaccuracy that you are measuring from within the system and not > outside. I'm looking for metrics that I can use later for "put up or shut up" moments. If subprojects are sufficiently narrow in scope.. if they go well I can beat the drums a bit in praise of the community for stepping up and expanding what we are doing in a specific area and hold that up as a success for other involvement. If it doesn't go well, I can beat the drums a bit and find all those community people who wanted to see that area grow and challenge them to make it happen and to support the community leader who stepped up to lead that area. If someone steps up to lead an area, I want to have some goals and indicators identified so an effort doesn't languish in some unhealthy state without some way for the Board or other group to step in and try to make a positive impact when needed. -jef From pmachata at redhat.com Tue Jan 29 19:04:09 2008 From: pmachata at redhat.com (Petr Machata) Date: Tue, 29 Jan 2008 20:04:09 +0100 Subject: nasm 2.01 Message-ID: <479F78A9.6000200@redhat.com> Hi, I've done a rebase of nasm to 2.01. It should hit rawhide shortly. Packagers of packages that depend on nasm may consider rebuild, although I believe it shouldn't be necessary. Feedback welcome. Thanks, PM -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From lesmikesell at gmail.com Tue Jan 29 19:08:48 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 29 Jan 2008 13:08:48 -0600 Subject: long term support release In-Reply-To: <80d7e4090801291033y6bb0826amc49ed4882278780f@mail.gmail.com> References: <1201249426.14800.19.camel@cutter> <80d7e4090801281542y561978acs41bccb857aa6de46@mail.gmail.com> <1201575406.7066.59.camel@cutter> <479E9986.6050209@gmail.com> <1201576549.7066.66.camel@cutter> <34e52d0c0801281936n627db4f9j8bb8269bcba381b3@mail.gmail.com> <200801291411.m0TEBGor005216@laptop13.inf.utfsm.cl> <20080129102307.29d44666@redhat.com> <479F4DCE.8080907@gmail.com> <80d7e4090801291033y6bb0826amc49ed4882278780f@mail.gmail.com> Message-ID: <479F79C0.7060006@gmail.com> Stephen John Smoogen wrote: >>>> If a minute downtime is millions of USD, you surely can afford a few >>>> thousands to set up several machines and failover, soy you /can/ do >>>> the patching and rebooting without visible downtime. >>> And testing of your failover system, and practicing emergency drills, >>> and.... >> What process transformed mid/end life FC3 and FC6 into very stable, >> reliable OS's very much like the subsequent RHEL cut? I can't be the >> only person who sees the difference at those points from the previous >> fedora versions. >> > > Nothing did. EL-4 and EL-5 were cut from pre-releases of FC3 and > FC6... not mid/end-life versions. Fixes in final FC3/6 were pushed > upstream and vice versa but the 2 diverged in a yellow wood at least a > month before FC3 or 6 were released. So by the time FC3 and 6 were > released EL-4 and EL-5 was already set in stone. You can get FC3/6 > stuff to work on an EL-4/5 box but only to an extent. So there were no actual metrics or systematic processes used to transform the buggy FC2 and FC4/5 releases into the fairly usable FC3/FC6 versions? That's hard to believe, and especially that it just happened to converge with the RHEL releases - unless it is the fixes from the RHEL beta process simply overwhelming the normal fedora updates and forcing stability. And as for differences between FC6 and RHEL5, I thought that the Centos group reported that some binaries were not even rebuilt from their FC6 versions. Did I miss something there? -- Les Mikesell lesmikesell at gmail.com From jos at xos.nl Tue Jan 29 19:07:23 2008 From: jos at xos.nl (Jos Vos) Date: Tue, 29 Jan 2008 20:07:23 +0100 Subject: Joomla and Fedora Message-ID: <200801291907.m0TJ7Nqk003511@jasmine.xos.nl> Hi, Is there a technical and/or political reason why Joomla isn't packaged for Fedora? Or is it just that nobody has asked for it and/or nobody was interested in packaging it? -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From tcallawa at redhat.com Tue Jan 29 19:09:45 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 29 Jan 2008 14:09:45 -0500 Subject: Joomla and Fedora In-Reply-To: <200801291907.m0TJ7Nqk003511@jasmine.xos.nl> References: <200801291907.m0TJ7Nqk003511@jasmine.xos.nl> Message-ID: <1201633785.3573.4.camel@localhost.localdomain> On Tue, 2008-01-29 at 20:07 +0100, Jos Vos wrote: > Hi, > > Is there a technical and/or political reason why Joomla isn't > packaged for Fedora? > > Or is it just that nobody has asked for it and/or nobody was > interested in packaging it? There certainly isn't a political reason. :) I can't speak for technical reasons, as I'm not very familiar with Joomla. ~spot From lemenkov at gmail.com Tue Jan 29 19:19:12 2008 From: lemenkov at gmail.com (Peter Lemenkov) Date: Tue, 29 Jan 2008 22:19:12 +0300 Subject: Joomla and Fedora In-Reply-To: <200801291907.m0TJ7Nqk003511@jasmine.xos.nl> References: <200801291907.m0TJ7Nqk003511@jasmine.xos.nl> Message-ID: 2008/1/29, Jos Vos : > Hi, > > Is there a technical and/or political reason why Joomla isn't > packaged for Fedora? > > Or is it just that nobody has asked for it and/or nobody was > interested in packaging it? Correct. Feel free to create new review request. -- With best regards! From lemenkov at gmail.com Tue Jan 29 19:23:55 2008 From: lemenkov at gmail.com (Peter Lemenkov) Date: Tue, 29 Jan 2008 22:23:55 +0300 Subject: How to contact Jeff Ollie? Message-ID: Hello All! Sorry for the buzz but I tried to contact Jeff via email, but seems that he didn't noticed my mails (evil spam filter maybe?). I need to ask him about his plans for the rtpproxy. -- With best regards! From mmcgrath at redhat.com Tue Jan 29 19:26:06 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 29 Jan 2008 13:26:06 -0600 (CST) Subject: How to contact Jeff Ollie? In-Reply-To: References: Message-ID: He's pretty active in #fedora-admin on irc.freenode.net, you might be able to contact him there. -Mike On Tue, 29 Jan 2008, Peter Lemenkov wrote: > Hello All! > > Sorry for the buzz but I tried to contact Jeff via email, but seems > that he didn't noticed my mails (evil spam filter maybe?). > > I need to ask him about his plans for the rtpproxy. > > -- > With best regards! > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From lemenkov at gmail.com Tue Jan 29 19:35:12 2008 From: lemenkov at gmail.com (Peter Lemenkov) Date: Tue, 29 Jan 2008 22:35:12 +0300 Subject: How to contact Jeff Ollie? In-Reply-To: References: Message-ID: 2008/1/29, Mike McGrath : > He's pretty active in #fedora-admin on irc.freenode.net, you might be able > to contact him there. Heh, I never used IRC in my life (except for downloading so-called "illegal" mp3z in #efnet via selfmade scripts ~7-10 years ago). OK, I'll try to install some client for this oldskool chat system. -- With best regards! From jakub.rusinek at gmail.com Tue Jan 29 19:33:55 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Tue, 29 Jan 2008 20:33:55 +0100 Subject: How to contact Jeff Ollie? In-Reply-To: References: Message-ID: <1201635235.6811.1.camel@geeko> > Heh, I never used IRC in my life (except for downloading so-called > "illegal" mp3z in #efnet via selfmade scripts ~7-10 years ago). OK, > I'll try to install some client for this oldskool chat system. It's not so oldschool ;) . Try Google Groups - it's nice interface for REALLY oldschool chat system :> . -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? wiadomo?ci podpisana cyfrowo URL: From jspaleta at gmail.com Tue Jan 29 19:40:46 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 29 Jan 2008 10:40:46 -0900 Subject: bodhi 0.4.10 features In-Reply-To: <364d303b0801290836t3761d01fr4e06017573a5b6fa@mail.gmail.com> References: <20080127225406.GG3054@crow> <479DDB33.3070002@ioa.s.u-tokyo.ac.jp> <479DDF73.2060305@ioa.s.u-tokyo.ac.jp> <20080128142835.GB2713@ryvius.greysector.net> <364d303b0801280742s767b6618yef71d58d923d2c5e@mail.gmail.com> <3g63xdw4oo.fsf@allele2.eebweb.arizona.edu> <364d303b0801290836t3761d01fr4e06017573a5b6fa@mail.gmail.com> Message-ID: <604aa7910801291140g51cda137ta5f19818587bd851@mail.gmail.com> On Jan 29, 2008 7:36 AM, Christopher Brown wrote: > You are right. Splitting bugs in the first instance into three > (7,8,rawhide) serves no purpose as we are not sure that all three > versions have the bug. We cannot expect reporters or even maintainers > to test against all versions either. Basically, > > Duplicating bugs into all three version - bad > Closing of same version dupes - good > Closing of different version dupes - discretion of maintainer/triager > > This is what I would like to see and what I have up until now been doing. I wish we could just set the fedora release version as flags on a bug. And then when closing it fixed, you essentially unset the flag for the release version you know it was fixed for. This would give users a way to know its been fixed but it needs to be confirmed on the remaining flagged releases. -jef From jspaleta at gmail.com Tue Jan 29 19:50:56 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 29 Jan 2008 10:50:56 -0900 Subject: some package splits In-Reply-To: <1201615452.2793.6.camel@localhost.localdomain> References: <1201615452.2793.6.camel@localhost.localdomain> Message-ID: <604aa7910801291150g6996e432y2b225995fc9ce2fe@mail.gmail.com> On Jan 29, 2008 5:04 AM, Matthias Clasen wrote: > Last night I built a new evince, and since evince backends are modular > now, I've split off the dvi and djvu backends as subpackages, evince-dvi > and evince-djvu. This allows us to avoid the extra dependencies on the > live cd that those backends would drag in. I've made the new subpackages > installed by default in comps, but you may have to manually install them > if you are updating from an older version of evince. I love it. I personally have a need for the dvi backend..but I don't want to force other people to suffer it..especially not targetted livecd usages. But I have a general question. The dvi subpackage is set as default in comps, so anyone installing evince on an installed system without it(very rare) will get the subpackages too. Do we have a facility for livecd users who do an install to harddisk to gobble up default subpackages for an application that would have been installed from the network, instead of installing from a livecd? Would this sort of thing make sense? I could see an argument for it. I could imagine positioning this sort of feature like this: "Due to limitations of CD image sizes, this livecd image is missing some optional application functionality. We do our best to pack as much functionality as we can into a CD, but there is so much great open software that we can't fit it all in. If you choose to install to the harddrive, you will get the option to install this missing optional functionality so that you can enjoy an enhanced application experience made possible by the larger storage capacity of your harddrive" -jef From vonbrand at inf.utfsm.cl Tue Jan 29 20:10:34 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Tue, 29 Jan 2008 17:10:34 -0300 Subject: long term support release In-Reply-To: <479F3AF3.8020805@gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <20080125112254.382c9e13@redhat.com> <479A190F.8010402@gmail.com> <200801251727.m0PHRe0O016727@laptop13.inf.utfsm.cl> <479A268B.5070201@gmail.com> <1201330199.17905.561.camel@beck.corsepiu.local> <200801270129.m0R1T0Eg000930@laptop13.inf.utfsm.cl> <1201410189.17905.709.camel@beck.corsepiu.local> <200801272221.m0RMLBhk010404@laptop13.inf.utfsm.cl> <1201500923.3242.95.camel@beck.corsepiu.local> <80d7e4090801280612y78d012e0h725ed35a3299c11c@mail.gmail.com> <1201531237.3242.132.camel@beck.corsepiu.local> <200801291424.m0TENxuo005784@laptop13.inf.utfsm.cl> <479F3AF3.8020805@gmail.com> Message-ID: <200801292010.m0TKAYKO010641@laptop13.inf.utfsm.cl> Les Mikesell wrote: > Horst H. von Brand wrote: > > What do you suggest to fix that? What do you feel is wasting > > resources? > >> This causes "current fedora" to be of "suboptimal quality" > > Without concrete examples and measurements, it is very hard to fix > > this. > So, how would you obtain the measurements, which are the obvious first > step? Some sort of interactive poll, either on a web site or a > program that posts the results. Fedora can look at Bugzilla logs, download logs (specially about updates), access to their webpages, monitor what "the press" says, ... No need for a (very unreliable!) "please answer this webpage's poll, if you happen to wander this way and feel like it". > >> and causes people to ask for "Fedora LTS". > > Non sequitur. > On the contrary, it follows perfectly from developers that don't > know/care about the end user perception/experience. Even worse. If the perception is that "developers don't care", why would the perception about some LTS /handled by the same volunteers as a sideline/ be any better? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From vonbrand at inf.utfsm.cl Tue Jan 29 20:15:06 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Tue, 29 Jan 2008 17:15:06 -0300 Subject: long term support release In-Reply-To: <479F31E0.8060100@gmail.com> References: <604aa7910801222159s630a344bs46e6ed96ae860965@mail.gmail.com> <604aa7910801231016n7b3dc039q719f52a4a80a0cef@mail.gmail.com> <1201113331.17905.65.camel@beck.corsepiu.local> <1201118147.6218.99.camel@cutter> <1201240697.17905.179.camel@beck.corsepiu.local> <20080125081620.GA2750@free.fr> <1201249426.14800.19.camel@cutter> <20080125090850.GC2750@free.fr> <604aa7910801250126o10c0ce15k5db19cc248473560@mail.gmail.com> <20080125093517.GA16080@free.fr> <604aa7910801250150g3e2b6732we481ef783f83c240@mail.gmail.com> <4799ECB6.4070103@mindspring.com> <479ED923.8000202@gmail.com> <479F2A47.3030209@gmail.com> <479F31E0.8060100@gmail.com> Message-ID: <200801292015.m0TKF6B5010858@laptop13.inf.utfsm.cl> Andrew Farris wrote: > Les Mikesell wrote: [...] > > If you can't measure something, how can you ever improve it - or > > know whether you did? > You can't. Thats the point I was making. It is impossible to measure > against a 'metric' thats not observable/quantifiable/finite. True. > So > Richard asks about measuring Fedora; can't be done. Many things can be measured, the trick is to select things that /can/ be measured that (reliably!) tell something about what you want to know. > Commits/day to > cvs, package changes, users logged into systems, bug reported, etc, > are measurable. So is the number of random unrelated emails sent to > devel-list per hour! Right. Which ones tell you something worthwhile? > (ah the irony of this reply existing itself, with mostly pointless > drivel) Nodz ;-) -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From silfreed at silfreed.net Tue Jan 29 20:23:53 2008 From: silfreed at silfreed.net (Douglas E. Warner) Date: Tue, 29 Jan 2008 15:23:53 -0500 Subject: Koji build error (f8-x86_64): Missing Dependency: tcl = 1:8.4.15 is needed by package tk Message-ID: <200801291523.54126.silfreed@silfreed.net> On the following build: http://koji.fedoraproject.org/koji/taskinfo?taskID=382592 I'm getting this error in my root.log: http://koji.fedoraproject.org/koji/getfile?taskID=382601&name=root.log DEBUG util.py:261: Error: Missing Dependency: tcl = 1:8.4.15 is needed by package tk This built fine in mock on my local server; any ideas? -Doug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From opensource at till.name Tue Jan 29 20:34:58 2008 From: opensource at till.name (Till Maas) Date: Tue, 29 Jan 2008 21:34:58 +0100 Subject: bodhi 0.4.10 features In-Reply-To: <604aa7910801291140g51cda137ta5f19818587bd851@mail.gmail.com> References: <20080127225406.GG3054@crow> <364d303b0801290836t3761d01fr4e06017573a5b6fa@mail.gmail.com> <604aa7910801291140g51cda137ta5f19818587bd851@mail.gmail.com> Message-ID: <200801292135.03084.opensource@till.name> On Tue January 29 2008, Jeff Spaleta wrote: > I wish we could just set the fedora release version as flags on a bug. > And then when closing it fixed, you essentially unset the flag for > the release version you know it was fixed for. This would give users > a way to know its been fixed but it needs to be confirmed on the > remaining flagged releases. Yeah, or use Keyswords or the Status/QA Whiteboard. Afaik, the Whiteboards can be used with arbitrary content, so we only need to agree on a set of strings for this, e.g. FixedFX (when it is fixed already or was never an issue), FX (when it is present in FX) and no mentioning of any FX to show that nobody knows. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From lesmikesell at gmail.com Tue Jan 29 20:41:44 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 29 Jan 2008 14:41:44 -0600 Subject: long term support release In-Reply-To: <200801292010.m0TKAYKO010641@laptop13.inf.utfsm.cl> References: <1201058211.3001.79.camel@gandalf.cobite.com> <20080125112254.382c9e13@redhat.com> <479A190F.8010402@gmail.com> <200801251727.m0PHRe0O016727@laptop13.inf.utfsm.cl> <479A268B.5070201@gmail.com> <1201330199.17905.561.camel@beck.corsepiu.local> <200801270129.m0R1T0Eg000930@laptop13.inf.utfsm.cl> <1201410189.17905.709.camel@beck.corsepiu.local> <200801272221.m0RMLBhk010404@laptop13.inf.utfsm.cl> <1201500923.3242.95.camel@beck.corsepiu.local> <80d7e4090801280612y78d012e0h725ed35a3299c11c@mail.gmail.com> <1201531237.3242.132.camel@beck.corsepiu.local> <200801291424.m0TENxuo005784@laptop13.inf.utfsm.cl> <479F3AF3.8020805@gmail.com> <200801292010.m0TKAYKO010641@laptop13.inf.utfsm.cl> Message-ID: <479F8F88.2090203@gmail.com> Horst H. von Brand wrote: > >> So, how would you obtain the measurements, which are the obvious first >> step? Some sort of interactive poll, either on a web site or a >> program that posts the results. > > Fedora can look at Bugzilla logs, download logs (specially about updates), > access to their webpages, monitor what "the press" says, ... No need for a > (very unreliable!) "please answer this webpage's poll, if you happen to > wander this way and feel like it". I'd venture a guess that a large majority of user issues do not result in a bugzilla entry. New users in particular will just try some other disto or go back to whatever they used before if they have a problem - and many usability issues may not be actual bugs. But if you don't believe a user understands his own experience enough to report it given a venue friendlier than bugzilla, how can you hope to improve it? >>>> and causes people to ask for "Fedora LTS". > >>> Non sequitur. > >> On the contrary, it follows perfectly from developers that don't >> know/care about the end user perception/experience. > > Even worse. If the perception is that "developers don't care", why would > the perception about some LTS /handled by the same volunteers as a > sideline/ be any better? A realistic perception of how often you should expect major problems like updates that won't boot on a variety of hardware, sound not working, firewire issues, etc. would be good for everyone and some metric to show real progress would be more meaningful than someone just saying "oh, this is getting better now" with nothing to back it up. -- Les Mikesell lesmikesell at gmail.com From lordmorgul at gmail.com Tue Jan 29 20:54:00 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Tue, 29 Jan 2008 12:54:00 -0800 Subject: Bug reporting HOWTO In-Reply-To: <479F7133.4060704@ij.net> References: <1ct375xt8b.ln2@ppp1053.in.ipex.cz> <479F7133.4060704@ij.net> Message-ID: <479F9268.5060008@gmail.com> Felix Miata wrote: > So, I'd like to look at that Anaconda log(s) myself, and maybe file bug(s) > about these recurring failures. But, I have lots of broken and unreliable > legacy devices (floppies), and no remote hosts ready to accept uploads. I do > have plenty USB chips and hard disk partitions ready to accept log files. Why > are there no buttons on the crash screen to upload the logs to a hard disk > partition or memory stick? Does "Save to Floppy" really mean something else? > If so, where's the doc? Thats unfortunately not in anaconda, though some changes to that screen sound like a good idea to me. What you can do is switch to vt2 (anaconda is on vt1) and work with the shell there. Create a directory, mount the usb flash there, and copy logs off that way. The logs end up in a different spot than /var/log since its not working in the chroot at that point, but I don't remember at the moment where the files are.. poking around should let you find it, anaconda.log and some others. -- Andrew Farris www.lordmorgul.net gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From kwade at redhat.com Tue Jan 29 21:40:48 2008 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Tue, 29 Jan 2008 13:40:48 -0800 Subject: your release notes for F9 alpha Message-ID: <1201642848.5621.216.camel@calliope.phig.org> The one-page release notes for Fedora 9 alpha is ready for your notes: http://fedoraproject.org/wiki/Releases/9/Alpha/ReleaseNotes == Background == This one-page release notes is produced for the alpha and beta releases of Fedora, living on the wiki for last minute additions. The first draft of the real release notes ("beta relnotes") are produced for the first release after the distro beta, such as RC1. Beta relnotes are compiled, produced, and translated for at least one testing cycle of a release to ensure accuracy for the final Fedora release. -- Karsten Wade, Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From alexl at users.sourceforge.net Tue Jan 29 21:59:59 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Tue, 29 Jan 2008 14:59:59 -0700 Subject: Libsoup troubles in rawhide (compat-libsoup22 needed) In-Reply-To: <479F655F.2010000@odu.neva.ru> (Dmitry Butskoy's message of "Tue\, 29 Jan 2008 20\:41\:51 +0300") References: <479F655F.2010000@odu.neva.ru> Message-ID: >>>>> "DB" == Dmitry Butskoy writes: DB> The new "libsoup" library in rawhide, version 2.3.0, introduces a DB> lot of API incompatibility, comparing with the previous 2.2.x DB> versions. There are even some design changes, hence it seems DB> impossible for package maintainers to do "just a monkey job" of DB> renaming functions etc. In my case of "libtranslate" (which DB> depends on libsoup), it requires a deep upstream intervention DB> (which, surely, was not in upstream's todo list...) DB> It could be fine to have "libsoup22" or "compat-libsoup-2.2" DB> package in rawhide. Not to mention the fact that this major soname ABI/API bump was not announced in advance! The maintainer should have posted at least a day or so in advance to fedora-devel-announce-list to warn packagers in advance of the major change (which would have allowed discussion of the possibility of the necessity of introducing compat-libsoup type package). Here's the full list of packages broken either directly or indirectly by this change: (from http://koji.fedoraproject.org/mash/rawhide-20080129/logs/depcheck) bmpx-0.40.13-7.fc9.i386 requires libsoup-2.2.so.8 1:bug-buddy-2.20.1-1.fc9.i386 requires libsoup-2.2.so.8 buoh-0.8.2-2.fc7.i386 requires libsoup-2.2.so.8 drivel-2.1.1-0.3.20071130svn.fc9.i386 requires libsoup-2.2.so.8 evolution-brutus-1.1.28.7-2.fc8.i386 requires libcamel-1.2.so.10 evolution-webcal-2.12.0-1.fc8.i386 requires libsoup-2.2.so.8 hardinfo-0.4.2.3-1.fc9.i386 requires libsoup-2.2.so.8 libepc-0.3.3-1.fc9.i386 requires libsoup-2.2.so.8 libsyncml-0.4.5-1.fc9.i386 requires libsoup-2.2.so.8 libtranslate-0.99-12.fc9.i386 requires libsoup-2.2.so.8 1:logjam-4.5.3-9.fc8.3.i386 requires libsoup-2.2.so.8 mail-notification-evolution-plugin-5.0-0.2.rc1.fc9.i386 requires libcamel-provider-1.2.so.10 mail-notification-evolution-plugin-5.0-0.2.rc1.fc9.i386 requires libcamel-1.2.so.10 planner-eds-0.14.2-10.fc9.i386 requires libcamel-provider-1.2.so.10 planner-eds-0.14.2-10.fc9.i386 requires libcamel-1.2.so.10 rhythmbox-0.11.4-4.fc9.i386 requires libsoup-2.2.so.8 seahorse-2.21.4-3.fc9.i386 requires libsoup-2.2.so.8 swfdec-gtk-0.5.5-2.fc9.i386 requires libsoup-2.2.so.8 totem-pl-parser-2.21.91-1.fc9.i386 requires libcamel-1.2.so.10 totem-publish-2.21.90-2.fc9.i386 requires libsoup-2.2.so.8 twitux-0.60-2.fc9.i386 requires libsoup-2.2.so.8 Alex From lsof at nodata.co.uk Tue Jan 29 22:21:19 2008 From: lsof at nodata.co.uk (nodata) Date: Tue, 29 Jan 2008 23:21:19 +0100 Subject: F9 for Eeepc In-Reply-To: References: <479A650D.8060401@cora.nwra.com> <1201304569.2057.22.camel@localhost.localdomain> <645d17210801251629y2811f3f7jf0886a166ffd2f8@mail.gmail.com> <479E7137.5020705@cora.nwra.com> Message-ID: <1201645279.2868.2.camel@sb-home> Am Montag, den 28.01.2008, 19:54 -0500 schrieb Jon Nettleton: > On Jan 28, 2008 7:20 PM, Orion Poplawski wrote: > > Jonathan Underwood wrote: > > > On 25/01/2008, John (J5) Palmieri wrote: > > >> On Fri, 2008-01-25 at 15:39 -0700, Orion Poplawski wrote: > > >> > > >>> - Flash drive. Want to minimize writes. One attempt (eeedora) uses the > > >>> ext2 filesystem rather than ext3. Does that help? Are there things to > > >>> take from stateless projects for minimizing writes to /var? > > >>> > > >> jffs2 is what we use on the OLPC, there is another FS in the works that > > >> is a lot better for large flash though. I forget the name. On modern > > >> flash you don't have to worry about rewrites as much though since the > > >> hardware randomizes writes. What kills the disk on older flash drives > > >> is writing to the journal in Ext3 and writing to the FAT on Fat disks. > > >> Both of those are fixed locations which stress out a small portion of > > >> the disk. Each flash device has only so many writes per bit before that > > >> bit dies. By distributing it over the whole disk it takes a lot longer > > >> to destroy. I would check the specs on the flash drive that came with > > >> the Eee. Another thing you might want to do is not have a swap > > >> partition. Apps run fine without swap, you just might run into OOM more > > >> frequently. > > >> > > > > > > The eeepc drive has a FTL, so these drives don't appear as flash > > > drives to the OS, so jffs, yaffs, logfs and the like aren't applicable > > > to the eeepc, as I understand it. > > > > The drive appears as a standard IDE drive. dmesg reports the drive as a > > "SILICONMOTION SM223AC". Google doesn't seem to turn up much other > > than users' reports on their eeePC :-). > > > > For other eeepc users I just wanted to mention that I hacked on > devilspie to include matching on the geometry attributes of a window. > Long story short you can use it now to say if a window is taller than > 480 pixels you can either set it to resize smaller or maximize > vertically. > > This still doesn't work for dialog's yet, I am looking at gtk and a > few other places that I might hack around fixes to make them fit on > the small resolution better. > > Jon > Cool :) From mdehaan at redhat.com Tue Jan 29 23:01:48 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 29 Jan 2008 18:01:48 -0500 Subject: Debian style net-install ISOs (from FudCON Raleigh) Message-ID: <479FB05C.30302@redhat.com> At Matt Domsch's talk at FudCON some of us got into an interesting tangent. Fedora could really use Debian style net install ISOs. For those unfamiliar with the concept ... assume a minimally sized image that is enough to start up a net install for all content. Now imagine the bandwidth savings -- you're not downloading anything you don't need. For most Debian users I knew, this is the way we always installed systems. Imagine something like the rescue image (heck, this is only a slight tweak) with the following modifications: 1. a kickstart file on it that is set up for a network installation (everything else interactive) 2. the kernel options pre-modified to use that kickstart file 3. the network install source of a tree on download.fedoraproject.org (which is geoip magic) 4. and yum repos for updates (so installs can be done to updated content) that understand how to use yum mirror lists. (only the last part (4) seems to require any sort of software change) Currently I am not aware of the ability to express mirror lists in a kickstart file (pykickstart doesn't like em?) but I know Anaconda can do this. Debian actually had you enter in what mirror you wanted (I always picked kernel.org), but we probably have a even smarter solution with download.fedoraproject.org. What else do we need to get this going and hosted? I imagine the bandwidth savings for Fedora could be huge, but even more so, the users in bandwidth-constrained environments wouldn't have to download a full DVD (not even DVD 1) to get going. Thoughts? --Michael From tibbs at math.uh.edu Tue Jan 29 23:25:54 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 29 Jan 2008 17:25:54 -0600 Subject: Debian style net-install ISOs (from FudCON Raleigh) In-Reply-To: <479FB05C.30302@redhat.com> References: <479FB05C.30302@redhat.com> Message-ID: >>>>> "MD" == Michael DeHaan writes: MD> Fedora could really use Debian style net install ISOs. It's strange to see that, because I've never done a Fedora install any way other than how you describe. Even on my home machines, over a cable modem. So, I guess whatever changes are required must be pretty simple since this already works. I suppose you could improve ease of use by eliminating the need to type in a couple of URLs. - J< From cmadams at hiwaay.net Tue Jan 29 23:34:27 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 29 Jan 2008 17:34:27 -0600 Subject: Debian style net-install ISOs (from FudCON Raleigh) In-Reply-To: <479FB05C.30302@redhat.com> References: <479FB05C.30302@redhat.com> Message-ID: <20080129233427.GA1290738@hiwaay.net> Once upon a time, Michael DeHaan said: > Imagine something like the rescue image (heck, this is only a slight > tweak) with the following modifications: Really it is just adding the base and updates URLs; that's all that is different. Instead of a kickstart, maybe just have anaconda suggest the standard mirrorlist URLs for HTTP/FTP installs. > I imagine the bandwidth savings for Fedora could be huge Doubtful. That DVD download is usually used more than once, while all network installs will always download a whole lot of stuff each time. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jreiser at BitWagon.com Tue Jan 29 23:40:16 2008 From: jreiser at BitWagon.com (John Reiser) Date: Tue, 29 Jan 2008 15:40:16 -0800 Subject: Debian style net-install ISOs (from FudCON Raleigh) In-Reply-To: <479FB05C.30302@redhat.com> References: <479FB05C.30302@redhat.com> Message-ID: <479FB960.9070107@BitWagon.com> > Fedora could really use Debian style net install ISOs. > > For those unfamiliar with the concept ... assume a minimally sized image > that is enough to start up a net install for all content. Please devote some thought and implementation towards recovery, so that re-starting a net install doesn't waste most of the previous downloading. The big advantage of physical media (CDs, DVDs, USB flash memory devices) is that the bits typically survive more than one install. -- From katzj at redhat.com Tue Jan 29 23:41:50 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 29 Jan 2008 18:41:50 -0500 Subject: Debian style net-install ISOs (from FudCON Raleigh) In-Reply-To: <479FB05C.30302@redhat.com> References: <479FB05C.30302@redhat.com> Message-ID: <1201650110.6274.13.camel@aglarond.local> On Tue, 2008-01-29 at 18:01 -0500, Michael DeHaan wrote: > Fedora could really use Debian style net install ISOs. You do realize that the rescuecd can already basically be used in this fashion? And that's one of the reasons that in Fedora 9, we've been planning to rename that image. Also, with the work that clumens has been doing, we'll be able to delay repository selection in that case until you get to the second stage. Which will then give the ability to do things like using mirrorlists, proxies, etc. Jeremy From lesmikesell at gmail.com Wed Jan 30 00:10:56 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 29 Jan 2008 18:10:56 -0600 Subject: Debian style net-install ISOs (from FudCON Raleigh) In-Reply-To: <20080129233427.GA1290738@hiwaay.net> References: <479FB05C.30302@redhat.com> <20080129233427.GA1290738@hiwaay.net> Message-ID: <479FC090.6060808@gmail.com> Chris Adams wrote: > Once upon a time, Michael DeHaan said: >> Imagine something like the rescue image (heck, this is only a slight >> tweak) with the following modifications: > > Really it is just adding the base and updates URLs; that's all that is > different. Instead of a kickstart, maybe just have anaconda suggest the > standard mirrorlist URLs for HTTP/FTP installs. > >> I imagine the bandwidth savings for Fedora could be huge > > Doubtful. That DVD download is usually used more than once, while all > network installs will always download a whole lot of stuff each time. Reasonable proxy behavior would mostly fix that. But, it's hard to beat an rsync or bitorrent download of an image to an nfs-exported directory followed by an nfs install. -- Les Mikesell lesmikesell at gmail.com From jreiser at BitWagon.com Wed Jan 30 00:34:16 2008 From: jreiser at BitWagon.com (John Reiser) Date: Tue, 29 Jan 2008 16:34:16 -0800 Subject: Debian style net-install ISOs (from FudCON Raleigh) In-Reply-To: <479FC090.6060808@gmail.com> References: <479FB05C.30302@redhat.com> <20080129233427.GA1290738@hiwaay.net> <479FC090.6060808@gmail.com> Message-ID: <479FC608.8070908@BitWagon.com> Les Mikesell wrote: > Chris Adams wrote: > >> Once upon a time, Michael DeHaan said: >>> I imagine the bandwidth savings for Fedora could be huge >> >> >> Doubtful. That DVD download is usually used more than once, while all >> network installs will always download a whole lot of stuff each time. > > > Reasonable proxy behavior would mostly fix that. A base + software development install for x86 is about 3GB on disk, or 1.5GB on install media. Many proxies don't cache that much, so the savings usually are not so large. -- From davidsonpaulo at gmail.com Wed Jan 30 01:01:26 2008 From: davidsonpaulo at gmail.com (Davidson Rodrigues Paulo) Date: Tue, 29 Jan 2008 23:01:26 -0200 Subject: Debian style net-install ISOs (from FudCON Raleigh) In-Reply-To: <20080129233427.GA1290738@hiwaay.net> References: <479FB05C.30302@redhat.com> <20080129233427.GA1290738@hiwaay.net> Message-ID: 2008/1/29, Chris Adams : > > I imagine the bandwidth savings for Fedora could be huge > > Doubtful. That DVD download is usually used more than once, while all > network installs will always download a whole lot of stuff each time. What about optionally generate an installation media, at the end of the install process, containing all packages downloaded? It would be an interesting feature, would it be useful? How hard would be to integrate revisor in Anaconda? -- Davidson Paulo http://fedoraproject.org/wiki/DavidsonPaulo From lesmikesell at gmail.com Wed Jan 30 01:18:46 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 29 Jan 2008 19:18:46 -0600 Subject: Debian style net-install ISOs (from FudCON Raleigh) In-Reply-To: <479FC608.8070908@BitWagon.com> References: <479FB05C.30302@redhat.com> <20080129233427.GA1290738@hiwaay.net> <479FC090.6060808@gmail.com> <479FC608.8070908@BitWagon.com> Message-ID: <479FD076.2000600@gmail.com> John Reiser wrote: > Les Mikesell wrote: >> Chris Adams wrote: >> >>> Once upon a time, Michael DeHaan said: >>>> I imagine the bandwidth savings for Fedora could be huge >>> >>> Doubtful. That DVD download is usually used more than once, while all >>> network installs will always download a whole lot of stuff each time. >> >> Reasonable proxy behavior would mostly fix that. > > A base + software development install for x86 is about 3GB on disk, > or 1.5GB on install media. Many proxies don't cache that much, > so the savings usually are not so large. If you do this sort of thing regularly, it is worth configuring a proxy to cache large files. -- Les Mikesell lesmikesell at gmail.com From smooge at gmail.com Wed Jan 30 01:39:38 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 29 Jan 2008 18:39:38 -0700 Subject: long term support release In-Reply-To: <479F79C0.7060006@gmail.com> References: <1201249426.14800.19.camel@cutter> <1201575406.7066.59.camel@cutter> <479E9986.6050209@gmail.com> <1201576549.7066.66.camel@cutter> <34e52d0c0801281936n627db4f9j8bb8269bcba381b3@mail.gmail.com> <200801291411.m0TEBGor005216@laptop13.inf.utfsm.cl> <20080129102307.29d44666@redhat.com> <479F4DCE.8080907@gmail.com> <80d7e4090801291033y6bb0826amc49ed4882278780f@mail.gmail.com> <479F79C0.7060006@gmail.com> Message-ID: <80d7e4090801291739k4061a4a4s6abd63fff1091bd0@mail.gmail.com> On Jan 29, 2008 12:08 PM, Les Mikesell wrote: > Stephen John Smoogen wrote: > > >>>> If a minute downtime is millions of USD, you surely can afford a few > >>>> thousands to set up several machines and failover, soy you /can/ do > >>>> the patching and rebooting without visible downtime. > >>> And testing of your failover system, and practicing emergency drills, > >>> and.... > >> What process transformed mid/end life FC3 and FC6 into very stable, > >> reliable OS's very much like the subsequent RHEL cut? I can't be the > >> only person who sees the difference at those points from the previous > >> fedora versions. > >> > > > > Nothing did. EL-4 and EL-5 were cut from pre-releases of FC3 and > > FC6... not mid/end-life versions. Fixes in final FC3/6 were pushed > > upstream and vice versa but the 2 diverged in a yellow wood at least a > > month before FC3 or 6 were released. So by the time FC3 and 6 were > > released EL-4 and EL-5 was already set in stone. You can get FC3/6 > > stuff to work on an EL-4/5 box but only to an extent. > > So there were no actual metrics or systematic processes used to > transform the buggy FC2 and FC4/5 releases into the fairly usable > FC3/FC6 versions? That's hard to believe, and especially that it just > happened to converge with the RHEL releases - unless it is the fixes > from the RHEL beta process simply overwhelming the normal fedora updates I have no idea. Those are internal processes to Red Hat. Personally I found FC2 and EL-4 to be more stable than FC3 which was why I moved over to EL-4 until last year. > and forcing stability. And as for differences between FC6 and RHEL5, I > thought that the Centos group reported that some binaries were not even > rebuilt from their FC6 versions. Did I miss something there? > No you are correct about some packages not being recompiled. Some of the final packages were FC6 final packages, but the branching of many packages occured before FC6 was finalized. So the kernel, glibc, X, etc were very different than say inn or xorg-x11-filesystem which has supposedly not been recompiled ofr FC7 or FC8. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From stickster at gmail.com Wed Jan 30 02:28:17 2008 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 29 Jan 2008 21:28:17 -0500 Subject: Libsoup troubles in rawhide (compat-libsoup22 needed) In-Reply-To: References: <479F655F.2010000@odu.neva.ru> Message-ID: <1201660097.25209.24.camel@localhost.localdomain> On Tue, 2008-01-29 at 14:59 -0700, Alex Lancaster wrote: > >>>>> "DB" == Dmitry Butskoy writes: > > DB> The new "libsoup" library in rawhide, version 2.3.0, introduces a > DB> lot of API incompatibility, comparing with the previous 2.2.x > DB> versions. There are even some design changes, hence it seems > DB> impossible for package maintainers to do "just a monkey job" of > DB> renaming functions etc. In my case of "libtranslate" (which > DB> depends on libsoup), it requires a deep upstream intervention > DB> (which, surely, was not in upstream's todo list...) > > DB> It could be fine to have "libsoup22" or "compat-libsoup-2.2" > DB> package in rawhide. > > Not to mention the fact that this major soname ABI/API bump was not > announced in advance! The maintainer should have posted at least a > day or so in advance to fedora-devel-announce-list to warn packagers > in advance of the major change (which would have allowed discussion of > the possibility of the necessity of introducing compat-libsoup type > package). I'm not the maintainer of libsoup. But I own one of the broken packages (drivel). A cursory look -- by which I mean "asking people who I'm sure would know" ;-) -- tells me there's no written policy on this in the wiki to which maintainers should refer. If there truly isn't one, and people feel there should be, I humbly suggest those people should document the policy on the wiki in the generally accepted manner. While I personally believe in bending over backward to inform everyone about these changes well in advance, a policy is less dependent on personal predilections. :-) /me goes off to figure out how the heck to fix his package now. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From lordmorgul at gmail.com Wed Jan 30 02:43:35 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Tue, 29 Jan 2008 18:43:35 -0800 Subject: Debian style net-install ISOs (from FudCON Raleigh) In-Reply-To: References: <479FB05C.30302@redhat.com> <20080129233427.GA1290738@hiwaay.net> Message-ID: <479FE457.8080200@gmail.com> Davidson Rodrigues Paulo wrote: > 2008/1/29, Chris Adams : >>> I imagine the bandwidth savings for Fedora could be huge >> Doubtful. That DVD download is usually used more than once, while all >> network installs will always download a whole lot of stuff each time. > > What about optionally generate an installation media, at the end of > the install process, containing all packages downloaded? It would be > an interesting feature, would it be useful? How hard would be to > integrate revisor in Anaconda? > Anaconda and first boot have enough issues, adding an attempt to burn the downloaded files might be a bit ridiculous. I wouldn't mind if they cached them all post install in an easy to access way though, and let you then burn it once the machine is up and running. You have a kickstart file already created from the choices you made during install, and all the files should be there to work with. But doing it integrated in anaconda is probably not such a good idea, installs fail often enough as is. -- Andrew Farris www.lordmorgul.net gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From mclasen at redhat.com Wed Jan 30 02:44:14 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 29 Jan 2008 21:44:14 -0500 Subject: Libsoup troubles in rawhide (compat-libsoup22 needed) In-Reply-To: <1201660097.25209.24.camel@localhost.localdomain> References: <479F655F.2010000@odu.neva.ru> <1201660097.25209.24.camel@localhost.localdomain> Message-ID: <1201661054.2779.7.camel@localhost.localdomain> On Tue, 2008-01-29 at 21:28 -0500, Paul W. Frields wrote: > I'm not the maintainer of libsoup. But I own one of the broken packages > (drivel). A cursory look -- by which I mean "asking people who I'm sure > would know" ;-) -- tells me there's no written policy on this in the > wiki to which maintainers should refer. If there truly isn't one, and > people feel there should be, I humbly suggest those people should > document the policy on the wiki in the generally accepted manner. While > I personally believe in bending over backward to inform everyone about > these changes well in advance, a policy is less dependent on personal > predilections. :-) Dan really went out of his way to handle the api breakage as well as possible. He had patches for all affected gnome packages before even doing the 2.3.0 release, and he has only made the release after the Gnome release team strongly encouraged him to get libsoup 2.4 into Gnome 2.22. He has also provided a patch for libtranslate by now, and I'm sure he will be happy to help other package maintainers that are affected by this. From jkeating at redhat.com Wed Jan 30 02:35:40 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 29 Jan 2008 21:35:40 -0500 Subject: Fedora 9 Alpha delayed just a bit longer Message-ID: <20080129213540.0fac261f@redhat.com> Due to some production issues, we're not going to be able to stage the Alpha for mirrors in time for a Thursday release. Therefor we will be delaying the release until Tuesday the 5th. We are not taking in new builds, just giving the mirrors more time to sync up. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From jspaleta at gmail.com Wed Jan 30 03:11:41 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 29 Jan 2008 18:11:41 -0900 Subject: Libsoup troubles in rawhide (compat-libsoup22 needed) In-Reply-To: <1201661054.2779.7.camel@localhost.localdomain> References: <479F655F.2010000@odu.neva.ru> <1201660097.25209.24.camel@localhost.localdomain> <1201661054.2779.7.camel@localhost.localdomain> Message-ID: <604aa7910801291911p19acd675yaa7951c60948497c@mail.gmail.com> On Jan 29, 2008 5:44 PM, Matthias Clasen wrote: > He has also provided a patch for libtranslate by now, and I'm sure he > will be happy to help other package maintainers that are affected > by this. I think the only issue here is the issue of best effort notice. It's really nice to give people a heads up on the list so people with deps can brace for impact. Some of them might have even done some local test building ahead of it going live in rawhide. I wouldn't push to make this a requirement, but I'd like to encourage a culture where we voluntarily agree to give a heads up to other maintainers when we can in situations where know upgrades cause abi/api changes that affect other packages. You dont have to go as far as what was done with the impending gcc change, but i would hold up the effort made there as being a nearly perfect way to handle such a widespread issue. For single libraries, it would be great to give one or two days notice before it becomes available in rawhide and if possible a koji scratch build of it for maintainers to use in local testing. -jef"i really don't want to have to lay down all the ways we can be nice to each other as strict policy. I'd rather just ask individuals to be excellent to one other and trust them to do their best with regard to communicating"spaleta From eswierk at arastra.com Wed Jan 30 03:18:55 2008 From: eswierk at arastra.com (Ed Swierk) Date: Tue, 29 Jan 2008 19:18:55 -0800 Subject: InstantMirror needs a rethink In-Reply-To: References: <4797D5B3.7030002@redhat.com> <479880CB.8020300@leemhuis.info> Message-ID: After spending some time examining http-replicator I think that it's a much better foundation for further development of InstantMirror features than mod_python is. Running as a standalone daemon lets it handle concurrent requests more naturally. As a bonus, http-replicator supports upstream ftp servers as well as http, and deals with byte-range requests properly (more properly than InstantMirror does, at least). Unlike InstantMirror, the current http-replicator implements a traditional http proxy rather than a transparent proxy. It was pretty easy to hack in a new --mirror option that lets it support either mode. With the attached patch (applied atop http-replicator_4.0alpha1), http-replicator acts as a drop-in replacement for InstantMirror: ./http-replicator --port 80 --root /mirrors --mirror http://download.fedora.redhat.com --nohost --daemon mirror.log If this works for someone besides me, I'll submit the patch to the http-replicator maintainer. --Ed -------------- next part -------------- A non-text attachment was scrubbed... Name: http-replicator_4.0alpha1_mirror.patch Type: text/x-diff Size: 4135 bytes Desc: not available URL: From wtogami at redhat.com Wed Jan 30 03:19:58 2008 From: wtogami at redhat.com (Warren Togami) Date: Tue, 29 Jan 2008 22:19:58 -0500 Subject: InstantMirror needs a rethink In-Reply-To: References: <4797D5B3.7030002@redhat.com> <479880CB.8020300@leemhuis.info> Message-ID: <479FECDE.9090405@redhat.com> Hi Ed, Why don't you submit this as a Fedora RPM for review? Warren From jkeating at redhat.com Wed Jan 30 03:29:13 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 29 Jan 2008 22:29:13 -0500 Subject: Libsoup troubles in rawhide (compat-libsoup22 needed) In-Reply-To: <604aa7910801291911p19acd675yaa7951c60948497c@mail.gmail.com> References: <479F655F.2010000@odu.neva.ru> <1201660097.25209.24.camel@localhost.localdomain> <1201661054.2779.7.camel@localhost.localdomain> <604aa7910801291911p19acd675yaa7951c60948497c@mail.gmail.com> Message-ID: <20080129222913.4d5ca38b@redhat.com> On Tue, 29 Jan 2008 18:11:41 -0900 "Jeff Spaleta" wrote: > to be excellent to one other Party on Jeff. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From aron at hp.com Wed Jan 30 04:37:09 2008 From: aron at hp.com (Aron Griffis) Date: Tue, 29 Jan 2008 23:37:09 -0500 Subject: updated cross-gcc rpm Message-ID: <20080130043709.GI3836@fc.hp.com> [sorry for the dups, third try w/ fedora-devel-list subscribed] Hi Lennert, Referring to your post at http://www.redhat.com/archives/fedora-devel-list/2007-October/msg00045.html Thanks a lot for posting those rpms. I was able to use those with --define='cross_target ia64-linux-gnu' to build a cross-compiler that builds xen-unstable.hg including the userland tools. I posted that information today to the xen-devel mailing list, see http://lists.xensource.com/archives/html/xen-devel/2008-01/msg01105.html I had to make some changes, first to build the gcc rpm successfully on x86_64 targetting ia64, and second to include some files that were missing. The missing files were due to %ifarch tests which were looking at the build arch instead of the target arch. I came up with a solution for that... though I wouldn't be surprised if you're able to come up with something more elegant. The patch is below. Thanks again for your work which enabled me to get this running. Aron diff -r 8c95cc711df2 SPECS/gcc41.spec --- a/SPECS/gcc41.spec Fri Jan 18 08:51:45 2008 -0500 +++ b/SPECS/gcc41.spec Wed Jan 30 02:56:35 2008 +0000 @@ -1,8 +1,10 @@ %if "%{?cross_target}" == "" %define gcc_target %{_target_platform} +%define target_arch %{_arch} %define isnative 1 %else %define gcc_target %{cross_target} +%define target_arch %{expand:%%(echo "%{cross_target}" | sed 's/-.*//')} %define isnative 0 %define cross %{gcc_target}- %define crosspost -%{gcc_target} @@ -12,6 +14,8 @@ %define __find_requires %{nil} %define __find_provides %{nil} %endif + +%define inlist() %{expand:%%(case '%* ' in (%{1}*' '%1' '*) echo 1 ;; (*) echo 0 ;; esac)} %define DATE 20070925 %define gcc_version 4.1.2 @@ -1234,6 +1238,7 @@ rm -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/ rm -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/{libffi*,libiberty.a} rm -f $RPM_BUILD_ROOT%{_prefix}/%{gcc_target_platform}/%{_lib}/{libffi*,libiberty.a} rm -f $FULLEPATH/install-tools/{mkheaders,fixincl} +rm -f $FULLPATH/install-tools/mkheaders.conf rm -f $RPM_BUILD_ROOT%{_prefix}/lib/{32,64}/libiberty.a rm -f $RPM_BUILD_ROOT%{_prefix}/%{_lib}/libssp* rm -f $FULLPATH/libssp* @@ -1428,8 +1433,7 @@ fi %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/syslimits.h %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/unwind.h %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/omp.h -%if %{isnative} -%ifarch %{ix86} x86_64 +%if %{inlist %{target_arch} %{ix86} x86_64} %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/mmintrin.h %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/xmmintrin.h %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/emmintrin.h @@ -1439,14 +1443,13 @@ fi %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/mm_malloc.h %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/mm3dnow.h %endif -%ifarch ia64 +%if %{inlist %{target_arch} ia64} %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/ia64intrin.h %endif -%ifarch ppc ppc64 +%if %{inlist %{target_arch} ppc ppc64} %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/ppc-asm.h %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/altivec.h %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/spe.h -%endif %endif %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/include/README %{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_version}/collect2 @@ -1458,8 +1461,7 @@ fi %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libgomp.spec %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libgomp.a %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libgomp.so -%if %{isnative} -%ifarch sparc ppc +%if %{inlist %{target_arch} sparc ppc} %dir %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/64 %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/64/crt*.o %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/64/libgcc.a @@ -1473,7 +1475,7 @@ fi %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/64/libmudflap.so %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/64/libmudflapth.so %endif -%ifarch %{multilib_64_archs} +%if %{inlist %{target_arch} %{multilib_64_archs}} %dir %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/32 %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/32/crt*.o %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/32/libgcc.a @@ -1487,12 +1489,13 @@ fi %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/32/libmudflap.so %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/32/libmudflapth.so %endif -%ifarch sparc sparc64 ppc ppc64 +%if %{inlist %{target_arch} sparc sparc64 ppc ppc64} %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libmudflap.a %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libmudflapth.a %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libmudflap.so %{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_version}/libmudflapth.so %endif +%if %{isnative} %dir %{_prefix}/libexec/getconf %{_prefix}/libexec/getconf/default %endif From lmacken at redhat.com Wed Jan 30 06:40:05 2008 From: lmacken at redhat.com (Luke Macken) Date: Wed, 30 Jan 2008 01:40:05 -0500 Subject: F9 Alpha spinning In-Reply-To: <20080126220523.GA3054@crow> References: <20080125162835.GA19048@crow> <20080126220523.GA3054@crow> Message-ID: <20080130064005.GQ23022@crow> Latest f9-alpha live bits. It looks like our i686 GNOME/KDE spins can now fit on a CD. Ship it! :) -rw-r--r-- 1 root root 1.6G 2008-01-29 21:30 F9-Alpha-Developer-20080129.0.iso -rw-r--r-- 1 root root 767M 2008-01-29 21:43 F9-Alpha-FEL-i686-20080129.0.iso -rw-r--r-- 1 root root 4.0G 2008-01-29 22:20 F9-Alpha-games-i686-20080129.0.iso -rw-r--r-- 1 root root 698M 2008-01-29 20:24 F9-Alpha-i686-20080129.0.iso -rw-r--r-- 1 root root 688M 2008-01-29 20:51 F9-Alpha-KDE-i686-20080129.0.iso -rw-r--r-- 1 root root 801M 2008-01-29 21:04 F9-Alpha-KDE-x86_64-20080129.0.iso -rw-r--r-- 1 root root 745M 2008-01-29 20:40 F9-Alpha-x86_64-20080129.0.iso Diff between F9-Alpha-i686-20080126.0.iso and F9-Alpha-i686-20080129.0.iso firstboot grew 16501 bytes (4.02%) (410052->426553) python-pyblock shrunk 22 bytes (175969->175947) system-config-keyboard shrunk 1259 bytes (182829->181570) anaconda shrunk 12750 bytes (17027299->17014549) removed package scim-lang-kannada: 0 removed package scim-lang-tibetan: 0 removed package scim-lang-sinhalese: 0 removed package scim-lang-assamese: 0 removed package m17n-contrib-urdu: 3608 removed package m17n-db-assamese: 6079 removed package m17n-db-kannada: 7749 removed package m17n-contrib-kannada: 8717 removed package m17n-contrib-assamese: 12581 removed package m17n-db-sinhala: 14228 removed package m17n-db-tibetan: 15214 removed package m17n-contrib-sinhala: 16770 removed package scim-sinhala: 71021 removed package lohit-fonts-kannada: 210747 removed package lklug-fonts: 333507 removed package xorg-x11-fonts-ethiopic: 429894 removed package SDL: 495206 removed package abyssinica-fonts: 649794 removed package jomolhari-fonts: 2293163 removed package pwlib: 2423613 removed package tibetan-machine-uni-fonts: 4529886 removed package opal: 10988583 removed package ekiga: 13341902 old has 908 packages new has 885 packages diff between F8-Live-i686 and F9-Alpha-i686-20080129.0.iso new package libgdiplus-devel: 8584 new package xorg-x11-server-common: 38863 new package PolicyKit-gnome-libs: 40188 new package kerneloops: 52570 new package swfdec-gtk: 55786 new package gnome-panel-libs: 56936 new package swfdec-mozilla: 75911 new package libconfig: 120055 new package obex-data-server: 136538 new package at-spi-python: 170868 new package ncurses-base: 176949 new package pixman: 209556 new package scim-python: 247730 new package libcurl: 258148 new package libggz: 289477 new package hfsutils: 362228 new package libmtp: 398952 new package xorg-x11-drv-openchrome: 415754 new package ggz-client-libs: 434830 new package samyak-fonts: 457144 new package perl-Date-Manip: 458629 new package libtasn1: 466849 new package python-crypto: 571535 new package elilo: 613010 new package gfs2-utils: 650707 new package ncurses-libs: 668620 new package swfdec: 958169 new package reiserfs-utils: 1022402 new package iscsi-initiator-utils: 1138529 new package jfsutils: 1138726 new package gvfs: 1700127 new package totem-pl-parser: 2627745 new package xfsprogs: 3408051 new package VLGothic-fonts: 3831447 new package VLGothic-fonts-proportional: 3831790 new package gnome-settings-daemon: 6218660 new package mesa-libOSMesa: 7248256 new package scim-python-chinese: 7621164 new package libgweather: 14592282 new package dejavu-fonts: 15593008 new package vim-common: 16294034 new package xulrunner: 24481155 crontabs grew 144 bytes (6.83%) (2107->2251) libopenraw-gnome grew 348 bytes (7.94%) (4384->4732) xorg-x11-drv-fbdev grew 380 bytes (1.84%) (20597->20977) irqbalance grew 400 bytes (1.85%) (21595->21995) m17n-contrib grew 469 bytes (1.28%) (36757->37226) pam_ccreds grew 497 bytes (1.49%) (33428->33925) smolt-firstboot grew 655 bytes (6.01%) (10893->11548) pcsc-lite-libs grew 848 bytes (2.44%) (34696->35544) dbus-x11 grew 884 bytes (3.63%) (24353->25237) numactl grew 896 bytes (1.00%) (89239->90135) gnome-bluetooth-libs grew 1278 bytes (1.02%) (124866->126144) xorg-x11-drv-evdev grew 1445 bytes (4.05%) (35642->37087) m17n-db-hindi grew 1717 bytes (21.74%) (7899->9616) sysreport grew 1783 bytes (5.30%) (33620->35403) libpciaccess grew 1796 bytes (7.21%) (24901->26697) sg3_utils-libs grew 2156 bytes (1.97%) (109392->111548) pciutils grew 2464 bytes (1.36%) (180975->183439) setroubleshoot grew 2541 bytes (1.11%) (229578->232119) gnome-keyring-pam grew 2556 bytes (8.89%) (28760->31316) libcap grew 2618 bytes (5.79%) (45230->47848) apr grew 2823 bytes (1.04%) (271801->274624) bc grew 2861 bytes (1.50%) (190964->193825) libsepol grew 2992 bytes (1.33%) (224692->227684) lohit-fonts-telugu grew 3100 bytes (1.78%) (174487->177587) e2fsprogs-libs grew 3332 bytes (1.33%) (250016->253348) device-mapper-libs grew 3680 bytes (4.25%) (86516->90196) glx-utils grew 3704 bytes (10.98%) (33736->37440) scim-chewing grew 4072 bytes (3.22%) (126383->130455) dbus-libs grew 4100 bytes (1.63%) (251944->256044) nash grew 4128 bytes (1.74%) (237698->241826) libjpeg grew 4420 bytes (1.61%) (275021->279441) authconfig-gtk grew 4808 bytes (2.75%) (175143->179951) mkinitrd grew 4854 bytes (4.84%) (100334->105188) linuxwacom grew 5518 bytes (1.10%) (502293->507811) desktop-file-utils grew 5523 bytes (4.50%) (122601->128124) gnome-python2-gnomeprint grew 5547 bytes (1.27%) (437641->443188) bluez-utils-alsa grew 5856 bytes (13.67%) (42824->48680) m17n-contrib-telugu grew 6114 bytes (28.08%) (21776->27890) rsyslog grew 6922 bytes (1.45%) (477587->484509) ustr grew 7531 bytes (3.12%) (241610->249141) rhpxl grew 7783 bytes (2.36%) (329907->337690) xorg-x11-drv-mga grew 8319 bytes (4.91%) (169473->177792) taglib grew 8368 bytes (1.71%) (489415->497783) gtk-nodoka-engine grew 8948 bytes (9.32%) (96057->105005) nscd grew 9484 bytes (6.73%) (140911->150395) exempi grew 9692 bytes (1.39%) (698782->708474) gnome-menus grew 9841 bytes (1.57%) (626493->636334) dbus-glib grew 9970 bytes (2.10%) (473790->483760) libdhcp6client grew 10524 bytes (6.30%) (166956->177480) openldap grew 10658 bytes (1.76%) (604986->615644) nss_ldap grew 12224 bytes (2.17%) (562402->574626) dmidecode grew 14466 bytes (10.46%) (138266->152732) NetworkManager-vpnc grew 14477 bytes (4.58%) (316033->330510) system-config-rootpassword grew 14962 bytes (16.07%) (93118->108080) gstreamer-python grew 15266 bytes (1.64%) (933175->948441) rarian grew 15824 bytes (4.99%) (316947->332771) at-spi grew 16072 bytes (2.38%) (674624->690696) isomd5sum grew 17146 bytes (36.61%) (46840->63986) usbutils grew 17192 bytes (19.31%) (89044->106236) acl grew 17907 bytes (11.99%) (149361->167268) hicolor-icon-theme grew 17992 bytes (79.30%) (22688->40680) gnome-python2-desktop grew 18187 bytes (7.44%) (244527->262714) libdhcp grew 19318 bytes (14.23%) (135727->155045) which grew 20480 bytes (65.05%) (31485->51965) NetworkManager-gnome grew 20604 bytes (2.90%) (710665->731269) pam_krb5 grew 20943 bytes (8.06%) (259736->280679) system-config-language grew 21674 bytes (8.55%) (253576->275250) libxcb grew 22328 bytes (5.40%) (413804->436132) bluez-utils grew 22572 bytes (1.76%) (1280277->1302849) pygtksourceview grew 23100 bytes (36.06%) (64064->87164) libgpg-error grew 23525 bytes (12.14%) (193728->217253) glibmm24 grew 24411 bytes (5.25%) (465396->489807) fribidi grew 24912 bytes (17.19%) (144894->169806) gmime grew 24916 bytes (4.24%) (587824->612740) libuser grew 25215 bytes (1.56%) (1616562->1641777) xterm grew 25999 bytes (3.24%) (802644->828643) httpd grew 28595 bytes (1.12%) (2551734->2580329) m17n-lib grew 30893 bytes (10.14%) (304750->335643) rhpl grew 31037 bytes (3.99%) (778235->809272) libdhcp4client grew 32772 bytes (6.57%) (499144->531916) bind-utils grew 33408 bytes (10.87%) (307362->340770) NetworkManager grew 33657 bytes (1.42%) (2377366->2411023) dbus-python grew 36266 bytes (5.11%) (710089->746355) gnome-mag grew 36431 bytes (7.21%) (504936->541367) libXpm grew 37746 bytes (52.09%) (72467->110213) libgnomekbd grew 38042 bytes (6.68%) (569521->607563) pm-utils grew 39200 bytes (117.36%) (33402->72602) nautilus-sendto grew 42489 bytes (16.21%) (262118->304607) dhclient grew 42699 bytes (8.59%) (497288->539987) gtksourceview2 grew 42895 bytes (2.00%) (2148753->2191648) krb5-libs grew 45052 bytes (2.96%) (1522532->1567584) system-config-printer grew 56236 bytes (5.99%) (939482->995718) gnutls grew 58282 bytes (5.99%) (972804->1031086) libthai grew 60142 bytes (17.40%) (345628->405770) bluez-gnome grew 60576 bytes (22.56%) (268531->329107) mono-data grew 61605 bytes (1.21%) (5087435->5149040) libwnck grew 62234 bytes (5.42%) (1148126->1210360) gtk2-engines grew 63679 bytes (6.09%) (1045391->1109070) system-config-users grew 64047 bytes (4.40%) (1455495->1519542) gnokii grew 68723 bytes (4.36%) (1575916->1644639) rsync grew 73058 bytes (18.04%) (404896->477954) hal-info grew 75029 bytes (20.94%) (358305->433334) mesa-libGLU grew 77812 bytes (17.12%) (454428->532240) mdadm grew 83417 bytes (4.79%) (1743098->1826515) shared-mime-info grew 85852 bytes (9.51%) (902332->988184) compiz-gnome grew 87904 bytes (7.16%) (1227682->1315586) PolicyKit-gnome grew 89123 bytes (126.49%) (70457->159580) GConf2 grew 89585 bytes (1.68%) (5342705->5432290) dhcpv6-client grew 94965 bytes (54.70%) (173599->268564) system-config-firewall grew 103528 bytes (4.50%) (2300495->2404023) ntfs-3g grew 107185 bytes (36.31%) (295187->402372) f-spot grew 110065 bytes (1.44%) (7621883->7731948) PolicyKit grew 121200 bytes (71.93%) (168495->289695) gnupg grew 126829 bytes (2.62%) (4841029->4967858) libgcrypt grew 132376 bytes (38.24%) (346204->478580) libopenraw grew 136838 bytes (101.68%) (134583->271421) pykickstart grew 141694 bytes (17.92%) (790784->932478) gnome-python2-gnomevfs grew 142165 bytes (87.24%) (162958->305123) hwdata grew 144093 bytes (15.63%) (921699->1065792) shadow-utils grew 144973 bytes (5.29%) (2739389->2884362) gnome-volume-manager grew 158480 bytes (7.38%) (2146417->2304897) vbetool grew 162208 bytes (139.43%) (116340->278548) openssl grew 166448 bytes (4.81%) (3459831->3626279) libselinux-python grew 171323 bytes (118.46%) (144622->315945) libsilc grew 180620 bytes (17.41%) (1037560->1218180) sound-juicer grew 182617 bytes (5.86%) (3114050->3296667) gnome-system-monitor grew 186353 bytes (3.55%) (5244840->5431193) gdb grew 193437 bytes (3.11%) (6228176->6421613) evolution-data-server grew 208724 bytes (1.89%) (11029422->11238146) PyOpenGL grew 213779 bytes (4.86%) (4398157->4611936) tomboy grew 218900 bytes (3.63%) (6022535->6241435) parted grew 223507 bytes (15.16%) (1474368->1697875) selinux-policy-devel grew 229206 bytes (4.15%) (5522257->5751463) orca grew 231344 bytes (4.05%) (5718621->5949965) util-linux-ng grew 245524 bytes (5.17%) (4749959->4995483) iso-codes grew 269192 bytes (4.80%) (5605136->5874328) system-config-date grew 282500 bytes (10.09%) (2798572->3081072) xorg-x11-drv-ati grew 285328 bytes (35.75%) (798151->1083479) selinux-policy grew 292154 bytes (3.79%) (7707834->7999988) eog grew 292326 bytes (7.82%) (3740424->4032750) dbus grew 299134 bytes (58.75%) (509123->808257) totem grew 321458 bytes (5.87%) (5476956->5798414) gnome-keyring grew 333541 bytes (32.87%) (1014819->1348360) glibc grew 347221 bytes (2.59%) (13402107->13749328) sqlite grew 358672 bytes (76.12%) (471170->829842) setroubleshoot-server grew 363273 bytes (22.18%) (1637732->2001005) bind-libs grew 389872 bytes (17.27%) (2258064->2647936) gcalctool grew 496578 bytes (10.21%) (4862745->5359323) gnome-panel grew 509960 bytes (4.35%) (11714901->12224861) gutenprint grew 664813 bytes (15.07%) (4410340->5075153) rhythmbox grew 678314 bytes (6.41%) (10582223->11260537) mono-core grew 686301 bytes (2.01%) (34154946->34841247) nautilus grew 693197 bytes (5.04%) (13751211->14444408) mono-winforms grew 729754 bytes (7.47%) (9765822->10495576) liberation-fonts grew 767468 bytes (69.95%) (1097162->1864630) totem-mozplugin grew 770229 bytes (136.17%) (565632->1335861) mono-web grew 797665 bytes (9.85%) (8097242->8894907) glib2 grew 849381 bytes (29.07%) (2922173->3771554) gnome-power-manager grew 934030 bytes (8.33%) (11214535->12148565) nss grew 937664 bytes (44.33%) (2114975->3052639) libsmbclient grew 1191360 bytes (50.53%) (2357736->3549096) gnome-games grew 1373569 bytes (4.65%) (29510057->30883626) kernel grew 2268304 bytes (4.82%) (47063671->49331975) gutenprint-foomatic grew 2393009 bytes (5.05%) (47405319->49798328) anaconda grew 2566351 bytes (17.76%) (14448198->17014549) krb5-auth-dialog shrunk 1 bytes (53674->53673) libtirpc shrunk 1 bytes (150301->150300) gmime-sharp shrunk 6 bytes (197336->197330) gzip shrunk 6 bytes (219689->219683) gedit shrunk 8 bytes (13487572->13487564) system-config-network shrunk 8 bytes (1905298->1905290) perl shrunk 14 bytes (31645884->31645870) ntsysv shrunk 16 bytes (22156->22140) python-pyblock shrunk 22 bytes (175969->175947) pavucontrol shrunk 23 bytes (169857->169834) libXfont shrunk 32 bytes (456948->456916) gnome-python2-canvas shrunk 32 bytes (48902->48870) xorg-x11-drv-vmmouse shrunk 32 bytes (16364->16332) mono-data-sqlite shrunk 33 bytes (457296->457263) groff shrunk 35 bytes (5390470->5390435) gnome-pilot shrunk 36 bytes (1930958->1930922) libflashsupport shrunk 40 bytes (11044->11004) nautilus-extensions shrunk 48 bytes (31308->31260) pulseaudio-utils shrunk 56 bytes (234499->234443) libselinux shrunk 61 bytes (148311->148250) gimp shrunk 64 bytes (38423455->38423391) libXrender shrunk 64 bytes (47254->47190) paps shrunk 64 bytes (51462->51398) libxkbfile shrunk 96 bytes (146358->146262) librsvg2 shrunk 120 bytes (337750->337630) pulseaudio-libs shrunk 128 bytes (343843->343715) isdn4k-utils shrunk 144 bytes (9789025->9788881) less shrunk 171 bytes (176124->175953) urw-fonts shrunk 172 bytes (4389572->4389400) xorg-x11-drv-keyboard shrunk 256 bytes (26608->26352) anacron shrunk 274 bytes (56515->56241) libgtop2 shrunk 320 bytes (341012->340692) xorg-x11-drv-cirrus shrunk 355 bytes (77986->77631) cups-libs shrunk 356 bytes (336516->336160) gtkspell shrunk 400 bytes (56779->56379) pulseaudio-core-libs shrunk 416 bytes (439696->439280) libpcap shrunk 485 bytes (261897->261412) nspluginwrapper shrunk 495 bytes (311511->311016) udev shrunk 601 bytes (654430->653829) setroubleshoot-plugins shrunk 689 bytes (2422617->2421928) python-numeric shrunk 1040 bytes (1722779->1721739) xorg-x11-drv-vesa shrunk 1208 bytes (26099->24891) system-config-keyboard shrunk 1259 bytes (182829->181570) fedora-release shrunk 1450 bytes (46680->45230) gnome-spell shrunk 1568 bytes (377889->376321) gparted shrunk 1600 bytes (1569813->1568213) nspr shrunk 1856 bytes (248628->246772) dvd+rw-tools shrunk 1860 bytes (283930->282070) libdrm shrunk 1878 bytes (39456->37578) at shrunk 1892 bytes (83059->81167) synaptics shrunk 2072 bytes (113498->111426) m17n-contrib-hindi shrunk 2162 bytes (16757->14595) pango shrunk 3747 bytes (862572->858825) system-config-services shrunk 3768 bytes (561578->557810) libcdio shrunk 3961 bytes (555394->551433) audit-libs shrunk 4096 bytes (130447->126351) atmel-firmware shrunk 4458 bytes (732612->728154) fontconfig shrunk 4805 bytes (374336->369531) iwl4965-firmware shrunk 5572 bytes (389701->384129) checkpolicy shrunk 6752 bytes (510825->504073) ppp shrunk 8123 bytes (841674->833551) ntp shrunk 8426 bytes (2652615->2644189) procps shrunk 11625 bytes (374451->362826) iproute shrunk 11660 bytes (2152986->2141326) gnome-bluetooth shrunk 12179 bytes (545675->533496) smolt shrunk 13811 bytes (635219->621408) b43-fwcutter shrunk 17375 bytes (37123->19748) im-chooser shrunk 19198 bytes (208789->189591) evolution shrunk 30364 bytes (38160208->38129844) ntfsprogs shrunk 33559 bytes (1148797->1115238) zip shrunk 33692 bytes (302492->268800) vixie-cron shrunk 46771 bytes (673502->626731) logwatch shrunk 52401 bytes (1345913->1293512) compiz shrunk 57822 bytes (1846352->1788530) system-config-printer-libs shrunk 60765 bytes (2411303->2350538) cups shrunk 63488 bytes (10345708->10282220) eel2 shrunk 90562 bytes (848996->758434) yelp shrunk 99732 bytes (2559882->2460150) xorg-x11-drv-i810 shrunk 249946 bytes (655965->406019) gtk2 shrunk 308952 bytes (20696815->20387863) fedora-release-notes shrunk 329470 bytes (12271152->11941682) firstboot shrunk 356968 bytes (783521->426553) cairo shrunk 423604 bytes (1623706->1200102) control-center shrunk 492635 bytes (8945618->8452983) gnome-media shrunk 782217 bytes (4946507->4164290) e2fsprogs shrunk 904410 bytes (2366733->1462323) device-mapper shrunk 917957 bytes (1027430->109473) gnome-themes shrunk 1007647 bytes (4994173->3986526) xkeyboard-config shrunk 1188506 bytes (3043679->1855173) lvm2 shrunk 1386888 bytes (2186994->800106) xorg-x11-server-Xorg shrunk 1410978 bytes (7431876->6020898) python shrunk 1870258 bytes (18499208->16628950) xorg-x11-fonts-Type1 shrunk 1919814 bytes (2803806->883992) ncurses shrunk 2311863 bytes (2562051->250188) selinux-policy-targeted shrunk 3364847 bytes (27048093->23683246) gdm shrunk 6450348 bytes (14040436->7590088) gnome-applets shrunk 8005406 bytes (26478262->18472856) firefox shrunk 39666395 bytes (42009290->2342895) removed package fonts-gujarati: 0 removed package fonts-korean: 0 removed package scim-lang-kannada: 0 removed package fonts-arabic: 0 removed package fonts-punjabi: 0 removed package fonts-oriya: 0 removed package fonts-chinese: 0 removed package scim-lang-tibetan: 0 removed package fonts-kannada: 0 removed package fonts-bengali: 0 removed package fonts-hebrew: 0 removed package fonts-hindi: 0 removed package scim-lang-assamese: 0 removed package fonts-sinhala: 0 removed package scim-lang-sinhalese: 0 removed package fonts-tamil: 0 removed package fonts-telugu: 0 removed package fonts-malayalam: 0 removed package m17n-contrib-urdu: 3608 removed package m17n-db-assamese: 6079 removed package m17n-db-kannada: 7749 removed package m17n-contrib-kannada: 8717 removed package m17n-contrib-sinhala: 11327 removed package m17n-contrib-assamese: 12581 removed package m17n-db-sinhala: 14228 removed package m17n-db-tibetan: 15214 removed package xorg-x11-drv-ark: 18888 removed package xorg-x11-drv-tseng: 52907 removed package xorg-x11-drv-s3: 58401 removed package scim-sinhala: 66881 removed package totem-plparser: 70428 removed package libbeagle: 94092 removed package xorg-x11-drv-avivo: 107204 removed package xorg-x11-drv-chips: 154533 removed package lohit-fonts-kannada: 210687 removed package fuse: 216231 removed package beecrypt: 242015 removed package lklug-fonts: 333507 removed package xorg-x11-drv-via: 363192 removed package xorg-x11-fonts-ethiopic: 437981 removed package SDL: 495206 removed package curl: 514238 removed package firstboot-tui: 653472 removed package xorg-x11-fonts-truetype: 909077 removed package db4o: 1414265 removed package jomolhari-fonts: 2293163 removed package pwlib: 2423701 removed package evince: 3452782 removed package aspell-en: 3567971 removed package tibetan-machine-uni-fonts: 4529886 removed package dejavu-lgc-fonts: 6293390 removed package opal: 10988583 removed package ekiga: 13323689 old has 896 packages new has 885 packages From floss at lex.hider.name Wed Jan 30 09:51:28 2008 From: floss at lex.hider.name (Lex Hider) Date: Wed, 30 Jan 2008 20:51:28 +1100 Subject: How much personal information is necessary to close a bug? Message-ID: <1201686688.13318.4.camel@fedlex.lex.hider.name> Hi, I was wanting to do some bug triage for fedora. I checked out the list of NEW bugs for one of my favourite apps: amarok. There seemed a pretty obvious bug that could now be closed: https://bugzilla.redhat.com/show_bug.cgi?id=248625 I tried to close it and found I didn't have the privileges to do so. I asked on #fedora-devel and was pointed to the triage team wiki page and that I need a Fedora Account. Apparently to open a Fedora account I need to give my postal address and telephone number. Why is it necessary to give this personal information just to close a bug? Contrast to other projects I have contributed to where some realizes you know what you are doing or get sick of you pestering to close bugs on your behalf and give you the relevant privileges. Here's an example of my bug closing credentials: Look at Bug Killers: http://www.commit-digest.org/issues/2006-04-30/ Lex. From snecklifter at gmail.com Wed Jan 30 10:51:53 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Wed, 30 Jan 2008 10:51:53 +0000 Subject: How much personal information is necessary to close a bug? In-Reply-To: <1201686688.13318.4.camel@fedlex.lex.hider.name> References: <1201686688.13318.4.camel@fedlex.lex.hider.name> Message-ID: <364d303b0801300251s39ffe2b8we671f2005c836474@mail.gmail.com> On 30/01/2008, Lex Hider wrote: > Hi, > I was wanting to do some bug triage for fedora. > I checked out the list of NEW bugs for one of my favourite apps: amarok. > There seemed a pretty obvious bug that could now be closed: > https://bugzilla.redhat.com/show_bug.cgi?id=248625 > > I tried to close it and found I didn't have the privileges to do so. > I asked on #fedora-devel and was pointed to the triage team wiki page > and that I need a Fedora Account. > > Apparently to open a Fedora account I need to give my postal address and > telephone number. Why is it necessary to give this personal information > just to close a bug? > > Contrast to other projects I have contributed to where some realizes you > know what you are doing or get sick of you pestering to close bugs on > your behalf and give you the relevant privileges. > > Here's an example of my bug closing credentials: > Look at Bug Killers: > http://www.commit-digest.org/issues/2006-04-30/ Hello Lex, Great that you're wanting to do some triage work and yeah, that bug is the kind of stuff that we don't need hanging around any longer. :) As for the information side of things, FAS is used for a number of things, including the ability to create packages in Fedora and there has to, at some point, be some accountability for how this happens. With bugzilla triage privs you get the ability to modify to great extent the bugs in Red Hat's main bug tracking system so I think its understandable for this to be asked. Someone with legal knowledge might want to add to this though. Best place to hang out for triaging is #fedora-qa on IRC and the two bods leading the charge are John Poelstra and Jon Stanley. http://fedoraproject.org/wiki/JohnPoelstra http://fedoraproject.org/wiki/JonStanley We have a meeting today at 1700 UTC in #fedora-meeting - would be good to have you there as well. Cheers -- Christopher Brown http://www.chruz.com From floss at lex.hider.name Wed Jan 30 11:07:15 2008 From: floss at lex.hider.name (Lex Hider) Date: Wed, 30 Jan 2008 22:07:15 +1100 Subject: How much personal information is necessary to close a bug? In-Reply-To: <364d303b0801300251s39ffe2b8we671f2005c836474@mail.gmail.com> References: <1201686688.13318.4.camel@fedlex.lex.hider.name> <364d303b0801300251s39ffe2b8we671f2005c836474@mail.gmail.com> Message-ID: <1201691235.13318.13.camel@fedlex.lex.hider.name> On Wed, 2008-01-30 at 10:51 +0000, Christopher Brown wrote: > On 30/01/2008, Lex Hider wrote: > > Hi, > > I was wanting to do some bug triage for fedora. > > I checked out the list of NEW bugs for one of my favourite apps: amarok. > > There seemed a pretty obvious bug that could now be closed: > > https://bugzilla.redhat.com/show_bug.cgi?id=248625 > > > > I tried to close it and found I didn't have the privileges to do so. > > I asked on #fedora-devel and was pointed to the triage team wiki page > > and that I need a Fedora Account. > > > > Apparently to open a Fedora account I need to give my postal address and > > telephone number. Why is it necessary to give this personal information > > just to close a bug? > > > > Contrast to other projects I have contributed to where some realizes you > > know what you are doing or get sick of you pestering to close bugs on > > your behalf and give you the relevant privileges. > > > > Here's an example of my bug closing credentials: > > Look at Bug Killers: > > http://www.commit-digest.org/issues/2006-04-30/ > > Hello Lex, > > Great that you're wanting to do some triage work and yeah, that bug is > the kind of stuff that we don't need hanging around any longer. :) > > As for the information side of things, FAS is used for a number of > things, including the ability to create packages in Fedora and there > has to, at some point, be some accountability for how this happens. > With bugzilla triage privs you get the ability to modify to great > extent the bugs in Red Hat's main bug tracking system so I think its > understandable for this to be asked. Someone with legal knowledge > might want to add to this though. > > Best place to hang out for triaging is #fedora-qa on IRC and the two > bods leading the charge are John Poelstra and Jon Stanley. > > http://fedoraproject.org/wiki/JohnPoelstra > http://fedoraproject.org/wiki/JonStanley > > We have a meeting today at 1700 UTC in #fedora-meeting - would be good > to have you there as well. > > Cheers > > -- > Christopher Brown I think that meeting is around 4am local time, so I may have to give it a miss. Perhaps you could put on the agenda how high the barrier for entry is. Not only do I have to create a separate Fedora account aside form the bugzilla that I have, I have to give out my personal details, and then I have to learn enough about gpg to make a key to sign up for the account. If I have to jump through all the above hoops just to close trivial bugs, I'm not sure if I'll bother. I can see no reason why anyone would need my address and phone number. What is stopping anyone from putting in fake ones. I was tempted just to enter address as something like: 27 Gumdrop House Lolly Pop Lane. (http://thinkexist.com/quotation/owww-look-at-me-marge-i-m-making-people-happy-i-m/748180.html) Surely entering the phone number and address details is useless without verification anyway. Lex From sundaram at fedoraproject.org Wed Jan 30 11:20:22 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 30 Jan 2008 16:50:22 +0530 Subject: F9 Alpha spinning In-Reply-To: <20080130064005.GQ23022@crow> References: <20080125162835.GA19048@crow> <20080126220523.GA3054@crow> <20080130064005.GQ23022@crow> Message-ID: <47A05D76.9000301@fedoraproject.org> Luke Macken wrote: > Latest f9-alpha live bits. It looks like our i686 GNOME/KDE spins can now > fit on a CD. Ship it! :) > > -rw-r--r-- 1 root root 1.6G 2008-01-29 21:30 F9-Alpha-Developer-20080129.0.iso > -rw-r--r-- 1 root root 767M 2008-01-29 21:43 F9-Alpha-FEL-i686-20080129.0.iso FEL is supposed to fit into a CD. Chitlesh, are you checking this? Rahul From floss at lex.hider.name Wed Jan 30 11:14:45 2008 From: floss at lex.hider.name (Lex Hider) Date: Wed, 30 Jan 2008 22:14:45 +1100 Subject: How much personal information is necessary to close a bug? In-Reply-To: <364d303b0801300251s39ffe2b8we671f2005c836474@mail.gmail.com> References: <1201686688.13318.4.camel@fedlex.lex.hider.name> <364d303b0801300251s39ffe2b8we671f2005c836474@mail.gmail.com> Message-ID: <1201691685.13318.16.camel@fedlex.lex.hider.name> On Wed, 2008-01-30 at 10:51 +0000, Christopher Brown wrote: > On 30/01/2008, Lex Hider wrote: > > Hi, > > I was wanting to do some bug triage for fedora. > > I checked out the list of NEW bugs for one of my favourite apps: amarok. > > There seemed a pretty obvious bug that could now be closed: > > https://bugzilla.redhat.com/show_bug.cgi?id=248625 > > Thanks for closing above bug. Can someone close this one too: https://bugzilla.redhat.com/show_bug.cgi?id=253060 Lex. From snecklifter at gmail.com Wed Jan 30 11:32:09 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Wed, 30 Jan 2008 11:32:09 +0000 Subject: How much personal information is necessary to close a bug? In-Reply-To: <1201691235.13318.13.camel@fedlex.lex.hider.name> References: <1201686688.13318.4.camel@fedlex.lex.hider.name> <364d303b0801300251s39ffe2b8we671f2005c836474@mail.gmail.com> <1201691235.13318.13.camel@fedlex.lex.hider.name> Message-ID: <364d303b0801300332i4bd4a2b9n28a0f5b9eb3271b@mail.gmail.com> On 30/01/2008, Lex Hider wrote: > I think that meeting is around 4am local time, so I may have to give it > a miss. Perhaps you could put on the agenda how high the barrier for > entry is. Not only do I have to create a separate Fedora account aside > form the bugzilla that I have, I have to give out my personal details, > and then I have to learn enough about gpg to make a key to sign up for > the account. > > If I have to jump through all the above hoops just to close trivial > bugs, I'm not sure if I'll bother. > > I can see no reason why anyone would need my address and phone number. > What is stopping anyone from putting in fake ones. > > I was tempted just to enter address as something like: > 27 Gumdrop House > Lolly Pop Lane. > (http://thinkexist.com/quotation/owww-look-at-me-marge-i-m-making-people-happy-i-m/748180.html) > > > Surely entering the phone number and address details is useless without > verification anyway. Now I think of it, it may have something to do with code contributions, copyright assertion, etc etc. Perhaps fall-out from SCO case. Anyway, if you can ping either of the two above in #fedora-qa, their handles are poelcat and jds2001 they will be able to set you up quicker I believe. If you want to live at Lolly Pop Lane, by all means :) Cheers -- Christopher Brown http://www.chruz.com From buc at odusz.so-cdu.ru Wed Jan 30 12:29:00 2008 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Wed, 30 Jan 2008 15:29:00 +0300 Subject: Libsoup troubles in rawhide (compat-libsoup22 needed) In-Reply-To: <1201661054.2779.7.camel@localhost.localdomain> References: <479F655F.2010000@odu.neva.ru> <1201660097.25209.24.camel@localhost.localdomain> <1201661054.2779.7.camel@localhost.localdomain> Message-ID: <47A06D8C.2000808@odu.neva.ru> Matthias Clasen wrote: > Dan really went out of his way to handle the api breakage as well as > possible. He had patches for all affected gnome packages before even > doing the 2.3.0 release, and he has only made the release after the > Gnome release team strongly encouraged him to get libsoup 2.4 into > Gnome 2.22. > > He has also provided a patch for libtranslate by now I would like to see the patch... (I am a current maintainer of libtranslate, and have contacts with upstream). Could you hint him to send the patch for me? (I maintain libtrabslate now). Dmitry Butskoy http://www.fedoraproject.org/wiki/DmitryButskoy From sundaram at fedoraproject.org Wed Jan 30 13:55:44 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 30 Jan 2008 19:25:44 +0530 Subject: Bug reporting HOWTO In-Reply-To: <1ct375xt8b.ln2@ppp1053.in.ipex.cz> References: <1ct375xt8b.ln2@ppp1053.in.ipex.cz> Message-ID: <47A081E0.6080200@fedoraproject.org> Matej Cepl wrote: > While thinking about other threads on bug triaging etc. and while > reading > http://www.linuxindex.com/2008/01/18/bryce-harrington-bug-reporting-in-Ubuntu/ > I wrote some list of things which might help users to write > better bug reports (and us to get them solved more quickly). It > is currently on > http://fedoraproject.org/wiki/Matej_Cepl/Bug_Triage/Bug_reporting_HOWTO > but I plan to move it to BugTriage category once I will get > enough feedback to be happy with it. > > Would you please comment on this, what could be helpful, what is > missing, and what should be removed? Might be useful to merge with http://fedoraproject.org/wiki/BugsAndFeatureRequests Rahul From sgrubb at redhat.com Wed Jan 30 13:46:41 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 30 Jan 2008 08:46:41 -0500 Subject: Cannot access the Hardware Clock via any known method Message-ID: <200801300846.41420.sgrubb@redhat.com> Hi, I'm running an up to date rawhide machine. This message shows up everytime I boot and my system time is always way off. Its been like this for over a month. I figured somebody else would notice this and report it or fix it. This is the full message: Cannot access the Hardware Clock via any known method. Use the --debug option to see the details of our search for an access method. This occurs during boot. I have no idea where this is coming from. When I'm at the command prompt, /dev/rtc exists. Any one else running x86_64 rawhide notice this, too? -Steve From rdieter at math.unl.edu Wed Jan 30 14:05:48 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 30 Jan 2008 08:05:48 -0600 Subject: Cannot access the Hardware Clock via any known method References: <200801300846.41420.sgrubb@redhat.com> Message-ID: Steve Grubb wrote: > I'm running an up to date rawhide machine. This message shows up everytime > I boot and my system time is always way off. Its been like this for over a > month. I figured somebody else would notice this and report it or fix it. > This is the full message: > > Cannot access the Hardware Clock via any known method. > Use the --debug option to see the details of our search for an access > method. > > This occurs during boot. I have no idea where this is coming from. When > I'm at the command prompt, /dev/rtc exists. Any one else running x86_64 > rawhide notice this, too? yep, spot and I chatted about this @ FUDCon, his guess was that hwclock was running too early, possibly before udev had a chance to create /dev/rtc. ?? -- Rex From dakingun at gmail.com Wed Jan 30 14:11:00 2008 From: dakingun at gmail.com (Deji Akingunola) Date: Wed, 30 Jan 2008 09:11:00 -0500 Subject: Cannot access the Hardware Clock via any known method In-Reply-To: <200801300846.41420.sgrubb@redhat.com> References: <200801300846.41420.sgrubb@redhat.com> Message-ID: On Jan 30, 2008 8:46 AM, Steve Grubb wrote: > Hi, > > I'm running an up to date rawhide machine. This message shows up everytime I > boot and my system time is always way off. Its been like this for over a > month. I figured somebody else would notice this and report it or fix it. > This is the full message: > > Cannot access the Hardware Clock via any known method. > Use the --debug option to see the details of our search for an access method. > > This occurs during boot. I have no idea where this is coming from. When I'm at > the command prompt, /dev/rtc exists. Any one else running x86_64 rawhide > notice this, too? > Yes, https://bugzilla.redhat.com/show_bug.cgi?id=409551 https://bugzilla.redhat.com/show_bug.cgi?id=290731 Deji From sundaram at fedoraproject.org Wed Jan 30 14:19:45 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 30 Jan 2008 19:49:45 +0530 Subject: F9 for Eeepc In-Reply-To: References: <479A650D.8060401@cora.nwra.com> <1201304569.2057.22.camel@localhost.localdomain> <645d17210801251629y2811f3f7jf0886a166ffd2f8@mail.gmail.com> <479E7137.5020705@cora.nwra.com> Message-ID: <47A08781.70303@fedoraproject.org> Jon Nettleton wrote: > > For other eeepc users I just wanted to mention that I hacked on > devilspie to include matching on the geometry attributes of a window. > Long story short you can use it now to say if a window is taller than > 480 pixels you can either set it to resize smaller or maximize > vertically. > > This still doesn't work for dialog's yet, I am looking at gtk and a > few other places that I might hack around fixes to make them fit on > the small resolution better. FYI, there was a discussion in https://www.redhat.com/archives/fedora-advisory-board/2008-January/msg00277.html If you are interested in contacting them for merging back changes, let the board know. Rahul From bruno at wolff.to Wed Jan 30 14:11:15 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 30 Jan 2008 08:11:15 -0600 Subject: Libsoup troubles in rawhide (compat-libsoup22 needed) In-Reply-To: References: <479F655F.2010000@odu.neva.ru> Message-ID: <20080130141115.GA17552@wolff.to> This may be moot now, but I was able to upgrade most stuff, avoiding the libsoup problems by excluding evolution*, libsoup* and gvfs. (I didn't have gvfs-devel installed.) From j.w.r.degoede at hhs.nl Wed Jan 30 14:30:05 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 30 Jan 2008 15:30:05 +0100 Subject: Cannot access the Hardware Clock via any known method In-Reply-To: References: <200801300846.41420.sgrubb@redhat.com> Message-ID: <47A089ED.3020101@hhs.nl> Deji Akingunola wrote: > On Jan 30, 2008 8:46 AM, Steve Grubb wrote: >> Hi, >> >> I'm running an up to date rawhide machine. This message shows up everytime I >> boot and my system time is always way off. Its been like this for over a >> month. I figured somebody else would notice this and report it or fix it. >> This is the full message: >> >> Cannot access the Hardware Clock via any known method. >> Use the --debug option to see the details of our search for an access method. >> >> This occurs during boot. I have no idea where this is coming from. When I'm at >> the command prompt, /dev/rtc exists. Any one else running x86_64 rawhide >> notice this, too? >> > Yes, > https://bugzilla.redhat.com/show_bug.cgi?id=409551 > https://bugzilla.redhat.com/show_bug.cgi?id=290731 > 2 bugs, which as one can see I've been quite active in lately. Even offering a proof of concept fix, yet sofar it has been very silent around them. I hope that this mailinglist thread will get some attention to this bug. Short story: the initrd used to create /dev/rtc (don't ask why) and then rc.sysinit runs hwclock --hctosys before doing anything else including before running udev This no longer works as we've now switched from the old intel only rtc driver to the new generic rtc class which has a different major and minor number. To make things harder, this major and minor number now gets allocated dynamically, although it seems that the new rtc class consistently is the first to claim a dynamic char major and thus always gets 254. My proof of concept fix fixes things by letting mkinitrd check /boot/config-XXXX to detect old versus new rtc driver and use the correct major / minor combi (cutting some corners by using 254 as major for the new rtc class case) That isn't the complete fix however as with the new rtc class driver as currently configured in the kernel the actual pc rtc driver called cmos_rtc is compiled as a module so my proof of concept also add that module to the initrd and insmod's it from the initrd. I'm no where near sure that this is the correct fix. I wonder if /dev/rtc is needed during the initrd at all, and if it isn't I think that the initrd should not create it all. Then rc.sysinit should be modified to run hwclock after udev, or if there are reasons not to, create the /dev entry and load the driver itself. Regards, Hans From kanarip at kanarip.com Wed Jan 30 14:37:35 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 30 Jan 2008 15:37:35 +0100 Subject: Debian style net-install ISOs (from FudCON Raleigh) In-Reply-To: References: <479FB05C.30302@redhat.com> <20080129233427.GA1290738@hiwaay.net> Message-ID: <47A08BAF.4010909@kanarip.com> Davidson Rodrigues Paulo wrote: > 2008/1/29, Chris Adams : >>> I imagine the bandwidth savings for Fedora could be huge >> Doubtful. That DVD download is usually used more than once, while all >> network installs will always download a whole lot of stuff each time. > > How hard would be to > integrate revisor in Anaconda? > Feed Revisor (or pungi for that matter) the kickstart that Anaconda writes out (/root/install.ks). Kind regards, Jeroen van Meeuwen -kanarip From sgrubb at redhat.com Wed Jan 30 14:39:21 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 30 Jan 2008 09:39:21 -0500 Subject: Cannot access the Hardware Clock via any known method In-Reply-To: <47A089ED.3020101@hhs.nl> References: <200801300846.41420.sgrubb@redhat.com> <47A089ED.3020101@hhs.nl> Message-ID: <200801300939.21297.sgrubb@redhat.com> On Wednesday 30 January 2008 09:30:05 Hans de Goede wrote: > Deji Akingunola wrote: > >> I'm running an up to date rawhide machine. This message shows up > >> everytime I boot and my system time is always way off. Its been like > >> this for over a month. I figured somebody else would notice this and > >> report it or fix it. This is the full message: > >> > >> Cannot access the Hardware Clock via any known method. > >> Use the --debug option to see the details of our search for an access > >> method. > >> > >> This occurs during boot. I have no idea where this is coming from. When > >> I'm at the command prompt, /dev/rtc exists. Any one else running x86_64 > >> rawhide notice this, too? > > > > Yes, > > https://bugzilla.redhat.com/show_bug.cgi?id=409551 > > https://bugzilla.redhat.com/show_bug.cgi?id=290731 > > 2 bugs, which as one can see I've been quite active in lately. Even > offering a proof of concept fix, yet sofar it has been very silent around > them. > > I hope that this mailinglist thread will get some attention to this bug. > > Short story: Thanks for the info. I joined the bug. This bug makes rawhide hard to use for development work because autotools complains about the timestamp being in the future. Some things also refuse to build. -Steve From nicolas.mailhot at laposte.net Wed Jan 30 14:40:20 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 30 Jan 2008 15:40:20 +0100 (CET) Subject: Cannot access the Hardware Clock via any known method In-Reply-To: References: <200801300846.41420.sgrubb@redhat.com> Message-ID: <22848.192.54.193.53.1201704020.squirrel@rousalka.dyndns.org> Le Mer 30 janvier 2008 15:05, Rex Dieter a ?crit : > yep, spot and I chatted about this @ FUDCon, his guess was that > hwclock was > running too early, possibly before udev had a chance to > create /dev/rtc. ?? I think I don't have this message with my home-built mm kernels, so it's probably a mistake in rawhide's kernel config (IIRC there are two rtc stacks in the kernel now and you get this message if you build the wrong one, or both) -- Nicolas Mailhot From buildsys at redhat.com Wed Jan 30 14:48:21 2008 From: buildsys at redhat.com (Build System) Date: Wed, 30 Jan 2008 09:48:21 -0500 Subject: rawhide report: 20080130 changes Message-ID: <200801301448.m0UEmLso016720@porkchop.devel.redhat.com> New package gruler GNOME screen ruler New package libgee GObject collection library New package mod_line_edit A general-puropse filter for text documents New package perl-Authen-Krb5 Krb5 Perl module New package xmlcopyeditor A fast, free, validating XML editor Removed package ksplash-engine-moodin Removed package dekorator Removed package kgtk Removed package gcfilms Updated Packages: GConf2-2.21.90-1.fc9 -------------------- * Tue Jan 29 2008 Matthias Clasen - 2.21.90-1 - Update to 2.21.90 GtkAda-2.10.0-3.fc9 ------------------- * Tue Jan 29 2008 Michel Salim - 2.10.0-3 - Make gtkada.pc use _libdir - Fix URL and source fields ORBit2-2.14.12-1.fc9 -------------------- * Tue Jan 29 2008 Matthias Clasen - 2.14.12-1 - Update to 2.14.12 * Tue Jan 29 2008 Matthias Clasen - 2.14.11-1 - Update to 2.14.11 PyQt-3.17.4-2.fc9 ----------------- * Tue Jan 29 2008 Rex Dieter - 3.17.4-2 - drop qscintilla support (f9+) * Thu Dec 06 2007 Rex Dieter - 3.17.4-1 - 3.17.4 * Mon Nov 12 2007 Rex Dieter - 3.17.3-3 - Requires: sip >= %{sip_version_used_to_build} SDL_image-1.2.6-5.fc9 --------------------- * Tue Jan 29 2008 Brian Pepple - 1.2.6-5 - Add patch to fix ILBM image buffer overflow. (#430693) abicheck-1.2-17 --------------- * Tue Jan 29 2008 Michael Schwendt - 1.2-17 - Make ldlinux patch look for more linker names. - Remove unbound_match patch. Not needed in F-9 devel. - Move fortify-source patch into separate dbfile in docdir. * Fri Oct 05 2007 Michael Schwendt - 1.2-15 - Patch unbound_match. - Update fortify-source patch. * Thu Aug 02 2007 Michael Schwendt - 1.2-14 - Clarify licence (LGPLv2). abiword-1:2.4.6-7.fc9 --------------------- * Tue Jan 29 2008 Michel Salim - 1:2.4.6-7 - Update license field - Remove build deps on g++ and libstdc++ (in minimum build environment) - Remove .cvsignore files from installed doc; fix abw2html.pl permission - Add support for goffice-0.6 when building on Fedora 9 and above - Fix for F9 glibc lacking TRUE and FALSE anaconda-11.4.0.28-1 -------------------- * Mon Jan 28 2008 David Cantrell - 11.4.0.28-1 - Go back to the method screen if back is hit on nfs config (#430477). (clumens) - Fix dmidecode dependency (#430394, Josh Boyer - 9100e-1 - New upstream release. azureus-3.0.4.2-7.fc9 --------------------- * Tue Jan 29 2008 Lillian Angel - 3.0.4.2-7 - Upgraded to azureus version 3.0.4.2 - Removed azureus-no-update-manager-MainStatusBar.patch. - Removed azureus-rh-bugzilla-180418.patch. - Updated azureus-no-update-manager-UpdateMonitor.patch. - Updated azureus-remove-manifest-classpath.patch. - Resolves rhbz#430607 bakery-2.4.4-1.fc9 ------------------ * Tue Jan 29 2008 Denis Leroy - 2.4.4-1 - Update to upstream 2.4.4, needed by glom - BR versions update bug-buddy-1:2.20.1-2.fc9 ------------------------ * Tue Jan 29 2008 Matthias Clasen - 1:2.20.1-2 - Port to libsoup 2.4 cheese-2.21.91-1.fc9 -------------------- * Tue Jan 29 2008 Matthias Clasen 2.21.91-1 - Update to 2.21.91 control-center-1:2.21.90-2.fc9 ------------------------------ * Tue Jan 29 2008 Soren Sandmann - 2.21.90-2 - Various updates to randr applet * Tue Jan 29 2008 - Bastien Nocera - 2.21.90 - Update to 2.21.90 - Update RandR applet patch to apply * Tue Jan 29 2008 Soren Sandmann - 2.21.5-4 - BuildRequire gnome-desktop 2.21.90 dbus-qt3-0.8-2.fc9 ------------------ deskbar-applet-2.21.90.1-1.fc9 ------------------------------ * Tue Jan 29 2008 Luke Macken - 2.21.90.1-1 - 2.21.90.1 * Tue Jan 29 2008 Luke Macken - 2.21.90-1 - 2.21.90 * Thu Jan 17 2008 Luke Macken - 2.21.5-1 - 2.21.5 e2fsprogs-1.40.5-1.fc9 ---------------------- * Mon Jan 28 2008 Eric Sandeen 1.40.5-1 - New upstream version, drop several now-upstream patches. eric-4.0.4-4.fc9 ---------------- * Tue Jan 29 2008 Johan Cwiklinski 4.0.4-4 - define qt_ver and pyqt_ver - use environment variables to set documentation path - init preferences to have relevant qt commands suffix - add PyQt4 as Requires * Tue Jan 29 2008 Johan Cwiklinski 4.0.4-3 - requires qt4-designer not qt-designer - BR : qt-devel already required by PyQt-devel - seems no longer necessary to define qt_ver - language files were sourced, not installed - error on language files path evince-2.21.90-2.fc9 -------------------- * Mon Jan 28 2008 Matthias Clasen - 2.21.90-2 - Rebuild against split poppler evolution-2.21.90-3.fc9 ----------------------- * Tue Jan 29 2008 Matthew Barnes - 2.21.90-3.fc9 - Add patch to address the recent deprecation of G_GNUC_FUNCTION. file-4.23-1.fc9 --------------- * Tue Jan 29 2008 Tomas Smetana - 4.23-1 - new upstream version; update patches; drop unused patches file-roller-2.21.2-1.fc9 ------------------------ * Tue Jan 29 2008 Matthias Clasen - 2.21.2-1 - Update to 2.21.2 gedit-1:2.21.1-1.fc9 -------------------- * Tue Jan 29 2008 Matthias Clasen - 1:2.21.1-1 - Update to 2.21.1 glom-1.6.7-1.fc9 ---------------- * Tue Jan 29 2008 Denis Leroy - 1.6.7-1 - Update to upstream 1.6.7, bugfix release, BR versions updated gnome-desktop-2.21.90-2.fc9 --------------------------- * Tue Jan 29 2008 Soren Sandmann - 2.21.5-2 - uncomment stuff from gnome-common in configure.in * Tue Jan 29 2008 Soren Sandmann - 2.21.5-2 - Don't buildrequire gtk-doc - Install randrwrap.h * Tue Jan 29 2008 Soren Sandmann - 2.21.5-2 - Add randrwrap.[ch] gnome-games-1:2.21.90-1.fc9 --------------------------- * Tue Jan 29 2008 Matthias Clasen - 1:2.21.90-1 - Update to 2.21.90 * Tue Jan 15 2008 Matthias Clasen - 1:2.21.5-1 - Update to 2.21.5 * Tue Dec 18 2007 Matthias Clasen - 1:2.21.4-1 - Update to 2.21.4 gnome-keyring-2.21.90-1.fc9 --------------------------- * Tue Jan 29 2008 Matthias Clasen - 2.21.90-1 - Update to 2.21.90 gnome-panel-2.21.90-2.fc9 ------------------------- * Tue Jan 29 2008 Matthias Clasen - 2.21.90-1 - Update to 2.21.90 - Drop upstreamed patch gnome-session-2.21.90-1.fc9 --------------------------- * Tue Jan 29 2008 Matthias Clasen - 2.21.90-1 - Update to 2.21.90 gnome-settings-daemon-2.21.90.1-1.fc9 ------------------------------------- * Tue Jan 29 2008 - Bastien Nocera - 2.21.90.1-1 - Update to 2.21.90.1 * Tue Jan 29 2008 - Bastien Nocera - 2.21.90-1 - Update to 2.21.90 gnuplot-4.2.2-9.fc9 ------------------- * Tue Jan 29 2008 Ivana Varekova - 4.2.2-9 - spec file cleanup gstreamer-plugins-base-0.10.16-1.fc9 ------------------------------------ * Tue Jan 29 2008 - Bastien Nocera - 0.10.16-1 - Update to 0.10.16 gtk2-2.12.7-1.fc9 ----------------- * Wed Jan 30 2008 Matthias Clasen - 2.12.7-1 - Update to 2.12.7 * Tue Jan 29 2008 Matthias Clasen - 2.12.6-1 - Update to 2.12.6 * Tue Jan 08 2008 Matthias Clasen - 2.12.5-1 - Update to 2.12.5 gtkmm24-2.12.4-1.fc9 -------------------- * Tue Jan 29 2008 Denis Leroy - 2.12.4-1 - Update to upstream 2.12.4, includes gcc 4.3 build fix gtksourceview2-2.1.1-1.fc9 -------------------------- * Tue Jan 29 2008 Matthias Clasen - 2.1.1-1 - Update to 2.1.1 gvfs-0.1.6-1.fc9 ---------------- * Tue Jan 29 2008 Matthias Clasen - 0.1.6-1 - Update to 0.1.6 hardinfo-0.4.2.3-3.fc9 ---------------------- * Tue Jan 29 2008 Adel Gadllah 0.4.2.3-3 - Rebuild for new libsoup * Mon Nov 05 2007 Adel Gadllah 0.4.2.3-2 - Use --delete-original for desktopfile installation innotop-1.6.0-1.fc9 ------------------- * Tue Jan 29 2008 Michael Fleming 1.6.0-1 - New upstream release. - Update License kernel-2.6.24-9.fc9 ------------------- * Tue Jan 29 2008 John W. Linville - A few more wireless fixes for 2.6.25 - Some post-2.6.25 wireless updates - Actually, we support the new b43 firmware... libIDL-0.8.10-1.fc9 ------------------- * Tue Jan 29 2008 Matthias Clasen - 0.8.10-1 - Update to 0.8.10 libbonobo-2.20.4-1.fc9 ---------------------- * Tue Jan 29 2008 Matthias Clasen - 2.20.4-1 - Update to 2.20.4 libbonoboui-2.21.90-1.fc9 ------------------------- * Tue Jan 29 2008 Matthias Clasen - 2.21.90-1 - Update to 2.21.90 libepc-0.3.4-1.fc9 ------------------ * Tue Jan 29 2008 Brian Pepple - 0.3.4-1 - Update to 0.3.4. - Add BR on perl-xml-parser & gettext. - Bump min version of libsoup. libgnome-2.21.90-1.fc9 ---------------------- * Tue Jan 29 2008 Matthias Clasen - 2.21.90-1 - Update to 2.21.90 * Wed Jan 16 2008 Matthias Clasen - 2.20.1-4 - Make gvfs the default filechooser backend * Tue Dec 18 2007 Matthias Clasen - 2.20.1-3 - Add schema for gtk-im-module GConf key libgnomecups-0.2.3-1.fc9 ------------------------ * Tue Jan 29 2008 Matthias Clasen - 0.2.3-1 - Update to 0.2.3 libgnomeprint22-2.18.3-1.fc9 ---------------------------- * Tue Jan 29 2008 Matthias Clasen - 2.18.3-1 - Update to 2.18.3 libgnomeui-2.21.90-1.fc9 ------------------------ * Tue Jan 29 2008 Matthias Clasen - 2.21.90-1 - Update to 2.21.90 * Mon Jan 14 2008 Matthias Clasen - 2.21.5-1 - Update to 2.21.5 * Sat Dec 22 2007 Matthias Clasen - 2.20.1.1-2 - Add the gvfs filechooser backend libgnomeuimm26-2.20.1-1.fc9 --------------------------- * Tue Jan 29 2008 Denis Leroy - 2.20.1-1 - Update to upstream 2.20.1, gcc 4.3 fixes - BR versions update libselinux-2.0.50-1.fc9 ----------------------- * Tue Jan 29 2008 Dan Walsh - 2.0.50-1 - Update to Upstream * Merged fix for audit2why from Dan Walsh. libsemanage-2.0.18-1.fc9 ------------------------ * Tue Jan 29 2008 Dan Walsh - 2.0.18-1 - Update to upstream * Fix spurious out of memory error reports. * Merged second version of fix for genhomedircon handling from Caleb Case. logjam-1:4.5.3-10.fc9 --------------------- * Tue Jan 29 2008 Tom "spot" Callaway 1:4.5.3-10 - rebuild for new libsoup lvm2-2.02.32-8.fc9 ------------------ * Tue Jan 29 2008 Alasdair Kergon > - 2.02.32-8 - Fix pvs, vgs, lvs error exit status on some error paths. - Fix new parameter validation in vgsplit and test mode. - Fix internal metadata corruption in lvchange --resync. man-pages-2.76-1.fc9 -------------------- * Tue Jan 29 2008 Ivana Varekova - 2.76-1 - update to 2.76 - add new option to prctl man page * Fri Jan 11 2008 Ivana Varekova - 2.75-2 - update crypt.3 man page * Fri Jan 11 2008 Ivana Varekova - 2.75-1 - update to 2.75 - remove fs page patch mirage-0.9.2-1.fc9 ------------------ * Wed Jan 30 2008 Mamoru Tasaka - 0.9.2-1 - 0.9.2 nasm-2.01-1.fc9 --------------- * Tue Jan 29 2008 Petr Machata - 2.01-1 - rebase to a new stable upstream version 2.01 ndesk-dbus-0.6.1a-1.fc9 ----------------------- * Wed Jan 30 2008 David Nielsen - 0.6.1a-1 - Bump to 0.6.1a openoffice.org-1:2.4.0-5.1.fc9 ------------------------------ * Mon Jan 28 2008 Caolan McNamara - 1:2.4.0-5.1 - next milestone - replace cairotext with workspace.cairotext01.patch, not use SAL_DISABLE_CAIROTEXT=1 to disable as cairo text rendering is now default - add openoffice.org-2.4.0.ooo85643.psprint.helppreviewers.patch to help gv/evince rotate landscape pages when previewing - drop integrated workspace.sw24bf02.patch - drop integrated openoffice.org-2.4.0.ooo85055.psprint.linetoolong.patch - drop integrated openoffice.org-2.4.0.ooo85487.evoconnectivity.patch * Wed Jan 23 2008 Caolan McNamara - 1:2.4.0-4.1 - next milestone - drop integrated openoffice.org-2.4.0.ooo83410.solenv.renameserbian.patch - drop integrated openoffice.org-2.3.1.ooo83877.sal.allowsoftlinkdelete.patch - drop integrated workspace.sw8u10bf04.patch - drop integrated workspace.impress132.patch - add openoffice.org-2.4.0.ooo85487.evoconnectivity.patch to make evoab2 build - new finnish autocorrect file - Resolves: rhbz#429897 one click print with lpr-only backend fix - Resolves: rhbz#426295 openoffice.org-2.4.0.ooo85470.vcl.cairotext.patch use export SAL_ENABLE_CAIROTEXT=1 to enable * Mon Jan 21 2008 Caolan McNamara - 1:2.4.0-3.3 - fix openoffice.org-2.4.0.ooo85321.vcl.pixmapleak.patch for warren - fix openoffice.org-2.4.0.ooo85429.sw.a11ycrash.patch - Resolves: rhbz#428574 add workspace.sw24bf02.patch - Resolves: problem in rhbz#429550 openoffice.org-2.4.0.ooo85448.emptyrpath.patch openvpn-2.1-0.24.rc7.fc9 ------------------------ * Tue Jan 29 2008 Steven Pritchard 2.1-0.24.rc7 - Update to 2.1_rc7 - Drop BETA21-userpriv-fixups.patch (upstream) orca-2.21.90-1.fc9 ------------------ * Tue Jan 29 2008 Matthias Clasen - 2.21.90-1 - Update to 2.21.90 pango-1.19.3-2.fc9 ------------------ * Tue Jan 29 2008 Behdad Esfahbod - 1.19.3-2 - Bump libthai requirement. planner-0.14.2-11.fc9 --------------------- * Tue Jan 29 2008 Caolan McNamara - 0.14.2-11 - rebuild for deps policycoreutils-2.0.41-1.fc9 ---------------------------- * Tue Jan 29 2008 Dan Walsh 2.0.41-1 - Update to upstream * Merged audit2why fix and semanage boolean --on/--off/-1/-0 support from Dan Walsh. * Merged a second fixfiles -C fix from Marshall Miller. poppler-0.6.4-2.fc9 ------------------- * Tue Jan 29 2008 Matthias Clasen - 0.6.4-2 - Add some required inter-subpackge deps * Tue Jan 29 2008 Matthias Clasen - 0.6.4-1 - Update to 0.6.4 - Split off poppler-glib python-TestGears-0.2-7.fc9 -------------------------- * Tue Jan 29 2008 Luke Macken 0.2-7 - Fix broken URL (Bug #427645) python-numeric-24.2-9.fc9 ------------------------- * Tue Jan 29 2008 Matthew Barnes - 24.2-9 - Fix python-setuptools build requirement (RH bug #226345). quagga-0:0.99.9-4.fc9 --------------------- * Tue Jan 29 2008 Martin Nagy - 0.99.9-4 - check port number range when using -P or -p (#206071) rb_libtorrent-0.12-3.fc9 ------------------------ * Mon Jan 28 2008 Peter Gordon - 0.12-3 - Add upstream patch (changeset 1968) to fix potential security vulnerability: malformed messages passed through the bdecode_recursive routine could cause a potential stack overflow. + svn1968-bdecode_recursive-security-fix.patch rhythmbox-0.11.4-5.fc9 ---------------------- * Tue Jan 29 2008 Matthias Clasen - 0.11.4-5 - Port to libsoup 2.4 ruby-gnome2-0.16.0-26.fc9 ------------------------- * Wed Jan 30 2008 Mamoru Tasaka 0.16.0-26 - Add BR: poppler-glib-devel setools-3.3.2-2.fc9 ------------------- * Tue Jan 29 2008 Chris Pebenito 3.3.2-2.fc9 - Bump to pick up new libsepol and policy 22. swfdec-0.5.90-1.fc9 ------------------- * Tue Jan 29 2008 Brian Pepple - 0.5.90-1 - Update to 0.5.90. - Bump BR minimum versions for libsoup & pango. swfdec-gnome-2.21.90-1.fc9 -------------------------- * Tue Jan 29 2008 Brian Pepple - 2.21.90-1 - Update to 2.21.90. - Add man pages. - Update version of swfdec needed. swfdec-mozilla-0.5.90-1.fc9 --------------------------- * Tue Jan 29 2008 Brian Pepple - 0.5.90-1 - Update to 0.5.90. syslog-ng-2.0.7-2.fc9 --------------------- * Tue Jan 29 2008 Douglas E. Warner 2.0.7-2 - added patch from git commit a8b9878ab38b10d24df7b773c8c580d341b22383 to fix log rotation (bug#430057) system-config-nfs-1.3.37-1.fc9 ------------------------------ * Tue Jan 29 2008 Nils Philippsen - 1.3.37-1 - fix distinguishing between BR: rarian-compat and BR: scrollkeeper system-config-samba-1.2.61-1.fc9 -------------------------------- * Tue Jan 29 2008 Nils Philippsen - 1.2.61-1 - migrate online help to yelp/Docbook XML tomboy-0.9.5-1.fc9 ------------------ * Tue Jan 29 2008 Matthias Clasen - 0.9.5-1 - Update to 0.9.5 totem-pl-parser-2.21.91-2.fc9 ----------------------------- * Tue Jan 29 2008 - Matthew Barnes - 2.21.21-2 - Rebuild against newer libcamel-1.2. uncrustify-0.43-2.fc9 --------------------- * Tue Jan 29 2008 Neal Becker - 0.43-2 - Remove explicit dep libstdc++ * Tue Jan 29 2008 Neal Becker - 0.43-1 - Update to 0.43 vinagre-0.4.90-1.fc9 -------------------- * Tue Jan 29 2008 Matthias Clasen - 0.4.90-1 - Update to 0.4.90 vino-2.21.90-1.fc9 ------------------ * Tue Jan 29 2008 Matthias Clasen - 2.21.90-1 - Update to 2.21.90 xorg-x11-server-1.4.99.1-0.19.20080107.fc9 ------------------------------------------ * Tue Jan 29 2008 Adam Tkac 1.4.99.1-0.19 - added dix/protocol.txt to source subpackage * Fri Jan 18 2008 Dave Airlie 1.4.99.1-0.18 - cve-2007-6429.patch: Fix patch to not break java apps * Fri Jan 18 2008 Dave Airlie 1.4.99.1-0.17 - cve-2007-5760.patch: XFree86-Misc Extension Invalid Array Index Vulnerability - cve-2007-6427.patch: XInput Extension Memory Corruption Vulnerability - cve-2007-6428.patch: TOG-CUP Extension Memory Corruption Vulnerability - cve-2007-6429.patch: EVI and MIT-SHM Extension Integer Overflow Vulnerability - cve-2008-0006-server-fixup.patch: PCF Font Vulnerability - this patch isn't strictly required with new version of libXfont. yum-utils-1.1.11-1.fc9 ---------------------- * Wed Jan 30 2008 Tim Lauridsen - mark as 1.1.11 * Sun Jan 13 2008 Seth Vidal - add repodiff Broken deps for i386 ---------------------------------------------------------- bmpx-0.40.13-7.fc9.i386 requires libsoup-2.2.so.8 buoh-0.8.2-2.fc7.i386 requires libsoup-2.2.so.8 compiz-kde-0.6.2-6.fc9.i386 requires libkdecorations.so.1 drivel-2.1.1-0.3.20071130svn.fc9.i386 requires libsoup-2.2.so.8 epiphany-extensions-2.20.1-3.fc9.i386 requires libgtkembedmoz.so epiphany-extensions-2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 evolution-brutus-1.1.28.7-2.fc8.i386 requires libcamel-1.2.so.10 evolution-webcal-2.12.0-1.fc8.i386 requires libsoup-2.2.so.8 gnome-web-photo-0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo-0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo-0.3-8.fc9.i386 requires libgtkembedmoz.so gnome-web-photo-0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 kazehakase-0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 kicker-compiz-3.5.4-4.fc8.i386 requires libkickermain.so.1 kicker-compiz-3.5.4-4.fc8.i386 requires libtaskmanager.so.1 libsyncml-0.4.5-1.fc9.i386 requires libsoup-2.2.so.8 libtranslate-0.99-12.fc9.i386 requires libsoup-2.2.so.8 mail-notification-evolution-plugin-5.0-0.2.rc1.fc9.i386 requires libcamel-provider-1.2.so.10 mail-notification-evolution-plugin-5.0-0.2.rc1.fc9.i386 requires libcamel-1.2.so.10 muine-0.8.8-6.fc9.i386 requires mono(muine-plugin) = 0:1.0.0.0 seahorse-2.21.4-3.fc9.i386 requires libsoup-2.2.so.8 totem-publish-2.21.90-2.fc9.i386 requires libsoup-2.2.so.8 twitux-0.60-2.fc9.i386 requires libsoup-2.2.so.8 Broken deps for x86_64 ---------------------------------------------------------- bmpx-0.40.13-7.fc9.x86_64 requires libsoup-2.2.so.8()(64bit) buoh-0.8.2-2.fc7.x86_64 requires libsoup-2.2.so.8()(64bit) compiz-kde-0.6.2-6.fc9.x86_64 requires libkdecorations.so.1()(64bit) drivel-2.1.1-0.3.20071130svn.fc9.x86_64 requires libsoup-2.2.so.8()(64bit) epiphany-extensions-2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) epiphany-extensions-2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 evolution-brutus-1.1.28.7-2.fc8.i386 requires libcamel-1.2.so.10 evolution-brutus-1.1.28.7-2.fc8.x86_64 requires libcamel-1.2.so.10()(64bit) evolution-webcal-2.12.0-1.fc8.x86_64 requires libsoup-2.2.so.8()(64bit) gnome-web-photo-0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) gnome-web-photo-0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo-0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo-0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) kazehakase-0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 kicker-compiz-3.5.4-4.fc8.x86_64 requires libkickermain.so.1()(64bit) kicker-compiz-3.5.4-4.fc8.x86_64 requires libtaskmanager.so.1()(64bit) libsyncml-0.4.5-1.fc9.i386 requires libsoup-2.2.so.8 libsyncml-0.4.5-1.fc9.x86_64 requires libsoup-2.2.so.8()(64bit) libtranslate-0.99-12.fc9.i386 requires libsoup-2.2.so.8 libtranslate-0.99-12.fc9.x86_64 requires libsoup-2.2.so.8()(64bit) mail-notification-evolution-plugin-5.0-0.2.rc1.fc9.x86_64 requires libcamel-1.2.so.10()(64bit) mail-notification-evolution-plugin-5.0-0.2.rc1.fc9.x86_64 requires libcamel-provider-1.2.so.10()(64bit) muine-0.8.8-6.fc9.x86_64 requires mono(muine-plugin) = 0:1.0.0.0 seahorse-2.21.4-3.fc9.i386 requires libsoup-2.2.so.8 seahorse-2.21.4-3.fc9.x86_64 requires libsoup-2.2.so.8()(64bit) totem-publish-2.21.90-2.fc9.x86_64 requires libsoup-2.2.so.8()(64bit) twitux-0.60-2.fc9.x86_64 requires libsoup-2.2.so.8()(64bit) Broken deps for ppc ---------------------------------------------------------- bmpx-0.40.13-7.fc9.ppc requires libsoup-2.2.so.8 buoh-0.8.2-2.fc7.ppc requires libsoup-2.2.so.8 compiz-kde-0.6.2-6.fc9.ppc requires libkdecorations.so.1 drivel-2.1.1-0.3.20071130svn.fc9.ppc requires libsoup-2.2.so.8 epiphany-extensions-2.20.1-3.fc9.ppc requires libgtkembedmoz.so epiphany-extensions-2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 evolution-brutus-1.1.28.7-2.fc8.ppc requires libcamel-1.2.so.10 evolution-brutus-1.1.28.7-2.fc8.ppc64 requires libcamel-1.2.so.10()(64bit) evolution-webcal-2.12.0-1.fc8.ppc requires libsoup-2.2.so.8 gnome-web-photo-0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo-0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo-0.3-8.fc9.ppc requires libgtkembedmoz.so gnome-web-photo-0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 kazehakase-0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 kicker-compiz-3.5.4-4.fc8.ppc requires libkickermain.so.1 kicker-compiz-3.5.4-4.fc8.ppc requires libtaskmanager.so.1 libsyncml-0.4.5-1.fc9.ppc requires libsoup-2.2.so.8 libsyncml-0.4.5-1.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) libtranslate-0.99-12.fc9.ppc requires libsoup-2.2.so.8 libtranslate-0.99-12.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) mail-notification-evolution-plugin-5.0-0.2.rc1.fc9.ppc requires libcamel-provider-1.2.so.10 mail-notification-evolution-plugin-5.0-0.2.rc1.fc9.ppc requires libcamel-1.2.so.10 monodevelop-0.17-4.fc9.ppc requires boo muine-0.8.8-6.fc9.ppc requires mono(muine-plugin) = 0:1.0.0.0 seahorse-2.21.4-3.fc9.ppc requires libsoup-2.2.so.8 seahorse-2.21.4-3.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) totem-publish-2.21.90-2.fc9.ppc requires libsoup-2.2.so.8 twitux-0.60-2.fc9.ppc requires libsoup-2.2.so.8 Broken deps for ppc64 ---------------------------------------------------------- bmpx-0.40.13-7.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) buoh-0.8.2-2.fc7.ppc64 requires libsoup-2.2.so.8()(64bit) drivel-2.1.1-0.3.20071130svn.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) epiphany-extensions-2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) epiphany-extensions-2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 evolution-brutus-1.1.28.7-2.fc8.ppc64 requires libcamel-1.2.so.10()(64bit) evolution-webcal-2.12.0-1.fc8.ppc64 requires libsoup-2.2.so.8()(64bit) gnome-web-photo-0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) gnome-web-photo-0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo-0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo-0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) kazehakase-0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 kicker-compiz-3.5.4-4.fc8.ppc64 requires libkickermain.so.1()(64bit) kicker-compiz-3.5.4-4.fc8.ppc64 requires libtaskmanager.so.1()(64bit) libsyncml-0.4.5-1.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) libtranslate-0.99-12.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) mail-notification-evolution-plugin-5.0-0.2.rc1.fc9.ppc64 requires libcamel-1.2.so.10()(64bit) mail-notification-evolution-plugin-5.0-0.2.rc1.fc9.ppc64 requires libcamel-provider-1.2.so.10()(64bit) perl-Test-AutoBuild-darcs-1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 seahorse-2.21.4-3.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) totem-publish-2.21.90-2.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) twitux-0.60-2.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) From joachim.frieben at googlemail.com Wed Jan 30 14:52:00 2008 From: joachim.frieben at googlemail.com (Joachim Frieben) Date: Wed, 30 Jan 2008 15:52:00 +0100 Subject: Cannot access the Hardware Clock via any known method In-Reply-To: <200801300939.21297.sgrubb@redhat.com> References: <200801300846.41420.sgrubb@redhat.com> <47A089ED.3020101@hhs.nl> <200801300939.21297.sgrubb@redhat.com> Message-ID: <1c252d490801300652i2ff37e42p989a7df91025f575@mail.gmail.com> On Jan 30, 2008 3:39 PM, Steve Grubb wrote: > > Thanks for the info. I joined the bug. This bug makes rawhide hard to use > for > development work because autotools complains about the timestamp being in > the > future. Some things also refuse to build. > > -Steve In the meantime, if you're on a network, enable NTP and checkmark "Synchronize system clock before starting service". This doesn't solve the issue but at least corrects the time offset [+1 hour at every reboot in my case] at an early stage of the boot procedure. This should allow you to go on without being bothered by error messages like the ones you have reported. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwilson at redhat.com Wed Jan 30 14:53:40 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 30 Jan 2008 09:53:40 -0500 Subject: Cannot access the Hardware Clock via any known method In-Reply-To: <22848.192.54.193.53.1201704020.squirrel@rousalka.dyndns.org> References: <200801300846.41420.sgrubb@redhat.com> <22848.192.54.193.53.1201704020.squirrel@rousalka.dyndns.org> Message-ID: <200801300953.40749.jwilson@redhat.com> On Wednesday 30 January 2008 09:40:20 am Nicolas Mailhot wrote: > Le Mer 30 janvier 2008 15:05, Rex Dieter a ?crit : > > yep, spot and I chatted about this @ FUDCon, his guess was that > > hwclock was > > running too early, possibly before udev had a chance to > > create /dev/rtc. ?? > > I think I don't have this message with my home-built mm kernels, so > it's probably a mistake in rawhide's kernel config (IIRC there are two > rtc stacks in the kernel now and you get this message if you build the > wrong one, or both) The new cmos rtc driver was getting built as a module, rather than staticly into the kernel. Chuck checked in fixes yesterday, so some forthcoming rawhide kernel should be all good. -- Jarod Wilson jwilson at redhat.com From j.w.r.degoede at hhs.nl Wed Jan 30 15:00:15 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 30 Jan 2008 16:00:15 +0100 Subject: Cannot access the Hardware Clock via any known method In-Reply-To: <200801300953.40749.jwilson@redhat.com> References: <200801300846.41420.sgrubb@redhat.com> <22848.192.54.193.53.1201704020.squirrel@rousalka.dyndns.org> <200801300953.40749.jwilson@redhat.com> Message-ID: <47A090FF.3050002@hhs.nl> Jarod Wilson wrote: > On Wednesday 30 January 2008 09:40:20 am Nicolas Mailhot wrote: >> Le Mer 30 janvier 2008 15:05, Rex Dieter a ?crit : >>> yep, spot and I chatted about this @ FUDCon, his guess was that >>> hwclock was >>> running too early, possibly before udev had a chance to >>> create /dev/rtc. ?? >> I think I don't have this message with my home-built mm kernels, so >> it's probably a mistake in rawhide's kernel config (IIRC there are two >> rtc stacks in the kernel now and you get this message if you build the >> wrong one, or both) > > The new cmos rtc driver was getting built as a module, rather than staticly > into the kernel. Chuck checked in fixes yesterday, so some forthcoming > rawhide kernel should be all good. > wrong, the new driver has a different major/minor number, so having the new driver not build as a module is part of the solution, but not the complete solution, see: https://bugzilla.redhat.com/show_bug.cgi?id=290731 For the full story about the major/minor no issue. Regards, Hans From jonstanley at gmail.com Wed Jan 30 14:59:44 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Wed, 30 Jan 2008 09:59:44 -0500 Subject: How much personal information is necessary to close a bug? In-Reply-To: <364d303b0801300332i4bd4a2b9n28a0f5b9eb3271b@mail.gmail.com> References: <1201686688.13318.4.camel@fedlex.lex.hider.name> <364d303b0801300251s39ffe2b8we671f2005c836474@mail.gmail.com> <1201691235.13318.13.camel@fedlex.lex.hider.name> <364d303b0801300332i4bd4a2b9n28a0f5b9eb3271b@mail.gmail.com> Message-ID: On Jan 30, 2008 6:32 AM, Christopher Brown wrote: > Now I think of it, it may have something to do with code > contributions, copyright assertion, etc etc. It does. If you were to for example write some documentation for how to fix something, etc, then we couldn't use it, because the CLA assigns copyright to Red Hat with regard to things that you do for the Fedora Project. Not an unreasonable request. It's also required for the same reasons as above to gain edit access to the wiki, which is also part and parcel of triaging. > Perhaps fall-out from SCO case. Nah. > Anyway, if you can ping either of the two above in #fedora-qa, > their handles are poelcat and jds2001 they will be able to set you up > quicker I believe. If you want to live at Lolly Pop Lane, by all means > :) Saw your ping, just woke up myself :) From dwinship at redhat.com Wed Jan 30 15:01:35 2008 From: dwinship at redhat.com (Dan Winship) Date: Wed, 30 Jan 2008 10:01:35 -0500 Subject: Libsoup troubles in rawhide (compat-libsoup22 needed) In-Reply-To: References: <479F655F.2010000@odu.neva.ru> Message-ID: <47A0914F.2030709@redhat.com> Alex Lancaster wrote: > Here's the full list of packages broken either directly or indirectly > by this change: Hm... I'd done a "repoquery --whatrequires libsoup" and only came up with 2 non-GNOME packages (libtranslate, which I've now sent the patch for to Dmitry, and libsyncml, which I've submitted a patch upstream for, http://libsyncml.opensync.org/ticket/130). Apparently repoquery lies though. :-/ > bmpx-0.40.13-7.fc9.i386 requires libsoup-2.2.so.8 > buoh-0.8.2-2.fc7.i386 requires libsoup-2.2.so.8 > drivel-2.1.1-0.3.20071130svn.fc9.i386 requires libsoup-2.2.so.8 > hardinfo-0.4.2.3-1.fc9.i386 requires libsoup-2.2.so.8 > 1:logjam-4.5.3-9.fc8.3.i386 requires libsoup-2.2.so.8 > twitux-0.60-2.fc9.i386 requires libsoup-2.2.so.8 I'll look in to these. In the meantime, libsoup 2.4 and 2.2 are supposed to be parallel-installable (although as of libsoup 2.3.0.1, they aren't completely, because of conflicting documentation files), so a compat package would work. -- Dan From loupgaroublond at gmail.com Wed Jan 30 15:04:23 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 30 Jan 2008 10:04:23 -0500 Subject: How much personal information is necessary to close a bug? In-Reply-To: <1201691235.13318.13.camel@fedlex.lex.hider.name> References: <1201686688.13318.4.camel@fedlex.lex.hider.name> <364d303b0801300251s39ffe2b8we671f2005c836474@mail.gmail.com> <1201691235.13318.13.camel@fedlex.lex.hider.name> Message-ID: <7f692fec0801300704oc6cf53g6e7ac16b3d7c3d93@mail.gmail.com> On Jan 30, 2008 6:07 AM, Lex Hider wrote: > I think that meeting is around 4am local time, so I may have to give it > a miss. Perhaps you could put on the agenda how high the barrier for > entry is. Not only do I have to create a separate Fedora account aside > form the bugzilla that I have, I have to give out my personal details, > and then I have to learn enough about gpg to make a key to sign up for > the account. Sometimes people forget that projects like Fedora don't exist in that dark/gray side of the internet just because it's revolutionary open source software. To give you an analogy, think about the details that go into a property transfer between two businesses. Both businesses need to be registered with the state = registration is bugzilla and FAS A Notary needs to assert the identity of both representatives and their right to represent their business = PGP key Full names and addresses need to go on the device of transfer, (or whatever it's called, aka the contract) = Full address and name. You're expected to know these things being a citizen of the US (or similar laws for other countries), and in fact these things should be taught with civics classes in high school. If you're really rich, you have a private lawyer that explains these things, but then a lawyer would have you just sign the CLA for Fedora, and be done with it. > If I have to jump through all the above hoops just to close trivial > bugs, I'm not sure if I'll bother. Sorry, that's life. Honestly, it can't be much easier than it is already. > I can see no reason why anyone would need my address and phone number. > What is stopping anyone from putting in fake ones. Theoretically no, but if some bad things happen, like a copyright lawsuit, the courts will be looking for you. This isn't a bad thing, but they just need to see you're a real person, wrote real code or documentation, and exist at the very real address you represented yourself as living at. If that address is fake, IANAL, but I think that counts as some very minor perjury. This information isn't exactly public to one and all either. Red Hat certainly isn't selling your private details to the highest bidder. If there's one thing you mention, it's that perhaps all FAS accounts should get an automatic bugzilla account. Given the number of steps to get that done though, it seems pretty trivial. -Yaakov From j.w.r.degoede at hhs.nl Wed Jan 30 15:17:06 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 30 Jan 2008 16:17:06 +0100 Subject: Cannot access the Hardware Clock via any known method In-Reply-To: <47A090FF.3050002@hhs.nl> References: <200801300846.41420.sgrubb@redhat.com> <22848.192.54.193.53.1201704020.squirrel@rousalka.dyndns.org> <200801300953.40749.jwilson@redhat.com> <47A090FF.3050002@hhs.nl> Message-ID: <47A094F2.70707@hhs.nl> Hans de Goede wrote: > Jarod Wilson wrote: >> On Wednesday 30 January 2008 09:40:20 am Nicolas Mailhot wrote: >>> Le Mer 30 janvier 2008 15:05, Rex Dieter a ?crit : >>>> yep, spot and I chatted about this @ FUDCon, his guess was that >>>> hwclock was >>>> running too early, possibly before udev had a chance to >>>> create /dev/rtc. ?? >>> I think I don't have this message with my home-built mm kernels, so >>> it's probably a mistake in rawhide's kernel config (IIRC there are two >>> rtc stacks in the kernel now and you get this message if you build the >>> wrong one, or both) >> >> The new cmos rtc driver was getting built as a module, rather than >> staticly into the kernel. Chuck checked in fixes yesterday, so some >> forthcoming rawhide kernel should be all good. >> > > wrong, Erm I guess that sounds a bit more harsh then intented sorry. I always get a bit cranky when I take the time to thoroughly study and document a problem and others start making semi usefull comments without first reading the fine bug. Regards, Hans From jkeating at redhat.com Wed Jan 30 15:16:50 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 30 Jan 2008 10:16:50 -0500 Subject: Libsoup troubles in rawhide (compat-libsoup22 needed) In-Reply-To: <47A0914F.2030709@redhat.com> References: <479F655F.2010000@odu.neva.ru> <47A0914F.2030709@redhat.com> Message-ID: <20080130101650.39739927@redhat.com> On Wed, 30 Jan 2008 10:01:35 -0500 Dan Winship wrote: > Hm... I'd done a "repoquery --whatrequires libsoup" and only came up > with 2 non-GNOME packages (libtranslate, which I've now sent the patch > for to Dmitry, and libsyncml, which I've submitted a patch upstream > for, http://libsyncml.opensync.org/ticket/130). Apparently repoquery > lies though. :-/ you need to pass --alldeps so that automatically added library requirements come up. Otherwise you'll just get things that explicitly Require: libsoup. --alldeps check non-explicit dependencies (files and Provides:) as well -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Mon Jan 28 14:26:27 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 28 Jan 2008 15:26:27 +0100 Subject: long term support release In-Reply-To: <80d7e4090801280551i27fcd04ete8917756766df9fc@mail.gmail.com> References: <1201058211.3001.79.camel@gandalf.cobite.com> <47979470.6010507@leemhuis.info> <1201150608.17905.78.camel@beck.corsepiu.local> <20080124081720.GA2636@free.fr> <1201166022.17905.109.camel@beck.corsepiu.local> <1201198306.17905.117.camel@beck.corsepiu.local> <1201249261.17905.239.camel@beck.corsepiu.local> <479DC8BF.8090805@redhat.com> <80d7e4090801280551i27fcd04ete8917756766df9fc@mail.gmail.com> Message-ID: <1201530387.3242.122.camel@beck.corsepiu.local> On Mon, 2008-01-28 at 06:51 -0700, Stephen John Smoogen wrote: > On Jan 28, 2008 5:21 AM, Christopher Aillon wrote: > > On 01/25/2008 03:21 AM, Ralf Corsepius wrote: > > > I wouldn't choose Linux to control a spacecraft or a nuclear power > > > plant, but I didn't hesitate to chose Linux to control robots in a lab, > > > nor do I hesitate to chose Fedora to host "my personal mission's" > > > mission-critical data" ;) > > > > That's just you. Some people[1] think it's okay to let Linux control a > > spacecraft[2]. /me wonders which cpu they are going to use. > > [1] http://www.nasa.gov > > [2] http://www.linuxdevices.com/news/NS5714800202.html > > > > More than just NASA... a good many satellites from many countries (JP > and I think 1 or 2 Euro countries) I am aware about several of these ;) > and some of the planned rovers use > linux. Though none of them have been COTS as these articles say. c.f. http://www.rtems.org Ralf From jon.nettleton at gmail.com Wed Jan 30 15:46:16 2008 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Wed, 30 Jan 2008 10:46:16 -0500 Subject: F9 for Eeepc In-Reply-To: <47A08781.70303@fedoraproject.org> References: <479A650D.8060401@cora.nwra.com> <1201304569.2057.22.camel@localhost.localdomain> <645d17210801251629y2811f3f7jf0886a166ffd2f8@mail.gmail.com> <479E7137.5020705@cora.nwra.com> <47A08781.70303@fedoraproject.org> Message-ID: <1201707976.3882.59.camel@birkoff> On Wed, 2008-01-30 at 19:49 +0530, Rahul Sundaram wrote: > Jon Nettleton wrote: > > > > > For other eeepc users I just wanted to mention that I hacked on > > devilspie to include matching on the geometry attributes of a window. > > Long story short you can use it now to say if a window is taller than > > 480 pixels you can either set it to resize smaller or maximize > > vertically. > > > > This still doesn't work for dialog's yet, I am looking at gtk and a > > few other places that I might hack around fixes to make them fit on > > the small resolution better. > > FYI, there was a discussion in > > https://www.redhat.com/archives/fedora-advisory-board/2008-January/msg00277.html > > If you are interested in contacting them for merging back changes, let > the board know. > Thanks for the heads up. I am not directly working with the Eeedora project. I am really most interested in getting the most functional low resolution desktop as possible. Xfce is fine, however I find that desktop environment a bit restrictive. Here is the environment I am building/using right now on my eeepc ( by the way this is > 2GB's ). I know I know, but I am more interested in functionality than space. 1) Devilspie to better customize size and position of windows. Overly large windows are still problematic and I am trying methods to fix this. I am thinking maybe scaling the window with a compositing manager might be the way to go. Oh and some kind of gui to configure devilspie, it is said that one doesn't exist yet. I am thinking angelcake would be a good name. 2) Provide the best functionality for a low res screen. This includes things such as, changing nautilus default icon view to 75%, defaulting to "Icons only" for gtk Toolbar buttons, etc etc. 3) Use Avant-Window-Navigator by default for the lower bar. Awn has a behaviour which can be set so it drops behind windows that cover it and then comes forward when you bring the mouse to the bottom of the screen. This behaviour is excellent for a low res screen. 4) Update asus_acpi so it provides input events that can be configured by hal for the acpi keys. This will allow things like the volume up and down to work out of the box and give the nice composited gnome onscreen hints. 5) Provide better on and off control for the Microphone and Webcam. I am thinking awn plugins for now, but I am not sure. 6) Boot speed - It has got to be fast fast fast. I think that is enough for now. I don't plan on using the fedora branding on my project as I plan to break enough stuff out of the fedora repos that it won't be acceptable. Hopefully this project will be more of a test bed of what a streamlined desktop can be rather than a "Spin" Jon From fedora at camperquake.de Wed Jan 30 15:47:16 2008 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 30 Jan 2008 16:47:16 +0100 Subject: rawhide report: 20080130 changes In-Reply-To: <200801301448.m0UEmLso016720@porkchop.devel.redhat.com> References: <200801301448.m0UEmLso016720@porkchop.devel.redhat.com> Message-ID: <20080130164716.3ed1f8e3@dhcp03.addix.net> Hi. On Wed, 30 Jan 2008 09:48:21 -0500, Build System wrote: > kernel-2.6.24-9.fc9 > ------------------- > * Tue Jan 29 2008 John W. Linville > - A few more wireless fixes for 2.6.25 > - Some post-2.6.25 wireless updates > - Actually, we support the new b43 firmware... the -PAE package for this is 202MB in size, which can't be right. From jwilson at redhat.com Wed Jan 30 15:57:18 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 30 Jan 2008 10:57:18 -0500 Subject: rawhide report: 20080130 changes In-Reply-To: <20080130164716.3ed1f8e3@dhcp03.addix.net> References: <200801301448.m0UEmLso016720@porkchop.devel.redhat.com> <20080130164716.3ed1f8e3@dhcp03.addix.net> Message-ID: <200801301057.18153.jwilson@redhat.com> On Wednesday 30 January 2008 10:47:16 am Ralf Ertzinger wrote: > Hi. > > On Wed, 30 Jan 2008 09:48:21 -0500, Build System wrote: > > kernel-2.6.24-9.fc9 > > ------------------- > > * Tue Jan 29 2008 John W. Linville > > - A few more wireless fixes for 2.6.25 > > - Some post-2.6.25 wireless updates > > - Actually, we support the new b43 firmware... > > the -PAE package for this is 202MB in size, which can't be right. Ew, something is whacked out... kernel.i686, kernel-PAE.i686 and kernel.ppc are all in the 200MB range. kernel.x86_64 and kernel.ppc64 look fine though. Investibigating... -- Jarod Wilson jwilson at redhat.com From jwilson at redhat.com Wed Jan 30 16:00:12 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 30 Jan 2008 11:00:12 -0500 Subject: rawhide report: 20080130 changes In-Reply-To: <200801301057.18153.jwilson@redhat.com> References: <200801301448.m0UEmLso016720@porkchop.devel.redhat.com> <20080130164716.3ed1f8e3@dhcp03.addix.net> <200801301057.18153.jwilson@redhat.com> Message-ID: <200801301100.12565.jwilson@redhat.com> On Wednesday 30 January 2008 10:57:18 am Jarod Wilson wrote: > On Wednesday 30 January 2008 10:47:16 am Ralf Ertzinger wrote: > > Hi. > > > > On Wed, 30 Jan 2008 09:48:21 -0500, Build System wrote: > > > kernel-2.6.24-9.fc9 > > > ------------------- > > > * Tue Jan 29 2008 John W. Linville > > > - A few more wireless fixes for 2.6.25 > > > - Some post-2.6.25 wireless updates > > > - Actually, we support the new b43 firmware... > > > > the -PAE package for this is 202MB in size, which can't be right. > > Ew, something is whacked out... kernel.i686, kernel-PAE.i686 and kernel.ppc > are all in the 200MB range. kernel.x86_64 and kernel.ppc64 look fine > though. Investibigating... Something is horked with debug stripping. All the massive kernels have unnaturally small -debuginfo packages. We'll get that fixed... -- Jarod Wilson jwilson at redhat.com From jwilson at redhat.com Wed Jan 30 16:02:48 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 30 Jan 2008 11:02:48 -0500 Subject: Cannot access the Hardware Clock via any known method In-Reply-To: <47A094F2.70707@hhs.nl> References: <200801300846.41420.sgrubb@redhat.com> <47A090FF.3050002@hhs.nl> <47A094F2.70707@hhs.nl> Message-ID: <200801301102.48158.jwilson@redhat.com> On Wednesday 30 January 2008 10:17:06 am Hans de Goede wrote: > Hans de Goede wrote: > > Jarod Wilson wrote: > >> On Wednesday 30 January 2008 09:40:20 am Nicolas Mailhot wrote: > >>> Le Mer 30 janvier 2008 15:05, Rex Dieter a ?crit : > >>>> yep, spot and I chatted about this @ FUDCon, his guess was that > >>>> hwclock was > >>>> running too early, possibly before udev had a chance to > >>>> create /dev/rtc. ?? > >>> > >>> I think I don't have this message with my home-built mm kernels, so > >>> it's probably a mistake in rawhide's kernel config (IIRC there are two > >>> rtc stacks in the kernel now and you get this message if you build the > >>> wrong one, or both) > >> > >> The new cmos rtc driver was getting built as a module, rather than > >> staticly into the kernel. Chuck checked in fixes yesterday, so some > >> forthcoming rawhide kernel should be all good. > > > > wrong, > > Erm > > I guess that sounds a bit more harsh then intented sorry. I always get a > bit cranky when I take the time to thoroughly study and document a problem > and others start making semi usefull comments without first reading the > fine bug. Heh, no problem. No, I didn't read the bug, but I also didn't throw out all the comments I should have... Bill was talking to Chuck about it, and the device node major/minor number issue was also discussed, and should be fixed in initscripts to go along with the fixed kernel. -- Jarod Wilson jwilson at redhat.com From zcerza at redhat.com Wed Jan 30 16:19:09 2008 From: zcerza at redhat.com (Zack Cerza) Date: Wed, 30 Jan 2008 11:19:09 -0500 Subject: some package splits In-Reply-To: <1201615452.2793.6.camel@localhost.localdomain> References: <1201615452.2793.6.camel@localhost.localdomain> Message-ID: <47A0A37D.4070803@redhat.com> Matthias Clasen wrote: > Last night I built a new evince, and since evince backends are modular > now, I've split off the dvi and djvu backends as subpackages, evince-dvi > and evince-djvu. This allows us to avoid the extra dependencies on the > live cd that those backends would drag in. I've made the new subpackages > installed by default in comps, but you may have to manually install them > if you are updating from an older version of evince. > > Another package split is that there is now a poppler-glib (and > -glib-devel) package. Please adjust your dependencies accordingly. > > > Matthias > Very cool; now evince only wants djvulibre and qt installed, instead of all of texlive. But I can't help but wonder, is there a way to shave off qt? Zack From chasd at silveroaks.com Wed Jan 30 16:39:47 2008 From: chasd at silveroaks.com (chasd) Date: Wed, 30 Jan 2008 10:39:47 -0600 Subject: Debian style net-install ISOs (from FudCON Raleigh) In-Reply-To: <20080130031925.B53027309C@hormel.redhat.com> References: <20080130031925.B53027309C@hormel.redhat.com> Message-ID: <4D808F8F-7AE6-4420-A33B-F733AC1B5B0E@silveroaks.com> > John Reiser wrote: >> Les Mikesell wrote: >> >> Reasonable proxy behavior would mostly fix that. > > A base + software development install for x86 is about 3GB on disk, > or 1.5GB on install media. Many proxies don't cache that much, > so the savings usually are not so large. To get an idea of how this relates to the _default_ Squid settings : #Default: # cache_dir ufs /var/spool/squid 100 16 256 That 100 in the above config line means 100 MB of storage maximum. The "ufs" in that config line means if squid is blocked on disk I/O it will not attempt to cache any other requests until unblocked. There are other options, but that is the default. If you have your squid cache on an ext3 partition ( the default ) there is quite a bit of blocking for the kjournald. Using ext2 performs much better. #Default: # maximum_object_size 4096 KB I think that line is obvious, it means a lot of RPMs won't be cached at all. I won't get into the specific settings for determining what gets purged from the cache as new requests roll in. Basically, the default settings are more likely to purge large files ( most RPMs ) in order to allow many small files to remain cached. So the _default_ squid settings are almost worthless for caching RPMs either for updates or installs. That is not to say that squid could not have a configuration optimized for caching RPMs. However, for many people it is much easier to install InstantMirror or something like it than learn the ins and outs of squid configuration and tweak those settings. You will get better performance easier with an actual local mirror. Admins in larger organizations are more likely to spend the effort to set up a mirror on their local network, or even twiddle with cache settings if that is the solution best for them. Anything that can be done to encourage less experienced or less clueful admins to set up local mirrors is a Good Thing. At the very least it improves the update / install experience and reduces stress on internet mirrors. I can't think of any negatives to local mirrors off the top of my head. Charles Dostale From dennis at ausil.us Wed Jan 30 17:05:49 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 30 Jan 2008 11:05:49 -0600 Subject: Build failure due to make -j8 In-Reply-To: <1201518155.3590.9.camel@localhost.localdomain> References: <1201518155.3590.9.camel@localhost.localdomain> Message-ID: <200801301105.49914.dennis@ausil.us> On Monday 28 January 2008, G?rard Milmeister wrote: > I was trying to build a new release of genius, but the build failed due > to unsatisifed make dependencies on machines that use make -j8 or make > -j4 instead of the usual make -j2 and indeed when I tried make -j8 on > my (uni-processor) machine, it failed too. The package is automake > based. Has this behavior been observed with other packages? Could it be > a problem with make or automake, or would it be specific to the package > only? > > G?rard most likely its in your package. going fowrawd we will see in the build system -j32 and quite probably -j64 what generally happens is that things get built out of order with the higher thread count. Dennis From bpepple at fedoraproject.org Wed Jan 30 17:11:59 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 30 Jan 2008 12:11:59 -0500 Subject: Plan for tomorrows (20080131) FESCO meeting Message-ID: <1201713119.2398.5.camel@nixon> Hi, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Thursday at 18:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCO-Meeting -- sponsor nominations -- Ruben Kerkhof - https://www.redhat.com/archives/fedora-devel-list/2008-January/msg02116.html /topic FESCo-Meeting -- New Features - http://fedoraproject.org/wiki/Features/Dashboard - poelcat * http://fedoraproject.org/wiki/Anaconda/Features/SecondStageInstallSource * http://fedoraproject.org/wiki/Releases/FeatureEncryptedFilesystems * http://fedoraproject.org/wiki/Features/PreUpgrade /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule (I can't promise we will get to it tomorrow). You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. If your name/nick is on above list please update the status on the Extras schedule pages in the wiki ahead of the meeting. That way all the other FESCo members and interested contributors know what up ahead of the meeting. And we will avoid long delays in the meeting -- those often arise if someone describes the recent happenings on a topic directly in the meeting while all the others have to wait for his slow typing... Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mclasen at redhat.com Wed Jan 30 17:13:46 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 30 Jan 2008 12:13:46 -0500 Subject: some package splits In-Reply-To: <47A0A37D.4070803@redhat.com> References: <1201615452.2793.6.camel@localhost.localdomain> <47A0A37D.4070803@redhat.com> Message-ID: <1201713226.2957.2.camel@localhost.localdomain> On Wed, 2008-01-30 at 11:19 -0500, Zack Cerza wrote: > Matthias Clasen wrote: > > Last night I built a new evince, and since evince backends are modular > > now, I've split off the dvi and djvu backends as subpackages, evince-dvi > > and evince-djvu. This allows us to avoid the extra dependencies on the > > live cd that those backends would drag in. I've made the new subpackages > > installed by default in comps, but you may have to manually install them > > if you are updating from an older version of evince. > > > > Another package split is that there is now a poppler-glib (and > > -glib-devel) package. Please adjust your dependencies accordingly. > > > > > > Matthias > > > > Very cool; now evince only wants djvulibre and qt installed, instead of > all of texlive. But I can't help but wonder, is there a way to shave off qt? evince-djvu is split out, too. From notting at redhat.com Wed Jan 30 17:14:51 2008 From: notting at redhat.com (Bill Nottingham) Date: Wed, 30 Jan 2008 12:14:51 -0500 Subject: Cannot access the Hardware Clock via any known method In-Reply-To: <200801301102.48158.jwilson@redhat.com> References: <200801300846.41420.sgrubb@redhat.com> <47A090FF.3050002@hhs.nl> <47A094F2.70707@hhs.nl> <200801301102.48158.jwilson@redhat.com> Message-ID: <20080130171451.GE6250@nostromo.devel.redhat.com> Jarod Wilson (jwilson at redhat.com) said: > Heh, no problem. No, I didn't read the bug, but I also didn't throw out all > the comments I should have... Bill was talking to Chuck about it, and the > device node major/minor number issue was also discussed, and should be fixed > in initscripts to go along with the fixed kernel. The device node is a mkinitrd thing. Bill From notting at redhat.com Wed Jan 30 17:21:01 2008 From: notting at redhat.com (Bill Nottingham) Date: Wed, 30 Jan 2008 12:21:01 -0500 Subject: Cannot access the Hardware Clock via any known method In-Reply-To: <47A089ED.3020101@hhs.nl> References: <200801300846.41420.sgrubb@redhat.com> <47A089ED.3020101@hhs.nl> Message-ID: <20080130172101.GF6250@nostromo.devel.redhat.com> Hans de Goede (j.w.r.degoede at hhs.nl) said: > I'm no where near sure that this is the correct fix. I wonder if /dev/rtc > is needed during the initrd at all, and if it isn't I think that the initrd > should not create it all. Then rc.sysinit should be modified to run hwclock > after udev, or if there are reasons not to, create the /dev entry and load > the driver itself. The idea is to set the clock as early as possible, to ensure coordination among log messages, etc. After udev by definition isn't as early as possible. That being said, we *could*: - move clock setting later - set the clock from a udev rule Ideally, we could use the kernel support for automatically setting the clock when the rtc driver is initialized, but that would require everyone to have their clocks set in UTC, or have the kernel reading a userspace config file. Bill From Christian.Iseli at licr.org Wed Jan 30 17:24:54 2008 From: Christian.Iseli at licr.org (Christian Iseli) Date: Wed, 30 Jan 2008 18:24:54 +0100 Subject: Fedora Package Status of Jan 30, 2008 Message-ID: <20080130182454.2cd636d2@ludwig-alpha.unil.ch> Hi folks, PackageStatus page updated. The NEW review queue seems to be improving. And the number of open bugs seems to have gone slightly down, but it still looks like many BZ tickets are in need of some loving care. Someone should plan a small party when we reach the magical 10000 binary rpms (I hope for release 10... so we have reached the fourth dimension) :) Cheers, Christian ==== Fedora Package Status of Jan 30, 2008 The full report can be found here: http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus Owners stats: - 5634 packages - 9260 binary rpms in devel - 96 orphans - 61 packages not available in devel or release Axel dot Thimm at ATrpms dot net arpack Matt_Domsch at dell dot com efibootmgr ajackson at redhat dot com xorg-x11-drv-wiimote alexl at users dot sourceforge dot net sqlite2 andreas at bawue dot net perl-HTML-CalendarMonthSimple andreas at bawue dot net ngircd bdpepple at gmail dot com galago-filesystem bdpepple at gmail dot com gaim-galago caolanm at redhat dot com hunspell-he cweyl at alumni dot drew dot edu perl-HTML-Tidy cweyl at alumni dot drew dot edu gaim-gaym davidz at redhat dot com redhat-artwork dbhole at redhat dot com dom2-core-tests dennis at ausil dot us prtconf dennis at ausil dot us silo devrim at commandprompt dot com postgresql-pgpool-ha dgoodwin at dangerouslyinc dot com scapy dlehman at redhat dot com system-config-kdump j dot w dot r dot degoede at hhs dot nl nogravity j dot w dot r dot degoede at hhs dot nl nogravity-data jafo at tummy dot com python-mechanoid jkeating at redhat dot com tux jmp at safe dot ca clement jorton at redhat dot com libc-client jorton at redhat dot com newt-perl kwizart at gmail dot com xorg-x11-drv-ivtv kwizart at gmail dot com ivtv-firmware matthias at rpmforge dot net glusterfs matthias at rpmforge dot net csync2 mchristi at redhat dot com isns-utils mmaslano at redhat dot com cronie mpg at redhat dot com sugar-evince nhosoi at redhat dot com fedora-ds-console nhosoi at redhat dot com fedora-ds nhosoi at redhat dot com fedora-ds-admin-console nhosoi at redhat dot com fedora-idm-console noah at coderanger dot net rainbow noah at coderanger dot net python-olpcgames oliver at linux-kernel dot at aboot overholt at redhat dot com eclipse-nlspackager overholt at redhat dot com eclipse-sdk-nls paul at all-the-johnsons dot co dot uk mysql-connector-net pertusus at free dot fr ivman pknirsch at redhat dot com freeimpi rcritten at redhat dot com ipa rdieter at math dot unl dot edu pykdeextensions richard at hughsie dot com ohm rmeggins at redhat dot com fedora-ds-admin rmeggins at redhat dot com idm-console-framework rpm at greysector dot net freefem++ ruben at rubenkerkhof dot com perl-mogilefs-server rvokal at redhat dot com gaim-guifications splinux25 at gmail dot com drapes than at redhat dot com kde-l10n tmraz at redhat dot com openssl097a twaugh at redhat dot com desktop-printing vivekl at redhat dot com saxon8 vivekl at redhat dot com classpathx-jaxp wtogami at redhat dot com firefox-32 wtogami at redhat dot com ldm yufanyufan at gmail dot com audacious-plugins-docklet - 5 packages not available in devel but present in release andreas dot bierfert at lowlatency dot de multisync andreas dot bierfert at lowlatency dot de libopensync-plugin-synce gauret at free dot fr pdftohtml lvm-team at redhat dot com device-mapper mmahut at redhat dot com libopensync-plugin-sunbird - 7 packages which have not yet been FE-ACCEPT'd... https://bugzilla.redhat.com/buglist.cgi?bug_id=222191,231861,239184 eclipse ben at bagu.org cyrus-imapd tjanouse at redhat.com libdc1394 kwizart at gmail.com https://bugzilla.redhat.com/buglist.cgi?bug_id=221717,224458,250970,252049 agg caolanm at redhat.com libsilc wtogami at redhat.com ivtv-firmware axel.thimm at atrpms.net asm2 vivekl at redhat.com - 2 packages present in the development repo which have no owners entry mogilefs-server s390utils - 6 orphaned packages, yet available in devel avahi cgi-util gkrellm-weather libdaemon thinkfinger windowlab FE-ACCEPT packages stats: - 3978 accepted, closed package reviews - 50 accepted, closed package reviews not in repo - 16 accepted, closed package reviews not in owners - 66 accepted, open package reviews older than 4 weeks; - 64 accepted, open package reviews with a package already in the repo FE-REVIEW packages stats: - 250 open tickets - 117 tickets with no activity in eight weeks - 20 tickets with no activity in four weeks - 36 closed tickets FE-NEW packages stats: - 719 open tickets - 510 tickets with no activity in eight weeks - 31 tickets with no activity in four weeks FE-NEEDSPONSOR packages stats: - 27 open tickets - 2 tickets with no activity in eight weeks FE-Legal packages stats: - 9 open tickets - 3 tickets with no activity in eight weeks - 1 tickets with no activity in four weeks FE-GUIDELINES packages stats: - 46 open tickets OPEN-BUGS packages stats: - 9527 open tickets - 6544 tickets with no activity in eight weeks - 1000 tickets with no activity in four weeks CVS stats: - 5638 packages with a devel directory - 4 packages with no owners entry F-8 glibc32 glibc64 tdma - 290 packages were dropped from Fedora Maintainers stats: - 475 maintainers - 31 inactive maintainers with open bugs - 29 inactive maintainers Dropped Fedora packages: - 111 packages were dropped since Fedora 7 Comps.xml files stats: - 2648 packages in comps-f9 file - 1377 packages missing from comps-f9 file - 10 packages in comps-f9 but not in repo - 2657 packages in comps-f8 file - 1296 packages missing from comps-f8 file - 7 packages in comps-f8 but not in repo From ssorce at redhat.com Wed Jan 30 17:35:07 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 30 Jan 2008 12:35:07 -0500 Subject: Cannot access the Hardware Clock via any known method In-Reply-To: <20080130172101.GF6250@nostromo.devel.redhat.com> References: <200801300846.41420.sgrubb@redhat.com> <47A089ED.3020101@hhs.nl> <20080130172101.GF6250@nostromo.devel.redhat.com> Message-ID: <1201714507.3269.7.camel@localhost.localdomain> On Wed, 2008-01-30 at 12:21 -0500, Bill Nottingham wrote: > Hans de Goede (j.w.r.degoede at hhs.nl) said: > > I'm no where near sure that this is the correct fix. I wonder if /dev/rtc > > is needed during the initrd at all, and if it isn't I think that the initrd > > should not create it all. Then rc.sysinit should be modified to run hwclock > > after udev, or if there are reasons not to, create the /dev entry and load > > the driver itself. > > The idea is to set the clock as early as possible, to ensure coordination > among log messages, etc. After udev by definition isn't as early as > possible. > > That being said, we *could*: > - move clock setting later > - set the clock from a udev rule > > Ideally, we could use the kernel support for automatically setting the > clock when the rtc driver is initialized, but that would require everyone > to have their clocks set in UTC, or have the kernel reading a userspace > config file. Wouldn't be bad to start requiring to have the clock in UTC. But I guess dual-boot systems are the problem ? Simo. -- Simo Sorce * Red Hat, Inc * New York From katzj at redhat.com Wed Jan 30 17:40:14 2008 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 30 Jan 2008 12:40:14 -0500 Subject: Cannot access the Hardware Clock via any known method In-Reply-To: <1201714507.3269.7.camel@localhost.localdomain> References: <200801300846.41420.sgrubb@redhat.com> <47A089ED.3020101@hhs.nl> <20080130172101.GF6250@nostromo.devel.redhat.com> <1201714507.3269.7.camel@localhost.localdomain> Message-ID: <1201714814.7533.5.camel@aglarond.local> On Wed, 2008-01-30 at 12:35 -0500, Simo Sorce wrote: > > Ideally, we could use the kernel support for automatically setting the > > clock when the rtc driver is initialized, but that would require everyone > > to have their clocks set in UTC, or have the kernel reading a userspace > > config file. > > Wouldn't be bad to start requiring to have the clock in UTC. > But I guess dual-boot systems are the problem ? Yes. Jeremy From cra at WPI.EDU Wed Jan 30 17:56:47 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 30 Jan 2008 12:56:47 -0500 Subject: F9 Alpha spinning In-Reply-To: <20080130064005.GQ23022@crow> References: <20080125162835.GA19048@crow> <20080126220523.GA3054@crow> <20080130064005.GQ23022@crow> Message-ID: <20080130175647.GA5633@angus.ind.WPI.EDU> On Wed, Jan 30, 2008 at 01:40:05AM -0500, Luke Macken wrote: > Latest f9-alpha live bits. It looks like our i686 GNOME/KDE spins can now > fit on a CD. Ship it! :) > > diff between F8-Live-i686 and F9-Alpha-i686-20080129.0.iso > > removed package evince: 3452782 Now that evince-dvi and evince-dejavu are split out, can we put evince back pretty please? It would be a shame to not have this. From lesmikesell at gmail.com Wed Jan 30 18:01:02 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 30 Jan 2008 12:01:02 -0600 Subject: Debian style net-install ISOs (from FudCON Raleigh) In-Reply-To: <4D808F8F-7AE6-4420-A33B-F733AC1B5B0E@silveroaks.com> References: <20080130031925.B53027309C@hormel.redhat.com> <4D808F8F-7AE6-4420-A33B-F733AC1B5B0E@silveroaks.com> Message-ID: <47A0BB5E.7030109@gmail.com> chasd wrote: >>> >>> Reasonable proxy behavior would mostly fix that. >> > > So the _default_ squid settings are almost worthless for caching RPMs > either for updates or installs. That is not to say that squid could not > have a configuration optimized for caching RPMs. However, for many > people it is much easier to install InstantMirror or something like it > than learn the ins and outs of squid configuration and tweak those > settings. You will get better performance easier with an actual local > mirror. Changing squid defaults would help with any large repeated downloads. What does InstantMirror do for you if you use some other distro/versions. > Admins in larger organizations are more likely to spend the effort to > set up a mirror on their local network, or even twiddle with cache > settings if that is the solution best for them. Anything that can be > done to encourage less experienced or less clueful admins to set up > local mirrors is a Good Thing. At the very least it improves the update > / install experience and reduces stress on internet mirrors. I can't > think of any negatives to local mirrors off the top of my head. Admins in larger (even small) organizations aren't likely to be particularly married to fedora or anything that needs extra per distro/per version work. If you want stuff to be cached locally, make it work right with a generic setup that will help with all large repeated downloads and document what that setup should be - or make a squid config package to make it even easier. -- Les Mikesell lesmikesell at gmail.com From kevin.kofler at chello.at Wed Jan 30 17:59:24 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 30 Jan 2008 17:59:24 +0000 (UTC) Subject: Debian style net-install ISOs (from FudCON Raleigh) References: <479FB05C.30302@redhat.com> Message-ID: Michael DeHaan redhat.com> writes: > Fedora could really use Debian style net install ISOs. > > For those unfamiliar with the concept ... assume a minimally sized image > that is enough to start up a net install for all content. We already have that, it's called boot.iso. Kevin Kofler From tibbs at math.uh.edu Wed Jan 30 17:59:22 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 30 Jan 2008 11:59:22 -0600 Subject: Fedora Package Status of Jan 30, 2008 In-Reply-To: <20080130182454.2cd636d2@ludwig-alpha.unil.ch> References: <20080130182454.2cd636d2@ludwig-alpha.unil.ch> Message-ID: >>>>> "CI" == Christian Iseli writes: CI> FE-NEW packages stats: CI> - 719 open tickets CI> - 510 tickets with no activity in eight weeks CI> - 31 tickets with no activity in four weeks Note: this includes merge reviews. Outside of the merge reviews on the hit list (https://bugzilla.redhat.com/bugzilla/426387) most reviewers are concentrating on the non-merge review tickets as neglecting these potentially loses us both community members and new software. Out of the 720 non-tracker Package Review tickets with no fedora-review flag set that happened to be there when I looked, 487 of them were merge reviews, leaving 233 review tickets, and of those 46 are blocked waiting on guidelines. (There are almost certainly more which should be marked as such.) This includes all of the Java packages. Plus there are quite a few which are unreviewable for other reasons (submitter not responding, submitter has been informed that package is unacceptable but refuses to fix it, etc.) So on the whole we're actually doing really well. It's only the merge reviews and the unreviewable Java package dump that make the figure seem so large. CI> FE-NEEDSPONSOR packages stats: CI> - 27 open tickets CI> - 2 tickets with no activity in eight weeks BTW, those two tickets are https://bugzilla.redhat.com/192436 and https://bugzilla.redhat.com/250747 if anyone wants to have a look. I have pinged most of the really old tickets already but never got around to those two. - J< From dan at danny.cz Wed Jan 30 18:00:08 2008 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Wed, 30 Jan 2008 19:00:08 +0100 Subject: Cannot access the Hardware Clock via any known method In-Reply-To: <1201714507.3269.7.camel@localhost.localdomain> References: <200801300846.41420.sgrubb@redhat.com> <47A089ED.3020101@hhs.nl> <20080130172101.GF6250@nostromo.devel.redhat.com> <1201714507.3269.7.camel@localhost.localdomain> Message-ID: <1201716008.3249.16.camel@eagle.danny.cz> > > Ideally, we could use the kernel support for automatically setting the > > clock when the rtc driver is initialized, but that would require everyone > > to have their clocks set in UTC, or have the kernel reading a userspace > > config file. > > Wouldn't be bad to start requiring to have the clock in UTC. > But I guess dual-boot systems are the problem ? Depends on the second system, some reading is at http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html Dan From jkeating at redhat.com Wed Jan 30 17:57:21 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 30 Jan 2008 12:57:21 -0500 Subject: F9 Alpha spinning In-Reply-To: <20080130175647.GA5633@angus.ind.WPI.EDU> References: <20080125162835.GA19048@crow> <20080126220523.GA3054@crow> <20080130064005.GQ23022@crow> <20080130175647.GA5633@angus.ind.WPI.EDU> Message-ID: <20080130125721.3f7fa722@redhat.com> On Wed, 30 Jan 2008 12:56:47 -0500 Chuck Anderson wrote: > Now that evince-dvi and evince-dejavu are split out, can we put > evince back pretty please? It would be a shame to not have this. We can look again at Beta timeframe, and use between now and then to find ways to get evince to fit. Always the losing game. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From trond.danielsen at gmail.com Wed Jan 30 18:13:03 2008 From: trond.danielsen at gmail.com (Trond Danielsen) Date: Wed, 30 Jan 2008 19:13:03 +0100 Subject: Headsup: New libopenraw version heading for rawhide. Message-ID: <409676c70801301013u199882ddr6b8e1dfdbbba663b@mail.gmail.com> Hi, a new version of libopenraw should appear in rawhide any time soon. The new version changes the soname of libopenrawgnome.so from 1.2.0 to 1.3.0. Applications that depend on this library should take necessary actions to adjust to the changes. Regards, -- Trond Danielsen From jwilson at redhat.com Wed Jan 30 18:20:16 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 30 Jan 2008 13:20:16 -0500 Subject: Cannot access the Hardware Clock via any known method In-Reply-To: <20080130171451.GE6250@nostromo.devel.redhat.com> References: <200801300846.41420.sgrubb@redhat.com> <200801301102.48158.jwilson@redhat.com> <20080130171451.GE6250@nostromo.devel.redhat.com> Message-ID: <200801301320.16288.jwilson@redhat.com> On Wednesday 30 January 2008 12:14:51 pm Bill Nottingham wrote: > Jarod Wilson (jwilson at redhat.com) said: > > Heh, no problem. No, I didn't read the bug, but I also didn't throw out > > all the comments I should have... Bill was talking to Chuck about it, and > > the device node major/minor number issue was also discussed, and should > > be fixed in initscripts to go along with the fixed kernel. > > The device node is a mkinitrd thing. Oops, my bad, ASSumed it was in intscripts. ;) -- Jarod Wilson jwilson at redhat.com From j.w.r.degoede at hhs.nl Wed Jan 30 18:24:01 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 30 Jan 2008 19:24:01 +0100 Subject: Cannot access the Hardware Clock via any known method In-Reply-To: <200801301320.16288.jwilson@redhat.com> References: <200801300846.41420.sgrubb@redhat.com> <200801301102.48158.jwilson@redhat.com> <20080130171451.GE6250@nostromo.devel.redhat.com> <200801301320.16288.jwilson@redhat.com> Message-ID: <47A0C0C1.5020805@hhs.nl> Jarod Wilson wrote: > On Wednesday 30 January 2008 12:14:51 pm Bill Nottingham wrote: >> Jarod Wilson (jwilson at redhat.com) said: >>> Heh, no problem. No, I didn't read the bug, but I also didn't throw out >>> all the comments I should have... Bill was talking to Chuck about it, and >>> the device node major/minor number issue was also discussed, and should >>> be fixed in initscripts to go along with the fixed kernel. >> The device node is a mkinitrd thing. > > > Oops, my bad, ASSumed it was in intscripts. ;) > Try reading the bug report :) There even is a proposed fix in there for mkinitrd. I've tried to push fixes into mkinitrd and / or nash in the past and found it a painful experience, so my fix could use some backup from people close(r) to pjones. Once more its all here: https://bugzilla.redhat.com/show_bug.cgi?id=290731 Regards, Hans From j.w.r.degoede at hhs.nl Wed Jan 30 18:29:56 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 30 Jan 2008 19:29:56 +0100 Subject: F9 Alpha spinning In-Reply-To: <20080130125721.3f7fa722@redhat.com> References: <20080125162835.GA19048@crow> <20080126220523.GA3054@crow> <20080130064005.GQ23022@crow> <20080130175647.GA5633@angus.ind.WPI.EDU> <20080130125721.3f7fa722@redhat.com> Message-ID: <47A0C224.5090301@hhs.nl> Jesse Keating wrote: > On Wed, 30 Jan 2008 12:56:47 -0500 > Chuck Anderson wrote: > >> Now that evince-dvi and evince-dejavu are split out, can we put >> evince back pretty please? It would be a shame to not have this. > > We can look again at Beta timeframe, and use between now and then to > find ways to get evince to fit. Always the losing game. > I guess that the livecd currently includes perl? perl is quite large, maybe with some effort we can drop it? I'm willing to create proposal patches for any packages on the livecd requiring perl. Can someone with a livecd image handy do "rpm -e perl" on it and see how large the list of dep errors thrown is? Regards, Hans From notting at redhat.com Wed Jan 30 18:37:01 2008 From: notting at redhat.com (Bill Nottingham) Date: Wed, 30 Jan 2008 13:37:01 -0500 Subject: F9 Alpha spinning In-Reply-To: <47A0C224.5090301@hhs.nl> References: <20080125162835.GA19048@crow> <20080126220523.GA3054@crow> <20080130064005.GQ23022@crow> <20080130175647.GA5633@angus.ind.WPI.EDU> <20080130125721.3f7fa722@redhat.com> <47A0C224.5090301@hhs.nl> Message-ID: <20080130183701.GA12877@nostromo.devel.redhat.com> Hans de Goede (j.w.r.degoede at hhs.nl) said: > I'm willing to create proposal patches for any packages on the livecd > requiring perl. Can someone with a livecd image handy do "rpm -e perl" on > it and see how large the list of dep errors thrown is? error: Failed dependencies: perl(:MODULE_COMPAT_5.8.8) is needed by (installed) perl-Date-Manip-5.48-1.fc9.noarch perl(:MODULE_COMPAT_5.8.8) is needed by (installed) perl-String-CRC32-1.4-3.fc8.i386 perl(:MODULE_COMPAT_5.8.8) is needed by (installed) pilot-link-0.12.3-6.fc9.i386 perl(:MODULE_COMPAT_5.8.8) is needed by (installed) foomatic-3.0.2-53.fc9.i386 perl(AutoLoader) is needed by (installed) pilot-link-0.12.3-6.fc9.i386 perl(Carp) is needed by (installed) pilot-link-0.12.3-6.fc9.i386 perl(Cwd) is needed by (installed) genisoimage-1.1.6-6.fc8.i386 perl(Cwd) is needed by (installed) foomatic-3.0.2-53.fc9.i386 perl(Data::Dumper) is needed by (installed) foomatic-3.0.2-53.fc9.i386 perl(Digest::MD5) is needed by (installed) pilot-link-0.12.3-6.fc9.i386 perl(Digest::MD5) is needed by (installed) lftp-3.5.14-3.fc9.i386 perl(DynaLoader) is needed by (installed) perl-String-CRC32-1.4-3.fc8.i386 perl(DynaLoader) is needed by (installed) pilot-link-0.12.3-6.fc9.i386 perl(Encode) is needed by (installed) foomatic-3.0.2-53.fc9.i386 perl(Exporter) is needed by (installed) perl-Date-Manip-5.48-1.fc9.noarch perl(Exporter) is needed by (installed) perl-String-CRC32-1.4-3.fc8.i386 perl(Exporter) is needed by (installed) pilot-link-0.12.3-6.fc9.i386 perl(Exporter) is needed by (installed) foomatic-3.0.2-53.fc9.i386 perl(Exporter) is needed by (installed) logwatch-7.3.6-17.fc9.noarch perl(File::Basename) is needed by (installed) genisoimage-1.1.6-6.fc8.i386 perl(File::Basename) is needed by (installed) gstreamer-plugins-base-0.10.15-3.fc9.i386 perl(File::Path) is needed by (installed) genisoimage-1.1.6-6.fc8.i386 perl(File::Temp) is needed by (installed) logwatch-7.3.6-17.fc9.noarch perl(FileHandle) is needed by (installed) foomatic-3.0.2-53.fc9.i386 perl(Getopt::Long) is needed by (installed) genisoimage-1.1.6-6.fc8.i386 perl(Getopt::Long) is needed by (installed) libbonobo-2.20.3-1.fc9.i386 perl(Getopt::Long) is needed by (installed) foomatic-3.0.2-53.fc9.i386 perl(Getopt::Long) is needed by (installed) logwatch-7.3.6-17.fc9.noarch perl(Getopt::Std) is needed by (installed) ntp-4.2.4p4-2.fc9.i386 perl(Getopt::Std) is needed by (installed) pilot-link-0.12.3-6.fc9.i386 perl(Getopt::Std) is needed by (installed) foomatic-3.0.2-53.fc9.i386 perl(Getopt::Std) is needed by (installed) stunnel-4.20-5.i386 perl(IO::File) is needed by (installed) vpnc-0.5.1-2.fc9.i386 perl(IO::Handle) is needed by (installed) foomatic-3.0.2-53.fc9.i386 perl(IO::Select) is needed by (installed) pilot-link-0.12.3-6.fc9.i386 perl(IO::Socket) is needed by (installed) pilot-link-0.12.3-6.fc9.i386 perl(List::Util) is needed by (installed) genisoimage-1.1.6-6.fc8.i386 perl(POSIX) is needed by (installed) foomatic-3.0.2-53.fc9.i386 perl(POSIX) is needed by (installed) stunnel-4.20-5.i386 perl(POSIX) is needed by (installed) numactl-1.0.2-2.fc9.i386 perl(POSIX) is needed by (installed) logwatch-7.3.6-17.fc9.noarch perl(Socket) is needed by (installed) ntp-4.2.4p4-2.fc9.i386 perl(Text::ParseWords) is needed by (installed) evolution-2.21.5-2.fc9.i386 perl(Time::Local) is needed by (installed) pilot-link-0.12.3-6.fc9.i386 perl(diagnostics) is needed by (installed) evolution-2.21.5-2.fc9.i386 perl(getopts.pl) is needed by (installed) ghostscript-8.61-6.fc9.i386 perl(integer) is needed by (installed) perl-Date-Manip-5.48-1.fc9.noarch perl(sigtrap) is needed by (installed) foomatic-3.0.2-53.fc9.i386 perl(strict) is needed by (installed) genisoimage-1.1.6-6.fc8.i386 perl(strict) is needed by (installed) perl-Date-Manip-5.48-1.fc9.noarch perl(strict) is needed by (installed) pilot-link-0.12.3-6.fc9.i386 perl(strict) is needed by (installed) foomatic-3.0.2-53.fc9.i386 perl(strict) is needed by (installed) vpnc-0.5.1-2.fc9.i386 perl(strict) is needed by (installed) logwatch-7.3.6-17.fc9.noarch perl(strict) is needed by (installed) fonts-KOI8-R-1.0-10.fc8.noarch perl(strict) is needed by (installed) evolution-2.21.5-2.fc9.i386 perl(vars) is needed by (installed) perl-Date-Manip-5.48-1.fc9.noarch perl(vars) is needed by (installed) ntp-4.2.4p4-2.fc9.i386 perl(vars) is needed by (installed) foomatic-3.0.2-53.fc9.i386 perl(warnings) is needed by (installed) vpnc-0.5.1-2.fc9.i386 perl >= 4:5.8.1 is needed by (installed) genisoimage-1.1.6-6.fc8.i386 perl >= 0:5.000 is needed by (installed) perl-Date-Manip-5.48-1.fc9.noarch perl >= 3:5.8.1 is needed by (installed) foomatic-3.0.2-53.fc9.i386 perl is needed by (installed) libgnomeprint22-2.18.2-1.fc8.i386 perl = 4:5.8.8-31.fc9 is needed by (installed) perl-libs-5.8.8-31.fc9.i386 perl is needed by (installed) nss-mdns-0.10-3.fc8.i386 /usr/bin/perl is needed by (installed) genisoimage-1.1.6-6.fc8.i386 /usr/bin/perl is needed by (installed) libbonobo-2.20.3-1.fc9.i386 /usr/bin/perl is needed by (installed) ghostscript-8.61-6.fc9.i386 /usr/bin/perl is needed by (installed) ntp-4.2.4p4-2.fc9.i386 /usr/bin/perl is needed by (installed) pilot-link-0.12.3-6.fc9.i386 /usr/bin/perl is needed by (installed) foomatic-3.0.2-53.fc9.i386 /usr/bin/perl is needed by (installed) vpnc-0.5.1-2.fc9.i386 /usr/bin/perl is needed by (installed) cups-1.3.5-2.fc9.i386 /usr/bin/perl is needed by (installed) isdn4k-utils-3.2-56.fc9.i386 /usr/bin/perl is needed by (installed) lftp-3.5.14-3.fc9.i386 /usr/bin/perl is needed by (installed) stunnel-4.20-5.i386 /usr/bin/perl is needed by (installed) numactl-1.0.2-2.fc9.i386 /usr/bin/perl is needed by (installed) fbset-2.1-24.fc7.i386 /usr/bin/perl is needed by (installed) enscript-1.6.4-8.fc8.i386 /usr/bin/perl is needed by (installed) logwatch-7.3.6-17.fc9.noarch /usr/bin/perl is needed by (installed) fonts-KOI8-R-1.0-10.fc8.noarch /usr/bin/perl is needed by (installed) gstreamer-plugins-base-0.10.15-3.fc9.i386 /usr/bin/perl is needed by (installed) evolution-2.21.5-2.fc9.i386 Seems non-trivial. Bill From mclasen at redhat.com Wed Jan 30 18:42:00 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 30 Jan 2008 13:42:00 -0500 Subject: F9 Alpha spinning In-Reply-To: <20080130175647.GA5633@angus.ind.WPI.EDU> References: <20080125162835.GA19048@crow> <20080126220523.GA3054@crow> <20080130064005.GQ23022@crow> <20080130175647.GA5633@angus.ind.WPI.EDU> Message-ID: <1201718520.2957.22.camel@localhost.localdomain> On Wed, 2008-01-30 at 12:56 -0500, Chuck Anderson wrote: > On Wed, Jan 30, 2008 at 01:40:05AM -0500, Luke Macken wrote: > > Latest f9-alpha live bits. It looks like our i686 GNOME/KDE spins can now > > fit on a CD. Ship it! :) > > > > diff between F8-Live-i686 and F9-Alpha-i686-20080129.0.iso > > > > removed package evince: 3452782 > > Now that evince-dvi and evince-dejavu are split out, can we put evince > back pretty please? It would be a shame to not have this. > I added evince back to the live cd kickstart file (or rather I removed the exclusion). Either that didn't work, or Luke didn't use the latest configs. From katzj at redhat.com Wed Jan 30 18:42:04 2008 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 30 Jan 2008 13:42:04 -0500 Subject: F9 Alpha spinning In-Reply-To: <20080130183701.GA12877@nostromo.devel.redhat.com> References: <20080125162835.GA19048@crow> <20080126220523.GA3054@crow> <20080130064005.GQ23022@crow> <20080130175647.GA5633@angus.ind.WPI.EDU> <20080130125721.3f7fa722@redhat.com> <47A0C224.5090301@hhs.nl> <20080130183701.GA12877@nostromo.devel.redhat.com> Message-ID: <1201718524.7533.13.camel@aglarond.local> On Wed, 2008-01-30 at 13:37 -0500, Bill Nottingham wrote: > Hans de Goede (j.w.r.degoede at hhs.nl) said: > > I'm willing to create proposal patches for any packages on the livecd > > requiring perl. Can someone with a livecd image handy do "rpm -e perl" on > > it and see how large the list of dep errors thrown is? > > error: Failed dependencies: [snip] > Seems non-trivial. Also, the live image is supposed to be a comparable experience to a normal install. Removing something as integral as perl runs pretty counter to that goal. Jeremy From tcallawa at redhat.com Wed Jan 30 18:45:12 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 30 Jan 2008 13:45:12 -0500 Subject: F9 Alpha spinning In-Reply-To: <1201718524.7533.13.camel@aglarond.local> References: <20080125162835.GA19048@crow> <20080126220523.GA3054@crow> <20080130064005.GQ23022@crow> <20080130175647.GA5633@angus.ind.WPI.EDU> <20080130125721.3f7fa722@redhat.com> <47A0C224.5090301@hhs.nl> <20080130183701.GA12877@nostromo.devel.redhat.com> <1201718524.7533.13.camel@aglarond.local> Message-ID: <1201718712.3297.19.camel@dhcp83-155.boston.redhat.com> On Wed, 2008-01-30 at 13:42 -0500, Jeremy Katz wrote: > On Wed, 2008-01-30 at 13:37 -0500, Bill Nottingham wrote: > > Hans de Goede (j.w.r.degoede at hhs.nl) said: > > > I'm willing to create proposal patches for any packages on the livecd > > > requiring perl. Can someone with a livecd image handy do "rpm -e perl" on > > > it and see how large the list of dep errors thrown is? > > > > error: Failed dependencies: > [snip] > > Seems non-trivial. > > Also, the live image is supposed to be a comparable experience to a > normal install. Removing something as integral as perl runs pretty > counter to that goal. Perl is pretty split out these days, so it shouldn't be that bad. ~spot From j.w.r.degoede at hhs.nl Wed Jan 30 18:53:18 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 30 Jan 2008 19:53:18 +0100 Subject: F9 Alpha spinning In-Reply-To: <1201718524.7533.13.camel@aglarond.local> References: <20080125162835.GA19048@crow> <20080126220523.GA3054@crow> <20080130064005.GQ23022@crow> <20080130175647.GA5633@angus.ind.WPI.EDU> <20080130125721.3f7fa722@redhat.com> <47A0C224.5090301@hhs.nl> <20080130183701.GA12877@nostromo.devel.redhat.com> <1201718524.7533.13.camel@aglarond.local> Message-ID: <47A0C79E.1040002@hhs.nl> Jeremy Katz wrote: > On Wed, 2008-01-30 at 13:37 -0500, Bill Nottingham wrote: >> Hans de Goede (j.w.r.degoede at hhs.nl) said: >>> I'm willing to create proposal patches for any packages on the livecd >>> requiring perl. Can someone with a livecd image handy do "rpm -e perl" on >>> it and see how large the list of dep errors thrown is? >> error: Failed dependencies: > [snip] >> Seems non-trivial. > > Also, the live image is supposed to be a comparable experience to a > normal install. Removing something as integral as perl runs pretty > counter to that goal. > And I'm saying that perl is not necessarily an integral part of a desktop install. Quite a few of these deps are probably from little utility scripts which hardly get used ever. If you're right and it ends up that one needs to remove crucial parts / functionality we will find out soon enough. Regards, Hans From j.w.r.degoede at hhs.nl Wed Jan 30 18:54:46 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 30 Jan 2008 19:54:46 +0100 Subject: F9 Alpha spinning In-Reply-To: <1201718712.3297.19.camel@dhcp83-155.boston.redhat.com> References: <20080125162835.GA19048@crow> <20080126220523.GA3054@crow> <20080130064005.GQ23022@crow> <20080130175647.GA5633@angus.ind.WPI.EDU> <20080130125721.3f7fa722@redhat.com> <47A0C224.5090301@hhs.nl> <20080130183701.GA12877@nostromo.devel.redhat.com> <1201718524.7533.13.camel@aglarond.local> <1201718712.3297.19.camel@dhcp83-155.boston.redhat.com> Message-ID: <47A0C7F6.6020403@hhs.nl> Tom "spot" Callaway wrote: > On Wed, 2008-01-30 at 13:42 -0500, Jeremy Katz wrote: >> On Wed, 2008-01-30 at 13:37 -0500, Bill Nottingham wrote: >>> Hans de Goede (j.w.r.degoede at hhs.nl) said: >>>> I'm willing to create proposal patches for any packages on the livecd >>>> requiring perl. Can someone with a livecd image handy do "rpm -e perl" on >>>> it and see how large the list of dep errors thrown is? >>> error: Failed dependencies: >> [snip] >>> Seems non-trivial. >> Also, the live image is supposed to be a comparable experience to a >> normal install. Removing something as integral as perl runs pretty >> counter to that goal. > > Perl is pretty split out these days, so it shouldn't be that bad. > Erm it is still 37 Mb (installed size): [hans at localhost gt]$ rpm -qi perl perl-5.8.8-31.fc9.x86_64 Name : perl Relocations: (not relocatable) Version : 5.8.8 Vendor: Fedora Project Release : 31.fc9 Build Date: Mon 12 Nov 2007 09:02:06 PM CET Install Date: Tue 22 Jan 2008 04:12:49 PM CET Build Host: xenbuilder1.fedora.redhat.com Group : Development/Languages Source RPM: perl-5.8.8-31.fc9.src.rpm Size : 37202511 License: (GPL+ or Artistic) and (GPLv2+ or Artistic) Regards, Hans From notting at redhat.com Wed Jan 30 18:57:29 2008 From: notting at redhat.com (Bill Nottingham) Date: Wed, 30 Jan 2008 13:57:29 -0500 Subject: F9 Alpha spinning In-Reply-To: <1201718520.2957.22.camel@localhost.localdomain> References: <20080125162835.GA19048@crow> <20080126220523.GA3054@crow> <20080130064005.GQ23022@crow> <20080130175647.GA5633@angus.ind.WPI.EDU> <1201718520.2957.22.camel@localhost.localdomain> Message-ID: <20080130185729.GA14576@nostromo.devel.redhat.com> Matthias Clasen (mclasen at redhat.com) said: > I added evince back to the live cd kickstart file (or rather I removed > the exclusion). Either that didn't work, or Luke didn't use the latest > configs. The livecd is built from the alpha snapshot, not rawhide. So it didn't have the latest evince/poppler/djvu/etc splitup, so having it included wasn't going to work and have it still fit. Bill From j.w.r.degoede at hhs.nl Wed Jan 30 19:00:00 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 30 Jan 2008 20:00:00 +0100 Subject: F9 Alpha spinning In-Reply-To: <1201718524.7533.13.camel@aglarond.local> References: <20080125162835.GA19048@crow> <20080126220523.GA3054@crow> <20080130064005.GQ23022@crow> <20080130175647.GA5633@angus.ind.WPI.EDU> <20080130125721.3f7fa722@redhat.com> <47A0C224.5090301@hhs.nl> <20080130183701.GA12877@nostromo.devel.redhat.com> <1201718524.7533.13.camel@aglarond.local> Message-ID: <47A0C930.9050807@hhs.nl> Jeremy Katz wrote: > On Wed, 2008-01-30 at 13:37 -0500, Bill Nottingham wrote: >> Hans de Goede (j.w.r.degoede at hhs.nl) said: >>> I'm willing to create proposal patches for any packages on the livecd >>> requiring perl. Can someone with a livecd image handy do "rpm -e perl" on >>> it and see how large the list of dep errors thrown is? >> error: Failed dependencies: > [snip] >> Seems non-trivial. > > Also, the live image is supposed to be a comparable experience to a > normal install. Removing something as integral as perl runs pretty > counter to that goal. > Never mind, foomatic is heavily perl based, so dropping perl is not an option. Regards, Hans From kevin.kofler at chello.at Wed Jan 30 19:02:54 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 30 Jan 2008 19:02:54 +0000 (UTC) Subject: F9 Alpha spinning References: <20080125162835.GA19048@crow> <20080126220523.GA3054@crow> <20080130064005.GQ23022@crow> <20080130175647.GA5633@angus.ind.WPI.EDU> <20080130125721.3f7fa722@redhat.com> <47A0C224.5090301@hhs.nl> Message-ID: Hans de Goede hhs.nl> writes: > I guess that the livecd currently includes perl? perl is quite large, maybe > with some effort we can drop it? >From the GNOME one maybe, but it's impossible to drop Perl from the KDE-Live spin, it's a required dependency of KDE (used at least by kconf_update). Kevin Kofler From notting at redhat.com Wed Jan 30 19:05:04 2008 From: notting at redhat.com (Bill Nottingham) Date: Wed, 30 Jan 2008 14:05:04 -0500 Subject: F9 Alpha spinning In-Reply-To: <47A0C79E.1040002@hhs.nl> References: <20080125162835.GA19048@crow> <20080126220523.GA3054@crow> <20080130064005.GQ23022@crow> <20080130175647.GA5633@angus.ind.WPI.EDU> <20080130125721.3f7fa722@redhat.com> <47A0C224.5090301@hhs.nl> <20080130183701.GA12877@nostromo.devel.redhat.com> <1201718524.7533.13.camel@aglarond.local> <47A0C79E.1040002@hhs.nl> Message-ID: <20080130190504.GB14576@nostromo.devel.redhat.com> Hans de Goede (j.w.r.degoede at hhs.nl) said: > And I'm saying that perl is not necessarily an integral part of a desktop > install. Quite a few of these deps are probably from little utility scripts > which hardly get used ever. If you're right and it ends up that one needs > to remove crucial parts / functionality we will find out soon enough. foomatic is almost entirely perl. So i think we're stuck with it. Bill From mclasen at redhat.com Wed Jan 30 19:06:12 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 30 Jan 2008 14:06:12 -0500 Subject: F9 Alpha spinning In-Reply-To: <47A0C930.9050807@hhs.nl> References: <20080125162835.GA19048@crow> <20080126220523.GA3054@crow> <20080130064005.GQ23022@crow> <20080130175647.GA5633@angus.ind.WPI.EDU> <20080130125721.3f7fa722@redhat.com> <47A0C224.5090301@hhs.nl> <20080130183701.GA12877@nostromo.devel.redhat.com> <1201718524.7533.13.camel@aglarond.local> <47A0C930.9050807@hhs.nl> Message-ID: <1201719972.2957.25.camel@localhost.localdomain> On Wed, 2008-01-30 at 20:00 +0100, Hans de Goede wrote: > Jeremy Katz wrote: > > On Wed, 2008-01-30 at 13:37 -0500, Bill Nottingham wrote: > >> Hans de Goede (j.w.r.degoede at hhs.nl) said: > >>> I'm willing to create proposal patches for any packages on the livecd > >>> requiring perl. Can someone with a livecd image handy do "rpm -e perl" on > >>> it and see how large the list of dep errors thrown is? > >> error: Failed dependencies: > > [snip] > >> Seems non-trivial. > > > > Also, the live image is supposed to be a comparable experience to a > > normal install. Removing something as integral as perl runs pretty > > counter to that goal. > > > > Never mind, foomatic is heavily perl based, so dropping perl is not an option. > On the topic of foomatic, with gutenprint and foomatic, we ship a good 80-90 MB of printer 'drivers'. Mostly extremely bloated xml, so it should at least compress well... From cebbert at redhat.com Wed Jan 30 19:23:38 2008 From: cebbert at redhat.com (Chuck Ebbert) Date: Wed, 30 Jan 2008 14:23:38 -0500 Subject: F9 for Eeepc In-Reply-To: <479A650D.8060401@cora.nwra.com> References: <479A650D.8060401@cora.nwra.com> Message-ID: <47A0CEBA.3020601@redhat.com> On 01/25/2008 05:39 PM, Orion Poplawski wrote: > > other stuff? > There is someone working on ACPI support for the Eeepc. Debian already has a package for it, and integration with the upstream linux kernel is being discussed on the linux-acpi mailing list. From jakub at redhat.com Wed Jan 30 19:26:45 2008 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 30 Jan 2008 14:26:45 -0500 Subject: GCC license change to GPLv3+ with parts staying GPLv2+ with exceptions Message-ID: <20080130192645.GP30691@devserv.devel.redhat.com> Hi! dist-f9 switched to gcc-4.3.0-0.7 (shouldn't take too long before gcc trunk is released as 4.3 release candidate upstream) and that version bump also means license change to GPLv3+ for most of gcc. Runtime libraries and crtfiles still stay at GPLv2+ with exceptions. Jakub From smooge at gmail.com Wed Jan 30 19:41:59 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 30 Jan 2008 12:41:59 -0700 Subject: long term support release In-Reply-To: <1201530387.3242.122.camel@beck.corsepiu.local> References: <1201058211.3001.79.camel@gandalf.cobite.com> <20080124081720.GA2636@free.fr> <1201166022.17905.109.camel@beck.corsepiu.local> <1201198306.17905.117.camel@beck.corsepiu.local> <1201249261.17905.239.camel@beck.corsepiu.local> <479DC8BF.8090805@redhat.com> <80d7e4090801280551i27fcd04ete8917756766df9fc@mail.gmail.com> <1201530387.3242.122.camel@beck.corsepiu.local> Message-ID: <80d7e4090801301141t22ae42aerdc0f075072e1ffac@mail.gmail.com> On Jan 28, 2008 7:26 AM, Ralf Corsepius wrote: > > On Mon, 2008-01-28 at 06:51 -0700, Stephen John Smoogen wrote: > > On Jan 28, 2008 5:21 AM, Christopher Aillon wrote: > > > On 01/25/2008 03:21 AM, Ralf Corsepius wrote: > > > > I wouldn't choose Linux to control a spacecraft or a nuclear power > > > > plant, but I didn't hesitate to chose Linux to control robots in a lab, > > > > nor do I hesitate to chose Fedora to host "my personal mission's" > > > > mission-critical data" ;) > > > > > > That's just you. Some people[1] think it's okay to let Linux control a > > > spacecraft[2]. > /me wonders which cpu they are going to use. > I have seen hardened pentium, arm and a couple of PPC variants used. I think most of them have been hardened pentiums. Some of the are using the rt type kernels while a couple used a basic version because well RT wasnt needed. > c.f. http://www.rtems.org I thought I saw this a couple of years ago, but had not seen much since then. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From dcantrell at redhat.com Wed Jan 30 19:43:15 2008 From: dcantrell at redhat.com (David Cantrell) Date: Wed, 30 Jan 2008 09:43:15 -1000 Subject: Debian style net-install ISOs (from FudCON Raleigh) In-Reply-To: References: <479FB05C.30302@redhat.com> Message-ID: <20080130094315.bfaa0c44.dcantrell@redhat.com> On Wed, 30 Jan 2008 17:59:24 +0000 (UTC) Kevin Kofler wrote: > Michael DeHaan redhat.com> writes: > > Fedora could really use Debian style net install ISOs. > > > > For those unfamiliar with the concept ... assume a minimally sized image > > that is enough to start up a net install for all content. > > We already have that, it's called boot.iso. There are actually two minimal images that have already been pointed out, but for clarification: boot.iso - Just stage 1 part of the installer, does not contain the large stage 2 image. With this disc, the stage 2 image will be downloaded if you select HTTP or FTP install methods and then mounted. If you do hard disk or NFS, it will just find the stage 2 image and mount it. rescuecd.iso - Both stage 1 and stage 2. Regardless of your install method, the stage 2 image is always read from the installation media with this disc. I tend to go with the rescuecd.iso disc and do HTTP installs. Works great, download time is minimal for the image itself. And if you have a local mirror of the release, installation won't take forever. -- David Cantrell Red Hat / Honolulu, HI -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From sebastian at when.com Wed Jan 30 19:45:03 2008 From: sebastian at when.com (sebastian at when.com) Date: Wed, 30 Jan 2008 20:45:03 +0100 Subject: Fedora Education Spin In-Reply-To: <479CBF5F.80807@gmail.com> References: <479B4B6A.90805@when.com> <50baabb30801261000g690bfc40w80fdff6cca0efd35@mail.gmail.com> <479B85DD.5090406@when.com> <479B890A.3030903@fedoraproject.org> <20080126194213.1a466781@redhat.com> <479BD6C7.3010608@fedoraproject.org> <20080126195027.0cefe0ad@redhat.com> <479BDAA4.6070304@fedoraproject.org> <20080127025259.32e47cee@lain.camperquake.de> <479BE80A.5080309@fedoraproject.org> <479C727B.7060308@when.com> <479CBF5F.80807@gmail.com> Message-ID: <47A0D3BF.8030207@when.com> Les Mikesell wrote: > Would it be possible to build a 1-CD base install that would then give > you the option of doing a 'yum groupinstall some_big_set' if you have > a good internet connection, or installing that set from a separate CD > that does not have any of the base system on it? [...] If you don't > want to bother setting up the infrastructure for yum groupinstall, > just provide a script that puts the whole list on the yum command line > - or make a metapackage with all the others as dependencies. Hi all, Here (http://fedoraproject.org/wiki/SebastianDziallas/Education) is a new version of the Education Spin. I have extended the table with some apps (thanks for the recommendations!) and created three categories (included, available via script, available via yum). Currently, I have a problem with the integration of the installation script. I have added this to the kickstart file (post part): # create script for extras installation echo '#!/bin/bash'$'\n'"su -c 'yum install atomix blender enigma gcompris inkscape jokosher kalgebra kdeedu marble scribus solfege stardict stellarium taskjuggler wxmaxima'" > /home/fedora/Desktop/extras.sh chmod +x /home/fedora/Desktop/extras.sh But after having created this iso, I don't see such an icon on the desktop. Does anybody have an idea concerning this? And, by the way, will the script still be available, when the user does an installation to hard disk? Sebastian From nicolas.mailhot at laposte.net Wed Jan 30 19:47:08 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 30 Jan 2008 20:47:08 +0100 Subject: F9 Alpha spinning In-Reply-To: <47A0C79E.1040002@hhs.nl> References: <20080125162835.GA19048@crow> <20080126220523.GA3054@crow> <20080130064005.GQ23022@crow> <20080130175647.GA5633@angus.ind.WPI.EDU> <20080130125721.3f7fa722@redhat.com> <47A0C224.5090301@hhs.nl> <20080130183701.GA12877@nostromo.devel.redhat.com> <1201718524.7533.13.camel@aglarond.local> <47A0C79E.1040002@hhs.nl> Message-ID: <1201722428.7848.4.camel@rousalka.dyndns.org> Le mercredi 30 janvier 2008 ? 19:53 +0100, Hans de Goede a ?crit : > And I'm saying that perl is not necessarily an integral part of a desktop > install. Quite a few of these deps are probably from little utility scripts > which hardly get used ever. If you're right and it ends up that one needs to > remove crucial parts / functionality we will find out soon enough. If you're willing to do the work reducing the perl dependency tentacles to a few heavily perl-dependent packages would be appreciated. Not everyone installs the full liveimage and killing gratuituous perl deps makes the actual cost/benefits of using perl more obvious. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From cebbert at redhat.com Wed Jan 30 20:35:23 2008 From: cebbert at redhat.com (Chuck Ebbert) Date: Wed, 30 Jan 2008 15:35:23 -0500 Subject: rawhide report: 20080130 changes In-Reply-To: <20080130164716.3ed1f8e3@dhcp03.addix.net> References: <200801301448.m0UEmLso016720@porkchop.devel.redhat.com> <20080130164716.3ed1f8e3@dhcp03.addix.net> Message-ID: <47A0DF8B.60202@redhat.com> On 01/30/2008 10:47 AM, Ralf Ertzinger wrote: > Hi. > > On Wed, 30 Jan 2008 09:48:21 -0500, Build System wrote: > >> kernel-2.6.24-9.fc9 >> ------------------- >> * Tue Jan 29 2008 John W. Linville >> - A few more wireless fixes for 2.6.25 >> - Some post-2.6.25 wireless updates >> - Actually, we support the new b43 firmware... > > the -PAE package for this is 202MB in size, which can't be right. > This was caused by the update to file-4.23. 4.21 prints: # file ahci.ko ahci.ko: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped 4.23 prints: # file ahci.ko ahci.ko: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV) Now guess what string the find-debuginfo.sh script is looking for when it looks for modules to strip... From chasd at silveroaks.com Wed Jan 30 20:41:12 2008 From: chasd at silveroaks.com (chasd) Date: Wed, 30 Jan 2008 14:41:12 -0600 Subject: Debian style net-install ISOs (from FudCON Raleigh) In-Reply-To: <20080130182343.DD654733FC@hormel.redhat.com> References: <20080130182343.DD654733FC@hormel.redhat.com> Message-ID: <54ED1D40-1DC9-4122-A098-49DD01C92B10@silveroaks.com> Les Mikesell wrote: > What does InstantMirror do for you if you use some other distro/ > versions. As long as the package manager and upstream server use HTTP, you simply create anther InstantMirror virtual host for other distros. It isn't distro-specific, even though the packaging may be. > Admins in larger (even small) organizations aren't likely to be > particularly married to fedora or anything that needs extra per > distro/per version work. Yep, and installing InstantMirror or something like it takes very little of that extra effort. > If you want stuff to be cached locally, make > it work right with a generic setup that will help with all large > repeated downloads and document what that setup should be - or make a > squid config package to make it even easier. If you think that is a better course of action, get a sample config file included in /usr/share/doc/squid-XXXX/ I personally have no interest in that approach. Different people in different environments will like different solutions to the same problem. The more locally cached packages, whatever the mechanism, the better. Charles Dostale From skvidal at fedoraproject.org Wed Jan 30 20:41:40 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 30 Jan 2008 15:41:40 -0500 Subject: Debian style net-install ISOs (from FudCON Raleigh) In-Reply-To: <20080130094315.bfaa0c44.dcantrell@redhat.com> References: <479FB05C.30302@redhat.com> <20080130094315.bfaa0c44.dcantrell@redhat.com> Message-ID: <1201725700.27307.12.camel@cutter> On Wed, 2008-01-30 at 09:43 -1000, David Cantrell wrote: > On Wed, 30 Jan 2008 17:59:24 +0000 (UTC) > Kevin Kofler wrote: > > > Michael DeHaan redhat.com> writes: > > > Fedora could really use Debian style net install ISOs. > > > > > > For those unfamiliar with the concept ... assume a minimally sized image > > > that is enough to start up a net install for all content. > > > > We already have that, it's called boot.iso. > > There are actually two minimal images that have already been pointed out, but for clarification: > > boot.iso - Just stage 1 part of the installer, does not contain the large stage 2 image. With this disc, the stage 2 image will be downloaded if you select HTTP or FTP install methods and then mounted. If you do hard disk or NFS, it will just find the stage 2 image and mount it. > > rescuecd.iso - Both stage 1 and stage 2. Regardless of your install method, the stage 2 image is always read from the installation media with this disc. > > I tend to go with the rescuecd.iso disc and do HTTP installs. Works great, download time is minimal for the image itself. And if you have a local mirror of the release, installation won't take forever. all that michael dehaan was suggesting was that we hard code some default paths on the rescuecd to point to download.fedoraproject.org or to the mirrorlists. Then it makes using the iso for the simplest case even easier and for more complicated cases no harder. -sv From j.w.r.degoede at hhs.nl Wed Jan 30 20:46:44 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 30 Jan 2008 21:46:44 +0100 Subject: F9 Alpha spinning In-Reply-To: <1201722428.7848.4.camel@rousalka.dyndns.org> References: <20080125162835.GA19048@crow> <20080126220523.GA3054@crow> <20080130064005.GQ23022@crow> <20080130175647.GA5633@angus.ind.WPI.EDU> <20080130125721.3f7fa722@redhat.com> <47A0C224.5090301@hhs.nl> <20080130183701.GA12877@nostromo.devel.redhat.com> <1201718524.7533.13.camel@aglarond.local> <47A0C79E.1040002@hhs.nl> <1201722428.7848.4.camel@rousalka.dyndns.org> Message-ID: <47A0E234.7010204@hhs.nl> Nicolas Mailhot wrote: > Le mercredi 30 janvier 2008 ? 19:53 +0100, Hans de Goede a ?crit : > >> And I'm saying that perl is not necessarily an integral part of a desktop >> install. Quite a few of these deps are probably from little utility scripts >> which hardly get used ever. If you're right and it ends up that one needs to >> remove crucial parts / functionality we will find out soon enough. > > If you're willing to do the work reducing the perl dependency tentacles > to a few heavily perl-dependent packages would be appreciated. Not > everyone installs the full liveimage and killing gratuituous perl deps > makes the actual cost/benefits of using perl more obvious. > I agree that having unnecessary perl deps removed is a worthwhile goal in itself, but I can spend my time only once, and since it seems that a perl free livecd os not reachable I can think of better ways of spending my time. Regards, Hans From sundaram at fedoraproject.org Wed Jan 30 20:59:22 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 31 Jan 2008 02:29:22 +0530 Subject: Fedora Education Spin In-Reply-To: <47A0D3BF.8030207@when.com> References: <479B4B6A.90805@when.com> <50baabb30801261000g690bfc40w80fdff6cca0efd35@mail.gmail.com> <479B85DD.5090406@when.com> <479B890A.3030903@fedoraproject.org> <20080126194213.1a466781@redhat.com> <479BD6C7.3010608@fedoraproject.org> <20080126195027.0cefe0ad@redhat.com> <479BDAA4.6070304@fedoraproject.org> <20080127025259.32e47cee@lain.camperquake.de> <479BE80A.5080309@fedoraproject.org> <479C727B.7060308@when.com> <479CBF5F.80807@gmail.com> <47A0D3BF.8030207@when.com> Message-ID: <47A0E52A.90504@fedoraproject.org> sebastian at when.com wrote: > Les Mikesell wrote: >> Would it be possible to build a 1-CD base install that would then give >> you the option of doing a 'yum groupinstall some_big_set' if you have >> a good internet connection, or installing that set from a separate CD >> that does not have any of the base system on it? [...] If you don't >> want to bother setting up the infrastructure for yum groupinstall, >> just provide a script that puts the whole list on the yum command line >> - or make a metapackage with all the others as dependencies. > > Hi all, > > Here (http://fedoraproject.org/wiki/SebastianDziallas/Education) is a > new version of the Education Spin. I have extended the table with some > apps (thanks for the recommendations!) and created three categories > (included, available via script, available via yum). > > Currently, I have a problem with the integration of the installation > script. I have added this to the kickstart file (post part): > > # create script for extras installation > echo '#!/bin/bash'$'\n'"su -c 'yum install atomix blender enigma > gcompris inkscape jokosher kalgebra kdeedu marble scribus solfege > stardict stellarium taskjuggler wxmaxima'" > /home/fedora/Desktop/extras.sh > chmod +x /home/fedora/Desktop/extras.sh > > But after having created this iso, I don't see such an icon on the > desktop. Does anybody have an idea concerning this? And, by the way, > will the script still be available, when the user does an installation > to hard disk? Add xdg-user-dirs to the package list and this should work. If a file is created, it would remain post installation too. Rahul From roland at redhat.com Wed Jan 30 20:59:16 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 30 Jan 2008 12:59:16 -0800 (PST) Subject: rawhide report: 20080130 changes In-Reply-To: Chuck Ebbert's message of Wednesday, 30 January 2008 15:35:23 -0500 <47A0DF8B.60202@redhat.com> References: <200801301448.m0UEmLso016720@porkchop.devel.redhat.com> <20080130164716.3ed1f8e3@dhcp03.addix.net> <47A0DF8B.60202@redhat.com> Message-ID: <20080130205916.CAD6027018F@magilla.localdomain> > This was caused by the update to file-4.23. This was an upstream code change between 4.21 and 4.23, for which there is no proper explanation I can find. Also, it wasn't changed for 64-bit ELF files. This change should be reverted upstream. In file-4.23/src/readelf.c, file_tryelf was changed to check e_type and call doshn only for ET_EXEC and ET_DYN files. It really ought to just call it for any type except ET_CORE, without listing the individual ones, like it used to do. It is also perfectly fine to call dophn_exec for any file with e_phnum != 0, without checking its type other than for ET_CORE. The change was probably meant to call dophn_exec for ET_DYN too, which 64-bit still does not do. You'd get that just by not checking the type. It would also be less error prone not to duplicate the logic for 32/64. Instead, it can just call a shared function with the values from e_* fields. Thanks, Roland From laurent.rineau__fedora at normalesup.org Wed Jan 30 21:00:01 2008 From: laurent.rineau__fedora at normalesup.org (Laurent Rineau) Date: Wed, 30 Jan 2008 22:00:01 +0100 Subject: libsyncml, co-maintainer needed (Re: Libsoup troubles in rawhide (compat-libsoup22 needed)) In-Reply-To: <47A0914F.2030709@redhat.com> References: <479F655F.2010000@odu.neva.ru> <47A0914F.2030709@redhat.com> Message-ID: <200801302200.01913@rineau.tsetse> On Wednesday 30 January 2008 16:01:35 Dan Winship wrote: > Alex Lancaster wrote: > > Here's the full list of packages broken either directly or indirectly > > by this change: > > Hm... I'd done a "repoquery --whatrequires libsoup" and only came up > with 2 non-GNOME packages (libtranslate, which I've now sent the patch > for to Dmitry, and libsyncml, which I've submitted a patch upstream for, > http://libsyncml.opensync.org/ticket/130). Apparently repoquery lies > though. :-/ I?maintain libsyncml in Fedora. Although pushing the new release of libsyncml is high in my todo list, my job does not let me a lot of time to do it (and the build process of libsyncml have been switched to CMake). I would appreciate help on that package. I?may not have time for it before at least next week. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From caillon at redhat.com Wed Jan 30 21:23:12 2008 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 30 Jan 2008 16:23:12 -0500 Subject: F9 Alpha spinning In-Reply-To: <20080126220523.GA3054@crow> References: <20080125162835.GA19048@crow> <20080126220523.GA3054@crow> Message-ID: <47A0EAC0.6030502@redhat.com> On 01/26/2008 05:05 PM, Luke Macken wrote: > Here are some stats of todays re-spin against the latest f9-alpha bits and > livecd configs. It looks like our desktop spin lost 2mb overnight, > while everything else got bigger. In the diff below, I also include a list > of packages that have shrunk since F8. > > -rw-r--r-- 1 root root 1.6G 2008-01-26 02:28 F9-Alpha-Developer-20080126.0.iso > -rw-r--r-- 1 root root 767M 2008-01-26 02:42 F9-Alpha-FEL-i686-20080126.0.iso > -rw-r--r-- 1 root root 4.0G 2008-01-26 15:25 F9-Alpha-games-i686-20080126.0.iso > -rw-r--r-- 1 root root 712M 2008-01-26 01:18 F9-Alpha-i686-20080126.0.iso > -rw-r--r-- 1 root root 688M 2008-01-26 01:46 F9-Alpha-KDE-i686-20080126.0.iso > -rw-r--r-- 1 root root 801M 2008-01-26 02:02 F9-Alpha-KDE-x86_64-20080126.0.iso > -rw-r--r-- 1 root root 768M 2008-01-26 01:35 F9-Alpha-x86_64-20080126.0.iso Whatever happened to the Desktop spin? From a.badger at gmail.com Wed Jan 30 21:24:22 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 30 Jan 2008 13:24:22 -0800 Subject: How much personal information is necessary to close a bug? In-Reply-To: <1201691235.13318.13.camel@fedlex.lex.hider.name> References: <1201686688.13318.4.camel@fedlex.lex.hider.name> <364d303b0801300251s39ffe2b8we671f2005c836474@mail.gmail.com> <1201691235.13318.13.camel@fedlex.lex.hider.name> Message-ID: <47A0EB06.9030607@gmail.com> Lex Hider wrote: > On Wed, 2008-01-30 at 10:51 +0000, Christopher Brown wrote: >> On 30/01/2008, Lex Hider wrote: >>> Hi, >>> I was wanting to do some bug triage for fedora. >>> I checked out the list of NEW bugs for one of my favourite apps: amarok. >>> There seemed a pretty obvious bug that could now be closed: >>> https://bugzilla.redhat.com/show_bug.cgi?id=248625 >>> >>> I tried to close it and found I didn't have the privileges to do so. >>> I asked on #fedora-devel and was pointed to the triage team wiki page >>> and that I need a Fedora Account. >>> >>> Apparently to open a Fedora account I need to give my postal address and >>> telephone number. Why is it necessary to give this personal information >>> just to close a bug? >>> >>> Contrast to other projects I have contributed to where some realizes you >>> know what you are doing or get sick of you pestering to close bugs on >>> your behalf and give you the relevant privileges. >>> >>> Here's an example of my bug closing credentials: >>> Look at Bug Killers: >>> http://www.commit-digest.org/issues/2006-04-30/ >> Hello Lex, >> >> Great that you're wanting to do some triage work and yeah, that bug is >> the kind of stuff that we don't need hanging around any longer. :) >> >> As for the information side of things, FAS is used for a number of >> things, including the ability to create packages in Fedora and there >> has to, at some point, be some accountability for how this happens. >> With bugzilla triage privs you get the ability to modify to great >> extent the bugs in Red Hat's main bug tracking system so I think its >> understandable for this to be asked. Someone with legal knowledge >> might want to add to this though. >> >> Best place to hang out for triaging is #fedora-qa on IRC and the two >> bods leading the charge are John Poelstra and Jon Stanley. >> >> http://fedoraproject.org/wiki/JohnPoelstra >> http://fedoraproject.org/wiki/JonStanley >> >> We have a meeting today at 1700 UTC in #fedora-meeting - would be good >> to have you there as well. >> >> Cheers >> >> -- >> Christopher Brown > > I think that meeting is around 4am local time, so I may have to give it > a miss. Perhaps you could put on the agenda how high the barrier for > entry is. Not only do I have to create a separate Fedora account aside > form the bugzilla that I have, I have to give out my personal details, > and then I have to learn enough about gpg to make a key to sign up for > the account. > > If I have to jump through all the above hoops just to close trivial > bugs, I'm not sure if I'll bother. > > I can see no reason why anyone would need my address and phone number. > What is stopping anyone from putting in fake ones. > > I was tempted just to enter address as something like: > 27 Gumdrop House > Lolly Pop Lane. > (http://thinkexist.com/quotation/owww-look-at-me-marge-i-m-making-people-happy-i-m/748180.html) > > > Surely entering the phone number and address details is useless without > verification anyway. > I believe that we're removing the necessity for having an address and phone number in FAS2 (although having an alternate form of contact is definitely a good thing for many of the things people do in Fedora). GPG signing of the CLA is a legal requirement of becoming a "contributor". Whether a bug triager must be a "contributor" in this sense is up to Jon Stanley and John Poelstra to decide at this point as they're running the new triaging effort. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From sundaram at fedoraproject.org Wed Jan 30 21:42:40 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 31 Jan 2008 03:12:40 +0530 Subject: F9 Alpha spinning In-Reply-To: <47A0EAC0.6030502@redhat.com> References: <20080125162835.GA19048@crow> <20080126220523.GA3054@crow> <47A0EAC0.6030502@redhat.com> Message-ID: <47A0EF50.5080701@fedoraproject.org> Christopher Aillon wrote: > On 01/26/2008 05:05 PM, Luke Macken wrote: >> Here are some stats of todays re-spin against the latest f9-alpha bits >> and >> livecd configs. It looks like our desktop spin lost 2mb overnight, >> while everything else got bigger. In the diff below, I also include a >> list >> of packages that have shrunk since F8. >> >> -rw-r--r-- 1 root root 1.6G 2008-01-26 02:28 >> F9-Alpha-Developer-20080126.0.iso >> -rw-r--r-- 1 root root 767M 2008-01-26 02:42 >> F9-Alpha-FEL-i686-20080126.0.iso >> -rw-r--r-- 1 root root 4.0G 2008-01-26 15:25 >> F9-Alpha-games-i686-20080126.0.iso >> -rw-r--r-- 1 root root 712M 2008-01-26 01:18 F9-Alpha-i686-20080126.0.iso >> -rw-r--r-- 1 root root 688M 2008-01-26 01:46 >> F9-Alpha-KDE-i686-20080126.0.iso >> -rw-r--r-- 1 root root 801M 2008-01-26 02:02 >> F9-Alpha-KDE-x86_64-20080126.0.iso >> -rw-r--r-- 1 root root 768M 2008-01-26 01:35 >> F9-Alpha-x86_64-20080126.0.iso > > Whatever happened to the Desktop spin? The desktop spin has never been called that in the filename. What you need is F9-Alpha-i686-20080126.0.iso Rahul From caillon at redhat.com Wed Jan 30 21:53:18 2008 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 30 Jan 2008 16:53:18 -0500 Subject: F9 Alpha spinning In-Reply-To: <47A0EF50.5080701@fedoraproject.org> References: <20080125162835.GA19048@crow> <20080126220523.GA3054@crow> <47A0EAC0.6030502@redhat.com> <47A0EF50.5080701@fedoraproject.org> Message-ID: <47A0F1CE.4020406@redhat.com> On 01/30/2008 04:42 PM, Rahul Sundaram wrote: > Christopher Aillon wrote: >> On 01/26/2008 05:05 PM, Luke Macken wrote: >>> Here are some stats of todays re-spin against the latest f9-alpha >>> bits and >>> livecd configs. It looks like our desktop spin lost 2mb overnight, >>> while everything else got bigger. In the diff below, I also include >>> a list >>> of packages that have shrunk since F8. >>> >>> -rw-r--r-- 1 root root 1.6G 2008-01-26 02:28 >>> F9-Alpha-Developer-20080126.0.iso >>> -rw-r--r-- 1 root root 767M 2008-01-26 02:42 >>> F9-Alpha-FEL-i686-20080126.0.iso >>> -rw-r--r-- 1 root root 4.0G 2008-01-26 15:25 >>> F9-Alpha-games-i686-20080126.0.iso >>> -rw-r--r-- 1 root root 712M 2008-01-26 01:18 >>> F9-Alpha-i686-20080126.0.iso >>> -rw-r--r-- 1 root root 688M 2008-01-26 01:46 >>> F9-Alpha-KDE-i686-20080126.0.iso >>> -rw-r--r-- 1 root root 801M 2008-01-26 02:02 >>> F9-Alpha-KDE-x86_64-20080126.0.iso >>> -rw-r--r-- 1 root root 768M 2008-01-26 01:35 >>> F9-Alpha-x86_64-20080126.0.iso >> >> Whatever happened to the Desktop spin? > > The desktop spin has never been called that in the filename. What you > need is > > F9-Alpha-i686-20080126.0.iso I'm not talking about the default "Fedora" spin which provides a desktop (and which also lets you install server stuff). The "Desktop" spin was the targeted desktop spin of packages, and with tweaks such as NM-on-by-default, etc. Is that really what that iso file gives me? From katzj at redhat.com Wed Jan 30 22:00:34 2008 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 30 Jan 2008 17:00:34 -0500 Subject: F9 Alpha spinning In-Reply-To: <47A0F1CE.4020406@redhat.com> References: <20080125162835.GA19048@crow> <20080126220523.GA3054@crow> <47A0EAC0.6030502@redhat.com> <47A0EF50.5080701@fedoraproject.org> <47A0F1CE.4020406@redhat.com> Message-ID: <1201730434.25486.6.camel@aglarond.local> On Wed, 2008-01-30 at 16:53 -0500, Christopher Aillon wrote: > I'm not talking about the default "Fedora" spin which provides a desktop > (and which also lets you install server stuff). The "Desktop" spin was > the targeted desktop spin of packages, and with tweaks such as > NM-on-by-default, etc. > > Is that really what that iso file gives me? Yes. Because otherwise, the amount of confusion is absolutely staggering to an end-user who doesn't keep up with the minutae of fedora-*-list Jeremy From sundaram at fedoraproject.org Wed Jan 30 22:09:52 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 31 Jan 2008 03:39:52 +0530 Subject: F9 Alpha spinning In-Reply-To: <47A0F1CE.4020406@redhat.com> References: <20080125162835.GA19048@crow> <20080126220523.GA3054@crow> <47A0EAC0.6030502@redhat.com> <47A0EF50.5080701@fedoraproject.org> <47A0F1CE.4020406@redhat.com> Message-ID: <47A0F5B0.1070405@fedoraproject.org> Christopher Aillon wrote: >> F9-Alpha-i686-20080126.0.iso > > I'm not talking about the default "Fedora" spin which provides a desktop > (and which also lets you install server stuff). That's a DVD. The "Desktop" spin was > the targeted desktop spin of packages, and with tweaks such as > NM-on-by-default, etc. > > Is that really what that iso file gives me? Yes. The latest revision is 698M 2008-01-29 20:24 F9-Alpha-i686-20080129.0.iso Rahul From ml at deadbabylon.de Wed Jan 30 22:08:05 2008 From: ml at deadbabylon.de (Sebastian Vahl) Date: Wed, 30 Jan 2008 23:08:05 +0100 Subject: F9 Alpha spinning In-Reply-To: <20080130064005.GQ23022@crow> References: <20080125162835.GA19048@crow> <20080126220523.GA3054@crow> <20080130064005.GQ23022@crow> Message-ID: <20080130230805.1e55c718@moorgarten.schwarmsted> Am Wed, 30 Jan 2008 01:40:05 -0500 schrieb Luke Macken : > Latest f9-alpha live bits. It looks like our i686 GNOME/KDE spins > can now fit on a CD. Ship it! :) > > 688M 2008-01-29 F9-Alpha-KDE-i686-20080129.0.iso Looks better now. But in my tests I've always got ~695 megs. Could you send me a package list so I could make sure they are the same? Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From superpitou82 at gmail.com Wed Jan 30 22:24:08 2008 From: superpitou82 at gmail.com (=?ISO-8859-1?Q?Pierre_Mar=E9chal?=) Date: Wed, 30 Jan 2008 23:24:08 +0100 Subject: rawhide report: 20080130 changes In-Reply-To: <20080130205916.CAD6027018F@magilla.localdomain> References: <200801301448.m0UEmLso016720@porkchop.devel.redhat.com> <20080130164716.3ed1f8e3@dhcp03.addix.net> <47A0DF8B.60202@redhat.com> <20080130205916.CAD6027018F@magilla.localdomain> Message-ID: <285385910801301424y7c60ba3g8a1ff536365df2a0@mail.gmail.com> Hi, I'm trying to upgrade to rawhide from clean f8 install (x86_64). Yum complains about libcamel-1.2.so.10 and libsoup-2.2.so.8 not available. I had the same problem with an updated f8 (that's why I reinstalled at first time). here's the message --> Finished Dependency Resolution Error: Missing Dependency: libcamel-1.2.so.10()(64bit) is needed by package totem-pl-parser Error: Missing Dependency: libsoup-2.2.so.8()(64bit) is needed by package rhythmbox Error: Missing Dependency: libsoup-2.2.so.8()(64bit) is needed by package bug-buddy Error: Missing Dependency: libsoup-2.2.so.8()(64bit) is needed by package evolution-webcal Regards, Pierre 2008/1/30, Roland McGrath : > > > This was caused by the update to file-4.23. > > This was an upstream code change between 4.21 and 4.23, for which there is > no proper explanation I can find. Also, it wasn't changed for 64-bit ELF > files. This change should be reverted upstream. > > In file-4.23/src/readelf.c, file_tryelf was changed to check e_type and > call doshn only for ET_EXEC and ET_DYN files. It really ought to just > call > it for any type except ET_CORE, without listing the individual ones, like > it used to do. It is also perfectly fine to call dophn_exec for any file > with e_phnum != 0, without checking its type other than for ET_CORE. > The change was probably meant to call dophn_exec for ET_DYN too, which > 64-bit still does not do. You'd get that just by not checking the type. > It would also be less error prone not to duplicate the logic for 32/64. > Instead, it can just call a shared function with the values from e_* > fields. > > > Thanks, > Roland > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vonbrand at inf.utfsm.cl Wed Jan 30 22:26:55 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Wed, 30 Jan 2008 19:26:55 -0300 Subject: Firefox and Epiphany crash after today's updates Message-ID: <200801302227.m0UMQtvX022692@laptop13.inf.utfsm.cl> After updating today, trying to get into (I have a password saved for that site in Firefox) both browsers crash. BZ'd at . [Yes, the site could very well be badly built, but crashing isn't acceptable.] -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From jonstanley at gmail.com Wed Jan 30 22:56:43 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Wed, 30 Jan 2008 17:56:43 -0500 Subject: How much personal information is necessary to close a bug? In-Reply-To: <47A0EB06.9030607@gmail.com> References: <1201686688.13318.4.camel@fedlex.lex.hider.name> <364d303b0801300251s39ffe2b8we671f2005c836474@mail.gmail.com> <1201691235.13318.13.camel@fedlex.lex.hider.name> <47A0EB06.9030607@gmail.com> Message-ID: 2008/1/30 Toshio Kuratomi : > Whether a bug triager must be a "contributor" in this > sense is up to Jon Stanley and John Poelstra to decide at this point as > they're running the new triaging effort. Yes, we decided that in the FESCo meeting that cla_done is required (in non-Fedora terms, you are a "contributor" - that way there is no problem with using what folks put in there in release notes/documentation/training/whatever we want. From mrmazda at ij.net Thu Jan 31 00:43:15 2008 From: mrmazda at ij.net (Felix Miata) Date: Wed, 30 Jan 2008 19:43:15 -0500 Subject: mirrors broken again Message-ID: <47A119A3.9040505@ij.net> On several I checked, including mirrors.kernel.org, repodata and isolinux directories are missing again. -- "In the beginning was the Word, and the Word was with God, and the Word was God." John 1:1 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://mrmazda.no-ip.com/ From kanarip at kanarip.com Thu Jan 31 01:02:24 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 31 Jan 2008 02:02:24 +0100 Subject: Debian style net-install ISOs (from FudCON Raleigh) In-Reply-To: <1201725700.27307.12.camel@cutter> References: <479FB05C.30302@redhat.com> <20080130094315.bfaa0c44.dcantrell@redhat.com> <1201725700.27307.12.camel@cutter> Message-ID: <47A11E20.2090406@kanarip.com> seth vidal wrote: > all that michael dehaan was suggesting was that we hard code some > default paths on the rescuecd to point to download.fedoraproject.org or > to the mirrorlists. Then it makes using the iso for the simplest case > even easier and for more complicated cases no harder. > Aha, the "insert, boot and press enter" use case ;-) +1 for squeezing that in somewhere, but wouldn't that be a rescue+very minimalistic kickstart? I use kickstart to prevent the (in my personal opinion) language and keyboard settings dialog from popping up... I'm not sure what else it can take in a rescue cd environment? Kind regards, Jeroen van Meeuwen -kanarip From cjdahlin at ncsu.edu Thu Jan 31 02:29:26 2008 From: cjdahlin at ncsu.edu (Casey Dahlin) Date: Wed, 30 Jan 2008 21:29:26 -0500 Subject: Debian style net-install ISOs (from FudCON Raleigh) In-Reply-To: <47A11E20.2090406@kanarip.com> References: <479FB05C.30302@redhat.com> <20080130094315.bfaa0c44.dcantrell@redhat.com> <1201725700.27307.12.camel@cutter> <47A11E20.2090406@kanarip.com> Message-ID: <47A13286.7060102@ncsu.edu> Jeroen van Meeuwen wrote: > seth vidal wrote: >> all that michael dehaan was suggesting was that we hard code some >> default paths on the rescuecd to point to download.fedoraproject.org or >> to the mirrorlists. Then it makes using the iso for the simplest case >> even easier and for more complicated cases no harder. >> > > Aha, the "insert, boot and press enter" use case ;-) +1 for squeezing > that in somewhere, but wouldn't that be a rescue+very minimalistic > kickstart? I use kickstart to prevent the (in my personal opinion) > language and keyboard settings dialog from popping up... I'm not sure > what else it can take in a rescue cd environment? > In your opinion they are language and keyboard settings? What other opinions have you met? :P --CJD > Kind regards, > > Jeroen van Meeuwen > -kanarip > From wtogami at redhat.com Thu Jan 31 02:50:21 2008 From: wtogami at redhat.com (Warren Togami) Date: Wed, 30 Jan 2008 21:50:21 -0500 Subject: pulseaudio causing crashing of applications Message-ID: <47A1376D.7010408@redhat.com> Hi folks, Is anyone else seeing regular crashing of applications like pidgin, mplayer or xine caused by pulseaudio? Did anybody manage to get useful backtraces out of this? Thanks, Warren Togami wtogami at redhat.com From mclasen at redhat.com Thu Jan 31 03:00:51 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 30 Jan 2008 22:00:51 -0500 Subject: pulseaudio causing crashing of applications In-Reply-To: <47A1376D.7010408@redhat.com> References: <47A1376D.7010408@redhat.com> Message-ID: <1201748451.2777.0.camel@localhost.localdomain> On Wed, 2008-01-30 at 21:50 -0500, Warren Togami wrote: > Hi folks, > > Is anyone else seeing regular crashing of applications like pidgin, > mplayer or xine caused by pulseaudio? Did anybody manage to get useful > backtraces out of this? > You haven't seen a useful stacktrace, but you know that its caused by PA ? From ben.kreuter at gmail.com Thu Jan 31 03:01:53 2008 From: ben.kreuter at gmail.com (Benjamin Kreuter) Date: Wed, 30 Jan 2008 22:01:53 -0500 Subject: pulseaudio causing crashing of applications In-Reply-To: <47A1376D.7010408@redhat.com> References: <47A1376D.7010408@redhat.com> Message-ID: <200801302201.58423.ben.kreuter@gmail.com> On Wednesday 30 January 2008 21:50:21 Warren Togami wrote: > Hi folks, > > Is anyone else seeing regular crashing of applications like pidgin, > mplayer or xine caused by pulseaudio? Did anybody manage to get useful > backtraces out of this? > No, but I have had problems with pulseaudio and arts on the same system. I wasn't around to hear the discussion about including pulseaudio in F8...why did we go down that road? -- Benjamin Kreuter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From loupgaroublond at gmail.com Thu Jan 31 03:03:50 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 30 Jan 2008 22:03:50 -0500 Subject: F9 for Eeepc In-Reply-To: <1201707976.3882.59.camel@birkoff> References: <479A650D.8060401@cora.nwra.com> <1201304569.2057.22.camel@localhost.localdomain> <645d17210801251629y2811f3f7jf0886a166ffd2f8@mail.gmail.com> <479E7137.5020705@cora.nwra.com> <47A08781.70303@fedoraproject.org> <1201707976.3882.59.camel@birkoff> Message-ID: <7f692fec0801301903u24c27fb6na03674ca151cab05@mail.gmail.com> On Jan 30, 2008 10:46 AM, Jon Nettleton wrote: > Thanks for the heads up. I am not directly working with the Eeedora > project. I am really most interested in getting the most functional low > resolution desktop as possible. Xfce is fine, however I find that > desktop environment a bit restrictive. Here is the environment I am > building/using right now on my eeepc ( by the way this is > 2GB's ). I > know I know, but I am more interested in functionality than space. > > 1) Devilspie to better customize size and position of windows. Overly > large windows are still problematic and I am trying methods to fix this. > I am thinking maybe scaling the window with a compositing manager might > be the way to go. Oh and some kind of gui to configure devilspie, it is > said that one doesn't exist yet. I am thinking angelcake would be a > good name. Except that it doesn't do compositing yet, I recommend XMonad for your WM (or any other tiling window manager). On such a small screen, it should solve alot of difficulties you have in placing windows in a reasonable space. There is no gui to configure it either, but you have the same barrier both ways. At least this way you're not using something as inelegant as devilspie. -Yaakov From stickster at gmail.com Thu Jan 31 03:08:14 2008 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 30 Jan 2008 22:08:14 -0500 Subject: Libsoup troubles in rawhide (compat-libsoup22 needed) In-Reply-To: <1201661054.2779.7.camel@localhost.localdomain> References: <479F655F.2010000@odu.neva.ru> <1201660097.25209.24.camel@localhost.localdomain> <1201661054.2779.7.camel@localhost.localdomain> Message-ID: <1201748894.19021.12.camel@localhost.localdomain> On Tue, 2008-01-29 at 21:44 -0500, Matthias Clasen wrote: > On Tue, 2008-01-29 at 21:28 -0500, Paul W. Frields wrote: > > > I'm not the maintainer of libsoup. But I own one of the broken packages > > (drivel). A cursory look -- by which I mean "asking people who I'm sure > > would know" ;-) -- tells me there's no written policy on this in the > > wiki to which maintainers should refer. If there truly isn't one, and > > people feel there should be, I humbly suggest those people should > > document the policy on the wiki in the generally accepted manner. While > > I personally believe in bending over backward to inform everyone about > > these changes well in advance, a policy is less dependent on personal > > predilections. :-) > > Dan really went out of his way to handle the api breakage as well as > possible. He had patches for all affected gnome packages before even > doing the 2.3.0 release, and he has only made the release after the > Gnome release team strongly encouraged him to get libsoup 2.4 into > Gnome 2.22. > > He has also provided a patch for libtranslate by now, and I'm sure he > will be happy to help other package maintainers that are affected > by this. That's great to hear -- just in case it was unclear, please note that I was *in no way* impugning Dan's good work. It's Rawhide, we're only just now at Alpha anyway, usw.. I only wanted to point out that if someone feels differently, there are ways to handle that -- and if it's not a policy matter, bully. BTW, I will probably try to handle my package with the limited skills at my disposal, but if I fall short of the mark, I'm glad to know Dan's available for consults. :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mtasaka at ioa.s.u-tokyo.ac.jp Thu Jan 31 03:15:07 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 31 Jan 2008 12:15:07 +0900 Subject: Libsoup troubles in rawhide (compat-libsoup22 needed) In-Reply-To: <1201748894.19021.12.camel@localhost.localdomain> References: <479F655F.2010000@odu.neva.ru> <1201660097.25209.24.camel@localhost.localdomain> <1201661054.2779.7.camel@localhost.localdomain> <1201748894.19021.12.camel@localhost.localdomain> Message-ID: <47A13D3B.3020800@ioa.s.u-tokyo.ac.jp> Paul W. Frields wrote, at 01/31/2008 12:08 PM +9:00: > That's great to hear -- just in case it was unclear, please note that I > was *in no way* impugning Dan's good work. It's Rawhide, we're only > just now at Alpha anyway, usw.. I only wanted to point out that if > someone feels differently, there are ways to handle that -- and if it's > not a policy matter, bully. > > BTW, I will probably try to handle my package with the limited skills at > my disposal, but if I fall short of the mark, I'm glad to know Dan's > available for consults. :-) BTW libsoup22 package is now under review. https://bugzilla.redhat.com/show_bug.cgi?id=430978 Regards, Mamoru From lordmorgul at gmail.com Thu Jan 31 03:31:20 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Wed, 30 Jan 2008 19:31:20 -0800 Subject: pulseaudio causing crashing of applications In-Reply-To: <200801302201.58423.ben.kreuter@gmail.com> References: <47A1376D.7010408@redhat.com> <200801302201.58423.ben.kreuter@gmail.com> Message-ID: <47A14108.5050207@gmail.com> Benjamin Kreuter wrote: > No, but I have had problems with pulseaudio and arts on the same system. I > wasn't around to hear the discussion about including pulseaudio in F8...why > did we go down that road? Maybe because pulseaudio is to arts what playstation is to atari? Now I'm a big fan of atari, but its old. Pulseaudio is very cool, just not perfect yet. -- Andrew Farris www.lordmorgul.net gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From sandeen at redhat.com Thu Jan 31 03:36:14 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Wed, 30 Jan 2008 21:36:14 -0600 Subject: Smolt RFC: File System Information In-Reply-To: <7f692fec0801252035j66468790g47ddffb0d4479013@mail.gmail.com> References: <7f692fec0801252035j66468790g47ddffb0d4479013@mail.gmail.com> Message-ID: <47A1422E.1080507@redhat.com> Yaakov Nemoy wrote: > Hey list, > > I'm looking to get some input on a feature that was requested of > Smolt. One file system engineer wants to collect some basic data > about file systems in use, for fine tuning the default settings in > Fedora and RHEL. This is something that we can all benefit by, and > the greater participation we give, the better the results are going to > be for everyone. To hilight the information to be collected, actions > speak louder than words: > > yankee at dao:~$ sudo stat -f /dev/main/fedora8 > File: "/dev/main/fedora8" > ID: 0 Namelen: 255 Type: tmpfs > Block size: 4096 Fundamental block size: 4096 > Blocks: Total: 258215 Free: 258199 Available: 258199 > Inodes: Total: 223935 Free: 222932 > > (Actually I think something might be broken, that data doesn't look > correct for me) I think you sorted it out, but: stat the mountpoint not the dev... :) > In short, it will collect a list of file systems + types, and their usage stats. > > For the time being the stats won't be published on the web site. > We're having some reporting issues, and I don't want to add another > long running SQL query into the mix. However, anyone will be free to > ask one of us to report on that information. Furthermore, this > information will be enabled by default, for the time being, until we > have thing set up to allow fine grained information hiding. Remember, > all profiles will be anonymous as usual. > > Are there any underlying security or privacy issues here that would be > a clear reason not to do this? Any other comments, or refinements? The only thing I can think of is that while you'd like to report any filesystems in use (so as not to pre-select what you're interested in, and potentially filter out, say, a large unknown community of befs users...) you run the risk of possibly reporting a "secret" filesystem name; for example if suddenly 500 HP machines start reporting that "zfs" is in use, it might make you go "hmmm...." - but, I assume that other things reported by smolt after grepping around the bios run similar risks, and you're not worried about sending out those strings? So ideally I guess I'd like to see essentially df & df -i information for any real (non-loop?) devices in /dev. (well actually I can think of a lot more fs-specific things that would be cool, but I'll be happy with type/size/utilization for now) :) Thanks! -Eric From sandeen at redhat.com Thu Jan 31 03:55:22 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Wed, 30 Jan 2008 21:55:22 -0600 Subject: Smolt RFC: File System Information In-Reply-To: <47A1422E.1080507@redhat.com> References: <7f692fec0801252035j66468790g47ddffb0d4479013@mail.gmail.com> <47A1422E.1080507@redhat.com> Message-ID: <47A146AA.9090101@redhat.com> Eric Sandeen wrote: > So ideally I guess I'd like to see essentially df & df -i information > for any real (non-loop?) devices in /dev. Oh, one other thing I considered is that *if* the mountpoint is a FHS-specified path (hence no privacy issues), then reporting it might be interesting too - see what's used on /var vs. /tmp vs /home etc, and if it's /secret-project then just report "other" - but that probably complicates things a little. -Eric From lmacken at redhat.com Thu Jan 31 04:19:27 2008 From: lmacken at redhat.com (Luke Macken) Date: Wed, 30 Jan 2008 23:19:27 -0500 Subject: F9 Alpha spinning In-Reply-To: <20080130230805.1e55c718@moorgarten.schwarmsted> References: <20080125162835.GA19048@crow> <20080126220523.GA3054@crow> <20080130064005.GQ23022@crow> <20080130230805.1e55c718@moorgarten.schwarmsted> Message-ID: <20080131041927.GC9172@crow> On Wed, Jan 30, 2008 at 11:08:05PM +0100, Sebastian Vahl wrote: > Am Wed, 30 Jan 2008 01:40:05 -0500 > schrieb Luke Macken : > > > Latest f9-alpha live bits. It looks like our i686 GNOME/KDE spins > > can now fit on a CD. Ship it! :) > > > > 688M 2008-01-29 F9-Alpha-KDE-i686-20080129.0.iso > > Looks better now. But in my tests I've always got ~695 megs. Could you > send me a package list so I could make sure they are the same? http://lmacken.fedorapeople.org/livecd/F9-Alpha-i686-20080126.0.pkglist http://lmacken.fedorapeople.org/livecd/F9-Alpha-x86_64-20080126.0.pkglist http://lmacken.fedorapeople.org/livecd/F9-Alpha-KDE-i686-20080126.0.pkglist http://lmacken.fedorapeople.org/livecd/F9-Alpha-KDE-x86_64-20080126.0.pkglist http://lmacken.fedorapeople.org/livecd/F9-Alpha-Developer-20080126.0.pkglist http://lmacken.fedorapeople.org/livecd/F9-Alpha-FEL-i686-20080126.0.pkglist http://lmacken.fedorapeople.org/livecd/F9-Alpha-games-i686-20080126.0.pkglist From floss at lex.hider.name Thu Jan 31 04:35:36 2008 From: floss at lex.hider.name (Lex Hider) Date: Thu, 31 Jan 2008 15:35:36 +1100 Subject: Debian style net-install ISOs (from FudCON Raleigh) In-Reply-To: <20080130094315.bfaa0c44.dcantrell@redhat.com> References: <479FB05C.30302@redhat.com> <20080130094315.bfaa0c44.dcantrell@redhat.com> Message-ID: <9b34f920801302035w3ad97025uf68dc71edb757cc8@mail.gmail.com> On 1/31/08, David Cantrell wrote: > On Wed, 30 Jan 2008 17:59:24 +0000 (UTC) > Kevin Kofler wrote: > > > Michael DeHaan redhat.com> writes: > > > Fedora could really use Debian style net install ISOs. > > > > > > For those unfamiliar with the concept ... assume a minimally sized image > > > that is enough to start up a net install for all content. > > > > We already have that, it's called boot.iso. > > There are actually two minimal images that have already been pointed out, but for clarification: > > boot.iso - Just stage 1 part of the installer, does not contain the large stage 2 image. With this disc, the stage 2 image will be downloaded if you select HTTP or FTP install methods and then mounted. If you do hard disk or NFS, it will just find the stage 2 image and mount it. > > rescuecd.iso - Both stage 1 and stage 2. Regardless of your install method, the stage 2 image is always read from the installation media with this disc. > > I tend to go with the rescuecd.iso disc and do HTTP installs. Works great, download time is minimal for the image itself. And if you have a local mirror of the release, installation won't take forever. > Is it possible to do what I do with debian. I normally make a tarball with the packages from /var/cache/apt/archives Install the base system and when I get to package selection, switch to console and unpack tarball. This way I don't have to download packages I have downloaded previously. Is it possible to do similar thing with /var/cache/yum ? Lex. From rc040203 at freenet.de Thu Jan 31 04:42:52 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 31 Jan 2008 05:42:52 +0100 Subject: Debian style net-install ISOs (from FudCON Raleigh) In-Reply-To: <9b34f920801302035w3ad97025uf68dc71edb757cc8@mail.gmail.com> References: <479FB05C.30302@redhat.com> <20080130094315.bfaa0c44.dcantrell@redhat.com> <9b34f920801302035w3ad97025uf68dc71edb757cc8@mail.gmail.com> Message-ID: <1201754572.3250.124.camel@beck.corsepiu.local> On Thu, 2008-01-31 at 15:35 +1100, Lex Hider wrote: > On 1/31/08, David Cantrell wrote: > > On Wed, 30 Jan 2008 17:59:24 +0000 (UTC) > > Kevin Kofler wrote: > > > > > Michael DeHaan redhat.com> writes: > > > > Fedora could really use Debian style net install ISOs. > > > > > > > > For those unfamiliar with the concept ... assume a minimally sized image > > > > that is enough to start up a net install for all content. > > > > > > We already have that, it's called boot.iso. > > > > There are actually two minimal images that have already been pointed out, but for clarification: > > > > boot.iso - Just stage 1 part of the installer, does not contain the large stage 2 image. With this disc, the stage 2 image will be downloaded if you select HTTP or FTP install methods and then mounted. If you do hard disk or NFS, it will just find the stage 2 image and mount it. > > > > rescuecd.iso - Both stage 1 and stage 2. Regardless of your install method, the stage 2 image is always read from the installation media with this disc. > > > > I tend to go with the rescuecd.iso disc and do HTTP installs. Works great, download time is minimal for the image itself. And if you have a local mirror of the release, installation won't take forever. > > > > Is it possible to do what I do with debian. > I normally make a tarball with the packages from /var/cache/apt/archives > Install the base system and when I get to package selection, switch to > console and unpack tarball. This way I don't have to download packages > I have downloaded previously. > > Is it possible to do similar thing with /var/cache/yum ? Yes. Setting keepcache=1 in /etc/yum.conf keeps all previously downloaded rpm in /var/cache/yum* and allows you to reuse them later. I am nfs-mounting /var/cache/yum and sharing them across my local network. Ralf From joachim.frieben at googlemail.com Thu Jan 31 06:18:54 2008 From: joachim.frieben at googlemail.com (Joachim Frieben) Date: Thu, 31 Jan 2008 07:18:54 +0100 Subject: Firefox and Epiphany crash after today's updates In-Reply-To: <200801302227.m0UMQtvX022692@laptop13.inf.utfsm.cl> References: <200801302227.m0UMQtvX022692@laptop13.inf.utfsm.cl> Message-ID: <1c252d490801302218y7581df7w8c6f983f5de28@mail.gmail.com> On Jan 30, 2008 11:26 PM, Horst H. von Brand wrote: > After updating today, trying to get into > (I have a password > saved for that site in Firefox) both browsers crash. BZ'd at > . > > [Yes, the site could very well be badly built, but crashing isn't epiphany crashes ever since upgrading to xulrunner > 1.9-0.beta2.11.nightly20080115.fc9, see https://bugzilla.redhat.com/show_bug.cgi?id=356731#c34 . I can open the page without problem using epiphany-2.21.5-0.1.svn7856.fc9and xulrunner-1.9-0.beta2.11.nightly20080115.fc9. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsmetana at redhat.com Thu Jan 31 06:45:14 2008 From: tsmetana at redhat.com (=?UTF-8?B?VG9tw6HFoQ==?= Smetana) Date: Thu, 31 Jan 2008 07:45:14 +0100 Subject: rawhide report: 20080130 changes In-Reply-To: <20080130205916.CAD6027018F@magilla.localdomain> References: <200801301448.m0UEmLso016720@porkchop.devel.redhat.com> <20080130164716.3ed1f8e3@dhcp03.addix.net> <47A0DF8B.60202@redhat.com> <20080130205916.CAD6027018F@magilla.localdomain> Message-ID: <20080131074514.23d825de@dhcp-lab-165.englab.brq.redhat.com> On Wed, 30 Jan 2008 12:59:16 -0800 (PST) Roland McGrath wrote: > > This was caused by the update to file-4.23. > > This was an upstream code change between 4.21 and 4.23, for which > there is no proper explanation I can find. Also, it wasn't changed > for 64-bit ELF files. This change should be reverted upstream. > > In file-4.23/src/readelf.c, file_tryelf was changed to check e_type > and call doshn only for ET_EXEC and ET_DYN files. It really ought to > just call it for any type except ET_CORE, without listing the > individual ones, like it used to do. It is also perfectly fine to > call dophn_exec for any file with e_phnum != 0, without checking its > type other than for ET_CORE. The change was probably meant to call > dophn_exec for ET_DYN too, which 64-bit still does not do. You'd get > that just by not checking the type. It would also be less error prone > not to duplicate the logic for 32/64. Instead, it can just call a > shared function with the values from e_* fields. Sorry. It's my fault. I'll try to fix this ASAP. -- Tom?? Smetana Base OS Software Engineer, Red Hat RH IRC: #brno #devel #base-os; Freenode IRC: #fedora-devel From tagoh at redhat.com Thu Jan 31 07:23:23 2008 From: tagoh at redhat.com (Akira TAGOH) Date: Thu, 31 Jan 2008 16:23:23 +0900 (JST) Subject: Can't log into kojiweb Message-ID: <20080131.162323.-1343655093.tagoh@redhat.com> Hi, I'm facing an issue that I can't log into kojiweb now. when I click the login link, it's just redirecting to the same page and the login link is still there that means I'm not still logging into kojiweb, without any notice. Does anyone else see the same issue? am I missing any important information around the list? Regards, -- Akira TAGOH -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From csnook at redhat.com Thu Jan 31 08:31:13 2008 From: csnook at redhat.com (Chris Snook) Date: Thu, 31 Jan 2008 03:31:13 -0500 Subject: pulseaudio causing crashing of applications In-Reply-To: <47A14108.5050207@gmail.com> References: <47A1376D.7010408@redhat.com> <200801302201.58423.ben.kreuter@gmail.com> <47A14108.5050207@gmail.com> Message-ID: <47A18751.8070309@redhat.com> Andrew Farris wrote: > Benjamin Kreuter wrote: >> No, but I have had problems with pulseaudio and arts on the same >> system. I wasn't around to hear the discussion about including >> pulseaudio in F8...why did we go down that road? > > Maybe because pulseaudio is to arts what playstation is to atari? Now > I'm a big fan of atari, but its old. Pulseaudio is very cool, just not > perfect yet. > Perhaps a better analogy would be 3DO to Atari. Pulseaudio has a really cool design, but arts actually makes noise come out of my speakers. After dozens of F8 installs on 5 different machines, I have completely given up on getting sound to work with KDE. If I want sound, I have F7 and my old Mac. I imagine Ubuntu would work fine as well. Don't get me wrong, I'm thrilled that the Gnome developers are pushing ahead with all this neat stuff, but I wish they'd just let KDE be KDE if they're not even going to bother testing it. Every Red Hat/Fedora release since Red Hat 9 has had glaring KDE bugs not found in any other distribution. -- Chris From kagesenshi.87 at gmail.com Thu Jan 31 08:42:54 2008 From: kagesenshi.87 at gmail.com (Mohd Izhar Firdaus Ismail) Date: Thu, 31 Jan 2008 16:42:54 +0800 Subject: Fedora Education Spin In-Reply-To: <47A0D3BF.8030207@when.com> References: <479B4B6A.90805@when.com> <20080126194213.1a466781@redhat.com> <479BD6C7.3010608@fedoraproject.org> <20080126195027.0cefe0ad@redhat.com> <479BDAA4.6070304@fedoraproject.org> <20080127025259.32e47cee@lain.camperquake.de> <479BE80A.5080309@fedoraproject.org> <479C727B.7060308@when.com> <479CBF5F.80807@gmail.com> <47A0D3BF.8030207@when.com> Message-ID: On Jan 31, 2008 3:45 AM, wrote: > # create script for extras installation > echo '#!/bin/bash'$'\n'"su -c 'yum install atomix blender enigma > gcompris inkscape jokosher kalgebra kdeedu marble scribus solfege > stardict stellarium taskjuggler wxmaxima'" > /home/fedora/Desktop/extras.sh > chmod +x /home/fedora/Desktop/extras.sh how about using system-install-packages GUI instead of command line yum to avoid showing scary-terminals to users :P system-install-packages packageA packageB ..... my 2c -- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? http://fedoraproject.org/wiki/MohdIzharFirdaus http://blog.kagesenshi.org 92C2 B295 B40B B3DC 6866 5011 5BD2 584A 8A5D 7331 From lordmorgul at gmail.com Thu Jan 31 09:07:30 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Thu, 31 Jan 2008 01:07:30 -0800 Subject: pulseaudio causing crashing of applications In-Reply-To: <47A18751.8070309@redhat.com> References: <47A1376D.7010408@redhat.com> <200801302201.58423.ben.kreuter@gmail.com> <47A14108.5050207@gmail.com> <47A18751.8070309@redhat.com> Message-ID: <47A18FD2.70300@gmail.com> Chris Snook wrote: > Andrew Farris wrote: >> Benjamin Kreuter wrote: >>> No, but I have had problems with pulseaudio and arts on the same >>> system. I wasn't around to hear the discussion about including >>> pulseaudio in F8...why did we go down that road? >> >> Maybe because pulseaudio is to arts what playstation is to atari? Now >> I'm a big fan of atari, but its old. Pulseaudio is very cool, just >> not perfect yet. >> > > Perhaps a better analogy would be 3DO to Atari. Pulseaudio has a really > cool design, but arts actually makes noise come out of my speakers. > After dozens of F8 installs on 5 different machines, I have completely > given up on getting sound to work with KDE. If I want sound, I have F7 > and my old Mac. I imagine Ubuntu would work fine as well. > > Don't get me wrong, I'm thrilled that the Gnome developers are pushing > ahead with all this neat stuff, but I wish they'd just let KDE be KDE if > they're not even going to bother testing it. Every Red Hat/Fedora > release since Red Hat 9 has had glaring KDE bugs not found in any other > distribution. > > -- Chris You don't think that might have to do with the VERY small group of people attempting to keep it working while pushing the envelope with the newest KDE has to offer? There is no question that gnome gets more attention in Fedora, but more attention for KDE and getting things like pulseaudio to 'just work' would probably be more likely with more people working on it. What the few do right now is amazing to even keep KDE in the game. IMO it has everything to do with just not making it work; not with gnome doing their thing... -- Andrew Farris www.lordmorgul.net gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From lordmorgul at gmail.com Thu Jan 31 09:31:21 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Thu, 31 Jan 2008 01:31:21 -0800 Subject: pulseaudio causing crashing of applications In-Reply-To: <47A1376D.7010408@redhat.com> References: <47A1376D.7010408@redhat.com> Message-ID: <47A19569.7010700@gmail.com> Warren Togami wrote: > Hi folks, > > Is anyone else seeing regular crashing of applications like pidgin, > mplayer or xine caused by pulseaudio? Did anybody manage to get useful > backtraces out of this? > > Thanks, > Warren Togami > wtogami at redhat.com I just had an issue with rhythmbox locking up while playing through pulseaudio. It locked only when I switched to VT1 where root was logged in, and it immediately stopped playing and froze. I've got the backtrace for all threads, but the top few are below. The rest is rather long so I won't post it yet. I haven't had rhythmbox do this before tonight. Usually it will stop playing through the sink device (it is still trying to) until returning to the login that is running rhythmbox, but this time it actually froze and did not keep streaming to the sink. 0x00110402 in __kernel_vsyscall () (gdb) t a a bt Thread 12 (Thread 0xb5a5cb90 (LWP 8935)): #0 0x00110402 in __kernel_vsyscall () #1 0x00a4db05 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x008bba12 in ?? () from /lib/libglib-2.0.so.0 #3 0x008bbdb5 in g_async_queue_pop () from /lib/libglib-2.0.so.0 #4 0x0014ee9c in ?? () from /usr/lib/librhythmbox-core.so.0 #5 0x00908e4f in ?? () from /lib/libglib-2.0.so.0 #6 0x00a4953b in start_thread () from /lib/libpthread.so.0 #7 0x00f3befe in clone () from /lib/libc.so.6 Thread 11 (Thread 0xb505bb90 (LWP 8951)): #0 0x00110402 in __kernel_vsyscall () #1 0x00a50a6b in read () from /lib/libpthread.so.0 #2 0x008e1b6d in ?? () from /lib/libglib-2.0.so.0 #3 0x00908e4f in ?? () from /lib/libglib-2.0.so.0 #4 0x00a4953b in start_thread () from /lib/libpthread.so.0 #5 0x00f3befe in clone () from /lib/libc.so.6 Thread 10 (Thread 0xb3c1bb90 (LWP 10059)): #0 0x00110402 in __kernel_vsyscall () #1 0x00a4db05 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x0146deaf in ?? () from /usr/lib/gstreamer-0.10/libgstcoreelements.so #3 0x073befd9 in ?? () from /usr/lib/libgstreamer-0.10.so.0 #4 0x073bf692 in gst_pad_push () from /usr/lib/libgstreamer-0.10.so.0 #5 0x014b1b91 in ?? () from /usr/lib/gstreamer-0.10/libgstqtdemux.so #6 0x073d9656 in ?? () from /usr/lib/libgstreamer-0.10.so.0 #7 0x0090a9d8 in ?? () from /lib/libglib-2.0.so.0 #8 0x00908e4f in ?? () from /lib/libglib-2.0.so.0 #9 0x00a4953b in start_thread () from /lib/libpthread.so.0 #10 0x00f3befe in clone () from /lib/libc.so.6 Thread 9 (Thread 0xb6e8eb90 (LWP 10060)): #0 0x00110402 in __kernel_vsyscall () #1 0x00a4db05 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x0146deaf in ?? () from /usr/lib/gstreamer-0.10/libgstcoreelements.so #3 0x073befd9 in ?? () from /usr/lib/libgstreamer-0.10.so.0 #4 0x073bf692 in gst_pad_push () from /usr/lib/libgstreamer-0.10.so.0 #5 0x0144d5c7 in ?? () from /usr/lib/gstreamer-0.10/libgstplaybin.so ---Type to continue, or q to quit--- #6 0x073befd9 in ?? () from /usr/lib/libgstreamer-0.10.so.0 #7 0x073bf692 in gst_pad_push () from /usr/lib/libgstreamer-0.10.so.0 #8 0x073b0aaa in ?? () from /usr/lib/libgstreamer-0.10.so.0 #9 0x073befd9 in ?? () from /usr/lib/libgstreamer-0.10.so.0 #10 0x073bf692 in gst_pad_push () from /usr/lib/libgstreamer-0.10.so.0 #11 0x012db6c2 in ?? () from /usr/lib/gstreamer-0.10/libgstfaad.so #12 0x073befd9 in ?? () from /usr/lib/libgstreamer-0.10.so.0 #13 0x073bf692 in gst_pad_push () from /usr/lib/libgstreamer-0.10.so.0 #14 0x0146c2d8 in ?? () from /usr/lib/gstreamer-0.10/libgstcoreelements.so #15 0x073d9656 in ?? () from /usr/lib/libgstreamer-0.10.so.0 #16 0x0090a9d8 in ?? () from /lib/libglib-2.0.so.0 #17 0x00908e4f in ?? () from /lib/libglib-2.0.so.0 #18 0x00a4953b in start_thread () from /lib/libpthread.so.0 #19 0x00f3befe in clone () from /lib/libc.so.6 Thread 8 (Thread 0xb24acb90 (LWP 10140)): #0 0x00110402 in __kernel_vsyscall () #1 0x00a51266 in nanosleep () from /lib/libpthread.so.0 #2 0x0090b5c2 in g_usleep () from /lib/libglib-2.0.so.0 #3 0x037e3a5c in ?? () from /usr/lib/gstreamer-0.10/libgstxvimagesink.so #4 0x00908e4f in ?? () from /lib/libglib-2.0.so.0 #5 0x00a4953b in start_thread () from /lib/libpthread.so.0 #6 0x00f3befe in clone () from /lib/libc.so.6 Thread 7 (Thread 0xb10aab90 (LWP 10141)): #0 0x00110402 in __kernel_vsyscall () #1 0x00f31df3 in poll () from /lib/libc.so.6 #2 0x0686b812 in ?? () from /usr/lib/libpulse.so.0 #3 0x068606e4 in pa_mainloop_poll () from /usr/lib/libpulse.so.0 #4 0x068617b3 in pa_mainloop_iterate () from /usr/lib/libpulse.so.0 #5 0x06861854 in pa_mainloop_run () from /usr/lib/libpulse.so.0 #6 0x0686b713 in ?? () from /usr/lib/libpulse.so.0 #7 0x06885d0e in ?? () from /usr/lib/libpulse.so.0 #8 0x00a4953b in start_thread () from /lib/libpthread.so.0 #9 0x00f3befe in clone () from /lib/libc.so.6 -- Andrew Farris www.lordmorgul.net gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From csnook at redhat.com Thu Jan 31 09:47:01 2008 From: csnook at redhat.com (Chris Snook) Date: Thu, 31 Jan 2008 04:47:01 -0500 Subject: pulseaudio causing crashing of applications In-Reply-To: <47A18FD2.70300@gmail.com> References: <47A1376D.7010408@redhat.com> <200801302201.58423.ben.kreuter@gmail.com> <47A14108.5050207@gmail.com> <47A18751.8070309@redhat.com> <47A18FD2.70300@gmail.com> Message-ID: <47A19915.5050202@redhat.com> Andrew Farris wrote: > Chris Snook wrote: >> Andrew Farris wrote: >>> Benjamin Kreuter wrote: >>>> No, but I have had problems with pulseaudio and arts on the same >>>> system. I wasn't around to hear the discussion about including >>>> pulseaudio in F8...why did we go down that road? >>> >>> Maybe because pulseaudio is to arts what playstation is to atari? >>> Now I'm a big fan of atari, but its old. Pulseaudio is very cool, >>> just not perfect yet. >>> >> >> Perhaps a better analogy would be 3DO to Atari. Pulseaudio has a >> really cool design, but arts actually makes noise come out of my >> speakers. After dozens of F8 installs on 5 different machines, I have >> completely given up on getting sound to work with KDE. If I want >> sound, I have F7 and my old Mac. I imagine Ubuntu would work fine as >> well. >> >> Don't get me wrong, I'm thrilled that the Gnome developers are pushing >> ahead with all this neat stuff, but I wish they'd just let KDE be KDE >> if they're not even going to bother testing it. Every Red Hat/Fedora >> release since Red Hat 9 has had glaring KDE bugs not found in any >> other distribution. >> >> -- Chris > > You don't think that might have to do with the VERY small group of > people attempting to keep it working while pushing the envelope with the > newest KDE has to offer? There is no question that gnome gets more > attention in Fedora, but more attention for KDE and getting things like > pulseaudio to 'just work' would probably be more likely with more people > working on it. What the few do right now is amazing to even keep KDE in > the game. IMO it has everything to do with just not making it work; not > with gnome doing their thing... > On the contrary, the Gnome developers are actively breaking otherwise-functional KDE code, and have been for years. In Red Hat 9, the bluecurve KDE clock couldn't even stay synched with the system clock under load. That bug made me 50 minutes late for an exam. In RHEL 3, startkde was modified, for reasons unclear to me, in a way that caused it to fail to launch KDE when using an afs homedir under a UP kernel, though it worked by accident on SMP kernels. With FC4, I got so fed up with the myriad problems that I used the kde-redhat repository, and while it was at times a dependency nightmare, the software worked fine, because it was much closer to the upstream KDE code than the bastardized in-distro version. I have absolutely no interest in making Pulseaudio work with KDE. I just want sound to work with KDE. Unlike Pulseaudio, which has never once correctly made noise come out of my speakers (though I once got buzzing), arts actually does that, when not interfered with. Unlike the Fedora Gnome developers, the upstream KDE developers actually notice when stuff in KDE breaks, so the upstream KDE code tends to work pretty well until the Fedora Gnome developers start breaking it in the name of getting more people to work on it. SELinux has actually caused me more headaches than Gnomified KDE, but the SELinux developers actually respond to bug reports and fix them, sometimes within hours. With SELinux, the process works, and the result has been steadily improving quality. With Gnomified KDE, a Gnome developer decides that the correct fix is to make KDE do things the Gnome way, and puts the bug at the very end of his todo list, where is remains until bugzilla closes the bug a year later after the release goes EOL. The process is inaccessible to volunteer work from KDE users who are unfamiliar with Gnome code, which is why so few people are working on KDE in Fedora. The correct solution is to let KDE do things the KDE way, and keep Gnome from interfering. This will allow volunteers in the community to actively participate, and the worst-case scenario is that we get stuck with raw upstream KDE, which would be far better than we have today. -- Chris From lordmorgul at gmail.com Thu Jan 31 10:40:16 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Thu, 31 Jan 2008 02:40:16 -0800 Subject: pulseaudio causing crashing of applications In-Reply-To: <47A19569.7010700@gmail.com> References: <47A1376D.7010408@redhat.com> <47A19569.7010700@gmail.com> Message-ID: <47A1A590.7050708@gmail.com> Andrew Farris wrote: > Warren Togami wrote: >> Hi folks, >> >> Is anyone else seeing regular crashing of applications like pidgin, >> mplayer or xine caused by pulseaudio? Did anybody manage to get >> useful backtraces out of this? >> >> Thanks, >> Warren Togami >> wtogami at redhat.com > > I just had an issue with rhythmbox locking up while playing through > pulseaudio. It locked only when I switched to VT1 where root was logged > in, and it immediately stopped playing and froze. I've got the > backtrace for all threads, but the top few are below. The rest is > rather long so I won't post it yet. I haven't had rhythmbox do this > before tonight. > > Usually it will stop playing through the sink device (it is still trying > to) until returning to the login that is running rhythmbox, but this > time it actually froze and did not keep streaming to the sink. I have posted several backtraces [1]. I don't know if its PA related info or not really. I had posted several of them to a bug [2] tonight with xulrunner/firefox crashing but there are striking similarities between the xulrunner crashes and rhythmbox. I don't know if this is related to pulseaudio (not likely) but it could definitely be causing issues in most of those threaded apps. After galeon crashed once, as soon as I quit galeon (was attached in gdb) rhythmbox crashed as well right afterward. The rhythmbox bt I posted in the last email is there, and another one that occurred after galeon crashed. The CPU spins 100% as soon as this happens, and it just looks like there could be some threading issues going on with the latest rawhide changes. I thought it was xulrunner alone, but it looks likely that the rhythmbox crash was related. I tried but could not duplicate the timing of this crash (galeon -> rhythmbox). When rhythmbox has crashed, opening it again and just starting it playing has fixed things, its not as if the pulse server is dead. I have already installed the new gstreamer-0.10.17-1 in koji, but I believe those two backtraces were just before I installed it. Most of the debuginfo is missing, but I'll be trying to remedy that and see if these crashes keep happening. [1] http://www.lordmorgul.net/pub/fedora/testing/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=430981 -- Andrew Farris www.lordmorgul.net gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3 No one now has, and no one will ever again get, the big picture. - Daniel Geer ---- ---- From jon.nettleton at gmail.com Thu Jan 31 11:11:26 2008 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Thu, 31 Jan 2008 06:11:26 -0500 Subject: F9 for Eeepc In-Reply-To: <7f692fec0801301903u24c27fb6na03674ca151cab05@mail.gmail.com> References: <479A650D.8060401@cora.nwra.com> <1201304569.2057.22.camel@localhost.localdomain> <645d17210801251629y2811f3f7jf0886a166ffd2f8@mail.gmail.com> <479E7137.5020705@cora.nwra.com> <47A08781.70303@fedoraproject.org> <1201707976.3882.59.camel@birkoff> <7f692fec0801301903u24c27fb6na03674ca151cab05@mail.gmail.com> Message-ID: <1201777886.3882.67.camel@birkoff> On Wed, 2008-01-30 at 22:03 -0500, Yaakov Nemoy wrote: > On Jan 30, 2008 10:46 AM, Jon Nettleton wrote: > > Thanks for the heads up. I am not directly working with the Eeedora > > project. I am really most interested in getting the most functional low > > resolution desktop as possible. Xfce is fine, however I find that > > desktop environment a bit restrictive. Here is the environment I am > > building/using right now on my eeepc ( by the way this is > 2GB's ). I > > know I know, but I am more interested in functionality than space. > > > > 1) Devilspie to better customize size and position of windows. Overly > > large windows are still problematic and I am trying methods to fix this. > > I am thinking maybe scaling the window with a compositing manager might > > be the way to go. Oh and some kind of gui to configure devilspie, it is > > said that one doesn't exist yet. I am thinking angelcake would be a > > good name. > > Except that it doesn't do compositing yet, I recommend XMonad for your > WM (or any other tiling window manager). On such a small screen, it > should solve alot of difficulties you have in placing windows in a > reasonable space. There is no gui to configure it either, but you > have the same barrier both ways. At least this way you're not using > something as inelegant as devilspie. The Metacity in Rawhide does compositing now. That codebase with a few patches I am working on works quite nicely. I am not sure why you consider devilspie inelegant. It just hangs out and matches windows and places them if you tell it to. Very simple and straightforward. Jon From jos at xos.nl Thu Jan 31 11:19:38 2008 From: jos at xos.nl (Jos Vos) Date: Thu, 31 Jan 2008 12:19:38 +0100 Subject: long term support release In-Reply-To: <20080126193954.61e969fd@redhat.com> References: <1201240697.17905.179.camel@beck.corsepiu.local> <479A0A55.60409@fedoraproject.org> <1201277129.14800.25.camel@cutter> <200801251127.47467.jwilson@redhat.com> <1201278927.17905.382.camel@beck.corsepiu.local> <20080125195136.02a98f3d@redhat.com> <20080126081343.GA9229@jasmine.xos.nl> <80d7e4090801261251o4d08cefj217e18842f680357@mail.gmail.com> <20080126193954.61e969fd@redhat.com> Message-ID: <20080131111938.GB25656@jasmine.xos.nl> On Sat, Jan 26, 2008 at 07:39:54PM -0500, Jesse Keating wrote: > Much of this is changing for the better. The use of Koji internally > helps greatly, as does the effort going on in Fedora right now to > consolidate all the branding in easy to replace packages. We're > learning, keep bringing these issues up to us. Well. for RHEL5 I've filed this "bug" related to trademark separation . I didn't check how this is done in Fedora. For the rest, the "conga" package still contains Red Hat logos the last time I looked (and they can't be replaced easily, as they are part of the user interface with header text etc.). -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From nphilipp at redhat.com Thu Jan 31 11:54:55 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 31 Jan 2008 12:54:55 +0100 Subject: some package splits In-Reply-To: References: <1201615452.2793.6.camel@localhost.localdomain> <1201616415.2362.19.camel@gibraltar.str.redhat.com> Message-ID: <1201780495.31329.3.camel@gibraltar.str.redhat.com> On Tue, 2008-01-29 at 18:12 +0000, Kevin Kofler wrote: > Nils Philippsen redhat.com> writes: > > [...] > > Obsoletes: evince < $version > > Conflicts: evince < $version > > [...] > > %package dvi > > Obsoletes: evince < $version > > Conflicts: evince < $version > > [...] > > %package djvu > > Obsoletes: evince < $version > > Conflicts: evince < $version > > [...] > > > > This way, an existing old version of evince will get replaced by the > > triplet evince, evince-dvi and evince-djvu but new installations won't > > be affected --> no need for mentioning in the release ntoes. > > This doesn't really work: in practice, depsolvers will just pick an arbitrary > one out of the 3 packages in such a situation, not all 3. Is this intentional (i.e. does it serve a purpose)? Otherwise the depsolvers should be fixed as this makes splitting up packages rather painful. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From nphilipp at redhat.com Thu Jan 31 12:04:01 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 31 Jan 2008 13:04:01 +0100 Subject: Debian style net-install ISOs (from FudCON Raleigh) In-Reply-To: <479FB05C.30302@redhat.com> References: <479FB05C.30302@redhat.com> Message-ID: <1201781041.31329.9.camel@gibraltar.str.redhat.com> On Tue, 2008-01-29 at 18:01 -0500, Michael DeHaan wrote: > Thoughts? One thing that's missing is decent support for having the Internet connection directly on the machine, i.e. we can't rely on a DSL router being present which provides the Internet connection. To do that we'd need the PPPoe bits in the installer image and appropriate code in anaconda. Bonus points if the upgrade method would pull the DSL configuration bits from the already installed OS. NB: I guess something similar goes for cable modems. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From rdieter at math.unl.edu Thu Jan 31 12:34:30 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 31 Jan 2008 06:34:30 -0600 Subject: pulseaudio causing crashing of applications References: <47A1376D.7010408@redhat.com> <200801302201.58423.ben.kreuter@gmail.com> <47A14108.5050207@gmail.com> <47A18751.8070309@redhat.com> Message-ID: Chris Snook wrote: > Don't get me wrong, I'm thrilled that the Gnome developers are pushing > ahead with all this neat stuff, but I wish they'd just let KDE be KDE if > they're not even going to bother testing it. "They" != Gnome developers. They = KDE SIG. If you want someone to criticize and blame, blame the right people. :) That said, disabling pa support in kde is relatively simple (we left it optional on purpose): rpm -e kde-settings-pulseaudio alsa-plugins-pulseaudio (and restart your kde session). -- Rex From nphilipp at redhat.com Thu Jan 31 12:50:26 2008 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 31 Jan 2008 13:50:26 +0100 Subject: How much personal information is necessary to close a bug? In-Reply-To: References: <1201686688.13318.4.camel@fedlex.lex.hider.name> <364d303b0801300251s39ffe2b8we671f2005c836474@mail.gmail.com> <1201691235.13318.13.camel@fedlex.lex.hider.name> <364d303b0801300332i4bd4a2b9n28a0f5b9eb3271b@mail.gmail.com> Message-ID: <1201783826.31329.13.camel@gibraltar.str.redhat.com> On Wed, 2008-01-30 at 09:59 -0500, Jon Stanley wrote: > It does. If you were to for example write some documentation for how > to fix something, etc, then we couldn't use it, because the CLA > assigns copyright to Red Hat with regard to things that you do for the > Fedora Project. Just for clarification, by signing the CLA you don't assign copyright but grant a license to your contributions. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From laurent.rineau__fedora at normalesup.org Thu Jan 31 13:07:30 2008 From: laurent.rineau__fedora at normalesup.org (Laurent Rineau) Date: Thu, 31 Jan 2008 14:07:30 +0100 Subject: pulseaudio causing crashing of applications In-Reply-To: References: <47A1376D.7010408@redhat.com> <47A18751.8070309@redhat.com> Message-ID: <200801311407.30992@rineau.tsetse> On Thursday 31 January 2008 13:34:30 Rex Dieter wrote: > Chris Snook wrote: > > Don't get me wrong, I'm thrilled that the Gnome developers are pushing > > ahead with all this neat stuff, but I wish they'd just let KDE be KDE if > > they're not even going to bother testing it. > > "They" != Gnome developers. They = KDE SIG. If you want someone to > criticize and blame, blame the right people. :) > > That said, disabling pa support in kde is relatively simple (we left it > optional on purpose): > rpm -e kde-settings-pulseaudio alsa-plugins-pulseaudio > (and restart your kde session). How difficult would it be to make that setting a per-user choice? -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From rdieter at math.unl.edu Thu Jan 31 13:23:28 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 31 Jan 2008 07:23:28 -0600 Subject: pulseaudio causing crashing of applications References: <47A1376D.7010408@redhat.com> <47A18751.8070309@redhat.com> <200801311407.30992@rineau.tsetse> Message-ID: Laurent Rineau wrote: > On Thursday 31 January 2008 13:34:30 Rex Dieter wrote: >> Chris Snook wrote: >> > Don't get me wrong, I'm thrilled that the Gnome developers are pushing >> > ahead with all this neat stuff, but I wish they'd just let KDE be KDE >> > if they're not even going to bother testing it. >> >> "They" != Gnome developers. They = KDE SIG. If you want someone to >> criticize and blame, blame the right people. :) >> >> That said, disabling pa support in kde is relatively simple (we left it >> optional on purpose): >> rpm -e kde-settings-pulseaudio alsa-plugins-pulseaudio >> (and restart your kde session). > > How difficult would it be to make that setting a per-user choice? Not implemented, patches welcome. For lauching the pulseaudio daemon, that's easy, see /etc/kde/env/pulseaudio.sh add ability to read user-conf to optionally disable. To add a per-user ability to override the default alsa device/plugin (ala alsa-plugins-pulseaudio), that looks a bit harder. -- Rex From jima at beer.tclug.org Thu Jan 31 14:21:08 2008 From: jima at beer.tclug.org (Jima) Date: Thu, 31 Jan 2008 08:21:08 -0600 (CST) Subject: Debian style net-install ISOs (from FudCON Raleigh) In-Reply-To: <1201781041.31329.9.camel@gibraltar.str.redhat.com> References: <479FB05C.30302@redhat.com> <1201781041.31329.9.camel@gibraltar.str.redhat.com> Message-ID: On Thu, 31 Jan 2008, Nils Philippsen wrote: > One thing that's missing is decent support for having the Internet > connection directly on the machine, i.e. we can't rely on a DSL router > being present which provides the Internet connection. To do that we'd > need the PPPoe bits in the installer image and appropriate code in > anaconda. Bonus points if the upgrade method would pull the DSL > configuration bits from the already installed OS. > > NB: I guess something similar goes for cable modems. I've dealt with a lot of cable modems, but none that come to mind require software on the computer other than a TCP/IP stack. (MAC address registration crap aside.) DSL with PPPoE authentication is a bit of a corner case (but a valid one!). Jima (who supports 14 cable modem connections, 3 DSL w/o PPPoE, and 1 DSL with PPPoE...all terminated with OpenWRT devices) From dwinship at redhat.com Thu Jan 31 14:24:46 2008 From: dwinship at redhat.com (Dan Winship) Date: Thu, 31 Jan 2008 09:24:46 -0500 Subject: Libsoup troubles in rawhide (compat-libsoup22 needed) In-Reply-To: <1201748894.19021.12.camel@localhost.localdomain> References: <479F655F.2010000@odu.neva.ru> <1201660097.25209.24.camel@localhost.localdomain> <1201661054.2779.7.camel@localhost.localdomain> <1201748894.19021.12.camel@localhost.localdomain> Message-ID: <47A1DA2E.4010502@redhat.com> Paul W. Frields wrote: >>> I'm not the maintainer of libsoup. But I own one of the broken packages >>> (drivel). > BTW, I will probably try to handle my package with the limited skills at > my disposal, but if I fall short of the mark, I'm glad to know Dan's > available for consults. :-) Drivel has turned out to be pretty tricky, because it makes much heavier use of the XML-RPC API than any other other libsoup-using app, and XML-RPC is one of the the APIs that got changed the most from libsoup 2.2 to libsoup 2.4. But I'm working on it, and will post the patches to http://bugzilla.gnome.org/show_bug.cgi?id=513301 when I'm done. -- Dan From silfreed at silfreed.net Thu Jan 31 14:24:45 2008 From: silfreed at silfreed.net (Douglas E. Warner) Date: Thu, 31 Jan 2008 09:24:45 -0500 Subject: Koji tk/tcl dependancy problem (was: Koji build error (f8-x86_64): Missing Dependency: tcl = 1:8.4.15 is needed by package tk) In-Reply-To: <200801291523.54126.silfreed@silfreed.net> References: <200801291523.54126.silfreed@silfreed.net> Message-ID: <200801310924.50118.silfreed@silfreed.net> On Tuesday 29 January 2008, Douglas E. Warner wrote: > DEBUG util.py:261: ?Error: Missing Dependency: tcl = 1:8.4.15 is needed by > package tk Any idea what I need to do about this? I'm still having the same problem in koji, and it still builds correctly in F8 in my local mock setup. This doesn't seem to be arch dependant as it fails in PPC as well as x86_64 (doesn't seem that i386 can complete before one of those does). -Doug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From caillon at redhat.com Thu Jan 31 14:30:52 2008 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 31 Jan 2008 09:30:52 -0500 Subject: Firefox and Epiphany crash after today's updates In-Reply-To: <200801302227.m0UMQtvX022692@laptop13.inf.utfsm.cl> References: <200801302227.m0UMQtvX022692@laptop13.inf.utfsm.cl> Message-ID: <47A1DB9C.90402@redhat.com> On 01/30/2008 05:26 PM, Horst H. von Brand wrote: > After updating today, trying to get into > (I have a password > saved for that site in Firefox) both browsers crash. BZ'd at > . > > [Yes, the site could very well be badly built, but crashing isn't > acceptable.] I highly recommend filing every bug with Firefox 3 to upstream bugzilla and not to Red Hat bugzilla. I'm only grabbing snapshots as-is from HEAD and not adding patches to our package, as a rule. If there's a crash it needs to be reported upstream, and I think it would be great if Fedora contributors spent some time contributing to upstream(s) in general. From mmaslano at redhat.com Thu Jan 31 14:32:36 2008 From: mmaslano at redhat.com (Marcela Maslanova) Date: Thu, 31 Jan 2008 15:32:36 +0100 Subject: Koji tk/tcl dependancy problem In-Reply-To: <200801310924.50118.silfreed@silfreed.net> References: <200801291523.54126.silfreed@silfreed.net> <200801310924.50118.silfreed@silfreed.net> Message-ID: <47A1DC04.8060000@redhat.com> Ask rel-eng at fedoraproject.org about "tag" tcl on precise version 1:8.4.15. I have the same problem with every new tcl & tk version. Douglas E. Warner wrote: > On Tuesday 29 January 2008, Douglas E. Warner wrote: > >> DEBUG util.py:261: Error: Missing Dependency: tcl = 1:8.4.15 is needed by >> package tk >> > > Any idea what I need to do about this? I'm still having the same problem in > koji, and it still builds correctly in F8 in my local mock setup. > > This doesn't seem to be arch dependant as it fails in PPC as well as x86_64 > (doesn't seem that i386 can complete before one of those does). > > -Doug > From loupgaroublond at gmail.com Thu Jan 31 15:03:41 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 31 Jan 2008 10:03:41 -0500 Subject: Smolt RFC: File System Information In-Reply-To: <47A1422E.1080507@redhat.com> References: <7f692fec0801252035j66468790g47ddffb0d4479013@mail.gmail.com> <47A1422E.1080507@redhat.com> Message-ID: <7f692fec0801310703y25f8f9a8mc0349fa20cacc694@mail.gmail.com> On Jan 30, 2008 10:36 PM, Eric Sandeen wrote: > Yaakov Nemoy wrote: > > Hey list, > > > > I'm looking to get some input on a feature that was requested of > > Smolt. One file system engineer wants to collect some basic data > > about file systems in use, for fine tuning the default settings in > > Fedora and RHEL. This is something that we can all benefit by, and > > the greater participation we give, the better the results are going to > > be for everyone. To hilight the information to be collected, actions > > speak louder than words: > > > > yankee at dao:~$ sudo stat -f /dev/main/fedora8 > > File: "/dev/main/fedora8" > > ID: 0 Namelen: 255 Type: tmpfs > > Block size: 4096 Fundamental block size: 4096 > > Blocks: Total: 258215 Free: 258199 Available: 258199 > > Inodes: Total: 223935 Free: 222932 > > > > (Actually I think something might be broken, that data doesn't look > > correct for me) > > I think you sorted it out, but: stat the mountpoint not the dev... :) > > > In short, it will collect a list of file systems + types, and their usage stats. > > > > For the time being the stats won't be published on the web site. > > We're having some reporting issues, and I don't want to add another > > long running SQL query into the mix. However, anyone will be free to > > ask one of us to report on that information. Furthermore, this > > information will be enabled by default, for the time being, until we > > have thing set up to allow fine grained information hiding. Remember, > > all profiles will be anonymous as usual. > > > > Are there any underlying security or privacy issues here that would be > > a clear reason not to do this? Any other comments, or refinements? > > The only thing I can think of is that while you'd like to report any > filesystems in use (so as not to pre-select what you're interested in, > and potentially filter out, say, a large unknown community of befs > users...) you run the risk of possibly reporting a "secret" filesystem > name; for example if suddenly 500 HP machines start reporting that "zfs" > is in use, it might make you go "hmmm...." - but, I assume that other > things reported by smolt after grepping around the bios run similar > risks, and you're not worried about sending out those strings? That's of no consequence, because any report we would publish publically would never link the hardware to the software to the file system. All there would be is a count of 500 people using ZFS with certain settings, with absolutely no indication of who they are. Furthermore, unless you get a link to a profile, you have no way of ascertaining that link. If you share a profile link, then you lose anonymity anyways. I can't protect the privacy of people who don't want it ;) -Yaakov From loupgaroublond at gmail.com Thu Jan 31 15:05:01 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 31 Jan 2008 10:05:01 -0500 Subject: Smolt RFC: File System Information In-Reply-To: <47A146AA.9090101@redhat.com> References: <7f692fec0801252035j66468790g47ddffb0d4479013@mail.gmail.com> <47A1422E.1080507@redhat.com> <47A146AA.9090101@redhat.com> Message-ID: <7f692fec0801310705g2da8c154kef4ea1f62e503c66@mail.gmail.com> On Jan 30, 2008 10:55 PM, Eric Sandeen wrote: > Eric Sandeen wrote: > > > So ideally I guess I'd like to see essentially df & df -i information > > for any real (non-loop?) devices in /dev. > > Oh, one other thing I considered is that *if* the mountpoint is a > FHS-specified path (hence no privacy issues), then reporting it might be > interesting too - see what's used on /var vs. /tmp vs /home etc, and if > it's /secret-project then just report "other" - but that probably > complicates things a little. I have no objections for the same reasons I pointed out in my previous email. Someone else might. I'm going to approve this one (in so far as that I'm going to try to develop it.) -Yaakov From michel.sylvan at gmail.com Thu Jan 31 15:22:21 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Thu, 31 Jan 2008 10:22:21 -0500 Subject: GCC license change to GPLv3+ with parts staying GPLv2+ with exceptions In-Reply-To: <20080130192645.GP30691@devserv.devel.redhat.com> References: <20080130192645.GP30691@devserv.devel.redhat.com> Message-ID: On Jan 30, 2008 2:26 PM, Jakub Jelinek wrote: > Hi! > > dist-f9 switched to gcc-4.3.0-0.7 (shouldn't take too long before gcc trunk > is released as 4.3 release candidate upstream) and that version bump also > means license change to GPLv3+ for most of gcc. Runtime libraries and > crtfiles still stay at GPLv2+ with exceptions. > And advance warning to those who maintain C++ applications: GCC 4.3 breaks applications that do not explicitly #include the headers they use; some patching might be required. http://www.mail-archive.com/debian-hams at lists.debian.org/msg02733.html http://www.cyrius.com/journal/2007/05/10#gcc-4.3-include -- Michel Salim http://hircus.jaiku.com/ From jakub at redhat.com Thu Jan 31 15:29:21 2008 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 31 Jan 2008 10:29:21 -0500 Subject: GCC license change to GPLv3+ with parts staying GPLv2+ with exceptions In-Reply-To: References: <20080130192645.GP30691@devserv.devel.redhat.com> Message-ID: <20080131152921.GU30691@devserv.devel.redhat.com> On Thu, Jan 31, 2008 at 10:22:21AM -0500, Michel Salim wrote: > On Jan 30, 2008 2:26 PM, Jakub Jelinek wrote: > > dist-f9 switched to gcc-4.3.0-0.7 (shouldn't take too long before gcc trunk > > is released as 4.3 release candidate upstream) and that version bump also > > means license change to GPLv3+ for most of gcc. Runtime libraries and > > crtfiles still stay at GPLv2+ with exceptions. > > > And advance warning to those who maintain C++ applications: GCC 4.3 > breaks applications that do not explicitly #include the headers they > use; some patching might be required. > > http://www.mail-archive.com/debian-hams at lists.debian.org/msg02733.html > http://www.cyrius.com/journal/2007/05/10#gcc-4.3-include Better link is http://gcc.gnu.org/gcc-4.3/porting_to.html but this has been discussed here almost a month ago a lot, so I'm not sure it is necessary to repeat that. Jakub From sandeen at redhat.com Thu Jan 31 15:36:11 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Thu, 31 Jan 2008 09:36:11 -0600 Subject: Smolt RFC: File System Information In-Reply-To: <7f692fec0801310703y25f8f9a8mc0349fa20cacc694@mail.gmail.com> References: <7f692fec0801252035j66468790g47ddffb0d4479013@mail.gmail.com> <47A1422E.1080507@redhat.com> <7f692fec0801310703y25f8f9a8mc0349fa20cacc694@mail.gmail.com> Message-ID: <47A1EAEB.9000104@redhat.com> Yaakov Nemoy wrote: > On Jan 30, 2008 10:36 PM, Eric Sandeen wrote: >> ... but, I assume that other >> things reported by smolt after grepping around the bios run similar >> risks, and you're not worried about sending out those strings? > > That's of no consequence, because any report we would publish > publically would never link the hardware to the software to the file > system. All there would be is a count of 500 people using ZFS with > certain settings, with absolutely no indication of who they are. > Furthermore, unless you get a link to a profile, you have no way of > ascertaining that link. oh, right. I was thinking about an individual profile, not the aggregate stats, sorry - you're right of course. -Eric From laurent.rineau__fedora at normalesup.org Thu Jan 31 15:36:09 2008 From: laurent.rineau__fedora at normalesup.org (Laurent Rineau) Date: Thu, 31 Jan 2008 16:36:09 +0100 Subject: pulseaudio causing crashing of applications In-Reply-To: References: <47A1376D.7010408@redhat.com> <200801311407.30992@rineau.tsetse> Message-ID: <200801311636.09344@rineau.tsetse> On Thursday 31 January 2008 14:23:28 Rex Dieter wrote: > Laurent Rineau wrote: > > On Thursday 31 January 2008 13:34:30 Rex Dieter wrote: > >> Chris Snook wrote: > >> > Don't get me wrong, I'm thrilled that the Gnome developers are pushing > >> > ahead with all this neat stuff, but I wish they'd just let KDE be KDE > >> > if they're not even going to bother testing it. > >> > >> "They" != Gnome developers. They = KDE SIG. If you want someone to > >> criticize and blame, blame the right people. :) > >> > >> That said, disabling pa support in kde is relatively simple (we left it > >> optional on purpose): > >> rpm -e kde-settings-pulseaudio alsa-plugins-pulseaudio > >> (and restart your kde session). > > > > How difficult would it be to make that setting a per-user choice? > > Not implemented, patches welcome. > > For lauching the pulseaudio daemon, that's easy, see > /etc/kde/env/pulseaudio.sh > add ability to read user-conf to optionally disable. /etc/kde/env/pulseaudio.sh could use a trick like that: #!/bin/sh if [ -x /usr/bin/pulseaudio -a ! -e $HOME/.pulse/do-not-launch-in-kde]; then /usr/bin/pulseaudio -D fi That would allow users to block pulseaudio by creating a dummy file $HOME/.pulse/do-not-launch-in-kde. That is not a pretty solution however. > To add a per-user ability to override the default alsa device/plugin (ala > alsa-plugins-pulseaudio), that looks a bit harder. Actually that is the easiest: the user can put the following in $HOME/.asoundrc pcm.!default { type hw card 0 } ctl.!default { type hw card 0 } -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From ben.kreuter at gmail.com Thu Jan 31 15:36:40 2008 From: ben.kreuter at gmail.com (Benjamin Kreuter) Date: Thu, 31 Jan 2008 10:36:40 -0500 Subject: GCC license change to GPLv3+ with parts staying GPLv2+ with exceptions In-Reply-To: References: <20080130192645.GP30691@devserv.devel.redhat.com> Message-ID: <200801311036.44367.ben.kreuter@gmail.com> On Thursday 31 January 2008 10:22:21 Michel Salim wrote: > > And advance warning to those who maintain C++ applications: GCC 4.3 > breaks applications that do not explicitly #include the headers they > use; some patching might be required. It is generally a bad idea to rely on implicitly included headers, because it completely kills portability. Different STL implementations use different header hierarchies, and so the best practice is to explicitly include any headers you need. They all have inclusion guards, so there is really no risk to compiling if you do this, and most new C++ books advise this technique. Unfortunately, though, until very recently most STL implementations had myriad quirks that made portability a nightmare even if you followed best practices and wrote 100% compliant code. Alas, it is the same with every attempt at creating a standard; it takes years and years and years for the everyone to finally get it right (POSIX, CORBA, libc, etc., etc., etc...). -- Benjamin Kreuter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From jakub.rusinek at gmail.com Thu Jan 31 15:43:59 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Thu, 31 Jan 2008 16:43:59 +0100 Subject: Firefox and Epiphany crash after today's updates In-Reply-To: <47A1DB9C.90402@redhat.com> References: <200801302227.m0UMQtvX022692@laptop13.inf.utfsm.cl> <47A1DB9C.90402@redhat.com> Message-ID: <1201794239.3135.0.camel@geeko> Dnia 31-01-2008, czw o godzinie 09:30 -0500, Christopher Aillon pisze: > On 01/30/2008 05:26 PM, Horst H. von Brand wrote: > > After updating today, trying to get into > > (I have a password > > saved for that site in Firefox) both browsers crash. BZ'd at > > . > > > > [Yes, the site could very well be badly built, but crashing isn't > > acceptable.] > > I highly recommend filing every bug with Firefox 3 to upstream bugzilla > and not to Red Hat bugzilla. I'm only grabbing snapshots as-is from > HEAD and not adding patches to our package, as a rule. If there's a > crash it needs to be reported upstream, and I think it would be great if > Fedora contributors spent some time contributing to upstream(s) in general. Download nightly snapshot from Trunk and every day update it using ie. Help ? Check for updates. And file bugs as I'm doing. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? wiadomo?ci podpisana cyfrowo URL: From xavier at bachelot.org Thu Jan 31 16:46:24 2008 From: xavier at bachelot.org (Xavier Bachelot) Date: Thu, 31 Jan 2008 17:46:24 +0100 Subject: twiki in fedora ? Message-ID: <47A1FB60.8050600@bachelot.org> Hi all, Did anyone tried to package twiki for Fedora or is anyone working on it already ? http://twiki.org/ Regards, Xavier From caillon at redhat.com Thu Jan 31 16:49:14 2008 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 31 Jan 2008 11:49:14 -0500 Subject: Firefox and Epiphany crash after today's updates In-Reply-To: <1201794239.3135.0.camel@geeko> References: <200801302227.m0UMQtvX022692@laptop13.inf.utfsm.cl> <47A1DB9C.90402@redhat.com> <1201794239.3135.0.camel@geeko> Message-ID: <47A1FC0A.90509@redhat.com> On 01/31/2008 10:43 AM, Jakub 'Livio' Rusinek wrote: > Dnia 31-01-2008, czw o godzinie 09:30 -0500, Christopher Aillon pisze: >> On 01/30/2008 05:26 PM, Horst H. von Brand wrote: >>> After updating today, trying to get into >>> (I have a password >>> saved for that site in Firefox) both browsers crash. BZ'd at >>> . >>> >>> [Yes, the site could very well be badly built, but crashing isn't >>> acceptable.] >> I highly recommend filing every bug with Firefox 3 to upstream bugzilla >> and not to Red Hat bugzilla. I'm only grabbing snapshots as-is from >> HEAD and not adding patches to our package, as a rule. If there's a >> crash it needs to be reported upstream, and I think it would be great if >> Fedora contributors spent some time contributing to upstream(s) in general. > > Download nightly snapshot from Trunk and every day update it using ie. > Help ? Check for updates. What would it take to get you to use _our_ builds? Because in the end, Mozilla is _NOT_ going to distribute a binary for the final version of Firefox 3. It would be great if you were testing builds the way they are going to be done for final. From notting at redhat.com Thu Jan 31 17:08:30 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 31 Jan 2008 12:08:30 -0500 Subject: some package splits In-Reply-To: <1201780495.31329.3.camel@gibraltar.str.redhat.com> References: <1201615452.2793.6.camel@localhost.localdomain> <1201616415.2362.19.camel@gibraltar.str.redhat.com> <1201780495.31329.3.camel@gibraltar.str.redhat.com> Message-ID: <20080131170830.GB14673@nostromo.devel.redhat.com> Nils Philippsen (nphilipp at redhat.com) said: > Is this intentional (i.e. does it serve a purpose)? Otherwise the > depsolvers should be fixed as this makes splitting up packages rather > painful. If you have syslog-ng, rsyslog, and something else all obsoleting sysklogd, I don't think you want to automatically install all of them. (Then again, that may not be a proper usage of Obsoletes.) Bill From jakub.rusinek at gmail.com Thu Jan 31 17:38:30 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Thu, 31 Jan 2008 18:38:30 +0100 Subject: Firefox and Epiphany crash after today's updates In-Reply-To: <47A1FC0A.90509@redhat.com> References: <200801302227.m0UMQtvX022692@laptop13.inf.utfsm.cl> <47A1DB9C.90402@redhat.com> <1201794239.3135.0.camel@geeko> <47A1FC0A.90509@redhat.com> Message-ID: <1201801110.3258.0.camel@geeko> Dnia 31-01-2008, czw o godzinie 11:49 -0500, Christopher Aillon pisze: > On 01/31/2008 10:43 AM, Jakub 'Livio' Rusinek wrote: > > Dnia 31-01-2008, czw o godzinie 09:30 -0500, Christopher Aillon pisze: > >> On 01/30/2008 05:26 PM, Horst H. von Brand wrote: > >>> After updating today, trying to get into > >>> (I have a password > >>> saved for that site in Firefox) both browsers crash. BZ'd at > >>> . > >>> > >>> [Yes, the site could very well be badly built, but crashing isn't > >>> acceptable.] > >> I highly recommend filing every bug with Firefox 3 to upstream bugzilla > >> and not to Red Hat bugzilla. I'm only grabbing snapshots as-is from > >> HEAD and not adding patches to our package, as a rule. If there's a > >> crash it needs to be reported upstream, and I think it would be great if > >> Fedora contributors spent some time contributing to upstream(s) in general. > > > > Download nightly snapshot from Trunk and every day update it using ie. > > Help ? Check for updates. > > What would it take to get you to use _our_ builds? Because in the end, > Mozilla is _NOT_ going to distribute a binary for the final version of > Firefox 3. It would be great if you were testing builds the way they > are going to be done for final. Until Firefox 3 is released I'm hunting on their bugs and filing them. When Firefox 3 is released, I'll be one of the first testers. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? wiadomo?ci podpisana cyfrowo URL: From tmz at pobox.com Thu Jan 31 18:00:12 2008 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 31 Jan 2008 13:00:12 -0500 Subject: Koji tk/tcl dependancy problem In-Reply-To: <47A1DC04.8060000@redhat.com> References: <200801291523.54126.silfreed@silfreed.net> <200801310924.50118.silfreed@silfreed.net> <47A1DC04.8060000@redhat.com> Message-ID: <20080131180012.GU3082@inocybe.teonanacatl.org> Marcela Maslanova wrote: > Ask rel-eng at fedoraproject.org about "tag" tcl on precise version > 1:8.4.15. I have the same problem with every new tcl & tk version. This is broken in a slightly different way in updates-testing for F8: Resolving Dependencies --> Running transaction check ---> Package tk.i386 1:8.4.17-2.fc8 set to be updated --> Processing Dependency: tcl = 1:8.4.17 for package: tk --> Finished Dependency Resolution Error: Missing Dependency: tcl = 1:8.4.17 is needed by package tk The update that would correct it is pending in bodhi though: https://admin.fedoraproject.org/updates/F8/pending/tcl-8.4.17-1.fc8 Any idea why tk and tcl weren't both pushed at the same time? -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I believe in the noble, aristocratic art of doing absolutely nothing. And someday, I hope to be in a position where I can do even less. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From loupgaroublond at gmail.com Thu Jan 31 18:46:17 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Thu, 31 Jan 2008 13:46:17 -0500 Subject: Smolt RFC: Submitting Profile on upgrade Message-ID: <7f692fec0801311046i38480f1fq4424e765d1b96ee0@mail.gmail.com> Hey List, I want to ask a quick question to everyone about a change I would like to have made to Smolt. We're looking at making some other broad changes to Smolt which will be pushed as an upgrade that quite frankly will be mandatory because of security issues. There will also be other information that has been requested by two separate parties. I would like to have the Smolt client send an update to the server when it is installed. It will, of course, only send information on a system that has this already enabled by default. The same information will still be resent the first through third of every month. This will ensure fresh information in our database. It will also cause the server to run out of memory during an upgrade cycle, although we have some countermeasures against that in Infrastructure, but I'm just giving a heads up. Any objections? Privacy? Blatant Abuse of bandwidth? Tinfoil hats? Cheers, Yaakov From caillon at redhat.com Thu Jan 31 18:46:43 2008 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 31 Jan 2008 13:46:43 -0500 Subject: Firefox and Epiphany crash after today's updates In-Reply-To: <1201801110.3258.0.camel@geeko> References: <200801302227.m0UMQtvX022692@laptop13.inf.utfsm.cl> <47A1DB9C.90402@redhat.com> <1201794239.3135.0.camel@geeko> <47A1FC0A.90509@redhat.com> <1201801110.3258.0.camel@geeko> Message-ID: <47A21793.1070505@redhat.com> On 01/31/2008 12:38 PM, Jakub 'Livio' Rusinek wrote: > Until Firefox 3 is released I'm hunting on their bugs and filing them. > When Firefox 3 is released, I'll be one of the first testers. You're missing my point. I am shipping CVS code snapshots of Firefox 3. You know, just like you are downloading from mozilla.org. But in RPM format instead of a tarball. Specifically for Fedora. Not generic builds that will work in every distro (provided that they have the minimum requirements). So my builds will perform a bit better. From Jochen at herr-schmitt.de Thu Jan 31 18:49:52 2008 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 31 Jan 2008 19:49:52 +0100 Subject: redetermination of relationship between koji buildtags and used repositories Message-ID: <47A21850.1090302@herr-schmitt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I would to ask, how I can determinate which repositories are use for a special koji build tag liki dist-f9-gcc43? And the second question is it possible to include this repositories in a local mock configuration? Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHohg3T2AHK6txfgwRAmxQAJ9KoeknTjc5o97ADT34r+XCX+eFfgCfXKhG w7X9P9HPA2+EAZC5P34Jz98= =Z1hL -----END PGP SIGNATURE----- From vonbrand at inf.utfsm.cl Thu Jan 31 18:54:35 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Thu, 31 Jan 2008 15:54:35 -0300 Subject: Firefox and Epiphany crash after today's updates In-Reply-To: <47A21793.1070505@redhat.com> References: <200801302227.m0UMQtvX022692@laptop13.inf.utfsm.cl> <47A1DB9C.90402@redhat.com> <1201794239.3135.0.camel@geeko> <47A1FC0A.90509@redhat.com> <1201801110.3258.0.camel@geeko> <47A21793.1070505@redhat.com> Message-ID: <200801311854.m0VIsZ3U011327@laptop13.inf.utfsm.cl> Christopher Aillon wrote: > On 01/31/2008 12:38 PM, Jakub 'Livio' Rusinek wrote: > > Until Firefox 3 is released I'm hunting on their bugs and filing them. > > When Firefox 3 is released, I'll be one of the first testers. > You're missing my point. I am shipping CVS code snapshots of Firefox > 3. You know, just like you are downloading from mozilla.org. But in > RPM format instead of a tarball. Specifically for Fedora. Not > generic builds that will work in every distro (provided that they have > the minimum requirements). So my builds will perform a bit better. How are we supposed to report bugs then? - They aren't the upstream-"supported" binaries - We don't know what CVS revision went into them - We have no clue on Fedora-specific configuration/tweaking -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From jakub.rusinek at gmail.com Thu Jan 31 18:51:06 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Thu, 31 Jan 2008 19:51:06 +0100 Subject: Firefox and Epiphany crash after today's updates In-Reply-To: <47A21793.1070505@redhat.com> References: <200801302227.m0UMQtvX022692@laptop13.inf.utfsm.cl> <47A1DB9C.90402@redhat.com> <1201794239.3135.0.camel@geeko> <47A1FC0A.90509@redhat.com> <1201801110.3258.0.camel@geeko> <47A21793.1070505@redhat.com> Message-ID: <1201805466.3994.6.camel@geeko> Dnia 31-01-2008, czw o godzinie 13:46 -0500, Christopher Aillon pisze: > On 01/31/2008 12:38 PM, Jakub 'Livio' Rusinek wrote: > > Until Firefox 3 is released I'm hunting on their bugs and filing them. > > When Firefox 3 is released, I'll be one of the first testers. > > You're missing my point. I am shipping CVS code snapshots of Firefox 3. > You know, just like you are downloading from mozilla.org. But in RPM > format instead of a tarball. Specifically for Fedora. Not generic > builds that will work in every distro (provided that they have the > minimum requirements). So my builds will perform a bit better. I'm testing mostly how Firefox integrates with Linux and how much does it suck [kidding] :P . And it doesn't matter for me if I have RPM or tarball, because of what I'm testing. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? wiadomo?ci podpisana cyfrowo URL: From michel.sylvan at gmail.com Thu Jan 31 19:05:41 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Thu, 31 Jan 2008 14:05:41 -0500 Subject: some package splits In-Reply-To: <20080131170830.GB14673@nostromo.devel.redhat.com> References: <1201615452.2793.6.camel@localhost.localdomain> <1201616415.2362.19.camel@gibraltar.str.redhat.com> <1201780495.31329.3.camel@gibraltar.str.redhat.com> <20080131170830.GB14673@nostromo.devel.redhat.com> Message-ID: On Jan 31, 2008 12:08 PM, Bill Nottingham wrote: > Nils Philippsen (nphilipp at redhat.com) said: > > Is this intentional (i.e. does it serve a purpose)? Otherwise the > > depsolvers should be fixed as this makes splitting up packages rather > > painful. > > If you have syslog-ng, rsyslog, and something else all obsoleting > sysklogd, I don't think you want to automatically install all of them. > > (Then again, that may not be a proper usage of Obsoletes.) > Seems like we want a field like "Suggests:". That would accomodate Jef's idea of offering users to install missing packages (in this case, the set of suggested packages - installed packages) easily. Regards, -- Michel Salim http://hircus.jaiku.com/ From jkeating at redhat.com Thu Jan 31 19:04:12 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 31 Jan 2008 14:04:12 -0500 Subject: Koji tk/tcl dependancy problem In-Reply-To: <20080131180012.GU3082@inocybe.teonanacatl.org> References: <200801291523.54126.silfreed@silfreed.net> <200801310924.50118.silfreed@silfreed.net> <47A1DC04.8060000@redhat.com> <20080131180012.GU3082@inocybe.teonanacatl.org> Message-ID: <20080131140412.5a4a0c00@redhat.com> On Thu, 31 Jan 2008 13:00:12 -0500 Todd Zullinger wrote: > The update that would correct it is pending in bodhi though: > > https://admin.fedoraproject.org/updates/F8/pending/tcl-8.4.17-1.fc8 > > Any idea why tk and tcl weren't both pushed at the same time? The maintainer is trying to get tk build against the pending tcl, and thus asked for tcl to be udpated in the buildroot, which I did. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mikeb at redhat.com Thu Jan 31 19:16:58 2008 From: mikeb at redhat.com (Mike Bonnet) Date: Thu, 31 Jan 2008 14:16:58 -0500 Subject: redetermination of relationship between koji buildtags and used repositories In-Reply-To: <47A21850.1090302@herr-schmitt.de> References: <47A21850.1090302@herr-schmitt.de> Message-ID: <1201807018.25387.9.camel@localhost.localdomain> > I would to ask, how I can determinate which repositories are use for a > special koji build tag liki dist-f9-gcc43? You're probably talking about the "build target" here. You can search for a build target with that name, which will take you here: http://koji.fedoraproject.org/koji/buildtargetinfo?targetID=16 Which shows that the build tag (where packages used to populate the buildroots and satisfy BuildRequires come from) is dist-f9-gcc43-build, and the destination tag for built packages is dist-f9-gcc43. > And the second question is it possible to include this repositories in > a local mock configuration? Yes, you can use "koji mock-config". Something like this should generate an appropriate config to use to pull packages from the dist-f9-gcc43-build tag: koji mock-config --topurl http://koji.fedoraproject.org \ --arch i386 --tag dist-f9-gcc43-build my-mock-config Note that this config won't be valid forever, since repos get obsoleted and eventually deleted. It will be valid for at least a week though. If you want the absolutely latest packages, you should regenerate the mock config before every local build. From caillon at redhat.com Thu Jan 31 19:43:23 2008 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 31 Jan 2008 14:43:23 -0500 Subject: Firefox and Epiphany crash after today's updates In-Reply-To: <200801311854.m0VIsZ3U011327@laptop13.inf.utfsm.cl> References: <200801302227.m0UMQtvX022692@laptop13.inf.utfsm.cl> <47A1DB9C.90402@redhat.com> <1201794239.3135.0.camel@geeko> <47A1FC0A.90509@redhat.com> <1201801110.3258.0.camel@geeko> <47A21793.1070505@redhat.com> <200801311854.m0VIsZ3U011327@laptop13.inf.utfsm.cl> Message-ID: <47A224DB.2050308@redhat.com> On 01/31/2008 01:54 PM, Horst H. von Brand wrote: > How are we supposed to report bugs then? > > - They aren't the upstream-"supported" binaries There are no upstream supported binaries. > - We don't know what CVS revision went into them CVS has no concept of a repository wide revision. So it's impossible to tell anyway. The date of the snapshot is generally good enough. Even upstream, people file bugs as "on trunk from yesterday" etc. > - We have no clue on Fedora-specific configuration/tweaking There really isn't much tweaking. This is intentional. The big "tweaks" are pref tweaks and using system libaries of e.g. nspr, nss, libjpeg, libpng, etc. instead of building a static copy into the binaries, but these should in general be irrelevant to 99% of bugs filed. Also the other big thing is we're using FF-as-a-XULRunner app which upstream is excited about, and wants feedback on, but should not have any different behavior. Bottmon line: if anyone complains about you filing a bug on Fedora builds, let me know. Because they shouldn't. It's no different from any of the major contributors of FF doing self builds of Firefox themselves and reporting bugs. From caillon at redhat.com Thu Jan 31 20:01:46 2008 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 31 Jan 2008 15:01:46 -0500 Subject: Firefox and Epiphany crash after today's updates In-Reply-To: <1201805466.3994.6.camel@geeko> References: <200801302227.m0UMQtvX022692@laptop13.inf.utfsm.cl> <47A1DB9C.90402@redhat.com> <1201794239.3135.0.camel@geeko> <47A1FC0A.90509@redhat.com> <1201801110.3258.0.camel@geeko> <47A21793.1070505@redhat.com> <1201805466.3994.6.camel@geeko> Message-ID: <47A2292A.106@redhat.com> On 01/31/2008 01:51 PM, Jakub 'Livio' Rusinek wrote: > Dnia 31-01-2008, czw o godzinie 13:46 -0500, Christopher Aillon pisze: >> On 01/31/2008 12:38 PM, Jakub 'Livio' Rusinek wrote: >>> Until Firefox 3 is released I'm hunting on their bugs and filing them. >>> When Firefox 3 is released, I'll be one of the first testers. >> You're missing my point. I am shipping CVS code snapshots of Firefox 3. >> You know, just like you are downloading from mozilla.org. But in RPM >> format instead of a tarball. Specifically for Fedora. Not generic >> builds that will work in every distro (provided that they have the >> minimum requirements). So my builds will perform a bit better. > > I'm testing mostly how Firefox integrates with Linux and how much does > it suck [kidding] :P . > > And it doesn't matter for me if I have RPM or tarball, because of what > I'm testing. I've seen your bugs. It really doesn't matter. So why not use Fedora's RPM builds? From dmc.fedora at filteredperception.org Thu Jan 31 20:18:54 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Thu, 31 Jan 2008 14:18:54 -0600 Subject: F9 for Eeepc In-Reply-To: <1201777886.3882.67.camel@birkoff> References: <479A650D.8060401@cora.nwra.com> <1201304569.2057.22.camel@localhost.localdomain> <645d17210801251629y2811f3f7jf0886a166ffd2f8@mail.gmail.com> <479E7137.5020705@cora.nwra.com> <47A08781.70303@fedoraproject.org> <1201707976.3882.59.camel@birkoff> <7f692fec0801301903u24c27fb6na03674ca151cab05@mail.gmail.com> <1201777886.3882.67.camel@birkoff> Message-ID: <47A22D2E.8000606@filteredperception.org> Jon Nettleton wrote: > On Wed, 2008-01-30 at 22:03 -0500, Yaakov Nemoy wrote: >> On Jan 30, 2008 10:46 AM, Jon Nettleton wrote: >>> Thanks for the heads up. I am not directly working with the Eeedora >>> project. I am really most interested in getting the most functional low >>> resolution desktop as possible. Xfce is fine, however I find that >>> desktop environment a bit restrictive. Here is the environment I am >>> building/using right now on my eeepc ( by the way this is > 2GB's ). I >>> know I know, but I am more interested in functionality than space. >>> >>> 1) Devilspie to better customize size and position of windows. Overly >>> large windows are still problematic and I am trying methods to fix this. >>> I am thinking maybe scaling the window with a compositing manager might >>> be the way to go. Oh and some kind of gui to configure devilspie, it is >>> said that one doesn't exist yet. I am thinking angelcake would be a >>> good name. >> Except that it doesn't do compositing yet, I recommend XMonad for your >> WM (or any other tiling window manager). On such a small screen, it >> should solve alot of difficulties you have in placing windows in a >> reasonable space. There is no gui to configure it either, but you >> have the same barrier both ways. At least this way you're not using >> something as inelegant as devilspie. > > The Metacity in Rawhide does compositing now. That codebase with a few > patches I am working on works quite nicely. I am not sure why you > consider devilspie inelegant. It just hangs out and matches windows and > places them if you tell it to. Very simple and straightforward. Devilspie looks interesting. Looks like a nice lisp wrapper for stuff I had been doing myself with wmctrl. So maybe wmctrl is worth looking at as well. -dmc From bpepple at fedoraproject.org Thu Jan 31 20:53:59 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 31 Jan 2008 15:53:59 -0500 Subject: FESCo Meeting Summary for 2008-01-31 Message-ID: <1201812839.16538.6.camel@nixon> == Members Present == * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Dennis Gilmore (dgilmore) * Bill Nottingham (notting) * Tom Callaway (spot) * Warren Togami (warren) * Jeremy Katz (jeremy) * Christian Iseli (c4chris) * Kevin Fenzi (nirik) * Christopher Aillon (caillon) * Jesse Keating (f13) == Absent == * Josh Boyer (jwb) * David Woodhouse (dwmw2) == Summary == === New Package Maintainer Sponsor === * FESCo approved Ruben Kerkhof's request to become a sponsor. === F9 Feature Process === * FESCo approved the following feature for F9: * http://fedoraproject.org/wiki/Anaconda/Features/SecondStageInstallSource * http://fedoraproject.org/wiki/Releases/FeatureEncryptedFilesystems * http://fedoraproject.org/wiki/Features/PreUpgrade * FESCo still had more questions in regard to the Input Method and Desktop Integration proposal before approving it. dgilmore added the questions to the comments section. http://fedoraproject.org/wiki/Features/IMDesktopIntegration * John Poelstra (polecat) mentioned feature owners should update the release notes section of their features, since the Alpha release is just around the corner. IRC log can be found at: http://bpepple.fedorapeople.org/fesco/FESCo-2008-01-31.html Later, /B -- Brian Pepple http://fedoraproject.org/wiki/BrianPepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From smooge at gmail.com Thu Jan 31 20:58:09 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 31 Jan 2008 13:58:09 -0700 Subject: some package splits In-Reply-To: References: <1201615452.2793.6.camel@localhost.localdomain> <1201616415.2362.19.camel@gibraltar.str.redhat.com> <1201780495.31329.3.camel@gibraltar.str.redhat.com> <20080131170830.GB14673@nostromo.devel.redhat.com> Message-ID: <80d7e4090801311258i1513deaco4f97a8c649adb3ba@mail.gmail.com> On Jan 31, 2008 12:05 PM, Michel Salim wrote: > On Jan 31, 2008 12:08 PM, Bill Nottingham wrote: > > Nils Philippsen (nphilipp at redhat.com) said: > > > Is this intentional (i.e. does it serve a purpose)? Otherwise the > > > depsolvers should be fixed as this makes splitting up packages rather > > > painful. > > > > If you have syslog-ng, rsyslog, and something else all obsoleting > > sysklogd, I don't think you want to automatically install all of them. > > > > (Then again, that may not be a proper usage of Obsoletes.) > > > Seems like we want a field like "Suggests:". That would accomodate > Jef's idea of offering users to install missing packages (in this > case, the set of suggested packages - installed packages) easily. > Isn't that in rpm5? How about moving to that.. . -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From kanarip at kanarip.com Thu Jan 31 20:59:10 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 31 Jan 2008 21:59:10 +0100 Subject: Debian style net-install ISOs (from FudCON Raleigh) In-Reply-To: <47A13286.7060102@ncsu.edu> References: <479FB05C.30302@redhat.com> <20080130094315.bfaa0c44.dcantrell@redhat.com> <1201725700.27307.12.camel@cutter> <47A11E20.2090406@kanarip.com> <47A13286.7060102@ncsu.edu> Message-ID: <47A2369E.3040902@kanarip.com> Casey Dahlin wrote: > Jeroen van Meeuwen wrote: >> seth vidal wrote: >>> all that michael dehaan was suggesting was that we hard code some >>> default paths on the rescuecd to point to download.fedoraproject.org or >>> to the mirrorlists. Then it makes using the iso for the simplest case >>> even easier and for more complicated cases no harder. >>> >> >> Aha, the "insert, boot and press enter" use case ;-) +1 for squeezing >> that in somewhere, but wouldn't that be a rescue+very minimalistic >> kickstart? I use kickstart to prevent the (in my personal opinion) >> language and keyboard settings dialog from popping up... I'm not sure >> what else it can take in a rescue cd environment? >> > > In your opinion they are language and keyboard settings? What other > opinions have you met? :P > As I'm sure you'll understand this has been a customized rescue CD compose with the appropriate language and keyboard settings for my locale; English -said the Dutchman. You can probably tell I'm not a native English speaker. That being said... That wasn't my point ;-) -Jeroen From jakub.rusinek at gmail.com Thu Jan 31 20:57:05 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Thu, 31 Jan 2008 21:57:05 +0100 Subject: Firefox and Epiphany crash after today's updates In-Reply-To: <47A2292A.106@redhat.com> References: <200801302227.m0UMQtvX022692@laptop13.inf.utfsm.cl> <47A1DB9C.90402@redhat.com> <1201794239.3135.0.camel@geeko> <47A1FC0A.90509@redhat.com> <1201801110.3258.0.camel@geeko> <47A21793.1070505@redhat.com> <1201805466.3994.6.camel@geeko> <47A2292A.106@redhat.com> Message-ID: <1201813025.2169.0.camel@geeko> Dnia 31-01-2008, czw o godzinie 15:01 -0500, Christopher Aillon pisze: > On 01/31/2008 01:51 PM, Jakub 'Livio' Rusinek wrote: > > Dnia 31-01-2008, czw o godzinie 13:46 -0500, Christopher Aillon pisze: > >> On 01/31/2008 12:38 PM, Jakub 'Livio' Rusinek wrote: > >>> Until Firefox 3 is released I'm hunting on their bugs and filing them. > >>> When Firefox 3 is released, I'll be one of the first testers. > >> You're missing my point. I am shipping CVS code snapshots of Firefox 3. > >> You know, just like you are downloading from mozilla.org. But in RPM > >> format instead of a tarball. Specifically for Fedora. Not generic > >> builds that will work in every distro (provided that they have the > >> minimum requirements). So my builds will perform a bit better. > > > > I'm testing mostly how Firefox integrates with Linux and how much does > > it suck [kidding] :P . > > > > And it doesn't matter for me if I have RPM or tarball, because of what > > I'm testing. > > I've seen your bugs. It really doesn't matter. So why not use Fedora's > RPM builds? Because I need fresh vanilla sources. Even 28hrs matter here. -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? wiadomo?ci podpisana cyfrowo URL: From tmz at pobox.com Thu Jan 31 21:08:07 2008 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 31 Jan 2008 16:08:07 -0500 Subject: Koji tk/tcl dependancy problem In-Reply-To: <20080131140412.5a4a0c00@redhat.com> References: <200801291523.54126.silfreed@silfreed.net> <200801310924.50118.silfreed@silfreed.net> <47A1DC04.8060000@redhat.com> <20080131180012.GU3082@inocybe.teonanacatl.org> <20080131140412.5a4a0c00@redhat.com> Message-ID: <20080131210807.GX3082@inocybe.teonanacatl.org> Jesse Keating wrote: > On Thu, 31 Jan 2008 13:00:12 -0500 Todd Zullinger > wrote: > >> The update that would correct it is pending in bodhi though: >> >> https://admin.fedoraproject.org/updates/F8/pending/tcl-8.4.17-1.fc8 >> >> Any idea why tk and tcl weren't both pushed at the same time? > > The maintainer is trying to get tk build against the pending tcl, > and thus asked for tcl to be udpated in the buildroot, which I did. But for F8 updates-testing tk-8.4.17-2.fc8 is already built and pushed[1]. Since the tcl build is still pending, updating with -testing enabled is broken ATM. That's a different problem in rawhide that Doug was running into at the start of this thread. [1] https://admin.fedoraproject.org/updates/F8/FEDORA-2008-1122 -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Conscience is what hurts when everything else feels so good. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From sean.bruno at dsl-only.net Thu Jan 31 21:47:20 2008 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Thu, 31 Jan 2008 13:47:20 -0800 Subject: readline-devel version mismatch(F8 x86_64) Message-ID: <1201816040.3574.4.camel@home-desk> Looks like readline-devel needs a bump? [sean at home-desk firecontrol-0.2]$ sudo yum install readline-static Setting up Install Process Parsing package install arguments Resolving Dependencies --> Running transaction check ---> Package readline-static.x86_64 0:5.2-7.fc8 set to be updated --> Processing Dependency: readline-devel = 5.2-7.fc8 for package: readline-static --> Running transaction check ---> Package readline-devel.x86_64 0:5.2-7.fc8 set to be updated --> Processing Dependency: ncurses-devel for package: readline-devel --> Processing Dependency: readline = 5.2-7.fc8 for package: readline-devel --> Running transaction check ---> Package readline-devel.x86_64 0:5.2-7.fc8 set to be updated --> Processing Dependency: readline = 5.2-7.fc8 for package: readline-devel ---> Package ncurses-devel.x86_64 0:5.6-12.20070812.fc8 set to be updated --> Finished Dependency Resolution Error: Missing Dependency: readline = 5.2-7.fc8 is needed by package readline-devel [sean at home-desk firecontrol-0.2]$ rpm -q readline readline-5.2-9.fc8 readline-5.2-9.fc8 [sean at home-desk firecontrol-0.2]$ Sean From caillon at redhat.com Thu Jan 31 21:51:55 2008 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 31 Jan 2008 16:51:55 -0500 Subject: Firefox and Epiphany crash after today's updates In-Reply-To: <1201813025.2169.0.camel@geeko> References: <200801302227.m0UMQtvX022692@laptop13.inf.utfsm.cl> <47A1DB9C.90402@redhat.com> <1201794239.3135.0.camel@geeko> <47A1FC0A.90509@redhat.com> <1201801110.3258.0.camel@geeko> <47A21793.1070505@redhat.com> <1201805466.3994.6.camel@geeko> <47A2292A.106@redhat.com> <1201813025.2169.0.camel@geeko> Message-ID: <47A242FB.5020606@redhat.com> On 01/31/2008 03:57 PM, Jakub 'Livio' Rusinek wrote: > Because I need fresh vanilla sources. Even 28hrs matter here. My builds are fresh vanilla. But if you always want to have the tip, why aren't you pulling from CVS and compiling your own? Because the nightly builds at mozilla.org aren't always vanilla either, and are sometimes older than mine. From dmc.fedora at filteredperception.org Thu Jan 31 22:11:45 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Thu, 31 Jan 2008 16:11:45 -0600 Subject: Review? LiveUSB persistence Message-ID: <47A247A1.1040702@filteredperception.org> I keep hearing these crazy rumors that RedHat actually wants to subject actual users to my LiveUSB persistence feature next/this month. I for one think the feature is really cool, useful, and know of no showstopping or even known bugs. But I also would not subject actual users to it, without having had more people review it and sign off on it. Anyway, to absolve myself of any responsibility, I once again request code review and feedback- The current code is easily reviewed here- http://filteredperception.org/smiley/projects/viros/viros-0.5/traits/ZyX.overlay.f8/ A tutorial for how to actually use my tools to add the feature to a livecd-creator created iso image is here (#1 and #8) (you'll have time to order a pizza and see a movie during the process) http://filteredperception.org/smiley/projects/viros/docs/tutorial/ And for how to actually use it, I don't have a good webpage up, but just see past posts to this list with persistence in the title (or even persistance). Likewise in those past posts are alternate incarnations which were in the form of a patch to livecd-tools, but those patches are most certainly out of date by now. And I do happen to be aware that my scripts are so unpolished, that if I see no comments and feedback, it is NOT because the code is flawless :) https://www.redhat.com/archives/fedora-livecd-list/2008-January/msg00037.html https://www.redhat.com/archives/fedora-livecd-list/2007-December/msg00061.html -dmc From jakub.rusinek at gmail.com Thu Jan 31 22:10:09 2008 From: jakub.rusinek at gmail.com (Jakub 'Livio' Rusinek) Date: Thu, 31 Jan 2008 23:10:09 +0100 Subject: Firefox and Epiphany crash after today's updates In-Reply-To: <47A242FB.5020606@redhat.com> References: <200801302227.m0UMQtvX022692@laptop13.inf.utfsm.cl> <47A1DB9C.90402@redhat.com> <1201794239.3135.0.camel@geeko> <47A1FC0A.90509@redhat.com> <1201801110.3258.0.camel@geeko> <47A21793.1070505@redhat.com> <1201805466.3994.6.camel@geeko> <47A2292A.106@redhat.com> <1201813025.2169.0.camel@geeko> <47A242FB.5020606@redhat.com> Message-ID: <1201817409.4027.2.camel@geeko> Dnia 31-01-2008, czw o godzinie 16:51 -0500, Christopher Aillon pisze: > On 01/31/2008 03:57 PM, Jakub 'Livio' Rusinek wrote: > > Because I need fresh vanilla sources. Even 28hrs matter here. > > My builds are fresh vanilla. But if you always want to have the tip, > why aren't you pulling from CVS and compiling your own? Because the > nightly builds at mozilla.org aren't always vanilla either, and are > sometimes older than mine. I don't care if they're older than yours. I'll use their builds and you'll not gonna stop me from doing this. I'm not a fresh vanilla fanatic, but I just want to test super-hyper fresh FUNCTIONALITY and... ARTWORK ;D . Bugs I'm filing are not so important, so it doesn't matter if I you your or their builds. But its better if I use their builds, becase then its easier to find what changes current build has. What's the difference (all the commits can be listed, because build are signed with a number). -- Jakub 'Livio' Rusinek http://liviopl.jogger.pl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? wiadomo?ci podpisana cyfrowo URL: From tcallawa at redhat.com Thu Jan 31 22:33:42 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 31 Jan 2008 17:33:42 -0500 Subject: some package splits In-Reply-To: References: <1201615452.2793.6.camel@localhost.localdomain> <1201616415.2362.19.camel@gibraltar.str.redhat.com> <1201780495.31329.3.camel@gibraltar.str.redhat.com> <20080131170830.GB14673@nostromo.devel.redhat.com> Message-ID: <1201818822.5724.37.camel@dhcp83-155.boston.redhat.com> On Thu, 2008-01-31 at 14:05 -0500, Michel Salim wrote: > Seems like we want a field like "Suggests:". That would accomodate > Jef's idea of offering users to install missing packages (in this > case, the set of suggested packages - installed packages) easily. Suggests doesn't really solve this problem for the general user case. It might make it easier for the "lazy power user" case, but the power user can do this with --nodeps and --force and get the same end result. ~spot From dmc.fedora at filteredperception.org Thu Jan 31 22:47:35 2008 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Thu, 31 Jan 2008 16:47:35 -0600 Subject: Review? LiveUSB persistence In-Reply-To: <47A247A1.1040702@filteredperception.org> References: <47A247A1.1040702@filteredperception.org> Message-ID: <47A25007.9040601@filteredperception.org> Douglas McClendon wrote: > I keep hearing these crazy rumors that RedHat actually wants to subject > actual users to my LiveUSB persistence feature next/this month. Oops, thunderbird tab completion combined with laziness got this addressed here instead of fedora-livecd-list. Though honestly it may technically fall outside the scope of fedora* anyway. But... I'll just leave the question here, as part of the reason I asked it was that I hadn't gotten any recent feedback on the issue on fedora-livecd-list. -dmc From vonbrand at inf.utfsm.cl Thu Jan 31 23:22:20 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Thu, 31 Jan 2008 20:22:20 -0300 Subject: Firefox and Epiphany crash after today's updates In-Reply-To: <47A224DB.2050308@redhat.com> References: <200801302227.m0UMQtvX022692@laptop13.inf.utfsm.cl> <47A1DB9C.90402@redhat.com> <1201794239.3135.0.camel@geeko> <47A1FC0A.90509@redhat.com> <1201801110.3258.0.camel@geeko> <47A21793.1070505@redhat.com> <200801311854.m0VIsZ3U011327@laptop13.inf.utfsm.cl> <47A224DB.2050308@redhat.com> Message-ID: <200801312322.m0VNMKuS023309@laptop13.inf.utfsm.cl> Christopher Aillon wrote: > On 01/31/2008 01:54 PM, Horst H. von Brand wrote: > > How are we supposed to report bugs then? [...] > Bottmon line: if anyone complains about you filing a bug on Fedora > builds, let me know. Because they shouldn't. It's no different from > any of the major contributors of FF doing self builds of Firefox > themselves and reporting bugs. OK, reported as , and also noted in the RH BZ. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From buildsys at redhat.com Thu Jan 31 23:54:42 2008 From: buildsys at redhat.com (Build System) Date: Thu, 31 Jan 2008 18:54:42 -0500 Subject: rawhide report: 20080131 changes Message-ID: <200801312354.m0VNsggx016548@porkchop.devel.redhat.com> New package compat-libgfortran-41 Compatibility Fortran 95 runtime library version 4.1.2 New package cronie Cron daemon for executing programs at set times New package dekorator KDE window decoration engine New package emesene Instant messaging client for Windows Live Messenger (tm) network New package igraph Library for creating and manipulating graphs New package ipa The Identity, Policy and Audit system New package kgtk Allows Gtk and Qt applications to use KDE's file dialogs New package libspectre A library for rendering PostScript(TM) documents New package nogravity Space shooter in 3D New package nogravity-data Data files for No Gravity Removed package vixie-cron Updated Packages: GtkAda-2.10.0-4.fc9 ------------------- * Wed Jan 30 2008 Michel Salim - 2.10.0-4 - Add missing BRs on gtk2-devel and pkgconfig alex4-1.0-5.fc9 --------------- * Wed Jan 30 2008 Hans de Goede 1.0-5 - Several patches from Debian (Thanks Peter De Wachter) - endian clean dot-files code - fsf address corrected - no longer use deprecated allegro functions anaconda-11.4.0.30-1 -------------------- * Wed Jan 30 2008 David Cantrell - 11.4.0.30-1 - Initialize int in doConfigNetDevice() to fix compiler warnings. (dcantrell) * Wed Jan 30 2008 David Cantrell - 11.4.0.29-1 - Handle putting updates ahead of anaconda in the updates= case too. (clumens) - Make sure the device name starts with /dev (#430811). (clumens) - Revert "Initial support for network --bootproto=ask (#401531)." (clumens) - (#186439) handle lv names with "-" when doing kickstart. (jgranado) - Remove the last references to makeDevInode (#430784). (clumens) - Don't traceback trying to raise an exception when making users (#430772). (clumens) apcupsd-3.14.3-2.fc9 -------------------- * Wed Jan 30 2008 Tomas Smetana - 3.14.3-2 - fix #348701 - apcupsd control script does not invoke shutdown properly bluez-libs-3.24-1.fc9 --------------------- * Thu Jan 31 2008 - Bastien Nocera - 3.24-1 - Update to 3.24 bluez-utils-3.24-1.fc9 ---------------------- * Thu Jan 31 2008 - Bastien Nocera - 3.24-1 - Update to 3.24 - Fix dund and pand starting before hcid (#429489) cairo-1.5.8-2.fc9 ----------------- * Wed Jan 30 2008 Behdad Esfahbod 1.5.8-2 - Remove TODO and ROADMAP as they were removed from tarball upstream. * Wed Jan 30 2008 Behdad Esfahbod 1.5.8-1 - Update to 1.5.8 * Thu Jan 17 2008 Behdad Esfahbod 1.5.6-1 - Update to 1.5.6 createrepo-0.9.4-2.fc9 ---------------------- * Wed Jan 30 2008 Seth Vidal - 0.9.4-1 - 0.9.4 dnsmasq-2.41-0.6.rc1.fc9 ------------------------ * Wed Jan 30 2008 Patrick "Jima" Laughton 2.41-0.6.rc1 - Release candidate - Happy Birthday Isaac! evince-2.21.90-4.fc9 -------------------- * Wed Jan 30 2008 Matthias Clasen - 2.21.90-4 - Use libspectre * Wed Jan 30 2008 Matthias Clasen - 2.21.90-3 - Don't link the thumbnailer against djvu evolution-webcal-2.12.0-2.fc9 ----------------------------- * Wed Jan 30 2008 Adam Tkac 2.12.0-2 - rebuild against new libsoup (libsoup2.4 patch is from trunk) file-4.23-2.fc9 --------------- * Thu Jan 31 2008 Tomas Smetana - 4.23-2 - fix #430952 - wrong handling of ELF binaries * Tue Jan 29 2008 Tomas Smetana - 4.23-1 - new upstream version; update patches; drop unused patches * Thu Jan 24 2008 Tomas Smetana - 4.21-5 - build a separate python-magic package; thanks to Terje Rosten firefox-3.0-0.beta2.15.nightly20080130.fc9 ------------------------------------------ * Wed Jan 30 2008 Martin Stransky 3.0-0.beta2.15 - Update to latest trunk (2008-01-30) - Backported an old laucher * Mon Jan 28 2008 Martin Stransky 3.0-0.beta2.13 - cleared starting scripts, removed useless parts flac-1.2.1-2.fc9 ---------------- * Tue Jan 29 2008 Miroslav Lichvar 1.2.1-2 - fix building with gcc-4.3 - reenable some assembly optimizations - hide private libFLAC symbols (#285961) - update license tag - add %check - remove -maltivec from CFLAGS * Mon Sep 17 2007 - Bastien Nocera - 1.2.1-1 - Update to 1.2.1 * Wed Sep 12 2007 - Bastien Nocera - 1.2.0-3 - Make a few functions hidden, to try and avoid textrels - Disable optimisations on x86 for the same reason (#285961) gcc-4.3.0-0.7 ------------- * Wed Jan 30 2008 Jakub Jelinek 4.3.0-0.7 - update from trunk - fix ISO C99 6.7.4p3 diagnostics (#427634, PR c/35017) * Fri Jan 25 2008 Jakub Jelinek 4.3.0-0.6 - update from the trunk * Thu Jan 10 2008 Jakub Jelinek 4.3.0-0.5 - update from the trunk - don't require on ppc/ppc64 libmudflap in gcc subpackage gcin-1.3.9-1.fc9 ---------------- * Wed Jan 30 2008 Chung-Yen Chang - 1.3.9-1 - update to 1.3.9 gdm-1:2.21.6-1.fc9 ------------------ * Wed Jan 30 2008 Jon McCann - 1:2.21.6-1 - Update to 2.21.6 * Thu Jan 24 2008 Ray Strode - 1:2.21.5-2 - add BuildRequires for iso-codes-devel gimp-2:2.4.4-1.fc9 ------------------ * Wed Jan 30 2008 Nils Philippsen - 2:2.4.4-1 - version 2.4.4 Changes in GIMP 2.4.4 ===================== - fixed typo in stock icon name - fixed handling of PSD files with empty layer names (bug #504149) - merged TinyScheme bug-fixes - removed duplicate entry from Tango palette - corrected parameter range in Chip Away script (bug #506110) - reduced redraw priority and speed of the marching ants (bug #479875) - fixed out-of-bounds array access in Convolution Matrix plug-in - reduced rounding errors in Convolution Matrix plug-in (bug #508114) - fixed potential crash on missing CMYK color profile - fixed crash in Bumpmap plug-in when called from some scripts (bug #509608) - Equalize should not equalise the alpha channel (bug #510210) - increased the number of points the ImageMap plug-in can handle (bug #511072) - adjusted the priority of the projection renderer (bug #511214) - smooth the brush mask to get a simpler cursor boundary (bug #304798) - show the selection even if the image window is invisible (bug #505758) - allow to commit a pending rectangular selection using Enter (bug #511599) - fixed bug in image dirty state logic (bug #509822) - improved GIMPressionist preformance and reduced startup time (bug #512126) - fixed a crash in the Convert to Color Profile plug-in (bug #512529) - merged some other minor fixes from trunk - translation updates (de, it, lt, ru, sv, uk) * Mon Jan 28 2008 Nils Philippsen - 2:2.4.3-2 - don't package static libraries (#430330) - use %bcond_... macros for package options * Mon Dec 17 2007 Nils Philippsen - 2:2.4.3-1 - version 2.4.3 Changes in GIMP 2.4.3 ===================== - avoid filename encoding problems in the WMF import plug-in (bug #499329) - fixed horizontal flipping of linked layers (bug #499161) - fixed a missing update in the Lighting plug-in UI (bug #500317) - fixed a potential crash in the projection code (bug #500178) - fixed a minor Makefile issue (bug #500826) - removed some pointless warnings from the JPEG and TIFF load plug-ins - fixed size calculation for the image size warning dialog (bug #329468) - fixed loading of tool options for the rectangle tools (bug #498948) - push/pop a context in the Fog filter - fixed potential crashes in the Python binding - corrected grid drawing with non-integer spacing (bug #502374) - fixed grid snapping for coordinates less than the grid offset - made the healing brush work properly when dragged (bug #492575) - update tool state when a device change happens (bug #493176) - improved validation of strings sent over the wire (bug #498207) - fixed integer check in Script-Fu (bug #498207) - fixed potential out-of-memory problem in Script-Fu - translation updates (ca, cs, de, gl, it, ko, lt, sv, uk) gnome-schedule-2.0.0-1.fc9 -------------------------- * Thu Jan 31 2008 Frank Arnold 2.0.0-1 - Update to 2.0.0 gnome-screensaver-2.21.6-1.fc9 ------------------------------ * Wed Jan 30 2008 Matthias Clasen - 2.21.6-1 - Update to 2.21.6 gnome-settings-daemon-2.21.90.1-2.fc9 ------------------------------------- * Thu Jan 31 2008 - Bastien Nocera - 2.21.90.1-2 - Fix the path for g-s-d, from upstream patch gnome-terminal-2.21.90-1.fc9 ---------------------------- * Wed Jan 30 2008 Matthias Clasen - 2.21.90-1 - Update to 2.21.90 * Tue Jan 15 2008 Matthias Clasen - 2.21.5-1 - Update to 2.21.5 * Fri Dec 21 2007 Matthias Clasen - 2.21.4-1 - Update to 2.21.4 gnome-vfs2-2.21.90-1.fc9 ------------------------ * Wed Jan 30 2008 Matthias Clasen - 2.21.90-1 - Update to 2.21.90 gstreamer-0.10.17-1.fc9 ----------------------- * Wed Jan 30 2008 - Bastien Nocera - 0.10.17-1 - Update to 0.10.17 * Tue Jan 29 2008 - Bastien Nocera - 0.10.16-1 - Update to 0.10.16 * Fri Nov 16 2007 - Bastien Nocera - 0.10.15-1 - Update to 0.10.15 gstreamer-plugins-base-0.10.17-1.fc9 ------------------------------------ * Wed Jan 30 2008 - Bastien Nocera - 0.10.17-1 - Update to 0.10.17 gucharmap-2.21.90-1.fc9 ----------------------- * Wed Jan 30 2008 Matthias Clasen - 2.21.90-1 - Update to 2.21.90 htdig-3:3.2.0b6-15.fc9 ---------------------- * Wed Jan 30 2008 Adam Tkac 3:3.2.0b6-15 - fixed htstat sigsegv when number of words is zero icu-3.8.1-4.fc9 --------------- * Thu Jan 31 2008 Caolan McNamara - 3.8.1-4 - Resolves: rhbz#431029, rhbz#424661 Remove workaround for 0D31 characters * Fri Jan 25 2008 Caolan McNamara - 3.8.1-3 - CVE-2007-4770 CVE-2007-4771 add icu.regexp.patch - Resolves: rhbz#423211 fix malalayam stuff in light of syllable changes * Fri Jan 11 2008 Caolan McNamara - 3.8.1-2 - remove icu.icu5365.dependantvowels.patch and cleanup icu.icu5506.multiplevowels.patch as they patch and unpatch eachother (thanks George Rhoten for pointing out that madness) kdebase-6:4.0.0-3.fc9 --------------------- * Wed Jan 30 2008 Rex Dieter 4.0.0-3 - resurrect -libs (f9+) - improve %description * Sat Jan 19 2008 Kevin Kofler 4.0.0-2.1 - Obsoletes: dolphin, d3lphin, Provides: dolphin everywhere * Tue Jan 08 2008 Rex Dieter 4.0.0-2 - respun tarball kdebase-workspace-4.0.0-8.fc9 ----------------------------- * Wed Jan 30 2008 Rex Dieter 4.0.0-8 - respin (qt4) kdelibs-6:4.0.1-1.fc9 --------------------- * Wed Jan 30 2008 Rex Dieter 4.0.1-1 - 4.0.1 * Wed Jan 30 2008 Rex Dieter 4.0.0-4 - omit openssl patch (f9+ #429846) - respin (qt4) * Wed Jan 23 2008 Rex Dieter 4.0.0-3 - openssl patch kdepimlibs-4.0.1-1.fc9 ---------------------- * Wed Jan 30 2008 Rex Dieter 4.0.1-1 - 4.0.1 ksh-20071105-3.fc9 ------------------ * Wed Jan 30 2008 Tomas Smetana 20071105-3 - fix #430602 - ksh segfaults after unsetting OPTIND * Mon Jan 07 2008 Tomas Smetana 20071105-2 - fix #405381 - ksh will not handle $(xxx) when typeset -r IFS - fix #386501 - bad group in spec file * Wed Nov 07 2007 Tomas Smetana 20071105-1 - new upstream version libart_lgpl-2.3.20-1.fc9 ------------------------ * Wed Jan 30 2008 Matthias Clasen - 2.3.20-1 - Update to 2.3.20 - Drop upstreamed patch - Correct license field libgnomekbd-2.21.4.1-2.fc9 -------------------------- * Thu Jan 31 2008 Matthias Clasen - 2.21.4.1-2 - Rebuild against new libxklavier libopenraw-0.0.4-2.fc9 ---------------------- * Wed Jan 30 2008 Trond Danielsen - 0.0.4-2 - Added missing dependency on libxml * Wed Jan 30 2008 Trond Danielsen - 0.0.4-1 - New upstream version. libraw1394-1.3.0-4.fc9 ---------------------- * Wed Jan 30 2008 Jarod Wilson - 1.3.0-4 - Use firewire-cdev.h provided by kernel-headers * Wed Oct 24 2007 Jarod Wilson - 1.3.0-3 - Update firewire-cdev.h to match kernel and eliminate bitfield usage, fixes capture on big-endian systems (#345221) libtool-1.5.24-6.fc9 -------------------- * Wed Jan 30 2008 Bill Nottingham 1.5.24-6 - rebuild for new gcc libtranslate-0.99-13.fc9 ------------------------ * Tue Jan 29 2008 Dmitry Butskoy - 0.99-13 - Add support for libsoup > 2.2 (Patch from Dan Winship ) - Change upstreamed patches to the correspond upstream ones. libxklavier-3.4-1.fc9 --------------------- * Wed Jan 30 2008 Matthias Clasen - 3.4-1 - Update to 3.4 logjam-1:4.5.3-11.fc9 --------------------- * Wed Jan 30 2008 Tom "spot" Callaway 1:4.5.3-11 - apply patch for new libsoup from bz 430966 loudmouth-1.3.3-2.fc9 --------------------- * Wed Jan 30 2008 Owen Taylor - 1.3.3-2 - Add back stream-error patch, it wasn't fixed in the 1.3 branch lvm2-2.02.33-9.fc9 ------------------ * Thu Jan 31 2008 Alasdair Kergon > - 2.02.33-9 - Improve internal label caching performance while locks are held. - Fix mirror log name construction during lvconvert. lynx-2.8.6-12.fc9 ----------------- * Wed Jan 30 2008 Jiri Moskovcak - 2.8.6-12 - added telnet, rsh, zip and unzip to BuildRequires - Resolves: #430508 nautilus-cd-burner-2.21.6-1.fc9 ------------------------------- * Wed Jan 30 2008 Matthias Clasen - 2.21.6-1 - Update to 2.21.6 passivetex-1.25-7.fc9 --------------------- * Thu Jan 31 2008 Jeremy Katz - 1.25-7 - Ensure xmltex is installed first to avoid infinite loop during installation perl-HTML-Mason-1:1.39-1.fc9 ---------------------------- * Wed Jan 30 2008 Steven Pritchard 1:1.39-1 - Update to 1.39. pkgconfig-1:0.23-2.fc9 ---------------------- * Wed Jan 30 2008 Matthias Clasen - 1:0.23-2 - Readd the requires.private fix that was dropped prematurely * Wed Jan 30 2008 Matthias Clasen - 1:0.23-1 - Update to 0.23 pykickstart-1.29-1.fc9 ---------------------- * Wed Jan 30 2008 Chris Lumens - 1.29-1 - Renamed bootproto=ask to bootproto=query, add to RHEL5 as well. (clumens) qt4-4.3.3-6.fc9 --------------- * Wed Jan 30 2008 Rex Dieter 4.3.3-6 - qt-copy 20080130 patch set (helps address previous 0180-window-role BIC) - Trolltech.conf: (default) fontsize=10 - License: GPLv2 with exceptions or QPL sane-backends-1.0.18-21.fc9 --------------------------- * Wed Jan 30 2008 Nils Philippsen - 1.0.18-21 - don't require libsane-hpaio (#430834) - use %bcond_without/with macros scim-anthy-1.2.4-4.fc9 ---------------------- * Thu Jan 31 2008 Akira TAGOH - 1.2.4-4 - scim-anthy-1.2.4-gcc43.patch: Fix a build fail with gcc-4.3. * Wed Oct 31 2007 Akira TAGOH - Update the source url. selinux-policy-3.2.5-22.fc9 --------------------------- * Wed Jan 30 2008 Dan Walsh 3.2.5-22 - Add audisp policy and prelude * Mon Jan 28 2008 Dan Walsh 3.2.5-21 - Allow all user roles to executae samba net command slrn-0.9.8.1pl1-7.20070716cvs.fc9 --------------------------------- * Wed Jan 30 2008 Miroslav Lichvar 0.9.8.1pl1-7.20070716cvs - convert changes.txt to utf8, rename logrotate file, remove setgid from slrnpull, fix source URL (#226422) subversion-1.4.6-2 ------------------ * Fri Dec 21 2007 Joe Orton 1.4.6-2 - update to 1.4.6 syslog-ng-2.0.8-1.fc9 --------------------- * Thu Jan 31 2008 Douglas E. Warner 2.0.8-1 - updated to 2.0.8 - removed logrotate patch system-config-firewall-1.2.1-1.fc9 ---------------------------------- * Thu Jan 31 2008 Thomas Woerner 1.2.1-1 - fixed traceback for clean selinux configuration (rhbz#430963) - fixed icmp handling for ip6tables - updated translations: as, de, it, ja, pl, pt_BR, zh_CN system-config-services-0.9.20-1.fc9 ----------------------------------- * Wed Jan 30 2008 Nils Philippsen - 0.9.20-1 - migrate online help to yelp/Docbook XML system-config-users-1.2.76-1.fc9 -------------------------------- * Thu Jan 31 2008 Nils Philippsen - 1.2.76-1 - migrate online help to yelp/Docbook XML telepathy-salut-0.2.2-1.fc9 --------------------------- * Wed Jan 30 2008 Brian Pepple - 0.2.2-1 - Update to 0.2.2. tellico-1.3-2.fc9 ----------------- * Wed Jan 30 2008 Alex Lancaster - 1.3-2 - Enable webcam support. - Install missing MIME file. * Wed Jan 30 2008 Jos?? Matos - 1.3-1 - New release. textflow-0.2.2-3.fc9 -------------------- transmission-1.03-1.fc9 ----------------------- * Thu Jan 31 2008 Denis Leroy - 1.03-1 - Update to upstream 1.03 uim-1.4.1-11.fc9 ---------------- * Thu Jan 31 2008 Akira TAGOH - 1.4.1-11 - Use full path to bring up XIM server. - uim-1.4.1-gcc43.patch: Fix a build fail with gcc-4.3. * Wed Oct 31 2007 Akira TAGOH - Update the upstream URL. * Fri Sep 28 2007 Akira TAGOH - 1.4.1-9 - Add Requires: uim-gtk2 in uim-gnome. xchat-gnome-0.18-8.fc9 ---------------------- * Wed Jan 30 2008 Brian Pepple - 0.18-8 - Rebuild. xguest-1.0.6-3.fc9 ------------------ * Thu Jan 31 2008 Dan Walsh - 1.0.6-3 - Add support for exclusive login for xguest xinetd-2:2.3.14-18.fc9 ---------------------- * Thu Jan 31 2008 Jan Safranek - 2:2.3.14-18 - fixed LABEL flag (#430929) * Wed Jan 30 2008 Jan Safranek - 2:2.3.14-17 - fixing init scripts (#430816) xterm-232-1.fc9 --------------- * Thu Jan 31 2008 Miroslav Lichvar 232-1 - update to 232 xulrunner-1.9-0.beta2.15.nightly20080130.fc9 -------------------------------------------- * Tue Jan 29 2008 Christopher Aillon 1.9-0.beta2.15 - Update to latest trunk (2008-01-30) zsh-4.3.4-7.fc9 --------------- * Thu Jan 31 2008 James Antill - 4.3.4-7 - Tweak /etc/zshrc to source /etc/profile.d/*.sh in ksh compat. mode - Tweak /etc/zprofile to source /etc/profile in ksh compat. mode - Resolves: rhbz#430665 Broken deps for i386 ---------------------------------------------------------- bmpx-0.40.13-7.fc9.i386 requires libsoup-2.2.so.8 buoh-0.8.2-2.fc7.i386 requires libsoup-2.2.so.8 cairo-java-1.0.5-8.fc8.i386 requires libgcj.so.8rh compat-gcc-34-c++-3.4.6-8.i386 requires libstdc++ < 0:4.2.0 compiz-kde-0.6.2-6.fc9.i386 requires libkdecorations.so.1 1:control-center-2.21.90-2.fc9.i386 requires libxklavier.so.11 dekorator-0.3-3.fc7.i386 requires libkdecorations.so.1 drivel-2.1.1-0.3.20071130svn.fc9.i386 requires libsoup-2.2.so.8 epiphany-extensions-2.20.1-3.fc9.i386 requires libgtkembedmoz.so epiphany-extensions-2.20.1-3.fc9.i386 requires gecko-libs = 0:1.8.1.10 evolution-brutus-1.1.28.7-2.fc8.i386 requires libcamel-1.2.so.10 fmt-ptrn-java-1.3.13-1.fc9.i386 requires libgcj.so.8rh frysk-0.0.1.2008.01.18.rh1-1.fc9.i386 requires libgcj.so.8rh frysk-devel-0.0.1.2008.01.18.rh1-1.fc9.i386 requires libgcj.so.8rh frysk-gnome-0.0.1.2008.01.18.rh1-1.fc9.i386 requires libgcj.so.8rh 1:gdm-2.21.6-1.fc9.i386 requires ConsoleKit >= 0:0.2.7 ghdl-0.25-0.89svn.6.fc8.i386 requires libgnat-4.1.so glib-java-0.2.6-11.fc9.i386 requires libgcj.so.8rh 1:gnome-applets-2.21.4-4.fc9.i386 requires libxklavier.so.11 gnome-web-photo-0.3-8.fc9.i386 requires libgkgfx.so gnome-web-photo-0.3-8.fc9.i386 requires libxpcom_core.so gnome-web-photo-0.3-8.fc9.i386 requires libgtkembedmoz.so gnome-web-photo-0.3-8.fc9.i386 requires gecko-libs = 0:1.8.1.10 kazehakase-0.5.0-1.fc9.2.i386 requires gecko-libs = 0:1.8.1.10 kdebase-workspace-4.0.0-8.fc9.i386 requires libxklavier.so.11 kicker-compiz-3.5.4-4.fc8.i386 requires libkickermain.so.1 kicker-compiz-3.5.4-4.fc8.i386 requires libtaskmanager.so.1 libFoundation-1.1.3-10.fc6.i386 requires libobjc.so.1 libgconf-java-2.12.4-9.fc8.i386 requires libgcj.so.8rh libglade-java-2.12.5-7.fc8.i386 requires libgcj.so.8rh libgnome-java-2.12.4-7.fc8.i386 requires libgcj.so.8rh libgtk-java-2.8.7-5.fc8.i386 requires libgcj.so.8rh libsyncml-0.4.5-1.fc9.i386 requires libsoup-2.2.so.8 libvte-java-0.12.1-10.fc9.i386 requires libgcj.so.8rh mail-notification-evolution-plugin-5.0-0.2.rc1.fc9.i386 requires libcamel-provider-1.2.so.10 mail-notification-evolution-plugin-5.0-0.2.rc1.fc9.i386 requires libcamel-1.2.so.10 muine-0.8.8-6.fc9.i386 requires mono(muine-plugin) = 0:1.0.0.0 raidem-0.3.1-7.fc8.i386 requires libobjc.so.1 seahorse-2.21.4-3.fc9.i386 requires libsoup-2.2.so.8 totem-publish-2.21.90-2.fc9.i386 requires libsoup-2.2.so.8 twitux-0.60-2.fc9.i386 requires libsoup-2.2.so.8 wfut-1.1.0-4.fc8.i386 requires libgcj.so.8rh Broken deps for x86_64 ---------------------------------------------------------- bmpx-0.40.13-7.fc9.x86_64 requires libsoup-2.2.so.8()(64bit) buoh-0.8.2-2.fc7.x86_64 requires libsoup-2.2.so.8()(64bit) cairo-java-1.0.5-8.fc8.i386 requires libgcj.so.8rh cairo-java-1.0.5-8.fc8.x86_64 requires libgcj.so.8rh()(64bit) compat-gcc-34-c++-3.4.6-8.x86_64 requires libstdc++ < 0:4.2.0 compiz-kde-0.6.2-6.fc9.x86_64 requires libkdecorations.so.1()(64bit) 1:control-center-2.21.90-2.fc9.i386 requires libxklavier.so.11 1:control-center-2.21.90-2.fc9.x86_64 requires libxklavier.so.11()(64bit) dekorator-0.3-3.fc7.x86_64 requires libkdecorations.so.1()(64bit) drivel-2.1.1-0.3.20071130svn.fc9.x86_64 requires libsoup-2.2.so.8()(64bit) epiphany-extensions-2.20.1-3.fc9.x86_64 requires libgtkembedmoz.so()(64bit) epiphany-extensions-2.20.1-3.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 evolution-brutus-1.1.28.7-2.fc8.i386 requires libcamel-1.2.so.10 evolution-brutus-1.1.28.7-2.fc8.x86_64 requires libcamel-1.2.so.10()(64bit) fmt-ptrn-java-1.3.13-1.fc9.i386 requires libgcj.so.8rh fmt-ptrn-java-1.3.13-1.fc9.x86_64 requires libgcj.so.8rh()(64bit) frysk-0.0.1.2008.01.18.rh1-1.fc9.x86_64 requires libgcj.so.8rh()(64bit) frysk-devel-0.0.1.2008.01.18.rh1-1.fc9.i386 requires libgcj.so.8rh frysk-devel-0.0.1.2008.01.18.rh1-1.fc9.x86_64 requires libgcj.so.8rh()(64bit) frysk-gnome-0.0.1.2008.01.18.rh1-1.fc9.x86_64 requires libgcj.so.8rh()(64bit) 1:gdm-2.21.6-1.fc9.x86_64 requires ConsoleKit >= 0:0.2.7 ghdl-0.25-0.89svn.6.fc8.x86_64 requires libgnat-4.1.so()(64bit) glib-java-0.2.6-11.fc9.i386 requires libgcj.so.8rh glib-java-0.2.6-11.fc9.x86_64 requires libgcj.so.8rh()(64bit) 1:gnome-applets-2.21.4-4.fc9.x86_64 requires libxklavier.so.11()(64bit) gnome-web-photo-0.3-8.fc9.x86_64 requires libgkgfx.so()(64bit) gnome-web-photo-0.3-8.fc9.x86_64 requires libgtkembedmoz.so()(64bit) gnome-web-photo-0.3-8.fc9.x86_64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo-0.3-8.fc9.x86_64 requires libxpcom_core.so()(64bit) kazehakase-0.5.0-1.fc9.2.x86_64 requires gecko-libs = 0:1.8.1.10 kdebase-workspace-4.0.0-8.fc9.x86_64 requires libxklavier.so.11()(64bit) kicker-compiz-3.5.4-4.fc8.x86_64 requires libkickermain.so.1()(64bit) kicker-compiz-3.5.4-4.fc8.x86_64 requires libtaskmanager.so.1()(64bit) libFoundation-1.1.3-10.fc6.i386 requires libobjc.so.1 libFoundation-1.1.3-10.fc6.x86_64 requires libobjc.so.1()(64bit) libgconf-java-2.12.4-9.fc8.i386 requires libgcj.so.8rh libgconf-java-2.12.4-9.fc8.x86_64 requires libgcj.so.8rh()(64bit) libglade-java-2.12.5-7.fc8.i386 requires libgcj.so.8rh libglade-java-2.12.5-7.fc8.x86_64 requires libgcj.so.8rh()(64bit) libgnome-java-2.12.4-7.fc8.i386 requires libgcj.so.8rh libgnome-java-2.12.4-7.fc8.x86_64 requires libgcj.so.8rh()(64bit) libgtk-java-2.8.7-5.fc8.i386 requires libgcj.so.8rh libgtk-java-2.8.7-5.fc8.x86_64 requires libgcj.so.8rh()(64bit) libsyncml-0.4.5-1.fc9.i386 requires libsoup-2.2.so.8 libsyncml-0.4.5-1.fc9.x86_64 requires libsoup-2.2.so.8()(64bit) libvte-java-0.12.1-10.fc9.i386 requires libgcj.so.8rh libvte-java-0.12.1-10.fc9.x86_64 requires libgcj.so.8rh()(64bit) mail-notification-evolution-plugin-5.0-0.2.rc1.fc9.x86_64 requires libcamel-1.2.so.10()(64bit) mail-notification-evolution-plugin-5.0-0.2.rc1.fc9.x86_64 requires libcamel-provider-1.2.so.10()(64bit) muine-0.8.8-6.fc9.x86_64 requires mono(muine-plugin) = 0:1.0.0.0 raidem-0.3.1-7.fc8.x86_64 requires libobjc.so.1()(64bit) seahorse-2.21.4-3.fc9.i386 requires libsoup-2.2.so.8 seahorse-2.21.4-3.fc9.x86_64 requires libsoup-2.2.so.8()(64bit) totem-publish-2.21.90-2.fc9.x86_64 requires libsoup-2.2.so.8()(64bit) twitux-0.60-2.fc9.x86_64 requires libsoup-2.2.so.8()(64bit) wfut-1.1.0-4.fc8.x86_64 requires libgcj.so.8rh()(64bit) Broken deps for ppc ---------------------------------------------------------- bmpx-0.40.13-7.fc9.ppc requires libsoup-2.2.so.8 buoh-0.8.2-2.fc7.ppc requires libsoup-2.2.so.8 cairo-java-1.0.5-8.fc8.ppc requires libgcj.so.8rh cairo-java-1.0.5-8.fc8.ppc64 requires libgcj.so.8rh()(64bit) compat-gcc-34-c++-3.4.6-8.ppc requires libstdc++ < 0:4.2.0 compiz-kde-0.6.2-6.fc9.ppc requires libkdecorations.so.1 1:control-center-2.21.90-2.fc9.ppc requires libxklavier.so.11 1:control-center-2.21.90-2.fc9.ppc64 requires libxklavier.so.11()(64bit) dekorator-0.3-3.fc7.ppc requires libkdecorations.so.1 drivel-2.1.1-0.3.20071130svn.fc9.ppc requires libsoup-2.2.so.8 epiphany-extensions-2.20.1-3.fc9.ppc requires libgtkembedmoz.so epiphany-extensions-2.20.1-3.fc9.ppc requires gecko-libs = 0:1.8.1.10 evolution-brutus-1.1.28.7-2.fc8.ppc requires libcamel-1.2.so.10 evolution-brutus-1.1.28.7-2.fc8.ppc64 requires libcamel-1.2.so.10()(64bit) fmt-ptrn-java-1.3.13-1.fc9.ppc requires libgcj.so.8rh fmt-ptrn-java-1.3.13-1.fc9.ppc64 requires libgcj.so.8rh()(64bit) frysk-0.0.1.2008.01.18.rh1-1.fc9.ppc64 requires libgcj.so.8rh()(64bit) frysk-devel-0.0.1.2008.01.18.rh1-1.fc9.ppc64 requires libgcj.so.8rh()(64bit) 1:gdm-2.21.6-1.fc9.ppc requires ConsoleKit >= 0:0.2.7 ghdl-0.25-0.89svn.6.fc8.ppc requires libgnat-4.1.so glib-java-0.2.6-11.fc9.ppc requires libgcj.so.8rh glib-java-0.2.6-11.fc9.ppc64 requires libgcj.so.8rh()(64bit) 1:gnome-applets-2.21.4-4.fc9.ppc requires libxklavier.so.11 gnome-web-photo-0.3-8.fc9.ppc requires libgkgfx.so gnome-web-photo-0.3-8.fc9.ppc requires libxpcom_core.so gnome-web-photo-0.3-8.fc9.ppc requires libgtkembedmoz.so gnome-web-photo-0.3-8.fc9.ppc requires gecko-libs = 0:1.8.1.10 kazehakase-0.5.0-1.fc9.2.ppc requires gecko-libs = 0:1.8.1.10 kdebase-workspace-4.0.0-8.fc9.ppc requires libxklavier.so.11 kicker-compiz-3.5.4-4.fc8.ppc requires libkickermain.so.1 kicker-compiz-3.5.4-4.fc8.ppc requires libtaskmanager.so.1 libFoundation-1.1.3-10.fc6.ppc requires libobjc.so.1 libFoundation-1.1.3-10.fc6.ppc64 requires libobjc.so.1()(64bit) libgconf-java-2.12.4-9.fc8.ppc requires libgcj.so.8rh libgconf-java-2.12.4-9.fc8.ppc64 requires libgcj.so.8rh()(64bit) libglade-java-2.12.5-7.fc8.ppc requires libgcj.so.8rh libglade-java-2.12.5-7.fc8.ppc64 requires libgcj.so.8rh()(64bit) libgnome-java-2.12.4-7.fc8.ppc requires libgcj.so.8rh libgnome-java-2.12.4-7.fc8.ppc64 requires libgcj.so.8rh()(64bit) libgtk-java-2.8.7-5.fc8.ppc requires libgcj.so.8rh libgtk-java-2.8.7-5.fc8.ppc64 requires libgcj.so.8rh()(64bit) libsyncml-0.4.5-1.fc9.ppc requires libsoup-2.2.so.8 libsyncml-0.4.5-1.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) libvte-java-0.12.1-10.fc9.ppc requires libgcj.so.8rh libvte-java-0.12.1-10.fc9.ppc64 requires libgcj.so.8rh()(64bit) mail-notification-evolution-plugin-5.0-0.2.rc1.fc9.ppc requires libcamel-provider-1.2.so.10 mail-notification-evolution-plugin-5.0-0.2.rc1.fc9.ppc requires libcamel-1.2.so.10 monodevelop-0.17-4.fc9.ppc requires boo muine-0.8.8-6.fc9.ppc requires mono(muine-plugin) = 0:1.0.0.0 raidem-0.3.1-7.fc8.ppc requires libobjc.so.1 seahorse-2.21.4-3.fc9.ppc requires libsoup-2.2.so.8 seahorse-2.21.4-3.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) totem-publish-2.21.90-2.fc9.ppc requires libsoup-2.2.so.8 twitux-0.60-2.fc9.ppc requires libsoup-2.2.so.8 wfut-1.1.0-4.fc8.ppc requires libgcj.so.8rh Broken deps for ppc64 ---------------------------------------------------------- bmpx-0.40.13-7.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) buoh-0.8.2-2.fc7.ppc64 requires libsoup-2.2.so.8()(64bit) cairo-java-1.0.5-8.fc8.ppc64 requires libgcj.so.8rh()(64bit) compat-gcc-34-c++-3.4.6-8.ppc64 requires libstdc++ < 0:4.2.0 1:control-center-2.21.90-2.fc9.ppc64 requires libxklavier.so.11()(64bit) dekorator-0.3-3.fc7.ppc64 requires libkdecorations.so.1()(64bit) drivel-2.1.1-0.3.20071130svn.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) epiphany-extensions-2.20.1-3.fc9.ppc64 requires libgtkembedmoz.so()(64bit) epiphany-extensions-2.20.1-3.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 evolution-brutus-1.1.28.7-2.fc8.ppc64 requires libcamel-1.2.so.10()(64bit) fmt-ptrn-java-1.3.13-1.fc9.ppc64 requires libgcj.so.8rh()(64bit) frysk-0.0.1.2008.01.18.rh1-1.fc9.ppc64 requires libgcj.so.8rh()(64bit) frysk-devel-0.0.1.2008.01.18.rh1-1.fc9.ppc64 requires libgcj.so.8rh()(64bit) frysk-gnome-0.0.1.2008.01.18.rh1-1.fc9.ppc64 requires libgcj.so.8rh()(64bit) 1:gdm-2.21.6-1.fc9.ppc64 requires ConsoleKit >= 0:0.2.7 glib-java-0.2.6-11.fc9.ppc64 requires libgcj.so.8rh()(64bit) 1:gnome-applets-2.21.4-4.fc9.ppc64 requires libxklavier.so.11()(64bit) gnome-web-photo-0.3-8.fc9.ppc64 requires libgkgfx.so()(64bit) gnome-web-photo-0.3-8.fc9.ppc64 requires libgtkembedmoz.so()(64bit) gnome-web-photo-0.3-8.fc9.ppc64 requires gecko-libs = 0:1.8.1.10 gnome-web-photo-0.3-8.fc9.ppc64 requires libxpcom_core.so()(64bit) kazehakase-0.5.0-1.fc9.2.ppc64 requires gecko-libs = 0:1.8.1.10 kdebase-workspace-4.0.0-8.fc9.ppc64 requires libxklavier.so.11()(64bit) kicker-compiz-3.5.4-4.fc8.ppc64 requires libkickermain.so.1()(64bit) kicker-compiz-3.5.4-4.fc8.ppc64 requires libtaskmanager.so.1()(64bit) libFoundation-1.1.3-10.fc6.ppc64 requires libobjc.so.1()(64bit) libgconf-java-2.12.4-9.fc8.ppc64 requires libgcj.so.8rh()(64bit) libglade-java-2.12.5-7.fc8.ppc64 requires libgcj.so.8rh()(64bit) libgnome-java-2.12.4-7.fc8.ppc64 requires libgcj.so.8rh()(64bit) libgtk-java-2.8.7-5.fc8.ppc64 requires libgcj.so.8rh()(64bit) libsyncml-0.4.5-1.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) libvte-java-0.12.1-10.fc9.ppc64 requires libgcj.so.8rh()(64bit) mail-notification-evolution-plugin-5.0-0.2.rc1.fc9.ppc64 requires libcamel-1.2.so.10()(64bit) mail-notification-evolution-plugin-5.0-0.2.rc1.fc9.ppc64 requires libcamel-provider-1.2.so.10()(64bit) perl-Test-AutoBuild-darcs-1.2.2-1.fc9.noarch requires darcs >= 0:1.0.0 raidem-0.3.1-7.fc8.ppc64 requires libobjc.so.1()(64bit) seahorse-2.21.4-3.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) totem-publish-2.21.90-2.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) twitux-0.60-2.fc9.ppc64 requires libsoup-2.2.so.8()(64bit) wfut-1.1.0-4.fc8.ppc64 requires libgcj.so.8rh()(64bit)