From yuan.bbbush at gmail.com Wed Jun 1 02:09:04 2005 From: yuan.bbbush at gmail.com (Yuan Yijun) Date: Wed, 1 Jun 2005 10:09:04 +0800 Subject: alsa-oss In-Reply-To: <1117559658.6931.3.camel@ignacio.ignacio.lan> References: <1117559658.6931.3.camel@ignacio.ignacio.lan> Message-ID: <9792751e05053119091dfe3683@mail.gmail.com> 2005/6/1, Ignacio Vazquez-Abrams : > > With the pcm.!dsp target alsa-oss is obsolete. > please explain more. There is no pcm.!dsp in default configuration, how to add it? //thx. -- bbbush ^_^ From ivazquez at ivazquez.net Wed Jun 1 02:44:38 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 31 May 2005 22:44:38 -0400 Subject: alsa-oss In-Reply-To: <9792751e05053119091dfe3683@mail.gmail.com> References: <1117559658.6931.3.camel@ignacio.ignacio.lan> <9792751e05053119091dfe3683@mail.gmail.com> Message-ID: <1117593878.6284.15.camel@ignacio.ignacio.lan> On Wed, 2005-06-01 at 10:09 +0800, Yuan Yijun wrote: > 2005/6/1, Ignacio Vazquez-Abrams : > > > > With the pcm.!dsp target alsa-oss is obsolete. > > > > please explain more. There is no pcm.!dsp in default configuration, > how to add it? In your asoundrc file add the following: pcm.!dsp { type plug slave.pcm } If for instance your dmix slave is pcm.dmixer then you would put "dmixer" where the angle brackets are: pcm.!dsp { type plug slave.pcm "dmixer" } This will allow apps that use the obsolescent OSS interface to use software mixing. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 warren at togami.com Wed Jun 1 03:55:08 2005 From: warren at togami.com (Warren Togami) Date: Tue, 31 May 2005 17:55:08 -1000 Subject: alsa-oss In-Reply-To: <1117593878.6284.15.camel@ignacio.ignacio.lan> References: <1117559658.6931.3.camel@ignacio.ignacio.lan> <9792751e05053119091dfe3683@mail.gmail.com> <1117593878.6284.15.camel@ignacio.ignacio.lan> Message-ID: <429D319C.1000005@togami.com> Ignacio Vazquez-Abrams wrote: > On Wed, 2005-06-01 at 10:09 +0800, Yuan Yijun wrote: > >>2005/6/1, Ignacio Vazquez-Abrams : >> >>>With the pcm.!dsp target alsa-oss is obsolete. >>> >> >>please explain more. There is no pcm.!dsp in default configuration, >>how to add it? > > > In your asoundrc file add the following: > > pcm.!dsp { > type plug > slave.pcm > } > > If for instance your dmix slave is pcm.dmixer then you would put > "dmixer" where the angle brackets are: > > pcm.!dsp { > type plug > slave.pcm "dmixer" > } > > This will allow apps that use the obsolescent OSS interface to use > software mixing. > > Is there any drawback to doing this by default? Warren Togami wtogami at redhat.com From yuan.bbbush at gmail.com Wed Jun 1 04:43:22 2005 From: yuan.bbbush at gmail.com (Yuan Yijun) Date: Wed, 1 Jun 2005 12:43:22 +0800 Subject: alsa-oss In-Reply-To: <1117593878.6284.15.camel@ignacio.ignacio.lan> References: <1117559658.6931.3.camel@ignacio.ignacio.lan> <9792751e05053119091dfe3683@mail.gmail.com> <1117593878.6284.15.camel@ignacio.ignacio.lan> Message-ID: <9792751e05053121431cf8c858@mail.gmail.com> 2005/6/1, Ignacio Vazquez-Abrams : > pcm.!dsp { > type plug > slave.pcm "dmixer" > } > > This will allow apps that use the obsolescent OSS interface to use > software mixing. > Does it mean that any access to /dev/dsp and /dev/dsp0 will be redirected to alsa dmixer? How would that happen if /dev/dsp is handled by kernel driver and dmixer is just a userland library? I'm sorry if I missed something :) -- bbbush ^_^ I don't care about realplay since I use mplayer and xine From ivazquez at ivazquez.net Wed Jun 1 05:09:16 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 01 Jun 2005 01:09:16 -0400 Subject: alsa-oss In-Reply-To: <9792751e05053121431cf8c858@mail.gmail.com> References: <1117559658.6931.3.camel@ignacio.ignacio.lan> <9792751e05053119091dfe3683@mail.gmail.com> <1117593878.6284.15.camel@ignacio.ignacio.lan> <9792751e05053121431cf8c858@mail.gmail.com> Message-ID: <1117602556.6284.29.camel@ignacio.ignacio.lan> On Wed, 2005-06-01 at 12:43 +0800, Yuan Yijun wrote: > 2005/6/1, Ignacio Vazquez-Abrams : > > pcm.!dsp { > > type plug > > slave.pcm "dmixer" > > } > > > > This will allow apps that use the obsolescent OSS interface to use > > software mixing. > > > > Does it mean that any access to /dev/dsp and /dev/dsp0 will be > redirected to alsa dmixer? How would that happen if /dev/dsp is > handled by kernel driver and dmixer is just a userland library? I'm > sorry if I missed something :) Um, the same way ALSA deals with /dev/snd/* being handled by kernel drivers? IOW, transparently. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 Wed Jun 1 11:03:56 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 1 Jun 2005 13:03:56 +0200 Subject: alsa-oss In-Reply-To: <429D319C.1000005@togami.com> References: <1117559658.6931.3.camel@ignacio.ignacio.lan> <9792751e05053119091dfe3683@mail.gmail.com> <1117593878.6284.15.camel@ignacio.ignacio.lan> <429D319C.1000005@togami.com> Message-ID: <20050601130356.620a8c03@nausicaa.camperquake.de> Hi. Warren Togami wrote: > Is there any drawback to doing this by default? Well, I can't get it to work. I can still play sound using the oss interface, but only one stream at a time, no matter what I put in ~/.asoundrc. All other attempts fail with "resource busy" or a variant thereof. From mike at navi.cx Wed Jun 1 13:24:00 2005 From: mike at navi.cx (Mike Hearn) Date: Wed, 01 Jun 2005 14:24:00 +0100 Subject: alsa-oss References: <1117559658.6931.3.camel@ignacio.ignacio.lan> <9792751e05053119091dfe3683@mail.gmail.com> <1117593878.6284.15.camel@ignacio.ignacio.lan> <9792751e05053121431cf8c858@mail.gmail.com> <1117602556.6284.29.camel@ignacio.ignacio.lan> Message-ID: On Wed, 01 Jun 2005 01:09:16 -0400, Ignacio Vazquez-Abrams wrote: > Um, the same way ALSA deals with /dev/snd/* being handled by kernel > drivers? IOW, transparently. That's not a good enough explanation, sorry. The ALSA guys have spoken in the past about maybe having the OSS emulation redirect back up into userspace to be received by a special daemon that then sends the audio into dmix and then back into kernel space, so you have a kind of W shape, but I never heard of any implementation. And any such thing would be very slow, perhaps slower than alsa-oss. How *exactly* does this work, given that dmix mixes in userspace but the OSS emulation (unless you use alsa-oss) takes place in the kernel? thanks -mike From buildsys at redhat.com Wed Jun 1 15:04:21 2005 From: buildsys at redhat.com (Build System) Date: Wed, 1 Jun 2005 11:04:21 -0400 Subject: rawhide report: 20050601 changes Message-ID: <200506011504.j51F4Llh015039@porkchop.devel.redhat.com> Updated Packages: anaconda-10.2.1.4-2 ------------------- * Tue May 31 2005 Chris Lumens 10.2.1.4-2 - Bump release for FC4 build. * Tue May 31 2005 Chris Lumens 10.2.1.4-1 - Fix to not traceback on certain preexisting RAID setups (#159079, #159182). From sopwith at redhat.com Wed Jun 1 17:59:19 2005 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 1 Jun 2005 13:59:19 -0400 (EDT) Subject: What next? Message-ID: Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora Extras 5 - what major features are you willing to put effort into? Best, -- Elliot From mattdm at mattdm.org Wed Jun 1 19:16:11 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 1 Jun 2005 15:16:11 -0400 Subject: enhance security via private TMP/TMPDIR by default In-Reply-To: <1117224945.6021.5.camel@localhost.localdomain> References: <20050512155504.GA25624@jadzia.bu.edu> <1115913808.3424.5.camel@nexus.verbum.private> <87is1gjt7v.fsf@kosh.bigo.ensc.de> <1116455960.3552.42.camel@nexus.verbum.private> <20050518224834.GB25468@nostromo.devel.redhat.com> <1116462767.3483.19.camel@jellyfish.redfishdemo.com> <1116973123.7655.2.camel@localhost.localdomain> <20050524222445.GA23131@jadzia.bu.edu> <1117224945.6021.5.camel@localhost.localdomain> Message-ID: <20050601191611.GA18639@jadzia.bu.edu> On Fri, May 27, 2005 at 04:15:45PM -0400, Peter Jones wrote: > Yeah, that's better than just blindly using ~/tmp/. But why have the > extra complexity? Why not always do mktemp and the bind+namespace > magic? This does have some advantage -- all users' tmp dirs are created > the way the admin intended when he set the system up, and they're easy > to find if he needs to look for them, for whatever reason. Well, at this point, the bind+namespace magic is more complex. But it seems sufficiently promising that it's probably worth waiting until it's solid before implementing anything. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 78 degrees Fahrenheit. From jlayton at redhat.com Wed Jun 1 19:16:45 2005 From: jlayton at redhat.com (Jeffrey Layton) Date: Wed, 01 Jun 2005 15:16:45 -0400 Subject: [PATCH] mkinitrd rescue mode Message-ID: <1117653405.12259.51.camel@barsoom.rdu.redhat.com> I've opened a BZ ticket with a patch to add a rescue mode to the current devel version of mkinitrd, but wanted to post a message about it here since I know this is where most of the discussion occurs. The BZ ticket with the patch is here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159287 Essentially this patch adds some functionality to mkinitrd and nash. This adds some tools to the initrd images (busybox and fsck, in particular), and adds a function to nash to allow running a shell before the switchroot occurs. This gives you some ability to troubleshoot booting problems, and gives the ability to do some rescue-type work without having to boot to the CD. This is a big plus for people that run boxes remotely and don't have easy physical access to them. The patch needs a little work,but a backported version basically worked for me on RHEL4. I have not yet tested it on Fedora but it should basically work there. Essentially, I'm sending this to solicit some feedback on it. Anyone have comments or concerns with this idea? -- Jeffrey Layton From matthew at nocturnal.org Wed Jun 1 19:42:50 2005 From: matthew at nocturnal.org (Matthew Lenz) Date: Wed, 01 Jun 2005 14:42:50 -0500 Subject: What next? In-Reply-To: References: Message-ID: <1117654970.11154.36.camel@mlenzdesktop> Are people against attempting to move to some kind of enhanced init system that includes dependencies? Or is that already the plan? On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote: > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > Extras 5 - what major features are you willing to put effort into? > > Best, > -- Elliot > From arjanv at redhat.com Wed Jun 1 19:44:40 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 01 Jun 2005 21:44:40 +0200 Subject: What next? In-Reply-To: References: Message-ID: <1117655080.6271.52.camel@laptopd505.fenrus.org> On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote: > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > Extras 5 - what major features are you willing to put effort into? I'd like to see: * faster boot and shutdown * lower memory footprint * avoid redundant libaries in apps (for example most gnome apps right now have 2 XML libraries loaded and in use) * revamped installer/firstboot (reconsider what needs to go where, how Xen works eg allow to make a golden image you can clone but customize on bringing that up first time, hook it into yum to update the system during firstboot, work with extras nicer, optimize the speed, figure how to have system-config-packages merged in, do minimal install and let firstboot finish it etc etc) * next generation EXT3 features (delalloc, > 8Tb support, extends) * reduce PLTs in core libraries further. * library versioning in more core libraries and better symbol export control * FORTIFY_SOURCE in the kernel (patch available from me) * more security features a la ExecShield -------------- 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 ivazquez at ivazquez.net Wed Jun 1 19:45:12 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 01 Jun 2005 15:45:12 -0400 Subject: What next? In-Reply-To: References: Message-ID: <1117655112.6284.39.camel@ignacio.ignacio.lan> On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote: > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > Extras 5 - what major features are you willing to put effort into? I really really really want to see anaconda be able to use yum repos. I think it's "on the list", but I strongly feel that it's worth reiterating. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 notting at redhat.com Wed Jun 1 19:46:18 2005 From: notting at redhat.com (Bill Nottingham) Date: Wed, 1 Jun 2005 15:46:18 -0400 Subject: What next? In-Reply-To: <1117654970.11154.36.camel@mlenzdesktop> References: <1117654970.11154.36.camel@mlenzdesktop> Message-ID: <20050601194618.GA18280@nostromo.devel.redhat.com> Matthew Lenz (matthew at nocturnal.org) said: > Are people against attempting to move to some kind of enhanced init > system that includes dependencies? Or is that already the plan? It's vaguely the plan, yes. Bill From dhollis at davehollis.com Wed Jun 1 19:53:55 2005 From: dhollis at davehollis.com (David Hollis) Date: Wed, 01 Jun 2005 15:53:55 -0400 Subject: What next? In-Reply-To: References: Message-ID: <1117655635.6735.28.camel@dhollis-lnx.sunera.com> On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote: > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > Extras 5 - what major features are you willing to put effort into? > > Best, > -- Elliot > Now that the directory server is starting to trickle out, I'd love to see that incorporated with some form of administration tool. I've done a bunch of LDAP setups in recent months and can now finally manage it from command line/LDIFs but it really doesn't have to be that tough to get a simple directory setup. The great part about it is that once it's setup, it can do quite a bit and even act as an Active Directory domain controller which is really a beautiful thing. -- David Hollis -------------- 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 nmiell at comcast.net Wed Jun 1 20:07:59 2005 From: nmiell at comcast.net (Nicholas Miell) Date: Wed, 01 Jun 2005 13:07:59 -0700 Subject: What next? In-Reply-To: <1117655080.6271.52.camel@laptopd505.fenrus.org> References: <1117655080.6271.52.camel@laptopd505.fenrus.org> Message-ID: <1117656479.5013.7.camel@localhost.localdomain> On Wed, 2005-06-01 at 21:44 +0200, Arjan van de Ven wrote: > * avoid redundant libaries in apps > (for example most gnome apps right now have 2 XML libraries loaded and > in use) Lots of GNOME apps/libraries (and probably many other things as well) link to libraries that they don't actually use (try "ldd -r - u /usr/bin/*" some time). It'd be nice to get rid of those. Also, some libraries/apps don't actually link to libraries that they need and work purely by luck at the moment. i.e. appA requires libL. libL requires symbols from libM, but doesn't link to it. appA also requires libM, so libL happens to work. Even worse, occasionally appA doesn't actually require libM, but has to link to it anyway to make libL work. -- Nicholas Miell From arjanv at redhat.com Wed Jun 1 20:13:53 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 01 Jun 2005 22:13:53 +0200 Subject: What next? In-Reply-To: <1117656479.5013.7.camel@localhost.localdomain> References: <1117655080.6271.52.camel@laptopd505.fenrus.org> <1117656479.5013.7.camel@localhost.localdomain> Message-ID: <1117656834.6271.64.camel@laptopd505.fenrus.org> On Wed, 2005-06-01 at 13:07 -0700, Nicholas Miell wrote: > On Wed, 2005-06-01 at 21:44 +0200, Arjan van de Ven wrote: > > * avoid redundant libaries in apps > > (for example most gnome apps right now have 2 XML libraries loaded and > > in use) > > Lots of GNOME apps/libraries (and probably many other things as well) > link to libraries that they don't actually use (try "ldd -r - > u /usr/bin/*" some time). It'd be nice to get rid of those. > > Also, some libraries/apps don't actually link to libraries that they > need and work purely by luck at the moment. > > i.e. appA requires libL. libL requires symbols from libM, but doesn't > link to it. appA also requires libM, so libL happens to work. > > Even worse, occasionally appA doesn't actually require libM, but has to > link to it anyway to make libL work. yep this is exactly what I meant but explained far better ;) -------------- 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 jdesbonnet at gmail.com Wed Jun 1 20:14:06 2005 From: jdesbonnet at gmail.com (Joe Desbonnet) Date: Wed, 1 Jun 2005 21:14:06 +0100 Subject: What next? In-Reply-To: References: Message-ID: <1cef3e9505060113142ede12fc@mail.gmail.com> Bandwidth friendly yum using binary delta algs. On 6/1/05, Elliot Lee wrote: > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > Extras 5 - what major features are you willing to put effort into? > > Best, > -- Elliot > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From sopwith at redhat.com Wed Jun 1 20:15:36 2005 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 1 Jun 2005 16:15:36 -0400 (EDT) Subject: What next? In-Reply-To: <1117656479.5013.7.camel@localhost.localdomain> References: <1117655080.6271.52.camel@laptopd505.fenrus.org> <1117656479.5013.7.camel@localhost.localdomain> Message-ID: On Wed, 1 Jun 2005, Nicholas Miell wrote: > On Wed, 2005-06-01 at 21:44 +0200, Arjan van de Ven wrote: > > * avoid redundant libaries in apps > > (for example most gnome apps right now have 2 XML libraries loaded and > > in use) > > Lots of GNOME apps/libraries (and probably many other things as well) > link to libraries that they don't actually use (try "ldd -r - > u /usr/bin/*" some time). It'd be nice to get rid of those. Those links are there because libtool and pkg-config are stupid. libtool and pkg-config aren't going to stop being stupid anytime soon, so we live with the situation as-is :) -- Elliot From arjanv at redhat.com Wed Jun 1 20:18:43 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 01 Jun 2005 22:18:43 +0200 Subject: What next? In-Reply-To: <1117655080.6271.52.camel@laptopd505.fenrus.org> References: <1117655080.6271.52.camel@laptopd505.fenrus.org> Message-ID: <1117657124.6271.67.camel@laptopd505.fenrus.org> > * more security features a la ExecShield 5 things come to mind as more details * stackguard equivalent (patch posted for gcc inclusion already) * per user /tmp via namespace tricks * more selinux "execmem" * more selinux targeted protection * Better selinux/security GUI -------------- 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 dr at cluenet.de Wed Jun 1 20:20:18 2005 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 1 Jun 2005 22:20:18 +0200 Subject: What next? In-Reply-To: References: Message-ID: <20050601202018.GA21853@srv01.cluenet.de> On Wed, Jun 01, 2005 at 01:59:19PM -0400, Elliot Lee wrote: > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > Extras 5 - what major features are you willing to put effort into? - a window manager which isn't the functional equivalent of hello_world.c where I cannot even easily grab a window and just move it to another desktop without fiddling with the pager or some menus (all only allowing to drag the window to the same relative position on another desktop... I'd like to just grab the window, hit the desktop border and can drag along in the next adjacent desktop - as it is possible with about all other WMs. metacity is just inferior). Doesn't have to be Enlightenment, but please... :-) - a network server for Evolution (perhaps based on Directory Server?) so one can actually use Evolution for time and task management at home AND on the road (read: from different machines) without having to run full-fledged MS Exchange (sic!) or OpenDUNNOWHATITWAS (Exchange clone). - a window manager which isn't [...] - tool support to setup X 3D acceleration (OpenGL) stuff. I'm always having a HARD time getting 3D accel to work. - a window manager which isn't [...] Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From arjanv at redhat.com Wed Jun 1 20:21:09 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 1 Jun 2005 22:21:09 +0200 Subject: What next? In-Reply-To: References: <1117655080.6271.52.camel@laptopd505.fenrus.org> <1117656479.5013.7.camel@localhost.localdomain> Message-ID: <20050601202109.GA30198@devserv.devel.redhat.com> On Wed, Jun 01, 2005 at 04:15:36PM -0400, Elliot Lee wrote: > On Wed, 1 Jun 2005, Nicholas Miell wrote: > > > On Wed, 2005-06-01 at 21:44 +0200, Arjan van de Ven wrote: > > > * avoid redundant libaries in apps > > > (for example most gnome apps right now have 2 XML libraries loaded and > > > in use) > > > > Lots of GNOME apps/libraries (and probably many other things as well) > > link to libraries that they don't actually use (try "ldd -r - > > u /usr/bin/*" some time). It'd be nice to get rid of those. > > Those links are there because libtool and pkg-config are stupid. libtool > and pkg-config aren't going to stop being stupid anytime soon, so we live > with the situation as-is :) this is not correct. pkg-config is fixable! We need to teach it about -Wl,as-needed which causes the linker only to add a lib when the app directly uses it. libtool.. bigger question. But we can get pkg-config to do this right if we spend 2 days on it. From dr at cluenet.de Wed Jun 1 20:21:38 2005 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 1 Jun 2005 22:21:38 +0200 Subject: What next? In-Reply-To: <20050601202018.GA21853@srv01.cluenet.de> References: <20050601202018.GA21853@srv01.cluenet.de> Message-ID: <20050601202138.GB21853@srv01.cluenet.de> On Wed, Jun 01, 2005 at 10:20:18PM +0200, Daniel Roesen wrote: > On Wed, Jun 01, 2005 at 01:59:19PM -0400, Elliot Lee wrote: > > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > > Extras 5 - what major features are you willing to put effort into? Ah, and I forgot: - integration of some one-time password authentication scheme like S/Key or OPIE. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From nutello at sweetness.com Wed Jun 1 20:19:57 2005 From: nutello at sweetness.com (Rudi Chiarito) Date: Wed, 1 Jun 2005 22:19:57 +0200 Subject: What next? In-Reply-To: References: Message-ID: <20050601201957.GC22597@plain.rackshack.net> On Wed, Jun 01, 2005 at 01:59:19PM -0400, Elliot Lee wrote: > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > Extras 5 - what major features are you willing to put effort into? Improved Kerberos/Active Directory support? I asked last week about establishing a standard for keytabs. Noone replied. It would be nice to have a way for authconfig/anaconda to make a system join an AD realm. This is trickier than joining a realm managed by MIT Kerberos. The case where you have a domain administrator at the keyboard is more or less handled by Samba 3's "net ads join", but that's only one of the possible scenarios. I have been trying to tweak Samba to handle another scenario: a computer account has already been created in the directory and you have the account's password. Now you need to create the host principal (for ssh and the like to work), as well as additional principals for httpd and other services. For the time being I can see this done in post-install kickstart scriptlets, because it relies on Samba's net command. Hopefully with Samba4 things could be made easier to integrate. Authconfig would be involved in creating (if needed) the LDAP mappings necessary to convert the Services for Unix schema to the RFC2037 schema that nss_ldap uses: http://enterprise.linux.com/enterprise/04/12/09/2318244.shtml?tid=102&tid=101&tid=100 Something like that should remove yet another barrier to Linux adoption. -- Rudi From skvidal at phy.duke.edu Wed Jun 1 20:25:12 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 01 Jun 2005 16:25:12 -0400 Subject: What next? In-Reply-To: <20050601202018.GA21853@srv01.cluenet.de> References: <20050601202018.GA21853@srv01.cluenet.de> Message-ID: <1117657512.31018.30.camel@cutter> > - a window manager which isn't the functional equivalent of > hello_world.c where I cannot even easily grab a window and just > move it to another desktop without fiddling with the pager or some > menus (all only allowing to drag the window to the same relative > position on another desktop... I'd like to just grab the window, > hit the desktop border and can drag along in the next adjacent > desktop - as it is possible with about all other WMs. metacity is > just inferior). Doesn't have to be Enlightenment, but please... :-) yum install brightside provides all the things you listed above for metacity. -sv From lkml at mac.com Wed Jun 1 20:24:27 2005 From: lkml at mac.com (Felipe Alfaro Solana) Date: Wed, 1 Jun 2005 22:24:27 +0200 Subject: What next? In-Reply-To: References: Message-ID: <72F9029D-9B28-4244-AEE9-2385E273886F@mac.com> On 1 Jun 2005, at 19:59, Elliot Lee wrote: > Maybe it's time to start the brainstorming for Fedora Core 5 and > Fedora > Extras 5 - what major features are you willing to put effort into? Keep Stateless Linux development going on, for example? From nmiell at comcast.net Wed Jun 1 20:26:56 2005 From: nmiell at comcast.net (Nicholas Miell) Date: Wed, 01 Jun 2005 13:26:56 -0700 Subject: What next? In-Reply-To: <1117656834.6271.64.camel@laptopd505.fenrus.org> References: <1117655080.6271.52.camel@laptopd505.fenrus.org> <1117656479.5013.7.camel@localhost.localdomain> <1117656834.6271.64.camel@laptopd505.fenrus.org> Message-ID: <1117657616.5013.9.camel@localhost.localdomain> On Wed, 2005-06-01 at 22:13 +0200, Arjan van de Ven wrote: > On Wed, 2005-06-01 at 13:07 -0700, Nicholas Miell wrote: > > On Wed, 2005-06-01 at 21:44 +0200, Arjan van de Ven wrote: > > > * avoid redundant libaries in apps > > > (for example most gnome apps right now have 2 XML libraries loaded and > > > in use) > > > > Lots of GNOME apps/libraries (and probably many other things as well) > > link to libraries that they don't actually use (try "ldd -r - > > u /usr/bin/*" some time). It'd be nice to get rid of those. > > > > Also, some libraries/apps don't actually link to libraries that they > > need and work purely by luck at the moment. > > > > i.e. appA requires libL. libL requires symbols from libM, but doesn't > > link to it. appA also requires libM, so libL happens to work. > > > > Even worse, occasionally appA doesn't actually require libM, but has to > > link to it anyway to make libL work. > > yep this is exactly what I meant but explained far better ;) Ah. I thought you meant that things were using both libxml2 and SAX in different parts of the app, or something to that effect. -- Nicholas Miell From arjanv at redhat.com Wed Jun 1 20:30:05 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 1 Jun 2005 22:30:05 +0200 Subject: What next? In-Reply-To: <1117657616.5013.9.camel@localhost.localdomain> References: <1117655080.6271.52.camel@laptopd505.fenrus.org> <1117656479.5013.7.camel@localhost.localdomain> <1117656834.6271.64.camel@laptopd505.fenrus.org> <1117657616.5013.9.camel@localhost.localdomain> Message-ID: <20050601203005.GB30198@devserv.devel.redhat.com> On Wed, Jun 01, 2005 at 01:26:56PM -0700, Nicholas Miell wrote: > On Wed, 2005-06-01 at 22:13 +0200, Arjan van de Ven wrote: > > On Wed, 2005-06-01 at 13:07 -0700, Nicholas Miell wrote: > > > On Wed, 2005-06-01 at 21:44 +0200, Arjan van de Ven wrote: > > > > * avoid redundant libaries in apps > > > > (for example most gnome apps right now have 2 XML libraries loaded and > > > > in use) > > > > > > Lots of GNOME apps/libraries (and probably many other things as well) > > > link to libraries that they don't actually use (try "ldd -r - > > > u /usr/bin/*" some time). It'd be nice to get rid of those. > > > > > > Also, some libraries/apps don't actually link to libraries that they > > > need and work purely by luck at the moment. > > > > > > i.e. appA requires libL. libL requires symbols from libM, but doesn't > > > link to it. appA also requires libM, so libL happens to work. > > > > > > Even worse, occasionally appA doesn't actually require libM, but has to > > > link to it anyway to make libL work. > > > > yep this is exactly what I meant but explained far better ;) > > Ah. I thought you meant that things were using both libxml2 and SAX in > different parts of the app, or something to that effect. well both actually. From skvidal at phy.duke.edu Wed Jun 1 20:31:32 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 01 Jun 2005 16:31:32 -0400 Subject: What next? In-Reply-To: References: Message-ID: <1117657892.31018.33.camel@cutter> On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote: > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > Extras 5 - what major features are you willing to put effort into? > What about stretching out the dev cycle from 3months dev + 3 months of testing to something more like 6 months of dev + 3 months of testing. I'd be willing to work toward that feature. And if we want anaconda with yum repo support, and pup and new yum doodads, and the new buildsystem, etc, etc, etc, I think we need to start discussing stretching out the release cycle a bit to get the infrastructure bits done. -sv From skvidal at phy.duke.edu Wed Jun 1 20:31:46 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 01 Jun 2005 16:31:46 -0400 Subject: What next? In-Reply-To: <1cef3e9505060113142ede12fc@mail.gmail.com> References: <1cef3e9505060113142ede12fc@mail.gmail.com> Message-ID: <1117657906.31018.35.camel@cutter> On Wed, 2005-06-01 at 21:14 +0100, Joe Desbonnet wrote: > Bandwidth friendly yum using binary delta algs. > HAHAHAHAHAH no. :) -sv From mattdm at mattdm.org Wed Jun 1 20:32:44 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 1 Jun 2005 16:32:44 -0400 Subject: What next? In-Reply-To: <1117655112.6284.39.camel@ignacio.ignacio.lan> References: <1117655112.6284.39.camel@ignacio.ignacio.lan> Message-ID: <20050601203244.GA21761@jadzia.bu.edu> On Wed, Jun 01, 2005 at 03:45:12PM -0400, Ignacio Vazquez-Abrams wrote: > I really really really want to see anaconda be able to use yum repos. I > think it's "on the list", but I strongly feel that it's worth > reiterating. Yeah, this is the Killer Feature from my point of view, since it brings Extras into the mainstream. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 79 degrees Fahrenheit. From arjanv at redhat.com Wed Jun 1 20:35:41 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 01 Jun 2005 22:35:41 +0200 Subject: What next? In-Reply-To: <1117657892.31018.33.camel@cutter> References: <1117657892.31018.33.camel@cutter> Message-ID: <1117658141.6271.70.camel@laptopd505.fenrus.org> On Wed, 2005-06-01 at 16:31 -0400, seth vidal wrote: > On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote: > > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > > Extras 5 - what major features are you willing to put effort into? > > > > What about stretching out the dev cycle from 3months dev + 3 months of > testing to something more like 6 months of dev + 3 months of testing. agreed in part. Fedora is ready for a bigger cycle so that more fundamental things can get fixed. I don't like 6+3 per se, I'd like 3+3 +3, 3 devel, 3 devel+test and 3 test -------------- 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 mattdm at mattdm.org Wed Jun 1 20:35:51 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 1 Jun 2005 16:35:51 -0400 Subject: What next? In-Reply-To: <1117657892.31018.33.camel@cutter> References: <1117657892.31018.33.camel@cutter> Message-ID: <20050601203551.GB21761@jadzia.bu.edu> On Wed, Jun 01, 2005 at 04:31:32PM -0400, seth vidal wrote: > What about stretching out the dev cycle from 3months dev + 3 months of > testing to something more like 6 months of dev + 3 months of testing. > I'd be willing to work toward that feature. That would be awesome. And it'd take some of the pressure off of Fedora Legacy. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 79 degrees Fahrenheit. From dr at cluenet.de Wed Jun 1 20:36:55 2005 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 1 Jun 2005 22:36:55 +0200 Subject: What next? In-Reply-To: <1117657512.31018.30.camel@cutter> References: <20050601202018.GA21853@srv01.cluenet.de> <1117657512.31018.30.camel@cutter> Message-ID: <20050601203655.GA22148@srv01.cluenet.de> On Wed, Jun 01, 2005 at 04:25:12PM -0400, seth vidal wrote: > > - a window manager which isn't the functional equivalent of > > hello_world.c where I cannot even easily grab a window and just > > move it to another desktop without fiddling with the pager or some > > menus (all only allowing to drag the window to the same relative > > position on another desktop... I'd like to just grab the window, > > hit the desktop border and can drag along in the next adjacent > > desktop - as it is possible with about all other WMs. metacity is > > just inferior). Doesn't have to be Enlightenment, but please... :-) > > yum install brightside > > provides all the things you listed above for metacity. Thanks, that looks indeed like something that would cure the most pain for now. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From skvidal at phy.duke.edu Wed Jun 1 20:38:38 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 01 Jun 2005 16:38:38 -0400 Subject: What next? In-Reply-To: <20050601203655.GA22148@srv01.cluenet.de> References: <20050601202018.GA21853@srv01.cluenet.de> <1117657512.31018.30.camel@cutter> <20050601203655.GA22148@srv01.cluenet.de> Message-ID: <1117658318.31018.42.camel@cutter> On Wed, 2005-06-01 at 22:36 +0200, Daniel Roesen wrote: > On Wed, Jun 01, 2005 at 04:25:12PM -0400, seth vidal wrote: > > > - a window manager which isn't the functional equivalent of > > > hello_world.c where I cannot even easily grab a window and just > > > move it to another desktop without fiddling with the pager or some > > > menus (all only allowing to drag the window to the same relative > > > position on another desktop... I'd like to just grab the window, > > > hit the desktop border and can drag along in the next adjacent > > > desktop - as it is possible with about all other WMs. metacity is > > > just inferior). Doesn't have to be Enlightenment, but please... :-) > > > > yum install brightside > > > > provides all the things you listed above for metacity. > > Thanks, that looks indeed like something that would cure the most pain > for now. > see how useful fedora extras can be? :) -sv From jspaleta at gmail.com Wed Jun 1 20:41:57 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 1 Jun 2005 16:41:57 -0400 Subject: What next? In-Reply-To: References: Message-ID: <604aa79105060113412109c5fd@mail.gmail.com> On 6/1/05, Elliot Lee wrote: > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > Extras 5 - what major features are you willing to put effort into? I'd like to see a summary of known 'plans' from each of the designated subprojects listed on fedora's website. Random Feature requests are nice.... a more general understanding of where each subproject momentum is headed to provide scope for potential contributors would be nicer. Near-term plans, ie "crap I know, you know, that I know, that you know you are planning on implementing for fc5 as a lead core developer". that as well as speculative on the horizon items that aren't going to be completed in time for fc5 but could use some experimental love in the meantime. -jef"And i want that summary in a theora video diary format"spaleta From dr at cluenet.de Wed Jun 1 20:45:11 2005 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 1 Jun 2005 22:45:11 +0200 Subject: What next? In-Reply-To: <20050601203551.GB21761@jadzia.bu.edu> References: <1117657892.31018.33.camel@cutter> <20050601203551.GB21761@jadzia.bu.edu> Message-ID: <20050601204510.GB22148@srv01.cluenet.de> On Wed, Jun 01, 2005 at 04:35:51PM -0400, Matthew Miller wrote: > On Wed, Jun 01, 2005 at 04:31:32PM -0400, seth vidal wrote: > > What about stretching out the dev cycle from 3months dev + 3 months of > > testing to something more like 6 months of dev + 3 months of testing. > > I'd be willing to work toward that feature. > > That would be awesome. And it'd take some of the pressure off of Fedora > Legacy. Agreed. And users whould have _some_ more usable lifetime of their installs, which would make me happy. :-) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From notting at redhat.com Wed Jun 1 20:52:09 2005 From: notting at redhat.com (Bill Nottingham) Date: Wed, 1 Jun 2005 16:52:09 -0400 Subject: What next? In-Reply-To: <20050601202018.GA21853@srv01.cluenet.de> References: <20050601202018.GA21853@srv01.cluenet.de> Message-ID: <20050601205209.GA19109@nostromo.devel.redhat.com> Daniel Roesen (dr at cluenet.de) said: > - tool support to setup X 3D acceleration (OpenGL) stuff. I'm always > having a HARD time getting 3D accel to work. Not sure a tool is useful here. If it's not working, that 99% of the time means code is broken somewhere, not a config option missing. Bill From fitzsim at redhat.com Wed Jun 1 20:58:51 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Wed, 01 Jun 2005 16:58:51 -0400 Subject: What next? In-Reply-To: <20050601202018.GA21853@srv01.cluenet.de> References: <20050601202018.GA21853@srv01.cluenet.de> Message-ID: <1117659531.3357.12.camel@tortoise.toronto.redhat.com> On Wed, 2005-06-01 at 22:20 +0200, Daniel Roesen wrote: > On Wed, Jun 01, 2005 at 01:59:19PM -0400, Elliot Lee wrote: > > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > > Extras 5 - what major features are you willing to put effort into? > > - a window manager which isn't the functional equivalent of > hello_world.c where I cannot even easily grab a window and just > move it to another desktop without fiddling with the pager or some > menus (all only allowing to drag the window to the same relative > position on another desktop... I'd like to just grab the window, > hit the desktop border and can drag along in the next adjacent > desktop - as it is possible with about all other WMs. metacity is > just inferior). Doesn't have to be Enlightenment, but please... :-) You can do this in metacity: grab the window's title bar then hit the key combination you use to switch to the destination workspace. Tom From alan at redhat.com Wed Jun 1 20:59:32 2005 From: alan at redhat.com (Alan Cox) Date: Wed, 1 Jun 2005 16:59:32 -0400 Subject: What next? In-Reply-To: <20050601202018.GA21853@srv01.cluenet.de> References: <20050601202018.GA21853@srv01.cluenet.de> Message-ID: <20050601205932.GB22944@devserv.devel.redhat.com> On Wed, Jun 01, 2005 at 10:20:18PM +0200, Daniel Roesen wrote: > desktop - as it is possible with about all other WMs. metacity is > just inferior). Doesn't have to be Enlightenment, but please... :-) XFCE should be in extras. End of problem > - a window manager which isn't [...] See above > - tool support to setup X 3D acceleration (OpenGL) stuff. I'm always > having a HARD time getting 3D accel to work. This should work out of the box and thats what I'd like to see happen not more config tools - do you really need tools ? Alan -- "Microsoft Office, only used by dinosaurs" From dr at cluenet.de Wed Jun 1 21:05:19 2005 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 1 Jun 2005 23:05:19 +0200 Subject: What next? In-Reply-To: <20050601205932.GB22944@devserv.devel.redhat.com> References: <20050601202018.GA21853@srv01.cluenet.de> <20050601205932.GB22944@devserv.devel.redhat.com> Message-ID: <20050601210519.GA22440@srv01.cluenet.de> On Wed, Jun 01, 2005 at 04:59:32PM -0400, Alan Cox wrote: > On Wed, Jun 01, 2005 at 10:20:18PM +0200, Daniel Roesen wrote: > > desktop - as it is possible with about all other WMs. metacity is > > just inferior). Doesn't have to be Enlightenment, but please... :-) > > XFCE should be in extras. End of problem So when I install XFCE, do I get the exact same desktop just with some added functionality, or do I have to spend some hours of integration work so that things "work together" properly again? I tried to go down this road with Enlightenment after RH has thrown it out of the window and it was pain and I gave up finally. > > - tool support to setup X 3D acceleration (OpenGL) stuff. I'm always > > having a HARD time getting 3D accel to work. > > This should work out of the box and thats what I'd like to see happen not > more config tools - do you really need tools ? My wording wasn't good I guess. What I meant was that when the installer detects e.g. a Matrox card, it should (by default or optionally) just set up all the 3D accel stuff like agpgart and DRM module loading, X.org config like DRI and GLX etc. It should "just work". I've spend literally hours recently to get my G550 going with 3D accel and only succeeded half-way (X.org is now saying "rendering enabled" but glxinfo says "no rendering"). Had my G200 working fine (also after some hours of googling and mergin all the tips and hints together into a working setup). Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From alan at redhat.com Wed Jun 1 21:07:51 2005 From: alan at redhat.com (Alan Cox) Date: Wed, 1 Jun 2005 17:07:51 -0400 Subject: What next? In-Reply-To: <20050601210519.GA22440@srv01.cluenet.de> References: <20050601202018.GA21853@srv01.cluenet.de> <20050601205932.GB22944@devserv.devel.redhat.com> <20050601210519.GA22440@srv01.cluenet.de> Message-ID: <20050601210751.GB860@devserv.devel.redhat.com> On Wed, Jun 01, 2005 at 11:05:19PM +0200, Daniel Roesen wrote: > So when I install XFCE, do I get the exact same desktop just with some > added functionality, or do I have to spend some hours of integration > work so that things "work together" properly again? I tried to go > down this road with Enlightenment after RH has thrown it out of the > window and it was pain and I gave up finally. You get a lightweight desktop that honours gnome hints and will run with nautilus/gnome-panel if you want. It also starts up in about 2 seconds From green at redhat.com Wed Jun 1 21:09:06 2005 From: green at redhat.com (Anthony Green) Date: Wed, 01 Jun 2005 14:09:06 -0700 Subject: What next? In-Reply-To: References: Message-ID: <1117660147.9566.12.camel@localhost.localdomain> On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote: > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > Extras 5 - what major features are you willing to put effort into? We should ship a GCC 4.1 preview compiler so we can continue to demonstrate improvements on the java front. Most of the improvements of late imply ABI breakage because we're extending the library in incompatible ways. Restricting ourselves to non-ABI-breaking changes in GCC 4.0.x limits our ability to continue to demonstrate innovation. I also blogged about my personal ideas for java in FC5 recently, reproduced below..... Fedora Core 4 is getting close to ?done", and I think it?s safe to say that we hit the Free java trifecta in this release: OpenOffice.org 2, the Eclipse IDE, and Apache Tomcat. Congratulations to everybody who made this possible! But what next? FC5 is right around the corner? My personal wish list is as follows: gcjwebplugin, Azureus and RSSOwl. Michael Koch?s gcjwebplugin is important for obvious reasons. I?m less worried about the GUI work here than the security work. I?d rather see us ship a secure plugin that could only run a handful of applets than nothing at all. Let?s put security work ahead of AWT/Swing. Azureus is a wildly popular and innovative cross-platform and extensible bittorrent client. It seems to be a permanent fixture on the Most Active and Top Downloaded lists at sourceforge.net (#1 on both this week). There are lots of plugins for it, including some to let it act as a powerful podcasting client (which is where my interest lies). It uses SWT and almost runs out of the box on gcj today. I posted a screenshot of it stumbling along on gcj about 6 months ago. The current release fails to run for a number of reasons, including their use of com.sun.* classes for secure sockets. This is a common problem (witness OpenOffice.org) and Sven de Marothy has been maintaining a nice page to help educate people on writing portable code. We need to promote this better. Like Azureus, RSSOwl is an SWT based app that almost runs today. It?s a popular and well reviewed RSS feed reader. Sven de Marothy and Robin Green (no relation, btw) have both reported some success running on gcj. Azureus and RSSOwl are real success stories that complement the current Fedora Core/Extras offerings. My recent experience with the jogl and lwjgl communities tells me that project maintainers are willing to put work into getting their projects working with Free runtimes. We need to engage the Azureus and RSSOwl developer communities to see if they are willing to help make this all possible. I also wonder what the base compiler for FC5 will be. My guess at the FC and GCC schedules make me think that we could be using GCC 4.1, which would be nice. But 4.0.x is also possible. We should suss this out ASAP as it impacts how we go about getting these apps running. Well, this is all just my personal opinion - but I think it?s all possible. I hope I can convince everybody else! AG From skvidal at phy.duke.edu Wed Jun 1 21:11:39 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 01 Jun 2005 17:11:39 -0400 Subject: What next? In-Reply-To: References: Message-ID: <1117660299.31018.61.camel@cutter> On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote: > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > Extras 5 - what major features are you willing to put effort into? > I think continuing the migration of misc items to extras and making core truly core is good. I'd be willing to work toward: - extras organization into package groups or even sub-repos - stripping of core of any program that provides duplicate functionality to another program. - making the barrier to use of extras VERY low. -sv From skvidal at phy.duke.edu Wed Jun 1 21:11:52 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 01 Jun 2005 17:11:52 -0400 Subject: What next? In-Reply-To: <1117655112.6284.39.camel@ignacio.ignacio.lan> References: <1117655112.6284.39.camel@ignacio.ignacio.lan> Message-ID: <1117660312.31018.63.camel@cutter> On Wed, 2005-06-01 at 15:45 -0400, Ignacio Vazquez-Abrams wrote: > On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote: > > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > > Extras 5 - what major features are you willing to put effort into? > > I really really really want to see anaconda be able to use yum repos. I > think it's "on the list", but I strongly feel that it's worth > reiterating. > Hear Hear! -sv From jwboyer at jdub.homelinux.org Wed Jun 1 21:11:55 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 01 Jun 2005 16:11:55 -0500 Subject: What next? In-Reply-To: <1117660312.31018.63.camel@cutter> References: <1117655112.6284.39.camel@ignacio.ignacio.lan> <1117660312.31018.63.camel@cutter> Message-ID: <1117660315.3107.21.camel@yoda.jdub.homelinux.org> On Wed, 2005-06-01 at 17:11 -0400, seth vidal wrote: > On Wed, 2005-06-01 at 15:45 -0400, Ignacio Vazquez-Abrams wrote: > > On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote: > > > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > > > Extras 5 - what major features are you willing to put effort into? > > > > I really really really want to see anaconda be able to use yum repos. I > > think it's "on the list", but I strongly feel that it's worth > > reiterating. > > > > Hear Hear! Fourth'd! josh From notting at redhat.com Wed Jun 1 21:12:48 2005 From: notting at redhat.com (Bill Nottingham) Date: Wed, 1 Jun 2005 17:12:48 -0400 Subject: What next? In-Reply-To: <20050601210519.GA22440@srv01.cluenet.de> References: <20050601202018.GA21853@srv01.cluenet.de> <20050601205932.GB22944@devserv.devel.redhat.com> <20050601210519.GA22440@srv01.cluenet.de> Message-ID: <20050601211248.GA19281@nostromo.devel.redhat.com> Daniel Roesen (dr at cluenet.de) said: > > This should work out of the box and thats what I'd like to see happen not > > more config tools - do you really need tools ? > > My wording wasn't good I guess. What I meant was that when the installer > detects e.g. a Matrox card, it should (by default or optionally) just > set up all the 3D accel stuff like agpgart and DRM module loading, agpgart is not a module. DRM module loading is done by the X server. DRI and GLX are enabled by default, AFAIK. Bill From notting at redhat.com Wed Jun 1 21:15:00 2005 From: notting at redhat.com (Bill Nottingham) Date: Wed, 1 Jun 2005 17:15:00 -0400 Subject: What next? In-Reply-To: <1117660147.9566.12.camel@localhost.localdomain> References: <1117660147.9566.12.camel@localhost.localdomain> Message-ID: <20050601211500.GB19281@nostromo.devel.redhat.com> Anthony Green (green at redhat.com) said: > On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote: > > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > > Extras 5 - what major features are you willing to put effort into? > > We should ship a GCC 4.1 preview compiler so we can continue to > demonstrate improvements on the java front. What good is demonstrating improvement if we can't use it any apps because the ABI is moving too fast and it's not released yet? (I'm serious.) Bill From notting at redhat.com Wed Jun 1 21:15:29 2005 From: notting at redhat.com (Bill Nottingham) Date: Wed, 1 Jun 2005 17:15:29 -0400 Subject: What next? In-Reply-To: <1117660299.31018.61.camel@cutter> References: <1117660299.31018.61.camel@cutter> Message-ID: <20050601211529.GC19281@nostromo.devel.redhat.com> seth vidal (skvidal at phy.duke.edu) said: > I think continuing the migration of misc items to extras and making core > truly core is good. > > I'd be willing to work toward: > - extras organization into package groups or even sub-repos Including extending this to CD grouping? (I should write up the strawman proposal for this.) Bill From skvidal at phy.duke.edu Wed Jun 1 21:16:38 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 01 Jun 2005 17:16:38 -0400 Subject: What next? In-Reply-To: <1117658141.6271.70.camel@laptopd505.fenrus.org> References: <1117657892.31018.33.camel@cutter> <1117658141.6271.70.camel@laptopd505.fenrus.org> Message-ID: <1117660599.31018.67.camel@cutter> > > > > What about stretching out the dev cycle from 3months dev + 3 months of > > testing to something more like 6 months of dev + 3 months of testing. > > > agreed in part. Fedora is ready for a bigger cycle so that more > fundamental things can get fixed. I don't like 6+3 per se, I'd like 3+3 > +3, 3 devel, 3 devel+test and 3 test Sure - but in total a 9 month release cycle for this rev would take the strain off of some of us who aren't paid to do this all day. -sv From davej at redhat.com Wed Jun 1 21:18:16 2005 From: davej at redhat.com (Dave Jones) Date: Wed, 1 Jun 2005 17:18:16 -0400 Subject: What next? In-Reply-To: <20050601210519.GA22440@srv01.cluenet.de> References: <20050601202018.GA21853@srv01.cluenet.de> <20050601205932.GB22944@devserv.devel.redhat.com> <20050601210519.GA22440@srv01.cluenet.de> Message-ID: <20050601211815.GD3778@redhat.com> On Wed, Jun 01, 2005 at 11:05:19PM +0200, Daniel Roesen wrote: > My wording wasn't good I guess. What I meant was that when the installer > detects e.g. a Matrox card, it should (by default or optionally) just > set up all the 3D accel stuff like agpgart and DRM module loading, > X.org config like DRI and GLX etc. It should "just work". I've spend > literally hours recently to get my G550 going with 3D accel and only > succeeded half-way (X.org is now saying "rendering enabled" but glxinfo > says "no rendering"). Had my G200 working fine (also after some hours > of googling and mergin all the tips and hints together into a working > setup). Are you running the G550 in dual-head mode ? Xinerama usage disables direct rendering. There is a way around it using the mergedfb option aparently, but I've never tried it. Dave From skvidal at phy.duke.edu Wed Jun 1 21:20:15 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 01 Jun 2005 17:20:15 -0400 Subject: What next? In-Reply-To: <20050601211529.GC19281@nostromo.devel.redhat.com> References: <1117660299.31018.61.camel@cutter> <20050601211529.GC19281@nostromo.devel.redhat.com> Message-ID: <1117660815.31018.71.camel@cutter> On Wed, 2005-06-01 at 17:15 -0400, Bill Nottingham wrote: > seth vidal (skvidal at phy.duke.edu) said: > > I think continuing the migration of misc items to extras and making core > > truly core is good. > > > > I'd be willing to work toward: > > - extras organization into package groups or even sub-repos > > Including extending this to CD grouping? (I should write up > the strawman proposal for this.) Yah - I think it should. Although I tell you what I'd like - I think making it easy for users to make their own 'extras' cds that include the stuff they want + deps would make the most sense. you tell a program a list of packages you want and it compiles a list of that package + all its deps from extras and puts them in cd-sized subdirs. that would take some sorting work but it's not outside the realm of possibility. -sv From ed at eh3.com Wed Jun 1 21:24:33 2005 From: ed at eh3.com (Ed Hill) Date: Wed, 01 Jun 2005 17:24:33 -0400 Subject: What next? In-Reply-To: <20050601210519.GA22440@srv01.cluenet.de> References: <20050601202018.GA21853@srv01.cluenet.de> <20050601205932.GB22944@devserv.devel.redhat.com> <20050601210519.GA22440@srv01.cluenet.de> Message-ID: <1117661073.28429.281.camel@ernie> On Wed, 2005-06-01 at 23:05 +0200, Daniel Roesen wrote: > On Wed, Jun 01, 2005 at 04:59:32PM -0400, Alan Cox wrote: > > On Wed, Jun 01, 2005 at 10:20:18PM +0200, Daniel Roesen wrote: > > > desktop - as it is possible with about all other WMs. metacity is > > > just inferior). Doesn't have to be Enlightenment, but please... :-) > > > > XFCE should be in extras. End of problem Yes! I'm using XFCE from Extras on FC3 and am very happy with it. > So when I install XFCE, do I get the exact same desktop just with some > added functionality, or do I have to spend some hours of integration > work so that things "work together" properly again? I tried to go > down this road with Enlightenment after RH has thrown it out of the > window and it was pain and I gave up finally. Whatever customizations you've made for metacity will remain with metacity. However, its quite easy to configure XFCE to do almost everything you can do in metacity. And XFCE does a lot of stuff that you simply cannot do in metacity including, for instance, configurable window edge resistance, the ability to raise windows above the top of the screen, etc. Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From kyrre at solution-forge.net Wed Jun 1 21:38:41 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Wed, 01 Jun 2005 23:38:41 +0200 Subject: What next? In-Reply-To: <20050601203551.GB21761@jadzia.bu.edu> References: <1117657892.31018.33.camel@cutter> <20050601203551.GB21761@jadzia.bu.edu> Message-ID: <1117661921.5219.9.camel@localhost.localdomain> ons, 01.06.2005 kl. 22.35 skrev Matthew Miller: > On Wed, Jun 01, 2005 at 04:31:32PM -0400, seth vidal wrote: > > What about stretching out the dev cycle from 3months dev + 3 months of > > testing to something more like 6 months of dev + 3 months of testing. > > I'd be willing to work toward that feature. > > That would be awesome. And it'd take some of the pressure off of Fedora > Legacy. > Could fedora legacy use the same repourls as fedora core/extras? So that it would just continue to be "yum update"? Kyrre From kyrre at solution-forge.net Wed Jun 1 21:41:12 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Wed, 01 Jun 2005 23:41:12 +0200 Subject: What next? In-Reply-To: <20050601202018.GA21853@srv01.cluenet.de> References: <20050601202018.GA21853@srv01.cluenet.de> Message-ID: <1117662072.5219.12.camel@localhost.localdomain> *snip* > - a network server for Evolution (perhaps based on Directory Server?) > so one can actually use Evolution for time and task management at > home AND on the road (read: from different machines) without having > to run full-fledged MS Exchange (sic!) or OpenDUNNOWHATITWAS (Exchange > clone). *snip* Sounds like Hula to me - not that I've tried it myself Kyrre From kyrre at solution-forge.net Wed Jun 1 21:44:08 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Wed, 01 Jun 2005 23:44:08 +0200 Subject: What next? In-Reply-To: <1117660299.31018.61.camel@cutter> References: <1117660299.31018.61.camel@cutter> Message-ID: <1117662248.5219.15.camel@localhost.localdomain> ons, 01.06.2005 kl. 23.11 skrev seth vidal: > On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote: > > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > > Extras 5 - what major features are you willing to put effort into? > > > > I think continuing the migration of misc items to extras and making core > truly core is good. > > I'd be willing to work toward: > - extras organization into package groups or even sub-repos > - stripping of core of any program that provides duplicate > functionality to another program. > - making the barrier to use of extras VERY low. > > -sv > What about making it possible for non-text users to use yum? They shouldn't be kept out of such a great tool :) BTW., how does osx do installs (just bringing up the meta-file installer thingy again. Feel free not to answer)? From skvidal at phy.duke.edu Wed Jun 1 21:46:33 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 01 Jun 2005 17:46:33 -0400 Subject: What next? In-Reply-To: <1117662248.5219.15.camel@localhost.localdomain> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> Message-ID: <1117662394.31018.80.camel@cutter> > > > > What about making it possible for non-text users to use yum? They > shouldn't be kept out of such a great tool :) it's a work-in-progress. > BTW., how does osx do installs (just bringing up the meta-file installer > thingy again. Feel free not to answer)? their package system, umm, err, sucks. a lot. -sv From kyrre at solution-forge.net Wed Jun 1 21:48:05 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Wed, 01 Jun 2005 23:48:05 +0200 Subject: What next? In-Reply-To: <20050601194618.GA18280@nostromo.devel.redhat.com> References: <1117654970.11154.36.camel@mlenzdesktop> <20050601194618.GA18280@nostromo.devel.redhat.com> Message-ID: <1117662484.5219.17.camel@localhost.localdomain> ons, 01.06.2005 kl. 21.46 skrev Bill Nottingham: > Matthew Lenz (matthew at nocturnal.org) said: > > Are people against attempting to move to some kind of enhanced init > > system that includes dependencies? Or is that already the plan? > > It's vaguely the plan, yes. > > Bill *whistle* From mattdm at mattdm.org Wed Jun 1 21:49:34 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 1 Jun 2005 17:49:34 -0400 Subject: What next? In-Reply-To: <1117660299.31018.61.camel@cutter> References: <1117660299.31018.61.camel@cutter> Message-ID: <20050601214934.GA24588@jadzia.bu.edu> On Wed, Jun 01, 2005 at 05:11:39PM -0400, seth vidal wrote: > - extras organization into package groups or even sub-repos Maybe including changing all of the "Group:" tags to something more well-considered? (Like, just, "Core" and "Extras"; or, whatever the sub-repos end up being.) > - stripping of core of any program that provides duplicate > functionality to another program. With a very broad definition of "duplicate". > - making the barrier to use of extras VERY low. This should go *above* the previous one. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 79 degrees Fahrenheit. From mike at navi.cx Wed Jun 1 22:15:54 2005 From: mike at navi.cx (Mike Hearn) Date: Wed, 01 Jun 2005 23:15:54 +0100 Subject: What next? References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <1117662394.31018.80.camel@cutter> Message-ID: On Wed, 01 Jun 2005 17:46:33 -0400, seth vidal wrote: > > BTW., how does osx do installs (just bringing up the meta-file > > installer thingy again. Feel free not to answer)? > > their package system, umm, err, sucks. 99.9% of users seem to disagree with you, judging by how often "Linux should use appfolders like Macs do" is heard on various forums and mailing lists. MacOS X packaging works reliably for end users, 100% of the time, and from that perspective it doesn't matter how many features it has or doesn't have, it's better than yum/rpm/any Linux packaging system. I don't mean any offence to you by the way, yum is a nice piece of work and I'd agree that the way Apple did appfolders is pretty awful (launchservices? hello obscure bugs and security holes!) but we shouldn't use that poor implementation to ignore users experiences. thanks -mike From mike at navi.cx Wed Jun 1 22:21:49 2005 From: mike at navi.cx (Mike Hearn) Date: Wed, 01 Jun 2005 23:21:49 +0100 Subject: What next? References: <1117660147.9566.12.camel@localhost.localdomain> Message-ID: On Wed, 01 Jun 2005 14:09:06 -0700, Anthony Green wrote: > Most of the improvements of late imply ABI breakage because we're > extending the library in incompatible ways. Restricting ourselves to > non-ABI-breaking changes in GCC 4.0.x limits our ability to continue to > demonstrate innovation. Could you elaborate on that? In a private email exchange recently Tom Tromey suggested that the ABI was stable (or very nearly stable) in that apps compiled with GCJ 4.0 would run against a 4.1 system (but not vice-versa unfortunately). I'm afraid I'm also really convinced that breaking ABI constitutes innovation, or even is required for it ... it's a clone of Java so at most you would be adding new APIs which hopefully the ABI design allows for? I'm interested in this because I'm working with a guy who wishes to distribute GCJ compiled binaries across multiple Linux distributions. Obviously if you guys are chomping at the bit to break backwards compatibility as soon as possible, I'll have to tell him to give it up (or figure out some cunning hack where everything including libgcj is statically linked/private). thanks -mike From denis at poolshark.org Wed Jun 1 22:26:54 2005 From: denis at poolshark.org (Denis Leroy) Date: Wed, 01 Jun 2005 15:26:54 -0700 Subject: What next? In-Reply-To: References: Message-ID: <429E362E.9060701@poolshark.org> Elliot Lee wrote: >Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora >Extras 5 - what major features are you willing to put effort into? > > I'd like to see better laptop support, in particular some sort of Profile support as well as better wireless support. Currently to have my laptop work both at home and at work (in dual mode), i have to hack rc.sysinit horribly to extend the semantic of the 'netprofile=' kernel argument so that it also changes the Xorg.conf file, .gconf files, and so on.... Also, system-config-network is still an incredibly counter-intuitive and confusing tool. -denis From dr at cluenet.de Wed Jun 1 22:27:57 2005 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 2 Jun 2005 00:27:57 +0200 Subject: What next? In-Reply-To: <20050601211815.GD3778@redhat.com> References: <20050601202018.GA21853@srv01.cluenet.de> <20050601205932.GB22944@devserv.devel.redhat.com> <20050601210519.GA22440@srv01.cluenet.de> <20050601211815.GD3778@redhat.com> Message-ID: <20050601222757.GA23343@srv01.cluenet.de> On Wed, Jun 01, 2005 at 05:18:16PM -0400, Dave Jones wrote: > > My wording wasn't good I guess. What I meant was that when the installer > > detects e.g. a Matrox card, it should (by default or optionally) just > > set up all the 3D accel stuff like agpgart and DRM module loading, > > X.org config like DRI and GLX etc. It should "just work". I've spend > > literally hours recently to get my G550 going with 3D accel and only > > succeeded half-way (X.org is now saying "rendering enabled" but glxinfo > > says "no rendering"). Had my G200 working fine (also after some hours > > of googling and mergin all the tips and hints together into a working > > setup). > > Are you running the G550 in dual-head mode ? Nope, I know of this limitation. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From rodd at clarkson.id.au Wed Jun 1 22:30:24 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Thu, 02 Jun 2005 08:30:24 +1000 Subject: What next? In-Reply-To: <1117661921.5219.9.camel@localhost.localdomain> References: <1117657892.31018.33.camel@cutter> <20050601203551.GB21761@jadzia.bu.edu> <1117661921.5219.9.camel@localhost.localdomain> Message-ID: <1117665025.3094.1.camel@goose> On Wed, 2005-06-01 at 23:38 +0200, Kyrre Ness Sjobak wrote: > ons, 01.06.2005 kl. 22.35 skrev Matthew Miller: > > On Wed, Jun 01, 2005 at 04:31:32PM -0400, seth vidal wrote: > > > What about stretching out the dev cycle from 3months dev + 3 months of > > > testing to something more like 6 months of dev + 3 months of testing. > > > I'd be willing to work toward that feature. > > > > That would be awesome. And it'd take some of the pressure off of Fedora > > Legacy. > > > Could fedora legacy use the same repourls as fedora core/extras? So that > it would just continue to be "yum update"? I've often wondered why the final update for fedora (before cgoing legacy) doesn't include a switch to fedora legacy as part of it. R. -- "It's a fine line between denial and faith. It's much better on my side" From davej at redhat.com Wed Jun 1 22:31:21 2005 From: davej at redhat.com (Dave Jones) Date: Wed, 1 Jun 2005 18:31:21 -0400 Subject: What next? In-Reply-To: <429E362E.9060701@poolshark.org> References: <429E362E.9060701@poolshark.org> Message-ID: <20050601223121.GA5408@redhat.com> On Wed, Jun 01, 2005 at 03:26:54PM -0700, Denis Leroy wrote: > >Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > >Extras 5 - what major features are you willing to put effort into? > I'd like to see better laptop support, in particular some sort of > Profile support as well as better wireless support. Profiles: Isn't this the aim of sabayon (sp?) Better wireless support: The upstream drivers are slowly starting to converge to a point of sanity. Ie, a common ieee80211 core which drivers share, rather than implementing their own variants of in each driver with different userspace semantics. So FC5 will get better through this work, but it probably won't be 'perfect' for quite a while just due to the sheer volume of work needed to be done to fix up some of the mess in that part of the kernel. Dave From mike at navi.cx Wed Jun 1 22:27:54 2005 From: mike at navi.cx (Mike Hearn) Date: Wed, 01 Jun 2005 23:27:54 +0100 Subject: What next? References: <1117655080.6271.52.camel@laptopd505.fenrus.org> <1117656479.5013.7.camel@localhost.localdomain> <20050601202109.GA30198@devserv.devel.redhat.com> Message-ID: On Wed, 01 Jun 2005 22:21:09 +0200, Arjan van de Ven wrote: > pkg-config is fixable! > We need to teach it about -Wl,as-needed which causes the linker only to add > a lib when the app directly uses it. > > libtool.. bigger question. But we can get pkg-config to do this right if we > spend 2 days on it. This was already discussed on xdg-list and by James Henstridge. Pkg-config and libtool aren't broken, they do this for portability. The GNU linker doesn't need you to enumerate every library in the image but some (unbelievably) do. Pkg-config files can't contain --as-needed directly because it's not portable also. Maybe one way to do this would just be to make it the default for the compiler and start filing bugs upstream with the broken apps that don't actually have DT_NEEDED entries for all their dependencies. thanks -mike From dr at cluenet.de Wed Jun 1 22:35:27 2005 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 2 Jun 2005 00:35:27 +0200 Subject: What next? In-Reply-To: <20050601211248.GA19281@nostromo.devel.redhat.com> References: <20050601202018.GA21853@srv01.cluenet.de> <20050601205932.GB22944@devserv.devel.redhat.com> <20050601210519.GA22440@srv01.cluenet.de> <20050601211248.GA19281@nostromo.devel.redhat.com> Message-ID: <20050601223527.GB23343@srv01.cluenet.de> On Wed, Jun 01, 2005 at 05:12:48PM -0400, Bill Nottingham wrote: > Daniel Roesen (dr at cluenet.de) said: > > > This should work out of the box and thats what I'd like to see happen not > > > more config tools - do you really need tools ? > > > > My wording wasn't good I guess. What I meant was that when the installer > > detects e.g. a Matrox card, it should (by default or optionally) just > > set up all the 3D accel stuff like agpgart and DRM module loading, > > agpgart is not a module. $ /sbin/lsmod | fgrep agpgart agpgart 56740 3 > DRM module loading is done by the X server. > DRI and GLX are enabled by default, AFAIK. Uhm. I think I made a major mistake. I've not verified that the problems I described are still there in FC4T3 (or anything newer than FC1). My bad. Perhaps all this IS already a problem of the past... Please excuse the noise if all that is nowadays a non-issue, but in my FC1, no DRI stuff was set up at all. Well, as soon as FC4 is out, I'll upgrade (reinstall actually) my desktop and notebook systems to FC4 and see how things are, and will get back if that stuff is still an issue. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From mike at navi.cx Wed Jun 1 22:24:21 2005 From: mike at navi.cx (Mike Hearn) Date: Wed, 01 Jun 2005 23:24:21 +0100 Subject: What next? References: <1cef3e9505060113142ede12fc@mail.gmail.com> <1117657906.31018.35.camel@cutter> Message-ID: On Wed, 01 Jun 2005 16:31:46 -0400, seth vidal wrote: > > Bandwidth friendly yum using binary delta algs. > > > > HAHAHAHAHAH > no. :) Why not? SUSE do this, I think. thanks -mike From dr at cluenet.de Wed Jun 1 22:45:19 2005 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 2 Jun 2005 00:45:19 +0200 Subject: What next? In-Reply-To: <1117662072.5219.12.camel@localhost.localdomain> References: <20050601202018.GA21853@srv01.cluenet.de> <1117662072.5219.12.camel@localhost.localdomain> Message-ID: <20050601224519.GC23343@srv01.cluenet.de> On Wed, Jun 01, 2005 at 11:41:12PM +0200, Kyrre Ness Sjobak wrote: > *snip* > > - a network server for Evolution (perhaps based on Directory Server?) > > so one can actually use Evolution for time and task management at > > home AND on the road (read: from different machines) without having > > to run full-fledged MS Exchange (sic!) or OpenDUNNOWHATITWAS (Exchange > > clone). > *snip* > > Sounds like Hula to me - not that I've tried it myself When I looked for a solution a few weeks ago, I've spend some hours of googling and reading mailing list archives, and the only thing I've been able to come up with was a) use OpenGroupware! b) use Microsoft Exchange! c) oh yeah, I'd really like a lightweight server without all the bloat OpenGroupware needs to just store my stuff somewhere accessibly from remote locations The general consensus I found everywhere was "doesn't exist, or use the big ones". I didn't stumble over Hula at all... interesting. And Hula doesn't do contacts stuff. And that's besides calendar stuff what I'd need Evo most for - but it does other stuff I don't need, e.g. IMAP4 server and webmail etc. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From davej at redhat.com Wed Jun 1 22:48:33 2005 From: davej at redhat.com (Dave Jones) Date: Wed, 1 Jun 2005 18:48:33 -0400 Subject: What next? In-Reply-To: <20050601223527.GB23343@srv01.cluenet.de> References: <20050601202018.GA21853@srv01.cluenet.de> <20050601205932.GB22944@devserv.devel.redhat.com> <20050601210519.GA22440@srv01.cluenet.de> <20050601211248.GA19281@nostromo.devel.redhat.com> <20050601223527.GB23343@srv01.cluenet.de> Message-ID: <20050601224833.GB5408@redhat.com> On Thu, Jun 02, 2005 at 12:35:27AM +0200, Daniel Roesen wrote: > I think I made a major mistake. I've not verified that the problems > I described are still there in FC4T3 (or anything newer than FC1). > My bad. Perhaps all this IS already a problem of the past... > > Please excuse the noise if all that is nowadays a non-issue, but in my > FC1, no DRI stuff was set up at all. Things should be a *lot* better in this regard with current distros. Dave From dr at cluenet.de Wed Jun 1 22:53:30 2005 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 2 Jun 2005 00:53:30 +0200 Subject: What next? In-Reply-To: <20050601223121.GA5408@redhat.com> References: <429E362E.9060701@poolshark.org> <20050601223121.GA5408@redhat.com> Message-ID: <20050601225330.GD23343@srv01.cluenet.de> On Wed, Jun 01, 2005 at 06:31:21PM -0400, Dave Jones wrote: > On Wed, Jun 01, 2005 at 03:26:54PM -0700, Denis Leroy wrote: > > >Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > > >Extras 5 - what major features are you willing to put effort into? > > I'd like to see better laptop support, in particular some sort of > > Profile support as well as better wireless support. > > Profiles: Isn't this the aim of sabayon (sp?) > Better wireless support: The upstream drivers are slowly starting > to converge to a point of sanity. Ie, a common ieee80211 core > which drivers share, rather than implementing their own variants > of in each driver with different userspace semantics. So FC5 will > get better through this work, but it probably won't be 'perfect' > for quite a while just due to the sheer volume of work needed > to be done to fix up some of the mess in that part of the kernel. BTW, on a related matter I had trouble getting my laptop's prism54 card working when trying FC4T3 on it. As usual, I had to install, then throw the binary firmware into /lib/firmware and then I _would_ have expected the card to "just work" on insertion. But it didn't. I had to play around to get it recognized at all. First, the system just ignored the card on insert for whatever reason. Can someone tell me how this is _supposed_ to work? Having to install the binary myself is bad enough (yes, I know the politics around this so I won't start a debate over that *g*), but I'd expect it to work then... am I asking too much? Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From mike at navi.cx Wed Jun 1 22:48:30 2005 From: mike at navi.cx (Mike Hearn) Date: Wed, 01 Jun 2005 23:48:30 +0100 Subject: What next? References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> Message-ID: On Wed, 01 Jun 2005 23:44:08 +0200, Kyrre Ness Sjobak wrote: > BTW., how does osx do installs (just bringing up the meta-file installer > thingy again. Feel free not to answer)? http://arstechnica.com/reviews/apps/delicious-library.ars/2 http://developer.apple.com/documentation/Porting/Conceptual/PortingUnix/compiling/chapter_4_section_8.html That shows you pretty much how it works. In short: - Packages are contained entirely within a relocatable directory, which has a magic marker so the finder treats it as a file - Packages have no dependencies outside the operating system. They can embed libraries within themselves easily. - Package installation is a matter of clicking a URL to a "DMG" file which is a self mounting disk image, and dragging the appfolder inside to the /Applications directory. - There is no auto update system. Apple also provide a traditional Installer service, which some things use. - Nearly every app is packaged in this way. Mac users never have to compile from source or wait while an app [update] is packaged. Look at the screenshots in the Ars Technica article to get a feel for it. Most users consider it easier than what Linux has, in my experience (judging by how often I'm asked for it!) thanks -mike From cmadams at hiwaay.net Wed Jun 1 22:58:23 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 1 Jun 2005 17:58:23 -0500 Subject: What next? In-Reply-To: <1117657892.31018.33.camel@cutter> References: <1117657892.31018.33.camel@cutter> Message-ID: <20050601225823.GA772000@hiwaay.net> Once upon a time, seth vidal said: > What about stretching out the dev cycle from 3months dev + 3 months of > testing to something more like 6 months of dev + 3 months of testing. How about deciding what the major goals of the next release should be (within reason of course), estimating about how long it should take to meet those goals, and then add in whatever else seems reasonable in the given time frame? Fedora Core is not a marketing driven project like the commercial distros; releases need not be done on a fixed schedule. Instead, they should be made when there is something worth making a major release and based on technology goals. > And if we want anaconda with yum repo support, and pup and new yum > doodads, and the new buildsystem, etc, etc, etc, I think we need to > start discussing stretching out the release cycle a bit to get the > infrastructure bits done. That would be a big plus; before diving in to the next release, get the infrastructure done. I think anaconda with repo support should be a requirement for Extras to be considered "tier 1", but Extras also needs to be able to operate smoothly (mostly) automatically so you have more time to work on yum and such. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From mbneto at gmail.com Wed Jun 1 23:06:22 2005 From: mbneto at gmail.com (mbneto) Date: Wed, 1 Jun 2005 19:06:22 -0400 Subject: What next? In-Reply-To: References: Message-ID: <5cf776b805060116063efe0650@mail.gmail.com> I'd like to see the minimum required size for a 'firewall-only' setup drop. Something like conectiva's minimum install which takes less than 70Mb. - mb On 6/1/05, Elliot Lee wrote: > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > Extras 5 - what major features are you willing to put effort into? > > Best, > -- Elliot > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From dr at cluenet.de Wed Jun 1 23:07:54 2005 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 2 Jun 2005 01:07:54 +0200 Subject: What next? In-Reply-To: <20050601225823.GA772000@hiwaay.net> References: <1117657892.31018.33.camel@cutter> <20050601225823.GA772000@hiwaay.net> Message-ID: <20050601230754.GA23664@srv01.cluenet.de> On Wed, Jun 01, 2005 at 05:58:23PM -0500, Chris Adams wrote: > Fedora Core is not a marketing driven project like the commercial > distros; releases need not be done on a fixed schedule. Instead, they > should be made when there is something worth making a major release and > based on technology goals. But Fedora is Red Hat's technology beta platform for RHEL - so they need somewhat timely feedback on what works and what doesn't "in the field". So I doubt that RH buys into much longer release cycles... Personally, I think 9 months is a good compromise. Best regards, Daniel (a former RHL beta tester, like you too *g*) -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From jspaleta at gmail.com Wed Jun 1 23:28:22 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 1 Jun 2005 19:28:22 -0400 Subject: What next? In-Reply-To: References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> Message-ID: <604aa791050601162840b05c06@mail.gmail.com> On 6/1/05, Mike Hearn wrote: > - Packages are contained entirely within a relocatable directory, > which has a magic marker so the finder treats it as a file > > - Packages have no dependencies outside the operating system. They > can embed libraries within themselves easily. Yep its always fun having 23 different versions of gtk installed, one for each gtk based app you want to run. All with a different patch level... with no clear way to update any of them. > - There is no auto update system. Apple also provide a traditional > Installer service, which some things use. a lack of update notification. Oh yeah.. thats absolutely wonderful. Let's take for example something based on gaim... you know something like... http://www.adiumx.com Now gaim is actively development and like all networked software its going to have issues.... http://gaim.sourceforge.net/security/ Users of adiumx, who rely on mac osx's installer have no way of knowing that a new adiumx which incorporates a new libgaim to fix vulnerabilities is available unless they proactively watch for it. Extrapolate that out to 'all' applications including network facing services.. and that's a horrible position place users in. I don't think the complete lack of an update mechanism is an equitable trade-off at all. > - Nearly every app is packaged in this way. Mac users never have to > compile from source or wait while an app [update] is packaged. So no one uses fink anymore to get applications? I guess i should go tell them to close the project down. -jef"i think its time for someone to build their own distro using the packaging paradigm they like the best"spaleta From mail.sw.rh.rhl.devel at spam.fi.basen.net Wed Jun 1 23:31:43 2005 From: mail.sw.rh.rhl.devel at spam.fi.basen.net (Kaj J. Niemi) Date: Thu, 2 Jun 2005 02:31:43 +0300 (EEST) Subject: What next? References: <429E362E.9060701@poolshark.org> Message-ID: <20050601233143.0EE352F41E2@localhost.localdomain> > I'd like to see better laptop support, in particular some sort of > Profile support as well as better wireless support. Currently to have my > laptop work both at home and at work (in dual mode), i have to hack > rc.sysinit horribly to extend the semantic of the 'netprofile=' kernel > argument so that it also changes the Xorg.conf file, .gconf files, and > so on.... I would like automatic second display support (when connecting your laptop to a projector for example). So far I haven't been able to figure out how to do it except restart X with different settings. IMHO, it's one feature Apple's Powerbooks do really well running OS X. // kaj From sopwith at redhat.com Wed Jun 1 23:35:58 2005 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 1 Jun 2005 19:35:58 -0400 (EDT) Subject: What next? In-Reply-To: <20050601225823.GA772000@hiwaay.net> References: <1117657892.31018.33.camel@cutter> <20050601225823.GA772000@hiwaay.net> Message-ID: On Wed, 1 Jun 2005, Chris Adams wrote: > Once upon a time, seth vidal said: > > What about stretching out the dev cycle from 3months dev + 3 months of > > testing to something more like 6 months of dev + 3 months of testing. > > How about deciding what the major goals of the next release should be > (within reason of course), estimating about how long it should take to > meet those goals, and then add in whatever else seems reasonable in the > given time frame? Because the decision was explicitly made when the Fedora project started to do releases at regular intervals rather than based on feature-driven milestones. This is the model Gnome has used with a good bit of success. It avoids the Debian "work on it for three years until it's perfect" syndrome, because as this thread is already showing, everyone wants "just a little bit longer" to get their pet feature just right. Best, -- Elliot From jspaleta at gmail.com Wed Jun 1 23:35:39 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 1 Jun 2005 19:35:39 -0400 Subject: What next? In-Reply-To: <5cf776b805060116063efe0650@mail.gmail.com> References: <5cf776b805060116063efe0650@mail.gmail.com> Message-ID: <604aa7910506011635a0a0c70@mail.gmail.com> On 6/1/05, mbneto wrote: > I'd like to see the minimum required size for a 'firewall-only' setup drop. > > Something like conectiva's minimum install which takes less than 70Mb. This comes up a lot. And everytime it comes up I suggest that the first step that interested community members can do is edit the comps.xml file that defines the groups the installer uses. The very first thing users interested in a smaller 'minimal' install can do is reorganize the comps.xml so the minimal install installs less without disturbing the desktop/workstation/server install types. A reworked comps.xml is easy to hand out for the rest of the community to test by rebuild isos and doing test installs. Once the groups are reorganized, you'll have to talk with specific developers about dividing packages into subpackages to reduce the minimal install further. -jef From roland at redhat.com Wed Jun 1 23:44:06 2005 From: roland at redhat.com (Roland McGrath) Date: Wed, 1 Jun 2005 16:44:06 -0700 Subject: What next? In-Reply-To: Elliot Lee's message of Wednesday, 1 June 2005 19:35:58 -0400 Message-ID: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> To reiterate what Elliot said, the basic principle as I see it is that we endeavor for the current Fedora release always to have the newest stuff that is reasonably stable. After some fairly short interval in the 3-6 month ballpark, *something* certainly has a newer and better version that is reasonably stable. So more or less any time "rawhide has newer stuff", then it's a good reason to have a Fedora Core release before too long. If that sensation comes along, and there's something with a bleeding edge that's still too bloody, then that something can roll back to the stable version until the next FC release. It won't be too long. We don't want Fedora Core ever to spend significant periods of time where there is great new fabulosity out there, in some area or other, that we aren't representing in the latest release. From jspaleta at gmail.com Wed Jun 1 23:59:13 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 1 Jun 2005 19:59:13 -0400 Subject: What next? In-Reply-To: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> Message-ID: <604aa79105060116592bb21f84@mail.gmail.com> On 6/1/05, Roland McGrath wrote: > We don't want Fedora Core ever to spend significant periods of time where > there is great new fabulosity out there, in some area or other, that we > aren't representing in the latest release. On the other hand... fedora specific infrastructure.. like a community facing buildsystem or community facing process/policy needs some breathing room when the feature set of the actual releases themselves aren't the primary focus of leadership. Pushing hard to get the latest bits out... makes it difficult to get our own processes and tools in working order.. so people can work together effectively. I'd rather see the next couple of months focused on fedora project infrastructure and process, then start the clock again for the next core release development cycle so we can have more mature tools and processes in place. -jef From stevelist at silverorange.com Wed Jun 1 23:59:45 2005 From: stevelist at silverorange.com (Steven Garrity) Date: Wed, 01 Jun 2005 20:59:45 -0300 Subject: What next? In-Reply-To: <20050601233143.0EE352F41E2@localhost.localdomain> References: <429E362E.9060701@poolshark.org> <20050601233143.0EE352F41E2@localhost.localdomain> Message-ID: <429E4BF1.3040709@silverorange.com> Kaj J. Niemi wrote: > I would like automatic second display support (when connecting your > laptop to a projector for example). So far I haven't been able to figure > out how to do it except restart X with different settings. IMHO, it's one > feature Apple's Powerbooks do really well running OS X. After watching the video of the talks from Guadec, you can see that this is a big problem. Almost every talk started off with 5 or 10 minutes of fiddling to get the video-to-projector working. In some cases, the presentation went on with partially broken displays. Of course, if we can't do, neither can John Q. PowerPoint. Steven Garrity From notting at redhat.com Thu Jun 2 00:38:32 2005 From: notting at redhat.com (Bill Nottingham) Date: Wed, 1 Jun 2005 20:38:32 -0400 Subject: What next? In-Reply-To: References: <1117655080.6271.52.camel@laptopd505.fenrus.org> <1117656479.5013.7.camel@localhost.localdomain> <20050601202109.GA30198@devserv.devel.redhat.com> Message-ID: <20050602003832.GA21696@nostromo.devel.redhat.com> Mike Hearn (mike at navi.cx) said: > > libtool.. bigger question. But we can get pkg-config to do this right if we > > spend 2 days on it. > > This was already discussed on xdg-list and by James Henstridge. Pkg-config > and libtool aren't broken, they do this for portability. The GNU linker > doesn't need you to enumerate every library in the image but some > (unbelievably) do. > > Pkg-config files can't contain --as-needed directly because it's not > portable also. Whyever on earth not? The upstream distributed pkg-config files, sure. But if you have a local pkg-config file for the current linker, the vagaries of the Solaris linker are completely irrelevant. Bill From ed at eh3.com Thu Jun 2 00:38:37 2005 From: ed at eh3.com (Ed Hill) Date: Wed, 01 Jun 2005 20:38:37 -0400 Subject: What next? In-Reply-To: References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> Message-ID: <1117672717.28429.297.camel@ernie> On Wed, 2005-06-01 at 23:48 +0100, Mike Hearn wrote: > On Wed, 01 Jun 2005 23:44:08 +0200, Kyrre Ness Sjobak wrote: > > BTW., how does osx do installs (just bringing up the meta-file installer > > thingy again. Feel free not to answer)? > That shows you pretty much how it works. In short: Hi Mike, Have you been using *nix long enough to remember when people thought it was cool to stuff every package into is own /opt/${PACKAGE} directory? Does it sound at all familiar to Apple's approach that you just described? It should because its the *exact* same crap all over again. And as Jeff and many other folks will tell you, it just doesn't scale in terms of libraries (think about shared libraries and dependencies for just a minute), security updates, etc. Its the packaging equivalent of declaring that your yard is "clean" because you keep your copious garbage heaps in carefully segregated piles. In short, its a total mess. Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From florin at andrei.myip.org Thu Jun 2 00:49:15 2005 From: florin at andrei.myip.org (Florin Andrei) Date: Wed, 01 Jun 2005 17:49:15 -0700 Subject: What next? In-Reply-To: <1117657892.31018.33.camel@cutter> References: <1117657892.31018.33.camel@cutter> Message-ID: <1117673356.5887.8.camel@rivendell.home.local> On Wed, 2005-06-01 at 16:31 -0400, seth vidal wrote: > What about stretching out the dev cycle from 3months dev + 3 months of > testing to something more like 6 months of dev + 3 months of testing. That will remove (or at least alleviate to some degree) one of the major reasons some people are currently avoiding Fedora. -- Florin Andrei http://florin.myip.org/ From florin at andrei.myip.org Thu Jun 2 00:55:51 2005 From: florin at andrei.myip.org (Florin Andrei) Date: Wed, 01 Jun 2005 17:55:51 -0700 Subject: What next? In-Reply-To: References: Message-ID: <1117673751.5887.14.camel@rivendell.home.local> On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote: > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > Extras 5 - what major features are you willing to put effort into? Some support for live-CD, Knoppix-style media. Stateless clients support is a plus. Some way to share Evolution calendar and contacts info between computers and between users. Some way to migrate desktop settings from one machine to another, so I don't end up doing rsync/ssh hacks to keep my xchat/gaim/whatever settings in sync. GL-accelerated X server, so that my eyes won't hurt anymore after staring at the tube for 10 hours straight. ...hmmm, it looks like most of the things I'm mentioning are projects that are still in full development, unfinished yet. -- Florin Andrei http://florin.myip.org/ From tromey at redhat.com Thu Jun 2 01:01:58 2005 From: tromey at redhat.com (Tom Tromey) Date: 01 Jun 2005 19:01:58 -0600 Subject: What next? In-Reply-To: References: <1117660147.9566.12.camel@localhost.localdomain> Message-ID: >>>>> "Mike" == Mike Hearn writes: >> On Wed, 01 Jun 2005 14:09:06 -0700, Anthony Green wrote: >> Most of the improvements of late imply ABI breakage because we're >> extending the library in incompatible ways. Restricting ourselves to >> non-ABI-breaking changes in GCC 4.0.x limits our ability to continue to >> demonstrate innovation. Mike> Could you elaborate on that? In a private email exchange recently Tom Mike> Tromey suggested that the ABI was stable (or very nearly stable) in that Mike> apps compiled with GCJ 4.0 would run against a 4.1 system (but not Mike> vice-versa unfortunately). Yes. There are 2 ABIs, and you are talking about one (the binary compatibility ABI, aka BC ABI) while Anthony is talking about the other one (the "C++" ABI). Our current rule for hacking libgcj in the GCC tree is that we don't break the C++ ABI in a minor release. This is a very strict rule, it means we can't do things like add new non-static methods (we can add new classes and other things like that though). While the new BC ABI is fairly solid, we put off really promising long-term binary compatibility until GCC 4.1, on the theory that we might have overlooked something. And sure enough we found a couple of bugs after shipping; but it turns out we can fix these without breaking existing (4.0-compiled) binaries. Mike> I'm afraid I'm also really convinced that breaking ABI Mike> constitutes innovation, or even is required for it ... it's a Mike> clone of Java so at most you would be adding new APIs which Mike> hopefully the ABI design allows for? Yeah, the new ABI was made precisely so we could make all the changes to libgcj that we might need to make, while not breaking any existing binaries. The idea being that at some point (4.1 is our target) we can just make the BC ABI the default one and only promise that we won't break it, and let the C++ ABI break constantly. One option for FC5 would be to go ahead and update libgcj. All the BC-compiled code would still work. Mike> I'm interested in this because I'm working with a guy who wishes to Mike> distribute GCJ compiled binaries across multiple Linux distributions. Should be ok as long as you pick a consistent required base version, and compile everything BC. Tom From cra at WPI.EDU Thu Jun 2 01:12:36 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Wed, 1 Jun 2005 21:12:36 -0400 Subject: What next? In-Reply-To: <20050601202018.GA21853@srv01.cluenet.de> References: <20050601202018.GA21853@srv01.cluenet.de> Message-ID: <20050602011236.GB16547@angus.ind.WPI.EDU> On Wed, Jun 01, 2005 at 10:20:18PM +0200, Daniel Roesen wrote: > - tool support to setup X 3D acceleration (OpenGL) stuff. I'm always > having a HARD time getting 3D accel to work. If you have an OSS-supported 3D card, there should be no need to set it up at all. It should "Just Work". If that isn't true, it is a bug. If your 3D card requires binary drivers, then having a tool in Core to configure it is silly. From green at redhat.com Thu Jun 2 01:36:08 2005 From: green at redhat.com (Anthony Green) Date: Wed, 01 Jun 2005 18:36:08 -0700 Subject: What next? In-Reply-To: <20050601211500.GB19281@nostromo.devel.redhat.com> References: <1117660147.9566.12.camel@localhost.localdomain> <20050601211500.GB19281@nostromo.devel.redhat.com> Message-ID: <1117676168.5680.4.camel@localhost.localdomain> On Wed, 2005-06-01 at 17:15 -0400, Bill Nottingham wrote: > Anthony Green (green at redhat.com) said: > > On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote: > > > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > > > Extras 5 - what major features are you willing to put effort into? > > > > We should ship a GCC 4.1 preview compiler so we can continue to > > demonstrate improvements on the java front. > > What good is demonstrating improvement if we can't use it any > apps because the ABI is moving too fast and it's not > released yet? (I'm serious.) But we would use it in apps. I'm suggesting that java-gcj-compat refer to gij41 and friends (like it used to refer to gij4 in the early days of FC4 development). AG From mattdm at mattdm.org Thu Jun 2 02:17:36 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 1 Jun 2005 22:17:36 -0400 Subject: What next? In-Reply-To: <1117665025.3094.1.camel@goose> References: <1117657892.31018.33.camel@cutter> <20050601203551.GB21761@jadzia.bu.edu> <1117661921.5219.9.camel@localhost.localdomain> <1117665025.3094.1.camel@goose> Message-ID: <20050602021736.GA31444@jadzia.bu.edu> On Thu, Jun 02, 2005 at 08:30:24AM +1000, Rodd Clarkson wrote: > > Could fedora legacy use the same repourls as fedora core/extras? So that > > it would just continue to be "yum update"? > I've often wondered why the final update for fedora (before cgoing > legacy) doesn't include a switch to fedora legacy as part of it. Because Legacy and Core aren't that coordinated yet, that's why. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 79 degrees Fahrenheit. From shiva at sewingwitch.com Thu Jun 2 02:36:31 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 01 Jun 2005 19:36:31 -0700 Subject: What next? LDAP In-Reply-To: <1117655635.6735.28.camel@dhollis-lnx.sunera.com> References: <1117655635.6735.28.camel@dhollis-lnx.sunera.com> Message-ID: <83712260D48F4DF130523E0C@[10.169.6.246]> --On Wednesday, June 01, 2005 3:53 PM -0400 David Hollis wrote: > Now that the directory server is starting to trickle out, I'd love to > see that incorporated with some form of administration tool. I've done > a bunch of LDAP setups in recent months and can now finally manage it > from command line/LDIFs but it really doesn't have to be that tough to > get a simple directory setup. The great part about it is that once it's > setup, it can do quite a bit and even act as an Active Directory domain > controller which is really a beautiful thing. Agreed. I'm trying to get up to speed on deploying OpenLDAP together with the Samba schema to get single sign-on and a global address book, but it's been tough marshaling all the HOWTO's to figure out what's really required. I went down a wrong path using the PADL scripts bundled with OpenLDAP (because I failed to select the "enhanced" schema in the common config file) and they also fail badly on the /etc/services file due to the presence of Apple protocols. So far the best information for initial setup seems to be in the HOWTO's at , but I'm still working through it to understand how to migrate my existing setup. I'd recommend that anyone starting out get the smbtools from idealx and also get phpldapadmin set up on Apache to maintain the thing and get a more visual understanding of how things are organized. Hopefully volunteers will step forward to bring these into Extras. From rjune at bravegnuworld.com Thu Jun 2 02:20:01 2005 From: rjune at bravegnuworld.com (Richard June) Date: Wed, 1 Jun 2005 21:20:01 -0500 Subject: What next? In-Reply-To: <1117673356.5887.8.camel@rivendell.home.local> References: <1117657892.31018.33.camel@cutter> <1117673356.5887.8.camel@rivendell.home.local> Message-ID: <200506012120.25613.rjune@bravegnuworld.com> On Wednesday 01 June 2005 19:49, Florin Andrei wrote: > On Wed, 2005-06-01 at 16:31 -0400, seth vidal wrote: > > What about stretching out the dev cycle from 3months dev + 3 months of > > testing to something more like 6 months of dev + 3 months of testing. > > That will remove (or at least alleviate to some degree) one of the major > reasons some people are currently avoiding Fedora. What would alleviate it more is if one could upgrade Fedora versions via yum easily. I understand that's not always possible, but if you've kept to FC and extras, it would be great for that to be an option -- Public Key available Here: http://www.bravegnuworld.com/~rjune/pubkey.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mricon at gmail.com Thu Jun 2 03:01:14 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Wed, 1 Jun 2005 23:01:14 -0400 Subject: Packaging idea (Re: What next?) In-Reply-To: <604aa791050601162840b05c06@mail.gmail.com> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> Message-ID: > -jef"i think its time for someone to build their own distro using the > packaging paradigm they like the best"spaleta So, check this out. I'm going to brainstorm outloud, so feel free to shoot me down at any point. We have: 1. People seem to like Apple's idea of dragging and dropping a self-contained application folder into their Applications window, and see it magically work. Of course, this is a horrible idea, since it leads to the wonderful situation of a gajillion versions of libz and libxml being installed, all in different levels of (un)patching. The appeal, however, seems to be related to drag-and-dropping and seeing it magically work. 2. Yum has leet magic powers to install software, tracking all necessary dependencies via RPM libs, as long as the packages are a) not broken and b) not built for another distro. 3. Yum has leet magic powers to update installed software via various repositories that anyone around the world can create and maintain, above exceptions a) and b) nonwithstanding. What if: We create a "super-package" that is effectively a yum .repo file with a little extra information, and which can additionally contain a set of packages. Let's call this Fedora Active Package (FAP). Let's say I want to package my FlyingCows screensaver for Fedora, and I don't actually want to bother with Extras, since that's way too much trouble. So, I create a FlyingCows.fap, which is a zip archive containing the following files: 1. A manifest describing the software I am packaging, which would include a brief description with licensing information, which distribution(s), which arch(es), and which version it is for (Fedora Core 4 i386), maybe some other stuff like packager info. The manifest would also link each distribution information with the .repo file for that distribution. 2. FlyingCows.png to use for representing the package in, say, Nautilus. 3. A FlyingCows.repo file for yum. There may be more than one if more than one distribution is handled 4. Optionally, FlyingCows-1.0.0-1.fc4.i386.rpm and any additional libraries it depends on, all packaged snugly, which is useful for giving out CDs, for example. FAP packages containing actual binaries can be called .fab. So, I package FlyingCows.fap and put it on my site. A user, wanting to install my l33t screensaver, comes to my site and downloads FlyingCows.fap onto their desktop. Then, they open the apps:// pseudo-folder in Nautilus (similar to, say, fonts://), and drag the FlyingCows.fap there (or just double-click the package, which is the same). Once this happens, the following things would occur: 1. A package information screen would pop up, containing pre-installation information for the FlyingCows screensaver, like the license, packaging info, etc. At this step a very basic distro sanity comparison would be done, with a warning and a refusal if the user's distribution is not packaged for: "You are trying to install FlyingCows on a distribution that is not handled by this package (Fedora Core 1). This package can only be installed on the following systems: Fedora Core 3, Fedora Core 4, RHEL 4, CentOS 4). Install cannot proceed." If Distribution does check out (a .repo file exists for it), then installation goes on. 2. A user clicks "YES" on the license agreement. 3. The FAP handler installs the .repo file and, if there are any binary files in the package, installs them into /var/cache/yum/[repoid]: in other words, pre-populates the yum download directory. 4. At this point yum is invoked, which handles the actual installation -- including key download and verification, library dependencies, etc. If there are newer versions available in my FlyingCows remote repository, it downloads the latest versions and installs them instead of the bundled binary files (optionally asking the user if they want to do that). 5. If everything succeeds, a "FlyingCows is installed" is presented to the happy user. When the user gets tired of the Flying Cows, they can go to their apps:/// pseudo-folder and drag the FlyingCows.png into the trash. This would fire up the FAP handler and do a yum erase on the packages installed by the FlyingCows.fap, which happens completely transparently. What do you think? Xingbuxing? There are drawbacks to this, of course, but I can't think of any ones that we don't already have, like generally broken packages and whacky packagers. Having a super-package like a .fap or a .fab would allow vendors to package things for multiple distributions by simply providing multiple .repo files, with yum receiving the appropriate one. Comments, please. :) Cheers, -- Konstantin Ryabitsev Zlotniks, INC "???????? ?????????? ????? ? ??????? ???? ?????." From rjune at bravegnuworld.com Thu Jun 2 02:02:47 2005 From: rjune at bravegnuworld.com (Richard June) Date: Wed, 1 Jun 2005 21:02:47 -0500 Subject: What next? In-Reply-To: <20050601224519.GC23343@srv01.cluenet.de> References: <1117662072.5219.12.camel@localhost.localdomain> <20050601224519.GC23343@srv01.cluenet.de> Message-ID: <200506012103.21114.rjune@bravegnuworld.com> [snip] > When I looked for a solution a few weeks ago, I've spend some hours > of googling and reading mailing list archives, and the only thing I've > been able to come up with was > > a) use OpenGroupware! > b) use Microsoft Exchange! > c) oh yeah, I'd really like a lightweight server without all the > bloat OpenGroupware needs to just store my stuff somewhere > accessibly from remote locations > > The general consensus I found everywhere was "doesn't exist, or use > the big ones". > > I didn't stumble over Hula at all... interesting. And Hula doesn't do > contacts stuff. And that's besides calendar stuff what I'd need Evo > most for - but it does other stuff I don't need, e.g. IMAP4 server > and webmail etc. Well, if you don't use Evo, you can use egroupware as a backend server for kontact(kmail/korganizer/kaddressbook) and it works pretty well. it's not nearly the PITA to manage that opengroupware or MS Exchange are. I prefer IMAP4 myself, something about being able to get to my email everywhere(kinda like you want to do with your calandar and contacts) -- Public Key available Here: http://www.bravegnuworld.com/~rjune/pubkey.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Thu Jun 2 03:10:31 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 1 Jun 2005 23:10:31 -0400 Subject: Packaging idea (Re: What next?) In-Reply-To: References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> Message-ID: <604aa79105060120106eef01ae@mail.gmail.com> On 6/1/05, Konstantin Ryabitsev wrote: > Let's say I > want to package my FlyingCows screensaver for Fedora, and I don't > actually want to bother with Extras, since that's way too much > trouble. So, I create a FlyingCows.fap, which is a zip archive > containing the following files: Are you honestly saying... that working with other people.. inside the Extras policy space is MORE trouble.. then creating yet another layer of technical complexity.. that other people will have to help you completely implement in other user-facing parts of the operating system? -jef"And I thought I was anti-social"spaleta From mike at flyn.org Thu Jun 2 03:24:26 2005 From: mike at flyn.org (W. Michael Petullo) Date: Wed, 1 Jun 2005 22:24:26 -0500 Subject: What next? In-Reply-To: References: Message-ID: <20050602032426.GA3626@imp.flyn.org> > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > Extras 5 - what major features are you willing to put effort into? Okay, every six months I advertise some of my own projects: - Bugzilla #127378 Encrypted swap - Bugzilla #124789 Encrypted root And here are of few more of interest to me: - Bugzilla #158657 Build totem's Mozilla plugin - Bugzilla #127537 Free software applet viewer plugin - Free software flash viewer? - Bugzilla #122274 Mouse button emulation on Mac laptops -- Mike :wq From mricon at gmail.com Thu Jun 2 04:16:47 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Thu, 2 Jun 2005 00:16:47 -0400 Subject: Packaging idea (Re: What next?) In-Reply-To: <604aa79105060120106eef01ae@mail.gmail.com> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <604aa79105060120106eef01ae@mail.gmail.com> Message-ID: On 6/1/05, Jeff Spaleta wrote: > Are you honestly saying... that working with other people.. inside the > Extras policy space is MORE trouble.. then creating yet another layer > of technical complexity.. that other people will have to help you > completely implement in other user-facing parts of the operating > system? (correcting gmail's moronic reply handling) Well, there isn't much added technical complexity here. This is more or less a glorified "download a .repo file for your distribution and put it in your /etc/yum.repos.d" directory with a Nautilus plugin. And yes, I'm pretty sure a lot of people will not bother with Extras, if only because: a. They don't care to jump through all the hoops involved. b. They don't want to bind themselves with any sort of a contract with Red Hat. c. Their software is licensed so that it cannot be put in Extras. -- Konstantin Ryabitsev Zlotniks, INC "???????? ?????????? ????? ? ??????? ???? ?????." From skvidal at phy.duke.edu Thu Jun 2 04:27:23 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 02 Jun 2005 00:27:23 -0400 Subject: Packaging idea (Re: What next?) In-Reply-To: References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <604aa79105060120106eef01ae@mail.gmail.com> Message-ID: <1117686443.2702.9.camel@cutter> > Well, there isn't much added technical complexity here. This is more > or less a glorified "download a .repo file for your distribution and > put it in your /etc/yum.repos.d" directory with a Nautilus plugin. And > yes, I'm pretty sure a lot of people will not bother with Extras, if > only because: > > a. They don't care to jump through all the hoops involved. the hoops are getting lower and easier to overcome. > b. They don't want to bind themselves with any sort of a contract with Red Hat. the cla is very much like the asf's licensing agreement - nothing really special in it at all. > c. Their software is licensed so that it cannot be put in Extras. yep. that's the use case I figured from the .fap file you were describing before. -sv From mricon at gmail.com Thu Jun 2 04:35:24 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Thu, 2 Jun 2005 00:35:24 -0400 Subject: Packaging idea (Re: What next?) In-Reply-To: <1117686443.2702.9.camel@cutter> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <604aa79105060120106eef01ae@mail.gmail.com> <1117686443.2702.9.camel@cutter> Message-ID: On 6/2/05, seth vidal wrote: > > c. Their software is licensed so that it cannot be put in Extras. > > yep. that's the use case I figured from the .fap file you were > describing before. Yes, I cannot deny that the last 2 weeks spent packaging nonfree software has greatly influenced this post. :) That, plus the sad fact that even though several vendors provide .rpm files, they are utterly unusable because they try to be installable on as many things as possible, and always end up sucking on all. -- Konstantin Ryabitsev Zlotniks, INC "???????? ?????????? ????? ? ??????? ???? ?????." From jspaleta at gmail.com Thu Jun 2 04:41:15 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 2 Jun 2005 00:41:15 -0400 Subject: Packaging idea (Re: What next?) In-Reply-To: References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <604aa79105060120106eef01ae@mail.gmail.com> <1117686443.2702.9.camel@cutter> Message-ID: <604aa7910506012141650fbecf@mail.gmail.com> On 6/2/05, Konstantin Ryabitsev wrote: > Yes, I cannot deny that the last 2 weeks spent packaging nonfree > software has greatly influenced this post. :) That, plus the sad fact > that even though several vendors provide .rpm files, they are utterly > unusable because they try to be installable on as many things as > possible, and always end up sucking on all. so basically the fap layer is only really a target for nonfree software... but clearly its doomed to fail because the pre-existing conditions for it to be used successfully are not going to be met if proprietary vendors can't package rpms correctly.. the fap layer doesn't help. if proprietary vendors can't create repos correctly.. the fap layer doesn't help. I have very little faith in proprietary vendors doing either correctly. -jef From ed at eh3.com Thu Jun 2 04:52:05 2005 From: ed at eh3.com (Ed Hill) Date: Thu, 02 Jun 2005 00:52:05 -0400 Subject: Packaging idea (Re: What next?) In-Reply-To: References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <604aa79105060120106eef01ae@mail.gmail.com> <1117686443.2702.9.camel@cutter> Message-ID: <1117687925.28429.348.camel@ernie> On Thu, 2005-06-02 at 00:35 -0400, Konstantin Ryabitsev wrote: > On 6/2/05, seth vidal wrote: > > > c. Their software is licensed so that it cannot be put in Extras. > > > > yep. that's the use case I figured from the .fap file you were > > describing before. > > Yes, I cannot deny that the last 2 weeks spent packaging nonfree > software has greatly influenced this post. :) That, plus the sad fact > that even though several vendors provide .rpm files, they are utterly > unusable because they try to be installable on as many things as > possible, and always end up sucking on all. Yes, very true. And what could be done to help fix that? I propose: reviews, feedback, & iterative improvement In my opinion, your original "thinking-out-loud" post overlooked perhaps the biggest benefit of projects like Fedora Extras which is the *reviews*. Folks seem to be very focused on tools but I'm not convinced that better versions of yum, rpm, rpmlint, etc. will solve everything. The tools can help a *lot* but, ultimately, its best to have a few people review your junk and offer feedback. Even the sexiest and most modern of automated tools still do a lousy job of discerning intent and suggesting better approaches. And if the 3rd-party or commercial packagers that you mention joined the conversation, accepted feedback, and then used it to improve things their packages would probably suck a lot less. But then perhaps they wouldn't be "3rd-party" any more... ;-) Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From mricon at gmail.com Thu Jun 2 05:03:24 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Thu, 2 Jun 2005 01:03:24 -0400 Subject: Packaging idea (Re: What next?) In-Reply-To: <604aa7910506012141650fbecf@mail.gmail.com> References: <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <604aa79105060120106eef01ae@mail.gmail.com> <1117686443.2702.9.camel@cutter> <604aa7910506012141650fbecf@mail.gmail.com> Message-ID: On 6/2/05, Jeff Spaleta wrote: > > Yes, I cannot deny that the last 2 weeks spent packaging nonfree > > software has greatly influenced this post. :) That, plus the sad fact > > that even though several vendors provide .rpm files, they are utterly > > unusable because they try to be installable on as many things as > > possible, and always end up sucking on all. > > so basically the fap layer is only really a target for nonfree > software... but clearly > its doomed to fail because the pre-existing conditions for it to be > used successfully are not going to be met > > if proprietary vendors can't package rpms correctly.. the fap layer > doesn't help. > if proprietary vendors can't create repos correctly.. the fap layer > doesn't help. > > I have very little faith in proprietary vendors doing either correctly. Well, not exactly. The problem currently is that the only relatively standard packaging format available to vendors is .rpm, which works great when there is one distro, and not so great when there are many (the famous "rpms just create dependency hell" complaint). So, vendors have several ways out: 1. Don't bother and ship tarballs with a #!/bin/sh installer. Have some sort of an asinine custom updating mechanism, or none at all. 2. Create a long list for user to choose from: * download this if you are running Suse 8 * download this if you are running Suse 9 * download this if you are running Fedora Core 2 * download this if you are running Fedora Core 3 * ... ...which they rarely do, since they think it confuses users, and because some users only have a vague idea what distribution/version they are running. If the vendor ships kernel modules, then this list grows exponentially (see NVidia download page for examples). No updating mechanism available. 3. Create one RPM that statically links most things, and tries to work on anything by having horrendous staircases of %if-%endif, and by installing everything in /usr/local and hoping things still work. No updating mechanisms available. A super-package mechanism would help create a framework that would allow addressing the problems listed above. I'm not saying that vendors are guaranteed to use it (and not abuse it, or use poorly as they are wont to do with anything NIH), but if a mechanism is in place that makes things for them easier and convenient, then at least there would be a compelling reason for them to at least do something about the pitiful state things are in at the moment. Regards, -- Konstantin Ryabitsev Zlotniks, INC "???????? ?????????? ????? ? ??????? ???? ?????." From skvidal at phy.duke.edu Thu Jun 2 05:10:42 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 02 Jun 2005 01:10:42 -0400 Subject: What next? In-Reply-To: References: <1117657892.31018.33.camel@cutter> <20050601225823.GA772000@hiwaay.net> Message-ID: <1117689042.2702.25.camel@cutter> > Because the decision was explicitly made when the Fedora project started > to do releases at regular intervals rather than based on feature-driven > milestones. This is the model Gnome has used with a good bit of success. > It avoids the Debian "work on it for three years until it's perfect" > syndrome, because as this thread is already showing, everyone wants "just > a little bit longer" to get their pet feature just right. You'll note I didn't say drag it on ad infinitum, nor did I say we should make it stay that length of time permanently. I said for the next release make it a specifically longer length of time to do development work in. That's all. I'm saying that I think there is room to discuss a different timeline other than the 'every 6 months, release' timeline and I think that given the tasks set ahead for FC5 that I've heard batted around over the last N months that it would be worthwhile to lengthen the time for development for this release. -sv From skvidal at phy.duke.edu Thu Jun 2 05:12:54 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 02 Jun 2005 01:12:54 -0400 Subject: What next? In-Reply-To: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> Message-ID: <1117689174.2702.28.camel@cutter> On Wed, 2005-06-01 at 16:44 -0700, Roland McGrath wrote: > To reiterate what Elliot said, the basic principle as I see it is that we > endeavor for the current Fedora release always to have the newest stuff > that is reasonably stable. After some fairly short interval in the 3-6 > month ballpark, *something* certainly has a newer and better version that > is reasonably stable. So more or less any time "rawhide has newer stuff", > then it's a good reason to have a Fedora Core release before too long. If > that sensation comes along, and there's something with a bleeding edge > that's still too bloody, then that something can roll back to the stable > version until the next FC release. It won't be too long. > > We don't want Fedora Core ever to spend significant periods of time where > there is great new fabulosity out there, in some area or other, that we > aren't representing in the latest release. That's easy for you to say. You get paid to work on linux and/or fedora/rhel for a living. You have all day to work on it. If fedora is intended to have community involvement you have to remember that there are many of us who are doing this outside of our real job. Remember, fedora is for hobbyists. But if hobbyists cannot participate in development b/c the cycle is just too fast, well then it's not too terribly useful for us, is it. -sv From skvidal at phy.duke.edu Thu Jun 2 05:14:34 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 02 Jun 2005 01:14:34 -0400 Subject: What next? In-Reply-To: <200506012120.25613.rjune@bravegnuworld.com> References: <1117657892.31018.33.camel@cutter> <1117673356.5887.8.camel@rivendell.home.local> <200506012120.25613.rjune@bravegnuworld.com> Message-ID: <1117689274.2702.31.camel@cutter> On Wed, 2005-06-01 at 21:20 -0500, Richard June wrote: > What would alleviate it more is if one could upgrade Fedora versions via yum > easily. I understand that's not always possible, but if you've kept to FC and > extras, it would be great for that to be an option for many cases in the recent past it has been doable, but not necessarily supported. the reality is that the number of things changed in a major way make it difficult. FC1->FC2 was selinux and the kernel version change FC2->FC3 was lvm2 and udev -sv From fedora at leemhuis.info Thu Jun 2 05:25:24 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 02 Jun 2005 07:25:24 +0200 Subject: What next? In-Reply-To: References: Message-ID: <1117689924.2227.24.camel@thl.ct.heise.de> Am Mittwoch, den 01.06.2005, 13:59 -0400 schrieb Elliot Lee: > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > Extras 5 - what major features are you willing to put effort into? These were the first ideas that jumped out of my head: - http://gnome-power.sourceforge.net/ ? - Suspend-to-Disk support in the kernel? I know, Davej does not like the implementation in the kernel. Okay, I trust his decision -- but outsiders may not. And on the other side: Suse (and probably others) use it since two or three versions now. IMHO we should either prove somehow why we don't like it and therefor disable it in our kernel -- or we should enable (and test)it (at least in rawhide). - core only on three(?) CDs (better one)? - One DVD that can install both i386 and x86_64 (now that Intel starts shipping Celerons more and more people will try x86_64) - x86-Fedora-Live-DVD (like Knoppix) that also can install both i386 and x86_64 (for computer magazines that want to ship one media with a Linux-Distribution together with their print issue). - Once during lifetime of Core a updated media-set with all updates integrated -- this was done for the Red Hat magazine before iirc - One minor thing: network yum cache of downloaded packages. With something like that you don't have to download all packages more then once if you install them on more then one system (okay, something like that can be implemented with a shared network folder -- until someone calls "yum clean all" or does other bad things). I can post more details if someone is interested - Maybe a central "folder"/frontend from where you can call all the "system-config-*" (no, I don't think we need it -- but it seems those yast and drakeconf users miss something like that) - dmraid support in anaconda (I don't like this fake-raid-controllers but users do...) BTW, who takes all suggestions from this thread and updates http://www.fedoraproject.org/wiki/Wishlist ? CU thl From mike at navi.cx Thu Jun 2 06:07:08 2005 From: mike at navi.cx (Mike Hearn) Date: Thu, 02 Jun 2005 07:07:08 +0100 Subject: What next? References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <1117672717.28429.297.camel@ernie> Message-ID: On Wed, 01 Jun 2005 20:38:37 -0400, Ed Hill wrote: > Have you been using *nix long enough to remember when people thought it > was cool to stuff every package into is own /opt/${PACKAGE} directory? Yep. > Does it sound at all familiar to Apple's approach that you just > described? Nope. Not really. Putting apps in their own (movable) directory isn't the issue here. The things that make appfolders easy go pretty deep, but the fact that it's implemented in terms of magic directories is just a surface detail. From mike at navi.cx Thu Jun 2 06:13:33 2005 From: mike at navi.cx (Mike Hearn) Date: Thu, 02 Jun 2005 07:13:33 +0100 Subject: What next? References: <1117660147.9566.12.camel@localhost.localdomain> Message-ID: On Wed, 01 Jun 2005 19:01:58 -0600, Tom Tromey wrote: > Yes. There are 2 ABIs, and you are talking about one (the binary > compatibility ABI, aka BC ABI) while Anthony is talking about the > other one (the "C++" ABI). Hmm, interesting! OK, so you can choose which ABI your binary uses at compile time? When would you ever *not* want the BC ABI? Oh, wait, or is this for using the libgcj objects from actual C++ code using CNI? thanks -mike From mike at navi.cx Thu Jun 2 06:10:54 2005 From: mike at navi.cx (Mike Hearn) Date: Thu, 02 Jun 2005 07:10:54 +0100 Subject: What next? References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> Message-ID: On Wed, 01 Jun 2005 19:28:22 -0400, Jeff Spaleta wrote: > Yep its always fun having 23 different versions of gtk installed, one > for each gtk based app you want to run. All with a different patch > level... with no clear way to update any of them. Word on the street is that it's traditional for operating systems to ship with a widget toolkit and lots of other things too. Mac apps usually have few (if any) dependencies because they depend on the OS itself. By saying "This app requires MacOS X 10.3 or higher" apps get a massive chunk of functionality for free, that would on Linux require about 70 dependencies in order to express. > a lack of update notification. Oh yeah.. thats absolutely wonderful. That's why Gaim has an auto-update plugin that will pop up a message when there is an update. In fact, given that the little Fedora/Red Hat tray thing has *never* actually been able to stick in my session for more than about a week, I'm not sure why you think Fedora has user-friendly auto update either. Remembering to run a magic command every few weeks isn't user friendly. >> - Nearly every app is packaged in this way. Mac users never have to >> compile from source or wait while an app [update] is packaged. > > So no one uses fink anymore to get applications? I guess i should go > tell them to close the project down. No, Apples target audience are not UNIX heads using lots of trivially "ported" software so nobody in their target audience uses fink. Apps that are actually designed and built for the Mac as opposed to simply being compilable on it never have to be compiled from the source. Ever. thanks -mike From felipe.alfaro at gmail.com Thu Jun 2 06:22:04 2005 From: felipe.alfaro at gmail.com (Felipe Alfaro Solana) Date: Thu, 2 Jun 2005 08:22:04 +0200 Subject: What next? In-Reply-To: <1117662394.31018.80.camel@cutter> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <1117662394.31018.80.camel@cutter> Message-ID: <6f6293f105060123227235d2d2@mail.gmail.com> On 6/1/05, seth vidal wrote: > > BTW., how does osx do installs (just bringing up the meta-file installer > > thingy again. Feel free not to answer)? > > their package system, umm, err, sucks. Yeah! But many applications come packaged in such a way that the user simply needs to drag'n'drop them to the /Applications directory. That's really simple. From mike at navi.cx Thu Jun 2 06:16:18 2005 From: mike at navi.cx (Mike Hearn) Date: Thu, 02 Jun 2005 07:16:18 +0100 Subject: What next? References: <1117655080.6271.52.camel@laptopd505.fenrus.org> <1117656479.5013.7.camel@localhost.localdomain> <20050601202109.GA30198@devserv.devel.redhat.com> <20050602003832.GA21696@nostromo.devel.redhat.com> Message-ID: On Wed, 01 Jun 2005 20:38:32 -0400, Bill Nottingham wrote: > Whyever on earth not? > > The upstream distributed pkg-config files, sure. > > But if you have a local pkg-config file for the current linker, > the vagaries of the Solaris linker are completely irrelevant. Hmm, are you suggesting patching every .pc file in Fedora to have this option? One solution might be to use variables ... I think pkg-config allows stuff like Libs: $(foo) -lbar -lbaz Where foo could be defined internally as either "" in the portable upstream version or "--as-needed" in the downstream version. From mike at navi.cx Thu Jun 2 06:30:12 2005 From: mike at navi.cx (Mike Hearn) Date: Thu, 02 Jun 2005 07:30:12 +0100 Subject: Packaging idea (Re: What next?) References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> Message-ID: On Wed, 01 Jun 2005 23:01:14 -0400, Konstantin Ryabitsev wrote: > Having a super-package like a .fap or a .fab would allow vendors to > package things for multiple distributions by simply providing multiple > .repo files, with yum receiving the appropriate one. Well, distros other than Fedora don't use yum. But apart from that you very nearly described autopackage, except that autopackage exists and is being used right now: http://autopackage.org/gallery.html FlyingCows is very much the sort of thing it was built for. thanks -mike From jakub at redhat.com Thu Jun 2 06:37:33 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 2 Jun 2005 02:37:33 -0400 Subject: What next? In-Reply-To: References: <1117655080.6271.52.camel@laptopd505.fenrus.org> <1117656479.5013.7.camel@localhost.localdomain> <20050601202109.GA30198@devserv.devel.redhat.com> <20050602003832.GA21696@nostromo.devel.redhat.com> Message-ID: <20050602063733.GW22349@devserv.devel.redhat.com> On Thu, Jun 02, 2005 at 07:16:18AM +0100, Mike Hearn wrote: > Libs: $(foo) -lbar -lbaz > > Where foo could be defined internally as either "" in the portable > upstream version or "--as-needed" in the downstream version. Note that it would need to be Libs: $(foo) -lbar -lbaz $(no_foo) foo = --as-needed no_foo = --no-as-needed as the mere fact that you are linking against pkg-configed library xyz doesn't imply all libraries must be linked with --as-needed. Jakub From mike at navi.cx Thu Jun 2 06:41:42 2005 From: mike at navi.cx (Mike Hearn) Date: Thu, 02 Jun 2005 07:41:42 +0100 Subject: What next? References: <1117655080.6271.52.camel@laptopd505.fenrus.org> <1117656479.5013.7.camel@localhost.localdomain> <20050601202109.GA30198@devserv.devel.redhat.com> <20050602003832.GA21696@nostromo.devel.redhat.com> <20050602063733.GW22349@devserv.devel.redhat.com> Message-ID: On Thu, 02 Jun 2005 02:37:33 -0400, Jakub Jelinek wrote: > as the mere fact that you are linking against pkg-configed library xyz > doesn't imply all libraries must be linked with --as-needed. True, but how often would you not want un-needed dependencies to be stripped? Is that a common thing to do? thanks -mike From a.kurtz at hardsun.net Thu Jun 2 06:46:47 2005 From: a.kurtz at hardsun.net (Aaron Kurtz) Date: Wed, 01 Jun 2005 23:46:47 -0700 Subject: What next? In-Reply-To: <20050602032426.GA3626@imp.flyn.org> References: <20050602032426.GA3626@imp.flyn.org> Message-ID: <1117694807.3567.11.camel@rydia.hardsun.net> On Wed, 2005-06-01 at 22:24 -0500, W. Michael Petullo wrote: > > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > > Extras 5 - what major features are you willing to put effort into? > And here are of few more of interest to me: > > - Bugzilla #158657 Build totem's Mozilla plugin > - Bugzilla #127537 Free software applet viewer plugin http://www.nongnu.org/gcjwebplugin/ is being worked on. The blocker is the current lack of sandboxing. > - Free software flash viewer? http://www.schleef.org/swfdec/ plays some Flash, but fails on interactive and later Flash versions. -- Aaron Kurtz GPG Key ID: ED588CF2 From arjanv at redhat.com Thu Jun 2 07:19:52 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Thu, 02 Jun 2005 09:19:52 +0200 Subject: What next? In-Reply-To: <20050602063733.GW22349@devserv.devel.redhat.com> References: <1117655080.6271.52.camel@laptopd505.fenrus.org> <1117656479.5013.7.camel@localhost.localdomain> <20050601202109.GA30198@devserv.devel.redhat.com> <20050602003832.GA21696@nostromo.devel.redhat.com> <20050602063733.GW22349@devserv.devel.redhat.com> Message-ID: <1117696792.6458.15.camel@laptopd505.fenrus.org> On Thu, 2005-06-02 at 02:37 -0400, Jakub Jelinek wrote: > On Thu, Jun 02, 2005 at 07:16:18AM +0100, Mike Hearn wrote: > > Libs: $(foo) -lbar -lbaz > > > > Where foo could be defined internally as either "" in the portable > > upstream version or "--as-needed" in the downstream version. > > Note that it would need to be > Libs: $(foo) -lbar -lbaz $(no_foo) > foo = --as-needed > no_foo = --no-as-needed or better Libs: -lbar NeededLibs: -lbaz where pkg-config collects the various groups together, dedupes and then either issues --as-needed ... --no-as-needed around them (gnu-ld) or just put them there (non-gnu-ld). Not rocket science.. and takes those 2 days ;) -------------- 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 veillard at redhat.com Thu Jun 2 08:25:06 2005 From: veillard at redhat.com (Daniel Veillard) Date: Thu, 2 Jun 2005 04:25:06 -0400 Subject: What next? In-Reply-To: <20050601203005.GB30198@devserv.devel.redhat.com> References: <1117655080.6271.52.camel@laptopd505.fenrus.org> <1117656479.5013.7.camel@localhost.localdomain> <1117656834.6271.64.camel@laptopd505.fenrus.org> <1117657616.5013.9.camel@localhost.localdomain> <20050601203005.GB30198@devserv.devel.redhat.com> Message-ID: <20050602082506.GN20018@redhat.com> On Wed, Jun 01, 2005 at 10:30:05PM +0200, Arjan van de Ven wrote: > > On Wed, Jun 01, 2005 at 01:26:56PM -0700, Nicholas Miell wrote: > > Ah. I thought you meant that things were using both libxml2 and SAX in > > different parts of the app, or something to that effect. > > well both actually. You mean libxml2 and expat I assume. SAX is just an API more or less common to both libraries. Don't forget GMarkup which is also the non-compliant (and apparently slower if I believe feedback I got) parser embedded in glib. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From kewley at gps.caltech.edu Thu Jun 2 08:27:46 2005 From: kewley at gps.caltech.edu (David Kewley) Date: Thu, 2 Jun 2005 01:27:46 -0700 Subject: What next? In-Reply-To: <20050601202018.GA21853@srv01.cluenet.de> References: <20050601202018.GA21853@srv01.cluenet.de> Message-ID: <200506020127.46100.kewley@gps.caltech.edu> On Wednesday 01 June 2005 13:20, Daniel Roesen wrote: > On Wed, Jun 01, 2005 at 01:59:19PM -0400, Elliot Lee wrote: > > Maybe it's time to start the brainstorming for Fedora Core 5 and > > Fedora Extras 5 - what major features are you willing to put effort > > into? > > - a window manager which isn't the functional equivalent of > hello_world.c where I cannot even easily grab a window and just > move it to another desktop without fiddling with the pager or some > menus (all only allowing to drag the window to the same relative > position on another desktop... I'd like to just grab the window, > hit the desktop border and can drag along in the next adjacent > desktop - as it is possible with about all other WMs. metacity is > just inferior). Doesn't have to be Enlightenment, but please... :-) KDE. ;) I'm using it now on FC4t3. David From rms at 1407.org Thu Jun 2 08:55:40 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Thu, 02 Jun 2005 09:55:40 +0100 Subject: What next? In-Reply-To: References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> Message-ID: <1117702540.2777.8.camel@roque> On Wed, 2005-06-01 at 23:48 +0100, Mike Hearn wrote: > - Packages are contained entirely within a relocatable directory, > which has a magic marker so the finder treats it as a file > > - Packages have no dependencies outside the operating system. They > can embed libraries within themselves easily. The only thing this helps is proprietary crap, which can't be fixed to use new libraries or the standard system library version of whatever. There's no need for the free world to work this way because proprietary software is crapware :) Rui -- + 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...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.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 kyrre at solution-forge.net Thu Jun 2 09:39:19 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Thu, 02 Jun 2005 11:39:19 +0200 Subject: Packaging idea (Re: What next?) In-Reply-To: References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> Message-ID: <1117705158.3355.5.camel@localhost.localdomain> tor, 02.06.2005 kl. 08.30 skrev Mike Hearn: > On Wed, 01 Jun 2005 23:01:14 -0400, Konstantin Ryabitsev wrote: > > Having a super-package like a .fap or a .fab would allow vendors to > > package things for multiple distributions by simply providing multiple > > .repo files, with yum receiving the appropriate one. > > Well, distros other than Fedora don't use yum. But apart from that you > very nearly described autopackage, except that autopackage exists and is > being used right now: > > http://autopackage.org/gallery.html > No, its more similar to my .install idea a few weeks back, which everyone killed because "it sounds like Windows installer. GO AWAY!". Never metion GUI ideas in such a proposal... BTW, would this format be capable of providing multiple repos for multiple distros/distro versions? Kyrre From kyrre at solution-forge.net Thu Jun 2 09:43:45 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Thu, 02 Jun 2005 11:43:45 +0200 Subject: What next? In-Reply-To: <1117662394.31018.80.camel@cutter> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <1117662394.31018.80.camel@cutter> Message-ID: <1117705424.3355.8.camel@localhost.localdomain> ons, 01.06.2005 kl. 23.46 skrev seth vidal: > > > > > > > What about making it possible for non-text users to use yum? They > > shouldn't be kept out of such a great tool :) > > it's a work-in-progress. > > > > BTW., how does osx do installs (just bringing up the meta-file installer > > thingy again. Feel free not to answer)? > > their package system, umm, err, sucks. > > a lot. I was more referring to the little dialog that popped up when you installed it. Not the appfolders (which suck, at least technically). From P at draigBrady.com Thu Jun 2 09:49:48 2005 From: P at draigBrady.com (P at draigBrady.com) Date: Thu, 02 Jun 2005 10:49:48 +0100 Subject: What next? In-Reply-To: References: Message-ID: <429ED63C.5080208@draigBrady.com> Elliot Lee wrote: > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > Extras 5 - what major features are you willing to put effort into? Continue/support the RAM optimization work in gnome/X Core-- && Extras++ Stateless Better support for (kickstart) CD customization -- P?draig Brady - http://www.pixelbeat.org -- From tarjei.knapstad at predichem.com Thu Jun 2 09:57:26 2005 From: tarjei.knapstad at predichem.com (Tarjei Knapstad) Date: Thu, 02 Jun 2005 11:57:26 +0200 Subject: What next? In-Reply-To: References: <1cef3e9505060113142ede12fc@mail.gmail.com> <1117657906.31018.35.camel@cutter> Message-ID: <1117706246.776.26.camel@tarjei.predichem.nett> On Thu, 2005-06-02 at 00:24, Mike Hearn wrote: > On Wed, 01 Jun 2005 16:31:46 -0400, seth vidal wrote: > > > Bandwidth friendly yum using binary delta algs. > > > > > > > HAHAHAHAHAH > > no. :) > > Why not? SUSE do this, I think. > Initially I don't see any humongous hurdles here either, but others have investigated this a lot more than I have and come to rather different conclusions :) See this post from Warren for instance from a thread January last year: http://www.redhat.com/archives/fedora-devel-list/2004-January/msg01494.html The start of that thread contains some proof of concept scripts that seems to have passed initial testing, but I'm not sure where it all ended...? One consideration would be extra server space. Unless a common "RPM diff/patch API" is developed that can be employed by yum, up2date, apt etc. then you'll need to provide both the binary patches and the full updated RPM's which I guess would roughly double the serverspace needed. I think you would also need more local space, i.e. wouldn't every RPM that comes with the distribution need to be available so that they can be copied and patched with updates? In any case, you're right about SuSE - they've done it for quite some time I think, but I have no idea how they've implemented it. To sum up my feelings: Initial thought: That would be great! Second thought: That would probably be nice. Upon further investigation: I have no idea really, but Seth, Warren and others seem to have deemed it not feasible or at least hard to pull off successfully. Regards, -- Tarjei From mls at suse.de Thu Jun 2 10:10:12 2005 From: mls at suse.de (Michael Schroeder) Date: Thu, 2 Jun 2005 12:10:12 +0200 Subject: What next? In-Reply-To: <1117706246.776.26.camel@tarjei.predichem.nett> References: <1cef3e9505060113142ede12fc@mail.gmail.com> <1117657906.31018.35.camel@cutter> <1117706246.776.26.camel@tarjei.predichem.nett> Message-ID: <20050602101012.GA15208@suse.de> On Thu, Jun 02, 2005 at 11:57:26AM +0200, Tarjei Knapstad wrote: > The start of that thread contains some proof of concept scripts that > seems to have passed initial testing, but I'm not sure where it all > ended...? One consideration would be extra server space. Unless a common > "RPM diff/patch API" is developed that can be employed by yum, up2date, > apt etc. then you'll need to provide both the binary patches and the > full updated RPM's which I guess would roughly double the serverspace > needed. You'll always need the full rpm on the server in case something doesn't work with the delta. Deltas are normally about 10% of the full rpm, so that you double the needed space if you keep 10 deltas per package. I'm just preparing deltarpm v3 which has support for combining deltas. The point is that a delta is always between two exact rpm versions. If the client has left out some updates the server can combine the missing deltas to a single one (combining is quite fast as it doesn't need full rpms) and send it instead. > I think you would also need more local space, i.e. wouldn't > every RPM that comes with the distribution need to be available so that > they can be copied and patched with updates? No, deltas can work with filesystem data. Cheers, Michael. -- Michael Schroeder mls at suse.de main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} From kyrre at solution-forge.net Thu Jun 2 10:19:17 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Thu, 02 Jun 2005 12:19:17 +0200 Subject: What next? In-Reply-To: References: Message-ID: <1117707556.3355.13.camel@localhost.localdomain> ons, 01.06.2005 kl. 19.59 skrev Elliot Lee: > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > Extras 5 - what major features are you willing to put effort into? > > Best, > -- Elliot system-config-role some setup tool where you could select a machines role using profiles - examples: - Laptop (ACPI, NetworkManager etc) - Workstation (nothing special) - LAMP server (setup apache, mysql, and PHP in a sane way) - File/login-server (LDAP, NFS, Samba) Surely you can make a lot of profiles. program runs as stand-alone and in firstboot. Could probably make it really easy to setup a server etc. - reducing deployment time. Kyrre From kyrre at solution-forge.net Thu Jun 2 10:21:07 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Thu, 02 Jun 2005 12:21:07 +0200 Subject: What next? In-Reply-To: <20050602101012.GA15208@suse.de> References: <1cef3e9505060113142ede12fc@mail.gmail.com> <1117657906.31018.35.camel@cutter> <1117706246.776.26.camel@tarjei.predichem.nett> <20050602101012.GA15208@suse.de> Message-ID: <1117707667.3355.15.camel@localhost.localdomain> *snip* > I'm just preparing deltarpm v3 which has support for combining deltas. > The point is that a delta is always between two exact rpm versions. > If the client has left out some updates the server can combine the > missing deltas to a single one (combining is quite fast as it doesn't > need full rpms) and send it instead. *snip* Or the client download two deltas and combine them? Having the server do processing won't be taken ligthly by mirrors... From jakub at redhat.com Thu Jun 2 10:27:24 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 2 Jun 2005 06:27:24 -0400 Subject: What next? In-Reply-To: <20050602101012.GA15208@suse.de> References: <1cef3e9505060113142ede12fc@mail.gmail.com> <1117657906.31018.35.camel@cutter> <1117706246.776.26.camel@tarjei.predichem.nett> <20050602101012.GA15208@suse.de> Message-ID: <20050602102724.GY22349@devserv.devel.redhat.com> On Thu, Jun 02, 2005 at 12:10:12PM +0200, Michael Schroeder wrote: > > I think you would also need more local space, i.e. wouldn't > > every RPM that comes with the distribution need to be available so that > > they can be copied and patched with updates? > > No, deltas can work with filesystem data. What do you do about %config files? They can be legitimately changed on the filesystem. Also, what about prelinked executables/libraries? Do you include %config files in all delta rpms and unprelink executables/libraries to a stream before creating a rpm from that? Jakub From mls at suse.de Thu Jun 2 10:32:17 2005 From: mls at suse.de (Michael Schroeder) Date: Thu, 2 Jun 2005 12:32:17 +0200 Subject: What next? In-Reply-To: <20050602102724.GY22349@devserv.devel.redhat.com> References: <1cef3e9505060113142ede12fc@mail.gmail.com> <1117657906.31018.35.camel@cutter> <1117706246.776.26.camel@tarjei.predichem.nett> <20050602101012.GA15208@suse.de> <20050602102724.GY22349@devserv.devel.redhat.com> Message-ID: <20050602103215.GB15208@suse.de> On Thu, Jun 02, 2005 at 06:27:24AM -0400, Jakub Jelinek wrote: > What do you do about %config files? They can be legitimately changed > on the filesystem. All files that have the content verify bit off (i.e. that don't get checked by rpm -V) are not included in the delta generation. > Also, what about prelinked executables/libraries? Good point. Prelink support is indeed missing in the current implementation. It wouldn't be that hard to add, though. Cheers, Michael. -- Michael Schroeder mls at suse.de main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} From pbrobinson at gmail.com Thu Jun 2 10:36:48 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 2 Jun 2005 11:36:48 +0100 Subject: What next? In-Reply-To: <20050601224519.GC23343@srv01.cluenet.de> References: <20050601202018.GA21853@srv01.cluenet.de> <1117662072.5219.12.camel@localhost.localdomain> <20050601224519.GC23343@srv01.cluenet.de> Message-ID: <5256d0b05060203362cb76230@mail.gmail.com> > > > - a network server for Evolution (perhaps based on Directory Server?) > > > so one can actually use Evolution for time and task management at > > > home AND on the road (read: from different machines) without having > > > to run full-fledged MS Exchange (sic!) or OpenDUNNOWHATITWAS (Exchange > > > clone). > > *snip* > > > > Sounds like Hula to me - not that I've tried it myself > > When I looked for a solution a few weeks ago, I've spend some hours > of googling and reading mailing list archives, and the only thing I've > been able to come up with was > > a) use OpenGroupware! > b) use Microsoft Exchange! > c) oh yeah, I'd really like a lightweight server without all the > bloat OpenGroupware needs to just store my stuff somewhere > accessibly from remote locations > > The general consensus I found everywhere was "doesn't exist, or use > the big ones". > > I didn't stumble over Hula at all... interesting. And Hula doesn't do > contacts stuff. And that's besides calendar stuff what I'd need Evo > most for - but it does other stuff I don't need, e.g. IMAP4 server > and webmail etc. www.hula-project.org Contacts/address book is coming. The project was originally Novells Netmail product but they have to scrub the code to get any stuff out that they can't release as open source for what ever reason and its taking time but they are getting there. I think the address book code is one of the next on the list (you can see the remaining list on their site under scrub list). I think its the most promising open mail/calender/contacts product out there. Looking forward to the promised gmail esque webmail/calender interface :-) Been meaning to try and package this up as an rpm myself. Pete From kaboom at oobleck.net Thu Jun 2 11:09:43 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Thu, 2 Jun 2005 07:09:43 -0400 (EDT) Subject: What next? In-Reply-To: <5256d0b05060203362cb76230@mail.gmail.com> References: <20050601202018.GA21853@srv01.cluenet.de> <1117662072.5219.12.camel@localhost.localdomain> <20050601224519.GC23343@srv01.cluenet.de> <5256d0b05060203362cb76230@mail.gmail.com> Message-ID: On Thu, 2 Jun 2005, Peter Robinson wrote: > www.hula-project.org > > Contacts/address book is coming. The project was originally Novells > Netmail product but they have to scrub the code to get any stuff out > that they can't release as open source for what ever reason and its > taking time but they are getting there. I think the address book code > is one of the next on the list (you can see the remaining list on > their site under scrub list). I think its the most promising open > mail/calender/contacts product out there. Looking forward to the > promised gmail esque webmail/calender interface :-) > > Been meaning to try and package this up as an rpm myself. *hint hint* There's a first attempt (since abandoned, I believe) at a package of hula in the Extras CVS that you might start from Just as a word of warning: hula's a big, complex, ugly web app from a packaging perspective. It really wasn't designed with sane packaging (or sane integration period) in mind ;-) later, chris From pbrobinson at gmail.com Thu Jun 2 11:24:27 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 2 Jun 2005 12:24:27 +0100 Subject: What next? In-Reply-To: References: <20050601202018.GA21853@srv01.cluenet.de> <1117662072.5219.12.camel@localhost.localdomain> <20050601224519.GC23343@srv01.cluenet.de> <5256d0b05060203362cb76230@mail.gmail.com> Message-ID: <5256d0b050602042423f0087b@mail.gmail.com> > > Contacts/address book is coming. The project was originally Novells > > Netmail product but they have to scrub the code to get any stuff out > > that they can't release as open source for what ever reason and its > > taking time but they are getting there. I think the address book code > > is one of the next on the list (you can see the remaining list on > > their site under scrub list). I think its the most promising open > > mail/calender/contacts product out there. Looking forward to the > > promised gmail esque webmail/calender interface :-) > > > > Been meaning to try and package this up as an rpm myself. > > *hint hint* There's a first attempt (since abandoned, I believe) at a > package of hula in the Extras CVS that you might start from > > Just as a word of warning: hula's a big, complex, ugly web app from a > packaging perspective. It really wasn't designed with sane packaging (or > sane integration period) in mind ;-) I suspected as much which is why I've not got around to doing it yet :-) Pete From felipe.alfaro at gmail.com Thu Jun 2 11:31:32 2005 From: felipe.alfaro at gmail.com (Felipe Alfaro Solana) Date: Thu, 2 Jun 2005 13:31:32 +0200 Subject: What next? In-Reply-To: <20050602101012.GA15208@suse.de> References: <1cef3e9505060113142ede12fc@mail.gmail.com> <1117657906.31018.35.camel@cutter> <1117706246.776.26.camel@tarjei.predichem.nett> <20050602101012.GA15208@suse.de> Message-ID: <6f6293f1050602043132e3df19@mail.gmail.com> On 6/2/05, Michael Schroeder wrote: > You'll always need the full rpm on the server in case something doesn't > work with the delta. Deltas are normally about 10% of the full rpm, so > that you double the needed space if you keep 10 deltas per package. AFAIK, SUSE delta RPMs don?t require the presence of the full, original, binary RPM. Instead, the delta RPM can patch the needed files on the fly, directly onto the filesystem. In fact, they are not exactly deltas between complete RPM packages/files, but patch RPMs (or deltas for individual files inside an RPM package). From sundaram at redhat.com Thu Jun 2 11:39:16 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 02 Jun 2005 17:09:16 +0530 Subject: What next? In-Reply-To: <5256d0b050602042423f0087b@mail.gmail.com> References: <20050601202018.GA21853@srv01.cluenet.de> <1117662072.5219.12.camel@localhost.localdomain> <20050601224519.GC23343@srv01.cluenet.de> <5256d0b05060203362cb76230@mail.gmail.com> <5256d0b050602042423f0087b@mail.gmail.com> Message-ID: <429EEFE4.80006@redhat.com> Hi >>*hint hint* There's a first attempt (since abandoned, I believe) at a >>package of hula in the Extras CVS that you might start from >> >>Just as a word of warning: hula's a big, complex, ugly web app from a >>packaging perspective. It really wasn't designed with sane packaging (or >>sane integration period) in mind ;-) >> >> To be fair, people run into this type of problems while working with a project which has just been open sourced. Exactly the same thing has happened with the recently open sourced Fedora Directory server. I expect these kind of wrinkles to be ironed out over a few months of work http://www.0xdeadbeef.com/html/2005/06/#200506010936 regards Rahul From buildsys at redhat.com Thu Jun 2 11:41:54 2005 From: buildsys at redhat.com (Build System) Date: Thu, 2 Jun 2005 07:41:54 -0400 Subject: rawhide report: 20050602 changes Message-ID: <200506021141.j52Bfs8R028992@porkchop.devel.redhat.com> New package autoconvert Chinese HZ/GB/BIG5 encodings auto-converter New package system-config-cluster system-config-cluster is a utility which allows you to manage cluster configuration in a graphical setting. New package tog-pegasus OpenPegasus WBEM Services for Linux Removed package struts11 Updated Packages: a2ps-4.13b-47 ------------- * Thu May 05 2005 Tim Waugh 4.13b-47 - Make pdiff use diff(1) properly (bug #156916). alsa-lib-1.0.9rf-1 ------------------ * Mon May 30 2005 Martin Stransky 1.0.9rf-1 - New upstream version - moved alsacard utility to alsa-utils ant-0:1.6.2-3jpp_9fc -------------------- * Wed May 25 2005 Gary Benson 0:1.6.2-3jpp_9fc - Rearrange how BC-compiled stuff is built and installed. aspell-af-50:0.50-3 ------------------- aspell-br-50:0.50-3 ------------------- aspell-ca-50:0.50-3 ------------------- aspell-cy-50:0.50-3 ------------------- aspell-el-50:0.50-3 ------------------- aspell-fo-50:0.51-3 ------------------- aspell-ga-50:0.50-3 ------------------- aspell-gd-50:0.50-3 ------------------- aspell-gl-50:0.50-3 ------------------- aspell-hr-50:0.51-3 ------------------- aspell-id-50:0.50.1-3 --------------------- bind-24:9.3.1-4_FC4 ------------------- * Mon May 23 2005 Jason Vas Dias - 24:9.2.1-4_FC4 - Fix SDB LDAP * Mon May 16 2005 Jason Vas Dias - 24:9.2.1-4 - Fix bug 157601: give named.init a configtest function - Fix bug 156797: named.init should check SELinux booleans.local before booleans - Fix bug 154335: if no controls in named.conf, stop named with -TERM sig, not rndc - Fix bug 155848: add NOTES section to named.8 man-page with info on all Red Hat BIND quirks and SELinux DDNS / slave zone file configuration - D-BUS patches NOT applied until dhcdbd is in FC * Sun May 15 2005 Jason Vas Dias - 24:9.3.1-4_dbus - Enhancement to allow dynamic forwarder table management and - DHCP forwarder auto-configuration with D-BUS busybox-1:1.00-5 ---------------- * Wed May 11 2005 Ivana Varekova - 1.00-5 - add debug files to debug_package checkpolicy-1.23.4-1 -------------------- * Fri May 20 2005 Dan Walsh 1.23-4-1 - Update to NSA Release * Merged cleanup patch from Dan Walsh. * Thu May 19 2005 Dan Walsh 1.23-3-1 - Update to NSA Release * Added sepol_ prefix to Flask types to avoid namespace collision with libselinux. * Sat May 07 2005 Dan Walsh 1.23-2-1 - Update to NSA Release * Merged identifier fix from Joshua Brindle (Tresys). classpathx-mail-0:1.0-4jpp_2fc ------------------------------ * Wed Jun 01 2005 Gary Benson 0:1.0-4jpp_2fc - Fix location of monolithic jarfile. * Tue May 31 2005 Gary Benson 0:1.0-4jpp_1fc - Remove now-unnecessary workaround for #132524. - Upgrade to 1.0-4jpp. - Add a javamail-monolithic equivalent. * Mon May 02 2005 Jason Corley 0:1.0-4jpp - Rebuild cpufreq-utils-1:0.3-1.1.15 -------------------------- * Mon May 09 2005 Dave Jones - Update to upstream 0.3 cracklib-2.8.3-1 ---------------- * Fri May 13 2005 Nalin Dahyabhai 2.8.3-1 - update to 2.8.3 crypto-utils-2.2-6 ------------------ * Thu May 26 2005 Joe Orton 2.2-6 - certwatch: use UTC time correctly (Tomas Mraz, #158703) db4-4.3.27-4 ------------ * Tue May 17 2005 Paul Nasrat 4.3.27-4 - /usr/lib/tls/ix86 dirs (#151371) desktop-file-utils-0.10-2 ------------------------- * Thu May 12 2005 Ray Strode - 0.10-2 - Add build requires for emacs (bug #141297). eclipse-1:3.1.0_fc-0.M7.8 ------------------------- * Thu May 26 2005 Andrew Overholt 3.1.0_fc-0.M7.8 - Fix ant jar removal (gbenson). * Wed May 25 2005 Andrew Overholt 3.1.0_fc-0.M7.7 - Fix ecj symlink in /usr/share/java (rh#158734). * Sun May 22 2005 Andrew Overholt 3.1.0_fc-0.M7.4 - Remove compilation of jdt.ui jar.so on ppc. elfutils-0.108-3 ---------------- * Wed May 25 2005 Roland McGrath - 0.108-3 - more robustification * Mon May 16 2005 Roland McGrath - 0.108-2 - robustification epiphany-1.6.3-1 ---------------- * Fri May 13 2005 Christopher Aillon - 1.6.3-1 - Update to 1.6.3 esound-1:0.2.35-5 ----------------- * Wed Jun 01 2005 Bill Nottingham - 1.0.2.35-5 - readdd patch to prevent multilib conflicts ethereal-0.10.11-3 ------------------ * Mon May 30 2005 Radek Vokal 0.10.11-3 - ethereal cleanup, patch by Steve Grubb (#159107) - few more cleanups evolution-2.2.2-7 ----------------- * Thu May 26 2005 David Malcolm - 2.2.2-7 - Added Akira Tagoh's patch for calendar keypress handling (#154360) * Mon May 23 2005 David Malcolm - 2.2.2-6 - Remove static versions of libraries * Thu May 05 2005 David Malcolm - 2.2.2-5 - added evolution-2.2.2-fix-new-mail-notify.patch to CVS expect-5.43.0-2 --------------- * Tue May 31 2005 Jens Petersen - 5.43.0-2 - fix flushing of unbuffer script (Charles Sullivan, #143963) with unbuffer-child-flush-143963.patch (Don Libes) - make autoconf include parent dir in testsuite to avoid error (Robert Scheck, 150369) - separate the examples scripts patches from the rest * Mon Mar 07 2005 Jens Petersen - replace expect-5.32.2-setpgrp.patch by expect-5.43.0-cfg-setpgrp.patch to set SETPGRP_VOID correctly gcc-4.0.0-9 ----------- * Wed May 25 2005 Jakub Jelinek 4.0.0-9 - update from CVS - PRs c++/1016, c++/21686, libfortran/18495, libfortran/19014, libfortran/19016, libfortran/19106, libfortran/20074, libfortran/20436, libfortran/21075, libfortran/21108, libfortran/21354, libfortran/21376, libgcj/21637, libgcj/21703, libgcj/21736 - fix overflowed constant handling (Zdenek Dvorak, #156844, PRs middle-end/21331, tree-opt/21293) - make sure slow_pthread_self is never yes for linux targets - fix reg-stack ICE (#158407, PR target/21716) - fix ICE on fortran alternate returns (#158434) - fix ICE on fortran functions without explicit type with implicit none (#158232, PR fortran/21729) gdb-6.3.0.0-1.24 ---------------- * Wed May 18 2005 Jeff Johnston 6.3.0.0-1.24 - Bump up release number. * Wed May 18 2005 Jeff Johnston 6.3.0.0-1.23 - Bump up release number. * Wed May 18 2005 Jeff Johnston 6.3.0.0-1.22 - Specify SA_RESTART for linux-nat.c handlers and use my_waitpid which handles EINTR. gkrellm-2.2.4-5 --------------- * Tue May 17 2005 Karsten Hopp 2.2.4-5 - use Sans fonts (Ville Skytta, #157899) glibc-kernheaders-2.4-9.1.95 ---------------------------- * Mon May 23 2005 David Woodhouse 2.4-9.1.95 - Update audit.h, add CAP_AUDIT_{WRITE,CONTROL} to capability.h gphoto2-2.1.5-10 ---------------- * Wed Jun 01 2005 Bill Nottingham 2.1.5-10 - fix multilib conflict on fdi files, and their generation on x86_64 in general hdparm-5.9-3 ------------ * Wed May 18 2005 Karsten Hopp 5.9-3 - remove /etc/sysconfig/harddisks (#157673) * Tue May 10 2005 Karsten Hopp 5.9-2 - enable debuginfo iiimf-le-chinput-0.3-20 ----------------------- * Tue May 31 2005 Yu Shao -20 - fix for Bug 157619 ??? GBK pinyin and Shuang Pin input style crash iiimd iproute-2.6.11-2 ---------------- * Tue May 24 2005 Radek Vokal 2.6.11-2 - removed useless initvar patch (#150798) - new upstream source iptables-1.3.1-1 ---------------- * Wed May 11 2005 Thomas Woerner 1.3.1-1 - new version 1.3.1 iputils-20020927-23 ------------------- * Fri May 27 2005 Radek Vokal 20020927-23 - fixed un-initialized "device" (#158914) jakarta-commons-beanutils-0:1.7.0-2jpp_1fc ------------------------------------------ * Wed May 25 2005 Gary Benson - 0:1.7.0-2jpp_1fc - Upgrade to 1.7.0-2jpp. - Rearrange how BC-compiled stuff is built and installed. jakarta-commons-collections-0:3.1-1jpp_5fc ------------------------------------------ * Wed May 25 2005 Gary Benson - 0:3.1-1jpp_5fc - Rearrange how BC-compiled stuff is built and installed. jakarta-commons-digester-0:1.6-2jpp_5fc --------------------------------------- * Wed May 25 2005 Gary Benson - 0:1.6-2jpp_5fc - Rearrange how BC-compiled stuff is built and installed. jakarta-commons-el-0:1.0-3jpp_1fc --------------------------------- * Thu May 26 2005 Gary Benson - 0:1.0-3jpp_1fc - Upgrade to 1.0-3jpp. - Rearrange how BC-compiled stuff is built and installed. - Don't bundle servletapi sources (which weren't used anyway). jakarta-commons-logging-0:1.0.4-2jpp_5fc ---------------------------------------- * Wed May 25 2005 Gary Benson - 0:1.0.4-2jpp_5fc - Rearrange how BC-compiled stuff is built and installed. jakarta-commons-modeler-0:1.1-4jpp_1fc -------------------------------------- * Thu May 26 2005 Gary Benson - 0:1.1-4jpp_1fc - Upgrade to 1.1-4jpp. - Rearrange how BC-compiled stuff is built and installed. java-1.4.2-gcj-compat-0:1.4.2.0-40jpp_30rh ------------------------------------------ * Thu May 26 2005 Thomas Fitzsimmons - 0:1.4.2.0-40jpp_30rh - Add jaxp_parser_impl.jar alternative. (#158751) * Thu May 26 2005 Thomas Fitzsimmons - 0:1.4.2.0-40jpp_29rh - Separate post and postun requires lines * Thu May 26 2005 Thomas Fitzsimmons - 0:1.4.2.0-40jpp_28rh - Re-remove bouncy castle provider. jpilot-0.99.8-0.pre8.5 ---------------------- * Fri May 06 2005 Ivana Varekova 0.99.8-0.pre8.5 - fix typo (bug 157007) krb5-1.4.1-3 ------------ * Fri May 13 2005 Nalin Dahyabhai 1.4.1-3 - prevent spurious EBADF in krshd when stdin is closed by the client while the command is running (#151111) * Fri May 13 2005 Martin Stransky 1.4.1-2 - add deadlock patch, removed old patch * Fri May 06 2005 Nalin Dahyabhai 1.4.1-1 - update to 1.4.1, incorporating fixes for CAN-2005-0468 and CAN-2005-0469 - when starting the KDC or kadmind, if KRB5REALM is set via the /etc/sysconfig file for the service, pass it as an argument for the -r flag ksh-20050202-3 -------------- * Tue May 10 2005 Karsten Hopp 20050202-3 - enable debuginfo * Tue Mar 15 2005 Karsten Hopp 20050202-2 - add /usr/bin/ksh link for compatibility with pdksh scripts (#151134) libgal2-2:2.4.2-5 ----------------- * Thu May 26 2005 David Malcolm - 2:2.4.2-5 - added Akira Tagoh's patch to add boolean return value to keypress signal (#153360) libgsf-1.12.0-1 --------------- * Wed Mar 02 2005 Caolan McNamara 1.12.0-1 - bump to latest version - clean spec libidn-0.5.17-1 --------------- * Fri May 27 2005 Joe Orton 0.5.17-1 - update to 0.5.17 * Fri May 06 2005 Joe Orton 0.5.16-1 - update to 0.5.16 * Thu May 05 2005 Joe Orton 0.5.15-2 - constify data tables in pr29.c - clean up pre/post/postun requires libselinux-1.23.11-1 -------------------- * Fri May 20 2005 Dan Walsh 1.23.11-1 - Update from NSA * Merged avcstat and selinux man page from Dan Walsh. * Changed security_load_booleans to process booleans.local even if booleans file doesn't exist. * Tue Apr 26 2005 Dan Walsh 1.23.10-3 - Fix avcstat to clear totals libsepol-1.5.10-1 ----------------- * Tue May 17 2005 Dan Walsh 1.5.10-1 - Fix reset booleans warning message - Upgrade to latest from NSA * License changed to LGPL v2.1, see COPYING. libtool-1.5.18-2 ---------------- * Tue May 17 2005 Alexandre Oliva 1.5.18-2 - Update patch file. * Tue May 17 2005 Alexandre Oliva 1.5.18-1 - 1.5.18. Removed .multilib2 suffix. lm_sensors-2.9.1-3 ------------------ * Mon May 23 2005 Phil Knirsch 2.9.1-3 - Update to lm_sensors-2.9.1 - Fixed wrong/missing location variables for make user - Fixed missing check for /etc/modprobe.conf in sensors-detect (#139245) m2crypto-0.13-3 --------------- * Tue May 31 2005 Miloslav Trmac - 0.13-3 - Fix invalid Python version comparisons in M2Crypto.httpslib (#156979) - Don't ship obsolete xmlrpclib.py.patch - Clean up the build process a bit man-1.5p-6 ---------- * Tue May 17 2005 Ivana Varekova 1.5p-6 - change patch 18 (less hard solution) and patch 13 (don't change exit number in one case) * Wed Apr 13 2005 Ivana Varekova 1.5p-5 - fix bug 146849 - makewhatis from cron produce error message "zcat: stdout: Broken pipe" (patch 18) - fix makewhatis problem with sections (patch 19) - delete strips * Tue Mar 29 2005 Ivana Varekova 1.5p-4 - fix bug 140732 in man pages and the rest of bug 140207 change in man-pages again (patch 17) man-pages-ja-20050515-1 ----------------------- * Mon May 16 2005 Akira TAGOH - 20050515-1 - updates to 20050515. mod_perl-2.0.0-3 ---------------- * Fri May 20 2005 Warren Togami 2.0.0-3 - dep changes (#114651 jpo and ville) * Fri May 20 2005 Joe Orton 2.0.0-1 - update to 2.0.0 final mrtg-2.12.1-2 ------------- * Wed May 25 2005 Miloslav Trmac - 2.12.1-2 - Remove included old version of PodParser (#158735) * Tue May 17 2005 Miloslav Trmac - 2.12.1-1 - Update to mrtg-2.12.1 - Remove unnecessary BuildRequires, Requires - Don't link rateup to libpng and libz mx4j-1:2.1.0-1jpp_9fc --------------------- * Fri May 27 2005 Gary Benson 0:2.1.0-1jpp_9fc - Rearrange how BC-compiled stuff is built and installed. - Add missing epochs to dependencies. * Mon May 23 2005 Gary Benson 0:2.1.0-1jpp_8fc - Add alpha to the list of build architectures (#157522). - Use absolute paths for rebuild-gcj-db. net-snmp-5.2.1-13 ----------------- * Tue May 31 2005 Radek Vokal - 5.2.1-13 - CAN-2005-1740 net-snmp insecure temporary file usage (#158770) - patch from suse.de netpbm-10.27-4 -------------- * Tue May 31 2005 Jindrich Novy 10.27-4 - fix segfault in pnmcolormap what makes latex2html/ppmquant unusable (#158665, #139111) openldap-2.2.26-1 ----------------- * Thu May 19 2005 Nalin Dahyabhai 2.2.26-1 - run slaptest with the -u flag if no id2entry db files are found, because you can't check for read-write access to a non-existent database (#156787) - add /etc/openldap/cacerts, which authconfig sets as the TLS_CACERTDIR path in /etc/openldap/ldap.conf now - use a temporary wrapper script to launch slapd, in case we have arguments with embedded whitespace (#158111) * Wed May 04 2005 Nalin Dahyabhai - update to 2.2.26 (stable 20050429) - enable the lmpasswd scheme - print a warning if slaptest fails, slaptest -u succeeds, and one of the directories listed as the storage location for a given suffix in slapd.conf contains a readable file named __db.001 (#118678) * Tue Apr 26 2005 Nalin Dahyabhai 2.2.25-1 - update to 2.2.25 (release) openobex-1.0.1-4 ---------------- * Mon May 02 2005 Harald Hoyer 1.0.1-4 - added `OBEX_ServerAccept' to the exported symbols (bug rh#146353) openswan-2.3.1-3 ---------------- * Thu May 12 2005 Harald Hoyer - 2.3.1-3 - added openswan-2.3.1-nat_t_aggr.patch - added openswan-2.3.1-iproute2.patch - added openswan-2.3.1-cisco.patch - NAT-T/XAUTH/AGGR-MODE is now possible with a Cisco VPN 3000 pam-0.79-9 ---------- * Fri May 20 2005 Tomas Mraz 0.79-9 - update the pam audit patch to support newest audit library, audit also pam_setcred calls (Steve Grubb) - don't use the audit_fd as global static variable - don't unset the XAUTHORITY when target user is root * Mon May 02 2005 Tomas Mraz 0.79-8 - pam_console: support loading .perms files in the console.perms.d (#156069) * Tue Apr 26 2005 Tomas Mraz 0.79-7 - pam_xauth: unset the XAUTHORITY variable on error, fix potential memory leaks - modify path to IDE floppy devices in console.perms (#155560) policycoreutils-1.23.11-3 ------------------------- * Sat May 28 2005 Dan Walsh 1.23.11-3 - Add Ivan's patch for user role changes in genhomedircon * Thu May 26 2005 Dan Walsh 1.23.11-2 - Fix warning message on reload of booleans * Fri May 20 2005 Dan Walsh 1.23.11-1 - Update to match NSA * Merged fixfiles and newrole patch from Dan Walsh. * Merged audit2why man page from Dan Walsh. postfix-2:2.2.3-1 ----------------- * Thu May 12 2005 Thomas Woerner 2:2.2.3-1 - new version 2.2.3 - compiling all binaries PIE, dropped old pie patch privoxy-3.0.3-8 --------------- * Tue May 10 2005 Karsten Hopp 3.0.3-8 - enable debuginfo pvm-3.4.5-5 ----------- * Tue May 31 2005 Jason Vas Dias 3.4.5-4 - fix bug 158303: x86_64 build needs -fPIC - fix bug 155785: PVM_ARCH should be LINUX on i386, not LINUXI386 add LINUXPPC64 arch to pvmgetarch rdist-1:6.1.5-41 ---------------- * Wed May 04 2005 Phil Knirsch 6.1.5-41 - Fixed incorrect use of statfs return values (#147481) regexp-0:1.3-2jpp_1fc --------------------- * Thu May 26 2005 Gary Benson 0:1.3-2jpp_1fc - Upgrade to 1.3-2jpp. - Rearrange how BC-compiled stuff is built and installed. * Mon May 23 2005 Gary Benson 0:1.3-1jpp_6fc - Add alpha to the list of build architectures (#157522). - Use absolute paths for rebuild-gcj-db. rusers-0.17-44 -------------- * Wed May 04 2005 Phil Knirsch 0.17-44 - Fixed rup stack problem (#154396) sash-3.7-7 ---------- * Tue May 10 2005 Karsten Hopp 3.7-7 - enable debuginfo selinux-policy-strict-1.23.17-3 ------------------------------- * Sat May 28 2005 Dan Walsh 1.23.17-3 - Update policy, to remove crond_log_t - Fix selinuxenabled check * Thu May 26 2005 Dan Walsh 1.23.17-2 - Fixes to cups/ptal - Change ifconfig scripts back to etc_t * Wed May 25 2005 Dan Walsh 1.23.17-1 - Update from NSA * Merged minor fixes by Petre Rodan to the daemontools, dante, gpg, kerberos, and ucspi-tcp policies. * Merged minor fixes by Russell Coker to the bluetooth, crond, initrc, postfix, and udev policies. Modifies constraints so that newaliases can be run. Modifies types.fc so that objects in lost+found directories will not be relabled. * Modified fc rules for nvidia. * Added Chad Sellers policy for polyinstantiation support, which creates the polydir, polyparent, and polymember attributes. Also added the support_polyinstantiation tunable. * Merged patch from Dan Walsh. Includes mount_point attribute, read_font macros and some other policy fixes from Ivan Gyurdiev. Adds privkmsg and secadmfile attributes and ddcprobe policy. Removes the use_syslogng boolean. Many other minor fixes. selinux-policy-targeted-1.23.17-3 --------------------------------- * Sat May 28 2005 Dan Walsh 1.23.17-3 - Update policy, to remove crond_log_t - Fix selinuxenabled check * Thu May 26 2005 Dan Walsh 1.23.17-2 - Fixes to cups/ptal - Change ifconfig scripts back to etc_t * Wed May 25 2005 Dan Walsh 1.23.17-1 - Update from NSA * Merged minor fixes by Petre Rodan to the daemontools, dante, gpg, kerberos, and ucspi-tcp policies. * Merged minor fixes by Russell Coker to the bluetooth, crond, initrc, postfix, and udev policies. Modifies constraints so that newaliases can be run. Modifies types.fc so that objects in lost+found directories will not be relabled. * Modified fc rules for nvidia. * Added Chad Sellers policy for polyinstantiation support, which creates the polydir, polyparent, and polymember attributes. Also added the support_polyinstantiation tunable. * Merged patch from Dan Walsh. Includes mount_point attribute, read_font macros and some other policy fixes from Ivan Gyurdiev. Adds privkmsg and secadmfile attributes and ddcprobe policy. Removes the use_syslogng boolean. Many other minor fixes. slocate-2.7-23 -------------- * Sun May 01 2005 Miloslav Trmac - 2.7-23 - Remove "nodev" filesystems from PRUNEFS struts-0:1.2.4-1jpp_1fc ----------------------- * Fri May 27 2005 Gary Benson - 0:1.2.4-1jpp_1fc - Build into Fedora. * Fri Nov 26 2004 Fernando Nasser - 0:1.2.4-1jpp - Upgrade to 1.2.4 * Sat Sep 04 2004 Fernando Nasser - 0:1.1-3jpp - Rebuilt with Ant 1.6.2 subversion-1.2.0-2 ------------------ * Wed May 25 2005 Joe Orton 1.2.0-2 - disable java on all but x86, x86_64, ppc (#158719) * Tue May 24 2005 Joe Orton 1.2.0-1 - update to 1.2.0; add ruby subpackage synaptics-0:0.14.2-1 -------------------- * Tue May 17 2005 Paul Nasrat - 0:0.14.2-1 - Update to 0.14.2 * Mon May 16 2005 Paul Nasrat - 0:0.14.1-1 - Update to 0.14.1 sysstat-5.0.5-10.fc ------------------- * Tue May 10 2005 Ivana Varekova 5.0.5-10.fc - add debug files to debug_package system-config-kickstart-2.5.23-1 -------------------------------- * Tue May 31 2005 Chris Lumens 2.5.23-1 - Use random module instead of whrandom (#159115). system-config-netboot-0.1.16-1 ------------------------------ * Thu May 26 2005 Jason Vas Dias 0.1.16-1 - fix bugs 144240, 148022, 149000, 153047, 154982 system-config-soundcard-1.2.12-1 -------------------------------- * Fri May 27 2005 Martin Stransky 1.2.12 - fix order of cards - fix detection/setting of default card tomcat5-0:5.0.30-6jpp_1fc ------------------------- * Tue May 31 2005 Gary Benson 0:5.0.30-6jpp_1fc - Rearrange how BC-compiled stuff is built and installed. * Fri May 27 2005 Gary Benson - Upgrade to 5.0.30-6jpp. * Mon May 23 2005 Gary Benson - Add alpha to the list of build architectures (#157522). unzip-5.51-11 ------------- * Mon May 09 2005 Ivana Varekova 5.51-11 - fix bug 156959 ??? invalid file mode on created files vsftpd-2.0.3-2 -------------- * Fri May 27 2005 Radek Vokal 2.0.3-2 - timezone fix, patch from suse.de (#158779) xalan-j2-0:2.6.0-2jpp_3fc ------------------------- * Fri May 27 2005 Gary Benson 0:2.6.0-2jpp_3fc - Remove now-unnecessary workaround for #130162. - Rearrange how BC-compiled stuff is built and installed. * Tue May 24 2005 Gary Benson 0:2.6.0-2jpp_2fc - Add DOM3 stubs to classes that need them (#152255). - BC-compile the main jarfile. * Fri Apr 01 2005 Gary Benson - Add NOTICE file as per Apache License version 2.0. xen-2-20050530 -------------- * Mon May 30 2005 Rik van Riel 2-20050530 - create /var/lib/xen/xen-db/migrate directory so "xm save" works (#158895) xerces-j2-0:2.6.2-4jpp_7fc -------------------------- * Thu May 26 2005 Gary Benson 0:2.6.2-4jpp_7fc - Rearrange how BC-compiled stuff is built and installed. * Mon May 23 2005 Gary Benson 0:2.6.2-4jpp_6fc - Add alpha to the list of build architectures (#157522). - Use absolute paths for rebuild-gcj-db. xinitrc-4.0.19-1 ---------------- * Tue May 24 2005 Mike A. Harris 4.0.19-1 - [xinitrc-common] source /etc/profile.d/lang.sh if it exists to try and fix bug (#138681) - Remove unnecessary dependancy on /usr/X11R6/bin/RunWM from spec file - Do not install RunWM symlinks for window managers we have not shipped for several years. xml-commons-0:1.0-0.b2.7jpp_1fc ------------------------------- * Thu May 26 2005 Gary Benson - 0:1.0-0.b2.7jpp_1fc - Upgrade to 1.0-0.b2.7jpp. - Remove now-unnecessary workaround for #130162. - Rearrange how BC-compiled stuff is built and installed. * Mon May 23 2005 Gary Benson - 0:1.0-0.b2.6jpp_13fc - Add alpha to the list of build architectures (#157522). - Use absolute paths for rebuild-gcj-db. xorg-x11-6.8.2-36 ----------------- * Mon May 30 2005 Mike A. Harris 6.8.2-36 - Added xorg-x11-6.8.2-ia64-elfloader-cache-flush.patch to fix cache flush issue on ia64 systems (#153103) * Wed May 25 2005 Mike A. Harris 6.8.2-35 - Remove /usr/X11R6/lib/X11/xinit symlink on non with_Xserver builds to prevent rpm complaining about unpackaged symlinks on s390 et al. now that bug (#108778) is fixed. * Mon May 23 2005 Mike A. Harris - Made FC4 patches enabled for FC3, which will be merged into the FC-3 branch, and released as an FC3-testing update soon. xterm-200-7 ----------- * Mon May 02 2005 Mike A. Harris 200-7 - Updated xterm-resources-redhat.patch to enable xterm utf8 resource by default, as our default OS environment is UTF-8, for bug (#138681) From pp at ee.oulu.fi Thu Jun 2 11:46:14 2005 From: pp at ee.oulu.fi (Pekka Pietikainen) Date: Thu, 2 Jun 2005 14:46:14 +0300 Subject: What next? In-Reply-To: <1117655080.6271.52.camel@laptopd505.fenrus.org> References: <1117655080.6271.52.camel@laptopd505.fenrus.org> Message-ID: <20050602114614.GA13025@ee.oulu.fi> On Wed, Jun 01, 2005 at 09:44:40PM +0200, Arjan van de Ven wrote: > On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote: > > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > > Extras 5 - what major features are you willing to put effort into? > > I'd like to see: > * faster boot and shutdown And suspend/resume... ACPI is unfortunately quite laptop-specific in how it works. Currently you need quite a bit of script-tweaking to get it to work. hibernate (from swsusp2) eases things quite a bit, even if you don't use swsusp2. -- Pekka Pietikainen From thomas at apestaart.org Thu Jun 2 00:51:34 2005 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Thu, 02 Jun 2005 02:51:34 +0200 Subject: What next? In-Reply-To: References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <1117662394.31018.80.camel@cutter> Message-ID: <1117673495.29707.4.camel@otto.amantes> > 99.9% of users seem to disagree with you, judging by how often "Linux > should use appfolders like Macs do" is heard on various forums and mailing > lists. Probably because seem to think that the appfolder way is the thing that would automatically solve people's install problems on Linux, but ... > MacOS X packaging works reliably for end users, 100% of the time, and > from that perspective it doesn't matter how many features it has or > doesn't have, it's better than yum/rpm/any Linux packaging system. ... in reality the problem is not because of rpm/... vs. appfolders, the "problem" is that there is only ONE MacOSX and there are several linux distro's. People need to learn to treat, say, Fedora + extras as ONE distro, and only install from there, and their problem is solved. If they don't, then appfolders won't help them either - they will end up installing appfolders that conflict with their distro and were actually intended for another distro. In short, what people who say "linux should use appfolders like ..." mean is "please solve my install problems" which in practice would translate to "please have only 1 linux". Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> Please put me somewhere near the sea With one carrion angel waiting for me who'll be holding my heart in it's hand But most of all I'd like to go with a friend <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From thomas at apestaart.org Thu Jun 2 00:55:59 2005 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Thu, 02 Jun 2005 02:55:59 +0200 Subject: What next? In-Reply-To: References: <1117657892.31018.33.camel@cutter> <20050601225823.GA772000@hiwaay.net> Message-ID: <1117673759.29707.8.camel@otto.amantes> Hi, > > Once upon a time, seth vidal said: > > > What about stretching out the dev cycle from 3months dev + 3 months of > > > testing to something more like 6 months of dev + 3 months of testing. > > > > How about deciding what the major goals of the next release should be > > (within reason of course), estimating about how long it should take to > > meet those goals, and then add in whatever else seems reasonable in the > > given time frame? > > Because the decision was explicitly made when the Fedora project started > to do releases at regular intervals rather than based on feature-driven > milestones. This is the model Gnome has used with a good bit of success. I disagree with the request for stretching, and agree with the comparison with GNOME's model. Look at how Sarge went down. In contrast, I'd like to propose another idea - keep FC (x-2) alive until a month after FC (x) comes out. This would make people feel they don't need to upgrade every six months, but can do it every year, if they feel it is a real issue. I find it a little silly how currently FC (x - 2) gets eol'd around the time FC (x) is starting to churn out test releases. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> Don't shut your eyes just yet Don't even open your mouth just yet Because there's things you've got to see There's things you won't believe of me <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From mls at suse.de Thu Jun 2 12:13:05 2005 From: mls at suse.de (Michael Schroeder) Date: Thu, 2 Jun 2005 14:13:05 +0200 Subject: What next? In-Reply-To: <6f6293f1050602043132e3df19@mail.gmail.com> References: <1cef3e9505060113142ede12fc@mail.gmail.com> <1117657906.31018.35.camel@cutter> <1117706246.776.26.camel@tarjei.predichem.nett> <20050602101012.GA15208@suse.de> <6f6293f1050602043132e3df19@mail.gmail.com> Message-ID: <20050602121304.GA11013@suse.de> On Thu, Jun 02, 2005 at 01:31:32PM +0200, Felipe Alfaro Solana wrote: > On 6/2/05, Michael Schroeder wrote: > > You'll always need the full rpm on the server in case something doesn't > > work with the delta. Deltas are normally about 10% of the full rpm, so > > that you double the needed space if you keep 10 deltas per package. > > AFAIK, SUSE delta RPMs don?t require the presence of the full, > original, binary RPM. Are you talking about the client or the server side? The server should always have the full rpm in case the client doesn't understand deltas or the deltas don't match. The client can either work with filesystem data or with the old rpm. > Instead, the delta RPM can patch the needed files on the fly, directly > onto the filesystem. No, it doesn't do this. Applydeltarpm creates an rpm that is bitwise identical to the original. That's the beauty of it, you can still verify the rpm signature and so on. Cheers, Michael. -- Michael Schroeder mls at suse.de main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} From jspaleta at gmail.com Thu Jun 2 12:18:36 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 2 Jun 2005 08:18:36 -0400 Subject: Packaging idea (Re: What next?) In-Reply-To: References: <604aa791050601162840b05c06@mail.gmail.com> <604aa79105060120106eef01ae@mail.gmail.com> <1117686443.2702.9.camel@cutter> <604aa7910506012141650fbecf@mail.gmail.com> Message-ID: <604aa7910506020518108e3036@mail.gmail.com> On 6/2/05, Konstantin Ryabitsev wrote: > 1. Don't bother and ship tarballs with a #!/bin/sh installer. Have > some sort of an asinine custom updating mechanism, or none at all. > 2. Create a long list for user to choose from: > * download this if you are running Suse 8 > * download this if you are running Suse 9 > * download this if you are running Fedora Core 2 > * download this if you are running Fedora Core 3 > * ... > ...which they rarely do, since they think it confuses users, So instead... you'd have every user download one fab that contained ALL distro version specific packages? So instead of downloading 10 megs... i have to download 50 megs.. so i can have the suse and the other fedora payloads shoved over the wire never to be used... pointless. I can't wait to see openoffice.org's single upstream fap.. yippie for T3 connections! They still need to create the distro specific repos for faps to work! How about we focus on that first.. how about we get package venders to start using repositories at all and providing .repo files at all. > because some users only have a vague idea what distribution/version > they are running. If the vendor ships kernel modules, then this list > grows exponentially (see NVidia download page for examples). No > updating mechanism available. kernel modules.. are special.. dkms... hopefully in extras soon. Can we stick to ONE example please? > 3. Create one RPM that statically links most things, and tries to work > on anything by having horrendous staircases of %if-%endif, and by > installing everything in /usr/local and hoping things still work. No > updating mechanisms available. And I dont think proprietary vendors are going to move away from this at all. The could be using .repo definitiosn right now ... they aren't. -jef From paul at city-fan.org Thu Jun 2 12:24:46 2005 From: paul at city-fan.org (Paul Howarth) Date: Thu, 02 Jun 2005 13:24:46 +0100 Subject: Packaging idea (Re: What next?) In-Reply-To: <604aa7910506020518108e3036@mail.gmail.com> References: <604aa791050601162840b05c06@mail.gmail.com> <604aa79105060120106eef01ae@mail.gmail.com> <1117686443.2702.9.camel@cutter> <604aa7910506012141650fbecf@mail.gmail.com> <604aa7910506020518108e3036@mail.gmail.com> Message-ID: <429EFA8E.40904@city-fan.org> Jeff Spaleta wrote: > kernel modules.. are special.. dkms... hopefully in extras soon. It's already in extras. Paul. From fedora at leemhuis.info Thu Jun 2 12:45:26 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 02 Jun 2005 14:45:26 +0200 Subject: What next? In-Reply-To: <1117673759.29707.8.camel@otto.amantes> References: <1117657892.31018.33.camel@cutter> <20050601225823.GA772000@hiwaay.net> <1117673759.29707.8.camel@otto.amantes> Message-ID: <1117716326.2227.73.camel@thl.ct.heise.de> Am Donnerstag, den 02.06.2005, 02:55 +0200 schrieb Thomas Vander Stichele: > > > Once upon a time, seth vidal said: > > > > What about stretching out the dev cycle from 3months dev + 3 months of > > > > testing to something more like 6 months of dev + 3 months of testing. > > > > > > How about deciding what the major goals of the next release should be > > > (within reason of course), estimating about how long it should take to > > > meet those goals, and then add in whatever else seems reasonable in the > > > given time frame? > > > > Because the decision was explicitly made when the Fedora project started > > to do releases at regular intervals rather than based on feature-driven > > milestones. This is the model Gnome has used with a good bit of success. > > I disagree with the request for stretching, and agree with the > comparison with GNOME's model. Look at how Sarge went down. > > In contrast, I'd like to propose another idea - keep FC (x-2) alive > until a month after FC (x) comes out. This would make people feel they > don't need to upgrade every six months, but can do it every year, if > they feel it is a real issue. I find it a little silly how currently FC > (x - 2) gets eol'd around the time FC (x) is starting to churn out test > releases. ++ If fedora-legacy [cw]ould provide updates at the usual place for fedora-core updates this might not me needed. From ph18 at cornell.edu Thu Jun 2 12:46:57 2005 From: ph18 at cornell.edu (Paul A. Houle) Date: Thu, 02 Jun 2005 08:46:57 -0400 Subject: What next? In-Reply-To: References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <1117662394.31018.80.camel@cutter> Message-ID: On Wed, 01 Jun 2005 23:15:54 +0100, Mike Hearn wrote: > On Wed, 01 Jun 2005 17:46:33 -0400, seth vidal wrote: >> > BTW., how does osx do installs (just bringing up the meta-file >> > installer thingy again. Feel free not to answer)? >> >> their package system, umm, err, sucks. > > 99.9% of users seem to disagree with you, judging by how often "Linux > should use appfolders like Macs do" is heard on various forums and > mailing > lists. > > MacOS X packaging works reliably for end users, 100% of the time, and > from that perspective it doesn't matter how many features it has or > doesn't have, it's better than yum/rpm/any Linux packaging system. > This is something I've thought about: how much would the shell slow down if we had a very long $PATH, so that we can give applications independent bin directories? I love my Mac Mini but I find the 'Applications' item in the finder to be a painful way to find and run applications: I find myself using the dock very little, and I greatly prefer the 'Start' button on Windows and the imitations thereof under Unix. A downside to giving each app a directory is that it's harder to use partitions to isolate different kind of things, an art that I've been learning over time (and particular inspired by the Solaris shop I work with that uses something much like LVM, allocate a minimal amount of space for each partition, leave a large free pool, and grow the partitions online over tine) From skvidal at phy.duke.edu Thu Jun 2 12:58:34 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 02 Jun 2005 08:58:34 -0400 Subject: Packaging idea (Re: What next?) In-Reply-To: References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> Message-ID: <1117717114.2702.33.camel@cutter> On Thu, 2005-06-02 at 07:30 +0100, Mike Hearn wrote: > On Wed, 01 Jun 2005 23:01:14 -0400, Konstantin Ryabitsev wrote: > > Having a super-package like a .fap or a .fab would allow vendors to > > package things for multiple distributions by simply providing multiple > > .repo files, with yum receiving the appropriate one. > > Well, distros other than Fedora don't use yum. umm. they don't? CentOS Yellowdog Linux Tao Linux Whitebox -sv From ph18 at cornell.edu Thu Jun 2 12:58:53 2005 From: ph18 at cornell.edu (Paul A. Houle) Date: Thu, 02 Jun 2005 08:58:53 -0400 Subject: What next? In-Reply-To: <20050602032426.GA3626@imp.flyn.org> References: <20050602032426.GA3626@imp.flyn.org> Message-ID: On Wed, 1 Jun 2005 22:24:26 -0500, W. Michael Petullo wrote: > > - Bugzilla #158657 Build totem's Mozilla plugin > - Bugzilla #127537 Free software applet viewer plugin > - Free software flash viewer? > I hate to say it, but intellectual property restrictions make the multimedia software shipped with Fedora a joke, which I end up scrapping and replacing with stuff that plays media I get off the street. Ogg is great, for instance, and I rip CDs with ogg, but if I want to listen to 99% of the audio streams out there, I need mp3, and that's a matter of trashing the multimedia stuff that comes with Fedora and replacing it. My flash mp3 player doesn't play ogg, and I'd rather install some encoder software of questionably status than shell out another $200 for one that does. I know you can't really do anything about it, but this underlying problem makes improvements to multimedia players on Fedora like rearraigning the deck chairs on the titanic. From mattdm at mattdm.org Thu Jun 2 13:00:02 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 2 Jun 2005 09:00:02 -0400 Subject: What next? In-Reply-To: <1117673759.29707.8.camel@otto.amantes> References: <1117657892.31018.33.camel@cutter> <20050601225823.GA772000@hiwaay.net> <1117673759.29707.8.camel@otto.amantes> Message-ID: <20050602130002.GA14615@jadzia.bu.edu> On Thu, Jun 02, 2005 at 02:55:59AM +0200, Thomas Vander Stichele wrote: > I disagree with the request for stretching, and agree with the > comparison with GNOME's model. Look at how Sarge went down. Seth's not proposing an indefinite "stretching". Just a longer expected timeframe -- still *very* short. > In contrast, I'd like to propose another idea - keep FC (x-2) alive > until a month after FC (x) comes out. This would make people feel they This proposal is approximately the same timeframe per release, except it requires Fedora developers to support more releases at once. > don't need to upgrade every six months, but can do it every year, if > they feel it is a real issue. I find it a little silly how currently FC > (x - 2) gets eol'd around the time FC (x) is starting to churn out test > releases. There's a reason for that -- it lets the developers focus on the new instead of the much less interesting and exciting drudgery of maintaining the old releases. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 76 degrees Fahrenheit. From mattdm at mattdm.org Thu Jun 2 13:00:30 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 2 Jun 2005 09:00:30 -0400 Subject: Packaging idea (Re: What next?) In-Reply-To: <1117717114.2702.33.camel@cutter> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <1117717114.2702.33.camel@cutter> Message-ID: <20050602130030.GB14615@jadzia.bu.edu> On Thu, Jun 02, 2005 at 08:58:34AM -0400, seth vidal wrote: > > > Having a super-package like a .fap or a .fab would allow vendors to > > > package things for multiple distributions by simply providing multiple > > > .repo files, with yum receiving the appropriate one. > > Well, distros other than Fedora don't use yum. > umm. they don't? > CentOS > Yellowdog Linux > Tao Linux > Whitebox BU Linux. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 76 degrees Fahrenheit. From sundaram at redhat.com Thu Jun 2 13:02:42 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 02 Jun 2005 18:32:42 +0530 Subject: What next? In-Reply-To: References: <20050602032426.GA3626@imp.flyn.org> Message-ID: <429F0372.8060401@redhat.com> Hi > > > Ogg is great, for instance, and I rip CDs with ogg, but if I > want to listen to 99% of the audio streams out there, I need mp3, > and that's a matter of trashing the multimedia stuff that comes with > Fedora and replacing it. My flash mp3 player doesn't play ogg, and > I'd rather install some encoder software of questionably status than > shell out another $200 for one that does. You can use Real Player or relocate into a region that doesnt support software patents :-) regards Rahul From skvidal at phy.duke.edu Thu Jun 2 13:05:41 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 02 Jun 2005 09:05:41 -0400 Subject: What next? In-Reply-To: References: <20050602032426.GA3626@imp.flyn.org> Message-ID: <1117717541.2702.36.camel@cutter> > Ogg is great, for instance, and I rip CDs with ogg, but if I want to > listen to 99% of the audio streams out there, I need mp3, and that's a > matter of trashing the multimedia stuff that comes with Fedora and > replacing it. Trashing? No. It's been my experience that all that it takes is installing on gstreamer plugin from livna and one set of libraries for it. then it's done. what do you have to trash? > I know you can't really do anything about it, but this underlying > problem makes improvements to multimedia players on Fedora like > rearraigning the deck chairs on the titanic. > not really. As long as they allow simple plugins it works nicely, I've found. -sv From jspaleta at gmail.com Thu Jun 2 13:48:33 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 2 Jun 2005 09:48:33 -0400 Subject: What next? In-Reply-To: References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> Message-ID: <604aa791050602064843824513@mail.gmail.com> On 6/2/05, Mike Hearn wrote: > Word on the street is that it's traditional for operating systems to ship > with a widget toolkit and lots of other things too. So basically what you are saying is... you believe that an operating system.. like Fedora Core.. should include ONE widget toolkit and then demand all applications use that ONE widget toolkit? Please... please go build a linux distro that is toolkit pure. And even if you do, neither gtk or qt are going to disappear.. you will still have vendors creating apps in both that your precious software management system will have to deal with as an addon toolkit. But hey.. prove me wrong. Build the distro that is qt pure or gtk pure... and watch how much fun it is to drag in either toolkit in with every application you install with your cool include the kitchen-sink application installation process. > Mac apps usually have > few (if any) dependencies because they depend on the OS itself. As long as we aren't talking about any application that tries to be cross-platform sure... but then of course you are talking about a distinctly different pre-condition than what exists for any linux distributor. > By saying > "This app requires MacOS X 10.3 or higher" apps get a massive chunk of > functionality for free, that would on Linux require about 70 dependencies > in order to express. Because the collection of pieces that make up a linux distribution is far more organic process. Fedora as a distributor of individual project components can not dictate overall structure in the same way that Apple can do with their operating system. You can't make a linux distribution be a mockery of what macosx is... simply because of the way the development is structured. > > a lack of update notification. Oh yeah.. thats absolutely wonderful. > > That's why Gaim has an auto-update plugin that will pop up a message when > there is an update. i wasnt talking about 'gaim' the application i was talking about a native macosx application that uses libgaim as a backend and uses apples gorgeously braindead application installer method. You know.. native macosx toolkit and all that jazz. since gaim itself requires gtk, a toolkit that apple doesnt provide as part of the OS.. to get gaim installed you either compile it.. or most likely fink it. And we aren't talking about applications like that. > In fact, given that the little Fedora/Red Hat tray thing has *never* > actually been able to stick in my session for more than about a week, I'm > not sure why you think Fedora has user-friendly auto update either. > Remembering to run a magic command every few weeks isn't user friendly. I didn't say it was friendly. I said it existed. Evolving the process we have now to make it user-friendly doesn't require stripping out the package management system we have and starting over with mac osx's concept. You are of course, free to experiment with doing that... by building your own rpm-less or dpkg-less linux distro. I'd absolutely LOVE to see someone, create a toy distro that re-implements apple's application installer as a proof-of-concept inside the linux landscape.. sanely dealing with all the fun issues like competing toolkits that linux distributors have to deal with. I've already related in this list how in my most unexpert opinion an in-distro application that mimics the gnome menu structure could be use as an intuitive way to interact with configured repository collections as an install and removal tool. > No, Apples target audience are not UNIX heads using lots of trivially > "ported" software so nobody in their target audience uses fink. Apps that > are actually designed and built for the Mac as opposed to simply being > compilable on it never have to be compiled from the source. Ever. Right with one quick comment you summarily dismiss any application that uses gtk or qt as being outside the boundary of discussion, leaving precious few comparable applications. You need to face reality. The landscape in which a linux distributor works is vastly different than the landscape Apple creates.This is exactly what you get when you compare Apples to Linuxes. Apple's development model is starkly different than what ANY Linux distributor is going to be able to do....especially a Linux distributor that is attempting to work with upstream component projects as closely as possible. Top down design versus diverse/competitive component development. If a Linux distributor wants to fork upstream projects into a mockery of mac osx.. more power to them. But Fedora isn't that distributor. -jef From mail.sw.rh.rhl.devel at spam.fi.basen.net Thu Jun 2 14:23:27 2005 From: mail.sw.rh.rhl.devel at spam.fi.basen.net (Kaj J. Niemi) Date: Thu, 2 Jun 2005 17:23:27 +0300 (EEST) Subject: What next? References: <429E362E.9060701@poolshark.org> <20050601233143.0EE352F41E2@localhost.localdomain> <429E4BF1.3040709@silverorange.com> Message-ID: <20050602142327.961E82F41DD@localhost.localdomain> > After watching the video of the talks from Guadec, you can see that this > is a big problem. Almost every talk started off with 5 or 10 minutes of > fiddling to get the video-to-projector working. In some cases, the > presentation went on with partially broken displays. Of course, if we > can't do, neither can John Q. PowerPoint. In my experience, having seen a lot of powerpoint presentations in both IT and telco environments Windows 2000/XP support almost any decent projector very well and autoconfigure themselves correctly as well. Most issues with projectors and Windows relate to people being unsure how to switch displays (what function key was it again?) or not being patient enough while waiting for the projector to scan its inputs and figuring out how to display it. Not having watched the Guadec videos I can't of course say if the display issues were with people using Windows or Linux :-) // kaj From liste-p.alain at wanadoo.fr Thu Jun 2 14:30:34 2005 From: liste-p.alain at wanadoo.fr (Aph) Date: Thu, 2 Jun 2005 16:30:34 +0200 Subject: What next? In-Reply-To: References: Message-ID: <200506021630.48520@carola.nyarlathotep> Le Mercredi 1 Juin 2005 19:59, Elliot Lee a ?crit?: > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > Extras 5 - what major features are you willing to put effort into? A gnome navigator by defaut : firefox is not a good choice : it's in english only and many localisation don't work. Galeon or Epiphany are better choice for remplace Mozilla by defaut. -- je sais pas di il y a quelqu'un sur internet ? 1h48 mais j'aimerais bien parler! bisous -+- poisson des iles In: Guide du linuxien pervers - "Bavardage..." -+- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at phy.duke.edu Thu Jun 2 14:33:33 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 02 Jun 2005 10:33:33 -0400 Subject: What next? In-Reply-To: <1117689924.2227.24.camel@thl.ct.heise.de> References: <1117689924.2227.24.camel@thl.ct.heise.de> Message-ID: <1117722813.5041.8.camel@cutter> > - One minor thing: network yum cache of downloaded packages. With > something like that you don't have to download all packages more then > once if you install them on more then one system (okay, something like > that can be implemented with a shared network folder -- until someone > calls "yum clean all" or does other bad things). I can post more details > if someone is interested You seen yum-downloader yet? It might help with some of this. I think a yum caching util should probably be in yum-utils and not really for discussion on this list. -sv From cmadams at hiwaay.net Thu Jun 2 14:37:47 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 2 Jun 2005 09:37:47 -0500 Subject: What next? In-Reply-To: <1117689924.2227.24.camel@thl.ct.heise.de> References: <1117689924.2227.24.camel@thl.ct.heise.de> Message-ID: <20050602143747.GB1293533@hiwaay.net> Once upon a time, Thorsten Leemhuis said: > - One DVD that can install both i386 and x86_64 (now that Intel starts > shipping Celerons more and more people will try x86_64) I don't think that's going to be very practical. There's already a good bit of duplication in the distributed files and this would just add too it. I'd like to see a single source CD/DVD set (I know this is a non-trivial thing, but it would be nice). The FTP site is structured with all the SRPMS in the same directory; it would save a bunch of disk space if the ISOs were common as well. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From yuan.bbbush at gmail.com Thu Jun 2 14:41:09 2005 From: yuan.bbbush at gmail.com (Yuan Yijun) Date: Thu, 2 Jun 2005 22:41:09 +0800 Subject: rawhide report: 20050602 changes In-Reply-To: <200506021141.j52Bfs8R028992@porkchop.devel.redhat.com> References: <200506021141.j52Bfs8R028992@porkchop.devel.redhat.com> Message-ID: <9792751e0506020741626f9a43@mail.gmail.com> 2005/6/2, Build System : > New package autoconvert > Chinese HZ/GB/BIG5 encodings auto-converter > autoconvert? error: Failed dependencies: libhz.so.0 is needed by autoconvert-0.3.13-1.i386 -- bbbush ^_^ From katzj at redhat.com Thu Jun 2 14:58:36 2005 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 02 Jun 2005 10:58:36 -0400 Subject: What next? In-Reply-To: <1117655112.6284.39.camel@ignacio.ignacio.lan> References: <1117655112.6284.39.camel@ignacio.ignacio.lan> Message-ID: <1117724316.3768.3.camel@bree.local.net> On Wed, 2005-06-01 at 15:45 -0400, Ignacio Vazquez-Abrams wrote: > On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote: > > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > > Extras 5 - what major features are you willing to put effort into? > > I really really really want to see anaconda be able to use yum repos. I > think it's "on the list", but I strongly feel that it's worth > reiterating. The vague plan at this point is to get all of the depsolving, etc using yum as its backend, but we're probably not going to have UI for adding more repositories for FC5, at least not in the default install path. Doing this is a *BIG* change and it really needs to be staged carefully to avoid disaster[1] Jeremy [1] Disaster being defined as my bugzilla mailbox exploding to the point that there's no way I can keep up with it :-) From jpound at redhat.com Thu Jun 2 15:00:04 2005 From: jpound at redhat.com (Jeff Pound) Date: Thu, 02 Jun 2005 11:00:04 -0400 Subject: What next? In-Reply-To: <1117662394.31018.80.camel@cutter> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <1117662394.31018.80.camel@cutter> Message-ID: <1117724404.3361.13.camel@tower.toronto.redhat.com> On Wed, 2005-06-01 at 17:46 -0400, seth vidal wrote: > > > > > > > What about making it possible for non-text users to use yum? They > > shouldn't be kept out of such a great tool :) > > it's a work-in-progress. Speaking of which, is there a project page or hacking guide for pup? (or maybe a feature reqs doc) -- Jeff Pound From felipe.alfaro at gmail.com Thu Jun 2 15:05:44 2005 From: felipe.alfaro at gmail.com (Felipe Alfaro Solana) Date: Thu, 2 Jun 2005 17:05:44 +0200 Subject: What next? LDAP In-Reply-To: <83712260D48F4DF130523E0C@10.169.6.246> References: <1117655635.6735.28.camel@dhollis-lnx.sunera.com> <83712260D48F4DF130523E0C@10.169.6.246> Message-ID: <6f6293f105060208054b1f69cb@mail.gmail.com> On 6/2/05, Kenneth Porter wrote: > Agreed. I'm trying to get up to speed on deploying OpenLDAP together with > the Samba schema to get single sign-on and a global address book, but it's > been tough marshaling all the HOWTO's to figure out what's really required. > I went down a wrong path using the PADL scripts bundled with OpenLDAP > (because I failed to select the "enhanced" schema in the common config > file) and they also fail badly on the /etc/services file due to the > presence of Apple protocols. So far the best information for initial setup > seems to be in the HOWTO's at , but I'm still > working through it to understand how to migrate my existing setup. Single sign-on doesn't require a LDAP server, but some kind of central identity magament which can be supplied by using a Kerberos V KDC like the Kerberos V MIT implementation that comes in the form of krb5-* packages for Fedora Core. Once upon I time I wrote the attached document which enumerates all the steps I had to perform in order to set up a Kerberos V KDC and how to configure services like OpenSSH to support single sign-on. HTH. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Kerberos.txt URL: From heretic at ihug.co.nz Thu Jun 2 15:08:28 2005 From: heretic at ihug.co.nz (David Mohring) Date: Fri, 03 Jun 2005 03:08:28 +1200 Subject: Services, Roles and Xen [was whats next] In-Reply-To: <1117707556.3355.13.camel@localhost.localdomain> References: <1117707556.3355.13.camel@localhost.localdomain> Message-ID: <1117724908.13163.12.camel@heretic.grobb.org> On Thu, 2005-06-02 at 12:19 +0200, Kyrre Ness Sjobak wrote: > ons, 01.06.2005 kl. 19.59 skrev Elliot Lee: > > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > > Extras 5 - what major features are you willing to put effort into? > > > > Best, > > -- Elliot > > system-config-role > See below > - LAMP server (setup apache, mysql, and PHP in a sane way) > - File/login-server (LDAP, NFS, Samba) Instead of a single role, it's better to have the ability to assign individual services to individual machines, with each service having a "meta-role" of Master( primary host for a resource ), Apprentice ( in sync with Master ), or Backup ( as with Apprentice, but does not actively serve ). You configure the service for the Master server using a front end, which also stores the details in a single generalized config file, which also can be copied so it can be accessed at a given URI. When creating an Apprentice or Backup service all you should need to do is declare the URI of the Master file. When starting a init.d service, the back end grabs the generalized config file and generates the appropriate /etc/ files. The front and back ends should also include the ability to use encryption and digital signatures. And if your going to do that, then why not have the option of for each PC to load a master list of services and required rpm packages from a single remote URI at boot time, pxeboot style. > some setup tool where you could select a machines role using profiles - > examples: > > - Laptop (ACPI, NetworkManager etc) > - Workstation (nothing special) https://www.redhat.com/archives/fedora-devel-list/2005-April/msg00545.html QUOTE However, with a little scripted configuration, one OS install and one mounted file system tree, should be able to perform all of the following, one at a time, depending on boot flags and kernel selection. Native without Xen Workstation : Run level 5 Graphical mode. Runs most user applications locally. Can host remote services ( httpd etc ). X-Terminal : Run level 4? LTSP like thin graphical client. Runs most user applications remotely. * Important for desktop support: you can fix the normal workstation setup without any user downtime. Server : Run level 3 Text mode. Runs most user applications locally. hosts remote services. Repair : Run level 2 Text mode Root login only. Does not host remote services. Xen domain 0 Xen + Domain 0 Workstation : Run level 5 Graphical mode ( assuming that AGP is compatible ) Should operate same as native workstation Xen + Domain 0 X-Terminal : Run level 4? Graphical mode ( assuming that AGP is compatible ) Can also log into local domain U servers. Xen + Domain 0 Server : Run level 3 Text mode, Xen + Domain 0 Monitor : Run level 2? Text mode. Minimal Xen host setup, plus network support. Runs user application and services on domain U servers NOTE : whatever runlevel the Xen domain 0 is running it would still host/run the "xen" init.d Xen0 services. Xen domain U Note only two. Domain U Server : Run level 3 Domain U Repair : Run level 2 UNQUOTE > Surely you can make a lot of profiles. program runs as stand-alone and > in firstboot. > > Could probably make it really easy to setup a server etc. - reducing > deployment time. > > Kyrre > -- David Mohring From katzj at redhat.com Thu Jun 2 15:08:28 2005 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 02 Jun 2005 11:08:28 -0400 Subject: What next? In-Reply-To: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> Message-ID: <1117724908.3768.7.camel@bree.local.net> On Wed, 2005-06-01 at 16:44 -0700, Roland McGrath wrote: > To reiterate what Elliot said, the basic principle as I see it is that we > endeavor for the current Fedora release always to have the newest stuff > that is reasonably stable. After some fairly short interval in the 3-6 > month ballpark, *something* certainly has a newer and better version that > is reasonably stable. So more or less any time "rawhide has newer stuff", > then it's a good reason to have a Fedora Core release before too long. If > that sensation comes along, and there's something with a bleeding edge > that's still too bloody, then that something can roll back to the stable > version until the next FC release. It won't be too long. The problem is that we have significant amounts of things that *DON'T* have an upstream other than Fedora, and so if we want to get things done for them, we have to work within Fedora. And they're components that we can't just "skip" changing for a release. Jeremy From katzj at redhat.com Thu Jun 2 15:09:48 2005 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 02 Jun 2005 11:09:48 -0400 Subject: What next? In-Reply-To: <604aa79105060113412109c5fd@mail.gmail.com> References: <604aa79105060113412109c5fd@mail.gmail.com> Message-ID: <1117724988.3768.9.camel@bree.local.net> On Wed, 2005-06-01 at 16:41 -0400, Jeff Spaleta wrote: > On 6/1/05, Elliot Lee wrote: > > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > > Extras 5 - what major features are you willing to put effort into? > > I'd like to see a summary of known 'plans' from each of the designated > subprojects listed on fedora's website. Random Feature requests are > nice.... a more general understanding of where each subproject > momentum is headed to provide scope for potential contributors would > be nicer. I'm actually planning on doing this for anaconda... I've already started doing some writing of things, but the whole pressure of getting a release out has kept me from getting to it until now ;) Stay tuned... Jeremy From sundaram at redhat.com Thu Jun 2 15:14:50 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 02 Jun 2005 20:44:50 +0530 Subject: What next? In-Reply-To: <1117724988.3768.9.camel@bree.local.net> References: <604aa79105060113412109c5fd@mail.gmail.com> <1117724988.3768.9.camel@bree.local.net> Message-ID: <429F226A.10604@redhat.com> Jeremy Katz wrote: >On Wed, 2005-06-01 at 16:41 -0400, Jeff Spaleta wrote: > > >>On 6/1/05, Elliot Lee wrote: >> >> >>>Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora >>>Extras 5 - what major features are you willing to put effort into? >>> >>> >>I'd like to see a summary of known 'plans' from each of the designated >>subprojects listed on fedora's website. Random Feature requests are >>nice.... a more general understanding of where each subproject >>momentum is headed to provide scope for potential contributors would >>be nicer. >> >> I am working on this too. I still have to gather a few things. I will post further updates when something substantial is done regards Rahul From katzj at redhat.com Thu Jun 2 15:23:56 2005 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 02 Jun 2005 11:23:56 -0400 Subject: [PATCH] mkinitrd rescue mode In-Reply-To: <1117653405.12259.51.camel@barsoom.rdu.redhat.com> References: <1117653405.12259.51.camel@barsoom.rdu.redhat.com> Message-ID: <1117725836.3768.15.camel@bree.local.net> On Wed, 2005-06-01 at 15:16 -0400, Jeffrey Layton wrote: > Essentially this patch adds some functionality to mkinitrd and nash. > This adds some tools to the initrd images (busybox and fsck, in > particular), and adds a function to nash to allow running a shell before > the switchroot occurs. This will have a relatively significant impact on the size of the initramfs and thus on the memory profile. Although I see it's not enabled by default, which is at least a plus It also won't handle filesystems other than ext3. > This gives you some ability to troubleshoot booting problems, and gives > the ability to do some rescue-type work without having to boot to the > CD. This is a big plus for people that run boxes remotely and don't have > easy physical access to them. PXE, copying the pxeboot vmlinuz/initrd into your grub.conf and a few other things can give you a way to boot rescue mode without having to put in a CD. If you're having to run mkinitrd with different command line arguments, then you've already lost if you've really hosed your system badly. Honestly, I'd really rather see improvements to rescue mode than something like this. Jeremy From rjune at bravegnuworld.com Thu Jun 2 15:29:03 2005 From: rjune at bravegnuworld.com (Richard June) Date: Thu, 2 Jun 2005 10:29:03 -0500 Subject: What next? In-Reply-To: <1117689274.2702.31.camel@cutter> References: <200506012120.25613.rjune@bravegnuworld.com> <1117689274.2702.31.camel@cutter> Message-ID: <200506021029.04057.rjune@bravegnuworld.com> On Thursday 02 June 2005 12:14 am, seth vidal wrote: > On Wed, 2005-06-01 at 21:20 -0500, Richard June wrote: > > What would alleviate it more is if one could upgrade Fedora versions via > > yum easily. I understand that's not always possible, but if you've kept > > to FC and extras, it would be great for that to be an option > > for many cases in the recent past it has been doable, but not > necessarily supported. It's always doable if you want to put forth that kind of effort. > the reality is that the number of things changed in a major way make it > difficult. > > FC1->FC2 was selinux and the kernel version change > FC2->FC3 was lvm2 and udev and rh9 to fc1 was this or that. I understand that major stuff has changed with every release, but if, as an end user, I could be reasonably sure that I could install the latest fedora-release, yum update, reboot, and I have a the latest version of fedora, that would be a happy thing Most likely this will *never* be a supported thing. nobody wants to deal with it, but if we could work towards being able to jump from FC(X - 1) to FC(X) like that, it would be a nicety even if the requirements are, FC and extras only. how difficult would it be to enable selinux or udev on a migration? LVM is an install time option only, I understand that. but some things don't strike me as being too far outside the realm of reason. This "reinstall every six months" kinda sucks ya know. From sopwith at redhat.com Thu Jun 2 15:37:50 2005 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 2 Jun 2005 11:37:50 -0400 (EDT) Subject: What next? In-Reply-To: <1117689174.2702.28.camel@cutter> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> Message-ID: On Thu, 2 Jun 2005, seth vidal wrote: > On Wed, 2005-06-01 at 16:44 -0700, Roland McGrath wrote: > > To reiterate what Elliot said, the basic principle as I see it is that we > > endeavor for the current Fedora release always to have the newest stuff > > that is reasonably stable. After some fairly short interval in the 3-6 > > month ballpark, *something* certainly has a newer and better version that > > is reasonably stable. So more or less any time "rawhide has newer stuff", > > then it's a good reason to have a Fedora Core release before too long. If > > that sensation comes along, and there's something with a bleeding edge > > that's still too bloody, then that something can roll back to the stable > > version until the next FC release. It won't be too long. > > > > We don't want Fedora Core ever to spend significant periods of time where > > there is great new fabulosity out there, in some area or other, that we > > aren't representing in the latest release. > > That's easy for you to say. You get paid to work on linux and/or > fedora/rhel for a living. You have all day to work on it. If fedora is > intended to have community involvement you have to remember that there > are many of us who are doing this outside of our real job. Remember, > fedora is for hobbyists. > > But if hobbyists cannot participate in development b/c the cycle is just > too fast, well then it's not too terribly useful for us, is it. So my answer would be "if FC5 deadlines don't give you enough time to complete a given piece of work, target FC6 instead". On the other hand, someone was also pointing out that there are some pieces that really need to be worked on every single release, so it's more complicated than that. Maybe we need to try to decouple development work from the release cycle a bit more. What if we could make it so that hardcore development work could go on throughout all six months of the development cycle? Best, -- Elliot From heretic at ihug.co.nz Thu Jun 2 15:43:52 2005 From: heretic at ihug.co.nz (David Mohring) Date: Fri, 03 Jun 2005 03:43:52 +1200 Subject: Snowfox:White list firefox with gcj for intranets [was What next] In-Reply-To: <1117694807.3567.11.camel@rydia.hardsun.net> References: <20050602032426.GA3626@imp.flyn.org> <1117694807.3567.11.camel@rydia.hardsun.net> Message-ID: <1117727032.13282.20.camel@heretic.grobb.org> On Wed, 2005-06-01 at 23:46 -0700, Aaron Kurtz wrote: > On Wed, 2005-06-01 at 22:24 -0500, W. Michael Petullo wrote: > > > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > > > Extras 5 - what major features are you willing to put effort into? > > And here are of few more of interest to me: > > > > - Bugzilla #158657 Build totem's Mozilla plugin > > - Bugzilla #127537 Free software applet viewer plugin > > http://www.nongnu.org/gcjwebplugin/ is being worked on. The blocker is > the current lack of sandboxing. > Why not adapt the firefox source rpm to build an extra binary ( of /usr/lib/firefox-1.0.4/firefox-bin ) package called Snowfox - a White list Firefox for intranets. The Snowfox binary would use separate plug-in and user configure directories than the Firefox binary, but only be able to access URIs from an assigned "white list". Snowfox would pass any URLs not matching the white list to the normal Firefox. A Firefox extension could perform the same role, passing URLs in the white list to Snowfox. The Snowfox client would perform vetting using the referrer URL to stop cross-linked attacks. The advantage is that it separates the data, cache cookies and plug-ins used with intranets and Internet. SELinux can be used to further isolate each instance. You could then deploy trusted plug-ins for Snowfox without the fear of having them abused like Active-X. That means you can use Snowfox to deploy GCJ, Python and Perl based plugins which could access the user environment. This is something which could be developed downstream at Mozilla, but trivial enough to it with a patch for the current or next Fedora. > > - Free software flash viewer? > http://www.schleef.org/swfdec/ plays some Flash, but fails on interactive and later Flash versions. > > > -- > Aaron Kurtz GPG Key ID: ED588CF2 > -- David Mohring From chasd at silveroaks.com Thu Jun 2 15:48:43 2005 From: chasd at silveroaks.com (chasd at silveroaks.com) Date: Thu, 2 Jun 2005 10:48:43 -0500 Subject: What next? In-Reply-To: <20050601224509.55EF6735FC@hormel.redhat.com> References: <20050601224509.55EF6735FC@hormel.redhat.com> Message-ID: <237cbd726828f6b779137343bc3fde89@silveroaks.com> >>> BTW., how does osx do installs (just bringing up the meta-file >>> installer thingy again. Feel free not to answer)? >> >> their package system, umm, err, sucks. As an OS X user since Server 1.0, I feel the need to step out of the lurker shadow. OS X does not _have_ a package management system. One of its greatest weaknesses IMHO. > 99.9% of users seem to disagree with you, judging by how often "Linux > should use appfolders like Macs do" is heard on various forums and > mailing > lists. Installing applications is easy on OS X, by design. One of the trade offs is there are many apps that could share libraries but don't. Most are statically linked ( except for OS-provided frameworks ). Some people bitch about high RAM usage in Fedora, I think OS X is worse. > So no one uses fink anymore to get applications? I guess i should go > tell them to close the project down. Fink is a third-party application that fills a void in the base OS. It is not included in the OS, like rpm. It can't install _any_ application, only those it knows about. There is no way on OS X to ask the system what is the version of app foo, or ask it if app foo is even installed. You could look in the "Applications" Directory, but apps don't have to live there, so you can't be sure. From a single user perspective that may not be a big issue. As a system admin, that is a pain. Keeping users from installing random applications can be a _good_ thing. The a OS X .pkg format an installer depend on frail scripts to accomplish many things rpm does in an enforced, consistent way. And it uses a freakish .bom format as storage. OK, maybe the storage format isn't a big problem. There was talk on the Darwin devel list about adding a package management system, but inaction is the decision. It is a hard problem to solve. The application installation/management needs of a single-user desktop are almost opposite of a server, or a company-managed desktop. As for ease of use, users here are experienced in both OS X and Winders. Since we use Fedora too, when I show anyone "sudo yum update foo," they say, "That's it? It's that easy?" You can look to OS X for ease-of-use with installers, but it isn't as good as rpm/dpkg/ports in many ways, and some OS X users suffer because of that. At least I do. Charles Dostale System Admin - Silver Oaks Communications http://www.silveroaks.com/ 824 17th Street, Moline IL 61265 From jspaleta at gmail.com Thu Jun 2 15:50:06 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 2 Jun 2005 11:50:06 -0400 Subject: What next? In-Reply-To: <200506021029.04057.rjune@bravegnuworld.com> References: <200506012120.25613.rjune@bravegnuworld.com> <1117689274.2702.31.camel@cutter> <200506021029.04057.rjune@bravegnuworld.com> Message-ID: <604aa791050602085032be5beb@mail.gmail.com> On 6/2/05, Richard June wrote: > Most likely this will *never* be a supported thing. nobody wants to deal with > it, but if we could work towards being able to jump from FC(X - 1) to FC(X) > like that, it would be a nicety even if the requirements are, FC and extras > only. how difficult would it be to enable selinux or udev on a migration? There are going to always be a class of low level technology changes that require you to you be using an already updated kernel/library environment to correctly configure them. You either provide a target environment to do this in like anaconda's update facility does..or to make live upgrades work you'd have to do your live upgrade in stages... with multlple reboots with specialized boottime config options for some of the reboots. Fragile. > LVM > is an install time option only, I understand that. but some things don't > strike me as being too far outside the realm of reason. > This "reinstall every six months" kinda sucks ya know. anaconda has an upgrade option.... and from discussion you know there is a long term goal to make it repository aware. How about we focus community effort on making the anaconda upgrade process work better.. instead of jumping over to a more fragile live upgrade process that will still require a reboot or two. For example you can boot into the anaconda installer environment via grub entry with vnc access enabled. How about you focus on making it easy for upgraders to set that up.. instead of re-inventing the live upgrade process that we know is going to have problems in some situations because of low level technology shifts. -jef From sundaram at redhat.com Thu Jun 2 15:52:47 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 02 Jun 2005 21:22:47 +0530 Subject: What next? In-Reply-To: References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> Message-ID: <429F2B4F.90104@redhat.com> Hi >On the other hand, someone was also pointing out that there are some >pieces that really need to be worked on every single release, so it's more >complicated than that. Maybe we need to try to decouple development work >from the release cycle a bit more. What if we could make it so that >hardcore development work could go on throughout all six months of the >development cycle? > >Best, >-- Elliot > > Maybe branch of for FC6 half way during the FC5 development or variations of it. It might very well be a crazy idea though regards Rahul From jakub at redhat.com Thu Jun 2 15:54:01 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 2 Jun 2005 11:54:01 -0400 Subject: Snowfox:White list firefox with gcj for intranets [was What next] In-Reply-To: <1117727032.13282.20.camel@heretic.grobb.org> References: <20050602032426.GA3626@imp.flyn.org> <1117694807.3567.11.camel@rydia.hardsun.net> <1117727032.13282.20.camel@heretic.grobb.org> Message-ID: <20050602155401.GA22349@devserv.devel.redhat.com> On Fri, Jun 03, 2005 at 03:43:52AM +1200, David Mohring wrote: > On Wed, 2005-06-01 at 23:46 -0700, Aaron Kurtz wrote: > > On Wed, 2005-06-01 at 22:24 -0500, W. Michael Petullo wrote: > > > > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > > > > Extras 5 - what major features are you willing to put effort into? > > > And here are of few more of interest to me: > > > > > > - Bugzilla #158657 Build totem's Mozilla plugin > > > - Bugzilla #127537 Free software applet viewer plugin > > > > http://www.nongnu.org/gcjwebplugin/ is being worked on. The blocker is > > the current lack of sandboxing. > > > > Why not adapt the firefox source rpm to build an extra binary ( > of /usr/lib/firefox-1.0.4/firefox-bin ) package called > Snowfox - a White list Firefox for intranets. That's unnecessary. gcjwebplugin already works as a small mozilla/firefox plugin and the Java applet is running in a separate process. To make gcjwebplugin really usable, AppletSecurityManager class needs to be written (ATM it is just a dummy class that allows almost everything), I guess some Java auditing needs to be done and SELinux policy written for gcjappletviewer. Jakub From sundaram at redhat.com Thu Jun 2 15:59:33 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 02 Jun 2005 21:29:33 +0530 Subject: Snowfox:White list firefox with gcj for intranets [was What next] In-Reply-To: <20050602155401.GA22349@devserv.devel.redhat.com> References: <20050602032426.GA3626@imp.flyn.org> <1117694807.3567.11.camel@rydia.hardsun.net> <1117727032.13282.20.camel@heretic.grobb.org> <20050602155401.GA22349@devserv.devel.redhat.com> Message-ID: <429F2CE5.6010002@redhat.com> HI >That's unnecessary. gcjwebplugin already works as a small mozilla/firefox >plugin and the Java applet is running in a separate process. >To make gcjwebplugin really usable, AppletSecurityManager class needs to >be written (ATM it is just a dummy class that allows almost everything), >I guess some Java auditing needs to be done and SELinux policy written for >gcjappletviewer. > > Jakub > > What about when users turn off SELinux? (not a bright idea but still...) Will the plugin check that and stop working? regards Rahul From jspaleta at gmail.com Thu Jun 2 16:03:13 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 2 Jun 2005 12:03:13 -0400 Subject: What next? In-Reply-To: References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> Message-ID: <604aa79105060209034f6ebf1b@mail.gmail.com> On 6/2/05, Elliot Lee wrote: > On the other hand, someone was also pointing out that there are some > pieces that really need to be worked on every single release, so it's more > complicated than that. Maybe we need to try to decouple development work > from the release cycle a bit more. What if we could make it so that > hardcore development work could go on throughout all six months of the > development cycle? Except there are fedora specific infrastructure and process peices that need love so they can be more effective tools during the release cycle. How about this: 0)FC N comes out 1) Provide short time to make incramental changes to fedora contributor facing infrastructure, tools and policy, based on feedback during the FC N release cycle. 2) Put those incramental changes in tools and policy in place for use in FC N+1 testing/release. 3)Use those updated infrastructure during the release cycle..finding where they are suboptimal. Avoid the temptation to continually screw around with infrastructure items during a release cycle, because you know you'll have some time to make changes post FC N+1 release. 4)N=+N+1 5)goto 0 -jef From heretic at ihug.co.nz Thu Jun 2 16:07:02 2005 From: heretic at ihug.co.nz (David Mohring) Date: Fri, 03 Jun 2005 04:07:02 +1200 Subject: Snowfox:White list firefox with gcj for intranets [was What next] In-Reply-To: <20050602155401.GA22349@devserv.devel.redhat.com> References: <20050602032426.GA3626@imp.flyn.org> <1117694807.3567.11.camel@rydia.hardsun.net> <1117727032.13282.20.camel@heretic.grobb.org> <20050602155401.GA22349@devserv.devel.redhat.com> Message-ID: <1117728422.13282.29.camel@heretic.grobb.org> On Thu, 2005-06-02 at 11:54 -0400, Jakub Jelinek wrote: > On Fri, Jun 03, 2005 at 03:43:52AM +1200, David Mohring wrote: > > On Wed, 2005-06-01 at 23:46 -0700, Aaron Kurtz wrote: > > > On Wed, 2005-06-01 at 22:24 -0500, W. Michael Petullo wrote: > > > > > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > > > > > Extras 5 - what major features are you willing to put effort into? > > > > And here are of few more of interest to me: > > > > > > > > - Bugzilla #158657 Build totem's Mozilla plugin > > > > - Bugzilla #127537 Free software applet viewer plugin > > > > > > http://www.nongnu.org/gcjwebplugin/ is being worked on. The blocker is > > > the current lack of sandboxing. > > > > > > > Why not adapt the firefox source rpm to build an extra binary ( > > of /usr/lib/firefox-1.0.4/firefox-bin ) package called > > Snowfox - a White list Firefox for intranets. > > That's unnecessary. gcjwebplugin already works as a small mozilla/firefox > plugin and the Java applet is running in a separate process. > To make gcjwebplugin really usable, AppletSecurityManager class needs to > be written (ATM it is just a dummy class that allows almost everything), > I guess some Java auditing needs to be done and SELinux policy written for > gcjappletviewer. And what about Python, Perl etc? BTW I'm getting a little tired of ALL the vendors, be it Microsoft, KDE, Opera, Apple and yes, even Mozilla saying "Trust the browser and plugin!". Recent history, even including Sun's JVMs, points to the browser and plugins being the real weak point on ALL desktop platforms. If you TRULY want fedora/Redhat to provide better security, is not a little more isolation a better option? > > Jakub > -- David Mohring From notting at redhat.com Thu Jun 2 16:07:15 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 2 Jun 2005 12:07:15 -0400 Subject: rawhide report: 20050602 changes In-Reply-To: <9792751e0506020741626f9a43@mail.gmail.com> References: <200506021141.j52Bfs8R028992@porkchop.devel.redhat.com> <9792751e0506020741626f9a43@mail.gmail.com> Message-ID: <20050602160715.GA27335@nostromo.devel.redhat.com> Yuan Yijun (yuan.bbbush at gmail.com) said: > 2005/6/2, Build System : > > New package autoconvert > > Chinese HZ/GB/BIG5 encodings auto-converter > > > > autoconvert? > > error: Failed dependencies: > libhz.so.0 is needed by autoconvert-0.3.13-1.i386 Build accident; it's not in Core any more and won't be in tomorrow's tree. Bill From notting at redhat.com Thu Jun 2 16:20:47 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 2 Jun 2005 12:20:47 -0400 Subject: What next? In-Reply-To: <1117689924.2227.24.camel@thl.ct.heise.de> References: <1117689924.2227.24.camel@thl.ct.heise.de> Message-ID: <20050602162047.GA27561@nostromo.devel.redhat.com> Thorsten Leemhuis (fedora at leemhuis.info) said: > - One DVD that can install both i386 and x86_64 (now that Intel starts > shipping Celerons more and more people will try x86_64) Won't fit. :) (Yes, it's possible to get there, but you can't do it yet.) Bill From notting at redhat.com Thu Jun 2 16:21:29 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 2 Jun 2005 12:21:29 -0400 Subject: What next? In-Reply-To: <200506021630.48520@carola.nyarlathotep> References: <200506021630.48520@carola.nyarlathotep> Message-ID: <20050602162129.GB27561@nostromo.devel.redhat.com> Aph (liste-p.alain at wanadoo.fr) said: > A gnome navigator by defaut : firefox is not a good choice : it's in english > only and many localisation don't work. Have you tried 1.0.4-4 from rawhide? Bill From tromey at redhat.com Thu Jun 2 16:27:56 2005 From: tromey at redhat.com (Tom Tromey) Date: 02 Jun 2005 10:27:56 -0600 Subject: What next? In-Reply-To: References: <1117660147.9566.12.camel@localhost.localdomain> Message-ID: >>>>> "Mike" == Mike Hearn writes: >> Yes. There are 2 ABIs, and you are talking about one (the binary >> compatibility ABI, aka BC ABI) while Anthony is talking about the >> other one (the "C++" ABI). Mike> Hmm, interesting! OK, so you can choose which ABI your binary uses at Mike> compile time? When would you ever *not* want the BC ABI? Mike> Oh, wait, or is this for using the libgcj objects from actual C++ code Mike> using CNI? The C++ ABI has better performance. And, at the moment, CNI only works with the C++ ABI. The tradeoff is that the C++ ABI is not perfectly "java like", and so in general you have to modify your application to work properly with it. The reason we haven't yet made the BC ABI the default is that it is new, and also you can't yet compile directly from .java using this ABI; you must go via .class, which is a bit too broken for a default. Tom From pmatilai at laiskiainen.org Thu Jun 2 16:35:30 2005 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 02 Jun 2005 19:35:30 +0300 Subject: What next? In-Reply-To: References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> Message-ID: <1117730130.1674.3.camel@weasel.laiskiainen.org> On Thu, 2005-06-02 at 07:10 +0100, Mike Hearn wrote: > On Wed, 01 Jun 2005 19:28:22 -0400, Jeff Spaleta wrote: > > > a lack of update notification. Oh yeah.. thats absolutely wonderful. > > That's why Gaim has an auto-update plugin that will pop up a message when > there is an update. Oh, having every application do it's own auto-update checking is just wonderful. Wait.. no it's not. > > In fact, given that the little Fedora/Red Hat tray thing has *never* > actually been able to stick in my session for more than about a week, No such luck here, it sits there quite happily eating gobs of memory until cowboys come home on all of my systems. - Panu - From tromey at redhat.com Thu Jun 2 16:33:02 2005 From: tromey at redhat.com (Tom Tromey) Date: 02 Jun 2005 10:33:02 -0600 Subject: Snowfox:White list firefox with gcj for intranets [was What next] In-Reply-To: <20050602155401.GA22349@devserv.devel.redhat.com> References: <20050602032426.GA3626@imp.flyn.org> <1117694807.3567.11.camel@rydia.hardsun.net> <1117727032.13282.20.camel@heretic.grobb.org> <20050602155401.GA22349@devserv.devel.redhat.com> Message-ID: >>>>> "Jakub" == Jakub Jelinek writes: >> Why not adapt the firefox source rpm to build an extra binary ( >> of /usr/lib/firefox-1.0.4/firefox-bin ) package called >> Snowfox - a White list Firefox for intranets. Jakub> That's unnecessary. gcjwebplugin already works as a small Jakub> mozilla/firefox plugin and the Java applet is running in a Jakub> separate process. To make gcjwebplugin really usable, Jakub> AppletSecurityManager class needs to be written (ATM it is just Jakub> a dummy class that allows almost everything), I guess some Java Jakub> auditing needs to be done and SELinux policy written for Jakub> gcjappletviewer. A few things are needed before I would be comfortable advertising libgcj's applet security. I have a to-do list here with the tasks, I'll put it on the gcc wiki or in the gcc bugzilla or something soon. A couple of us are pressing for "make applets work" to be the next big target for gcj development. This means finishing the security tasks and also some AWT improvements. AFAIK this decision isn't settled yet; and we're taking suggestions. (Another related task I want to see is java web start support, so we can run applications off the web. Most of the pieces for this exist once we've got security working.) Defense in depth sounds like a great plan to me, so an SELinux policy should definitely be included. Tom From heretic at ihug.co.nz Thu Jun 2 16:57:12 2005 From: heretic at ihug.co.nz (David Mohring) Date: Fri, 03 Jun 2005 04:57:12 +1200 Subject: Snowfox:White list firefox with gcj for intranets [was What next] In-Reply-To: References: <20050602032426.GA3626@imp.flyn.org> <1117694807.3567.11.camel@rydia.hardsun.net> <1117727032.13282.20.camel@heretic.grobb.org> <20050602155401.GA22349@devserv.devel.redhat.com> Message-ID: <1117731432.13282.35.camel@heretic.grobb.org> On Thu, 2005-06-02 at 10:33 -0600, Tom Tromey wrote: > >>>>> "Jakub" == Jakub Jelinek writes: > > >> Why not adapt the firefox source rpm to build an extra binary ( > >> of /usr/lib/firefox-1.0.4/firefox-bin ) package called > >> Snowfox - a White list Firefox for intranets. > > Jakub> That's unnecessary. gcjwebplugin already works as a small > Defense in depth sounds like a great plan to me, so an SELinux policy > should definitely be included. Then why not "Defense in depth" using SELinux typing to isolate intranet and Internet client access? > > Tom > -- David Mohring From fedora at leemhuis.info Thu Jun 2 17:01:48 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 02 Jun 2005 19:01:48 +0200 Subject: What next? In-Reply-To: <20050602162047.GA27561@nostromo.devel.redhat.com> References: <1117689924.2227.24.camel@thl.ct.heise.de> <20050602162047.GA27561@nostromo.devel.redhat.com> Message-ID: <1117731708.5435.13.camel@notebook.thl.home> Am Donnerstag, den 02.06.2005, 12:20 -0400 schrieb Bill Nottingham: > Thorsten Leemhuis (fedora at leemhuis.info) said: > > - One DVD that can install both i386 and x86_64 (now that Intel starts > > shipping Celerons more and more people will try x86_64) > > Won't fit. :) > (Yes, it's possible to get there, but you can't do it yet.) Of course double layer DVDs or double side DVDs could be used. More an more magazines ship with such beasts and double-layer DVD-burners are not unusual anymore. BTW, I know one german computer magazine that just announced that it will ship with a DVD/CD combo-media soon (CD on one side, double layer DVD on the other). On the DVD-Side there is a Suse-Live-Media and a install versions of Suse for i386 and x86_64. On the CD side there is a lot of windows software. Something like that should be possible with Fedora, too. Maybe without the Live-CD part for now. -- Thorsten Leemhuis From notting at redhat.com Thu Jun 2 17:04:28 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 2 Jun 2005 13:04:28 -0400 Subject: What next? In-Reply-To: <1117731708.5435.13.camel@notebook.thl.home> References: <1117689924.2227.24.camel@thl.ct.heise.de> <20050602162047.GA27561@nostromo.devel.redhat.com> <1117731708.5435.13.camel@notebook.thl.home> Message-ID: <20050602170428.GA28126@nostromo.devel.redhat.com> Thorsten Leemhuis (fedora at leemhuis.info) said: > > Won't fit. :) > > (Yes, it's possible to get there, but you can't do it yet.) > > Of course double layer DVDs or double side DVDs could be used. More an > more magazines ship with such beasts and double-layer DVD-burners are > not unusual anymore. Obviously, double-sided can be done right now. Are dual-layer *readers* really that popular these days? Heck, if they are that popular, we should drop CD images altogether! Bill From jlayton at redhat.com Thu Jun 2 17:06:34 2005 From: jlayton at redhat.com (Jeffrey Layton) Date: Thu, 02 Jun 2005 13:06:34 -0400 Subject: [PATCH] mkinitrd rescue mode In-Reply-To: <1117725836.3768.15.camel@bree.local.net> References: <1117653405.12259.51.camel@barsoom.rdu.redhat.com> <1117725836.3768.15.camel@bree.local.net> Message-ID: <1117731994.12259.68.camel@barsoom.rdu.redhat.com> On Thu, 2005-06-02 at 11:23 -0400, Jeremy Katz wrote: > This will have a relatively significant impact on the size of the > initramfs and thus on the memory profile. Although I see it's not > enabled by default, which is at least a plus It also won't handle > filesystems other than ext3. > This is just a proof-of-concept sort of thing at this stage. A better patch would detect the filesystem type of / and copy the fsck for that partition here. Then if you had other filesystems you could mount / and use those. This does increase the memory profile of the initramfs by about 1.5M. Isn't that memory freed after the switchroot occurs, though? It's not enabled by default in this incarnation, but my preference would be that it is in a later one. > > This gives you some ability to troubleshoot booting problems, and gives > > the ability to do some rescue-type work without having to boot to the > > CD. This is a big plus for people that run boxes remotely and don't have > > easy physical access to them. > > PXE, copying the pxeboot vmlinuz/initrd into your grub.conf and a few > other things can give you a way to boot rescue mode without having to > put in a CD. If you're having to run mkinitrd with different command > line arguments, then you've already lost if you've really hosed your > system badly. > > Honestly, I'd really rather see improvements to rescue mode than > something like this. Both of those methods mean you'll be booting to a different kernel than the one that is giving you problems. The main reason I rolled this patch is to allow you to inspect (and possibly repair) the state of the system when you're having problems booting. If you update to a new kernel, and that kernel isn't detecting your drives correctly, then that is very difficult to troubleshoot once you boot to a rescue kernel. -- Jeffrey Layton From fedora at camperquake.de Thu Jun 2 17:10:50 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 2 Jun 2005 19:10:50 +0200 Subject: What next? In-Reply-To: <20050602170428.GA28126@nostromo.devel.redhat.com> References: <1117689924.2227.24.camel@thl.ct.heise.de> <20050602162047.GA27561@nostromo.devel.redhat.com> <1117731708.5435.13.camel@notebook.thl.home> <20050602170428.GA28126@nostromo.devel.redhat.com> Message-ID: <20050602191050.1c9bab39@nausicaa.camperquake.de> Hi. Bill Nottingham wrote: > Obviously, double-sided can be done right now. Are dual-layer *readers* > really that popular these days? Am I missing some hidden joke here? All readers can do dual-layer. -- "Shall I tell you what I want? What I really really want?" From fedora at leemhuis.info Thu Jun 2 17:28:30 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 02 Jun 2005 19:28:30 +0200 Subject: What next? In-Reply-To: <20050602191050.1c9bab39@nausicaa.camperquake.de> References: <1117689924.2227.24.camel@thl.ct.heise.de> <20050602162047.GA27561@nostromo.devel.redhat.com> <1117731708.5435.13.camel@notebook.thl.home> <20050602170428.GA28126@nostromo.devel.redhat.com> <20050602191050.1c9bab39@nausicaa.camperquake.de> Message-ID: <1117733310.5435.15.camel@notebook.thl.home> Am Donnerstag, den 02.06.2005, 19:10 +0200 schrieb Ralf Ertzinger: > Hi. > > Bill Nottingham wrote: > > > Obviously, double-sided can be done right now. Are dual-layer *readers* > > really that popular these days? > > Am I missing some hidden joke here? All readers can do dual-layer. Yes, all DVD-ROM should do that. (But yes, some have trouble with those burned in dual-layer dvd-burners) -- Thorsten Leemhuis From fedora at wir-sind-cool.org Thu Jun 2 17:27:52 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 2 Jun 2005 19:27:52 +0200 Subject: rawhide report: 20050602 changes In-Reply-To: <200506021141.j52Bfs8R028992@porkchop.devel.redhat.com> References: <200506021141.j52Bfs8R028992@porkchop.devel.redhat.com> Message-ID: <20050602192752.3f00fd68.fedora@wir-sind-cool.org> On Thu, 2 Jun 2005 07:41:54 -0400, Build System wrote: > gcc-4.0.0-9 > ----------- > * Wed May 25 2005 Jakub Jelinek 4.0.0-9 > - update from CVS > - PRs c++/1016, c++/21686, libfortran/18495, libfortran/19014, > libfortran/19016, libfortran/19106, libfortran/20074, > libfortran/20436, libfortran/21075, libfortran/21108, > libfortran/21354, libfortran/21376, libgcj/21637, libgcj/21703, > libgcj/21736 > - fix overflowed constant handling (Zdenek Dvorak, #156844, > PRs middle-end/21331, tree-opt/21293) > - make sure slow_pthread_self is never yes for linux targets > - fix reg-stack ICE (#158407, PR target/21716) > - fix ICE on fortran alternate returns (#158434) > - fix ICE on fortran functions without explicit type with implicit none > (#158232, PR fortran/21729) Since I don't know whether the Fedora Extras buildsys runs this compiler already, I must assume that it does, because Amarok, which built fine some hours ago on i386, fails with many C++ related errors now. I cannot reproduce it with $ rpm -q gcc gcc-4.0.0-8 and need to wait for Rawhide mirror sync first. From jakub at redhat.com Thu Jun 2 17:32:48 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 2 Jun 2005 13:32:48 -0400 Subject: rawhide report: 20050602 changes In-Reply-To: <20050602192752.3f00fd68.fedora@wir-sind-cool.org> References: <200506021141.j52Bfs8R028992@porkchop.devel.redhat.com> <20050602192752.3f00fd68.fedora@wir-sind-cool.org> Message-ID: <20050602173248.GB22349@devserv.devel.redhat.com> On Thu, Jun 02, 2005 at 07:27:52PM +0200, Michael Schwendt wrote: > On Thu, 2 Jun 2005 07:41:54 -0400, Build System wrote: > > > gcc-4.0.0-9 > > ----------- > > * Wed May 25 2005 Jakub Jelinek 4.0.0-9 > > - update from CVS > > - PRs c++/1016, c++/21686, libfortran/18495, libfortran/19014, > > libfortran/19016, libfortran/19106, libfortran/20074, > > libfortran/20436, libfortran/21075, libfortran/21108, > > libfortran/21354, libfortran/21376, libgcj/21637, libgcj/21703, > > libgcj/21736 > > - fix overflowed constant handling (Zdenek Dvorak, #156844, > > PRs middle-end/21331, tree-opt/21293) > > - make sure slow_pthread_self is never yes for linux targets > > - fix reg-stack ICE (#158407, PR target/21716) > > - fix ICE on fortran alternate returns (#158434) > > - fix ICE on fortran functions without explicit type with implicit none > > (#158232, PR fortran/21729) > > Since I don't know whether the Fedora Extras buildsys runs this compiler > already, I must assume that it does, because Amarok, which built fine some > hours ago on i386, fails with many C++ related errors now. > > I cannot reproduce it with > > $ rpm -q gcc > gcc-4.0.0-8 > > and need to wait for Rawhide mirror sync first. This compiler is used only for FC5-ish builds ATM, FC4 uses 4.0.0-8. But if you prove 4.0.0-9 breaks some package built while 4.0.0-8 worked, please gather details and file a bug report, so that we can investigate it to see if it is a GCC or application bug. Jakub From davej at redhat.com Thu Jun 2 17:33:16 2005 From: davej at redhat.com (Dave Jones) Date: Thu, 2 Jun 2005 13:33:16 -0400 Subject: What next? In-Reply-To: <1117673759.29707.8.camel@otto.amantes> References: <1117657892.31018.33.camel@cutter> <20050601225823.GA772000@hiwaay.net> <1117673759.29707.8.camel@otto.amantes> Message-ID: <20050602173315.GB12419@redhat.com> On Thu, Jun 02, 2005 at 02:55:59AM +0200, Thomas Vander Stichele wrote: > Hi, > > > > > Once upon a time, seth vidal said: > > > > What about stretching out the dev cycle from 3months dev + 3 months of > > > > testing to something more like 6 months of dev + 3 months of testing. > > > > > > How about deciding what the major goals of the next release should be > > > (within reason of course), estimating about how long it should take to > > > meet those goals, and then add in whatever else seems reasonable in the > > > given time frame? > > > > Because the decision was explicitly made when the Fedora project started > > to do releases at regular intervals rather than based on feature-driven > > milestones. This is the model Gnome has used with a good bit of success. > > I disagree with the request for stretching, and agree with the > comparison with GNOME's model. Look at how Sarge went down. > > In contrast, I'd like to propose another idea - keep FC (x-2) alive > until a month after FC (x) comes out. This would make people feel they > don't need to upgrade every six months, but can do it every year, if > they feel it is a real issue. I find it a little silly how currently FC > (x - 2) gets eol'd around the time FC (x) is starting to churn out test > releases. Concurrently supporting 3 releases at the same time is already painful enough. The ability to drop the oldest release once the next test series is well underway really helps gather momentum to getting that next release out the door. Being stuck doing errata for older releases kills you, especially on larger packages. We decided long ago that keeping all the releases on the same revision of the kernel was the only way to stay sane and keep on top of bugs across three releases. However, this adds an additional burden onto other developers when upstream breaks compatibility with something or other, and random bits of userspace need updating. Stretching out the support for older releases means we have to put more effort into doing this, or spend more effort backporting cherry-picked patches (hint: at ~4000 changesets a month upstream, this isn't going to happen). The only other two alternatives are dropping support for the oldest release when the time comes, (ie, what we do now) , or just not doing updates for anything non-critical. This sounds feasible, but still gets you into the nightmare of having to cherry-pick and backport patches, and judging from comments in bugzilla when we've done similar things in the past, users tend not to like having their bugs closed with 'not critical, upgrade to the next release'. Dave From notting at redhat.com Thu Jun 2 17:37:46 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 2 Jun 2005 13:37:46 -0400 Subject: What next? In-Reply-To: <20050602191050.1c9bab39@nausicaa.camperquake.de> References: <1117689924.2227.24.camel@thl.ct.heise.de> <20050602162047.GA27561@nostromo.devel.redhat.com> <1117731708.5435.13.camel@notebook.thl.home> <20050602170428.GA28126@nostromo.devel.redhat.com> <20050602191050.1c9bab39@nausicaa.camperquake.de> Message-ID: <20050602173746.GA28352@nostromo.devel.redhat.com> Ralf Ertzinger (fedora at camperquake.de) said: > > Obviously, double-sided can be done right now. Are dual-layer *readers* > > really that popular these days? > > Am I missing some hidden joke here? All readers can do dual-layer. No, I'm just ignorant sometimes. :) Bill From overholt at redhat.com Thu Jun 2 17:42:58 2005 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 2 Jun 2005 13:42:58 -0400 Subject: What next? In-Reply-To: <429E4BF1.3040709@silverorange.com> References: <429E362E.9060701@poolshark.org> <20050601233143.0EE352F41E2@localhost.localdomain> <429E4BF1.3040709@silverorange.com> Message-ID: <20050602174258.GB4772@redhat.com> * Steven Garrity [2005-06-01 20:04]: > Kaj J. Niemi wrote: > >I would like automatic second display support (when connecting your > >laptop to a projector for example). So far I haven't been able to figure > >out how to do it except restart X with different settings. IMHO, it's one > >feature Apple's Powerbooks do really well running OS X. > > After watching the video of the talks from Guadec, you can see that this > is a big problem. Almost every talk started off with 5 or 10 minutes of > fiddling to get the video-to-projector working. In some cases, the > presentation went on with partially broken displays. I think part of the problem here was xrandr. It seemed that when using the dynamic resolution switching app (which I think uses xrandr), things didn't work. We ended up having to restart X using the resolution we wanted and get the technician to re-sync the projector before our stuff worked (and by 'worked' I mean 'worked for all but ~5% of the bottom of the screen' ;) . Andrew From notting at redhat.com Thu Jun 2 17:50:44 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 2 Jun 2005 13:50:44 -0400 Subject: What next? In-Reply-To: <1117731708.5435.13.camel@notebook.thl.home> References: <1117689924.2227.24.camel@thl.ct.heise.de> <20050602162047.GA27561@nostromo.devel.redhat.com> <1117731708.5435.13.camel@notebook.thl.home> Message-ID: <20050602175044.GB28352@nostromo.devel.redhat.com> Thorsten Leemhuis (fedora at leemhuis.info) said: > BTW, I know one german computer magazine that just announced that it > will ship with a DVD/CD combo-media soon (CD on one side, double layer > DVD on the other). On the DVD-Side there is a Suse-Live-Media and a > install versions of Suse for i386 and x86_64. On the CD side there is a > lot of windows software. > > Something like that should be possible with Fedora, too. Maybe without > the Live-CD part for now. The big issue with *this* is that the CD media might not be useful for some CD players; see various online refs on DualDisc. Bill From fedora at wir-sind-cool.org Thu Jun 2 17:55:10 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 2 Jun 2005 19:55:10 +0200 Subject: rawhide report: 20050602 changes In-Reply-To: <20050602173248.GB22349@devserv.devel.redhat.com> References: <200506021141.j52Bfs8R028992@porkchop.devel.redhat.com> <20050602192752.3f00fd68.fedora@wir-sind-cool.org> <20050602173248.GB22349@devserv.devel.redhat.com> Message-ID: <20050602195510.7bfc9742.fedora@wir-sind-cool.org> On Thu, 2 Jun 2005 13:32:48 -0400, Jakub Jelinek wrote: > On Thu, Jun 02, 2005 at 07:27:52PM +0200, Michael Schwendt wrote: > > On Thu, 2 Jun 2005 07:41:54 -0400, Build System wrote: > > > > > gcc-4.0.0-9 > > > ----------- > > > * Wed May 25 2005 Jakub Jelinek 4.0.0-9 > > > - update from CVS > > > - PRs c++/1016, c++/21686, libfortran/18495, libfortran/19014, > > > libfortran/19016, libfortran/19106, libfortran/20074, > > > libfortran/20436, libfortran/21075, libfortran/21108, > > > libfortran/21354, libfortran/21376, libgcj/21637, libgcj/21703, > > > libgcj/21736 > > > - fix overflowed constant handling (Zdenek Dvorak, #156844, > > > PRs middle-end/21331, tree-opt/21293) > > > - make sure slow_pthread_self is never yes for linux targets > > > - fix reg-stack ICE (#158407, PR target/21716) > > > - fix ICE on fortran alternate returns (#158434) > > > - fix ICE on fortran functions without explicit type with implicit none > > > (#158232, PR fortran/21729) > > > > Since I don't know whether the Fedora Extras buildsys runs this compiler > > already, I must assume that it does, because Amarok, which built fine some > > hours ago on i386, fails with many C++ related errors now. > > > > I cannot reproduce it with > > > > $ rpm -q gcc > > gcc-4.0.0-8 > > > > and need to wait for Rawhide mirror sync first. > > This compiler is used only for FC5-ish builds ATM, FC4 uses 4.0.0-8. Damn! :) When I asked about this on #fedora-extras, I was told the build system syncs with Fedora Core Development. That had been my earlier theory. A few hours before, Amarok built fine, http://extras64.linux.duke.edu/failed/4/amarok/1.2.4-3/i386/ then it failed, http://extras64.linux.duke.edu/failed/4/amarok/1.2.4-4/i386/ http://extras64.linux.duke.edu/failed/4/amarok/1.2.4-5/i386/ > But if you prove 4.0.0-9 breaks some package built while 4.0.0-8 > worked, please gather details and file a bug report, so that we > can investigate it to see if it is a GCC or application bug. My local build fails to rebuild amarok from Fedora Extras FC-4 CVS now, too. $ rpm -q gcc libstdc++ gcc-4.0.0-9 libstdc++-4.0.0-9 From Nicolas.Mailhot at laPoste.net Thu Jun 2 17:55:40 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 02 Jun 2005 19:55:40 +0200 Subject: What next? In-Reply-To: <1117662248.5219.15.camel@localhost.localdomain> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> Message-ID: <1117734944.7932.7.camel@rousalka.dyndns.org> Le mercredi 01 juin 2005 ? 23:44 +0200, Kyrre Ness Sjobak a ?crit : > BTW., how does osx do installs (just bringing up the meta-file installer > thingy again. Feel free not to answer)? Mac systems and all the systems they inspired (java...) basically stuff an app and all its needs in a single archive (because you can't mouse easily more than one file) Installation is just dropping this file in the right place Un-installation is deleting it It sucks big time because you have massive code duplication leading to maintenance problems and high memory usage, no shared infrastructure apart from the one provided by the OS/JVM and controlled by a single vendor. And app writers do not really care if all the third-party stuff they put in their archive with their own code is stale and leaking. -- Nicolas Mailhot -------------- 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 Nicolas.Mailhot at laPoste.net Thu Jun 2 17:57:02 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 02 Jun 2005 19:57:02 +0200 Subject: What next? In-Reply-To: <20050601214934.GA24588@jadzia.bu.edu> References: <1117660299.31018.61.camel@cutter> <20050601214934.GA24588@jadzia.bu.edu> Message-ID: <1117735023.7932.9.camel@rousalka.dyndns.org> Le mercredi 01 juin 2005 ? 17:49 -0400, Matthew Miller a ?crit : > On Wed, Jun 01, 2005 at 05:11:39PM -0400, seth vidal wrote: > > - extras organization into package groups or even sub-repos > > Maybe including changing all of the "Group:" tags to something more > well-considered? (Like, just, "Core" and "Extras"; or, whatever the > sub-repos end up being.) Maybe admit they were a bad idea and kill them -- Nicolas Mailhot -------------- 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 leemhuis.info Thu Jun 2 18:16:10 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 02 Jun 2005 20:16:10 +0200 Subject: What next? In-Reply-To: <20050602175044.GB28352@nostromo.devel.redhat.com> References: <1117689924.2227.24.camel@thl.ct.heise.de> <20050602162047.GA27561@nostromo.devel.redhat.com> <1117731708.5435.13.camel@notebook.thl.home> <20050602175044.GB28352@nostromo.devel.redhat.com> Message-ID: <1117736170.5435.30.camel@notebook.thl.home> Am Donnerstag, den 02.06.2005, 13:50 -0400 schrieb Bill Nottingham: > Thorsten Leemhuis (fedora at leemhuis.info) said: > > BTW, I know one german computer magazine that just announced that it > > will ship with a DVD/CD combo-media soon (CD on one side, double layer > > DVD on the other). On the DVD-Side there is a Suse-Live-Media and a > > install versions of Suse for i386 and x86_64. On the CD side there is a > > lot of windows software. > > > > Something like that should be possible with Fedora, too. Maybe without > > the Live-CD part for now. > > The big issue with *this* is that the CD media might not be useful for > some CD players; see various online refs on DualDisc. Okay. But that not our problem if magazines what to ship those discs (and it seems they do) we should help them with that IMHO (if possible). Some may even ship only double layer dvds without the CD backside (if x86_64 becomes more widespread they probably *will* have to ship both x86_64 and i386 together). Any argument against those nearly normal DVDs also? ;-) -- Thorsten Leemhuis From mike at navi.cx Thu Jun 2 18:12:58 2005 From: mike at navi.cx (Mike Hearn) Date: Thu, 02 Jun 2005 19:12:58 +0100 Subject: Packaging idea (Re: What next?) References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <1117705158.3355.5.camel@localhost.localdomain> Message-ID: On Thu, 02 Jun 2005 11:39:19 +0200, Kyrre Ness Sjobak wrote: > BTW, would this format be capable of providing multiple repos for > multiple distros/distro versions? I'd suggest reading the website. Autopackage isn't based on multiple repositories for each distro, that doesn't scale and never will. thanks -mike From mike at navi.cx Thu Jun 2 18:17:54 2005 From: mike at navi.cx (Mike Hearn) Date: Thu, 02 Jun 2005 19:17:54 +0100 Subject: What next? References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <1117662394.31018.80.camel@cutter> <1117673495.29707.4.camel@otto.amantes> Message-ID: On Thu, 02 Jun 2005 02:51:34 +0200, Thomas Vander Stichele wrote: > In short, what people who say "linux should use appfolders like ..." > mean is "please solve my install problems" which in practice would > translate to "please have only 1 linux". Sounds good to me. Too bad the LSB sort of wandered off into the haze, what we really need is some freedesktop.org equivalent for distributions. There's no fundamental reason why packages have to be incompatible, a lot of times the differences are different merely through being apart. But yeah, I agree that people translate "I want things to be easy" into "I want it to be like on the Mac" internally. That's not necessarily a faulty line of thinking though. thanks -mike From sundaram at redhat.com Thu Jun 2 18:24:09 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 02 Jun 2005 23:54:09 +0530 Subject: What next? In-Reply-To: References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <1117662394.31018.80.camel@cutter> <1117673495.29707.4.camel@otto.amantes> Message-ID: <429F4EC9.6050908@redhat.com> Hi > >But yeah, I agree that people translate "I want things to be easy" into "I >want it to be like on the Mac" internally. That's not necessarily a faulty >line of thinking though. > > No. its not a faulty line of thinking but the Mac solution is based on the assumption of a monolithic platform. We can produce something similar with a integrated release structure. we have bits and pieces of that in GNOME and elsewhere. More bits like a freedesktop.org platform and packaging guidelines and naming conventions shared across distributions would help get similar functionality in Fedora but its a big process and not everyone is very keen on seeing that happen unfortunately regards Rahul From ed at eh3.com Thu Jun 2 18:28:21 2005 From: ed at eh3.com (Ed Hill) Date: Thu, 02 Jun 2005 14:28:21 -0400 Subject: What next? In-Reply-To: References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <1117672717.28429.297.camel@ernie> Message-ID: <1117736901.27637.45.camel@ernie> On Thu, 2005-06-02 at 07:07 +0100, Mike Hearn wrote: > On Wed, 01 Jun 2005 20:38:37 -0400, Ed Hill wrote: > > Have you been using *nix long enough to remember when people thought it > > was cool to stuff every package into is own /opt/${PACKAGE} directory? > > Yep. > > > Does it sound at all familiar to Apple's approach that you just > > described? > > Nope. Not really. Putting apps in their own (movable) directory isn't the > issue here. The things that make appfolders easy go pretty deep, but the > fact that it's implemented in terms of magic directories is just a surface > detail. >From the description that you've provided, there is *no* depth. And there is *no* magic. Quoting from your original email, the two key parts are: > - Packages have no dependencies outside the operating system. They > can embed libraries within themselves easily. > - There is no auto update system. Apple also provide a traditional > Installer service, which some things use. So when you've thrown out updates and completely eliminated any intra- package dependencies, whats left? Nothing but a hollow GUI wrapper over yet-another brain-dead application of /opt/${PACKAGE}. Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From jpo at di.uminho.pt Thu Jun 2 18:28:51 2005 From: jpo at di.uminho.pt (=?ISO-8859-1?Q?Jos=E9_Pedro_Oliveira?=) Date: Thu, 02 Jun 2005 19:28:51 +0100 Subject: What next? LDAP In-Reply-To: <83712260D48F4DF130523E0C@[10.169.6.246]> References: <1117655635.6735.28.camel@dhollis-lnx.sunera.com> <83712260D48F4DF130523E0C@[10.169.6.246]> Message-ID: <429F4FE3.9010005@di.uminho.pt> Kenneth Porter wrote: > --On Wednesday, June 01, 2005 3:53 PM -0400 David Hollis > wrote: > >> Now that the directory server is starting to trickle out, I'd love to >> see that incorporated with some form of administration tool. I've done >> a bunch of LDAP setups in recent months and can now finally manage it >> from command line/LDIFs but it really doesn't have to be that tough to >> get a simple directory setup. The great part about it is that once it's >> setup, it can do quite a bit and even act as an Active Directory domain >> controller which is really a beautiful thing. > > > Agreed. I'm trying to get up to speed on deploying OpenLDAP together > with the Samba schema to get single sign-on and a global address book, > but it's been tough marshaling all the HOWTO's to figure out what's > really required. I went down a wrong path using the PADL scripts bundled > with OpenLDAP (because I failed to select the "enhanced" schema in the > common config file) and they also fail badly on the /etc/services file > due to the presence of Apple protocols. So far the best information for > initial setup seems to be in the HOWTO's at , > but I'm still working through it to understand how to migrate my > existing setup. > > I'd recommend that anyone starting out get the smbtools from idealx and > also get phpldapadmin set up on Apache to maintain the thing and get a > more visual understanding of how things are organized. Hopefully > volunteers will step forward to bring these into Extras. The smbldap-tools scripts are already being distributed with samba Unfortunately the scripts are being packaged as documentation by Red-Hat: # rpm -ql samba | grep smbldap-tools /usr/share/doc/samba-3.0.14a/LDAP/smbldap-tools-0.8.7 /usr/share/doc/samba-3.0.14a/LDAP/smbldap-tools-0.8.7/CONTRIBUTORS ... /usr/share/doc/samba-3.0.14a/LDAP/smbldap-tools-0.8.7/smbldap-groupadd /usr/share/doc/samba-3.0.14a/LDAP/smbldap-tools-0.8.7/smbldap-groupdel /usr/share/doc/samba-3.0.14a/LDAP/smbldap-tools-0.8.7/smbldap-groupmod /usr/share/doc/samba-3.0.14a/LDAP/smbldap-tools-0.8.7/smbldap-groupshow /usr/share/doc/samba-3.0.14a/LDAP/smbldap-tools-0.8.7/smbldap-passwd /usr/share/doc/samba-3.0.14a/LDAP/smbldap-tools-0.8.7/smbldap-populate /usr/share/doc/samba-3.0.14a/LDAP/smbldap-tools-0.8.7/smbldap-useradd /usr/share/doc/samba-3.0.14a/LDAP/smbldap-tools-0.8.7/smbldap-userdel /usr/share/doc/samba-3.0.14a/LDAP/smbldap-tools-0.8.7/smbldap-userinfo /usr/share/doc/samba-3.0.14a/LDAP/smbldap-tools-0.8.7/smbldap-usermod /usr/share/doc/samba-3.0.14a/LDAP/smbldap-tools-0.8.7/smbldap-usershow /usr/share/doc/samba-3.0.14a/LDAP/smbldap-tools-0.8.7/smbldap.conf /usr/share/doc/samba-3.0.14a/LDAP/smbldap-tools-0.8.7/smbldap_bind.conf /usr/share/doc/samba-3.0.14a/LDAP/smbldap-tools-0.8.7/smbldap_tools.pm jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From mattdm at mattdm.org Thu Jun 2 18:32:59 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 2 Jun 2005 14:32:59 -0400 Subject: What next? In-Reply-To: <1117735023.7932.9.camel@rousalka.dyndns.org> References: <1117660299.31018.61.camel@cutter> <20050601214934.GA24588@jadzia.bu.edu> <1117735023.7932.9.camel@rousalka.dyndns.org> Message-ID: <20050602183259.GA778@jadzia.bu.edu> On Thu, Jun 02, 2005 at 07:57:02PM +0200, Nicolas Mailhot wrote: > > Maybe including changing all of the "Group:" tags to something more > > well-considered? (Like, just, "Core" and "Extras"; or, whatever the > > sub-repos end up being.) > Maybe admit they were a bad idea and kill them I'm suggesting killing the idea of using them for fine-grained grouping, yeah. But they still could be useful for what I suggest above. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 78 degrees Fahrenheit. From ronny-vlug at vlugnet.org Thu Jun 2 18:38:10 2005 From: ronny-vlug at vlugnet.org (Ronny Buchmann) Date: Thu, 2 Jun 2005 20:38:10 +0200 Subject: What next? In-Reply-To: <1117660599.31018.67.camel@cutter> References: <1117658141.6271.70.camel@laptopd505.fenrus.org> <1117660599.31018.67.camel@cutter> Message-ID: <200506022038.10556.ronny-vlug@vlugnet.org> On Wednesday 01 June 2005 23:16, seth vidal wrote: > > > What about stretching out the dev cycle from 3months dev + 3 months of > > > testing to something more like 6 months of dev + 3 months of testing. > > > > agreed in part. Fedora is ready for a bigger cycle so that more > > fundamental things can get fixed. I don't like 6+3 per se, I'd like 3+3 > > +3, 3 devel, 3 devel+test and 3 test > > Sure - but in total a 9 month release cycle for this rev would take the > strain off of some of us who aren't paid to do this all day. I think we should do only work on infrastructure for FC5 and basically get FC5=FC4+FC4updates+infrastructure in the 6 months timeframe we have. -- http://LinuxWiki.org/RonnyBuchmann From Nicolas.Mailhot at laPoste.net Thu Jun 2 18:37:46 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 02 Jun 2005 20:37:46 +0200 Subject: What next? LDAP In-Reply-To: <6f6293f105060208054b1f69cb@mail.gmail.com> References: <1117655635.6735.28.camel@dhollis-lnx.sunera.com> <83712260D48F4DF130523E0C@10.169.6.246> <6f6293f105060208054b1f69cb@mail.gmail.com> Message-ID: <1117737488.7932.27.camel@rousalka.dyndns.org> Le jeudi 02 juin 2005 ? 17:05 +0200, Felipe Alfaro Solana a ?crit : > On 6/2/05, Kenneth Porter wrote: > > Agreed. I'm trying to get up to speed on deploying OpenLDAP together with > > the Samba schema to get single sign-on and a global address book, but it's > > been tough marshaling all the HOWTO's to figure out what's really required. > > I went down a wrong path using the PADL scripts bundled with OpenLDAP > > (because I failed to select the "enhanced" schema in the common config > > file) and they also fail badly on the /etc/services file due to the > > presence of Apple protocols. So far the best information for initial setup > > seems to be in the HOWTO's at , but I'm still > > working through it to understand how to migrate my existing setup. > > Single sign-on doesn't require a LDAP server, but some kind of central > identity magament which can be supplied by using a Kerberos V KDC like > the Kerberos V MIT implementation that comes in the form of krb5-* > packages for Fedora Core. Kerberos is insufficient by itself. 9 times out of ten if you're interested in SSO you want at least a centralised adressbook too. The needs start snowballing pretty quickly. The Microsoft implementation may be bad but they've understood the needs of small to big corporations pretty well (for huge corporations their offering does not scale but they'll be using their own ldap/kerberos combo anyway). An easy ldap/krb5 setup would be used starting from two computer networks. Only licensing and complexity have active directory start above SMEs. We need easy SSO, adressbook, network conf, ical, file sharing (thanksfully dhcp/dns, imap/smtp, ipp, http, sql and office software are well covered now) Do this and SMEs won't have any core need for windows anymore (so it can be relegated to a few seats). They're the ones that feed Microsoft - home users and corporations either do not buy stuff or get it with huge discounts. -- Nicolas Mailhot -------------- 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 Nicolas.Mailhot at laPoste.net Thu Jun 2 19:00:42 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 02 Jun 2005 21:00:42 +0200 Subject: What next? In-Reply-To: References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <1117662394.31018.80.camel@cutter> <1117673495.29707.4.camel@otto.amantes> Message-ID: <1117738856.7932.33.camel@rousalka.dyndns.org> Le jeudi 02 juin 2005 ? 19:17 +0100, Mike Hearn a ?crit : > On Thu, 02 Jun 2005 02:51:34 +0200, Thomas Vander Stichele wrote: > > In short, what people who say "linux should use appfolders like ..." > > mean is "please solve my install problems" which in practice would > > translate to "please have only 1 linux". > > Sounds good to me. Too bad the LSB sort of wandered off into the haze, > what we really need is some freedesktop.org equivalent for distributions. > There's no fundamental reason why packages have to be incompatible, a lot > of times the differences are different merely through being apart. We don't have the ressources for the "one linux model" The linux progress rate is so high because a lot of stuff is loosely coupled, so people can work on what they care about in parallel, syncing only now and then. Hell, even Microsoft does not have the ressources for the "one windows" model. And they have lots of $$$, and scale a lot less in all directions. -- Nicolas Mailhot -------------- 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 Nicolas.Mailhot at laPoste.net Thu Jun 2 19:16:59 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 02 Jun 2005 21:16:59 +0200 Subject: What next? In-Reply-To: <6f6293f105060123227235d2d2@mail.gmail.com> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <1117662394.31018.80.camel@cutter> <6f6293f105060123227235d2d2@mail.gmail.com> Message-ID: <1117739839.7932.45.camel@rousalka.dyndns.org> Le jeudi 02 juin 2005 ? 08:22 +0200, Felipe Alfaro Solana a ?crit : > On 6/1/05, seth vidal wrote: > > > BTW., how does osx do installs (just bringing up the meta-file installer > > > thingy again. Feel free not to answer)? > > > > their package system, umm, err, sucks. > > Yeah! But many applications come packaged in such a way that the user > simply needs to drag'n'drop them to the /Applications directory. > That's really simple. But the technical price for this is awful. We may soon be able to do something similar from an end-user perspective (dropping a metadatafile in a directory that's monitored by the system and triggers an install) but that won't be in spite of rpm/yum but thanks to them. There is at least the same gap in underlying infrastructure as there were between true and false transparency in X. Moreover all the closed app vendors that would benefit the most from it went the LSB/Mac way, turned their back on linux packaging principles, and will be quite unable to exploit the system once it's in place. They're still learning what a dependency is today! -- Nicolas Mailhot -------------- 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 Nicolas.Mailhot at laPoste.net Thu Jun 2 19:22:00 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 02 Jun 2005 21:22:00 +0200 Subject: Packaging idea (Re: What next?) In-Reply-To: References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> Message-ID: <1117740125.7932.48.camel@rousalka.dyndns.org> Le mercredi 01 juin 2005 ? 23:01 -0400, Konstantin Ryabitsev a ?crit : > > -jef"i think its time for someone to build their own distro using the > > packaging paradigm they like the best"spaleta > > So, check this out. I'm going to brainstorm outloud, so feel free to > shoot me down at any point. Apart from the "drop a metadata file somewhere" all the rest is pretty irrelevant to users. FC is not in the "let's be problem-compatible with windows" space. -- Nicolas Mailhot -------------- 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 Nicolas.Mailhot at laPoste.net Thu Jun 2 19:25:48 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 02 Jun 2005 21:25:48 +0200 Subject: Packaging idea (Re: What next?) In-Reply-To: References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <604aa79105060120106eef01ae@mail.gmail.com> Message-ID: <1117740357.7932.51.camel@rousalka.dyndns.org> Le jeudi 02 juin 2005 ? 00:16 -0400, Konstantin Ryabitsev a ?crit : > And > yes, I'm pretty sure a lot of people will not bother with Extras, if > only because: > > a. They don't care to jump through all the hoops involved. > b. They don't want to bind themselves with any sort of a contract with Red Hat. > c. Their software is licensed so that it cannot be put in Extras. d. They don't want to QA their stuff on FC/RHEL. Yay drop statically-compiled horror in /usr/local/bin Nothing prevents them from creating an overlay repository today. You can even solve the closed license part by adding authenticated https support to yum today. -- Nicolas Mailhot -------------- 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 Nicolas.Mailhot at laPoste.net Thu Jun 2 19:31:14 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 02 Jun 2005 21:31:14 +0200 Subject: Packaging idea (Re: What next?) In-Reply-To: References: <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <604aa79105060120106eef01ae@mail.gmail.com> <1117686443.2702.9.camel@cutter> <604aa7910506012141650fbecf@mail.gmail.com> Message-ID: <1117740683.7932.54.camel@rousalka.dyndns.org> Le jeudi 02 juin 2005 ? 01:03 -0400, Konstantin Ryabitsev a ?crit : > A super-package mechanism would help create a framework that would > allow addressing the problems listed above. A super-package mechanism would add yet another layer of vendor mess over the existing layers of vendor mess. Sometimes less is more. -- Nicolas Mailhot -------------- 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 dwmw2 at infradead.org Thu Jun 2 19:47:39 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 02 Jun 2005 20:47:39 +0100 Subject: What next? In-Reply-To: <1117689924.2227.24.camel@thl.ct.heise.de> References: <1117689924.2227.24.camel@thl.ct.heise.de> Message-ID: <1117741659.25956.47.camel@hades.cambridge.redhat.com> On Thu, 2005-06-02 at 07:25 +0200, Thorsten Leemhuis wrote: > - One DVD that can install both i386 and x86_64 (now that Intel starts > shipping Celerons more and more people will try x86_64) We already do this for PPC/PPC64. But it's a little saner there because ppc32 isn't quite as crappy as i386 is -- so we actually end up using mostly ppc32 userspace even on ppc64 hardware, just because there's little point in being 64-bit. Whereas on x86_64 you almost always want the 64-bit binaries just so you get a sane number of registers, so there's much more duplication. -- dwmw2 From katzj at redhat.com Thu Jun 2 19:51:47 2005 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 02 Jun 2005 15:51:47 -0400 Subject: What next? In-Reply-To: References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> Message-ID: <1117741907.3768.27.camel@bree.local.net> On Thu, 2005-06-02 at 11:37 -0400, Elliot Lee wrote: > So my answer would be "if FC5 deadlines don't give you enough time to > complete a given piece of work, target FC6 instead". > > On the other hand, someone was also pointing out that there are some > pieces that really need to be worked on every single release, so it's more > complicated than that. Maybe we need to try to decouple development work > from the release cycle a bit more. What if we could make it so that > hardcore development work could go on throughout all six months of the > development cycle? Except that I can guarantee there will be things that have to be done for FC5 as well. And splitting development efforts across branches when the resources are already at the point of scarcity helps nothing. Jeremy From denis at poolshark.org Thu Jun 2 20:00:02 2005 From: denis at poolshark.org (Denis Leroy) Date: Thu, 02 Jun 2005 13:00:02 -0700 Subject: What next? In-Reply-To: References: <20050602032426.GA3626@imp.flyn.org> Message-ID: <429F6542.1060108@poolshark.org> Paul A. Houle wrote: > On Wed, 1 Jun 2005 22:24:26 -0500, W. Michael Petullo > wrote: > >> >> - Bugzilla #158657 Build totem's Mozilla plugin >> - Bugzilla #127537 Free software applet viewer plugin >> - Free software flash viewer? >> > > I hate to say it, but intellectual property restrictions make the > multimedia software shipped with Fedora a joke, which I end up > scrapping and replacing with stuff that plays media I get off the street. > > Ogg is great, for instance, and I rip CDs with ogg, but if I want > to listen to 99% of the audio streams out there, I need mp3, and > that's a matter of trashing the multimedia stuff that comes with Fedora > and replacing it. My flash mp3 player doesn't play ogg, and I'd > rather install some encoder software of questionably status than shell > out another $200 for one that does. > > I know you can't really do anything about it, but this underlying > problem makes improvements to multimedia players on Fedora like > rearraigning the deck chairs on the titanic. Has a high-ranked RedHat official ever tried calling Fraunhofer in Germany to negociate something ? Fraunhofer has always said they would not enfore the MP3 patents onto open-source and free projects. Maybe RHEL wouldn't qualify, but Fedora should be fine... From mike at navi.cx Thu Jun 2 20:02:50 2005 From: mike at navi.cx (Mike Hearn) Date: Thu, 02 Jun 2005 21:02:50 +0100 Subject: What next? References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <1117662394.31018.80.camel@cutter> <1117673495.29707.4.camel@otto.amantes> <1117738856.7932.33.camel@rousalka.dyndns.org> Message-ID: On Thu, 02 Jun 2005 21:00:42 +0200, Nicolas Mailhot wrote: > We don't have the ressources for the "one linux model" Given that reducing duplication would increase resources, I don't see why not. Look at it like this. Before the freedesktop.org efforts, KDE and GNOME didn't play so well together. There were two choices ahead of the community: 1) Tell users not to use KDE apps in GNOME or GNOME apps in KDE. If stuff breaks, it's their own fault, in other words 2) Standardise Fortunately, the desktop developers did 2 and now users benefit. Even better, the whole community benefits because people aren't pointlessly cloning each others apps anymore (well, not as much). Useful bits of code like the GtkQt theming engine fill in the bits that are easier to code than standardise. Right now for packaging you guys are choosing path (1). But it's worse than with desktops: there it was only really KDE vs GNOME, but here it's Fedora vs Ubuntu vs Gentoo vs Mandrake vs SUSE and so on. So the duplication of effort and cloning of each others work is much worse. In other words, Thomas is right, we need "1 Linux". Not one distro, but one set of standards people can write packages and installers to. thanks -mike From tibbs at math.uh.edu Thu Jun 2 20:08:11 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 02 Jun 2005 15:08:11 -0500 Subject: [PATCH] mkinitrd rescue mode In-Reply-To: <1117653405.12259.51.camel@barsoom.rdu.redhat.com> (Jeffrey Layton's message of "Wed, 01 Jun 2005 15:16:45 -0400") References: <1117653405.12259.51.camel@barsoom.rdu.redhat.com> Message-ID: >>>>> "JL" == Jeffrey Layton writes: JL> Essentially, I'm sending this to solicit some feedback on JL> it. Anyone have comments or concerns with this idea? I really like the idea. Often when there's a problem I don't want to go messing with the DHCP server to get a PXE load going (due the the screams from the hallway) and I have a couple of boxes on networks not under my control so that there's no chance of getting DHCP properly configured. Many will complain about initramfs bloat and those complaints are valid. But isn't the initramfs dynamically generated at kernel install time (or later if you call the right tool)? So let me decide (via /etc/sysconfig/mkinitrd or whatever) what stuff gets crammed into my initramfs and give me a boot flag to drop into it and I'm quite happy. - J< From mike at navi.cx Thu Jun 2 20:10:36 2005 From: mike at navi.cx (Mike Hearn) Date: Thu, 02 Jun 2005 21:10:36 +0100 Subject: What next? References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <1117672717.28429.297.camel@ernie> <1117736901.27637.45.camel@ernie> Message-ID: On Thu, 02 Jun 2005 14:28:21 -0400, Ed Hill wrote: > So when you've thrown out updates and completely eliminated any intra- > package dependencies, whats left? Nothing but a hollow GUI wrapper over > yet-another brain-dead application of /opt/${PACKAGE}. No, not at all. Read the links I posted, in particular the one about porting Linux apps. There are bits of magic here: - LaunchServices - Framework/bundle linking - Internet enabled DMGs Anyway, I'm not suggesting we implement appfolders like Apple did. We can do better (and don't have much choice anyway). See here: http://autopackage.org/ui-vision.html That describes how to implement a Mac style UI on top of Linux style package management. From katzj at redhat.com Thu Jun 2 20:17:22 2005 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 02 Jun 2005 16:17:22 -0400 Subject: [PATCH] mkinitrd rescue mode In-Reply-To: <1117731994.12259.68.camel@barsoom.rdu.redhat.com> References: <1117653405.12259.51.camel@barsoom.rdu.redhat.com> <1117725836.3768.15.camel@bree.local.net> <1117731994.12259.68.camel@barsoom.rdu.redhat.com> Message-ID: <1117743443.3768.37.camel@bree.local.net> On Thu, 2005-06-02 at 13:06 -0400, Jeffrey Layton wrote: > On Thu, 2005-06-02 at 11:23 -0400, Jeremy Katz wrote: > > This will have a relatively significant impact on the size of the > > initramfs and thus on the memory profile. Although I see it's not > > enabled by default, which is at least a plus It also won't handle > > filesystems other than ext3. > > > > This is just a proof-of-concept sort of thing at this stage. A better > patch would detect the filesystem type of / and copy the fsck for that > partition here. Then if you had other filesystems you could mount / and > use those. Note that only fsck.ext[23] are statically linked right now, which adds some complications. > This does increase the memory profile of the initramfs by about 1.5M. > Isn't that memory freed after the switchroot occurs, though? The impression I've gotten is that the memory isn't freed with initramfs since you can't actually unmount the original rootfs. > It's not enabled by default in this incarnation, but my preference would > be that it is in a later one. 1.5 M additional overhead on all installs is less than ideal. > > > This gives you some ability to troubleshoot booting problems, and gives > > > the ability to do some rescue-type work without having to boot to the > > > CD. This is a big plus for people that run boxes remotely and don't have > > > easy physical access to them. > > > > PXE, copying the pxeboot vmlinuz/initrd into your grub.conf and a few > > other things can give you a way to boot rescue mode without having to > > put in a CD. If you're having to run mkinitrd with different command > > line arguments, then you've already lost if you've really hosed your > > system badly. > > > > Honestly, I'd really rather see improvements to rescue mode than > > something like this. > > Both of those methods mean you'll be booting to a different kernel than > the one that is giving you problems. The main reason I rolled this patch > is to allow you to inspect (and possibly repair) the state of the system > when you're having problems booting. If you update to a new kernel, and > that kernel isn't detecting your drives correctly, then that is very > difficult to troubleshoot once you boot to a rescue kernel. If the kernel doesn't detect your drives correctly, then how exactly does this let you "repair" things? Most problems I've had are long before the driver is going to screw things up. Jeremy From pnasrat at redhat.com Thu Jun 2 20:20:09 2005 From: pnasrat at redhat.com (Paul Nasrat) Date: Thu, 02 Jun 2005 16:20:09 -0400 Subject: What next? In-Reply-To: References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <1117662394.31018.80.camel@cutter> <1117673495.29707.4.camel@otto.amantes> <1117738856.7932.33.camel@rousalka.dyndns.org> Message-ID: <1117743609.3133.24.camel@enki.eridu> On Thu, 2005-06-02 at 21:02 +0100, Mike Hearn wrote: > On Thu, 02 Jun 2005 21:00:42 +0200, Nicolas Mailhot wrote: > > We don't have the ressources for the "one linux model" > > Given that reducing duplication would increase resources, I don't see why > not. > Right now for packaging you guys are choosing path (1). But it's worse > than with desktops: there it was only really KDE vs GNOME, but here it's > Fedora vs Ubuntu vs Gentoo vs Mandrake vs SUSE and so on. So the > duplication of effort and cloning of each others work is much worse. Getting people to the table for packaging architecture stack is going to be hard. I'm certainly happy to talk to people, but there has to be serious enough interest on all sides. As far as the packaging cf freedesktop stuff goes, I spoke with some people a while back on this front. With fd.o a) the wheel was getting reinvented b) each party's implementation had something the other lacked and vice versa c) doing it within each project was causing integration issues Certainly you could argue similarly for packaging. > In other words, Thomas is right, we need "1 Linux". Not one distro, but > one set of standards people can write packages and installers to. Theoretically we have that with LSB packages but that's not the reality. If you are arguing for get people talking fine - point me at the list. The metadata list had some cross distribution interest and it's still ticking along, but keeping people co-operating is the hard one. The main obstacles are going to be convincing people that having shared components makes their life better. Some parts of the packaging fit into this, but it'll take some time. So point me at the list. Paul From jdesbonnet at gmail.com Thu Jun 2 20:21:19 2005 From: jdesbonnet at gmail.com (Joe Desbonnet) Date: Thu, 2 Jun 2005 21:21:19 +0100 Subject: Packaging idea (Re: What next?) In-Reply-To: <1117740683.7932.54.camel@rousalka.dyndns.org> References: <604aa791050601162840b05c06@mail.gmail.com> <604aa79105060120106eef01ae@mail.gmail.com> <1117686443.2702.9.camel@cutter> <604aa7910506012141650fbecf@mail.gmail.com> <1117740683.7932.54.camel@rousalka.dyndns.org> Message-ID: <1cef3e9505060213215a173824@mail.gmail.com> This is probably science fiction from FC's perspective, but I came across this interesting paper when researching software updates via binary patches recently: http://www.cs.uu.nl/people/eelco/pubs/eupfcdm-cbse2005-final.pdf Abstract. Safe and efficient deployment of software components is an important aspect of CBSE. The Nix deployment system enables side-by-side deployment of different versions and variants of components, complete installation, safe upgrades, and safe uninstalls through garbage collection. It accomplishes this through a purely functional deployment model, meaning that the file system content of a component only depends on the inputs used to build it, and never changes afterwards. An apparent downside to this model is that upgrading "fundamental" components used as build inputs by many other components becomes expensive, since all of these must be rebuilt and redeployed. In this paper we show that binary patching between sets of components enables efficient deployment of upgrades in the purely functional model, transparently to users. Sequences of patches can be combined automatically to enable upgrading between arbitrary versions. The approach was empirically validated. On 6/2/05, Nicolas Mailhot wrote: > Le jeudi 02 juin 2005 ? 01:03 -0400, Konstantin Ryabitsev a ?crit : > > > A super-package mechanism would help create a framework that would > > allow addressing the problems listed above. > > A super-package mechanism would add yet another layer of vendor mess > over the existing layers of vendor mess. > > Sometimes less is more. > > -- > Nicolas Mailhot > > > BodyID:264713259.2.n.logpart (stored separately) > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > > From chasd at silveroaks.com Thu Jun 2 20:32:50 2005 From: chasd at silveroaks.com (chasd at silveroaks.com) Date: Thu, 2 Jun 2005 15:32:50 -0500 Subject: What next? In-Reply-To: <20050602174303.ADE2E735F9@hormel.redhat.com> References: <20050602174303.ADE2E735F9@hormel.redhat.com> Message-ID: >>> Obviously, double-sided can be done right now. Are dual-layer >>> *readers* >>> really that popular these days? >> >> Am I missing some hidden joke here? All readers can do dual-layer. > > Yes, all DVD-ROM should do that. (But yes, some have trouble with those > burned in dual-layer dvd-burners) The main issue is that the only double-layer recordable media available on the street is DVD+R DL. There is some DVD-R DL out there now, but it is not common. The opposite was true of DVD readers, DVD dash whatever came out first, drives that can read DVD plus whatever came later. So if you have an older DVD reader ( DVD dash only ), it won't read DVD+R DL discs. If it is a stamped, duplicated double-layer disk ( DVD-9 ), _any_ DVD reader should work, and should be considered a bug in the reader if it doesn't. Charles Dostale System Admin - Silver Oaks Communications http://www.silveroaks.com/ 824 17th Street, Moline IL 61265 From Nicolas.Mailhot at laPoste.net Thu Jun 2 20:34:18 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 02 Jun 2005 22:34:18 +0200 Subject: What next? In-Reply-To: References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <1117662394.31018.80.camel@cutter> <1117673495.29707.4.camel@otto.amantes> <1117738856.7932.33.camel@rousalka.dyndns.org> Message-ID: <1117744458.7932.59.camel@rousalka.dyndns.org> Le jeudi 02 juin 2005 ? 21:02 +0100, Mike Hearn a ?crit : > On Thu, 02 Jun 2005 21:00:42 +0200, Nicolas Mailhot wrote: > > We don't have the ressources for the "one linux model" > > Given that reducing duplication would increase resources, I don't see why > not. Reducing duplication will increase the synchronisation burden. Even the Linux kernel uses the parallel tree development model, and it has almost no dependencies to speak of. -- Nicolas Mailhot -------------- 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 emily at atropine.ath.cx Thu Jun 2 20:35:09 2005 From: emily at atropine.ath.cx (Emily Brantley) Date: Thu, 02 Jun 2005 16:35:09 -0400 Subject: Google's Summer of Code Message-ID: <429F6D7D.5080406@atropine.ath.cx> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I haven't found anything regarding this in the archives, so I'd like to start discussion about Fedora Core's participation in the Google Summer of Code. Google has announced on their page here: http://code.google.com/summerofcode.html that Fedora Core is participating, but I couldn't find anymore information. While I'm a student, I know that not many of the developers or lurkers may be active students, though. Is any discussion taking place about it ? Maybe the first step is to publicize what ideas Fedora Core might like worked on, and what languages they prefer. Following some of the ideas linked for many other projects sounds like a good starting point. I'm not sure what projects there could be, but maybe we should chip in ideas ? Completely reworking and adding to system-config-* might be a nice one, and it's PyGTK so it would be relatively platform-agnostic (anybody could work on that). I don't know about others. If others could start giving ideas or filling in information about it, maybe we could make a page or wiki about it where further discussion could take place in more public view (something Google could link to). Thanks ! Em -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCn219l/fI0i0h13cRAjrNAJ97ycVqXeFi04UiHDMwMoWbRQDodwCfdpMc HE2hKcoPoTSNmBL8AzNWenM= =M9Mf -----END PGP SIGNATURE----- From jspaleta at gmail.com Thu Jun 2 20:40:28 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 2 Jun 2005 16:40:28 -0400 Subject: What next? In-Reply-To: <1cef3e9505060113142ede12fc@mail.gmail.com> References: <1cef3e9505060113142ede12fc@mail.gmail.com> Message-ID: <604aa79105060213404d0ee146@mail.gmail.com> On 6/1/05, Joe Desbonnet wrote: > Bandwidth friendly yum using binary delta algs. As seen in one of the fedora lists in march. A proof-of-concept proxy server that layers over yum. http://www.wombat.ie/software/rpmdc/releasenotes-0.1.0.html If the proxy server approach works, there is no reason why it can't be used as a general way to provide this functionality to the userbase that needs it without shoving support for deltas into yum itself. -jef From mattdm at mattdm.org Thu Jun 2 20:42:24 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 2 Jun 2005 16:42:24 -0400 Subject: What next? In-Reply-To: <429F6542.1060108@poolshark.org> References: <20050602032426.GA3626@imp.flyn.org> <429F6542.1060108@poolshark.org> Message-ID: <20050602204224.GA4938@jadzia.bu.edu> On Thu, Jun 02, 2005 at 01:00:02PM -0700, Denis Leroy wrote: > Has a high-ranked RedHat official ever tried calling Fraunhofer in Germany > to negociate something ? Fraunhofer has always said they would not enfore > the MP3 patents onto open-source and free projects. Maybe RHEL wouldn't > qualify, but Fedora should be fine... If RHEL doesn't qualify, then that would be an additional restriction forbidden by the GPL. Some-other-licensed MP3 player might get by with this, though. (However, it's not really in the spirit of Free / open source software.) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 79 degrees Fahrenheit. From jdesbonnet at gmail.com Thu Jun 2 21:02:15 2005 From: jdesbonnet at gmail.com (Joe Desbonnet) Date: Thu, 2 Jun 2005 22:02:15 +0100 Subject: What next? In-Reply-To: <604aa79105060213404d0ee146@mail.gmail.com> References: <1cef3e9505060113142ede12fc@mail.gmail.com> <604aa79105060213404d0ee146@mail.gmail.com> Message-ID: <1cef3e950506021402568791d2@mail.gmail.com> I'd be willing to maintain an diff archive for FC4. I need to update the software to use deltarpm by Michael Schroeder: this is an excellent piece of software that allows binary patches to be applied without having to keep the RPMs lying around (it computes deltas on a file by file basis, ignoring config files which are likely to change). There is one (minor) thing I don't like about deltarpm: the algorithm (while good) is hard coded into the format. It would be nice if the delta format allowed different algorithms to be used. Perhaps using VCDIFF (RFC 3284 - The VCDIFF Generic Differencing and Compression Data Format). Regarding the archive: I don't have a suitable FTP server. I estimate a max of about 1GB of storage would be needed. Joe. On 6/2/05, Jeff Spaleta wrote: > On 6/1/05, Joe Desbonnet wrote: > > Bandwidth friendly yum using binary delta algs. > > As seen in one of the fedora lists in march. A proof-of-concept proxy > server that layers over yum. > http://www.wombat.ie/software/rpmdc/releasenotes-0.1.0.html > > If the proxy server approach works, there is no reason why it can't be > used as a general way to provide this functionality to the userbase > that needs it without shoving support for deltas into yum itself. > > -jef > From brugolsky at telemetry-investments.com Thu Jun 2 21:04:36 2005 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Thu, 2 Jun 2005 17:04:36 -0400 Subject: [PATCH] mkinitrd rescue mode In-Reply-To: <1117743443.3768.37.camel@bree.local.net> References: <1117653405.12259.51.camel@barsoom.rdu.redhat.com> <1117725836.3768.15.camel@bree.local.net> <1117731994.12259.68.camel@barsoom.rdu.redhat.com> <1117743443.3768.37.camel@bree.local.net> Message-ID: <20050602210436.GA4357@ti64.telemetry-investments.com> Jeffrey, This is a nice start at fulfilling a request I made more than a year ago (that Jeremy dismissed): http://www.redhat.com/archives/fedora-devel-list/2004-January/msg00901.html On Thu, Jun 02, 2005 at 04:17:22PM -0400, Jeremy Katz wrote: > > This does increase the memory profile of the initramfs by about 1.5M. > > Isn't that memory freed after the switchroot occurs, though? > > The impression I've gotten is that the memory isn't freed with initramfs > since you can't actually unmount the original rootfs. One is expected to delete files before doing the switchroot. Unlike a ramdisk, the ramfs pages are immediately reclaimed. > > Both of those methods mean you'll be booting to a different kernel than > > the one that is giving you problems. The main reason I rolled this patch > > is to allow you to inspect (and possibly repair) the state of the system > > when you're having problems booting. If you update to a new kernel, and > > that kernel isn't detecting your drives correctly, then that is very > > difficult to troubleshoot once you boot to a rescue kernel. > > If the kernel doesn't detect your drives correctly, then how exactly > does this let you "repair" things? Most problems I've had are long > before the driver is going to screw things up. Potential uses: o Repairing a busted root logical volume (which can happen when snapshotting the root filesystem for example -- been there, done that). o Shrinking filesystems, including the root filesystem. The various resizers only allow for online growth. Having a simple method to create an initramfs image that includes tools plus their load dependencies (pulling in shared libraries, etc.), whatever the size, would be a win. One could decide what is useful locally and put it in a special initramfs image, e.g., /boot/initrd-$KVER-rescue.img With a remote filesystem mount (nfs, cifs, etc.) one could have access to a full set of tools with a simple "mount." Booting with grub is a simple matter of including a stanza for rescue, or editing the initrd line manually at the grub menu. Bill Rugolsky From jspaleta at gmail.com Thu Jun 2 21:09:29 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 2 Jun 2005 17:09:29 -0400 Subject: What next? In-Reply-To: <1cef3e950506021402568791d2@mail.gmail.com> References: <1cef3e9505060113142ede12fc@mail.gmail.com> <604aa79105060213404d0ee146@mail.gmail.com> <1cef3e950506021402568791d2@mail.gmail.com> Message-ID: <604aa7910506021409614df303@mail.gmail.com> On 6/2/05, Joe Desbonnet wrote: > Regarding the archive: I don't have a suitable FTP server. I estimate > a max of about 1GB > of storage would be needed. perhaps, some existing fedora mirrors would choose to work with you? Someone on the mirror list might be gracious enough to forward a brief proposal from you so individual mirror maintainers could contact you if they want to help provide support for your deltas. I have no idea if any of them will choose to help with this or not, but you never know.... -jef From jlayton at redhat.com Thu Jun 2 21:47:41 2005 From: jlayton at redhat.com (Jeff Layton) Date: Thu, 02 Jun 2005 17:47:41 -0400 Subject: [PATCH] mkinitrd rescue mode In-Reply-To: <20050602210436.GA4357@ti64.telemetry-investments.com> References: <1117653405.12259.51.camel@barsoom.rdu.redhat.com> <1117725836.3768.15.camel@bree.local.net> <1117731994.12259.68.camel@barsoom.rdu.redhat.com> <1117743443.3768.37.camel@bree.local.net> <20050602210436.GA4357@ti64.telemetry-investments.com> Message-ID: <1117748861.7178.26.camel@localhost.localdomain> > On Thu, Jun 02, 2005 at 04:17:22PM -0400, Jeremy Katz wrote: > > > This does increase the memory profile of the initramfs by about 1.5M. > > > Isn't that memory freed after the switchroot occurs, though? > > > > The impression I've gotten is that the memory isn't freed with initramfs > > since you can't actually unmount the original rootfs. > > One is expected to delete files before doing the switchroot. Unlike a ramdisk, > the ramfs pages are immediately reclaimed. > That shouldn't be too hard to handle then -- just delete busybox and fsck* before the switchroot. Even better would be if there were some way to get at the initramfs (is it mountable?) after the switchroot and clean the thing out entirely. > > If the kernel doesn't detect your drives correctly, then how exactly > > does this let you "repair" things? Most problems I've had are long > > before the driver is going to screw things up. > It won't let you repair anything in that particular case, but it at least would let you determine what the problem is. That's often very difficult. Being able to go into rescue mode and then from there being able to do: dmesg | more would be be very helpful. > Potential uses: > > o Repairing a busted root logical volume (which can happen when snapshotting > the root filesystem for example -- been there, done that). > > o Shrinking filesystems, including the root filesystem. > The various resizers only allow for online growth. > > Having a simple method to create an initramfs image that includes tools plus > their load dependencies (pulling in shared libraries, etc.), whatever the size, > would be a win. One could decide what is useful locally and put it in a > special initramfs image, e.g., > > /boot/initrd-$KVER-rescue.img > > With a remote filesystem mount (nfs, cifs, etc.) one could have access to > a full set of tools with a simple "mount." > > Booting with grub is a simple matter of including a stanza for rescue, or > editing the initrd line manually at the grub menu. > Bill makes a good point here. This doesn't have to be something used on every boot (though if we can clean out the initramfs then I don't see the harm). We could potentially generate 2 initrd's -- one "normal" and one "rescue", and then have separate grub entries for each. If we want to go with this, it might be best to think about just ditching nash and moving to using busybox instead. Most of the functions that nash does could be handled by the script, and other stuff we'd need (like switchroot) could be added to it. -- Jeff From felipe.alfaro at gmail.com Thu Jun 2 21:54:38 2005 From: felipe.alfaro at gmail.com (Felipe Alfaro Solana) Date: Thu, 2 Jun 2005 23:54:38 +0200 Subject: What next? LDAP In-Reply-To: <1117737488.7932.27.camel@rousalka.dyndns.org> References: <1117655635.6735.28.camel@dhollis-lnx.sunera.com> <83712260D48F4DF130523E0C@10.169.6.246> <6f6293f105060208054b1f69cb@mail.gmail.com> <1117737488.7932.27.camel@rousalka.dyndns.org> Message-ID: <6f6293f1050602145453222c1@mail.gmail.com> On 6/2/05, Nicolas Mailhot wrote: > > Single sign-on doesn't require a LDAP server, but some kind of central > > identity magament which can be supplied by using a Kerberos V KDC like > > the Kerberos V MIT implementation that comes in the form of krb5-* > > packages for Fedora Core. > > Kerberos is insufficient by itself. > 9 times out of ten if you're interested in SSO you want at least a > centralised adressbook too. The needs start snowballing pretty quickly. Yeah, I know... I simply stated that LDAP isn't a requirement, although it's pretty recommended. I have a small LAN at home and have been using Kerberos without LDAP with no problems. However, SSO without centralized identity management in SMEs can lead to serious security and organizational headaches. > The Microsoft implementation may be bad but they've understood the needs > of small to big corporations pretty well (for huge corporations their > offering does not scale but they'll be using their own ldap/kerberos > combo anyway). Microsoft implementation isn't that bad... what's bad is their closed-mind approach to getting things out of the door and their lock-in mentality. However, AD is a great idea and it's what we're currently lacking. > > An easy ldap/krb5 setup would be used starting from two computer > networks. Only licensing and complexity have active directory start > above SMEs. > We need easy SSO, adressbook, network conf, ical, file sharing > (thanksfully dhcp/dns, imap/smtp, ipp, http, sql and office software are > well covered now) Agree, but just make sure we don't make this a requisite: people should still be able to work without this kind of integration, if they wish. From brugolsky at telemetry-investments.com Thu Jun 2 22:10:30 2005 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Thu, 2 Jun 2005 18:10:30 -0400 Subject: [PATCH] mkinitrd rescue mode In-Reply-To: <20050602220838.GG21569@ti64.telemetry-investments.com> References: <1117653405.12259.51.camel@barsoom.rdu.redhat.com> <1117725836.3768.15.camel@bree.local.net> <1117731994.12259.68.camel@barsoom.rdu.redhat.com> <1117743443.3768.37.camel@bree.local.net> <20050602210436.GA4357@ti64.telemetry-investments.com> <1117748861.7178.26.camel@localhost.localdomain> <20050602220838.GG21569@ti64.telemetry-investments.com> Message-ID: <20050602221030.GH21569@ti64.telemetry-investments.com> [Resent; wrong From address last time.] > Bill makes a good point here. This doesn't have to be something used on > every boot (though if we can clean out the initramfs then I don't see > the harm). We could potentially generate 2 initrd's -- one "normal" and > one "rescue", and then have separate grub entries for each. > > If we want to go with this, it might be best to think about just > ditching nash and moving to using busybox instead. Most of the functions > that nash does could be handled by the script, and other stuff we'd need > (like switchroot) could be added to it. BTW, the initramfs standard allows for multiple cpio archives, so in principle, one could have an "addon" images. That's useful, because we want kernel modules in the the initrd-$KVER.img, but we could have a generic initrd-rescue.img that is loaded after it. Caveat: I haven't tried this, and don't know whether it actually works with current kernels. -Bill From Nicolas.Mailhot at laPoste.net Thu Jun 2 22:13:43 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Fri, 03 Jun 2005 00:13:43 +0200 Subject: What next? LDAP In-Reply-To: <6f6293f1050602145453222c1@mail.gmail.com> References: <1117655635.6735.28.camel@dhollis-lnx.sunera.com> <83712260D48F4DF130523E0C@10.169.6.246> <6f6293f105060208054b1f69cb@mail.gmail.com> <1117737488.7932.27.camel@rousalka.dyndns.org> <6f6293f1050602145453222c1@mail.gmail.com> Message-ID: <1117750423.7932.65.camel@rousalka.dyndns.org> Le jeudi 02 juin 2005 ? 23:54 +0200, Felipe Alfaro Solana a ?crit : > > We need easy SSO, adressbook, network conf, ical, file sharing > > (thanksfully dhcp/dns, imap/smtp, ipp, http, sql and office software are > > well covered now) > > Agree, but just make sure we don't make this a requisite: people > should still be able to work without this kind of integration, if they > wish. If it doesn't get in the way there will be little reason to avoid it (I know lean and mean is great, but lots of people do not care and waste cpu cycles on just about anything nowadays) Just look how many people run a small MTA nowadays. Regards, -- Nicolas Mailhot -------------- 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 hp at redhat.com Thu Jun 2 23:11:27 2005 From: hp at redhat.com (Havoc Pennington) Date: Thu, 02 Jun 2005 19:11:27 -0400 Subject: What next? In-Reply-To: <20050601202109.GA30198@devserv.devel.redhat.com> References: <1117655080.6271.52.camel@laptopd505.fenrus.org> <1117656479.5013.7.camel@localhost.localdomain> <20050601202109.GA30198@devserv.devel.redhat.com> Message-ID: <1117753887.8832.1.camel@localhost.localdomain> On Wed, 2005-06-01 at 22:21 +0200, Arjan van de Ven wrote: > pkg-config is fixable! > We need to teach it about -Wl,as-needed which causes the linker only to add > a lib when the app directly uses it. I don't really see why this should go in pkg-config... pkg-config isn't where we set default link flags for the distribution, it's a way to learn about specific libs. Why not just make ld do this by default, or put it in the rpm build config? Is there something we need to know about specific libraries when we decide whether we want as-needed? Havoc From mike at navi.cx Thu Jun 2 23:20:36 2005 From: mike at navi.cx (Mike Hearn) Date: Fri, 03 Jun 2005 00:20:36 +0100 Subject: What next? References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <1117662394.31018.80.camel@cutter> <1117673495.29707.4.camel@otto.amantes> <1117738856.7932.33.camel@rousalka.dyndns.org> <1117743609.3133.24.camel@enki.eridu> Message-ID: On Thu, 02 Jun 2005 16:20:09 -0400, Paul Nasrat wrote: > Getting people to the table for packaging architecture stack is going to > be hard. I'm certainly happy to talk to people, but there has to be > serious enough interest on all sides. OK, I'm really glad to hear that. Right now there is no such freedistro.org list. The idea has been kicked around before, but nobody seriously stepped up to do it. Rather than focus purely on packaging standards, I think it'd be better for such a group to eliminate pointless differences between distributions by producing a series of informal RFC type documents. I am meaning differences like some distros supporting /etc/profile.d and others not, or using different locations for LinuxThreads, or different ways of parallel installing libpng. That makes it easier to build packages that install anywhere reliably. Attempting to de-jure standardise some packaging technology probably won't go anywhere, the LSB tried that and it didn't work out too well. But by smoothing out distro differences, making "standard" packages becomes a lot simpler. If there is genuine interest in this, I'll bump it much nearer the top of my priority list. I don't mind trying to kick start such a forum, though I'd appreciate the thoughts of Havoc Pennington on this though. I think freedesktop.org just kind of grew out of the EWMH effort, but I wasn't around at that time. thanks -mike From hp at redhat.com Thu Jun 2 23:32:15 2005 From: hp at redhat.com (Havoc Pennington) Date: Thu, 02 Jun 2005 19:32:15 -0400 Subject: What next? In-Reply-To: References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <1117662394.31018.80.camel@cutter> <1117673495.29707.4.camel@otto.amantes> <1117738856.7932.33.camel@rousalka.dyndns.org> <1117743609.3133.24.camel@enki.eridu> Message-ID: <1117755135.8832.7.camel@localhost.localdomain> On Fri, 2005-06-03 at 00:20 +0100, Mike Hearn wrote: > > Rather than focus purely on packaging standards, I think it'd be better > for such a group to eliminate pointless differences between distributions > by producing a series of informal RFC type documents. I am meaning > differences like some distros supporting /etc/profile.d and others not, or > using different locations for LinuxThreads, or different ways of parallel > installing libpng. > Well, I did spend a lot of sweat trying to just get the libpng maintainers to eliminate that particular problem back when the problem appeared ;-) which would have been easier! > If there is genuine interest in this, I'll bump it much nearer the top of > my priority list. I don't mind trying to kick start such a forum, though > I'd appreciate the thoughts of Havoc Pennington on this though. I think > freedesktop.org just kind of grew out of the EWMH effort, but I wasn't > around at that time. What do you want my thinking on? freedesktop.org was not really based on EWMH, that I can remember. I started it by writing the mission statement: http://freedesktop.org/wiki/MissionStatement well, maybe it's been edited a bit over the years, I don't know. But it was roughly like that always. Havoc From mike at navi.cx Fri Jun 3 00:52:12 2005 From: mike at navi.cx (Mike Hearn) Date: Fri, 03 Jun 2005 01:52:12 +0100 Subject: What next? References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <1117662394.31018.80.camel@cutter> <1117673495.29707.4.camel@otto.amantes> <1117738856.7932.33.camel@rousalka.dyndns.org> <1117743609.3133.24.camel@enki.eridu> <1117755135.8832.7.camel@localhost.localdomain> Message-ID: On Thu, 02 Jun 2005 19:32:15 -0400, Havoc Pennington wrote: > What do you want my thinking on? freedesktop.org was not really based on > EWMH, that I can remember. I started it by writing the mission > statement: > http://freedesktop.org/wiki/MissionStatement > > well, maybe it's been edited a bit over the years, I don't know. But it > was roughly like that always. Well, to be honest, I'm not sure how to start. A website and a mailing list is fine, but you have to get the right people involved and sometimes they aren't so visible. I guess for KDE/GNOME that wasn't an issue but distro developers, especially for SUSE, can be quite hard to track down. And obviously there has to be something to work on ... some simple things that can be agreed on easily to get it up and running. I threw out some ideas there but there might be others that are more important. For one I'd love everyone to standardise on using pam_xauth, as then ISVs could just assume su works with X correctly instead of having tons of crappy hacks like now. But that may be asking a bit much. There's also the issue of being seen to be competing with the LSB. But I'm not sure anybody would really care about that. thanks -mike From daryll.strauss at gmail.com Fri Jun 3 02:36:33 2005 From: daryll.strauss at gmail.com (Daryll Strauss) Date: Thu, 02 Jun 2005 19:36:33 -0700 Subject: Zeroconf in FC5? Message-ID: <1117766193.4649.51.camel@ninja> I saw zeroconf in action at a Mac based facility a while back and I have to say I was impressed. It makes their networking setup very easy. The biggest downside was that they knew very little about how their network actually worked. That made my life integrating a Linux system in to their environment much more difficult. So, I'd like to see zeroconf really integrated in to FC5. I think it'll make network setup for a lot of users much easier. For those who don't know, zeroconf provides several functions: *) Dynamically allocating an IP address to a system when it boots (without requiring a DHCP server) *) Translate between names and IP addresses (without any setup or directory server) *) Allows for the publishing and discovery of services such as DNS, NFS, ftp, http, printers, whatever (without requiring any setup or directory server) *) Allocates multicast addresses (without a MADCAP server). (This part isn't yet supported and I'm not sure I know what it means :)) Fedora ships with Howl which looks to be the framework for doing zeroconf. It seems that what's needed is integrating howl in to all the appropriate places. - |Daryll From webmaster at margo.bijoux.nom.br Fri Jun 3 04:01:56 2005 From: webmaster at margo.bijoux.nom.br (Pedro Fernandes Macedo) Date: Fri, 03 Jun 2005 01:01:56 -0300 Subject: Google's Summer of Code In-Reply-To: <429F6D7D.5080406@atropine.ath.cx> References: <429F6D7D.5080406@atropine.ath.cx> Message-ID: <429FD634.9060800@margo.bijoux.nom.br> Emily Brantley wrote: >I'm not sure what projects there could be, but maybe we should chip in >ideas ? Completely reworking and adding to system-config-* might be a >nice one, and it's PyGTK so it would be relatively platform-agnostic >(anybody could work on that). > > > Ideas would be nice.. I was already looking at some at the ideas available , but couldnt come up with anything interesting and usefull.. And now that Fedora is one of the participating projects , that's one more reason to participate.. Time to give (more) back to the distro I like and use ;) -- Pedro Macedo Member of the Fedora Core pt_BR translation team From webmaster at margo.bijoux.nom.br Fri Jun 3 04:06:17 2005 From: webmaster at margo.bijoux.nom.br (Pedro Fernandes Macedo) Date: Fri, 03 Jun 2005 01:06:17 -0300 Subject: Google's Summer of Code In-Reply-To: <429FD634.9060800@margo.bijoux.nom.br> References: <429F6D7D.5080406@atropine.ath.cx> <429FD634.9060800@margo.bijoux.nom.br> Message-ID: <429FD739.90504@margo.bijoux.nom.br> Pedro Fernandes Macedo wrote: > Ideas would be nice.. I was already looking at some at the ideas > available , but couldnt come up with anything interesting and > usefull.. And now that Fedora is one of the participating projects , > that's one more reason to participate.. Time to give (more) back to > the distro I like and use ;) > > Just found out this page: http://fedoraproject.org/wiki/FedoraBounties Thanks Warren for putting some ideas there... I'll take a look on some of these ideas and try to come up with some good solutions for those problems (and try to get more volunteers ;D ) -- Pedro Macedo From emily at atropine.ath.cx Fri Jun 3 04:10:42 2005 From: emily at atropine.ath.cx (Emily Brantley) Date: Fri, 03 Jun 2005 00:10:42 -0400 Subject: Google's Summer of Code In-Reply-To: <429FD739.90504@margo.bijoux.nom.br> References: <429F6D7D.5080406@atropine.ath.cx> <429FD634.9060800@margo.bijoux.nom.br> <429FD739.90504@margo.bijoux.nom.br> Message-ID: <429FD842.2020906@atropine.ath.cx> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Just found out this page: http://fedoraproject.org/wiki/FedoraBounties > > Thanks Warren for putting some ideas there... I'll take a look on some > of these ideas and try to come up with some good solutions for those > problems (and try to get more volunteers ;D ) that definitely is what we needed. this thread could be a lightning-rod of sorts for proposing other ideas, i suppose, but i'll go look at that page now. thanks ! Em -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCn9hCl/fI0i0h13cRAg9dAJ9zlYqrtdBfRm0K/TU5fbruVjObXwCgjmO/ rnTUn42yCmU4QuX65iXl16g= =Gz3W -----END PGP SIGNATURE----- From steve at rueb.com Fri Jun 3 04:21:35 2005 From: steve at rueb.com (Steve Bergman) Date: Thu, 02 Jun 2005 23:21:35 -0500 Subject: What next? In-Reply-To: <1117730130.1674.3.camel@weasel.laiskiainen.org> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <1117730130.1674.3.camel@weasel.laiskiainen.org> Message-ID: <429FDACF.20608@rueb.com> Panu Matilainen wrote: >No such luck here, it sits there quite happily eating gobs of memory >until cowboys come home on all of my systems. > > - Panu - > > > > "chmod 700 /usr/bin/rhn-applet-gui" is standard procedure after *all* my installations. :-) Only root gets it then. Crude but effective. (Thanks, Alan!) -Steve Bergman From mattdm at mattdm.org Fri Jun 3 04:36:49 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 3 Jun 2005 00:36:49 -0400 Subject: What next? In-Reply-To: <429FDACF.20608@rueb.com> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <1117730130.1674.3.camel@weasel.laiskiainen.org> <429FDACF.20608@rueb.com> Message-ID: <20050603043649.GA19171@jadzia.bu.edu> On Thu, Jun 02, 2005 at 11:21:35PM -0500, Steve Bergman wrote: > "chmod 700 /usr/bin/rhn-applet-gui" is standard procedure after *all* my > installations. :-) > Only root gets it then. Crude but effective. Ow -- you're logging in to the GUI as root? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 79 degrees Fahrenheit. From steve at rueb.com Fri Jun 3 05:09:18 2005 From: steve at rueb.com (Steve Bergman) Date: Fri, 03 Jun 2005 00:09:18 -0500 Subject: What next? In-Reply-To: <20050603043649.GA19171@jadzia.bu.edu> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <1117730130.1674.3.camel@weasel.laiskiainen.org> <429FDACF.20608@rueb.com> <20050603043649.GA19171@jadzia.bu.edu> Message-ID: <429FE5FE.6010705@rueb.com> Matthew Miller wrote: > >Ow -- you're logging in to the GUI as root? > > > No. I just "yum update" at the command line. Leaving it where root *would* get it is just an aesthetic preference. -Steve From skvidal at phy.duke.edu Fri Jun 3 06:25:26 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 03 Jun 2005 02:25:26 -0400 Subject: What next? In-Reply-To: References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> Message-ID: <1117779926.3488.30.camel@cutter> > So my answer would be "if FC5 deadlines don't give you enough time to > complete a given piece of work, target FC6 instead". Not to be rude but why the hard headed attachment to 'WE MUST RELEASE EVERY 6 MONTHS'. The gnome people have recently said that new and interesting development has been stymied somewhat by that schedule and that development for gnome 3.0 is not going to fit into that schedule. > On the other hand, someone was also pointing out that there are some > pieces that really need to be worked on every single release, so it's more > complicated than that. Maybe we need to try to decouple development work > from the release cycle a bit more. What if we could make it so that > hardcore development work could go on throughout all six months of the > development cycle? I'd love to see how you do that given the available resources. I just don't see my time being any more available than it is currently. -sv From skvidal at phy.duke.edu Fri Jun 3 06:28:15 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 03 Jun 2005 02:28:15 -0400 Subject: What next? In-Reply-To: <429FDACF.20608@rueb.com> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <1117730130.1674.3.camel@weasel.laiskiainen.org> <429FDACF.20608@rueb.com> Message-ID: <1117780095.3488.32.camel@cutter> On Thu, 2005-06-02 at 23:21 -0500, Steve Bergman wrote: > Panu Matilainen wrote: > > >No such luck here, it sits there quite happily eating gobs of memory > >until cowboys come home on all of my systems. > > > > - Panu - > > > > > > > > > "chmod 700 /usr/bin/rhn-applet-gui" is standard procedure after *all* my > installations. :-) > > Only root gets it then. Crude but effective. > yum remove rhn-applet problem solved. -sv From arjanv at redhat.com Fri Jun 3 07:01:35 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Fri, 03 Jun 2005 09:01:35 +0200 Subject: What next? In-Reply-To: <1117753887.8832.1.camel@localhost.localdomain> References: <1117655080.6271.52.camel@laptopd505.fenrus.org> <1117656479.5013.7.camel@localhost.localdomain> <20050601202109.GA30198@devserv.devel.redhat.com> <1117753887.8832.1.camel@localhost.localdomain> Message-ID: <1117782096.6270.8.camel@laptopd505.fenrus.org> On Thu, 2005-06-02 at 19:11 -0400, Havoc Pennington wrote: > On Wed, 2005-06-01 at 22:21 +0200, Arjan van de Ven wrote: > > pkg-config is fixable! > > We need to teach it about -Wl,as-needed which causes the linker only to add > > a lib when the app directly uses it. > > I don't really see why this should go in pkg-config... pkg-config isn't > where we set default link flags for the distribution, it's a way to > learn about specific libs. > > Why not just make ld do this by default, or put it in the rpm build > config? Is there something we need to know about specific libraries when > we decide whether we want as-needed? it can't be default realistically and is a per lib thing: making it default prevents the situation where an app links to a library in order to provide this service for plugins. -------------- 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 shiva at sewingwitch.com Fri Jun 3 07:44:12 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Fri, 03 Jun 2005 00:44:12 -0700 Subject: What next? LDAP In-Reply-To: <429F4FE3.9010005@di.uminho.pt> References: <1117655635.6735.28.camel@dhollis-lnx.sunera.com> <83712260D48F4DF130523E0C@[10.169.6.246]> <429F4FE3.9010005@di.uminho.pt> Message-ID: <75207E04F01FB1BE766677C3@[10.169.6.246]> --On Thursday, June 02, 2005 7:28 PM +0100 Jos? Pedro Oliveira wrote: > The smbldap-tools scripts are already being distributed with samba > Unfortunately the scripts are being packaged as documentation by Red-Hat: > ># rpm -ql samba | grep smbldap-tools I stand corrected. Why are they bundled into Samba instead of shipped as a free-standing package? The upstream source (now at 0.9.1) includes its own spec file and packages fine on FC2. From veillard at redhat.com Fri Jun 3 07:59:38 2005 From: veillard at redhat.com (Daniel Veillard) Date: Fri, 3 Jun 2005 03:59:38 -0400 Subject: What next? In-Reply-To: <1117779926.3488.30.camel@cutter> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <1117779926.3488.30.camel@cutter> Message-ID: <20050603075938.GW20018@redhat.com> On Fri, Jun 03, 2005 at 02:25:26AM -0400, seth vidal wrote: > > > So my answer would be "if FC5 deadlines don't give you enough time to > > complete a given piece of work, target FC6 instead". > > Not to be rude but why the hard headed attachment to 'WE MUST RELEASE > EVERY 6 MONTHS'. The gnome people have recently said that new and > interesting development has been stymied somewhat by that schedule and This does not reflect at all un understanding of the GNOME community There is very strong backing for time based releases. There may be people with a different viewpoint, but it's certainly not "The gnome people". > that development for gnome 3.0 is not going to fit into that schedule. And most of the people around the GNOME community do not want a 3.0 revolutionary release, all I heard from GUADEC last week indicated otherwise. The point is that most people/companies prefer a graceful gradual shift than big point releases. This does not prevent big change, but it forces to still release and take into account the evolution. To me the counter example of Debian stable release shows clearly why a time based release schedule is very important for the community in general. You think your change will take too long to implement ? Then plan this over the time frame of multiple releases, really ! Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From skvidal at phy.duke.edu Fri Jun 3 08:09:05 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 03 Jun 2005 04:09:05 -0400 Subject: What next? In-Reply-To: <20050603075938.GW20018@redhat.com> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <1117779926.3488.30.camel@cutter> <20050603075938.GW20018@redhat.com> Message-ID: <1117786145.3488.84.camel@cutter> On Fri, 2005-06-03 at 03:59 -0400, Daniel Veillard wrote: > On Fri, Jun 03, 2005 at 02:25:26AM -0400, seth vidal wrote: > > > > > So my answer would be "if FC5 deadlines don't give you enough time to > > > complete a given piece of work, target FC6 instead". > > > > Not to be rude but why the hard headed attachment to 'WE MUST RELEASE > > EVERY 6 MONTHS'. The gnome people have recently said that new and > > interesting development has been stymied somewhat by that schedule and > > This does not reflect at all un understanding of the GNOME community > There is very strong backing for time based releases. There may be > people with a different viewpoint, but it's certainly not > "The gnome people". you're right. I misspoke. I was referring to what I had read in a series of blog entries on the subject. > The point is that most people/companies prefer a graceful gradual shift than > big point releases. This does not prevent big change, but it forces to > still release and take into account the evolution. To me the counter example of > Debian stable release shows clearly why a time based release schedule > is very important for the community in general. > You think your change will take too long to implement ? Then plan this over > the time frame of multiple releases, really ! I'm not arguing against a time based release. I'm arguing against the current time allotted for the release. So I think time based released are just fine - but not when it only allows about 2-3 months of actual time allotted to doing any development Can you see the distinction b/t the two? -sv From thomas at apestaart.org Fri Jun 3 08:57:46 2005 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Fri, 03 Jun 2005 10:57:46 +0200 Subject: What next? In-Reply-To: References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <1117662394.31018.80.camel@cutter> <1117673495.29707.4.camel@otto.amantes> <1117738856.7932.33.camel@rousalka.dyndns.org> Message-ID: <1117789066.7960.2.camel@otto.amantes> Hi, > In other words, Thomas is right, we need "1 Linux". Not one distro, but > one set of standards people can write packages and installers to. Just to clarify - I do not actually feel that we need "1 linux". I'm just saying that the reason things aren't as easy as on mac is because there is not just "1 linux". Personally, I'm completely fine with linux being a thriving ecosystem, and for daily use I stick to using Fedora + extras, knowing that this is a window on the larger ecosystem that Just Works. So what I'm saying is that user should choose their own "1 linux", be it fedora, ubuntu, suse, .... and live within the boundaries of that. I personally feel that homogenizing distros to the point where they're pretty much the same is a bad thing - I like how stuff gets fed back between distros and how some distros have different focus points and the good approaches tend to end up in all of them. In reality, Mac is not just "1 os" either, there's still plenty of people working on macos8, 9, ... Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> "Two million women and only one Flasheart..." <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From veillard at redhat.com Fri Jun 3 09:26:08 2005 From: veillard at redhat.com (Daniel Veillard) Date: Fri, 3 Jun 2005 05:26:08 -0400 Subject: What next? In-Reply-To: <1117786145.3488.84.camel@cutter> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <1117779926.3488.30.camel@cutter> <20050603075938.GW20018@redhat.com> <1117786145.3488.84.camel@cutter> Message-ID: <20050603092608.GY20018@redhat.com> On Fri, Jun 03, 2005 at 04:09:05AM -0400, seth vidal wrote: > I'm not arguing against a time based release. I'm arguing against the > current time allotted for the release. So I think time based released > are just fine - but not when it only allows about 2-3 months of actual > time allotted to doing any development > > Can you see the distinction b/t the two? Any duration will get people arguing whether it's too long or too short. To me 6 months is a 80/20 equilibrium point, plus it makes very easy to memorize and predict releases (one for the Summer, one for the Winter). Just skip one release, branch and you get 9 months to work without being disturbed too much. It seems to me that a fair amount of users follow that pattern too and don't update every 6 months, but every year or so (that would be an interesting poll to set up on the fedora web site I think). Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From db-fedora at 3di.it Fri Jun 3 09:46:50 2005 From: db-fedora at 3di.it (Davide Bolcioni) Date: Fri, 03 Jun 2005 11:46:50 +0200 Subject: RPM guidelines for vendors (was: Packaging idea) In-Reply-To: <604aa7910506012141650fbecf@mail.gmail.com> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <604aa79105060120106eef01ae@mail.gmail.com> <1117686443.2702.9.camel@cutter> <604aa7910506012141650fbecf@mail.gmail.com> Message-ID: <42A0270A.6010100@3di.it> Jeff Spaleta wrote: >>Yes, I cannot deny that the last 2 weeks spent packaging nonfree >>software has greatly influenced this post. :) That, plus the sad fact >>that even though several vendors provide .rpm files, they are utterly >>unusable because they try to be installable on as many things as >>possible, and always end up sucking on all. > > > so basically the fap layer is only really a target for nonfree > software... but clearly > its doomed to fail because the pre-existing conditions for it to be > used successfully are not going to be met > > if proprietary vendors can't package rpms correctly.. the fap layer > doesn't help. > if proprietary vendors can't create repos correctly.. the fap layer > doesn't help. > > I have very little faith in proprietary vendors doing either correctly. Are there guidelines for proprietary vendors to follow beyond the fedora.us Wiki and Mandrake's Howto (neither of which addresses yum repositories, unless my memory fails me) ? Maybe it's just a problem of the relevant information being too fragmented over too many mailing lists - in my own little corner of the universe, this is equivalent to "there is no documentation" for the proprietary software developer. Furthermore, but maybe it's just me, I've found that proprietary developers working under silly time constraints tend to skip "good practices" in the rush to finish *but* pay attention to avoiding known "bad practices", so maybe guidelines geared for vendor packaging should be in the form of "horror stories" - if you have suppressed the urge to rant about a glaring packaging blunder till now, I just gave you a justification :-) Thank you for your consideration, Davide Bolcioni From nphilipp at redhat.com Fri Jun 3 09:55:34 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 03 Jun 2005 11:55:34 +0200 Subject: What next? In-Reply-To: <1117782096.6270.8.camel@laptopd505.fenrus.org> References: <1117655080.6271.52.camel@laptopd505.fenrus.org> <1117656479.5013.7.camel@localhost.localdomain> <20050601202109.GA30198@devserv.devel.redhat.com> <1117753887.8832.1.camel@localhost.localdomain> <1117782096.6270.8.camel@laptopd505.fenrus.org> Message-ID: <1117792535.18370.0.camel@gibraltar.stuttgart.redhat.com> On Fri, 2005-06-03 at 09:01 +0200, Arjan van de Ven wrote: > On Thu, 2005-06-02 at 19:11 -0400, Havoc Pennington wrote: > > On Wed, 2005-06-01 at 22:21 +0200, Arjan van de Ven wrote: > > > pkg-config is fixable! > > > We need to teach it about -Wl,as-needed which causes the linker only to add > > > a lib when the app directly uses it. > > > > I don't really see why this should go in pkg-config... pkg-config isn't > > where we set default link flags for the distribution, it's a way to > > learn about specific libs. > > > > Why not just make ld do this by default, or put it in the rpm build > > config? Is there something we need to know about specific libraries when > > we decide whether we want as-needed? > > it can't be default realistically and is a per lib thing: > making it default prevents the situation where an app links to a library > in order to provide this service for plugins. Just curious: What is wrong with the idea that the plugins link the libraries they need? Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain 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 uraeus at gnome.org Fri Jun 3 10:17:57 2005 From: uraeus at gnome.org (Christian Fredrik Kalager Schaller) Date: Fri, 03 Jun 2005 12:17:57 +0200 Subject: pygtk in FC4 Message-ID: <1117793877.3435.29.camel@wildsrc.fluendo.lan> Hi, Any plans to get pygtk 2.6.1 (or 2.6.2) into FC4? There are some bugs in 2.6.0 which makes PiTiVi not work (the GStreamer based non-linear editor) which is fixed in 2.6.1. (2.6.0 code generator are broken) Christian From buildsys at redhat.com Fri Jun 3 11:32:15 2005 From: buildsys at redhat.com (Build System) Date: Fri, 3 Jun 2005 07:32:15 -0400 Subject: rawhide report: 20050603 changes Message-ID: <200506031132.j53BWFUn023782@porkchop.devel.redhat.com> Removed package autoconvert Updated Packages: audit-0.9.2-1 ------------- * Thu Jun 02 2005 Steve Grubb 0.9.2-1 - Step up to new glibc-kernheaders * Thu Jun 02 2005 Steve Grubb 0.9.1-1 - AUDITD_CLEAN_STOP config option in /etc/sysconfig/auditd - When unknown, show raw record in ausearch. - Add CWD message type support * Wed May 25 2005 Steve Grubb 0.9-1 - Translate numeric info to human readable for ausearch output - add '-if' option to ausearch to select input file - add '-c' option to ausearch to allow searching by comm field - init script now deletes all rules when daemon stops - Make auditctl display perms correctly in watch listings - Make auditctl -D remove all watches docbook-dtds-1.0-27 ------------------- * Thu Jun 02 2005 Tim Waugh 1.0-27 - Increase NAMELEN (bug #36058, bug #159382). rsync-2.6.5-2 ------------- * Thu Jun 02 2005 Jay Fenlason 2.6.5-2 - New upstream release * Tue May 17 2005 Jay Fenlason 2.6.5-0.pre1.0 - new upstream pre-release stunnel-4.10-2 -------------- * Wed Jun 01 2005 Miloslav Trmac - 4.10-2 - Fix inetd mode - Remove unnecessary Requires: and BuildRequires: - Clean up the spec file * Tue Apr 26 2005 Nalin Dahyabhai 4.10-1 - update to 4.10 xorg-x11-6.8.2-37 ----------------- * Mon May 30 2005 Mike A. Harris 6.8.2-37 - Implemented xorg-x11-6.8.2-redhat-kt.patch new kernel tainting diagnostics patch to aide in troubleshooting reported issues. - Removed older redhat-custom patch as the kt patch above replaces it now. - s/XFree86CustomVersion/XorgCustomVersion/ in host.def - Build for FC5 development. From nicolas.mailhot at laposte.net Fri Jun 3 11:49:18 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 3 Jun 2005 13:49:18 +0200 (CEST) Subject: RPM guidelines for vendors (was: Packaging idea) In-Reply-To: <42A0270A.6010100@3di.it> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <604aa79105060120106eef01ae@mail.gmail.com> <1117686443.2702.9.camel@cutter> <604aa7910506012141650fbecf@mail.gmail.com> <42A0270A.6010100@3di.it> Message-ID: <47914.192.54.193.37.1117799358.squirrel@rousalka.dyndns.org> On Ven 3 juin 2005 11:46, Davide Bolcioni a ?crit : > Maybe it's just a problem of the relevant information being too > fragmented over too many mailing lists - in my own little corner of the > universe, this is equivalent to "there is no documentation" for the > proprietary software developer. It's a problem of closed vendors treating Linux as a better windows than windows, or a better unix as solaris. Therefore they constantly bitch about the things they're used to and are not 100% identical, and completely ignore the genuinly different and innovative parts that evolved in Linux. Of which packaging is on the forefront. Vendors that genuinely believe Linux is here to stay and they need to be a player there fare on the whole better than the others. They're approaching the non-destructive rpm stage and will probably start releasing fine packages in two to three years. The others just need to be hit with the cluestick of people moving to other products, and they'll adapt (at a time they pushed motif - most of them have gotten over it now). All the proposed changes designed to have the core infrastructure behave like something it isn't only slow down this evolution while putting the burden of their mistakes on the rest of the system. Linux didn't get where it is now just because of the happy penguin. To take advantage of it you need to actually look at what's in the box. -- Nicolas Mailhot From e_mc_h2 at web.de Fri Jun 3 12:19:59 2005 From: e_mc_h2 at web.de (ness) Date: Fri, 03 Jun 2005 14:19:59 +0200 Subject: google summer of code Message-ID: <42A04AEF.9080309@web.de> I'm not actually using fredora, but I want to be active at the 'google summer of code'. I've got a strange idea for a project, and I think a distribution is the best organization to call. My project has not directly sth. to do with fredora, it's more 'distribution independ'. Would fredora like to be to mentoring organization for such a project? If so, I'd be happy to tell you more about my project. From ph18 at cornell.edu Fri Jun 3 12:33:35 2005 From: ph18 at cornell.edu (Paul A. Houle) Date: Fri, 03 Jun 2005 08:33:35 -0400 Subject: Zeroconf in FC5? In-Reply-To: <1117766193.4649.51.camel@ninja> References: <1117766193.4649.51.camel@ninja> Message-ID: On Thu, 02 Jun 2005 19:36:33 -0700, Daryll Strauss wrote: > > Fedora ships with Howl which looks to be the framework for doing > zeroconf. It seems that what's needed is integrating howl in to all the > appropriate places. > Although zeroconf looks like a good idea, the bogus entries that it created in our network routing tables were one of many red herrings we faced when debugging bizzare networking problems that were caused by a race condition in the 2.4 kernel that came with RHEL 3. A mac feature that's really fascinated me is the way that you can boot a mac into a mode where it functions as a firewire target. I've got an old PC that's getting abused by my toddler that I've been thinking of turning into an iSCSI target: I've been thinking of making a micro linux distribution, probably fedora based, that makes a machine into an iSCSI target. One application would be a 'storage appliance' for a SOHO environment, but another could be a specialized boot mode, that maybe lives on a small partition, that would let you boot a mainstream Linux system into a iSCSI target mode the same way a Mac can boot into firewire target mode -- there are concerns about security, and it would take some work to make a client so that this is 'plug-and-play' with another Linux box, but it would be a fun project and probably useful. Zeroconf would be a great way to make this happen. The storage appliance project faces the more serious problem that my home network (and many others) is heterogenous: i'd really like a global filesystem that works with Linux, MacOS and Windows, never mind a planned Solaris 10/x86 test machine and a stack of 32-bit and 64-bit SPARC machines that I'm going to install whatever OS I can to run on them. It's for that reason that iSCSI might wind up in the same dustbin as WAP and the fifth-generation computer... From ndbecker2 at gmail.com Fri Jun 3 12:34:02 2005 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 03 Jun 2005 08:34:02 -0400 Subject: Whither /usr/lib64/libfam.la? Message-ID: I just tried to build kyum-0.7.1, and got a link error, /usr/lib64/libfam.la not found. I see on FC3 this file exists: rpm -q -f /usr/lib64/libfam.la gamin-devel-0.0.25-1.FC3 It's missing from FC4 version: rpm -q gamin-devel gamin-devel-0.1.0-1 I think this is a big problem, because it seems other kde libs reference it. From ivazquez at ivazquez.net Fri Jun 3 12:42:01 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 03 Jun 2005 08:42:01 -0400 Subject: pygtk in FC4 In-Reply-To: <1117793877.3435.29.camel@wildsrc.fluendo.lan> References: <1117793877.3435.29.camel@wildsrc.fluendo.lan> Message-ID: <1117802521.14243.0.camel@ignacio.ignacio.lan> On Fri, 2005-06-03 at 12:17 +0200, Christian Fredrik Kalager Schaller wrote: > Any plans to get pygtk 2.6.1 (or 2.6.2) into FC4? There are some bugs in > 2.6.0 which makes PiTiVi not work (the GStreamer based non-linear > editor) which is fixed in 2.6.1. (2.6.0 code generator are broken) http://bugzilla.redhat.com/ -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 veillard at redhat.com Fri Jun 3 12:57:32 2005 From: veillard at redhat.com (Daniel Veillard) Date: Fri, 3 Jun 2005 08:57:32 -0400 Subject: Whither /usr/lib64/libfam.la? In-Reply-To: References: Message-ID: <20050603125732.GZ20018@redhat.com> On Fri, Jun 03, 2005 at 08:34:02AM -0400, Neal Becker wrote: > I just tried to build kyum-0.7.1, and got a link error, /usr/lib64/libfam.la > not found. I see on FC3 this file exists: > > rpm -q -f /usr/lib64/libfam.la > gamin-devel-0.0.25-1.FC3 > > It's missing from FC4 version: > rpm -q gamin-devel > gamin-devel-0.1.0-1 > > I think this is a big problem, because it seems other kde libs reference it. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159144 Those kde libraries should be rebuilt to not reference the .la, since as you discovered those reference are way too fragile (at least that's my understanding of the issue but I'm not a libtool specialist.) Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From kaboom at oobleck.net Fri Jun 3 12:56:12 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Fri, 3 Jun 2005 08:56:12 -0400 (EDT) Subject: What next? In-Reply-To: References: Message-ID: On Wed, 1 Jun 2005, Elliot Lee wrote: > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > Extras 5 - what major features are you willing to put effort into? I'd like to see Fedora Core continue to slim down, and apps which largely duplicate functionality continue to move into Extras One proposal: postfix in core, sendmail in extras. Vice-versa would be fine too, but I think Postfix makes more sense for core than sendmail - the design is more amenable to SELinux, and the configuration files are simpler for new users to parse Of course, really slimming core requires support for generating cds of extras.... later, chris From pmatilai at laiskiainen.org Fri Jun 3 13:14:34 2005 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Fri, 3 Jun 2005 06:14:34 -0700 (PDT) Subject: Whither /usr/lib64/libfam.la? In-Reply-To: <20050603125732.GZ20018@redhat.com> References: <20050603125732.GZ20018@redhat.com> Message-ID: On Fri, 3 Jun 2005, Daniel Veillard wrote: > On Fri, Jun 03, 2005 at 08:34:02AM -0400, Neal Becker wrote: >> I just tried to build kyum-0.7.1, and got a link error, /usr/lib64/libfam.la >> not found. I see on FC3 this file exists: >> >> rpm -q -f /usr/lib64/libfam.la >> gamin-devel-0.0.25-1.FC3 >> >> It's missing from FC4 version: >> rpm -q gamin-devel >> gamin-devel-0.1.0-1 >> >> I think this is a big problem, because it seems other kde libs reference it. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159144 > > Those kde libraries should be rebuilt to not reference the .la, since as > you discovered those reference are way too fragile (at least that's my > understanding of the issue but I'm not a libtool specialist.) >From what I've seen, ALL KDE packages require those .la files to be present, and not in the -devel package but in the main package. Drop the .la files and it wont even run. Don't ask me why.. :) - Panu - From johnp at redhat.com Fri Jun 3 13:18:02 2005 From: johnp at redhat.com (John (J5) Palmieri) Date: Fri, 03 Jun 2005 09:18:02 -0400 Subject: pygtk in FC4 In-Reply-To: <1117793877.3435.29.camel@wildsrc.fluendo.lan> References: <1117793877.3435.29.camel@wildsrc.fluendo.lan> Message-ID: <1117804682.21229.3.camel@localhost.localdomain> On Fri, 2005-06-03 at 12:17 +0200, Christian Fredrik Kalager Schaller wrote: > Hi, > Any plans to get pygtk 2.6.1 (or 2.6.2) into FC4? There are some bugs in > 2.6.0 which makes PiTiVi not work (the GStreamer based non-linear > editor) which is fixed in 2.6.1. (2.6.0 code generator are broken) > > Christian I will build it as an update. FC4 is frozen right now. Can you file a bug so I will not forget. Thanks. -- John (J5) Palmieri From mattdm at mattdm.org Fri Jun 3 13:20:04 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 3 Jun 2005 09:20:04 -0400 Subject: What next? In-Reply-To: <20050603092608.GY20018@redhat.com> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <1117779926.3488.30.camel@cutter> <20050603075938.GW20018@redhat.com> <1117786145.3488.84.camel@cutter> <20050603092608.GY20018@redhat.com> Message-ID: <20050603132004.GA30334@jadzia.bu.edu> On Fri, Jun 03, 2005 at 05:26:08AM -0400, Daniel Veillard wrote: > Just skip one release, branch and you get 9 months to work without being > disturbed too much. It seems to me that a fair amount of users follow that > pattern too and don't update every 6 months, but every year or so (that would > be an interesting poll to set up on the fedora web site I think). So, do you want Seth to contribute all the work he's been doing only to even-numbered Fedora releases? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 80 degrees Fahrenheit. From rdieter at math.unl.edu Fri Jun 3 13:16:43 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 03 Jun 2005 08:16:43 -0500 Subject: Whither /usr/lib64/libfam.la? In-Reply-To: <20050603125732.GZ20018@redhat.com> References: <20050603125732.GZ20018@redhat.com> Message-ID: Daniel Veillard wrote: > On Fri, Jun 03, 2005 at 08:34:02AM -0400, Neal Becker wrote: > >>I just tried to build kyum-0.7.1, and got a link error, /usr/lib64/libfam.la >>not found. I see on FC3 this file exists: >> >>rpm -q -f /usr/lib64/libfam.la >>gamin-devel-0.0.25-1.FC3 >> >>It's missing from FC4 version: >>rpm -q gamin-devel >>gamin-devel-0.1.0-1 >> >>I think this is a big problem, because it seems other kde libs reference it. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159144 > > Those kde libraries should be rebuilt to not reference the .la, since as > you discovered those reference are way too fragile Amen brother. Either rebuild or remove the references to to libfam.la from all /usr/lib/*.la files, perl -pi -e "s@/usr/lib/libfam.la@@" /usr/lib/*.la -- Rex From jspaleta at gmail.com Fri Jun 3 13:29:31 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 3 Jun 2005 09:29:31 -0400 Subject: RPM guidelines for vendors (was: Packaging idea) In-Reply-To: <42A026E1.6010002@3di.it> References: <604aa791050601162840b05c06@mail.gmail.com> <604aa79105060120106eef01ae@mail.gmail.com> <1117686443.2702.9.camel@cutter> <604aa7910506012141650fbecf@mail.gmail.com> <42A026E1.6010002@3di.it> Message-ID: <604aa79105060306297a496601@mail.gmail.com> On 6/3/05, Davide Bolcioni wrote: > Are there guidelines for proprietary vendors to follow beyond the > fedora.us Wiki and Mandrake's Howto (neither of which addresses yum > repositories, unless my memory fails me) ? First of all, fedora.us is most likely no longer as relevant as fedoraproject.org/wiki at this point in time. The fedoraproject wiki has a packaging guideline document... but it doesn't cover what a proprietary vendor would need to do to play nice with fedora. The document is focused on what an Extras contributor should be doing. There is no reason why there couldn't be a guidance document to outside vendors.. as soon as people interested in laying out the groundwork for the ideal external vender situation start discussing it. How about.. proprietary vendors get invovled in discussion inside the development community for the distros they are serving so they can continually be aware and have input of best practises? You know... talk to people. Linux distributions that have rapid release cycles <=1 year are evolving processes not static platform targets.. and that isn't going to change... because its inherent in how development throughout the projects that make up a modern distribution is done. Competing ideas fight it out in the linux ecosystem, and either get adopted widely.. or fail. Either way, its an evolving process not a static one. Hell.. whole distros are build around an 'innovative' approach to packaging. Standardization is always in tension with innovation. The absolute best way to build packages.. is to submit package spec files for review to other packagers. The packaging that wraps a proprietary product can certainly evolve on a different time scale than the actual payload development. Proprietary vendors could certaintly open up important sections of the spec file for community input and review. Outside the sections of the spec that deal with compilation.. which i'm pretty sure proprietary vendors probably short circuit anyways... other sections certaintly can't leak ip secrets. > Furthermore, but maybe it's just me, I've found that proprietary > developers working under silly time constraints tend to skip "good > practices" in the rush to finish *but* pay attention to avoiding > known "bad practices", so maybe guidelines geared for vendor > packaging should be in the form of "horror stories" - if you > have suppressed the urge to rant about a glaring packaging blunder till > now, I just gave you a justification :-) Or they can build bridges with the existing community of packagers.. and start having their packaging process reviewed and augmented by external community. Macromedia makes an attempt at this... http://sluglug.ucsc.edu/macromedia/site_ucsc.html and nvidia's license explicitly allows for external community to repackage and redistribute as needed. The big lesson that proprietary vendors need to realize is that they can tap into expert community skills at distro packaging... they just have to be willing to let external community touch the packaging layer. The THIN packaging layer doesn't need to stagnate on proprietary timescales.. nor do we need to re-invent packaging..again. Vendor's need to be just open enough to allow the community to repackage their payloads in a way that keeps pace with the evolution of distribution. -jef"all this..and only one cup of coffee"spaleta From rdieter at math.unl.edu Fri Jun 3 13:26:56 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 03 Jun 2005 08:26:56 -0500 Subject: Whither /usr/lib64/libfam.la? In-Reply-To: References: <20050603125732.GZ20018@redhat.com> Message-ID: Panu Matilainen wrote: > From what I've seen, ALL KDE packages require those .la files to be > present, and not in the -devel package but in the main package. Drop the > .la files and it wont even run. Don't ask me why.. :) KDE WORKSFORME without libfam.la (and has for ages). -- Rex From jspaleta at gmail.com Fri Jun 3 13:35:29 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 3 Jun 2005 09:35:29 -0400 Subject: What next? In-Reply-To: References: Message-ID: <604aa79105060306352e229d06@mail.gmail.com> On 6/3/05, Chris Ricker wrote: > Of course, really slimming core requires support for generating cds of > extras.... Does anyone have any contacts with 3rd party media vendors like for example cheapbytes? If someone is going to tackle how to split up extras into cd sized chunks.. clearly media vendors as well as lugs are going to end up being the primary consumers of those media images and then they would in turn redistributed to users. I think ideally you would want some input from media vendors as to what would be ideal for them. -jef From jspaleta at gmail.com Fri Jun 3 13:44:12 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 3 Jun 2005 09:44:12 -0400 Subject: What next? In-Reply-To: <20050603092608.GY20018@redhat.com> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <1117779926.3488.30.camel@cutter> <20050603075938.GW20018@redhat.com> <1117786145.3488.84.camel@cutter> <20050603092608.GY20018@redhat.com> Message-ID: <604aa7910506030644aa7547e@mail.gmail.com> On 6/3/05, Daniel Veillard wrote: > (that would > be an interesting poll to set up on the fedora web site I think). I'd love a more useful central website! Red Hat sort of needs to make time between releases though to redo it. So how about.. 2 extras months... before fc5 testing begins.. to work on things like the website.. and the community build system. So those things can be in place for the fc5 cycle. -jef From sundaram at redhat.com Fri Jun 3 13:48:38 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 03 Jun 2005 19:18:38 +0530 Subject: What next? In-Reply-To: <604aa7910506030644aa7547e@mail.gmail.com> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <1117779926.3488.30.camel@cutter> <20050603075938.GW20018@redhat.com> <1117786145.3488.84.camel@cutter> <20050603092608.GY20018@redhat.com> <604aa7910506030644aa7547e@mail.gmail.com> Message-ID: <42A05FB6.4090507@redhat.com> Jeff Spaleta wrote: >On 6/3/05, Daniel Veillard wrote: > > >>(that would >>be an interesting poll to set up on the fedora web site I think). >> >> > >I'd love a more useful central website! >Red Hat sort of needs to make time between releases though to redo it. >So how about.. 2 extras months... before fc5 testing begins.. to work >on things like the website.. and the community build system. So those >things can be in place for the fc5 cycle. > > Join the Fedora marketing list and propose your ideas. Expect some good ideas to pop up in that list pretty soon regards Rahul From jspaleta at gmail.com Fri Jun 3 13:57:54 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 3 Jun 2005 09:57:54 -0400 Subject: dkms coreward for fc5? (was Re: What next?) In-Reply-To: References: Message-ID: <604aa7910506030657111cdd8d@mail.gmail.com> On 6/1/05, Elliot Lee wrote: > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > Extras 5 - what major features are you willing to put effort into? Now that dkms is in Extras... and fc4 has kernel modules in Core. How about for fc5 we put dkms in Core and have the kernel modules in Core use dkms to alleviate some of the sync issues we saw this time around in rawhide. I know the kernel module maintainer in Core is trying hard to keep on the ball about keeping up with the kernel builds, and I have no doubts that kernel module packages in Core will be made available asap after an update kernel is released... but i don't think thats always going to be simultaneous. dkms could really help out and provide the client side stopgap during the hours when a critical kernel update comes out and a new set of clustering kernel module packages are built and available for updating. This also sets up the groundwork for providing useful kernel modules in Extras. I fully expect future kernel modules in Extras to lag a kernel update by a day or two, and having dkms in Core for Extras packagers to rely on to provide a client side module rebuild in the lagtime would be useful. And.. I'm willing to actually help test and implement this with regard to the core kernel module packages. -jef"is really just hoping for a heated technical debate"spaleta From nphilipp at redhat.com Fri Jun 3 14:07:05 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 03 Jun 2005 16:07:05 +0200 Subject: google summer of code In-Reply-To: <42A04AEF.9080309@web.de> References: <42A04AEF.9080309@web.de> Message-ID: <1117807625.23296.37.camel@gibraltar.stuttgart.redhat.com> On Fri, 2005-06-03 at 14:19 +0200, ness wrote: > I'm not actually using fredora, but I want to be active at the 'google > summer of code'. I've got a strange idea for a project, and I think a > distribution is the best organization to call. My project has not > directly sth. to do with fredora, it's more 'distribution independ'. > Would fredora like to be to mentoring organization for such a project? > If so, I'd be happy to tell you more about my project. Chicken and egg problem here, people probably can't answer unless they know more about your proposal. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain 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 seyman at wanadoo.fr Fri Jun 3 13:27:33 2005 From: seyman at wanadoo.fr (Emmanuel Seyman) Date: Fri, 3 Jun 2005 15:27:33 +0200 Subject: What next? In-Reply-To: <20050603132004.GA30334@jadzia.bu.edu> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <1117779926.3488.30.camel@cutter> <20050603075938.GW20018@redhat.com> <1117786145.3488.84.camel@cutter> <20050603092608.GY20018@redhat.com> <20050603132004.GA30334@jadzia.bu.edu> Message-ID: <20050603132733.GA7927@orient.maison.moi> On Fri, Jun 03, 2005 at 09:20:04AM -0400, Matthew Miller wrote: > > So, do you want Seth to contribute all the work he's been doing only to > even-numbered Fedora releases? If the changes are too big to be done in six months (and I seriously doubt all Seth's work qualifies), sure. Why not? Emmanuel From e_mc_h2 at web.de Fri Jun 3 14:23:32 2005 From: e_mc_h2 at web.de (ness) Date: Fri, 03 Jun 2005 16:23:32 +0200 Subject: google summer of code In-Reply-To: <1117807625.23296.37.camel@gibraltar.stuttgart.redhat.com> References: <42A04AEF.9080309@web.de> <1117807625.23296.37.camel@gibraltar.stuttgart.redhat.com> Message-ID: <42A067E4.7010005@web.de> Nils Philippsen wrote: >On Fri, 2005-06-03 at 14:19 +0200, ness wrote: > > >>I'm not actually using fredora, but I want to be active at the 'google >>summer of code'. I've got a strange idea for a project, and I think a >>distribution is the best organization to call. My project has not >>directly sth. to do with fredora, it's more 'distribution independ'. >>Would fredora like to be to mentoring organization for such a project? >>If so, I'd be happy to tell you more about my project. >> >> > >Chicken and egg problem here, people probably can't answer unless they >know more about your proposal. > >Nils > > OK, if I understand you right, I shall tell more about my project. My first question was wether fredora would mentor a project not directly connected to the fredora distribution. But more about my proposal: The idea is an udev based authentication using an usb-stick. This means following: I put the stick into the pc, then, if a loginmanger is started, it will automaticly open a graphical session. If not, a shell based session will start. I think I could add interesting expands to that, such as automaticly open encrypted devices... I'd realize this (means: writing patches for common dm, write the udev rule and so on) and write config tools. If you want, I sent you a complete spec of what I'd be going to do. From matthew at nocturnal.org Fri Jun 3 14:34:10 2005 From: matthew at nocturnal.org (Matthew Lenz) Date: Fri, 03 Jun 2005 09:34:10 -0500 Subject: What next? In-Reply-To: <1117780095.3488.32.camel@cutter> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <1117730130.1674.3.camel@weasel.laiskiainen.org> <429FDACF.20608@rueb.com> <1117780095.3488.32.camel@cutter> Message-ID: <1117809250.8385.11.camel@mlenzdesktop> On Fri, 2005-06-03 at 02:28 -0400, seth vidal wrote: > On Thu, 2005-06-02 at 23:21 -0500, Steve Bergman wrote: > > Panu Matilainen wrote: > > > > >No such luck here, it sits there quite happily eating gobs of memory > > >until cowboys come home on all of my systems. > > > > > > - Panu - > > > > > > > > > > > > > > "chmod 700 /usr/bin/rhn-applet-gui" is standard procedure after *all* my > > installations. :-) > > > > Only root gets it then. Crude but effective. > > > > yum remove rhn-applet > > problem solved. I hate to admit it but I remove all the redhat update stuff as well and use yum or apt-get (if i'm feeling impatient). I used ubuntu for awhile (but ultimately found fedora to be superior) and found their update functionality much more usable. > -sv > > From nphilipp at redhat.com Fri Jun 3 15:31:55 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 03 Jun 2005 17:31:55 +0200 Subject: google summer of code In-Reply-To: <42A067E4.7010005@web.de> References: <42A04AEF.9080309@web.de> <1117807625.23296.37.camel@gibraltar.stuttgart.redhat.com> <42A067E4.7010005@web.de> Message-ID: <1117812715.23296.88.camel@gibraltar.stuttgart.redhat.com> On Fri, 2005-06-03 at 16:23 +0200, ness wrote: > Nils Philippsen wrote: > > >On Fri, 2005-06-03 at 14:19 +0200, ness wrote: > > > > > >>I'm not actually using fredora, but I want to be active at the 'google > >>summer of code'. I've got a strange idea for a project, and I think a > >>distribution is the best organization to call. My project has not > >>directly sth. to do with fredora, it's more 'distribution independ'. > >>Would fredora like to be to mentoring organization for such a project? > >>If so, I'd be happy to tell you more about my project. > >> > >> > > > >Chicken and egg problem here, people probably can't answer unless they > >know more about your proposal. > > > >Nils > > > > > OK, if I understand you right, I shall tell more about my project. My > first question was wether fredora would mentor a project not directly > connected to the fredora distribution. But more about my proposal: > The idea is an udev based authentication using an usb-stick. This means > following: I put the stick into the pc, then, if a loginmanger is > started, it will automaticly open a graphical session. If not, a shell > based session will start. I think I could add interesting expands to > that, such as automaticly open encrypted devices... I'd realize this > (means: writing patches for common dm, write the udev rule and so on) > and write config tools. If you want, I sent you a complete spec of what > I'd be going to do. This sounds interesting, consider auto-locking of the session (via xscreensaver and/or vlock) when the USB stick is removed (just a random idea I've been carrying around with me for a while). I could imagine that you could do that within the "Fedora project space", but I'm not the one doing decisions. Anybody else? Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain 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 mattdm at mattdm.org Fri Jun 3 15:34:35 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 3 Jun 2005 11:34:35 -0400 Subject: What next? In-Reply-To: <20050603132733.GA7927@orient.maison.moi> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <1117779926.3488.30.camel@cutter> <20050603075938.GW20018@redhat.com> <1117786145.3488.84.camel@cutter> <20050603092608.GY20018@redhat.com> <20050603132004.GA30334@jadzia.bu.edu> <20050603132733.GA7927@orient.maison.moi> Message-ID: <20050603153435.GA2169@jadzia.bu.edu> On Fri, Jun 03, 2005 at 03:27:33PM +0200, Emmanuel Seyman wrote: > > So, do you want Seth to contribute all the work he's been doing only to > > even-numbered Fedora releases? > If the changes are too big to be done in six months (and I seriously > doubt all Seth's work qualifies), sure. Why not? Have you looked at everything Seth's been doing for Extras? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 81 degrees Fahrenheit. From skvidal at phy.duke.edu Fri Jun 3 15:37:55 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 03 Jun 2005 11:37:55 -0400 Subject: What next? In-Reply-To: <20050603153435.GA2169@jadzia.bu.edu> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <1117779926.3488.30.camel@cutter> <20050603075938.GW20018@redhat.com> <1117786145.3488.84.camel@cutter> <20050603092608.GY20018@redhat.com> <20050603132004.GA30334@jadzia.bu.edu> <20050603132733.GA7927@orient.maison.moi> <20050603153435.GA2169@jadzia.bu.edu> Message-ID: <1117813075.22965.12.camel@opus.phy.duke.edu> On Fri, 2005-06-03 at 11:34 -0400, Matthew Miller wrote: > On Fri, Jun 03, 2005 at 03:27:33PM +0200, Emmanuel Seyman wrote: > > > So, do you want Seth to contribute all the work he's been doing only to > > > even-numbered Fedora releases? > > If the changes are too big to be done in six months (and I seriously > > doubt all Seth's work qualifies), sure. Why not? > > Have you looked at everything Seth's been doing for Extras? > it's not just me. But that's the point, isn't it. Even the folks inside rh need more time to work on things b/c b/t rhel update releases and everything else, the time is just tight. -sv From jspaleta at gmail.com Fri Jun 3 15:45:34 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 3 Jun 2005 11:45:34 -0400 Subject: google summer of code In-Reply-To: <1117812715.23296.88.camel@gibraltar.stuttgart.redhat.com> References: <42A04AEF.9080309@web.de> <1117807625.23296.37.camel@gibraltar.stuttgart.redhat.com> <42A067E4.7010005@web.de> <1117812715.23296.88.camel@gibraltar.stuttgart.redhat.com> Message-ID: <604aa791050603084566f64981@mail.gmail.com> On 6/3/05, Nils Philippsen wrote: > This sounds interesting, consider auto-locking of the session (via > xscreensaver and/or vlock) when the USB stick is removed (just a random > idea I've been carrying around with me for a while). I could imagine > that you could do that within the "Fedora project space", but I'm not > the one doing decisions. Anybody else? Do you allow mutliple sticks? and multiple sessions? locking sessions as sticks are removed and adding new sessions when a new stick is inserted? If so how do you switch between sessions? How do you handle device permissions in the case of multiple console sessions? The switch between sessions problem is a problem we already have. gdmflexiserver exists and is useful to do multiple sessions. It even activates the screensaver lock when you swtich over to a new or different session. So when you move back to the previous session you have to provide a password. BUT.. we don't have a graphical mechanism to switch back and forth between sessions and must use the ALT+CTL+F# magic to navigate back and forth. Once you hit the locked session screen.. there is no way to navigate out of that to another session without using the 3 finger salute. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=128758 -jef From seyman at wanadoo.fr Fri Jun 3 15:54:44 2005 From: seyman at wanadoo.fr (Emmanuel Seyman) Date: Fri, 3 Jun 2005 17:54:44 +0200 Subject: What next? In-Reply-To: <20050603153435.GA2169@jadzia.bu.edu> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <1117779926.3488.30.camel@cutter> <20050603075938.GW20018@redhat.com> <1117786145.3488.84.camel@cutter> <20050603092608.GY20018@redhat.com> <20050603132004.GA30334@jadzia.bu.edu> <20050603132733.GA7927@orient.maison.moi> <20050603153435.GA2169@jadzia.bu.edu> Message-ID: <20050603155444.GA8537@orient.maison.moi> On Fri, Jun 03, 2005 at 11:34:35AM -0400, Matthew Miller wrote: > > Have you looked at everything Seth's been doing for Extras? He's been doing a lot but I don't see how this relates to the subject. Some projects will make major releases every six months, some projects will do them in longer periods of time and some projects will do them when they feel like it. How is this a problem? Emmanuel From mattdm at mattdm.org Fri Jun 3 16:03:43 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 3 Jun 2005 12:03:43 -0400 Subject: What next? In-Reply-To: <1117813075.22965.12.camel@opus.phy.duke.edu> References: <1117689174.2702.28.camel@cutter> <1117779926.3488.30.camel@cutter> <20050603075938.GW20018@redhat.com> <1117786145.3488.84.camel@cutter> <20050603092608.GY20018@redhat.com> <20050603132004.GA30334@jadzia.bu.edu> <20050603132733.GA7927@orient.maison.moi> <20050603153435.GA2169@jadzia.bu.edu> <1117813075.22965.12.camel@opus.phy.duke.edu> Message-ID: <20050603160343.GA3331@jadzia.bu.edu> On Fri, Jun 03, 2005 at 11:37:55AM -0400, seth vidal wrote: > > Have you looked at everything Seth's been doing for Extras? > it's not just me. Right, sorry to pick on you -- you're just a highly-visible example and you started the subthread. It's pretty much EVERY outside contributor to Fedora. > But that's the point, isn't it. Even the folks inside rh need more time > to work on things b/c b/t rhel update releases and everything else, the > time is just tight. And sure, I think it'd help inside people too. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 81 degrees Fahrenheit. From i.pilcher at comcast.net Fri Jun 3 16:49:16 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Fri, 03 Jun 2005 11:49:16 -0500 Subject: What next? In-Reply-To: <20050602204224.GA4938@jadzia.bu.edu> References: <20050602032426.GA3626@imp.flyn.org> <429F6542.1060108@poolshark.org> <20050602204224.GA4938@jadzia.bu.edu> Message-ID: Matthew Miller wrote: > If RHEL doesn't qualify, then that would be an additional restriction > forbidden by the GPL. Some-other-licensed MP3 player might get by with this, > though. (However, it's not really in the spirit of Free / open source > software.) Which means that it couldn't be included in Fedora (Core or Extras) either. -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From felipe.alfaro at gmail.com Fri Jun 3 16:53:59 2005 From: felipe.alfaro at gmail.com (Felipe Alfaro Solana) Date: Fri, 3 Jun 2005 18:53:59 +0200 Subject: Zeroconf in FC5? In-Reply-To: References: <1117766193.4649.51.camel@ninja> Message-ID: <6f6293f10506030953345a3e8a@mail.gmail.com> On 6/3/05, Paul A. Houle wrote: > The storage appliance project faces the more serious problem that my home > network (and many others) is heterogenous: i'd really like a global > filesystem that works with Linux, MacOS and Windows, never mind a > planned Solaris 10/x86 test machine and a stack of 32-bit and 64-bit SPARC > machines that I'm going to install whatever OS I can to run on them. NFS? Samba? ;-) > It's for that reason that iSCSI might wind up in the same dustbin as WAP and > the fifth-generation computer... Ups! Then FAT32? No, seriously, I'd hope for some kind of universal, local filesystem. From notting at redhat.com Fri Jun 3 17:02:42 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 3 Jun 2005 13:02:42 -0400 Subject: Fedora Core 4 delayed until June 13 Message-ID: <20050603170242.GC6057@nostromo.devel.redhat.com> Due to some unforseen complications, Fedora Core 4 is now scheduled for general availability on June 13. We apologize for the inconvenience. Bill From nman64 at n-man.com Fri Jun 3 17:18:51 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Fri, 03 Jun 2005 12:18:51 -0500 Subject: Red Hat to create Fedora Foundation Message-ID: <42A090FB.2060601@n-man.com> For all those who haven't heard: http://www.eweek.com/article2/0,1759,1823403,00.asp -- Patrick "The N-Man" Barnes nman64 at n-man.com www.n-man.com -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From caillon at redhat.com Fri Jun 3 17:35:53 2005 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 03 Jun 2005 13:35:53 -0400 Subject: What next? In-Reply-To: <200506021630.48520@carola.nyarlathotep> References: <200506021630.48520@carola.nyarlathotep> Message-ID: <42A094F9.3020207@redhat.com> Aph wrote: > Le Mercredi 1 Juin 2005 19:59, Elliot Lee a ?crit : > >>Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora >>Extras 5 - what major features are you willing to put effort into? > > > A gnome navigator by defaut : firefox is not a good choice : it's in english > only and many localisation don't work. I added quite a few localizations installed by default into Fedora Core 4's version of Firefox. Try firefox-1.0.4-4 or later. From the changelog: - Add support for locales: af-ZA, ast-ES, ca-AD, cs-CZ, cy-GB, da-DK, de-DE, el-GR, en-GB es-AR, es-ES, eu-ES, fi-FI, fr-FR, ga-IE, he-IL, hu-HU, it-IT, ko-KR, ja-JP, ja-JPM, mk-MK, nb-NO, nl-NL, pa-IN, pl-PL, pt-BR, pt-PT, ro-RO, ru-RU, sk-SK, sl-SI, sq-AL, sv-SE, tr-TR, zh-CN, zh-TW > Galeon or Epiphany are better choice for remplace Mozilla by defaut. Is your only complaints about Mozilla/Firefox the language issue? If you strongly feel that those browsers are better choices, you should qualify those with reasons to back your statement up. Making general statements is no way to fix the issue. If I know what's wrong, I can address it properly. Thanks From i.pilcher at comcast.net Fri Jun 3 17:34:09 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Fri, 03 Jun 2005 12:34:09 -0500 Subject: Fedora Core 4 delayed until June 13 In-Reply-To: <20050603170242.GC6057@nostromo.devel.redhat.com> References: <20050603170242.GC6057@nostromo.devel.redhat.com> Message-ID: Bill Nottingham wrote: > Due to some unforseen complications, Fedora Core 4 is now > scheduled for general availability on June 13. We apologize for > the inconvenience. Everything is proceeding as I have forseen it. -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From skvidal at phy.duke.edu Fri Jun 3 17:42:07 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 03 Jun 2005 13:42:07 -0400 Subject: What next? In-Reply-To: <20050603155444.GA8537@orient.maison.moi> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <1117779926.3488.30.camel@cutter> <20050603075938.GW20018@redhat.com> <1117786145.3488.84.camel@cutter> <20050603092608.GY20018@redhat.com> <20050603132004.GA30334@jadzia.bu.edu> <20050603132733.GA7927@orient.maison.moi> <20050603153435.GA2169@jadzia.bu.edu> <20050603155444.GA8537@orient.maison.moi> Message-ID: <1117820528.22965.24.camel@opus.phy.duke.edu> On Fri, 2005-06-03 at 17:54 +0200, Emmanuel Seyman wrote: > On Fri, Jun 03, 2005 at 11:34:35AM -0400, Matthew Miller wrote: > > > > Have you looked at everything Seth's been doing for Extras? > > He's been doing a lot but I don't see how this relates to the subject. > > Some projects will make major releases every six months, some projects > will do them in longer periods of time and some projects will do them > when they feel like it. > > How is this a problem? b/c a fair bit of the stuff I, and others are working on, get tied up in each other. So if project X takes two release cycles then projects Y and Z have to wait for project X. The projects are not islands unto themselves. They have to be taken in the context of other items. -sv From skvidal at phy.duke.edu Fri Jun 3 17:43:41 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 03 Jun 2005 13:43:41 -0400 Subject: What next? In-Reply-To: <1117809250.8385.11.camel@mlenzdesktop> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <1117730130.1674.3.camel@weasel.laiskiainen.org> <429FDACF.20608@rueb.com> <1117780095.3488.32.camel@cutter> <1117809250.8385.11.camel@mlenzdesktop> Message-ID: <1117820621.22965.26.camel@opus.phy.duke.edu> > I hate to admit it but I remove all the redhat update stuff as well and > use yum or apt-get (if i'm feeling impatient). I used ubuntu for awhile > (but ultimately found fedora to be superior) and found their update > functionality much more usable. when fc4 comes out with yum 2.3.X in it - I'd like to hear your take on if yum is still coming out slower than apt for your use. some very smart people have made it faster in many different ways. -sv From e_mc_h2 at web.de Fri Jun 3 18:09:58 2005 From: e_mc_h2 at web.de (ness) Date: Fri, 03 Jun 2005 20:09:58 +0200 Subject: google summer of code In-Reply-To: <1117812715.23296.88.camel@gibraltar.stuttgart.redhat.com> References: <42A04AEF.9080309@web.de> <1117807625.23296.37.camel@gibraltar.stuttgart.redhat.com> <42A067E4.7010005@web.de> <1117812715.23296.88.camel@gibraltar.stuttgart.redhat.com> Message-ID: <42A09CF6.3060000@web.de> Hm, pam_usb looks interesting. But there are some things I don't like: -you have to enter your username first -It's pam based - some guys don't like this -It looks too big for something simple at all -I think pam isn't the right place to do sth. like that, because it only authenticates. It can't do any additional things like open an encrypted device or so But pam has some nice things that make it a goog place for sth.: -much applications use it, so there're no patches needed at all -it really does the authentication, so you don't need to safe the real pass on the usbstick and can work with public/private keys All in all I think it's better to write a new, not pam-based usblogin using ipc, udev (OK, not all guys use udev, but I think it's the future, pam isn't I think) and patches for the dm (theese aren't so much at all, right?) I thought to logout the user, if the usbstick is removed not locking the session, but this only a config option I think... OK, how ever, you've to decide whether you'd like to mentor this project. From kyrre at solution-forge.net Fri Jun 3 18:21:57 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Fri, 03 Jun 2005 20:21:57 +0200 Subject: google summer of code In-Reply-To: <42A067E4.7010005@web.de> References: <42A04AEF.9080309@web.de> <1117807625.23296.37.camel@gibraltar.stuttgart.redhat.com> <42A067E4.7010005@web.de> Message-ID: <1117822916.3355.7.camel@localhost.localdomain> fre, 03.06.2005 kl. 16.23 skrev ness: > Nils Philippsen wrote: > > >On Fri, 2005-06-03 at 14:19 +0200, ness wrote: > > > > > >>I'm not actually using fredora, but I want to be active at the 'google > >>summer of code'. I've got a strange idea for a project, and I think a > >>distribution is the best organization to call. My project has not > >>directly sth. to do with fredora, it's more 'distribution independ'. > >>Would fredora like to be to mentoring organization for such a project? > >>If so, I'd be happy to tell you more about my project. > >> > >> > > > >Chicken and egg problem here, people probably can't answer unless they > >know more about your proposal. > > > >Nils > > > > > OK, if I understand you right, I shall tell more about my project. My > first question was wether fredora would mentor a project not directly > connected to the fredora distribution. But more about my proposal: > The idea is an udev based authentication using an usb-stick. This means > following: I put the stick into the pc, then, if a loginmanger is > started, it will automaticly open a graphical session. If not, a shell > based session will start. I think I could add interesting expands to > that, such as automaticly open encrypted devices... I'd realize this > (means: writing patches for common dm, write the udev rule and so on) > and write config tools. If you want, I sent you a complete spec of what > I'd be going to do. Interesting :) Could the users homedir lie encrypted on such a device (say, a standard usb memory stick), and when presented with such a stick, the machine would ask for the users password (witch would also be the encryption key, and log the user in? Could be really usefull for simple setups with many users - say a school, or a village in India. With this setup, they could hand out such sticks to student, witch they could plug into any computer to login, or take home to retrive his/her data. Some linux/windows/mac-based "client" must then be aviable to decrypt data.) What about some kind of personal authentification using a gpg-key on the stick? Problem is that if you have the stick, you should not be able to retrive the key... But if the stick works as a decryption device (the computer sends data to stick, stick decrypts using on-board CPU, sticks sends unencrypted data to computer) - but that would require some HW hacking. Kyrre From ph18 at cornell.edu Fri Jun 3 18:23:46 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Fri, 3 Jun 2005 14:23:46 -0400 (EDT) Subject: Zeroconf in FC5? In-Reply-To: <6f6293f10506030953345a3e8a@mail.gmail.com> References: <1117766193.4649.51.camel@ninja> <6f6293f10506030953345a3e8a@mail.gmail.com> Message-ID: <1654.128.84.103.66.1117823026.squirrel@128.84.103.66> > On 6/3/05, Paul A. Houle wrote: >> The storage appliance project faces the more serious problem >> that my home >> network (and many others) is heterogenous: i'd really like a global >> filesystem that works with Linux, MacOS and Windows, never mind a >> planned Solaris 10/x86 test machine and a stack of 32-bit and 64-bit >> SPARC >> machines that I'm going to install whatever OS I can to run on them. > > NFS? Samba? ;-) Global filesystem, not network filesystem. iSCSI works at the block level: a global filesystem is one where a number of computers can share a block device and all make updates to the filesystem without trashing it. Redhat bought Sistina and makes one (GPL) that works w/ Linux. In principle, an iSCSI target takes 3-5 times less CPU power to run than NFS does. Also, NFS sucks in a number of ways, performance isn't really that good, filesystem semantics aren't quite right. Advocates of iSCSI think that iSCSI appliances would appeal to people in the SOHO market, but the lack of a universal filesystem makes that a pipe dream. (+manageability problems) Yeah, I could configure my extra machine as an NFS or Samba server, but that's not much of a hacking projhect. (If I do do this project, I probably will install GFS, have it mount itself and provide NFS and Samba to the non-Linux machines on the network.) Half of this is about screwing around w/ iSCSI, the other half is evaluation of GFS which we might want to use for a cluster system a few years from now. From e_mc_h2 at web.de Fri Jun 3 18:29:40 2005 From: e_mc_h2 at web.de (ness) Date: Fri, 03 Jun 2005 20:29:40 +0200 Subject: google summer of code In-Reply-To: <1117822916.3355.7.camel@localhost.localdomain> References: <42A04AEF.9080309@web.de> <1117807625.23296.37.camel@gibraltar.stuttgart.redhat.com> <42A067E4.7010005@web.de> <1117822916.3355.7.camel@localhost.localdomain> Message-ID: <42A0A194.704@web.de> An HTML attachment was scrubbed... URL: From denis at poolshark.org Fri Jun 3 18:43:03 2005 From: denis at poolshark.org (Denis Leroy) Date: Fri, 03 Jun 2005 11:43:03 -0700 Subject: What next? In-Reply-To: <42A094F9.3020207@redhat.com> References: <200506021630.48520@carola.nyarlathotep> <42A094F9.3020207@redhat.com> Message-ID: <42A0A4B7.301@poolshark.org> Christopher Aillon wrote: >> Galeon or Epiphany are better choice for remplace Mozilla by defaut. > > > Is your only complaints about Mozilla/Firefox the language issue? If > you strongly feel that those browsers are better choices, you should > qualify those with reasons to back your statement up. Making general > statements is no way to fix the issue. If I know what's wrong, I can > address it properly. As much as i like Firefox, it is not a Gnome application. It has lots of settings that are direct duplicates of Gnome global settings (Proxy, Fonts, ...). Firefox doesn't quit when i type 'Ctrl-Q', you can't detach the menu bars, nor change the menu shortcuts. You can't use Firefox to view HTML directly into a Nautilus window (only Galeon can do this). Those are just a few differences that come to mind. -denis From denis at poolshark.org Fri Jun 3 18:52:38 2005 From: denis at poolshark.org (Denis Leroy) Date: Fri, 03 Jun 2005 11:52:38 -0700 Subject: What next? In-Reply-To: References: <20050602032426.GA3626@imp.flyn.org> <429F6542.1060108@poolshark.org> <20050602204224.GA4938@jadzia.bu.edu> Message-ID: <42A0A6F6.6000905@poolshark.org> Ian Pilcher wrote: > Matthew Miller wrote: > >> If RHEL doesn't qualify, then that would be an additional restriction >> forbidden by the GPL. Some-other-licensed MP3 player might get by with >> this, >> though. (However, it's not really in the spirit of Free / open source >> software.) > > > Which means that it couldn't be included in Fedora (Core or Extras) > either. This doesn't look obvious to me. I know the way the GPL and Patents interact is always a source of debate, but the GPL specifies "If, as a consequence of a court judgment or allegation of patent infringement..., conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License...". The whole point here would be to get Fraunhofer to give 'written promise' to not sue the newly founded non-profit Fedora Foundation, then there will not be any 'court judgments' or 'allegations' to speak of that would bother the GPL... See this interesting read at http://www.phptr.com/articles/article.asp?p=353550&seqNum=14&rl=1 -denis From cmadams at hiwaay.net Fri Jun 3 18:54:21 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 3 Jun 2005 13:54:21 -0500 Subject: What next? In-Reply-To: <42A0A4B7.301@poolshark.org> References: <200506021630.48520@carola.nyarlathotep> <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> Message-ID: <20050603185421.GF1343147@hiwaay.net> Once upon a time, Denis Leroy said: > As much as i like Firefox, it is not a Gnome application. > ... > Firefox doesn't quit when i type 'Ctrl-Q', Neither do lots of GNOME applications, which is quite annoying. I thought maybe GNOME had decided you weren't supposed to quit applications and had deprecated that keyboard shortcut. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From skvidal at phy.duke.edu Fri Jun 3 18:56:58 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 03 Jun 2005 14:56:58 -0400 Subject: What next? In-Reply-To: <20050603185421.GF1343147@hiwaay.net> References: <200506021630.48520@carola.nyarlathotep> <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> Message-ID: <1117825018.7091.0.camel@cutter> On Fri, 2005-06-03 at 13:54 -0500, Chris Adams wrote: > Once upon a time, Denis Leroy said: > > As much as i like Firefox, it is not a Gnome application. > > ... > > Firefox doesn't quit when i type 'Ctrl-Q', > > Neither do lots of GNOME applications, which is quite annoying. I > thought maybe GNOME had decided you weren't supposed to quit > applications and had deprecated that keyboard shortcut. > If you don't close applications then the startup time is that much faster.... :) /me runs. -sv From cmadams at hiwaay.net Fri Jun 3 18:58:53 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 3 Jun 2005 13:58:53 -0500 Subject: What next? In-Reply-To: <42A0A6F6.6000905@poolshark.org> References: <20050602032426.GA3626@imp.flyn.org> <429F6542.1060108@poolshark.org> <20050602204224.GA4938@jadzia.bu.edu> <42A0A6F6.6000905@poolshark.org> Message-ID: <20050603185853.GG1343147@hiwaay.net> Once upon a time, Denis Leroy said: > otherwise) that contradict the conditions of this License...". The whole > point here would be to get Fraunhofer to give 'written promise' to not sue > the newly founded non-profit Fedora Foundation, then there will not be any > 'court judgments' or 'allegations' to speak of that would bother the GPL... Read the rest of that section of the GPL: For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program. So if Fraunhofer allows any GPL distribution, anyone can take that code (or a derived work) and distribute it under the terms of the GPL (which means that Red Hat or TiVo for example can sell it without paying license feeds to Fraunhofer). Under the terms of the GPL, Fraunhofer cannot allow free/non-commercial distribution and restrict commercial distribution of the same code. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From cmadams at hiwaay.net Fri Jun 3 19:02:21 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 3 Jun 2005 14:02:21 -0500 Subject: What next? In-Reply-To: <1117825018.7091.0.camel@cutter> References: <200506021630.48520@carola.nyarlathotep> <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> Message-ID: <20050603190221.GH1343147@hiwaay.net> Once upon a time, seth vidal said: > If you don't close applications then the startup time is that much > faster.... :) Well, for the first couple of dozen apps anyway. :-) I didn't actually notice Firefox didn't support ^Q for a while, because I typically leave a few xterms and a browser running all the time. I noticed the missing ^Q short-cut with gpdf and ggv first. ISTR others, but I don't remember the names off the top of my head. -- 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 Jun 3 19:24:38 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 3 Jun 2005 15:24:38 -0400 Subject: What next? In-Reply-To: <20050603185853.GG1343147@hiwaay.net> References: <20050602032426.GA3626@imp.flyn.org> <429F6542.1060108@poolshark.org> <20050602204224.GA4938@jadzia.bu.edu> <42A0A6F6.6000905@poolshark.org> <20050603185853.GG1343147@hiwaay.net> Message-ID: <604aa79105060312245ac7377a@mail.gmail.com> On 6/3/05, Chris Adams wrote: > So if Fraunhofer allows any GPL distribution, anyone can take that code > (or a derived work) and distribute it under the terms of the GPL (which > means that Red Hat or TiVo for example can sell it without paying > license feeds to Fraunhofer). Under the terms of the GPL, Fraunhofer > cannot allow free/non-commercial distribution and restrict commercial > distribution of the same code. If this issue was about Fraunhofers rights and responsbilities as a "copyright" holder to GPL code you'd be sort of right.. but the issue isn't about "copyrights" its about "patents". Fraunhofer has not released a single piece of code "copyrighted" under the GPL. The issue is about the "patents" Fraunhofer holds, and Fraunhofter can absolutely grant their patent as they deem fit regardless of what the GPL "copyright" license says. Do not confuse patents with copyrights.. they are distinctly different legal concepts. Fraunhofer is not a party to any GPL "copyright" license for any code that uses concepts from the associated "patents." Fraunhofer's actions with regard how it licenses its "patents" are not bound by the "copyright" restrictions GPL places works under its "copyright" protections. The GPL puts restrictions on the actions of redistributors of the GPL "copyrighted" work. If a "patent" holder prevents redistribution to any individual.. then the GPL says noone is allow to redistribute. The GPL does not restrict the actions of the "patent" holder in any way.. it restricts redistribution of the "copyrighted" work to prevent privledged redistribution. Fraunhofer can attempt to play favorites with its patents all it wants...but the GPL prevents anyone from taking advantage of Fraunhofer's actions. If there was a BSD "copyright" licensed implementation out there for mp3, that would change things considerable. BSD "copyright" license is perfectly compatible with non-commercial use "patent" licenses like what Fraunhofer currently allows. -jef"dials up groklaw and signs chris up for the next GPL-101 class"spaleta From kyrre at solution-forge.net Fri Jun 3 20:14:30 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Fri, 03 Jun 2005 22:14:30 +0200 Subject: Fedora Core 4 delayed until June 13 In-Reply-To: <20050603170242.GC6057@nostromo.devel.redhat.com> References: <20050603170242.GC6057@nostromo.devel.redhat.com> Message-ID: <1117829669.3355.9.camel@localhost.localdomain> fre, 03.06.2005 kl. 19.02 skrev Bill Nottingham: > Due to some unforseen complications, Fedora Core 4 is now > scheduled for general availability on June 13. We apologize for > the inconvenience. > > Bill What where the complications? From skvidal at phy.duke.edu Fri Jun 3 20:16:30 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 03 Jun 2005 16:16:30 -0400 Subject: Fedora Core 4 delayed until June 13 In-Reply-To: <1117829669.3355.9.camel@localhost.localdomain> References: <20050603170242.GC6057@nostromo.devel.redhat.com> <1117829669.3355.9.camel@localhost.localdomain> Message-ID: <1117829790.7091.12.camel@cutter> On Fri, 2005-06-03 at 22:14 +0200, Kyrre Ness Sjobak wrote: > fre, 03.06.2005 kl. 19.02 skrev Bill Nottingham: > > Due to some unforseen complications, Fedora Core 4 is now > > scheduled for general availability on June 13. We apologize for > > the inconvenience. > > > > Bill > > > What where the complications? > vetting the name for the release through legal. not that anyone ever USES the name for anything, but hey, names are fun, sorta. -sv From mike at flyn.org Fri Jun 3 20:16:26 2005 From: mike at flyn.org (W. Michael Petullo) Date: Fri, 3 Jun 2005 15:16:26 -0500 (CDT) Subject: pam_ccreds and Fedora Message-ID: <3153.66.151.13.100.1117829786.squirrel@zero.voxel.net> >> I have been using Fedora Core's pam_ccreds package to allow my laptop to >> authenticate users even when it is disconnected from my network's LDAP >> server[1]. Recently, logging in to my computer when disconnected began >> to fail. >> >> It seems that I was incorrectly relying on nscd to cache information for >> long periods of time. Bug 150748 fixed nscd, but made it difficult to >> abuse it in the way I require. >> >> After doing some research, I found nss_updatedb, a utility that maintains >> a local cache of network directory user and group information. However, >> nss_updatedb is not included in Fedora Core. >> >> What is the preferred way to use pam_ccreds on Fedora? Is anyone else >> using this PAM module? Is nss_updatedb a prerequisite and, if so, will >> it be packaged for Fedora? >> >> I think disconnected authentication is an important feature for Fedora >> and would like to help work on it. > You don't really need nss_updatedb, in fact nss_updatedb is totally > unusable in *big* environments), nscd does all the necessary caching as > of FC3 and beyond. What IS missing is integration of pam_ccreds into > authconfig. There's a bug about it somewhere in RH bugzilla and > apparently there's been (an RH internal) patch to authconfig floating > around to add the support for configuring pam_ccreds, too bad it hasn't > made the broad daylights so far despite me asking on a few occasions :-/ I have been having trouble with nscd. If connect my laptop to my network, then nscd seems to fill its caches. Disconnecting my laptop from my network and trying an "id -gn" works. But if I later boot my laptop while connected to a different network (but where my LDAP server is not available), then nscd seems to forget about the groups it had cached. "id -gn" now fails. I have set the timeout values on the cache data to several days. Is there a way to directly print the data contained in the nscd cache ("nscd -g" does not really help)? I have been using the pam_ccreds module fine for quite a while but caching name information has been flakey. There does not seem to be too much documentation published about this. Some related bugs: 151914 -- pam_ccreds + xscreensaver (I hope to provide a fix soon). 145044 -- pam_ccreds + authconfig -- Mike From kyrre at solution-forge.net Fri Jun 3 20:32:20 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Fri, 03 Jun 2005 22:32:20 +0200 Subject: What next? In-Reply-To: <604aa79105060312245ac7377a@mail.gmail.com> References: <20050602032426.GA3626@imp.flyn.org> <429F6542.1060108@poolshark.org> <20050602204224.GA4938@jadzia.bu.edu> <42A0A6F6.6000905@poolshark.org> <20050603185853.GG1343147@hiwaay.net> <604aa79105060312245ac7377a@mail.gmail.com> Message-ID: <1117830739.3355.13.camel@localhost.localdomain> *snip* > If > there was a BSD "copyright" licensed implementation out there for mp3, > that would change things considerable. BSD "copyright" license is > perfectly compatible with non-commercial use "patent" licenses like > what Fraunhofer currently allows. So that somebody would write a BSD gstreamer mp3 plugin, and RH would call Fraunhofer and get the goahead for Fedora - it would be OK (but they would have to pay fraunhofer for distributing the same plugin with RHEL?)? From jspaleta at gmail.com Fri Jun 3 20:40:06 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 3 Jun 2005 16:40:06 -0400 Subject: What next? In-Reply-To: <1117830739.3355.13.camel@localhost.localdomain> References: <20050602032426.GA3626@imp.flyn.org> <429F6542.1060108@poolshark.org> <20050602204224.GA4938@jadzia.bu.edu> <42A0A6F6.6000905@poolshark.org> <20050603185853.GG1343147@hiwaay.net> <604aa79105060312245ac7377a@mail.gmail.com> <1117830739.3355.13.camel@localhost.localdomain> Message-ID: <604aa7910506031340417a455e@mail.gmail.com> On 6/3/05, Kyrre Ness Sjobak wrote: > So that somebody would write a BSD gstreamer mp3 plugin, and RH would > call Fraunhofer and get the goahead for Fedora - it would be OK I said the existence of a BSD codebase would be compatible with the patent situation whereas the GPL codebases are not by virtue of restrictions that the GPL places regarding redistribution. I did not say a BSD licensed plugin to gst would be acceptable in terms of licensing arrangements (though gstreamer is lgpl so it seems likely). I did not say that RH would choose to allow any such code base in Fedora Core or Extras. -jef From nphilipp at redhat.com Fri Jun 3 20:41:15 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 03 Jun 2005 22:41:15 +0200 Subject: What next? In-Reply-To: <1117830739.3355.13.camel@localhost.localdomain> References: <20050602032426.GA3626@imp.flyn.org> <429F6542.1060108@poolshark.org> <20050602204224.GA4938@jadzia.bu.edu> <42A0A6F6.6000905@poolshark.org> <20050603185853.GG1343147@hiwaay.net> <604aa79105060312245ac7377a@mail.gmail.com> <1117830739.3355.13.camel@localhost.localdomain> Message-ID: <1117831276.3319.7.camel@gibraltar.stuttgart.redhat.com> On Fri, 2005-06-03 at 22:32 +0200, Kyrre Ness Sjobak wrote: > *snip* > > If > > there was a BSD "copyright" licensed implementation out there for mp3, > > that would change things considerable. BSD "copyright" license is > > perfectly compatible with non-commercial use "patent" licenses like > > what Fraunhofer currently allows. > > So that somebody would write a BSD gstreamer mp3 plugin, and RH would > call Fraunhofer and get the goahead for Fedora - it would be OK (but > they would have to pay fraunhofer for distributing the same plugin with > RHEL?)? But is that what we want? To enable anybody to just take Fedora and distribute it -- for free or for money -- we don't want to include software with specific license exemptions for us. Having a patent license exemption only for the project wouldn't be different in my eyes. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain 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 cmadams at hiwaay.net Fri Jun 3 21:02:16 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 3 Jun 2005 16:02:16 -0500 Subject: What next? In-Reply-To: <1117830739.3355.13.camel@localhost.localdomain> References: <20050602032426.GA3626@imp.flyn.org> <429F6542.1060108@poolshark.org> <20050602204224.GA4938@jadzia.bu.edu> <42A0A6F6.6000905@poolshark.org> <20050603185853.GG1343147@hiwaay.net> <604aa79105060312245ac7377a@mail.gmail.com> <1117830739.3355.13.camel@localhost.localdomain> Message-ID: <20050603210216.GI1343147@hiwaay.net> Once upon a time, Kyrre Ness Sjobak said: > So that somebody would write a BSD gstreamer mp3 plugin, and RH would > call Fraunhofer and get the goahead for Fedora - it would be OK (but > they would have to pay fraunhofer for distributing the same plugin with > RHEL?)? That would still mean that Fedora would have a restricted distribution, which is counter to the Fedora project goals. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From skvidal at phy.duke.edu Fri Jun 3 21:05:00 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 03 Jun 2005 17:05:00 -0400 Subject: What next? In-Reply-To: <20050603092608.GY20018@redhat.com> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <1117779926.3488.30.camel@cutter> <20050603075938.GW20018@redhat.com> <1117786145.3488.84.camel@cutter> <20050603092608.GY20018@redhat.com> Message-ID: <1117832701.7091.24.camel@cutter> > Any duration will get people arguing whether it's too long or too short. > To me 6 months is a 80/20 equilibrium point, plus it makes very easy to > memorize and predict releases (one for the Summer, one for the Winter). Any change requires discussion. That's how change happens. I'm glad you feel good about a schedule that's twice a year, but I don't think that's enough time for what we're trying to get done. > Just skip one release, branch and you get 9 months to work without being > disturbed too much. It seems to me that a fair amount of users follow that > pattern too and don't update every 6 months, but every year or so (that would > be an interesting poll to set up on the fedora web site I think). it doesn't work that way b/c some of the stuff I want to do would stall out plans for anaconda and pup, as well, it plays into a lot of doodads we want to get more time moving on. these projects are not islands unto themselves, they involve other plans too. Release coordination should be a discussion otherwise it's not really an integrated release. -sv From cmadams at hiwaay.net Fri Jun 3 21:06:33 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 3 Jun 2005 16:06:33 -0500 Subject: What next? In-Reply-To: <604aa79105060312245ac7377a@mail.gmail.com> References: <20050602032426.GA3626@imp.flyn.org> <429F6542.1060108@poolshark.org> <20050602204224.GA4938@jadzia.bu.edu> <42A0A6F6.6000905@poolshark.org> <20050603185853.GG1343147@hiwaay.net> <604aa79105060312245ac7377a@mail.gmail.com> Message-ID: <20050603210633.GJ1343147@hiwaay.net> Once upon a time, Jeff Spaleta said: > If this issue was about Fraunhofers rights and responsbilities as a > "copyright" holder to GPL code you'd be sort of right.. but the issue > isn't about "copyrights" its about "patents". I was basing my comments on the current state of freely (legal or not) available MP3 decoders. AFAIK the free decoders are all GPL. For that code to actually be legally distributable in some places (i.e. the US), Fraunhofer would have to agree to a royalty-free patent license to the copyright holder _and_ to anyone else who distributes such code under the terms of the GPL (whether such distribution is commercial or not). Otherwise, the code cannot be distributed at all (since a patent license requirement conflicts with the terms of the GPL). -- 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 Jun 3 21:18:33 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 3 Jun 2005 17:18:33 -0400 Subject: What next? In-Reply-To: <20050603210633.GJ1343147@hiwaay.net> References: <20050602032426.GA3626@imp.flyn.org> <429F6542.1060108@poolshark.org> <20050602204224.GA4938@jadzia.bu.edu> <42A0A6F6.6000905@poolshark.org> <20050603185853.GG1343147@hiwaay.net> <604aa79105060312245ac7377a@mail.gmail.com> <20050603210633.GJ1343147@hiwaay.net> Message-ID: <604aa79105060314187dd81da9@mail.gmail.com> On 6/3/05, Chris Adams wrote: > I was basing my comments on the current state of freely (legal or not) > available MP3 decoders. AFAIK the free decoders are all GPL. For that > code to actually be legally distributable in some places (i.e. the US), > Fraunhofer would have to agree to a royalty-free patent license to the > copyright holder _and_ to anyone else who distributes such code under > the terms of the GPL (whether such distribution is commercial or not). > Otherwise, the code cannot be distributed at all (since a patent license > requirement conflicts with the terms of the GPL). The assessment is valid... and materially different than what you wrote earlier... because this paragraph does not put constraints on what Fraunhofer is allowed to do with their patents. -jef From mike at navi.cx Fri Jun 3 21:20:06 2005 From: mike at navi.cx (Mike Hearn) Date: Fri, 03 Jun 2005 22:20:06 +0100 Subject: What next? References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <1117662394.31018.80.camel@cutter> <1117673495.29707.4.camel@otto.amantes> <1117738856.7932.33.camel@rousalka.dyndns.org> <1117789066.7960.2.camel@otto.amantes> Message-ID: On Fri, 03 Jun 2005 10:57:46 +0200, Thomas Vander Stichele wrote: > So what I'm saying is that user should choose their own "1 linux", be it > fedora, ubuntu, suse, .... and live within the boundaries of that. Well, I don't really mind a thriving ecosystem of distros, but I feel that this is like saying users should live within the boundaries of their desktop and never run apps that don't use their preferred toolkit. That's needlessly limiting and hurts developers and end users alike. I don't think standardisation would seriously modify most distros. KDE is still KDE and GNOME is still GNOME even though they share some infrastructure these days. Most of the things that were standardised weren't obviously better or worse in either desktop. It'd be the same for distributions. thanks -mike From alan at redhat.com Fri Jun 3 21:33:53 2005 From: alan at redhat.com (Alan Cox) Date: Fri, 3 Jun 2005 17:33:53 -0400 Subject: What next? In-Reply-To: <1117830739.3355.13.camel@localhost.localdomain> References: <20050602032426.GA3626@imp.flyn.org> <429F6542.1060108@poolshark.org> <20050602204224.GA4938@jadzia.bu.edu> <42A0A6F6.6000905@poolshark.org> <20050603185853.GG1343147@hiwaay.net> <604aa79105060312245ac7377a@mail.gmail.com> <1117830739.3355.13.camel@localhost.localdomain> Message-ID: <20050603213353.GA7389@devserv.devel.redhat.com> On Fri, Jun 03, 2005 at 10:32:20PM +0200, Kyrre Ness Sjobak wrote: > So that somebody would write a BSD gstreamer mp3 plugin, and RH would > call Fraunhofer and get the goahead for Fedora - it would be OK (but > they would have to pay fraunhofer for distributing the same plugin with > RHEL?)? People sell Fedora and it is also free software, which means no restrictions. Anyone who wants is free to try and negotiate with the MP3 license holders to get a license one off for their project or for GPL use. I believe people have tried. From kyrre at solution-forge.net Fri Jun 3 21:36:28 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Fri, 03 Jun 2005 23:36:28 +0200 Subject: What next? In-Reply-To: <1117831276.3319.7.camel@gibraltar.stuttgart.redhat.com> References: <20050602032426.GA3626@imp.flyn.org> <429F6542.1060108@poolshark.org> <20050602204224.GA4938@jadzia.bu.edu> <42A0A6F6.6000905@poolshark.org> <20050603185853.GG1343147@hiwaay.net> <604aa79105060312245ac7377a@mail.gmail.com> <1117830739.3355.13.camel@localhost.localdomain> <1117831276.3319.7.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1117834587.3355.18.camel@localhost.localdomain> fre, 03.06.2005 kl. 22.41 skrev Nils Philippsen: > On Fri, 2005-06-03 at 22:32 +0200, Kyrre Ness Sjobak wrote: > > *snip* > > > If > > > there was a BSD "copyright" licensed implementation out there for mp3, > > > that would change things considerable. BSD "copyright" license is > > > perfectly compatible with non-commercial use "patent" licenses like > > > what Fraunhofer currently allows. > > > > So that somebody would write a BSD gstreamer mp3 plugin, and RH would > > call Fraunhofer and get the goahead for Fedora - it would be OK (but > > they would have to pay fraunhofer for distributing the same plugin with > > RHEL?)? > > But is that what we want? To enable anybody to just take Fedora and > distribute it -- for free or for money -- we don't want to include > software with specific license exemptions for us. Having a patent > license exemption only for the project wouldn't be different in my eyes. I agree, was just testing out the idea. Even if mp3 support would be great for many users. OTOH, don't already RH-artwork, present such a problem for freely distributing? And not everyone lives in the US. Kyrre From jspaleta at gmail.com Fri Jun 3 21:40:39 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 3 Jun 2005 17:40:39 -0400 Subject: What next? In-Reply-To: <1117834587.3355.18.camel@localhost.localdomain> References: <429F6542.1060108@poolshark.org> <20050602204224.GA4938@jadzia.bu.edu> <42A0A6F6.6000905@poolshark.org> <20050603185853.GG1343147@hiwaay.net> <604aa79105060312245ac7377a@mail.gmail.com> <1117830739.3355.13.camel@localhost.localdomain> <1117831276.3319.7.camel@gibraltar.stuttgart.redhat.com> <1117834587.3355.18.camel@localhost.localdomain> Message-ID: <604aa791050603144061520a41@mail.gmail.com> On 6/3/05, Kyrre Ness Sjobak wrote: > OTOH, don't already RH-artwork, present such a problem for freely > distributing? No.. because there is an explicit trademark license that allows 3rd parties to take the fedora software..without modification... and redistribute it. http://fedora.redhat.com/about/trademarks/guidelines/page4.html -jef From kyrre at solution-forge.net Fri Jun 3 22:17:33 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sat, 04 Jun 2005 00:17:33 +0200 Subject: Fedora Core 4 delayed until June 13 In-Reply-To: <1117829790.7091.12.camel@cutter> References: <20050603170242.GC6057@nostromo.devel.redhat.com> <1117829669.3355.9.camel@localhost.localdomain> <1117829790.7091.12.camel@cutter> Message-ID: <1117837052.3355.21.camel@localhost.localdomain> fre, 03.06.2005 kl. 22.16 skrev seth vidal: > On Fri, 2005-06-03 at 22:14 +0200, Kyrre Ness Sjobak wrote: > > fre, 03.06.2005 kl. 19.02 skrev Bill Nottingham: > > > Due to some unforseen complications, Fedora Core 4 is now > > > scheduled for general availability on June 13. We apologize for > > > the inconvenience. > > > > > > Bill > > > > > > What where the complications? > > > > vetting the name for the release through legal. > > not that anyone ever USES the name for anything, but hey, names are fun, > sorta. > > -sv > What is the name for the release? still-secret? :) BTW what about this?: http://www.fedora.info/ http://www.fedora.info/redHat.shtml From skvidal at phy.duke.edu Fri Jun 3 22:21:26 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 03 Jun 2005 18:21:26 -0400 Subject: Fedora Core 4 delayed until June 13 In-Reply-To: <1117837052.3355.21.camel@localhost.localdomain> References: <20050603170242.GC6057@nostromo.devel.redhat.com> <1117829669.3355.9.camel@localhost.localdomain> <1117829790.7091.12.camel@cutter> <1117837052.3355.21.camel@localhost.localdomain> Message-ID: <1117837286.7091.57.camel@cutter> On Sat, 2005-06-04 at 00:17 +0200, Kyrre Ness Sjobak wrote: > fre, 03.06.2005 kl. 22.16 skrev seth vidal: > > On Fri, 2005-06-03 at 22:14 +0200, Kyrre Ness Sjobak wrote: > > > fre, 03.06.2005 kl. 19.02 skrev Bill Nottingham: > > > > Due to some unforseen complications, Fedora Core 4 is now > > > > scheduled for general availability on June 13. We apologize for > > > > the inconvenience. > > > > > > > > Bill > > > > > > > > > What where the complications? > > > > > > > vetting the name for the release through legal. > > > > not that anyone ever USES the name for anything, but hey, names are fun, > > sorta. > > > > -sv > > > > What is the name for the release? still-secret? :) read your cvs commits mail. it's in there. -sv From tmraz at redhat.com Fri Jun 3 23:35:38 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Sat, 04 Jun 2005 01:35:38 +0200 Subject: What next? In-Reply-To: <1117789066.7960.2.camel@otto.amantes> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <1117662394.31018.80.camel@cutter> <1117673495.29707.4.camel@otto.amantes> <1117738856.7932.33.camel@rousalka.dyndns.org> <1117789066.7960.2.camel@otto.amantes> Message-ID: <1117841738.5343.29.camel@perun.redhat.usu> On Fri, 2005-06-03 at 10:57 +0200, Thomas Vander Stichele wrote: > Hi, > > > > In other words, Thomas is right, we need "1 Linux". Not one distro, but > > one set of standards people can write packages and installers to. > > Just to clarify - I do not actually feel that we need "1 linux". I'm > just saying that the reason things aren't as easy as on mac is because > there is not just "1 linux". Personally, I'm completely fine with linux > being a thriving ecosystem, and for daily use I stick to using Fedora + > extras, knowing that this is a window on the larger ecosystem that Just > Works. Yes, and this is exactly the thing that makes Linux being Linux. Otherwise there are plenty of other operating systems which do it the "one way" style. So please, if you want to have only one Linux, choose another operating system and don't take the choice from us. P.S. I don't think there shouldn't be more standards here or there, but generaly the idea of only one Linux takes the essential point of Linux existence away. -- Tomas Mraz From naheemzaffar at gmail.com Sat Jun 4 00:03:53 2005 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Sat, 4 Jun 2005 01:03:53 +0100 Subject: Fedora Extras Cd's, yum In-Reply-To: <20050603222034.EDFD1735CA@hormel.redhat.com> References: <20050603222034.EDFD1735CA@hormel.redhat.com> Message-ID: <3adc772105060317032db25613@mail.gmail.com> If fedora extras cd's are to be used through yum, I believe there should be a local.repo file pointing at mounted devices (a generic file, possibly using HAL? I am not developer, but that seems to be the use for it). By FC5 There should probably be a frontend for yum in the default install. The CD should have a directory structure, with the headers and a premade sqlite file with the files that can be used against the local version, along with a gpg key. The yum GUI should handle the install. There is an issue though: What if more than one cd is needed? Will there be a need to allow for each cd to have a unique name distinguishable through yum? or can this be handled with the sqlite file which will distinguish the cd's. This in addition to a secong localrepo file that handles installs of downloaded rpm's (I suggested this earlier; you could even have a scripted folder called apps, where dragging an app into it will start yum just for the mac lovers!) should make the Fedora way better than other competitor's ways. Bullet points of what I as a semi-geek end-user think will solve the problem: 1. Stick to the linux way of repositories. 2. Add two local repositories: 1 for installing downloaded rpm's, one for mounted extras media. 3. media that have the same structure as online repository (self containing with both headers, and rpms in similar structure), with the addition of sqlite file (which is only compared against local version; you do not want to have to load a cd every time you run yum update ;)). If an app is instalkled, just do the normal 'downloading' of the header, and rpm to the pc from the cd! 3. Some gui front-end for installing. a YumEX tat as the features of synaptic, but easier to use! (Not asking for much am I?) 4. A scripted folder that will automatically install apps. (Or this could just be the apps menu; drag an app into the Applications menu, and it will auto install via yum!) (the folder could be like the ones in my lcations; computer, network, wastebasket, apps...) 5. drag the file out of the folder (or off the menu) into the recyclebin, and this will run yum remove... None of this deals with auto updating rpms downloaded from proprietry sources that have not created a repo, but the consensus seems proprietry devs will not use the more elegant 'fap' method anyway, so make things simpler and have less hassle. (Sorry if this messes up the listing format in archives. I m using Gmail with the Digest option, and thus cannot reply to individual emails. If anyone can tell me kow to sort this problem out, please mail me.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tibbs at math.uh.edu Sat Jun 4 00:45:32 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 03 Jun 2005 19:45:32 -0500 Subject: Fedora Core 4 delayed until June 13 In-Reply-To: <1117837286.7091.57.camel@cutter> (seth vidal's message of "Fri, 03 Jun 2005 18:21:26 -0400") References: <20050603170242.GC6057@nostromo.devel.redhat.com> <1117829669.3355.9.camel@localhost.localdomain> <1117829790.7091.12.camel@cutter> <1117837052.3355.21.camel@localhost.localdomain> <1117837286.7091.57.camel@cutter> Message-ID: >>>>> "sv" == seth vidal writes: sv> read your cvs commits mail. A bottle washer? That's what legal is hung up on? - J< From florin at andrei.myip.org Sat Jun 4 07:11:02 2005 From: florin at andrei.myip.org (Florin Andrei) Date: Sat, 04 Jun 2005 00:11:02 -0700 Subject: Fedora Core 4 delayed until June 13 In-Reply-To: References: <20050603170242.GC6057@nostromo.devel.redhat.com> <1117829669.3355.9.camel@localhost.localdomain> <1117829790.7091.12.camel@cutter> <1117837052.3355.21.camel@localhost.localdomain> <1117837286.7091.57.camel@cutter> Message-ID: <1117869063.5925.1.camel@rivendell.home.local> On Fri, 2005-06-03 at 19:45 -0500, Jason L Tibbitts III wrote: > A bottle washer? That's what legal is hung up on? (similar discussion in the Legal department) A minus sign on line 2457 in validate_input.c? That's what development is hung up on? Learning to look at things from other people's perspective, and all that. ;-) -- Florin Andrei http://florin.myip.org/ From enrico.scholz at informatik.tu-chemnitz.de Sat Jun 4 08:39:49 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 04 Jun 2005 10:39:49 +0200 Subject: What next? In-Reply-To: <20050603190221.GH1343147@hiwaay.net> (Chris Adams's message of "Fri, 3 Jun 2005 14:02:21 -0500") References: <200506021630.48520@carola.nyarlathotep> <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> Message-ID: <87wtpay0q2.fsf@kosh.bigo.ensc.de> cmadams at hiwaay.net (Chris Adams) writes: > I didn't actually notice Firefox didn't support ^Q for a while, because > I typically leave a few xterms and a browser running all the time. I > noticed the missing ^Q short-cut with gpdf and ggv first. The question is, why simple viewers need two keystrokes to quit the program. Existing viewers like 'less', 'more', 'info' or 'xpdf' need only a simple 'Q' (instead of C-Q). Enrico From veillard at redhat.com Sat Jun 4 09:26:18 2005 From: veillard at redhat.com (Daniel Veillard) Date: Sat, 4 Jun 2005 05:26:18 -0400 Subject: What next? In-Reply-To: <1117832701.7091.24.camel@cutter> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <1117779926.3488.30.camel@cutter> <20050603075938.GW20018@redhat.com> <1117786145.3488.84.camel@cutter> <20050603092608.GY20018@redhat.com> <1117832701.7091.24.camel@cutter> Message-ID: <20050604092618.GC22547@redhat.com> On Fri, Jun 03, 2005 at 05:05:00PM -0400, seth vidal wrote: > > Just skip one release, branch and you get 9 months to work without being > > disturbed too much. It seems to me that a fair amount of users follow that > > pattern too and don't update every 6 months, but every year or so (that would > > be an interesting poll to set up on the fedora web site I think). > > it doesn't work that way b/c some of the stuff I want to do would stall > out plans for anaconda and pup, as well, it plays into a lot of doodads > we want to get more time moving on. > > these projects are not islands unto themselves, they involve other plans > too. Release coordination should be a discussion otherwise it's not > really an integrated release. Can't you branch all 3 ? differential updates done to head can then be merged back selectively when the branch is made the main trunk once ready. In general I don't see why this is not possible, I would need more specifics to understand. I assume it's about integrating the extras which I agree may need deep structural change in some of the distro tools, but I fail to see why this can't be done on a branch. Are you afraid of not having enough momentum if you branch to get this done ? If this is the case maybe this mean the plan must be brought up more publicly to try to ensure sufficient community support on that branch effort. Are you afraid of the cost of merging back the branch as the main trunk ? Sure this is an annoyance but from a community perspective less than breaking the release cycle or the loss of momentum due to the larger gap between releases. "release early, release often" still rules in my opinion, fedora is not just a distro it's also the key channel between a community of users and a community of developers, increasing the time between releases weakens that link a lot in my opinion, making it less valuable to both communities which could result in a big loss of users to other reactive distros like Ubuntu. Even if the ultimate goals of the big changes is to increase usefulness to those 2 communities, the impact of delaying releases can be negative in the end. That's why I'm suggesting to branch with a clear plan of what is to be achieved, and expectation of when this would become the main trunk. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From buildsys at redhat.com Sat Jun 4 11:26:02 2005 From: buildsys at redhat.com (Build System) Date: Sat, 4 Jun 2005 07:26:02 -0400 Subject: rawhide report: 20050604 changes Message-ID: <200506041126.j54BQ2Yj021390@porkchop.devel.redhat.com> Updated Packages: GFS-kernel-2.6.11.8-20050601.152643.FC4.2 ----------------------------------------- at-3.1.8-78 ----------- * Fri Jun 03 2005 Jason Vas Dias 3.1.8-78 - fix bug 159220: add pam_loginuid to pam session stack in /etc/pam.d/atd - fix bug 102341: add '-r' synonym for '-d' / atrm for POSIX / SuS conformance cman-kernel-2.6.11.5-20050601.152643.FC4.2 ------------------------------------------ dlm-kernel-2.6.11.5-20050601.152643.FC4.2 ----------------------------------------- eclipse-cdt-1:3.0.0_fc-0.M6.8 ----------------------------- * Fri Jun 03 2005 Jeff Pound 3.0.0_fc-0.M6.8 - Patch refactoring/build.properties to include plugin.properties. - Temporarily move all *.so's to *.so.bak due to native compilation bug. - Temporarily remove gcj .jar -> .so db population. gamin-0.1.0-1.1 --------------- * Fri Jun 03 2005 Elliot Lee 0.1.0-1.1 - Add the .la file back in for now (FC-4) ghostscript-8.15-0.rc3.1 ------------------------ * Fri Jun 03 2005 Tim Waugh 8.15-0.rc3.1 - Switch to ESP Ghostscript. - 8.15rc3. - Lots of patches dropped. Perhaps some will need to be re-added. gnbd-kernel-2.6.11.2-20050420.133124.FC4.35 ------------------------------------------- kernel-2.6.11-1.1369_FC4 ------------------------ * Wed Jun 01 2005 Dave Jones - Fix up ALI IDE regression. (#157175) * Mon May 30 2005 Dave Jones - Fix up VIA IRQ quirk. python-urlgrabber-2.9.6-2 ------------------------- * Fri Jun 03 2005 Phil Knirsch 2.9.6-2 - Fixed the reget method to actually work correctly (skip completely transfered files, etc) From ndbecker2 at gmail.com Sat Jun 4 12:26:50 2005 From: ndbecker2 at gmail.com (Neal Becker) Date: Sat, 04 Jun 2005 08:26:50 -0400 Subject: rawhide report: 20050604 changes References: <200506041126.j54BQ2Yj021390@porkchop.devel.redhat.com> Message-ID: Error: Missing Dependency: libijs.so()(64bit) is needed by package gimp-print Error: Missing Dependency: libgs.so.7()(64bit) is needed by package ImageMagick-perl Error: Missing Dependency: libgs.so.7()(64bit) is needed by package ImageMagick [nbecker at nbecker ~]$ sudo yum --exclude=ghostscript* upgrade [Now updates OK] From jlayton at redhat.com Sat Jun 4 12:50:44 2005 From: jlayton at redhat.com (Jeff Layton) Date: Sat, 04 Jun 2005 08:50:44 -0400 Subject: [PATCH] mkinitrd rescue mode In-Reply-To: <20050602210436.GA4357@ti64.telemetry-investments.com> References: <1117653405.12259.51.camel@barsoom.rdu.redhat.com> <1117725836.3768.15.camel@bree.local.net> <1117731994.12259.68.camel@barsoom.rdu.redhat.com> <1117743443.3768.37.camel@bree.local.net> <20050602210436.GA4357@ti64.telemetry-investments.com> Message-ID: <1117889444.7838.10.camel@localhost.localdomain> On Thu, 2005-06-02 at 17:04 -0400, Bill Rugolsky Jr. wrote: > > One is expected to delete files before doing the switchroot. Unlike a ramdisk, > the ramfs pages are immediately reclaimed. Ok, I've whipped up a new patch. This adds a simple "unlink" function to nash. The mkinitrd script now does an "rm /bin/fsck*" (using busybox's rm), and then a "unlink /bin/busybox" after the rescue mode and prior to the switchroot. That should free up any significant extra memory we consume by adding these tools to the initramfs. The new patch is attached to the BZ ticket: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159287 I've done some looking around at whether there is some way to get at the initramfs after switchrooting (or whether there is some mechanism to cause the kernel to just free it), but haven't found any way to do this yet. The early-userspace docs seem to state that you can only have a single cpio archive, but that multiple 'images' are allowed. I'm not clear at this point on what these images are and how they're stored, however. -- Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: mkinitrd-rescue.patch Type: text/x-patch Size: 3966 bytes Desc: not available URL: From twaugh at redhat.com Sat Jun 4 12:52:15 2005 From: twaugh at redhat.com (Tim Waugh) Date: Sat, 4 Jun 2005 13:52:15 +0100 Subject: rawhide report: 20050604 changes In-Reply-To: References: <200506041126.j54BQ2Yj021390@porkchop.devel.redhat.com> Message-ID: <20050604125215.GH8706@redhat.com> On Sat, Jun 04, 2005 at 08:26:50AM -0400, Neal Becker wrote: > Error: Missing Dependency: libijs.so()(64bit) is needed by package > gimp-print > Error: Missing Dependency: libgs.so.7()(64bit) is needed by package > ImageMagick-perl > Error: Missing Dependency: libgs.so.7()(64bit) is needed by package > ImageMagick > [nbecker at nbecker ~]$ sudo yum --exclude=ghostscript* upgrade > [Now updates OK] Yes, this is the very beginning of FC5 development, so things will be a little broken at the moment. First I want to check whether some old patches still need to be applied to ghostscript. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jlayton at redhat.com Sat Jun 4 13:03:36 2005 From: jlayton at redhat.com (Jeff Layton) Date: Sat, 04 Jun 2005 09:03:36 -0400 Subject: [PATCH] mkinitrd rescue mode In-Reply-To: <1117889444.7838.10.camel@localhost.localdomain> References: <1117653405.12259.51.camel@barsoom.rdu.redhat.com> <1117725836.3768.15.camel@bree.local.net> <1117731994.12259.68.camel@barsoom.rdu.redhat.com> <1117743443.3768.37.camel@bree.local.net> <20050602210436.GA4357@ti64.telemetry-investments.com> <1117889444.7838.10.camel@localhost.localdomain> Message-ID: <1117890216.7838.13.camel@localhost.localdomain> On second thought, I changed the mkinitrd script to just use unlink to remove the files individually. I wasn't sure how nash would handle wildcards, and this should be slightly faster. See BZ case for updated patch. -- Jeff From skvidal at phy.duke.edu Sat Jun 4 13:22:54 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 04 Jun 2005 09:22:54 -0400 Subject: rawhide report: 20050604 changes In-Reply-To: <200506041126.j54BQ2Yj021390@porkchop.devel.redhat.com> References: <200506041126.j54BQ2Yj021390@porkchop.devel.redhat.com> Message-ID: <1117891374.3099.7.camel@cutter> > python-urlgrabber-2.9.6-2 > ------------------------- > * Fri Jun 03 2005 Phil Knirsch 2.9.6-2 > - Fixed the reget method to actually work correctly (skip completely transfered > files, etc) Odd, I didn't see a post to yum-devel or this filed upstream. It'd be nice if you filed that upstream and asked about a release before you patched it in the distro. -sv From liste-p.alain at wanadoo.fr Sat Jun 4 14:03:37 2005 From: liste-p.alain at wanadoo.fr (Aph) Date: Sat, 4 Jun 2005 16:03:37 +0200 Subject: What next? In-Reply-To: <20050602162129.GB27561@nostromo.devel.redhat.com> References: <200506021630.48520@carola.nyarlathotep> <20050602162129.GB27561@nostromo.devel.redhat.com> Message-ID: <200506041603.46782@carola.nyarlathotep> Le Jeudi 2 Juin 2005 18:21, Bill Nottingham a ?crit?: > Aph (liste-p.alain at wanadoo.fr) said: > > A gnome navigator by defaut : firefox is not a good choice : it's in > > english only and many localisation don't work. > > Have you tried 1.0.4-4 from rawhide? Yes ; what is new ? I have firefox in english ?! And anything change when I apply a french localisation (error, ...). Idea for many users is a localized program in defaut choice (navigator, mail, term, ...) ; with firefox, it's "bricolage". Regards. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From thacker at math.cornell.edu Sat Jun 4 15:01:28 2005 From: thacker at math.cornell.edu (John Thacker) Date: Sat, 4 Jun 2005 11:01:28 -0400 Subject: What next? In-Reply-To: <87wtpay0q2.fsf@kosh.bigo.ensc.de> References: <200506021630.48520@carola.nyarlathotep> <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> Message-ID: <20050604150128.GA17357@thacker.dyndns.org> On Sat, Jun 04, 2005 at 10:39:49AM +0200, Enrico Scholz wrote: > The question is, why simple viewers need two keystrokes to quit the > program. Existing viewers like 'less', 'more', 'info' or 'xpdf' need > only a simple 'Q' (instead of C-Q). I would assume because the GNOME people would like consistency across the platform (that's what led to this discussion) and people feel it would be annoying to put in extra keystrokes to shift more interactive editors and other programs into a viewing mode where 'Q' would quit them. Having 'Q' for some programs and 'CTRL-Q' for others would be annoying, as this thread has shown. John Thacker -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From thacker at math.cornell.edu Sat Jun 4 15:04:18 2005 From: thacker at math.cornell.edu (John Thacker) Date: Sat, 4 Jun 2005 11:04:18 -0400 Subject: rawhide report: 20050604 changes In-Reply-To: <200506041126.j54BQ2Yj021390@porkchop.devel.redhat.com> References: <200506041126.j54BQ2Yj021390@porkchop.devel.redhat.com> Message-ID: <20050604150418.GB17357@thacker.dyndns.org> On Sat, Jun 04, 2005 at 07:26:02AM -0400, Build System wrote: > Updated Packages: > > GFS-kernel-2.6.11.8-20050601.152643.FC4.2 > ----------------------------------------- > cman-kernel-2.6.11.5-20050601.152643.FC4.2 > ------------------------------------------ > dlm-kernel-2.6.11.5-20050601.152643.FC4.2 > ----------------------------------------- > gnbd-kernel-2.6.11.2-20050420.133124.FC4.35 > ------------------------------------------- > kernel-2.6.11-1.1369_FC4 > ------------------------ I'm sure people know this, but seeing all these "FC4" tags can be confusing when this is actually early FC5 stuff. John Thacker -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Sat Jun 4 15:16:56 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 4 Jun 2005 11:16:56 -0400 Subject: rawhide report: 20050604 changes In-Reply-To: <20050604150418.GB17357@thacker.dyndns.org> References: <200506041126.j54BQ2Yj021390@porkchop.devel.redhat.com> <20050604150418.GB17357@thacker.dyndns.org> Message-ID: <604aa7910506040816495e53eb@mail.gmail.com> On 6/4/05, John Thacker wrote: > I'm sure people know this, but seeing all these "FC4" tags can be > confusing when this is actually early FC5 stuff. who said its ALL early fc5 stuff? -jef From mattdm at mattdm.org Sat Jun 4 15:50:32 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 4 Jun 2005 11:50:32 -0400 Subject: What next? In-Reply-To: <20050604150128.GA17357@thacker.dyndns.org> References: <200506021630.48520@carola.nyarlathotep> <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> Message-ID: <20050604155032.GA9144@jadzia.bu.edu> On Sat, Jun 04, 2005 at 11:01:28AM -0400, John Thacker wrote: > > The question is, why simple viewers need two keystrokes to quit the > > program. Existing viewers like 'less', 'more', 'info' or 'xpdf' need > > only a simple 'Q' (instead of C-Q). > I would assume because the GNOME people would like consistency across > the platform (that's what led to this discussion) and people feel it > would be annoying to put in extra keystrokes to shift more interactive > editors and other programs into a viewing mode where 'Q' would quit them. > Having 'Q' for some programs and 'CTRL-Q' for others would be annoying, > as this thread has shown. Well, not to mention that it'd be horribly bad if hitting one key closed your web browser. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 80 degrees Fahrenheit. From e_mc_h2 at web.de Sat Jun 4 16:29:35 2005 From: e_mc_h2 at web.de (ness) Date: Sat, 04 Jun 2005 18:29:35 +0200 Subject: google summer of code In-Reply-To: <1117812715.23296.88.camel@gibraltar.stuttgart.redhat.com> References: <42A04AEF.9080309@web.de> <1117807625.23296.37.camel@gibraltar.stuttgart.redhat.com> <42A067E4.7010005@web.de> <1117812715.23296.88.camel@gibraltar.stuttgart.redhat.com> Message-ID: <42A1D6EF.6070408@web.de> An HTML attachment was scrubbed... URL: From enrico.scholz at informatik.tu-chemnitz.de Sat Jun 4 17:22:14 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 04 Jun 2005 19:22:14 +0200 Subject: What next? In-Reply-To: <20050604150128.GA17357@thacker.dyndns.org> (John Thacker's message of "Sat, 4 Jun 2005 11:01:28 -0400") References: <200506021630.48520@carola.nyarlathotep> <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> Message-ID: <87mzq6xcjd.fsf@kosh.bigo.ensc.de> thacker at math.cornell.edu (John Thacker) writes: > Having 'Q' for some programs and 'CTRL-Q' for others would be annoying, > as this thread has shown. I do not think so. People distinguished between :wq, C-x C-c, q and C-q for several decades, so why should viewers -- which are used mainly by one-key bindings -- need suddenly two keystrokes for shutdown? Enrico From enrico.scholz at informatik.tu-chemnitz.de Sat Jun 4 17:24:58 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 04 Jun 2005 19:24:58 +0200 Subject: What next? In-Reply-To: <20050604155032.GA9144@jadzia.bu.edu> (Matthew Miller's message of "Sat, 4 Jun 2005 11:50:32 -0400") References: <200506021630.48520@carola.nyarlathotep> <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <20050604155032.GA9144@jadzia.bu.edu> Message-ID: <87is0uxcet.fsf@kosh.bigo.ensc.de> mattdm at mattdm.org (Matthew Miller) writes: > Well, not to mention that it'd be horribly bad if hitting one key closed > your web browser. My response was regarding | noticed the missing ^Q short-cut with gpdf and ggv first. and simple viewers should be controllable by one-key bindings. Enrico From thacker at math.cornell.edu Sat Jun 4 19:18:34 2005 From: thacker at math.cornell.edu (John Thacker) Date: Sat, 4 Jun 2005 15:18:34 -0400 Subject: What next? In-Reply-To: <87mzq6xcjd.fsf@kosh.bigo.ensc.de> References: <200506021630.48520@carola.nyarlathotep> <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> Message-ID: <20050604191834.GA19626@thacker.dyndns.org> On Sat, Jun 04, 2005 at 07:22:14PM +0200, Enrico Scholz wrote: > thacker at math.cornell.edu (John Thacker) writes: > > > Having 'Q' for some programs and 'CTRL-Q' for others would be annoying, > > as this thread has shown. > > I do not think so. People distinguished between :wq, C-x C-c, q and C-q > for several decades, so why should viewers -- which are used mainly by > one-key bindings -- need suddenly two keystrokes for shutdown? Hmm. I seem to recall that when vi(m) is run as a viewer, with view, it still requires :wq to shutdown. I don't think it would be a good idea to have vi, when executed as view or in read-only mode, suddenly switch keybindings and quit with one keystrokes. It's confusing to be inconsistent. And what applies to vi as one application applies to GNOME as a platform. Yes, people did distinguish. I distinguished between :wq, used by a program I used, and C-x C-c, used by a program I never used. Part of the reason that I (and other people I know) don't use emacs is because I don't want to bother to learn a whole other set of keyboard shortcuts. Similarly, I know plenty of average users that use only emacs and never vi(m) for the same reasons, as well as pico/nano users who want the same keyboard shortcuts that they've had in pine for many years who avoid emacs and vi. Having lots of different keyboard shortcuts that differ across programs is annoying for users, especially casual users. Since GNOME stresses usability, it encourages common keyboard shortcuts. For several decades plenty of people avoided UNIX-based systems because it was "hard to use," and learning esoteric keyboard commands for vi and a host of other esoteric keyboard commands for emacs is one commonly-pointed to example of it being hard to use, in my experience. John Thacker -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mrsam at courier-mta.com Sat Jun 4 19:31:33 2005 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sat, 04 Jun 2005 15:31:33 -0400 Subject: The situation with libwww. Message-ID: W3C stopped maintaining libwww three years ago (http://www.w3.org/Library/). So, what should one do after finding a bunch of major, but non-security related flaws in libwww? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From davej at redhat.com Sat Jun 4 19:47:02 2005 From: davej at redhat.com (Dave Jones) Date: Sat, 4 Jun 2005 15:47:02 -0400 Subject: rawhide report: 20050604 changes In-Reply-To: <20050604150418.GB17357@thacker.dyndns.org> References: <200506041126.j54BQ2Yj021390@porkchop.devel.redhat.com> <20050604150418.GB17357@thacker.dyndns.org> Message-ID: <20050604194702.GB9658@redhat.com> On Sat, Jun 04, 2005 at 11:04:18AM -0400, John Thacker wrote: > On Sat, Jun 04, 2005 at 07:26:02AM -0400, Build System wrote: > > Updated Packages: > > > > GFS-kernel-2.6.11.8-20050601.152643.FC4.2 > > ----------------------------------------- > > cman-kernel-2.6.11.5-20050601.152643.FC4.2 > > ------------------------------------------ > > dlm-kernel-2.6.11.5-20050601.152643.FC4.2 > > ----------------------------------------- > > gnbd-kernel-2.6.11.2-20050420.133124.FC4.35 > > ------------------------------------------- > > kernel-2.6.11-1.1369_FC4 > > ------------------------ > > I'm sure people know this, but seeing all these "FC4" tags can be > confusing when this is actually early FC5 stuff. Packages that haven't been rebuilt for FC5 yet inherit their FC4 packages. Dave From mfioretti at mclink.it Sat Jun 4 21:04:02 2005 From: mfioretti at mclink.it (M. Fioretti) Date: Sat, 4 Jun 2005 23:04:02 +0200 Subject: What next? In-Reply-To: <20050604191834.GA19626@thacker.dyndns.org> References: <200506021630.48520@carola.nyarlathotep> <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> Message-ID: <20050604210402.GE3329@mclink.it> On Sat, Jun 04, 2005 15:18:34 PM -0400, John Thacker (thacker at math.cornell.edu) wrote: > Having lots of different keyboard shortcuts that differ across programs > is annoying for users, especially casual users. FWIW: I spend roughly 40% of my computer time in Emacs, 40% in OpenOffice. Almost every day for several hours a day. So I'm not a casual user of those two program. And I still curse every day because: I go OO.o after two hours of Emacs, hit C-x C-W to save, canceling whatever was highlighted and being asked if I want to close the file without saving. I go Emacs after two hours of OO.o, hit C-s to save, and the program stops until I remember that it's waiting for me to know what to search. Not that with VI it would be different. And using any other editor is not an option for me, those two are the only ones I am sure to find, with a decent configuration, on any *nix machine I have to work. I'd switch to any Linux distro that came configured with the same shortcuts for Emacs and OO.o in one second... Ciao, Marco -- Marco Fioretti mfioretti, at the server mclink.it Fedora Core 3 for low memory http://www.rule-project.org/ Non si vive se non il tempo che si ama. C. A. Helvetius From cmadams at hiwaay.net Sat Jun 4 21:22:36 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Sat, 4 Jun 2005 16:22:36 -0500 Subject: What next? In-Reply-To: <20050604191834.GA19626@thacker.dyndns.org> References: <200506021630.48520@carola.nyarlathotep> <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> Message-ID: <20050604212236.GB1306147@hiwaay.net> Once upon a time, John Thacker said: > Hmm. I seem to recall that when vi(m) is run as a viewer, with view, > it still requires :wq to shutdown. You recall incorrectly. ":wq" is two commands: "w" is write and "q" is quit. If you are in view only mode, you can just ":q". -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From mattdm at mattdm.org Sat Jun 4 23:06:05 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 4 Jun 2005 19:06:05 -0400 Subject: What next? In-Reply-To: <87is0uxcet.fsf@kosh.bigo.ensc.de> References: <200506021630.48520@carola.nyarlathotep> <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <20050604155032.GA9144@jadzia.bu.edu> <87is0uxcet.fsf@kosh.bigo.ensc.de> Message-ID: <20050604230605.GA20132@jadzia.bu.edu> On Sat, Jun 04, 2005 at 07:24:58PM +0200, Enrico Scholz wrote: > > Well, not to mention that it'd be horribly bad if hitting one key closed > > your web browser. > My response was regarding > | noticed the missing ^Q short-cut with gpdf and ggv first. > and simple viewers should be controllable by one-key bindings. Sorry, I misread -- I thought you were classing web browsers with "simple [html] viewers". -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 80 degrees Fahrenheit. From drepper at redhat.com Sat Jun 4 23:50:13 2005 From: drepper at redhat.com (Ulrich Drepper) Date: Sat, 04 Jun 2005 16:50:13 -0700 Subject: What next? In-Reply-To: References: <1117655080.6271.52.camel@laptopd505.fenrus.org> <1117656479.5013.7.camel@localhost.localdomain> Message-ID: <42A23E35.3050607@redhat.com> Elliot Lee wrote: > Those links are there because libtool and pkg-config are stupid. libtool > and pkg-config aren't going to stop being stupid anytime soon, so we live > with the situation as-is :) There is no reason to not fix libtool et.al for Linux to not do the stupid things necessary on some other platforms. It'll mostly mean throwing out unnecessary parts of the libtool/... script. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From drepper at redhat.com Sun Jun 5 00:05:26 2005 From: drepper at redhat.com (Ulrich Drepper) Date: Sat, 04 Jun 2005 17:05:26 -0700 Subject: What next? In-Reply-To: <1117689174.2702.28.camel@cutter> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> Message-ID: <42A241C6.5000706@redhat.com> seth vidal wrote: > But if hobbyists cannot participate in development b/c the cycle is just > too fast, well then it's not too terribly useful for us, is it. I don't buy this argument at all. So what if the changes you're working on don't go in the next release? They can still go into the one after that. There will always be cutoff points and a more frequent release cycle is actually the only mean to ensure a feature can get wide exposure by being part of the distribution. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From skvidal at phy.duke.edu Sun Jun 5 00:23:13 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 04 Jun 2005 20:23:13 -0400 Subject: What next? In-Reply-To: <42A241C6.5000706@redhat.com> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <42A241C6.5000706@redhat.com> Message-ID: <1117930993.7104.2.camel@cutter> On Sat, 2005-06-04 at 17:05 -0700, Ulrich Drepper wrote: > seth vidal wrote: > > > But if hobbyists cannot participate in development b/c the cycle is just > > too fast, well then it's not too terribly useful for us, is it. > > I don't buy this argument at all. I'm sorry you don't buy it - but I wasn't stating an opinion, I was describing the case. > So what if the changes you're working on don't go in the next release? Well the changes I'm working on for this next release affect anaconda and the package updater in use on fedora, so, yah, I think there is a problem if they don't go in the next release. -sv From drepper at redhat.com Sun Jun 5 00:21:32 2005 From: drepper at redhat.com (Ulrich Drepper) Date: Sat, 04 Jun 2005 17:21:32 -0700 Subject: Zeroconf in FC5? In-Reply-To: <1117766193.4649.51.camel@ninja> References: <1117766193.4649.51.camel@ninja> Message-ID: <42A2458C.4030300@redhat.com> Daryll Strauss wrote: > So, I'd like to see zeroconf > really integrated in to FC5. I think it'll make network setup for a lot > of users much easier. So get working. There is a lot to do. And don't mention these foolish attempts of integration done by some other distributions. What is needed is another daemon (or an extended and renamed mDNSResponder) which monitors the network and caches all entries for the appropriate time. The daemon needs a programming interface so that a new NSS module can be used to query the daemon's cache of known addresses and probably also to initiate the daemon to send out requests for information which isn't in the cache. I talked with the author of the current (unusable) nss_mdns module and he plans to do something like this after I explained it to him. But I haven't seen any progress. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From drepper at redhat.com Sun Jun 5 00:31:58 2005 From: drepper at redhat.com (Ulrich Drepper) Date: Sat, 04 Jun 2005 17:31:58 -0700 Subject: What next? In-Reply-To: <1117930993.7104.2.camel@cutter> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> Message-ID: <42A247FE.1030300@redhat.com> seth vidal wrote: >> So what if the changes you're working on don't go in the next release? > > Well the changes I'm working on for this next release affect anaconda > and the package updater in use on fedora, so, yah, I think there is a > problem if they don't go in the next release. No, it just means that coordination is needed. Just as it does now but today this coordination (or lack thereof) manifests itself "only" in temporarily broken FC trees. Projects are getting larger and larger and need more time to develop. Increasing the release cycle every year or two isn't the answer. Developers simply need to get a bit more sophisticated and have a stable development tree and one or more blue-sky trees. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From felipe.alfaro at gmail.com Sun Jun 5 02:09:02 2005 From: felipe.alfaro at gmail.com (Felipe Alfaro Solana) Date: Sun, 5 Jun 2005 04:09:02 +0200 Subject: Zeroconf in FC5? In-Reply-To: <42A2458C.4030300@redhat.com> References: <1117766193.4649.51.camel@ninja> <42A2458C.4030300@redhat.com> Message-ID: <6f6293f10506041909333866b2@mail.gmail.com> On 6/5/05, Ulrich Drepper wrote: > So get working. There is a lot to do. And don't mention these foolish > attempts of integration done by some other distributions. > > What is needed is another daemon (or an extended and renamed > mDNSResponder) which monitors the network and caches all entries for the > appropriate time. The daemon needs a programming interface so that a > new NSS module can be used to query the daemon's cache of known > addresses and probably also to initiate the daemon to send out requests > for information which isn't in the cache. > > I talked with the author of the current (unusable) nss_mdns module and > he plans to do something like this after I explained it to him. But I > haven't seen any progress. Are you referring to the nss_mdns module that comes bundled with Apple's own implementation of Zeroconf/Rendezvous/Bonjour? From skvidal at phy.duke.edu Sun Jun 5 07:08:40 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 05 Jun 2005 03:08:40 -0400 Subject: What next? In-Reply-To: <42A247FE.1030300@redhat.com> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> Message-ID: <1117955320.7104.8.camel@cutter> > Projects are getting larger and larger and need more time to develop. > Increasing the release cycle every year or two isn't the answer. How would you know? Red hat has never had a release cycle of anything other than 6 months. You seem to be making an assertion you can't support. I'm suggesting we try something to see if it helps. > Developers simply need to get a bit more sophisticated and have a stable > development tree and one or more blue-sky trees. I'll make sure I put that down on my list of things to do for fedora next week: 'be more sophisticated' thanks, -sv From veillard at redhat.com Sun Jun 5 08:27:11 2005 From: veillard at redhat.com (Daniel Veillard) Date: Sun, 5 Jun 2005 04:27:11 -0400 Subject: What next? In-Reply-To: <1117955320.7104.8.camel@cutter> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> Message-ID: <20050605082711.GG22547@redhat.com> On Sun, Jun 05, 2005 at 03:08:40AM -0400, seth vidal wrote: > > > Projects are getting larger and larger and need more time to develop. > > Increasing the release cycle every year or two isn't the answer. > > How would you know? Red hat has never had a release cycle of anything > other than 6 months. You seem to be making an assertion you can't > support. I'm suggesting we try something to see if it helps. Sure we do internally... RHEL so far has had an 18 months cycle and it does work by branching at some point and doing the work we want to do on the community base until it is ready to release. Like you we need more time to integrate changes and stabilize than what the 6month cycle allows, we also have the need to integrate most of it back into the main cycle, and not disrupt it. It requires planning, branching, merging, but it's doable and I think we can support that model from a technical standpoint since we are over the fourth iteration on that model. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From Nicolas.Mailhot at laPoste.net Sun Jun 5 08:38:10 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 05 Jun 2005 10:38:10 +0200 Subject: What next? In-Reply-To: <42A23E35.3050607@redhat.com> References: <1117655080.6271.52.camel@laptopd505.fenrus.org> <1117656479.5013.7.camel@localhost.localdomain> <42A23E35.3050607@redhat.com> Message-ID: <1117960693.12764.2.camel@rousalka.dyndns.org> Another thing : I'd like jackd in core now that we have a vanilla kernel that can support it. That or (if jackd is absolutely impossible to integrate) something else that will make the audio people happy. And then a lot of audio apps in extras :) -- Nicolas Mailhot -------------- 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 Nicolas.Mailhot at laPoste.net Sun Jun 5 09:42:56 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 05 Jun 2005 11:42:56 +0200 Subject: What next? In-Reply-To: <42A23E35.3050607@redhat.com> References: <1117655080.6271.52.camel@laptopd505.fenrus.org> <1117656479.5013.7.camel@localhost.localdomain> <42A23E35.3050607@redhat.com> Message-ID: <1117964578.13642.0.camel@rousalka.dyndns.org> Another thing : I'd like jackd in core now that we have a vanilla kernel that can support it. That or (if jackd is absolutely impossible to integrate) something else that will make the audio people happy. And then a lot of audio apps in extras :) -- Nicolas Mailhot -------------- 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 enrico.scholz at informatik.tu-chemnitz.de Sun Jun 5 10:30:14 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sun, 05 Jun 2005 12:30:14 +0200 Subject: What next? In-Reply-To: <20050604191834.GA19626@thacker.dyndns.org> (John Thacker's message of "Sat, 4 Jun 2005 15:18:34 -0400") References: <200506021630.48520@carola.nyarlathotep> <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> Message-ID: <87ekbhxfih.fsf@kosh.bigo.ensc.de> thacker at math.cornell.edu (John Thacker) writes: > Having lots of different keyboard shortcuts that differ across programs > is annoying for users, especially casual users. Since GNOME stresses > usability, The "usability" stressed by Gnome2 is the usability expected by novice Windoze users seeing Linux the first time. For experienced users, Gnome2 has a horrible usability: with every new minor version they make a 180 degree turn[1] without providing a transitition. Examples? The spastic windowmode of nautilus appeared suddenly in existing installations without a way to use the old one, the Emacs style bindings were suddenly turned off in favor of the windoze like ones (and there are only hidden ways to use the old one), a good webbrowser was replaced by something with an experimental bookmarking which was never proved to be usefully (and this thing still resists in ages of Firefox...), a powerful windowmanager was replaced by a crippled something which is unable to do the simplest things. Perhaps, the "features" mentioned above could be provided in parallel to the existing ones. But removing suddenly the old ones is the wrong way. (FWIW, that's why I use KDE for my family; I am tired to explain on every update why the old things do not work anymore). > it encourages common keyboard shortcuts. The "common shortcuts" are probably the Emacs style ones (e.g. they are used by *Emacs, bash and old versions of Gnome). I do not see a reason why they could not be patched into Ooffice; RH is crippl^Wpatching other programs (e.g. firefox) already, so Ooffice could become a little bit more Unix-style also. Enrico Footnotes: [1] they are very good in inventing new dimensions of unusability so do not expected to reach the old direction ever -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From buildsys at redhat.com Sun Jun 5 11:31:06 2005 From: buildsys at redhat.com (Build System) Date: Sun, 5 Jun 2005 07:31:06 -0400 Subject: rawhide report: 20050605 changes Message-ID: <200506051131.j55BV6bH007934@porkchop.devel.redhat.com> Updated Packages: metacity-2.10.0-2.fc5 --------------------- * Mon May 30 2005 Warren Togami 2.10.0-2 - raise demands attention (#157271 newren) From alan at redhat.com Sun Jun 5 16:15:45 2005 From: alan at redhat.com (Alan Cox) Date: Sun, 5 Jun 2005 12:15:45 -0400 Subject: What next? In-Reply-To: <87ekbhxfih.fsf@kosh.bigo.ensc.de> References: <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <87ekbhxfih.fsf@kosh.bigo.ensc.de> Message-ID: <20050605161545.GA28581@devserv.devel.redhat.com> On Sun, Jun 05, 2005 at 12:30:14PM +0200, Enrico Scholz wrote: > why they could not be patched into Ooffice; RH is crippl^Wpatching other > programs (e.g. firefox) already, so Ooffice could become a little bit Actually firefox support for unixlike keybindings is something from the Firefox community rather than RH as I understand it. From jkeating at j2solutions.net Sun Jun 5 16:21:15 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 05 Jun 2005 09:21:15 -0700 Subject: The situation with libwww. In-Reply-To: References: Message-ID: <1117988476.2797.0.camel@yoda.loki.me> On Sat, 2005-06-04 at 15:31 -0400, Sam Varshavchik wrote: > W3C stopped maintaining libwww three years ago > (http://www.w3.org/Library/). > So, what should one do after finding a bunch of major, but > non-security > related flaws in libwww? Bribe somebody to take it over and possibly somebody else to package it for Extras? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From drepper at redhat.com Sun Jun 5 16:20:04 2005 From: drepper at redhat.com (Ulrich Drepper) Date: Sun, 05 Jun 2005 09:20:04 -0700 Subject: Zeroconf in FC5? In-Reply-To: <6f6293f10506041909333866b2@mail.gmail.com> References: <1117766193.4649.51.camel@ninja> <42A2458C.4030300@redhat.com> <6f6293f10506041909333866b2@mail.gmail.com> Message-ID: <42A32634.8080705@redhat.com> Felipe Alfaro Solana wrote: > Are you referring to the nss_mdns module that comes bundled with > Apple's own implementation of Zeroconf/Rendezvous/Bonjour? No, certainly not. Search freshmeat for nss_mdns, there is a module written for Linux. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From skvidal at phy.duke.edu Sun Jun 5 16:30:35 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 05 Jun 2005 12:30:35 -0400 Subject: What next? In-Reply-To: <20050605082711.GG22547@redhat.com> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> Message-ID: <1117989035.7104.36.camel@cutter> On Sun, 2005-06-05 at 04:27 -0400, Daniel Veillard wrote: > On Sun, Jun 05, 2005 at 03:08:40AM -0400, seth vidal wrote: > > > > > Projects are getting larger and larger and need more time to develop. > > > Increasing the release cycle every year or two isn't the answer. > > > > How would you know? Red hat has never had a release cycle of anything > > other than 6 months. You seem to be making an assertion you can't > > support. I'm suggesting we try something to see if it helps. > > Sure we do internally... RHEL so far has had an 18 months cycle Nice of y'all to allow yourself longer release cycles while denying it to fedora community developers. > and it does work by branching at some point and doing the work we want > to do on the community base until it is ready to release. Like you we > need more time to integrate changes and stabilize than what the 6month > cycle allows, we also have the need to integrate most of it back into > the main cycle, and not disrupt it. It requires planning, branching, > merging, but it's doable and I think we can support that model from a > technical standpoint since we are over the fourth iteration on that model. I think we don't have nearly enough volunteers or infrastructure to say that the fourth iteration of that model is viable. I've watched the amount of stuff that needs to be done at the fedora extras steering committee meetings and it's non-trivial and needs to be done ASAP. -sv From ndbecker2 at gmail.com Sun Jun 5 16:35:36 2005 From: ndbecker2 at gmail.com (Neal Becker) Date: Sun, 05 Jun 2005 12:35:36 -0400 Subject: nvidia-glx-1.0.7664-0.lvn.1.3.src.rpm Message-ID: I updated linva nvidia package with latest from nvidia, and placed the result here: http://nbecker.dyndns.org:8080/nvidia-glx-1.0.7664-0.lvn.1.3.src.rpm From jwboyer at jdub.homelinux.org Sun Jun 5 16:42:24 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 05 Jun 2005 11:42:24 -0500 Subject: What next? In-Reply-To: <1117989035.7104.36.camel@cutter> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> Message-ID: <1117989744.3107.114.camel@yoda.jdub.homelinux.org> On Sun, 2005-06-05 at 12:30 -0400, seth vidal wrote: > On Sun, 2005-06-05 at 04:27 -0400, Daniel Veillard wrote: > > > > > > How would you know? Red hat has never had a release cycle of anything > > > other than 6 months. You seem to be making an assertion you can't > > > support. I'm suggesting we try something to see if it helps. > > > > Sure we do internally... RHEL so far has had an 18 months cycle > > Nice of y'all to allow yourself longer release cycles while denying it > to fedora community developers. I agree with Seth here. A longer release cycle could prove to be very beneficial. 18 months would be too long for Fedora, but 9 might work out very nicely. What's the harm in trying it for a release and seeing how it goes? > > > and it does work by branching at some point and doing the work we want > > to do on the community base until it is ready to release. Like you we > > need more time to integrate changes and stabilize than what the 6month > > cycle allows, we also have the need to integrate most of it back into > > the main cycle, and not disrupt it. It requires planning, branching, > > merging, but it's doable and I think we can support that model from a > > technical standpoint since we are over the fourth iteration on that model. > > I think we don't have nearly enough volunteers or infrastructure to say > that the fourth iteration of that model is viable. I've watched the > amount of stuff that needs to be done at the fedora extras steering > committee meetings and it's non-trivial and needs to be done ASAP. As an aside, perhaps the FESCO meeting agendas/minutes should be publicly available somewhere. Then people who want to volunteer for stuff like that would have a place to look. At the very least, it provides the community with an idea of what's happening and where things are headed. josh From jspaleta at gmail.com Sun Jun 5 16:48:00 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 5 Jun 2005 12:48:00 -0400 Subject: nvidia-glx-1.0.7664-0.lvn.1.3.src.rpm In-Reply-To: References: Message-ID: <604aa79105060509483cb629ff@mail.gmail.com> On 6/5/05, Neal Becker wrote: > I updated linva nvidia package with latest from nvidia, and placed the > result here: > > http://nbecker.dyndns.org:8080/nvidia-glx-1.0.7664-0.lvn.1.3.src.rpm did you happen to file a bugticket at livna....to let the packagers there know? -jef From skvidal at phy.duke.edu Sun Jun 5 17:12:45 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 05 Jun 2005 13:12:45 -0400 Subject: What next? In-Reply-To: <1117989744.3107.114.camel@yoda.jdub.homelinux.org> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> <1117989744.3107.114.camel@yoda.jdub.homelinux.org> Message-ID: <1117991565.7104.38.camel@cutter> > As an aside, perhaps the FESCO meeting agendas/minutes should be > publicly available somewhere. Then people who want to volunteer for > stuff like that would have a place to look. At the very least, it > provides the community with an idea of what's happening and where things > are headed. > I thought they were. I'll bring it up at the next meeting for us to post them prominently. Thanks, -sv From jwboyer at jdub.homelinux.org Sun Jun 5 17:19:26 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 05 Jun 2005 12:19:26 -0500 Subject: What next? In-Reply-To: <1117991565.7104.38.camel@cutter> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> <1117989744.3107.114.camel@yoda.jdub.homelinux.org> <1117991565.7104.38.camel@cutter> Message-ID: <1117991966.3107.118.camel@yoda.jdub.homelinux.org> On Sun, 2005-06-05 at 13:12 -0400, seth vidal wrote: > > As an aside, perhaps the FESCO meeting agendas/minutes should be > > publicly available somewhere. Then people who want to volunteer for > > stuff like that would have a place to look. At the very least, it > > provides the community with an idea of what's happening and where things > > are headed. > > > > I thought they were. I'll bring it up at the next meeting for us to post > them prominently. Thanks. I found a few older posts to the mailing list about them, but nothing recent. IIRC, the meetings are usually held in an IRC chat. Perhaps even just posting the log from that would suffice. Although, having nice summarized action items would be good too :). josh From skvidal at phy.duke.edu Sun Jun 5 17:21:37 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 05 Jun 2005 13:21:37 -0400 Subject: What next? In-Reply-To: <1117991966.3107.118.camel@yoda.jdub.homelinux.org> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> <1117989744.3107.114.camel@yoda.jdub.homelinux.org> <1117991565.7104.38.camel@cutter> <1117991966.3107.118.camel@yoda.jdub.homelinux.org> Message-ID: <1117992097.7104.47.camel@cutter> On Sun, 2005-06-05 at 12:19 -0500, Josh Boyer wrote: > On Sun, 2005-06-05 at 13:12 -0400, seth vidal wrote: > > > As an aside, perhaps the FESCO meeting agendas/minutes should be > > > publicly available somewhere. Then people who want to volunteer for > > > stuff like that would have a place to look. At the very least, it > > > provides the community with an idea of what's happening and where things > > > are headed. > > > > > > > I thought they were. I'll bring it up at the next meeting for us to post > > them prominently. > > Thanks. I found a few older posts to the mailing list about them, but > nothing recent. > > IIRC, the meetings are usually held in an IRC chat. Perhaps even just > posting the log from that would suffice. Although, having nice > summarized action items would be good too :). > posting the logs would be a bad idea, if only b/c of the cursing ;) -sv From veillard at redhat.com Sun Jun 5 17:49:02 2005 From: veillard at redhat.com (Daniel Veillard) Date: Sun, 5 Jun 2005 13:49:02 -0400 Subject: What next? In-Reply-To: <1117989035.7104.36.camel@cutter> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> Message-ID: <20050605174902.GI22547@redhat.com> On Sun, Jun 05, 2005 at 12:30:35PM -0400, seth vidal wrote: > that the fourth iteration of that model is viable. I've watched the > amount of stuff that needs to be done at the fedora extras steering > committee meetings and it's non-trivial and needs to be done ASAP. I asked you to give informations about what is giving troubles, now you reference something I never heard of before. What is the fedora extras steering committee ? Pointers ? First time I heard about it. Maybe I'm just off track, but there is a complete lack of clarity around all this at least from my perspective. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From mattdm at mattdm.org Sun Jun 5 17:52:05 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 5 Jun 2005 13:52:05 -0400 Subject: What next? In-Reply-To: <20050605174902.GI22547@redhat.com> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> <20050605174902.GI22547@redhat.com> Message-ID: <20050605175205.GA23912@jadzia.bu.edu> On Sun, Jun 05, 2005 at 01:49:02PM -0400, Daniel Veillard wrote: > I asked you to give informations about what is giving troubles, > now you reference something I never heard of before. > What is the fedora extras steering committee ? Pointers ? First time I > heard about it. > Maybe I'm just off track, but there is a complete lack of clarity > around all this at least from my perspective. By "all this" do you mean Fedora in general, or Fedora Extras, or what? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 80 degrees Fahrenheit. From veillard at redhat.com Sun Jun 5 18:08:00 2005 From: veillard at redhat.com (Daniel Veillard) Date: Sun, 5 Jun 2005 14:08:00 -0400 Subject: What next? In-Reply-To: <20050605175205.GA23912@jadzia.bu.edu> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> <20050605174902.GI22547@redhat.com> <20050605175205.GA23912@jadzia.bu.edu> Message-ID: <20050605180800.GJ22547@redhat.com> On Sun, Jun 05, 2005 at 01:52:05PM -0400, Matthew Miller wrote: > On Sun, Jun 05, 2005 at 01:49:02PM -0400, Daniel Veillard wrote: > > I asked you to give informations about what is giving troubles, > > now you reference something I never heard of before. > > What is the fedora extras steering committee ? Pointers ? First time I > > heard about it. > > > > > Maybe I'm just off track, but there is a complete lack of clarity > > around all this at least from my perspective. > > By "all this" do you mean Fedora in general, or Fedora Extras, or what? about the technical work which need to be done and which need to change the Fedora cycle durations. What, who, when, how long, and why this can't be done in parrallel ? All I'm getting is "we need longuer cycles" and still not understanding. BTW I'm not represnting Red Hat position, just an engineer trying to understand some engineering plumbing and not getting it. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From skvidal at phy.duke.edu Sun Jun 5 18:12:09 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 05 Jun 2005 14:12:09 -0400 Subject: What next? In-Reply-To: <20050605180800.GJ22547@redhat.com> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> <20050605174902.GI22547@redhat.com> <20050605175205.GA23912@jadzia.bu.edu> <20050605180800.GJ22547@redhat.com> Message-ID: <1117995129.655.4.camel@opus.phy.duke.edu> > about the technical work which need to be done and which need to change > the Fedora cycle durations. What, who, when, how long, and why this > can't be done in parrallel ? All I'm getting is "we need longuer cycles" > and still not understanding. > > BTW I'm not represnting Red Hat position, just an engineer trying to > understand some engineering plumbing and not getting it. > Who: fedora community people along with some red hat release engineers What: Fedora extras steering committee Why: We have to re-engineer EVERYTHING that y'all already have in order to: 1. support systems which are not inside red hat's network 2. have a buildsystem at all 3. have an errata release mechanism at all 4. have a db to coordinate any of these things. We're not allowed to use or even see anything already written at rh b/c either: 1. it sucks or 2. it's part of the 'secret sauce' that some vp at rh thinks is valuable, somehow. So we have to start over from scratch on everything and only a handful of those systems are in place: 1. cvs - only took a year to get it happening and another 6 months to use it 2. account system - only 18 months 3. build system - once extras got moving it took a mere 4 months to get time to take care of it - and we still have to throw one away. 4. errata system - not there yet - probably AT LEAST another 6 months 5. db for coordination - just starting oh and we need all of those things YESTERDAY. So there you go. - that's the list - now do you understand why we would like a little more time before the next release? -sv From e_mc_h2 at web.de Sun Jun 5 18:14:34 2005 From: e_mc_h2 at web.de (ness) Date: Sun, 05 Jun 2005 20:14:34 +0200 Subject: google summer of code In-Reply-To: <42A0A194.704@web.de> References: <42A04AEF.9080309@web.de> <1117807625.23296.37.camel@gibraltar.stuttgart.redhat.com> <42A067E4.7010005@web.de> <1117822916.3355.7.camel@localhost.localdomain> <42A0A194.704@web.de> Message-ID: <42A3410A.8040901@web.de> I've written a spec file for what I'd do (see attachment). I don't wan't to press so., but there's not much time until June 14th, the final deadlinev for applying to the google summer of code. It would be really nice if so. could tell me whether my idea is accepted and fredora would like o be the mentoring organization or not, because of if not I've to ask so. other (eg. ubuntu), but I like the idea of a community distribution like fredora. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: specs URL: From ndbecker2 at gmail.com Sun Jun 5 18:56:11 2005 From: ndbecker2 at gmail.com (Neal Becker) Date: Sun, 05 Jun 2005 14:56:11 -0400 Subject: nvidia-glx-1.0.7664-0.lvn.1.3.src.rpm References: <604aa79105060509483cb629ff@mail.gmail.com> Message-ID: Jeff Spaleta wrote: > On 6/5/05, Neal Becker wrote: >> I updated linva nvidia package with latest from nvidia, and placed the >> result here: >> >> http://nbecker.dyndns.org:8080/nvidia-glx-1.0.7664-0.lvn.1.3.src.rpm > > did you happen to file a bugticket at livna....to let the packagers there > know? > > -jef > Did now. Thanks. From tiemann at redhat.com Sun Jun 5 23:07:21 2005 From: tiemann at redhat.com (Michael Tiemann) Date: Sun, 05 Jun 2005 19:07:21 -0400 Subject: What next? In-Reply-To: <1117989035.7104.36.camel@cutter> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> Message-ID: <1118012841.4040.20.camel@localhost.localdomain> On Sun, 2005-06-05 at 12:30 -0400, seth vidal wrote: > On Sun, 2005-06-05 at 04:27 -0400, Daniel Veillard wrote: > > On Sun, Jun 05, 2005 at 03:08:40AM -0400, seth vidal wrote: > > > > > > > Projects are getting larger and larger and need more time to develop. > > > > Increasing the release cycle every year or two isn't the answer. > > > > > > How would you know? Red hat has never had a release cycle of anything > > > other than 6 months. You seem to be making an assertion you can't > > > support. I'm suggesting we try something to see if it helps. > > > > Sure we do internally... RHEL so far has had an 18 months cycle > > Nice of y'all to allow yourself longer release cycles while denying it > to fedora community developers. Not fair--see below. > > and it does work by branching at some point and doing the work we want > > to do on the community base until it is ready to release. Like you we > > need more time to integrate changes and stabilize than what the 6month > > cycle allows, we also have the need to integrate most of it back into > > the main cycle, and not disrupt it. It requires planning, branching, > > merging, but it's doable and I think we can support that model from a > > technical standpoint since we are over the fourth iteration on that model. > > I think we don't have nearly enough volunteers or infrastructure to say > that the fourth iteration of that model is viable. I've watched the > amount of stuff that needs to be done at the fedora extras steering > committee meetings and it's non-trivial and needs to be done ASAP. Seth, you've actually answered your own question. Based on what I have seen inside of Red Hat, 6 months is a release cycle that matches well the challenge of the problem with the nature and resources of the present community. Even with the surprise 7 day delay, FC4 is great, as was FC3 vs. the targets we all set. I even think that your suggestion of a one-time-for-now 9 month cycle could make sense. But the stuff that's required to hit an 18 month target is just Night And Day different. It may look easy--copying and criticizing the decisions we make is pretty easy stuff compared to sorting out the initial plan and keeping enough of the contingencies viable that the release is relevant by the time it sees daylight. I'm not saying that Red Hat is the only one trying to make these guesses and trying to following them through to their logical conclusion--there are companies and community efforts alike that try this stuff every day. But I am saying that it's a sufficiently difficult and resource-intensive task that it's Just Not Fair to suggest that simple goal-setting will lead to simple goal attainment. Running a marathon is hard, but running up up Mt. Everest is a different ballgame, and pretending it's not is reckless. My $0.02. M From jspaleta at gmail.com Sun Jun 5 19:12:00 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 5 Jun 2005 15:12:00 -0400 Subject: What next? In-Reply-To: <1118012841.4040.20.camel@localhost.localdomain> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> <1118012841.4040.20.camel@localhost.localdomain> Message-ID: <604aa79105060512124ac6a222@mail.gmail.com> On 6/5/05, Michael Tiemann wrote: > I even think that your suggestion > of a one-time-for-now 9 month cycle could make sense. +1 -jef"data-mining executive memos for topical comments since 1874"spaleta From skvidal at phy.duke.edu Sun Jun 5 19:23:08 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 05 Jun 2005 15:23:08 -0400 Subject: What next? In-Reply-To: <1118012841.4040.20.camel@localhost.localdomain> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> <1118012841.4040.20.camel@localhost.localdomain> Message-ID: <1117999388.655.21.camel@opus.phy.duke.edu> > > > > Nice of y'all to allow yourself longer release cycles while denying it > > to fedora community developers. > > Not fair--see below. My dad used to say something about things not being fair.... > Seth, you've actually answered your own question. Based on what I have > seen inside of Red Hat, 6 months is a release cycle that matches well > the challenge of the problem with the nature and resources of the > present community. *boggle* Where are you getting this? > Even with the surprise 7 day delay, FC4 is great, as > was FC3 vs. the targets we all set. For fedora CORE maybe - but there is Fedora Extras and there's A LOT of infrastructure work to keep fedora from being completely manually managed. > I even think that your suggestion > of a one-time-for-now 9 month cycle could make sense. good. > But the stuff that's required to hit an 18 month target is just Night And Day > different. I wasn't recommending an 18 month target, I was saying that I thought lengthening the fc devel cycle would help us get some things done that we just haven't had the time to do. > It may look easy--copying and criticizing the decisions we > make is pretty easy stuff compared to sorting out the initial plan and > keeping enough of the contingencies viable that the release is relevant > by the time it sees daylight. I'm not saying that Red Hat is the only > one trying to make these guesses and trying to following them through to > their logical conclusion--there are companies and community efforts > alike that try this stuff every day. But I am saying that it's a > sufficiently difficult and resource-intensive task that it's Just Not > Fair to suggest that simple goal-setting will lead to simple goal > attainment. Running a marathon is hard, but running up up Mt. Everest > is a different ballgame, and pretending it's not is reckless. You're damn right. So I guess you can understand why I'm a bit pissed at being talked down to by you when I sat in a meeting 3 months ago about the fedora extras buildsystem process and I was the only one who volunteered to work on it. Why? B/c everyone else was too busy. Hell, I was too busy, too but I wanted it to happen and it appeared that was the only way it was GOING to happen. Someone else set the objectives and I met them. So get down off your high horse about "copying and criticizing". I don't when, exactly, I get to stop paying dues but I think it needs to be soon. -sv From mike at netlyncs.com Sun Jun 5 19:46:18 2005 From: mike at netlyncs.com (Mike Chambers) Date: Sun, 05 Jun 2005 14:46:18 -0500 Subject: What next? In-Reply-To: <1117999388.655.21.camel@opus.phy.duke.edu> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> <1118012841.4040.20.camel@localhost.localdomain> <1117999388.655.21.camel@opus.phy.duke.edu> Message-ID: <1118000778.2525.4.camel@scrappy.netlyncs.com> On Sun, 2005-06-05 at 15:23 -0400, seth vidal wrote: > > But the stuff that's required to hit an 18 month target is just Night And Day > > different. > > > I wasn't recommending an 18 month target, I was saying that I thought > lengthening the fc devel cycle would help us get some things done that > we just haven't had the time to do. I may be totally off base here, but I think you misunderstood what Michael was talking about. I *think* he is referring to RHEL being on the 18 month target, which means Fedora basically does 3 releases to meet the goals they set for RHEL, which sort of is an 18 month target as well, or 3 *3 month* targets to get it there? *shrug*, just trying to help understand. So throw this email out the window if it's not correct :P -- Mike Chambers Madisonville, KY "Everything is difficult before it's easy!" From tiemann at redhat.com Sun Jun 5 23:48:33 2005 From: tiemann at redhat.com (Michael Tiemann) Date: Sun, 05 Jun 2005 19:48:33 -0400 Subject: What next? In-Reply-To: <1117999388.655.21.camel@opus.phy.duke.edu> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> <1118012841.4040.20.camel@localhost.localdomain> <1117999388.655.21.camel@opus.phy.duke.edu> Message-ID: <1118015313.4040.44.camel@localhost.localdomain> On Sun, 2005-06-05 at 15:23 -0400, seth vidal wrote: > > > > > > Nice of y'all to allow yourself longer release cycles while denying it > > > to fedora community developers. > > > > Not fair--see below. > > My dad used to say something about things not being fair.... > I get it that life's not fair. But you (and I) can be fair if we want to. > > I even think that your suggestion > > of a one-time-for-now 9 month cycle could make sense. > > > good. Heh--violent agreement. > > But the stuff that's required to hit an 18 month target is just Night And Day > > different. > > > I wasn't recommending an 18 month target, I was saying that I thought > lengthening the fc devel cycle would help us get some things done that > we just haven't had the time to do. OK. I misunderstood your proposal when you chose to quote off of Daniel's message about 18 month. Had you continued from the 9 month proposal, I would have continued reading, with interest. I apologize for misinterpreting your intent. > > [...] So I guess you can understand why I'm a bit pissed at > being talked down to by you when I sat in a meeting 3 months ago about > the fedora extras buildsystem process and I was the only one who > volunteered to work on it. Why? B/c everyone else was too busy. Hell, I > was too busy, too but I wanted it to happen and it appeared that was the > only way it was GOING to happen. > > Someone else set the objectives and I met them. You misinterpreted me. I was not talking about any shortcomings of the work on Fedora Core or Extras. I was talking about the perception that many people have about what it takes to hit an 18 month target. Since that wasn't your intent, my point was irrelevant. M From Curtis at GreenKey.net Sun Jun 5 19:48:13 2005 From: Curtis at GreenKey.net (Curtis Doty) Date: Sun, 05 Jun 2005 12:48:13 -0700 Subject: What next? In-Reply-To: <1118012841.4040.20.camel@localhost.localdomain> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> <1118012841.4040.20.camel@localhost.localdomain> Message-ID: <42A356FD.1080507@GreenKey.net> Michael Tiemann wrote: >attainment. Running a marathon is hard, but running up up Mt. Everest >is a different ballgame, and pretending it's not is reckless. > > What a great analogy. I would suggest walking is safer and has a better chance of reaching the summit and returning alive... And don't piss off the Sherpas. :-p OT: How does one outsider/dabbler know which specific rpm builds are going into fc4 (or any official release) at any given point in time? I'm in the middle of uncovering/reverting some unpleasant behaviour introduced into syslinux 3.08 and I'd be curious to know if the 3.08-2 build up on rawhide is on the table for fc4 or fc5? Since only 3.07 was in test3. ../C From skvidal at phy.duke.edu Sun Jun 5 19:54:12 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 05 Jun 2005 15:54:12 -0400 Subject: What next? In-Reply-To: <1118000778.2525.4.camel@scrappy.netlyncs.com> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> <1118012841.4040.20.camel@localhost.localdomain> <1117999388.655.21.camel@opus.phy.duke.edu> <1118000778.2525.4.camel@scrappy.netlyncs.com> Message-ID: <1118001252.655.27.camel@opus.phy.duke.edu> > I may be totally off base here, but I think you misunderstood what > Michael was talking about. > > I *think* he is referring to RHEL being on the 18 month target, which > means Fedora basically does 3 releases to meet the goals they set for > RHEL, which sort of is an 18 month target as well, or 3 *3 month* > targets to get it there? Last time I checked fedora does not ONLY meet goals that are set for rhel. For further evidence of that look at fedora extras. -sv From skvidal at phy.duke.edu Sun Jun 5 19:59:42 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 05 Jun 2005 15:59:42 -0400 Subject: What next? In-Reply-To: <1118015313.4040.44.camel@localhost.localdomain> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> <1118012841.4040.20.camel@localhost.localdomain> <1117999388.655.21.camel@opus.phy.duke.edu> <1118015313.4040.44.camel@localhost.localdomain> Message-ID: <1118001582.655.31.camel@opus.phy.duke.edu> > OK. I misunderstood your proposal when you chose to quote off of > Daniel's message about 18 month. Had you continued from the 9 month > proposal, I would have continued reading, with interest. I apologize > for misinterpreting your intent. I quoted Daniel's 18 month remark b/c I was feeling pissy and b/c he was trying to counter my claim of red hat not having anything other than a 6 month release cycle to go on with rhel's release cycle, which I think is a red herring for the discussion of fedora. I do not advocate an 18month cycle for fedora, that'd be nuts and would defeat one of the reasons I like using fedora, which is to know that it will run on recent/newer hardware. All I'm arguing for is 3 extra months for the time b/t FC4 and FC5 to give us some time to catch up on some items that need doing. -sv From mattdm at mattdm.org Sun Jun 5 20:02:55 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 5 Jun 2005 16:02:55 -0400 Subject: What next? In-Reply-To: <1118012841.4040.20.camel@localhost.localdomain> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> <1118012841.4040.20.camel@localhost.localdomain> Message-ID: <20050605200255.GA27583@jadzia.bu.edu> On Sun, Jun 05, 2005 at 07:07:21PM -0400, Michael Tiemann wrote: > attainment. Running a marathon is hard, but running up up Mt. Everest > is a different ballgame, and pretending it's not is reckless. Cute mixed-metaphor. :) Seriously, though, assuming you mean Fedora is the marathon and the Mt. Everest run is RHEL, the question is: do you *really* want outside help with Fedora? Because the current 6 month schedule feels like running a marathon every day to those of us not paid to devote all of our time to Fedora. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 80 degrees Fahrenheit. From mitr at volny.cz Sun Jun 5 20:08:10 2005 From: mitr at volny.cz (Miloslav Trmac) Date: Sun, 5 Jun 2005 22:08:10 +0200 Subject: What next? In-Reply-To: <1118001582.655.31.camel@opus.phy.duke.edu> References: <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> <1118012841.4040.20.camel@localhost.localdomain> <1117999388.655.21.camel@opus.phy.duke.edu> <1118015313.4040.44.camel@localhost.localdomain> <1118001582.655.31.camel@opus.phy.duke.edu> Message-ID: <20050605200805.GA31422@chrys.ms.mff.cuni.cz> On Sun, Jun 05, 2005 at 03:59:42PM -0400, seth vidal wrote: > I quoted Daniel's 18 month remark b/c I was feeling pissy and b/c he was > trying to counter my claim of red hat not having anything other than a 6 > month release cycle to go on with rhel's release cycle, which I think is > a red herring for the discussion of fedora. Maybe the people really suggest a branch for the work you are talking about - without realizing that the work "has to" happen by FC5 because the promise that it will happen by FC5 ended the one of the previous rounds of flamewars. Mirek From skvidal at phy.duke.edu Sun Jun 5 20:11:33 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 05 Jun 2005 16:11:33 -0400 Subject: What next? In-Reply-To: <20050605200805.GA31422@chrys.ms.mff.cuni.cz> References: <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> <1118012841.4040.20.camel@localhost.localdomain> <1117999388.655.21.camel@opus.phy.duke.edu> <1118015313.4040.44.camel@localhost.localdomain> <1118001582.655.31.camel@opus.phy.duke.edu> <20050605200805.GA31422@chrys.ms.mff.cuni.cz> Message-ID: <1118002294.655.33.camel@opus.phy.duke.edu> On Sun, 2005-06-05 at 22:08 +0200, Miloslav Trmac wrote: > On Sun, Jun 05, 2005 at 03:59:42PM -0400, seth vidal wrote: > > I quoted Daniel's 18 month remark b/c I was feeling pissy and b/c he was > > trying to counter my claim of red hat not having anything other than a 6 > > month release cycle to go on with rhel's release cycle, which I think is > > a red herring for the discussion of fedora. > Maybe the people really suggest a branch for the work you are talking > about - without realizing that the work "has to" happen by FC5 because > the promise that it will happen by FC5 ended the one of the previous > rounds of flamewars. good point. :) -sv From mikelurk at rogers.com Sun Jun 5 20:18:44 2005 From: mikelurk at rogers.com (Mike Lurk) Date: Sun, 05 Jun 2005 16:18:44 -0400 Subject: Wish list Message-ID: <1118002724.9556.34.camel@Darkstar> This is my wish list for Fedora Core. 1. download and install from cd or dvd (this already works 99.9% of the time, depending on hardware) 2. Ease of use, ( not for a new Linux user, but getting there) 3. Easy to install new software, (not quite, but very close). Oh what the hell, Linux will not go anywhere until the hardware manufacturers will give the end user the option and support for Linux (be it Fedora, Mandrake, Suse or any other flavour of Linux). As it stands now Windows (yuck) is the only option. Who says there is no monopoly on the OS that is installed on, lets say a Dell for arguments sake, a Notebook. Try to purchase a notebook with no OS, impossible. About the only way to do that is to buy a build your own desktop PC and be damned with the likes of Dell, HP/Compaq, and Sony, as well as others. Sorry for the ranting and raving, but Linux is the best OS out there, my choice is Fedora Core, and Windose is the only choice for end users, poor them. How many people actually know that there is an alternative OS besides Windose. None, nobody, nada, ziltch. No one promotes it in any way. On that note that is my biggest wish, PROMOTE LINUX. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nman64 at n-man.com Sun Jun 5 20:44:57 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Sun, 05 Jun 2005 15:44:57 -0500 Subject: Wish list In-Reply-To: <1118002724.9556.34.camel@Darkstar> References: <1118002724.9556.34.camel@Darkstar> Message-ID: <42A36449.80509@n-man.com> Mike Lurk wrote: > This is my wish list for Fedora Core. > > 1. download and install from cd or dvd (this already works 99.9% of > the time, depending on hardware) > 2. Ease of use, ( not for a new Linux user, but getting there) > 3. Easy to install new software, (not quite, but very close). > > Oh what the hell, Linux will not go anywhere until the hardware > manufacturers will give the end user the option and support for Linux > (be it Fedora, Mandrake, Suse or any other flavour of Linux). As it > stands now Windows (yuck) is the only option. Who says there is no > monopoly on the OS that is installed on, lets say a Dell for arguments > sake, a Notebook. Try to purchase a notebook with no OS, impossible. > About the only way to do that is to buy a build your own desktop PC > and be damned with the likes of Dell, HP/Compaq, and Sony, as well as > others. > > Sorry for the ranting and raving, but Linux is the best OS out there, > my choice is Fedora Core, and Windose is the only choice for end > users, poor them. How many people actually know that there is an > alternative OS besides Windose. None, nobody, nada, ziltch. No one > promotes it in any way. > > On that note that is my biggest wish, PROMOTE LINUX. You've got some fire in you. Subscribe to fedora-marketing-list. I tend to disagree on some aspects. I think Fedora Core is starting to be good enough for end users. I sell computers, and offer both Windows and Linux on them. Some people haven't even heard of Linux or Fedora, but choose it to save money. Others have heard of Linux but not used it, and welcome the opportunity to try it out. I have gotten a small number of questions regarding the differences between the two systems, but I have not yet had a complaint that some piece of hardware absolutely would not work (we set up everything before the computer leaves the shop) and have never had someone dissatisfied with Fedora Core. I think that's very impressive. You'd be surprised by how many people have heard of Linux and heard good things. They often just don't know where to look. BTW, we do sell laptops with no operating system. ;-) -- Patrick "The N-Man" Barnes nman64 at n-man.com www.n-man.com -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From veillard at redhat.com Sun Jun 5 21:07:27 2005 From: veillard at redhat.com (Daniel Veillard) Date: Sun, 5 Jun 2005 17:07:27 -0400 Subject: What next? In-Reply-To: <1117995129.655.4.camel@opus.phy.duke.edu> References: <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> <20050605174902.GI22547@redhat.com> <20050605175205.GA23912@jadzia.bu.edu> <20050605180800.GJ22547@redhat.com> <1117995129.655.4.camel@opus.phy.duke.edu> Message-ID: <20050605210727.GK22547@redhat.com> On Sun, Jun 05, 2005 at 02:12:09PM -0400, seth vidal wrote: > Who: fedora community people along with some red hat release engineers > What: Fedora extras steering committee > Why: We have to re-engineer EVERYTHING that y'all already have in order > to: 1. support systems which are not inside red hat's network > 2. have a buildsystem at all > 3. have an errata release mechanism at all > 4. have a db to coordinate any of these things. > We're not allowed to use or even see anything already written at rh b/c > either: 1. it sucks or 2. it's part of the 'secret sauce' that some vp > at rh thinks is valuable, somehow. > > So we have to start over from scratch on everything and only a handful > of those systems are in place: > 1. cvs - only took a year to get it happening and another 6 months to > use it > 2. account system - only 18 months > 3. build system - once extras got moving it took a mere 4 months to > get time to take care of it - and we still have to throw one away. > 4. errata system - not there yet - probably AT LEAST another 6 months > 5. db for coordination - just starting > > oh and we need all of those things YESTERDAY. > > So there you go. - that's the list - thanks, I note that http://fedora.redhat.com/participate/ seems to imply all this background infrastructure will magically happen and then people will be able to contribute. Maybe making public what need to be done and building a community around making those and maintaining them could help the magic disapear. > now do you understand why we would > like a little more time before the next release? No. There is a lot of work needed to change the machine used to make the final product called Fedora Core. I don't see why developping that new machine can't be done in parallel with the current one still running. I'm only left with the guess that you think doing both in parallel need more workforce than we have currently, is that right ? If it's the case it might be worth asking why there isn't more volunteers to help on the infrastructure. Again don't consider I'm coming from a Red Hat angle, I'm more trying to find parallels with other projects I know like GNOME where we had some similar problems (building a release team, sysadmin maintainance, etc.) but which were less core to the project itself. Also I'm perfectly fine being told that I'm just bothering the people doing the work, in which case I will just return to my dark cave. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard at redhat.com Sun Jun 5 21:14:09 2005 From: veillard at redhat.com (Daniel Veillard) Date: Sun, 5 Jun 2005 17:14:09 -0400 Subject: What next? In-Reply-To: <1117999388.655.21.camel@opus.phy.duke.edu> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> <1118012841.4040.20.camel@localhost.localdomain> <1117999388.655.21.camel@opus.phy.duke.edu> Message-ID: <20050605211408.GL22547@redhat.com> On Sun, Jun 05, 2005 at 03:23:08PM -0400, seth vidal wrote: > You're damn right. So I guess you can understand why I'm a bit pissed at > being talked down to by you when I sat in a meeting 3 months ago about > the fedora extras buildsystem process and I was the only one who > volunteered to work on it. Why? B/c everyone else was too busy. Hell, I > was too busy, too but I wanted it to happen and it appeared that was the > only way it was GOING to happen. Ahum, so there is a meeting about critical work needed for Fedora, maybe I'm not in the right lists but I didn't see anything about it. Is there public minutes from that meeting ? Are you trying to build a community around this part of the work ? If it's done behind closed doors, only the people within that meeting can really help getting it done, and then of course it will take foreever if nobody can. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From skvidal at phy.duke.edu Sun Jun 5 21:17:34 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 05 Jun 2005 17:17:34 -0400 Subject: What next? In-Reply-To: <20050605211408.GL22547@redhat.com> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> <1118012841.4040.20.camel@localhost.localdomain> <1117999388.655.21.camel@opus.phy.duke.edu> <20050605211408.GL22547@redhat.com> Message-ID: <1118006254.655.37.camel@opus.phy.duke.edu> On Sun, 2005-06-05 at 17:14 -0400, Daniel Veillard wrote: > On Sun, Jun 05, 2005 at 03:23:08PM -0400, seth vidal wrote: > > You're damn right. So I guess you can understand why I'm a bit pissed at > > being talked down to by you when I sat in a meeting 3 months ago about > > the fedora extras buildsystem process and I was the only one who > > volunteered to work on it. Why? B/c everyone else was too busy. Hell, I > > was too busy, too but I wanted it to happen and it appeared that was the > > only way it was GOING to happen. > > > Ahum, so there is a meeting about critical work needed for Fedora, > maybe I'm not in the right lists but I didn't see anything about it. > Is there public minutes from that meeting ? Are you trying to build > a community around this part of the work ? If it's done behind closed > doors, only the people within that meeting can really help getting it > done, and then of course it will take foreever if nobody can. > > the meeting was at red hat's HQ in raleigh. -sv From mike at navi.cx Sun Jun 5 21:31:31 2005 From: mike at navi.cx (Mike Hearn) Date: Sun, 05 Jun 2005 22:31:31 +0100 Subject: Wish list References: <1118002724.9556.34.camel@Darkstar> <42A36449.80509@n-man.com> Message-ID: On Sun, 05 Jun 2005 15:44:57 -0500, Patrick Barnes wrote: > I tend to disagree on some aspects. I think Fedora Core is starting to > be good enough for end users. There's real opportunity to market Linux to people coming up - with all the great work Red Hat/NSA have been doing on security you can actually say "Linux is fundamentally more secure than Windows, and will remain secure as it gets popular" and believe it ... security sells, as the Firefox developers will attest. Mudflap and SELinux might be slightly weird names but ExecShield is catchy (props to whoever invented that name!), so why aren't we doing an Apple: giving them ambiguous glowing balls for logos and slapping them on the website? That said, currently two problems that would stop me installing Fedora for very non-technical users: - Auto update is not reliable/graphical enough, or never has been for me. Maybe it's fixed in FC4. - Auto update breaks nvidia drivers every few weeks If Fedora was more like Ubuntu in these aspects (fully graphical/automatic auto update, supporting nvidia drivers out of the box) I'd be confident enough to install it for a friend and then go away on holiday or whatever, and not come back expecting trouble. Wouldn't necessarily be *liked*, but wouldn't actually break (I'm talking from experience of doing exactly that here). Need better MSN support and maybe a faster OpenOffice to be really comfortable. For users who are perhaps confident with computers but not technical, ie your average teenager/20something the other issues would be: - Too hard to install new software (this is what autopackage is for) - Hard to get supported wireless hardware - Games - L33t apps like Picasa, iTunes etc. I'd need to install Wine/Crossover for them myself. It's not supported by Fedora out of the box (yeah yeah I'm biased ;) At least, those are the problems I've encountered before when friends have wanted to try Linux/Fedora before. Nothing insurmountable! thanks -mike From jspaleta at gmail.com Sun Jun 5 21:36:08 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 5 Jun 2005 17:36:08 -0400 Subject: Wish list In-Reply-To: References: <1118002724.9556.34.camel@Darkstar> <42A36449.80509@n-man.com> Message-ID: <604aa791050605143632af676a@mail.gmail.com> On 6/5/05, Mike Hearn wrote: > - Auto update is not reliable/graphical enough, or never has been for me. > Maybe it's fixed in FC4. > - Auto update breaks nvidia drivers every few weeks breaks the nvidia drivers.... installed from rpms? now that dkms is in extras... i really hope the packagers of the nvidia rpms look into it as making it easier to avoid updating problems. -jef From jkeating at j2solutions.net Sun Jun 5 21:44:51 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 05 Jun 2005 14:44:51 -0700 Subject: What next? In-Reply-To: <20050605210727.GK22547@redhat.com> References: <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> <20050605174902.GI22547@redhat.com> <20050605175205.GA23912@jadzia.bu.edu> <20050605180800.GJ22547@redhat.com> <1117995129.655.4.camel@opus.phy.duke.edu> <20050605210727.GK22547@redhat.com> Message-ID: <1118007891.7472.77.camel@localhost.localdomain> On Sun, 2005-06-05 at 17:07 -0400, Daniel Veillard wrote: > No. There is a lot of work needed to change the machine used to > make > the final product called Fedora Core. I don't see why developping > that new machine can't be done in parallel with the current one still > running. Mostly because history has shown us that Red Hat et al can work on one thing at a time. If thats a release, then everything suffers until release is done. When releases are happening every 6 months, this leaves very very little time for the Giant to pay attention to infrastructure. Asking to extend development time so that there is time to focus on infrastructure, while focusing on the next release could be possible. > I'm only left with the guess that you think doing both in > parallel need more workforce than we have currently, is that right ? > If it's the case it might be worth asking why there isn't more > volunteers > to help on the infrastructure. Another problem. Outsiders can't really do much. We're told that things are being worked on to help us contribute, and so far the only thing we can contribute is extras packages. Infrastructure is decided on behind mostly closed doors, and the only thing that has worked for community contribution is to just build something (like the Extras build system) and shove it in RH's face, so that they have to take it and use it. -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- 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 mike at navi.cx Sun Jun 5 21:58:16 2005 From: mike at navi.cx (Mike Hearn) Date: Sun, 05 Jun 2005 22:58:16 +0100 Subject: Wish list References: <1118002724.9556.34.camel@Darkstar> <42A36449.80509@n-man.com> <604aa791050605143632af676a@mail.gmail.com> Message-ID: On Sun, 05 Jun 2005 17:36:08 -0400, Jeff Spaleta wrote: > breaks the nvidia drivers.... installed from rpms? Yeah. Even then. I'm not sure what happened but at some point the livna nvidia RPMs just stopped updating, and yum went ahead and upgraded the kernel anyway. It's been doing that ever since. I just pin it in grub these days. thanks -mike From mattdm at mattdm.org Sun Jun 5 22:16:10 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 5 Jun 2005 18:16:10 -0400 Subject: What next? In-Reply-To: <20050605210727.GK22547@redhat.com> References: <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> <20050605174902.GI22547@redhat.com> <20050605175205.GA23912@jadzia.bu.edu> <20050605180800.GJ22547@redhat.com> <1117995129.655.4.camel@opus.phy.duke.edu> <20050605210727.GK22547@redhat.com> Message-ID: <20050605221610.GA31003@jadzia.bu.edu> On Sun, Jun 05, 2005 at 05:07:27PM -0400, Daniel Veillard wrote: > If it's the case it might be worth asking why there isn't more volunteers > to help on the infrastructure. Because we *can't* run a marathon every six months. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 80 degrees Fahrenheit. From skvidal at phy.duke.edu Sun Jun 5 23:34:55 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 05 Jun 2005 19:34:55 -0400 Subject: What next? In-Reply-To: <1118007891.7472.77.camel@localhost.localdomain> References: <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> <20050605174902.GI22547@redhat.com> <20050605175205.GA23912@jadzia.bu.edu> <20050605180800.GJ22547@redhat.com> <1117995129.655.4.camel@opus.phy.duke.edu> <20050605210727.GK22547@redhat.com> <1118007891.7472.77.camel@localhost.localdomain> Message-ID: <1118014495.19379.12.camel@cutter> > > I'm only left with the guess that you think doing both in > > parallel need more workforce than we have currently, is that right ? > > If it's the case it might be worth asking why there isn't more > > volunteers > > to help on the infrastructure. > > Another problem. Outsiders can't really do much. We're told that > things are being worked on to help us contribute, and so far the only > thing we can contribute is extras packages. Infrastructure is decided > on behind mostly closed doors, and the only thing that has worked for > community contribution is to just build something (like the Extras build > system) and shove it in RH's face, so that they have to take it and use > it. I've found that the best way for external folks to make larger changes is to have their own infrastructure. Hence, fedora extras runs out of my building. :) We've got to get beyond that or make a nice way of tying together multiple infrastructures as 'fedora'. I think we're getting closer to that in some ways. We need to update and renovate http://fedoraproject.org and try to stop relying on fedora.redhat.com for the web infrastructure I think, especially in light of the fedora foundation. Finding fedora as a subdomain off of redhat.com makes less sense if the goal of the fedora foundation is for fedora to live a little more on its own. -sv From jspaleta at gmail.com Sun Jun 5 23:36:32 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 5 Jun 2005 19:36:32 -0400 Subject: What next? In-Reply-To: <1118014495.19379.12.camel@cutter> References: <42A241C6.5000706@redhat.com> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> <20050605174902.GI22547@redhat.com> <20050605175205.GA23912@jadzia.bu.edu> <20050605180800.GJ22547@redhat.com> <1117995129.655.4.camel@opus.phy.duke.edu> <20050605210727.GK22547@redhat.com> <1118007891.7472.77.camel@localhost.localdomain> <1118014495.19379.12.camel@cutter> Message-ID: <604aa7910506051636d03ac3f@mail.gmail.com> On 6/5/05, seth vidal wrote: > Finding fedora as a subdomain off of redhat.com makes less > sense if the goal of the fedora foundation is for fedora to live a > little more on its own. Oh are we making up goals for the foundation now? or did you find out more about it? -jef From Matt_Domsch at dell.com Sun Jun 5 23:37:13 2005 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 5 Jun 2005 18:37:13 -0500 Subject: Wish list In-Reply-To: <604aa791050605143632af676a@mail.gmail.com> References: <1118002724.9556.34.camel@Darkstar> <42A36449.80509@n-man.com> <604aa791050605143632af676a@mail.gmail.com> Message-ID: <20050605233713.GB3786@lists.us.dell.com> On Sun, Jun 05, 2005 at 05:36:08PM -0400, Jeff Spaleta wrote: > On 6/5/05, Mike Hearn wrote: > > - Auto update is not reliable/graphical enough, or never has been for me. > > Maybe it's fixed in FC4. > > - Auto update breaks nvidia drivers every few weeks > > breaks the nvidia drivers.... installed from rpms? > > now that dkms is in extras... i really hope the packagers of the > nvidia rpms look into it as making it easier to avoid updating > problems. John Hull from Dell has packaged up the NVidia drivers that we release for our Precision workstations, using DKMS. ftp://ftp.dell.com/video/ dell-nvidia-7167-5dkms.src.rpm dell-nvidia-7167-multiarch-5.tar.gz I don't know where he's at with getting NVidia do to this work for him, but as long as we've got to do it, it'll get done... Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From skvidal at phy.duke.edu Sun Jun 5 23:40:14 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 05 Jun 2005 19:40:14 -0400 Subject: What next? In-Reply-To: <604aa7910506051636d03ac3f@mail.gmail.com> References: <42A241C6.5000706@redhat.com> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> <20050605174902.GI22547@redhat.com> <20050605175205.GA23912@jadzia.bu.edu> <20050605180800.GJ22547@redhat.com> <1117995129.655.4.camel@opus.phy.duke.edu> <20050605210727.GK22547@redhat.com> <1118007891.7472.77.camel@localhost.localdomain> <1118014495.19379.12.camel@cutter> <604aa7910506051636d03ac3f@mail.gmail.com> Message-ID: <1118014814.19379.16.camel@cutter> On Sun, 2005-06-05 at 19:36 -0400, Jeff Spaleta wrote: > On 6/5/05, seth vidal wrote: > > Finding fedora as a subdomain off of redhat.com makes less > > sense if the goal of the fedora foundation is for fedora to live a > > little more on its own. > > Oh are we making up goals for the foundation now? or did you find out > more about it? In the absence of goals I prefer to create them. All the media cruft I've read this week has said: "Red Hat is freeing the Fedora project to allow it to become a fully independent entity. Red Hat will continue to support Fedora financially, but the project will be governed by an independent board of directors." quoted from: http://business.newsforge.com/article.pl?sid=05/06/03/1729211&from=rss That sounds like 'fedora should be more independent from red hat' to me. -sv From mricon at gmail.com Sun Jun 5 23:57:35 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Sun, 5 Jun 2005 19:57:35 -0400 Subject: NVidia RPMs from Dell (Re: Wish list) In-Reply-To: <20050605233713.GB3786@lists.us.dell.com> References: <1118002724.9556.34.camel@Darkstar> <42A36449.80509@n-man.com> <604aa791050605143632af676a@mail.gmail.com> <20050605233713.GB3786@lists.us.dell.com> Message-ID: On 6/5/05, Matt Domsch wrote: > John Hull from Dell has packaged up the NVidia drivers that we release > for our Precision workstations, using DKMS. > > ftp://ftp.dell.com/video/ > dell-nvidia-7167-5dkms.src.rpm > dell-nvidia-7167-multiarch-5.tar.gz Hmm... well, I'm not an expert or anything, but doing this in %post is probably sub-.. er... optimal. :) #Remove existing GL libraries rm -rf /usr/X11R6/lib/libGL.* > /dev/null 2>&1 rm -rf /usr/X11R6/lib/modules/extensions/libGLcore.* > /dev/null 2>&1 rm -rf /usr/X11R6/lib/modules/extensions/libglx.a > /dev/null 2>&1 rm -rf /usr/X11R6/lib64/libGL.* > /dev/null 2>&1 rm -rf /usr/X11R6/lib64/modules/extensions/libGLcore.* > /dev/null 2>&1 rm -rf /usr/X11R6/lib64/modules/extensions/libglx.a > /dev/null 2>&1 ...if only because all of this will be undone the next time xorg-x11-Mesa-libGL is updated. I know I'm mildly offtopic for this list, but I thought I'd mention it, seeing as this package is likely to be installed by lots and lots of people using Fedora. You are far better off obsoleting xorg-x11-Mesa-libGL. No, seriously, this is BAD (TM). Cheers, -- Konstantin Ryabitsev Zlotniks, INC "???????? ?????????? ????? ? ??????? ???? ?????." From jwboyer at jdub.homelinux.org Mon Jun 6 00:10:39 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 05 Jun 2005 19:10:39 -0500 Subject: "I plan to work on..." for FC5 In-Reply-To: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> Message-ID: <1118016639.3107.148.camel@yoda.jdub.homelinux.org> On Mon, 2005-06-06 at 00:57 +0200, Miloslav Trmac wrote: > Hello world, > (Apparently I don't know any better than to send this, which could start > another long-lived "future of FC5" thread. Apologies to all if that > happens.) > > Josh's great list has "??" in most "Developer(s)" collumns, let's try > to do something about it. > > The idea is that all e-mails in this thread should start with "I plan to > work on ...". This basic filter should separate the doable projects from > the obviously impossible. Great idea! > > - It is okay to ask for help from other people, as long as you are planning > to work on implementing the feature. > > - It is okay if it turns out that the plan can't be finished; we can't > predict the future. > > - The project in question does not have to be on the current list. Absolutely correct. Feel free to add projects to the list too. And if you want to work on one that is already listed, put your name in the "Developer(s)" list. Once we get some interest in the projects, the developers working on it can come up with a due date. Btw, if someone feels the page could have better formatting that's cool too. My wiki skillz aren't the best ;) josh From seandarcy2 at gmail.com Mon Jun 6 01:45:48 2005 From: seandarcy2 at gmail.com (sean) Date: Sun, 05 Jun 2005 21:45:48 -0400 Subject: rawhide report: 20050604 changes In-Reply-To: <20050604125215.GH8706@redhat.com> References: <200506041126.j54BQ2Yj021390@porkchop.devel.redhat.com> <20050604125215.GH8706@redhat.com> Message-ID: Tim Waugh wrote: > On Sat, Jun 04, 2005 at 08:26:50AM -0400, Neal Becker wrote: > > >>Error: Missing Dependency: libijs.so()(64bit) is needed by package >>gimp-print >>Error: Missing Dependency: libgs.so.7()(64bit) is needed by package >>ImageMagick-perl >>Error: Missing Dependency: libgs.so.7()(64bit) is needed by package >>ImageMagick >>[nbecker at nbecker ~]$ sudo yum --exclude=ghostscript* upgrade >>[Now updates OK] > > > Yes, this is the very beginning of FC5 development, so things will be > a little broken at the moment. First I want to check whether some old > patches still need to be applied to ghostscript. > > Tim. > */ > So I got too smart. I figured I'd just install ghost 8.15 and rebuild ImageMagick. But: /bin/sh ./libtool --silent --tag=CXX --mode=link g++ -O2 -fPIC -ffast-math -mtune=athlon64 -ftree-vectorize -pthread -L/usr/X11R6/lib64 -L/usr/lib64 -Wl,--rpath -Wl,/usr/lib64 -lfreetype -lz -L/usr/lib -o Magick++/lib/libMagick++.la -rpath /usr/lib64 -version-info 8:2:2 Magick++/lib/Blob.lo Magick++/lib/BlobRef.lo Magick++/lib/CoderInfo.lo Magick++/lib/Color.lo Magick++/lib/Drawable.lo Magick++/lib/Exception.lo Magick++/lib/Functions.lo Magick++/lib/Geometry.lo Magick++/lib/Image.lo Magick++/lib/ImageRef.lo Magick++/lib/Montage.lo Magick++/lib/Options.lo Magick++/lib/Pixels.lo Magick++/lib/STL.lo Magick++/lib/Thread.lo Magick++/lib/TypeMetric.lo magick/libMagick.la wand/libWand.la /usr/bin/ld: Magick++/lib/.libs/CoderInfo.o: relocation R_X86_64_PC32 against `std::basic_string, std::allocator >::~basic_string()@@GLIBCXX_3.4' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status How the h*** did ImageMagick get built in the first place? sean From katzj at redhat.com Mon Jun 6 02:20:11 2005 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 05 Jun 2005 22:20:11 -0400 Subject: Making update functionality more usable (Was: Re: What next?) In-Reply-To: <1117809250.8385.11.camel@mlenzdesktop> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <1117730130.1674.3.camel@weasel.laiskiainen.org> <429FDACF.20608@rueb.com> <1117780095.3488.32.camel@cutter> <1117809250.8385.11.camel@mlenzdesktop> Message-ID: <1118024411.3011.11.camel@bree.local.net> On Fri, 2005-06-03 at 09:34 -0500, Matthew Lenz wrote: > I hate to admit it but I remove all the redhat update stuff as well and > use yum or apt-get (if i'm feeling impatient). I used ubuntu for awhile > (but ultimately found fedora to be superior) and found their update > functionality much more usable. Since one of the goals of FC5 is to have pup in place to handle updates from a graphical point of view, I'd be interested in hearing what sorts of things made the Ubuntu stuff more usable. Or the same for other distros as well. Jeremy From katzj at redhat.com Mon Jun 6 02:26:27 2005 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 05 Jun 2005 22:26:27 -0400 Subject: dkms coreward for fc5? (was Re: What next?) In-Reply-To: <604aa7910506030657111cdd8d@mail.gmail.com> References: <604aa7910506030657111cdd8d@mail.gmail.com> Message-ID: <1118024787.3011.16.camel@bree.local.net> On Fri, 2005-06-03 at 09:57 -0400, Jeff Spaleta wrote: > On 6/1/05, Elliot Lee wrote: > > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > > Extras 5 - what major features are you willing to put effort into? > > Now that dkms is in Extras... and fc4 has kernel modules in Core. > How about for fc5 we put dkms in Core and have the kernel modules in > Core use dkms to alleviate some of the sync issues we saw this time > around in rawhide. DKMS doesn't solve the problem of the dependencies for the packages not matching, so it feels to me like you're just trying to be a troll. But I'll bite ;-) As far as I'm concerned, DKMS solves the wrong problem. As long as the user has to have a compiler installed to use it, it's not useful. As long as it's not an integrated part of the packaging system, it's not useful. That said, I think that cleaning up the interaction for kernel module packages and ensuring that everything is cleanly defined such that it can work is a good goal for FC5 and I'm willing to help out some to make it happen. Spot and I talked briefly about this in New Orleans and I think the plan is to restart that discussion after he gets back from a (much needed and deserved) vacation. Once _that_ is defined, then we can think about buildsystem triggers to ensure that the packages get rebuilt in a timely fashion and that the tree thus stays sane. Jeremy From toshio at tiki-lounge.com Mon Jun 6 02:38:59 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Sun, 05 Jun 2005 22:38:59 -0400 Subject: What next? In-Reply-To: <1117995129.655.4.camel@opus.phy.duke.edu> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> <20050605174902.GI22547@redhat.com> <20050605175205.GA23912@jadzia.bu.edu> <20050605180800.GJ22547@redhat.com> <1117995129.655.4.camel@opus.phy.duke.edu> Message-ID: <1118025539.25625.88.camel@localhost> On Sun, 2005-06-05 at 14:12 -0400, seth vidal wrote: > > about the technical work which need to be done and which need to change > > the Fedora cycle durations. What, who, when, how long, and why this > > can't be done in parrallel ? All I'm getting is "we need longuer cycles" > > and still not understanding. > > > > BTW I'm not represnting Red Hat position, just an engineer trying to > > understand some engineering plumbing and not getting it. > > > > Who: fedora community people along with some red hat release engineers > What: Fedora extras steering committee > Why: We have to re-engineer EVERYTHING that y'all already have in order > to: 1. support systems which are not inside red hat's network > 2. have a buildsystem at all > 3. have an errata release mechanism at all > 4. have a db to coordinate any of these things. > We're not allowed to use or even see anything already written at rh b/c > either: 1. it sucks or 2. it's part of the 'secret sauce' that some vp > at rh thinks is valuable, somehow. > > So we have to start over from scratch on everything and only a handful > of those systems are in place: > 1. cvs - only took a year to get it happening and another 6 months to > use it > 2. account system - only 18 months > 3. build system - once extras got moving it took a mere 4 months to > get time to take care of it - and we still have to throw one away. > 4. errata system - not there yet - probably AT LEAST another 6 months > 5. db for coordination - just starting > > > oh and we need all of those things YESTERDAY. > > So there you go. - that's the list - now do you understand why we would > like a little more time before the next release? We don't need all of those things yesterday. If we did, we wouldn't have FC/FE4 rolling out soon. OTOH, I think you, Jesse, and Miloslav do a good job of stating the primary goal here: infrastructure has been taking too long to appear. We need more developer hours to make everything come together for FC5. Will changing the amount of time in a release cycle get us to that goal? I kinda doubt it. I think a longer release cycle will mean developers will get to spend more time working on their packages and projects. You might know that nine months will be enough for you to get the build system out even if no one else helps but what about the rest of the promised infrastructure gals? What we need is for more developers to spend time on the projects related to infrastructure. We need to prioritize and assign tasks. First: What things have been promised or are otherwise blocker infrastructure goals for FC5 that we must have adequate developers working on? What things should they start working on next so we can meet our goals for FC6? How many man hours will it take to complete each of the stated infrastructure goals? Are the goals something that multiple developers can work on or only certain specific developers? What things are always going to need some maintenance work so we'll have to permanently allocate some developer time to it? And then: What developers from within the Red Hat fence can be assigned to work on this instead of the projects they are working on now? What is needed to empower developers outside the fenceline to step into the roles necessary to make meaningful contributions to the infrastructure? Seth has bandwidth, hardware, information on the things the buildsystem must do to be acceptable to Red Hat, and a job that gives him time for a lot of Fedora hacking. What would be needed to (for instance) hack a new front-end for bugzilla that allows tracking of new packages in Extras from initial request, through review and fixing, into acceptance? I don't think we'll have all the infrastructure done simply by giving you nine months to work on it. I do think we can make progress by saying Seth is going to have this specific piece of the infrastructure that we have promised for FC5 done in nine months. While he's working on that we can have the other tasks promised for FC5 completed if we assign Developer A, B, and C to work on them. All other goals are allowed to slip into the FC6 (9 + 6 month time frame) although developers A and C can work on them if they finish their projects early. If people want to commit Fedora to 6 months for FC5, there will also have to be a commitment of more developers to divide up the necessary work to make that happen. -Toshio -------------- 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 katzj at redhat.com Mon Jun 6 02:43:02 2005 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 05 Jun 2005 22:43:02 -0400 Subject: What next? In-Reply-To: <1117989744.3107.114.camel@yoda.jdub.homelinux.org> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> <1117989744.3107.114.camel@yoda.jdub.homelinux.org> Message-ID: <1118025782.3011.25.camel@bree.local.net> On Sun, 2005-06-05 at 11:42 -0500, Josh Boyer wrote: > As an aside, perhaps the FESCO meeting agendas/minutes should be > publicly available somewhere. Then people who want to volunteer for > stuff like that would have a place to look. At the very least, it > provides the community with an idea of what's happening and where things > are headed. Yes, they should. This is partially my fault as I started writing up reasonable minutes and then never posted them anywhere. I can't promise a change for this week as I may not be able to make the FESCO meeting due to real life concerns, but for next week, I will _commit_ to making them available to the world at large. At least by mailing to fedora-extras-list and I'll also try to get them so they can at least be linked from fedora.redhat.com. Jeremy From katzj at redhat.com Mon Jun 6 02:58:42 2005 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 05 Jun 2005 22:58:42 -0400 Subject: What next? In-Reply-To: <42A356FD.1080507@GreenKey.net> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> <1118012841.4040.20.camel@localhost.localdomain> <42A356FD.1080507@GreenKey.net> Message-ID: <1118026722.3968.6.camel@bree.local.net> On Sun, 2005-06-05 at 12:48 -0700, Curtis Doty wrote: > OT: How does one outsider/dabbler know which specific rpm builds are > going into fc4 (or any official release) at any given point in time? There's not a "good" way at the moment other than ask. > I'm in the middle of uncovering/reverting some unpleasant behaviour > introduced into syslinux 3.08 and I'd be curious to know if the 3.08-2 > build up on rawhide is on the table for fc4 or fc5? Since only 3.07 was > in test3. 3.08 is targeted at FC4. 3.07 was broken for a pretty large number of laptops and 3.08 resolved those problems. Jeremy From notting at redhat.com Mon Jun 6 03:30:20 2005 From: notting at redhat.com (Bill Nottingham) Date: Sun, 5 Jun 2005 23:30:20 -0400 Subject: The situation with libwww. In-Reply-To: <1117988476.2797.0.camel@yoda.loki.me> References: <1117988476.2797.0.camel@yoda.loki.me> Message-ID: <20050606033020.GA8161@nostromo.devel.redhat.com> Jesse Keating (jkeating at j2solutions.net) said: > On Sat, 2005-06-04 at 15:31 -0400, Sam Varshavchik wrote: > > W3C stopped maintaining libwww three years ago > > (http://www.w3.org/Library/). > > So, what should one do after finding a bunch of major, but > > non-security > > related flaws in libwww? > > Bribe somebody to take it over and possibly somebody else to package it > for Extras? Yeah, it's headed out of Core RSN anyway - the only dep in core is a obsolete buildreq that's not actually needed. Bill From rodd at clarkson.id.au Mon Jun 6 03:31:57 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Mon, 06 Jun 2005 13:31:57 +1000 Subject: What next? In-Reply-To: <87ekbhxfih.fsf@kosh.bigo.ensc.de> References: <200506021630.48520@carola.nyarlathotep> <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <87ekbhxfih.fsf@kosh.bigo.ensc.de> Message-ID: <1118028717.4808.22.camel@jellyfish.redfishdemo.com> Not to nit pick, but... On Sun, 2005-06-05 at 12:30 +0200, Enrico Scholz wrote: > The spastic windowmode of nautilus appeared How does a windowmode 'spasm'? Rodd -- "It's a fine line between denial and faith. It's much better on my side" From byte at aeon.com.my Sun Jun 5 15:24:40 2005 From: byte at aeon.com.my (Colin Charles) Date: Sun, 05 Jun 2005 08:24:40 -0700 Subject: What next? In-Reply-To: References: Message-ID: <1117985080.25131.28.camel@arena.soho.bytebot.net> On Wed, 2005-06-01 at 13:59 -0400, Elliot Lee wrote: > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > Extras 5 - what major features are you willing to put effort into? Can we make it a point to write out Specification documents? This way we foster more openness, everyone has an idea of what we want to achieve, and its publically accessible (and more can come along to help out when they see interest) This is very much like how we did it for UbuntuDownUnder (http://udu.wiki.ubuntu.com/) and I think we can only gain from repeating this exact process We too have a wiki at http://fedoraproject.org/wiki/ and I'm sure a new section for this can be created and will foster a lot more community targets (and we'll also know what to expect for FC-5, goals, expectations, future goals, etc.) Regards -- Colin Charles, http://www.bytebot.net/ From rodd at clarkson.id.au Mon Jun 6 03:58:19 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Mon, 06 Jun 2005 13:58:19 +1000 Subject: What next? In-Reply-To: <20050602174258.GB4772@redhat.com> References: <429E362E.9060701@poolshark.org> <20050601233143.0EE352F41E2@localhost.localdomain> <429E4BF1.3040709@silverorange.com> <20050602174258.GB4772@redhat.com> Message-ID: <1118030299.4808.35.camel@jellyfish.redfishdemo.com> On Thu, 2005-06-02 at 13:42 -0400, Andrew Overholt wrote: > * Steven Garrity [2005-06-01 20:04]: > > Kaj J. Niemi wrote: > > >I would like automatic second display support (when connecting your > > >laptop to a projector for example). So far I haven't been able to figure > > >out how to do it except restart X with different settings. IMHO, it's one > > >feature Apple's Powerbooks do really well running OS X. > > > > After watching the video of the talks from Guadec, you can see that this > > is a big problem. Almost every talk started off with 5 or 10 minutes of > > fiddling to get the video-to-projector working. In some cases, the > > presentation went on with partially broken displays. > > I think part of the problem here was xrandr. It seemed that when using the > dynamic resolution switching app (which I think uses xrandr), things didn't > work. We ended up having to restart X using the resolution we wanted and > get the technician to re-sync the projector before our stuff worked (and by > 'worked' I mean 'worked for all but ~5% of the bottom of the screen' ;) . My wife's Linux based laptop (a HP running FC2) with 1024x768 resolution just works with projectors. She plugs the projector into the back and then uses the Fn- to choose between just the laptop, just the projector or both. On my laptop (a Dell running FC4) with 1920x1200 resolution I've had no luck at all getting a couple of projectors to show my screen. All these projectors were capable of sizes up to 1600x1200, but even running my laptop at these screen sizes didn't work. The problem didn't seem to be the resolution, but rather the output to the plug at the back of the laptop. By this I mean that even running my screen at 1024x768 the bottom and sides were chopped off, pretty much the same thing that happened at 1920x1200. This would be great to have addressed as I would love to be able to just plug in my laptop and go. Getting something on the screen wasn't a problem, just getting it to display (enough of) my desktop. Rodd -- "It's a fine line between denial and faith. It's much better on my side" From rodd at clarkson.id.au Mon Jun 6 04:03:39 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Mon, 06 Jun 2005 14:03:39 +1000 Subject: What next? In-Reply-To: <1117780095.3488.32.camel@cutter> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <1117730130.1674.3.camel@weasel.laiskiainen.org> <429FDACF.20608@rueb.com> <1117780095.3488.32.camel@cutter> Message-ID: <1118030619.4808.39.camel@jellyfish.redfishdemo.com> On Fri, 2005-06-03 at 02:28 -0400, seth vidal wrote: > On Thu, 2005-06-02 at 23:21 -0500, Steve Bergman wrote: > > Panu Matilainen wrote: > > > > >No such luck here, it sits there quite happily eating gobs of memory > > >until cowboys come home on all of my systems. > > > > > > - Panu - > > > > > > > > > > > > > > "chmod 700 /usr/bin/rhn-applet-gui" is standard procedure after *all* my > > installations. :-) > > > > Only root gets it then. Crude but effective. > > > > yum remove rhn-applet Another solution might be to include a simple applet as part of yum that allows users to see what new software is avaiable without having to run rhn-applet. I'd happily get rhn-applet, except that it does show me when new updates have been releasd and what's been updated (without having to go to the command line, and doing so manually). I love the applet on my desktop and just wish is was included with yum (and not rhn-applet). R. -- "It's a fine line between denial and faith. It's much better on my side" From symbiont at berlios.de Mon Jun 6 04:10:53 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Mon, 6 Jun 2005 12:10:53 +0800 Subject: Laptop Enhancements (was Re: What next?) In-Reply-To: <20050601233143.0EE352F41E2@localhost.localdomain> References: <429E362E.9060701@poolshark.org> <20050601233143.0EE352F41E2@localhost.localdomain> Message-ID: <200506061210.53488.symbiont@berlios.de> On Thursday 02 June 2005 07:31, Kaj J. Niemi wrote: > > I'd like to see better laptop support, in particular some sort of > > Profile support as well as better wireless support. Currently to > > have my laptop work both at home and at work (in dual mode), i have > > to hack rc.sysinit horribly to extend the semantic of the > > 'netprofile=' kernel argument so that it also changes the Xorg.conf > > file, .gconf files, and so on.... > > I would like automatic second display support (when connecting your > laptop to a projector for example). So far I haven't been able to > figure out how to do it except restart X with different settings. > IMHO, it's one feature Apple's Powerbooks do really well running OS > X. This should be requested upstream at X.org. All Fedora can do is provide config hackery. Automation by flipping between resolutions. meta modes, virtual resolutions, merged FB, xinerama, etc. etc. is the realm of X.org. Anyway, I can't even get the CRT/LCD switch to work since ACPI, it's just always on my IBM T30. I'd like to see better default configs for Synaptics. Recommend MergedFB over Xinerama. It's got some quirks, but it's faster. (Not all cards support it.) There also needs to be a massive undertaking to get Sleep in ACPI to actually function for a wide range of supported laptops. This includes participation in upstream ACPI to get patches and configs in. Also should include populating /etc/acpi/actions, /etc/acpi/events with the right stuff to get better behavior during sleep. Scripts could throw in cute things like kdialog or gdialog to bring up dialogs like "Computer sleeping...". Maybe a patch to Dbus to get an event instead .. who knows. Maybe there needs to be a fedora laptop mailing list, project, and working group to address all of these issues and other miscellaneous howtos littering the internet. Dealing with packaging for different laptop configurations would also be an interesting issue to address. -- -jeff From conditionterminal at gmail.com Mon Jun 6 04:26:12 2005 From: conditionterminal at gmail.com (condition terminal) Date: Mon, 6 Jun 2005 16:26:12 +1200 Subject: question about RedHat/Fedora and the GPL Message-ID: OK, firstly, I am sorry if I am miss understanding the text of the GPL. The part I am questioning is this: ---QUOTE--- complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. --END--QUOTE--- should this not mean that the likes of "beehive" be distributed? Beehive is used to create and build the entire distro, including but not limited too GPL based software. I only ask since I have been looking around and many comments have been that RH will not release it and people are told to go use mach etc. The same applies to the scripts for building the ISOs. I have seen examples of what people have been doing, but no comment form RH/Fedora. Am I barking up the wrong tree and completely missing the point? ta. From skvidal at phy.duke.edu Mon Jun 6 04:46:32 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 06 Jun 2005 00:46:32 -0400 Subject: Wiki Status Message-ID: <1118033192.19379.46.camel@cutter> Hey folks, I updated the wiki to moinmoin 1.3.4 and I changed the default theme. It has all sorts of new things now and some of them are probably even broken! :) let me know if you see anything out of place. Thanks, -sv From fedora at leemhuis.info Mon Jun 6 05:07:21 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 06 Jun 2005 07:07:21 +0200 Subject: What next? In-Reply-To: <604aa79105060512124ac6a222@mail.gmail.com> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> <1118012841.4040.20.camel@localhost.localdomain> <604aa79105060512124ac6a222@mail.gmail.com> Message-ID: <1118034441.4991.6.camel@thl.ct.heise.de> Am Sonntag, den 05.06.2005, 15:12 -0400 schrieb Jeff Spaleta: > On 6/5/05, Michael Tiemann wrote: > > I even think that your suggestion > > of a one-time-for-now 9 month cycle could make sense. > > +1 -1 The whole world (and the press also) knows "Suse and Fedora usually ship in April/May and September/October". Okay, with FC4 we're a bit late. But it would IMHO be nice if it could stay this way. And with a 9 Month schedule this time we would have the end of the beta phase around/after Chrismas. And (if we go back to 6 month after that) the next one during the summer holidays. I suspect that will decrease testing (and work spend just before release). And we'll get a lot of "gnome 2.{12,14} is out since three month -- where are Fedora packages." Just my 2 cent CU thl From notting at redhat.com Mon Jun 6 05:29:55 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 6 Jun 2005 01:29:55 -0400 Subject: What next? In-Reply-To: <200506041603.46782@carola.nyarlathotep> References: <200506021630.48520@carola.nyarlathotep> <20050602162129.GB27561@nostromo.devel.redhat.com> <200506041603.46782@carola.nyarlathotep> Message-ID: <20050606052955.GA8659@nostromo.devel.redhat.com> Aph (liste-p.alain at wanadoo.fr) said: > > > A gnome navigator by defaut : firefox is not a good choice : it's in > > > english only and many localisation don't work. > > > > Have you tried 1.0.4-4 from rawhide? > > Yes ; what is new ? I have firefox in english ?! While I can't comment on the quality fo the translations, when I run: LANG=fr_FR.UTF-8 firefox with 1.0.4-4, it does come up in French. Bill From fedora at leemhuis.info Mon Jun 6 05:34:55 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 06 Jun 2005 07:34:55 +0200 Subject: dkms coreward for fc5? (was Re: What next?) In-Reply-To: <1118024787.3011.16.camel@bree.local.net> References: <604aa7910506030657111cdd8d@mail.gmail.com> <1118024787.3011.16.camel@bree.local.net> Message-ID: <1118036096.4991.26.camel@thl.ct.heise.de> Am Sonntag, den 05.06.2005, 22:26 -0400 schrieb Jeremy Katz: > On Fri, 2005-06-03 at 09:57 -0400, Jeff Spaleta wrote: > > On 6/1/05, Elliot Lee wrote: > > > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > > > Extras 5 - what major features are you willing to put effort into? > > > > Now that dkms is in Extras... and fc4 has kernel modules in Core. > > How about for fc5 we put dkms in Core and have the kernel modules in > > Core use dkms to alleviate some of the sync issues we saw this time > > around in rawhide. I'm against using DKMS in core. IMHO it solves the problem in the wrong way. It was nice in the 2.4 days but IMHO the overhead from dkms with 2.6 kernels is way to much. But to be more productive: Lets discuss kernelmodule packaging, dkms and the issues with updateing kernel-module packages somewhere on the lists. Especially with those who maintain kernel-module packages already for a long time (Ville, moZer, C. Feist, me are the first who come to my mind; surely i missed someone). If we agree on dkms then I have no problem with it. But saying "we have X in extras so let use it in core now" is IMHO the wrong approach (and maybe stupid). > DKMS doesn't solve the problem of the dependencies for the packages not > matching, And not the yum update problem for those who don't want to install gcc-stuff. CU thl From vonbrand at inf.utfsm.cl Mon Jun 6 04:42:05 2005 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Mon, 06 Jun 2005 00:42:05 -0400 Subject: rawhide report: 20050604 changes In-Reply-To: Message from Neal Becker of "Sat, 04 Jun 2005 08:26:50 -0400." Message-ID: <200506060442.j564g56A012322@laptop11.inf.utfsm.cl> Neal Becker wrote: > Error: Missing Dependency: libijs.so()(64bit) is needed by package > gimp-print > Error: Missing Dependency: libgs.so.7()(64bit) is needed by package > ImageMagick-perl > Error: Missing Dependency: libgs.so.7()(64bit) is needed by package > ImageMagick > [nbecker at nbecker ~]$ sudo yum --exclude=ghostscript* upgrade > [Now updates OK] Same for i386 here. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From vonbrand at inf.utfsm.cl Mon Jun 6 03:13:55 2005 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Sun, 05 Jun 2005 23:13:55 -0400 Subject: Fedora Core 4 delayed until June 13 In-Reply-To: Your message of "Fri, 03 Jun 2005 13:02:42 -0400." <20050603170242.GC6057@nostromo.devel.redhat.com> Message-ID: <200506060314.j563Dtln005869@laptop11.inf.utfsm.cl> Bill Nottingham wrote: > Due to some unforseen complications, Fedora Core 4 is now > scheduled for general availability on June 13. We apologize for > the inconvenience. Care to elaborate? Beta testers want to know... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From symbiont at berlios.de Mon Jun 6 06:16:22 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Mon, 6 Jun 2005 14:16:22 +0800 Subject: question about RedHat/Fedora and the GPL In-Reply-To: References: Message-ID: <200506061416.22829.symbiont@berlios.de> On Monday 06 June 2005 12:26, condition terminal wrote: > Am I barking up the wrong tree and completely missing the point? Beehive is a meta-compiler and meta-installer which is a relm above what the GPL covers. SRPMs are provided and they are the scripts that compile and install the executables. -- -jeff From arjanv at redhat.com Mon Jun 6 06:49:28 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 06 Jun 2005 08:49:28 +0200 Subject: question about RedHat/Fedora and the GPL In-Reply-To: References: Message-ID: <1118040569.5652.2.camel@laptopd505.fenrus.org> On Mon, 2005-06-06 at 16:26 +1200, condition terminal wrote: > OK, firstly, I am sorry if I am miss understanding the text of the GPL. > > The part I am questioning is this: > > ---QUOTE--- > complete source code means all the source code for all modules it > contains, plus any associated interface definition files, plus the > scripts used to control compilation and installation of the > executable. > --END--QUOTE--- > > should this not mean that the likes of "beehive" be distributed? > Am I barking up the wrong tree and completely missing the point? yes. All the scripts needed to control the compilation and installation of the executable is in the src.rpm perfectly fine. -------------- 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 arjanv at redhat.com Mon Jun 6 06:56:25 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 06 Jun 2005 08:56:25 +0200 Subject: Wish list In-Reply-To: <20050605233713.GB3786@lists.us.dell.com> References: <1118002724.9556.34.camel@Darkstar> <42A36449.80509@n-man.com> <604aa791050605143632af676a@mail.gmail.com> <20050605233713.GB3786@lists.us.dell.com> Message-ID: <1118040985.5652.4.camel@laptopd505.fenrus.org> On Sun, 2005-06-05 at 18:37 -0500, Matt Domsch wrote: > On Sun, Jun 05, 2005 at 05:36:08PM -0400, Jeff Spaleta wrote: > > On 6/5/05, Mike Hearn wrote: > > > - Auto update is not reliable/graphical enough, or never has been for me. > > > Maybe it's fixed in FC4. > > > - Auto update breaks nvidia drivers every few weeks > > > > breaks the nvidia drivers.... installed from rpms? > > > > now that dkms is in extras... i really hope the packagers of the > > nvidia rpms look into it as making it easier to avoid updating > > problems. > > John Hull from Dell has packaged up the NVidia drivers that we release > for our Precision workstations, using DKMS. > > ftp://ftp.dell.com/video/ does this mean that everyone on this list can call Dell support when they have any nvidia issues? I can imagine that being more pleasant than the nvidia forums... -------------- 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 redhat.com Mon Jun 6 07:27:59 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 06 Jun 2005 12:57:59 +0530 Subject: Wish list In-Reply-To: References: <1118002724.9556.34.camel@Darkstar> <42A36449.80509@n-man.com> Message-ID: <42A3FAFF.7070800@redhat.com> Hi >There's real opportunity to market Linux to people coming up - with all >the great work Red Hat/NSA have been doing on security you can actually >say "Linux is fundamentally more secure than Windows, and will remain >secure as it gets popular" and believe it ... security sells, as the >Firefox developers will attest. > >Mudflap and SELinux might be slightly weird names but ExecShield is >catchy (props to whoever invented that name!), so why aren't we doing an >Apple: giving them ambiguous glowing balls for logos and slapping them on >the website? > > agreed. There needs to be more marketing done here. It helps educate people on the benefits not to mention other side benefits like actually selling the product ;-). For Fedora, do join the Fedora Marketing list if you have some creative ideas regards Rahul From tarjei.knapstad at predichem.com Mon Jun 6 07:31:33 2005 From: tarjei.knapstad at predichem.com (Tarjei Knapstad) Date: Mon, 06 Jun 2005 09:31:33 +0200 Subject: Google's Summer of Code In-Reply-To: <429FD842.2020906@atropine.ath.cx> References: <429F6D7D.5080406@atropine.ath.cx> <429FD634.9060800@margo.bijoux.nom.br> <429FD739.90504@margo.bijoux.nom.br> <429FD842.2020906@atropine.ath.cx> Message-ID: <1118043093.31098.3.camel@tarjei.predichem.nett> On Fri, 2005-06-03 at 06:10, Emily Brantley wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Just found out this page: http://fedoraproject.org/wiki/FedoraBounties > > > > Thanks Warren for putting some ideas there... I'll take a look on some > > of these ideas and try to come up with some good solutions for those > > problems (and try to get more volunteers ;D ) > > that definitely is what we needed. this thread could be a lightning-rod > of sorts for proposing other ideas, i suppose, but i'll go look at that > page now. thanks ! > A good candidate: http://www.catb.org/~esr/writings/cups-horror.html The article itself is somewhat of a rant, but that aside I've had similar trouble myself when setting up network printing here in the office and know lots of others... I can email this as a suggestion to the address mentioned on the bounties page. -- Tarjei From arjanv at redhat.com Mon Jun 6 07:38:44 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 06 Jun 2005 09:38:44 +0200 Subject: Wish list In-Reply-To: References: <1118002724.9556.34.camel@Darkstar> <42A36449.80509@n-man.com> Message-ID: <1118043525.5652.9.camel@laptopd505.fenrus.org> > > That said, currently two problems that would stop me installing Fedora > for very non-technical users: > > - Auto update is not reliable/graphical enough, or never has been for me. > Maybe it's fixed in FC4. > - Auto update breaks nvidia drivers every few weeks well the moment you use the (probably illegal) nvidia binary drivers you gave up all advantages of open source already. Especially on the security front, binary drivers have a really bad reputation and history there. > > If Fedora was more like Ubuntu in these aspects (fully graphical/automatic > auto update, supporting nvidia drivers out of the box) I'd be confident > enough to install it for a friend and then go away on holiday or > whatever, and not come back expecting trouble. so don't install the binary drivers. -------------- 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 conditionterminal at gmail.com Mon Jun 6 07:48:28 2005 From: conditionterminal at gmail.com (condition terminal) Date: Mon, 6 Jun 2005 19:48:28 +1200 Subject: question about RedHat/Fedora and the GPL In-Reply-To: <1118040569.5652.2.camel@laptopd505.fenrus.org> References: <1118040569.5652.2.camel@laptopd505.fenrus.org> Message-ID: On 6/6/05, Arjan van de Ven wrote: > On Mon, 2005-06-06 at 16:26 +1200, condition terminal wrote: > > OK, firstly, I am sorry if I am miss understanding the text of the GPL. > > > > The part I am questioning is this: > > > > ---QUOTE--- > > complete source code means all the source code for all modules it > > contains, plus any associated interface definition files, plus the > > scripts used to control compilation and installation of the > > executable. > > --END--QUOTE--- > > > > should this not mean that the likes of "beehive" be distributed? > > > Am I barking up the wrong tree and completely missing the point? > > yes. All the scripts needed to control the compilation and installation > of the executable is in the src.rpm perfectly fine. OK then.. so how are the files and scripts used to control the building of the rpms outside the specs excluded from the conditions of the GPL? ta From tarjei.knapstad at predichem.com Mon Jun 6 07:56:42 2005 From: tarjei.knapstad at predichem.com (Tarjei Knapstad) Date: Mon, 06 Jun 2005 09:56:42 +0200 Subject: google summer of code In-Reply-To: <42A3410A.8040901@web.de> References: <42A04AEF.9080309@web.de> <1117807625.23296.37.camel@gibraltar.stuttgart.redhat.com> <42A067E4.7010005@web.de> <1117822916.3355.7.camel@localhost.localdomain> <42A0A194.704@web.de> <42A3410A.8040901@web.de> Message-ID: <1118044602.31098.6.camel@tarjei.predichem.nett> On Sun, 2005-06-05 at 20:14, ness wrote: > I've written a spec file for what I'd do (see attachment). > I don't wan't to press so., but there's not much time until June 14th, > the final deadlinev for applying to the google summer of code. It would > be really nice if so. could tell me whether my idea is accepted and > fredora would like o be the mentoring organization or not, because of if > not I've to ask so. other (eg. ubuntu), but I like the idea of a > community distribution like fredora. Hi! The FedoraBounties Wiki page mentioned in another thread says: "If you would like clarification on any of these projects, have a great idea for a project not listed here (doesn't even have to be Fedora-specific!), or would like help applying, please e-mail summerofcode05 at fedora.redhat.com." So that's probably the right place to send off your spec. The wiki is here: http://fedoraproject.org/wiki/FedoraBounties Good luck! -- Tarjei From veillard at redhat.com Mon Jun 6 08:07:23 2005 From: veillard at redhat.com (Daniel Veillard) Date: Mon, 6 Jun 2005 04:07:23 -0400 Subject: What next? In-Reply-To: <1118025782.3011.25.camel@bree.local.net> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> <1117989744.3107.114.camel@yoda.jdub.homelinux.org> <1118025782.3011.25.camel@bree.local.net> Message-ID: <20050606080723.GO22547@redhat.com> On Sun, Jun 05, 2005 at 10:43:02PM -0400, Jeremy Katz wrote: > On Sun, 2005-06-05 at 11:42 -0500, Josh Boyer wrote: > > As an aside, perhaps the FESCO meeting agendas/minutes should be > > publicly available somewhere. Then people who want to volunteer for > > stuff like that would have a place to look. At the very least, it > > provides the community with an idea of what's happening and where things > > are headed. > > Yes, they should. This is partially my fault as I started writing up > reasonable minutes and then never posted them anywhere. I can't promise > a change for this week as I may not be able to make the FESCO meeting > due to real life concerns, but for next week, I will _commit_ to making > them available to the world at large. At least by mailing to > fedora-extras-list and I'll also try to get them so they can at least be > linked from fedora.redhat.com. Thanks, this is a painful routine, but from my experience as Gnome secretary it's important for the community and it's better to have not perfect minutes delivered quickly after the meeting than perfect minutes posted 3 weeks later (when faced with "I should finish the minutes and post them when I have more time" I would suggest to just post them as is, then the worse which can happen is that people will ask more question and raise awareness :-) Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From arjanv at redhat.com Mon Jun 6 08:08:48 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 06 Jun 2005 10:08:48 +0200 Subject: question about RedHat/Fedora and the GPL In-Reply-To: References: <1118040569.5652.2.camel@laptopd505.fenrus.org> Message-ID: <1118045329.5652.19.camel@laptopd505.fenrus.org> On Mon, 2005-06-06 at 19:48 +1200, condition terminal wrote: > On 6/6/05, Arjan van de Ven wrote: > > On Mon, 2005-06-06 at 16:26 +1200, condition terminal wrote: > > > OK, firstly, I am sorry if I am miss understanding the text of the GPL. > > > > > > The part I am questioning is this: > > > > > > ---QUOTE--- > > > complete source code means all the source code for all modules it > > > contains, plus any associated interface definition files, plus the > > > scripts used to control compilation and installation of the > > > executable. > > > --END--QUOTE--- > > > > > > should this not mean that the likes of "beehive" be distributed? > > > > > Am I barking up the wrong tree and completely missing the point? > > > > yes. All the scripts needed to control the compilation and installation > > of the executable is in the src.rpm perfectly fine. > > OK then.. so how are the files and scripts used to control the > building of the rpms outside the specs excluded from the conditions of > the GPL? I guess it comes down to with what you mean with "control". I'm not a lawyer, but control means to me "have impact on the result". The goal is that the binary building process is fully reproducable (see earlier parts of the license about the rationale). All the parts that impact the results are included in the src.rpm (with some global settings from redhat-rpm-config which is also shipped). The RH buildsystem actually calls rpmbuild to build the binary, all it does on top of that is some queueing. Queueing does not impact the outcome of the build in any way. The intent of the GPL is clearly that you have to provide the Makefiles and any other scripts you use to build the source code. A src.rpm is clearly that, it has everything used to build the source code (if it didn't the RH buildsystem couldn't even build it in the first place). Or in other words "scripts to control compilation of the executable" means "makefiles and related". I'd argue that a buildsystem doesn't contain scripts to control the binary, what it does is invoke those scripts at certain moments in time. That's a pretty important difference. There is a gray area, and that gray area is if a spec file belongs into this. When the sourcecode is autoconf'd, is a spec file that just calls configure, make and make install something that controls the compilation of the executable? Borderline. I guess you can argue it does since the outcome changes depending on the the configure flags passed, and if the spec does pass any, it's controls the creation of the binary. -------------- 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 symbiont at berlios.de Mon Jun 6 08:22:28 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Mon, 6 Jun 2005 16:22:28 +0800 Subject: question about RedHat/Fedora and the GPL In-Reply-To: References: <1118040569.5652.2.camel@laptopd505.fenrus.org> Message-ID: <200506061622.28649.symbiont@berlios.de> On Monday 06 June 2005 15:48, condition terminal wrote: > OK then.. so how are the files and scripts used to control the > building of the rpms outside the specs excluded from the conditions > of the GPL? Think of beehive as an over-glorified cron system. If you use cron to do a daily checkout from CVS and build a system, that doesn't mean you need to release the source code to cron for every release of your software. You could even use some proprietary cron setup and still not be obligated to release it. -- -jeff From nphilipp at redhat.com Mon Jun 6 08:24:08 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 06 Jun 2005 10:24:08 +0200 Subject: nvidia-glx-1.0.7664-0.lvn.1.3.src.rpm In-Reply-To: References: Message-ID: <1118046248.19918.3.camel@gibraltar.stuttgart.redhat.com> On Sun, 2005-06-05 at 12:35 -0400, Neal Becker wrote: > I updated linva nvidia package with latest from nvidia, and placed the > result here: > > http://nbecker.dyndns.org:8080/nvidia-glx-1.0.7664-0.lvn.1.3.src.rpm Note that this driver version broke suspend/resume for me (oh the joys of proprietary software with a proprietary development model), the display gets garbled. After some dabbling with it I found a workaround, though: Setting the display to DPMS suspend, then on again brought the card back into a semi-sane state (X works, text console are still garbled). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain 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 enrico.scholz at informatik.tu-chemnitz.de Mon Jun 6 08:25:12 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 06 Jun 2005 10:25:12 +0200 Subject: Firefox crippling (was: What next?) In-Reply-To: <20050605161545.GA28581@devserv.devel.redhat.com> (Alan Cox's message of "Sun, 5 Jun 2005 12:15:45 -0400") References: <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <87ekbhxfih.fsf@kosh.bigo.ensc.de> <20050605161545.GA28581@devserv.devel.redhat.com> Message-ID: <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> alan at redhat.com (Alan Cox) writes: > On Sun, Jun 05, 2005 at 12:30:14PM +0200, Enrico Scholz wrote: >> why they could not be patched into Ooffice; RH is crippl^Wpatching other >> programs (e.g. firefox) already, so Ooffice could become a little bit > > Actually firefox support for unixlike keybindings is something from > the Firefox community rather than RH as I understand it. The broken (windoze-like) keybindings (which appear suddenly and without prior confirmation although formerly the Unix like keybindings were active) are probably caused by a Gnome2 misbehavior. The firefox crippling is the result of %patch25-29 in the src.rpm: it removes the functionality which allows to update extensions with potential security leaks, and it replaces the nice looking default icons with butt-ugly icons from a Gnome2 theme. There exists a better patch for the first issue (which disables only the capability to upgrade the application but still allows to update extensions) but it is silently ignored by the firefox maintainer. Regarding the ugly icons, I do not see how this change can be justified. The new icons are objectively ugly, the default firefox icons are much nicer and there are now some missing icons. So it seems that these icon patches are only applied to satisfy some brainless Gnome2 ideas about consistent lookout of applications (which might have different functionality and can never have the same lookout therefore). Based on the discussion regarding the "Firefox" branding, I do not see how the FC4 firefox can be stilled named "Firefox" as it is destroys the reputation of the project. Enrico From nphilipp at redhat.com Mon Jun 6 08:28:15 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 06 Jun 2005 10:28:15 +0200 Subject: NVidia RPMs from Dell (Re: Wish list) In-Reply-To: References: <1118002724.9556.34.camel@Darkstar> <42A36449.80509@n-man.com> <604aa791050605143632af676a@mail.gmail.com> <20050605233713.GB3786@lists.us.dell.com> Message-ID: <1118046495.19918.7.camel@gibraltar.stuttgart.redhat.com> On Sun, 2005-06-05 at 19:57 -0400, Konstantin Ryabitsev wrote: > On 6/5/05, Matt Domsch wrote: > > John Hull from Dell has packaged up the NVidia drivers that we release > > for our Precision workstations, using DKMS. > > > > ftp://ftp.dell.com/video/ > > dell-nvidia-7167-5dkms.src.rpm > > dell-nvidia-7167-multiarch-5.tar.gz > > Hmm... well, I'm not an expert or anything, but doing this in %post is > probably sub-.. er... optimal. :) > > #Remove existing GL libraries > rm -rf /usr/X11R6/lib/libGL.* > /dev/null 2>&1 > rm -rf /usr/X11R6/lib/modules/extensions/libGLcore.* > /dev/null 2>&1 > rm -rf /usr/X11R6/lib/modules/extensions/libglx.a > /dev/null 2>&1 > rm -rf /usr/X11R6/lib64/libGL.* > /dev/null 2>&1 > rm -rf /usr/X11R6/lib64/modules/extensions/libGLcore.* > /dev/null 2>&1 > rm -rf /usr/X11R6/lib64/modules/extensions/libglx.a > /dev/null 2>&1 John should look at how livna packages the nvidia drivers (enabling one to install it cleanly along the normal GL libraries), the above is just tasteless ;-). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain 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 Axel.Thimm at ATrpms.net Mon Jun 6 09:22:46 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 6 Jun 2005 11:22:46 +0200 Subject: Beware of nvidia-graphics 1.0-7664 (was: nvidia-glx-1.0.7664-0.lvn.1.3.src.rpm) In-Reply-To: <1118046248.19918.3.camel@gibraltar.stuttgart.redhat.com> References: <1118046248.19918.3.camel@gibraltar.stuttgart.redhat.com> Message-ID: <20050606092246.GF4511@neu.nirvana> On Mon, Jun 06, 2005 at 10:24:08AM +0200, Nils Philippsen wrote: > Note that this driver version broke suspend/resume for me (oh the joys > of proprietary software with a proprietary development model), the > display gets garbled. After some dabbling with it I found a workaround, > though: Setting the display to DPMS suspend, then on again brought the > card back into a semi-sane state (X works, text console are still > garbled). Yes, I had to find that out myself when the screensaver kicked in killing two hours of work ... :/ Also XvMC libs are broken :/ The joys of closed source. I suspect there will be an updated quite imminent. For ATrpms users: If you want to test this release nevertheless, use nvidia-graphics-switch to switch to and from this new release. Don't uninstall the previous driver, yet ;) -- 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 rms at 1407.org Mon Jun 6 08:53:31 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Mon, 06 Jun 2005 09:53:31 +0100 Subject: Making update functionality more usable (Was: Re: What next?) In-Reply-To: <1118024411.3011.11.camel@bree.local.net> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <1117730130.1674.3.camel@weasel.laiskiainen.org> <429FDACF.20608@rueb.com> <1117780095.3488.32.camel@cutter> <1117809250.8385.11.camel@mlenzdesktop> <1118024411.3011.11.camel@bree.local.net> Message-ID: <1118048011.2779.2.camel@roque> On Sun, 2005-06-05 at 22:20 -0400, Jeremy Katz wrote: > On Fri, 2005-06-03 at 09:34 -0500, Matthew Lenz wrote: > > I hate to admit it but I remove all the redhat update stuff as well and > > use yum or apt-get (if i'm feeling impatient). I used ubuntu for awhile > > (but ultimately found fedora to be superior) and found their update > > functionality much more usable. > > Since one of the goals of FC5 is to have pup in place to handle updates > from a graphical point of view, I'd be interested in hearing what sorts > of things made the Ubuntu stuff more usable. Or the same for other > distros as well. The update-notifier is wonderfull. I have a translator using Ubuntu, and the way the icon *only* shows it self when there are updates was enough to make her go check it out. When she was trying Fedora, that didn't happen. The icon was always there, and making it flash wasn't appealing enough. Also, the way it was just click... click... now it's updating, was so easy that I've found she's updating without ever having to tell her to do it :) Rui -- + 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...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.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 jos at xos.nl Mon Jun 6 10:03:54 2005 From: jos at xos.nl (Jos Vos) Date: Mon, 6 Jun 2005 12:03:54 +0200 Subject: question about RedHat/Fedora and the GPL In-Reply-To: <1118045329.5652.19.camel@laptopd505.fenrus.org>; from arjanv@redhat.com on Mon, Jun 06, 2005 at 10:08:48AM +0200 References: <1118040569.5652.2.camel@laptopd505.fenrus.org> <1118045329.5652.19.camel@laptopd505.fenrus.org> Message-ID: <20050606120354.A18425@xos037.xos.nl> On Mon, Jun 06, 2005 at 10:08:48AM +0200, Arjan van de Ven wrote: > I guess it comes down to with what you mean with "control". I'm not a > lawyer, but control means to me "have impact on the result". The goal is > that the binary building process is fully reproducable (see earlier > parts of the license about the rationale). All the parts that impact the > results are included in the src.rpm (with some global settings from > redhat-rpm-config which is also shipped). The RH buildsystem actually > calls rpmbuild to build the binary, all it does on top of that is some > queueing. Queueing does not impact the outcome of the build in any way. Although I agree with most of your comments, two remarks: - There seem to be a few settings that are different from redhat-rpm-config: see my thread started with https://www.redhat.com/archives/fedora-devel-list/2005-February/msg00523.html about rebuilding pango c.s. that was never really answered... OK, I can imagine what settings it needs, and our local RHEL-rebuild environment has implemented that ;-), but that's actually a bit of reverse engineering. At least in FC3 (didn't check FC4t* yet) this was still the issue. - Except from the build environment software itself, there's always "all the software on the build host" that may influence a build (more specifically "configure"). This has no direct relation to releasing the build environment software, although that software may control it, but with this I want to say you'll never be 100% sure to exactly match the original environment. This is also not required by the GPL, IMHO, as it can be brought down to even HW/BIOS issues, when you look at it from an academical point of view. For this discussion it's much more interesting to see how vendors of proprietary software/equipment with GPL stuff included/embedded deal with this. There's much more to win in that area, than blaming RH for not releasing some internal tools: see also . -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From arjanv at redhat.com Mon Jun 6 10:07:26 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 6 Jun 2005 12:07:26 +0200 Subject: question about RedHat/Fedora and the GPL In-Reply-To: <20050606120354.A18425@xos037.xos.nl> References: <1118040569.5652.2.camel@laptopd505.fenrus.org> <1118045329.5652.19.camel@laptopd505.fenrus.org> <20050606120354.A18425@xos037.xos.nl> Message-ID: <20050606100725.GC31431@devserv.devel.redhat.com> On Mon, Jun 06, 2005 at 12:03:54PM +0200, Jos Vos wrote: > On Mon, Jun 06, 2005 at 10:08:48AM +0200, Arjan van de Ven wrote: > > > I guess it comes down to with what you mean with "control". I'm not a > > lawyer, but control means to me "have impact on the result". The goal is > > that the binary building process is fully reproducable (see earlier > > parts of the license about the rationale). All the parts that impact the > > results are included in the src.rpm (with some global settings from > > redhat-rpm-config which is also shipped). The RH buildsystem actually > > calls rpmbuild to build the binary, all it does on top of that is some > > queueing. Queueing does not impact the outcome of the build in any way. > > Although I agree with most of your comments, two remarks: > > - There seem to be a few settings that are different from redhat-rpm-config: > see my thread started with > > https://www.redhat.com/archives/fedora-devel-list/2005-February/msg00523.html > > about rebuilding pango c.s. that was never really answered... OK, I can > imagine what settings it needs, and our local RHEL-rebuild environment > has implemented that ;-), but that's actually a bit of reverse engineering. > At least in FC3 (didn't check FC4t* yet) this was still the issue. rpmbuild --target i386 From alan at redhat.com Mon Jun 6 11:13:21 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 6 Jun 2005 07:13:21 -0400 Subject: What next? In-Reply-To: <1117989035.7104.36.camel@cutter> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> Message-ID: <20050606111321.GA1339@devserv.devel.redhat.com> On Sun, Jun 05, 2005 at 12:30:35PM -0400, seth vidal wrote: > Nice of y'all to allow yourself longer release cycles while denying it > to fedora community developers. Nobody is denying it to anyone. If a project takes 3 years it takes 3 years and at some point its ready to merge into distributions. Its also worth remembering large parts of the RHEL release cycle would drive most developers nuts because they consist of "justify that specific change", "which bug id", "who signed this off", "you can't import the current release backport the change" ... not 'development'. Alan From alan at redhat.com Mon Jun 6 11:23:56 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 6 Jun 2005 07:23:56 -0400 Subject: Firefox crippling (was: What next?) In-Reply-To: <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> References: <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <87ekbhxfih.fsf@kosh.bigo.ensc.de> <20050605161545.GA28581@devserv.devel.redhat.com> <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> Message-ID: <20050606112356.GC1339@devserv.devel.redhat.com> On Mon, Jun 06, 2005 at 10:25:12AM +0200, Enrico Scholz wrote: > prior confirmation although formerly the Unix like keybindings were > active) are probably caused by a Gnome2 misbehavior. As I understand it, it should pick up the preferences from your gnome settings - ie if the emacs key support is on in gnome then firefox should use them [I find it funny people call it "Unix like" keybindings btw, historically its nothing like 'unix keybindings' 8)] I'm not too familiar with all the other bits you comment on. From buildsys at redhat.com Mon Jun 6 11:29:08 2005 From: buildsys at redhat.com (Build System) Date: Mon, 6 Jun 2005 07:29:08 -0400 Subject: rawhide report: 20050606 changes Message-ID: <200506061129.j56BT87T029902@porkchop.devel.redhat.com> Updated Packages: VFlib2-2.25.6-29 ---------------- * Mon Jun 06 2005 Akira TAGOH - 2.25.6-29 - convert a spec file to UTF-8. (#159577) arts-8:1.4.1-1 -------------- * Mon Jun 06 2005 Than Ngo 8:1.4.1-1 - 1.4.1 iiimf-le-xcin-0.1.10-2 ---------------------- * Mon Jun 06 2005 Leon Ho - 0.1.10-2 - requires > iiimf-server-12.2-1 - fix key accelerations (RH#154789) * Thu Apr 07 2005 Jens Petersen - update %sendhup to signal iiimd joe-3.3-1 --------- * Mon Jun 06 2005 Ivana Varekova 3.3-1 - new upstream version net-tools-1.60-53 ----------------- * Mon Jun 06 2005 Radek Vokal 1.60-53 - etherwake man page changed to ether-wake (#159156) spamassassin-3.0.4-1.fc5 ------------------------ * Sun Jun 05 2005 Warren Togami - 3.0.4-1 - 3.0.4 From e_mc_h2 at web.de Mon Jun 6 11:43:46 2005 From: e_mc_h2 at web.de (ness) Date: Mon, 06 Jun 2005 13:43:46 +0200 Subject: google summer of code In-Reply-To: <1118044602.31098.6.camel@tarjei.predichem.nett> References: <42A04AEF.9080309@web.de> <1117807625.23296.37.camel@gibraltar.stuttgart.redhat.com> <42A067E4.7010005@web.de> <1117822916.3355.7.camel@localhost.localdomain> <42A0A194.704@web.de> <42A3410A.8040901@web.de> <1118044602.31098.6.camel@tarjei.predichem.nett> Message-ID: <42A436F2.10506@web.de> An HTML attachment was scrubbed... URL: From mattdm at mattdm.org Mon Jun 6 12:37:39 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 6 Jun 2005 08:37:39 -0400 Subject: Firefox crippling (was: What next?) In-Reply-To: <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> References: <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <87ekbhxfih.fsf@kosh.bigo.ensc.de> <20050605161545.GA28581@devserv.devel.redhat.com> <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> Message-ID: <20050606123739.GA18458@jadzia.bu.edu> On Mon, Jun 06, 2005 at 10:25:12AM +0200, Enrico Scholz wrote: > The firefox crippling is the result of %patch25-29 in the src.rpm: it > removes the functionality which allows to update extensions with > potential security leaks, and it replaces the nice looking default > icons with butt-ugly icons from a Gnome2 theme. > > There exists a better patch for the first issue (which disables only > the capability to upgrade the application but still allows to update > extensions) but it is silently ignored by the firefox maintainer. That'd be: To be a little more fair to the RH firefox maintainer, he's waiting for a better-designed updates infrastructure from the upstream project. But I think that's a bit over-optimistic and would really appreciate it if the less-intrusive replacement patch were swapped in in the meantime. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 80 degrees Fahrenheit. From tiemann at redhat.com Mon Jun 6 16:44:44 2005 From: tiemann at redhat.com (Michael Tiemann) Date: Mon, 06 Jun 2005 12:44:44 -0400 Subject: What next? In-Reply-To: <20050606080723.GO22547@redhat.com> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> <1117989744.3107.114.camel@yoda.jdub.homelinux.org> <1118025782.3011.25.camel@bree.local.net> <20050606080723.GO22547@redhat.com> Message-ID: <1118076284.4026.11.camel@localhost.localdomain> On Mon, 2005-06-06 at 04:07 -0400, Daniel Veillard wrote: > On Sun, Jun 05, 2005 at 10:43:02PM -0400, Jeremy Katz wrote: > > On Sun, 2005-06-05 at 11:42 -0500, Josh Boyer wrote: > > > As an aside, perhaps the FESCO meeting agendas/minutes should be > > > publicly available somewhere. Then people who want to volunteer for > > > stuff like that would have a place to look. At the very least, it > > > provides the community with an idea of what's happening and where things > > > are headed. > > > > Yes, they should. This is partially my fault as I started writing up > > reasonable minutes and then never posted them anywhere. I can't promise > > a change for this week as I may not be able to make the FESCO meeting > > due to real life concerns, but for next week, I will _commit_ to making > > them available to the world at large. At least by mailing to > > fedora-extras-list and I'll also try to get them so they can at least be > > linked from fedora.redhat.com. > > Thanks, this is a painful routine, but from my experience as Gnome secretary > it's important for the community and it's better to have not perfect minutes > delivered quickly after the meeting than perfect minutes posted 3 weeks > later (when faced with "I should finish the minutes and post them when I have > more time" I would suggest to just post them as is, then the worse which can > happen is that people will ask more question and raise awareness :-) +1 The reason that most board agendas begin with "approval of the minutes from the last meeting" is specifically so that minutes can be distributed quickly and corrected later if there's a problem. Buffering minutes to get them right leads to more trouble than it's worth. M From skvidal at phy.duke.edu Mon Jun 6 13:04:21 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 06 Jun 2005 09:04:21 -0400 Subject: What next? In-Reply-To: <20050606111321.GA1339@devserv.devel.redhat.com> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> <20050606111321.GA1339@devserv.devel.redhat.com> Message-ID: <1118063061.19379.76.camel@cutter> On Mon, 2005-06-06 at 07:13 -0400, Alan Cox wrote: > On Sun, Jun 05, 2005 at 12:30:35PM -0400, seth vidal wrote: > > Nice of y'all to allow yourself longer release cycles while denying it > > to fedora community developers. > > Nobody is denying it to anyone. If a project takes 3 years it takes 3 years > and at some point its ready to merge into distributions. read the followup emails from this thread. I think you're misunderstanding me. -sv From enrico.scholz at informatik.tu-chemnitz.de Mon Jun 6 13:12:00 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 06 Jun 2005 15:12:00 +0200 Subject: Firefox crippling In-Reply-To: <20050606112356.GC1339@devserv.devel.redhat.com> (Alan Cox's message of "Mon, 6 Jun 2005 07:23:56 -0400") References: <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <87ekbhxfih.fsf@kosh.bigo.ensc.de> <20050605161545.GA28581@devserv.devel.redhat.com> <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> <20050606112356.GC1339@devserv.devel.redhat.com> Message-ID: <87hdgbtysf.fsf@kosh.bigo.ensc.de> alan at redhat.com (Alan Cox) writes: >> prior confirmation although formerly the Unix like keybindings were >> active) are probably caused by a Gnome2 misbehavior. > > As I understand it, it should pick up the preferences from your gnome > settings - ie if the emacs key support is on in gnome then firefox > should use them Yes, that's the Gnome2 misbehavior I am speaking about. There was a firefox in an existing Gnome2 environment with emacs-style keybindings and from one day to the other, these bindings did not work anymore. Using autoupdate functionality for Gnome2 packages will be the total horror for the enduser support... Enrico From cmadams at hiwaay.net Mon Jun 6 13:16:47 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 6 Jun 2005 08:16:47 -0500 Subject: Firefox crippling (was: What next?) In-Reply-To: <20050606112356.GC1339@devserv.devel.redhat.com> References: <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <87ekbhxfih.fsf@kosh.bigo.ensc.de> <20050605161545.GA28581@devserv.devel.redhat.com> <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> <20050606112356.GC1339@devserv.devel.redhat.com> Message-ID: <20050606131647.GA1526570@hiwaay.net> Once upon a time, Alan Cox said: > [I find it funny people call it "Unix like" keybindings btw, historically its > nothing like 'unix keybindings' 8)] ^W is a Unix "delete previous word" keybinding. In Firefox now however that closes the current window (quite annoying when you are editing a significant text area, like a Bugzilla report, and want to delete the last word quickly and instead close the window and lose everything you've entered). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From brugolsky at telemetry-investments.com Mon Jun 6 13:39:41 2005 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Mon, 6 Jun 2005 09:39:41 -0400 Subject: [PATCH] mkinitrd rescue mode In-Reply-To: <1117889444.7838.10.camel@localhost.localdomain> References: <1117653405.12259.51.camel@barsoom.rdu.redhat.com> <1117725836.3768.15.camel@bree.local.net> <1117731994.12259.68.camel@barsoom.rdu.redhat.com> <1117743443.3768.37.camel@bree.local.net> <20050602210436.GA4357@ti64.telemetry-investments.com> <1117889444.7838.10.camel@localhost.localdomain> Message-ID: <20050606133940.GA16224@ti64.telemetry-investments.com> On Sat, Jun 04, 2005 at 08:50:44AM -0400, Jeff Layton wrote: > The early-userspace docs seem to state that you can only have a single > cpio archive, but that multiple 'images' are allowed. I'm not clear at > this point on what these images are and how they're stored, however. I was referring explicitly to this: In human terms, the initramfs buffer contains a collection of compressed and/or uncompressed cpio archives (in the "newc" or "crc" formats); arbitrary amounts zero bytes (for padding) can be added between members. Back in 2001, Dave Cinege proposed the following patch for GRUB: http://lists.gnu.org/archive/html/bug-grub/2001-06/msg00141.html This patch fixes GRUB's initrd loading behavior. Each 'initrd' call is now loaded 'inline' instead of replacing the previous file. This allows one to load an initrd image that is split across several devices (or floppies, using 'pause'). It also allows kernel patches like initrd_dynamic to load multiple tgz archives to construct a root. ... Some version of this appears to have been incorporated into GRUB. In any case, with an appropriately patched boot loader, one could specify two initrd load lines, and they will be concatenated together. There ought to be a base initrd with hooks that would automatically pick up add-on functionality just by placing files into the appropriate ".d" directories, just as Red Hat has wisely done all over the rest of the distribution. A sample GRUB stanza might look like: title Fedora Core Rescue Mode (2.6.11-1.1369_FC4) kernel /vmlinuz-2.6.11-1.1369_FC4 ro root=LABEL=/ acpi=on initrd /initrd-boot.img initrd /initrd-2.6.11-1.1369_FC4.img initrd /initrd-rescue.img My preference would be to place add-on functionality in a directory under sysconfig, e.g., /etc/sysconfig/boot.d/*, so that rpms for EVMS, net booting, ... , could simply drop files there. -Bill From alan at redhat.com Mon Jun 6 13:41:35 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 6 Jun 2005 09:41:35 -0400 Subject: Firefox crippling (was: What next?) In-Reply-To: <20050606131647.GA1526570@hiwaay.net> References: <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <87ekbhxfih.fsf@kosh.bigo.ensc.de> <20050605161545.GA28581@devserv.devel.redhat.com> <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> <20050606112356.GC1339@devserv.devel.redhat.com> <20050606131647.GA1526570@hiwaay.net> Message-ID: <20050606134135.GA7916@devserv.devel.redhat.com> On Mon, Jun 06, 2005 at 08:16:47AM -0500, Chris Adams wrote: > significant text area, like a Bugzilla report, and want to delete the > last word quickly and instead close the window and lose everything > you've entered). And if it closes without asking that would be a large bug for the mozilla bugzilla.. From nphilipp at redhat.com Mon Jun 6 13:41:58 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 06 Jun 2005 15:41:58 +0200 Subject: Beware of nvidia-graphics 1.0-7664 (was: nvidia-glx-1.0.7664-0.lvn.1.3.src.rpm) In-Reply-To: <20050606092246.GF4511@neu.nirvana> References: <1118046248.19918.3.camel@gibraltar.stuttgart.redhat.com> <20050606092246.GF4511@neu.nirvana> Message-ID: <1118065318.13470.2.camel@wombat.tiptoe.de> On Mon, 2005-06-06 at 11:22 +0200, Axel Thimm wrote: > On Mon, Jun 06, 2005 at 10:24:08AM +0200, Nils Philippsen wrote: > > Note that this driver version broke suspend/resume for me (oh the joys > > of proprietary software with a proprietary development model), the > > display gets garbled. After some dabbling with it I found a workaround, > > though: Setting the display to DPMS suspend, then on again brought the > > card back into a semi-sane state (X works, text console are still > > garbled). > > Yes, I had to find that out myself when the screensaver kicked in > killing two hours of work ... :/ Hmm, screensavers work just fine here, I only had problems with suspend/resume until I implemented the workaround. > Also XvMC libs are broken :/ Care to elaborate? I don't see these in the livna RPMs I use, but maybe they're just missing ;-). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain 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 shiva at sewingwitch.com Mon Jun 6 14:07:02 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Mon, 06 Jun 2005 07:07:02 -0700 Subject: Firefox crippling (was: What next?) In-Reply-To: <20050606131647.GA1526570@hiwaay.net> References: <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <87ekbhxfih.fsf@kosh.bigo.ensc.de> <20050605161545.GA28581@devserv.devel.redhat.com> <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> <20050606112356.GC1339@devserv.devel.redhat.com> <20050606131647.GA1526570@hiwaay.net> Message-ID: <51B54E96EF2442960C65057B@[10.169.6.246]> --On Monday, June 06, 2005 8:16 AM -0500 Chris Adams wrote: > Once upon a time, Alan Cox said: >> [I find it funny people call it "Unix like" keybindings btw, >> historically its nothing like 'unix keybindings' 8)] > > ^W is a Unix "delete previous word" keybinding. I remember using that on TOPS-20 in the early 80's. Did it inherit the command line hot keys from early Unix? I usually get burned using control-W in the command buffer of Lugaru Epsilon, a commercial Emacs clone (available for Win32, Linux, and BSD). In that context it "wipes" everything back to the last mark, which if one wasn't explicitly set, defaults to the start of the buffer. If I then mindlessly yank, it pastes the entire command buffer into the current command line. Fortunately this now generates a popup warning asking me if I really want to paste 1000's of command lines. (Lugaru is very responsive to user requests.) From alan at redhat.com Mon Jun 6 14:11:10 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 6 Jun 2005 10:11:10 -0400 Subject: Firefox crippling (was: What next?) In-Reply-To: <51B54E96EF2442960C65057B@[10.169.6.246]> References: <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <87ekbhxfih.fsf@kosh.bigo.ensc.de> <20050605161545.GA28581@devserv.devel.redhat.com> <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> <20050606112356.GC1339@devserv.devel.redhat.com> <20050606131647.GA1526570@hiwaay.net> <51B54E96EF2442960C65057B@[10.169.6.246]> Message-ID: <20050606141110.GA22394@devserv.devel.redhat.com> On Mon, Jun 06, 2005 at 07:07:02AM -0700, Kenneth Porter wrote: > >^W is a Unix "delete previous word" keybinding. > > I remember using that on TOPS-20 in the early 80's. Did it inherit the > command line hot keys from early Unix? via emacs. Traditional unix never had 'delete word'. I suspect it may have come via teco originally but lets not mention that too many times in case it comes back to life ;) Alan From Axel.Thimm at ATrpms.net Mon Jun 6 14:14:01 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 6 Jun 2005 16:14:01 +0200 Subject: Beware of nvidia-graphics 1.0-7664 In-Reply-To: <1118065318.13470.2.camel@wombat.tiptoe.de> References: <1118046248.19918.3.camel@gibraltar.stuttgart.redhat.com> <20050606092246.GF4511@neu.nirvana> <1118065318.13470.2.camel@wombat.tiptoe.de> Message-ID: <20050606141401.GA15733@neu.nirvana> On Mon, Jun 06, 2005 at 03:41:58PM +0200, Nils Philippsen wrote: > On Mon, 2005-06-06 at 11:22 +0200, Axel Thimm wrote: > > On Mon, Jun 06, 2005 at 10:24:08AM +0200, Nils Philippsen wrote: > > > Note that this driver version broke suspend/resume for me (oh the joys > > > of proprietary software with a proprietary development model), the > > > display gets garbled. After some dabbling with it I found a workaround, > > > though: Setting the display to DPMS suspend, then on again brought the > > > card back into a semi-sane state (X works, text console are still > > > garbled). > > > > Yes, I had to find that out myself when the screensaver kicked in > > killing two hours of work ... :/ > > Hmm, screensavers work just fine here, I only had problems with > suspend/resume until I implemented the workaround. My symptoms are display goes black, but never returns. The system works fine though, but a headless laptop is no joy ... :/ > > Also XvMC libs are broken :/ > > Care to elaborate? I don't see these in the livna RPMs I use, but maybe > they're just missing ;-). libXvMCNVIDIA_dynamic.so.1 is refencing _nv0019XvMCdynamic which does not exist. You'll only hit it if you use XvMC, e.g. mplayer/mythtv/xine etc. -- 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 cmadams at hiwaay.net Mon Jun 6 14:29:52 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 6 Jun 2005 09:29:52 -0500 Subject: Firefox crippling (was: What next?) In-Reply-To: <20050606141110.GA22394@devserv.devel.redhat.com> References: <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <87ekbhxfih.fsf@kosh.bigo.ensc.de> <20050605161545.GA28581@devserv.devel.redhat.com> <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> <20050606112356.GC1339@devserv.devel.redhat.com> <20050606131647.GA1526570@hiwaay.net> <51B54E96EF2442960C65057B@[10.169.6.246]> <20050606141110.GA22394@devserv.devel.redhat.com> Message-ID: <20050606142952.GB1526570@hiwaay.net> Once upon a time, Alan Cox said: > On Mon, Jun 06, 2005 at 07:07:02AM -0700, Kenneth Porter wrote: > > >^W is a Unix "delete previous word" keybinding. > > > > I remember using that on TOPS-20 in the early 80's. Did it inherit the > > command line hot keys from early Unix? > > via emacs. Traditional unix never had 'delete word'. I suspect it may have > come via teco originally but lets not mention that too many times in case > it comes back to life ;) Are you sure ^W comes via emacs? Word erase is a TTY setting (look at "stty -a"). ^U is line erase, ^R is redraw, and so on; these all work in "true" Bourne shell on Unix systems. -- 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 Mon Jun 6 14:41:31 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 6 Jun 2005 10:41:31 -0400 Subject: dkms coreward for fc5? (was Re: What next?) In-Reply-To: <1118024787.3011.16.camel@bree.local.net> References: <604aa7910506030657111cdd8d@mail.gmail.com> <1118024787.3011.16.camel@bree.local.net> Message-ID: <604aa7910506060741355e2aa0@mail.gmail.com> On 6/5/05, Jeremy Katz wrote: > DKMS doesn't solve the problem of the dependencies for the packages not > matching, so it feels to me like you're just trying to be a troll. But > I'll bite ;-) Whatever it takes to get the kernel module discussion restarted. It sort of died in the packaging list when it came up before. I'm more than happy to wait for spot to come back and discussion can begin in earnest in the packaging list. > Once _that_ is defined, then we can think about buildsystem triggers to > ensure that the packages get rebuilt in a timely fashion and that the > tree thus stays sane. buildsystem triggers that Core and Extras and 3rd party builders of ntfs modules can rely on? -jef From smooge at gmail.com Mon Jun 6 14:47:00 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Mon, 6 Jun 2005 08:47:00 -0600 Subject: Firefox crippling (was: What next?) In-Reply-To: <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> References: <42A094F9.3020207@redhat.com> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <87ekbhxfih.fsf@kosh.bigo.ensc.de> <20050605161545.GA28581@devserv.devel.redhat.com> <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> Message-ID: <80d7e409050606074738f85ff5@mail.gmail.com> On 6/6/05, Enrico Scholz wrote: > alan at redhat.com (Alan Cox) writes: > > > Based on the discussion regarding the "Firefox" branding, I do not see > how the FC4 firefox can be stilled named "Firefox" as it is destroys the > reputation of the project. > I vote for Red Baron.. but thats because I know the pain that I inflicted that upon Red Hat 4.x :). -- Stephen J Smoogen. CSIRT/Linux System Administrator From ph18 at cornell.edu Mon Jun 6 14:47:07 2005 From: ph18 at cornell.edu (Paul A. Houle) Date: Mon, 06 Jun 2005 10:47:07 -0400 Subject: Firefox crippling (was: What next?) In-Reply-To: <20050606141110.GA22394@devserv.devel.redhat.com> References: <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <87ekbhxfih.fsf@kosh.bigo.ensc.de> <20050605161545.GA28581@devserv.devel.redhat.com> <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> <20050606112356.GC1339@devserv.devel.redhat.com> <20050606131647.GA1526570@hiwaay.net> <51B54E96EF2442960C65057B@[10.169.6.246]> <20050606141110.GA22394@devserv.devel.redhat.com> Message-ID: On Mon, 6 Jun 2005 10:11:10 -0400, Alan Cox wrote: > On Mon, Jun 06, 2005 at 07:07:02AM -0700, Kenneth Porter wrote: >> >^W is a Unix "delete previous word" keybinding. >> >> I remember using that on TOPS-20 in the early 80's. Did it inherit the >> command line hot keys from early Unix? > > via emacs. Traditional unix never had 'delete word'. I suspect it may > have > come via teco originally but lets not mention that too many times in case > it comes back to life ;) > > Alan > Can you really win by changing key bindings? You might be able to do it with Firefox, but if you mess with my emacs keybinding it will be just another application that gets the rpm --erase ... ./configure make make install treatment. I use emacs on at least five different operating systems a day, it's bad enough dealing with ^H-backspace-delete problems, I don't need to see it changed. emacs is a solid application that really works, I find myself losing work with emacs about once every two years. you can do whatever you like with the half-working GUI "rpm --erase"ware that comes with RH, but don't mess with tools I need to get work done. (For instance, I need emacs so I can make configuration changes in 20 seconds that my coworker needs 20 minutes to do through the GUI because the GUI screws things up and makes the machine go off the network.) From mattdm at mattdm.org Mon Jun 6 14:48:49 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 6 Jun 2005 10:48:49 -0400 Subject: dkms coreward for fc5? (was Re: What next?) In-Reply-To: <604aa7910506060741355e2aa0@mail.gmail.com> References: <604aa7910506030657111cdd8d@mail.gmail.com> <1118024787.3011.16.camel@bree.local.net> <604aa7910506060741355e2aa0@mail.gmail.com> Message-ID: <20050606144849.GA24260@jadzia.bu.edu> On Mon, Jun 06, 2005 at 10:41:31AM -0400, Jeff Spaleta wrote: > buildsystem triggers that Core and Extras and 3rd party builders of > ntfs modules can rely on? And third-party builders of OpenAFS. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 80 degrees Fahrenheit. From alan at redhat.com Mon Jun 6 14:55:19 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 6 Jun 2005 10:55:19 -0400 Subject: Firefox crippling (was: What next?) In-Reply-To: <20050606142952.GB1526570@hiwaay.net> References: <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <87ekbhxfih.fsf@kosh.bigo.ensc.de> <20050605161545.GA28581@devserv.devel.redhat.com> <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> <20050606112356.GC1339@devserv.devel.redhat.com> <20050606131647.GA1526570@hiwaay.net> <51B54E96EF2442960C65057B@[10.169.6.246]> <20050606141110.GA22394@devserv.devel.redhat.com> <20050606142952.GB1526570@hiwaay.net> Message-ID: <20050606145519.GA14780@devserv.devel.redhat.com> On Mon, Jun 06, 2005 at 09:29:52AM -0500, Chris Adams wrote: > Are you sure ^W comes via emacs? Word erase is a TTY setting (look at > "stty -a"). ^U is line erase, ^R is redraw, and so on; these all work > in "true" Bourne shell on Unix systems. Only on late system5 and after. From emily at atropine.ath.cx Mon Jun 6 15:19:19 2005 From: emily at atropine.ath.cx (Emily Brantley) Date: Mon, 06 Jun 2005 11:19:19 -0400 Subject: Google's Summer of Code In-Reply-To: <1118043093.31098.3.camel@tarjei.predichem.nett> References: <429F6D7D.5080406@atropine.ath.cx> <429FD634.9060800@margo.bijoux.nom.br> <429FD739.90504@margo.bijoux.nom.br> <429FD842.2020906@atropine.ath.cx> <1118043093.31098.3.camel@tarjei.predichem.nett> Message-ID: <42A46977.5020303@atropine.ath.cx> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tarjei Knapstad wrote: > On Fri, 2005-06-03 at 06:10, Emily Brantley wrote: > >>-----BEGIN PGP SIGNED MESSAGE----- >>Hash: SHA1 >> >> >>>Just found out this page: http://fedoraproject.org/wiki/FedoraBounties >>> >>>Thanks Warren for putting some ideas there... I'll take a look on some >>>of these ideas and try to come up with some good solutions for those >>>problems (and try to get more volunteers ;D ) >> >>that definitely is what we needed. this thread could be a lightning-rod >>of sorts for proposing other ideas, i suppose, but i'll go look at that >>page now. thanks ! >> > > > A good candidate: > > http://www.catb.org/~esr/writings/cups-horror.html > > The article itself is somewhat of a rant, but that aside I've had > similar trouble myself when setting up network printing here in the > office and know lots of others... > > I can email this as a suggestion to the address mentioned on the > bounties page. > > -- > Tarjei > i read that in the past, and that's just the sort of thing i mean ! i don't feel like i can put my faith in the normal config tools and leave someone alone with a FC system without some hand-holding. i think my personal life (working on a client's project and getting ready to move), as well as my shaky status as student (i'm moving schools as well) preclude me from personally taking part in the summer of code... someone should do this though ! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCpGl1l/fI0i0h13cRAgA1AJwMYLcNIufsSVfPG6iJN24pS0GgCACgiQTr lZ3qWcdMLPDv4YBh2O68k+E= =+cwb -----END PGP SIGNATURE----- From caillon at redhat.com Mon Jun 6 15:54:52 2005 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 06 Jun 2005 11:54:52 -0400 Subject: Firefox crippling In-Reply-To: <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> References: <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <87ekbhxfih.fsf@kosh.bigo.ensc.de> <20050605161545.GA28581@devserv.devel.redhat.com> <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> Message-ID: <42A471CC.70905@redhat.com> Enrico Scholz wrote: > alan at redhat.com (Alan Cox) writes: > > >>On Sun, Jun 05, 2005 at 12:30:14PM +0200, Enrico Scholz wrote: >> >>>why they could not be patched into Ooffice; RH is crippl^Wpatching other >>>programs (e.g. firefox) already, so Ooffice could become a little bit >> >>Actually firefox support for unixlike keybindings is something from >>the Firefox community rather than RH as I understand it. > > > The broken (windoze-like) keybindings (which appear suddenly and without > prior confirmation although formerly the Unix like keybindings were > active) are probably caused by a Gnome2 misbehavior. This is controlled by GNOME, actually. If you want the old bindings, there is a setting you can add to your rc file which I don't remember off the top of my head. > The firefox crippling is the result of %patch25-29 in the src.rpm: it > removes the functionality which allows to update extensions with > potential security leaks, and it replaces the nice looking default > icons with butt-ugly icons from a Gnome2 theme. Installing third party software, which includes Firefox extensions is always at your own risk. > There exists a better patch for the first issue (which disables only > the capability to upgrade the application but still allows to update > extensions) but it is silently ignored by the firefox maintainer. Better in whose eyes? I've already vocalized that upstream doesn't want those patches in our tree. There is a plan to get this done right. It's not done just yet. It missed the FC4 final cutoff but as soon as the proper fix gets done, it will be included as an update if possible. > > Regarding the ugly icons, I do not see how this change can be justified. > The new icons are objectively ugly, the default firefox icons are much nicer > and there are now some missing icons. Thanks for the comments. Some share your opinion, some don't. I have had many positive comments about them. And yes there have been a few complaints. Much like some people prefer Firefox, some prefer Epiphany. Some prefer GNOME, some prefer KDE. Some prefer to troll, some don't. So it seems that these icon patches > are only applied to satisfy some brainless Gnome2 ideas about consistent > lookout of applications (which might have different functionality and can > never have the same lookout therefore). Hey, be fair. They are my brainless ideas, too. > Based on the discussion regarding the "Firefox" branding, I do not see > how the FC4 firefox can be stilled named "Firefox" as it is destroys the > reputation of the project. By getting the patches we use approved by upstream, as I make sure to do. It's not really rocket science. From emily at atropine.ath.cx Mon Jun 6 16:03:24 2005 From: emily at atropine.ath.cx (Emily Brantley) Date: Mon, 06 Jun 2005 12:03:24 -0400 Subject: Firefox crippling In-Reply-To: <42A471CC.70905@redhat.com> References: <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <87ekbhxfih.fsf@kosh.bigo.ensc.de> <20050605161545.GA28581@devserv.devel.redhat.com> <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> <42A471CC.70905@redhat.com> Message-ID: <42A473CC.5090005@atropine.ath.cx> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christopher Aillon wrote: > Enrico Scholz wrote: > >> alan at redhat.com (Alan Cox) writes: >> >> >>> On Sun, Jun 05, 2005 at 12:30:14PM +0200, Enrico Scholz wrote: >>> >>>> why they could not be patched into Ooffice; RH is crippl^Wpatching >>>> other >>>> programs (e.g. firefox) already, so Ooffice could become a little bit >>> >>> >>> Actually firefox support for unixlike keybindings is something from >>> the Firefox community rather than RH as I understand it. >> >> >> >> The broken (windoze-like) keybindings (which appear suddenly and without >> prior confirmation although formerly the Unix like keybindings were >> active) are probably caused by a Gnome2 misbehavior. > > > This is controlled by GNOME, actually. If you want the old bindings, > there is a setting you can add to your rc file which I don't remember > off the top of my head. do you mean this in your $HOME/.gtkrc-2.0 ? gtk-key-theme-name = "Emacs" or if that doesn't work include "/usr/share/themes/Emacs/gtk-2.0-key/gtkrc" Em -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCpHPLl/fI0i0h13cRAlHSAJ9wgn6108Pd8SxpKfpfA1hUuswIYwCgiFR3 7LGVMeeAxvCRZdMhO7JoolU= =fy5/ -----END PGP SIGNATURE----- From Curtis at GreenKey.net Mon Jun 6 17:16:15 2005 From: Curtis at GreenKey.net (Curtis Doty) Date: Mon, 06 Jun 2005 10:16:15 -0700 Subject: question about RedHat/Fedora and the GPL In-Reply-To: <1118040569.5652.2.camel@laptopd505.fenrus.org> References: <1118040569.5652.2.camel@laptopd505.fenrus.org> Message-ID: <42A484DF.9090604@GreenKey.net> Arjan van de Ven wrote: >yes. All the scripts needed to control the compilation and installation >of the executable is in the src.rpm perfectly fine. > > I find myself always adding something like: --- kernel-2.6.spec 2005-05-17 16:50:40.000000000 -0700 +++ kernel-2.6gk.spec 2005-05-30 18:58:15.000000000 -0700 @@ -21,7 +21,7 @@ %define sublevel 11 %define kversion 2.6.%{sublevel} %define rpmversion 2.6.%{sublevel} -%define rhbsys %([ -r /etc/beehive-root -o -n "%{?__beehive_build}" ] && echo || echo .`whoami`) +%define rhbsys %([ -r /etc/beehive-root -o -n "%{?__beehive_build}" ] && echo || echo .`whoami`@`hostname -s`) %if %{FC3} %define release %(R="$Revision: 1.27 $"; RR="${R##: }"; echo ${RR%%?})_FC3%{rhbsys} %endif It sure would be nice if the Red Had specfile maintainers took us into consideration. .. Those of us who don't have access to the Red Hat IP known as beehive. .. And have no problem managing our own parallel build environments. ../C From dragoran at feuerpokemon.de Mon Jun 6 17:24:23 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Mon, 06 Jun 2005 19:24:23 +0200 Subject: Beware of nvidia-graphics 1.0-7664 In-Reply-To: <20050606141401.GA15733@neu.nirvana> References: <1118046248.19918.3.camel@gibraltar.stuttgart.redhat.com> <20050606092246.GF4511@neu.nirvana> <1118065318.13470.2.camel@wombat.tiptoe.de> <20050606141401.GA15733@neu.nirvana> Message-ID: <42A486C7.7030603@feuerpokemon.de> Axel Thimm wrote: >On Mon, Jun 06, 2005 at 03:41:58PM +0200, Nils Philippsen wrote: > > >>On Mon, 2005-06-06 at 11:22 +0200, Axel Thimm wrote: >> >> >>>On Mon, Jun 06, 2005 at 10:24:08AM +0200, Nils Philippsen wrote: >>> >>> >>>>Note that this driver version broke suspend/resume for me (oh the joys >>>>of proprietary software with a proprietary development model), the >>>>display gets garbled. After some dabbling with it I found a workaround, >>>>though: Setting the display to DPMS suspend, then on again brought the >>>>card back into a semi-sane state (X works, text console are still >>>>garbled). >>>> >>>> >>>Yes, I had to find that out myself when the screensaver kicked in >>>killing two hours of work ... :/ >>> >>> >>Hmm, screensavers work just fine here, I only had problems with >>suspend/resume until I implemented the workaround. >> >> > >My symptoms are display goes black, but never returns. The system works >fine though, but a headless laptop is no joy ... :/ > > > >>>Also XvMC libs are broken :/ >>> >>> >>Care to elaborate? I don't see these in the livna RPMs I use, but maybe >>they're just missing ;-). >> >> > >libXvMCNVIDIA_dynamic.so.1 is refencing _nv0019XvMCdynamic which does >not exist. You'll only hit it if you use XvMC, e.g. mplayer/mythtv/xine etc. > > I have send a mail to nvidia about this issue but no replay yet :( From caillon at redhat.com Mon Jun 6 17:25:38 2005 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 06 Jun 2005 13:25:38 -0400 Subject: Firefox crippling In-Reply-To: <42A473CC.5090005@atropine.ath.cx> References: <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <87ekbhxfih.fsf@kosh.bigo.ensc.de> <20050605161545.GA28581@devserv.devel.redhat.com> <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> <42A471CC.70905@redhat.com> <42A473CC.5090005@atropine.ath.cx> Message-ID: <42A48712.40608@redhat.com> Emily Brantley wrote: > Christopher Aillon wrote: > >>Enrico Scholz wrote: >>>The broken (windoze-like) keybindings (which appear suddenly and without >>>prior confirmation although formerly the Unix like keybindings were >>>active) are probably caused by a Gnome2 misbehavior. >> >> >>This is controlled by GNOME, actually. If you want the old bindings, >>there is a setting you can add to your rc file which I don't remember >>off the top of my head. > > > do you mean this in your $HOME/.gtkrc-2.0 ? > > gtk-key-theme-name = "Emacs" > > or if that doesn't work > > include "/usr/share/themes/Emacs/gtk-2.0-key/gtkrc" Yeah, that's it. From Curtis at GreenKey.net Mon Jun 6 17:33:04 2005 From: Curtis at GreenKey.net (Curtis Doty) Date: Mon, 06 Jun 2005 10:33:04 -0700 Subject: question about RedHat/Fedora and the GPL In-Reply-To: References: <1118040569.5652.2.camel@laptopd505.fenrus.org> Message-ID: <42A488D0.8010901@GreenKey.net> condition terminal wrote: >On 6/6/05, Arjan van de Ven wrote: > > >>On Mon, 2005-06-06 at 16:26 +1200, condition terminal wrote: >> >> >>>OK, firstly, I am sorry if I am miss understanding the text of the GPL. >>> >>>The part I am questioning is this: >>> >>>---QUOTE--- >>>complete source code means all the source code for all modules it >>>contains, plus any associated interface definition files, plus the >>>scripts used to control compilation and installation of the >>>executable. >>>--END--QUOTE--- >>> >>>should this not mean that the likes of "beehive" be distributed? >>> >>> >>>Am I barking up the wrong tree and completely missing the point? >>> >>> >>yes. All the scripts needed to control the compilation and installation >>of the executable is in the src.rpm perfectly fine. >> >> >OK then.. so how are the files and scripts used to control the >building of the rpms outside the specs excluded from the conditions of >the GPL? > > Maybe you have an idea for an open-source build system you would like to start here? http://code.google.com/summerofcode.html http://www.fedoraproject.org/wiki/FedoraBounties ../C From Curtis at GreenKey.net Mon Jun 6 17:38:51 2005 From: Curtis at GreenKey.net (Curtis Doty) Date: Mon, 06 Jun 2005 10:38:51 -0700 Subject: syslinux and pxelinux.0 Message-ID: <42A48A2B.1090603@GreenKey.net> Jeremy Katz wrote: >On Sun, 2005-06-05 at 12:48 -0700, Curtis Doty wrote: > > >>I'm in the middle of uncovering/reverting some unpleasant behaviour >>introduced into syslinux 3.08 and I'd be curious to know if the 3.08-2 >>build up on rawhide is on the table for fc4 or fc5? Since only 3.07 was >>in test3. >> >> >3.08 is targeted at FC4. 3.07 was broken for a pretty large number of >laptops and 3.08 resolved those problems. > > Yesterday, I posted my findings upstream. And am awaiting hpa's return. http://syslinux.zytor.com/archives/2005-June/005240.html Maybe it's my PXE (Intel on a Broadcom) environment or maybe it's a legitimate bug in syslinux? Bit it appears that v3.08 cannot handle displaying the Fedora logo (or any rle-lss16-file for that matter) when pulled via tftp. ../C From enrico.scholz at informatik.tu-chemnitz.de Mon Jun 6 17:51:31 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 06 Jun 2005 19:51:31 +0200 Subject: Firefox crippling In-Reply-To: <42A471CC.70905@redhat.com> (Christopher Aillon's message of "Mon, 06 Jun 2005 11:54:52 -0400") References: <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <87ekbhxfih.fsf@kosh.bigo.ensc.de> <20050605161545.GA28581@devserv.devel.redhat.com> <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> <42A471CC.70905@redhat.com> Message-ID: <87slzv2x24.fsf@kosh.bigo.ensc.de> caillon at redhat.com (Christopher Aillon) writes: >> The broken (windoze-like) keybindings (which appear suddenly and without >> prior confirmation although formerly the Unix like keybindings were >> active) are probably caused by a Gnome2 misbehavior. > > This is controlled by GNOME, actually. If you want the old bindings, > there is a setting you can add to your rc file which I don't remember > off the top of my head. I do not care whether Windoze or Emacs keybindings are the default ones (as long as they can be configured). As expressed several times, I am just pissed off by the Gnome2 practice to *override* existing installations with their ideas of usability. >> The firefox crippling is the result of %patch25-29 in the src.rpm: it >> removes the functionality which allows to update extensions with >> potential security leaks, and it replaces the nice looking default >> icons with butt-ugly icons from a Gnome2 theme. > > Installing third party software, which includes Firefox extensions is > always at your own risk. Having an update functionality helps to reduce this risk. But this functionality was removed to avoid complains of novice users which try to update the firefox application and get error messages. >> There exists a better patch for the first issue (which disables only >> the capability to upgrade the application but still allows to update >> extensions) but it is silently ignored by the firefox maintainer. > > Better in whose eyes? Mmh... let's compare both patches: current patch: * removes functionality to update both firefox and extensions * 4 files changed, 11 insertions(+), 10 deletions(-) Matthew Miller's patch (bz #136080) * removed only the functionality to update firefox * 2 files changed, 2 insertions(+), 5 deletions(-) So, the alternative patch is less intrusive and simpler, has the wanted purpose and does not have unwanted side-effects. > I've already vocalized that upstream doesn't want those patches in our > tree. And upstream accepts the current patches? >> Regarding the ugly icons, I do not see how this change can be justified. >> The new icons are objectively ugly, the default firefox icons are much >> nicer and there are now some missing icons. > > Thanks for the comments. Some share your opinion, some don't. I have > had many positive comments about them. Let me guess who gave these positive comments... Gnome2 developers... right? > And yes there have been a few complaints. Why was there no response on these complaints? E.g. these about invisible icons (#138986) or the uglyness of the icons itself (#138984, #138988). > Much like some people prefer Firefox, some prefer Epiphany. Some > prefer GNOME, some prefer KDE. Some prefer to troll, some don't. Trolling is sometimes the only way when the bugreports are ignored... Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From e_mc_h2 at web.de Mon Jun 6 17:58:35 2005 From: e_mc_h2 at web.de (ness) Date: Mon, 06 Jun 2005 19:58:35 +0200 Subject: Google's Summer of Code In-Reply-To: <42A46977.5020303@atropine.ath.cx> References: <429F6D7D.5080406@atropine.ath.cx> <429FD634.9060800@margo.bijoux.nom.br> <429FD739.90504@margo.bijoux.nom.br> <429FD842.2020906@atropine.ath.cx> <1118043093.31098.3.camel@tarjei.predichem.nett> <42A46977.5020303@atropine.ath.cx> Message-ID: <42A48ECB.5050304@web.de> An HTML attachment was scrubbed... URL: From pjones at redhat.com Mon Jun 6 18:06:23 2005 From: pjones at redhat.com (Peter Jones) Date: Mon, 06 Jun 2005 14:06:23 -0400 Subject: [PATCH] mkinitrd rescue mode In-Reply-To: <1117731994.12259.68.camel@barsoom.rdu.redhat.com> References: <1117653405.12259.51.camel@barsoom.rdu.redhat.com> <1117725836.3768.15.camel@bree.local.net> <1117731994.12259.68.camel@barsoom.rdu.redhat.com> Message-ID: <1118081184.9625.5.camel@localhost.localdomain> On Thu, 2005-06-02 at 13:06 -0400, Jeffrey Layton wrote: > This does increase the memory profile of the initramfs by about 1.5M. > Isn't that memory freed after the switchroot occurs, though? It isn't currently freed. There's a plan for how to free it within the switchroot command, but I haven't had the time to implement it. > If you update to a new kernel, and that kernel isn't detecting your > drives correctly, then that is very difficult to troubleshoot once you > boot to a rescue kernel. How often is that a real problem? I don't think I've seen any significant number of bug reports on this in recent memory. -- Peter From caillon at redhat.com Mon Jun 6 18:15:35 2005 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 06 Jun 2005 14:15:35 -0400 Subject: Firefox crippling In-Reply-To: <87slzv2x24.fsf@kosh.bigo.ensc.de> References: <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <87ekbhxfih.fsf@kosh.bigo.ensc.de> <20050605161545.GA28581@devserv.devel.redhat.com> <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> <42A471CC.70905@redhat.com> <87slzv2x24.fsf@kosh.bigo.ensc.de> Message-ID: <42A492C7.3090809@redhat.com> Enrico Scholz wrote: > caillon at redhat.com (Christopher Aillon) writes: > > >>>The broken (windoze-like) keybindings (which appear suddenly and without >>>prior confirmation although formerly the Unix like keybindings were >>>active) are probably caused by a Gnome2 misbehavior. >> >>This is controlled by GNOME, actually. If you want the old bindings, >>there is a setting you can add to your rc file which I don't remember >>off the top of my head. > > > I do not care whether Windoze or Emacs keybindings are the default > ones (as long as they can be configured). As expressed several times, > I am just pissed off by the Gnome2 practice to *override* existing > installations with their ideas of usability. So take your complaints up with the GNOME guys and stop pissing on me. Your flaming is not going to make me care any more about you or your causes. In fact, it is likely to make me care less. > Let me guess who gave these positive comments... Gnome2 developers... right? Several corporate types, a few members of various media organizations, a bunch of artists, some users. A few geekier people have voiced their distaste in them --- you know what? you're complaining about GNOME, not Firefox. Go to a GNOME list instead and stop pissing on Firefox. >>And yes there have been a few complaints. > > > Why was there no response on these complaints? E.g. these about invisible > icons (#138986) or the uglyness of the icons itself (#138984, #138988). Sorry, I just wontfixed them with clarification. > > > >>Much like some people prefer Firefox, some prefer Epiphany. Some >>prefer GNOME, some prefer KDE. Some prefer to troll, some don't. > > > Trolling is sometimes the only way when the bugreports are ignored...z Be careful, not all maintainers respond well to trolls. Trolling with some people may result in more of your items ignored. From Matt_Domsch at dell.com Mon Jun 6 18:16:59 2005 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 6 Jun 2005 13:16:59 -0500 Subject: dkms coreward for fc5? (was Re: What next?) In-Reply-To: <1118024787.3011.16.camel@bree.local.net> References: <604aa7910506030657111cdd8d@mail.gmail.com> <1118024787.3011.16.camel@bree.local.net> Message-ID: <20050606181659.GA28411@lists.us.dell.com> On Sun, Jun 05, 2005 at 10:26:27PM -0400, Jeremy Katz wrote: > As far as I'm concerned, DKMS solves the wrong problem. As long as the > user has to have a compiler installed to use it, it's not useful. You don't have to have a compiler on the target systems. *If* you've got a compiler, and choose to invoke the build system (either through AUTOINSTALL="yes" on a per-package basis, or manually), then it yes, you can use the compiler to build. But it's not strictly required. Point in fact, Dell's factory install process doesn't invoke the compiler at all - it uses the precompiled modules from each package. The build system needs a compiler, the target systems don't. > As long as it's not an integrated part of the packaging system, > it's not useful. This is mostly true. It would be of great benefit if it were integrated, but it's not strictly required to be if you've got a compiler on your target systems, or an ancillary build system. > That said, I think that cleaning up the interaction for kernel module > packages and ensuring that everything is cleanly defined such that it > can work is a good goal for FC5 and I'm willing to help out some to make > it happen. Spot and I talked briefly about this in New Orleans and I > think the plan is to restart that discussion after he gets back from a > (much needed and deserved) vacation. Agreed on all points. > Once _that_ is defined, then we can think about buildsystem triggers to > ensure that the packages get rebuilt in a timely fashion and that the > tree thus stays sane. Agreed. -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From jlayton at redhat.com Mon Jun 6 18:27:17 2005 From: jlayton at redhat.com (Jeffrey Layton) Date: Mon, 06 Jun 2005 14:27:17 -0400 Subject: [PATCH] mkinitrd rescue mode In-Reply-To: <1118081184.9625.5.camel@localhost.localdomain> References: <1117653405.12259.51.camel@barsoom.rdu.redhat.com> <1117725836.3768.15.camel@bree.local.net> <1117731994.12259.68.camel@barsoom.rdu.redhat.com> <1118081184.9625.5.camel@localhost.localdomain> Message-ID: <1118082437.3702.28.camel@barsoom.rdu.redhat.com> On Mon, 2005-06-06 at 14:06 -0400, Peter Jones wrote: > How often is that a real problem? I don't think I've seen any > significant number of bug reports on this in recent memory. That's just a "for instance". Most of them aren't actual bugs, and so you won't see BZ tickets on them. Problems booting after kernel upgrades are common, however. We deal with them on a daily basis in production support. The problem for us is that there is virtually no simple way to troubleshoot the case where the rootfs isn't getting mounted for some reason, the switchroot fails, and the kernel panics. The most helpful messages telling us what the problem is usually have scrolled off the screen. We generally have to fix this based on experience and guesswork. You can have the user set up a serial console, but users who are savvy enough to figure out how to do that are generally able to troubleshoot their own booting problems. Being able to tell a user to add "rescue" to the command line and then to walk them through some commands (like dmesg) to try to determine the problem would be very helpful for a number of different reasons. It would also give people the ability to try to rescue corrupted root filesystems without needing special infrastructure (like a PXE server) and without having to physically be near the machine (with a CD boot). Since we're discussing this, I posted a proposed patch this morning to nash to clean out the initramfs prior to the switchroot: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159636 If nash is able to clean out the initramfs before switching the root, is there any reason _not_ to have some useful tools in it? -- Jeffrey Layton From enrico.scholz at informatik.tu-chemnitz.de Mon Jun 6 18:27:29 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 06 Jun 2005 20:27:29 +0200 Subject: Firefox crippling In-Reply-To: <42A492C7.3090809@redhat.com> (Christopher Aillon's message of "Mon, 06 Jun 2005 14:15:35 -0400") References: <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <87ekbhxfih.fsf@kosh.bigo.ensc.de> <20050605161545.GA28581@devserv.devel.redhat.com> <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> <42A471CC.70905@redhat.com> <87slzv2x24.fsf@kosh.bigo.ensc.de> <42A492C7.3090809@redhat.com> Message-ID: <87oeaj2ve6.fsf@kosh.bigo.ensc.de> caillon at redhat.com (Christopher Aillon) writes: >>>This is controlled by GNOME, actually. If you want the old bindings, >>>there is a setting you can add to your rc file which I don't remember >>>off the top of my head. >> I do not care whether Windoze or Emacs keybindings are the default >> ones (as long as they can be configured). As expressed several times, >> I am just pissed off by the Gnome2 practice to *override* existing >> installations with their ideas of usability. > > So take your complaints up with the GNOME guys does not make fun... they always say: "only we are right, we are the gods of usability, you are just a stupid user who does not have the faintest idea about usability"... >> Let me guess who gave these positive comments... Gnome2 developers... right? > > Several corporate types, a few members of various media organizations, > a bunch of artists, some users. A few geekier people have voiced > their distaste in them --- you know what? you're complaining about > GNOME, not Firefox. No. I complain about firefox. Things are fine when removing patches 25-28 from the firefox src.rpm. I do not have to touch Gnome. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From katzj at redhat.com Mon Jun 6 18:37:06 2005 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 06 Jun 2005 14:37:06 -0400 Subject: dkms coreward for fc5? (was Re: What next?) In-Reply-To: <20050606181659.GA28411@lists.us.dell.com> References: <604aa7910506030657111cdd8d@mail.gmail.com> <1118024787.3011.16.camel@bree.local.net> <20050606181659.GA28411@lists.us.dell.com> Message-ID: <1118083027.3968.61.camel@bree.local.net> On Mon, 2005-06-06 at 13:16 -0500, Matt Domsch wrote: > On Sun, Jun 05, 2005 at 10:26:27PM -0400, Jeremy Katz wrote: > > As far as I'm concerned, DKMS solves the wrong problem. As long as the > > user has to have a compiler installed to use it, it's not useful. > > You don't have to have a compiler on the target systems. *If* you've > got a compiler, and choose to invoke the build system (either through > AUTOINSTALL="yes" on a per-package basis, or manually), then it yes, > you can use the compiler to build. But it's not strictly required. > Point in fact, Dell's factory install process doesn't invoke the > compiler at all - it uses the precompiled modules from each package. > The build system needs a compiler, the target systems don't. Allow me to clarify. If DKMS is to be the solution to Jef's problem (which is that the kernel modules in the devel tree don't match the kernel in the devel tree), then you need to have a compiler on the system so you can recompile whenever the kernel changes. Or we get into the build system trigger stuff I talked about (at which point, we should be doing it with the packaging system anyway IMHO) Jeremy From pjones at redhat.com Mon Jun 6 18:52:40 2005 From: pjones at redhat.com (Peter Jones) Date: Mon, 06 Jun 2005 14:52:40 -0400 Subject: [PATCH] mkinitrd rescue mode In-Reply-To: <1117889444.7838.10.camel@localhost.localdomain> References: <1117653405.12259.51.camel@barsoom.rdu.redhat.com> <1117725836.3768.15.camel@bree.local.net> <1117731994.12259.68.camel@barsoom.rdu.redhat.com> <1117743443.3768.37.camel@bree.local.net> <20050602210436.GA4357@ti64.telemetry-investments.com> <1117889444.7838.10.camel@localhost.localdomain> Message-ID: <1118083960.9625.11.camel@localhost.localdomain> On Sat, 2005-06-04 at 08:50 -0400, Jeff Layton wrote: > Ok, I've whipped up a new patch. This adds a simple "unlink" function to > nash. The mkinitrd script now does an "rm /bin/fsck*" (using busybox's > rm), and then a "unlink /bin/busybox" after the rescue mode and prior to > the switchroot. That should free up any significant extra memory we > consume by adding these tools to the initramfs. That's really not the right solution, or rather not the whole solution, for the memory problem. See the patch and discussion in bz 153069 . > I've done some looking around at whether there is some way to get at the > initramfs after switchrooting (or whether there is some mechanism to > cause the kernel to just free it), but haven't found any way to do this > yet. You could bind mount it at another location before the MS_MOVE mount (inside of "switchroot" itself). -- Peter From sundaram at redhat.com Mon Jun 6 18:54:05 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Tue, 07 Jun 2005 00:24:05 +0530 Subject: Fedora Goals Message-ID: <42A49BCD.1040104@redhat.com> Hi We now have a roadmap page that describes project goals for Fedora Core 5. More information should be added about other major things like say the SELinux MLS plans or the per user /tmp work , under a security overview (potentially reorganised into layers ) depending on the amount of indepth details that could be provided. Its a wiki page so everyone including developers working on the major sub systems could pitch in with their ideas and comments there. http://www.fedoraproject.org/wiki/FC5Future If there are things that is planned for the next release or split up across versions , new "future" pages for FC5+x could be added to the wiki. This is just a broad overview of things that is planned to be done and not necessarily core stuff or code related. If there isnt enough to time to complete it within the current release, one could always push it to the next one. It would help the community understand the plans and serve as a work list for developers. Thanks to everyone who worked on this regards Rahul From pjones at redhat.com Mon Jun 6 18:54:08 2005 From: pjones at redhat.com (Peter Jones) Date: Mon, 06 Jun 2005 14:54:08 -0400 Subject: [PATCH] mkinitrd rescue mode In-Reply-To: <20050606133940.GA16224@ti64.telemetry-investments.com> References: <1117653405.12259.51.camel@barsoom.rdu.redhat.com> <1117725836.3768.15.camel@bree.local.net> <1117731994.12259.68.camel@barsoom.rdu.redhat.com> <1117743443.3768.37.camel@bree.local.net> <20050602210436.GA4357@ti64.telemetry-investments.com> <1117889444.7838.10.camel@localhost.localdomain> <20050606133940.GA16224@ti64.telemetry-investments.com> Message-ID: <1118084048.9625.13.camel@localhost.localdomain> On Mon, 2005-06-06 at 09:39 -0400, Bill Rugolsky Jr. wrote: > My preference would be to place add-on functionality in > a directory under sysconfig, e.g., /etc/sysconfig/boot.d/*, > so that rpms for EVMS, net booting, ... , could simply > drop files there. /etc/sysconfig is a total no-go there. Something like /boot/initrd.d/ might work... -- Peter From kamenzky at inf.fu-berlin.de Mon Jun 6 19:01:50 2005 From: kamenzky at inf.fu-berlin.de (Nico) Date: Mon, 6 Jun 2005 21:01:50 +0200 Subject: OT: Survey facing design patterns and communication Message-ID: <3570b57930762ab55e662a5b79db05db@inf.fu-berlin.de> Hello everybody! We are a group of students at "Freie Universitaet Berlin". As part of our computer science studies we are going to do a survey facing the use of design patterns in communication. Examples of design patterns are "Abstract Factory", "Singleton", "Composite", "Iterator" and "Listener". If you know what we are talking about, you are welcome to take part in our survey. It takes about 5 minutes to fill out the form. Just jump to: http://study.beatdepot.de If you agree, we will send you the results of our survey. Thanks in advance for your participation! And sorry for the interruption of your discussion. From fedora at leemhuis.info Mon Jun 6 19:31:05 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 06 Jun 2005 21:31:05 +0200 Subject: Fedora Goals In-Reply-To: <42A49BCD.1040104@redhat.com> References: <42A49BCD.1040104@redhat.com> Message-ID: <1118086265.5474.23.camel@notebook.thl.home> Am Dienstag, den 07.06.2005, 00:24 +0530 schrieb Rahul Sundaram: > We now have a roadmap page that describes project goals for Fedora Core > 5. More information should be added about other major things like say > the SELinux MLS plans or the per user /tmp work , under a security > overview (potentially reorganised into layers ) depending on the amount > of indepth details that could be provided. Its a wiki page so everyone > including developers working on the major sub systems could pitch in > with their ideas and comments there. > > http://www.fedoraproject.org/wiki/FC5Future We also still have http://www.fedoraproject.org/wiki/Wishlist Yes, needs a bit cleaning up. But there and in the "Wish List" thread on fedora-devel are still many (sometimes minor) more suggestion that did not make it to the FC5Future page and/or need further discussion. My suggestion: Get rid of the current Wishlist. Create three new pages: http://www.fedoraproject.org/wiki/FCWhishlist (core Wishlist) http://www.fedoraproject.org/wiki/FCWhishlist (extras Wishlist and package requests) http://www.fedoraproject.org/wiki/FE5Future (extras targets for FC5) Anyone should be able to create new entries in the Whishlist. Now and then someone (Fresco and/or Core-developers) could go though those lists and "move" entries to FC5Future and FE5Future (or pages that succeed it) or clarify in the wishlist why nobody is working on those ideas (yet). Comments? And yes, I'm willing to help creating the initial version of those pages. -- Thorsten Leemhuis From jlayton at redhat.com Mon Jun 6 19:28:27 2005 From: jlayton at redhat.com (Jeff Layton) Date: Mon, 06 Jun 2005 15:28:27 -0400 Subject: [PATCH] mkinitrd rescue mode In-Reply-To: <1118083960.9625.11.camel@localhost.localdomain> References: <1117653405.12259.51.camel@barsoom.rdu.redhat.com> <1117725836.3768.15.camel@bree.local.net> <1117731994.12259.68.camel@barsoom.rdu.redhat.com> <1117743443.3768.37.camel@bree.local.net> <20050602210436.GA4357@ti64.telemetry-investments.com> <1117889444.7838.10.camel@localhost.localdomain> <1118083960.9625.11.camel@localhost.localdomain> Message-ID: <1118086107.3702.43.camel@barsoom.rdu.redhat.com> On Mon, 2005-06-06 at 14:52 -0400, Peter Jones wrote: > That's really not the right solution, or rather not the whole solution, > for the memory problem. See the patch and discussion in bz 153069 . Agreed -- I've opened a new BZ today and posted a proposed patch to recursively remove all files and directories under a given directory (namely '/'), without crossing mountpoints. I didn't realize there was already a BZ open on this, so please let me know if you'd like me to close 159636, and post my patch to 153069. Though, the more I think about it, I like your second suggestion of bind-mounting initramfs inside the switchroot routine. Then we could just use regular coreutils 'rm' to clean it out and unmount it fairly early in the boot process. That would also potentially give you the option to leave it intact for troubleshooting problems inside it after switchrooting (if that were ever needed). It also keeps us from having to hack a lot of new stuff into nash. Maybe if a /initrd directory exists on the "real" root, we could bind- mount it there and do the cleanup? -- Jeff Layton From pjones at redhat.com Mon Jun 6 19:31:42 2005 From: pjones at redhat.com (Peter Jones) Date: Mon, 06 Jun 2005 15:31:42 -0400 Subject: [PATCH] mkinitrd rescue mode In-Reply-To: <1118082437.3702.28.camel@barsoom.rdu.redhat.com> References: <1117653405.12259.51.camel@barsoom.rdu.redhat.com> <1117725836.3768.15.camel@bree.local.net> <1117731994.12259.68.camel@barsoom.rdu.redhat.com> <1118081184.9625.5.camel@localhost.localdomain> <1118082437.3702.28.camel@barsoom.rdu.redhat.com> Message-ID: <1118086303.9625.35.camel@localhost.localdomain> On Mon, 2005-06-06 at 14:27 -0400, Jeffrey Layton wrote: > On Mon, 2005-06-06 at 14:06 -0400, Peter Jones wrote: > > How often is that a real problem? I don't think I've seen any > > significant number of bug reports on this in recent memory. > > That's just a "for instance". Most of them aren't actual bugs, and so > you won't see BZ tickets on them. I don't buy that at all. If, as you state below, we're seeing lots of cases where machines don't boot after upgrades, then there's a bug in something. Period. > Problems booting after kernel upgrades are common, however. We deal with > them on a daily basis in production support. The problem for us is that > there is virtually no simple way to troubleshoot the case where the > rootfs isn't getting mounted for some reason, the switchroot fails, and > the kernel panics. And if we're getting those, then there *is* a real mkinitrd bug, or a real module_upgrade bug, or a real new-kernel-pkg bug. If Engineering isn't seeing BZ tickets on them, then Engineering and GPS both lose. No new nash/mkinitrd features will help that at all. > The most helpful messages telling us what the problem is usually have > scrolled off the screen. We generally have to fix this based on experience > and guesswork. One (much more acceptable) solution for that would be a much simpler switchroot change -- make it look for a command line option "pause", and if it finds it, wait for the user to hit "enter" before executing init. For the overwhelmingly vast majority of boxes that'll get you enough scrollback in shift+pageup to see everything since kernel started. > You can have the user set up a serial console, but users who are savvy > enough to figure out how to do that are generally able to troubleshoot > their own booting problems. Being able to tell a user to add "rescue" > to the command line and then to walk them through some commands (like > dmesg) to try to determine the problem would be very helpful for a > number of different reasons. This is something of a contradiction -- you've just said the user isn't savvy enough to debug boot problems, and then suggested a step that'd make them only very marginally easier. > It would also give people the ability to try to rescue corrupted root > filesystems without needing special infrastructure (like a PXE server) > and without having to physically be near the machine (with a CD boot). This is a strawman -- your scenario is that they've just installed or upgraded, in which case they've already set up this infrastructure or are already close to the box. > Since we're discussing this, I posted a proposed patch this morning to > nash to clean out the initramfs prior to the switchroot: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159636 Thank you for doing this. > If nash is able to clean out the initramfs before switching the root, is > there any reason _not_ to have some useful tools in it? Added complexity is bad. Sometimes we have to add some, and that sucks. When we don't have to, in general the answer is "no". So if you *really* think this is worth doing, I'm more likely to take a change to add a command line argument which causes nash to execute something on a second initramfs cpio ball in lieu of switchroot/init, and then an entirely separate image (unrelated to mkinitrd) to do your rescue stuff. -- Peter From conditionterminal at gmail.com Mon Jun 6 19:41:55 2005 From: conditionterminal at gmail.com (condition terminal) Date: Tue, 7 Jun 2005 07:41:55 +1200 Subject: question about RedHat/Fedora and the GPL In-Reply-To: <1118045329.5652.19.camel@laptopd505.fenrus.org> References: <1118040569.5652.2.camel@laptopd505.fenrus.org> <1118045329.5652.19.camel@laptopd505.fenrus.org> Message-ID: On 6/6/05, Arjan van de Ven wrote: > On Mon, 2005-06-06 at 19:48 +1200, condition terminal wrote: > > On 6/6/05, Arjan van de Ven wrote: > > > On Mon, 2005-06-06 at 16:26 +1200, condition terminal wrote: > > > > OK, firstly, I am sorry if I am miss understanding the text of the GPL. > > > > > > > > The part I am questioning is this: > > > > > > > > ---QUOTE--- > > > > complete source code means all the source code for all modules it > > > > contains, plus any associated interface definition files, plus the > > > > scripts used to control compilation and installation of the > > > > executable. > > > > --END--QUOTE--- > > > > > > > > should this not mean that the likes of "beehive" be distributed? > > > > > > > Am I barking up the wrong tree and completely missing the point? > > > > > > yes. All the scripts needed to control the compilation and installation > > > of the executable is in the src.rpm perfectly fine. > > > > OK then.. so how are the files and scripts used to control the > > building of the rpms outside the specs excluded from the conditions of > > the GPL? > > I guess it comes down to with what you mean with "control". I'm not a > lawyer, but control means to me "have impact on the result". The goal is > that the binary building process is fully reproducable (see earlier > parts of the license about the rationale). All the parts that impact the > results are included in the src.rpm (with some global settings from > redhat-rpm-config which is also shipped). The RH buildsystem actually > calls rpmbuild to build the binary, all it does on top of that is some > queueing. Queueing does not impact the outcome of the build in any way. beehive does impact the result of the binary build. You can argue that you can build an identical binary with out it, but you could do the same without the spec file. beehive is used to control the process to generate GPL binaries. Therefore, it should be released under the same terms. Like wise with the scripts and tools used to build ISOs. > > The intent of the GPL is clearly that you have to provide the Makefiles > and any other scripts you use to build the source code. A src.rpm is > clearly that, it has everything used to build the source code (if it > didn't the RH buildsystem couldn't even build it in the first place). Intent is not law. Please don't make a case on intent. The GPL clearly states that files used to control the building and making of GPL source and binaries must be provided under the same terms. > Or in other words "scripts to control compilation of the executable" > means "makefiles and related". I'd argue that a buildsystem doesn't > contain scripts to control the binary, what it does is invoke those > scripts at certain moments in time. That's a pretty important > difference. There is a gray area, and that gray area is if a spec file > belongs into this. When the sourcecode is autoconf'd, is a spec file > that just calls configure, make and make install something that controls > the compilation of the executable? Borderline. I guess you can argue it > does since the outcome changes depending on the the configure flags > passed, and if the spec does pass any, it's controls the creation of the > binary. > So your saying that beehive doesn't control the process? ha! Intent and grey area. I guess thats your arguement. ta. From conditionterminal at gmail.com Mon Jun 6 19:44:43 2005 From: conditionterminal at gmail.com (condition terminal) Date: Tue, 7 Jun 2005 07:44:43 +1200 Subject: question about RedHat/Fedora and the GPL In-Reply-To: <42A484DF.9090604@GreenKey.net> References: <1118040569.5652.2.camel@laptopd505.fenrus.org> <42A484DF.9090604@GreenKey.net> Message-ID: Funny.... If beehive has little to nothing to do with the build, why does it have to be factored into spec files? Hardly a glorified cron job or meta-foo By the fact that spec files have to accommadate beehive it clearly shows that beehive is indeed a big factor in the RH/Fedora binaires. ta. On 6/7/05, Curtis Doty wrote: > Arjan van de Ven wrote: > > >yes. All the scripts needed to control the compilation and installation > >of the executable is in the src.rpm perfectly fine. > > > > > I find myself always adding something like: > > --- kernel-2.6.spec 2005-05-17 16:50:40.000000000 -0700 > +++ kernel-2.6gk.spec 2005-05-30 18:58:15.000000000 -0700 > @@ -21,7 +21,7 @@ > %define sublevel 11 > %define kversion 2.6.%{sublevel} > %define rpmversion 2.6.%{sublevel} > -%define rhbsys %([ -r /etc/beehive-root -o -n "%{?__beehive_build}" ] > && echo || echo .`whoami`) > +%define rhbsys %([ -r /etc/beehive-root -o -n "%{?__beehive_build}" ] > && echo || echo .`whoami`@`hostname -s`) > %if %{FC3} > %define release %(R="$Revision: 1.27 $"; RR="${R##: }"; echo > ${RR%%?})_FC3%{rhbsys} > %endif > > It sure would be nice if the Red Had specfile maintainers took us into > consideration. .. Those of us who don't have access to the Red Hat IP > known as beehive. .. And have no problem managing our own parallel build > environments. > > ../C > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From conditionterminal at gmail.com Mon Jun 6 19:45:19 2005 From: conditionterminal at gmail.com (condition terminal) Date: Tue, 7 Jun 2005 07:45:19 +1200 Subject: question about RedHat/Fedora and the GPL In-Reply-To: <42A488D0.8010901@GreenKey.net> References: <1118040569.5652.2.camel@laptopd505.fenrus.org> <42A488D0.8010901@GreenKey.net> Message-ID: Um.. your missing the point. On 6/7/05, Curtis Doty wrote: > condition terminal wrote: > > >On 6/6/05, Arjan van de Ven wrote: > > > > > >>On Mon, 2005-06-06 at 16:26 +1200, condition terminal wrote: > >> > >> > >>>OK, firstly, I am sorry if I am miss understanding the text of the GPL. > >>> > >>>The part I am questioning is this: > >>> > >>>---QUOTE--- > >>>complete source code means all the source code for all modules it > >>>contains, plus any associated interface definition files, plus the > >>>scripts used to control compilation and installation of the > >>>executable. > >>>--END--QUOTE--- > >>> > >>>should this not mean that the likes of "beehive" be distributed? > >>> > >>> > >>>Am I barking up the wrong tree and completely missing the point? > >>> > >>> > >>yes. All the scripts needed to control the compilation and installation > >>of the executable is in the src.rpm perfectly fine. > >> > >> > >OK then.. so how are the files and scripts used to control the > >building of the rpms outside the specs excluded from the conditions of > >the GPL? > > > > > Maybe you have an idea for an open-source build system you would like to > start here? > > http://code.google.com/summerofcode.html > http://www.fedoraproject.org/wiki/FedoraBounties > > ../C > From jlayton at redhat.com Mon Jun 6 19:56:14 2005 From: jlayton at redhat.com (Jeff Layton) Date: Mon, 06 Jun 2005 15:56:14 -0400 Subject: [PATCH] mkinitrd rescue mode In-Reply-To: <1118086303.9625.35.camel@localhost.localdomain> References: <1117653405.12259.51.camel@barsoom.rdu.redhat.com> <1117725836.3768.15.camel@bree.local.net> <1117731994.12259.68.camel@barsoom.rdu.redhat.com> <1118081184.9625.5.camel@localhost.localdomain> <1118082437.3702.28.camel@barsoom.rdu.redhat.com> <1118086303.9625.35.camel@localhost.localdomain> Message-ID: <1118087774.3702.65.camel@barsoom.rdu.redhat.com> On Mon, 2005-06-06 at 15:31 -0400, Peter Jones wrote: > And if we're getting those, then there *is* a real mkinitrd bug, or a > real module_upgrade bug, or a real new-kernel-pkg bug. If Engineering > isn't seeing BZ tickets on them, then Engineering and GPS both lose. No > new nash/mkinitrd features will help that at all. > These problems are often configuration issues, or someone has removed the /initrd directory (not such a problem with initramfs, but very common with initrd problems). On occasion this is a kernel issue, where a device is no longer being detected correctly for some reason. In these cases, we _do_ open BZ tickets and engineering gets them. Unfortunately, we it's often after a lot of time working with the user before we can determine that this is the case. Making this easier to troubleshoot would be helpful for users and us. It's tough to simply categorize all of the instances where we see problems with booting. If I could then we could just eliminate them, this is an attempt to get better visibility into an area where we are generally flying blind. > > The most helpful messages telling us what the problem is usually have > > scrolled off the screen. We generally have to fix this based on experience > > and guesswork. > > One (much more acceptable) solution for that would be a much simpler > switchroot change -- make it look for a command line option "pause", and > if it finds it, wait for the user to hit "enter" before executing init. > For the overwhelmingly vast majority of boxes that'll get you enough > scrollback in shift+pageup to see everything since kernel started. > I'm open to this. I don't think it would be as helpful as a true rescue mode, but it's better than nothing. > > You can have the user set up a serial console, but users who are savvy > > enough to figure out how to do that are generally able to troubleshoot > > their own booting problems. Being able to tell a user to add "rescue" > > to the command line and then to walk them through some commands (like > > dmesg) to try to determine the problem would be very helpful for a > > number of different reasons. > > This is something of a contradiction -- you've just said the user isn't > savvy enough to debug boot problems, and then suggested a step that'd > make them only very marginally easier. True, but this gives us _some_ ability to see what the problem is. Being able to tell them (for instance): Ok run "cat /proc/mounts" and tell me if /dev/hda2 is listed would be very helpful. This tool wouldn't be useful for users with no clue on their own, but would be helpful for helping such users over the phone. > > It would also give people the ability to try to rescue corrupted root > > filesystems without needing special infrastructure (like a PXE server) > > and without having to physically be near the machine (with a CD boot). > > This is a strawman -- your scenario is that they've just installed or > upgraded, in which case they've already set up this infrastructure or > are already close to the box. > Not necessarily -- serial consoles are very common in datacenters. > > Since we're discussing this, I posted a proposed patch this morning to > > nash to clean out the initramfs prior to the switchroot: > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159636 > > Thank you for doing this. > Gladly :-) > > If nash is able to clean out the initramfs before switching the root, is > > there any reason _not_ to have some useful tools in it? > > Added complexity is bad. Sometimes we have to add some, and that sucks. > When we don't have to, in general the answer is "no". > > So if you *really* think this is worth doing, I'm more likely to take a > change to add a command line argument which causes nash to execute > something on a second initramfs cpio ball in lieu of switchroot/init, > and then an entirely separate image (unrelated to mkinitrd) to do your > rescue stuff. > I'm with you -- extra complexity is generally bad, but in this case I don't see where it's harmful. If you don't want to use it, don't add "rescue" to the commandline (or generate your initrd images without it). To make sure I understand what you're proposing as an alternative... You're proposing having a secondary cpio image containing the "rescue" tools. We'd then pass this as a secondary initrd image to GRUB. We could then either use the rescue command line parameter (more or less as-is), or could key off the presence of something from the rescue image to enter rescue mode. If so, that would be acceptable to me, but I'll have to see how multiple cpio archives work in practice (I've never used them). -- Jeff Layton From davej at redhat.com Mon Jun 6 19:56:57 2005 From: davej at redhat.com (Dave Jones) Date: Mon, 6 Jun 2005 15:56:57 -0400 Subject: question about RedHat/Fedora and the GPL In-Reply-To: References: <1118040569.5652.2.camel@laptopd505.fenrus.org> <42A484DF.9090604@GreenKey.net> Message-ID: <20050606195657.GG19655@redhat.com> On Tue, Jun 07, 2005 at 07:44:43AM +1200, condition terminal wrote: > Funny.... > > If beehive has little to nothing to do with the build, why does it > have to be factored into spec files? > > Hardly a glorified cron job or meta-foo > > By the fact that spec files have to accommadate beehive it clearly > shows that beehive is indeed a big factor in the RH/Fedora binaires. They don't _have_ to accomodate it at all. The fact that you can rpmbuild a spec file on any host is proof of this. Dave From ronny-vlug at vlugnet.org Mon Jun 6 20:04:30 2005 From: ronny-vlug at vlugnet.org (Ronny Buchmann) Date: Mon, 6 Jun 2005 22:04:30 +0200 Subject: Wiki Status In-Reply-To: <1118033192.19379.46.camel@cutter> References: <1118033192.19379.46.camel@cutter> Message-ID: <200506062204.31056.ronny-vlug@vlugnet.org> On Monday 06 June 2005 06:46, seth vidal wrote: > Hey folks, > I updated the wiki to moinmoin 1.3.4 and I changed the default theme. Great, thanks a lot > It has all sorts of new things now and some of them are probably even > broken! :) > > let me know if you see anything out of place. please delete the old (unchanged) master pages, these are now in the underlay directory grep -l "^##master-page" should give the names I think -- http://LinuxWiki.org/RonnyBuchmann From pjones at redhat.com Mon Jun 6 20:12:35 2005 From: pjones at redhat.com (Peter Jones) Date: Mon, 06 Jun 2005 16:12:35 -0400 Subject: [PATCH] mkinitrd rescue mode In-Reply-To: <1118086107.3702.43.camel@barsoom.rdu.redhat.com> References: <1117653405.12259.51.camel@barsoom.rdu.redhat.com> <1117725836.3768.15.camel@bree.local.net> <1117731994.12259.68.camel@barsoom.rdu.redhat.com> <1117743443.3768.37.camel@bree.local.net> <20050602210436.GA4357@ti64.telemetry-investments.com> <1117889444.7838.10.camel@localhost.localdomain> <1118083960.9625.11.camel@localhost.localdomain> <1118086107.3702.43.camel@barsoom.rdu.redhat.com> Message-ID: <1118088755.9625.44.camel@localhost.localdomain> On Mon, 2005-06-06 at 15:28 -0400, Jeff Layton wrote: > Agreed -- I've opened a new BZ today and posted a proposed patch to > recursively remove all files and directories under a given directory > (namely '/'), without crossing mountpoints. I didn't realize there was > already a BZ open on this, so please let me know if you'd like me to > close 159636, and post my patch to 153069. Already done, thanks. > Though, the more I think about it, I like your second suggestion of > bind-mounting initramfs inside the switchroot routine. Then we could > just use regular coreutils 'rm' to clean it out and unmount it fairly > early in the boot process. I actually like the recursiveRemove way far more, because it means "init" is still the only thing we rely on from the mounted fs. The result is much more flexibility for the installed system. > That would also potentially give you the option to leave it intact for > troubleshooting problems inside it after switchrooting (if that were > ever needed). It also keeps us from having to hack a lot of new stuff > into nash. I'd rather see "call another initramfs script" stuff I mentioned in my other email... > Maybe if a /initrd directory exists on the "real" root, we could bind- > mount it there and do the cleanup? Ew, please no. Users already erroneously complain about, file bugs regarding, etc. /initrd way too much, it's better just not to have it if we can... (and it was recently removed, as well) -- Peter From david at fubar.dk Mon Jun 6 20:16:54 2005 From: david at fubar.dk (David Zeuthen) Date: Mon, 06 Jun 2005 16:16:54 -0400 Subject: What next? In-Reply-To: <429E362E.9060701@poolshark.org> References: <429E362E.9060701@poolshark.org> Message-ID: <1118089014.3919.44.camel@daxter.boston.redhat.com> On Wed, 2005-06-01 at 15:26 -0700, Denis Leroy wrote: > Elliot Lee wrote: > > >Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > >Extras 5 - what major features are you willing to put effort into? > > > > > I'd like to see better laptop support, in particular some sort of > Profile support as well as better wireless support. Currently to have my > laptop work both at home and at work (in dual mode), i have to hack > rc.sysinit horribly to extend the semantic of the 'netprofile=' kernel > argument so that it also changes the Xorg.conf file, .gconf files, and > so on.... Also, system-config-network is still an incredibly > counter-intuitive and confusing tool. With good hardware [1], NetworkManager works very very well these days. I expect this to become even better with FC5 (I believe nowadays you need to manually add /usr/libexec/nm-applet to your startup programs in GNOME... :-/) Cheers, David [1] : e.g. networking cards with good drivers (and firmware) that are in the mainline and thus the Fedora kernel. The IBM T41 that I and many other people at Red Hat uses is an example of this. From pjones at redhat.com Mon Jun 6 20:22:57 2005 From: pjones at redhat.com (Peter Jones) Date: Mon, 06 Jun 2005 16:22:57 -0400 Subject: [PATCH] mkinitrd rescue mode In-Reply-To: <1118087774.3702.65.camel@barsoom.rdu.redhat.com> References: <1117653405.12259.51.camel@barsoom.rdu.redhat.com> <1117725836.3768.15.camel@bree.local.net> <1117731994.12259.68.camel@barsoom.rdu.redhat.com> <1118081184.9625.5.camel@localhost.localdomain> <1118082437.3702.28.camel@barsoom.rdu.redhat.com> <1118086303.9625.35.camel@localhost.localdomain> <1118087774.3702.65.camel@barsoom.rdu.redhat.com> Message-ID: <1118089377.9625.52.camel@localhost.localdomain> On Mon, 2005-06-06 at 15:56 -0400, Jeff Layton wrote: > > > It would also give people the ability to try to rescue corrupted root > > > filesystems without needing special infrastructure (like a PXE server) > > > and without having to physically be near the machine (with a CD boot). > > > > This is a strawman -- your scenario is that they've just installed or > > upgraded, in which case they've already set up this infrastructure or > > are already close to the box. > > > > Not necessarily -- serial consoles are very common in datacenters. How does that matter? They've still either got CDs and are standing in front of the box, or they've set up the infrastructure for netboot and whatnot. > I'm with you -- extra complexity is generally bad, but in this case I > don't see where it's harmful. If you don't want to use it, don't add > "rescue" to the commandline (or generate your initrd images without > it). I just don't think there's a significant amount of benefit. Using the rescue image just isn't a very difficult task. > To make sure I understand what you're proposing as an alternative... > > You're proposing having a secondary cpio image containing the "rescue" > tools. We'd then pass this as a secondary initrd image to GRUB. We could > then either use the rescue command line parameter (more or less as-is), > or could key off the presence of something from the rescue image to > enter rescue mode. Right. And I like the second way better -- because once you've decided you sometimes need to do debugging stuff, you can add the second initrd and just keep on using it. Then ignore it until you need it again. > If so, that would be acceptable to me, but I'll have to see how multiple > cpio archives work in practice (I've never used them). Me neither -- let me know how it works for you ;) -- Peter From pjones at redhat.com Mon Jun 6 20:45:38 2005 From: pjones at redhat.com (Peter Jones) Date: Mon, 06 Jun 2005 16:45:38 -0400 Subject: What next? In-Reply-To: <1117792535.18370.0.camel@gibraltar.stuttgart.redhat.com> References: <1117655080.6271.52.camel@laptopd505.fenrus.org> <1117656479.5013.7.camel@localhost.localdomain> <20050601202109.GA30198@devserv.devel.redhat.com> <1117753887.8832.1.camel@localhost.localdomain> <1117782096.6270.8.camel@laptopd505.fenrus.org> <1117792535.18370.0.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1118090738.9625.58.camel@localhost.localdomain> On Fri, 2005-06-03 at 11:55 +0200, Nils Philippsen wrote: > > it can't be default realistically and is a per lib thing: > > making it default prevents the situation where an app links to a library > > in order to provide this service for plugins. > > Just curious: What is wrong with the idea that the plugins link the > libraries they need? The application also provides what amounts to a library to the plugin. I think the situation Arjan is referring to is when the application needs another library in order to implement some part of its module API, but it never needs the library unless it has loaded a plugin which uses that part of the API provided by the application. -- Peter From denis at poolshark.org Mon Jun 6 20:48:45 2005 From: denis at poolshark.org (Denis Leroy) Date: Mon, 06 Jun 2005 13:48:45 -0700 Subject: What next? In-Reply-To: <1118089014.3919.44.camel@daxter.boston.redhat.com> References: <429E362E.9060701@poolshark.org> <1118089014.3919.44.camel@daxter.boston.redhat.com> Message-ID: <42A4B6AD.7030607@poolshark.org> David Zeuthen wrote: > On Wed, 2005-06-01 at 15:26 -0700, Denis Leroy wrote: > >>Elliot Lee wrote: >> >> >>>Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora >>>Extras 5 - what major features are you willing to put effort into? >>> >>> >> >>I'd like to see better laptop support, in particular some sort of >>Profile support as well as better wireless support. Currently to have my >>laptop work both at home and at work (in dual mode), i have to hack >>rc.sysinit horribly to extend the semantic of the 'netprofile=' kernel >>argument so that it also changes the Xorg.conf file, .gconf files, and >>so on.... Also, system-config-network is still an incredibly >>counter-intuitive and confusing tool. > > > With good hardware [1], NetworkManager works very very well these days. > I expect this to become even better with FC5 (I believe nowadays you > need to manually add /usr/libexec/nm-applet to your startup programs in > GNOME... :-/) > > Cheers, > David Looks like a very nice wireless tool. But by the time i get to the desktop login window, i.e. way before NetworkManager comes into play, it's WAY to late to make decisions about profiles: my laptop at work wants eth0 to come up on boot, because it wants things such as nfs-mounted home directories, ntpd, dual-screen Xorg.conf and so on. For example, booting my laptop at home in work profile will result in a boot time of 10 MINUTES for all the stupid startup scripts to time out and fail and a pretty unusable system. So this is where we're really lacking imho. -denis From thebs413 at earthlink.net Mon Jun 6 20:48:45 2005 From: thebs413 at earthlink.net (Bryan J. Smith ) Date: Mon, 6 Jun 2005 15:48:45 -0500 (GMT-05:00) Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ Message-ID: <19543506.1118090925521.JavaMail.root@wamui-milano.atl.sa.earthlink.net> [ Sorry, I'm on the digests, so this response won't thread correctly. ] 16. Fedora Goals (Rahul Sundaram) From: Rahul Sundaram > Hi > We now have a roadmap page that describes project goals for Fedora Core > 5. More information should be added about other major things like say > the SELinux MLS plans or the per user /tmp work , under a security > overview (potentially reorganised into layers ) depending on the amount > of indepth details that could be provided. Its a wiki page so everyone > including developers working on the major sub systems could pitch in > with their ideas and comments there. > http://www.fedoraproject.org/wiki/FC5Future > If there are things that is planned for the next release or split up > across versions , new "future" pages for FC5+x could be added to the > wiki. This is just a broad overview of things that is planned to be done > and not necessarily core stuff or code related. If there isnt enough to > time to complete it within the current release, one could always push it > to the next one. It would help the community understand the plans and > serve as a work list for developers. > Thanks to everyone who worked on this I'm a long-time lurker (and long-time general annoyance) to many, but I would _love_ to start to tackle a fully LSB-compliant/ideal init with dependency checking, etc... for FC5+. I probably force bash (and even legacy Bourne sh on non-Linux) far more than I should (although I'll break out the Perl and, gasp, C when needbe), so I think this is right up my part-time (maybe 10 hours/week) alley if I could be any assistance to the team. I'm sure some code could already be leveraged from SuSE's dependency init approach. When in doubt on anything, LSB and then legacy Red Hat is the final consideration (i.e., I won't just be blindly forcing SuSE's logic). I have haven't checked if it's under GPL, but I seriously doubt Novell hasn't made it such (I'll make sure). Another option to consider is an "optional" rcS.d directory, which wouldn't be used by default, but is available for packages that want to drop in scripts before the run-levels start. It would be a nice option for those coming from Solaris, SuSE and others that have it. But, again, this is just an idea to create such an option for dropping scripts (tell me to shelve the idea if its not a good idea right now). -- Bryan P.S. You don't know how many times I've wanted to kill portmapper and tire of bash statements like: ;-> # service nfs stop && service nfslock stop && service portmap restart && service nfslock start && service nfs start And that's assuming I'm not running even more RPC services! @-p So damn I'll go ahead put my ass out and get it going! As I said before, I'm used to forcing bash (as well as legacy Bourne sh on non-Linux platforms) to do lots of things C/Perl coders roll their eyes at me for. So count me in (and who's currently working on this?)! -- Bryan J. Smith mailto:b.j.smith at ieee.org From notting at redhat.com Mon Jun 6 20:55:04 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 6 Jun 2005 16:55:04 -0400 Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ In-Reply-To: <19543506.1118090925521.JavaMail.root@wamui-milano.atl.sa.earthlink.net> References: <19543506.1118090925521.JavaMail.root@wamui-milano.atl.sa.earthlink.net> Message-ID: <20050606205504.GB18562@nostromo.devel.redhat.com> Bryan J. Smith (thebs413 at earthlink.net) said: > I'm a long-time lurker (and long-time general annoyance) to many, but I > would _love_ to start to tackle a fully LSB-compliant/ideal init with > dependency checking, etc... for FC5+. I probably force bash (and even > legacy Bourne sh on non-Linux) far more than I should (although I'll > break out the Perl and, gasp, C when needbe), so I think this is right > up my part-time (maybe 10 hours/week) alley if I could be any > assistance to the team. Well, there are some plans here. They don't usually involve bash, though, and generally consist of migrating to a completely different framework, with support for legacy installation concerns such as LSB compatibility and the current init-style scripts. > So count me in (and who's currently working on this?)! No one, just yet. :) Bill From pjones at redhat.com Mon Jun 6 20:58:19 2005 From: pjones at redhat.com (Peter Jones) Date: Mon, 06 Jun 2005 16:58:19 -0400 Subject: What next? In-Reply-To: <1117654970.11154.36.camel@mlenzdesktop> References: <1117654970.11154.36.camel@mlenzdesktop> Message-ID: <1118091500.9625.72.camel@localhost.localdomain> On Wed, 2005-06-01 at 14:42 -0500, Matthew Lenz wrote: > Are people against attempting to move to some kind of enhanced init > system that includes dependencies? Or is that already the plan? I think this is still a kindof crappy solution. Many of the cases why "dependencies" sound nice for init, they're just a kludge. One example would be ntpd. Currently the thought is "ntpd has to go after networking starts", and that's what would be expressed as a dependency. But that sucks for a lot of reasons, especially in a scenario like the one created by NetworkManager. What would be better is to make things like ntpd start up, and use dbus to a) discover if there are any networks available that are suitable for its purpose, and b) wait for one to become available. So in this case basically NM could discover an ntp server from the dhcp response, and then advertise it via dbus to ntpd, which would add it in the pool as appropriate (depending on some sort of policy or configuration). I suspect this is the case for a lot of network services, and similar cases exist for most of the other things you'd want to add dependencies for. In reality, I think most stuff we run at start up is either: a) something which really must be run relatively early and in some particular order (no point in doing a tsort for them, the ordering is generally pretty obvious). We don't really care about these for this discussion. b) stuff where we don't conceptually care the order, but which needs some event to have occurred either before the script runs or before the resulting daemon (or whatever) becomes useful. In our current scenario, "some event" is something done by a different initscript. In the dependency scenario, it's waiting on some side affect of a script, and that satisfies the dependency. In most cases I think it'd be better to have the other program notify things that the real event we care about has happened, and the programs we're starting respond accordingly. The initscript itself should be long gone (at least conceptually) by the time that matters. -- Peter From brugolsky at telemetry-investments.com Mon Jun 6 20:59:26 2005 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Mon, 6 Jun 2005 16:59:26 -0400 Subject: [PATCH] mkinitrd rescue mode In-Reply-To: <1118086303.9625.35.camel@localhost.localdomain> References: <1117653405.12259.51.camel@barsoom.rdu.redhat.com> <1117725836.3768.15.camel@bree.local.net> <1117731994.12259.68.camel@barsoom.rdu.redhat.com> <1118081184.9625.5.camel@localhost.localdomain> <1118082437.3702.28.camel@barsoom.rdu.redhat.com> <1118086303.9625.35.camel@localhost.localdomain> Message-ID: <20050606205926.GG16224@ti64.telemetry-investments.com> On Mon, Jun 06, 2005 at 03:31:42PM -0400, Peter Jones wrote: > > It would also give people the ability to try to rescue corrupted root > > filesystems without needing special infrastructure (like a PXE server) > > and without having to physically be near the machine (with a CD boot). > > This is a strawman -- your scenario is that they've just installed or > upgraded, in which case they've already set up this infrastructure or > are already close to the box. I don't understand why you think that everyone should be running a PXE server, which can be a security nightmare as well as an administrative hassle. The following is a real-world, though perhaps ill-advised, configuration: o /boot on RAID1 across several /dev/sd?1 o swap on RAID1 across several other /dev/sd?1 o Everything else on LVM2-over-RAID5 on /dev/sd?2 [As disks have gotten larger and cheaper, putting the root file system on RAID5 has become less attractive, but people still do it.] A disk failure followed by a crash/outage requires manual intervention to bring the RAID5 back online, since we do not have RAID5 journaling yet, and it is still early days for RAID6. Getting to a command prompt and running mdadm to reassemble the array would certainly be quite useful. -Bill From pjones at redhat.com Mon Jun 6 21:00:16 2005 From: pjones at redhat.com (Peter Jones) Date: Mon, 06 Jun 2005 17:00:16 -0400 Subject: What next? In-Reply-To: References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <1117662394.31018.80.camel@cutter> Message-ID: <1118091616.9625.75.camel@localhost.localdomain> On Wed, 2005-06-01 at 23:15 +0100, Mike Hearn wrote: > On Wed, 01 Jun 2005 17:46:33 -0400, seth vidal wrote: > > > BTW., how does osx do installs (just bringing up the meta-file > > > installer thingy again. Feel free not to answer)? > > > > their package system, umm, err, sucks. > > 99.9% of users seem to disagree with you, judging by how often "Linux > should use appfolders like Macs do" is heard on various forums and mailing > lists. One hears "Macs should do packaging $FOO way instead of their crap" pretty often, too. I think everybody hates both ways, and which complaints you see just depends on which lists you read. -- Peter From Nicolas.Mailhot at laPoste.net Mon Jun 6 21:07:43 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 06 Jun 2005 23:07:43 +0200 Subject: Fedora Goals In-Reply-To: <42A49BCD.1040104@redhat.com> References: <42A49BCD.1040104@redhat.com> Message-ID: <1118092064.32490.3.camel@rousalka.dyndns.org> Le mardi 07 juin 2005 ? 00:24 +0530, Rahul Sundaram a ?crit : > We now have a roadmap page that describes project goals for Fedora Core > 5. > http://www.fedoraproject.org/wiki/FC5Future Rhaa nothing on jackd or lowlatency work Is Ingo still working at Red Hat ? Regards, -- Nicolas Mailhot -------------- 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 denis at poolshark.org Mon Jun 6 21:09:51 2005 From: denis at poolshark.org (Denis Leroy) Date: Mon, 06 Jun 2005 14:09:51 -0700 Subject: Firefox crippling In-Reply-To: <87slzv2x24.fsf@kosh.bigo.ensc.de> References: <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <87ekbhxfih.fsf@kosh.bigo.ensc.de> <20050605161545.GA28581@devserv.devel.redhat.com> <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> <42A471CC.70905@redhat.com> <87slzv2x24.fsf@kosh.bigo.ensc.de> Message-ID: <42A4BB9F.7070402@poolshark.org> Enrico Scholz wrote: > I do not care whether Windoze or Emacs keybindings are the default > ones (as long as they can be configured). As expressed several times, > I am just pissed off by the Gnome2 practice to *override* existing > installations with their ideas of usability. You speak for me, this has also been an enormous source of frustration over the past few years, and filing bugs on bugzilla.gnome.org to ask for better configurability always result in absolute ignorance. The worst for me was switching from the 3rd button to the middle button to perform interactive window resizing, almost impossible to do on a mouse on which the middle button is a wheel (ie. all Logitech mice). Fortunately, that's an easy enough metacity patch. I know those are all GNOME issues, but Fedora, being one of the big Gnome "client" (read, supporter), should have considerable influence over them. Just as an example, if Fedora were to ditch Metacity, or Epiphany, or some other Gnome default, based on Fedora users feedback, it would send a powerful message... -denis From alan at redhat.com Mon Jun 6 21:17:30 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 6 Jun 2005 17:17:30 -0400 Subject: question about RedHat/Fedora and the GPL In-Reply-To: References: <1118040569.5652.2.camel@laptopd505.fenrus.org> <1118045329.5652.19.camel@laptopd505.fenrus.org> Message-ID: <20050606211730.GC28754@devserv.devel.redhat.com> On Tue, Jun 07, 2005 at 07:41:55AM +1200, condition terminal wrote: > beehive is used to control the process to generate GPL binaries. > Therefore, it should be released under the same terms. So does the processor silicon, stepping and design. Alan From denis at poolshark.org Mon Jun 6 21:20:05 2005 From: denis at poolshark.org (Denis Leroy) Date: Mon, 06 Jun 2005 14:20:05 -0700 Subject: Wish list In-Reply-To: <1118043525.5652.9.camel@laptopd505.fenrus.org> References: <1118002724.9556.34.camel@Darkstar> <42A36449.80509@n-man.com> <1118043525.5652.9.camel@laptopd505.fenrus.org> Message-ID: <42A4BE05.9060105@poolshark.org> Arjan van de Ven wrote: >>That said, currently two problems that would stop me installing Fedora >>for very non-technical users: >> >>- Auto update is not reliable/graphical enough, or never has been for me. >> Maybe it's fixed in FC4. >>- Auto update breaks nvidia drivers every few weeks > > > well the moment you use the (probably illegal) nvidia binary drivers you > gave up all advantages of open source already. Especially on the > security front, binary drivers have a really bad reputation and history > there. People love Fedora, and people love Nvidia drivers. Both for good reasons. You'll have to accept that eventually, instead of systematically bad-mouthing every person that brings up Nvidia issues on this mailing list. -denis From pjones at redhat.com Mon Jun 6 21:21:48 2005 From: pjones at redhat.com (Peter Jones) Date: Mon, 06 Jun 2005 17:21:48 -0400 Subject: [PATCH] mkinitrd rescue mode In-Reply-To: <20050606205926.GG16224@ti64.telemetry-investments.com> References: <1117653405.12259.51.camel@barsoom.rdu.redhat.com> <1117725836.3768.15.camel@bree.local.net> <1117731994.12259.68.camel@barsoom.rdu.redhat.com> <1118081184.9625.5.camel@localhost.localdomain> <1118082437.3702.28.camel@barsoom.rdu.redhat.com> <1118086303.9625.35.camel@localhost.localdomain> <20050606205926.GG16224@ti64.telemetry-investments.com> Message-ID: <1118092908.9625.91.camel@localhost.localdomain> On Mon, 2005-06-06 at 16:59 -0400, Bill Rugolsky Jr. wrote: > On Mon, Jun 06, 2005 at 03:31:42PM -0400, Peter Jones wrote: > > > It would also give people the ability to try to rescue corrupted root > > > filesystems without needing special infrastructure (like a PXE server) > > > and without having to physically be near the machine (with a CD boot). > > > > This is a strawman -- your scenario is that they've just installed or > > upgraded, in which case they've already set up this infrastructure or > > are already close to the box. > > I don't understand why you think that everyone should be running a PXE > server, which can be a security nightmare as well as an administrative > hassle. I don't think that at all. In the scenario we were discussing, the system had just been installed or upgraded. In that case, I'm 100% sure you have things set up to boot either a CD, a PXE image, or some other boot media that you can just as easily put the rescue image on. > The following is a real-world, though perhaps ill-advised, configuration: > > o /boot on RAID1 across several /dev/sd?1 > o swap on RAID1 across several other /dev/sd?1 > o Everything else on LVM2-over-RAID5 on /dev/sd?2 > > [As disks have gotten larger and cheaper, putting the root file system on > RAID5 has become less attractive, but people still do it.] > > A disk failure followed by a crash/outage requires manual intervention to > bring the RAID5 back online, since we do not have RAID5 journaling yet, > and it is still early days for RAID6. Getting to a command prompt and > running mdadm to reassemble the array would certainly be quite useful. In this scenario you're replacing a drive. I hope you've got physical access to the machine. Also, this isn't a very good example -- your random drive failure is relatively likely to wedge the bus, etc. In that case, this is the exact same scenario as if /boot isn't available at all. You have to go and touch the box here. If you have to touch the box, then I don't buy "I couldn't boot a CD". -- Peter From skvidal at phy.duke.edu Mon Jun 6 21:23:39 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 06 Jun 2005 17:23:39 -0400 Subject: Wish list In-Reply-To: <42A4BE05.9060105@poolshark.org> References: <1118002724.9556.34.camel@Darkstar> <42A36449.80509@n-man.com> <1118043525.5652.9.camel@laptopd505.fenrus.org> <42A4BE05.9060105@poolshark.org> Message-ID: <1118093019.2468.42.camel@cutter> > > > > well the moment you use the (probably illegal) nvidia binary drivers you > > gave up all advantages of open source already. Especially on the > > security front, binary drivers have a really bad reputation and history > > there. > > People love Fedora, and people love Nvidia drivers. Both for good reasons. > You'll have to accept that eventually, instead of systematically bad-mouthing > every person that brings up Nvidia issues on this mailing list. He's not bad-mouthing the person. He's bad-mouthing the driver. And he's hardly doing it systematically. seriously - nvidia drivers being bad for your system is not new. You should have seen this before. -sv From johnp at redhat.com Mon Jun 6 21:27:38 2005 From: johnp at redhat.com (John (J5) Palmieri) Date: Mon, 06 Jun 2005 17:27:38 -0400 Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ In-Reply-To: <20050606205504.GB18562@nostromo.devel.redhat.com> References: <19543506.1118090925521.JavaMail.root@wamui-milano.atl.sa.earthlink.net> <20050606205504.GB18562@nostromo.devel.redhat.com> Message-ID: <1118093259.18813.21.camel@remedyz.boston.redhat.com> On Mon, 2005-06-06 at 16:55 -0400, Bill Nottingham wrote: > Bryan J. Smith (thebs413 at earthlink.net) said: > > I'm a long-time lurker (and long-time general annoyance) to many, but I > > would _love_ to start to tackle a fully LSB-compliant/ideal init with > > dependency checking, etc... for FC5+. I probably force bash (and even > > legacy Bourne sh on non-Linux) far more than I should (although I'll > > break out the Perl and, gasp, C when needbe), so I think this is right > > up my part-time (maybe 10 hours/week) alley if I could be any > > assistance to the team. > > Well, there are some plans here. They don't usually involve bash, > though, and generally consist of migrating to a completely different > framework, with support for legacy installation concerns such > as LSB compatibility and the current init-style scripts. > > > So count me in (and who's currently working on this?)! > > No one, just yet. :) Well we do have the session work somewhat done in an experimental stage. We are targeting the session for dependency loading of session services a) to make the session startup stuff more robust and b) to see if the idea will fly for more complex situations such as a replacement for init. I gave a short 5 minute talk on it at GUADEC. You can check out the video here: http://stream.fluendo.com/archive/6uadec/Lightning_Talks.ogg Mine is 32 minutes and 30 seconds in. Basically while most of the code can't be reused (glib dependencies) the methods and policies created here will be able to be transported to a system wide service framework. -- John (J5) Palmieri Associate Software Engineer Desktop Group Red Hat, Inc. Blog: http://martianrock.com From pjones at redhat.com Mon Jun 6 21:34:16 2005 From: pjones at redhat.com (Peter Jones) Date: Mon, 06 Jun 2005 17:34:16 -0400 Subject: What next? In-Reply-To: References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <1117662394.31018.80.camel@cutter> Message-ID: <1118093656.9625.101.camel@localhost.localdomain> On Thu, 2005-06-02 at 08:46 -0400, Paul A. Houle wrote: > > MacOS X packaging works reliably for end users, 100% of the time, and > > from that perspective it doesn't matter how many features it has or > > doesn't have, it's better than yum/rpm/any Linux packaging system. > > > > This is something I've thought about: how much would the shell slow down > if we had a very long $PATH, so that we can give applications independent > bin directories? The bigger issue is likely to be limited size in which to store the data. ISTR you get a page or something like that to put environmental data in during exec(). Kernel guys correct me, I'm sure it's bigger than that but totally fuzzy on the details. Anyway, you might do better by making some way to marking "this file here needs to be made into program named 'foo' in the (user/admin) default path" in the package, or in a file at a well known location. Sort of like how pkg-config tells you how to link against a library. Then you can separate out the responsibility of how to make it executable, and have something that knows about the distro's policy do the work of making it available (whether by symlink, copy, hardlink, etc). This could be during package install, or at boot time, or in an initscript when starting some particular service. > [...] > A downside to giving each app a directory is that it's harder to use > partitions to isolate different kind of things, an art that I've been > learning over time (and particular inspired by the Solaris shop I work > with that uses something much like LVM, allocate a minimal amount of > space for each partition, leave a large free pool, and grow the > partitions online over tine) You could, uh, use lvm for that... -- Peter From skvidal at phy.duke.edu Mon Jun 6 21:40:33 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 06 Jun 2005 17:40:33 -0400 Subject: Wiki Status In-Reply-To: <200506062204.31056.ronny-vlug@vlugnet.org> References: <1118033192.19379.46.camel@cutter> <200506062204.31056.ronny-vlug@vlugnet.org> Message-ID: <1118094033.2468.49.camel@cutter> On Mon, 2005-06-06 at 22:04 +0200, Ronny Buchmann wrote: > On Monday 06 June 2005 06:46, seth vidal wrote: > > Hey folks, > > I updated the wiki to moinmoin 1.3.4 and I changed the default theme. > Great, thanks a lot > > > It has all sorts of new things now and some of them are probably even > > broken! :) > > > > let me know if you see anything out of place. > please delete the old (unchanged) master pages, these are now in the underlay > directory > > grep -l "^##master-page" > should give the names I think that's cool - I didn't realize I could search for that string - I got rid of them. thanks, -sv From conditionterminal at gmail.com Mon Jun 6 21:49:15 2005 From: conditionterminal at gmail.com (condition terminal) Date: Tue, 7 Jun 2005 09:49:15 +1200 Subject: question about RedHat/Fedora and the GPL In-Reply-To: <20050606211730.GC28754@devserv.devel.redhat.com> References: <1118040569.5652.2.camel@laptopd505.fenrus.org> <1118045329.5652.19.camel@laptopd505.fenrus.org> <20050606211730.GC28754@devserv.devel.redhat.com> Message-ID: hardly a realistic arguement. A CPU is not a "file" as per the text of the GPL. ta On 6/7/05, Alan Cox wrote: > On Tue, Jun 07, 2005 at 07:41:55AM +1200, condition terminal wrote: > > beehive is used to control the process to generate GPL binaries. > > Therefore, it should be released under the same terms. > > So does the processor silicon, stepping and design. > > Alan > > From skvidal at phy.duke.edu Mon Jun 6 21:51:40 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 06 Jun 2005 17:51:40 -0400 Subject: question about RedHat/Fedora and the GPL In-Reply-To: References: <1118040569.5652.2.camel@laptopd505.fenrus.org> <1118045329.5652.19.camel@laptopd505.fenrus.org> <20050606211730.GC28754@devserv.devel.redhat.com> Message-ID: <1118094700.2468.53.camel@cutter> On Tue, 2005-06-07 at 09:49 +1200, condition terminal wrote: > hardly a realistic arguement. > > A CPU is not a "file" as per the text of the GPL. > It's unix. Everything is a file.... /me runs -sv From jspaleta at gmail.com Mon Jun 6 21:53:19 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 6 Jun 2005 17:53:19 -0400 Subject: question about RedHat/Fedora and the GPL In-Reply-To: <1118094700.2468.53.camel@cutter> References: <1118040569.5652.2.camel@laptopd505.fenrus.org> <1118045329.5652.19.camel@laptopd505.fenrus.org> <20050606211730.GC28754@devserv.devel.redhat.com> <1118094700.2468.53.camel@cutter> Message-ID: <604aa79105060614536ee35475@mail.gmail.com> On 6/6/05, seth vidal wrote: > It's unix. Everything is a file.... unless your using rieser4, then everything is a directory.... -jef"i hear rotten tomatos make an excellent facial scrub"spaleta From nman64 at n-man.com Mon Jun 6 21:54:07 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Mon, 06 Jun 2005 16:54:07 -0500 Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ In-Reply-To: <19543506.1118090925521.JavaMail.root@wamui-milano.atl.sa.earthlink.net> References: <19543506.1118090925521.JavaMail.root@wamui-milano.atl.sa.earthlink.net> Message-ID: <42A4C5FF.9000000@n-man.com> Bryan J. Smith wrote: >[ Sorry, I'm on the digests, so this response won't thread correctly. ] > > 16. Fedora Goals (Rahul Sundaram) > >From: Rahul Sundaram > > >>Hi >>We now have a roadmap page that describes project goals for Fedora Core >>5. More information should be added about other major things like say >>the SELinux MLS plans or the per user /tmp work , under a security >>overview (potentially reorganised into layers ) depending on the amount >>of indepth details that could be provided. Its a wiki page so everyone >>including developers working on the major sub systems could pitch in >>with their ideas and comments there. >>http://www.fedoraproject.org/wiki/FC5Future >>If there are things that is planned for the next release or split up >>across versions , new "future" pages for FC5+x could be added to the >>wiki. This is just a broad overview of things that is planned to be done >>and not necessarily core stuff or code related. If there isnt enough to >>time to complete it within the current release, one could always push it >>to the next one. It would help the community understand the plans and >>serve as a work list for developers. >>Thanks to everyone who worked on this >> >> > >I'm a long-time lurker (and long-time general annoyance) to many, but I >would _love_ to start to tackle a fully LSB-compliant/ideal init with >dependency checking, etc... for FC5+. I probably force bash (and even >legacy Bourne sh on non-Linux) far more than I should (although I'll >break out the Perl and, gasp, C when needbe), so I think this is right >up my part-time (maybe 10 hours/week) alley if I could be any >assistance to the team. > >I'm sure some code could already be leveraged from SuSE's dependency >init approach. When in doubt on anything, LSB and then legacy Red Hat >is the final consideration (i.e., I won't just be blindly forcing SuSE's logic). >I have haven't checked if it's under GPL, but I seriously doubt Novell >hasn't made it such (I'll make sure). > >Another option to consider is an "optional" rcS.d directory, which wouldn't >be used by default, but is available for packages that want to drop in >scripts before the run-levels start. It would be a nice option for those >coming from Solaris, SuSE and others that have it. But, again, this is >just an idea to create such an option for dropping scripts (tell me to >shelve the idea if its not a good idea right now). > >-- Bryan > >P.S. You don't know how many times I've wanted to kill portmapper and >tire of bash statements like: ;-> > # service nfs stop && service nfslock stop && service portmap restart >&& service nfslock start && service nfs start > >And that's assuming I'm not running even more RPC services! @-p > >So damn I'll go ahead put my ass out and get it going! As I said before, >I'm used to forcing bash (as well as legacy Bourne sh on non-Linux >platforms) to do lots of things C/Perl coders roll their eyes at me for. >So count me in (and who's currently working on this?)! > > >-- >Bryan J. Smith mailto:b.j.smith at ieee.org > > > I think many of the ideas for an improved init system sound awesome, but perhaps you could expand the scope and draw more assistance. Consider creating a project at SourceForge and involving members from other distributions. This will help garner support for the methods you use (instead of creating a Fedora-only solution), increase the number of volunteers to help you out, provide a full project space to work in, and will provide a larger forum for feedback. Make sure you come back here and let us know once your project is created, though. I'm sure several people here will be interested in your efforts. -- Patrick "The N-Man" Barnes nman64 at n-man.com www.n-man.com -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From philip at balister.org Mon Jun 6 22:04:32 2005 From: philip at balister.org (Philip Balister) Date: Mon, 06 Jun 2005 18:04:32 -0400 Subject: question about RedHat/Fedora and the GPL In-Reply-To: References: <1118040569.5652.2.camel@laptopd505.fenrus.org> <1118045329.5652.19.camel@laptopd505.fenrus.org> <20050606211730.GC28754@devserv.devel.redhat.com> Message-ID: <1118095472.5709.211.camel@localhost.localdomain> Why do people who don't use their names in email tend to start this sort of argument? Philip On Tue, 2005-06-07 at 09:49 +1200, condition terminal wrote: > hardly a realistic arguement. > > A CPU is not a "file" as per the text of the GPL. > > ta > > On 6/7/05, Alan Cox wrote: > > On Tue, Jun 07, 2005 at 07:41:55AM +1200, condition terminal wrote: > > > beehive is used to control the process to generate GPL binaries. > > > Therefore, it should be released under the same terms. > > > > So does the processor silicon, stepping and design. > > > > Alan > > > > > From conditionterminal at gmail.com Mon Jun 6 22:10:39 2005 From: conditionterminal at gmail.com (condition terminal) Date: Tue, 7 Jun 2005 10:10:39 +1200 Subject: question about RedHat/Fedora and the GPL In-Reply-To: <1118095472.5709.211.camel@localhost.localdomain> References: <1118040569.5652.2.camel@laptopd505.fenrus.org> <1118045329.5652.19.camel@laptopd505.fenrus.org> <20050606211730.GC28754@devserv.devel.redhat.com> <1118095472.5709.211.camel@localhost.localdomain> Message-ID: hehe.. whats a name? a label? an identiy? My name is Jon doe.. happy now? Your point is OT to this thread, please dont try to hi-jack it. ta. On 6/7/05, Philip Balister wrote: > Why do people who don't use their names in email tend to start this sort > of argument? > > Philip > > On Tue, 2005-06-07 at 09:49 +1200, condition terminal wrote: > > hardly a realistic arguement. > > > > A CPU is not a "file" as per the text of the GPL. > > > > ta > > > > On 6/7/05, Alan Cox wrote: > > > On Tue, Jun 07, 2005 at 07:41:55AM +1200, condition terminal wrote: > > > > beehive is used to control the process to generate GPL binaries. > > > > Therefore, it should be released under the same terms. > > > > > > So does the processor silicon, stepping and design. > > > > > > Alan > > > > > > > > > From info at a-wing.co.uk Mon Jun 6 22:14:31 2005 From: info at a-wing.co.uk (Andrew Hutchings) Date: Mon, 06 Jun 2005 23:14:31 +0100 Subject: question about RedHat/Fedora and the GPL In-Reply-To: References: <1118040569.5652.2.camel@laptopd505.fenrus.org> <1118045329.5652.19.camel@laptopd505.fenrus.org> <20050606211730.GC28754@devserv.devel.redhat.com> Message-ID: <42A4CAC7.2000801@a-wing.co.uk> condition terminal wrote: > hardly a realistic arguement. > > A CPU is not a "file" as per the text of the GPL. > > ta > I have used a file on a CPU before though. Made it into a keyring, but that's for another time. Regards Andrew -- Andrew Hutchings (A-Wing) Linux Guru - Netserve Consultants Ltd. - http://www.domaincity.co.uk/ Admin - North Wales Linux User Group - http://www.nwlug.org.uk/ BOFH excuse 83: Support staff hung over, send aspirin and come back LATER. From hballal at gmail.com Mon Jun 6 22:13:24 2005 From: hballal at gmail.com (Hrishikesh Ballal) Date: Mon, 06 Jun 2005 18:13:24 -0400 Subject: Fedora Goals In-Reply-To: <20050606185416.7227773366@hormel.redhat.com> References: <20050606185416.7227773366@hormel.redhat.com> Message-ID: <42A4CA84.6050502@gmail.com> Hi I went to the fedoraproject FC5 future wiki website and I can help out with the last category: Fedora website / infrastructure improvement. I have the relevant experience and can elaborate. Can someone please direct me to somebody who will lead that "module"? Thanks a lot.. Hrishi ------------------------------ Message: 16 Date: Tue, 07 Jun 2005 00:24:05 +0530 From: Rahul Sundaram Subject: Fedora Goals To: Development discussions related to Fedora Core , Discussions on expanding the Fedora user base Message-ID: <42A49BCD.1040104 at redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi We now have a roadmap page that describes project goals for Fedora Core 5. More information should be added about other major things like say the SELinux MLS plans or the per user /tmp work , under a security overview (potentially reorganised into layers ) depending on the amount of indepth details that could be provided. Its a wiki page so everyone including developers working on the major sub systems could pitch in with their ideas and comments there. http://www.fedoraproject.org/wiki/FC5Future If there are things that is planned for the next release or split up across versions , new "future" pages for FC5+x could be added to the wiki. This is just a broad overview of things that is planned to be done and not necessarily core stuff or code related. If there isnt enough to time to complete it within the current release, one could always push it to the next one. It would help the community understand the plans and serve as a work list for developers. Thanks to everyone who worked on this regards Rahul ------------------------------ -- fedora-devel-list mailing list fedora-devel-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list End of fedora-devel-list Digest, Vol 16, Issue 31 ************************************************* From skvidal at phy.duke.edu Mon Jun 6 22:21:59 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 06 Jun 2005 18:21:59 -0400 Subject: Fedora Goals In-Reply-To: <42A4CA84.6050502@gmail.com> References: <20050606185416.7227773366@hormel.redhat.com> <42A4CA84.6050502@gmail.com> Message-ID: <1118096519.2468.67.camel@cutter> On Mon, 2005-06-06 at 18:13 -0400, Hrishikesh Ballal wrote: > Hi > I went to the fedoraproject FC5 future wiki website and I can help out > with the last category: Fedora website / infrastructure improvement. I > have the relevant experience and can elaborate. Can someone please > direct me to somebody who will lead that "module"? Thanks a lot.. > Hrishi > I can help a bit with that. How do you think you can contribute? -sv From jwboyer at jdub.homelinux.org Mon Jun 6 22:27:47 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 06 Jun 2005 17:27:47 -0500 Subject: Fedora Goals In-Reply-To: <1118092064.32490.3.camel@rousalka.dyndns.org> References: <42A49BCD.1040104@redhat.com> <1118092064.32490.3.camel@rousalka.dyndns.org> Message-ID: <1118096867.3107.154.camel@yoda.jdub.homelinux.org> On Mon, 2005-06-06 at 23:07 +0200, Nicolas Mailhot wrote: > Le mardi 07 juin 2005 ? 00:24 +0530, Rahul Sundaram a ?crit : > > > We now have a roadmap page that describes project goals for Fedora Core > > 5. > > > http://www.fedoraproject.org/wiki/FC5Future > > Rhaa nothing on jackd or lowlatency work > Is Ingo still working at Red Hat ? Just to clarify, the page wasn't made by Red Hat. It was started by a _community_ volunteer (me). And no, it isn't a complete and exhaustive list. It's a work in progress. So, as Rahul said, feel free to pitch in and add ideas. thx, josh From gvelasquez at minag.gob.pe Mon Jun 6 22:27:05 2005 From: gvelasquez at minag.gob.pe (=?ISO-8859-1?Q?Geffrey_Vel=E1squez_?=[Minag]) Date: Mon, 6 Jun 2005 17:27:05 -0500 Subject: Kudzu API Documentation Message-ID: <20050606222447.M15073@minag.gob.pe> Hi pals, I was searching in google about Kudzu API Documentation without sucess, if somebody knows where could I get some information please send me the link. Thanks, Geffrey From johnp at redhat.com Mon Jun 6 22:32:51 2005 From: johnp at redhat.com (John (J5) Palmieri) Date: Mon, 06 Jun 2005 18:32:51 -0400 Subject: Kudzu API Documentation In-Reply-To: <20050606222447.M15073@minag.gob.pe> References: <20050606222447.M15073@minag.gob.pe> Message-ID: <1118097171.18813.29.camel@remedyz.boston.redhat.com> On Mon, 2005-06-06 at 17:27 -0500, =?ISO-8859-1?Q?Geffrey_Vel=E1squez_?=[Minag] wrote: > Hi pals, I was searching in google about Kudzu API Documentation without > sucess, if somebody knows where could I get some information please send me > the link. > > Thanks, > Geffrey I would think just read the code. I am not sure if there are any formal docs. BTW Kudzu is most likely going away as soon as HAL can take over all the tasks Kudzu handles. -- John (J5) Palmieri Associate Software Engineer Desktop Group Red Hat, Inc. Blog: http://martianrock.com From mattdm at mattdm.org Mon Jun 6 22:57:59 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 6 Jun 2005 18:57:59 -0400 Subject: Kudzu API Documentation In-Reply-To: <1118097171.18813.29.camel@remedyz.boston.redhat.com> References: <20050606222447.M15073@minag.gob.pe> <1118097171.18813.29.camel@remedyz.boston.redhat.com> Message-ID: <20050606225759.GA13730@jadzia.bu.edu> On Mon, Jun 06, 2005 at 06:32:51PM -0400, John (J5) Palmieri wrote: > I would think just read the code. I am not sure if there are any formal > docs. BTW Kudzu is most likely going away as soon as HAL can take over > all the tasks Kudzu handles. Including "locking up my system at boot"? Just wonderin'. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 80 degrees Fahrenheit. From emily at atropine.ath.cx Mon Jun 6 23:01:26 2005 From: emily at atropine.ath.cx (Emily Brantley) Date: Mon, 06 Jun 2005 19:01:26 -0400 Subject: Kudzu API Documentation In-Reply-To: <20050606225759.GA13730@jadzia.bu.edu> References: <20050606222447.M15073@minag.gob.pe> <1118097171.18813.29.camel@remedyz.boston.redhat.com> <20050606225759.GA13730@jadzia.bu.edu> Message-ID: <42A4D5C6.3080200@atropine.ath.cx> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matthew Miller wrote: > On Mon, Jun 06, 2005 at 06:32:51PM -0400, John (J5) Palmieri wrote: > >>I would think just read the code. I am not sure if there are any formal >>docs. BTW Kudzu is most likely going away as soon as HAL can take over >>all the tasks Kudzu handles. > > > Including "locking up my system at boot"? > > Just wonderin'. :) > > don't laugh ! HAL used to do that to me. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCpNXFl/fI0i0h13cRAmyKAJ9ZXD0D0oXs1RQRnsCXWJPpEQiSzACfb08x r9wdO9CNRvLjP8CLXWIsd7I= =wH8b -----END PGP SIGNATURE----- From seandarcy2 at gmail.com Tue Jun 7 00:14:29 2005 From: seandarcy2 at gmail.com (sean) Date: Mon, 06 Jun 2005 20:14:29 -0400 Subject: jade looks for docbook/dtd/xml/4.2/docbookx.dtd ?? Message-ID: I'm using db2html to build the gutenprint docs. But: /usr/bin/db2html gutenprint.xml output is gutenprint Using catalogs: /etc/sgml/xml-docbook-4.2-1.0-27.cat Using stylesheet: /usr/share/sgml/docbook/utils-0.6.14/docbook-utils.dsl#html Working on: /usr/src/redhat/BUILD/print/doc/developer/gutenprint.xml jade:/usr/src/redhat/BUILD/print/doc/developer/gutenprint.xml:13:0:E: cannot open "/usr/share/sgml/docbook/dtd/xml/4.2/docbookx.dtd" (No such file or directory) But jade should be looking for /usr/share/sgml/docbook/xml-dtd-4.2-1.0-27/docbookx.dtd Not sure how to track this down: /etc/sgml/xml-docbook-4.2-1.0-27.cat first entry is CATALOG "/usr/share/sgml/docbook/xml-dtd-4.2-1.0-27/catalog" which looks right. And /usr/share/sgml/docbook/xml-dtd-4.2-1.0-27/catalog entry is PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "docbookx.dtd" So jade should be able to figure it out. This worked about a month ago. rpm -q openjade openjade-1.3.2-16 docbook-utils-0.6.14-4 sean From wtogami at redhat.com Tue Jun 7 00:52:17 2005 From: wtogami at redhat.com (Warren Togami) Date: Mon, 06 Jun 2005 14:52:17 -1000 Subject: Firefox crippling In-Reply-To: <42A492C7.3090809@redhat.com> References: <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <87ekbhxfih.fsf@kosh.bigo.ensc.de> <20050605161545.GA28581@devserv.devel.redhat.com> <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> <42A471CC.70905@redhat.com> <87slzv2x24.fsf@kosh.bigo.ensc.de> <42A492C7.3090809@redhat.com> Message-ID: <42A4EFC1.1090407@redhat.com> Christopher Aillon wrote: >> Why was there no response on these complaints? E.g. these about invisible >> icons (#138986) or the uglyness of the icons itself (#138984, #138988). > > > Sorry, I just wontfixed them with clarification. One legitimate problem with the GNOMEification is that there is no way to switch the Firefox theme back to the upstream original. It would be nice if we had this capability, but not a priority. Warren Togami wtogami at redhat.com From notting at redhat.com Tue Jun 7 01:36:52 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 6 Jun 2005 21:36:52 -0400 Subject: Kudzu API Documentation In-Reply-To: <20050606225759.GA13730@jadzia.bu.edu> References: <20050606222447.M15073@minag.gob.pe> <1118097171.18813.29.camel@remedyz.boston.redhat.com> <20050606225759.GA13730@jadzia.bu.edu> Message-ID: <20050607013652.GA20878@nostromo.devel.redhat.com> Matthew Miller (mattdm at mattdm.org) said: > On Mon, Jun 06, 2005 at 06:32:51PM -0400, John (J5) Palmieri wrote: > > I would think just read the code. I am not sure if there are any formal > > docs. BTW Kudzu is most likely going away as soon as HAL can take over > > all the tasks Kudzu handles. > > Including "locking up my system at boot"? Yeah, we need to get that fully refined for HAL 1.0. Bill From notting at redhat.com Tue Jun 7 01:38:15 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 6 Jun 2005 21:38:15 -0400 Subject: Kudzu API Documentation In-Reply-To: <20050606222447.M15073@minag.gob.pe> References: <20050606222447.M15073@minag.gob.pe> Message-ID: <20050607013815.GB20878@nostromo.devel.redhat.com> Geffrey Vel?squez [Minag] (gvelasquez at minag.gob.pe) said: > Hi pals, I was searching in google about Kudzu API Documentation without > sucess, if somebody knows where could I get some information please send me > the link. The API docs for kudzu is basically the code. As for using the API, it's deprecated in favor of HAL for use for probing for devices; at this point, it's mainly a layer to get the proper modules loaded at boot, and will eventually disappear. Bill From notting at redhat.com Tue Jun 7 01:41:32 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 6 Jun 2005 21:41:32 -0400 Subject: What next? In-Reply-To: <1118091500.9625.72.camel@localhost.localdomain> References: <1117654970.11154.36.camel@mlenzdesktop> <1118091500.9625.72.camel@localhost.localdomain> Message-ID: <20050607014132.GC20878@nostromo.devel.redhat.com> Peter Jones (pjones at redhat.com) said: > On Wed, 2005-06-01 at 14:42 -0500, Matthew Lenz wrote: > > Are people against attempting to move to some kind of enhanced init > > system that includes dependencies? Or is that already the plan? > > I think this is still a kindof crappy solution. Many of the cases why > "dependencies" sound nice for init, they're just a kludge. > > One example would be ntpd. Currently the thought is "ntpd has to go > after networking starts", and that's what would be expressed as a > dependency. > > But that sucks for a lot of reasons, especially in a scenario like the > one created by NetworkManager. What would be better is to make things > like ntpd start up, and use dbus to a) discover if there are any > networks available that are suitable for its purpose, and b) wait for > one to become available. So in this case basically NM could discover an > ntp server from the dhcp response, and then advertise it via dbus to > ntpd, which would add it in the pool as appropriate (depending on some > sort of policy or configuration). Well, it's still technically a dependency. In the situation you describe, there's really no reason for ntpd to start at all until NM declares there's some network connection available on which to actually sync to a server. > a) something which really must be run relatively early and in some > particular order (no point in doing a tsort for them, the ordering is > generally pretty obvious). We don't really care about these for this > discussion. Yeah, this is rc.sysinit at the moment - parallelization & dependencies here aren't really useful, as it follows pretty much in order: - load hardware modules - initialize storage - check & mount filesystems - misc boottime cleanups (/var, etc.) > In our current scenario, "some event" is something done by a different > initscript. In the dependency scenario, it's waiting on some side > affect of a script, and that satisfies the dependency. In most cases I > think it'd be better to have the other program notify things that the > real event we care about has happened, and the programs we're starting > respond accordingly. The initscript itself should be long gone (at > least conceptually) by the time that matters. The fun part will be rewriting the various apps/servers to sanely respond to runtime reconfigration like this. Bill From katzj at redhat.com Tue Jun 7 01:57:57 2005 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 06 Jun 2005 21:57:57 -0400 Subject: Kudzu API Documentation In-Reply-To: <20050607013815.GB20878@nostromo.devel.redhat.com> References: <20050606222447.M15073@minag.gob.pe> <20050607013815.GB20878@nostromo.devel.redhat.com> Message-ID: <1118109477.3968.89.camel@bree.local.net> On Mon, 2005-06-06 at 21:38 -0400, Bill Nottingham wrote: > Geffrey Vel?squez [Minag] (gvelasquez at minag.gob.pe) said: > > Hi pals, I was searching in google about Kudzu API Documentation without > > sucess, if somebody knows where could I get some information please send me > > the link. > > The API docs for kudzu is basically the code. > > As for using the API, it's deprecated in favor of HAL for use > for probing for devices; at this point, it's mainly a layer to > get the proper modules loaded at boot, and will eventually disappear. Which also requires some thought for how to use it in the installer... dbus in the loader would be a bit overkill even if it were easier to do. Jeremy From rodd at clarkson.id.au Tue Jun 7 01:59:28 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Tue, 07 Jun 2005 11:59:28 +1000 Subject: Firefox crippling In-Reply-To: <87oeaj2ve6.fsf@kosh.bigo.ensc.de> References: <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <87ekbhxfih.fsf@kosh.bigo.ensc.de> <20050605161545.GA28581@devserv.devel.redhat.com> <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> <42A471CC.70905@redhat.com> <87slzv2x24.fsf@kosh.bigo.ensc.de> <42A492C7.3090809@redhat.com> <87oeaj2ve6.fsf@kosh.bigo.ensc.de> Message-ID: <1118109568.3119.8.camel@jellyfish.redfishdemo.com> On Mon, 2005-06-06 at 20:27 +0200, Enrico Scholz wrote: > caillon at redhat.com (Christopher Aillon) writes: > > >>>This is controlled by GNOME, actually. If you want the old bindings, > >>>there is a setting you can add to your rc file which I don't remember > >>>off the top of my head. > >> I do not care whether Windoze or Emacs keybindings are the default > >> ones (as long as they can be configured). As expressed several times, > >> I am just pissed off by the Gnome2 practice to *override* existing > >> installations with their ideas of usability. > > > > So take your complaints up with the GNOME guys > > does not make fun... they always say: "only we are right, we are the > gods of usability, you are just a stupid user who does not have the > faintest idea about usability"... Personally, I've filed dozens of usability bugs against gnome and for the most part they have been taken very seriously. The developers (and I am not a Gnome developer) seem to respond very positively to me comments on usability. My experience is that Gnome developers do not think they are "", and are more than willing to address usability issues. Food for thought: Maybe this isn't a usability issue, but instead is a personal peeve about how you think it should work. Maybe it has to do with how you approach the situation. Maybe it has to do with just accepting that other view points are also valid. At least you can complain - go try that with Windows were the decision is made without your input and you simply can't complain to the developers. R. -- "It's a fine line between denial and faith. It's much better on my side" From cmadams at hiwaay.net Tue Jun 7 02:15:32 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 6 Jun 2005 21:15:32 -0500 Subject: question about RedHat/Fedora and the GPL In-Reply-To: References: <1118040569.5652.2.camel@laptopd505.fenrus.org> <1118045329.5652.19.camel@laptopd505.fenrus.org> <20050606211730.GC28754@devserv.devel.redhat.com> Message-ID: <20050607021532.GA938160@hiwaay.net> Once upon a time, condition terminal said: > hardly a realistic arguement. > > A CPU is not a "file" as per the text of the GPL. vmunix (or vmlinux/vmlinuz under Linux) is a file, and it has impact on the building of binaries, but no reasonable person demands it be distributed (not even RMS AFAIK). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From conditionterminal at gmail.com Tue Jun 7 02:32:01 2005 From: conditionterminal at gmail.com (condition terminal) Date: Tue, 7 Jun 2005 14:32:01 +1200 Subject: question about RedHat/Fedora and the GPL In-Reply-To: <20050607021532.GA938160@hiwaay.net> References: <1118040569.5652.2.camel@laptopd505.fenrus.org> <1118045329.5652.19.camel@laptopd505.fenrus.org> <20050606211730.GC28754@devserv.devel.redhat.com> <20050607021532.GA938160@hiwaay.net> Message-ID: I still see no answer. I see people making jokes of this thread, but no answers. Why is beehive allowed to not be released under the terms and conditions of the GPL when the GPL clearly states that files use to build GPL code also have to be released under the terms and conditions of the GPL? ta. From skvidal at phy.duke.edu Tue Jun 7 02:37:16 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 06 Jun 2005 22:37:16 -0400 Subject: question about RedHat/Fedora and the GPL In-Reply-To: References: <1118040569.5652.2.camel@laptopd505.fenrus.org> <1118045329.5652.19.camel@laptopd505.fenrus.org> <20050606211730.GC28754@devserv.devel.redhat.com> <20050607021532.GA938160@hiwaay.net> Message-ID: <1118111836.5721.3.camel@cutter> On Tue, 2005-06-07 at 14:32 +1200, condition terminal wrote: > I still see no answer. > > I see people making jokes of this thread, but no answers. > > Why is beehive allowed to not be released under the terms and > conditions of the GPL when the GPL clearly states that files use to > build GPL code also have to be released under the terms and conditions > of the GPL? > b/c everyone who has had a lawyer review it say the same thing that beehive doesn't have to be released under the gpl and the integration level of beehive with red hat's environment makes it bordering on useless to release anyway. -sv From dfarning at sbcglobal.net Tue Jun 7 02:38:29 2005 From: dfarning at sbcglobal.net (david) Date: Mon, 06 Jun 2005 21:38:29 -0500 Subject: question about RedHat/Fedora and the GPL In-Reply-To: References: <1118040569.5652.2.camel@laptopd505.fenrus.org> <1118045329.5652.19.camel@laptopd505.fenrus.org> <20050606211730.GC28754@devserv.devel.redhat.com> <20050607021532.GA938160@hiwaay.net> Message-ID: <42A508A5.2090009@sbcglobal.net> condition terminal wrote: >I still see no answer. > >I see people making jokes of this thread, but no answers. > >Why is beehive allowed to not be released under the terms and >conditions of the GPL when the GPL clearly states that files use to >build GPL code also have to be released under the terms and conditions >of the GPL? > >ta. > > > It's not so much that you are barking up the wrong tree as you are barking at a telephone pole and hoping that it sprouts leaves. -dtf From mattdm at mattdm.org Tue Jun 7 02:43:14 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 6 Jun 2005 22:43:14 -0400 Subject: Kudzu API Documentation In-Reply-To: <20050607013652.GA20878@nostromo.devel.redhat.com> References: <20050606222447.M15073@minag.gob.pe> <1118097171.18813.29.camel@remedyz.boston.redhat.com> <20050606225759.GA13730@jadzia.bu.edu> <20050607013652.GA20878@nostromo.devel.redhat.com> Message-ID: <20050607024314.GA20334@jadzia.bu.edu> On Mon, Jun 06, 2005 at 09:36:52PM -0400, Bill Nottingham wrote: > > > I would think just read the code. I am not sure if there are any formal > > > docs. BTW Kudzu is most likely going away as soon as HAL can take over > > > all the tasks Kudzu handles. > > Including "locking up my system at boot"? > Yeah, we need to get that fully refined for HAL 1.0. Excellent. This kind of feature parity is a bare minimum! -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 80 degrees Fahrenheit. From symbiont at berlios.de Tue Jun 7 04:36:53 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Tue, 7 Jun 2005 12:36:53 +0800 Subject: Please Help Me! (Re: question about RedHat/Fedora and the GPL) In-Reply-To: References: <20050607021532.GA938160@hiwaay.net> Message-ID: <200506071236.53896.symbiont@berlios.de> On Tuesday 07 June 2005 10:32, condition terminal wrote: > I still see no answer. > > I see people making jokes of this thread, but no answers. > > Why is beehive allowed to not be released under the terms and > conditions of the GPL when the GPL clearly states that files use to > build GPL code also have to be released under the terms and > conditions of the GPL? Someone help me here. I appear to be posting to this list with legitimate responses and I get no responses. *wave* Can anyone hear me?! -- -jeff From symbiont at berlios.de Tue Jun 7 04:39:50 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Tue, 7 Jun 2005 12:39:50 +0800 Subject: question about RedHat/Fedora and the GPL In-Reply-To: <42A484DF.9090604@GreenKey.net> References: <1118040569.5652.2.camel@laptopd505.fenrus.org> <42A484DF.9090604@GreenKey.net> Message-ID: <200506071239.50914.symbiont@berlios.de> On Tuesday 07 June 2005 01:16, Curtis Doty wrote: > It sure would be nice if the Red Had specfile maintainers took us > into consideration. .. Those of us who don't have access to the Red > Hat IP known as beehive. .. And have no problem managing our own > parallel build environments. www.bugzilla.com -- -jeff From symbiont at berlios.de Tue Jun 7 04:40:12 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Tue, 7 Jun 2005 12:40:12 +0800 Subject: question about RedHat/Fedora and the GPL In-Reply-To: References: <42A484DF.9090604@GreenKey.net> Message-ID: <200506071240.13169.symbiont@berlios.de> It's not "factored" in or required. Can you read shell code? On Tuesday 07 June 2005 03:44, condition terminal wrote: > Funny.... > > If beehive has little to nothing to do with the build, why does it > have to be factored into spec files? > > Hardly a glorified cron job or meta-foo > > By the fact that spec files have to accommadate beehive it clearly > shows that beehive is indeed a big factor in the RH/Fedora binaires. > > ta. > > On 6/7/05, Curtis Doty wrote: > > Arjan van de Ven wrote: > > >yes. All the scripts needed to control the compilation and > > > installation of the executable is in the src.rpm perfectly fine. > > > > I find myself always adding something like: > > > > --- kernel-2.6.spec 2005-05-17 16:50:40.000000000 -0700 > > +++ kernel-2.6gk.spec 2005-05-30 18:58:15.000000000 -0700 > > @@ -21,7 +21,7 @@ > > %define sublevel 11 > > %define kversion 2.6.%{sublevel} > > %define rpmversion 2.6.%{sublevel} > > -%define rhbsys %([ -r /etc/beehive-root -o -n > > "%{?__beehive_build}" ] && echo || echo .`whoami`) > > +%define rhbsys %([ -r /etc/beehive-root -o -n > > "%{?__beehive_build}" ] && echo || echo .`whoami`@`hostname -s`) > > %if %{FC3} > > %define release %(R="$Revision: 1.27 $"; RR="${R##: }"; echo > > ${RR%%?})_FC3%{rhbsys} > > %endif > > > > It sure would be nice if the Red Had specfile maintainers took us > > into consideration. .. Those of us who don't have access to the Red > > Hat IP known as beehive. .. And have no problem managing our own > > parallel build environments. > > > > ../C > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-devel-list > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- -jeff From ivazquez at ivazquez.net Tue Jun 7 04:47:33 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 07 Jun 2005 00:47:33 -0400 Subject: Please Help Me! (Re: question about RedHat/Fedora and the GPL) In-Reply-To: <200506071236.53896.symbiont@berlios.de> References: <20050607021532.GA938160@hiwaay.net> <200506071236.53896.symbiont@berlios.de> Message-ID: <1118119653.26747.34.camel@ignacio.ignacio.lan> On Tue, 2005-06-07 at 12:36 +0800, Jeff Pitman wrote: > *wave* Can anyone hear me?! Nope. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 symbiont at berlios.de Tue Jun 7 04:53:22 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Tue, 7 Jun 2005 12:53:22 +0800 Subject: question about RedHat/Fedora and the GPL In-Reply-To: <200506071239.50914.symbiont@berlios.de> References: <42A484DF.9090604@GreenKey.net> <200506071239.50914.symbiont@berlios.de> Message-ID: <200506071253.22617.symbiont@berlios.de> On Tuesday 07 June 2005 12:39, Jeff Pitman wrote: > Today 12:39:50 > ? > > On Tuesday 07 June 2005 01:16, Curtis Doty wrote: > > It sure would be nice if the Red Had specfile maintainers took us > > into consideration. .. Those of us who don't have access to the Red > > Hat IP known as beehive. .. And have no problem managing our own > > parallel build environments. > > www.bugzilla.com Correction: bugzilla.redhat.com -- -jeff From conditionterminal at gmail.com Tue Jun 7 04:56:29 2005 From: conditionterminal at gmail.com (condition terminal) Date: Tue, 7 Jun 2005 16:56:29 +1200 Subject: Please Help Me! (Re: question about RedHat/Fedora and the GPL) In-Reply-To: <200506071236.53896.symbiont@berlios.de> References: <20050607021532.GA938160@hiwaay.net> <200506071236.53896.symbiont@berlios.de> Message-ID: Thats very grown up... On 6/7/05, Jeff Pitman wrote: > On Tuesday 07 June 2005 10:32, condition terminal wrote: > > I still see no answer. > > > > I see people making jokes of this thread, but no answers. > > > > Why is beehive allowed to not be released under the terms and > > conditions of the GPL when the GPL clearly states that files use to > > build GPL code also have to be released under the terms and > > conditions of the GPL? > > Someone help me here. I appear to be posting to this list with > legitimate responses and I get no responses. > > *wave* Can anyone hear me?! > > -- > -jeff > From Curtis at GreenKey.net Tue Jun 7 05:01:12 2005 From: Curtis at GreenKey.net (Curtis Doty) Date: Mon, 06 Jun 2005 22:01:12 -0700 Subject: question about RedHat/Fedora and the GPL In-Reply-To: <200506071239.50914.symbiont@berlios.de> References: <1118040569.5652.2.camel@laptopd505.fenrus.org> <42A484DF.9090604@GreenKey.net> <200506071239.50914.symbiont@berlios.de> Message-ID: <42A52A18.3080709@GreenKey.net> Jeff Pitman wrote: >On Tuesday 07 June 2005 01:16, Curtis Doty wrote: > > >>It sure would be nice if the Red Had specfile maintainers took us >>into consideration. .. Those of us who don't have access to the Red >>Hat IP known as beehive. .. And have no problem managing our own >>parallel build environments. >> >> >www.bugzilla.com > > So noted as a second. And dutifuly entered here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159696 And thanks for the link to the gphoto of a goofy Volkswagen. I'm sure it's owner is proud. :-p ../C From sundaram at redhat.com Tue Jun 7 05:22:48 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Tue, 07 Jun 2005 10:52:48 +0530 Subject: Fedora Goals In-Reply-To: <1118092064.32490.3.camel@rousalka.dyndns.org> References: <42A49BCD.1040104@redhat.com> <1118092064.32490.3.camel@rousalka.dyndns.org> Message-ID: <42A52F28.9000101@redhat.com> Hi >>http://www.fedoraproject.org/wiki/FC5Future >> >> > >Rhaa nothing on jackd or lowlatency work >Is Ingo still working at Red Hat ? > >Regards, >Nicolas Mailhot > > The above page is for tracking FC5 goals specifically. The timeline for inclusion of Ingo's RT patches (which is rapidly improving) in the kernel is still under discussion and Fedora project has a goal of sticking close to the upstream versions. regards Rahul From conditionterminal at gmail.com Tue Jun 7 05:23:12 2005 From: conditionterminal at gmail.com (condition terminal) Date: Tue, 7 Jun 2005 17:23:12 +1200 Subject: question about RedHat/Fedora and the GPL In-Reply-To: <42A52A18.3080709@GreenKey.net> References: <1118040569.5652.2.camel@laptopd505.fenrus.org> <42A484DF.9090604@GreenKey.net> <200506071239.50914.symbiont@berlios.de> <42A52A18.3080709@GreenKey.net> Message-ID: On 6/7/05, Curtis Doty wrote: > Jeff Pitman wrote: > > >On Tuesday 07 June 2005 01:16, Curtis Doty wrote: > > > > > >>It sure would be nice if the Red Had specfile maintainers took us > >>into consideration. .. Those of us who don't have access to the Red > >>Hat IP known as beehive. .. And have no problem managing our own > >>parallel build environments. > >> > >> > >www.bugzilla.com > > > > > So noted as a second. And dutifuly entered here: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159696 > > And thanks for the link to the gphoto of a goofy Volkswagen. I'm sure > it's owner is proud. :-p > hehe.. no no.. beehive isnt a factor in providing rpms... but we will just patch in beehive support and intergrate beehive into the build process, but then claim it has nothing to do with GPL and is free from the T&C of the GPL... ta From wtogami at redhat.com Tue Jun 7 07:40:11 2005 From: wtogami at redhat.com (Warren Togami) Date: Mon, 06 Jun 2005 21:40:11 -1000 Subject: question about RedHat/Fedora and the GPL In-Reply-To: <1118111836.5721.3.camel@cutter> References: <1118040569.5652.2.camel@laptopd505.fenrus.org> <1118045329.5652.19.camel@laptopd505.fenrus.org> <20050606211730.GC28754@devserv.devel.redhat.com> <20050607021532.GA938160@hiwaay.net> <1118111836.5721.3.camel@cutter> Message-ID: <42A54F5B.6070509@redhat.com> seth vidal wrote: > On Tue, 2005-06-07 at 14:32 +1200, condition terminal wrote: > >>I still see no answer. >> >>I see people making jokes of this thread, but no answers. >> >>Why is beehive allowed to not be released under the terms and >>conditions of the GPL when the GPL clearly states that files use to >>build GPL code also have to be released under the terms and conditions >>of the GPL? >> > > > b/c everyone who has had a lawyer review it say the same thing that > beehive doesn't have to be released under the gpl and the integration > level of beehive with red hat's environment makes it bordering on > useless to release anyway. > Not to mention that beehive is based on a very old design, and modern buildsystem designs like mach or mock do a better job of ensuring that certain types of bugs are discovered and fixed. Warren Togami wtogami at redhat.com From symbiont at berlios.de Tue Jun 7 07:46:31 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Tue, 7 Jun 2005 15:46:31 +0800 Subject: question about RedHat/Fedora and the GPL In-Reply-To: References: <42A52A18.3080709@GreenKey.net> Message-ID: <200506071546.31561.symbiont@berlios.de> On Tuesday 07 June 2005 13:23, condition terminal wrote: > hehe.. no no.. beehive isnt a factor in providing rpms... but we will > just patch in beehive support and intergrate beehive into the build > process, but then claim it has nothing to do with GPL and is free > from the T&C of the GPL... Now you are reaching troll status. "The" build process is rpmbuild. Redhat so happens to hack together a meta-builder on top. So what. Beehive is old and you would make more progress and contribution to the community by helping with tools like mach/mock. Even if they did release beehive, which they have no obligation to do, it would be useless. -- -jeff From nicolas.mailhot at laposte.net Tue Jun 7 08:03:19 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 7 Jun 2005 10:03:19 +0200 (CEST) Subject: Fedora Goals In-Reply-To: <42A52F28.9000101@redhat.com> References: <42A49BCD.1040104@redhat.com> <1118092064.32490.3.camel@rousalka.dyndns.org> <42A52F28.9000101@redhat.com> Message-ID: <41803.192.54.193.37.1118131399.squirrel@rousalka.dyndns.org> On Mar 7 juin 2005 7:22, Rahul Sundaram a ?crit : > Hi > >>>http://www.fedoraproject.org/wiki/FC5Future >>Rhaa nothing on jackd or lowlatency work >>Is Ingo still working at Red Hat ? > The above page is for tracking FC5 goals specifically. The timeline for > inclusion of Ingo's RT patches (which is rapidly improving) in the > kernel is still under discussion and Fedora project has a goal of > sticking close to the upstream versions. Historically RHL then FC were a way to have easly access to RH stuff (gcc/gcj work, gnome 0.x...). I find it a pitty a major RH work like the RT patches looks like it won't find its way in RH distros first. Regards, -- Nicolas Mailhot From twaugh at redhat.com Tue Jun 7 08:15:58 2005 From: twaugh at redhat.com (Tim Waugh) Date: Tue, 7 Jun 2005 09:15:58 +0100 Subject: jade looks for docbook/dtd/xml/4.2/docbookx.dtd ?? In-Reply-To: References: Message-ID: <20050607081558.GP8706@redhat.com> On Mon, Jun 06, 2005 at 08:14:29PM -0400, sean wrote: > I'm using db2html to build the gutenprint docs. But: > > /usr/bin/db2html gutenprint.xml > output is gutenprint > Using catalogs: /etc/sgml/xml-docbook-4.2-1.0-27.cat This catalog gives the correct path for the PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" DTD. > Using stylesheet: > /usr/share/sgml/docbook/utils-0.6.14/docbook-utils.dsl#html > Working on: > /usr/src/redhat/BUILD/print/doc/developer/gutenprint.xml > jade:/usr/src/redhat/BUILD/print/doc/developer/gutenprint.xml:13:0:E: > cannot open > "/usr/share/sgml/docbook/dtd/xml/4.2/docbookx.dtd" (No such > file or directory) Unfortunately gutenprint.xml uses a hard-coded path, which is not guaranteed to work on anyone's system except the author's. The !DOCTYPE at the top of the document should not use SYSTEM "/usr/share/sgml/..." but the PUBLIC ID above. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From conditionterminal at gmail.com Tue Jun 7 08:49:37 2005 From: conditionterminal at gmail.com (condition terminal) Date: Tue, 7 Jun 2005 20:49:37 +1200 Subject: question about RedHat/Fedora and the GPL In-Reply-To: <200506071546.31561.symbiont@berlios.de> References: <42A52A18.3080709@GreenKey.net> <200506071546.31561.symbiont@berlios.de> Message-ID: On 6/7/05, Jeff Pitman wrote: > On Tuesday 07 June 2005 13:23, condition terminal wrote: > > hehe.. no no.. beehive isnt a factor in providing rpms... but we will > > just patch in beehive support and intergrate beehive into the build > > process, but then claim it has nothing to do with GPL and is free > > from the T&C of the GPL... > > Now you are reaching troll status. > > "The" build process is rpmbuild. Redhat so happens to hack together a > meta-builder on top. So what. Beehive is old and you would make more > progress and contribution to the community by helping with tools like > mach/mock. > > Even if they did release beehive, which they have no obligation to do, > it would be useless. > "So what" thats a good arguement. However, regardless of the fact that there *could* be better solutions, it doesn't change the fact that RH deny access to beehive when it clearly is used to produce the binaries that go into FC and RHEL. Old, meta, could be better options, these arguments do not deviate the point that beehive is used to *control* the build of GPL source code. Again, the GPL clearly states that files used to control this process must be provided under the same terms and conditions. ta From mpeters at mac.com Tue Jun 7 09:00:54 2005 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 07 Jun 2005 02:00:54 -0700 Subject: question about RedHat/Fedora and the GPL In-Reply-To: References: <1118040569.5652.2.camel@laptopd505.fenrus.org> <1118045329.5652.19.camel@laptopd505.fenrus.org> <20050606211730.GC28754@devserv.devel.redhat.com> <20050607021532.GA938160@hiwaay.net> Message-ID: <1118134855.2234.7.camel@laptop.mpeters.local> On Tue, 2005-06-07 at 14:32 +1200, condition terminal wrote: > I still see no answer. There have been plenty of answers > > I see people making jokes of this thread, but no answers. > > Why is beehive allowed to not be released under the terms and > conditions of the GPL when the GPL clearly states that files use to > build GPL code also have to be released under the terms and conditions > of the GPL? > > ta. > beehive does not effect the build of the package. an rpm built by my typing rpmbuild --rebuild foobar.src.rpm is NOT going to be different than if something else builds it. The spec file is included in the src.rpm The spec file specifies the BuildRequires, the configure switches, the patches (which are in a src.rpm), the install process, the file permissions. All that is in the src.rpm and NOT in the build system that happens to rebuild the src.rpm for distribution. If that is not what you want to hear, fine - but don't then claim your question has gone unanswered. From laroche at redhat.com Tue Jun 7 09:04:51 2005 From: laroche at redhat.com (Florian La Roche) Date: Tue, 7 Jun 2005 11:04:51 +0200 Subject: Fedora Goals In-Reply-To: <41803.192.54.193.37.1118131399.squirrel@rousalka.dyndns.org> References: <42A49BCD.1040104@redhat.com> <1118092064.32490.3.camel@rousalka.dyndns.org> <42A52F28.9000101@redhat.com> <41803.192.54.193.37.1118131399.squirrel@rousalka.dyndns.org> Message-ID: <20050607090451.GB3030@dudweiler.stuttgart.redhat.com> On Tue, Jun 07, 2005 at 10:03:19AM +0200, Nicolas Mailhot wrote: > > On Mar 7 juin 2005 7:22, Rahul Sundaram a ?crit : > > Hi > > > >>>http://www.fedoraproject.org/wiki/FC5Future > > >>Rhaa nothing on jackd or lowlatency work > >>Is Ingo still working at Red Hat ? > > > The above page is for tracking FC5 goals specifically. The timeline for > > inclusion of Ingo's RT patches (which is rapidly improving) in the > > kernel is still under discussion and Fedora project has a goal of > > sticking close to the upstream versions. > > Historically RHL then FC were a way to have easly access to RH stuff > (gcc/gcj work, gnome 0.x...). I find it a pitty a major RH work like the > RT patches looks like it won't find its way in RH distros first. Might be still real development work that needs testing in a development community. Within Fedora it is already hitting quite a large audience. Also Dave is already pretty busy to move the kernel along for Fedora, then adding real development projects would really complicate release coordination a lot... (Not only for Dave, also for Ingo.) greetings, Florian La Roche From warren at togami.com Tue Jun 7 09:05:17 2005 From: warren at togami.com (Warren Togami) Date: Mon, 06 Jun 2005 23:05:17 -1000 Subject: question about RedHat/Fedora and the GPL In-Reply-To: <1118134855.2234.7.camel@laptop.mpeters.local> References: <1118040569.5652.2.camel@laptopd505.fenrus.org> <1118045329.5652.19.camel@laptopd505.fenrus.org> <20050606211730.GC28754@devserv.devel.redhat.com> <20050607021532.GA938160@hiwaay.net> <1118134855.2234.7.camel@laptop.mpeters.local> Message-ID: <42A5634D.7010301@togami.com> Michael A. Peters wrote: > beehive does not effect the build of the package. > an rpm built by my typing > > rpmbuild --rebuild foobar.src.rpm > > is NOT going to be different than if something else builds it. And if it is, it is a packaging bug that should be fixed. And beehive is actually one of the causes of these bugs not getting detected and fixed. beehive is not useful to you anyway. Please stop asking. Warren Togami wtogami at redhat.com From merlin at mwob.org.uk Tue Jun 7 09:16:27 2005 From: merlin at mwob.org.uk (Howard Johnson) Date: Tue, 07 Jun 2005 10:16:27 +0100 Subject: question about RedHat/Fedora and the GPL In-Reply-To: References: Message-ID: <1118135787.6344.12.camel@thunderbolt.localnet> Disclaimer: I am not a lawyer. On Mon, 2005-06-06 at 05:26, condition terminal wrote: > OK, firstly, I am sorry if I am miss understanding the text of the GPL. > > The part I am questioning is this: > > ---QUOTE--- > complete source code means all the source code for all modules it > contains, plus any associated interface definition files, plus the > scripts used to control compilation and installation of the > executable. > --END--QUOTE--- Red Hat make available all of the SRPMs from which the GPL-licenced components of their OSes are built (including RHEL). Red Hat have made available a number of OSes which include the rpmbuild command, using which I can rebuild the SRPMs and get binaries. In my (personal, non-lawyerish) opinion, that means they've fulfilled their obligation under the GPL. At the end of the day, Fedora and RHEL may as well be built with a for loop in shell for all it really seems to matter. Having rebuilt large chunks of various releases of Red Hat myself, the only impact I've seen from not having used beehive is the /etc/beehive-root check in the modern kernel spec files. > The same applies to the scripts for building the ISOs. I have seen > examples of what people have been doing, but no comment form > RH/Fedora. The ISO building scripts are, IIRC, part of anaconda, and distributed with modern versions of RHEL and Fedora. I've not tried building actual ISOs recently, but I've certainly generated all the hdlist files and whatnot for a custom network install. Frankly, having read the rest of this thread, I suspect there won't be much more gained without the consultation of lawyer or three. -- Howard Johnson From symbiont at berlios.de Tue Jun 7 09:24:50 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Tue, 7 Jun 2005 17:24:50 +0800 Subject: question about RedHat/Fedora and the GPL In-Reply-To: References: <200506071546.31561.symbiont@berlios.de> Message-ID: <200506071724.50604.symbiont@berlios.de> On Tuesday 07 June 2005 16:49, condition terminal wrote: > "So what" thats a good arguement. However, regardless of the fact > that there *could* be better solutions, it doesn't change the fact > that RH deny access to beehive when it clearly is used to produce the > binaries that go into FC and RHEL. > > Old, meta, could be better options, these arguments do not deviate > the point that beehive is used to *control* the build of GPL source > code. Again, the GPL clearly states that files used to control this > process must be provided under the same terms and conditions. The GPL only applies to one layer above the source files: Makefiles, configure, rpmbuild, etc. If it had an infinite ceiling above that, it'd be asinine. If you believe it does, I believe you should start at the very top of the software stack: the BIOS. Once you've convinced Acer Labs, AMI, Microid Research, Phoenix and Winbond that they're all in violation of the GPL because their BIOS allowed for builds of GPL software, come back here to talk about other links in the "infinite ceiling of GPL coverage". (Which doesn't exist). In other words, it stops one layer above. -- -jeff From david at fubar.dk Tue Jun 7 10:39:40 2005 From: david at fubar.dk (David Zeuthen) Date: Tue, 07 Jun 2005 06:39:40 -0400 Subject: Kudzu API Documentation In-Reply-To: <20050606225759.GA13730@jadzia.bu.edu> References: <20050606222447.M15073@minag.gob.pe> <1118097171.18813.29.camel@remedyz.boston.redhat.com> <20050606225759.GA13730@jadzia.bu.edu> Message-ID: <1118140780.4246.14.camel@daxter.boston.redhat.com> On Mon, 2005-06-06 at 18:57 -0400, Matthew Miller wrote: > On Mon, Jun 06, 2005 at 06:32:51PM -0400, John (J5) Palmieri wrote: > > I would think just read the code. I am not sure if there are any formal > > docs. BTW Kudzu is most likely going away as soon as HAL can take over > > all the tasks Kudzu handles. > > Including "locking up my system at boot"? > > Just wonderin'. :) > You're most probably referring to broken kernel drivers caused by hal poking the devices. The problem here is that in order to do automatic hardware configuration the right way, one actually needs to interact with the hardware and since it's done from a program rather than some user doing it interactively from a terminal, it sometimes confuses poor drivers that, as a side effect, lock up your system. The drivers just needs to get fixed and from what I can see this is getting better, not worse. Of course, out-of-tree drivers are slower to catch up but such is life. For example, at http://at76c503a.berlios.de/ there is an out-of-tree driver that I use for a USB 802.11b wireless device on my Powerbook 12". It works nice when configuring it interactively from the terminal (doing the ifconfig, iwconfig, dhclient styff) but it doesn't work that nice with hal/NetworkManager. Ditto for some USB storage devices but this has improved a lot since 2.6.10 or so. In a way, I'd argue that having hal and NetworkManager doing all this device probing actually helps out getting the drivers in better shape because users report bugs and bugs get fixed. David From david at fubar.dk Tue Jun 7 11:40:35 2005 From: david at fubar.dk (David Zeuthen) Date: Tue, 07 Jun 2005 07:40:35 -0400 Subject: Firstboot: Module to add other OS partitions' entry to fstab In-Reply-To: <20050530085600.53686.qmail@web30801.mail.mud.yahoo.com> References: <20050530085600.53686.qmail@web30801.mail.mud.yahoo.com> Message-ID: <1118144436.4246.31.camel@daxter.boston.redhat.com> On Mon, 2005-05-30 at 01:56 -0700, Prasad H.L. wrote: > Hi, > > I'm using Fedora Core 3. > > I've developed a firstboot python module which can > detect other OS(currently only windows) partitions and > add entries to the fstab. It also creates a user group > which has access to those partitions. > > The version of firstboot is 1.3.33-2. > > I would like to know whether the firstboot developers > are interested in seeing and using it in future > releases of Fedora. If so, I'll send the module as an > E-mail attachment. I'm pretty sure this is not the right way to tackle the problem. For a while before FC3 we've actually had HAL/fstab-sync add these automatically upon every boot. It worked great for all file systems that hal knows about (vfat, ntfs, ext3, reiserfs, hfs, hfs+, xfs, ...) and it was really usable. It worked great both on my Mac and x86 laptops which dual booted with other operating systems. However, we disabled it because there are the following risks: a) sometimes we could pick up an ataraid physical volume and mistake it for a real partition with e.g. vfat filesystem (supposed it was one of the PV's for a mirror), add it to the /etc/fstab and have it automounted and then we would risk data corruption. This never happened though (e.g. no bug was filed), but I didn't want to run the risk... b) Auto-mounting ext3 filesystems is dangerous since with FC3 and forward because we write extended attributes on ext3 which might panic older 2.4 kernels. (but note that at least all supported Red Hat distros with 2.4 have got kernel updates to cope with this; still vocal users complained when in fact they should just have kept their systems upgraded) What I want to do for FC5 is to have a gconf setting that can be toggled whether we should automount and display such drives in computer:/// in Nautilus. Whether this should option will be in the Nautilus or gnome-volume-manager preferences is another question. Another option is to set this preference in the installer: if you're installing a "Personal Desktop" set it to TRUE, if you're installing a server FALSE. We may also ask the question in firstboot though this is a bad idea as most target users won't understand the question. Hope this helps, David From nphilipp at redhat.com Tue Jun 7 11:56:17 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 07 Jun 2005 13:56:17 +0200 Subject: Beware of nvidia-graphics 1.0-7664 In-Reply-To: <20050606141401.GA15733@neu.nirvana> References: <1118046248.19918.3.camel@gibraltar.stuttgart.redhat.com> <20050606092246.GF4511@neu.nirvana> <1118065318.13470.2.camel@wombat.tiptoe.de> <20050606141401.GA15733@neu.nirvana> Message-ID: <1118145377.24054.1.camel@wombat.tiptoe.de> On Mon, 2005-06-06 at 16:14 +0200, Axel Thimm wrote: > On Mon, Jun 06, 2005 at 03:41:58PM +0200, Nils Philippsen wrote: > > On Mon, 2005-06-06 at 11:22 +0200, Axel Thimm wrote: > > > On Mon, Jun 06, 2005 at 10:24:08AM +0200, Nils Philippsen wrote: > > > > Note that this driver version broke suspend/resume for me (oh the joys > > > > of proprietary software with a proprietary development model), the > > > > display gets garbled. After some dabbling with it I found a workaround, > > > > though: Setting the display to DPMS suspend, then on again brought the > > > > card back into a semi-sane state (X works, text console are still > > > > garbled). > > > > > > Yes, I had to find that out myself when the screensaver kicked in > > > killing two hours of work ... :/ > > > > Hmm, screensavers work just fine here, I only had problems with > > suspend/resume until I implemented the workaround. > > My symptoms are display goes black, but never returns. The system works > fine though, but a headless laptop is no joy ... :/ Have you tried the workaround yet? > > > Also XvMC libs are broken :/ > > > > Care to elaborate? I don't see these in the livna RPMs I use, but maybe > > they're just missing ;-). > > libXvMCNVIDIA_dynamic.so.1 is refencing _nv0019XvMCdynamic which does > not exist. You'll only hit it if you use XvMC, e.g. mplayer/mythtv/xine etc. Well, mplayer doesn't use libXvMC here: nils at gibraltar:~> rpm -q mplayer --requires | grep -i xvmc nils at gibraltar:~> Perhaps you shouldn't build mplayer against nvidia's libraries? Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain 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 buildsys at redhat.com Tue Jun 7 11:56:38 2005 From: buildsys at redhat.com (Build System) Date: Tue, 7 Jun 2005 07:56:38 -0400 Subject: rawhide report: 20050607 changes Message-ID: <200506071156.j57BucXX005944@porkchop.devel.redhat.com> Updated Packages: ImageMagick-6.2.2.0-3 --------------------- * Mon Jun 06 2005 Tim Waugh 6.2.2.0-3 - Rebuilt for new ghostscript. anaconda-10.2.1.5-2 ------------------- * Mon Jun 06 2005 Jeremy Katz - 10.2.1.5-1 - fix segfault on upgrades evince-0.3.1-2 -------------- * Mon Jun 06 2005 Marco Pesenti Gritti - 0.3.1-2 - Add poppler version dep and refactor the gtk2 one evolution-2.2.2-8 ----------------- * Mon Jun 06 2005 David Malcolm - 2.2.2-8 - Added Ivan Gyurdiev's patch to move autosave files inside the .evolution directory gcc-4.0.0-11 ------------ * Mon Jun 06 2005 Jakub Jelinek 4.0.0-11 - update from CVS - PRs c++/20350, c++/21151, c++/21280, c++/21336, c++/21619, c++/21853, c/21873, c/21879, fortran/16898, fortran/16939, fortran/17192, fortran/17193, fortran/17202, fortran/18109, fortran/18283, fortran/18689, fortran/18890, fortran/19107, fortran/19195, fortran/20883, fortran/21912, java/21722, libgcj/21753, target/21888 - fix some -fvar-tracking bugs that were causing bogus DW_OP_piece ops - extend GCC NLS support, so that gettext 0.14.5+ can verify GCC internal diagnostics format strings - fix ICE on not fully enumerated VECTOR_CSTs (PR regression/21897) - fix a typo in reset_evolution_in_loop * Tue May 31 2005 Jakub Jelinek 4.0.0-10 - update from CVS - PRs c++/21165, c++/21340, c++/21455, c++/21614, c++/21681, c++/21768, c++/21784, fortran/20846, libfortran/17283, libfortran/20006, libfortran/20179, libgcj/20273, libgcj/21775, middle-end/20931, middle-end/20946, middle-end/21595 - remove no longer used extra line in %build (#158863) - fold extractions from vector constant - fix and , so that they are usable with -std=c89 -pedantic-errors - gimplify SAVE_EXPRs in types (PRs c/21536, c/20760) - fix ICE in ivopts on vector constant (Zdenek Dvorak, PR tree-optimization/21817) gimp-print-4.2.7-10 ------------------- * Mon Jun 06 2005 Tim Waugh 4.2.7-10 - Use full path for hardlink. * Sun Jun 05 2005 Tim Waugh 4.2.7-9 - Rebuilt for new ghostscript. kdelibs-6:3.4.1-1 ----------------- * Wed May 25 2005 Than Ngo 6:3.4.1-1 - 3.4.1 mc-1:4.6.1a-0.10 ---------------- * Mon Jun 06 2005 Jindrich Novy 4.6.1a-0.10 - update from CVS - sync with .utf8 patch and some minor gcc4 fixups - add .fixes patch - drop upstreamed .spaceprompt patch - update .userhost, .64bit patch - add mcview mikmod-3.1.6-35 --------------- * Mon Jun 06 2005 Martin Stransky 3.1.6-35 - fixed #159290,#159291 - CAN-2003-0427 - fixed playing mod files from tar archive mkinitrd-4.2.16-1 ----------------- * Mon Jun 06 2005 Peter Jones - 4.2.16-1 - Add a patch from Jeff Layton to remove files from the initramfs before executing the new init. (slightly modified, #153069) openssh-4.1p1-1 --------------- * Mon Jun 06 2005 Tomas Mraz 4.1p1-1 - upgrade to a new upstream version - call pam_loginuid as a pam session module xorg-x11-6.8.2-36 ----------------- * Mon May 30 2005 Mike A. Harris 6.8.2-36 - Added xorg-x11-6.8.2-ia64-elfloader-cache-flush.patch to fix cache flush issue on ia64 systems (#153103) * Wed May 25 2005 Mike A. Harris 6.8.2-35 - Remove /usr/X11R6/lib/X11/xinit symlink on non with_Xserver builds to prevent rpm complaining about unpackaged symlinks on s390 et al. now that bug (#108778) is fixed. * Mon May 23 2005 Mike A. Harris - Made FC4 patches enabled for FC3, which will be merged into the FC-3 branch, and released as an FC3-testing update soon. From Axel.Thimm at ATrpms.net Tue Jun 7 12:13:23 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 7 Jun 2005 14:13:23 +0200 Subject: Beware of nvidia-graphics 1.0-7664 In-Reply-To: <1118145377.24054.1.camel@wombat.tiptoe.de> References: <1118046248.19918.3.camel@gibraltar.stuttgart.redhat.com> <20050606092246.GF4511@neu.nirvana> <1118065318.13470.2.camel@wombat.tiptoe.de> <20050606141401.GA15733@neu.nirvana> <1118145377.24054.1.camel@wombat.tiptoe.de> Message-ID: <20050607121323.GA32184@neu.nirvana> On Tue, Jun 07, 2005 at 01:56:17PM +0200, Nils Philippsen wrote: > On Mon, 2005-06-06 at 16:14 +0200, Axel Thimm wrote: > > On Mon, Jun 06, 2005 at 03:41:58PM +0200, Nils Philippsen wrote: > > > On Mon, 2005-06-06 at 11:22 +0200, Axel Thimm wrote: > > > > On Mon, Jun 06, 2005 at 10:24:08AM +0200, Nils Philippsen wrote: > > > > > Note that this driver version broke suspend/resume for me (oh the joys > > > > > of proprietary software with a proprietary development model), the > > > > > display gets garbled. After some dabbling with it I found a workaround, > > > > > though: Setting the display to DPMS suspend, then on again brought the > > > > > card back into a semi-sane state (X works, text console are still > > > > > garbled). > > > > > > > > Yes, I had to find that out myself when the screensaver kicked in > > > > killing two hours of work ... :/ > > > > > > Hmm, screensavers work just fine here, I only had problems with > > > suspend/resume until I implemented the workaround. > > > > My symptoms are display goes black, but never returns. The system works > > fine though, but a headless laptop is no joy ... :/ > > Have you tried the workaround yet? No, I was bitten before reading this and haven't had the chance to test it. Also, my xset says I have DPMS suspend on, so I'm probably already using the workaround. My symptoms were not a garbled display, but a permanently turned off one, perhaps different bugs altogether. > > > > Also XvMC libs are broken :/ > > > > > > Care to elaborate? I don't see these in the livna RPMs I use, but maybe > > > they're just missing ;-). > > > > libXvMCNVIDIA_dynamic.so.1 is refencing _nv0019XvMCdynamic which does > > not exist. You'll only hit it if you use XvMC, e.g. mplayer/mythtv/xine etc. > > Well, mplayer doesn't use libXvMC here: > > nils at gibraltar:~> rpm -q mplayer --requires | grep -i xvmc > nils at gibraltar:~> It probably depends on your mplayer rpm. mplayer -vo help lists the output devices: $ mplayer -vo help MPlayer 1.0pre7-3.4.3 (C) 2000-2005 MPlayer Team CPU: Intel Pentium M Banias (Family: 6, Stepping: 5) Detected cache-line size is 64 bytes CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 Available video output drivers: ivtvosd IVTV OSD xvmc XVideo Motion Compensation xv X11/Xv x11 X11 ( XImage/Shm ) xover General X11 driver for overlay capable video output drivers gl X11 (OpenGL) gl2 X11 (OpenGL) - multiple textures version dga DGA ( Direct Graphic Access V2.0 ) sdl SDL YUV/RGB/BGR renderer (SDL v1.1.7+ only!) aa AAlib vesa VESA VBE 2.0 video output xvidix X11 (VIDIX) cvidix console VIDIX null Null video output mpegpes Mpeg-PES file ivtv IVTV-Mpeg file yuv4mpeg yuv4mpeg output for mjpegtools png PNG file jpeg JPEG file tga Targa output pnm PPM/PGM/PGMYUV file md5sum md5sum of each frame > Perhaps you shouldn't build mplayer against nvidia's libraries? You don't have a real choice on a fanless low-CPU-power system relaying on the GPU's acceleration. That's what XvMC is about. :( There is a wrapper lib that can be used to divert the XvMC implementation at runtime. That would protect against broken (unused) libs. -- 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 herrold at owlriver.com Tue Jun 7 12:49:15 2005 From: herrold at owlriver.com (R P Herrold) Date: Tue, 7 Jun 2005 08:49:15 -0400 (EDT) Subject: question about RedHat/Fedora and the GPL In-Reply-To: <1118134855.2234.7.camel@laptop.mpeters.local> References: <1118040569.5652.2.camel@laptopd505.fenrus.org> <1118045329.5652.19.camel@laptopd505.fenrus.org> <20050606211730.GC28754@devserv.devel.redhat.com> <20050607021532.GA938160@hiwaay.net> <1118134855.2234.7.camel@laptop.mpeters.local> Message-ID: gawd, I hate to jump in as the initial thread has wandered so far, and seems OT, but there are a couple clear items needing correction, under the GPL para 3 stanza. On Tue, 7 Jun 2005, Michael A. Peters wrote: > beehive does not effect the build of the package. > an rpm built by my typing > > rpmbuild --rebuild foobar.src.rpm > > is NOT going to be different than if something else builds it. > The spec file is included in the src.rpm Clearly false. My (documented) research, the experience at cAos, and in some of the RHEL rebuilds, and that of others, clearly show that it certainly matters a lot as to the build environment, and pre-arguments, defines, and arguments passed in to the builder. These settings are argueably covered under GPL 3, para following c), which is pretty explicit: "For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable." ------------ On Mon, 6 Jun 2005, seth vidal wrote: > b/c everyone who has had a lawyer review it say the same > thing that beehive doesn't have to be released under the gpl True enough, so far as it goes; 'release of beehive' code itself. But if the argument is that one may conceal from a covered recipient under the GPL, the state of the build environment which controls rpmbuild, autogen, ./configure, etc, I certainly know of at least two lawyers who differ. We presented in a panel discussion a couple years ago on the GPL, and hit this topic at the Ohio Linuxfest 2003 ;) -- Russ Herrold From skvidal at phy.duke.edu Tue Jun 7 12:55:28 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 07 Jun 2005 08:55:28 -0400 Subject: question about RedHat/Fedora and the GPL In-Reply-To: References: <1118040569.5652.2.camel@laptopd505.fenrus.org> <1118045329.5652.19.camel@laptopd505.fenrus.org> <20050606211730.GC28754@devserv.devel.redhat.com> <20050607021532.GA938160@hiwaay.net> <1118134855.2234.7.camel@laptop.mpeters.local> Message-ID: <1118148928.5721.24.camel@cutter> > True enough, so far as it goes; 'release of beehive' code > itself. But if the argument is that one may conceal from a > covered recipient under the GPL, the state of the build > environment which controls rpmbuild, autogen, ./configure, > etc, I certainly know of at least two lawyers who differ. We > presented in a panel discussion a couple years ago on the GPL, > and hit this topic at the Ohio Linuxfest 2003 ;) Then if that's the case it's an issue best taken up with fedora-legal or redhat-legal. No one on this list can do anything about it, I assure you. :) -sv From ph18 at cornell.edu Tue Jun 7 13:04:46 2005 From: ph18 at cornell.edu (Paul A. Houle) Date: Tue, 07 Jun 2005 09:04:46 -0400 Subject: Kudzu API Documentation In-Reply-To: <20050607013815.GB20878@nostromo.devel.redhat.com> References: <20050606222447.M15073@minag.gob.pe> <20050607013815.GB20878@nostromo.devel.redhat.com> Message-ID: On Mon, 6 Jun 2005 21:38:15 -0400, Bill Nottingham wrote: > > As for using the API, it's deprecated in favor of HAL for use > for probing for devices; at this point, it's mainly a layer to > get the proper modules loaded at boot, and will eventually disappear. > Great, I've found that one key to a successful Red Hat/Fedora install is rpm --erase kudzu nice to know that you're catching up. (1) We're about to put a new server in production, RHEL 4, and after running up2date the system became unbootable, crashing when kudzu would run. removing kudzu solved the problem. (2) I've got a home system that would have kudzu waste a great deal of time because my toddler would turn the power strips on and off that supplied a number of USB devices, in particular a set of speakers -- each time it flipped state, kudzu would come up and waste a lot of time, doing ~something~ that wasn't necessary, since I've always been able to plug and unplug USB devices without any help from kudzu, hal, or whatever. (3) I installed RHL 9 for my wife's sister, and she complained about long boot times. Some investigation turned up a number of useless processes on boot that wasted a few seconds each, and kudzu was the worst of them. I think kudzu is particularly intimidating to beginning Linux users -- Windows and Mac OS don't get into your face with 15 dialog boxes to answer because your USB speakers had a hiccup or because your mouse is having electrical problems. I'd love to see good software for detecting and automatically doing something useful with hotplug hardware (say I plug in my digital camera, it recognizes the volume id of the flash card and mounts it in a certain place), but seeing how much GUI stuff in RH/Fedora has gone on for years in 1/3-2/3rds working states, everybody being too polite to say the emperor has no clothes, I'm not all that optimistic. From b.j.smith at ieee.org Tue Jun 7 13:24:55 2005 From: b.j.smith at ieee.org (Bryan J. Smith) Date: Tue, 07 Jun 2005 08:24:55 -0500 Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ In-Reply-To: <20050606205504.GB18562@nostromo.devel.redhat.com> References: <19543506.1118090925521.JavaMail.root@wamui-milano.atl.sa.earthlink.net> <20050606205504.GB18562@nostromo.devel.redhat.com> Message-ID: <1118150696.4802.5.camel@bert64.mobile.smithconcepts.com> On Mon, 2005-06-06 at 16:55 -0400, Bill Nottingham wrote: > Well, there are some plans here. They don't usually involve bash, Well, I'm half-way decent at system-level C (even some real-time experience), as well as Perl, but no Python though (one of these days). > though, and generally consist of migrating to a completely different > framework, with support for legacy installation concerns such > as LSB compatibility and the current init-style scripts. So the base won't be traditional System-V init? -- Bryan J. Smith b.j.smith at ieee.org --------------------------------------------------------------------- It is mathematically impossible for someone who makes more than you to be anything but richer than you. Any tax rate that penalizes them will also penalize you similarly (to those below you, and then below them). Linear algebra, let alone differential calculus or even ele- mentary concepts of limits, is mutually exclusive with US journalism. So forget even attempting to explain how tax cuts work. ;-> From david at fubar.dk Tue Jun 7 14:32:36 2005 From: david at fubar.dk (David Zeuthen) Date: Tue, 07 Jun 2005 10:32:36 -0400 Subject: Kudzu API Documentation In-Reply-To: References: <20050606222447.M15073@minag.gob.pe> <20050607013815.GB20878@nostromo.devel.redhat.com> Message-ID: <1118154756.3926.6.camel@daxter.boston.redhat.com> On Tue, 2005-06-07 at 09:04 -0400, Paul A. Houle wrote: > I'd love to see good software for detecting and automatically doing > something useful with hotplug hardware (say I plug in my digital camera, > it recognizes the volume id of the flash card and mounts it in a certain > place), but seeing how much GUI stuff in RH/Fedora has gone on for years > in 1/3-2/3rds working states, everybody being too polite to say the > emperor has no clothes, I'm not all that optimistic. Have you at all tried Fedora Core 3? David From pjones at redhat.com Tue Jun 7 14:41:56 2005 From: pjones at redhat.com (Peter Jones) Date: Tue, 07 Jun 2005 10:41:56 -0400 Subject: What next? In-Reply-To: <1117736170.5435.30.camel@notebook.thl.home> References: <1117689924.2227.24.camel@thl.ct.heise.de> <20050602162047.GA27561@nostromo.devel.redhat.com> <1117731708.5435.13.camel@notebook.thl.home> <20050602175044.GB28352@nostromo.devel.redhat.com> <1117736170.5435.30.camel@notebook.thl.home> Message-ID: <1118155316.7916.3.camel@localhost.localdomain> On Thu, 2005-06-02 at 20:16 +0200, Thorsten Leemhuis wrote: > Am Donnerstag, den 02.06.2005, 13:50 -0400 schrieb Bill Nottingham: > > The big issue with *this* is that the CD media might not be useful for > > some CD players; see various online refs on DualDisc. > > Okay. But that not our problem if magazines what to ship those discs > (and it seems they do) we should help them with that IMHO (if > possible). Magazines distributing CDs that don't work will hurt our reputation, even though it may not be (directly) our fault. Given which type of drives the discs are most likely to fail on, I think we should discourage it. -- Peter From jspaleta at gmail.com Tue Jun 7 15:04:01 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 7 Jun 2005 11:04:01 -0400 Subject: Kudzu API Documentation In-Reply-To: <1118154756.3926.6.camel@daxter.boston.redhat.com> References: <20050606222447.M15073@minag.gob.pe> <20050607013815.GB20878@nostromo.devel.redhat.com> <1118154756.3926.6.camel@daxter.boston.redhat.com> Message-ID: <604aa79105060708042eb1dbc@mail.gmail.com> On 6/7/05, David Zeuthen wrote: > Have you at all tried Fedora Core 3? I have to say... that the hotplugging of usb-storage devices is working pretty damn well on my rawhide box. So well I bought a couple of usb enclosures to use as external storage for things like digital pictures. The /media/Volume_Label/ mountpoint magic makes its much easier to do anything scripted.. and it just works. Most of my pet peeves are second order issues like multiuser situations where non-console owners can hold the hotplug devices open https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136602 Or application level issues like gthumb not working the same way with mounted usb-storage the same as the ptp cameras. The dcim directory sensing for the gthumb wrapper works, but once gthumb is open.. you just can't interact with the mounted cf card as you would with the ptp camera it came from. I'd love to just be able to slap in a cf card in the reader automount it, have gthumb start up and then be able to hit one button and import all the files from the dcim directory tree on the cf card to my existing digital picture catalog on the harddrive. Instead gthumb treats the cf card as just another harddrive catalog space. Or in the case of music, rhythmbox forgetting about a music library and associated playlists that is on a removal disk if the disk is not present when rhythmbox starts up again. But the underlying hotplug mounting with volume-label as mountpoint is working like a charm. How close are we to seeing user configurable mount action policy for unique mounts? I'd love to be able to have an external harddrive full of music and be able to configure gnome to mount the drive and launch rhythmbox when the drive was connected all triggered by the volume name. -jef From dfarning at sbcglobal.net Tue Jun 7 15:06:13 2005 From: dfarning at sbcglobal.net (david) Date: Tue, 07 Jun 2005 10:06:13 -0500 Subject: Mirror monitor for meta data repos Message-ID: <42A5B7E5.5040707@sbcglobal.net> I downloaded a copy of mirmon, pulled a copy of the camel book from a shelf and started hacking on mirror monitor for meta data repos (m3d). The basic idea is to probe for the ?? of the primary.xml of repo.xml and compare the ?? of designated mirrors repo.xml. Attached is a sample output table. Each version will have it's own separate page. ie fc1-core, fc3-extras, fc-development. All the available archs for a version will be on a page. I believe that I will use a color scheme of green, uptodate; yellow, outofdate; red, error contacting mirror; white, mirror does not carry copy of that arch Clicking a green or yellow square will link to repodata.html for that arch. Clicking a red square will link to a more detail error statement of the mirror failure. The row of little row of squares in a mirror/arch intersection give a 24 history of that mirrors status. I'm thinking about narrowing row so that a 24 history fit comfortably. All suggestion on what other information will be useful. -dtf -------------- next part -------------- An HTML attachment was scrubbed... URL: From jspaleta at gmail.com Tue Jun 7 16:08:50 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 7 Jun 2005 12:08:50 -0400 Subject: Firstboot: Module to add other OS partitions' entry to fstab In-Reply-To: <1118144436.4246.31.camel@daxter.boston.redhat.com> References: <20050530085600.53686.qmail@web30801.mail.mud.yahoo.com> <1118144436.4246.31.camel@daxter.boston.redhat.com> Message-ID: <604aa791050607090853289862@mail.gmail.com> On 6/7/05, David Zeuthen wrote: > Another option is to set this preference in the installer: if you're > installing a "Personal Desktop" set it to TRUE, if you're installing a > server FALSE. We may also ask the question in firstboot though this is a > bad idea as most target users won't understand the question. If you don't expose the boolean during firstboot, do you plan to make ui available to expose this to an admin for later reconfiguration? If people experience problem a or problem b or some other wacky issue because they run a locally compiled kernel, leaving that option buried in the bowels of gconf with no ui exposed to switch the state isn't going to help anyone. -jef From notting at redhat.com Tue Jun 7 16:10:56 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 7 Jun 2005 12:10:56 -0400 Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ In-Reply-To: <1118150696.4802.5.camel@bert64.mobile.smithconcepts.com> References: <19543506.1118090925521.JavaMail.root@wamui-milano.atl.sa.earthlink.net> <20050606205504.GB18562@nostromo.devel.redhat.com> <1118150696.4802.5.camel@bert64.mobile.smithconcepts.com> Message-ID: <20050607160935.GA4680@nostromo.devel.redhat.com> Bryan J. Smith (b.j.smith at ieee.org) said: > On Mon, 2005-06-06 at 16:55 -0400, Bill Nottingham wrote: > > Well, there are some plans here. They don't usually involve bash, > > Well, I'm half-way decent at system-level C (even some real-time > experience), as well as Perl, but no Python though (one of these > days). > > > though, and generally consist of migrating to a completely different > > framework, with support for legacy installation concerns such > > as LSB compatibility and the current init-style scripts. > > So the base won't be traditional System-V init? Correct. (Well, the core *init* under everything may or may not change; but it certainly won't be the same interface from userland.) Bill From jspaleta at gmail.com Tue Jun 7 16:15:11 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 7 Jun 2005 12:15:11 -0400 Subject: Mirror monitor for meta data repos In-Reply-To: <42A5B7E5.5040707@sbcglobal.net> References: <42A5B7E5.5040707@sbcglobal.net> Message-ID: <604aa791050607091570d2d535@mail.gmail.com> On 6/7/05, david wrote: > The row of little row of squares in a mirror/arch intersection give a 24 > history of that mirrors status. I'm thinking about narrowing row so > that a 24 history fit comfortably. > > > All suggestion on what other information will be useful. How ofter do you plan to pull from each server? How long does it take to make a comparison of the full set of official fedora mirrors? -jef From david at fubar.dk Tue Jun 7 16:18:22 2005 From: david at fubar.dk (David Zeuthen) Date: Tue, 07 Jun 2005 12:18:22 -0400 Subject: Firstboot: Module to add other OS partitions' entry to fstab In-Reply-To: <604aa791050607090853289862@mail.gmail.com> References: <20050530085600.53686.qmail@web30801.mail.mud.yahoo.com> <1118144436.4246.31.camel@daxter.boston.redhat.com> <604aa791050607090853289862@mail.gmail.com> Message-ID: <1118161102.3926.39.camel@daxter.boston.redhat.com> On Tue, 2005-06-07 at 12:08 -0400, Jeff Spaleta wrote: > On 6/7/05, David Zeuthen wrote: > > Another option is to set this preference in the installer: if you're > > installing a "Personal Desktop" set it to TRUE, if you're installing a > > server FALSE. We may also ask the question in firstboot though this is a > > bad idea as most target users won't understand the question. > > If you don't expose the boolean during firstboot, do you plan to make > ui available to expose this to an admin for later reconfiguration? If > people experience problem a or problem b or some other wacky issue > because they run a locally compiled kernel, leaving that option buried > in the bowels of gconf with no ui exposed to switch the state isn't > going to help anyone. Well, for admins I suppose that gconf-editor is pretty good? Btw, all this is still a bit up in the air; I suppose it's easier to discuss in detail once it's actually implemented... David From david at fubar.dk Tue Jun 7 16:24:34 2005 From: david at fubar.dk (David Zeuthen) Date: Tue, 07 Jun 2005 12:24:34 -0400 Subject: Kudzu API Documentation In-Reply-To: <604aa79105060708042eb1dbc@mail.gmail.com> References: <20050606222447.M15073@minag.gob.pe> <20050607013815.GB20878@nostromo.devel.redhat.com> <1118154756.3926.6.camel@daxter.boston.redhat.com> <604aa79105060708042eb1dbc@mail.gmail.com> Message-ID: <1118161474.3926.47.camel@daxter.boston.redhat.com> On Tue, 2005-06-07 at 11:04 -0400, Jeff Spaleta wrote: > Most of my pet peeves are second order issues like multiuser situations > where non-console owners can hold the hotplug devices open > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136602 It's something that is particular difficult to do with the way we now handle removable storage (fstab-sync and /etc/fstab) - with a mount wrapper it should be much easier (see below). > Or application level issues like gthumb not working the same way with > mounted usb-storage the same as the ptp cameras. The dcim directory > sensing for the gthumb wrapper works, but once gthumb is open.. you > just can't interact with the mounted cf card as you would with the ptp > camera it came from. I'd love to just be able to slap in a cf card in > the reader automount it, have gthumb start up and then be able to hit > one button and import all the files from the dcim directory tree on > the cf card to my existing digital picture catalog on the harddrive. > Instead gthumb treats the cf card as just another harddrive catalog > space. Yeah, this is a bug with gthumb really; I'd really wish it had that functionality too. > Or in the case of music, rhythmbox forgetting about a music library > and associated playlists that is on a removal disk if the disk is not > present when rhythmbox starts up again. I know Colin was talking about fixing this... > But the underlying hotplug mounting with volume-label as mountpoint is > working like a charm. How close are we to seeing user configurable > mount action policy for unique mounts? I'd love to be able to have an > external harddrive full of music and be able to configure gnome to > mount the drive and launch rhythmbox when the drive was connected all > triggered by the volume name. I put down my thoughts here http://mail.gnome.org/archives/utopia-list/2005-May/msg00005.html but the code still needs to be written/integrated (a few weeks of work). It's definitely something I'd like to see in FC5. Cheers, David From dfarning at sbcglobal.net Tue Jun 7 16:51:31 2005 From: dfarning at sbcglobal.net (david) Date: Tue, 07 Jun 2005 11:51:31 -0500 Subject: Mirror monitor for meta data repos In-Reply-To: <604aa791050607091570d2d535@mail.gmail.com> References: <42A5B7E5.5040707@sbcglobal.net> <604aa791050607091570d2d535@mail.gmail.com> Message-ID: <42A5D093.2080208@sbcglobal.net> Jeff Spaleta wrote: >On 6/7/05, david wrote: > > >>The row of little row of squares in a mirror/arch intersection give a 24 >>history of that mirrors status. I'm thinking about narrowing row so >>that a 24 history fit comfortably. >> >> >>All suggestion on what other information will be useful. >> >> > > >How ofter do you plan to pull from each server? >How long does it take to make a comparison of the full set of official >fedora mirrors? > >-jef > > > I'm looking at pulling the timestamp from the master about every hour. If a master version/arch timestamp changes, I will check evey hour until it becomes up to date. If a prior version/arch timestamp fails, I will check evey hour until it becomes up to date. Every {hour | couple of hours] I will check a random version/arch timestamp per mirror to ensure that the entire mirror isn't dead. There is no official list of which mirror hold which arch-- so with the assumption that all mirrors are holding all archs using the list at http://fedora.redhat.com/download/mirrors.html and a max of 25 probes. [dfarning at localhost m3d]$ time /home/dfarning/workspace/m3d/mirmon.pl -v -get all -c development/core.conf -probes 25 real 13m12.098s user 0m51.962s sys 0m31.346s An update should be pretty quick because the master timestamp seldom changes. thanks -dtf From jspaleta at gmail.com Tue Jun 7 17:07:08 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 7 Jun 2005 13:07:08 -0400 Subject: Mirror monitor for meta data repos In-Reply-To: <42A5D093.2080208@sbcglobal.net> References: <42A5B7E5.5040707@sbcglobal.net> <604aa791050607091570d2d535@mail.gmail.com> <42A5D093.2080208@sbcglobal.net> Message-ID: <604aa791050607100717e0dcd1@mail.gmail.com> On 6/7/05, david wrote: > I'm looking at pulling the timestamp from the master about every hour. > > If a master version/arch timestamp changes, I will check evey hour > until it becomes up to date. > If a prior version/arch timestamp fails, I will check evey hour until > it becomes up to date. > > Every {hour | couple of hours] I will check a random version/arch > timestamp per mirror to ensure that the entire mirror isn't dead. So you are checking every mirror once an hour after you see the master mirror timestamp change? So the time between checking the master and the time to check an individual a mirror is at maximum 1 hour? You need to have a state of "unknown" for each mirror between when you know the master has changed and you have yet to check to see if the mirror has been updated. You can't assume that a mirror is out of date until you check that mirror. Nor can you assume the mirror is up2date either. Mirrors are simply in an unverified state in the meantime. > [dfarning at localhost m3d]$ time /home/dfarning/workspace/m3d/mirmon.pl -v > -get all -c development/core.conf -probes 25 > real 13m12.098s > user 0m51.962s > sys 0m31.346s > > An update should be pretty quick because the master timestamp seldom > changes. that 25 means 25 different mirrors? How long does it take to do the whole set of mirrors assuming just x86? Thinking again about the unverified state for the web page summary... if it takes 15 minutes to work through a list of mirrors.. you want to make sure that for those 15 minutes the webpage isnt misleading. -jef From notting at redhat.com Tue Jun 7 16:09:35 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 7 Jun 2005 12:09:35 -0400 Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ In-Reply-To: <1118150696.4802.5.camel@bert64.mobile.smithconcepts.com> References: <19543506.1118090925521.JavaMail.root@wamui-milano.atl.sa.earthlink.net> <20050606205504.GB18562@nostromo.devel.redhat.com> <1118150696.4802.5.camel@bert64.mobile.smithconcepts.com> Message-ID: <20050607160935.GA4680@nostromo.devel.redhat.com> Bryan J. Smith (b.j.smith at ieee.org) said: > On Mon, 2005-06-06 at 16:55 -0400, Bill Nottingham wrote: > > Well, there are some plans here. They don't usually involve bash, > > Well, I'm half-way decent at system-level C (even some real-time > experience), as well as Perl, but no Python though (one of these > days). > > > though, and generally consist of migrating to a completely different > > framework, with support for legacy installation concerns such > > as LSB compatibility and the current init-style scripts. > > So the base won't be traditional System-V init? Correct. (Well, the core *init* under everything may or may not change; but it certainly won't be the same interface from userland.) Bill From thebs413 at earthlink.net Tue Jun 7 17:19:39 2005 From: thebs413 at earthlink.net (Bryan J. Smith ) Date: Tue, 7 Jun 2005 12:19:39 -0500 (GMT-05:00) Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ Message-ID: <25326487.1118164779912.JavaMail.root@wamui-norfolk.atl.sa.earthlink.net> From: Bill Nottingham > Correct. (Well, the core *init* under everything may or may not > change; but it certainly won't be the same interface from userland.) Two follow-ups then: 1) Is there any information, documentation, ideas or any mailing archives on this? 2) How can I help from a Bash, C or Perl perspective? I would love to be involved with userland LSB-compliance/ideal end of it. I've also been looking for an excuse to learn Python/Newt (that's what the fedora/redhat-config-* programs are written in so they can target both slang and GTK+, correct?), so if there is some opportunity to develop there, I'm interested. I can give up to an honest 10 hours/week on this, so just let me know. I'd really to be involved in this area. -- Bryan J. Smith mailto:b.j.smith at ieee.org From jspaleta at gmail.com Tue Jun 7 17:26:01 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 7 Jun 2005 13:26:01 -0400 Subject: Firstboot: Module to add other OS partitions' entry to fstab In-Reply-To: <1118161102.3926.39.camel@daxter.boston.redhat.com> References: <20050530085600.53686.qmail@web30801.mail.mud.yahoo.com> <1118144436.4246.31.camel@daxter.boston.redhat.com> <604aa791050607090853289862@mail.gmail.com> <1118161102.3926.39.camel@daxter.boston.redhat.com> Message-ID: <604aa79105060710267387fbb1@mail.gmail.com> On 6/7/05, David Zeuthen wrote: > Well, for admins I suppose that gconf-editor is pretty good? gconf-editor can be..adequate.. under certain conditions. The primary one being you know exactly what boolean you are looking for before you go looking for it and its not a critically important setting. I would suggest that a boolean that can have serious system-wide effects like the problems you described in your post isn't something people shouldn't have to troll through the gconf tree for.. in a panic. We aren't talking about turning on metacity wireframe window moving to get a slight speedup on low end hardware. You mentioned potential data corruption situations... i think thats important enough to expose in sort sort of dedicated ui. Potentially important enough to be a firstboot dialog. -jef From dfarning at sbcglobal.net Tue Jun 7 18:00:36 2005 From: dfarning at sbcglobal.net (david) Date: Tue, 07 Jun 2005 13:00:36 -0500 Subject: Mirror monitor for meta data repos In-Reply-To: <604aa791050607100717e0dcd1@mail.gmail.com> References: <42A5B7E5.5040707@sbcglobal.net> <604aa791050607091570d2d535@mail.gmail.com> <42A5D093.2080208@sbcglobal.net> <604aa791050607100717e0dcd1@mail.gmail.com> Message-ID: <42A5E0C4.4090703@sbcglobal.net> Jeff Spaleta wrote: >On 6/7/05, david wrote: > > >>I'm looking at pulling the timestamp from the master about every hour. >> >>If a master version/arch timestamp changes, I will check evey hour >>until it becomes up to date. >>If a prior version/arch timestamp fails, I will check evey hour until >>it becomes up to date. >> >>Every {hour | couple of hours] I will check a random version/arch >>timestamp per mirror to ensure that the entire mirror isn't dead. >> >> > >So you are checking every mirror once an hour after you see the master >mirror timestamp change? So the time between checking the master and >the time to check an individual a mirror is at maximum 1 hour? You >need to have a state of "unknown" for each mirror between when you >know the master has changed and you have yet to check to see if the >mirror has been updated. You can't assume that a mirror is out of date >until you check that mirror. Nor can you assume the mirror is up2date >either. Mirrors are simply in an unverified state in the meantime. > > > Good heavens man, I just working on this a few hours ago. So as they say, "The concrete ain't set up real firm yet." I originally started looking at the mirror status problem to set up some sort of geoip/ mirror_list/dns_server for a repository and wanted to ensure that I am not referring to dead or out of date mirrors. But, that a good why off. In the mean time-- My intentions are to probe all master timestamps each hour. So, for the development branch 1 mirror X 6 arch X ~1.1K (size of repomd.xml) = 250K traffic per hour If a master timestamp has change - probe all mirrors ~250 mirror X 1 arch X ~1.1K = 1.5M traffic per arch per change (development changes ~ once per day) If a master timestamp has not changed - probe only those mirrors that did not report op2date last probe ~150 mirror X 1 arch X ~1.1K = 150K traffic first hour after change (sync delay) ~75 mirror X 1 arch X ~1.1K = 750K traffic second hour after sage (sync delay) ... Every time a master timestamp is changed all mirrors are immediately reprobed to eliminate "the dreaded unknown state." >>[dfarning at localhost m3d]$ time /home/dfarning/workspace/m3d/mirmon.pl -v >>-get all -c development/core.conf -probes 25 >>real 13m12.098s >>user 0m51.962s >>sys 0m31.346s >> >>An update should be pretty quick because the master timestamp seldom >>changes. >> >> > >that 25 means 25 different mirrors? How long does it take to do the >whole set of mirrors assuming just x86? Thinking again about the >unverified state for the web page summary... if it takes 15 minutes to >work through a list of mirrors.. you want to make sure that for those >15 minutes the webpage isnt misleading. > > > A probe is a little chunk of c code ( part of a repository tool kit that I am working on) that return the primary.xml timestamp for a given repo ie. rtk_probe ftp://ftp.linux.ncsu.edu/pub/fedora/linux/core//development/ returns 1118144219 hmm.. lets rerun for only one arch (x86) and up the probes to 250 and see the results on my dsl line Took 23 seconds to get all but the last 14 mirrors. Those reported time out failure are 360 seconds as set in the probe. Not bad How would you feel if I stated the time since the last probe so user are aware of that fact. Also, the mirror master could (with the help of m3d) clean up the mirror list so not as much effort is spent contacting dead mirrors. >-jef > > > thanks -dtf From notting at redhat.com Tue Jun 7 18:04:17 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 7 Jun 2005 14:04:17 -0400 Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ In-Reply-To: <25326487.1118164779912.JavaMail.root@wamui-norfolk.atl.sa.earthlink.net> References: <25326487.1118164779912.JavaMail.root@wamui-norfolk.atl.sa.earthlink.net> Message-ID: <20050607180417.GA5916@nostromo.devel.redhat.com> Bryan J. Smith (thebs413 at earthlink.net) said: > Two follow-ups then: > > 1) Is there any information, documentation, ideas or any mailing > archives on this? Here ya go. Luke Macken (lmacken at redhat.com) may be looking at some of this in the near future. > I've also been looking for an excuse to learn Python/Newt (that's what > the fedora/redhat-config-* programs are written in so they can target > both slang and GTK+, correct?), so if there is some opportunity to > develop there, I'm interested. At first, I expect there to be very little UI code here; what's needed is the framework. Bill -------------- next part -------------- Some comments/proposals for init work ------------------------------------- Please refer to any of the varied references on the net for System V init to get a general idea of how the current init system works. The current initialization and bootup system has generated various complaints: - it's not very fast, or at least appears that way - it does not have full LSB support, or dependency support - there's not a good global view of what services that are configured for a particular runlevel are actually running - there's no mechanism for respawning of services except by init - there's no structured logging of serviced, and if they failed, etc Over time, various alternative frameworks have popped up, including, but not limited to: - minit - runit - initng - serel Looking at how these stack up: 1) Bootup speed A lot of these claim "look how much faster we boot!". However, in most cases they miss the point. For example: A) The new-fangled init system has: 1) exec nscd B) The current init system has: 1) make sure nscd directories are in place 2) check to make sure it's not already running 3) set ulimits correctly 4) set nice level 5) setuid to a specified user, if necessary 6) exec nscd 7) log whether or not it succeeded Telling me that A) is faster is meaningless, and, frankly, not useful. What's needed is to make B) faster. In some cases, this can mean eliminating some of those steps. But blindly eliminating all of them is silly. The other aspect of bootup speed is parallelization. Initially, this seems like a big win. However, testing of simple naive implementations show that, at least initially, parallelization isn't a huge benefit. Generally, this is because disk seek time and other I/O limitations can dominate. Moreover, a not insignificant portion of boot time is the parts handled by /etc/rc.sysinit; this is almost entirely linear in nature (need to load modules first, then check filesystems, then clean out /tmp, etc.) 2) LSB support http://www.linuxbase.org/spec//booksets/LSB-Core-generic/LSB-Core-generic.html#TOCSYSINIT Currently, LSB support is wedged in via chkconfig. chkconfig can parse LSB standard headers for start and stop levels. For LSB dependencies, a conversion to the current Sxx/Kxx priorities is done at script installation time by computing a valid start priority relative to the dependencies specified. This does have some problems: - priorities aren't recomputed if other dependencies are added/changed - adoption of other LSB features is slow Moreover, very few of the current initscripts correspond to LSB standards such as for exit codes - in fact, they're very much ad-hoc in that regard. 3) No global view of state Services can be queried individually for status, and there's a global view of what services are configured to start via system-config-services. There's no combination of this, however. (And, the implementation of system-config-services leaves much to be desired.) 4) No respawn mechanism Some of the newer implementations actually do handle this. 5) No structured logging Earlier (prior to FC4) initlog was used. This was a inefficient and badly coded (by me!) program that basically dumped a program's output to syslog if it failed, and otherwise logged a simple ' succeeded'. However, this only happened on startup; there was no monitoring of services to see if they failed later, or respawning of services if they did fail. Moreover, since it was just logging program output, it didn't log in a way that could be easily monitored or picked out. So, how to solve these problems? -------------------------------- Obviously, rewrite everything! This would include, at a minimum, /etc/rc. It may also include /sbin/init, and could extend to crond, atd, xinetd, and other service frameworks as well. Features required by this implementation: - Proper *runtime* dependency support. Starting a service should start its dependencies, in-order. Changes to dependent services should be immediately handled. Out of this work, parallelization can easily fall out. Without this work, parallelization is pointless. :) - Full backwards compatibility. Old-style init scripts aren't going to go away anytime soon. - Full LSB support for LSB init scripts. Makes the spec groups happy, even though the number of LSB scripts is basically nil. - D-BUS support. Services should be exposed via D-BUS, and should be available for querying to: - check what's configured - check what's actually running - start them - stop them - etc. The services should also post notifications via D-BUS when they've started successfully, and (more importantly) when they haven't, or when they've unexpectedly exited. - Support for respawning services, if necessary. Complete with rate limits and other fun stuff. This should handle most of the concerns above. More speed hopefully will fall out of this, but if it doesn't, oh well. Looking at these features, the best way to do this is almost certainly to add the D-BUS, etc support into the services themselves, and provide a wrapper for legacy LSB and other initscripts that provides the D-BUS interface to them. Things to look at when implementing this: - initng http://jw.dyndns.org/initng/ The latest new-init proposal, it's starting to get more traction, Segfaults immediately when I tried it, though. - SystemServices http://www.gnome.org/~seth/blog/2003/Sep/27 Beat code out of Seth if necessary. :) He's got the right idea, even if I quibble with some of his implementation. (Not sure that python is a good idea here, at least for parts of it.) Things we'd like to look at, but can't: - launchd http://www.macgeekery.com/tips/all_about_launchd_items_and_how_to_make_one_yourself http://developer.apple.com/documentation/Darwin/Reference/ManPages/man8/launchd.8.html http://arstechnica.com/reviews/os/macosx-10.4.ars/5 You can look at the docs. You can probably even play with a OS X implementation. You can not look at the code. launchd is APSL licensed. Looking at the code will contaminate you, and you won't be able to write code that implements its features. It may be possible to have someone else, who never touches our code, to look at the code and writes specs. The best solution is to beat Apple into releasing launchd under a sane license. Don't hold your breath, though. Required languages of implementation: C, potentially a little python Not much flexibility here. Obviously, the lower level in the bootup process you get, the more you're confined to C. From razvan.vilt at linux360.ro Tue Jun 7 18:05:41 2005 From: razvan.vilt at linux360.ro (Razvan Corneliu C.R. Vilt) Date: Tue, 07 Jun 2005 21:05:41 +0300 Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ In-Reply-To: <20050607160935.GA4680@nostromo.devel.redhat.com> References: <19543506.1118090925521.JavaMail.root@wamui-milano.atl.sa.earthlink.net> <20050606205504.GB18562@nostromo.devel.redhat.com> <1118150696.4802.5.camel@bert64.mobile.smithconcepts.com> <20050607160935.GA4680@nostromo.devel.redhat.com> Message-ID: <42A5E1F5.6050209@linux360.ro> Bill Nottingham wrote: >Bryan J. Smith (b.j.smith at ieee.org) said: > > >>On Mon, 2005-06-06 at 16:55 -0400, Bill Nottingham wrote: >> >> >>>though, and generally consist of migrating to a completely different >>>framework, with support for legacy installation concerns such >>>as LSB compatibility and the current init-style scripts. >>> >>> >>So the base won't be traditional System-V init? >> >> > >Correct. (Well, the core *init* under everything may or may not >change; but it certainly won't be the same interface from userland.) > >Bill > I hate to be the bad guy over here, but what about something similar with SMF from Solaris. It's by far the best thing for what we need, and it's already there and functional. It provides dependancy checking, and any other feature you can think of. It should be easy to combine with SELinux knowing all that information that is provided in the service xml files. Let's try not to reinvent the wheel due to political issues between Sun Microsystems and Red Hat. Best regards, Razvan P.S. for a short presentation with enough information to get you excited about this check out http://www.filibeto.org/aduritz/truetrue/solaris10/sol-smf.pdf and http://mediacast.sun.com/share/lianep/t-smf-general-march-2005.pdf . From notting at redhat.com Tue Jun 7 18:08:08 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 7 Jun 2005 14:08:08 -0400 Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ In-Reply-To: <42A5E1F5.6050209@linux360.ro> References: <19543506.1118090925521.JavaMail.root@wamui-milano.atl.sa.earthlink.net> <20050606205504.GB18562@nostromo.devel.redhat.com> <1118150696.4802.5.camel@bert64.mobile.smithconcepts.com> <20050607160935.GA4680@nostromo.devel.redhat.com> <42A5E1F5.6050209@linux360.ro> Message-ID: <20050607180808.GB5916@nostromo.devel.redhat.com> Razvan Corneliu C.R. Vilt (razvan.vilt at linux360.ro) said: > I hate to be the bad guy over here, but what about something similar > with SMF from Solaris. License? Bill From razvan.vilt at linux360.ro Tue Jun 7 18:15:08 2005 From: razvan.vilt at linux360.ro (Razvan Corneliu C.R. Vilt) Date: Tue, 07 Jun 2005 21:15:08 +0300 Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ In-Reply-To: <20050607180808.GB5916@nostromo.devel.redhat.com> References: <19543506.1118090925521.JavaMail.root@wamui-milano.atl.sa.earthlink.net> <20050606205504.GB18562@nostromo.devel.redhat.com> <1118150696.4802.5.camel@bert64.mobile.smithconcepts.com> <20050607160935.GA4680@nostromo.devel.redhat.com> <42A5E1F5.6050209@linux360.ro> <20050607180808.GB5916@nostromo.devel.redhat.com> Message-ID: <42A5E42C.5080602@linux360.ro> Bill Nottingham wrote: >Razvan Corneliu C.R. Vilt (razvan.vilt at linux360.ro) said: > > >>I hate to be the bad guy over here, but what about something similar >>with SMF from Solaris. >> >> > >License? > >Bill > > > Good point. But based on the docs on the internet, we could implement something similar in functionality. They kinda had the same problems that we are facing right now. I suspect that it should be soon covered by the CDDL Licence, provided the imminent OpenSolaris release. Although not GPL, I think that it's good enough to be included in Fedora Core, due to it's Mozilla Public Licence heritage diff at http://www.sun.com/cddl/CDDL_MPL_redline.pdf and FAQ at http://www.opensolaris.org/faq/licensing_faq.html and licence at http://www.opensolaris.org/license/cddl_license.txt. Cheers, Razvan From notting at redhat.com Tue Jun 7 18:17:06 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 7 Jun 2005 14:17:06 -0400 Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ In-Reply-To: <42A5E42C.5080602@linux360.ro> References: <19543506.1118090925521.JavaMail.root@wamui-milano.atl.sa.earthlink.net> <20050606205504.GB18562@nostromo.devel.redhat.com> <1118150696.4802.5.camel@bert64.mobile.smithconcepts.com> <20050607160935.GA4680@nostromo.devel.redhat.com> <42A5E1F5.6050209@linux360.ro> <20050607180808.GB5916@nostromo.devel.redhat.com> <42A5E42C.5080602@linux360.ro> Message-ID: <20050607181706.GC5916@nostromo.devel.redhat.com> Razvan Corneliu C.R. Vilt (razvan.vilt at linux360.ro) said: > Good point. But based on the docs on the internet, we could implement > something similar in functionality. They kinda had the same problems > that we are facing right now. I suspect that it should be soon covered > by the CDDL Licence, provided the imminent OpenSolaris release. Although > not GPL, I think that it's good enough to be included in Fedora Core, > due to it's Mozilla Public Licence heritage diff at > http://www.sun.com/cddl/CDDL_MPL_redline.pdf and FAQ at > http://www.opensolaris.org/faq/licensing_faq.html and licence at > http://www.opensolaris.org/license/cddl_license.txt. No, CDDL (like ASPL, actually) isn't a viable license for Fedora code. Bill From Brian.Edginton at ge.com Tue Jun 7 18:20:55 2005 From: Brian.Edginton at ge.com (Edginton, Brian (GE Healthcare)) Date: Tue, 07 Jun 2005 12:20:55 -0600 Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ In-Reply-To: <20050607181706.GC5916@nostromo.devel.redhat.com> References: <19543506.1118090925521.JavaMail.root@wamui-milano.atl.sa.earthlink.net> <20050606205504.GB18562@nostromo.devel.redhat.com> <1118150696.4802.5.camel@bert64.mobile.smithconcepts.com> <20050607160935.GA4680@nostromo.devel.redhat.com> <42A5E1F5.6050209@linux360.ro> <20050607180808.GB5916@nostromo.devel.redhat.com> <42A5E42C.5080602@linux360.ro> <20050607181706.GC5916@nostromo.devel.redhat.com> Message-ID: <1118168455.5221.0.camel@splitter.savi.med.ge.com> On Tue, 2005-06-07 at 14:17 -0400, Bill Nottingham wrote: > Razvan Corneliu C.R. Vilt (razvan.vilt at linux360.ro) said: > > Good point. But based on the docs on the internet, we could implement > > something similar in functionality. They kinda had the same problems > > that we are facing right now. I suspect that it should be soon covered > > by the CDDL Licence, provided the imminent OpenSolaris release. Although > > not GPL, I think that it's good enough to be included in Fedora Core, > > due to it's Mozilla Public Licence heritage diff at > > http://www.sun.com/cddl/CDDL_MPL_redline.pdf and FAQ at > > http://www.opensolaris.org/faq/licensing_faq.html and licence at > > http://www.opensolaris.org/license/cddl_license.txt. > > No, CDDL (like ASPL, actually) isn't a viable license for Fedora code. > > Bill > Bill, Specifics? -edge -------------- 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 kaboom at oobleck.net Tue Jun 7 18:23:27 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Tue, 7 Jun 2005 14:23:27 -0400 (EDT) Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ In-Reply-To: <20050607160935.GA4680@nostromo.devel.redhat.com> References: <19543506.1118090925521.JavaMail.root@wamui-milano.atl.sa.earthlink.net> <20050606205504.GB18562@nostromo.devel.redhat.com> <1118150696.4802.5.camel@bert64.mobile.smithconcepts.com> <20050607160935.GA4680@nostromo.devel.redhat.com> Message-ID: On Tue, 7 Jun 2005, Bill Nottingham wrote: > Bryan J. Smith (b.j.smith at ieee.org) said: > > On Mon, 2005-06-06 at 16:55 -0400, Bill Nottingham wrote: > > > Well, there are some plans here. They don't usually involve bash, > > > > Well, I'm half-way decent at system-level C (even some real-time > > experience), as well as Perl, but no Python though (one of these > > days). > > > > > though, and generally consist of migrating to a completely different > > > framework, with support for legacy installation concerns such > > > as LSB compatibility and the current init-style scripts. > > > > So the base won't be traditional System-V init? > > Correct. (Well, the core *init* under everything may or may not > change; but it certainly won't be the same interface from userland.) Is this going to be based on / similar to anything existing, or something new entirely? So far, everything you've said is sounding a *lot* like the redone services stuff in Solaris 10. The main difference would just be the use of D-BUS for communication rather than the Solaris-specific stuff SMF uses (svc.startd, mainly).... See for an overview of svcs, svcadm, svccfg, etc As an added benefit, the architecture Sun has for all this really has drastically reduced boot times (which I know is always a complaint people seem to have on Linux for some reason). Solaris 9 -> Solaris 10 went from ~3 minutes to ~25 seconds to boot (from the OBP to login prompt) on one of my workstations, for example later, chris From jspaleta at gmail.com Tue Jun 7 18:26:17 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 7 Jun 2005 14:26:17 -0400 Subject: Mirror monitor for meta data repos In-Reply-To: <42A5E0C4.4090703@sbcglobal.net> References: <42A5B7E5.5040707@sbcglobal.net> <604aa791050607091570d2d535@mail.gmail.com> <42A5D093.2080208@sbcglobal.net> <604aa791050607100717e0dcd1@mail.gmail.com> <42A5E0C4.4090703@sbcglobal.net> Message-ID: <604aa79105060711261dafbc5b@mail.gmail.com> On 6/7/05, david wrote: > Good heavens man, I just working on this a few hours ago. So as they > say, "The concrete ain't set up real firm yet." Easy, I'm just making suggestions I'm not throwing stones. You did ask for input. > Every time a master timestamp is changed all mirrors are immediately > reprobed to eliminate "the dreaded unknown state." I have concerns about how immediate 'immediately' means in practise. You will be probing some mirrors which are under heavy load or have reached their client connection limit. You have to account for some finite timeout and a mechanism to go back and re-attempt. Trust me.. first week of release you will run into overwhelmed mirrors because of both the people grabbing isos as well as people trying to get 0-day, 1-day, 5-day updates. And again when something like an important security update comes out some mirrors can get stressed again. How long is it going to take to successfully connect and probe 100 mirrors on release day or the day after release. There will most likely be some updates with in the first 24 hours. And some mirrors will reach their connection limit and you will have ot make repeated attempts to probe. You can't call these mirrors broken. Can you accurately distinguish broken mirrors from overwhelmed mirrors in the first week of release? > How would you feel if I stated the time since the last probe so user are > aware of that fact. Time since last probe.. as well as putting that mirror in the unverified state... would be good. I want to avoid situations where this summary generates erroneous mail to the mirror-admin. If this script can't probe because of too many clients for a 10 or even 24 hours, the mirror admin doesn't need to be contacted about that. Especially on release week... it could simply mean the mirror really is being heavily used and your script can't get a connection. -jef From notting at redhat.com Tue Jun 7 18:55:46 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 7 Jun 2005 14:55:46 -0400 Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ In-Reply-To: <1118168455.5221.0.camel@splitter.savi.med.ge.com> References: <19543506.1118090925521.JavaMail.root@wamui-milano.atl.sa.earthlink.net> <20050606205504.GB18562@nostromo.devel.redhat.com> <1118150696.4802.5.camel@bert64.mobile.smithconcepts.com> <20050607160935.GA4680@nostromo.devel.redhat.com> <42A5E1F5.6050209@linux360.ro> <20050607180808.GB5916@nostromo.devel.redhat.com> <42A5E42C.5080602@linux360.ro> <20050607181706.GC5916@nostromo.devel.redhat.com> <1118168455.5221.0.camel@splitter.savi.med.ge.com> Message-ID: <20050607185546.GB6389@nostromo.devel.redhat.com> Edginton, Brian (GE Healthcare) (Brian.Edginton at ge.com) said: > > No, CDDL (like ASPL, actually) isn't a viable license for Fedora code. > > Specifics? Just the hazy memory of a conversation I had. I'll try to dig up some. It's GPL-incompatible, of course. What could be done with it is the same thing that's done with launchd; look at the docs/manauls, see the general way it works, and go from there. But looking at the code and trying to reimplement it that way is right out. Bill From thebs413 at earthlink.net Tue Jun 7 19:00:00 2005 From: thebs413 at earthlink.net (Bryan J. Smith ) Date: Tue, 7 Jun 2005 14:00:00 -0500 (GMT-05:00) Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ Message-ID: <13047871.1118170800892.JavaMail.root@wamui-hound.atl.sa.earthlink.net> From: Bill Nottingham > Here ya go. Much appreciated! Looks like I've been a little more than ignorant on newer developments. I thought just a little start-time dependency checking here, and a little LSB compliance there was all that was being address. And I think I'll spend the next few days learning the D-BUS interfaces before commenting any more. Definitely agree that this is going to be a framework that has to be written in C. I'm fine there, love system-level stuff (although the same statement by Linus, "I wrote it in C, but some people might not call what I write C" probably applies even more so to me). Too bad about launchd being APSL. It's stuff like that, along with IBM CPL, IPL as well as Sun (insert our acronym today) that makes me wonder how people can demonize Red Hat, and praise Apple or IBM (at least we got StarOffice as LGPL from Sun). So, I take it Seth's SystemServices is probably going to get the nod at this point, since it looks like initng is one of those "are we there yet?" Correct me if I'm wrong. > Luke Macken (lmacken at redhat.com) may be looking at some of this > in the near future. As I said, I've got up to 10 hours/week to give assistance. I would be nice to see Red Hat leapfrog a lot of distros on the init, and set the standard for the next generation of Linux distros. > At first, I expect there to be very little UI code here; what's > needed is the framework. Yep, I got that from your forward. That is more in the future when the back-end is actually working. -- Bryan J. Smith mailto:b.j.smith at ieee.org From dfarning at sbcglobal.net Tue Jun 7 19:04:43 2005 From: dfarning at sbcglobal.net (david) Date: Tue, 07 Jun 2005 14:04:43 -0500 Subject: Mirror monitor for meta data repos In-Reply-To: <604aa79105060711261dafbc5b@mail.gmail.com> References: <42A5B7E5.5040707@sbcglobal.net> <604aa791050607091570d2d535@mail.gmail.com> <42A5D093.2080208@sbcglobal.net> <604aa791050607100717e0dcd1@mail.gmail.com> <42A5E0C4.4090703@sbcglobal.net> <604aa79105060711261dafbc5b@mail.gmail.com> Message-ID: <42A5EFCB.1050101@sbcglobal.net> Jeff Spaleta wrote: >On 6/7/05, david wrote: > > >>Good heavens man, I just working on this a few hours ago. So as they >>say, "The concrete ain't set up real firm yet." >> >> > >Easy, I'm just making suggestions I'm not throwing stones. You did ask >for input. > > > I should have put a little simley face after the above comment;) You best not be gettin' stones in my wet concrete;) >>Every time a master timestamp is changed all mirrors are immediately >>reprobed to eliminate "the dreaded unknown state." >> >> > >I have concerns about how immediate 'immediately' means in practise. >You will be probing some mirrors which are under heavy load or have >reached their client connection limit. You have to account for some >finite timeout and a mechanism to go back and re-attempt. Trust me.. >first week of release you will run into overwhelmed mirrors because of >both the people grabbing isos as well as people trying to get 0-day, >1-day, 5-day updates. And again when something like an important >security update comes out some mirrors can get stressed again. How >long is it going to take to successfully connect and probe 100 mirrors >on release day or the day after release. There will most likely be >some updates with in the first 24 hours. And some mirrors will reach >their connection limit and you will have ot make repeated attempts to >probe. You can't call these mirrors broken. Can you accurately >distinguish broken mirrors from overwhelmed mirrors in the first week >of release? > > You are taking this farther than I intended. This version is just a quick visual tool to see the general status of the mirror system. You are right about the above short comings, in future versions I would like createrepo to push a message to m3d to say that something has been updated. Then createrepo could call a tool that walks down the mirror list letting child tiers know that they need to sync. The children would then push a message to m3d that they are done syncing. Thus, allowing security release to be pushed rather than pulled through the system. But, that will require buyin from the build system as well as the mirrors. For now, I want focus on a tool that 1. Creates visability of the mirror system as a whole. 2. Allow the mirror master ( in this usage the master is the guy who keeps the mirror list up to date) to quickly inspect the overall state of the mirrors. 3. Create a single point of truth from which uptodate regional mirror lists can be automatically generated for use with yum. When the above three things start to fall into place. I'll start work on the push system. > > >>How would you feel if I stated the time since the last probe so user are >>aware of that fact. >> >> > >Time since last probe.. as well as putting that mirror in the >unverified state... would be good. I want to avoid situations where >this summary generates erroneous mail to the mirror-admin. If this >script can't probe because of too many clients for a 10 or even 24 >hours, the mirror admin doesn't need to be contacted about that. >Especially on release week... it could simply mean the mirror really >is being heavily used and your script can't get a connection. > > Good point, I will replace the term "mirror failure" with "probe failure." Note to self. "How and when to push information to mirrors?" Thanks for the input -dtf From mwiktowy at gmx.net Tue Jun 7 19:09:03 2005 From: mwiktowy at gmx.net (Michael Wiktowy) Date: Tue, 07 Jun 2005 15:09:03 -0400 Subject: Fedora Core 4 delayed until June 13 In-Reply-To: <1117829790.7091.12.camel@cutter> References: <20050603170242.GC6057@nostromo.devel.redhat.com> <1117829669.3355.9.camel@localhost.localdomain> <1117829790.7091.12.camel@cutter> Message-ID: <42A5F0CF.10502@gmx.net> seth vidal wrote: >On Fri, 2005-06-03 at 22:14 +0200, Kyrre Ness Sjobak wrote: > > >>fre, 03.06.2005 kl. 19.02 skrev Bill Nottingham: >> >> >>>Due to some unforseen complications, Fedora Core 4 is now >>>scheduled for general availability on June 13. We apologize for >>>the inconvenience. >>> >>>Bill >>> >>> >> >>What where the complications? >> >> >> > >vetting the name for the release through legal. > >not that anyone ever USES the name for anything, but hey, names are fun, >sorta. > >-sv > > If this is the case, do they have to go through the same release procedure for a nameless test release? If not, what is stopping the Fedora project from releasing a nameless release candidate immediately for a week of final bashing of installation/CD mastering and Extras integration issues? Supposedly, everything was all ready to go yesterday in a technical sense and this is just a legal delay. Doing an rc release and a short time later re-badging it as the final product is not unusual and could make for a more flawless final release. /Mike From fedora at camperquake.de Tue Jun 7 19:14:38 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 7 Jun 2005 21:14:38 +0200 Subject: Fedora Core 4 delayed until June 13 In-Reply-To: <42A5F0CF.10502@gmx.net> References: <20050603170242.GC6057@nostromo.devel.redhat.com> <1117829669.3355.9.camel@localhost.localdomain> <1117829790.7091.12.camel@cutter> <42A5F0CF.10502@gmx.net> Message-ID: <20050607211438.38777840@nausicaa.camperquake.de> Hi. Michael Wiktowy wrote: > Doing an rc release and a short time later re-badging it as the final > product is not unusual and could make for a more flawless final release. That's what the test releases are for. -- "...or you could just download NT Perl. OTOH, learning programming using perl is like learning chemistry using live grenades." -- Richard Watts From jkeating at j2solutions.net Tue Jun 7 19:15:44 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 07 Jun 2005 12:15:44 -0700 Subject: Fedora Core 4 delayed until June 13 In-Reply-To: <42A5F0CF.10502@gmx.net> References: <20050603170242.GC6057@nostromo.devel.redhat.com> <1117829669.3355.9.camel@localhost.localdomain> <1117829790.7091.12.camel@cutter> <42A5F0CF.10502@gmx.net> Message-ID: <1118171744.6416.39.camel@localhost.localdomain> On Tue, 2005-06-07 at 15:09 -0400, Michael Wiktowy wrote: > If this is the case, do they have to go through the same release > procedure for a nameless test release? > If not, what is stopping the Fedora project from releasing a nameless > release candidate immediately for a week of final bashing of > installation/CD mastering and Extras integration issues? > Supposedly, everything was all ready to go yesterday in a technical > sense and this is just a legal delay. > Doing an rc release and a short time later re-badging it as the final > product is not unusual and could make for a more flawless final > release. Because any changes would have to re-go through legal, and any changes will require more testing, etc... A lot of times it is easier to release what has already been approved and fix and prepare any last minute bugfixes for immediate updates. This is why you'll sometimes see updates available the day after a fedora release. -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- 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 nman64 at n-man.com Tue Jun 7 19:16:49 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Tue, 07 Jun 2005 14:16:49 -0500 Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ In-Reply-To: References: <19543506.1118090925521.JavaMail.root@wamui-milano.atl.sa.earthlink.net> <20050606205504.GB18562@nostromo.devel.redhat.com> <1118150696.4802.5.camel@bert64.mobile.smithconcepts.com> <20050607160935.GA4680@nostromo.devel.redhat.com> Message-ID: <42A5F2A1.10202@n-man.com> Chris Ricker wrote: >On Tue, 7 Jun 2005, Bill Nottingham wrote: > > > >>Bryan J. Smith (b.j.smith at ieee.org) said: >> >> >>>On Mon, 2005-06-06 at 16:55 -0400, Bill Nottingham wrote: >>> >>> >>>>Well, there are some plans here. They don't usually involve bash, >>>> >>>> >>>Well, I'm half-way decent at system-level C (even some real-time >>>experience), as well as Perl, but no Python though (one of these >>>days). >>> >>> >>> >>>>though, and generally consist of migrating to a completely different >>>>framework, with support for legacy installation concerns such >>>>as LSB compatibility and the current init-style scripts. >>>> >>>> >>>So the base won't be traditional System-V init? >>> >>> >>Correct. (Well, the core *init* under everything may or may not >>change; but it certainly won't be the same interface from userland.) >> >> > >Is this going to be based on / similar to anything existing, or something >new entirely? > >So far, everything you've said is sounding a *lot* like the redone >services stuff in Solaris 10. The main difference would just be the use of >D-BUS for communication rather than the Solaris-specific stuff SMF >uses (svc.startd, mainly).... > >See for an >overview of svcs, svcadm, svccfg, etc > >As an added benefit, the architecture Sun has for all this really has >drastically reduced boot times (which I know is always a complaint people >seem to have on Linux for some reason). Solaris 9 -> Solaris 10 went from >~3 minutes to ~25 seconds to boot (from the OBP to login prompt) on one of >my workstations, for example > >later, >chris > > > It will probably be a new implementation, but might contain code or ideas from existing projects. See the (new) wiki page at http://fedoraproject.org/wiki/FCNewInit for an outline of what's on the table. -- Patrick "The N-Man" Barnes nman64 at n-man.com www.n-man.com -- -------------- 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 redhat.com Tue Jun 7 19:21:45 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 08 Jun 2005 00:51:45 +0530 Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ In-Reply-To: <42A5F2A1.10202@n-man.com> References: <19543506.1118090925521.JavaMail.root@wamui-milano.atl.sa.earthlink.net> <20050606205504.GB18562@nostromo.devel.redhat.com> <1118150696.4802.5.camel@bert64.mobile.smithconcepts.com> <20050607160935.GA4680@nostromo.devel.redhat.com> <42A5F2A1.10202@n-man.com> Message-ID: <42A5F3C9.8000702@redhat.com> Hi > > It will probably be a new implementation, but might contain code or > ideas from existing projects. > > See the (new) wiki page at http://fedoraproject.org/wiki/FCNewInit for > an outline of what's on the table. Err, thats just a copy of the email from Bill that I posted into the wiki for reference regards Rahul From razvan.vilt at linux360.ro Tue Jun 7 19:21:47 2005 From: razvan.vilt at linux360.ro (Razvan Corneliu C.R. Vilt) Date: Tue, 07 Jun 2005 22:21:47 +0300 Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ In-Reply-To: <20050607185546.GB6389@nostromo.devel.redhat.com> References: <19543506.1118090925521.JavaMail.root@wamui-milano.atl.sa.earthlink.net> <20050606205504.GB18562@nostromo.devel.redhat.com> <1118150696.4802.5.camel@bert64.mobile.smithconcepts.com> <20050607160935.GA4680@nostromo.devel.redhat.com> <42A5E1F5.6050209@linux360.ro> <20050607180808.GB5916@nostromo.devel.redhat.com> <42A5E42C.5080602@linux360.ro> <20050607181706.GC5916@nostromo.devel.redhat.com> <1118168455.5221.0.camel@splitter.savi.med.ge.com> <20050607185546.GB6389@nostromo.devel.redhat.com> Message-ID: <42A5F3CB.4050505@linux360.ro> Bill Nottingham wrote: >Edginton, Brian (GE Healthcare) (Brian.Edginton at ge.com) said: > > >>>No, CDDL (like ASPL, actually) isn't a viable license for Fedora code. >>> >>> >> Specifics? >> >> > >Just the hazy memory of a conversation I had. I'll try to dig up >some. > >It's GPL-incompatible, of course. > >What could be done with it is the same thing that's done with >launchd; look at the docs/manauls, see the general way it works, >and go from there. But looking at the code and trying to reimplement >it that way is right out. > >Bill > > > That reminds me. What are we to do regarding the network scripts? Bug 145464 (gre scripts) springs in my mind right now. We have two separate issues. The lack of network scripts for stuff like gre/ipip and many others. How should this be integrated in the new init stuff. Like a service or lower-level (rc.sysinit style but in the new init would probably be in C) ? I purpose that a new wiki page should be set-up for this. It's the only place where only the ideas remain and not the eventual flames that a thread might contain. As a bonus it can be better organised, thus easier to read than the email archives. Razvan From razvan.vilt at linux360.ro Tue Jun 7 19:23:24 2005 From: razvan.vilt at linux360.ro (Razvan Corneliu C.R. Vilt) Date: Tue, 07 Jun 2005 22:23:24 +0300 Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ In-Reply-To: <42A5F3CB.4050505@linux360.ro> References: <19543506.1118090925521.JavaMail.root@wamui-milano.atl.sa.earthlink.net> <20050606205504.GB18562@nostromo.devel.redhat.com> <1118150696.4802.5.camel@bert64.mobile.smithconcepts.com> <20050607160935.GA4680@nostromo.devel.redhat.com> <42A5E1F5.6050209@linux360.ro> <20050607180808.GB5916@nostromo.devel.redhat.com> <42A5E42C.5080602@linux360.ro> <20050607181706.GC5916@nostromo.devel.redhat.com> <1118168455.5221.0.camel@splitter.savi.med.ge.com> <20050607185546.GB6389@nostromo.devel.redhat.com> <42A5F3CB.4050505@linux360.ro> Message-ID: <42A5F42C.700@linux360.ro> > That reminds me. What are we to do regarding the network scripts? Bug > 145464 (gre scripts) springs in my mind right now. We have two > separate issues. The lack of network scripts for stuff like gre/ipip > and many others. How should this be integrated in the new init stuff. > Like a service or lower-level (rc.sysinit style but in the new init > would probably be in C) ? > > I purpose that a new wiki page should be set-up for this. It's the > only place where only the ideas remain and not the eventual flames > that a thread might contain. As a bonus it can be better organised, > thus easier to read than the email archives. > > Razvan > Geez, are you people fast. You've already set-up the wiki. From nman64 at n-man.com Tue Jun 7 19:30:13 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Tue, 07 Jun 2005 14:30:13 -0500 Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ In-Reply-To: <42A5F3C9.8000702@redhat.com> References: <19543506.1118090925521.JavaMail.root@wamui-milano.atl.sa.earthlink.net> <20050606205504.GB18562@nostromo.devel.redhat.com> <1118150696.4802.5.camel@bert64.mobile.smithconcepts.com> <20050607160935.GA4680@nostromo.devel.redhat.com> <42A5F2A1.10202@n-man.com> <42A5F3C9.8000702@redhat.com> Message-ID: <42A5F5C5.3070507@n-man.com> Rahul Sundaram wrote: > Hi > >> >> It will probably be a new implementation, but might contain code or >> ideas from existing projects. >> >> See the (new) wiki page at http://fedoraproject.org/wiki/FCNewInit for >> an outline of what's on the table. > > > > Err, thats just a copy of the email from Bill that I posted into the > wiki for reference > > regards > Rahul > It's a good starting point at least. It quite well sums up the overall results of this discussion thus far. -- Patrick "The N-Man" Barnes nman64 at n-man.com www.n-man.com -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From thebs413 at earthlink.net Tue Jun 7 19:32:26 2005 From: thebs413 at earthlink.net (Bryan J. Smith ) Date: Tue, 7 Jun 2005 14:32:26 -0500 (GMT-05:00) Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ Message-ID: <22886775.1118172746704.JavaMail.root@wamui-hound.atl.sa.earthlink.net> From: Bill Nottingham > Just the hazy memory of a conversation I had. I'll try to dig up > some. It's GPL-incompatible, of course. > What could be done with it is the same thing that's done with > launchd; look at the docs/manauls, see the general way it works, > and go from there. But looking at the code and trying to reimplement > it that way is right out. I have to completely agree with Bill. You can't just GPL something (other than BSD and rare other exceptions), and I'm 100% in agreement with Red Hat on keeping everything GPL. With that said, has anyone approached Sun about dual-licensing SMF? If they are open to it, great. If not, then don't even bother looking at it (let alone avoid the code!). [ Professional Side Note: One of the reasons I have not done much Java other than required (largely in the financial industry) is because of not only the license of it, but most of the libraries -- even IBM's (which are no better). It's also the reason I'm a huge fan of Mono's GPL/LGPL/BSD compiler/library/classlibs. ] -- Bryan J. Smith mailto:b.j.smith at ieee.org From nman64 at n-man.com Tue Jun 7 19:32:22 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Tue, 07 Jun 2005 14:32:22 -0500 Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ In-Reply-To: <42A5F42C.700@linux360.ro> References: <19543506.1118090925521.JavaMail.root@wamui-milano.atl.sa.earthlink.net> <20050606205504.GB18562@nostromo.devel.redhat.com> <1118150696.4802.5.camel@bert64.mobile.smithconcepts.com> <20050607160935.GA4680@nostromo.devel.redhat.com> <42A5E1F5.6050209@linux360.ro> <20050607180808.GB5916@nostromo.devel.redhat.com> <42A5E42C.5080602@linux360.ro> <20050607181706.GC5916@nostromo.devel.redhat.com> <1118168455.5221.0.camel@splitter.savi.med.ge.com> <20050607185546.GB6389@nostromo.devel.redhat.com> <42A5F3CB.4050505@linux360.ro> <42A5F42C.700@linux360.ro> Message-ID: <42A5F646.9000105@n-man.com> Razvan Corneliu C.R. Vilt wrote: > >> That reminds me. What are we to do regarding the network scripts? Bug >> 145464 (gre scripts) springs in my mind right now. We have two >> separate issues. The lack of network scripts for stuff like gre/ipip >> and many others. How should this be integrated in the new init stuff. >> Like a service or lower-level (rc.sysinit style but in the new init >> would probably be in C) ? >> >> I purpose that a new wiki page should be set-up for this. It's the >> only place where only the ideas remain and not the eventual flames >> that a thread might contain. As a bonus it can be better organised, >> thus easier to read than the email archives. >> >> Razvan >> > Geez, are you people fast. You've already set-up the wiki. > ...and Bill has already prettied it up a bit. ;-) -- Patrick "The N-Man" Barnes nman64 at n-man.com www.n-man.com -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From notting at redhat.com Tue Jun 7 19:38:13 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 7 Jun 2005 15:38:13 -0400 Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ In-Reply-To: <42A5F3CB.4050505@linux360.ro> References: <20050606205504.GB18562@nostromo.devel.redhat.com> <1118150696.4802.5.camel@bert64.mobile.smithconcepts.com> <20050607160935.GA4680@nostromo.devel.redhat.com> <42A5E1F5.6050209@linux360.ro> <20050607180808.GB5916@nostromo.devel.redhat.com> <42A5E42C.5080602@linux360.ro> <20050607181706.GC5916@nostromo.devel.redhat.com> <1118168455.5221.0.camel@splitter.savi.med.ge.com> <20050607185546.GB6389@nostromo.devel.redhat.com> <42A5F3CB.4050505@linux360.ro> Message-ID: <20050607193813.GA6834@nostromo.devel.redhat.com> Razvan Corneliu C.R. Vilt (razvan.vilt at linux360.ro) said: > That reminds me. What are we to do regarding the network scripts? Bug > 145464 (gre scripts) springs in my mind right now. We have two separate > issues. The lack of network scripts for stuff like gre/ipip and many > others. How should this be integrated in the new init stuff. Like a > service or lower-level (rc.sysinit style but in the new init would > probably be in C) ? Eventually? All the networking scripts go away and are replaced with calls into NetworkManager. :) Bill From kaboom at oobleck.net Tue Jun 7 19:45:56 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Tue, 7 Jun 2005 15:45:56 -0400 (EDT) Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ In-Reply-To: <22886775.1118172746704.JavaMail.root@wamui-hound.atl.sa.earthlink.net> References: <22886775.1118172746704.JavaMail.root@wamui-hound.atl.sa.earthlink.net> Message-ID: On Tue, 7 Jun 2005, Bryan J. Smith wrote: > I have to completely agree with Bill. > > You can't just GPL something (other than BSD and rare other exceptions), > and I'm 100% in agreement with Red Hat on keeping everything GPL. > > With that said, has anyone approached Sun about dual-licensing SMF? > If they are open to it, great. If not, then don't even bother looking at > it (let alone avoid the code!). > > [ Professional Side Note: > One of the reasons I have not done much Java other than required (largely > in the financial industry) is because of not only the license of it, but > most of the libraries -- even IBM's (which are no better). It's also the > reason I'm a huge fan of Mono's GPL/LGPL/BSD compiler/library/classlibs. ] Note that the CDDL (which is what Sun uses for Solaris code, presumably including SMF, when the OpenSolaris code finally is released) is not at all the same as the Sun Community Source License (the Sun Java license) The CDDL is basically like the Mozilla license. It's not compatible with the GPL in that you can't link code licensed GPL and code licensed CDDL together (due to the terms of the GPL), but other than that, its OSI-approved, free software, redistributable, etc. later, chris From richardl at redhat.com Tue Jun 7 19:50:16 2005 From: richardl at redhat.com (Richard Li) Date: Tue, 07 Jun 2005 15:50:16 -0400 Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ In-Reply-To: <22886775.1118172746704.JavaMail.root@wamui-hound.atl.sa.earthlink.net> References: <22886775.1118172746704.JavaMail.root@wamui-hound.atl.sa.earthlink.net> Message-ID: <42A5FA78.4060005@redhat.com> >One of the reasons I have not done much Java other than required (largely >in the financial industry) is because of not only the license of it, but >most of the libraries -- even IBM's (which are no better). It's also the >reason I'm a huge fan of Mono's GPL/LGPL/BSD compiler/library/classlibs. ] > > Classpath and gcj are GPL. They have also made enormous strides in stability, performance, and completeness as of late (cf OpenOffice, Jonas). From razvan.vilt at linux360.ro Tue Jun 7 19:55:06 2005 From: razvan.vilt at linux360.ro (Razvan Corneliu C.R. "d3vi1" VILT) Date: Tue, 07 Jun 2005 22:55:06 +0300 Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ In-Reply-To: <20050607193813.GA6834@nostromo.devel.redhat.com> References: <20050606205504.GB18562@nostromo.devel.redhat.com> <1118150696.4802.5.camel@bert64.mobile.smithconcepts.com> <20050607160935.GA4680@nostromo.devel.redhat.com> <42A5E1F5.6050209@linux360.ro> <20050607180808.GB5916@nostromo.devel.redhat.com> <42A5E42C.5080602@linux360.ro> <20050607181706.GC5916@nostromo.devel.redhat.com> <1118168455.5221.0.camel@splitter.savi.med.ge.com> <20050607185546.GB6389@nostromo.devel.redhat.com> <42A5F3CB.4050505@linux360.ro> <20050607193813.GA6834@nostromo.devel.redhat.com> Message-ID: <1118174106.19602.2.camel@d3vi1.linux360.ro> On Tue, 2005-06-07 at 15:38 -0400, Bill Nottingham wrote: > Eventually? > > All the networking scripts go away and are replaced with calls > into NetworkManager. :) Thank god. But... Where does that leave the gre bug? Not to mention that, although it's quite a nice thing, NetworkManager screwed up totally for me a couple of times. It started the dhcp daemon instead of taking that damned static ip address. But those are bugs and will be solved by the time we actually do this. > Bill Razvan -------------- next part -------------- An HTML attachment was scrubbed... URL: From felipe.alfaro at gmail.com Tue Jun 7 19:57:10 2005 From: felipe.alfaro at gmail.com (Felipe Alfaro Solana) Date: Tue, 7 Jun 2005 21:57:10 +0200 Subject: Wish list In-Reply-To: <1118093019.2468.42.camel@cutter> References: <1118002724.9556.34.camel@Darkstar> <42A36449.80509@n-man.com> <1118043525.5652.9.camel@laptopd505.fenrus.org> <42A4BE05.9060105@poolshark.org> <1118093019.2468.42.camel@cutter> Message-ID: <6f6293f105060712576a17cde0@mail.gmail.com> On 6/6/05, seth vidal wrote: > > > > > > well the moment you use the (probably illegal) nvidia binary drivers you > > > gave up all advantages of open source already. Especially on the > > > security front, binary drivers have a really bad reputation and history > > > there. > > > > People love Fedora, and people love Nvidia drivers. Both for good reasons. > > You'll have to accept that eventually, instead of systematically bad-mouthing > > every person that brings up Nvidia issues on this mailing list. > > He's not bad-mouthing the person. He's bad-mouthing the driver. > > And he's hardly doing it systematically. > > seriously - nvidia drivers being bad for your system is not new. You > should have seen this before. Don't see why they can be bad for my system: I've never had problems with them (even when CONFIG_PREEMPT and CONFIG_4K_STACKS), have been using them for more than 3 months with all unstable/testing kernel releases up to 2.6.12-rc6 and performance is exceptional with them loaded. From razvan.vilt at linux360.ro Tue Jun 7 20:10:53 2005 From: razvan.vilt at linux360.ro (Razvan Corneliu C.R. "d3vi1" VILT) Date: Tue, 07 Jun 2005 23:10:53 +0300 Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ In-Reply-To: <22886775.1118172746704.JavaMail.root@wamui-hound.atl.sa.earthlink.net> References: <22886775.1118172746704.JavaMail.root@wamui-hound.atl.sa.earthlink.net> Message-ID: <1118175054.19602.10.camel@d3vi1.linux360.ro> On Tue, 2005-06-07 at 14:32 -0500, Bryan J. Smith wrote: > From: Bill Nottingham > > Just the hazy memory of a conversation I had. I'll try to dig up > > some. It's GPL-incompatible, of course. > > What could be done with it is the same thing that's done with > > launchd; look at the docs/manauls, see the general way it works, > > and go from there. But looking at the code and trying to reimplement > > it that way is right out. > > I have to completely agree with Bill. Me too. I never said anything related to including something that is incompatible with Fedora license guidelines. But it's a piece of software that was created from the same problems that we have right now. It has compatibility with sysvinit scripts adn stuff like that. > You can't just GPL something (other than BSD and rare other exceptions), > and I'm 100% in agreement with Red Hat on keeping everything GPL. If you take a look at the packages included in Red Hat Enterprise Linux and Fedora Core, you'll see that not all of them are GPL. Give OpenSSL and Apache a look. > With that said, has anyone approached Sun about dual-licensing SMF? > If they are open to it, great. If not, then don't even bother looking at > it (let alone avoid the code!). Should we also exclude Mozilla and Gecko derivatives on that same thinking? CDDL is a simplified Mozilla Public License (see my previous email with the diff). > [ Professional Side Note: > One of the reasons I have not done much Java other than required (largely > in the financial industry) is because of not only the license of it, but > most of the libraries -- even IBM's (which are no better). It's also the > reason I'm a huge fan of Mono's GPL/LGPL/BSD compiler/library/classlibs. ] You love their license but you're willing to take the Intellectual Property risks upon your shoulders? The license is so important to you but the fact that the license might not be valid is not? Weird. Cheers, R?zvan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jspaleta at gmail.com Tue Jun 7 20:14:13 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 7 Jun 2005 16:14:13 -0400 Subject: Mirror monitor for meta data repos In-Reply-To: <42A5EFCB.1050101@sbcglobal.net> References: <42A5B7E5.5040707@sbcglobal.net> <604aa791050607091570d2d535@mail.gmail.com> <42A5D093.2080208@sbcglobal.net> <604aa791050607100717e0dcd1@mail.gmail.com> <42A5E0C4.4090703@sbcglobal.net> <604aa79105060711261dafbc5b@mail.gmail.com> <42A5EFCB.1050101@sbcglobal.net> Message-ID: <604aa791050607131426a5742d@mail.gmail.com> On 6/7/05, david wrote: > You are right about the above short comings, in future versions I would > like createrepo to push a message to m3d to say that something has > been updated. Then createrepo could call a tool that walks down the > mirror list letting child tiers know that they need to sync. The > children would then push a message to m3d that they are done syncing. While a noble idea... i'm not sure a lot of the official mirrors are going to be thrilled about running an additional service on their mirrors to listen to that push. I think you need to gauge how many current mirrors are interested in running an additional service to before you think about that push system too much. It's technically feasible.. but I'm just not sure if its going to be popular with the current mirror admins, if it means another service to setup and babysit. If only 5% of the mirrors are willing to run an additional service to handle that centralized push, its sort of a non-starter. Maybe some mirror admins lurking on this list can weight in as to the political feasibility for adoption of any push system. Unless something has changed, I don't think the mirrors are organized into a several tier system. And if there is a tiered system in place right now for mirrors, the system you want to create could end up driving users to the higher tier servers that get the updates first, defeating the point of tiering. > For now, I want focus on a tool that > 1. Creates visability of the mirror system as a whole. > 2. Allow the mirror master ( in this usage the master is the guy who > keeps the mirror list up to date) to quickly inspect the overall state > of the mirrors. Hmm.. if you are talking about the centralized mirrorlists at fedora.redhat.com... I'm not sure who the right person to talk to is. Let's see if I can taunt them into expressing an opinion as to your approach as a follow up to this thread. > 3. Create a single point of truth from which uptodate regional mirror > lists can be automatically generated for use with yum. Truth is subjective. And if you aren't careful you can end up having this tool generate very small mirrorlists which point people to just a few quickly updated mirrors and end up driving too much traffic to the first mirrors who happen to catch an update.. causing client connection failures when those quickly updated mirrors max their connected clients. How often do most official mirrors attempt to rsync with the master now? If they only do it once an hour you shouldn't probe more often than about 2 hours realistically or else you just might happen to probe just after the master mirror syncs before any mirror's own rsync script has fired. > Good point, I will replace the term "mirror failure" with "probe failure." > There can be mirror failures... but i think you have to wait for a mirror to go missing for a few days straight before you can distinguish in the case of too many connection errors. Can your script tell the difference between error states handed back from the server? Don't you get different messages back from the server if the server is full instead of down? Or when the directory is not there or you dont have permissions to access the directory? I'm still interested to watch how long it takes for you to do a full run on a heavy load day with updates like the day after a release. Hey look there is one right around the corner. Hopefully you'll do a few timed runs of that 200+ mirror update check in that 48 period after release and get a better feel for how bad it can get and show me my concerns are completely unjustified. -jef From seandarcy2 at gmail.com Tue Jun 7 20:14:56 2005 From: seandarcy2 at gmail.com (sean) Date: Tue, 07 Jun 2005 16:14:56 -0400 Subject: jade looks for docbook/dtd/xml/4.2/docbookx.dtd ?? In-Reply-To: <20050607081558.GP8706@redhat.com> References: <20050607081558.GP8706@redhat.com> Message-ID: Tim Waugh wrote: > On Mon, Jun 06, 2005 at 08:14:29PM -0400, sean wrote: > > >>I'm using db2html to build the gutenprint docs. But: >> >>/usr/bin/db2html gutenprint.xml >>output is gutenprint >>Using catalogs: /etc/sgml/xml-docbook-4.2-1.0-27.cat > > > This catalog gives the correct path for the PUBLIC "-//OASIS//DTD > DocBook XML V4.2//EN" DTD. > > >>Using stylesheet: >>/usr/share/sgml/docbook/utils-0.6.14/docbook-utils.dsl#html >>Working on: >>/usr/src/redhat/BUILD/print/doc/developer/gutenprint.xml >>jade:/usr/src/redhat/BUILD/print/doc/developer/gutenprint.xml:13:0:E: >>cannot open >>"/usr/share/sgml/docbook/dtd/xml/4.2/docbookx.dtd" (No such >>file or directory) > > > Unfortunately gutenprint.xml uses a hard-coded path, which is not > guaranteed to work on anyone's system except the author's. The > !DOCTYPE at the top of the document should not use SYSTEM > "/usr/share/sgml/..." but the PUBLIC ID above. > Thanks for the quick response. I just deleted the hard-coded path from gutenprint.xml and it built. I've sent a note to the devel list. sean From seanlkml at sympatico.ca Tue Jun 7 20:41:16 2005 From: seanlkml at sympatico.ca (Sean) Date: Tue, 7 Jun 2005 16:41:16 -0400 (EDT) Subject: OT: nVidia driver [was: Wish list] In-Reply-To: <6f6293f105060712576a17cde0@mail.gmail.com> References: <1118002724.9556.34.camel@Darkstar> <42A36449.80509@n-man.com> <1118043525.5652.9.camel@laptopd505.fenrus.org> <42A4BE05.9060105@poolshark.org> <1118093019.2468.42.camel@cutter> <6f6293f105060712576a17cde0@mail.gmail.com> Message-ID: <3609.10.10.10.24.1118176876.squirrel@linux1> On Tue, June 7, 2005 3:57 pm, Felipe Alfaro Solana said: > > Don't see why they can be bad for my system: I've never had problems with > them (even when CONFIG_PREEMPT and CONFIG_4K_STACKS), have been using them > for more than 3 months with all unstable/testing kernel releases up to > 2.6.12-rc6 and performance is exceptional with them loaded. People should probably take the word of those who have been bringing Linux to the world for many years over someone who has been experimenting for 3 months. For anyone with valuable data on their system, it's very bad advice to go anywhere near binary drivers. For those with nothing worthwhile on their system, and no concept of how and why Linux was created, go nuts. Sean From dfarning at sbcglobal.net Tue Jun 7 20:49:41 2005 From: dfarning at sbcglobal.net (david) Date: Tue, 07 Jun 2005 15:49:41 -0500 Subject: Mirror monitor for meta data repos In-Reply-To: <604aa791050607131426a5742d@mail.gmail.com> References: <42A5B7E5.5040707@sbcglobal.net> <604aa791050607091570d2d535@mail.gmail.com> <42A5D093.2080208@sbcglobal.net> <604aa791050607100717e0dcd1@mail.gmail.com> <42A5E0C4.4090703@sbcglobal.net> <604aa79105060711261dafbc5b@mail.gmail.com> <42A5EFCB.1050101@sbcglobal.net> <604aa791050607131426a5742d@mail.gmail.com> Message-ID: <42A60865.4070803@sbcglobal.net> Jeff Spaleta wrote: >I'm still interested to watch how long it takes for you to do a full >run on a heavy load day with updates like the day after a release. Hey >look there is one right around the corner. Hopefully you'll do a few >timed runs of that 200+ mirror update check in that 48 period after >release and get a better feel for how bad it can get and show me my >concerns are completely unjustified. > >-jef > > > Ah good, a dead line. I'll run the test you are talking about around release time. In the mean time, I am setting up a web site to post my results. -dtf From thebs413 at earthlink.net Tue Jun 7 20:59:45 2005 From: thebs413 at earthlink.net (Bryan J. Smith ) Date: Tue, 7 Jun 2005 15:59:45 -0500 (GMT-05:00) Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ Message-ID: <21396121.1118177985907.JavaMail.root@wamui-cypress.atl.sa.earthlink.net> From: "Razvan Corneliu C.R. \"d3vi1\" VILT" > If you take a look at the packages included in Red Hat Enterprise Linux > and Fedora Core, you'll see that not all of them are GPL. Give OpenSSL > and Apache a look. OpenSSL _is_ a BSD-style license and GPL compatible. It, like most other core components, libraries and functionality in Debian and Fedora distributions are GPL or at least "GPL compatible." Apache is an end-user service outside of the core components, libraries and functionality and it doesn't quite have to be GPL compatible. If something it going to go into init, IMHO, it had better be GPL or at least GPL compatible. > Should we also exclude Mozilla and Gecko derivatives on that same > thinking? For core components, libraries and functionality? Yes! But for end-user services or applications, no. > CDDL is a simplified Mozilla Public License (see my previous > email with the diff). Yes, I know. I've even written code for dual-GPL/MPL projects. But when you're talking the _core_init_ -- hell no. ;-> > You love their license but you're willing to take the Intellectual > Property risks upon your shoulders? The license is so important to you > but the fact that the license might not be valid is not? Weird. Because IP has to be proven to make you subject to them. Novell/Mono has an "exit strategy" to an EMCA-compliant version. And HP and Intel are big backers of the BSD class libraries. But you have _no_excuse_ for violating a license. You are at the mercy of the copyright holder when you violate a license. And given all that, there are IP issues with Java too. -- Bryan J. Smith mailto:b.j.smith at ieee.org From felipe.alfaro at gmail.com Tue Jun 7 21:04:28 2005 From: felipe.alfaro at gmail.com (Felipe Alfaro Solana) Date: Tue, 7 Jun 2005 23:04:28 +0200 Subject: OT: nVidia driver [was: Wish list] In-Reply-To: <3609.10.10.10.24.1118176876.squirrel@linux1> References: <1118002724.9556.34.camel@Darkstar> <42A36449.80509@n-man.com> <1118043525.5652.9.camel@laptopd505.fenrus.org> <42A4BE05.9060105@poolshark.org> <1118093019.2468.42.camel@cutter> <6f6293f105060712576a17cde0@mail.gmail.com> <3609.10.10.10.24.1118176876.squirrel@linux1> Message-ID: <6f6293f1050607140420024cc8@mail.gmail.com> On 6/7/05, Sean wrote: > On Tue, June 7, 2005 3:57 pm, Felipe Alfaro Solana said: > > Don't see why they can be bad for my system: I've never had problems with > > them (even when CONFIG_PREEMPT and CONFIG_4K_STACKS), have been using them > > for more than 3 months with all unstable/testing kernel releases up to > > 2.6.12-rc6 and performance is exceptional with them loaded. > > People should probably take the word of those who have been bringing Linux > to the world for many years over someone who has been experimenting for 3 > months. I wasn't trying to take away the credit that Linux kernel developers deserve. I was simply stating my personal experience with nVidia propietary drivers, nothing else. From cmadams at hiwaay.net Tue Jun 7 21:09:52 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 7 Jun 2005 16:09:52 -0500 Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ In-Reply-To: <21396121.1118177985907.JavaMail.root@wamui-cypress.atl.sa.earthlink.net> References: <21396121.1118177985907.JavaMail.root@wamui-cypress.atl.sa.earthlink.net> Message-ID: <20050607210952.GD1189481@hiwaay.net> Once upon a time, Bryan J. Smith said: > OpenSSL _is_ a BSD-style license and GPL compatible. The OpenSSL license is an old-style BSD type license with the advertising clause, which I understand to be incompatible with the GPL. That's part of why some programs are moving to the (LGPLed) GNU TLS library instead. > If something it going to go into init, IMHO, it had better be GPL or at > least GPL compatible. If it requires random services to link or include the code, it should probably be BSD (non-advertising clause). Otherwise, things like Oracle won't be able to start at boot. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From thebs413 at earthlink.net Tue Jun 7 21:14:33 2005 From: thebs413 at earthlink.net (Bryan J. Smith ) Date: Tue, 7 Jun 2005 16:14:33 -0500 (GMT-05:00) Subject: Java and Mono Licensing -- WAS: Fedora Goals Message-ID: <18895992.1118178873484.JavaMail.root@wamui-cypress.atl.sa.earthlink.net> From: Richard Li > Classpath and gcj are GPL. They have also made enormous strides in > stability, performance, and completeness as of late (cf OpenOffice, Jonas). Yes, I've been tracking that as well. It was a pleasant surprise to see. While a lot of people have been complaining about it, Red Hat and other developers are actually solving the issues. I sincerely hope that it will reach the point where you can take just about any, major Java code, and target both the Java byte code and native byte with gcj, as well as AWT/Swing with Classpath. I'll have to bring myself up-to-speed on those developments. Otherwise, I had been going down the Mono route because I very much like the GPL/LPGL/BSD Compiler/Library/Class Library combo. It allows you to license under whatever you want, GPL, MIT, etc... And I'm somewhat of a GTK+/GTK# fan for cross-platform development. Swing is good, but has left much to be desired IMHO. -- Bryan J. Smith mailto:b.j.smith at ieee.org From brugolsky at telemetry-investments.com Tue Jun 7 21:31:44 2005 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Tue, 7 Jun 2005 17:31:44 -0400 Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ In-Reply-To: <20050607180417.GA5916@nostromo.devel.redhat.com> References: <25326487.1118164779912.JavaMail.root@wamui-norfolk.atl.sa.earthlink.net> <20050607180417.GA5916@nostromo.devel.redhat.com> Message-ID: <20050607213143.GA29448@ti64.telemetry-investments.com> On Tue, Jun 07, 2005 at 02:04:17PM -0400, Bill Nottingham wrote: > - Support for respawning services, if necessary. Complete with rate > limits and other fun stuff. Looking ahead, it would be useful to design the service monitoring and restart mechanisms with HA failover support in mind. Bill Rugolsky From matthew at nocturnal.org Tue Jun 7 21:38:10 2005 From: matthew at nocturnal.org (Matthew Lenz) Date: Tue, 07 Jun 2005 16:38:10 -0500 Subject: OT: nVidia driver [was: Wish list] In-Reply-To: <3609.10.10.10.24.1118176876.squirrel@linux1> References: <1118002724.9556.34.camel@Darkstar> <42A36449.80509@n-man.com> <1118043525.5652.9.camel@laptopd505.fenrus.org> <42A4BE05.9060105@poolshark.org> <1118093019.2468.42.camel@cutter> <6f6293f105060712576a17cde0@mail.gmail.com> <3609.10.10.10.24.1118176876.squirrel@linux1> Message-ID: <1118180290.7742.73.camel@mlenzdesktop> On Tue, 2005-06-07 at 16:41 -0400, Sean wrote: > On Tue, June 7, 2005 3:57 pm, Felipe Alfaro Solana said: > > > > > Don't see why they can be bad for my system: I've never had problems with > > them (even when CONFIG_PREEMPT and CONFIG_4K_STACKS), have been using them > > for more than 3 months with all unstable/testing kernel releases up to > > 2.6.12-rc6 and performance is exceptional with them loaded. > > People should probably take the word of those who have been bringing Linux > to the world for many years over someone who has been experimenting for 3 > months. > For anyone with valuable data on their system, it's very bad advice to go > anywhere near binary drivers. For those with nothing worthwhile on their > system, and no concept of how and why Linux was created, go nuts. > > Sean > > The people who bring linux to the world need to stop bitching about Nvidia who is the only game in town when it comes to commercial quality video drivers for linux. I've used Nvidia's binaries since they were first released on dozens of systems running dozens of different kernels and 4 generations of nvidia chipsets. Never ONCE has their driver caused instability in these systems. Nvidia is way off topic on this board anyway. People should ask nvidia for support not the OS developers. That is why they have a bulletin board for asking questions and why they have a support email address on their site. Next time someone posts having problems with the driver send em to nvidia's site. Done. From seanlkml at sympatico.ca Tue Jun 7 21:53:12 2005 From: seanlkml at sympatico.ca (Sean) Date: Tue, 7 Jun 2005 17:53:12 -0400 (EDT) Subject: OT: nVidia driver [was: Wish list] In-Reply-To: <1118180290.7742.73.camel@mlenzdesktop> References: <1118002724.9556.34.camel@Darkstar> <42A36449.80509@n-man.com> <1118043525.5652.9.camel@laptopd505.fenrus.org> <42A4BE05.9060105@poolshark.org> <1118093019.2468.42.camel@cutter> <6f6293f105060712576a17cde0@mail.gmail.com> <3609.10.10.10.24.1118176876.squirrel@linux1> <1118180290.7742.73.camel@mlenzdesktop> Message-ID: <3186.10.10.10.24.1118181192.squirrel@linux1> On Tue, June 7, 2005 5:38 pm, Matthew Lenz said: > The people who bring linux to the world need to stop bitching about > Nvidia who is the only game in town when it comes to commercial quality > video drivers for linux. I've used Nvidia's binaries since they were > first released on dozens of systems running dozens of different kernels > and 4 generations of nvidia chipsets. Never ONCE has their driver > caused instability in these systems. No, the people who use Linux for free without a clue should wake up and listen to the people who created the bloody OS instead of agnostic johnny-come-lately's. > Nvidia is way off topic on this board anyway. People should ask nvidia > for support not the OS developers. That is why they have a bulletin > board for asking questions and why they have a support email address on > their site. > > Next time someone posts having problems with the driver send em to > nvidia's site. Done. If you're going to undermine the integrity of your system and the open source process at the same time, you're better off just going back and using Windows. Actually, do whatever you want personally, but don't spread this bad advice here. Sean From denis at poolshark.org Tue Jun 7 22:19:24 2005 From: denis at poolshark.org (Denis Leroy) Date: Tue, 07 Jun 2005 15:19:24 -0700 Subject: OT: nVidia driver [was: Wish list] In-Reply-To: <3186.10.10.10.24.1118181192.squirrel@linux1> References: <1118002724.9556.34.camel@Darkstar> <42A36449.80509@n-man.com> <1118043525.5652.9.camel@laptopd505.fenrus.org> <42A4BE05.9060105@poolshark.org> <1118093019.2468.42.camel@cutter> <6f6293f105060712576a17cde0@mail.gmail.com> <3609.10.10.10.24.1118176876.squirrel@linux1> <1118180290.7742.73.camel@mlenzdesktop> <3186.10.10.10.24.1118181192.squirrel@linux1> Message-ID: <42A61D6C.7060606@poolshark.org> Sean wrote: > On Tue, June 7, 2005 5:38 pm, Matthew Lenz said: > If you're going to undermine the integrity of your system and the open > source process at the same time, you're better off just going back and > using Windows. Actually, do whatever you want personally, but don't > spread this bad advice here. That's a very naive thing to say. You can't deny the fact that people want graphics hardware acceleration for various reasons, whether it's games, video apps or openGL development. Now F/OSS can't provide that, at least not yet, and not well enough. Not everyone uses the NVidia driver by choice. And if you think their driver is a pain to deal with, don't ever try to get a USB wireless device working. I need this for one of my boxes and I have to deal with the infamous linux-wlan driver, an absolute piece of garbage that doesn't even implement the wireless extensions and is riddled with SMP race conditions :-( Unfortunately, it's the only way to get some 3-year old USB wireless receivers to work (anything newer isn't supported). Now you can't say it's my fault for needing USB-based wireless connectivity (it's not my fault is the media box i use has no PCI slots). I'm the first to agree it's all NVidia's fault for not releasing their entire driver under the GPL. Maybe if the companies that owned the most powerful Linux distros were to put some pressure on them... -denis From seanlkml at sympatico.ca Tue Jun 7 22:44:01 2005 From: seanlkml at sympatico.ca (Sean) Date: Tue, 7 Jun 2005 18:44:01 -0400 (EDT) Subject: OT: nVidia driver [was: Wish list] In-Reply-To: <42A61D6C.7060606@poolshark.org> References: <1118002724.9556.34.camel@Darkstar> <42A36449.80509@n-man.com> <1118043525.5652.9.camel@laptopd505.fenrus.org> <42A4BE05.9060105@poolshark.org> <1118093019.2468.42.camel@cutter> <6f6293f105060712576a17cde0@mail.gmail.com> <3609.10.10.10.24.1118176876.squirrel@linux1> <1118180290.7742.73.camel@mlenzdesktop> <3186.10.10.10.24.1118181192.squirrel@linux1> <42A61D6C.7060606@poolshark.org> Message-ID: <4167.10.10.10.24.1118184241.squirrel@linux1> On Tue, June 7, 2005 6:19 pm, Denis Leroy said: > Sean wrote: >> On Tue, June 7, 2005 5:38 pm, Matthew Lenz said: > > If you're going to undermine the integrity of your system and the open >> source process at the same time, you're better off just going back and >> using Windows. Actually, do whatever you want personally, but don't >> spread this bad advice here. > > That's a very naive thing to say. You can't deny the fact that people want > graphics hardware acceleration for various reasons, whether it's games, > video > apps or openGL development. Now F/OSS can't provide that, at least not > yet, > and not well enough. Not everyone uses the NVidia driver by choice. And if > you > think their driver is a pain to deal with, don't ever try to get a USB > wireless device working. I need this for one of my boxes and I have to > deal > with the infamous linux-wlan driver, an absolute piece of garbage that > doesn't > even implement the wireless extensions and is riddled with SMP race > conditions > :-( Unfortunately, it's the only way to get some 3-year old USB wireless > receivers to work (anything newer isn't supported). Now you can't say it's > my > fault for needing USB-based wireless connectivity (it's not my fault is > the > media box i use has no PCI slots). I'm the first to agree it's all > NVidia's > fault for not releasing their entire driver under the GPL. Maybe if the > companies that owned the most powerful Linux distros were to put some > pressure > on them... Frankly, the power of a few distros is nothing compared to the power of more people waking up to what is at stake in the decisions they make. There are way too many apologists for nVidia et. al. Most of these people don't have a clue about how Linux managed to get where it is today. That's fine, but it doesn't mean we have to let their bad advice go by without comment. It's pretty annoying listening to all the newcomers unthinkingly thumb their nose at what got us to where we are today. You simply can't move Linux forward by undermining exactly what makes it important and successful. Anyway, choosing a binary driver has real risks involved. If you value the data in your computer, you understand the open source process, and you're thankful for the great O/S that you find yourself using; the decisions become rather easy. Signing-off, Sean. From denis at poolshark.org Tue Jun 7 23:02:32 2005 From: denis at poolshark.org (Denis Leroy) Date: Tue, 07 Jun 2005 16:02:32 -0700 Subject: OT: nVidia driver [was: Wish list] In-Reply-To: <4167.10.10.10.24.1118184241.squirrel@linux1> References: <1118002724.9556.34.camel@Darkstar> <42A36449.80509@n-man.com> <1118043525.5652.9.camel@laptopd505.fenrus.org> <42A4BE05.9060105@poolshark.org> <1118093019.2468.42.camel@cutter> <6f6293f105060712576a17cde0@mail.gmail.com> <3609.10.10.10.24.1118176876.squirrel@linux1> <1118180290.7742.73.camel@mlenzdesktop> <3186.10.10.10.24.1118181192.squirrel@linux1> <42A61D6C.7060606@poolshark.org> <4167.10.10.10.24.1118184241.squirrel@linux1> Message-ID: <42A62788.3070306@poolshark.org> Sean wrote: > It's pretty annoying listening to all the newcomers unthinkingly thumb > their nose at what got us to where we are today. You simply can't move > Linux forward by undermining exactly what makes it important and > successful. I don't know who you're calling newcomers, but there are plenty of Linux veterans, including myself, who don't share your opinion. > Anyway, choosing a binary driver has real risks involved. If you value > the data in your computer, you understand the open source process, and > you're thankful for the great O/S that you find yourself using; the > decisions become rather easy. My points was, you can only choose if there's an alternative. There are no serious alternatives to the Nvidia binary driver, and that's not my fault. -denis From jerone at gmail.com Wed Jun 8 00:21:18 2005 From: jerone at gmail.com (Jerone Young) Date: Tue, 7 Jun 2005 19:21:18 -0500 Subject: OT: nVidia driver [was: Wish list] In-Reply-To: <4167.10.10.10.24.1118184241.squirrel@linux1> References: <1118002724.9556.34.camel@Darkstar> <1118043525.5652.9.camel@laptopd505.fenrus.org> <42A4BE05.9060105@poolshark.org> <1118093019.2468.42.camel@cutter> <6f6293f105060712576a17cde0@mail.gmail.com> <3609.10.10.10.24.1118176876.squirrel@linux1> <1118180290.7742.73.camel@mlenzdesktop> <3186.10.10.10.24.1118181192.squirrel@linux1> <42A61D6C.7060606@poolshark.org> <4167.10.10.10.24.1118184241.squirrel@linux1> Message-ID: <9f50a7a005060717213c76b518@mail.gmail.com> Why so angry. I think that you should really get off the religious kick. I for one have been using Linux for an extremely long time. I also use the Nvidia propritary drivers. Why you ask? Because open or closed they are clearly the best drivers for X. For most people who do actual work on their boxes, functionality matters more than a religious kick :-) . Also I want to run the latest hardware & not something that is 7 years old with crappy performance, just to say that my system is all open source. We have all asked Nvidia to open there drivers, but they insit on staying closed source. Since they keep up with kernel releases & fix the drivers when there are breaks, I personally have just gotten used to it. I install them and I don't have any problems. There drivers clearly surpass all drivers in X when it comes to features. Maybe one day Nvidia will wake up and release there drivers open source, but until then I have as of yet to see anyone who can match their drviers...especially ATI. On 6/7/05, Sean wrote: > On Tue, June 7, 2005 6:19 pm, Denis Leroy said: > > Sean wrote: > >> On Tue, June 7, 2005 5:38 pm, Matthew Lenz said: > > > If you're going to undermine the integrity of your system and the open > >> source process at the same time, you're better off just going back and > >> using Windows. Actually, do whatever you want personally, but don't > >> spread this bad advice here. > > > > That's a very naive thing to say. You can't deny the fact that people want > > graphics hardware acceleration for various reasons, whether it's games, > > video > > apps or openGL development. Now F/OSS can't provide that, at least not > > yet, > > and not well enough. Not everyone uses the NVidia driver by choice. And if > > you > > think their driver is a pain to deal with, don't ever try to get a USB > > wireless device working. I need this for one of my boxes and I have to > > deal > > with the infamous linux-wlan driver, an absolute piece of garbage that > > doesn't > > even implement the wireless extensions and is riddled with SMP race > > conditions > > :-( Unfortunately, it's the only way to get some 3-year old USB wireless > > receivers to work (anything newer isn't supported). Now you can't say it's > > my > > fault for needing USB-based wireless connectivity (it's not my fault is > > the > > media box i use has no PCI slots). I'm the first to agree it's all > > NVidia's > > fault for not releasing their entire driver under the GPL. Maybe if the > > companies that owned the most powerful Linux distros were to put some > > pressure > > on them... > > Frankly, the power of a few distros is nothing compared to the power of > more people waking up to what is at stake in the decisions they make. > There are way too many apologists for nVidia et. al. Most of these > people don't have a clue about how Linux managed to get where it is today. > That's fine, but it doesn't mean we have to let their bad advice go by > without comment. > > It's pretty annoying listening to all the newcomers unthinkingly thumb > their nose at what got us to where we are today. You simply can't move > Linux forward by undermining exactly what makes it important and > successful. > > Anyway, choosing a binary driver has real risks involved. If you value > the data in your computer, you understand the open source process, and > you're thankful for the great O/S that you find yourself using; the > decisions become rather easy. > > Signing-off, > Sean. > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From pjones at redhat.com Wed Jun 8 00:33:16 2005 From: pjones at redhat.com (Peter Jones) Date: Tue, 07 Jun 2005 20:33:16 -0400 Subject: What next? In-Reply-To: <42A356FD.1080507@GreenKey.net> References: <200506012344.j51Ni6oJ032236@magilla.sf.frob.com> <1117689174.2702.28.camel@cutter> <42A241C6.5000706@redhat.com> <1117930993.7104.2.camel@cutter> <42A247FE.1030300@redhat.com> <1117955320.7104.8.camel@cutter> <20050605082711.GG22547@redhat.com> <1117989035.7104.36.camel@cutter> <1118012841.4040.20.camel@localhost.localdomain> <42A356FD.1080507@GreenKey.net> Message-ID: <1118190796.8637.4.camel@localhost.localdomain> On Sun, 2005-06-05 at 12:48 -0700, Curtis Doty wrote: > OT: How does one outsider/dabbler know which specific rpm builds are > going into fc4 (or any official release) at any given point in time? Generally, one looks at rawhide. > I'm in the middle of uncovering/reverting some unpleasant behaviour > introduced into syslinux 3.08 and I'd be curious to know if the 3.08-2 > build up on rawhide is on the table for fc4 or fc5? Since only 3.07 was > in test3. Have you made sure there's a bug filed in bugzilla? Or does "unpleasant behaviour" mean it's not actually wrong, merely not what you expect? -- Peter From jspaleta at gmail.com Wed Jun 8 01:03:10 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 7 Jun 2005 21:03:10 -0400 Subject: OT: nVidia driver [was: Wish list] In-Reply-To: <9f50a7a005060717213c76b518@mail.gmail.com> References: <1118002724.9556.34.camel@Darkstar> <42A4BE05.9060105@poolshark.org> <1118093019.2468.42.camel@cutter> <6f6293f105060712576a17cde0@mail.gmail.com> <3609.10.10.10.24.1118176876.squirrel@linux1> <1118180290.7742.73.camel@mlenzdesktop> <3186.10.10.10.24.1118181192.squirrel@linux1> <42A61D6C.7060606@poolshark.org> <4167.10.10.10.24.1118184241.squirrel@linux1> <9f50a7a005060717213c76b518@mail.gmail.com> Message-ID: <604aa7910506071803712fa32f@mail.gmail.com> On 6/7/05, Jerone Young wrote: > but until then I have as of yet to see > anyone who can match their drviers...especially ATI. Well duh, of course ATI isnt going to have good drivers for your nvidia card. Lame jokes aside... do you know exactly how responsible nvidia is for the state of nv driver development that is available as part of X? Perhaps, more than perhaps.. nv could also be claimed as their driver too. Maybe the disparity in functionality between the nv driver and the closed nvidia driver is delibrate. Maybe the developers provided as much functionality in the open nv driver as the feel they can do and its not so much a decision that the engineers are actively making as it is a set of legal opinions and or business decisions constraining their actions. Or maybe they are just twisted evil dwarves who like watching the drivers break as the kernel development churns forward. -jef From seanlkml at sympatico.ca Wed Jun 8 01:10:44 2005 From: seanlkml at sympatico.ca (Sean) Date: Tue, 7 Jun 2005 21:10:44 -0400 (EDT) Subject: OT: nVidia driver [was: Wish list]] In-Reply-To: <20050608005103.GA8443@linux1.attic.local> References: <20050608005103.GA8443@linux1.attic.local> Message-ID: <2035.10.10.10.24.1118193044.squirrel@linux1> > Why so angry. I think that you should really get off the religious > kick. I for one have been using Linux for an extremely long time. I Why is it always the nVidia zealots who accuse everyone else of being religious? > also use the Nvidia propritary drivers. Why you ask? Because open or > closed they are clearly the best drivers for X. For most people who > do actual work on their boxes, functionality matters more than a > religious kick :-) . Also I want to run the latest hardware & not Yeah, and what "work" are you getting done with your binary nVidia driver that couldn't be done with an open source alternative. My guess, nothing. Have you even tried the open source nv alternative? > something that is 7 years old with crappy performance, just to say > that my system is all open source. We have all asked Nvidia to open > there drivers, but they insit on staying closed source. Since they > keep up with kernel releases & fix the drivers when there are breaks, > I personally have just gotten used to it. I install them and I don't > have any problems. There drivers clearly surpass all drivers in X when > it comes to features. Maybe one day Nvidia will wake up and release > there drivers open source, but until then I have as of yet to see > anyone who can match their drviers...especially ATI. BS. Obviously you have to overstate the facts (ie. there are many open source cards newer than 7 years old) to feel like you can defend your position, typical nVidia zealotry. Get over it. Sean From jerone at gmail.com Wed Jun 8 01:22:26 2005 From: jerone at gmail.com (Jerone Young) Date: Tue, 7 Jun 2005 20:22:26 -0500 Subject: OT: nVidia driver [was: Wish list] In-Reply-To: <604aa7910506071803712fa32f@mail.gmail.com> References: <1118002724.9556.34.camel@Darkstar> <1118093019.2468.42.camel@cutter> <6f6293f105060712576a17cde0@mail.gmail.com> <3609.10.10.10.24.1118176876.squirrel@linux1> <1118180290.7742.73.camel@mlenzdesktop> <3186.10.10.10.24.1118181192.squirrel@linux1> <42A61D6C.7060606@poolshark.org> <4167.10.10.10.24.1118184241.squirrel@linux1> <9f50a7a005060717213c76b518@mail.gmail.com> <604aa7910506071803712fa32f@mail.gmail.com> Message-ID: <9f50a7a0050607182269d4603e@mail.gmail.com> On 6/7/05, Jeff Spaleta wrote: > On 6/7/05, Jerone Young wrote: > > but until then I have as of yet to see > > anyone who can match their drviers...especially ATI. > > Well duh, of course ATI isnt going to have good drivers for your nvidia card. > Dude I was referring to all drivers...ATI having very bad drivers (the proprietary ones). While Nvidia having good drivers :-) > Lame jokes aside... do you know exactly how responsible nvidia is for > the state of nv driver development that is available as part of X? Since I havne not actively kept up with nv development I really don't. I don't believe they work on the nv driver any, just pass on the specs to someone to support the card. All nvidia cards work with the nv driver with 2d only just fine (minus some optimized acceleration for overlay). > Perhaps, more than perhaps.. nv could also be claimed as their driver > too. Maybe the disparity in functionality between the nv driver and > the closed nvidia driver is delibrate. Yes somewhat. Most of the functionality is 3D related. There are also TwinView & other nvidiaish things that are not in the nv driver. I don't like it, but inspite of what people have told Nvidia. They still do it this way. > Maybe the developers provided > as much functionality in the open nv driver as the feel they can do > and its not so much a decision that the engineers are actively making > as it is a set of legal opinions and or business decisions > constraining their actions. >From posts on the nvidia linux forum the developers are held back mainly by legal reasons. S3TC compression is patented and they can't just give out that code without permission. Also they claim there are a bunch of trade secrets in there code...optimized algorithms and such. I really don't buy it all that much. I don't see why they couldn't release the driver open source & there GL libraries closed. But it mainly has to do with lawyers. > Or maybe they are just twisted evil > dwarves who like watching the drivers break as the kernel development > churns forward. Actually the developers are and they know it. They also know that no one has any pity on them as Nvidia has chosen the hardest path to follow. > > -jef > From jerone at gmail.com Wed Jun 8 01:28:13 2005 From: jerone at gmail.com (Jerone Young) Date: Tue, 7 Jun 2005 20:28:13 -0500 Subject: OT: nVidia driver [was: Wish list]] In-Reply-To: <2035.10.10.10.24.1118193044.squirrel@linux1> References: <20050608005103.GA8443@linux1.attic.local> <2035.10.10.10.24.1118193044.squirrel@linux1> Message-ID: <9f50a7a005060718287874b879@mail.gmail.com> I do apologis to the list for getting this flame war started so this is my last post on this. On 6/7/05, Sean wrote: > > Why so angry. I think that you should really get off the religious > > kick. I for one have been using Linux for an extremely long time. I > > Why is it always the nVidia zealots who accuse everyone else of being > religious? > > > also use the Nvidia propritary drivers. Why you ask? Because open or > > closed they are clearly the best drivers for X. For most people who > > do actual work on their boxes, functionality matters more than a > > religious kick :-) . Also I want to run the latest hardware & not > > Yeah, and what "work" are you getting done with your binary nVidia driver > that couldn't be done with an open source alternative. My guess, > nothing. Have you even tried the open source nv alternative? Ok your obviously an imature kid. And you havn't had a serious job yet. I more so program Linux related stuff. But I also get into 3D art using Maya mainly. These require 3d accelration (hmmm.. can nv driver do that?) Though I'm not very good at it. Friends of mine use it at there jobs everyday. > > > something that is 7 years old with crappy performance, just to say > > that my system is all open source. We have all asked Nvidia to open > > there drivers, but they insit on staying closed source. Since they > > keep up with kernel releases & fix the drivers when there are breaks, > > I personally have just gotten used to it. I install them and I don't > > have any problems. There drivers clearly surpass all drivers in X when > > it comes to features. Maybe one day Nvidia will wake up and release > > there drivers open source, but until then I have as of yet to see > > anyone who can match their drviers...especially ATI. > > BS. Obviously you have to overstate the facts (ie. there are many open > source cards newer than 7 years old) to feel like you can defend your > position, typical nVidia zealotry. Get over it. No I don't overstate the facts. As a long time linux user I am now more concerned on functionality. I have owned ATI Radeons and there Linux drivers are horrible in comparison. Hopefully they can get there act together. But Nvidia from day one has had a nice solid driver set for people to use. Works great for games & work under Linux. > > Sean > > > From jspaleta at gmail.com Wed Jun 8 01:32:52 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 7 Jun 2005 21:32:52 -0400 Subject: OT: nVidia driver [was: Wish list] In-Reply-To: <9f50a7a0050607182269d4603e@mail.gmail.com> References: <1118002724.9556.34.camel@Darkstar> <6f6293f105060712576a17cde0@mail.gmail.com> <3609.10.10.10.24.1118176876.squirrel@linux1> <1118180290.7742.73.camel@mlenzdesktop> <3186.10.10.10.24.1118181192.squirrel@linux1> <42A61D6C.7060606@poolshark.org> <4167.10.10.10.24.1118184241.squirrel@linux1> <9f50a7a005060717213c76b518@mail.gmail.com> <604aa7910506071803712fa32f@mail.gmail.com> <9f50a7a0050607182269d4603e@mail.gmail.com> Message-ID: <604aa79105060718327a5d494a@mail.gmail.com> On 6/7/05, Jerone Young wrote: > Since I havne not actively kept up with nv development I really don't. > I don't believe they work on the nv driver any, just pass on the > specs to someone to support the card. I think you should go check through the history of the nv driver. You'll be amazed at whom is doing the large scale changes and perhaps shocked when you find their name at nvidia as an email address. hell just grep through the /usr/share/doc/xorg-x11-6.8.2/CHANGELOG for nv highlighted references and you'll get a much better feel as to long term historic nature of nvidia's involvement with nv driver development. -jef From conditionterminal at gmail.com Wed Jun 8 02:36:09 2005 From: conditionterminal at gmail.com (condition terminal) Date: Wed, 8 Jun 2005 14:36:09 +1200 Subject: question about RedHat/Fedora and the GPL In-Reply-To: <1118148928.5721.24.camel@cutter> References: <1118045329.5652.19.camel@laptopd505.fenrus.org> <20050606211730.GC28754@devserv.devel.redhat.com> <20050607021532.GA938160@hiwaay.net> <1118134855.2234.7.camel@laptop.mpeters.local> <1118148928.5721.24.camel@cutter> Message-ID: On 6/8/05, seth vidal wrote: > > > True enough, so far as it goes; 'release of beehive' code > > itself. But if the argument is that one may conceal from a > > covered recipient under the GPL, the state of the build > > environment which controls rpmbuild, autogen, ./configure, > > etc, I certainly know of at least two lawyers who differ. We > > presented in a panel discussion a couple years ago on the GPL, > > and hit this topic at the Ohio Linuxfest 2003 ;) > > Then if that's the case it's an issue best taken up with fedora-legal or > redhat-legal. No one on this list can do anything about it, I assure > you. :) > Actualy, you are wrong. If it is correct that beehive should be released, then a list, such as this, can be used to obtain an agreed concenus that it should be taken further. Shooting first ask later is not clever and this is excatly why I asked here. I knew I would see the "its no use to you, so why ask", "its old" and good old Warren with his "stop asking" blindside manner, but the crux of of this issue is that its not up to YOU (anyone aside from me) as to its (beehives) usefullness. People are asked to lobby against voilations all the time, even when it doesn't affect them. Its the princible, so, if people do agree that it is a something worth taking to the RH legal team, then I will do so. I think Mr Harrold shows a "real" world example as to the fact that beehive does indeed play a large role in the control of building GPL sources at RH. ta From skvidal at phy.duke.edu Wed Jun 8 02:48:35 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 07 Jun 2005 22:48:35 -0400 Subject: question about RedHat/Fedora and the GPL In-Reply-To: References: <1118045329.5652.19.camel@laptopd505.fenrus.org> <20050606211730.GC28754@devserv.devel.redhat.com> <20050607021532.GA938160@hiwaay.net> <1118134855.2234.7.camel@laptop.mpeters.local> <1118148928.5721.24.camel@cutter> Message-ID: <1118198915.5209.41.camel@cutter> > Actualy, you are wrong. > > If it is correct that beehive should be released, then a list, such as > this, can be used to obtain an agreed concenus that it should be taken > further. > > Shooting first ask later is not clever and this is excatly why I asked > here. I knew I would see the "its no use to you, so why ask", "its > old" and good old Warren with his "stop asking" blindside manner, but > the crux of of this issue is that its not up to YOU (anyone aside from > me) as to its (beehives) usefullness. People are asked to lobby > against voilations all the time, even when it doesn't affect them. Its > the princible, so, if people do agree that it is a something worth > taking to the RH legal team, then I will do so. I think Mr Harrold > shows a "real" world example as to the fact that beehive does indeed > play a large role in the control of building GPL sources at RH. I have a better idea and one that results in much less discussion about this subject. if you'd like to see a buildsystem that can build anaconda then contribute to the one we're(mostly dcbw) working on for fedora extras. If it works well then we can lobby to work on using it to build fedora core, too. then presto, no more beehive to worry with. :) -sv From jspaleta at gmail.com Wed Jun 8 02:48:30 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 7 Jun 2005 22:48:30 -0400 Subject: question about RedHat/Fedora and the GPL In-Reply-To: References: <20050606211730.GC28754@devserv.devel.redhat.com> <20050607021532.GA938160@hiwaay.net> <1118134855.2234.7.camel@laptop.mpeters.local> <1118148928.5721.24.camel@cutter> Message-ID: <604aa79105060719487c9d6c0a@mail.gmail.com> On 6/7/05, condition terminal wrote: > if people do agree that it is a something worth > taking to the RH legal team, then I will do so. I think most people in this thread have already reached consensous on this issue. I don't think its the outcome you personally want however. But since you seem to want to keep count, I also do not think its worth it. I think at this point the community is better served by everyone doing what they can to help seth and others create a buildsystem that is useful for a larger community build environment. -jef"has a pretty strong gut feeling the fsf would have already approached redhat quietly about any compliance issues and worked to correct any license violating behavior if there were any present"spaleta From mattdm at mattdm.org Wed Jun 8 03:15:17 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 7 Jun 2005 23:15:17 -0400 Subject: OT: nVidia driver [was: Wish list]] In-Reply-To: <2035.10.10.10.24.1118193044.squirrel@linux1> References: <20050608005103.GA8443@linux1.attic.local> <2035.10.10.10.24.1118193044.squirrel@linux1> Message-ID: <20050608031517.GA2868@jadzia.bu.edu> On Tue, Jun 07, 2005 at 09:10:44PM -0400, Sean wrote: > Yeah, and what "work" are you getting done with your binary nVidia driver > that couldn't be done with an open source alternative. My guess, > nothing. Have you even tried the open source nv alternative? I don't know about the the original poster here, but graphics programmers in our Scientific Computing and Visualization center need fast, modern 3D graphics cards. As much as I hate the situation, their realistic choices are: 1) use the nVidia proprietary drivers on Linux or 2) use a whole proprietary OS. I wish that weren't the case, but there it is. > BS. Obviously you have to overstate the facts (ie. there are many open > source cards newer than 7 years old) to feel like you can defend your > position, typical nVidia zealotry. Get over it. Seven years is an exaggeration, but as far as I know, the most powerful card with open source 3D drivers in x.org is the ATI FireGL 8800, which was launched August, 2001. (It's basically a faster version of the Radeon 8500.) That's almost four years ago. There are several options for "okay, at least 3D hardware is somehow involved here" (notably, the Intel integrated chipsets), but generally the situation is grim. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 81 degrees Fahrenheit. From mikem at cyber.com.au Wed Jun 8 03:52:42 2005 From: mikem at cyber.com.au (Mike MacCana) Date: Wed, 8 Jun 2005 13:52:42 +1000 (EST) Subject: Is the Wiki to be used? Message-ID: I was attempting to add something useful to the Wiki (a link to J5s suggested init/kudzu/likely also cron replacement talk) and noticed the page was immutable. FC5Future has also become immutable. Is the Wiki intended to be used as a Wiki, or it it just a CMS? Mike -- __________________________________________________________________________ Mike MacCana Consultant RHCX, MCSE, MCP+I 0419 394 504 From skvidal at phy.duke.edu Wed Jun 8 03:58:05 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 07 Jun 2005 23:58:05 -0400 Subject: Is the Wiki to be used? In-Reply-To: References: Message-ID: <1118203085.5209.97.camel@cutter> On Wed, 2005-06-08 at 13:52 +1000, Mike MacCana wrote: > I was attempting to add something useful to the Wiki (a link to J5s > suggested init/kudzu/likely also cron replacement talk) and noticed the > page was immutable. FC5Future has also become immutable. > > Is the Wiki intended to be used as a Wiki, or it it just a CMS? > do you have an account? Are you in the editgroup? the wiki is not a free-for-all in terms of editing but we do have a lot of people who can edit it, yes. -sv From b.j.smith at ieee.org Wed Jun 8 04:43:36 2005 From: b.j.smith at ieee.org (Bryan J. Smith) Date: Tue, 07 Jun 2005 23:43:36 -0500 Subject: OT: nVidia driver [was: Wish list] -- understanding the GPU market In-Reply-To: <20050608012857.4573B73725@hormel.redhat.com> References: <20050608012857.4573B73725@hormel.redhat.com> Message-ID: <1118205816.4456.25.camel@bert64.mobile.smithconcepts.com> Matrox has been proprietary. ATI is now proprietary. The XFree86 4.0+ model introduced a loadable module option, which allowed binary drivers. nVidia just adds some kernel memory and AGPgart interfaces. Until recently, those were Intel "trade secrets" nVidia could not disclose. As far as the unified driver, Matrox, nVidia and now ATI have the same issue, Intel, Microsoft and a host of other companies' lawyers would have a field day if they were GPL'd. ATI should be commended for attempting to make a "clean room" DRI/ GLX implementation. But eventually they had to give in, and started withholding specifications as of R300 (Radeon 9500+). And even before, many 2D and 3D interfaces were _never_ published by ATI. What really gets to me here is the _real_market_conditions_ involved. We're not talking about a product that is released and modern for 2-5 years. We're talking about a product that is _obsolete_ in less than _12_months_! GPUs double in speed 2-3 times faster than CPUs. The drivers are under development alongside engineering under NDA, and that's not going to change. If they opened up the driver model, then they'd still either need to A) have you sign a NDA, or B) you'll see drivers for Linux come out some 6+ months _after_ release. I think there are lessons to be learned from ATI's prior attempts. In reality, we're still talking an "open standard" in GLX, with ARB extensions and in a few cases, yes, some GPU-specific extensions (that get rolled into ARB much faster than DirectX where many _never_ become part of the spec). The concept that leading-edge video drivers will _ever_ be GPL is very slim-to-none. And as far as the license, the drivers are unified, and written for _all_ platforms, so there is the argument that they do not require Linux (and Linus' comments have been used similarly for justifying binary-only WLAN objects). In reality, yes, I'd like to see nVidia's memory interfaces in the kernel GPL'd. And now that the _standard_ PCI-Express is here from the PCI Standards Group (AGP was _never_ a standard, but an Intel trade secret of PCI), I hope Intel takes off some chains on nVidia. But there is just too much IP involved, and too many NDAs. GPUs are far, far, _far_ more complex than even CPUs these days -- and the IP in the software even more so and closely tied. There is some open source GLX code out there for both ATI and nVidia -- but you're _never_ going to get the "cutting edge" under the model. -- Bryan J. Smith b.j.smith at ieee.org --------------------------------------------------------------------- It is mathematically impossible for someone who makes more than you to be anything but richer than you. Any tax rate that penalizes them will also penalize you similarly (to those below you, and then below them). Linear algebra, let alone differential calculus or even ele- mentary concepts of limits, is mutually exclusive with US journalism. So forget even attempting to explain how tax cuts work. ;-> From b.j.smith at ieee.org Wed Jun 8 04:50:21 2005 From: b.j.smith at ieee.org (Bryan J. Smith) Date: Tue, 07 Jun 2005 23:50:21 -0500 Subject: fedora-devel-list Digest, Vol 16, Issue 41 In-Reply-To: <20050608012857.4573B73725@hormel.redhat.com> References: <20050608012857.4573B73725@hormel.redhat.com> Message-ID: <1118206221.4456.28.camel@bert64.mobile.smithconcepts.com> From: Chris Adams > The OpenSSL license is an old-style BSD type license with the > advertising clause, which I understand to be incompatible with the GPL. > That's part of why some programs are moving to the (LGPLed) GNU TLS > library instead. Ack, you're right. My apologies. > If it requires random services to link or include the code, it should > probably be BSD (non-advertising clause). Otherwise, things like Oracle > won't be able to start at boot. I think LGPL on those sections will do. I'm not a huge fan of BSD, at least for core details, because it's a leechable license. I can understand it in the case of Class libraries for Mono where vendors are freely sharing amongst each other. But the core system and libraries are GPL and LGPL. -- Bryan J. Smith b.j.smith at ieee.org --------------------------------------------------------------------- It is mathematically impossible for someone who makes more than you to be anything but richer than you. Any tax rate that penalizes them will also penalize you similarly (to those below you, and then below them). Linear algebra, let alone differential calculus or even ele- mentary concepts of limits, is mutually exclusive with US journalism. So forget even attempting to explain how tax cuts work. ;-> From sundaram at redhat.com Wed Jun 8 04:50:41 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 08 Jun 2005 10:20:41 +0530 Subject: OT: nVidia driver [was: Wish list]] In-Reply-To: <9f50a7a005060718287874b879@mail.gmail.com> References: <20050608005103.GA8443@linux1.attic.local> <2035.10.10.10.24.1118193044.squirrel@linux1> <9f50a7a005060718287874b879@mail.gmail.com> Message-ID: <42A67921.1030603@redhat.com> Hi >Ok your obviously an imature kid. And you havn't had a serious job >yet. > If you are going to indulge in name calling and personal insults, take it elsewhere. regards Rahul From davej at redhat.com Wed Jun 8 05:03:50 2005 From: davej at redhat.com (Dave Jones) Date: Wed, 8 Jun 2005 01:03:50 -0400 Subject: OT: nVidia driver [was: Wish list] -- understanding the GPU market In-Reply-To: <1118205816.4456.25.camel@bert64.mobile.smithconcepts.com> References: <20050608012857.4573B73725@hormel.redhat.com> <1118205816.4456.25.camel@bert64.mobile.smithconcepts.com> Message-ID: <20050608050350.GA5744@redhat.com> On Tue, Jun 07, 2005 at 11:43:36PM -0500, Bryan J. Smith wrote: > nVidia just adds some kernel memory and AGPgart interfaces. Plus god knows what else. Take a look at the size of the binary part of their driver. It's (to the best of my knowledge) the largest kernel module available for Linux. > Until recently, those were Intel "trade secrets" nVidia could not > disclose. I'm not sure where you're getting this. > ATI should be commended for attempting to make a "clean room" DRI/ > GLX implementation. But eventually they had to give in The r200 work was actually done by precision insight, under sponsership from The Weather Channel, not ATI. > The concept that leading-edge video drivers will _ever_ be GPL is > very slim-to-none. The folks reverse engineering the r300 cores have come along in leaps and bounds. From what I hear it's good enough to play quake and such already. Having to reverse engineer the hardware does mean we're at best going to be one generation of card behind though, but the picture isn't totally bleak.. > In reality, yes, I'd like to see nVidia's memory interfaces in the > kernel GPL'd. And now that the _standard_ PCI-Express is here from > the PCI Standards Group (AGP was _never_ a standard, but an Intel > trade secret of PCI) If you mean this in the sense "Was never a standard that PCI-SIG made people pay for to see", you are correct. But there was nothing secret about it at all. The fact that it was freely downloadable was one of the reasons that Linux ended up with agpgart support so quickly. Dave From conditionterminal at gmail.com Wed Jun 8 06:41:08 2005 From: conditionterminal at gmail.com (condition terminal) Date: Wed, 8 Jun 2005 18:41:08 +1200 Subject: question about RedHat/Fedora and the GPL In-Reply-To: <604aa79105060719487c9d6c0a@mail.gmail.com> References: <20050606211730.GC28754@devserv.devel.redhat.com> <20050607021532.GA938160@hiwaay.net> <1118134855.2234.7.camel@laptop.mpeters.local> <1118148928.5721.24.camel@cutter> <604aa79105060719487c9d6c0a@mail.gmail.com> Message-ID: On 6/8/05, Jeff Spaleta wrote: > On 6/7/05, condition terminal wrote: > > if people do agree that it is a something worth > > taking to the RH legal team, then I will do so. > I think most people in this thread have already reached consensous on > this issue. I don't think its the outcome you personally want however. > But since you seem to want to keep count, I also do not think its > worth it. I think at this point the community is better served by > everyone doing what they can to help seth and others create a > buildsystem that is useful for a larger community build environment. > > -jef"has a pretty strong gut feeling the fsf would have already > approached redhat quietly about any compliance issues and worked to > correct any license violating behavior if there were any > present"spaleta > So ignore a potentional violation because someone else is planning to do the same thing, but better? Thats an interesting view point on possible GPL violations. ta From jkeating at j2solutions.net Wed Jun 8 07:07:14 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 08 Jun 2005 00:07:14 -0700 Subject: question about RedHat/Fedora and the GPL In-Reply-To: References: <20050606211730.GC28754@devserv.devel.redhat.com> <20050607021532.GA938160@hiwaay.net> <1118134855.2234.7.camel@laptop.mpeters.local> <1118148928.5721.24.camel@cutter> <604aa79105060719487c9d6c0a@mail.gmail.com> Message-ID: <1118214435.9062.26.camel@yoda.loki.me> On Wed, 2005-06-08 at 18:41 +1200, condition terminal wrote: > > So ignore a potentional violation because someone else is planning to > do the same thing, but better? > > Thats an interesting view point on possible GPL violations. No, ignore this thread as most people (and lawyers that have looked into it) find no violation. And further more, even if there WAS a violation, most people on this list have 0 interest in seeing code to something that is outdated, useless and is going away. Instead they would like to spend time working on an ALREADY OPEN build system that is tagged to be the replacement. What is it you hope to gain by accessing beehive? Or is it merely that you want to soapbox about Red Hat being evil and possibly (very very very very unlikely) violating the GPL? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From mitr at volny.cz Wed Jun 8 09:45:14 2005 From: mitr at volny.cz (Miloslav Trmac) Date: Wed, 8 Jun 2005 11:45:14 +0200 Subject: question about RedHat/Fedora and the GPL In-Reply-To: References: <1118045329.5652.19.camel@laptopd505.fenrus.org> <20050606211730.GC28754@devserv.devel.redhat.com> <20050607021532.GA938160@hiwaay.net> <1118134855.2234.7.camel@laptop.mpeters.local> <1118148928.5721.24.camel@cutter> Message-ID: <20050608094510.GB5652@chrys.ms.mff.cuni.cz> On Wed, Jun 08, 2005 at 02:36:09PM +1200, condition terminal wrote: > If it is correct that beehive should be released, then a list, such as > this, can be used to obtain an agreed concenus that it should be taken > further. > > Shooting first ask later is not clever and this is excatly why I asked > here. Asking Alice when planning to shoot Bob doesn't seem too clever either :) Mirek From david at fubar.dk Wed Jun 8 10:21:59 2005 From: david at fubar.dk (David Zeuthen) Date: Wed, 08 Jun 2005 06:21:59 -0400 Subject: Firstboot: Module to add other OS partitions' entry to fstab In-Reply-To: <604aa79105060710267387fbb1@mail.gmail.com> References: <20050530085600.53686.qmail@web30801.mail.mud.yahoo.com> <1118144436.4246.31.camel@daxter.boston.redhat.com> <604aa791050607090853289862@mail.gmail.com> <1118161102.3926.39.camel@daxter.boston.redhat.com> <604aa79105060710267387fbb1@mail.gmail.com> Message-ID: <1118226119.14331.29.camel@daxter.boston.redhat.com> On Tue, 2005-06-07 at 13:26 -0400, Jeff Spaleta wrote: > On 6/7/05, David Zeuthen wrote: > > Well, for admins I suppose that gconf-editor is pretty good? > > gconf-editor can be..adequate.. under certain conditions. The primary > one being you know exactly what boolean you are looking for before you > go looking for it and its not a critically important setting. I would > suggest that a boolean that can have serious system-wide effects like > the problems you described in your post isn't something people > shouldn't have to troll through the gconf tree for.. in a panic. We > aren't talking about turning on metacity wireframe window moving to > get a slight speedup on low end hardware. You mentioned potential data > corruption situations... i think thats important enough to expose in > sort sort of dedicated ui. Potentially important enough to be a > firstboot dialog. You make some good points here. At this point, I don't really know, I *think* we may want to put it somewhere in the install/firstboot and perhaps also ask other questions so it looks like [ ] Automatically mount internal fixed drives (1) [x] Automatically mount external storage devices (2) [ ] Require password for write access to external storage (3) [x] Ignore SCSI drives for auto mounting (4) [x] Except optical drives (5) where (2) and (3) is needed for lock down; think either a) system in a library where people are not allowed to copy material to USB sticks; or b) an enterprise with low trust in their people ;-). That's this article: http://www.pbs.org/cringely/pulpit/pulpit20040916.html - search for ''epoxy''. Also, (4) and (5) is needed for the "enthusiast user" that uses SCSI drives; by default we ignore them since we can't really tell apart a Fiber Channel controller with 500 drivers from the enthusiast with his, say, two SCSI drives - we don't want the former to get 500+ icons on the desktop for mounted drives (I had a bug report about that pre-FC3), however, we do want the latter to work... So, it's all pretty complex if you want to auto mount drives in a sane way without screwing everyone. For the UI for these options, I think we need some of the interaction/ usability guys to say whether we can ask the user these questions :-). We'll see.. Cheers, David From fedora at camperquake.de Wed Jun 8 10:25:17 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 8 Jun 2005 12:25:17 +0200 Subject: Firstboot: Module to add other OS partitions' entry to fstab In-Reply-To: <1118226119.14331.29.camel@daxter.boston.redhat.com> References: <20050530085600.53686.qmail@web30801.mail.mud.yahoo.com> <1118144436.4246.31.camel@daxter.boston.redhat.com> <604aa791050607090853289862@mail.gmail.com> <1118161102.3926.39.camel@daxter.boston.redhat.com> <604aa79105060710267387fbb1@mail.gmail.com> <1118226119.14331.29.camel@daxter.boston.redhat.com> Message-ID: <20050608102517.GA20620@ryoko.camperquake.de> On Wed, Jun 08, 2005 at 06:21:59AM -0400, David Zeuthen wrote: > [x] Automatically mount external storage devices (2) > [ ] Require password for write access to external storage (3) Is there any way to mount an unclean ext3 filesystem without writing to it? From skn8700 at yahoo.co.in Wed Jun 8 10:17:00 2005 From: skn8700 at yahoo.co.in (SK Sharma) Date: Wed, 8 Jun 2005 11:17:00 +0100 (BST) Subject: SATA Driver's for x86 system Message-ID: <20050608101701.1843.qmail@web8503.mail.in.yahoo.com> Gentlemen/ Customer Support- I understand that D865GBF & D915Xpress Chipset based MB's are desktop boards - but while NO Modem driver (for internal ACE with CONEXANT Softmodem was available) - this is to enquire of the LINK from where SATA drivers for the aforesaid TWO Intel MOtherboards with P4 processors can be secured & How to configure the Installtion CD's accordingly for Installing RedHat Enterprise Linux 3 (Workstation) & RedHat Ver 9,1 & Fedora Core Release 1.0. Will appreciate if a URL link from where to find the Drivers & a guide to create the Installation CD's for the abovesaid. Thankyou, SkN8700// 8,June-2005. _______________________________________________________ Too much spam in your inbox? Yahoo! Mail gives you the best spam protection for FREE! http://in.mail.yahoo.com From buildsys at redhat.com Wed Jun 8 11:21:00 2005 From: buildsys at redhat.com (Build System) Date: Wed, 8 Jun 2005 07:21:00 -0400 Subject: rawhide report: 20050608 changes Message-ID: <200506081121.j58BL0gO020822@porkchop.devel.redhat.com> New package dhcdbd DHCP D-BUS daemon (dhcdbd) controls dhclient sessions with D-BUS, stores and presents DHCP options. Removed package w3c-libwww Updated Packages: fetchmail-6.2.5-8 ----------------- * Tue Jun 07 2005 Miloslav Trmac - 6.2.5-8 - Fix APOP and RPOP (#127315) - Don't link to libdl gedit-1:2.10.2-5 ---------------- * Tue Jun 07 2005 Ray Strode 1:2.10.2-5 - Dont pass user input as format specifiers to gtk_message_dialog_new (bug 159657). gstreamer-plugins-0.8.9-1 ------------------------- * Tue Jun 07 2005 John (J5) Palmieri - 0.8.9-1 - update to upstream 0.8.9 - disable spc support - Add requirement for cairo-devel - Add freeze, video4linuxradio, and wavpack plugins parted-1.6.22-3 --------------- * Tue Jun 07 2005 Chris Lumens 1.6.22-3 - Modified Apple_Free patch to take care of the case where the partitions are unnamed, causing many errors to be printed (#159047). tcpdump-14:3.8.2-13 ------------------- * Tue Jun 07 2005 Martin Stransky - 14:3.8.2-13 - fix for CAN-2005-1267 - BGP DoS, #159209 texinfo-4.8-5 ------------- * Tue Jun 07 2005 Tim Waugh 4.8-5 - Ship texi2pdf (bug #147271). From ndbecker2 at gmail.com Wed Jun 8 11:35:12 2005 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 08 Jun 2005 07:35:12 -0400 Subject: rawhide report: 20050608 changes (I'm conflicted) References: <200506081121.j58BL0gO020822@porkchop.devel.redhat.com> Message-ID: Anyone know a workaround for this? Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Updating: ghostscript x86_64 8.15-0.rc3.1 development 4.8 M ghostscript-devel x86_64 8.15-0.rc3.1 development 34 k ghostscript-gtk x86_64 8.15-0.rc3.1 development 26 k gimp-print x86_64 4.2.7-10 development 2.4 M gimp-print-cups x86_64 4.2.7-10 development 2.6 M gimp-print-devel x86_64 4.2.7-10 development 566 k gimp-print-plugin x86_64 4.2.7-10 development 46 k gimp-print-utils x86_64 4.2.7-10 development 21 k Transaction Summary ============================================================================= Install 0 Package(s) Update 8 Package(s) Remove 0 Package(s) Total download size: 10 M Is this ok [y/N]: y Downloading Packages: Running Transaction Test Finished Transaction Test Transaction Check Error: file /usr/bin/bdftops from install of ghostscript-8.1 5-0.rc3.1 conflicts with file from package ghostscript-7.07-40 [Lots more similar conflicts] From ellson at research.att.com Wed Jun 8 11:50:49 2005 From: ellson at research.att.com (John Ellson) Date: Wed, 08 Jun 2005 07:50:49 -0400 Subject: rawhide report: 20050607 changes In-Reply-To: <200506071156.j57BucXX005944@porkchop.devel.redhat.com> References: <200506071156.j57BucXX005944@porkchop.devel.redhat.com> Message-ID: <42A6DB99.4090507@research.att.com> Build System wrote: >xorg-x11-6.8.2-36 >----------------- >* Mon May 30 2005 Mike A. Harris 6.8.2-36 >- Added xorg-x11-6.8.2-ia64-elfloader-cache-flush.patch to fix cache flush > issue on ia64 systems (#153103) > >* Wed May 25 2005 Mike A. Harris 6.8.2-35 >- Remove /usr/X11R6/lib/X11/xinit symlink on non with_Xserver builds to > prevent rpm complaining about unpackaged symlinks on s390 et al. now that > bug (#108778) is fixed. > >* Mon May 23 2005 Mike A. Harris >- Made FC4 patches enabled for FC3, which will be merged into the FC-3 > branch, and released as an FC3-testing update soon. > > > xorg-x11 was upgraded to xorg-x11-6.8.2-37 on June 03 and now downgraded to xorg-x11-6.8.2-36? If this downgrade is deliberate couldn't the build system provide a better indication? If it was not deliberate, then some kind of additional check is needed to catch the error. John From fedora at camperquake.de Wed Jun 8 11:51:48 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 8 Jun 2005 13:51:48 +0200 Subject: rawhide report: 20050608 changes (I'm conflicted) In-Reply-To: References: <200506081121.j58BL0gO020822@porkchop.devel.redhat.com> Message-ID: <20050608115147.GB20620@ryoko.camperquake.de> On Wed, Jun 08, 2005 at 07:35:12AM -0400, Neal Becker wrote: > Anyone know a workaround for this? --exclude ghostscript\* From nicolas.mailhot at laposte.net Wed Jun 8 11:54:22 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 8 Jun 2005 13:54:22 +0200 (CEST) Subject: Firstboot: Module to add other OS partitions' entry to fstab In-Reply-To: <1118226119.14331.29.camel@daxter.boston.redhat.com> References: <20050530085600.53686.qmail@web30801.mail.mud.yahoo.com> <1118144436.4246.31.camel@daxter.boston.redhat.com> <604aa791050607090853289862@mail.gmail.com> <1118161102.3926.39.camel@daxter.boston.redhat.com> <604aa79105060710267387fbb1@mail.gmail.com> <1118226119.14331.29.camel@daxter.boston.redhat.com> Message-ID: <41128.192.54.193.35.1118231662.squirrel@rousalka.dyndns.org> On Mer 8 juin 2005 12:21, David Zeuthen a ?crit : > You make some good points here. At this point, I don't really know, I > *think* we may want to put it somewhere in the install/firstboot Firstboot is the same dead end as kudzu and sequential initscripts. Modern systems have a complex life, parameters need to be changed at any point of time, not only during 'initialisation'. This BTW is one reason why rpm plays in another category than windows-style installers that only care about the initial state. > and > perhaps also ask other questions so it looks like > > [ ] Automatically mount internal fixed drives (1) > [x] Automatically mount external storage devices (2) > [ ] Require password for write access to external storage (3) > [x] Ignore SCSI drives for auto mounting (4) > [x] Except optical drives (5) [x] Except usb drives (6) Regards, -- Nicolas Mailhot From rms at 1407.org Wed Jun 8 10:59:23 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Wed, 08 Jun 2005 11:59:23 +0100 Subject: OT: nVidia driver [was: Wish list] In-Reply-To: <42A61D6C.7060606@poolshark.org> References: <1118002724.9556.34.camel@Darkstar> <42A36449.80509@n-man.com> <1118043525.5652.9.camel@laptopd505.fenrus.org> <42A4BE05.9060105@poolshark.org> <1118093019.2468.42.camel@cutter> <6f6293f105060712576a17cde0@mail.gmail.com> <3609.10.10.10.24.1118176876.squirrel@linux1> <1118180290.7742.73.camel@mlenzdesktop> <3186.10.10.10.24.1118181192.squirrel@linux1> <42A61D6C.7060606@poolshark.org> Message-ID: <1118228363.2869.11.camel@roque> On Tue, 2005-06-07 at 15:19 -0700, Denis Leroy wrote: > That's a very naive thing to say. You can't deny the fact that people want > graphics hardware acceleration for various reasons, whether it's games, video > apps or openGL development. And you can't deny the fact that NVidia wants to hold that control ove the user. > Now F/OSS can't provide that, at least not yet, > and not well enough. Actually, it is NVidia who pretty much makes it near to impossible, and not lack of developer quality. Rui -- + 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...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.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 twaugh at redhat.com Wed Jun 8 12:09:30 2005 From: twaugh at redhat.com (Tim Waugh) Date: Wed, 8 Jun 2005 13:09:30 +0100 Subject: ESP Ghostscript 8.x for FC5 In-Reply-To: References: <200506081121.j58BL0gO020822@porkchop.devel.redhat.com> Message-ID: <20050608120930.GW8706@redhat.com> (Dropping fedora-test-list, since this is not relevant on that list.) ESP Ghostscript 8.15rc3 is now in the development tree. This is targetted at Fedora Core 5. Please help test it out and see if I've missed anything. I'm particularly interested in any regressions compared to the Fedora Core 4 package (ghostscript-7.07-40). On Wed, Jun 08, 2005 at 07:35:12AM -0400, Neal Becker wrote: > Transaction Check Error: file /usr/bin/bdftops from install of > ghostscript-8.1 > 5-0.rc3.1 conflicts with file from package ghostscript-7.07-40 > [Lots more similar conflicts] This is because you have something that still requires something that the old ghostscript provides. Do you have ImageMagick < 6.2.2.0-3 perhaps? Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Wed Jun 8 12:10:48 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 8 Jun 2005 14:10:48 +0200 (CEST) Subject: OT: nVidia driver [was: Wish list] -- understanding the GPU market In-Reply-To: <1118205816.4456.25.camel@bert64.mobile.smithconcepts.com> References: <20050608012857.4573B73725@hormel.redhat.com> <1118205816.4456.25.camel@bert64.mobile.smithconcepts.com> Message-ID: <29877.192.54.193.35.1118232648.squirrel@rousalka.dyndns.org> On Mer 8 juin 2005 6:43, Bryan J. Smith a ?crit : > We're not talking about a product that is released and modern for 2-5 > years. We're talking about a product that is _obsolete_ in less than > _12_months_! This is a very misleading statement. The core driver architecture has a much longer lifetime. Ati/NVidia are not adding a thin closed layer above a common core. They're systematicaly bastardising this common core to avoid having to distingish between the secret and public parts. In other words, they're lazy. Graphic cards are not the only parts in a computer with a short lifetime. Srangely other members of the industry have little problem standardising the hardware interface. Regards, -- Nicolas Mailhot From nicolas.mailhot at laposte.net Wed Jun 8 12:20:27 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 8 Jun 2005 14:20:27 +0200 (CEST) Subject: question about RedHat/Fedora and the GPL In-Reply-To: References: <20050606211730.GC28754@devserv.devel.redhat.com> <20050607021532.GA938160@hiwaay.net> <1118134855.2234.7.camel@laptop.mpeters.local> <1118148928.5721.24.camel@cutter> <604aa79105060719487c9d6c0a@mail.gmail.com> Message-ID: <63266.192.54.193.35.1118233227.squirrel@rousalka.dyndns.org> On Mer 8 juin 2005 8:41, condition terminal a ?crit : > So ignore a potentional violation because someone else is planning to > do the same thing, but better? There is _no_ violation. If I had to guess 90% of the problems you have in reproducing Red Hat builds is because of non-deterministic parts of beehive like in what order packages where queued by humans on the server, what was considered "core packages" at one point in time, incorrect/incomplete spec dependencies. If you want a totally deterministic and reproduceable system contribute one I'm sure Red Hat will be delighted to use it (not because they have to legally, but because they'd be mad not to) In other words : if the current tools suck it's not intentional and having them public will not make them suck less. Especially since there is already a public rewrite going on because Red Hat engineers (which have seen beehive internals) declared it a dead end for Fedora Extras (at least). -- Nicolas Mailhot From alan at redhat.com Wed Jun 8 12:22:33 2005 From: alan at redhat.com (Alan Cox) Date: Wed, 8 Jun 2005 08:22:33 -0400 Subject: OT: nVidia driver [was: Wish list] -- understanding the GPU market In-Reply-To: <1118205816.4456.25.camel@bert64.mobile.smithconcepts.com> References: <20050608012857.4573B73725@hormel.redhat.com> <1118205816.4456.25.camel@bert64.mobile.smithconcepts.com> Message-ID: <20050608122233.GE17703@devserv.devel.redhat.com> On Tue, Jun 07, 2005 at 11:43:36PM -0500, Bryan J. Smith wrote: > ATI should be commended for attempting to make a "clean room" DRI/ > GLX implementation. But eventually they had to give in, and started > withholding specifications as of R300 (Radeon 9500+). And even before, > many 2D and 3D interfaces were _never_ published by ATI. Actually its not quite as simple as some people may think here. ATI maintain a lot of stuff and help with many things. The lack of an ATI open R300 driver is at least partly certain Linux organisations fault for not taking up opportunities rather than ATI's. (and more I cannot say in public) > The concept that leading-edge video drivers will _ever_ be GPL is > very slim-to-none. And as far as the license, the drivers are Its more an inevitability than the reverse. Commoditisation means that very soon all the 'must keep secret' IP will be only relevant to real time ray tracing. What happens to the Radeon 9800 when Intel 9xx/VIA/etc graphics on chip are good enough for gamers. Leading-edge video will be for VR nuts. (And guess why Nvidia and ATI are in the chipset business nowdays) > the PCI Standards Group (AGP was _never_ a standard, but an Intel > trade secret of PCI), I hope Intel takes off some chains on nVidia. Hardly. AGP is a published open specification. People like nVidia do some really clever tricks with it for performance like the DMA contexts but nothing major we don't actually understand AFAIK. > There is some open source GLX code out there for both ATI and nVidia > -- but you're _never_ going to get the "cutting edge" under the model. Which would be why folks are currently just starting to sort out PCI express ATI radeons right now of course. Alan From ndbecker2 at gmail.com Wed Jun 8 12:21:23 2005 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 08 Jun 2005 08:21:23 -0400 Subject: ESP Ghostscript 8.x for FC5 References: <200506081121.j58BL0gO020822@porkchop.devel.redhat.com> <20050608120930.GW8706@redhat.com> Message-ID: Tim Waugh wrote: > (Dropping fedora-test-list, since this is not relevant on that list.) > > ESP Ghostscript 8.15rc3 is now in the development tree. This is > targetted at Fedora Core 5. Please help test it out and see if I've > missed anything. > > I'm particularly interested in any regressions compared to the Fedora > Core 4 package (ghostscript-7.07-40). > > On Wed, Jun 08, 2005 at 07:35:12AM -0400, Neal Becker wrote: > >> Transaction Check Error: file /usr/bin/bdftops from install of >> ghostscript-8.1 >> 5-0.rc3.1 conflicts with file from package ghostscript-7.07-40 >> [Lots more similar conflicts] > > This is because you have something that still requires something that > the old ghostscript provides. Do you have ImageMagick < 6.2.2.0-3 > perhaps? > > Tim. > */ rpm -q ImageMagick ImageMagick-6.2.2.0-3 ImageMagick-6.2.2.0-3 Any other suggestions? From alan at redhat.com Wed Jun 8 12:25:26 2005 From: alan at redhat.com (Alan Cox) Date: Wed, 8 Jun 2005 08:25:26 -0400 Subject: Firstboot: Module to add other OS partitions' entry to fstab In-Reply-To: <20050608102517.GA20620@ryoko.camperquake.de> References: <20050530085600.53686.qmail@web30801.mail.mud.yahoo.com> <1118144436.4246.31.camel@daxter.boston.redhat.com> <604aa791050607090853289862@mail.gmail.com> <1118161102.3926.39.camel@daxter.boston.redhat.com> <604aa79105060710267387fbb1@mail.gmail.com> <1118226119.14331.29.camel@daxter.boston.redhat.com> <20050608102517.GA20620@ryoko.camperquake.de> Message-ID: <20050608122526.GF17703@devserv.devel.redhat.com> On Wed, Jun 08, 2005 at 12:25:17PM +0200, Ralf Ertzinger wrote: > Is there any way to mount an unclean ext3 filesystem without writing > to it? There are some ugly ones using snapshots, basically snapshot it and fsck the snapshot. From mike at navi.cx Wed Jun 8 12:40:39 2005 From: mike at navi.cx (Mike Hearn) Date: Wed, 08 Jun 2005 13:40:39 +0100 Subject: Wish list References: <1118002724.9556.34.camel@Darkstar> <42A36449.80509@n-man.com> Message-ID: On Sun, 05 Jun 2005 22:31:31 +0100, Mike Hearn wrote: > - Auto update breaks nvidia drivers every few weeks I guess I should have added that this affects the open source NTFS drivers too. This isn't a black/white thing to do with proprietary vs open source drivers - anything that Red Hat choose not to ship for whatever reason (which they usually keep secret) is affected by it :/ From ndbecker2 at gmail.com Wed Jun 8 12:41:55 2005 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 08 Jun 2005 08:41:55 -0400 Subject: ESP Ghostscript 8.x for FC5 References: <200506081121.j58BL0gO020822@porkchop.devel.redhat.com> <20050608120930.GW8706@redhat.com> Message-ID: Tim Waugh wrote: > (Dropping fedora-test-list, since this is not relevant on that list.) > > ESP Ghostscript 8.15rc3 is now in the development tree. This is > targetted at Fedora Core 5. Please help test it out and see if I've > missed anything. > > I'm particularly interested in any regressions compared to the Fedora > Core 4 package (ghostscript-7.07-40). > > On Wed, Jun 08, 2005 at 07:35:12AM -0400, Neal Becker wrote: > >> Transaction Check Error: file /usr/bin/bdftops from install of >> ghostscript-8.1 >> 5-0.rc3.1 conflicts with file from package ghostscript-7.07-40 >> [Lots more similar conflicts] > > This is because you have something that still requires something that > the old ghostscript provides. Do you have ImageMagick < 6.2.2.0-3 > perhaps? > > Tim. > */ for file in $(rpm -q --whatrequires ghostscript); do echo "..." $file && ( rpm -q --requires$file | grep ghostscript; ); done ... ghostscript-fonts-5.50-13 ghostscript ... hpijs-1.7.1-3 ghostscript ... gnome-print-0.37-11 ghostscript ghostscript-fonts ... ghostscript-devel-7.07-40 ghostscript = 7.07-40 ... ghostscript-gtk-7.07-40 ghostscript = 7.07-40 ... system-config-printer-0.6.131-1 ghostscript >= 6.51-16 ... gsview-4.6-10 ghostscript >= 7.07-15.3 ... libgnomeprint22-2.10.3-1 ghostscript ghostscript-fonts ghostscript ghostscript-fonts ... libgnomeprint22-2.10.3-1 ghostscript ghostscript-fonts ghostscript ghostscript-fonts ... scribus-1.2.1-5 ghostscript >= 7.07 Looks like the culprits are ghostscript-fonts and ghostscript-gtk From sundaram at redhat.com Wed Jun 8 12:47:49 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 08 Jun 2005 18:17:49 +0530 Subject: Wish list In-Reply-To: References: <1118002724.9556.34.camel@Darkstar> <42A36449.80509@n-man.com> Message-ID: <42A6E8F5.9080009@redhat.com> Mike Hearn wrote: >On Sun, 05 Jun 2005 22:31:31 +0100, Mike Hearn wrote: > > >>- Auto update breaks nvidia drivers every few weeks >> >> > >I guess I should have added that this affects the open source NTFS drivers >too. This isn't a black/white thing to do with proprietary vs open source >drivers - anything that Red Hat choose not to ship for whatever reason >(which they usually keep secret) is affected by it :/ > > > One of the proposed goals for FC5 [1] is to provide to mechanism to package external kernel modules in a way that would keep them in sync and working together, so for GPL'ed kernel modules not include in the Fedora kernel or for modules where the proprietary vendor allows repackaging and redistribution this planned infrastructure could solve the problem regards Rahul [1] http://www.fedoraproject.org/wiki/FC5Future From fedora at camperquake.de Wed Jun 8 13:02:46 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 8 Jun 2005 15:02:46 +0200 Subject: Firstboot: Module to add other OS partitions' entry to fstab In-Reply-To: <41128.192.54.193.35.1118231662.squirrel@rousalka.dyndns.org> References: <20050530085600.53686.qmail@web30801.mail.mud.yahoo.com> <1118144436.4246.31.camel@daxter.boston.redhat.com> <604aa791050607090853289862@mail.gmail.com> <1118161102.3926.39.camel@daxter.boston.redhat.com> <604aa79105060710267387fbb1@mail.gmail.com> <1118226119.14331.29.camel@daxter.boston.redhat.com> <41128.192.54.193.35.1118231662.squirrel@rousalka.dyndns.org> Message-ID: <20050608130246.GC20620@ryoko.camperquake.de> On Wed, Jun 08, 2005 at 01:54:22PM +0200, Nicolas Mailhot wrote: > Modern systems have a complex life, parameters need to be changed at any > point of time, not only during 'initialisation'. This does not make asking for these parameters explicitly at the time the system comes up first a bad idea, doesn't it? From mattdm at mattdm.org Wed Jun 8 13:09:58 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 8 Jun 2005 09:09:58 -0400 Subject: OT: nVidia driver [was: Wish list] -- understanding the GPU market In-Reply-To: <20050608122233.GE17703@devserv.devel.redhat.com> References: <20050608012857.4573B73725@hormel.redhat.com> <1118205816.4456.25.camel@bert64.mobile.smithconcepts.com> <20050608122233.GE17703@devserv.devel.redhat.com> Message-ID: <20050608130958.GA6644@jadzia.bu.edu> On Wed, Jun 08, 2005 at 08:22:33AM -0400, Alan Cox wrote: > Its more an inevitability than the reverse. Commoditisation means that very > soon all the 'must keep secret' IP will be only relevant to real time > ray tracing. What happens to the Radeon 9800 when Intel 9xx/VIA/etc graphics > on chip are good enough for gamers. Leading-edge video will be for VR nuts. Yes -- this is what'll save us eventually. Remember when on-board sound was a joke and if you actually wanted to listen to something besides blips and beeps you bought an add-on sound card? Now, pretty much only people actually working with audio for a professional reason (or hardcore hobby reason) need to buy a sound card. This day will come with video too. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 79 degrees Fahrenheit. From sundaram at redhat.com Wed Jun 8 13:10:56 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 08 Jun 2005 18:40:56 +0530 Subject: Firstboot: Module to add other OS partitions' entry to fstab In-Reply-To: <20050608130246.GC20620@ryoko.camperquake.de> References: <20050530085600.53686.qmail@web30801.mail.mud.yahoo.com> <1118144436.4246.31.camel@daxter.boston.redhat.com> <604aa791050607090853289862@mail.gmail.com> <1118161102.3926.39.camel@daxter.boston.redhat.com> <604aa79105060710267387fbb1@mail.gmail.com> <1118226119.14331.29.camel@daxter.boston.redhat.com> <41128.192.54.193.35.1118231662.squirrel@rousalka.dyndns.org> <20050608130246.GC20620@ryoko.camperquake.de> Message-ID: <42A6EE60.1050909@redhat.com> Ralf Ertzinger wrote: >On Wed, Jun 08, 2005 at 01:54:22PM +0200, Nicolas Mailhot wrote: > > > >>Modern systems have a complex life, parameters need to be changed at any >>point of time, not only during 'initialisation'. >> >> > >This does not make asking for these parameters explicitly at the time >the system comes up first a bad idea, doesn't it? > > > Ok, there a couple of problems with this approach. * Firstboot is not available for non-graphical installations. Could be solvable using a first login wizard * The installer has been in general very easy to understand and follow. These type of questions are not easily understood by end users to make good choices on what to do. Might be better to just choose the "best" option as default and push these choices into a advanced section/ provide them with documentation and a easy way to change the options after the installation is complete. regards Rahul From nicolas.mailhot at laposte.net Wed Jun 8 13:19:15 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 8 Jun 2005 15:19:15 +0200 (CEST) Subject: Firstboot: Module to add other OS partitions' entry to fstab In-Reply-To: <20050608130246.GC20620@ryoko.camperquake.de> References: <20050530085600.53686.qmail@web30801.mail.mud.yahoo.com> <1118144436.4246.31.camel@daxter.boston.redhat.com> <604aa791050607090853289862@mail.gmail.com> <1118161102.3926.39.camel@daxter.boston.redhat.com> <604aa79105060710267387fbb1@mail.gmail.com> <1118226119.14331.29.camel@daxter.boston.redhat.com> <41128.192.54.193.35.1118231662.squirrel@rousalka.dyndns.org> <20050608130246.GC20620@ryoko.camperquake.de> Message-ID: <62243.192.54.193.35.1118236755.squirrel@rousalka.dyndns.org> On Mer 8 juin 2005 15:02, Ralf Ertzinger a ?crit : > On Wed, Jun 08, 2005 at 01:54:22PM +0200, Nicolas Mailhot wrote: > >> Modern systems have a complex life, parameters need to be changed at any >> point of time, not only during 'initialisation'. > > This does not make asking for these parameters explicitly at the time > the system comes up first a bad idea, doesn't it? If you provide a good tool to change them afterwards you do not need such "in the face" advertising. Just select good defaults like for everything else. Regards, -- Nicolas Mailhot From jspaleta at gmail.com Wed Jun 8 13:21:00 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 8 Jun 2005 09:21:00 -0400 Subject: question about RedHat/Fedora and the GPL In-Reply-To: References: <20050607021532.GA938160@hiwaay.net> <1118134855.2234.7.camel@laptop.mpeters.local> <1118148928.5721.24.camel@cutter> <604aa79105060719487c9d6c0a@mail.gmail.com> Message-ID: <604aa79105060806212a704fb4@mail.gmail.com> On 6/8/05, condition terminal wrote: > So ignore a potentional violation because someone else is planning to > do the same thing, but better? You asked for a concensous opinion about whether or not to continue to press forward with this. I've done exactly what you have asked, I gave you my opinion as to the worth of releasing rawhide. I think concensous has been reached in this thread.. and its contrary to your desire. I'm not qualified.. nor are you... to make a serious legal determination as to whether their is a violation in this space. I am quite confident that competent legal opinion both inside and outside of RedHat have look at this. I would be shocked if the fsf hadn't already made a determination with regard to the beehive situation. You are of course free to go ask the fsf about what they think about this situation. And while your on their site, make a donation ( https://www.fsf.org/donate/directed-donations/gpl.html ) that will go towards serious efforts by serious people to enforce gpl compliance. It's time to face facts, continued discussion on this list about your desire to compell the release of beehive is going to get you nowhere. Its time for this discussion to end here. If you believe there is a violation here its now time for you to find a competent legal opinion who is familiar with the gpl and begin a formal legal review. > Thats an interesting view point on possible GPL violations. No... actually... all ianal view points are uninteresting.. both mine and yours. -jef"i dare you to donate"spaleta From nicolas.mailhot at laposte.net Wed Jun 8 13:26:12 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 8 Jun 2005 15:26:12 +0200 (CEST) Subject: OT: nVidia driver [was: Wish list] -- understanding the GPU market In-Reply-To: <20050608130958.GA6644@jadzia.bu.edu> References: <20050608012857.4573B73725@hormel.redhat.com> <1118205816.4456.25.camel@bert64.mobile.smithconcepts.com> <20050608122233.GE17703@devserv.devel.redhat.com> <20050608130958.GA6644@jadzia.bu.edu> Message-ID: <20387.192.54.193.35.1118237172.squirrel@rousalka.dyndns.org> On Mer 8 juin 2005 15:09, Matthew Miller a ?crit : > On Wed, Jun 08, 2005 at 08:22:33AM -0400, Alan Cox wrote: >> Its more an inevitability than the reverse. Commoditisation means that >> very >> soon all the 'must keep secret' IP will be only relevant to real time >> ray tracing. What happens to the Radeon 9800 when Intel 9xx/VIA/etc >> graphics >> on chip are good enough for gamers. Leading-edge video will be for VR >> nuts. > > Yes -- this is what'll save us eventually. Remember when on-board sound > was > a joke and if you actually wanted to listen to something besides blips and > beeps you bought an add-on sound card? And this card is widely supported (by Alsa...). Nowadays you can almost choose a card based on the performance of its chips, not the brokeness of its closed driver (though for some high-end audio stuff, people still choose harware based on the quality of its windows driver, on a "sucks less" basis) Regards, -- Nicolas Mailhot From ndbecker2 at gmail.com Wed Jun 8 13:19:53 2005 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 08 Jun 2005 09:19:53 -0400 Subject: ESP Ghostscript 8.x for FC5 References: <200506081121.j58BL0gO020822@porkchop.devel.redhat.com> <20050608120930.GW8706@redhat.com> Message-ID: Neal Becker wrote: > Tim Waugh wrote: > >> (Dropping fedora-test-list, since this is not relevant on that list.) >> >> ESP Ghostscript 8.15rc3 is now in the development tree. This is >> targetted at Fedora Core 5. Please help test it out and see if I've >> missed anything. >> >> I'm particularly interested in any regressions compared to the Fedora >> Core 4 package (ghostscript-7.07-40). >> >> On Wed, Jun 08, 2005 at 07:35:12AM -0400, Neal Becker wrote: >> >>> Transaction Check Error: file /usr/bin/bdftops from install of >>> ghostscript-8.1 >>> 5-0.rc3.1 conflicts with file from package ghostscript-7.07-40 >>> [Lots more similar conflicts] >> >> This is because you have something that still requires something that >> the old ghostscript provides. Do you have ImageMagick < 6.2.2.0-3 >> perhaps? >> >> Tim. >> */ > for file in $(rpm -q --whatrequires ghostscript); do echo "..." $file && > ( rpm -q --requires$file | grep ghostscript; ); done > ... ghostscript-fonts-5.50-13 > ghostscript > ... hpijs-1.7.1-3 > ghostscript > ... gnome-print-0.37-11 > ghostscript > ghostscript-fonts > ... ghostscript-devel-7.07-40 > ghostscript = 7.07-40 > ... ghostscript-gtk-7.07-40 > ghostscript = 7.07-40 > ... system-config-printer-0.6.131-1 > ghostscript >= 6.51-16 > ... gsview-4.6-10 > ghostscript >= 7.07-15.3 > ... libgnomeprint22-2.10.3-1 > ghostscript > ghostscript-fonts > ghostscript > ghostscript-fonts > ... libgnomeprint22-2.10.3-1 > ghostscript > ghostscript-fonts > ghostscript > ghostscript-fonts > ... scribus-1.2.1-5 > ghostscript >= 7.07 > > Looks like the culprits are ghostscript-fonts and ghostscript-gtk > Sorry, that's ghostscript-devel and ghostscript-gtk. From twaugh at redhat.com Wed Jun 8 13:28:25 2005 From: twaugh at redhat.com (Tim Waugh) Date: Wed, 8 Jun 2005 14:28:25 +0100 Subject: ESP Ghostscript 8.x for FC5 In-Reply-To: References: <200506081121.j58BL0gO020822@porkchop.devel.redhat.com> <20050608120930.GW8706@redhat.com> Message-ID: <20050608132825.GX8706@redhat.com> On Wed, Jun 08, 2005 at 08:41:55AM -0400, Neal Becker wrote: > Looks like the culprits are ghostscript-fonts and ghostscript-gtk No, ghostscript-gtk is upgraded too, and ghostscript-fonts just requires 'ghostscript'. Try again with libgs.so or something. FWIW, 'rpm -Fvh ...' worked fine for me. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Wed Jun 8 13:30:33 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 8 Jun 2005 09:30:33 -0400 Subject: Firstboot: Module to add other OS partitions' entry to fstab In-Reply-To: <62243.192.54.193.35.1118236755.squirrel@rousalka.dyndns.org> References: <20050530085600.53686.qmail@web30801.mail.mud.yahoo.com> <1118144436.4246.31.camel@daxter.boston.redhat.com> <604aa791050607090853289862@mail.gmail.com> <1118161102.3926.39.camel@daxter.boston.redhat.com> <604aa79105060710267387fbb1@mail.gmail.com> <1118226119.14331.29.camel@daxter.boston.redhat.com> <41128.192.54.193.35.1118231662.squirrel@rousalka.dyndns.org> <20050608130246.GC20620@ryoko.camperquake.de> <62243.192.54.193.35.1118236755.squirrel@rousalka.dyndns.org> Message-ID: <604aa791050608063074a6970e@mail.gmail.com> On 6/8/05, Nicolas Mailhot wrote: > If you provide a good tool to change them afterwards you do not need such > "in the face" advertising. Just select good defaults like for everything Ah.. but how do you make sure people are aware of the new good tool? and sadly i think this is one of those system-wide features that can benefit from install-time or firstboot configuration depending on the role the machine is playing. As long as good defaults.. mean safe defaults I'm happier. If the data corruption situations that david mentioned can be prevented my important concerns over the question of defaults disappears. Shaking out the lingering data corruption situations should be something targetted for the early fc5 test releases if this feature is implemented and turned on by default in the test releases. Everything else is murky trade-offs about defaults versus feature discovery, a category of questions we don't have a general answer for. -jef From twaugh at redhat.com Wed Jun 8 13:31:13 2005 From: twaugh at redhat.com (Tim Waugh) Date: Wed, 8 Jun 2005 14:31:13 +0100 Subject: ESP Ghostscript 8.x for FC5 In-Reply-To: References: <200506081121.j58BL0gO020822@porkchop.devel.redhat.com> <20050608120930.GW8706@redhat.com> Message-ID: <20050608133113.GY8706@redhat.com> On Wed, Jun 08, 2005 at 09:19:53AM -0400, Neal Becker wrote: > Sorry, that's ghostscript-devel and ghostscript-gtk. But they are both sub-packages of ghostscript, and so should both be updated as well as ghostscript. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From brugolsky at telemetry-investments.com Wed Jun 8 13:33:01 2005 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Wed, 8 Jun 2005 09:33:01 -0400 Subject: Testing RPM dependencies [was Re: ESP Ghostscript 8.x for FC5] In-Reply-To: References: <200506081121.j58BL0gO020822@porkchop.devel.redhat.com> <20050608120930.GW8706@redhat.com> Message-ID: <20050608133300.GF20486@ti64.telemetry-investments.com> On Wed, Jun 08, 2005 at 08:41:55AM -0400, Neal Becker wrote: > for file in $(rpm -q --whatrequires ghostscript); do echo "..." $file && > ( rpm -q --requires$file | grep ghostscript; ); done I find it much easier to let rpm show me the dependencies: sudo rpm --test -e ghostscript I seem to recall hearing some noises at some point (perhaps from Jeff Johnson) that one ought not to do this, but I've never had a problem with it. Bill Rugolsky From fedora at camperquake.de Wed Jun 8 13:35:27 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 8 Jun 2005 15:35:27 +0200 Subject: Testing RPM dependencies [was Re: ESP Ghostscript 8.x for FC5] In-Reply-To: <20050608133300.GF20486@ti64.telemetry-investments.com> References: <200506081121.j58BL0gO020822@porkchop.devel.redhat.com> <20050608120930.GW8706@redhat.com> <20050608133300.GF20486@ti64.telemetry-investments.com> Message-ID: <20050608133527.GD20620@ryoko.camperquake.de> On Wed, Jun 08, 2005 at 09:33:01AM -0400, Bill Rugolsky Jr. wrote: > sudo rpm --test -e ghostscript > > I seem to recall hearing some noises at some point (perhaps from Jeff Johnson) > that one ought not to do this, but I've never had a problem with it. Well, you could drop the "sudo". rpm -e --test works fine as a normal user. From jspaleta at gmail.com Wed Jun 8 13:37:52 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 8 Jun 2005 09:37:52 -0400 Subject: ESP Ghostscript 8.x for FC5 In-Reply-To: <20050608133113.GY8706@redhat.com> References: <200506081121.j58BL0gO020822@porkchop.devel.redhat.com> <20050608120930.GW8706@redhat.com> <20050608133113.GY8706@redhat.com> Message-ID: <604aa79105060806371da5479c@mail.gmail.com> On 6/8/05, Tim Waugh wrote: > On Wed, Jun 08, 2005 at 09:19:53AM -0400, Neal Becker wrote: > > > Sorry, that's ghostscript-devel and ghostscript-gtk. > > But they are both sub-packages of ghostscript, and so should both be > updated as well as ghostscript. Does he perhaps have some odd multilib issue? My x86 system installs the ghostscript fine. His x86_64 system might be running into a 32bit/64bit parallel package install issue. He might need to coax the arch information out of rpm when doing any queries to make sense of it. -jef From ndbecker2 at gmail.com Wed Jun 8 13:42:28 2005 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 08 Jun 2005 09:42:28 -0400 Subject: ESP Ghostscript 8.x for FC5 References: <200506081121.j58BL0gO020822@porkchop.devel.redhat.com> <20050608120930.GW8706@redhat.com> <20050608133113.GY8706@redhat.com> Message-ID: Tim Waugh wrote: > On Wed, Jun 08, 2005 at 09:19:53AM -0400, Neal Becker wrote: > >> Sorry, that's ghostscript-devel and ghostscript-gtk. > > But they are both sub-packages of ghostscript, and so should both be > updated as well as ghostscript. > > Tim. > */ This is x86_64 system, so it's a little more complicated. There are both i386 and x86_64 ghostscript. Any more ideas on debugging this? I'm sure this is not just a problem for my setup, it should give the same result on any x86_64 system with everything installed. From twaugh at redhat.com Wed Jun 8 13:55:06 2005 From: twaugh at redhat.com (Tim Waugh) Date: Wed, 8 Jun 2005 14:55:06 +0100 Subject: ESP Ghostscript 8.x for FC5 In-Reply-To: <604aa79105060806371da5479c@mail.gmail.com> References: <200506081121.j58BL0gO020822@porkchop.devel.redhat.com> <20050608120930.GW8706@redhat.com> <20050608133113.GY8706@redhat.com> <604aa79105060806371da5479c@mail.gmail.com> Message-ID: <20050608135506.GZ8706@redhat.com> On Wed, Jun 08, 2005 at 09:37:52AM -0400, Jeff Spaleta wrote: > Does he perhaps have some odd multilib issue? My x86 system installs > the ghostscript fine. His x86_64 system might be running into a > 32bit/64bit parallel package install issue. He might need to coax the > arch information out of rpm when doing any queries to make sense of > it. Ah, I bet it's because of this: $ rpm -qp --provides ghostscript-8.15-0.rc3.1.x86_64.rpm X11.so()(64bit) config(ghostscript) = 8.15-0.rc3.1 libgs.so.8()(64bit) libijs-0.35.so()(64bit) libijs.so ghostscript = 8.15-0.rc3.1 I had to put 'Provides: libijs.so' in the spec file explicitly, because for some reason it is not picked up automatically. Of course, for the x86_64 package it should be libijs.so()(64bit). Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Wed Jun 8 13:55:27 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 8 Jun 2005 09:55:27 -0400 Subject: ESP Ghostscript 8.x for FC5 In-Reply-To: References: <200506081121.j58BL0gO020822@porkchop.devel.redhat.com> <20050608120930.GW8706@redhat.com> <20050608133113.GY8706@redhat.com> Message-ID: <604aa79105060806557e10877a@mail.gmail.com> On 6/8/05, Neal Becker wrote: > This is x86_64 system, so it's a little more complicated. There are both > i386 and x86_64 ghostscript. Any more ideas on debugging this? I'm sure > this is not just a problem for my setup, it should give the same result on > any x86_64 system with everything installed. do you have something installed that specifically needs the 32bit ghostscript on your system? If i were a betting man, I bet that you can isolate it to the 32bit ghostscript not being updated as well or something. If you can get the 32bit version uninstalled.. does the yum update go smoothly? I dont have 64bit hardware so I can't directly help with confirming or troubleshooting this. -jef" me: I'd like to buy a 64bit amd computer her: why? me: to uhm.. help other people on the internet troubleshoot theirs her: "spaleta From ndbecker2 at gmail.com Wed Jun 8 14:11:28 2005 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 08 Jun 2005 10:11:28 -0400 Subject: ESP Ghostscript 8.x for FC5 References: <200506081121.j58BL0gO020822@porkchop.devel.redhat.com> <20050608120930.GW8706@redhat.com> <20050608133113.GY8706@redhat.com> <604aa79105060806371da5479c@mail.gmail.com> <20050608135506.GZ8706@redhat.com> Message-ID: Tim Waugh wrote: > On Wed, Jun 08, 2005 at 09:37:52AM -0400, Jeff Spaleta wrote: > >> Does he perhaps have some odd multilib issue? My x86 system installs >> the ghostscript fine. His x86_64 system might be running into a >> 32bit/64bit parallel package install issue. He might need to coax the >> arch information out of rpm when doing any queries to make sense of >> it. > > Ah, I bet it's because of this: > > $ rpm -qp --provides ghostscript-8.15-0.rc3.1.x86_64.rpm > X11.so()(64bit) > config(ghostscript) = 8.15-0.rc3.1 > libgs.so.8()(64bit) > libijs-0.35.so()(64bit) > libijs.so > ghostscript = 8.15-0.rc3.1 > > I had to put 'Provides: libijs.so' in the spec file explicitly, > because for some reason it is not picked up automatically. Of course, > for the x86_64 package it should be libijs.so()(64bit). > > Tim. > */ If you can provide me a fixed package I'd be happy to try it. From kyrre at solution-forge.net Wed Jun 8 14:29:08 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Wed, 08 Jun 2005 16:29:08 +0200 Subject: question about RedHat/Fedora and the GPL In-Reply-To: <200506061622.28649.symbiont@berlios.de> References: <1118040569.5652.2.camel@laptopd505.fenrus.org> <200506061622.28649.symbiont@berlios.de> Message-ID: <1118240948.3354.4.camel@localhost.localdomain> man, 06.06.2005 kl. 10.22 skrev Jeff Pitman: > On Monday 06 June 2005 15:48, condition terminal wrote: > > OK then.. so how are the files and scripts used to control the > > building of the rpms outside the specs excluded from the conditions > > of the GPL? > > Think of beehive as an over-glorified cron system. If you use cron to > do a daily checkout from CVS and build a system, that doesn't mean you > need to release the source code to cron for every release of your > software. You could even use some proprietary cron setup and still not > be obligated to release it. > -- > -jeff From kyrre at solution-forge.net Wed Jun 8 14:30:44 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Wed, 08 Jun 2005 16:30:44 +0200 Subject: question about RedHat/Fedora and the GPL In-Reply-To: <200506061622.28649.symbiont@berlios.de> References: <1118040569.5652.2.camel@laptopd505.fenrus.org> <200506061622.28649.symbiont@berlios.de> Message-ID: <1118241043.3354.6.camel@localhost.localdomain> man, 06.06.2005 kl. 10.22 skrev Jeff Pitman: > On Monday 06 June 2005 15:48, condition terminal wrote: > > OK then.. so how are the files and scripts used to control the > > building of the rpms outside the specs excluded from the conditions > > of the GPL? > > Think of beehive as an over-glorified cron system. If you use cron to > do a daily checkout from CVS and build a system, that doesn't mean you > need to release the source code to cron for every release of your > software. You could even use some proprietary cron setup and still not > be obligated to release it. > -- > -jeff Sorry for dup., hit send a bit to early... And then there is people building GPL software with Closed-Source tools such as the MS compiler... Does that make MS obligated to release their compiler as GPL? Just curious... That would be fun. Kyrre From byte at aeon.com.my Tue Jun 7 23:10:25 2005 From: byte at aeon.com.my (Colin Charles) Date: Tue, 07 Jun 2005 16:10:25 -0700 Subject: What next? In-Reply-To: <1117724404.3361.13.camel@tower.toronto.redhat.com> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <1117662394.31018.80.camel@cutter> <1117724404.3361.13.camel@tower.toronto.redhat.com> Message-ID: <1118185825.20494.24.camel@arena.soho.bytebot.net> On Thu, 2005-06-02 at 11:00 -0400, Jeff Pound wrote: > > > What about making it possible for non-text users to use yum? They > > > shouldn't be kept out of such a great tool :) > > > > it's a work-in-progress. > > Speaking of which, is there a project page or hacking guide for pup? > (or > maybe a feature reqs doc) Besides whats in CVS (at elvis), and Paul's talk from FUDCon 1 (at fedoraproject.org), none that I know of -- Colin Charles, http://www.bytebot.net/ From byte at aeon.com.my Wed Jun 8 12:34:27 2005 From: byte at aeon.com.my (Colin Charles) Date: Wed, 08 Jun 2005 05:34:27 -0700 Subject: Making update functionality more usable (Was: Re: What next?) In-Reply-To: <1118048011.2779.2.camel@roque> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <1117730130.1674.3.camel@weasel.laiskiainen.org> <429FDACF.20608@rueb.com> <1117780095.3488.32.camel@cutter> <1117809250.8385.11.camel@mlenzdesktop> <1118024411.3011.11.camel@bree.local.net> <1118048011.2779.2.camel@roque> Message-ID: <1118234067.20494.39.camel@arena.soho.bytebot.net> On Mon, 2005-06-06 at 09:53 +0100, Rui Miguel Seabra wrote: > > > I hate to admit it but I remove all the redhat update stuff as well and > > > use yum or apt-get (if i'm feeling impatient). I used ubuntu for awhile > > > (but ultimately found fedora to be superior) and found their update > > > functionality much more usable. > > > > Since one of the goals of FC5 is to have pup in place to handle updates > > from a graphical point of view, I'd be interested in hearing what sorts > > of things made the Ubuntu stuff more usable. Or the same for other > > distros as well. Just to make it clear, Ubuntu just has: dpkg/apt, Synaptic, and update-notifier, right? We (will) have: rpm/yum, s-c-packages(okay, pup), and pup's update-notifier > The update-notifier is wonderfull. IIRC, pup is to have an update-notifier as well (it will suck less memory than rhn-applet, I'm assured) > I have a translator using Ubuntu, and the way the icon *only* shows it > self when there are updates was enough to make her go check it out. > When she was trying Fedora, that didn't happen. The icon was always > there, and making it flash wasn't appealing enough. Ah, icons. We should keep this in mind during FC-5 then -- Colin Charles, http://www.bytebot.net/ From byte at aeon.com.my Wed Jun 8 13:07:35 2005 From: byte at aeon.com.my (Colin Charles) Date: Wed, 08 Jun 2005 06:07:35 -0700 Subject: What next? In-Reply-To: <20050604210402.GE3329@mclink.it> References: <200506021630.48520@carola.nyarlathotep> <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <20050604210402.GE3329@mclink.it> Message-ID: <1118236055.20494.42.camel@arena.soho.bytebot.net> On Sat, 2005-06-04 at 23:04 +0200, M. Fioretti wrote: > > I go OO.o after two hours of Emacs, hit C-x C-W to save, canceling > whatever was highlighted and being asked if I want to close the file > without saving. You can change OOo's keybindings to that of Emacs, if you so incline. Its an XML file edit away... -- Colin Charles, http://www.bytebot.net/ From mattdm at mattdm.org Wed Jun 8 15:29:54 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 8 Jun 2005 11:29:54 -0400 Subject: What next? In-Reply-To: <1118185825.20494.24.camel@arena.soho.bytebot.net> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <1117662394.31018.80.camel@cutter> <1117724404.3361.13.camel@tower.toronto.redhat.com> <1118185825.20494.24.camel@arena.soho.bytebot.net> Message-ID: <20050608152954.GA12995@jadzia.bu.edu> On Tue, Jun 07, 2005 at 04:10:25PM -0700, Colin Charles wrote: > > Speaking of which, is there a project page or hacking guide for pup? (or > > maybe a feature reqs doc) > Besides whats in CVS (at elvis), and Paul's talk from FUDCon 1 (at > fedoraproject.org), none that I know of There was a document on , but it's gone now. (Not for pup, but for some system-config-packages replacement.) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 79 degrees Fahrenheit. From mfioretti at mclink.it Wed Jun 8 15:59:51 2005 From: mfioretti at mclink.it (M. Fioretti) Date: Wed, 8 Jun 2005 17:59:51 +0200 Subject: What next? In-Reply-To: <1118236055.20494.42.camel@arena.soho.bytebot.net> References: <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <20050604210402.GE3329@mclink.it> <1118236055.20494.42.camel@arena.soho.bytebot.net> Message-ID: <20050608155951.GA3392@mclink.it> On Wed, Jun 08, 2005 06:07:35 AM -0700, Colin Charles (byte at aeon.com.my) wrote: > On Sat, 2005-06-04 at 23:04 +0200, M. Fioretti wrote: > > > > I go OO.o after two hours of Emacs, hit C-x C-W to save, canceling > > whatever was highlighted and being asked if I want to close the > > file without saving. > > You can change OOo's keybindings to that of Emacs, if you so > incline. Its an XML file edit away... I'd probably prefer to make Emacs behave as OO.o and others, but thanks, I will look into this. However (IIRC), I was making a general point, that is the fact that, for users integration is often something very different, and simpler, than what developers and packagers struggle to do. Thanks again, Marco -- Marco Fioretti mfioretti, at the server mclink.it Fedora Core 3 for low memory http://www.rule-project.org/ Excuse me for being greedy, but I want freedom and good government. Both a flourishing economy and a well-cared-for earth. A society that is diverse and communal.. that offers both privacy and accountability. One that can afford a big conscience, along with lots of neat toys. -- David Brin -- The Transparent Society From thebs413 at earthlink.net Wed Jun 8 19:42:42 2005 From: thebs413 at earthlink.net (Bryan J. Smith ) Date: Wed, 8 Jun 2005 14:42:42 -0500 (GMT-05:00) Subject: OT: nVidia driver [was: Wish list] -- understanding the GPU market Message-ID: <24352831.1118259763177.JavaMail.root@wamui-chisos.atl.sa.earthlink.net> Alan Cox wrote: > The lack of an ATI open R300 driver is at least partly certain Linux > organisations fault for not taking up opportunities rather than ATI's. > (and more I cannot say in public) Thanx for that insight. > Commoditisation means that very soon all the 'must keep secret' IP > will be only relevant to real time ray tracing. What happens to the > Radeon 9800 when Intel 9xx/VIA/etc graphics on chip are good enough > for gamers. Leading-edge video will be for VR nuts. > (And guess why Nvidia and ATI are in the chipset business nowdays) Another good insight. Of course, I still see the GPU market with a good 3-5 years more of Triple-Moore's Law, unlike CPUs. In reality, people should be interested in vendors like 3DLabs who want to keep OpenGL pure. > Hardly. AGP is a published open specification. People like nVidia do some > really clever tricks with it for performance like the DMA contexts but nothing > major we don't actually understand AFAIK. Well, from what I understand, there are many unpublished aspects to AGP, ones that only Intel licensees have, or have been reverse engineered. And nVidia is legally bound by those and not to work on a reverse engineered version. Same deal with the NIC in their nForce chipset, and why they release the nvnet driver, but can't officially work on the forcedeth. > Which would be why folks are currently just starting to sort out PCI express > ATI radeons right now of course. Exactomundo. The GPU market is a catch-22 when it comes to commodity, at least for awhile. But it is very nice to see Fedora Core 3 install DRI/GLX out-of-the-box on a i855GM in a notebook. -- Bryan J. Smith mailto:b.j.smith at ieee.org From dfarning at sbcglobal.net Wed Jun 8 19:43:29 2005 From: dfarning at sbcglobal.net (david) Date: Wed, 08 Jun 2005 14:43:29 -0500 Subject: Mirror monitor for meta data repos In-Reply-To: <604aa79105060812262a76f7bb@mail.gmail.com> References: <42A5B7E5.5040707@sbcglobal.net> <604aa791050607091570d2d535@mail.gmail.com> <42A5D093.2080208@sbcglobal.net> <604aa791050607100717e0dcd1@mail.gmail.com> <42A5E0C4.4090703@sbcglobal.net> <604aa79105060711261dafbc5b@mail.gmail.com> <42A5EFCB.1050101@sbcglobal.net> <604aa791050607131426a5742d@mail.gmail.com> <42A7431F.7020706@sbcglobal.net> <604aa79105060812262a76f7bb@mail.gmail.com> Message-ID: <42A74A61.8040703@sbcglobal.net> Jeff Spaleta wrote: >Hopefully you can tell the difference between >a mirror that is full from mirrors that are just plain dead via the >messages the servers return back to your process. Full mirrors that >can't be probed shouldn't be marked in the same way as dead mirrors. >I have no problem informing users that a mirror is full in the >webpage. But full mirrors shouldnt be removed from the dynamically >created mirrorlist nor should users be encouraged to contact a >mirror-admin if the mirror is full instead of dead and unresponsive. > > >-jef > > Yes, my probes, written in c, return the http error codes as exits codes. These codes should let us determine pretty well the status of the mirror. Now, to figure how to slurp the exit codes along with the return values into perl. -dtf From kewley at gps.caltech.edu Wed Jun 8 19:45:17 2005 From: kewley at gps.caltech.edu (David Kewley) Date: Wed, 8 Jun 2005 12:45:17 -0700 Subject: ESP Ghostscript 8.x for FC5 In-Reply-To: References: <200506081121.j58BL0gO020822@porkchop.devel.redhat.com> <20050608120930.GW8706@redhat.com> Message-ID: <200506081245.17896.kewley@gps.caltech.edu> On Wednesday 08 June 2005 05:41, Neal Becker wrote: > Tim Waugh wrote: > > On Wed, Jun 08, 2005 at 07:35:12AM -0400, Neal Becker wrote: > >> Transaction Check Error: file /usr/bin/bdftops from install of > >> ghostscript-8.1 > >> 5-0.rc3.1 conflicts with file from package ghostscript-7.07-40 > >> [Lots more similar conflicts] > > > > This is because you have something that still requires something > > that the old ghostscript provides. Do you have ImageMagick < > > 6.2.2.0-3 perhaps? Might this bit be particularly relevant? > ghostscript = 7.07-40 > ... system-config-printer-0.6.131-1 David From arjanv at redhat.com Wed Jun 8 19:49:00 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 08 Jun 2005 21:49:00 +0200 Subject: OT: nVidia driver [was: Wish list] -- understanding the GPU market In-Reply-To: <24352831.1118259763177.JavaMail.root@wamui-chisos.atl.sa.earthlink.net> References: <24352831.1118259763177.JavaMail.root@wamui-chisos.atl.sa.earthlink.net> Message-ID: <1118260141.9541.5.camel@laptopd505.fenrus.org> > > Same deal with the NIC in their nForce chipset, and why they release > the nvnet driver, but can't officially work on the forcedeth. they actually work on it (well provide patches) so I don't buy this bit ;) -------------- 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 Wed Jun 8 19:26:40 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 8 Jun 2005 15:26:40 -0400 Subject: Mirror monitor for meta data repos In-Reply-To: <42A7431F.7020706@sbcglobal.net> References: <42A5B7E5.5040707@sbcglobal.net> <604aa791050607091570d2d535@mail.gmail.com> <42A5D093.2080208@sbcglobal.net> <604aa791050607100717e0dcd1@mail.gmail.com> <42A5E0C4.4090703@sbcglobal.net> <604aa79105060711261dafbc5b@mail.gmail.com> <42A5EFCB.1050101@sbcglobal.net> <604aa791050607131426a5742d@mail.gmail.com> <42A7431F.7020706@sbcglobal.net> Message-ID: <604aa79105060812262a76f7bb@mail.gmail.com> On 6/8/05, david wrote: > Concerning the time issue, I was thinking that I was not clear about the > point that my probes operate in parallel. Thus, dealing with the > network latency issue. Yeah that wasn't clear initially.. but after i saw your time numbers i assumed it was parallel. Even in parallel.. if mirrors are full and not accepting connections.. there will be timeouts and several re-connection attempts needed... this takes finite time. Hopefully you can tell the difference between a mirror that is full from mirrors that are just plain dead via the messages the servers return back to your process. Full mirrors that can't be probed shouldn't be marked in the same way as dead mirrors. I have no problem informing users that a mirror is full in the webpage. But full mirrors shouldnt be removed from the dynamically created mirrorlist nor should users be encouraged to contact a mirror-admin if the mirror is full instead of dead and unresponsive. -jef From dfarning at sbcglobal.net Wed Jun 8 19:12:31 2005 From: dfarning at sbcglobal.net (david) Date: Wed, 08 Jun 2005 14:12:31 -0500 Subject: Mirror monitor for meta data repos In-Reply-To: <604aa791050607131426a5742d@mail.gmail.com> References: <42A5B7E5.5040707@sbcglobal.net> <604aa791050607091570d2d535@mail.gmail.com> <42A5D093.2080208@sbcglobal.net> <604aa791050607100717e0dcd1@mail.gmail.com> <42A5E0C4.4090703@sbcglobal.net> <604aa79105060711261dafbc5b@mail.gmail.com> <42A5EFCB.1050101@sbcglobal.net> <604aa791050607131426a5742d@mail.gmail.com> Message-ID: <42A7431F.7020706@sbcglobal.net> Jeff Spaleta wrote: >I'm still interested to watch how long it takes for you to do a full >run on a heavy load day with updates like the day after a release. Hey >look there is one right around the corner. Hopefully you'll do a few >timed runs of that 200+ mirror update check in that 48 period after >release and get a better feel for how bad it can get and show me my >concerns are completely unjustified. > >-jef > Concerning the time issue, I was thinking that I was not clear about the point that my probes operate in parallel. Thus, dealing with the network latency issue. If I increase the max parallel probes to 250 my test box becomes cpu rather than network bound. thanks -dtf From vonbrand at inf.utfsm.cl Wed Jun 8 18:33:46 2005 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Wed, 08 Jun 2005 14:33:46 -0400 Subject: ESP Ghostscript 8.x for FC5 In-Reply-To: Your message of "Wed, 08 Jun 2005 10:11:28 -0400." Message-ID: <200506081833.j58IXk9Q007336@laptop11.inf.utfsm.cl> [...] My x86-64 also complained about ghostscript. It had the following i386 packages installed: ghostscript, ImageMagick, ImageMagick-c++. Deleting them let the update go through. A glitch in the multi-arch handling? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From enrico.scholz at informatik.tu-chemnitz.de Wed Jun 8 19:52:04 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 08 Jun 2005 21:52:04 +0200 Subject: Firefox crippling In-Reply-To: <1118109568.3119.8.camel@jellyfish.redfishdemo.com> (Rodd Clarkson's message of "Tue, 07 Jun 2005 11:59:28 +1000") References: <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <87ekbhxfih.fsf@kosh.bigo.ensc.de> <20050605161545.GA28581@devserv.devel.redhat.com> <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> <42A471CC.70905@redhat.com> <87slzv2x24.fsf@kosh.bigo.ensc.de> <42A492C7.3090809@redhat.com> <87oeaj2ve6.fsf@kosh.bigo.ensc.de> <1118109568.3119.8.camel@jellyfish.redfishdemo.com> Message-ID: <87wtp48w4b.fsf@kosh.bigo.ensc.de> rodd at clarkson.id.au (Rodd Clarkson) writes: >> >> I do not care whether Windoze or Emacs keybindings are the default >> >> ones (as long as they can be configured). As expressed several >> >> times, I am just pissed off by the Gnome2 practice to *override* >> >> existing installations with their ideas of usability. >> > >> > So take your complaints up with the GNOME guys >> >> does not make fun... they always say: "only we are right, we are the >> gods of usability, you are just a stupid user who does not have the >> faintest idea about usability"... > > Personally, I've filed dozens of usability bugs against gnome and for > the most part they have been taken very seriously. Do you remember the spartial window management in nautilus? It was a completely experimental feature, it was tried only by a very small userbase before, there were lot of critical voices against it -- and the Gnome2 developers actived it without providing a way to turn it off, and it was activated on every existing system. Ditto for epiphany -- its experimental bookmark management was never proved to be useful but everybody was forced to use it. Or metacity... there are lot of wishes which are all rejected because configurability is assumed as evil by Gnome2 developers. Or the ~/.Xmodmap + ~/.Xresources files: Gnome2 developers do not accept that people want to configure their system by these methods and there does not exist a way to stop Gnome2 to override the settings of these files; only stupid suggestions to delete/edit files in /usr/share/... (which will be overridden by the next auto-update). Or the recent firefox discussions... there are lot of critical voices against the Gnomeification but they are rejected without giving a reason or responding to other suggestions. Altogether, Gnome2 is a very unergonomic piece of software. Userfriendly software should adapt to the user, but with Gnome2 the user has to adapt to the software. This is caused by the refusal of Gnome2 developers to allow configuration of their software and the frequent changes of the user interface. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From vonbrand at inf.utfsm.cl Wed Jun 8 17:36:00 2005 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Wed, 08 Jun 2005 13:36:00 -0400 Subject: Wish list In-Reply-To: Your message of "Wed, 08 Jun 2005 13:40:39 +0100." Message-ID: <200506081736.j58Ha1aO006501@laptop11.inf.utfsm.cl> Mike Hearn wrote: > On Sun, 05 Jun 2005 22:31:31 +0100, Mike Hearn wrote: > > - Auto update breaks nvidia drivers every few weeks > I guess I should have added that this affects the open source NTFS drivers > too. This isn't a black/white thing to do with proprietary vs open source > drivers - anything that Red Hat choose not to ship for whatever reason > (which they usually keep secret) is affected by it :/ I'm not happy either, but I can understand the (probable) reason behind this: If you are in doubt that shipping $SOMETHING might be illegal, better just don't ship and shut up. That way $THEY can't later claim that RH warned the community about the legal problem, that RH considered breaking the law (now /that/ would make SCOXes day! not that such considering and deciding not to do it because of whatever reasons (including legal ones) must be commonplace...), and/or that RH agrees with them that shipping $SOMETHING is illegal or whatever. AFAIU in the case of NTFS it is that as there is no write support (just picture at all the users screaming they can't write to their Hasefroch partition...), and using the alternative (Win drivers via captive) might be legally dubious, better abstain completely. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From davej at redhat.com Wed Jun 8 17:59:16 2005 From: davej at redhat.com (Dave Jones) Date: Wed, 8 Jun 2005 13:59:16 -0400 Subject: OT: nVidia driver [was: Wish list] -- understanding the GPU market In-Reply-To: <20050608122233.GE17703@devserv.devel.redhat.com> References: <20050608012857.4573B73725@hormel.redhat.com> <1118205816.4456.25.camel@bert64.mobile.smithconcepts.com> <20050608122233.GE17703@devserv.devel.redhat.com> Message-ID: <20050608175915.GB876@redhat.com> On Wed, Jun 08, 2005 at 08:22:33AM -0400, Alan Cox wrote: > Which would be why folks are currently just starting to sort out PCI express > ATI radeons right now of course. FWIW, I picked up a PCI-E Radeon X300 for not-many-beans recently. It works out of the box with FC4, with no need for proprietory drivers. The 3d isn't supported yet (See reverse engineering effort I mentioned in earlier mail), but for 2D its a damn good card. I never thought I'd say I'd find a better dual-head card than a Matrox, but this thing really shines. Dave From enrico.scholz at informatik.tu-chemnitz.de Wed Jun 8 16:31:19 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 08 Jun 2005 18:31:19 +0200 Subject: What next? In-Reply-To: <1118236055.20494.42.camel@arena.soho.bytebot.net> (Colin Charles's message of "Wed, 08 Jun 2005 06:07:35 -0700") References: <200506021630.48520@carola.nyarlathotep> <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <20050604210402.GE3329@mclink.it> <1118236055.20494.42.camel@arena.soho.bytebot.net> Message-ID: <873brsajzc.fsf@kosh.bigo.ensc.de> byte at aeon.com.my (Colin Charles) writes: >> I go OO.o after two hours of Emacs, hit C-x C-W to save, canceling >> whatever was highlighted and being asked if I want to close the file >> without saving. > > You can change OOo's keybindings to that of Emacs, if you so incline. Really? Does OOo support multi-keystroke actions (e.g. 'C-x C-s' for save)? Enrico From vonbrand at inf.utfsm.cl Wed Jun 8 17:41:47 2005 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Wed, 08 Jun 2005 13:41:47 -0400 Subject: ESP Ghostscript 8.x for FC5 In-Reply-To: Your message of "Wed, 08 Jun 2005 08:41:55 -0400." Message-ID: <200506081741.j58HflOI006584@laptop11.inf.utfsm.cl> Neal Becker wrote: > Tim Waugh wrote: > > ESP Ghostscript 8.15rc3 is now in the development tree. This is > > targetted at Fedora Core 5. Please help test it out and see if I've > > missed anything. > > > > I'm particularly interested in any regressions compared to the Fedora > > Core 4 package (ghostscript-7.07-40). > > > > On Wed, Jun 08, 2005 at 07:35:12AM -0400, Neal Becker wrote: > > > >> Transaction Check Error: file /usr/bin/bdftops from install of > >> ghostscript-8.1 > >> 5-0.rc3.1 conflicts with file from package ghostscript-7.07-40 > >> [Lots more similar conflicts] > > > > This is because you have something that still requires something that > > the old ghostscript provides. Do you have ImageMagick < 6.2.2.0-3 > > perhaps? > > > > Tim. > > */ > for file in $(rpm -q --whatrequires ghostscript); do echo "..." $file && > ( rpm -q --requires$file | grep ghostscript; ); done > ... ghostscript-fonts-5.50-13 > ghostscript > ... hpijs-1.7.1-3 > ghostscript > ... gnome-print-0.37-11 > ghostscript > ghostscript-fonts > ... ghostscript-devel-7.07-40 > ghostscript = 7.07-40 > ... ghostscript-gtk-7.07-40 > ghostscript = 7.07-40 > ... system-config-printer-0.6.131-1 > ghostscript >= 6.51-16 > ... gsview-4.6-10 > ghostscript >= 7.07-15.3 > ... libgnomeprint22-2.10.3-1 > ghostscript > ghostscript-fonts > ghostscript > ghostscript-fonts > ... libgnomeprint22-2.10.3-1 > ghostscript > ghostscript-fonts > ghostscript > ghostscript-fonts > ... scribus-1.2.1-5 > ghostscript >= 7.07 I've got ghostscript installed fine here, up-to-date what used to be FC4t3 [Any chance that this might be changed to "Rawhide" or whatever in the fedora-release package?]. > Looks like the culprits are ghostscript-fonts and ghostscript-gtk [vonbrand at laptop11 linux-2.6.git]$ rpm -q ghostscript-fonts ghostscript-gtk ghostscript-fonts-5.50-13 package ghostscript-gtk is not installed Just installed ghostscript-gtk-8.15-0.rc3.1 without a hitch. Hope this helps- -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From mhw at wittsend.com Wed Jun 8 17:15:22 2005 From: mhw at wittsend.com (Michael H. Warfield) Date: Wed, 08 Jun 2005 13:15:22 -0400 Subject: [PATCH] mkinitrd rescue mode - now crypto In-Reply-To: <1118081184.9625.5.camel@localhost.localdomain> References: <1117653405.12259.51.camel@barsoom.rdu.redhat.com> <1117725836.3768.15.camel@bree.local.net> <1117731994.12259.68.camel@barsoom.rdu.redhat.com> <1118081184.9625.5.camel@localhost.localdomain> Message-ID: <1118250922.5299.60.camel@localhost.localdomain> Ok... Time for a variation on a theme. I'm also in the middle of doing some similar type stuff in initrd. Modified the subject to reflect a change in direction On Mon, 2005-06-06 at 14:06 -0400, Peter Jones wrote: > On Thu, 2005-06-02 at 13:06 -0400, Jeffrey Layton wrote: > > > This does increase the memory profile of the initramfs by about 1.5M. > > Isn't that memory freed after the switchroot occurs, though? > It isn't currently freed. There's a plan for how to free it within the > switchroot command, but I haven't had the time to implement it. Ouch! I thought the kernel was suppose to be doing this already. Wasn't that what the big discussion was on the kernel mailing list about "Double free of initramfs" back in March? So, if we add stuff to the initrd, we just have to delete it all before calling switchroot? Not freeing that memory seems like a bug. I'm using this for a more sophisticated scenario. Basically, I'm using it to run with my laptop hard drives totally encrypted, including the root and swap partitions, through dm_crypt and booted from a USB pendrive/key/flash/whatever (possibly CD-Rom as well). To accomplish that, I needed to add cryptsetup and busybox to the initrd (plus any modules for USB for any USB devices like USB keyboards and SCSI if I want to mount the flash while in initrd space). Busybox needed to be rebuilt with a few different options, like adding losetup (so I can decrypt a luks encrypted keyblob image) and switching from msh to ash (msh is borked - gag). Then just add a single line hook into the "init" nash script to run "crytpsetup.sh" which was also added into bin (and cryptsetup.sh has an optional drop to shell for doing maintenance on the crypto from initrd). Only reason I seem to need nash at all, right now, is for the "makerootdev" command and the "switchroot" command (busybox has pivot_root, but not switchroot, and I can ignore the "setquiet" noise). With those two functions, I could dump nash entirely and operate totally from busybox with a minimal increase in size. Which raises some other questions regarding busybox... Originally, I was using the static busybox from the Adios bootable CD flavor of FC (based on FC3). That was built with ash and wasn't much bigger than nash (about 10K larger). If I could eliminate nash, the size difference would have been relatively small. But, busybox doesn't have that "makerootdev" or mount by LABEL= (AFAICT) or switchroot, so it's an add on, rather that a replace. Sigh... Then I tried switching to the stock FC version of busybox. Static version, built from the SRPM, is over twice as large as the Adios version (gag!)... I yet haven't gone through it, option by option, to figure out just WHAT is bloating busybox like that. But I had to modify busybox anyways, since neither version included losetup, which I definitely needed. Busybox in Fedora Core seems to be built with msh and not ash. But I've found several normal "sh" type things that work just fine under "ash" but just flat out don't work properly in "msh". Example: cat /proc/partitions | while read major minor blocks name do : done and while read major minor blocks name do : done < /proc/partitions Under msh, the first iteration in the loop works and I get the correct values. All subsequent iterations return null in all the variables although the number of iterations is correct. That's not the only instance of normal "sh" type structures that fail on msh but work with ash. I also had some troubles with some odd VARBLE=`command` type substitutions that didn't seem to do the right thing. So it seems like msh is buggy. So I rebuilt the FC flavor of busybox to dump msh and add ash and add ash as sh. And the scripts then work once again. And busybox got smaller (a bit smaller). Ok... So msh is busted for certain legitimate sh constructs and it's fatter than ash. Why is msh being used instead of ash? What does msh do (I can't find ANY doco on msh) that ash doesn't? There must be something good and useful about it or why would it be there? Right now, I've got a script that runs the stock "mkinitrd" called to add the appropriate modules to be loaded. It then unpacks the resulting initrd archive and adds cryptsetup (which is already static) and the static busybox, plus my files and finally hooks init to call the crypto script. Then I repack the initrd file and it's done. I'd definitely like it to be smaller and I'm definitely going to add some rm's in there to get rid of anything other than nash in bin before running "switchroot" but it's now working rock solid. Any idea when the switchroot thing will be fixed to completely free up the initramfs thing? > > If you update to a new kernel, and that kernel isn't detecting your > > drives correctly, then that is very difficult to troubleshoot once you > > boot to a rescue kernel. > How often is that a real problem? I don't think I've seen any > significant number of bug reports on this in recent memory. In my case, with encrypting the drives, I'm into this area every time my laptop boots. I travel internationally for speaking engagements and we consider this an important feature. I'm also working up a talk for some Linux shows (maybe LinuxWorld where I regularly speak) and groups on doing this. There seems to be some significant interest, judging from comments I've heard back from the Atlanta Linux Enthusiasts group, especially after some of the headlines about stolen laptops and lost hard drives resulting in confidential information (like customer and client data) leaking out. :-) I'll be making the various scripts publicly available once I get past a few cleanups and write some maintenance scripts and get past my first talk on the subject (July 14 in Atlanta as things stand right now). > -- > Peter > Mike -- Michael H. Warfield | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part URL: From denis at poolshark.org Wed Jun 8 17:07:15 2005 From: denis at poolshark.org (Denis Leroy) Date: Wed, 08 Jun 2005 10:07:15 -0700 Subject: OT: nVidia driver [was: Wish list] In-Reply-To: <604aa7910506071803712fa32f@mail.gmail.com> References: <1118002724.9556.34.camel@Darkstar> <42A4BE05.9060105@poolshark.org> <1118093019.2468.42.camel@cutter> <6f6293f105060712576a17cde0@mail.gmail.com> <3609.10.10.10.24.1118176876.squirrel@linux1> <1118180290.7742.73.camel@mlenzdesktop> <3186.10.10.10.24.1118181192.squirrel@linux1> <42A61D6C.7060606@poolshark.org> <4167.10.10.10.24.1118184241.squirrel@linux1> <9f50a7a005060717213c76b518@mail.gmail.com> <604aa7910506071803712fa32f@mail.gmail.com> Message-ID: <42A725C3.6000509@poolshark.org> Jeff Spaleta wrote: > do you know exactly how responsible nvidia is for > the state of nv driver development that is available as part of X? > Perhaps, more than perhaps.. nv could also be claimed as their driver > too. Maybe the disparity in functionality between the nv driver and > the closed nvidia driver is delibrate. Maybe the developers provided > as much functionality in the open nv driver as the feel they can do > and its not so much a decision that the engineers are actively making > as it is a set of legal opinions and or business decisions > constraining their actions. Or maybe they are just twisted evil > dwarves who like watching the drivers break as the kernel development > churns forward. That's an interesting point to consider, but you have to understand that NVidia is a company, and therefore is only interested in two things: profits and market share. All NVidia wants is to own the Linux market share (and they pretty much do), because even if it's only half a percent or so of the desktop market, it's half a percent they would rather own over ATI in the ultra-competitive graphics market. With that perspective in mind, it makes no sense from a business point of view for NVidia to somehow deliberately sabotage or slow down the progress of the nv GPL driver: after all their closed-source driver is free, all they want is for linux people to buy their cards... It's also in their best interest to have a solid GPL unaccelerated nv driver in Xorg, so that things like graphics installer will work... -denis From thebs413 at earthlink.net Wed Jun 8 20:01:18 2005 From: thebs413 at earthlink.net (Bryan J. Smith ) Date: Wed, 8 Jun 2005 15:01:18 -0500 (GMT-05:00) Subject: OT: nVidia driver [was: Wish list] Message-ID: <28134358.1118260879139.JavaMail.root@wamui-chisos.atl.sa.earthlink.net> Sean wrote: > If you're going to undermine the integrity of your system and the open > source process at the same time, you're better off just going back and > using Windows. Actually, do whatever you want personally, but don't > spread this bad advice here. Sean also wrote: > It's pretty annoying listening to all the newcomers unthinkingly thumb > their nose at what got us to where we are today. You simply can't move > Linux forward by undermining exactly what makes it important and > successful. You know Sean, you're right. About 5 years ago, I sure wish the entire, multi-_billion_ dollar CAM and EDA markets would have just switched their codebases to Win32/DX once-and-for-all, and gotten away from POSIX/GLX because nVidia shouldn't have even offered a proprietary GLX solution for Linux. No offense Sean, but I think it's pretty annoying to listen to people who don't realize that without a proprietary GLX driver on Linux, a lot of CAM and EDA vendors wouldn't have ported to Linux from Irix, Solaris, etc... and would have just taken the time and effort to port to Win32/DX _never_ to return to POSIX/GLX. That was 5+ years ago, and we have nVidia to thank for keeping these critical applications in the POSIX/GLX space. That's the difference between _choosing_ to work with a community and having this overriding, overbearing "we the community know better than you" attitude that is Step #1 in the communist manifesto. Sometimes there are factors and considerations where a less-than- commodity innovation requires you to understand why there is a need for _temporary_ IP, copyright and other, proprietary concessions. > Anyway, choosing a binary driver has real risks involved. If you value > the data in your computer, you understand the open source process, and > you're thankful for the great O/S that you find yourself using; the > decisions become rather easy. No, this is _very_different_. We are talking a proprietary driver for an _open_standard_, GLX. We're not talking about 3dfx Glide (before 3dfx/nVidia they opened it), or any other proprietary APIs (although there are OpenGL ARB and OpenGL vendor extensions -- which I won't get into, although I agree with 3DLab's viewpoints, but at least it's not as bad as in the DirectX world, God help us ;-). That's what I think people forget. They get on this "open" v. "proprietary" religious war and they don't think about the fact that there are lots and lots of _good_ projects and companies in between GNU/Linux and Microsoft. It's like watching a Democrat and a Republican argue here in the US like they are the _only_2_ viewpoints, forgetting everything from Communist to Libertarians, etc... who just roll their eyes sometimes. Which is why I call the nVidia drivers as "Standardware" in my 2-axis, 4-extreme model: - Freedomware** (Open Source, Open Standard) - Standardware (Proprietary Source, Open Standard) - Sourceware (Open Source, Proprietary Standard -- e.g., IP requirements) - Commerceware (Proprietary Source, Proprietary Standard) [ **NOTE: I must prefer the term "Freedomware" to "Free Software," "Open Source Software" or the latest FOSS acronym. Why? Because you say "FOSS" and people give you a dumb stare. And if you say "Free Software" or "Freeware" or whatever, people get the wrong idea, possibly even "Shareware." But when you say "Freedomware," people instantly think that they are responsible for their part in ensuring it, and that ain't always "free as in cost." ;-] And even in that model, Microsoft doesn't fit. Because Microsoft adovcates what I call "intentional Hostageware": - Hostageware (Unmaintainable Source, Unmaintainable Standard) Hostageware can result from _any_ of the 4 above software. Using eccentric, underdocumented, etc... formats can result in Hostageware from Freedomware as much as any other. But our case, we are talking about a proprietary driver that provides interfaces for _open_standard_ GLX! Sorry, the whole "data hostage" junk doesn't hold. And you need to be a little more "open minded." Otherwise people like yourself just make me thing of what I also break down Freedomware into: - Freedomware: choosing to work together on Open Source/Standard - Commuware: forcing everyone to work on Open Source/Standard Freedom only works when people have the right to choose. -- Bryan P.S. I am a _huge_ fan of Red Hat's dedication to the GPL, and constantly defend Red Hat against unfair, uneven comments when companies like IBM get praise for spending $1B on maturing their product line, $100M for porting a 100% Commerceware application suite to Linux, and donations of GPL _in_compatible CPL/IPL software. But damn, sometimes people forget that we don't get all huffy on Red Hat about trademarks (which is a bigger story than most people care about), cut throat business tactics, etc... Why? Because Red Hat is dedicated to the GPL and community where it _legally_ can. nVidia is pretty much in the same boat too. Or do I have to remind people that nVidia _did_ release GLX source code back in the XFree 3.3.x days? This issue is very long and drawn out. -- Bryan J. Smith mailto:b.j.smith at ieee.org From thebs413 at earthlink.net Wed Jun 8 20:03:18 2005 From: thebs413 at earthlink.net (Bryan J. Smith ) Date: Wed, 8 Jun 2005 15:03:18 -0500 (GMT-05:00) Subject: OT: nVidia driver [was: Wish list] -- understanding the GPU market Message-ID: <22993738.1118260998572.JavaMail.root@wamui-chisos.atl.sa.earthlink.net> From: Arjan van de Ven > they actually work on it (well provide patches) so I don't buy this > bit ;) Okay, maybe their legal standing has changed since the last time I looked at this (about 2+ years ago). Thanks for the heads-up. >From everyone I know at nVidia, when they don't go GPL or MIT, their hands are legally tied. Kinda like Red Hat on the trademark proliferation issue that some people don't stop to understand, and just want to demonize Red Hat on. Companies have their legal reasons in many cases, and they can't do much about it. -- Bryan J. Smith mailto:b.j.smith at ieee.org From thebs413 at earthlink.net Wed Jun 8 20:12:12 2005 From: thebs413 at earthlink.net (Bryan J. Smith ) Date: Wed, 8 Jun 2005 15:12:12 -0500 (GMT-05:00) Subject: OT: nVidia driver [was: Wish list] -- understanding the GPU market Message-ID: <32673398.1118261532967.JavaMail.root@wamui-hound.atl.sa.earthlink.net> Little Davie Jones wrote: > FWIW, I picked up a PCI-E Radeon X300 for not-many-beans recently. > It works out of the box with FC4, with no need for proprietory drivers. > The 3d isn't supported yet ... Please replace "PCI-E Radeon X300" with "PCI-E GeForce 6800" and retype that and it will be the _exact_same_ logic. nVidia _does_ put people on the MIT "nv" driver, and 2D _does_ work with their newest NV4x series of cards -- typically in about the same development time as the ATI "radeon" and other drivers. Also note that the X300 is a prior series R300, and not the latest R400. It's like comparing to a GeForce FX5700LE. I think people forget that nVidia gives you the option of using the MIT drivers for 2D only, and the proprietary drivers with 2D+GLX. The 2D drivers work very good _if_ your GPU logic is supported, just like the MIT ATI drivers as well. And there is some UtahGLX and other support for nVidia as well. I think people tend to demonize nVidia when they give you just the _option_ to go 3D/GLX. And ATI is definitely _not_ a good poster child against nVidia. 3DLabs would be a better consideration as they push are for full OpenGL compliance with no extensions or after-the-fact ARB extensions. -- Bryan J. Smith mailto:b.j.smith at ieee.org From richardl at redhat.com Wed Jun 8 20:23:01 2005 From: richardl at redhat.com (Richard Li) Date: Wed, 08 Jun 2005 16:23:01 -0400 Subject: Firefox crippling In-Reply-To: <87wtp48w4b.fsf@kosh.bigo.ensc.de> References: <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <87ekbhxfih.fsf@kosh.bigo.ensc.de> <20050605161545.GA28581@devserv.devel.redhat.com> <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> <42A471CC.70905@redhat.com> <87slzv2x24.fsf@kosh.bigo.ensc.de> <42A492C7.3090809@redhat.com> <87oeaj2ve6.fsf@kosh.bigo.ensc.de> <1118109568.3119.8.camel@jellyfish.redfishdemo.com> <87wtp48w4b.fsf@kosh.bigo.ensc.de> Message-ID: <42A753A5.7090703@redhat.com> >Altogether, Gnome2 is a very unergonomic piece of software. Userfriendly >software should adapt to the user, but with Gnome2 the user has to adapt >to the software. This is caused by the refusal of Gnome2 developers to >allow configuration of their software and the frequent changes of the >user interface. > > Any claim like this should probably start with a definition of user ;-). I would imagine that someone who does, say, marketing, would never configure their desktop (for better or worse). From seanlkml at sympatico.ca Wed Jun 8 20:23:41 2005 From: seanlkml at sympatico.ca (Sean) Date: Wed, 8 Jun 2005 16:23:41 -0400 (EDT) Subject: OT: nVidia driver [was: Wish list] In-Reply-To: <28134358.1118260879139.JavaMail.root@wamui-chisos.atl.sa.earthlink.ne t> References: <28134358.1118260879139.JavaMail.root@wamui-chisos.atl.sa.earthlink.net> Message-ID: <1383.10.10.10.24.1118262221.squirrel@linux1> On Wed, June 8, 2005 4:01 pm, Bryan J. Smith said: > About 5 years ago, I sure wish the entire, multi-_billion_ dollar > CAM and EDA markets would have just switched their codebases to > Win32/DX once-and-for-all, and gotten away from POSIX/GLX > because nVidia shouldn't have even offered a proprietary GLX > solution for Linux. > > No offense Sean, but I think it's pretty annoying to listen to people > who don't realize that without a proprietary GLX driver on Linux, > a lot of CAM and EDA vendors wouldn't have ported to Linux from Irix, > Solaris, etc... and would have just taken the time and effort to port > to Win32/DX _never_ to return to POSIX/GLX. There are clearly cases where the benefit of using a proprietary solution outweigh the risks involved. However, there are _way_ too many people making excuses for abandoning open source. Many of whom seem motivated by brand loyalty without any concern for system integrity or overall viability of open source alternatives. These bloody zealots for nVidia are every bit as much engaged in religion (or not) as the supporters of open source software (ie. both are just supporting what they believe in). Anyway, my comments were not about abolishing personal choice or in denying the existence of _exceptional_ cases, rather as a counterbalance to the unthinking there-is-no-cost-at-all-in-using-binary-modules mentality. That applies both in terms of system integrity and the social implications. Sean. From davej at redhat.com Wed Jun 8 20:43:11 2005 From: davej at redhat.com (Dave Jones) Date: Wed, 8 Jun 2005 16:43:11 -0400 Subject: OT: nVidia driver [was: Wish list] -- understanding the GPU market In-Reply-To: <32673398.1118261532967.JavaMail.root@wamui-hound.atl.sa.earthlink.net> References: <32673398.1118261532967.JavaMail.root@wamui-hound.atl.sa.earthlink.net> Message-ID: <20050608204311.GN876@redhat.com> On Wed, Jun 08, 2005 at 03:12:12PM -0500, Bryan J. Smith wrote: > Little Davie Jones wrote: > > FWIW, I picked up a PCI-E Radeon X300 for not-many-beans recently. > > It works out of the box with FC4, with no need for proprietory drivers. > > The 3d isn't supported yet ... > > Please replace "PCI-E Radeon X300" with "PCI-E GeForce 6800" and > retype that and it will be the _exact_same_ logic. Except the GeForce doesn't have any possibility of working 3d any time soon, whereas the X300 does have a good chance. > nVidia _does_ put people on the MIT "nv" driver, and 2D _does_ work > with their newest NV4x series of cards -- typically in about the same > development time as the ATI "radeon" and other drivers. It's somewhat different in reality. The nvidia involvement in nv is one engineer in his spare time when he feels like it. NVIDIA don't actually employ him to do nv development, and theres no commitment whatsoever from Nvidia to enhance it further. (I don't think he actually does work on their binary 3d driver any more either coincidentally). > Also note that the X300 is a prior series R300, and not the latest > R400. It's like comparing to a GeForce FX5700LE. As I mentioned in an earlier mail, at best we're going to be one generation behind. > And there is some UtahGLX and other support for nVidia as well. Which for modern Xorg based servers is next to useless. That code has festered in UtahGLX for years, and no-one seems interested in doing anything with it. Dave From thebs413 at earthlink.net Wed Jun 8 20:44:22 2005 From: thebs413 at earthlink.net (Bryan J. Smith ) Date: Wed, 8 Jun 2005 15:44:22 -0500 (GMT-05:00) Subject: OT: nVidia driver [was: Wish list] Message-ID: <16231728.1118263463122.JavaMail.root@wamui-rustique.atl.sa.earthlink.net> From: Sean > There are clearly cases where the benefit of using a proprietary solution > outweigh the risks involved. By "proprietary" do you mean proprietary "source", or "standard" or both? See how quickly the over-simplification of "open" v. "proprietary" can get? I don't like the fact that the nVidia "nvidia" driver is proprietary any more than you do, but there are sound, legal reasons for it (even if I'm not aware of all the latest developments -- I just remember the ones from the XFree86 3.3.x nVidia GLX release fiasco, as well as the initial nvnet drivers, etc...). At the same time, at least *1* person was unaware that most of the latest nVidia GeForce 6000 series card (NV40, 42, 43, 45, etc...) work "out-of-the-box" with Fedora Core 4, and even the 6800 (NV40) did with Fedora Core 3. I know, I loaded it on an Athlon64 PCIe GeForce 6800GT and bam! It worked solid at 2D. ATI is _no_better_ than nVidia, and they have only more recently joined them on the "unified driver" approach and are 3+ years behind. > However, there are _way_ too many people making excuses for > abandoning open source. Many of whom seem motivated > by brand loyalty without any concern for system integrity or overall > viability of open source alternatives. And I agree with you. IBM gets far too much credit right now, while people demonize them. Heck, even Sun gets demonized compared to IBM, and people don't stop to think that IBM and Sun aren't much different when it comes to licenses -- and at least Sun gave us StarOffice/OpenOffice.org with a dual-license that includes LGPL. > These bloody zealots for nVidia are every bit as much engaged in > religion (or not) as the supporters of open source software (ie. both > are just supporting what they believe in). No offense, but I _am_ as much of an "apologist" for nVidia as Red Hat, because there _are_ legal issues involved. Whether it's NDAs or trademarks, sometimes the hands of people are tied by 3rd party, Common Law, etc... Eventually these details _will_ get commodity. I already appreciate the fact that more and more chipset-integrated GPUs are supported out-of-the-box by GLX. I spent 20 months in the semiconductor industry, and have many colleagues at both ATI and nVidia. I was there when the whole portage of CAM and EDA tools to Linux happened, as nVidia started offering quality GLX support for Linux. A lot of vendors already had "lite" versions running on Win32/GLX (via X11 emulation), and were working on Win32/DX ports. But once Linux opened up an "economies-of-scale" POSIX/GLX platform, those vendors went to Linux instead. It's not the game market -- it was the CAM/EDA market that put nVidia where it's at. Games are chump change in the Linux realm. Sure, Sony is going to change that, and GNU is already the development platform outside of Microsoft for games. But the reality is that most people are completely oblivious of how important it was for an viable, performance capable GLX solution to be available for Linux before the mass ports started to Win32/DX. > Anyway, my comments were not about abolishing personal choice or in > denying the existence of _exceptional_ cases, rather as a counterbalance > to the unthinking there-is-no-cost-at-all-in-using-binary-modules > mentality. I don't think _anyone_ is saying that. I think people are just tired of ATI being "held up high" or other vendors when nVidia _does_ put a number of people on the MIT 2D drivers. I typically find that XFree/Xorg works _better_ out-of-the-box on newer nVidia cards than ATI -- and the lag between release date is not much different at all (typically in nVidia's favor). Yes, sometimes there are new cards of a new nVidia NV3x or NV4x series that aren't supported in the MIT drivers until the next XFree/Xorg revision. But same deal for ATI! Same deal for Matrox! Same deal for a number of vendors! In fact, Matrox isn't open either. Now from what I understand, the AGPgart and memory logic in nVidia's kernel driver is becoming more open, because Intel just freed nVidia of some contractual obligations on some of their more NDA stuff. I don't have all the details, because I'm not privy to them, but it explains a lot. > That applies both in terms of system integrity and the social > implications. Agreed. But understand not all of us are "ignorant" of them. In fact, we are no more "ignorant" of them than those who are "ignorant" of the benefit nVidia provided by having a GLX option in lieu of virtually no other viable solution. And the last time I checked, even the Freedomware BSD/MIT GLX implementations aren't the best in stability either. Which is how this whole thread started -- people complaining its the proprietary model. The reality is that we're talking about products being released and obsoleted so fast that the drivers don't have time to mature -- be they proprietary or open! ;-> -- Bryan J. Smith mailto:b.j.smith at ieee.org From thebs413 at earthlink.net Wed Jun 8 20:49:37 2005 From: thebs413 at earthlink.net (Bryan J. Smith ) Date: Wed, 8 Jun 2005 15:49:37 -0500 (GMT-05:00) Subject: OT: nVidia driver [was: Wish list] -- understanding the GPU market Message-ID: <5432516.1118263778044.JavaMail.root@wamui-rustique.atl.sa.earthlink.net> From: Dave Jones > Except the GeForce doesn't have any possibility of working 3d > any time soon, whereas the X300 does have a good chance. You _do_ know that there is some DRI/UtahGLX for nVidia, correct? I'm glad to see that some people are reverse engineering ATI R300+ since ATI started withholding the specs, but that just means that they aren't doing anything more than nVidia. > It's somewhat different in reality. The nvidia involvement in nv > is one engineer in his spare time when he feels like it. > NVIDIA don't actually employ him to do nv development, and theres > no commitment whatsoever from Nvidia to enhance it further. (I don't > think he actually does work on their binary 3d driver any more either > coincidentally). I'm sure he doesn't. But then again, ATI isn't exactly helping either. > As I mentioned in an earlier mail, at best we're going to be one > generation behind. I disagree. The NV40 (GF6800) was supported rather quickly after release. I've typically seen nVidia support for specific core/cards in the 2D MIT within 2-3 months. It's nice to boot a card that is not very old on a new distro and have it come up, working, and the docs say the specific revision is supported, so there are no quirks. > Which for modern Xorg based servers is next to useless. > That code has festered in UtahGLX for years, and no-one seems > interested in doing anything with it. I'm sure one of the reasons why people aren't sponsoring DRI development for nVidia is because they view it as redundant compared to nVidia's Standardware drivers. All I'm saying is that there's a "double standard" that is applied to nVidia versus ATI, and that's what most of us are complaining about. It's like watching the same "double standard" applied to Red Hat versus IBM, which makes me curious. ;-> -- Bryan J. Smith mailto:b.j.smith at ieee.org From thacker at math.cornell.edu Wed Jun 8 20:55:27 2005 From: thacker at math.cornell.edu (John Thacker) Date: Wed, 8 Jun 2005 16:55:27 -0400 Subject: Firefox crippling In-Reply-To: <42A753A5.7090703@redhat.com> References: <87ekbhxfih.fsf@kosh.bigo.ensc.de> <20050605161545.GA28581@devserv.devel.redhat.com> <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> <42A471CC.70905@redhat.com> <87slzv2x24.fsf@kosh.bigo.ensc.de> <42A492C7.3090809@redhat.com> <87oeaj2ve6.fsf@kosh.bigo.ensc.de> <1118109568.3119.8.camel@jellyfish.redfishdemo.com> <87wtp48w4b.fsf@kosh.bigo.ensc.de> <42A753A5.7090703@redhat.com> Message-ID: <20050608205527.GA10700@thacker.dyndns.org> On Wed, Jun 08, 2005 at 04:23:01PM -0400, Richard Li wrote: > > >Altogether, Gnome2 is a very unergonomic piece of software. Userfriendly > >software should adapt to the user, but with Gnome2 the user has to adapt > >to the software. This is caused by the refusal of Gnome2 developers to > >allow configuration of their software and the frequent changes of the > >user interface. > > > Any claim like this should probably start with a definition of user ;-). > > I would imagine that someone who does, say, marketing, would never > configure their desktop (for better or worse). Yes, and shipping a large combination of software with dramatically different icons and keyboard shortcuts for the same tasks forces a user to adapt to the software, and can hardly be considered user friendly. I agree that user configuration should be allowed (and I believe that the gconf setting that turns off spatial Nautilus was available right at the release of GNOME 2.6.0, not that using gconf is user friendly). However, while changing an application from its original defaults to something consistent with other applications does force people who have gotten used to the original application to adapt, having a bunch of inconsistent applications also forces users to adapt too. So long as experienced users can configure things if they want to, I think that consistency across the desktop is a much better default. It makes things easier for the people who are most likely to have trouble, people seeing things for the first time. Experienced users are more likely to be able to figure out how to set their configuration. John Thacker -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From davej at redhat.com Wed Jun 8 20:59:21 2005 From: davej at redhat.com (Dave Jones) Date: Wed, 8 Jun 2005 16:59:21 -0400 Subject: OT: nVidia driver [was: Wish list] -- understanding the GPU market In-Reply-To: <5432516.1118263778044.JavaMail.root@wamui-rustique.atl.sa.earthlink.net> References: <5432516.1118263778044.JavaMail.root@wamui-rustique.atl.sa.earthlink.net> Message-ID: <20050608205921.GA12749@redhat.com> On Wed, Jun 08, 2005 at 03:49:37PM -0500, Bryan J. Smith wrote: > From: Dave Jones > > Except the GeForce doesn't have any possibility of working 3d > > any time soon, whereas the X300 does have a good chance. > > You _do_ know that there is some DRI/UtahGLX for nVidia, correct? The newest Nvidia card the utahGLX code supported last I looked was TNT/GeForce256, which makes it pretty useless for any NVIDIA card made in the last 4-5 years. > All I'm saying is that there's a "double standard" that is applied > to nVidia versus ATI, and that's what most of us are complaining > about. It's like watching the same "double standard" applied > to Red Hat versus IBM, which makes me curious. ;-> I'm not endorsing ATIs business methods / development decisions over NVIDIAs. The point I'm making is that of the two, the R300 is the most modern core with working 3D in opensource drivers. There is no double standard. I dislike both binary drivers equally[*] Dave [*] Well, actually, I dislike ATIs slightly more over the mess they made of welding the kernel agpgart to their driver, but thats moot for this discussion. From perbj at stanford.edu Wed Jun 8 21:01:46 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Wed, 08 Jun 2005 14:01:46 -0700 Subject: Firefox crippling In-Reply-To: <87wtp48w4b.fsf@kosh.bigo.ensc.de> References: <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <87ekbhxfih.fsf@kosh.bigo.ensc.de> <20050605161545.GA28581@devserv.devel.redhat.com> <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> <42A471CC.70905@redhat.com> <87slzv2x24.fsf@kosh.bigo.ensc.de> <42A492C7.3090809@redhat.com> <87oeaj2ve6.fsf@kosh.bigo.ensc.de> <1118109568.3119.8.camel@jellyfish.redfishdemo.com> <87wtp48w4b.fsf@kosh.bigo.ensc.de> Message-ID: <1118264506.4699.56.camel@localhost.localdomain> On Wed, 2005-06-08 at 21:52 +0200, Enrico Scholz wrote: > Do you remember the spartial window management in nautilus? It was a > completely experimental feature, it was tried only by a very small > userbase before, there were lot of critical voices against it -- and > the Gnome2 developers actived it without providing a way to turn it > off, and it was activated on every existing system. It was always possible to turn it off, but in order to get _more_ testing it wasn't made obvious to begin with. Nowadays it's right there in Edit->Preferences. You're getting awfully close to red herrings here! > Ditto for epiphany -- its experimental bookmark management was never proved > to be useful but everybody was forced to use it. Epiphany was never meant to be all things to all people, if you don't like it then use another web browser. Its purpose is to be an easy-to- use non-intimidating browser. By the way, basically what you are asking here is that the authors write a _different_ bookmark system from what they want, in addition to the one they want. > Or metacity... there are > lot of wishes which are all rejected because configurability is assumed as > evil by Gnome2 developers. To some extent, configurability _is_ evil, especially when it's done instead of just doing things right. More generally, options have a cost, both to the developer and the user. Have you even cared to read Havoc's (now somewhat old, but still generally relevant) article on this? http://www.ometer.com/free-software-ui.html (especially the section on options a bit down.) > Altogether, Gnome2 is a very unergonomic piece of software. Userfriendly > software should adapt to the user, but with Gnome2 the user has to adapt > to the software. This is caused by the refusal of Gnome2 developers to > allow configuration of their software and the frequent changes of the > user interface. I'm a Gnome user and have been for a long time and the only really major shift that I noticed and cared about was when Nautilus went spatial. In principle I think the debate here might be between trying to keep compatibility with old cruft (with rather few users) or to try to build the best system for the future (i.e. something that will attract users who have Windows and Mac experience and couldn't care less about hacking config files in order to get some sanity to a desktop.) /Per From seandarcy2 at gmail.com Wed Jun 8 20:57:33 2005 From: seandarcy2 at gmail.com (sean) Date: Wed, 08 Jun 2005 16:57:33 -0400 Subject: rawhide report: 20050608 changes (I'm conflicted) In-Reply-To: References: <200506081121.j58BL0gO020822@porkchop.devel.redhat.com> Message-ID: Neal Becker wrote: > Anyone know a workaround for this? > > Dependencies Resolved > > ============================================================================= > Package Arch Version Repository Size > ============================================================================= > Updating: > ghostscript x86_64 8.15-0.rc3.1 development 4.8 M > ghostscript-devel x86_64 8.15-0.rc3.1 development 34 k > ghostscript-gtk x86_64 8.15-0.rc3.1 development 26 k > gimp-print x86_64 4.2.7-10 development 2.4 M > gimp-print-cups x86_64 4.2.7-10 development 2.6 M > gimp-print-devel x86_64 4.2.7-10 development 566 k > gimp-print-plugin x86_64 4.2.7-10 development 46 k > gimp-print-utils x86_64 4.2.7-10 development 21 k > > Transaction Summary > ============================================================================= > Install 0 Package(s) > Update 8 Package(s) > Remove 0 Package(s) > Total download size: 10 M > Is this ok [y/N]: y > Downloading Packages: > Running Transaction Test > Finished Transaction Test > Transaction Check Error: file /usr/bin/bdftops from install of > ghostscript-8.1 > 5-0.rc3.1 conflicts with file from package ghostscript-7.07-40 > [Lots more similar conflicts] > See if you have ghostscript.i386 installed sean From perbj at stanford.edu Wed Jun 8 21:05:54 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Wed, 08 Jun 2005 14:05:54 -0700 Subject: OT: nVidia driver [was: Wish list] -- understanding the GPU market In-Reply-To: <32673398.1118261532967.JavaMail.root@wamui-hound.atl.sa.earthlink.net> References: <32673398.1118261532967.JavaMail.root@wamui-hound.atl.sa.earthlink.net> Message-ID: <1118264754.4699.61.camel@localhost.localdomain> On Wed, 2005-06-08 at 15:12 -0500, Bryan J. Smith wrote: > Little Davie Jones wrote: > > FWIW, I picked up a PCI-E Radeon X300 for not-many-beans recently. > > It works out of the box with FC4, with no need for proprietory drivers. > > The 3d isn't supported yet ... > > Please replace "PCI-E Radeon X300" with "PCI-E GeForce 6800" and > retype that and it will be the _exact_same_ logic. Do they actually have a matching feature set? ATI seems much more involved in the development of their 2D driver; as Dave Jones pointed out, it' just one guy apparently in his spare time for the nv driver. > nVidia _does_ put people on the MIT "nv" driver, and 2D _does_ work > with their newest NV4x series of cards -- typically in about the same > development time as the ATI "radeon" and other drivers. Well, as you mentioned, at one point they did contribute some code to Utah-GLX (at least it ended up there, I don't know what Nvidia originally did with it but the copyright/license statements do indicate an Nvidia origin). It seems to work basically up to GeForce2/GeForce4MX class cards. However, Nvidia stopped touching this stuff well before those cards came along. Since they had already published the code and minor fiddling and tweaks got it to work with some newer hardware, how is it not a business decision to stop doing open-source 3D (at least at that support level): it seems that they could do the fancy, IP- encumbered stuff in a proprietary driver, and a decent basic-3D implementation in a free driver. By the way, someone is poking at the stuff in Utah-GLX, although on Haiku (BeOS clone): http://web.inter.nl.net/users/be-hold/BeOS/NVdriver/index.html > Also note that the X300 is a prior series R300, and not the latest > R400. It's like comparing to a GeForce FX5700LE. How sure are you about that? According to the DRI site it's an "rv370"; as far as I can tell this seems to be more like a crippled r400 or so than the original r300s? In any case, the point is actually moot, since the driver seems to work with the _definitely_ r400-class and still fairly hot X800 (apparently r420 or similar): http://www.mail-archive.com/dri-devel% 40lists.sourceforge.net/msg23412.html Admittedly, it doesn't seem like anyone has tested on an X850 (r480) yet, but it seems unlikely that that single card/chip in the family would be all that different. And for the upcoming r5XX all bets are off of course. But your comments are a bit off base I'm afraid. /Per From Nicolas.Mailhot at laPoste.net Wed Jun 8 21:16:11 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 08 Jun 2005 23:16:11 +0200 Subject: OT: nVidia driver [was: Wish list] In-Reply-To: <42A725C3.6000509@poolshark.org> References: <1118002724.9556.34.camel@Darkstar> <42A4BE05.9060105@poolshark.org> <1118093019.2468.42.camel@cutter> <6f6293f105060712576a17cde0@mail.gmail.com> <3609.10.10.10.24.1118176876.squirrel@linux1> <1118180290.7742.73.camel@mlenzdesktop> <3186.10.10.10.24.1118181192.squirrel@linux1> <42A61D6C.7060606@poolshark.org> <4167.10.10.10.24.1118184241.squirrel@linux1> <9f50a7a005060717213c76b518@mail.gmail.com> <604aa7910506071803712fa32f@mail.gmail.com> <42A725C3.6000509@poolshark.org> Message-ID: <1118265372.27024.3.camel@rousalka.dyndns.org> Le mercredi 08 juin 2005 ? 10:07 -0700, Denis Leroy a ?crit : > That's an interesting point to consider, but you have to understand that > NVidia is a company, and therefore is only interested in two things: profits > and market share. All NVidia wants is to own the Linux market share Well an open driver would get them there instantaneously. Matrox pretty much owned the Linux market back when the G400 had a complete open driver. -- Nicolas Mailhot -------------- 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 jspaleta at gmail.com Wed Jun 8 21:25:21 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 8 Jun 2005 17:25:21 -0400 Subject: Can sash be moved into Extras Message-ID: <604aa7910506081425ea49848@mail.gmail.com> I know its tiny... but in the spirit of removing duplication.. is there a reason to have both sash and busybox in Core come fc5? -jef From enrico.scholz at informatik.tu-chemnitz.de Wed Jun 8 21:28:33 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 08 Jun 2005 23:28:33 +0200 Subject: Firefox crippling In-Reply-To: <1118264506.4699.56.camel@localhost.localdomain> (Per Bjornsson's message of "Wed, 08 Jun 2005 14:01:46 -0700") References: <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <87ekbhxfih.fsf@kosh.bigo.ensc.de> <20050605161545.GA28581@devserv.devel.redhat.com> <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> <42A471CC.70905@redhat.com> <87slzv2x24.fsf@kosh.bigo.ensc.de> <42A492C7.3090809@redhat.com> <87oeaj2ve6.fsf@kosh.bigo.ensc.de> <1118109568.3119.8.camel@jellyfish.redfishdemo.com> <87wtp48w4b.fsf@kosh.bigo.ensc.de> <1118264506.4699.56.camel@localhost.localdomain> Message-ID: <87slzs8rni.fsf@kosh.bigo.ensc.de> perbj at stanford.edu (Per Bjornsson) writes: >> Do you remember the spartial window management in nautilus? It was a >> completely experimental feature, it was tried only by a very small >> userbase before, there were lot of critical voices against it -- and >> the Gnome2 developers actived it without providing a way to turn it >> off, and it was activated on every existing system. > > It was always possible to turn it off, but in order to get _more_ > testing it wasn't made obvious to begin with. Abusing users as beta testers is known from other companies also... > Nowadays it's right there in Edit->Preferences. But it still does not respect current settings (was Gnome2.4 running previously, then use normal window mode. Else, use the default spatial mode), right? >> Or metacity... there are lot of wishes which are all rejected because >> configurability is assumed as evil by Gnome2 developers. > > To some extent, configurability _is_ evil, especially when it's done > instead of just doing things right. That's why I said, that Gnome2 developers think that they are gods because only they know what is right and what is not. But in most cases, the right thing is to make it configurable; you will find a common base only very seldom. > More generally, options have a cost, both to the developer and the > user. Have you even cared to read Havoc's (now somewhat old, but still > generally relevant) article on this? > http://www.ometer.com/free-software-ui.html (especially the section on > options a bit down.) Yes, this paper is one of the root of the Gnome2 evil. Gnome2 developers read it and think that they should program after it. E.g. because Gnome2 developers always think, they are right (see above), they assume that everybody wants Emacs in the colors of the default theme. So they do not care about existing ~/.Xresources entries and there is not way (not even in the registry) to turn off this behavior. Ditto for ~/.Xmodmap. Or as this thread shows, Gnome2 developers assume that everybody wants theme icons in firefox and do not allow to configure it in another way. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From Nicolas.Mailhot at laPoste.net Wed Jun 8 21:29:30 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 08 Jun 2005 23:29:30 +0200 Subject: Firefox crippling In-Reply-To: <42A753A5.7090703@redhat.com> References: <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <87ekbhxfih.fsf@kosh.bigo.ensc.de> <20050605161545.GA28581@devserv.devel.redhat.com> <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> <42A471CC.70905@redhat.com> <87slzv2x24.fsf@kosh.bigo.ensc.de> <42A492C7.3090809@redhat.com> <87oeaj2ve6.fsf@kosh.bigo.ensc.de> <1118109568.3119.8.camel@jellyfish.redfishdemo.com> <87wtp48w4b.fsf@kosh.bigo.ensc.de> <42A753A5.7090703@redhat.com> Message-ID: <1118266170.27024.6.camel@rousalka.dyndns.org> Le mercredi 08 juin 2005 ? 16:23 -0400, Richard Li a ?crit : > >Altogether, Gnome2 is a very unergonomic piece of software. Userfriendly > >software should adapt to the user, but with Gnome2 the user has to adapt > >to the software. This is caused by the refusal of Gnome2 developers to > >allow configuration of their software and the frequent changes of the > >user interface. > > > > > Any claim like this should probably start with a definition of user ;-). > > I would imagine that someone who does, say, marketing, would never > configure their desktop (for better or worse). What a strange things to say. Marketing people _love_ eye-candy and fancy stuff. That's why they are in marketing. -- Nicolas Mailhot -------------- 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 enrico.scholz at informatik.tu-chemnitz.de Wed Jun 8 21:38:16 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 08 Jun 2005 23:38:16 +0200 Subject: Firefox crippling In-Reply-To: <20050608205527.GA10700@thacker.dyndns.org> (John Thacker's message of "Wed, 8 Jun 2005 16:55:27 -0400") References: <87ekbhxfih.fsf@kosh.bigo.ensc.de> <20050605161545.GA28581@devserv.devel.redhat.com> <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> <42A471CC.70905@redhat.com> <87slzv2x24.fsf@kosh.bigo.ensc.de> <42A492C7.3090809@redhat.com> <87oeaj2ve6.fsf@kosh.bigo.ensc.de> <1118109568.3119.8.camel@jellyfish.redfishdemo.com> <87wtp48w4b.fsf@kosh.bigo.ensc.de> <42A753A5.7090703@redhat.com> <20050608205527.GA10700@thacker.dyndns.org> Message-ID: <87oeag8r7b.fsf@kosh.bigo.ensc.de> thacker at math.cornell.edu (John Thacker) writes: >> >Altogether, Gnome2 is a very unergonomic piece of software. Userfriendly >> >software should adapt to the user, but with Gnome2 the user has to adapt >> >to the software. This is caused by the refusal of Gnome2 developers to >> >allow configuration of their software and the frequent changes of the >> >user interface. >> > >> Any claim like this should probably start with a definition of user ;-). I think on my mother which was not very amused when the desktop had a completely different behavior after the Gnome2.4->2.6 upgrade. Or on me, who wants to use his ~/.Xmodmap and ~/.Xresources files and is stopped in this by the arrogance of the Gnome2 developers. >> I would imagine that someone who does, say, marketing, would never >> configure their desktop (for better or worse). > > Yes, and shipping a large combination of software with dramatically > different icons and keyboard shortcuts for the same tasks forces a > user to adapt to the software, and can hardly be considered user > friendly. 1. The default firefox icons are not "dramatically different" from the default Gnome2 icon theme 2. I do not care about the default setting as long as: - it can be configured - does not override current settings 3. What is the meaning of "different"? Different to what? Firefox is the only Gnome2 application I am using, so why am I forced to see these ugly icons? I do not know KDE, but I can imagine that people with this desktop environment will be shocked also when they see the current firefox icons; they probably do not match the KDE theme neither. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From alan at redhat.com Wed Jun 8 21:43:06 2005 From: alan at redhat.com (Alan Cox) Date: Wed, 8 Jun 2005 17:43:06 -0400 Subject: OT: nVidia driver [was: Wish list] -- understanding the GPU market In-Reply-To: <24352831.1118259763177.JavaMail.root@wamui-chisos.atl.sa.earthlink.net> References: <24352831.1118259763177.JavaMail.root@wamui-chisos.atl.sa.earthlink.net> Message-ID: <20050608214306.GF7976@devserv.devel.redhat.com> On Wed, Jun 08, 2005 at 02:42:42PM -0500, Bryan J. Smith wrote: > Same deal with the NIC in their nForce chipset, and why they release > the nvnet driver, but can't officially work on the forcedeth. They do work on forcedeth nowdays. Beware of 'I hear' and internet rumour. From alan at redhat.com Wed Jun 8 21:46:11 2005 From: alan at redhat.com (Alan Cox) Date: Wed, 8 Jun 2005 17:46:11 -0400 Subject: OT: nVidia driver [was: Wish list] -- understanding the GPU market In-Reply-To: <20050608204311.GN876@redhat.com> References: <32673398.1118261532967.JavaMail.root@wamui-hound.atl.sa.earthlink.net> <20050608204311.GN876@redhat.com> Message-ID: <20050608214611.GG7976@devserv.devel.redhat.com> On Wed, Jun 08, 2005 at 04:43:11PM -0400, Dave Jones wrote: > Which for modern Xorg based servers is next to useless. > That code has festered in UtahGLX for years, and no-one seems > interested in doing anything with it. Those who care don't use Nvidia hw, those who don't care us Nvidia binary drivers ;) From thacker at math.cornell.edu Wed Jun 8 22:14:46 2005 From: thacker at math.cornell.edu (John Thacker) Date: Wed, 8 Jun 2005 18:14:46 -0400 Subject: Firefox crippling In-Reply-To: <87oeag8r7b.fsf@kosh.bigo.ensc.de> References: <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> <42A471CC.70905@redhat.com> <87slzv2x24.fsf@kosh.bigo.ensc.de> <42A492C7.3090809@redhat.com> <87oeaj2ve6.fsf@kosh.bigo.ensc.de> <1118109568.3119.8.camel@jellyfish.redfishdemo.com> <87wtp48w4b.fsf@kosh.bigo.ensc.de> <42A753A5.7090703@redhat.com> <20050608205527.GA10700@thacker.dyndns.org> <87oeag8r7b.fsf@kosh.bigo.ensc.de> Message-ID: <20050608221446.GA11330@thacker.dyndns.org> On Wed, Jun 08, 2005 at 11:38:16PM +0200, Enrico Scholz wrote: > 1. The default firefox icons are not "dramatically different" from the > default Gnome2 icon theme > > 2. I do not care about the default setting as long as: > - it can be configured > - does not override current settings But weren't you complaining about the change to spatial nautilus? Your complaint there, it seems, is because of the dramatic change in behavior between people who had GNOME 2.4 and upgraded. But I know plenty of people who *do* want current settings to be overriden, at least in the case where they always used the previous application default and never set any sort of special configuration. So many users never change the default preferences, and they want any genuinely useful or cool new feature to be enabled by default; they don't want to have to specifically enable everything in the new release. They don't want to have to be that familiar with every detail of their program. Especially when you're changing the UI, it's rather crazy to make users specifically select from a list of preferences many options in order to change to the new look and feel. That violates user friendliness as well. People who hate some change should be able to change it back, certainly. > 3. What is the meaning of "different"? Different to what? Firefox is the > only Gnome2 application I am using, so why am I forced to see these > ugly icons? I'm impressed that you're familiar enough with the Gnome2 icon theme to make the statement in 1. despite not using any Gnome2 applications. I'm furthermore impressed that you can argue simultaneously that the icons are not all that different, yet very ugly. I can see the position, I suppose. Largely you see those icons by default because GNOME is the default desktop for Fedora. There are plenty of reasons to make the default desktop have consistent icons; it's absolutely a core principle of user friendliness. The default certainly has to be something, and that is the most logical choice. Admittedly, from the user perspective of someone who uses Firefox on multiple different operating systems, it's not the greatest either. (In the same way, there is a reasonable argument for key shortcuts which are close to Windows, too.) There's nothing forcing you to see those icons, though. There are plenty of ways around it. A unified look to the desktop, like similar keyboard shortcuts, are kinder to users than everything being different. You mentioned not using KDE; RedHat got a lot of grief for a similar decision to develop Bluecurve in order to have a unified look throughout the desktop. (Bero left around when 8.0 was released over this.) From any usability standpoint, it makes sense. I'm a little confused; are you complaining partially because you only use GUI apps which are too difficult to make look consistent to be worth the effort to do so? John Thacker -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From thacker at math.cornell.edu Wed Jun 8 22:18:31 2005 From: thacker at math.cornell.edu (John Thacker) Date: Wed, 8 Jun 2005 18:18:31 -0400 Subject: Firefox crippling In-Reply-To: <1118266170.27024.6.camel@rousalka.dyndns.org> References: <20050605161545.GA28581@devserv.devel.redhat.com> <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> <42A471CC.70905@redhat.com> <87slzv2x24.fsf@kosh.bigo.ensc.de> <42A492C7.3090809@redhat.com> <87oeaj2ve6.fsf@kosh.bigo.ensc.de> <1118109568.3119.8.camel@jellyfish.redfishdemo.com> <87wtp48w4b.fsf@kosh.bigo.ensc.de> <42A753A5.7090703@redhat.com> <1118266170.27024.6.camel@rousalka.dyndns.org> Message-ID: <20050608221831.GB11330@thacker.dyndns.org> On Wed, Jun 08, 2005 at 11:29:30PM +0200, Nicolas Mailhot wrote: > Le mercredi 08 juin 2005 ? 16:23 -0400, Richard Li a ?crit : > > >Altogether, Gnome2 is a very unergonomic piece of software. Userfriendly > > >software should adapt to the user, but with Gnome2 the user has to adapt > > >to the software. This is caused by the refusal of Gnome2 developers to > > >allow configuration of their software and the frequent changes of the > > >user interface. > > Any claim like this should probably start with a definition of user ;-). > > > > I would imagine that someone who does, say, marketing, would never > > configure their desktop (for better or worse). > > What a strange things to say. > Marketing people _love_ eye-candy and fancy stuff. That's why they are > in marketing. Yes, but they don't tend to configure their desktop outside of things like desktop wallpaper, screen savers, and, say, WinAMP skins. Marketing people like eyecandy and fancy stuff and choices when it comes to *producing* things for their work. That doesn't mean that they want to fiddle with a bunch of choices about what double-clicking on a title bar does or whether their windows auto-raise on mouseover. Nor have I ever seen a marketing person who was interested in customizing their keyboard shortcuts-- outside of complaining if they didn't all basically work like Microsoft Office shortcuts for similar tasks. John Thacker -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From matthew at nocturnal.org Wed Jun 8 22:22:52 2005 From: matthew at nocturnal.org (Matthew Lenz) Date: Wed, 8 Jun 2005 17:22:52 -0500 Subject: OT: nVidia driver [was: Wish list] -- understanding the GPUmarket References: <32673398.1118261532967.JavaMail.root@wamui-hound.atl.sa.earthlink.net><20050608204311.GN876@redhat.com> <20050608214611.GG7976@devserv.devel.redhat.com> Message-ID: <003901c56c78$9e59ae80$0201a8c0@Greeney> ----- Original Message ----- From: "Alan Cox" To: "Development discussions related to Fedora Core" Cc: Sent: Wednesday, June 08, 2005 4:46 PM Subject: Re: OT: nVidia driver [was: Wish list] -- understanding the GPUmarket > On Wed, Jun 08, 2005 at 04:43:11PM -0400, Dave Jones wrote: >> Which for modern Xorg based servers is next to useless. >> That code has festered in UtahGLX for years, and no-one seems >> interested in doing anything with it. > > Those who care don't use Nvidia hw, those who don't care us Nvidia binary > drivers ;) I think we should all go headless in protest ;) Take it up with those damn 3D software developers and their eye candy, games and major motion pictures. Damn them, damn their eyes, damn them to hell!!!! :^D > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From jwboyer at jdub.homelinux.org Thu Jun 9 00:11:42 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 08 Jun 2005 19:11:42 -0500 Subject: Can sash be moved into Extras In-Reply-To: <604aa7910506081425ea49848@mail.gmail.com> References: <604aa7910506081425ea49848@mail.gmail.com> Message-ID: <1118275902.3107.161.camel@yoda.jdub.homelinux.org> On Wed, 2005-06-08 at 17:25 -0400, Jeff Spaleta wrote: > I know its tiny... but in the spirit of removing duplication.. is > there a reason to have both sash and busybox in Core come fc5? Um... why not move both? Is there a reason to have busybox in Core? josh From mattdm at mattdm.org Thu Jun 9 00:30:01 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 8 Jun 2005 20:30:01 -0400 Subject: Can sash be moved into Extras In-Reply-To: <1118275902.3107.161.camel@yoda.jdub.homelinux.org> References: <604aa7910506081425ea49848@mail.gmail.com> <1118275902.3107.161.camel@yoda.jdub.homelinux.org> Message-ID: <20050609003001.GA3399@jadzia.bu.edu> On Wed, Jun 08, 2005 at 07:11:42PM -0500, Josh Boyer wrote: > > I know its tiny... but in the spirit of removing duplication.. is > > there a reason to have both sash and busybox in Core come fc5? > Um... why not move both? Is there a reason to have busybox in Core? Yes -- anaconda uses it. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 81 degrees Fahrenheit. From jwboyer at jdub.homelinux.org Thu Jun 9 00:41:54 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 08 Jun 2005 19:41:54 -0500 Subject: Can sash be moved into Extras In-Reply-To: <20050609003001.GA3399@jadzia.bu.edu> References: <604aa7910506081425ea49848@mail.gmail.com> <1118275902.3107.161.camel@yoda.jdub.homelinux.org> <20050609003001.GA3399@jadzia.bu.edu> Message-ID: <1118277714.3107.164.camel@yoda.jdub.homelinux.org> On Wed, 2005-06-08 at 20:30 -0400, Matthew Miller wrote: > On Wed, Jun 08, 2005 at 07:11:42PM -0500, Josh Boyer wrote: > > > I know its tiny... but in the spirit of removing duplication.. is > > > there a reason to have both sash and busybox in Core come fc5? > > Um... why not move both? Is there a reason to have busybox in Core? > > Yes -- anaconda uses it. Ah. That would be a pretty good reason. josh From katzj at redhat.com Thu Jun 9 01:24:12 2005 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 08 Jun 2005 21:24:12 -0400 Subject: Can sash be moved into Extras In-Reply-To: <604aa7910506081425ea49848@mail.gmail.com> References: <604aa7910506081425ea49848@mail.gmail.com> Message-ID: <1118280252.3810.30.camel@bree.local.net> On Wed, 2005-06-08 at 17:25 -0400, Jeff Spaleta wrote: > I know its tiny... but in the spirit of removing duplication.. is > there a reason to have both sash and busybox in Core come fc5? Seems sane... Karsten, any objection? Jeremy From b.j.smith at ieee.org Thu Jun 9 01:45:23 2005 From: b.j.smith at ieee.org (Bryan J. Smith) Date: Wed, 08 Jun 2005 20:45:23 -0500 Subject: OT: nVidia driver [was: Wish list] -- understanding the GPU market In-Reply-To: <20050608214306.GF7976@devserv.devel.redhat.com> References: <24352831.1118259763177.JavaMail.root@wamui-chisos.atl.sa.earthlink.net> <20050608214306.GF7976@devserv.devel.redhat.com> Message-ID: <1118281524.4423.1.camel@bert64.mobile.smithconcepts.com> On Wed, 2005-06-08 at 17:43 -0400, Alan Cox wrote: > They do work on forcedeth nowdays. As I said, I'm out-of-date there. All I know is that it was a 3rd party IP issue years ago. > Beware of 'I hear' and internet rumour. I know. That's why I typically get information from people in the semiconductor business. But I will full admit that many things I know are 2+ years old now, other than the comment on the Intel- nVidia relationship. -- Bryan J. Smith b.j.smith at ieee.org --------------------------------------------------------------------- It is mathematically impossible for someone who makes more than you to be anything but richer than you. Any tax rate that penalizes them will also penalize you similarly (to those below you, and then below them). Linear algebra, let alone differential calculus or even ele- mentary concepts of limits, is mutually exclusive with US journalism. So forget even attempting to explain how tax cuts work. ;-> From b.j.smith at ieee.org Thu Jun 9 01:46:53 2005 From: b.j.smith at ieee.org (Bryan J. Smith) Date: Wed, 08 Jun 2005 20:46:53 -0500 Subject: OT: nVidia driver [was: Wish list] -- understanding the GPU market In-Reply-To: <1118264754.4699.61.camel@localhost.localdomain> References: <32673398.1118261532967.JavaMail.root@wamui-hound.atl.sa.earthlink.net> <1118264754.4699.61.camel@localhost.localdomain> Message-ID: <1118281613.4423.3.camel@bert64.mobile.smithconcepts.com> On Wed, 2005-06-08 at 14:05 -0700, Per Bjornsson wrote: > Do they actually have a matching feature set? ATI seems much more > involved in the development of their 2D driver; as Dave Jones pointed > out, it' just one guy apparently in his spare time for the nv driver. I've heard differently. Yes, there may be 1 point man. > How sure are you about that? According to the DRI site it's an "rv370"; > as far as I can tell this seems to be more like a crippled r400 or so > than the original r300s? It's a R300-series. I didn't mean an exact R300. But no, it's not a R400-series variant. -- Bryan J. Smith b.j.smith at ieee.org --------------------------------------------------------------------- It is mathematically impossible for someone who makes more than you to be anything but richer than you. Any tax rate that penalizes them will also penalize you similarly (to those below you, and then below them). Linear algebra, let alone differential calculus or even ele- mentary concepts of limits, is mutually exclusive with US journalism. So forget even attempting to explain how tax cuts work. ;-> From pri.rhl4 at iadonisi.to Thu Jun 9 02:11:34 2005 From: pri.rhl4 at iadonisi.to (Paul Iadonisi) Date: Wed, 08 Jun 2005 22:11:34 -0400 Subject: OT: nVidia driver [was: Wish list] In-Reply-To: <16231728.1118263463122.JavaMail.root@wamui-rustique.atl.sa.earthlink.net> References: <16231728.1118263463122.JavaMail.root@wamui-rustique.atl.sa.earthlink.net> Message-ID: <1118283094.14929.21.camel@md.nc.linuxlobbyist.org> Wow. Stop reading a mailing list for two days and miss all the fun. ;-) On Wed, 2005-06-08 at 15:44 -0500, Bryan J. Smith wrote: [snip] > No offense, but I _am_ as much of an "apologist" for nVidia as Red > Hat, because there _are_ legal issues involved. Whether it's NDAs > or trademarks, sometimes the hands of people are tied by 3rd party, Without reading the rest of your message (or the rest of this thread) yet, I feel I should comment on this. I don't think anyone here has denied that there are legal issues involved and the nVidia's hands are tied. However, *they chose that path*, and for that, we can fault them. I recall an analogous example from about four years ago. I went to work for a small (6 or 7 people) software development firm. I was a sysadmin, but played kind of a dual role as backend developer as well. I can remember several conversations about what SDK to choose for our next feature set and constantly trying to explain to these rather uninformed developers of all the available free (many LGPL, so no real legal issues there) libraries out there to do what they wanted. It seemed that the immediate response to the question of 'we need a development SDK' was, 'who can we buy/license one from'. My first reaction, of course, was to hop over to sourceforge, freshmeat, and finally google to find something that did what they wanted, often finding better alternatives to the closed ones they wanted to pay an arm and a leg for. After a few months of this, I actually had one of the developers converted over to the idea of Free Software, and another one amazed at how much Free Software there was out there. nVidia chose it's path, and, yes, it's hard to reverse that now. But with projects like opengraphics.org and Intel's on board chipsets set to commoditize the graphics world, I don't believe the situation is as glum as some in this thread have implied. Unfortunately for nVidia and ATI, they may loose out in the end, but it won't be impossible for them to join the party. It'll just be a lot of back room negotiations to convince the stakeholders that they will no longer be able to compete without releasing the source code for their drivers without restrictive (or incompatible) licenses. On a related note, I don't know what this whole Fedora Foundation news is about specifically, but I do hope one thing. And that is that the Fedora principle of producing a distribution that is completely redistributable (both source and binary) without permission from some external third party remains an important goal. There aren't many distributions out there that stick to that goal. Debian is really the only one I can think of, at the moment, and I don't want to go there. But it's an important goal for me, and I suspect most of the old timers here on these lists (fedora-devel and fedora-test specifically). To me, it gives credence to the likes of SCO if we produce something that is not entirely redistributable, but then go ahead and redistribute it later. I don't know the nVidia driver license, but if we go down that path, I fear that we will be stepping onto a slippery slope. (Yes, I do see that no one's talking about shipping the nVidia driver, but even kowtowing to their whims, or slowness in keeping is going to do nothing but slow us down.) Let's not go there. Please. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From enrico.scholz at informatik.tu-chemnitz.de Thu Jun 9 06:12:12 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 09 Jun 2005 08:12:12 +0200 Subject: Firefox crippling In-Reply-To: <20050608221446.GA11330@thacker.dyndns.org> (John Thacker's message of "Wed, 8 Jun 2005 18:14:46 -0400") References: <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> <42A471CC.70905@redhat.com> <87slzv2x24.fsf@kosh.bigo.ensc.de> <42A492C7.3090809@redhat.com> <87oeaj2ve6.fsf@kosh.bigo.ensc.de> <1118109568.3119.8.camel@jellyfish.redfishdemo.com> <87wtp48w4b.fsf@kosh.bigo.ensc.de> <42A753A5.7090703@redhat.com> <20050608205527.GA10700@thacker.dyndns.org> <87oeag8r7b.fsf@kosh.bigo.ensc.de> <20050608221446.GA11330@thacker.dyndns.org> Message-ID: <87k6l483er.fsf@kosh.bigo.ensc.de> thacker at math.cornell.edu (John Thacker) writes: >> 1. The default firefox icons are not "dramatically different" from >> the default Gnome2 icon theme >> >> 2. I do not care about the default setting as long as: >> - it can be configured >> - does not override current settings > > But weren't you complaining about the change to spatial nautilus? > Your complaint there, it seems, is because of the dramatic change in > behavior between people who had GNOME 2.4 and upgraded. But I know > plenty of people who *do* want current settings to be overriden, Then, such dramatical changes should be done in an user friendly manner. E.g. pop up a dialog box saying "We invented a new feature... Do you want to use this or do you want to stay at the current behavior? You can toggle between both by Settings -> ...". >> 3. What is the meaning of "different"? Different to what? Firefox is the >> only Gnome2 application I am using, so why am I forced to see these >> ugly icons? > > I'm impressed that you're familiar enough with the Gnome2 icon theme > to make the statement in 1. despite not using any Gnome2 applications. ??? I see the butt-ugly Gnome2 icons when I upgrade firefox from RH sources. I see the nice looking default icons when I recompile the .src.rpm after removing patches 25-28. > I'm furthermore impressed that you can argue simultaneously that the > icons are not all that different, yet very ugly. In both, "go back/forward" are symbolized by arrows, "go home" by a house, ... But the Gnome2 icons are butt-ugly (intrusive default bookmark [1], erroneously [2], the 4-color icons were perhaps beatiful in the ages of CGA graphics). Corresponding bug reports and user wishes were completely ignored by Gnome2 developers. > (In the same way, there is a reasonable argument for key shortcuts > which are close to Windows, too.) That's another problem of Gnome2; it tries to satisfy the novice Windoze user seeing Linux the first time. But it completely ignores the existing Linux userbase which learned to configure their systems with ~/.X* files or by editing files. > There's nothing forcing you to see those icons, though. RH/Gnome2 *is* forcing me to see these butt-ugly icons; there is no simple way to enable the standard icons. Recompiling firefox does not count; installing the resulting package might be complicated till impossible (no root perms). > You mentioned not using KDE; RedHat got a lot of grief for a similar > decision to develop Bluecurve in order to have a unified look throughout > the desktop. (Bero left around when 8.0 was released over this.) Yes, he was probably pissed off the ignorance of the Gnome2 developers who are enforcing their ideas ("we are always right"). Best, what I heard about the RH KDE is "wow, it looks really like Gnome. But please, can you restore the defaults?". > From any usability standpoint, it makes sense. I'm a little confused; > are you complaining partially because you only use GUI apps which are > too difficult to make look consistent to be worth the effort to do so? I am complaining about the arrogance of the Gnome2 developers which * stops me to use ~/.Xmodmap + ~/.Xresources, without providing a way to disable the broken gnome-settings-daemon behavior * enforces butt-ugly icons in firefox, without providing a way to use the default ones * overrides existing user-configurations Enrico Footnotes: [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138984 https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=106558 [2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138986 https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=106559 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From arjanv at redhat.com Thu Jun 9 07:10:38 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Thu, 09 Jun 2005 09:10:38 +0200 Subject: OT: nVidia driver [was: Wish list] In-Reply-To: <1118283094.14929.21.camel@md.nc.linuxlobbyist.org> References: <16231728.1118263463122.JavaMail.root@wamui-rustique.atl.sa.earthlink.net> <1118283094.14929.21.camel@md.nc.linuxlobbyist.org> Message-ID: <1118301038.5508.10.camel@laptopd505.fenrus.org> > I don't think anyone here has denied that there are legal issues > involved and the nVidia's hands are tied. ok then I'll say it here and now: I don't believe for a minute that nvidia has significant third party code or NDA's in their driver. I can't say here why though. There probably are patents involved, but those don't in general prevent open sourcing something unless you're on the wrong end of the stick. Sure nvidia gives the same nice 5 excuses everyone else with binary modules gives just to shut people up. Doesn't mean it's true ... ;-) -------------- 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 twaugh at redhat.com Thu Jun 9 08:28:50 2005 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 9 Jun 2005 09:28:50 +0100 Subject: ESP Ghostscript 8.x for FC5 In-Reply-To: <200506081245.17896.kewley@gps.caltech.edu> References: <200506081121.j58BL0gO020822@porkchop.devel.redhat.com> <20050608120930.GW8706@redhat.com> <200506081245.17896.kewley@gps.caltech.edu> Message-ID: <20050609082850.GC8706@redhat.com> On Wed, Jun 08, 2005 at 12:45:17PM -0700, David Kewley wrote: > Might this bit be particularly relevant? > > > ghostscript = 7.07-40 > > ... system-config-printer-0.6.131-1 No: those lines are unrelated to each other. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kas11 at tampabay.rr.com Thu Jun 9 09:28:30 2005 From: kas11 at tampabay.rr.com (kas) Date: Thu, 09 Jun 2005 05:28:30 -0400 Subject: mtune=nocona Message-ID: <1118309310.12595.47.camel@neptune.psag.mwg> As I was educating myself on the intricacies of building rpms last night, I was just a little nonplussed to see the following scroll by, in particular the last little bit: CFLAGS='-O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64 -mtune=nocona' Of course, on through -m64 was as expected. I'm just a bit surprised that it didn't say mtune=k8 since it was definitely building on one ... which begs the question ... is GCC (and hence the entire x86_64 distribution) being built this way? What are the K8 performance implications? I've seen a few things that indicate that Nocona cores running K8 code look pretty bad in some areas compared to optimized code...however, I find nothing to indicate how nocona optimized code runs on the K8. Karen From arjanv at redhat.com Thu Jun 9 10:09:08 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Thu, 09 Jun 2005 12:09:08 +0200 Subject: mtune=nocona In-Reply-To: <1118309310.12595.47.camel@neptune.psag.mwg> References: <1118309310.12595.47.camel@neptune.psag.mwg> Message-ID: <1118311748.5508.14.camel@laptopd505.fenrus.org> > Of course, on through -m64 was as expected. I'm just a bit surprised > that it didn't say mtune=k8 since it was definitely building on one ... > which begs the question ... is GCC (and hence the entire x86_64 > distribution) being built this way? What are the K8 performance > implications? I've seen a few things that indicate that Nocona cores > running K8 code look pretty bad in some areas compared to optimized > code...however, I find nothing to indicate how nocona optimized code > runs on the K8. AMD cpus are very good at running just about anything you throw at it (think about it; with their marketshare... most code out there is optimized for intel cpus so their cpus are effectively required to deal well with such code). The reverse unfortunatly isn't the case. -------------- 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 b.j.smith at ieee.org Thu Jun 9 10:26:44 2005 From: b.j.smith at ieee.org (Bryan J. Smith) Date: Thu, 09 Jun 2005 05:26:44 -0500 Subject: OT: nVidia driver [was: Wish list] In-Reply-To: <20050609071047.C3C59732FF@hormel.redhat.com> References: <20050609071047.C3C59732FF@hormel.redhat.com> Message-ID: <1118312804.4423.38.camel@bert64.mobile.smithconcepts.com> From: Paul Iadonisi > I recall an analogous example from about four years ago. I went to > work for a small (6 or 7 people) software development firm. I was a > sysadmin, but played kind of a dual role as backend developer as well. > I can remember several conversations about what SDK to choose for our > next feature set and constantly trying to explain to these rather > uninformed developers of all the available free (many LGPL, so no real > legal issues there) libraries out there to do what they wanted. It > seemed that the immediate response to the question of 'we need a > development SDK' was, 'who can we buy/license one from'. My first > reaction, of course, was to hop over to sourceforge, freshmeat, and > finally google to find something that did what they wanted, often > finding better alternatives to the closed ones they wanted to pay an arm > and a leg for. > After a few months of this, I actually had one of the developers > converted over to the idea of Free Software, and another one amazed at > how much Free Software there was out there. > nVidia chose it's path, and, yes, it's hard to reverse that now. But you're talking about picking an arbitrary library/SDK for a purpose where the API may radically differ between the open source and the proprietary source versions. nVidia is _already_supporting_ OpenGL on X11 (GLX). That's the whole reason many of us had to adopt nVidia in the first place! Because it was the only damn viable hardware solution for Linux! @-ppp People aren't picking "nVidia-only" application. They are picking nVidia to run those _open_standard_ applications on nVidia hardware for now. They are _not_ tying themselves into nVidia-only applications. I think that's the point I keep seeing people miss. And why the whole "open" v. "proprietary" can be demonized to make anyone's argument stick to whatever ideal they want. Me? I'm more interested in using Freedomware where it's viable, and sticking with Standardware that still mitigates risk when it doesn't. > On a related note, I don't know what this whole Fedora Foundation news > is about specifically, but I do hope one thing. And that is that the > Fedora principle of producing a distribution that is completely > redistributable (both source and binary) without permission from some > external third party remains an important goal. There aren't many > distributions out there that stick to that goal. Debian is really the > only one I can think of, at the moment, and I don't want to go there. And I'll be the first to 100% agree. I don't recommend people use nVidia drivers. But I really hate seeing _both_sides_ go at it with *0* understanding and all sorts of _unrelated_ "open" non-sense. Like talking about proprietary libraries, when we're talking just hardware and drivers that does _open_standard_ GLX! If I choose nVidia's hardware to run my GLX applications, then I'm _not_ tying myself to nVidia. I'm only tying myself to GLX applications! > But it's an important goal for me, and I suspect most of the old timers > here on these lists (fedora-devel and fedora-test specifically). To me, > it gives credence to the likes of SCO if we produce something that is > not entirely redistributable, but then go ahead and redistribute it > later. I don't know the nVidia driver license, but if we go down that > path, I fear that we will be stepping onto a slippery slope. (Yes, I do > see that no one's talking about shipping the nVidia driver, but even > kowtowing to their whims, or slowness in keeping is going to do nothing > but slow us down.) It's not about nVidia. It's about realizing that what nVidia is sell is _not_ a "proprietary" solution that only works with "proprietary" applications. It is GLX, and it is an open standard. It's like chastizing someone who uses Macromedia Standardware applications to produce 100% W3C standards-compliant sites instead of Freedomware applications. You may choose not to use Macromedia, but many of us are very aware of the risks involved, but we have mitigated those risks by sticking with a vendor who releases software that supports open standards, or only using that software in those modes. If there _was_ a Freedomware solution that offered a similar, _viable_ capability, we would. But don't lump us into the same category as someone who blindly uses Frontpage. Which is what I meant about the who "there are only 2 absolutes" non-sense. To me, it's not about some ideology, although that does come into play. It's about balancing feasibility against risk. -- Bryan J. Smith b.j.smith at ieee.org --------------------------------------------------------------------- It is mathematically impossible for someone who makes more than you to be anything but richer than you. Any tax rate that penalizes them will also penalize you similarly (to those below you, and then below them). Linear algebra, let alone differential calculus or even ele- mentary concepts of limits, is mutually exclusive with US journalism. So forget even attempting to explain how tax cuts work. ;-> From buildsys at redhat.com Thu Jun 9 11:35:31 2005 From: buildsys at redhat.com (Build System) Date: Thu, 9 Jun 2005 07:35:31 -0400 Subject: rawhide report: 20050609 changes Message-ID: <200506091135.j59BZVeK025438@porkchop.devel.redhat.com> New package aspell-ru Russian dictionaries for Aspell. New package hplip HP Linux Imaging and Printing Project Removed package VFlib2 Removed package hpoj Removed package hpijs Updated Packages: dbus-0.33-4 ----------- * Sat Jun 18 2005 John (J5) Palmieri - 0.33-4 - Add new libaudit patch from Steve Grub and enable in configure (Bug #159218) fonts-japanese-0.20050222-4 --------------------------- * Thu Jun 09 2005 Akira TAGOH - 0.20050222-4 - removed VFlib2 dependency. ghostscript-8.15-0.rc3.2 ------------------------ * Wed Jun 08 2005 Tim Waugh 8.15-0.rc3.2 - Drop 'Provides: libijs.so' because it is incorrect. - Build igcref.c with -O0 to work around bug #150771. - Renumber patches. hdparm-6.1-1 ------------ * Wed Jun 08 2005 Karsten Hopp 6.1-1 - update to 6.1 (BLKGETSIZE fixes) - work around hdparm's usage of kernel headers, assume that we run it on little-endian machines only libuser-0.53.8-1 ---------------- * Wed Jun 08 2005 Miloslav Trmac - 0.53.8-1 - Permit "portable" user and group names as defined by SUSv3, plus trailing $ (#159452) - Don't build static libraries oprofile-0.9-1 -------------- * Wed Jun 08 2005 Will Cohen - Rebase on OProfile 0.9. pilot-link-1:0.12.0-0.pre3.1 ---------------------------- * Wed Jun 08 2005 Than Ngo 0.12.0-0.pre3.1 - apply patch to fix compiler warnings * Wed Jun 08 2005 Than Ngo 0.12.0-0.pre3.0 - 0.12.0-pre3 selinux-policy-strict-1.23.18-2 ------------------------------- * Wed Jun 08 2005 Dan Walsh 1.23.18-2 - Add alsa policy - Policy cleanup from Ivan * Mon Jun 06 2005 Dan Walsh 1.23.18-1 - Upgrade from NSA * Merged minor fixes to pppd.fc and courier.te by Russell Coker. * Removed devfsd policy as suggested by Russell Coker. * Merged patch from Dan Walsh. Includes beginnings of Ivan Gyurdiev's Font Config policy. Don't transition to fsadm_t from unconfined_t (sysadm_t) in targeted policy. Add support for debugfs in modutil. Allow automount to create and delete directories in /root and /home dirs. Move can_ypbind to chkpwd_macro.te. Allow useradd to create additional files and types via the skell mechanism. Other minor cleanups and fixes. * Sat May 28 2005 Dan Walsh 1.23.17-4 - Add evolution/thunderbird support for strict policy. Including break out of orbits, fonts, and gnome. All done by Ivan G. selinux-policy-targeted-1.23.18-2 --------------------------------- * Wed Jun 08 2005 Dan Walsh 1.23.18-2 - Add alsa policy - Policy cleanup from Ivan * Mon Jun 06 2005 Dan Walsh 1.23.18-1 - Upgrade from NSA * Merged minor fixes to pppd.fc and courier.te by Russell Coker. * Removed devfsd policy as suggested by Russell Coker. * Merged patch from Dan Walsh. Includes beginnings of Ivan Gyurdiev's Font Config policy. Don't transition to fsadm_t from unconfined_t (sysadm_t) in targeted policy. Add support for debugfs in modutil. Allow automount to create and delete directories in /root and /home dirs. Move can_ypbind to chkpwd_macro.te. Allow useradd to create additional files and types via the skell mechanism. Other minor cleanups and fixes. * Sat May 28 2005 Dan Walsh 1.23.17-4 - Add evolution/thunderbird support for strict policy. Including break out of orbits, fonts, and gnome. All done by Ivan G. system-config-netboot-0.1.17-1 ------------------------------ * Wed Jun 08 2005 Jason Vas Dias 0.1.17-1 - fix bugs 159490, 159390, 159064, 156274 From seanlkml at sympatico.ca Thu Jun 9 11:58:45 2005 From: seanlkml at sympatico.ca (Sean) Date: Thu, 9 Jun 2005 07:58:45 -0400 (EDT) Subject: OT: nVidia driver [was: Wish list] In-Reply-To: <1118312804.4423.38.camel@bert64.mobile.smithconcepts.com> References: <20050609071047.C3C59732FF@hormel.redhat.com> <1118312804.4423.38.camel@bert64.mobile.smithconcepts.com> Message-ID: <1865.10.10.10.24.1118318325.squirrel@linux1> On Thu, June 9, 2005 6:26 am, Bryan J. Smith said: > But you're talking about picking an arbitrary library/SDK for a purpose > where the API may radically differ between the open source and the > proprietary source versions. > > nVidia is _already_supporting_ OpenGL on X11 (GLX). That's the whole > reason many of us had to adopt nVidia in the first place! Because it > was the only damn viable hardware solution for Linux! @-ppp Your choice of past tense is very appropriate. Lets move on to what we should be promoting for people today. > People aren't picking "nVidia-only" application. They are picking > nVidia to run those _open_standard_ applications on nVidia hardware for > now. They are _not_ tying themselves into nVidia-only applications. > > I think that's the point I keep seeing people miss. And why the whole > "open" v. "proprietary" can be demonized to make anyone's argument stick > to whatever ideal they want. > > Me? I'm more interested in using Freedomware where it's viable, and > sticking with Standardware that still mitigates risk when it doesn't. Those are your priorities and you're entitled to them. But this is a list for the development of open source software so perhaps you can understand why some of us have a different set of priorities. There's nothing wrong with nVidia hardware, the problem is when zealots start running around telling everyone to use binary drivers, which is just bad advice. > And I'll be the first to 100% agree. > I don't recommend people use nVidia drivers. Good. > But I really hate seeing _both_sides_ go at it with *0* understanding > and all sorts of _unrelated_ "open" non-sense. Like talking about > proprietary libraries, when we're talking just hardware and drivers that > does _open_standard_ GLX! > > If I choose nVidia's hardware to run my GLX applications, then I'm _not_ > tying myself to nVidia. I'm only tying myself to GLX applications! Actually you are tied to nVidia. Every time a significant kernel change comes out you have to rely on them to produce a new driver for you. If they tire of that exercise you are SOL or you'll have to go buy a different piece of hardware. Why not just start out by buying a different piece of hardware that _is_ supported by open source and reduce the risk? > It's not about nVidia. It's about realizing that what nVidia is sell is > _not_ a "proprietary" solution that only works with "proprietary" > applications. It is GLX, and it is an open standard. Sure, and there are open source solutions that accomplish the same thing. While nVidia may still enjoy a slight edge in performance and features there are _very few_ situations that actually demand the extra capacity provided. So, if you want all the advantages provided by open source software the best choice is to avoid any solution like the one you're still promoting. > It's like chastizing someone who uses Macromedia Standardware > applications to produce 100% W3C standards-compliant sites instead of > Freedomware applications. You may choose not to use Macromedia, but > many of us are very aware of the risks involved, but we have mitigated > those risks by sticking with a vendor who releases software that > supports open standards, or only using that software in those modes. No, that's a false analogy. There are _real_ risks when running binary only modules in kernel-mode. Those same risks don't come into play with binary only user applications. That's a big difference. Not to mention there is a very real risk of you losing support for your beloved hardware. Again, a problem that doesn't exist in your analogy. > If there _was_ a Freedomware solution that offered a similar, _viable_ > capability, we would. But don't lump us into the same category as > someone who blindly uses Frontpage. Which is what I meant about the who > "there are only 2 absolutes" non-sense. Sorry, you are in that category if you fail to recognize that the vast majority of the time there are perfectly viable fully open source solutions. That's fine if you want to pursue them yourself, just don't come here and recommend the practice for others, it's bad advice. > To me, it's not about some ideology, although that does come into play. > It's about balancing feasibility against risk. Supporting open source as a preferred platform is no more ideological than the arguments you're putting forth. Again, there are perfectly viable fully open source solutions today for the vast majority of uses. There is nothing wrong with people promoting them over binary only solutions. Period. Sean. From brugolsky at telemetry-investments.com Thu Jun 9 12:13:48 2005 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Thu, 9 Jun 2005 08:13:48 -0400 Subject: mtune=nocona In-Reply-To: <1118311748.5508.14.camel@laptopd505.fenrus.org> References: <1118309310.12595.47.camel@neptune.psag.mwg> <1118311748.5508.14.camel@laptopd505.fenrus.org> Message-ID: <20050609121348.GA25729@ti64.telemetry-investments.com> On Thu, Jun 09, 2005 at 12:09:08PM +0200, Arjan van de Ven wrote: > AMD cpus are very good at running just about anything you throw at it > (think about it; with their marketshare... most code out there is > optimized for intel cpus so their cpus are effectively required to deal > well with such code). The reverse unfortunatly isn't the case. And when Intel shows up late to the party with a solution that can only be described as crap, we bow in their direction. I'm not saying that it is the wrong decision, but it is disheartening. In any case, AMD's architecture still retains numerous advantages. -Bill From ndbecker2 at gmail.com Thu Jun 9 11:39:21 2005 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 09 Jun 2005 07:39:21 -0400 Subject: ESP Ghostscript 8.x for FC5 References: <200506081833.j58IXk9Q007336@laptop11.inf.utfsm.cl> Message-ID: Horst von Brand wrote: > [...] > > My x86-64 also complained about ghostscript. It had the following i386 > packages installed: ghostscript, ImageMagick, ImageMagick-c++. Deleting > them let the update go through. > > A glitch in the multi-arch handling? I erased ghostscript.i386 (only), and upgrade worked: Updated: ghostscript.x86_64 0:8.15-0.rc3.1 ghostscript-devel.x86_64 0:8.15-0.rc3.1 ghostscript-gtk.x86_64 0:8.15-0.rc3.1 gimp-print.x86_64 0:4.2.7-10 No idea why ghostscript.i386 was installed, yum did not remove anything when erasing it. From ph18 at cornell.edu Thu Jun 9 12:34:23 2005 From: ph18 at cornell.edu (Paul A. Houle) Date: Thu, 09 Jun 2005 08:34:23 -0400 Subject: OT: nVidia driver [was: Wish list] In-Reply-To: <1865.10.10.10.24.1118318325.squirrel@linux1> References: <20050609071047.C3C59732FF@hormel.redhat.com> <1118312804.4423.38.camel@bert64.mobile.smithconcepts.com> <1865.10.10.10.24.1118318325.squirrel@linux1> Message-ID: On Thu, 9 Jun 2005 07:58:45 -0400 (EDT), Sean wrote: > > Actually you are tied to nVidia. Every time a significant kernel change > comes out you have to rely on them to produce a new driver for you. If > they tire of that exercise you are SOL or you'll have to go buy a > different piece of hardware. Why not just start out by buying a > different piece of hardware that _is_ supported by open source and reduce > the risk? (i) I've suffered through a lot of graphics cards that were "supported" by open source drivers that crashed all the time. My nVidia card is the first one I've had in about six years that doesn't crash when I'm using it. (Sometimes it gets crashed by screensavers, but that's another job for "rpm --erase") (ii) There isn't any 3-d card with open source driver support that's within an order of magntitue of current nvidia and ATI cards in performance (iii) I like doing stream programming with the GPU In a lot of ways, propreitary hardware/software combos from vendors like Apple and Sun are starting to look good to me. Linux has a lot of quality problems because much of the hardware it supports is junk and it has bad drivers even for good hardware: for instance, Apache disables the sendfile() system call on Linux because some network cards supported by Linux are total crap and can corrupt data when using sendfile() on an NFS-mounted file. What's terrible is that there isn't any reliable way to know what's junk and what isn't. I'll ask around online and it's like calling your average software vendor for support: "Yeah, there's a driver for that card, it's supported, it's fine." A year later I finally find out other people are having horrible performance and crashes too -- cold comfort. > > No, that's a false analogy. There are _real_ risks when running binary > only modules in kernel-mode. Those same risks don't come into play with > binary only user applications. That's a big difference. Not to > mention > there is a very real risk of you losing support for your beloved > hardware. > Again, a problem that doesn't exist in your analogy. Yeah sure, but there are risks everywhere. You can get hit by a bus crossing the street. Tainted kernel or not, I've never seen a Linux 2.4 system running non-scientific workloads on an SMP machines that didn't have strange concurrency problems. There are lots of open source drivers that suck -- I'd rather trade a propreitary driver that actually works for an open source driver that crashes my machine. It might not be fair that good graphic cards are propreitary and that you can't make free drivers for 802.11g but the real choice is between being pure and being relevant: you ought to be glad that I'm choosing to run Linux with modern graphics cards and modern wireless networking rather than choosing to foresake Linux so I can support modern hardware. > > Supporting open source as a preferred platform is no more ideological > than > the arguments you're putting forth. Again, there are perfectly viable > fully open source solutions today for the vast majority of uses. There > is > nothing wrong with people promoting them over binary only solutions. > Period. > In some areas that's true. Name a specific graphics card I should be using, and show me some evidence that it can make it more than two hours without a crash and I might believe you. From mattdm at mattdm.org Thu Jun 9 12:39:04 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 9 Jun 2005 08:39:04 -0400 Subject: OT: nVidia driver [was: Wish list] In-Reply-To: References: <20050609071047.C3C59732FF@hormel.redhat.com> <1118312804.4423.38.camel@bert64.mobile.smithconcepts.com> <1865.10.10.10.24.1118318325.squirrel@linux1> Message-ID: <20050609123904.GA4145@jadzia.bu.edu> On Thu, Jun 09, 2005 at 08:34:23AM -0400, Paul A. Houle wrote: > (i) I've suffered through a lot of graphics cards that were > "supported" by open source drivers that crashed all the time. My nVidia > card is the first one I've had in about six years that doesn't crash when > I'm using it. (Sometimes it gets crashed by screensavers, but that's > another job for "rpm --erase") Almost certainly, these crashes *are* bugs in the driver, not the screensavers. FWIW. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 80 degrees Fahrenheit. From pri.rhl4 at iadonisi.to Thu Jun 9 12:40:16 2005 From: pri.rhl4 at iadonisi.to (Paul Iadonisi) Date: Thu, 09 Jun 2005 08:40:16 -0400 Subject: OT: nVidia driver [was: Wish list] In-Reply-To: <1118301038.5508.10.camel@laptopd505.fenrus.org> References: <16231728.1118263463122.JavaMail.root@wamui-rustique.atl.sa.earthlink.net> <1118283094.14929.21.camel@md.nc.linuxlobbyist.org> <1118301038.5508.10.camel@laptopd505.fenrus.org> Message-ID: <1118320816.26265.1.camel@md.nc.linuxlobbyist.org> On Thu, 2005-06-09 at 09:10 +0200, Arjan van de Ven wrote: [snip] > Sure nvidia gives the same nice 5 excuses everyone else with binary > modules gives just to shut people up. Doesn't mean it's true ... ;-) Yup. Like the whole Canon nonsense wrt. the OpenRAW project. There is zero excuse for locking up MY data in a format that isn't accessible by any means I wish. But I digress... -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From rms at 1407.org Thu Jun 9 12:42:36 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Thu, 09 Jun 2005 13:42:36 +0100 Subject: Making update functionality more usable (Was: Re: What next?) In-Reply-To: <1118234067.20494.39.camel@arena.soho.bytebot.net> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <1117730130.1674.3.camel@weasel.laiskiainen.org> <429FDACF.20608@rueb.com> <1117780095.3488.32.camel@cutter> <1117809250.8385.11.camel@mlenzdesktop> <1118024411.3011.11.camel@bree.local.net> <1118048011.2779.2.camel@roque> <1118234067.20494.39.camel@arena.soho.bytebot.net> Message-ID: <1118320956.2897.37.camel@roque> On Wed, 2005-06-08 at 05:34 -0700, Colin Charles wrote: > On Mon, 2005-06-06 at 09:53 +0100, Rui Miguel Seabra wrote: > > > > I hate to admit it but I remove all the redhat update stuff as well and > > > > use yum or apt-get (if i'm feeling impatient). I used ubuntu for awhile > > > > (but ultimately found fedora to be superior) and found their update > > > > functionality much more usable. > > > > > > Since one of the goals of FC5 is to have pup in place to handle updates > > > from a graphical point of view, I'd be interested in hearing what sorts > > > of things made the Ubuntu stuff more usable. Or the same for other > > > distros as well. > > Just to make it clear, Ubuntu just has: dpkg/apt, Synaptic, and > update-notifier, right? > > We (will) have: rpm/yum, s-c-packages(okay, pup), and pup's > update-notifier They have a graphical update manager that's very fancy. Probably the update-notifier icon is part of that update manager. Another very interesting thing is that every single one of those apps around packaging use the same repo settings (besides other settings), so they feel integrated. Rui -- + 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...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.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 pri.rhl4 at iadonisi.to Thu Jun 9 13:05:02 2005 From: pri.rhl4 at iadonisi.to (Paul Iadonisi) Date: Thu, 09 Jun 2005 09:05:02 -0400 Subject: OT: nVidia driver [was: Wish list] In-Reply-To: <1865.10.10.10.24.1118318325.squirrel@linux1> References: <20050609071047.C3C59732FF@hormel.redhat.com> <1118312804.4423.38.camel@bert64.mobile.smithconcepts.com> <1865.10.10.10.24.1118318325.squirrel@linux1> Message-ID: <1118322302.26265.25.camel@md.nc.linuxlobbyist.org> [Note: This should have been a reply to the Bryan's message, since I didn't wind up responding to any of Sean's comments. I was just lazy and didn't want to change what message I was replying to and subsequently have to change all the quoting. Sorry. :-/ ] On Thu, 2005-06-09 at 07:58 -0400, Sean wrote: > On Thu, June 9, 2005 6:26 am, Bryan J. Smith said: > > People aren't picking "nVidia-only" application. They are picking > > nVidia to run those _open_standard_ applications on nVidia hardware for > > now. They are _not_ tying themselves into nVidia-only applications. > > > > I think that's the point I keep seeing people miss. And why the whole > > "open" v. "proprietary" can be demonized to make anyone's argument stick > > to whatever ideal they want. I don't think you read my message very carefully. I know what your talking about regarding open v. proprietary, but that was not at all the gist of my message. I'm talking about Free Software in the FSF sense of the phrase. That's what matters to me, and it is what I want to continue to matter to the Fedora Project and, going forward, the Fedora Foundation. > > But I really hate seeing _both_sides_ go at it with *0* understanding > > and all sorts of _unrelated_ "open" non-sense. Like talking about > > proprietary libraries, when we're talking just hardware and drivers that > > does _open_standard_ GLX! Again, I haven't seen many, if any people arguing about whether or not nVidia is designing their cards and drivers to an open standard. But you're starting to sound like Sun's Jonathan Schwartz. To him, and some others in the industry, open standards matter more than source code under a Free license. That's not the case with the Fedora Project and I, at least, am going to lobby to keep it that way. And although that doesn't mean deliberately breaking closed source kernel modules, it does mean having zero concern about whether or not they break. We leave that completely in the hands of those who have chosen keep their source closed. I make sacrifices when there isn't a Free Software solution for the job I need to do. I'm not talking about work here...there, sure, I don't always have a choice. But I know the folly of my ways. I'm a reluctantly loyal user VMware since version 1.0. But when it breaks -- which it does just often enough to be annoying after some kernel updates -- I get to keep all the pieces. I don't complain on the Fedora lists that VMware is broken again. When I get the chance, I bitch at VMware, where my wrath should be directed. Even if it was free-as-in-beer software like nVidia's drivers, I wouldn't be complaining here. And, of course, I fully intend to stop purchasing upgrades to VMware when Xen is a viable replacement for me. But I know my folly, and that it is *my* folly. I help people to get it working when the latest kernel update precipitates a another breakage. Never, NEVER, would I argue that Fedora should make it easy for VMware to keep their drivers closed. I want pressure to be placed on VMware to open at least those kernel modules so that core kernel developers can help when they break. EVEN when it inconveniences me. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From vonbrand at inf.utfsm.cl Thu Jun 9 02:24:05 2005 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Wed, 08 Jun 2005 22:24:05 -0400 Subject: ESP Ghostscript 8.x for FC5 In-Reply-To: Your message of "Wed, 08 Jun 2005 12:45:17 MST." <200506081245.17896.kewley@gps.caltech.edu> Message-ID: <200506090224.j592O59U005952@laptop11.inf.utfsm.cl> [...] Here it broke gsview-4.6-10. Reported on bugzilla. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From vonbrand at inf.utfsm.cl Thu Jun 9 14:03:31 2005 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Thu, 09 Jun 2005 10:03:31 -0400 Subject: mtune=nocona In-Reply-To: Your message of "Thu, 09 Jun 2005 12:09:08 +0200." <1118311748.5508.14.camel@laptopd505.fenrus.org> Message-ID: <200506091403.j59E3VBB005184@laptop11.inf.utfsm.cl> Arjan van de Ven wrote: > > Of course, on through -m64 was as expected. I'm just a bit surprised > > that it didn't say mtune=k8 since it was definitely building on one ... > > which begs the question ... is GCC (and hence the entire x86_64 > > distribution) being built this way? What are the K8 performance > > implications? I've seen a few things that indicate that Nocona cores > > running K8 code look pretty bad in some areas compared to optimized > > code...however, I find nothing to indicate how nocona optimized code > > runs on the K8. > AMD cpus are very good at running just about anything you throw at it > (think about it; with their marketshare... most code out there is > optimized for intel cpus so their cpus are effectively required to deal > well with such code). The reverse unfortunatly isn't the case. AFAIU, they are talking about /64 bit/ code here. There the situation is almost exactly the other way around, isn't it? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From twaugh at redhat.com Thu Jun 9 14:09:50 2005 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 9 Jun 2005 15:09:50 +0100 Subject: ESP Ghostscript 8.x for FC5 In-Reply-To: <200506090224.j592O59U005952@laptop11.inf.utfsm.cl> References: <200506081245.17896.kewley@gps.caltech.edu> <200506090224.j592O59U005952@laptop11.inf.utfsm.cl> Message-ID: <20050609140950.GH8706@redhat.com> On Wed, Jun 08, 2005 at 10:24:05PM -0400, Horst von Brand wrote: > [...] > > Here it broke gsview-4.6-10. Reported on bugzilla. Well, it probably just needs rebuilding I would think. The soname changed. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From twaugh at redhat.com Thu Jun 9 14:10:30 2005 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 9 Jun 2005 15:10:30 +0100 Subject: ESP Ghostscript 8.x for FC5 In-Reply-To: <200506090224.j592O59U005952@laptop11.inf.utfsm.cl> References: <200506081245.17896.kewley@gps.caltech.edu> <200506090224.j592O59U005952@laptop11.inf.utfsm.cl> Message-ID: <20050609141030.GI8706@redhat.com> ...incidentally, ghostscript-devel is broken before 8.15-0.rc3.3, so rebuilding gsview will have to wait until then. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Thu Jun 9 14:15:14 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 9 Jun 2005 10:15:14 -0400 Subject: mtune=nocona In-Reply-To: <1118309310.12595.47.camel@neptune.psag.mwg> References: <1118309310.12595.47.camel@neptune.psag.mwg> Message-ID: <604aa79105060907156909a8b2@mail.gmail.com> On 6/9/05, kas wrote: > Of course, on through -m64 was as expected. I'm just a bit surprised > that it didn't say mtune=k8 since it was definitely building on one ... > which begs the question ... is GCC (and hence the entire x86_64 > distribution) being built this way? What are the K8 performance > implications? I've seen a few things that indicate that Nocona cores > running K8 code look pretty bad in some areas compared to optimized > code...however, I find nothing to indicate how nocona optimized code > runs on the K8. Well... if you really want to find out for yourself you could run benchs. I'm pretty confident that the distro-wide settings are close to the best if not the best settings to provide the best average performance for people using the variety of x86_64 chips in the wild. I highly doubt Core is ever going to decide its worth the support and maintainence hassle to distro tuned optimally for just a 64bit amd chip or just a 64bit intel chip. When you are only going to ship one version of the distro to cover several chips.. you make choices as to what performance hits your are going to allow. I'm very confident that the choices made for Core allow both intel and amd hardware users to have reasonable good performance from the same binaries. -jef From dcbw at redhat.com Thu Jun 9 14:15:48 2005 From: dcbw at redhat.com (Dan Williams) Date: Thu, 09 Jun 2005 10:15:48 -0400 Subject: mtune=nocona In-Reply-To: <200506091403.j59E3VBB005184@laptop11.inf.utfsm.cl> References: <200506091403.j59E3VBB005184@laptop11.inf.utfsm.cl> Message-ID: <1118326548.14381.6.camel@dcbw.boston.redhat.com> On Thu, 2005-06-09 at 10:03 -0400, Horst von Brand wrote: > Arjan van de Ven wrote: > > > > Of course, on through -m64 was as expected. I'm just a bit surprised > > > that it didn't say mtune=k8 since it was definitely building on one ... > > > which begs the question ... is GCC (and hence the entire x86_64 > > > distribution) being built this way? What are the K8 performance > > > implications? I've seen a few things that indicate that Nocona cores > > > running K8 code look pretty bad in some areas compared to optimized > > > code...however, I find nothing to indicate how nocona optimized code > > > runs on the K8. > > > AMD cpus are very good at running just about anything you throw at it > > (think about it; with their marketshare... most code out there is > > optimized for intel cpus so their cpus are effectively required to deal > > well with such code). The reverse unfortunatly isn't the case. > > AFAIU, they are talking about /64 bit/ code here. There the situation is > almost exactly the other way around, isn't it? What Arjan is saying is this: AMD Opteron/Athlon64 CPUs do much, much better with -mtune=nocona than Intel EM64T CPUs do with -mtune=k8. It appears that the Opteron/Althon64 are more flexible in this regard. Therefore, since the hit for -mtune=nocona on Opteron is much smaller than -mtune=k8 on EM64T, the distro uses -mtune=nocona. The question, distilled: Would you like: (a) Small speed hit for Opteron users, OR (b) much larger speed hit for EM64T users? (a), ie -mtune=nocona everywhere, seems to be the fairest option here for everybody since we obviously cannot make 1 build of Fedora Core for Opteron and 1 comletely separate build of Fedora Core for EM64T. Dan From arjanv at redhat.com Thu Jun 9 14:16:55 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Thu, 9 Jun 2005 16:16:55 +0200 Subject: mtune=nocona In-Reply-To: <1118326548.14381.6.camel@dcbw.boston.redhat.com> References: <200506091403.j59E3VBB005184@laptop11.inf.utfsm.cl> <1118326548.14381.6.camel@dcbw.boston.redhat.com> Message-ID: <20050609141655.GB26893@devserv.devel.redhat.com> On Thu, Jun 09, 2005 at 10:15:48AM -0400, Dan Williams wrote: > The question, distilled: > > Would you like: (a) Small speed hit for Opteron users, OR (b) much > larger speed hit for EM64T users? note the hit is REALLY REALLY small. Hard to measure kind of small. From tmraz at redhat.com Thu Jun 9 14:21:38 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 09 Jun 2005 16:21:38 +0200 Subject: mtune=nocona In-Reply-To: <1118326548.14381.6.camel@dcbw.boston.redhat.com> References: <200506091403.j59E3VBB005184@laptop11.inf.utfsm.cl> <1118326548.14381.6.camel@dcbw.boston.redhat.com> Message-ID: <1118326898.5128.23.camel@perun.redhat.usu> On Thu, 2005-06-09 at 10:15 -0400, Dan Williams wrote: > The question, distilled: > > Would you like: (a) Small speed hit for Opteron users, OR (b) much > larger speed hit for EM64T users? The question is how small is the small hit and how large is the large one. Percentage numbers anyone? > (a), ie -mtune=nocona everywhere, seems to be the fairest option here > for everybody since we obviously cannot make 1 build of Fedora Core for > Opteron and 1 comletely separate build of Fedora Core for EM64T. Yes, that's true. -- Tomas Mraz From P at draigBrady.com Thu Jun 9 14:28:37 2005 From: P at draigBrady.com (P at draigBrady.com) Date: Thu, 09 Jun 2005 15:28:37 +0100 Subject: mtune=nocona In-Reply-To: <20050609141655.GB26893@devserv.devel.redhat.com> References: <200506091403.j59E3VBB005184@laptop11.inf.utfsm.cl> <1118326548.14381.6.camel@dcbw.boston.redhat.com> <20050609141655.GB26893@devserv.devel.redhat.com> Message-ID: <42A85215.1030304@draigBrady.com> Arjan van de Ven wrote: > On Thu, Jun 09, 2005 at 10:15:48AM -0400, Dan Williams wrote: > >>The question, distilled: >> >>Would you like: (a) Small speed hit for Opteron users, OR (b) much >>larger speed hit for EM64T users? > > note the hit is REALLY REALLY small. Hard to measure kind of small. Have you compared -march=k8 with -mtune=nocona ? -- P?draig Brady - http://www.pixelbeat.org -- From vmakarov at redhat.com Thu Jun 9 14:33:03 2005 From: vmakarov at redhat.com (Vladimir Makarov) Date: Thu, 09 Jun 2005 10:33:03 -0400 Subject: mtune=nocona In-Reply-To: <1118326898.5128.23.camel@perun.redhat.usu> References: <200506091403.j59E3VBB005184@laptop11.inf.utfsm.cl> <1118326548.14381.6.camel@dcbw.boston.redhat.com> <1118326898.5128.23.camel@perun.redhat.usu> Message-ID: <42A8531F.5020200@redhat.com> Tomas Mraz wrote: >On Thu, 2005-06-09 at 10:15 -0400, Dan Williams wrote: > > >>The question, distilled: >> >>Would you like: (a) Small speed hit for Opteron users, OR (b) much >>larger speed hit for EM64T users? >> >> > >The question is how small is the small hit and how large is the large >one. Percentage numbers anyone? > > > I have an old data for gcc3.4. Data should be practically the same for gcc4 because tuninng affect back back end optimizations which have not been changed since gcc3.4. In brief, when we use tuning to AMD64, SPECFP2000 (floating point programs) is 28% worse and SPECINT2000 (integer benchmarks) is 0.6% worse on Intel nocona processor. When we use tuning to Intel Nocona, SPECFP2000 is 2.7% and SPECINT2000 is 1.6% worse on Opteron. Code tuned for Intel Nocona parctically always has smaller size. So I think tunning to nocona by default is a right decision. From kmaraas at broadpark.no Thu Jun 9 14:39:23 2005 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Thu, 09 Jun 2005 16:39:23 +0200 Subject: Firefox crippling In-Reply-To: <87slzs8rni.fsf@kosh.bigo.ensc.de> References: <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <87ekbhxfih.fsf@kosh.bigo.ensc.de> <20050605161545.GA28581@devserv.devel.redhat.com> <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> <42A471CC.70905@redhat.com> <87slzv2x24.fsf@kosh.bigo.ensc.de> <42A492C7.3090809@redhat.com> <87oeaj2ve6.fsf@kosh.bigo.ensc.de> <1118109568.3119.8.camel@jellyfish.redfishdemo.com> <87wtp48w4b.fsf@kosh.bigo.ensc.de> <1118264506.4699.56.camel@localhost.localdomain> <87slzs8rni.fsf@kosh.bigo.ensc.de> Message-ID: <1118327963.16602.15.camel@localhost.localdomain> ons, 08,.06.2005 kl. 23.28 +0200, skrev Enrico Scholz: > perbj at stanford.edu (Per Bjornsson) writes: > > >> Do you remember the spartial window management in nautilus? It was a > >> completely experimental feature, it was tried only by a very small > >> userbase before, there were lot of critical voices against it -- and > >> the Gnome2 developers actived it without providing a way to turn it > >> off, and it was activated on every existing system. > > > > It was always possible to turn it off, but in order to get _more_ > > testing it wasn't made obvious to begin with. > > Abusing users as beta testers is known from other companies also... > Can we stop with the shit slinging and throwing around hints that GNOME == Windows please? > > > Nowadays it's right there in Edit->Preferences. > > But it still does not respect current settings (was Gnome2.4 running > previously, then use normal window mode. Else, use the default spatial > mode), right? > The decision was made to use spatial as default, can you seriously still be offended by having to flick a switch two years later? You sure know how to hold a grudge :-) > > >> Or metacity... there are lot of wishes which are all rejected because > >> configurability is assumed as evil by Gnome2 developers. > > > > To some extent, configurability _is_ evil, especially when it's done > > instead of just doing things right. > > That's why I said, that Gnome2 developers think that they are gods > because only they know what is right and what is not. But in most > cases, the right thing is to make it configurable; you will find a > common base only very seldom. > And some people are more interested in tweaking settings that actually doing work. Seriously, the argument is that every preference comes with a cost. That cost is on the maintainer since the maintainer has to deal with bugs in the code, porting to new interfaces, documenting things etc. This is one of the main arguments against preferences. Not that the user interface should be dumbed down so that "newbies" don't get scared off or that one should mimick other OSes just for the fun of it. The GNOME project definitely is influenced by design choices of other desktops and OSes, but it's not like we blindly follow either one of them and have no opinion of our own. > > > More generally, options have a cost, both to the developer and the > > user. Have you even cared to read Havoc's (now somewhat old, but still > > generally relevant) article on this? > > http://www.ometer.com/free-software-ui.html (especially the section on > > options a bit down.) > > Yes, this paper is one of the root of the Gnome2 evil. Gnome2 developers > read it and think that they should program after it. E.g. because Gnome2 > developers always think, they are right (see above), they assume that > everybody wants Emacs in the colors of the default theme. So they do not > care about existing ~/.Xresources entries and there is not way (not even > in the registry) to turn off this behavior. Ditto for ~/.Xmodmap. Or as > this thread shows, Gnome2 developers assume that everybody wants theme > icons in firefox and do not allow to configure it in another way. > AFAIK there is code in gnome-settings-daemon to merge stuff from both Xmodmap and Xresources, maybe the daemon just has bugs that were never filed because someone decided to flame and rant about the issue because they thought it was a conscious decision to fuck users over? You know where bugzilla is if that's the case. Cheers Kjartan From arjanv at redhat.com Thu Jun 9 15:18:04 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Thu, 09 Jun 2005 17:18:04 +0200 Subject: mtune=nocona In-Reply-To: <42A85215.1030304@draigBrady.com> References: <200506091403.j59E3VBB005184@laptop11.inf.utfsm.cl> <1118326548.14381.6.camel@dcbw.boston.redhat.com> <20050609141655.GB26893@devserv.devel.redhat.com> <42A85215.1030304@draigBrady.com> Message-ID: <1118330284.5508.19.camel@laptopd505.fenrus.org> On Thu, 2005-06-09 at 15:28 +0100, P at draigBrady.com wrote: > Arjan van de Ven wrote: > > On Thu, Jun 09, 2005 at 10:15:48AM -0400, Dan Williams wrote: > > > >>The question, distilled: > >> > >>Would you like: (a) Small speed hit for Opteron users, OR (b) much > >>larger speed hit for EM64T users? > > > > note the hit is REALLY REALLY small. Hard to measure kind of small. > > Have you compared -march=k8 with -mtune=nocona ? I didn't personally, but our gcc guys did and they said it was hardly measureable if at all. -------------- 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 seanlkml at sympatico.ca Thu Jun 9 15:18:09 2005 From: seanlkml at sympatico.ca (Sean) Date: Thu, 9 Jun 2005 11:18:09 -0400 (EDT) Subject: OT: nVidia driver [was: Wish list] In-Reply-To: References: <20050609071047.C3C59732FF@hormel.redhat.com> <1118312804.4423.38.camel@bert64.mobile.smithconcepts.com> <1865.10.10.10.24.1118318325.squirrel@linux1> Message-ID: <3160.10.10.10.24.1118330289.squirrel@linux1> On Thu, June 9, 2005 8:34 am, Paul A. Houle said: > (i) I've suffered through a lot of graphics cards that were "supported" > by open source drivers that crashed all the time. My nVidia card is the > first one I've had in about six years that doesn't crash when I'm using > it. (Sometimes it gets crashed by screensavers, but that's another job > for "rpm --erase") Linux has traditionally been most useful on servers so anyone engaged in using it as a workstation has shed more blood than others using Linux. However, the _vast_ majority of desktop users today can choose a video card supported by open source which will meet their needs and not crash. The constant drum beat of "nVidia binary drivers are the best" completely misses that point. Hell there are even open source drivers available for nVidia. > (ii) There isn't any 3-d card with open source driver support that's > within an order of magntitue of current nvidia and ATI cards in > performance And the vast majority of users won't be using any of that added capacity and shouldn't be encouraged to use binary drivers when they have no need to do so. > (iii) I like doing stream programming with the GPU So you're not exactly a typical user then are you? > In a lot of ways, propreitary hardware/software combos from vendors > like Apple and Sun are starting to look good to me. Linux has a lot of > quality problems because much of the hardware it supports is junk and it > has bad drivers even for good hardware: for instance, Apache disables > the sendfile() system call on Linux because some network cards supported > by Linux are total crap and can corrupt data when using sendfile() on an > NFS-mounted file. Well Apple has just announced they're going to be moving to Intel CPU's so not sure you want to move in their direction just yet. Anyway, do whatever you want, if you don't believe in open source and it's not ready to service your needs yet, there's no harm in you going and doing something else. > What's terrible is that there isn't any reliable way to know what's junk > and what isn't. I'll ask around online and it's like calling your average > software vendor for support: "Yeah, there's a driver for that card, > it's supported, it's fine." A year later I finally find out other people > are having horrible performance and crashes too -- cold comfort. Yes there is a reliable way, every RHEL system i've ever installed has gone completely without a hardware problem. RedHat is _great_ about helping you find the correct hardware to meet your needs. > Yeah sure, but there are risks everywhere. You can get hit by a bus > crossing the street. Tainted kernel or not, I've never seen a Linux 2.4 > system running non-scientific workloads on an SMP machines that didn't > have strange concurrency problems. There are lots of open source drivers > that suck -- I'd rather trade a propreitary driver that actually works for > an open source driver that crashes my machine. Go nuts, but i'd rather have a working open source driver. > It might not be fair that good graphic cards are propreitary and that you > can't make free drivers for 802.11g but the real choice is between being > pure and being relevant: you ought to be glad that I'm choosing to run > Linux with modern graphics cards and modern wireless networking rather > than choosing to foresake Linux so I can support modern hardware. Linux is running on some of the most modern hardware around. Having a bunch of people hacking in binary crap to Linux does nothing to move it forward in any important way. > In some areas that's true. Name a specific graphics card I should be > using, and show me some evidence that it can make it more than two hours > without a crash and I might believe you. Sounds like you wouldn't be happy with the open source card I'm using to write this email now, however it sure suits my purposes and it hasn't crashed on me ever. Cheers, Sean P.S. I'm out of this thread. From alan at redhat.com Thu Jun 9 15:27:03 2005 From: alan at redhat.com (Alan Cox) Date: Thu, 9 Jun 2005 11:27:03 -0400 Subject: mtune=nocona In-Reply-To: <1118326548.14381.6.camel@dcbw.boston.redhat.com> References: <200506091403.j59E3VBB005184@laptop11.inf.utfsm.cl> <1118326548.14381.6.camel@dcbw.boston.redhat.com> Message-ID: <20050609152703.GA19461@devserv.devel.redhat.com> On Thu, Jun 09, 2005 at 10:15:48AM -0400, Dan Williams wrote: > Would you like: (a) Small speed hit for Opteron users, OR (b) much > larger speed hit for EM64T users? > > (a), ie -mtune=nocona everywhere, seems to be the fairest option here > for everybody since we obviously cannot make 1 build of Fedora Core for > Opteron and 1 comletely separate build of Fedora Core for EM64T. That sort of depends on market share. I would put a beer on almost all Fedora 64bit users being AMD users because Fedora is appealing to the technically aware community rather than those whose choice is driven by "business relationships" as happens in the enterprise space Alan From dcbw at redhat.com Thu Jun 9 15:28:42 2005 From: dcbw at redhat.com (Dan Williams) Date: Thu, 09 Jun 2005 11:28:42 -0400 Subject: mtune=nocona In-Reply-To: <20050609152703.GA19461@devserv.devel.redhat.com> References: <200506091403.j59E3VBB005184@laptop11.inf.utfsm.cl> <1118326548.14381.6.camel@dcbw.boston.redhat.com> <20050609152703.GA19461@devserv.devel.redhat.com> Message-ID: <1118330922.14381.8.camel@dcbw.boston.redhat.com> On Thu, 2005-06-09 at 11:27 -0400, Alan Cox wrote: > On Thu, Jun 09, 2005 at 10:15:48AM -0400, Dan Williams wrote: > > Would you like: (a) Small speed hit for Opteron users, OR (b) much > > larger speed hit for EM64T users? > > > > (a), ie -mtune=nocona everywhere, seems to be the fairest option here > > for everybody since we obviously cannot make 1 build of Fedora Core for > > Opteron and 1 comletely separate build of Fedora Core for EM64T. > > That sort of depends on market share. I would put a beer on almost all Fedora > 64bit users being AMD users because Fedora is appealing to the technically > aware community rather than those whose choice is driven by "business > relationships" as happens in the enterprise space However, simply due to sheer marketshare, Intel may in the future have the most x86_64 processors out there. Where does that leave us? Dan From alan at redhat.com Thu Jun 9 15:28:46 2005 From: alan at redhat.com (Alan Cox) Date: Thu, 9 Jun 2005 11:28:46 -0400 Subject: mtune=nocona In-Reply-To: <42A8531F.5020200@redhat.com> References: <200506091403.j59E3VBB005184@laptop11.inf.utfsm.cl> <1118326548.14381.6.camel@dcbw.boston.redhat.com> <1118326898.5128.23.camel@perun.redhat.usu> <42A8531F.5020200@redhat.com> Message-ID: <20050609152846.GB19461@devserv.devel.redhat.com> On Thu, Jun 09, 2005 at 10:33:03AM -0400, Vladimir Makarov wrote: > When we use tuning to Intel Nocona, SPECFP2000 is 2.7% and SPECINT2000 > is 1.6% worse on Opteron. And neither specfp or specint are related to anything but compiler and processor benchmarketing in my experience. > Code tuned for Intel Nocona parctically always has smaller size. That could well make up for some of the other hit on a real systems From alan at redhat.com Thu Jun 9 15:30:36 2005 From: alan at redhat.com (Alan Cox) Date: Thu, 9 Jun 2005 11:30:36 -0400 Subject: mtune=nocona In-Reply-To: <1118330922.14381.8.camel@dcbw.boston.redhat.com> References: <200506091403.j59E3VBB005184@laptop11.inf.utfsm.cl> <1118326548.14381.6.camel@dcbw.boston.redhat.com> <20050609152703.GA19461@devserv.devel.redhat.com> <1118330922.14381.8.camel@dcbw.boston.redhat.com> Message-ID: <20050609153036.GC19461@devserv.devel.redhat.com> On Thu, Jun 09, 2005 at 11:28:42AM -0400, Dan Williams wrote: > However, simply due to sheer marketshare, Intel may in the future have > the most x86_64 processors out there. Where does that leave us? About FC6 or FC7 8) Alan From mpeters at mac.com Thu Jun 9 15:43:02 2005 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 09 Jun 2005 08:43:02 -0700 Subject: OT: nVidia driver [was: Wish list] In-Reply-To: <1865.10.10.10.24.1118318325.squirrel@linux1> References: <20050609071047.C3C59732FF@hormel.redhat.com> <1118312804.4423.38.camel@bert64.mobile.smithconcepts.com> <1865.10.10.10.24.1118318325.squirrel@linux1> Message-ID: <1118331782.31279.18.camel@laptop.mpeters.local> On Thu, 2005-06-09 at 07:58 -0400, Sean wrote: > > No, that's a false analogy. There are _real_ risks when running binary > only modules in kernel-mode. I can testify to this. With the NVidia kernel module - Tux Racer was rather sweet, but programs unrelated to video were sometimes segfaulting. Other applications - such as my e-mail client - would suddenly become unresponsive for 10 to 15 seconds. Reverting to the nv driver and all those issues just "went away". Who could help with the issues I was having with nvidia? Not my operating system vendor - they (Fedora) don't have access to the source. I could file a bug report with nvidia, but that never lead to an improvement - until the next release, which solved some things and introduced others. With the nv.ko module - tux racer sucks, but the system is rock solid stable. From thebs413 at earthlink.net Thu Jun 9 15:45:26 2005 From: thebs413 at earthlink.net (Bryan J. Smith ) Date: Thu, 9 Jun 2005 10:45:26 -0500 (GMT-05:00) Subject: OT: nVidia driver [was: Wish list] Message-ID: <26077939.1118331927204.JavaMail.root@wamui-hybrid.atl.sa.earthlink.net> From: fedora-devel-list-request at redhat.com > Actually you are tied to nVidia. Every time a significant kernel change > comes out you have to rely on them to produce a new driver for you. This has _yet_ to happen. At the most, there was a stack or other configuration difference not in the stock kernel that required a quick rebuild, nothing difficult to accommodate. In fact, you complain about the "zealots" who blindly recommend nVidia's drivers. Well, as someone who is not blind to _both_ sides, I tell you I tire of "zealots" who _overstate_ the "quality" of Freedomware DRI/GLX solutions versus nVidia. Yes, I love a solution like an integrated GPU in a chipset that comes ready-to-use, out-of-the-box. I love that Fedora Core 3 installed on my i855GM system and immediately gave me GLX on first boot. I will commend all parties involved on that. But that solution is _not_ going to solve _real_ engineering needs. Not now, and not likely in the future. > If they tire of that exercise you are SOL or you'll have to go buy a > different piece of hardware. My mitigating factors are the reality that nVidia will not because of the industry that deploys their solutions, and the continued, strong marketshare as a result. This is a _far_better_case_ for risk mitigation that some _blind_faith_ in ideals. Just because something is Freedomware does _not_ guarantee it will be supported. Many video cards and vendors have either gone by the way-side, or "closed up." One only needs to look at the number of drivers that have gone unmaintained in the 2.6 kernel. REALITY #1: As long as open standards are adhered to, sometimes risk is more about popularity when it comes to maintanence than philosophy. And even if something goes unmaintained, by adhering to open standards, it's a matter of changing the intermedia solution, such as hardware. REALITY #2: As long as I stick to GLX applications, I have my _choice_ of hardware with Freedomware or Standardware drivers. BIGGEST REALITY: The cost and economies-of-scale of nVidia solutions are the best "bang-for-the-buck" and if they are not supported some 1-2 years down the road, it will still cost me _less_ than buying an eccentric, costly hardware solution, or relying on a poorly supported solution _today_. I'm sorry, but in my industry, nVidia provides _excellent_ support. Yes, the new 1.0-7xxx series drivers are flaky, but just like some of the other series when they first came out. I've been sticking with the last revs of the 1.0-6xxx drivers without issue, including supporting some of the latest products. And I've _never_ had a kernel incompatibility, sans only one case where a rebuild of the kernel was required. But I've _never_ been without working drivers. > Why not just start out by buying a different piece of hardware that _is_ > supported by open source and reduce the risk? Because the risk is _not_ reduced! They their Linux drivers are often: 1) Less reliable 2) Far lower performing 3) Far less supported by the vendor 4) Often lag product release, heavily > Sure, and there are open source solutions that accomplish the same thing. > While nVidia may still enjoy a slight edge in performance and features Okay, get off this. Sorry, this is a _bogus_ assumption. I'm not talking about gaming here either! > there are _very few_ situations that actually demand the extra capacity > provided. But those "very few" situations are a _major_ sustainment of nVidia's Linux driver efforts. Not only for other companies, but do you know how much of nVidia itself is Linux??? It's not just a majority, but a massive and overwhelming majority. Linux drivers are a staple to their own, internal IT need. > So, if you want all the advantages provided by open source > software the best choice is to avoid any solution like the one you're > still promoting. By "advantage," you are typically talking about "open" v. "proprietary" in a blanket statement -- proprietary APIs, data in proprietary formats, etc... The problem is that it isn't that simple because we are not talking about "proprietary standards." In the case of nVidia, the _only_ thing you are risking is that your hardware investments will not be supported in the future. Given the cost of nVidia's typical solution, it is chump change to lose compared to going with more costly hardware and/or 3rd party drivers. > No, that's a false analogy. There are _real_ risks when running binary > only modules in kernel-mode. Those same risks don't come into play with > binary only user applications. That's a big difference. The reality is that that are real _needs_ to address issues at the kernel level that cannot be done in a user-space driver, especially memory control. This is not some "infestation" of user-space detail into the kernel, but things that should probably be controlled by the kernel in the first place. Now I'm not saying it wouldn't be nice if nVidia GPL'd it. I would love to see that. But I just know it's not legally possible at this time, at least not all of it. I'm not "praising" nVidia for it, but understand that as long as people are aware of the risks, then it's still using "open standards." Unfortunately, you can't see to see the "other risk" we have in not deploying nVidia as a solution. See #1-4 above. > Not to mention there is a very real risk of you losing support for your > beloved hardware. But the _cost_ of using something else is _much_greater_! So what nVidia provides me is _value_ in a Standardware product, that does _not_ expense open standards, _today_. Not promises, not drivers for obsoleted products with various product issues and quirks -- _real_, _working_ hardware. Probably the biggest reality is the fact that nVidia is one of the _largest_ users of EDA on Linux, using their own GLX solution. They could _easily_ persuade the EDA industry to start supporting only their chipsets, but they are dedicated to OpenGL. Maybe not as strict to the ARB that 3DLabs wants, but fairly good. So, once again, who is going to give me "less risk": A) A Standardware vendor who is not only the producer of products and drivers that adhere to open standards, but is also a _user_ in the same industry as I? B) Freedomware--er, excuse me--Commuware zealots that do not take the time to understand the _real_ risks of going with _less_supported_ solutions. There's quite a bit of "Hostageware hardware" out there now, because no one's maintaining the hardware. With nVidia, I know that they are going to continuing supporting Linux, at least in the near-term, because they need it for themselves! Especially for a product that is obsoleted in 12 months anyway, and rarely used beyond 3-4 years. > Again, a problem that doesn't exist in your analogy. > Sorry, you are in that category if you fail to recognize that the vast > majority of the time there are perfectly viable fully open source > solutions. That's fine if you want to pursue them yourself, just don't > come here and recommend the practice for others, it's bad advice. I use nVu, and have since version 0.2. But I also use Macromedia Dreamweaver. If I lay out the risks involved, and let others decide for themselves, then I'm going to be damned on what I can and can't say. Choice is the key. Furthermore, I didn't even start this thread! My problem is that you claim there are these "zealots" out there and what I'm telling you is that you're doing the same, damn thing! Especially given the fact that you are so oblivious to thing that no "Proprietary" vendor could possibly reduce risk over an "Open" vendor. Sorry, there's a good example in widespread use by doctors and law firms for decades, Corel. And there are many others. Risk is not about zealousy. It is about careful analysis of the risks involved. But deploying nVidia, I not only solve my needs, but I stick with POSIX/GLX applications on _Linux_. Without nVidia, many solutions would have gone to Win32/DX, never to return. And even if nVidia drops support -- which I've gone at length here to show they will not for their own, internal sake -- then I merely switch to another GLX solution. Given the increased cost of those solutions in price/performance, I'm already getting the nVidia solution for chump change, and benefit from their economies-of-scale. > Supporting open source as a preferred platform is no more ideological > than the arguments you're putting forth. The problem is that "open source" is _not_ always the "preferred platform." People take some concepts that work well against "proprietary standards" and then assume they still have the same argument against "proprietary source" but "open standards." The game changes there a bit. ;-> If a Standardware solution offers far greater feasibility and _reduced_ risk than a Freedomware solution, then it should be considered on those merits, even if only limitedly or for specification applications where they apply. > Again, there are perfectly viable fully open source solutions today for > the vast majority of uses. Yes. And in many cases, I don't need GLX, so I use the "nv", "radeon" or whatever, Freedomware MIT driver comes with XFree/Xorg. And I have deployed UtahGLX, DRI and even Xi and other, partially open/proprietary source solutions. > There is nothing wrong with people promoting them over binary only > solutions. Period. Except when they introduce more risk. > That's fine if you want to pursue them yourself, just don't > come here and recommend the practice for others, it's bad advice. That's the problem -- I did _no_such_thing_! I merely tried to explain why so-called "zealots" aren't understood by opposing "zealots" like yourself. -- Bryan J. Smith mailto:b.j.smith at ieee.org From mattdm at mattdm.org Thu Jun 9 15:55:07 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 9 Jun 2005 11:55:07 -0400 Subject: mtune=nocona In-Reply-To: <20050609152703.GA19461@devserv.devel.redhat.com> References: <200506091403.j59E3VBB005184@laptop11.inf.utfsm.cl> <1118326548.14381.6.camel@dcbw.boston.redhat.com> <20050609152703.GA19461@devserv.devel.redhat.com> Message-ID: <20050609155507.GA12047@jadzia.bu.edu> On Thu, Jun 09, 2005 at 11:27:03AM -0400, Alan Cox wrote: > That sort of depends on market share. I would put a beer on almost all > Fedora 64bit users being AMD users because Fedora is appealing to the > technically aware community rather than those whose choice is driven by > "business relationships" as happens in the enterprise space I'm not sure that's a safe beer. At Boston University, there's big pressure to buy from Approved Vendors, and the current Approved Vendor Of Choice is Dell -- and that means, pretty much Intel. Academia isn't exactly "enterprise space" but we definitely have some things in common. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 80 degrees Fahrenheit. From roozbeh at farsiweb.info Thu Jun 9 16:10:13 2005 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Thu, 09 Jun 2005 20:40:13 +0430 Subject: Where is "comps" in the CVS? Message-ID: <1118333413.5654.21.camel@tameshk.bamdad.org> I can't find the directory for the "comps" package in the Fedora CVS. Where is it? roozbeh From thebs413 at earthlink.net Thu Jun 9 16:12:08 2005 From: thebs413 at earthlink.net (Bryan J. Smith ) Date: Thu, 9 Jun 2005 11:12:08 -0500 (GMT-05:00) Subject: OT: nVidia driver [was: Wish list] Message-ID: <7551805.1118333528805.JavaMail.root@wamui-hybrid.atl.sa.earthlink.net> Paul Iadonisi wrote: > Again, I haven't seen many, if any people arguing about whether or not > nVidia is designing their cards and drivers to an open standard. I know, I'm the first one who reminded people. Because a _lot_ of the arguments that I have seen made are applying attributes of proprietary standards, which are wholly inappropriate and inapplicable. > But you're starting to sound like Sun's Jonathan Schwartz. To him, > and some others in the industry, open standards matter more than > source code under a Free license. Now I _never_ made that. Why does everything have to be in black and white? All I said is you can_not_ apply the same logic of proprietary standards to proprietary source of open standards. That's all. Again, it's like being a Libertarian and watching Democrats and Republicans sometimes. I try to interject a fact that is not applicable to the demonizing viewpoints of both sides, and what I get is people just taking what I said and demonizing it the same. Same deal here. I see Freedomware proponents using Commerceware/ Hostageware arguments, that are totally and wholly inapplicable, against Standardware. I try to point that out and all of the sudden, people like yourself are saying I'm like Schwartz saying that Open Standards are all that matter. No, I'm not saying that at all! I believe _very_strongly_ in Freedomware. I use it by default. I regularly defend Debian and Fedora on their strict guidelines, and warn of the dangers of not doing such -- especially when it comes to indemfication. E.g., I have a _formal_policy_ in my department that _no_ Knoppix or other Live CD is allowed in the building _except_ those that have been verified to be "pure" Debian, Fedora or another distro that does not have IP issues. I support projects, even if extremely limitedly with a patch of only a few lines here or there, as much as I can. And I am very aware of the dangers of not supporting Freedomware and other community developments. But I'm also an engineer and a realist, and that means I have to make solid arguments when it comes to adoption, and those arguments are 100% based on risk mitigation of many factors. > That's not the case with the Fedora Project and I, at least, am going > to lobby to keep it that way. And I will too! If you didn't notice, in the init thread, I was very much against even looking at Solaris' new init, because of that exact issue. If an end-user is going to make that decision based on all collective risk factors, then it's their choice. But from a development and shipping standpoint, I agree. I think the problem is that once someone started calling anyone who recommends nVidia's driver a "zealot," that's when I thought it was rather hypocritical. And that's when I came into it. Maybe I should not have, especially since this was the "development" list. > And although that doesn't mean deliberately breaking closed source > kernel modules, it does mean having zero concern about whether or > not they break. We leave that completely in the hands of those who > have chosen keep their source closed. Agreed. And I can understand your viewpoint of expected support. Anyone who chooses nVidia's Standardware drivers must contact nVidia for support, and do their "own homework" on configuration management. I.e., people who think "upgrade to the latest" is a valid configuration management are the types of people I _flog_ in person (at least virtually ;-)! > But I know my folly, and that it is *my* folly. I help people to get > it working when the latest kernel update precipitates a another > breakage. Never, NEVER, would I argue that Fedora should make it easy > for VMware to keep their drivers closed. I want pressure to be placed > on VMware to open at least those kernel modules so that core kernel > developers can help when they break. EVEN when it inconveniences me. And I understand your viewpoint, and the collective frustration, on the nVidia issue. I just didn't like the "over-extended comments" made by a few people. One must be cautious when making such. -- Bryan J. Smith mailto:b.j.smith at ieee.org From jspaleta at gmail.com Thu Jun 9 16:18:45 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 9 Jun 2005 12:18:45 -0400 Subject: Where is "comps" in the CVS? In-Reply-To: <1118333413.5654.21.camel@tameshk.bamdad.org> References: <1118333413.5654.21.camel@tameshk.bamdad.org> Message-ID: <604aa79105060909182f463ca@mail.gmail.com> On 6/9/05, Roozbeh Pournader wrote: > I can't find the directory for the "comps" package in the Fedora CVS. > Where is it? There is no comps package in the development tree... there is a comps-extras and i see it listed in http://cvs.fedora.redhat.com/viewcvs/devel/ -jef From enrico.scholz at informatik.tu-chemnitz.de Thu Jun 9 16:28:30 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 09 Jun 2005 18:28:30 +0200 Subject: Firefox crippling In-Reply-To: <1118327963.16602.15.camel@localhost.localdomain> (Kjartan Maraas's message of "Thu, 09 Jun 2005 16:39:23 +0200") References: <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <87ekbhxfih.fsf@kosh.bigo.ensc.de> <20050605161545.GA28581@devserv.devel.redhat.com> <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> <42A471CC.70905@redhat.com> <87slzv2x24.fsf@kosh.bigo.ensc.de> <42A492C7.3090809@redhat.com> <87oeaj2ve6.fsf@kosh.bigo.ensc.de> <1118109568.3119.8.camel@jellyfish.redfishdemo.com> <87wtp48w4b.fsf@kosh.bigo.ensc.de> <1118264506.4699.56.camel@localhost.localdomain> <87slzs8rni.fsf@kosh.bigo.ensc.de> <1118327963.16602.15.camel@localhost.localdomain> Message-ID: <877jh3qytt.fsf@kosh.bigo.ensc.de> kmaraas at broadpark.no (Kjartan Maraas) writes: >> But it still does not respect current settings (was Gnome2.4 running >> previously, then use normal window mode. Else, use the default spatial >> mode), right? >> > The decision was made to use spatial as default, can you seriously still > be offended by having to flick a switch two years later? There has nothing been changed in these two years on the Gnome2 practice to enforce the Gnome2 ideas of "usability". The Emacs -> Windoze keybindings were introduced silently without a smooth transition, the ~/.X* files were made pointless, Firefox was crippled, ... >> So they do not care about existing ~/.Xresources entries and there is >> not way (not even in the registry) to turn off this behavior. Ditto >> for ~/.Xmodmap... >> > AFAIK there is code in gnome-settings-daemon to merge stuff from both > Xmodmap and Xresources, maybe the daemon just has bugs that were never > filed because someone decided to flame and rant about the issue because > they thought it was a conscious decision to fuck users over? > > You know where bugzilla is if that's the case. Filing bugs regarding Gnome2 usability is senseless; Gnome2 developers think that they are the gods of usability and reject anything which is against their ideas. E.g. regarding ~/.Xresources read [1]: instead of adding an appropriate configuration option, Gnome2 developers give worthless responses like "if you do not like it, delete files under /usr/share/...". Perhaps a good practice under Windoze, but does not work in Linux where I might have no perms for that or the next autoupdate will override my "settings". Similarly for ~/.Xmodmap in [2]. And regarding firefox, the BZ tickets were told in this thread already. Enrico Footnotes: [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103521 [2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117221 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From roozbeh at farsiweb.info Thu Jun 9 16:33:01 2005 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Thu, 09 Jun 2005 21:03:01 +0430 Subject: Where is "comps" in the CVS? In-Reply-To: <604aa79105060909182f463ca@mail.gmail.com> References: <1118333413.5654.21.camel@tameshk.bamdad.org> <604aa79105060909182f463ca@mail.gmail.com> Message-ID: <1118334781.5654.26.camel@tameshk.bamdad.org> On Thu, 2005-06-09 at 12:18 -0400, Jeff Spaleta wrote: > There is no comps package in the development tree... there is a comps-extras > and i see it listed in http://cvs.fedora.redhat.com/viewcvs/devel/ That's only images for comps groups and scripts to process the comps file. I am wondering where the comps data itself is kept in the CVS. roozbeh From jos at xos.nl Thu Jun 9 16:42:54 2005 From: jos at xos.nl (Jos Vos) Date: Thu, 9 Jun 2005 18:42:54 +0200 Subject: question about RedHat/Fedora and the GPL In-Reply-To: <20050606100725.GC31431@devserv.devel.redhat.com>; from arjanv@redhat.com on Mon, Jun 06, 2005 at 12:07:26PM +0200 References: <1118040569.5652.2.camel@laptopd505.fenrus.org> <1118045329.5652.19.camel@laptopd505.fenrus.org> <20050606120354.A18425@xos037.xos.nl> <20050606100725.GC31431@devserv.devel.redhat.com> Message-ID: <20050609184254.A11175@xos037.xos.nl> On Mon, Jun 06, 2005 at 12:07:26PM +0200, Arjan van de Ven wrote: > > - There seem to be a few settings that are different from redhat-rpm-config: > > see my thread started with > > > > https://www.redhat.com/archives/fedora-devel-list/2005-February/msg00523.html > > > > about rebuilding pango c.s. that was never really answered... OK, I can > > imagine what settings it needs, and our local RHEL-rebuild environment > > has implemented that ;-), but that's actually a bit of reverse engineering. > > At least in FC3 (didn't check FC4t* yet) this was still the issue. > > rpmbuild --target i386 Nope... my build system does that standard and that does not do the job. AFAIK, you do need some extra settings that are probably in beehive (and in my build system ;-)). -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From thacker at math.cornell.edu Thu Jun 9 16:43:27 2005 From: thacker at math.cornell.edu (John Thacker) Date: Thu, 9 Jun 2005 12:43:27 -0400 Subject: Firefox crippling In-Reply-To: <877jh3qytt.fsf@kosh.bigo.ensc.de> References: <42A471CC.70905@redhat.com> <87slzv2x24.fsf@kosh.bigo.ensc.de> <42A492C7.3090809@redhat.com> <87oeaj2ve6.fsf@kosh.bigo.ensc.de> <1118109568.3119.8.camel@jellyfish.redfishdemo.com> <87wtp48w4b.fsf@kosh.bigo.ensc.de> <1118264506.4699.56.camel@localhost.localdomain> <87slzs8rni.fsf@kosh.bigo.ensc.de> <1118327963.16602.15.camel@localhost.localdomain> <877jh3qytt.fsf@kosh.bigo.ensc.de> Message-ID: <20050609164327.GA24246@thacker.dyndns.org> On Thu, Jun 09, 2005 at 06:28:30PM +0200, Enrico Scholz wrote: > > Filing bugs regarding Gnome2 usability is senseless; Gnome2 developers think > that they are the gods of usability and reject anything which is against > their ideas. I haven't noticed that. I have noticed that they tend to stick very tightly to a set of usability rules (which are approved and allow modification) which follow well-known guidelines that have been tested experimentally and with ordinary users by many, many companies and programmers. They don't seem to think that they are the "gods of usability"; if anything, they're following in the footsteps of a large amount of research and discussion from everyone in the industry. The only person I see as setting himself up as a "god of usability" is you, who apparently gets strongly upset whenever any one of your ideas is rejected. This despite that almost all of your suggestions that I've seen go against every well-known and well-tested concept of usability. It's easy enough to point you to books, essays, and research on the topic of usability (I believe that earlier someone pointed to links to chapters from Joel Spolsky's book, for example) that disagree with you. People aren't disagreeing with you out of arrogance or refusal to listen; they're disagreeing with you because there is real data to back their side. I don't doubt that your suggestions would make life easier for you personally, but they don't apply to users in general. I'm not going to reply anymore, though; fedora-desktop-devel or some of the GNOME desktop mailing lists are better places for this sort of thing. John Thacker -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From denis at poolshark.org Thu Jun 9 17:12:21 2005 From: denis at poolshark.org (Denis Leroy) Date: Thu, 09 Jun 2005 10:12:21 -0700 Subject: OT: nVidia driver [was: Wish list] In-Reply-To: <1118301038.5508.10.camel@laptopd505.fenrus.org> References: <16231728.1118263463122.JavaMail.root@wamui-rustique.atl.sa.earthlink.net> <1118283094.14929.21.camel@md.nc.linuxlobbyist.org> <1118301038.5508.10.camel@laptopd505.fenrus.org> Message-ID: <42A87875.9070300@poolshark.org> Arjan van de Ven wrote: > There probably are patents involved, but those don't in general prevent > open sourcing something unless you're on the wrong end of the stick. Yup that's likely, and if they opened the code, we'd still have our hands tied like with the MP3 code. OTOH, there's a trend lately of companies "pledging" their patents to the Open Source community (Nokia, CA, IBM...). Would it help if Nvidia did the same ? -denis From mattdm at mattdm.org Thu Jun 9 17:14:43 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 9 Jun 2005 13:14:43 -0400 Subject: OT: nVidia driver [was: Wish list] In-Reply-To: <42A87875.9070300@poolshark.org> References: <16231728.1118263463122.JavaMail.root@wamui-rustique.atl.sa.earthlink.net> <1118283094.14929.21.camel@md.nc.linuxlobbyist.org> <1118301038.5508.10.camel@laptopd505.fenrus.org> <42A87875.9070300@poolshark.org> Message-ID: <20050609171443.GA15010@jadzia.bu.edu> On Thu, Jun 09, 2005 at 10:12:21AM -0700, Denis Leroy wrote: > OTOH, there's a trend lately of companies "pledging" their patents to > the Open Source community (Nokia, CA, IBM...). Would it help if Nvidia > did the same ? Yes, as long as the do it like IBM or Red Hat rather than like Nokia. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 81 degrees Fahrenheit. From felipe.alfaro at gmail.com Thu Jun 9 18:07:09 2005 From: felipe.alfaro at gmail.com (Felipe Alfaro Solana) Date: Thu, 9 Jun 2005 20:07:09 +0200 Subject: OT: nVidia driver [was: Wish list] In-Reply-To: <3160.10.10.10.24.1118330289.squirrel@linux1> References: <20050609071047.C3C59732FF@hormel.redhat.com> <1118312804.4423.38.camel@bert64.mobile.smithconcepts.com> <1865.10.10.10.24.1118318325.squirrel@linux1> <3160.10.10.10.24.1118330289.squirrel@linux1> Message-ID: <6f6293f105060911073e208e75@mail.gmail.com> On 6/9/05, Sean wrote: > Linux has traditionally been most useful on servers so anyone engaged in > using it as a workstation has shed more blood than others using Linux. > However, the _vast_ majority of desktop users today can choose a video > card supported by open source which will meet their needs and not crash. > The constant drum beat of "nVidia binary drivers are the best" completely > misses that point. Hell there are even open source drivers available for > nVidia. Try enabling the Composite X.org extensions and KDE's transparency and shadow effects, then fire up glxgears and play a video with MPlayer. nVidia opensource drivers can't keep up with the work. However, propietary drivers can. And yes, I know most people don't need this, yet. From fedora at camperquake.de Thu Jun 9 18:46:32 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 9 Jun 2005 20:46:32 +0200 Subject: Firstboot: Module to add other OS partitions' entry to fstab In-Reply-To: <20050608122526.GF17703@devserv.devel.redhat.com> References: <20050530085600.53686.qmail@web30801.mail.mud.yahoo.com> <1118144436.4246.31.camel@daxter.boston.redhat.com> <604aa791050607090853289862@mail.gmail.com> <1118161102.3926.39.camel@daxter.boston.redhat.com> <604aa79105060710267387fbb1@mail.gmail.com> <1118226119.14331.29.camel@daxter.boston.redhat.com> <20050608102517.GA20620@ryoko.camperquake.de> <20050608122526.GF17703@devserv.devel.redhat.com> Message-ID: <20050609204632.3ea0797e@nausicaa.camperquake.de> Hi. Alan Cox wrote: > There are some ugly ones using snapshots, basically snapshot it and > fsck the snapshot. Then maybe we should avoid adding unclean file systems to fstab automagically. -- No luck for the crystal under the sign of the five. -- Nostradamus, c. 1503 on the Pentium bug. From thebs413 at earthlink.net Thu Jun 9 19:40:04 2005 From: thebs413 at earthlink.net (Bryan J. Smith ) Date: Thu, 9 Jun 2005 14:40:04 -0500 (GMT-05:00) Subject: OT: nVidia driver [was: Wish list] Message-ID: <17964574.1118346004592.JavaMail.root@wamui-little.atl.sa.earthlink.net> Felipe Alfaro Solana wrote: > Try enabling the Composite X.org extensions and KDE's transparency and > shadow effects, then fire up glxgears and play a video with MPlayer. > nVidia opensource drivers can't keep up with the work. However, > propietary drivers can. And yes, I know most people don't need this, > yet. Eye candy aside, it _would_ be nice to get PC platforms out of the dark ages of software-based and duplicate buffers and into the realm of windows as GPU rendered planes. I'm not talking about X RENDER where you merely use extra GPU framebuffer, but actually build the desktop environment under the GPU's control. Right now the _only_ platform that offers that well integrated is Apple c/o QuartzExtreme. It's _not_ about eye candy, but _efficiency_. The concepts of layer upon layer of overlapping, independent software buffers is rather ludicrious. The problem is that GLX isn't standard, which means you can't assume everyone has it. Microsoft has already bumped the Windows Graphic Framework (WGF) 2.0, fka DirectX 10, to post-NT6.0 Longhorn client release. Although Avalon is still in for NT6.0 Longhorn client release, it is going to be in the gutter, performance-wise, because the shipping WGF 1.0 is going to be DirectX 9 based and largely still software buffers. Now we've got innovative desktops like Xgl, and even the FreeDesktop Cario implementations we're now starting to see in things like Enlightenment DR17, as well as the next gen desktops. Without some good GLX solutions, Linux/X is going to continue to be a plague of inefficiency. Hell, atop of all that, one thing that was a pleasant surprise is Sun Looking Glass. Once I hit the API, I realized how forward-thinking Sun is. E.g., even input is treated as a 3D via the "picker." Talk about realizing that we really need to end the days of 2D buffers upon buffers, independent, unintegrated layers upon layers, the sooner every system is GLX, the better. And best of all, Looking Glass it's GPL -- not any MPL-like license or even MIT advertising. How we get GLX standard on the Linux desktop, I really don't care. It's all GLX, and if that means that some vendors put us their first with Standardware drivers, then don't knock them for putting forth the effort in the absence of "clean room" endeavors. Hopefully GLX on most 3D hardware _will_ become comodity, but at this point, it's quite the opposite. -- Bryan J. Smith mailto:b.j.smith at ieee.org From thebs413 at earthlink.net Thu Jun 9 20:00:00 2005 From: thebs413 at earthlink.net (Bryan J. Smith ) Date: Thu, 9 Jun 2005 15:00:00 -0500 (GMT-05:00) Subject: OT: nVidia driver [was: Wish list] (CORRECTION) Message-ID: <28907222.1118347200423.JavaMail.root@wamui-mouette.atl.sa.earthlink.net> From: "Bryan J. Smith " > Hell, atop of all that, one thing that was a pleasant surprise is Sun Looking > Glass. Once I hit the API, I realized how forward-thinking Sun is. E.g., even > input is treated as a 3D via the "picker." Talk about realizing that we really > need to end the days of 2D buffers upon buffers, independent, unintegrated > layers upon layers, the sooner every system is GLX, the better. And best of all, > Looking Glass it's GPL -- not any MPL-like license or even MIT advertising. Just as a clarification, while I often refer to accelerated OpenGL (via libGL) and OpenGL over X11 (GLX) interchangably, I do mean the former in most cases -- where the latter is typically inherited for free. I should make that distinction, because Looking Glass is not a GLX environment. It is a completely different, but GPL Freedomware (Open Source, Open Standard) environment with X11, GLX, etc... compatibility layers. -- Bryan J. Smith mailto:b.j.smith at ieee.org From pmatilai at laiskiainen.org Thu Jun 9 20:17:09 2005 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 09 Jun 2005 23:17:09 +0300 Subject: Testing RPM dependencies [was Re: ESP Ghostscript 8.x for FC5] In-Reply-To: <20050608133300.GF20486@ti64.telemetry-investments.com> References: <200506081121.j58BL0gO020822@porkchop.devel.redhat.com> <20050608120930.GW8706@redhat.com> <20050608133300.GF20486@ti64.telemetry-investments.com> Message-ID: <1118348229.15436.17.camel@weasel.laiskiainen.org> On Wed, 2005-06-08 at 09:33 -0400, Bill Rugolsky Jr. wrote: > On Wed, Jun 08, 2005 at 08:41:55AM -0400, Neal Becker wrote: > > for file in $(rpm -q --whatrequires ghostscript); do echo "..." $file && > > ( rpm -q --requires$file | grep ghostscript; ); done > > I find it much easier to let rpm show me the dependencies: > > sudo rpm --test -e ghostscript > > I seem to recall hearing some noises at some point (perhaps from Jeff Johnson) > that one ought not to do this, but I've never had a problem with it. I end up using rpm -e --test to see what packages actually require something as well, largely because rpm -e --whatrequires output is so horribly misleading (it only lists explicit package dependencies, not automatic). Repoquery can show the reality easier than shell-script tricks and multiple rpm runs: [pmatilai at weasel yum-utils]$ ./repoquery.py --quiet --whatrequires --alldeps ghostscript scribus-0:1.2.1-5.x86_64 ghostscript-0:8.15-0.rc3.2.x86_64 system-config-printer-0:0.6.131-1.x86_64 fbida-fbgs-0:2.03-5.x86_64 ghostscript-gtk-0:8.15-0.rc3.2.x86_64 gimp-print-0:4.2.7-10.x86_64 libgnomeprint22-0:2.10.3-1.i386 ghostscript-devel-0:8.15-0.rc3.2.x86_64 libgnomeprint22-0:2.10.3-1.x86_64 TeXmacs-0:1.0.4.6-1.x86_64 gsview-0:4.6-10.x86_64 gnome-print-1:0.37-11.x86_64 ghostscript-fonts-0:5.50-13.noarch OTOH it will list all packages on the yum package universe requiring ghostscript, not just what you have installed. Supporting that is on my todo-list, if only for this very reason (figuring out dependencies of installed packages reliably without shellscripts or rpm -e --test). - Panu - From jlayton at redhat.com Thu Jun 9 20:29:23 2005 From: jlayton at redhat.com (Jeff Layton) Date: Thu, 09 Jun 2005 16:29:23 -0400 Subject: [PATCH] mkinitrd rescue mode - now crypto In-Reply-To: <1118250922.5299.60.camel@localhost.localdomain> References: <1117653405.12259.51.camel@barsoom.rdu.redhat.com> <1117725836.3768.15.camel@bree.local.net> <1117731994.12259.68.camel@barsoom.rdu.redhat.com> <1118081184.9625.5.camel@localhost.localdomain> <1118250922.5299.60.camel@localhost.localdomain> Message-ID: <1118348963.19973.27.camel@barsoom.rdu.redhat.com> On Wed, 2005-06-08 at 13:15 -0400, Michael H. Warfield wrote: > Any idea when the > switchroot thing will be fixed to completely free up the initramfs > thing? Looks like Peter incorporated a slightly modified version of my patch into mkinitrd-4.2.16. I've been working with it today and that version of nash seems to work, but it's tough to tell whether it's actually cleaning things up or not. Is there some way to tell whether it's actually cleaning things up? Where would this memory allocation show up under /proc/meminfo? Perhaps I can roll a large initramfs image, and see if there is a difference with and without this nash patch in how memory is allocated... -- Jeff Layton From kyrre at solution-forge.net Thu Jun 9 20:55:33 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Thu, 09 Jun 2005 22:55:33 +0200 Subject: Making update functionality more usable (Was: Re: What next?) In-Reply-To: <1118320956.2897.37.camel@roque> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <1117730130.1674.3.camel@weasel.laiskiainen.org> <429FDACF.20608@rueb.com> <1117780095.3488.32.camel@cutter> <1117809250.8385.11.camel@mlenzdesktop> <1118024411.3011.11.camel@bree.local.net> <1118048011.2779.2.camel@roque> <1118234067.20494.39.camel@arena.soho.bytebot.net> <1118320956.2897.37.camel@roque> Message-ID: <1118350533.7337.0.camel@localhost.localdomain> tor, 09.06.2005 kl. 14.42 skrev Rui Miguel Seabra: > On Wed, 2005-06-08 at 05:34 -0700, Colin Charles wrote: > > On Mon, 2005-06-06 at 09:53 +0100, Rui Miguel Seabra wrote: > > > > > I hate to admit it but I remove all the redhat update stuff as well and > > > > > use yum or apt-get (if i'm feeling impatient). I used ubuntu for awhile > > > > > (but ultimately found fedora to be superior) and found their update > > > > > functionality much more usable. > > > > > > > > Since one of the goals of FC5 is to have pup in place to handle updates > > > > from a graphical point of view, I'd be interested in hearing what sorts > > > > of things made the Ubuntu stuff more usable. Or the same for other > > > > distros as well. > > > > Just to make it clear, Ubuntu just has: dpkg/apt, Synaptic, and > > update-notifier, right? > > > > We (will) have: rpm/yum, s-c-packages(okay, pup), and pup's > > update-notifier > > They have a graphical update manager that's very fancy. Probably the > update-notifier icon is part of that update manager. > > Another very interesting thing is that every single one of those apps > around packaging use the same repo settings (besides other settings), so > they feel integrated. > > Rui They all use apt, so apt sources is always used. I think Fedora is also heading that way (yum). From gmaxwell at gmail.com Thu Jun 9 20:59:00 2005 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Thu, 9 Jun 2005 16:59:00 -0400 Subject: [PATCH] mkinitrd rescue mode - now crypto In-Reply-To: <1118250922.5299.60.camel@localhost.localdomain> References: <1117653405.12259.51.camel@barsoom.rdu.redhat.com> <1117725836.3768.15.camel@bree.local.net> <1117731994.12259.68.camel@barsoom.rdu.redhat.com> <1118081184.9625.5.camel@localhost.localdomain> <1118250922.5299.60.camel@localhost.localdomain> Message-ID: On 6/8/05, Michael H. Warfield wrote: > Only reason I seem to need nash at all, right now, is for the > "makerootdev" command and the "switchroot" command (busybox has > pivot_root, but not switchroot, and I can ignore the "setquiet" noise). > With those two functions, I could dump nash entirely and operate totally > from busybox with a minimal increase in size. Which raises some other > questions regarding busybox... I too am running an entirely encrypted disk (LVM in dmcrypt no less, so I get auto volume detection)... I pretty much solved it the same way you did, I kept nash around for switchroot and change to ash for everything else so I could interact with the password prompt. From pjones at redhat.com Thu Jun 9 21:13:39 2005 From: pjones at redhat.com (Peter Jones) Date: Thu, 09 Jun 2005 17:13:39 -0400 Subject: [PATCH] mkinitrd rescue mode - now crypto In-Reply-To: <1118348963.19973.27.camel@barsoom.rdu.redhat.com> References: <1117653405.12259.51.camel@barsoom.rdu.redhat.com> <1117725836.3768.15.camel@bree.local.net> <1117731994.12259.68.camel@barsoom.rdu.redhat.com> <1118081184.9625.5.camel@localhost.localdomain> <1118250922.5299.60.camel@localhost.localdomain> <1118348963.19973.27.camel@barsoom.rdu.redhat.com> Message-ID: <1118351619.27196.2.camel@localhost.localdomain> On Thu, 2005-06-09 at 16:29 -0400, Jeff Layton wrote: > On Wed, 2005-06-08 at 13:15 -0400, Michael H. Warfield wrote: > > Any idea when the > > switchroot thing will be fixed to completely free up the initramfs > > thing? > > Looks like Peter incorporated a slightly modified version of my patch > into mkinitrd-4.2.16. I've been working with it today and that version > of nash seems to work, but it's tough to tell whether it's actually > cleaning things up or not. > > Is there some way to tell whether it's actually cleaning things up? > Where would this memory allocation show up under /proc/meminfo? Perhaps > I can roll a large initramfs image, and see if there is a difference > with and without this nash patch in how memory is allocated... Well, there is the scary echo/cd hack patch that was attached to one of those bugs... -- Peter From conditionterminal at gmail.com Thu Jun 9 21:26:19 2005 From: conditionterminal at gmail.com (condition terminal) Date: Fri, 10 Jun 2005 09:26:19 +1200 Subject: question about RedHat/Fedora and the GPL In-Reply-To: <1118241043.3354.6.camel@localhost.localdomain> References: <1118040569.5652.2.camel@laptopd505.fenrus.org> <200506061622.28649.symbiont@berlios.de> <1118241043.3354.6.camel@localhost.localdomain> Message-ID: On 6/9/05, Kyrre Ness Sjobak wrote: > man, 06.06.2005 kl. 10.22 skrev Jeff Pitman: > > On Monday 06 June 2005 15:48, condition terminal wrote: > > > OK then.. so how are the files and scripts used to control the > > > building of the rpms outside the specs excluded from the conditions > > > of the GPL? > > > > Think of beehive as an over-glorified cron system. If you use cron to > > do a daily checkout from CVS and build a system, that doesn't mean you > > need to release the source code to cron for every release of your > > software. You could even use some proprietary cron setup and still not > > be obligated to release it. > > -- > > -jeff > > Sorry for dup., hit send a bit to early... > > And then there is people building GPL software with Closed-Source tools > such as the MS compiler... Does that make MS obligated to release their > compiler as GPL? > > Just curious... > > That would be fun. > I bet the GPL police would be all over them in a heart beat. Provided the coplied software linked with any of the compiler libs, as happens with GCC (to my knowledge). ta From thebs413 at earthlink.net Thu Jun 9 21:35:02 2005 From: thebs413 at earthlink.net (Bryan J. Smith ) Date: Thu, 9 Jun 2005 16:35:02 -0500 (GMT-05:00) Subject: OT: nVidia driver [was: Wish list] -- nVidia doesn't own a lot of the IP Message-ID: <4566127.1118352903177.JavaMail.root@wamui-hound.atl.sa.earthlink.net> From: Denis Leroy > Yup that's likely, and if they opened the code, we'd still have our > hands tied like with the MP3 code. > OTOH, there's a trend lately of companies "pledging" their patents to > the Open Source community (Nokia, CA, IBM...). Would it help if Nvidia > did the same ? The problem is that you assume nVidia actually _owns_ the IP. They do _not_. ATI is in the same boat, that's why they are now doing a unified driver. Matrox has been the same as well. nVidia, Matrox and others have gotten themselves in some messy legal issues for code release in the past. So either you create an independent, "clean room" version, or you're at the mercy of the IP holders. I see the first major IP battle in the 3D space. And companies like nVidia, SGI and Sun will be our allies against the biggest IP leech of them all in the OpenGL space ... Microsoft. I don't think people realize how much of an IP issue there really is in this space. And when you have companies that hold inter-twined patents on all sorts of 3D concepts, it really matters little how "clean room" the code is anyway. 3D is an IP landfield. -- Bryan J. Smith mailto:b.j.smith at ieee.org From rjune at bravegnuworld.com Thu Jun 9 21:23:39 2005 From: rjune at bravegnuworld.com (Richard June) Date: Thu, 9 Jun 2005 16:23:39 -0500 Subject: OT: nVidia driver [was: Wish list] In-Reply-To: <3160.10.10.10.24.1118330289.squirrel@linux1> References: <20050609071047.C3C59732FF@hormel.redhat.com> <3160.10.10.10.24.1118330289.squirrel@linux1> Message-ID: <200506091623.43367.rjune@bravegnuworld.com> [snip] > > (ii) There isn't any 3-d card with open source driver support that's > > within an order of magntitue of current nvidia and ATI cards in > > performance > > And the vast majority of users won't be using any of that added capacity > and shouldn't be encouraged to use binary drivers when they have no need > to do so. Uhm, WOW! that's a completely retarded statement. *normal* users as defined by what? nearly everybody I know of that uses Linux on the desktop plays games. and surprisingly, many commercial games available for linux(and quite a few Open Source games) make excellent use of that added capacity. so those binary only drivers make a huge difference. > > (iii) I like doing stream programming with the GPU > > So you're not exactly a typical user then are you? > > > In a lot of ways, propreitary hardware/software combos from vendors > > like Apple and Sun are starting to look good to me. Linux has a lot of > > quality problems because much of the hardware it supports is junk and it > > has bad drivers even for good hardware: for instance, Apache disables > > the sendfile() system call on Linux because some network cards supported > > by Linux are total crap and can corrupt data when using sendfile() on an > > NFS-mounted file. > > Well Apple has just announced they're going to be moving to Intel CPU's so > not sure you want to move in their direction just yet. Anyway, do > whatever you want, if you don't believe in open source and it's not ready > to service your needs yet, there's no harm in you going and doing > something else. Apple moving to an intel chip doesn't mean it won't be proprietary hardware. Jobs already said that Mac OS will only run on apple hardware, just like it does now. > > What's terrible is that there isn't any reliable way to know what's junk > > and what isn't. I'll ask around online and it's like calling your > > average software vendor for support: "Yeah, there's a driver for that > > card, it's supported, it's fine." A year later I finally find out other > > people are having horrible performance and crashes too -- cold comfort. > > Yes there is a reliable way, every RHEL system i've ever installed has > gone completely without a hardware problem. RedHat is _great_ about > helping you find the correct hardware to meet your needs. > > > Yeah sure, but there are risks everywhere. You can get hit by a bus > > crossing the street. Tainted kernel or not, I've never seen a Linux 2.4 > > system running non-scientific workloads on an SMP machines that didn't > > have strange concurrency problems. There are lots of open source > > drivers that suck -- I'd rather trade a propreitary driver that actually > > works for an open source driver that crashes my machine. > > Go nuts, but i'd rather have a working open source driver. yeah, that's great, but that wasn't one of the choices he thinks he has. If somebody came out with a 3d card that did pretty well, and GPLed the drivers so that we had reasonable performance with it, lots of people would buy it. like he said though, if I have a choice between proprietary drivers that work and GPL one's that don't. I pick the ones that work. > > It might not be fair that good graphic cards are propreitary and that you > > can't make free drivers for 802.11g but the real choice is between being > > pure and being relevant: you ought to be glad that I'm choosing to run > > Linux with modern graphics cards and modern wireless networking rather > > than choosing to foresake Linux so I can support modern hardware. > > Linux is running on some of the most modern hardware around. Having a > bunch of people hacking in binary crap to Linux does nothing to move it > forward in any important way. Uhm, yes and no. More users means more and better support. which means the likelihood of some company figuring out that they stand to turn a tidy profit by GPLing their software goes up. if it works out of the box, it becomes preferred. But it also demonstrates that we're wililng to accept binary only. > > In some areas that's true. Name a specific graphics card I should be > > using, and show me some evidence that it can make it more than two hours > > without a crash and I might believe you. > > Sounds like you wouldn't be happy with the open source card I'm using to > write this email now, however it sure suits my purposes and it hasn't > crashed on me ever. Nope. I play games on my box. I use an ATi 9200SE, hardly state of the art, but the OSS drivers still don't work very well. -- Public Key available Here: http://www.bravegnuworld.com/~rjune/pubkey.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mike at flyn.org Thu Jun 9 22:36:51 2005 From: mike at flyn.org (W. Michael Petullo) Date: Thu, 9 Jun 2005 17:36:51 -0500 (CDT) Subject: [PATCH] mkinitrd rescue mode - now crypto In-Reply-To: References: <1117653405.12259.51.camel@barsoom.rdu.redhat.com> <1117725836.3768.15.camel@bree.local.net> <1117731994.12259.68.camel@barsoom.rdu.redhat.com> <1118081184.9625.5.camel@localhost.localdomain> <1118250922.5299.60.camel@localhost.localdomain> Message-ID: <1291.140.192.38.105.1118356611.squirrel@zero.voxel.net> >> Only reason I seem to need nash at all, right now, is for the >> "makerootdev" command and the "switchroot" command (busybox has >> pivot_root, but not switchroot, and I can ignore the "setquiet" noise). >> With those two functions, I could dump nash entirely and operate totally >> from busybox with a minimal increase in size. Which raises some other >> questions regarding busybox... > > I too am running an entirely encrypted disk (LVM in dmcrypt no less, > so I get auto volume detection)... I pretty much solved it the same > way you did, I kept nash around for switchroot and change to ash for > everything else so I could interact with the password prompt. I have been maintaining a patch for Fedora's mkinitrd that adds support for encrypted root filesystems. The patch may be found at: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124789 Currently, my system requires that the boot partition and encryption key reside together on a removable disk. -- Mike From wtogami at redhat.com Thu Jun 9 23:37:55 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 09 Jun 2005 13:37:55 -1000 Subject: mtune=nocona In-Reply-To: <1118330922.14381.8.camel@dcbw.boston.redhat.com> References: <200506091403.j59E3VBB005184@laptop11.inf.utfsm.cl> <1118326548.14381.6.camel@dcbw.boston.redhat.com> <20050609152703.GA19461@devserv.devel.redhat.com> <1118330922.14381.8.camel@dcbw.boston.redhat.com> Message-ID: <42A8D2D3.1000003@redhat.com> Dan Williams wrote: > On Thu, 2005-06-09 at 11:27 -0400, Alan Cox wrote: > >>On Thu, Jun 09, 2005 at 10:15:48AM -0400, Dan Williams wrote: >> >>>Would you like: (a) Small speed hit for Opteron users, OR (b) much >>>larger speed hit for EM64T users? >>> >>>(a), ie -mtune=nocona everywhere, seems to be the fairest option here >>>for everybody since we obviously cannot make 1 build of Fedora Core for >>>Opteron and 1 comletely separate build of Fedora Core for EM64T. >> >>That sort of depends on market share. I would put a beer on almost all Fedora >>64bit users being AMD users because Fedora is appealing to the technically >>aware community rather than those whose choice is driven by "business >>relationships" as happens in the enterprise space > > > However, simply due to sheer marketshare, Intel may in the future have > the most x86_64 processors out there. Where does that leave us? > Including x86_64 celerons... Warren From pri.rhl4 at iadonisi.to Fri Jun 10 00:09:32 2005 From: pri.rhl4 at iadonisi.to (Paul Iadonisi) Date: Thu, 09 Jun 2005 20:09:32 -0400 Subject: OT: nVidia driver [was: Wish list] -- nVidia doesn't own a lot of the IP In-Reply-To: <4566127.1118352903177.JavaMail.root@wamui-hound.atl.sa.earthlink.net> References: <4566127.1118352903177.JavaMail.root@wamui-hound.atl.sa.earthlink.net> Message-ID: <1118362173.2936.8.camel@md.nc.linuxlobbyist.org> On Thu, 2005-06-09 at 16:35 -0500, Bryan J. Smith wrote: > From: Denis Leroy > > Yup that's likely, and if they opened the code, we'd still have our > > hands tied like with the MP3 code. > > OTOH, there's a trend lately of companies "pledging" their patents to > > the Open Source community (Nokia, CA, IBM...). Would it help if Nvidia > > did the same ? > > The problem is that you assume nVidia actually _owns_ the IP. > They do _not_. ATI is in the same boat, that's why they are now > doing a unified driver. Matrox has been the same as well. > > nVidia, Matrox and others have gotten themselves in some messy > legal issues for code release in the past. So either you create an > independent, "clean room" version, or you're at the mercy of the > IP holders. > > I see the first major IP battle in the 3D space. And companies like > nVidia, SGI and Sun will be our allies against the biggest IP leech > of them all in the OpenGL space ... > > Microsoft. If I saw nVidia and ATI maybe actively participating in the antitrust case against Microsoft in the EU and joining NoSoftwarePatents.com then I'd be willing to cut them some slack. And take a stand against the current patent system in the US. That goes for any other company that is in this kind of mess. Otherwise, they are just playing the victims. Or perhaps it isn't them painting *themselves* as victims. But if they expended the resources necessary to *change* this mess more than in their cloistered little worlds (with the resulting limited effect) then maybe we'd get somewhere. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From jbuell at vmware.com Fri Jun 10 01:22:05 2005 From: jbuell at vmware.com (Jeffrey Buell) Date: Thu, 9 Jun 2005 18:22:05 -0700 Subject: SEP bit disabled in FC Message-ID: <58743620D2C0D9439C627C064581E25218D76F@PA-ECLUSTER2.vmware.com> In arch/i386/kernel/cpu/common.c: /* hack: disable SEP for non-NX cpus; SEP breaks Execshield. */ #ifdef CONFIG_HIGHMEM64G if (!test_bit(X86_FEATURE_NX, c->x86_capability)) #endif clear_bit(X86_FEATURE_SEP, c->x86_capability); So, in order to enable Execshield, the SEP cpu bit (sysenter/sysexit) has to be turned off. But this costs a lot of performance: as much as 2.5X in syscall-heavy benchmarks (e.g., process tests in lmbench). How permanent is this hack? Will Execshield be fixed (or removed) by FC5? Ever? Note that SEP is enabled in SuSE 9.3, for instance. Jeff From davej at redhat.com Fri Jun 10 01:25:32 2005 From: davej at redhat.com (Dave Jones) Date: Thu, 9 Jun 2005 21:25:32 -0400 Subject: SEP bit disabled in FC In-Reply-To: <58743620D2C0D9439C627C064581E25218D76F@PA-ECLUSTER2.vmware.com> References: <58743620D2C0D9439C627C064581E25218D76F@PA-ECLUSTER2.vmware.com> Message-ID: <20050610012532.GB24256@redhat.com> On Thu, Jun 09, 2005 at 06:22:05PM -0700, Jeffrey Buell wrote: > In arch/i386/kernel/cpu/common.c: > > /* hack: disable SEP for non-NX cpus; SEP breaks Execshield. */ > #ifdef CONFIG_HIGHMEM64G > if (!test_bit(X86_FEATURE_NX, c->x86_capability)) > #endif > clear_bit(X86_FEATURE_SEP, c->x86_capability); > > So, in order to enable Execshield, the SEP cpu bit (sysenter/sysexit) has to > be turned off. But this costs a lot of performance: as much as 2.5X in > syscall-heavy benchmarks (e.g., process tests in lmbench). > > How permanent is this hack? Will Execshield be fixed (or removed) by FC5? It was going to be reeanbled for FC4, but due to a last minute glitch, (which we think we fixed), we disabled for it for the release with the intention of reenabling it in the first kernel update that goes out for FC4. Dave From subsolar at subsolar.org Fri Jun 10 01:33:45 2005 From: subsolar at subsolar.org (Paul) Date: Thu, 09 Jun 2005 20:33:45 -0500 Subject: OT: nVidia driver [was: Wish list] In-Reply-To: <7551805.1118333528805.JavaMail.root@wamui-hybrid.atl.sa.earthlink.net> References: <7551805.1118333528805.JavaMail.root@wamui-hybrid.atl.sa.earthlink.net> Message-ID: <1118367225.5207.2.camel@localhost> On Thu, 2005-06-09 at 11:12 -0500, Bryan J. Smith wrote: > Paul Iadonisi wrote: > > But you're starting to sound like Sun's Jonathan Schwartz. To him, > > and some others in the industry, open standards matter more than > > source code under a Free license. > > Now I _never_ made that. Why does everything have to be in black > and white? All I said is you can_not_ apply the same logic of proprietary > standards to proprietary source of open standards. That's all. Because only the SITH see things as absolutes?? J/K Paul From roland at redhat.com Fri Jun 10 01:35:06 2005 From: roland at redhat.com (Roland McGrath) Date: Thu, 9 Jun 2005 18:35:06 -0700 Subject: SEP bit disabled in FC In-Reply-To: Jeffrey Buell's message of Thursday, 9 June 2005 18:22:05 -0700 <58743620D2C0D9439C627C064581E25218D76F@PA-ECLUSTER2.vmware.com> Message-ID: <200506100135.j5A1Z68n030784@magilla.sf.frob.com> > In arch/i386/kernel/cpu/common.c: > > /* hack: disable SEP for non-NX cpus; SEP breaks Execshield. */ > #ifdef CONFIG_HIGHMEM64G > if (!test_bit(X86_FEATURE_NX, c->x86_capability)) > #endif > clear_bit(X86_FEATURE_SEP, c->x86_capability); > > So, in order to enable Execshield, the SEP cpu bit (sysenter/sysexit) has to > be turned off. But this costs a lot of performance: as much as 2.5X in > syscall-heavy benchmarks (e.g., process tests in lmbench). That is unavoidable on CPUs that do not have NX support. Using sysexit resets to flat 4GB segments, so you lose the protection of a limited code segment preventing all readable pages from being executable. When the CPU supports the NX page table bit, we don't use segments for execute permission and so it is safe to enable sysenter/sysexit. CPUs being sold this year have NX support, so you don't have this limitation. From ville.skytta at iki.fi Fri Jun 10 06:29:14 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 10 Jun 2005 09:29:14 +0300 Subject: Firefox crippling In-Reply-To: <87oeag8r7b.fsf@kosh.bigo.ensc.de> References: <87ekbhxfih.fsf@kosh.bigo.ensc.de> <20050605161545.GA28581@devserv.devel.redhat.com> <87ll5nuc2f.fsf_-_@kosh.bigo.ensc.de> <42A471CC.70905@redhat.com> <87slzv2x24.fsf@kosh.bigo.ensc.de> <42A492C7.3090809@redhat.com> <87oeaj2ve6.fsf@kosh.bigo.ensc.de> <1118109568.3119.8.camel@jellyfish.redfishdemo.com> <87wtp48w4b.fsf@kosh.bigo.ensc.de> <42A753A5.7090703@redhat.com> <20050608205527.GA10700@thacker.dyndns.org> <87oeag8r7b.fsf@kosh.bigo.ensc.de> Message-ID: <1118384954.11604.26.camel@bobcat.mine.nu> On Wed, 2005-06-08 at 23:38 +0200, Enrico Scholz wrote: > I do not know KDE, but I can imagine that people with this desktop > environment will be shocked also when they see the current firefox > icons; they probably do not match the KDE theme neither. I use KDE and FF, but "shocked" is a bit strong expression to describe what I felt when first seeing these new icons. A strong dislike would be more accurate. Anyway, these icons made me realize that I never use the home or reload buttons anyway, so I got rid of them. Part of the problem solved. Other parts of the problem still remain. I do agree that replacing the default theme of a themeable browser, and while at it, making it impossible to switch back to the original doesn't sound like a good idea. (I haven't studied the theming in-depth, so there might be inaccuracies here.) BTW, the "Firefox (default) 2.0" theme which AFAICT is now no longer what it says in the FF themes UI is still "credited" to the original upstream authors. From arjanv at redhat.com Fri Jun 10 07:32:55 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Fri, 10 Jun 2005 09:32:55 +0200 Subject: SEP bit disabled in FC In-Reply-To: <20050610012532.GB24256@redhat.com> References: <58743620D2C0D9439C627C064581E25218D76F@PA-ECLUSTER2.vmware.com> <20050610012532.GB24256@redhat.com> Message-ID: <1118388776.5272.14.camel@laptopd505.fenrus.org> On Thu, 2005-06-09 at 21:25 -0400, Dave Jones wrote: > On Thu, Jun 09, 2005 at 06:22:05PM -0700, Jeffrey Buell wrote: > > In arch/i386/kernel/cpu/common.c: > > > > /* hack: disable SEP for non-NX cpus; SEP breaks Execshield. */ > > #ifdef CONFIG_HIGHMEM64G > > if (!test_bit(X86_FEATURE_NX, c->x86_capability)) > > #endif > > clear_bit(X86_FEATURE_SEP, c->x86_capability); > > > > So, in order to enable Execshield, the SEP cpu bit (sysenter/sysexit) has to > > be turned off. But this costs a lot of performance: as much as 2.5X in > > syscall-heavy benchmarks (e.g., process tests in lmbench). > > > > How permanent is this hack? Will Execshield be fixed (or removed) by FC5? > > It was going to be reeanbled for FC4, but due to a last minute glitch, > (which we think we fixed), we disabled for it for the release with > the intention of reenabling it in the first kernel update that goes > out for FC4. You're confusing VDSO page with SEP. You can't have both SEP and the segment limit part of execshield at the same time. -------------- 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 russell at coker.com.au Fri Jun 10 07:57:39 2005 From: russell at coker.com.au (Russell Coker) Date: Fri, 10 Jun 2005 17:57:39 +1000 Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ In-Reply-To: <42A5E1F5.6050209@linux360.ro> References: <19543506.1118090925521.JavaMail.root@wamui-milano.atl.sa.earthlink.net> <20050607160935.GA4680@nostromo.devel.redhat.com> <42A5E1F5.6050209@linux360.ro> Message-ID: <200506101757.43309.russell@coker.com.au> On Wednesday 08 June 2005 04:05, "Razvan Corneliu C.R. Vilt" wrote: > I hate to be the bad guy over here, but what about something similar > with SMF from Solaris. It's by far the best thing for what we need, and Is this the Solaris feature that so many people complain about because it makes changes to a binary file on every boot? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From harald at redhat.com Fri Jun 10 06:59:54 2005 From: harald at redhat.com (Harald Hoyer) Date: Fri, 10 Jun 2005 08:59:54 +0200 Subject: gnome-vfs not in Rawhide? In-Reply-To: References: <20050407132815.15244.qmail@web8504.mail.in.yahoo.com> Message-ID: <42A93A6A.6040501@redhat.com> Mike Hearn wrote: > On Thu, 07 Apr 2005 06:28:15 -0700, Rahul Sundaram wrote: > >>The question is what kind of error messages do you get >>from the loki installers if gtk1 is not installed on >>the system already. > > > Good question! Some of them are statically linked with GTK 1.2, I think > it's a build time configuration option. I just renamed my copy and ran one > Loki Setup, this is what I got: > > Gtk-WARNING **: libgtk-1.2.so.0: cannot open shared object file: No such file or directory > > Gdk-WARNING **: Missing charsets in FontSet creation > [other stuff that's probably unrelated snipped] > > But the GUI appeared anyway. So I'm not sure what it's doing - trying to > use the systems copy and otherwise falling back to a builtin one? > > Then I tried another, for the game "Dark Horizons Lore" and it didn't show > the GTK UI, but it still "worked" in that it fell back to an ncurses based > install. > > This was the error: > /root/.setup4665: error while loading shared libraries: libgtk-1.2.so.0: > cannot open shared object file: No such file or directory > > Text based installers for games are from the DOS era though. I don't think > that should be counted as working. > > > Let me show you what "could" be done for the desktop user, who cannot read terminal output, as he does not use a terminal: The dynamic loader, which raises "error while loading shared libraries: libgtk-1.2.so.0: cannot open shared object file: No such file or directory" could send a message on the user's session DBUS with a helper tool (exec "/bin/error-shared-lib-not-found"). A small helper app listens on the user's session DBUS for such a message and presents a gui dialog to the user stating: "Application foo needs the library bar to run.". It can offer the user to search the rpmdb and the internet repos for this file and, if found, to install the appropriate rpm package with all its dependencies. Just a thought, but quite useful for any unexperienced linux user :) From mikem at cyber.com.au Fri Jun 10 10:29:13 2005 From: mikem at cyber.com.au (Mike MacCana) Date: Fri, 10 Jun 2005 20:29:13 +1000 Subject: Smart package manager (was Re: Making update functionality more usable (Was: Re: What next?)) In-Reply-To: <1118234067.20494.39.camel@arena.soho.bytebot.net> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <1117730130.1674.3.camel@weasel.laiskiainen.org> <429FDACF.20608@rueb.com> <1117780095.3488.32.camel@cutter> <1117809250.8385.11.camel@mlenzdesktop> <1118024411.3011.11.camel@bree.local.net> <1118048011.2779.2.camel@roque> <1118234067.20494.39.camel@arena.soho.bytebot.net> Message-ID: <42A96B79.5010609@cyber.com.au> Colin Charles wrote: >Just to make it clear, Ubuntu just has: dpkg/apt, Synaptic, and >update-notifier, right? > >We (will) have: rpm/yum, s-c-packages(okay, pup), and pup's >update-notifier > > 1. I'd like to add smart install to Extras. - It's written by the author of Synaptic and principal maintainer of apt-get for RPM - Its a replacement for yum / apt-get / up2date / synaptic / etc. - It has both a CLI and GUI interface. - The GUI version is GTK2, and looks exactly like Synaptic (oddly enough being written by the same author). - It works with Yum metadata repositories. - Its faster than yum and apt-get as it downloads from multiple sources simultaneously. I've been using it on Rawhide for months and it's fast, simple, and reliable. 2. What's pup? Where can I find out more about it? What's it's relationship to s-c-p? Mike From mitr at volny.cz Fri Jun 10 11:02:39 2005 From: mitr at volny.cz (Miloslav Trmac) Date: Fri, 10 Jun 2005 13:02:39 +0200 Subject: Stop! (was Re: OT: nVidia driver) In-Reply-To: <1118205816.4456.25.camel@bert64.mobile.smithconcepts.com> References: <20050608012857.4573B73725@hormel.redhat.com> <1118205816.4456.25.camel@bert64.mobile.smithconcepts.com> Message-ID: <20050610110234.GB25817@chrys.ms.mff.cuni.cz> Why exactly does this discussion belong to fedora-devel-list? Before answering please reread Fedora Project objective 2. Mirek From buildsys at redhat.com Fri Jun 10 11:42:10 2005 From: buildsys at redhat.com (Build System) Date: Fri, 10 Jun 2005 07:42:10 -0400 Subject: rawhide report: 20050610 changes Message-ID: <200506101142.j5ABgAA1000595@porkchop.devel.redhat.com> New package javacc A parser/scanner generator for java Updated Packages: ImageMagick-6.2.2.0-4 --------------------- * Thu Jun 09 2005 Tim Waugh 6.2.2.0-4 - Rebuilt for fixed ghostscript. arptables_jf-0:0.0.8-5 ---------------------- * Thu Jun 09 2005 Jay Fenlason 0.0.8-5 - add -man patch to correct the names of the default tables. bz#123089 aptables man pages is not correct: built in chain name are wrong. * Tue Mar 08 2005 Jay Fenlason 0.0.8-4 - rebuilt with gcc4 * Fri Nov 26 2004 Florian La Roche - add a %clean target into .spec audit-0.9.3-1 ------------- * Thu Jun 09 2005 Steve Grubb 0.9.3-1 - Change filename handling to use linked list in ausearch - Add man pages for audit_setloginuid & audit_getloginuid - Fix problem where you couldn't set rule on unset loginuid's - Adjust memory management for sighup needs - Fix problem where netlink timeout counter wasn't being reset ddd-3.3.11-1 ------------ * Thu Jun 09 2005 Than Ngo 3.3.11-1 - 3.3.11 - add workaround for utf8 dump-0.4b40-3 ------------- * Thu Jun 09 2005 Jindrich Novy 0.4b40-3 - fix restoration of ext3 ACL's (#159617) - Stelian Pop elfutils-0.108-5 ---------------- * Thu Jun 09 2005 Roland McGrath - 0.108-5 - robustification of eu-strip and eu-readelf gaim-1:1.3.1-0.fc5 ------------------ * Thu Jun 09 2005 Warren Togami 1:1.3.1-0 - 1.3.1 more bug fixes CAN-2005-1269 CAN-2005-1934 - enable Message Notification plugin by default ghostscript-8.15-0.rc3.3 ------------------------ * Thu Jun 09 2005 Tim Waugh 8.15-0.rc3.3 - Build requires xorg-x11-devel, not XFree86-devel. - Include ierrors.h in the devel package. gkrellm-2.2.7-1 --------------- * Thu Jun 09 2005 Karsten Hopp 2.2.7-1 - update to 2.2.7 - add Requires: /sbin/chkconfig for -daemon subpackage - allow gkrellm width up to 1600 pixel - change spec file to valid UTF-8 (#159578) hplip-0.9.3-2 ------------- jpilot-0.99.8-0.pre9.1 ---------------------- * Thu Jun 09 2005 Ivana Varekova 0.99.8-0.pre9.1 - rebuilt new version (0.99.8-pre9) kernel-2.6.11-1.1381_FC5 ------------------------ * Thu Jun 09 2005 Dave Jones - 2.6.12-rc6-git3 - Temporarily disable the ipw drivers until I sort them out. * Tue Jun 07 2005 Dave Jones - 2.6.12-rc6-git1 - Disable hercules fb. If you have one of these, please put it back in the trash. Thanks. * Mon Jun 06 2005 Dave Jones - 2.6.12-rc6 - Copy asm-i386 into x86-64's kernel-devel too. (#150266) m2crypto-0.13-4 --------------- * Thu Jun 09 2005 Miloslav Trmac - 0.13-4 - Fix invalid handle_error override in SSL.SSLServer (#159898, patch by Dan Williams) openssh-4.1p1-2 --------------- * Thu Jun 09 2005 Tomas Mraz 4.1p1-2 - use only pam_nologin for nologin testing pam-0.79-10 ----------- * Thu Jun 09 2005 Tomas Mraz 0.79-10 - add the Requires dependency on audit-libs (#159885) - pam_loginuid shouldn't report error when /proc/self/loginuid is missing (#159974) pam_ccreds-1-7 -------------- * Thu Jun 09 2005 John Dennis - 1-7 - fix bug #134674, change BuildPrereq openssl to openssl-devel pilot-link-1:0.12.0-0.pre3.2 ---------------------------- * Thu Jun 09 2005 Than Ngo 0.12.0-0.pre3.2 - fix non utf-8 in changelog #159582 pychecker-0.8.14-4 ------------------ * Thu Jun 09 2005 Miloslav Trmac - 0.8.14-4 - Backport a fix for spurious warnings about "is{, not} None" redhat-artwork-0.124-1 ---------------------- * Thu Jun 09 2005 Than Ngo 0.124-1 - fix ComboBox_Popup issue in qt-theme #157809 - drop redhat-artwork-0.122-throbbers.patch, it's in new upstream selinux-policy-strict-1.23.18-4 ------------------------------- * Thu Jun 09 2005 Dan Walsh 1.23.18-4 - Add /etc/profile.d/selinux.sh /etc/profile.d/selinux.csh for strict - move ice_tmp_t definition for mls - More cleanup selinux-policy-targeted-1.23.18-3 --------------------------------- * Thu Jun 09 2005 Dan Walsh 1.23.18-3 - Add /etc/profile.d/selinux.sh /etc/profile.d/selinux.csh for strict - move ice_tmp_t definition for mls strace-4.5.12-1 --------------- * Wed Jun 08 2005 Roland McGrath - 4.5.12-1 - Fix known syscall recognition for IA32 processes on x86-64 (#158934). - Fix bad output for ptrace on x86-64 (#159787). - Fix potential buffer overruns (#151570, #159196). - Make some diagnostics more consistent (#159308). - Update PowerPC system calls. - Better printing for Linux aio system calls. - Don't truncate statfs64 fields to 32 bits in output (#158243). - Cosmetic code cleanups (#159688). system-config-printer-0.6.132-1 ------------------------------- * Thu Jun 09 2005 Tim Waugh 0.6.132-1 - Added hp-devid to file manifest. - 0.6.132: - F1 for help (bug #159152). - HPLIP support (replacing PTAL support). system-config-securitylevel-1.5.9-1 ----------------------------------- * Thu Jun 09 2005 Chris Lumens 1.5.9-1 - Handle ports that are not listed in /etc/services (#157620). - Add an option to allow Samba browsing - enables several ports, so use with care (#133478). - Mark updated menu option and comment for translation (#156800). - Rebuilt .pot file. texinfo-4.8-6 ------------- * Thu Jun 09 2005 Tim Waugh 4.8-6 - Ship texi2pdf man page, taken from tetex-2.0.2 RPM. From fedora at camperquake.de Fri Jun 10 11:48:52 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 10 Jun 2005 13:48:52 +0200 Subject: rawhide report: 20050610 changes In-Reply-To: <200506101142.j5ABgAA1000595@porkchop.devel.redhat.com> References: <200506101142.j5ABgAA1000595@porkchop.devel.redhat.com> Message-ID: <20050610114852.GA29977@ryoko.camperquake.de> On Fri, Jun 10, 2005 at 07:42:10AM -0400, Build System wrote: > - Disable hercules fb. > If you have one of these, please put it back in the trash. Thanks. Awwwww. Come on. Well, OK, Maybe you're right. But using a Hercules as non-fb-console still works? From dwmw2 at infradead.org Fri Jun 10 11:51:16 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 10 Jun 2005 12:51:16 +0100 Subject: "I plan to work on..." for FC5 In-Reply-To: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> Message-ID: <1118404276.2934.7.camel@localhost.localdomain> I plan to work on... Top of the list would probably be NetworkManager. It's quite nice now, but needs to learn about Bluetooth networking and dialup so it can actually handle _all_ the common connectivity requirements for my laptop rather than only some of them. I'll also try to make something mergeable out of the hacks I have at the moment to effectively authenticate via Bluetooth at boot time -- I have gdm set to autologin, and my GNOME session checks via Bluetooth for the presence of my phone and runs 'xscreensaver -lock' if it's not found. I'll probably make this happen on resume from sleep too, which is probably more useful since the laptop spends far more time asleep than it does turned off. -- dwmw2 From mattdm at mattdm.org Fri Jun 10 12:45:29 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 10 Jun 2005 08:45:29 -0400 Subject: Smart package manager (was Re: Making update functionality more usable (Was: Re: What next?)) In-Reply-To: <42A96B79.5010609@cyber.com.au> References: <604aa791050601162840b05c06@mail.gmail.com> <1117730130.1674.3.camel@weasel.laiskiainen.org> <429FDACF.20608@rueb.com> <1117780095.3488.32.camel@cutter> <1117809250.8385.11.camel@mlenzdesktop> <1118024411.3011.11.camel@bree.local.net> <1118048011.2779.2.camel@roque> <1118234067.20494.39.camel@arena.soho.bytebot.net> <42A96B79.5010609@cyber.com.au> Message-ID: <20050610124529.GA6201@jadzia.bu.edu> On Fri, Jun 10, 2005 at 08:29:13PM +1000, Mike MacCana wrote: > 1. I'd like to add smart install to Extras. Okay. > 2. What's pup? Where can I find out more about it? What's it's > relationship to s-c-p? A GUI front end to updating packages via yum. In the archives; also, short FUDCon1 presentation. "Better than, for what it does." -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 81 degrees Fahrenheit. From ndbecker2 at gmail.com Fri Jun 10 13:04:39 2005 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 10 Jun 2005 09:04:39 -0400 Subject: hardlink error installing kernel-devel (still) Message-ID: Installing: kernel-devel ##################### [ 45/125] hardlink: hardlink: no version information available (required by hardlink) hardlink: hardlink: no version information available (required by hardlink) hardlink: hardlink: no version information available (required by hardlink) hardlink: symbol lookup error: hardlink: undefined symbol: stderr, version GLIBC_2.2.5 From symbiont at berlios.de Fri Jun 10 13:50:57 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Fri, 10 Jun 2005 21:50:57 +0800 Subject: "I plan to work on..." for FC5 In-Reply-To: <1118404276.2934.7.camel@localhost.localdomain> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <1118404276.2934.7.camel@localhost.localdomain> Message-ID: <200506102150.57994.symbiont@berlios.de> On Friday 10 June 2005 19:51, David Woodhouse wrote: > I'll also try to make something mergeable out of the hacks I have at > the moment to effectively authenticate via Bluetooth at boot time -- > I have gdm set to autologin, and my GNOME session checks via > Bluetooth for the presence of my phone and runs 'xscreensaver -lock' > if it's not found. While you're at it, get hotplug to run "/etc/init.d/bluetooth start" after it detects an external usb bluetooth. That chicken and egg always nabbed me when starting up kdebluetooth services. -- -jeff From mailinglists at erwinrol.com Fri Jun 10 14:25:53 2005 From: mailinglists at erwinrol.com (Erwin Rol) Date: Fri, 10 Jun 2005 16:25:53 +0200 Subject: gnome-panel eats a lot of memory In-Reply-To: <42851482.6040108@conversis.de> References: <42851482.6040108@conversis.de> Message-ID: <1118413553.11245.13.camel@xpc.home.erwinrol.com> I noticed that the gnome-panel seems to have a memory leak. Every time new a window is opened and closed again the memory usage grows. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13643 erwin 16 0 611m 461m 12m S 0.0 24.5 2:02.01 gnome-panel Open a new window 13643 erwin 17 0 621m 471m 12m S 42.3 25.0 2:04.89 gnome-panel Close it 13643 erwin 15 0 621m 471m 12m S 0.0 25.0 2:04.89 gnome-panel Open a new window 13643 erwin 17 0 629m 479m 12m R 74.2 25.5 2:07.30 gnome-panel Close it 13643 erwin 15 0 631m 481m 12m S 0.0 25.6 2:07.77 gnome-panel etc. When i continue to open/close windows it eats up my 2G RAM and 4G Swap and other application start to complain they can't get memory anymore. This is with Rawhide on x86_64. - Erwin On Fri, 2005-05-13 at 22:56 +0200, Dennis Jacobfeuerborn wrote: > I noticed that gnome-panel eats 25% (=256mb) of my memory which is quite a > lot for a simple panel. Does anybody else see this too? I installed > FC4Test2 and then upgraded to Rawhide. > > Regards, > Dennis > From dwmw2 at infradead.org Fri Jun 10 14:35:23 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 10 Jun 2005 15:35:23 +0100 Subject: "I plan to work on..." for FC5 In-Reply-To: <200506102150.57994.symbiont@berlios.de> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <1118404276.2934.7.camel@localhost.localdomain> <200506102150.57994.symbiont@berlios.de> Message-ID: <1118414123.3454.0.camel@localhost.localdomain> On Fri, 2005-06-10 at 21:50 +0800, Jeff Pitman wrote: > While you're at it, get hotplug to run "/etc/init.d/bluetooth start" > after it detects an external usb bluetooth. That chicken and egg > always nabbed me when starting up kdebluetooth services. Nah. If hcid is running, it'll bring up the new device when it appears. Just make sure it _is_ running by default. Maybe with the new init setup we can have services started and stopped on demand in a more cunning way, but I don't really like starting it from hotplug like the above. -- dwmw2 From markmc at redhat.com Fri Jun 10 14:39:39 2005 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 10 Jun 2005 15:39:39 +0100 Subject: gnome-panel eats a lot of memory In-Reply-To: <1118413553.11245.13.camel@xpc.home.erwinrol.com> References: <42851482.6040108@conversis.de> <1118413553.11245.13.camel@xpc.home.erwinrol.com> Message-ID: <1118414379.8535.32.camel@blaa> On Fri, 2005-06-10 at 16:25 +0200, Erwin Rol wrote: > I noticed that the gnome-panel seems to have a memory leak. Every time > new a window is opened and closed again the memory usage grows. Not seeing this here and I've no idea why this might be happening - the applets which do anything related to open windows are in separate process (wnck-applet) so ... Any unusual applets on your panel (they'd have to be shlib applets) ? What windows are you opening ? How ? (Might be best to just move this to bugzilla) Cheers, Mark. From dwmw2 at infradead.org Fri Jun 10 15:05:32 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 10 Jun 2005 16:05:32 +0100 Subject: "I plan to work on..." for FC5 In-Reply-To: <1118414660.3932.27.camel@daxter.boston.redhat.com> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <1118404276.2934.7.camel@localhost.localdomain> <1118414660.3932.27.camel@daxter.boston.redhat.com> Message-ID: <1118415932.4823.1.camel@localhost.localdomain> On Fri, 2005-06-10 at 10:44 -0400, David Zeuthen wrote: > Sounds good, however, we should just lock the screen when the machine > is suspended so it is locked when we resume. It still needs to check for the presence of my mobile phone at _resume_ time, and unlock if it's found, surely? -- dwmw2 From vonbrand at inf.utfsm.cl Fri Jun 10 15:08:04 2005 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Fri, 10 Jun 2005 11:08:04 -0400 Subject: OT: nVidia driver [was: Wish list] In-Reply-To: Message from Denis Leroy of "Thu, 09 Jun 2005 10:12:21 MST." <42A87875.9070300@poolshark.org> Message-ID: <200506101508.j5AF841r011688@laptop11.inf.utfsm.cl> Denis Leroy wrote: > Arjan van de Ven wrote: > > There probably are patents involved, but those don't in general prevent > > open sourcing something unless you're on the wrong end of the stick. > Yup that's likely, and if they opened the code, we'd still have our > hands tied like with the MP3 code. Maybe. > OTOH, there's a trend lately of companies "pledging" their patents to > the Open Source community (Nokia, CA, IBM...). Would it help if Nvidia > did the same ? What if nVidia just /licensed/ the patents for use with their cards, not for /distributing source/? They may very well not even be their own. And there might also be "trade secrets" in there. OTOH, a friend of mine got to write a driver under NDA for the specs of the device and protocols to talk to it... which he claims aren't all that earth-shaking. But they came in form of photocopies of hastily printed pages with handwritten amendments and additions. His take is that they'd be ashamed to show the specs ;-) -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From kaboom at oobleck.net Fri Jun 10 15:24:15 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Fri, 10 Jun 2005 11:24:15 -0400 (EDT) Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ In-Reply-To: <200506101757.43309.russell@coker.com.au> References: <19543506.1118090925521.JavaMail.root@wamui-milano.atl.sa.earthlink.net> <20050607160935.GA4680@nostromo.devel.redhat.com> <42A5E1F5.6050209@linux360.ro> <200506101757.43309.russell@coker.com.au> Message-ID: On Fri, 10 Jun 2005, Russell Coker wrote: > On Wednesday 08 June 2005 04:05, "Razvan Corneliu C.R. Vilt" > wrote: > > I hate to be the bad guy over here, but what about something similar > > with SMF from Solaris. It's by far the best thing for what we need, and > > Is this the Solaris feature that so many people complain about because it > makes changes to a binary file on every boot? There's an /etc/svc/repository.db that's a transactional db which gets updated continuously as svc state changes, including at system boot as svcs start up. There's also a backup of that db made at every boot, /etc/svc/repository-boot-$timestamp, since if you corrupt /etc/svc/repository.db you're in trouble (you'll crash down to single-user at boot and have to restore / regenerate) I'm not aware of the updating of that file being a cause for major complaint amongst Solaris types though ;-) later, chris From mailinglists at erwinrol.com Fri Jun 10 15:29:28 2005 From: mailinglists at erwinrol.com (Erwin Rol) Date: Fri, 10 Jun 2005 17:29:28 +0200 Subject: gnome-panel eats a lot of memory In-Reply-To: <1118414379.8535.32.camel@blaa> References: <42851482.6040108@conversis.de> <1118413553.11245.13.camel@xpc.home.erwinrol.com> <1118414379.8535.32.camel@blaa> Message-ID: <1118417369.11245.31.camel@xpc.home.erwinrol.com> On Fri, 2005-06-10 at 15:39 +0100, Mark McLoughlin wrote: > On Fri, 2005-06-10 at 16:25 +0200, Erwin Rol wrote: > > I noticed that the gnome-panel seems to have a memory leak. Every time > > new a window is opened and closed again the memory usage grows. > > Not seeing this here and I've no idea why this might be happening - the > applets which do anything related to open windows are in separate > process (wnck-applet) so ... > > Any unusual applets on your panel (they'd have to be shlib applets) ? Hmmm not really; In the top panel the menu's and System Monitor 2.10.1, Notification Area 2.10.1, Clock 2.10.1, Volume Applet 2.10.1 and Window Selector 2.10.1. In the bottom bar, Show Desktop Button 2.10.1, Windows List 2.10.1 and Workspace Switcher 2.10.1. > > What windows are you opening ? How ? Some how it seems to be related to the text in the window title or something in that area. When i open Evince from the menu nothing happens to the memory usage of gnome-panel. When i now open a PDF file with that (empty) evince the memory usage of gnome-panel jumps up. If it open a PDF from nautilus evince opens with the PDF and the memory usage of gnome-panel jumps up. the same thing seems to be the case with archive manager, when opened from the menu nothing happens to gnome-panel memory usages, but when double clicking a tar file in nautilus or open a new tar file, the memory usage of gnome-panel jumps up. On the other hand, opening a gnome-terminal and cd'ing around (that also sets the window title) does nothing to the memory usage of gnome-panel. > > (Might be best to just move this to bugzilla) > Might be a good idea. > Cheers, > Mark. > - Erwin From chrism at plope.com Fri Jun 10 15:31:27 2005 From: chrism at plope.com (Chris McDonough) Date: Fri, 10 Jun 2005 11:31:27 -0400 Subject: Smart package manager (was Re: Making update functionality more usable (Was: Re: What next?)) In-Reply-To: <42A96B79.5010609@cyber.com.au> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <1117730130.1674.3.camel@weasel.laiskiainen.org> <429FDACF.20608@rueb.com> <1117780095.3488.32.camel@cutter> <1117809250.8385.11.camel@mlenzdesktop> <1118024411.3011.11.camel@bree.local.net> <1118048011.2779.2.camel@roque> <1118234067.20494.39.camel@arena.soho.bytebot.net> <42A96B79.5010609@cyber.com.au> Message-ID: <1118417487.7471.17.camel@plope.dyndns.org> Hmm. On Fri, 2005-06-10 at 20:29 +1000, Mike MacCana wrote: > 1. I'd like to add smart install to Extras. > > - It's written by the author of Synaptic and principal maintainer of > apt-get for RPM > - Its a replacement for yum / apt-get / up2date / synaptic / etc. > - It has both a CLI and GUI interface. > - The GUI version is GTK2, and looks exactly like Synaptic (oddly enough > being written by the same author). > - It works with Yum metadata repositories. > - Its faster than yum and apt-get as it downloads from multiple sources > simultaneously. It's written in Python, too! Very nice. Thanks for the tip... > I've been using it on Rawhide for months and it's fast, simple, and > reliable. > > 2. What's pup? Where can I find out more about it? What's it's > relationship to s-c-p? Pup is a project that has as a goal replacing the functionality of rhn-applet-gui + up2date. It is not now within its' scope to do ad-hoc package management like Synaptic. I know because I asked yesterday on the fedora config list. - C From symbiont at berlios.de Fri Jun 10 15:39:48 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Fri, 10 Jun 2005 23:39:48 +0800 Subject: "I plan to work on..." for FC5 In-Reply-To: <1118414123.3454.0.camel@localhost.localdomain> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <200506102150.57994.symbiont@berlios.de> <1118414123.3454.0.camel@localhost.localdomain> Message-ID: <200506102339.48959.symbiont@berlios.de> On Friday 10 June 2005 22:35, David Woodhouse wrote: > On Fri, 2005-06-10 at 21:50 +0800, Jeff Pitman wrote: > > While you're at it, get hotplug to run "/etc/init.d/bluetooth > > start" after it detects an external usb bluetooth. That chicken > > and egg always nabbed me when starting up kdebluetooth services. > > Nah. If hcid is running, it'll bring up the new device when it > appears. Just make sure it _is_ running by default. Currently, /etc/init.d/bluetooth start don't work unless I have the usb plugged in. But, when you plug it in, sdp, et al don't start. There's gotta be a way around this. -- -jeff From dwmw2 at infradead.org Fri Jun 10 15:40:26 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 10 Jun 2005 16:40:26 +0100 Subject: "I plan to work on..." for FC5 In-Reply-To: <200506102339.48959.symbiont@berlios.de> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <200506102150.57994.symbiont@berlios.de> <1118414123.3454.0.camel@localhost.localdomain> <200506102339.48959.symbiont@berlios.de> Message-ID: <1118418026.4823.21.camel@localhost.localdomain> On Fri, 2005-06-10 at 23:39 +0800, Jeff Pitman wrote: > Currently, /etc/init.d/bluetooth start don't work unless I have the > usb plugged in. But, when you plug it in, sdp, et al don't start. > There's gotta be a way around this. That's strange. hcid and sdpd ought to be running before you connect the usb device. Are they? What do they do when you plug the device in? What happens if you kill hcid, then run it from a terminal with '-n'? What does it do when you plug the device in? -- dwmw2 From jspaleta at gmail.com Fri Jun 10 15:52:14 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 10 Jun 2005 11:52:14 -0400 Subject: gnome-panel eats a lot of memory In-Reply-To: <1118417369.11245.31.camel@xpc.home.erwinrol.com> References: <42851482.6040108@conversis.de> <1118413553.11245.13.camel@xpc.home.erwinrol.com> <1118414379.8535.32.camel@blaa> <1118417369.11245.31.camel@xpc.home.erwinrol.com> Message-ID: <604aa79105061008527426df3c@mail.gmail.com> On 6/10/05, Erwin Rol wrote: > On the other hand, opening a gnome-terminal and cd'ing around (that also > sets the window title) does nothing to the memory usage of gnome-panel. do both window list and window selector pick up the title change for gnome-terminal correctly? -jef From symbiont at berlios.de Fri Jun 10 15:59:35 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Fri, 10 Jun 2005 23:59:35 +0800 Subject: "I plan to work on..." for FC5 In-Reply-To: <1118418026.4823.21.camel@localhost.localdomain> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <200506102339.48959.symbiont@berlios.de> <1118418026.4823.21.camel@localhost.localdomain> Message-ID: <200506102359.36554.symbiont@berlios.de> On Friday 10 June 2005 23:40, David Woodhouse wrote: > On Fri, 2005-06-10 at 23:39 +0800, Jeff Pitman wrote: > > Currently, /etc/init.d/bluetooth start don't work unless I have the > > usb plugged in. ?But, when you plug it in, sdp, et al don't start. > > There's gotta be a way around this. > > That's strange. hcid and sdpd ought to be running before you connect > the usb device. Are they? What do they do when you plug the device > in? Fedora Core 3 (haven't check FC4 test): [root at kubik ~]# service bluetooth start Can't open RFCOMM control socket: Address family not supported by protocol [root at kubik ~]# ps -ef |grep hcid root 1861 1728 0 23:51 pts/4 00:00:00 grep hcid [root at kubik ~]# When I plug in I get "Failed to connect to the SDP server." in kdebluetooth. > What happens if you kill hcid, then run it from a terminal with '-n'? [root at kubik ~]# hcid -n hcid[2190]: Bluetooth HCI daemon > What does it do when you plug the device in? [root at kubik ~]# hcid -n hcid[2190]: Bluetooth HCI daemon hcid[2190]: HCI dev 0 registered hcid[2190]: HCI dev 0 up hcid[2190]: Starting security manager 0 hcid[2190]: link_key_request (sba=00:0E:A1:04:86:FF, dba=00:0E:6D:2B:42:05) Works great. So, I think it's a /etc/init.d/bluetooth problem. If I take it out, and the execute /etc/init.d/bluetooth start, it's okay. Only on cold bootup and prior to plugging it in, it goofs on the daemon. Go figger. Ideas? -- -jeff From dwmw2 at infradead.org Fri Jun 10 16:05:11 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 10 Jun 2005 17:05:11 +0100 Subject: "I plan to work on..." for FC5 In-Reply-To: <200506102359.36554.symbiont@berlios.de> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <200506102339.48959.symbiont@berlios.de> <1118418026.4823.21.camel@localhost.localdomain> <200506102359.36554.symbiont@berlios.de> Message-ID: <1118419511.4823.24.camel@localhost.localdomain> On Fri, 2005-06-10 at 23:59 +0800, Jeff Pitman wrote: > If I take it out, and the execute /etc/init.d/bluetooth start, it's > okay. Only on cold bootup and prior to plugging it in, it goofs on > the daemon. Go figger. Ideas? It's failing to automatically load the bluetooth kernel modules. If you unload them all and run hcid, I suspect you'll see the same thing and should be able to debug it a little further. -- dwmw2 From mailinglists at erwinrol.com Fri Jun 10 16:09:55 2005 From: mailinglists at erwinrol.com (Erwin Rol) Date: Fri, 10 Jun 2005 18:09:55 +0200 Subject: gnome-panel eats a lot of memory In-Reply-To: <604aa79105061008527426df3c@mail.gmail.com> References: <42851482.6040108@conversis.de> <1118413553.11245.13.camel@xpc.home.erwinrol.com> <1118414379.8535.32.camel@blaa> <1118417369.11245.31.camel@xpc.home.erwinrol.com> <604aa79105061008527426df3c@mail.gmail.com> Message-ID: <1118419795.11245.36.camel@xpc.home.erwinrol.com> On Fri, 2005-06-10 at 11:52 -0400, Jeff Spaleta wrote: > On 6/10/05, Erwin Rol wrote: > > On the other hand, opening a gnome-terminal and cd'ing around (that also > > sets the window title) does nothing to the memory usage of gnome-panel. > > do both window list and window selector pick up the title change for > gnome-terminal correctly? Yes, both list and selector display the same text as the window title, and they keep up with every "cd ./somewhere/". - Erwin > > -jef > From dwmw2 at infradead.org Fri Jun 10 16:29:10 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 10 Jun 2005 17:29:10 +0100 Subject: "I plan to work on..." for FC5 In-Reply-To: <1118420788.12844.0.camel@daxter.boston.redhat.com> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <1118404276.2934.7.camel@localhost.localdomain> <1118414660.3932.27.camel@daxter.boston.redhat.com> <1118415932.4823.1.camel@localhost.localdomain> <1118420788.12844.0.camel@daxter.boston.redhat.com> Message-ID: <1118420951.4823.27.camel@localhost.localdomain> On Fri, 2005-06-10 at 12:26 -0400, David Zeuthen wrote: > Well, it needs to do that every time you want to unlock the screen > saver so I don't really see a need to special case it? The idea is that if I boot or resume the machine while my phone is nearby, the screen shouldn't become locked in the first place. I don't want it to lock whenever I walk away from it; I want it to lock only at {boot,resume} time if my phone isn't present _then_. -- dwmw2 From dimi at lattica.com Fri Jun 10 16:36:24 2005 From: dimi at lattica.com (Dimi Paun) Date: Fri, 10 Jun 2005 12:36:24 -0400 Subject: Fw: "I plan to work on..." for FC5 Message-ID: <030a01c56dda$8a87a250$b6491b31@td612671> From: "David Woodhouse" > I don't want it to lock whenever I walk away from it; I want it to lock > only at {boot,resume} time if my phone isn't present _then_. That's cool, but another very interesting usecase would be to lock/unlock automagically when you walk away/to the box. Talking for myself, I'd certainly use such a feature where I currently work, simply because there have been problems in the past with unlocked computers. And I admit, I forget sometimes to lock mine when I go for a coffee. Such a feature would be more then a simple convenience for me. -- Dimi Paun Lattica, Inc. From davej at redhat.com Fri Jun 10 17:04:25 2005 From: davej at redhat.com (Dave Jones) Date: Fri, 10 Jun 2005 13:04:25 -0400 Subject: SEP bit disabled in FC In-Reply-To: <1118388776.5272.14.camel@laptopd505.fenrus.org> References: <58743620D2C0D9439C627C064581E25218D76F@PA-ECLUSTER2.vmware.com> <20050610012532.GB24256@redhat.com> <1118388776.5272.14.camel@laptopd505.fenrus.org> Message-ID: <20050610170425.GD20255@redhat.com> On Fri, Jun 10, 2005 at 09:32:55AM +0200, Arjan van de Ven wrote: > On Thu, 2005-06-09 at 21:25 -0400, Dave Jones wrote: > > On Thu, Jun 09, 2005 at 06:22:05PM -0700, Jeffrey Buell wrote: > > > In arch/i386/kernel/cpu/common.c: > > > > > > /* hack: disable SEP for non-NX cpus; SEP breaks Execshield. */ > > > #ifdef CONFIG_HIGHMEM64G > > > if (!test_bit(X86_FEATURE_NX, c->x86_capability)) > > > #endif > > > clear_bit(X86_FEATURE_SEP, c->x86_capability); > > > > > > So, in order to enable Execshield, the SEP cpu bit (sysenter/sysexit) has to > > > be turned off. But this costs a lot of performance: as much as 2.5X in > > > syscall-heavy benchmarks (e.g., process tests in lmbench). > > > > > > How permanent is this hack? Will Execshield be fixed (or removed) by FC5? > > > > It was going to be reeanbled for FC4, but due to a last minute glitch, > > (which we think we fixed), we disabled for it for the release with > > the intention of reenabling it in the first kernel update that goes > > out for FC4. > > You're confusing VDSO page with SEP. Indeed. Dave From davej at redhat.com Fri Jun 10 17:13:55 2005 From: davej at redhat.com (Dave Jones) Date: Fri, 10 Jun 2005 13:13:55 -0400 Subject: "I plan to work on..." for FC5 In-Reply-To: <1118404276.2934.7.camel@localhost.localdomain> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <1118404276.2934.7.camel@localhost.localdomain> Message-ID: <20050610171354.GE20255@redhat.com> On Fri, Jun 10, 2005 at 12:51:16PM +0100, David Woodhouse wrote: > I'll also try to make something mergeable out of the hacks I have at the > moment to effectively authenticate via Bluetooth at boot time -- I have > gdm set to autologin, and my GNOME session checks via Bluetooth for the > presence of my phone and runs 'xscreensaver -lock' if it's not found. So all I have to do is steal your laptop and phone, and I've got access to all your data ? The auto-login bit scares me a little. Having it lock the screen if you wander off I like the sound of though. Whilst I remember, who was working on encrypted homedirs ? davidz ? Any progress on that ? Dave From davej at redhat.com Fri Jun 10 17:34:34 2005 From: davej at redhat.com (Dave Jones) Date: Fri, 10 Jun 2005 13:34:34 -0400 Subject: rawhide report: 20050610 changes In-Reply-To: <20050610114852.GA29977@ryoko.camperquake.de> References: <200506101142.j5ABgAA1000595@porkchop.devel.redhat.com> <20050610114852.GA29977@ryoko.camperquake.de> Message-ID: <20050610173434.GF20255@redhat.com> On Fri, Jun 10, 2005 at 01:48:52PM +0200, Ralf Ertzinger wrote: > On Fri, Jun 10, 2005 at 07:42:10AM -0400, Build System wrote: > > > - Disable hercules fb. > > If you have one of these, please put it back in the trash. Thanks. > > Awwwww. Come on. > > > Well, OK, Maybe you're right. But using a Hercules as non-fb-console > still works? No idea. I've not seen such hardware since 1997. (And even that one was broken iirc ;-) Dave From dwmw2 at infradead.org Fri Jun 10 17:36:40 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 10 Jun 2005 18:36:40 +0100 Subject: "I plan to work on..." for FC5 In-Reply-To: <20050610171354.GE20255@redhat.com> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <1118404276.2934.7.camel@localhost.localdomain> <20050610171354.GE20255@redhat.com> Message-ID: <1118425001.4823.36.camel@localhost.localdomain> On Fri, 2005-06-10 at 13:13 -0400, Dave Jones wrote: > So all I have to do is steal your laptop and phone, and I've got > access to all your data ? The auto-login bit scares me a little. > Having it lock the screen if you wander off I like the sound of > though. Who runs a password-protected bootloader? You steal my laptop and you've got access to all my data anyway. Besides, about the only time my laptop and phone are ever in the bag together are when they're on an airplane, and if you manage to steal them then you're _still_ fairly unlikely to try booting the laptop while the phone is turned on, so you don't gain much. -- dwmw2 From dfarning at sbcglobal.net Fri Jun 10 18:19:58 2005 From: dfarning at sbcglobal.net (david) Date: Fri, 10 Jun 2005 13:19:58 -0500 Subject: Mirror Monitor for Meta Data. Message-ID: <42A9D9CE.3070900@sbcglobal.net> I've got a short term url for a m3d test site. http://vyum.sourceforge.net/m3d/ http://vyum.sourceforge.net/m3d/development/development.html Next on the todo list are replacing 'no time' with the actually http error. Disable a particular arch(s) for a mirror. The actual data won't be updated until Sunday. I'm leaving town and don't want to cause an accidental DOS attack by letting the the probes run unattended. thanks -dtf From jlayton at redhat.com Fri Jun 10 18:48:31 2005 From: jlayton at redhat.com (Jeff Layton) Date: Fri, 10 Jun 2005 14:48:31 -0400 Subject: [PATCH] mkinitrd rescue mode - now crypto In-Reply-To: <1118351619.27196.2.camel@localhost.localdomain> References: <1117653405.12259.51.camel@barsoom.rdu.redhat.com> <1117725836.3768.15.camel@bree.local.net> <1117731994.12259.68.camel@barsoom.rdu.redhat.com> <1118081184.9625.5.camel@localhost.localdomain> <1118250922.5299.60.camel@localhost.localdomain> <1118348963.19973.27.camel@barsoom.rdu.redhat.com> <1118351619.27196.2.camel@localhost.localdomain> Message-ID: <1118429311.19973.66.camel@barsoom.rdu.redhat.com> On Thu, 2005-06-09 at 17:13 -0400, Peter Jones wrote: > > Well, there is the scary echo/cd hack patch that was attached to one of > those bugs... Ok, I did a little more testing today. Enabled -DDEBUG in the build process and added this just after the recursiveRemove(): lsdir("/",""); After that, I booted to an initramfs with my test nash, and it showed this: Switching to new root //proc/ //sys/ //sysroot/ unmounting old /proc unmounting old /sys So it looks like only /proc,/sys, and /sysroot were still in the root directory. I suppose this means we can call the recursiveRemove() a success! As a side note, however, I've been unable so far to get an initramfs that is a "merge" of more than one cpio image. I've tried passing more than 1 initrd directive via GRUB, and have tried using an initrd command line that has more than one arg. Neither way seems to work -- perhaps this is an issue with GRUB in FC4? -- Jeff Layton From wtogami at redhat.com Fri Jun 10 19:51:15 2005 From: wtogami at redhat.com (Warren Togami) Date: Fri, 10 Jun 2005 09:51:15 -1000 Subject: Smart package manager (was Re: Making update functionality more usable (Was: Re: What next?)) In-Reply-To: <1118417487.7471.17.camel@plope.dyndns.org> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <1117730130.1674.3.camel@weasel.laiskiainen.org> <429FDACF.20608@rueb.com> <1117780095.3488.32.camel@cutter> <1117809250.8385.11.camel@mlenzdesktop> <1118024411.3011.11.camel@bree.local.net> <1118048011.2779.2.camel@roque> <1118234067.20494.39.camel@arena.soho.bytebot.net> <42A96B79.5010609@cyber.com.au> <1118417487.7471.17.camel@plope.dyndns.org> Message-ID: <42A9EF33.3010601@redhat.com> Chris McDonough wrote: > Hmm. > > On Fri, 2005-06-10 at 20:29 +1000, Mike MacCana wrote: > >>1. I'd like to add smart install to Extras. >> >>- It's written by the author of Synaptic and principal maintainer of >>apt-get for RPM >>- Its a replacement for yum / apt-get / up2date / synaptic / etc. >>- It has both a CLI and GUI interface. >>- The GUI version is GTK2, and looks exactly like Synaptic (oddly enough >>being written by the same author). >>- It works with Yum metadata repositories. >>- Its faster than yum and apt-get as it downloads from multiple sources >>simultaneously. > > > It's written in Python, too! Very nice. Thanks for the tip... Does smartpm support multilib yet? Warren Togami wtogami at redhat.com From chrism at plope.com Fri Jun 10 21:42:27 2005 From: chrism at plope.com (Chris McDonough) Date: Fri, 10 Jun 2005 17:42:27 -0400 Subject: Smart package manager (was Re: Making update functionality more usable (Was: Re: What next?)) In-Reply-To: <42A9EF33.3010601@redhat.com> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <1117730130.1674.3.camel@weasel.laiskiainen.org> <429FDACF.20608@rueb.com> <1117780095.3488.32.camel@cutter> <1117809250.8385.11.camel@mlenzdesktop> <1118024411.3011.11.camel@bree.local.net> <1118048011.2779.2.camel@roque> <1118234067.20494.39.camel@arena.soho.bytebot.net> <42A96B79.5010609@cyber.com.au> <1118417487.7471.17.camel@plope.dyndns.org> <42A9EF33.3010601@redhat.com> Message-ID: <1118439747.4345.1.camel@plope.dyndns.org> Hard to say, as I don't have a machine on which to test that multilib actually works, but the docs indicate that some thought has been put into it: - There's a special RPMNameProvides class that must be used to provide the package name itself together with the package version and the architecture appended. We must use a special class here to be able to match RPMObsoletes against package names only, since that's the way RPM expects it to happen. Appending the architecture is necessary for multilib handling of upgrades. Notice that RPM packages already provide the name/version explicitly, so instead of just adding a new provides, it's usually necessary to catch the existent provides and change the class/append the arch when matching the package name/version. On Fri, 2005-06-10 at 09:51 -1000, Warren Togami wrote: > Chris McDonough wrote: > > Hmm. > > > > On Fri, 2005-06-10 at 20:29 +1000, Mike MacCana wrote: > > > >>1. I'd like to add smart install to Extras. > >> > >>- It's written by the author of Synaptic and principal maintainer of > >>apt-get for RPM > >>- Its a replacement for yum / apt-get / up2date / synaptic / etc. > >>- It has both a CLI and GUI interface. > >>- The GUI version is GTK2, and looks exactly like Synaptic (oddly enough > >>being written by the same author). > >>- It works with Yum metadata repositories. > >>- Its faster than yum and apt-get as it downloads from multiple sources > >>simultaneously. > > > > > > It's written in Python, too! Very nice. Thanks for the tip... > > Does smartpm support multilib yet? > > Warren Togami > wtogami at redhat.com > From notting at redhat.com Fri Jun 10 21:59:41 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 10 Jun 2005 17:59:41 -0400 Subject: Smart package manager (was Re: Making update functionality more usable (Was: Re: What next?)) In-Reply-To: <42A9EF33.3010601@redhat.com> References: <1117730130.1674.3.camel@weasel.laiskiainen.org> <429FDACF.20608@rueb.com> <1117780095.3488.32.camel@cutter> <1117809250.8385.11.camel@mlenzdesktop> <1118024411.3011.11.camel@bree.local.net> <1118048011.2779.2.camel@roque> <1118234067.20494.39.camel@arena.soho.bytebot.net> <42A96B79.5010609@cyber.com.au> <1118417487.7471.17.camel@plope.dyndns.org> <42A9EF33.3010601@redhat.com> Message-ID: <20050610215941.GB10673@nostromo.devel.redhat.com> Warren Togami (wtogami at redhat.com) said: > >It's written in Python, too! Very nice. Thanks for the tip... > > Does smartpm support multilib yet? IIRC, apt doesn't, and it's in Extras. So, not sure that that's a blocking issue. Bill From wtogami at redhat.com Fri Jun 10 22:04:05 2005 From: wtogami at redhat.com (Warren Togami) Date: Fri, 10 Jun 2005 12:04:05 -1000 Subject: Smart package manager (was Re: Making update functionality more usable (Was: Re: What next?)) In-Reply-To: <20050610215941.GB10673@nostromo.devel.redhat.com> References: <1117730130.1674.3.camel@weasel.laiskiainen.org> <429FDACF.20608@rueb.com> <1117780095.3488.32.camel@cutter> <1117809250.8385.11.camel@mlenzdesktop> <1118024411.3011.11.camel@bree.local.net> <1118048011.2779.2.camel@roque> <1118234067.20494.39.camel@arena.soho.bytebot.net> <42A96B79.5010609@cyber.com.au> <1118417487.7471.17.camel@plope.dyndns.org> <42A9EF33.3010601@redhat.com> <20050610215941.GB10673@nostromo.devel.redhat.com> Message-ID: <42AA0E55.3020806@redhat.com> Bill Nottingham wrote: > Warren Togami (wtogami at redhat.com) said: > >>>It's written in Python, too! Very nice. Thanks for the tip... >> >>Does smartpm support multilib yet? > > > IIRC, apt doesn't, and it's in Extras. So, not sure that that's > a blocking issue. > > Bill > Huh? apt and smartpm have nothing in common. Warren Togami wtogami at redhat.com From jspaleta at gmail.com Fri Jun 10 22:06:19 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 10 Jun 2005 18:06:19 -0400 Subject: Smart package manager (was Re: Making update functionality more usable (Was: Re: What next?)) In-Reply-To: <42AA0E55.3020806@redhat.com> References: <1117730130.1674.3.camel@weasel.laiskiainen.org> <1117809250.8385.11.camel@mlenzdesktop> <1118024411.3011.11.camel@bree.local.net> <1118048011.2779.2.camel@roque> <1118234067.20494.39.camel@arena.soho.bytebot.net> <42A96B79.5010609@cyber.com.au> <1118417487.7471.17.camel@plope.dyndns.org> <42A9EF33.3010601@redhat.com> <20050610215941.GB10673@nostromo.devel.redhat.com> <42AA0E55.3020806@redhat.com> Message-ID: <604aa79105061015063a89fb5e@mail.gmail.com> On 6/10/05, Warren Togami wrote: > Huh? apt and smartpm have nothing in common. i think the point of notting's point was the fact that multilib support isn't a requirement for inclusion into Extras for any new alternative tool -jef"i could make a joke about packaging grab but I'll go home and drink instead"spaleta From chrism at plope.com Fri Jun 10 22:42:33 2005 From: chrism at plope.com (Chris McDonough) Date: Fri, 10 Jun 2005 18:42:33 -0400 Subject: Smart package manager (was Re: Making update functionality more usable (Was: Re: What next?)) In-Reply-To: <604aa79105061015063a89fb5e@mail.gmail.com> References: <1117730130.1674.3.camel@weasel.laiskiainen.org> <1117809250.8385.11.camel@mlenzdesktop> <1118024411.3011.11.camel@bree.local.net> <1118048011.2779.2.camel@roque> <1118234067.20494.39.camel@arena.soho.bytebot.net> <42A96B79.5010609@cyber.com.au> <1118417487.7471.17.camel@plope.dyndns.org> <42A9EF33.3010601@redhat.com> <20050610215941.GB10673@nostromo.devel.redhat.com> <42AA0E55.3020806@redhat.com> <604aa79105061015063a89fb5e@mail.gmail.com> Message-ID: <1118443354.4345.3.camel@plope.dyndns.org> FWIW, it does appear to handle multilib OK, as I see both i686 and i386 versions of the same packages independently. On Fri, 2005-06-10 at 18:06 -0400, Jeff Spaleta wrote: > On 6/10/05, Warren Togami wrote: > > Huh? apt and smartpm have nothing in common. > > i think the point of notting's point was the fact that multilib > support isn't a requirement for inclusion into Extras for any new > alternative tool > > -jef"i could make a joke about packaging grab but I'll go home and > drink instead"spaleta > From alan at redhat.com Fri Jun 10 23:32:26 2005 From: alan at redhat.com (Alan Cox) Date: Fri, 10 Jun 2005 19:32:26 -0400 Subject: "I plan to work on..." for FC5 In-Reply-To: <200506102359.36554.symbiont@berlios.de> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <200506102339.48959.symbiont@berlios.de> <1118418026.4823.21.camel@localhost.localdomain> <200506102359.36554.symbiont@berlios.de> Message-ID: <20050610233226.GH18279@devserv.devel.redhat.com> On Fri, Jun 10, 2005 at 11:59:35PM +0800, Jeff Pitman wrote: > [root at kubik ~]# service bluetooth start > Can't open RFCOMM control socket: Address family not supported by > protocol That usually means the bluetooth kernel modules are not loaded. What does lsmod show ? From alan at redhat.com Fri Jun 10 23:34:32 2005 From: alan at redhat.com (Alan Cox) Date: Fri, 10 Jun 2005 19:34:32 -0400 Subject: Fw: "I plan to work on..." for FC5 In-Reply-To: <030a01c56dda$8a87a250$b6491b31@td612671> References: <030a01c56dda$8a87a250$b6491b31@td612671> Message-ID: <20050610233432.GI18279@devserv.devel.redhat.com> On Fri, Jun 10, 2005 at 12:36:24PM -0400, Dimi Paun wrote: > the past with unlocked computers. And I admit, I forget > sometimes to lock mine when I go for a coffee. Such a feature > would be more then a simple convenience for me. The newer phones also support running a java crapplet when a bluetooth connection is made to the phone, so you can actually prompt for the password on the phone not just use it for presence testing. From alan at redhat.com Fri Jun 10 23:35:40 2005 From: alan at redhat.com (Alan Cox) Date: Fri, 10 Jun 2005 19:35:40 -0400 Subject: rawhide report: 20050610 changes In-Reply-To: <20050610173434.GF20255@redhat.com> References: <200506101142.j5ABgAA1000595@porkchop.devel.redhat.com> <20050610114852.GA29977@ryoko.camperquake.de> <20050610173434.GF20255@redhat.com> Message-ID: <20050610233540.GJ18279@devserv.devel.redhat.com> On Fri, Jun 10, 2005 at 01:34:34PM -0400, Dave Jones wrote: > > Well, OK, Maybe you're right. But using a Hercules as non-fb-console > > still works? > > No idea. I've not seen such hardware since 1997. > (And even that one was broken iirc ;-) A lot of modern cards can still do hercules modes 8) Alan From alan at redhat.com Fri Jun 10 23:36:43 2005 From: alan at redhat.com (Alan Cox) Date: Fri, 10 Jun 2005 19:36:43 -0400 Subject: "I plan to work on..." for FC5 In-Reply-To: <1118425001.4823.36.camel@localhost.localdomain> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <1118404276.2934.7.camel@localhost.localdomain> <20050610171354.GE20255@redhat.com> <1118425001.4823.36.camel@localhost.localdomain> Message-ID: <20050610233643.GK18279@devserv.devel.redhat.com> On Fri, Jun 10, 2005 at 06:36:40PM +0100, David Woodhouse wrote: > Who runs a password-protected bootloader? You steal my laptop and you've > got access to all my data anyway. Paranoid companies run password protected bios which unlocks the password protected disk which loads the protected bootloader. Its easy to do with an IBM thinkpad From jwboyer at jdub.homelinux.org Fri Jun 10 23:46:08 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 10 Jun 2005 18:46:08 -0500 Subject: "I plan to work on..." for FC5 In-Reply-To: <20050610233643.GK18279@devserv.devel.redhat.com> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <1118404276.2934.7.camel@localhost.localdomain> <20050610171354.GE20255@redhat.com> <1118425001.4823.36.camel@localhost.localdomain> <20050610233643.GK18279@devserv.devel.redhat.com> Message-ID: <1118447168.3329.2.camel@yoda.jdub.homelinux.org> On Fri, 2005-06-10 at 19:36 -0400, Alan Cox wrote: > On Fri, Jun 10, 2005 at 06:36:40PM +0100, David Woodhouse wrote: > > Who runs a password-protected bootloader? You steal my laptop and you've > > got access to all my data anyway. > > Paranoid companies run password protected bios which unlocks the password > protected disk which loads the protected bootloader. Its easy to do with an > IBM thinkpad Yes, it is. And it's really, really annoying sometimes :). josh From jspaleta at gmail.com Fri Jun 10 23:48:53 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 10 Jun 2005 19:48:53 -0400 Subject: Smart package manager (was Re: Making update functionality more usable (Was: Re: What next?)) In-Reply-To: <1118443354.4345.3.camel@plope.dyndns.org> References: <1117730130.1674.3.camel@weasel.laiskiainen.org> <1118048011.2779.2.camel@roque> <1118234067.20494.39.camel@arena.soho.bytebot.net> <42A96B79.5010609@cyber.com.au> <1118417487.7471.17.camel@plope.dyndns.org> <42A9EF33.3010601@redhat.com> <20050610215941.GB10673@nostromo.devel.redhat.com> <42AA0E55.3020806@redhat.com> <604aa79105061015063a89fb5e@mail.gmail.com> <1118443354.4345.3.camel@plope.dyndns.org> Message-ID: <604aa79105061016487576e224@mail.gmail.com> On 6/10/05, Chris McDonough wrote: > FWIW, it does appear to handle multilib OK, as I see both i686 and i386 > versions of the same packages independently. I think you are a little confused. You need to check to see if it can handle parallel installation of both 64bit and 32bit packages while on 64bit hardware. -jef From symbiont at berlios.de Sat Jun 11 01:05:00 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Sat, 11 Jun 2005 09:05:00 +0800 Subject: "I plan to work on..." for FC5 In-Reply-To: <20050610233226.GH18279@devserv.devel.redhat.com> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <200506102359.36554.symbiont@berlios.de> <20050610233226.GH18279@devserv.devel.redhat.com> Message-ID: <200506110905.00788.symbiont@berlios.de> On Saturday 11 June 2005 07:32, Alan Cox wrote: > On Fri, Jun 10, 2005 at 11:59:35PM +0800, Jeff Pitman wrote: > > [root at kubik ~]# service bluetooth start > > Can't open RFCOMM control socket: Address family not supported by > > protocol > > That usually means the bluetooth kernel modules are not loaded. What > does lsmod show ? When I nuke the modules out, I get the above response. I have this in /etc/modprobe.conf: alias net-pf-31 bluez alias bt-proto-0 l2cap alias bt-proto-2 sco alias bt-proto-3 rfcomm I tried adding this: alias char-major-216-* rfcomm But, I still cannot get rfcomm to autoload. If I execute "modprobe" at the commandline, it works. (ie. modprobe rfcomm). I guess I could put this hackery in rc.sysinit: echo -n $"Initializing hardware... " ide="" scsi="" network="" audio="" other="nvram rfcomm" Do I have any other options? thanks, -- -jeff From chrism at plope.com Sat Jun 11 01:15:50 2005 From: chrism at plope.com (Chris McDonough) Date: Fri, 10 Jun 2005 21:15:50 -0400 Subject: Smart package manager (was Re: Making update functionality more usable (Was: Re: What next?)) In-Reply-To: <604aa79105061016487576e224@mail.gmail.com> References: <1117730130.1674.3.camel@weasel.laiskiainen.org> <1118048011.2779.2.camel@roque> <1118234067.20494.39.camel@arena.soho.bytebot.net> <42A96B79.5010609@cyber.com.au> <1118417487.7471.17.camel@plope.dyndns.org> <42A9EF33.3010601@redhat.com> <20050610215941.GB10673@nostromo.devel.redhat.com> <42AA0E55.3020806@redhat.com> <604aa79105061015063a89fb5e@mail.gmail.com> <1118443354.4345.3.camel@plope.dyndns.org> <604aa79105061016487576e224@mail.gmail.com> Message-ID: <1118452551.4345.12.camel@plope.dyndns.org> On Fri, 2005-06-10 at 19:48 -0400, Jeff Spaleta wrote: > On 6/10/05, Chris McDonough wrote: > > FWIW, it does appear to handle multilib OK, as I see both i686 and i386 > > versions of the same packages independently. > > I think you are a little confused. You need to check to see if it can > handle parallel installation of both 64bit and 32bit packages while on > 64bit hardware. Yep, probably I am. I don't have a machine on which I can test that simultaneous installation of 32-bit and 64-bit binaries actually works. But if "multilib" means "the capability to distinguish between multiple architecture packages for the same component and have the ability to install each simultaneously or independently", smart seems to be able to do that just fine. It takes the architecture into account when presenting the package listing. - C From byte at aeon.com.my Sat Jun 11 00:40:58 2005 From: byte at aeon.com.my (Colin Charles) Date: Fri, 10 Jun 2005 17:40:58 -0700 Subject: Smart package manager (was Re: Making update functionality more usable (Was: Re: What next?)) In-Reply-To: <42A96B79.5010609@cyber.com.au> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <1117730130.1674.3.camel@weasel.laiskiainen.org> <429FDACF.20608@rueb.com> <1117780095.3488.32.camel@cutter> <1117809250.8385.11.camel@mlenzdesktop> <1118024411.3011.11.camel@bree.local.net> <1118048011.2779.2.camel@roque> <1118234067.20494.39.camel@arena.soho.bytebot.net> <42A96B79.5010609@cyber.com.au> Message-ID: <1118450459.3544.241.camel@arena.soho.bytebot.net> On Fri, 2005-06-10 at 20:29 +1000, Mike MacCana wrote: > 1. I'd like to add smart install to Extras. Please go thru the Fedora Extras new maintainer process, and package away! > - Its a replacement for yum / apt-get / up2date / synaptic / etc. It must /work alongside/ and can't *replace* Core tools. We've done away with the idea of Fedora Alternatives, in where a core replacement could sit (in theory) > 2. What's pup? Where can I find out more about it? What's it's > relationship to s-c-p? Mailing list archives, fedora-config-list will be helpful. -- Colin Charles, http://www.bytebot.net/ FUDCon II @ LinuxTag June 24-25, 2005 in Karlsruhe, Germany http://fedoraproject.com/fudcon/ From byte at aeon.com.my Sat Jun 11 00:35:39 2005 From: byte at aeon.com.my (Colin Charles) Date: Fri, 10 Jun 2005 17:35:39 -0700 Subject: What next? In-Reply-To: <873brsajzc.fsf@kosh.bigo.ensc.de> References: <200506021630.48520@carola.nyarlathotep> <42A094F9.3020207@redhat.com> <42A0A4B7.301@poolshark.org> <20050603185421.GF1343147@hiwaay.net> <1117825018.7091.0.camel@cutter> <20050603190221.GH1343147@hiwaay.net> <87wtpay0q2.fsf@kosh.bigo.ensc.de> <20050604150128.GA17357@thacker.dyndns.org> <87mzq6xcjd.fsf@kosh.bigo.ensc.de> <20050604191834.GA19626@thacker.dyndns.org> <20050604210402.GE3329@mclink.it> <1118236055.20494.42.camel@arena.soho.bytebot.net> <873brsajzc.fsf@kosh.bigo.ensc.de> Message-ID: <1118450139.3544.238.camel@arena.soho.bytebot.net> On Wed, 2005-06-08 at 18:31 +0200, Enrico Scholz wrote: > >> I go OO.o after two hours of Emacs, hit C-x C-W to save, canceling > >> whatever was highlighted and being asked if I want to close the > file > >> without saving. > > > > You can change OOo's keybindings to that of Emacs, if you so > incline. > > Really? Does OOo support multi-keystroke actions (e.g. 'C-x C-s' for > save)? It should. Look at editing ~/.openoffice.org2.0/user/config/soffice.cfg/global/accelerator/en-US (basically anything in soffice.cfg), edit current.xml and have fun Now, the catch, you need to read the StarOffice 6/7/8 Administrator Guide to get the correct accels... I can't remember them off-hand -- Colin Charles, http://www.bytebot.net/ FUDCon II @ LinuxTag June 24-25, 2005 in Karlsruhe, Germany http://fedoraproject.com/fudcon/ From christey at csee.wvu.edu Sat Jun 11 01:52:28 2005 From: christey at csee.wvu.edu (Damian Christey) Date: Fri, 10 Jun 2005 21:52:28 -0400 Subject: gnome-panel eats a lot of memory Message-ID: <1118454748.17578.9.camel@localhost.localdomain> > Some how it seems to be related to the text in the window title or > something in that area. When i open Evince from the menu nothing happens > to the memory usage of gnome-panel. When i now open a PDF file with that > (empty) evince the memory usage of gnome-panel jumps up. If it open a > PDF from nautilus evince opens with the PDF and the memory usage of > gnome-panel jumps up. > > the same thing seems to be the case with archive manager, when opened > from the menu nothing happens to gnome-panel memory usages, but when > double clicking a tar file in nautilus or open a new tar file, the > memory usage of gnome-panel jumps up. > > On the other hand, opening a gnome-terminal and cd'ing around (that also > sets the window title) does nothing to the memory usage of gnome-panel. > Sounds to me like it has more to do with opening files with Gnome programs than opening windows in general, which says to me "gnome-recent", which is used by the panel. How much of a leak are we talking about? More than would be expected for the menu item that it adds for each opened file? Bug number? -- Damian Christey From cmadams at hiwaay.net Sat Jun 11 02:29:57 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 10 Jun 2005 21:29:57 -0500 Subject: Smart package manager (was Re: Making update functionality more usable (Was: Re: What next?)) In-Reply-To: <1118452551.4345.12.camel@plope.dyndns.org> References: <1118234067.20494.39.camel@arena.soho.bytebot.net> <42A96B79.5010609@cyber.com.au> <1118417487.7471.17.camel@plope.dyndns.org> <42A9EF33.3010601@redhat.com> <20050610215941.GB10673@nostromo.devel.redhat.com> <42AA0E55.3020806@redhat.com> <604aa79105061015063a89fb5e@mail.gmail.com> <1118443354.4345.3.camel@plope.dyndns.org> <604aa79105061016487576e224@mail.gmail.com> <1118452551.4345.12.camel@plope.dyndns.org> Message-ID: <20050611022957.GB1145007@hiwaay.net> Once upon a time, Chris McDonough said: > But if "multilib" means "the capability to distinguish between multiple > architecture packages for the same component and have the ability to > install each simultaneously or independently", smart seems to be able to > do that just fine. That's not what multilib means. It means the ability to take into account 32 and 64 bit libs and apps, and properly satisfy dependencies as appropriate. For example, if on a 64 bit arch I want to install a 32 bit app, the package management tool has to know that if the app requires libabc, it needs to find a 32 bit libabc to satisfy the dep (whether or not the 64 bit libabc is install or available has no relevance). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From b.j.smith at ieee.org Sat Jun 11 02:33:01 2005 From: b.j.smith at ieee.org (Bryan J. Smith) Date: Fri, 10 Jun 2005 21:33:01 -0500 Subject: OT: nVidia driver [was: Wish list] -- nVidia doesn't own a lot of the IP In-Reply-To: <20050610110313.825317312A@hormel.redhat.com> References: <20050610110313.825317312A@hormel.redhat.com> Message-ID: <1118457182.5835.185.camel@bert64.mobile.smithconcepts.com> From: Paul Iadonisi > If I saw nVidia and ATI maybe actively participating in the antitrust > case against Microsoft in the EU Oh don't even go there. Anti-trust is just another word for "everyone ganging up on a competitor." It typically solves *0* of the actual community issues, but only competitor ones. I think the results of the US trial -- both during the Clinton and Bush administrations -- show that it only addressed competitor issues, not standards-based ones. And you can be sure the EU lawsuit is more about trade than standards too. After all, HP and Red Hat donate massive amounts of IP and real GPL software to Linux -- in far excess of EU corporations, yet they are being "lumped in" with IBM as exploiting Linux in recent, so-called "reports." That _really_ exposed with what the EU is doing. I think the epitome of this can be seen in Boeing v. Airbus and the WTO. In other words, I don't believe any federated organization of states has any interest in standards and other community-focused endeavors -- at least it's very small compared to fiscally-aligned interests of its member corporations. Case-in-point: Who was the Senator that really got the DOJ v. MS going and what state was he from? ;-> > and joining NoSoftwarePatents.com then I'd be willing to cut them some > slack. Patents aren't bad. Patents on _common_ideas_ are bad. What we need to do is lobby for a massive reduction in patents, and 10x the scrutiny, instead of this "organ grinder" system we have. The US has a massive patent system that's out of control. At the same time, the US continues to be the incubator of countless technologies -- especially in the medical field. Disrespect for IP is why medicine are dis-proportionally expensive in this country, because no one else shares the IP burden but Americans. But without that return, there would not be the research. I have no argument that Microsoft is the _least_ innovative and the _most_ IP sucking company in the world. But just because of companies like Microsoft doesn't mean all companies are "bad." > And take a stand against the current patent system in the US. I think nVidia and SGI has done a lot of good for OpenGL in the past. You should read up on their donations. > That goes for any other company that is in this kind of mess. > Otherwise, they are just playing the victims. I do agree with you on companies like Red Hat trying to form "grass roots" efforts with other, _ethical_ companies to address this. > Or perhaps it isn't them painting *themselves* as victims. But if they > expended the resources necessary to *change* this mess more than in > their cloistered little worlds (with the resulting limited effect) then > maybe we'd get somewhere. Unfortunately, if one company does that, they just get taken advantage of by the other companies. Which is why we should support endeavors like Red Hat's. It could change the face of the landscape. Your points are noted. However, I don't believe in the current trend of federated litigation and abolishment of all software patents. Anything forced by a federated body smells like ... well, I don't want to say it. ;-> Community-based efforts by _choice_, like Red Hat's current efforts, are the best way. -- Bryan J. Smith b.j.smith at ieee.org --------------------------------------------------------------------- It is mathematically impossible for someone who makes more than you to be anything but richer than you. Any tax rate that penalizes them will also penalize you similarly (to those below you, and then below them). Linear algebra, let alone differential calculus or even ele- mentary concepts of limits, is mutually exclusive with US journalism. So forget even attempting to explain how tax cuts work. ;-> From vonbrand at inf.utfsm.cl Sat Jun 11 01:54:42 2005 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Fri, 10 Jun 2005 21:54:42 -0400 Subject: Breakage today on i686 Message-ID: <200506110154.j5B1sgPh009672@laptop11.inf.utfsm.cl> Kernel is broken ("BUG(): Software watchdog on CPU#0" or some such), freeze until I push the power button on this Toshiba Satellite M30, then boot continues. redhat-artwork-0.124-1.i386 kills gdm login completely. I get a login screen with a flower, but it doesn't work at all. Had to downgrade. selinux-policy-strict-1.23.18-4.noarch kills bash somehow, luckily I had tcsh installed, and (via rescue) created an account using it. YHBT. HAND. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From chrism at plope.com Sat Jun 11 03:56:27 2005 From: chrism at plope.com (Chris McDonough) Date: Fri, 10 Jun 2005 23:56:27 -0400 Subject: Smart package manager (was Re: Making update functionality more usable (Was: Re: What next?)) In-Reply-To: <20050611022957.GB1145007@hiwaay.net> References: <1118234067.20494.39.camel@arena.soho.bytebot.net> <42A96B79.5010609@cyber.com.au> <1118417487.7471.17.camel@plope.dyndns.org> <42A9EF33.3010601@redhat.com> <20050610215941.GB10673@nostromo.devel.redhat.com> <42AA0E55.3020806@redhat.com> <604aa79105061015063a89fb5e@mail.gmail.com> <1118443354.4345.3.camel@plope.dyndns.org> <604aa79105061016487576e224@mail.gmail.com> <1118452551.4345.12.camel@plope.dyndns.org> <20050611022957.GB1145007@hiwaay.net> Message-ID: <1118462187.4345.15.camel@plope.dyndns.org> On Fri, 2005-06-10 at 21:29 -0500, Chris Adams wrote: > That's not what multilib means. It means the ability to take into > account 32 and 64 bit libs and apps, and properly satisfy dependencies > as appropriate. For example, if on a 64 bit arch I want to install a 32 > bit app, the package management tool has to know that if the app > requires libabc, it needs to find a 32 bit libabc to satisfy the dep > (whether or not the 64 bit libabc is install or available has no > relevance). Gotcha. Thanks, I understand now. Maybe somebody with a 64-bit machine can try it out and let us know for sure? - C From dwmw2 at infradead.org Sat Jun 11 07:51:14 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 11 Jun 2005 08:51:14 +0100 Subject: Fw: "I plan to work on..." for FC5 In-Reply-To: <20050610233432.GI18279@devserv.devel.redhat.com> References: <030a01c56dda$8a87a250$b6491b31@td612671> <20050610233432.GI18279@devserv.devel.redhat.com> Message-ID: <1118476275.4823.84.camel@localhost.localdomain> On Fri, 2005-06-10 at 19:34 -0400, Alan Cox wrote: > The newer phones also support running a java crapplet when a bluetooth > connection is made to the phone, so you can actually prompt for the password > on the phone not just use it for presence testing. Yeah, but if you're going to prompt for a password on the phone, you might as well prompt for the password on the computer itself. You might get an extra layer of tinfoil for your hat by requiring the password _and_ the phone, but then you won't be able to use it on planes. -- dwmw2 From mailinglists at erwinrol.com Sat Jun 11 08:28:00 2005 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sat, 11 Jun 2005 10:28:00 +0200 Subject: gnome-panel eats a lot of memory In-Reply-To: <1118454748.17578.9.camel@localhost.localdomain> References: <1118454748.17578.9.camel@localhost.localdomain> Message-ID: <1118478481.11245.135.camel@xpc.home.erwinrol.com> On Fri, 2005-06-10 at 21:52 -0400, Damian Christey wrote: > > Sounds to me like it has more to do with opening files with Gnome > programs than opening windows in general, which says to me > "gnome-recent", which is used by the panel. How much of a leak are we > talking about? More than would be expected for the menu item that it > adds for each opened file? > The hint that it might be the recent file, seems a good guess, that would explain why gnome-terminal doesn't cause a problem. More info in bugzilla. > Bug number? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160137 > -- > Damian Christey > - Erwin From symbiont at berlios.de Sat Jun 11 09:24:54 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Sat, 11 Jun 2005 17:24:54 +0800 Subject: Smart package manager (was Re: Making update functionality more usable (Was: Re: What next?)) In-Reply-To: <1118462187.4345.15.camel@plope.dyndns.org> References: <1118234067.20494.39.camel@arena.soho.bytebot.net> <20050611022957.GB1145007@hiwaay.net> <1118462187.4345.15.camel@plope.dyndns.org> Message-ID: <200506111724.54749.symbiont@berlios.de> On Saturday 11 June 2005 11:56, Chris McDonough wrote: > On Fri, 2005-06-10 at 21:29 -0500, Chris Adams wrote: > > That's not what multilib means. ?It means the ability to take into > > account 32 and 64 bit libs and apps, and properly satisfy > > dependencies as appropriate. ?For example, if on a 64 bit arch I > > want to install a 32 bit app, the package management tool has to > > know that if the app requires libabc, it needs to find a 32 bit > > libabc to satisfy the dep (whether or not the 64 bit libabc is > > install or available has no relevance). > > Gotcha. ?Thanks, I understand now. ?Maybe somebody with a 64-bit > machine can try it out and let us know for sure? Or, you could ask gustavo: smart at linux-mandrake.com I've already forwarded a part of the thread over there. take care, -- -jeff From buildsys at redhat.com Sat Jun 11 11:23:14 2005 From: buildsys at redhat.com (Build System) Date: Sat, 11 Jun 2005 07:23:14 -0400 Subject: rawhide report: 20050611 changes Message-ID: <200506111123.j5BBNEgQ010583@porkchop.devel.redhat.com> New package gpart A program for recovering corrupt partition tables. Removed package sash Updated Packages: gamin-0.1.1-1 ------------- * Thu May 12 2005 Daniel Veillard 0.1.0-1 - Close inherited file descriptors on exec of gam_server - Cancelling a monitor send back a FAMAcknowledge - Fixed for big files > 2GB - Bug when monitoring a non existing directory - Make client side thread safe - Unreadable directory fixes - Better flow control handling - Updated to latest inotify version: 0.23-6 * Tue Mar 15 2005 Daniel Veillard 0.0.26-1 - Fix an include problem showing up with gcc4 - Fix the crash on failed tree assert bug #150471 based on patch from Dean Brettle - removed an incompatibility with SGI FAM #149822 * Tue Mar 01 2005 Daniel Veillard 0.0.25-1 - Fix a configure problem reported by Martin Schlemmer - Fix the /media/* and /mnt/* mount blocking problems from 0.0.24 e.g. #142637 - Fix the monitoring of directory using poll and not kernel hplip-0.9.3-3 ------------- * Thu Jun 09 2005 Tim Waugh 0.9.3-3 - Added Obsoletes: for xojpanel and hpoj-devel (but we don't actually package devel files yet). netpbm-10.28-1 -------------- * Fri Jun 10 2005 Jindrich Novy 10.28-1 - update to 10.28 - regenerated man pages - sync .security, .security2, .badlink, .libpm, .gcc4 patches - drop upstreamed .pngtopnm, .pnmcolormap patches openoffice.org-1:1.9.109-1.2.0.fc5 ---------------------------------- * Fri Jun 10 2005 Caolan McNamara - 1:1.9.109-1 - rh#158943# Require some fonts - bump to next version - drop integrated ooo46528.stillnotpic.icu.patch - drop integrated ooo48816.instsetoo_native.systempython.patch * Fri Jun 10 2005 Caolan McNamara - 1:1.9.108-4 - ooo#50556# Filetype-label doesn't support special char * Thu Jun 09 2005 Caolan McNamara - 1:1.9.108-3 - rh#159930# use us english thesaurus for australia as well - add openoffice.org-1.9.108.ooo47323.binfilter.stupiddetect.patch for rh#159851#/ooo#47323# prelink-0.3.5-1 --------------- * Fri Jun 10 2005 Jakub Jelinek 0.3.5-1 - support for ppc32 -msecure-plt libraries and binaries - don't crash if d_tag is invalid (#155605) - rebuilt against robustified libelf (CAN-2005-1704) - fix handling of libraries and binaries given on command line without any / characters in the filename selinux-policy-strict-1.23.18-5 ------------------------------- * Fri Jun 10 2005 Dan Walsh 1.23.18-5 - Further cleanup of user separation patches from Ivan selinux-policy-targeted-1.23.18-5 --------------------------------- * Fri Jun 10 2005 Dan Walsh 1.23.18-5 - Further cleanup of user separation patches from Ivan xerces-j2-0:2.6.2-4jpp_8fc -------------------------- * Fri Jun 10 2005 Gary Benson 0:2.6.2-4jpp_8fc - Remove the tools tarball, and build xjavac from source. - Replace classpath workaround to xjavac task and use xml-commons classes again (#152255). From fedora at camperquake.de Sat Jun 11 12:16:48 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 11 Jun 2005 14:16:48 +0200 Subject: Breakage today on i686 In-Reply-To: <200506110154.j5B1sgPh009672@laptop11.inf.utfsm.cl> References: <200506110154.j5B1sgPh009672@laptop11.inf.utfsm.cl> Message-ID: <20050611141648.54a38abf@nausicaa.camperquake.de> Hi. Horst von Brand wrote: > redhat-artwork-0.124-1.i386 kills gdm login completely. I get a login > screen with a flower, but it doesn't work at all. Had to downgrade. Workaround: switch to text console (Ctrl-Alt-F1), log in as root, run perl -pi -e 's/^GraphicalTheme=.*$/GraphicalTheme=circles/i' \ /etc/X11/gdm/gdm.conf Switch back to gdm (Alt-F7) Restart GDM (Ctrl-Alt-Backspace) -- "How should I know if it works? That's what beta testers are for. I only coded it." -- Linus Torvalds (allegedly) From Axel.Thimm at ATrpms.net Sat Jun 11 13:25:49 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 11 Jun 2005 15:25:49 +0200 Subject: Smart package manager In-Reply-To: <42AA0E55.3020806@redhat.com> References: <1117780095.3488.32.camel@cutter> <1117809250.8385.11.camel@mlenzdesktop> <1118024411.3011.11.camel@bree.local.net> <1118048011.2779.2.camel@roque> <1118234067.20494.39.camel@arena.soho.bytebot.net> <42A96B79.5010609@cyber.com.au> <1118417487.7471.17.camel@plope.dyndns.org> <42A9EF33.3010601@redhat.com> <20050610215941.GB10673@nostromo.devel.redhat.com> <42AA0E55.3020806@redhat.com> Message-ID: <20050611132549.GA30246@neu.nirvana> On Fri, Jun 10, 2005 at 12:04:05PM -1000, Warren Togami wrote: > Bill Nottingham wrote: > > Warren Togami (wtogami at redhat.com) said: > > > > It's written in Python, too! Very nice. Thanks for the tip... > > > Does smartpm support multilib yet? Yes, it does. Try for yourself: http://atrpms.net/name/smart/ Works for all FCs, RHEL4, RHL7.3-9. Does not work yet for RHEL3 due to promoteepoch necessities. Also rhn backend support would be very nice to have for RHEL3/4 (but officially probably out of Fedora's scope). It is said to be easy to add, but it would probably be done best by an rhn expert (Adrian? misa?). > > IIRC, apt doesn't, and it's in Extras. So, not sure that that's a > > blocking issue. > > > > Bill > > > > Huh? apt and smartpm have nothing in common. Other than the author? ;) -- 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 symbiont at berlios.de Sat Jun 11 13:30:43 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Sat, 11 Jun 2005 21:30:43 +0800 Subject: Fwd: [smart] multilib support (was: Smart package manager) Message-ID: <200506112130.43707.symbiont@berlios.de> FYI: smart supports multilib. ---------- Forwarded Message ---------- Subject: [smart] multilib support (was: Smart package manager) Date: Saturday 11 June 2005 20:22 From: Axel Thimm To: smart at mandrivalinux.org On Sat, Jun 11, 2005 at 08:53:56AM +0800, Jeff Pitman wrote: > Does smart do multi-lib yet? It does. :) -- Axel.Thimm at ATrpms.net ------------------------------------------------------- -- -jeff From rms at 1407.org Sat Jun 11 13:54:26 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Sat, 11 Jun 2005 14:54:26 +0100 Subject: OT: nVidia driver [was: Wish list] -- nVidia doesn't own a lot of the IP In-Reply-To: <1118457182.5835.185.camel@bert64.mobile.smithconcepts.com> References: <20050610110313.825317312A@hormel.redhat.com> <1118457182.5835.185.camel@bert64.mobile.smithconcepts.com> Message-ID: <1118498066.2806.23.camel@roque> On Fri, 2005-06-10 at 21:33 -0500, Bryan J. Smith wrote: > > and joining NoSoftwarePatents.com then I'd be willing to cut them some > > slack. > > Patents aren't bad. Patents on _common_ideas_ are bad. What we need to > do is lobby for a massive reduction in patents, and 10x the scrutiny, > instead of this "organ grinder" system we have. He's not talking about patents in general but software patents. All software patents are bad, and virtually all software patents are patents on _common_ideas_ Feel free to be the first to draw the line in the sand from whereupon it's a common idea or not. Nobody was ever able to clearly define that, so what you say is very nice in principle, but unfeasible in practice. But this is getting more and more off-topic. Rui -- + 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...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.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 alan at redhat.com Sat Jun 11 15:57:45 2005 From: alan at redhat.com (Alan Cox) Date: Sat, 11 Jun 2005 11:57:45 -0400 Subject: OT: nVidia driver [was: Wish list] -- nVidia doesn't own a lot of the IP In-Reply-To: <1118457182.5835.185.camel@bert64.mobile.smithconcepts.com> References: <20050610110313.825317312A@hormel.redhat.com> <1118457182.5835.185.camel@bert64.mobile.smithconcepts.com> Message-ID: <20050611155745.GA9566@devserv.devel.redhat.com> On Fri, Jun 10, 2005 at 09:33:01PM -0500, Bryan J. Smith wrote: > Oh don't even go there. Anti-trust is just another word for "everyone > ganging up on a competitor." It typically solves *0* of the actual Actually its a formally defined legal process to preserve free market behaviour and prevent massive abuse of the citizenship, riots, war and the other unpleasantries that follow when society isn't working. How well it works is a different matter. > too. After all, HP and Red Hat donate massive amounts of IP and real > GPL software to Linux -- in far excess of EU corporations, yet they are The EU people I've talked to don't think thats the case interestingly. They will point at SuSE, at KDE, (the fact Gnome is more European than US has eluded them so far) and numerous other projects in the EU. > Patents aren't bad. Patents on _common_ideas_ are bad. What we need to So you want patents on books, movies, and other literary works (software is a literary work remember...) > I think nVidia and SGI has done a lot of good for OpenGL in the past. > You should read up on their donations. But nVidia and friends are how markets are supposed to work, or something like it. Innovation, competition and price battles - and at times co-operation. No different to any other market. > Your points are noted. However, I don't believe in the current trend of > federated litigation and abolishment of all software patents. Anything > forced by a federated body smells like ... well, I don't want to say > it. ;-> Ah yes. Rights to justice, drinking water, not to be shot without a trial (except if you look foreign) ... Alan From b.j.smith at ieee.org Sat Jun 11 16:00:32 2005 From: b.j.smith at ieee.org (Bryan J. Smith) Date: Sat, 11 Jun 2005 11:00:32 -0500 Subject: OT: nVidia driver [was: Wish list] -- nVidia doesn't own a lot of the IP Message-ID: <1118505632.6504.41.camel@bert64.mobile.smithconcepts.com> From: Rui Miguel Seabra > He's not talking about patents in general but software patents. > All software patents are bad, and virtually all software patents are > patents on _common_ideas_ I completely disagree. There are countless, innovative software patents in many areas -- especially 3D, semiconductor, etc... You can't start eliminating software patents altogether without throwing away a lot of innovation. The problem is the "one-click" and other non-sense. Don't blame the entire patent concept as the problem because of the stupid patents that are granted. The US needs massive patent reform, yes, I don't disagree with that. But do away with all software patents? Sorry, that's the wrong move. Companies are expending a lot of funds to research many ideas. *NOT* Microsoft -- don't think of Microsoft when you think of software patents. Think of companies that truly innovate. They are rare compared to the crap that is granted, but they do exist. Sorry, but I have to say that the community is not always entitled to the absolutely latest innovations in many areas that are truly novel. Thankfully we do have companies who make them available and usable by even community software in open standard APIs. That is a very nice touch, and should be appreciated. > Feel free to be the first to draw the line in the sand from whereupon > it's a common idea or not. Nobody was ever able to clearly define > that, so what you say is very nice in principle, but unfeasible in > practice. The problem is the _lack_ of "peer review" in the patent system. Regulation, legislation and laws have _never_ solved problems as good as putting "peer experts" on the problem. That has always been the problem, people always wanting to go to more legislation, instead of relying on peer experts and industry-based approaches. > But this is getting more and more off-topic. I didn't introduce it. Some people want to introduce their political agendas here, and I'm merely trying to show the other side. I'm sure that's "annoying" at times, but I'm trying to let people know how to avoid being viewed as "community radicals" by others. If you want Linux to engage the corporate world, you have show them how things should and should not work. Not that the entire system is wrong, because if you take away the absolutes, it's really just skewed, and _can_ be fixed. I think Red Hat's new venture in getting companies to work together in a common patent pool is the most _helpful_ and most _American_ thing I have ever seen, and it's why I continue to believe Red Hat is the _best_ Linux company in the world. It believes strongly in community, yet understand that community is about _choice_ -- be it an individual or corporation. And not some ideal of federated mandate where not everyone might agree. Corporations and individuals who ban together in a community by choice will topple those who abuse IP, marketshare and other, unethical tactics. It is a far better, far safer, for more useful approach than by federated mandate that says "we know better than you." -- Bryan J. Smith b.j.smith at ieee.org --------------------------------------------------------------------- It is mathematically impossible for someone who makes more than you to be anything but richer than you. Any tax rate that penalizes them will also penalize you similarly (to those below you, and then below them). Linear algebra, let alone differential calculus or even ele- mentary concepts of limits, is mutually exclusive with US journalism. So forget even attempting to explain how tax cuts work. ;-> From b.j.smith at ieee.org Sat Jun 11 16:16:13 2005 From: b.j.smith at ieee.org (Bryan J. Smith) Date: Sat, 11 Jun 2005 11:16:13 -0500 Subject: OT: nVidia driver [was: Wish list] -- nVidia doesn't own a lot of the IP In-Reply-To: <20050611160013.334E473420@hormel.redhat.com> References: <20050611160013.334E473420@hormel.redhat.com> Message-ID: <1118506573.6504.52.camel@bert64.mobile.smithconcepts.com> From: Alan Cox > Actually its a formally defined legal process to preserve free market behaviour > and prevent massive abuse of the citizenship, riots, war and the other > unpleasantries that follow when society isn't working. > How well it works is a different matter. I'll see your wisdom there. > The EU people I've talked to don't think thats the case interestingly. They > will point at SuSE, at KDE, (the fact Gnome is more European than US has > eluded them so far) and numerous other projects in the EU. Most Americans believed the DOJ v. MS case was more of the same. Most didn't read the transcripts and follow the realities of the trial. >From what I've seen, while the people in both Unions may believe it's about them, it's really about the corporations in those Unions. Be it an advantages of one in a state against another, or of the union against other unions. > So you want patents on books, movies, and other literary works (software is > a literary work remember...) I think you're confusing implementations with concepts. Movies are not patentable. New innovations in movie technology are. That's why implementations are copyrighted for many decades, whereas patents are granted for a much shorter time. > But nVidia and friends are how markets are supposed to work, or something like > it. Innovation, competition and price battles - and at times co-operation. No > different to any other market. Yes and no. Yes, many markets have it. But no, we're talking products that are obsoleted in months, instead of years. We're already seeing community Freedomware development in the 3D space that was only 3-4 years behind. That is more than understandable. The community has never had the right to ownership to cutting-edge concepts, at least not without the research burden that goes with it. But it _is_ nice that we _do_ have corporate entities who _do_ at least release Standardware so we _can_ benefit from their innovations on Freedomware platforms _until_ the Freedomware research "catches up." > Ah yes. Rights to justice, drinking water, not to be shot without a trial > (except if you look foreign) ... So you believe rights to software are an inalienable right? How about a job for that matter? Or anything else that you believe is absolutely necessary to live? People who do not believe in entitlements aren't trying to preserve anything but the reality that when you mandate something, you only remove choice as well as any fiscal incentives to innovate. Yes, most software patents are bad in the US. They are simplistic and take no effort at all to conceive. And then there are real, innovative algorithms in software, that took years of research and proof of concepts to come about. Those endeavors and innovations will quickly _go_away_ if software patents are taken away. -- Bryan J. Smith b.j.smith at ieee.org --------------------------------------------------------------------- It is mathematically impossible for someone who makes more than you to be anything but richer than you. Any tax rate that penalizes them will also penalize you similarly (to those below you, and then below them). Linear algebra, let alone differential calculus or even ele- mentary concepts of limits, is mutually exclusive with US journalism. So forget even attempting to explain how tax cuts work. ;-> From seandarcy2 at gmail.com Sat Jun 11 16:19:19 2005 From: seandarcy2 at gmail.com (sean) Date: Sat, 11 Jun 2005 12:19:19 -0400 Subject: rawhide report: 20050611 changes In-Reply-To: <200506111123.j5BBNEgQ010583@porkchop.devel.redhat.com> References: <200506111123.j5BBNEgQ010583@porkchop.devel.redhat.com> Message-ID: Build System wrote: ................. > > gamin-0.1.1-1 > ------------- > * Thu May 12 2005 Daniel Veillard 0.1.0-1 > - Close inherited file descriptors on exec of gam_server > - Cancelling a monitor send back a FAMAcknowledge > - Fixed for big files > 2GB > - Bug when monitoring a non existing directory > - Make client side thread safe > - Unreadable directory fixes > - Better flow control handling > - Updated to latest inotify version: 0.23-6 > > * Tue Mar 15 2005 Daniel Veillard 0.0.26-1 > - Fix an include problem showing up with gcc4 > - Fix the crash on failed tree assert bug #150471 based on patch from Dean Brettle > - removed an incompatibility with SGI FAM #149822 > > * Tue Mar 01 2005 Daniel Veillard 0.0.25-1 > - Fix a configure problem reported by Martin Schlemmer > - Fix the /media/* and /mnt/* mount blocking problems from 0.0.24 e.g. #142637 > - Fix the monitoring of directory using poll and not kernel > The spec files removes libfam.la. For whatever reason, this is needed to build koffice ( other kde?) and filelight. sean From johnp at redhat.com Sat Jun 11 16:31:33 2005 From: johnp at redhat.com (John (J5) Palmieri) Date: Sat, 11 Jun 2005 12:31:33 -0400 Subject: Breakage today on i686 In-Reply-To: <200506110154.j5B1sgPh009672@laptop11.inf.utfsm.cl> References: <200506110154.j5B1sgPh009672@laptop11.inf.utfsm.cl> Message-ID: <1118507494.8090.1.camel@localhost.localdomain> redhat-artwork-0.124-2 fixes the problem but seems to be stuck in the build queue so we might not see it until after the weekend. On Fri, 2005-06-10 at 21:54 -0400, Horst von Brand wrote: > Kernel is broken ("BUG(): Software watchdog on CPU#0" or some such), freeze > until I push the power button on this Toshiba Satellite M30, then boot > continues. > > redhat-artwork-0.124-1.i386 kills gdm login completely. I get a login > screen with a flower, but it doesn't work at all. Had to downgrade. > > selinux-policy-strict-1.23.18-4.noarch kills bash somehow, luckily I had > tcsh installed, and (via rescue) created an account using it. > > YHBT. HAND. > -- > Dr. Horst H. von Brand User #22616 counter.li.org > Departamento de Informatica Fono: +56 32 654431 > Universidad Tecnica Federico Santa Maria +56 32 654239 > Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 > -- John (J5) Palmieri From seanlkml at sympatico.ca Sat Jun 11 15:35:10 2005 From: seanlkml at sympatico.ca (Sean) Date: Sat, 11 Jun 2005 11:35:10 -0400 (EDT) Subject: OT: nVidia driver [was: Wish list] -- nVidia doesn't own a lot of the IP In-Reply-To: <1118505632.6504.41.camel@bert64.mobile.smithconcepts.com> References: <1118505632.6504.41.camel@bert64.mobile.smithconcepts.com> Message-ID: <4593.10.10.10.24.1118504110.squirrel@linux1> On Sat, June 11, 2005 12:00 pm, Bryan J. Smith said: > I didn't introduce it. Some people want to introduce their political > agendas here, and I'm merely trying to show the other side. I'm sure > that's "annoying" at times, but I'm trying to let people know how to > avoid being viewed as "community radicals" by others. Bryan, It is not a political agenda or radical to have concluded that open source is a good thing. Therefore, it is not radical or political to advocate for it as a preference over closed-source solutions. Branding someone a radical just because they advocate for one solution over another is just plain nonsense. Let's not worry too much about being viewed as "community radicals"; lets just keep making the best open source solutions we know how. Those who see the benefits will follow; those who don't, will do something else. In the end, there is very little value to the open source community in supporting an infestation of binary-hacks into the O/S, no matter how much you personally believe in the functionality they add. Cheers, Sean From veillard at redhat.com Sat Jun 11 16:42:08 2005 From: veillard at redhat.com (Daniel Veillard) Date: Sat, 11 Jun 2005 12:42:08 -0400 Subject: rawhide report: 20050611 changes In-Reply-To: References: <200506111123.j5BBNEgQ010583@porkchop.devel.redhat.com> Message-ID: <20050611164208.GC20350@redhat.com> On Sat, Jun 11, 2005 at 12:19:19PM -0400, sean wrote: > Build System wrote: > ................. > > > >gamin-0.1.1-1 > > The spec files removes libfam.la. For whatever reason, this > is needed to build koffice ( other kde?) and filelight. the version in FC3 & FC3 keep the .la . The consensus was that kde would be rebuild to remove that dependancy. We are on Rawhide, the goal is to fix things at this point, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159144 Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From alan at redhat.com Sat Jun 11 16:58:44 2005 From: alan at redhat.com (Alan Cox) Date: Sat, 11 Jun 2005 12:58:44 -0400 Subject: OT: nVidia driver [was: Wish list] -- nVidia doesn't own a lot of the IP In-Reply-To: <1118506573.6504.52.camel@bert64.mobile.smithconcepts.com> References: <20050611160013.334E473420@hormel.redhat.com> <1118506573.6504.52.camel@bert64.mobile.smithconcepts.com> Message-ID: <20050611165844.GA31215@devserv.devel.redhat.com> On Sat, Jun 11, 2005 at 11:16:13AM -0500, Bryan J. Smith wrote: > I think you're confusing implementations with concepts. Movies are not > patentable. New innovations in movie technology are. That's why You can get patents on better projectors but not on "space movies" or "epic battle where hero loses a leg" .. You can get patents on processors but not on programs (at least in most of the world) > that was only 3-4 years behind. That is more than understandable. The > community has never had the right to ownership to cutting-edge concepts, > at least not without the research burden that goes with it. Nobody has a right to "own" ideas. Al the countries that have patents do so because they recognized the need to make a pact between the people and the creator and to distort both markets and natural order in order to foster progress (in theory). > > Ah yes. Rights to justice, drinking water, not to be shot without a trial > > (except if you look foreign) ... > > So you believe rights to software are an inalienable right? No I'm just pointing out that the evil federal mandates include good things 8) But this is getting off topic so I'll shut up Alan From pri.rhl4 at iadonisi.to Sat Jun 11 17:04:28 2005 From: pri.rhl4 at iadonisi.to (Paul Iadonisi) Date: Sat, 11 Jun 2005 13:04:28 -0400 Subject: OT: nVidia driver [was: Wish list] -- nVidia doesn't own a lot of the IP In-Reply-To: <1118506573.6504.52.camel@bert64.mobile.smithconcepts.com> References: <20050611160013.334E473420@hormel.redhat.com> <1118506573.6504.52.camel@bert64.mobile.smithconcepts.com> Message-ID: <1118509468.8156.7.camel@md.nc.linuxlobbyist.org> On Sat, 2005-06-11 at 11:16 -0500, Bryan J. Smith wrote: [snip] > Yes, most software patents are bad in the US. They are simplistic and > take no effort at all to conceive. And then there are real, innovative > algorithms in software, that took years of research and proof of > concepts to come about. Those endeavors and innovations will quickly > _go_away_ if software patents are taken away. This is complete bunk. If that were true then a lot Free Software wouldn't exist. I think this discussion on this list should end. I'll see you from the opposite side of the aisle as those of us who care about the future of software fight hard to abolish software patents (and prevent them in Europe). That's the goal, though we may never reach it, maybe we'll reach what you think is the ideal, but it's most likely the goal of at least GPL software authors and advocates. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From davej at redhat.com Sat Jun 11 17:46:26 2005 From: davej at redhat.com (Dave Jones) Date: Sat, 11 Jun 2005 13:46:26 -0400 Subject: Breakage today on i686 In-Reply-To: <200506110154.j5B1sgPh009672@laptop11.inf.utfsm.cl> References: <200506110154.j5B1sgPh009672@laptop11.inf.utfsm.cl> Message-ID: <20050611174625.GA13275@redhat.com> On Fri, Jun 10, 2005 at 09:54:42PM -0400, Horst von Brand wrote: > Kernel is broken ("BUG(): Software watchdog on CPU#0" or some such), freeze > until I push the power button on this Toshiba Satellite M30, then boot > continues. you should also get a backtrace with that message. please put it in bugzilla, and I'll take a look when I get back from vacation. Dave From seandarcy2 at gmail.com Sat Jun 11 18:16:43 2005 From: seandarcy2 at gmail.com (sean) Date: Sat, 11 Jun 2005 14:16:43 -0400 Subject: rawhide report: 20050611 changes In-Reply-To: <20050611164208.GC20350@redhat.com> References: <200506111123.j5BBNEgQ010583@porkchop.devel.redhat.com> <20050611164208.GC20350@redhat.com> Message-ID: Daniel Veillard wrote: > On Sat, Jun 11, 2005 at 12:19:19PM -0400, sean wrote: > >>Build System wrote: >>................. >> >>>gamin-0.1.1-1 >> >>The spec files removes libfam.la. For whatever reason, this >>is needed to build koffice ( other kde?) and filelight. > > > the version in FC3 & FC3 keep the .la . The consensus was that > kde would be rebuild to remove that dependancy. We are on Rawhide, > the goal is to fix things at this point, > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159144 > > Daniel > OK. Does the libfam.la dependency just go away if kde is rebuilt without .la installed, or does this require a change to the kde code? sean From veillard at redhat.com Sat Jun 11 21:43:34 2005 From: veillard at redhat.com (Daniel Veillard) Date: Sat, 11 Jun 2005 17:43:34 -0400 Subject: rawhide report: 20050611 changes In-Reply-To: References: <200506111123.j5BBNEgQ010583@porkchop.devel.redhat.com> <20050611164208.GC20350@redhat.com> Message-ID: <20050611214334.GE20350@redhat.com> On Sat, Jun 11, 2005 at 02:16:43PM -0400, sean wrote: > Daniel Veillard wrote: > >On Sat, Jun 11, 2005 at 12:19:19PM -0400, sean wrote: > > > >>Build System wrote: > >>................. > >> > >>>gamin-0.1.1-1 > >> > >>The spec files removes libfam.la. For whatever reason, this > >>is needed to build koffice ( other kde?) and filelight. > > > > > > the version in FC3 & FC3 keep the .la . The consensus was that > >kde would be rebuild to remove that dependancy. We are on Rawhide, > >the goal is to fix things at this point, > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159144 > > > >Daniel > > > OK. Does the libfam.la dependency just go away if kde is > rebuilt without .la installed, or does this require a change > to the kde code? our current guess is that it won't require it if rebuilt. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From d.jacobfeuerborn at conversis.de Sun Jun 12 01:09:36 2005 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Sun, 12 Jun 2005 03:09:36 +0200 Subject: gnome-panel eats a lot of memory In-Reply-To: <42851482.6040108@conversis.de> References: <42851482.6040108@conversis.de> Message-ID: <42AB8B50.9030407@conversis.de> Yesterday the same thing occured again. (I usually notice this when I try to open a terminal and gnome tells me that there isn't enough memory left to do that) This time however I also realized that the eog that was sitting on my desktop for the last few days displaying a picture apparently had grown to 128mb too. After closing it and loading the same picture up again it used a mere 12mb so it seems eog is also affected by some sort of leak. The question is how an application like eog that just sits there and does nothing can leak like that. Dennis Jacobfeuerborn wrote: > I noticed that gnome-panel eats 25% (=256mb) of my memory which is quite > a lot for a simple panel. Does anybody else see this too? I installed > FC4Test2 and then upgraded to Rawhide. > > Regards, > Dennis > From vonbrand at inf.utfsm.cl Sun Jun 12 01:15:54 2005 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Sat, 11 Jun 2005 21:15:54 -0400 Subject: Breakage today on i686 In-Reply-To: Your message of "Sat, 11 Jun 2005 13:46:26 -0400." <20050611174625.GA13275@redhat.com> Message-ID: <200506120115.j5C1FsYX009628@laptop11.inf.utfsm.cl> Dave Jones said: > On Fri, Jun 10, 2005 at 09:54:42PM -0400, Horst von Brand wrote: > > Kernel is broken ("BUG(): Software watchdog on CPU#0" or some such), > > freeze until I push the power button on this Toshiba Satellite M30, > > then boot continues. > you should also get a backtrace with that message. No backtrace, sorry. > please put it in bugzilla, and I'll take a look when I get > back from vacation. Thanks! Will see if it gets fixed in the meantime. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From pmatilai at laiskiainen.org Sun Jun 12 06:37:53 2005 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Sat, 11 Jun 2005 23:37:53 -0700 (PDT) Subject: "I plan to work on..." for FC5 In-Reply-To: <1118425001.4823.36.camel@localhost.localdomain> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <1118404276.2934.7.camel@localhost.localdomain> <20050610171354.GE20255@redhat.com> <1118425001.4823.36.camel@localhost.localdomain> Message-ID: On Fri, 10 Jun 2005, David Woodhouse wrote: > On Fri, 2005-06-10 at 13:13 -0400, Dave Jones wrote: >> So all I have to do is steal your laptop and phone, and I've got >> access to all your data ? The auto-login bit scares me a little. >> Having it lock the screen if you wander off I like the sound of >> though. > > Who runs a password-protected bootloader? You steal my laptop and you've > got access to all my data anyway. That's why people encrypt their laptops, password protected bootloader wont help at all by itself. - Panu - From gauret at free.fr Sun Jun 12 07:02:16 2005 From: gauret at free.fr (Aurelien Bompard) Date: Sun, 12 Jun 2005 09:02:16 +0200 Subject: Website: CSS file missing Message-ID: Hello, It looks like the CSS file is missing for the custom 404 page at download.fedora.redhat.com : http://download.fedora.redhat.com/something_that_doesnt_exist Bye, Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." -- Rich Cook From fedora at camperquake.de Sun Jun 12 10:41:13 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 12 Jun 2005 12:41:13 +0200 Subject: gnome-panel eats a lot of memory In-Reply-To: <42AB8B50.9030407@conversis.de> References: <42851482.6040108@conversis.de> <42AB8B50.9030407@conversis.de> Message-ID: <20050612104113.GA26737@ryoko.camperquake.de> On Sun, Jun 12, 2005 at 03:09:36AM +0200, Dennis Jacobfeuerborn wrote: > This time however I also realized that the eog that was sitting on my > desktop for the last few days displaying a picture apparently had grown to > 128mb too. After closing it and loading the same picture up again it used a > mere 12mb so it seems eog is also affected by some sort of leak. I have seen this, too, but did not have time so far to investigate and file a bug. Open a directory with pictures (large ones will help), and browse through them with eog. Sooner or later eog will die with an out of memory error. From mfioretti at mclink.it Sun Jun 12 10:54:06 2005 From: mfioretti at mclink.it (M. Fioretti) Date: Sun, 12 Jun 2005 12:54:06 +0200 Subject: Which patches to apply to source RPMs for a mini KDE? Message-ID: <20050612105406.GB21487@mclink.it> Greetings, I want to figure out how to install stable, already packaged versions of only some KDE applications on a Fedora Core 3 system which already has X and Qt. In other words, I would like to start from some KDE source RPMs for Fedora and massage the spec and Make files until I get other RPMs that *only* install: KOffice Konqueror KMail Kopete Kpdf (maybe a couple more whose name escapes me now) all the base KDE libraries that are *really* needed by those programs *nothing* else: NO sound, only one theme and set of icons, no wallpaper, no animation.... The purpose is to build a mini-KDe desktop for basic SOHO applications which has modern functionality (gpg, Khtml, Imap OpenDocument support...) but is as light as possible on RAM and hard drive. Said this: what are the latest stable SRPMS for the apps above for FC3, and where? any suggestion and tip on how and which files and settings remove and/or change (how) in the spec files? Thank you in advance, Marco -- Marco Fioretti mfioretti, at the server mclink.it Fedora Core 3 for low memory http://www.rule-project.org/ In a hundred years from now it will not matter what my bank account was, the type of house I lived in, or the kinds of clothes I wore, but the world may be much different because I was important in the life of a child Author unknown From buildsys at redhat.com Sun Jun 12 11:21:58 2005 From: buildsys at redhat.com (Build System) Date: Sun, 12 Jun 2005 07:21:58 -0400 Subject: rawhide report: 20050612 changes Message-ID: <200506121121.j5CBLwvw004540@porkchop.devel.redhat.com> Updated Packages: (none) From mpeters at mac.com Sun Jun 12 14:27:32 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 12 Jun 2005 07:27:32 -0700 Subject: Which patches to apply to source RPMs for a mini KDE? In-Reply-To: <20050612105406.GB21487@mclink.it> References: <20050612105406.GB21487@mclink.it> Message-ID: <1118586452.32158.16.camel@laptop.mpeters.local> On Sun, 2005-06-12 at 12:54 +0200, M. Fioretti wrote: > Greetings, > > I want to figure out how to install stable, already packaged versions > of only some KDE applications on a Fedora Core 3 system which already > has X and Qt. In other words, I would like to start from some KDE > source RPMs for Fedora and massage the spec and Make files until I get > other RPMs that *only* install: > > KOffice > Konqueror > KMail > Kopete > Kpdf > (maybe a couple more whose name escapes me now) > all the base KDE libraries that are *really* needed by those programs > > *nothing* else: NO sound, only one theme and set of icons, no > wallpaper, no animation.... > > The purpose is to build a mini-KDe desktop for basic SOHO applications > which has modern functionality (gpg, Khtml, Imap OpenDocument > support...) but is as light as possible on RAM and hard drive. Many apps are linked against libraries as a compile time detection - and the same package can be built so it is NOT linked against the libraries. The way to do it is to remove the BuildRequires for those packages and build in mach - that way the resulting rpm's won't be linked against the optional libraries you don't want. You also could disable the optional libraries explicitly in the spec spec file at the configure line. From mfioretti at mclink.it Sun Jun 12 17:01:20 2005 From: mfioretti at mclink.it (M. Fioretti) Date: Sun, 12 Jun 2005 19:01:20 +0200 Subject: Which patches to apply to source RPMs for a mini KDE? In-Reply-To: <1118586452.32158.16.camel@laptop.mpeters.local> References: <20050612105406.GB21487@mclink.it> <1118586452.32158.16.camel@laptop.mpeters.local> Message-ID: <20050612170120.GA27382@mclink.it> On Sun, Jun 12, 2005 07:27:32 AM -0700, Michael A. Peters (mpeters at mac.com) wrote: > On Sun, 2005-06-12 at 12:54 +0200, M. Fioretti wrote: > > Greetings, > > > > I want to figure out how to install stable, already packaged > > versions of only some KDE applications on a Fedora Core 3 system > > which already has X and Qt. [...] > > The purpose is to build a mini-KDe desktop for basic SOHO > > applications which has modern functionality (gpg, Khtml, Imap > > OpenDocument support...) but is as light as possible on RAM and > > hard drive. > > Many apps are linked against libraries as a compile time detection - and > the same package can be built so it is NOT linked against the libraries. > > The way to do it is to remove the BuildRequires for those packages and > build in mach - that way the resulting rpm's won't be linked against the > optional libraries you don't want. > > You also could disable the optional libraries explicitly in the spec > spec file at the configure line. > Michael, Thanks for the prompt answer. I will experiment as you suggest, but what did you exactly mean with the "build in mach" bit above? I understand the rest of your message, but that piece of sentence confused me... Related question: is there anything I could read to understand a priori, with the smallest number of trial and errors, what can be unlinked? I am prepared to try them one at a time, if really needed, but if there is a way around... Thanks again, Marco -- Marco Fioretti mfioretti, at the server mclink.it Fedora Core 3 for low memory http://www.rule-project.org/ None can love freedom heartily but good men; the rest love not freedom but license. John Milton From mpeters at mac.com Sun Jun 12 17:52:15 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 12 Jun 2005 10:52:15 -0700 Subject: Which patches to apply to source RPMs for a mini KDE? In-Reply-To: <20050612170120.GA27382@mclink.it> References: <20050612105406.GB21487@mclink.it> <1118586452.32158.16.camel@laptop.mpeters.local> <20050612170120.GA27382@mclink.it> Message-ID: <1118598735.32158.34.camel@laptop.mpeters.local> On Sun, 2005-06-12 at 19:01 +0200, M. Fioretti wrote: > > Thanks for the prompt answer. I will experiment as you suggest, but > what did you exactly mean with the "build in mach" bit above? I > understand the rest of your message, but that piece of sentence > confused me... mach is a tool for building clean rpm's in a chrooted environment. It will setup a basic chroot with minimal build environment, then grab only the build requires specified in the spec file (and their dependencies), and then build the rpm. It's a great way to catch missing build requires, and make sure your package only links against what you want it to link against. > > Related question: is there anything I could read to understand a > priori, with the smallest number of trial and errors, what can be > unlinked? I am prepared to try them one at a time, if really needed, > but if there is a way around... unpack the tarball - and run ./configure --help You should get a list that gives you a good idea of what is optional and what is not. Sometimes the readme gives a bare minimum. Also - google for Linux From Scratch - and BLFS The BLFS guide (beyond linux from scratch) sometimes has exactly listed what is required and what is optional. From b.j.smith at ieee.org Sun Jun 12 18:35:21 2005 From: b.j.smith at ieee.org (Bryan J. Smith) Date: Sun, 12 Jun 2005 13:35:21 -0500 Subject: OT: nVidia driver [was: Wish list] -- nVidia doesn't own a lot of the IP In-Reply-To: <20050612160005.544C973926@hormel.redhat.com> References: <20050612160005.544C973926@hormel.redhat.com> Message-ID: <1118601321.4411.109.camel@bert64.mobile.smithconcepts.com> Sean wrote: > Bryan, > It is not a political agenda or radical to have concluded that open source > is a good thing. Open source is a _very_good_ thing. The idea of the community bonding together in the hope of establishing something for the good of everyone is very noble. But there is a fine line between people or entities _choosing_ and it being _mandated_. You have to be very cautious. One company that will continually receive my praise is Red Hat because it understand the value of _choosing_ to share. And they are a "do as I do" instead of a "do as I say" type of entity. It makes it very easy to point to Red Hat and say -- "see, there's an example!" > Therefore, it is not radical or political to advocate for it as a preference > over closed-source solutions. Agreed. But some people go beyond that. They don't want to stop and understand the other side of the coin. They think of Microsoft or the worst example, not realizing there are very good companies in between. They may not be open source, or only partially open source, but they are dedicated to open standards. People will always differ, but as long as everyone can inter-operate, that's ideal. > Branding someone a radical just because they advocate for one solution > over another is just plain nonsense. No, not *1* solution, but *1* _outlaw_ of another, or federal preference of one. It's a very fine line. Freedom has to be choice. Community has to be choice. Again, it's a very fine line. > Let's not worry too much about being viewed as "community radicals"; Why not? It happens all-the-time. Personally, I run into it all-the- time. I'm arguing for Freedomware (open source, open standards by choice) solutions, and then I get shot down because people lump my concepts in with the Commuware (open source, open standards by mandate) fundamentalists. By not taking the time to differentiate Commerceware/Hostageware from Standardware/Sourceware, you're going the same thing in reverse. There is this absolutist radicalism on _both_ sides. [ And yes, these terms are terms of my own creation. But I haven't seen a better set -- other than the 1-dimensional "open" v. "proprietary" sides that doesn't do much to expose the lack of understanding in both directions. ] > lets just keep making the best open source solutions we know how. I agree very much so. But that doesn't mean by tearing down the whole institution of IP -- or just the portion that affects us. > Those who see the benefits will follow; those who don't, will do > something else. In the majority of cases, especially with commodity concepts and ideas, open source is the ideal. But sometimes, especially in an area with limited development by the community, especially with new concepts, things aren't so commodity. In that case, we can either hope someone will release open standards until the concepts become commodity or open source endeavors mature, or we're stuck with proprietary standards and everyone loses. No one has a right to every idea as it is thought of, but we can appreciate those who care to share it, even when it is still fresh. Especially when the industry is still maturing, and there is a lot at stake in products -- especially when products themselves are obsoleted not only after the moment they are conceived. > In the end, there is very little value to the open source community in > supporting an infestation of binary-hacks into the O/S, You don't have to support it -- not one finger. But you do have to understand why others might want it. That's what the term "freedom to choose" means. > no matter how much you personally believe in the functionality they add. And *I* will decide that for myself. We should let others do the same. Sometimes there is nothing more dangerous than someone saying "we know what's better for you." As much as I may _agree_ with you, I have to step back and realize that _choice_ much be preserved, even when I don't agree with Microsoft or others. Alan Cox wrote: > Nobody has a right to "own" ideas. Al the countries that have patents do so > because they recognized the need to make a pact between the people and the > creator and to distort both markets and natural order in order to foster > progress (in theory). > No I'm just pointing out that the evil federal mandates include good things 8) Yes, as they are necessary. In fact, if someone wants to mandate "open standards," I'm all for it. The problem is when someone decides that "open source" is always better. In many, many cases, yes. But not always. Especially not when someone is willing to pay for an implementation that might not be so commodity in idea, at least not at first. > But this is getting off topic so I'll shut up Well, sometimes I can be a little "radical" in my ideas too, I'll admit that. I'm sure some of my American Libertarian-oriented views probably make various people sick. But I don't think I'm too far from ESR. My biggest fear is to see Linux mandated. It's one thing to standardize on it as a consumer -- even as the federal government (thinking as a consumer). It's another, very scare thing to see it legislated (thinking as a regulator). As much as I would never vote Ralph Nader, he hit it on the nose when he said the US federal government should think more as a consumer, than as a regulator when it comes to Microsoft. We must remember not to demonize the entire commercial software industry as Microsoft. Even if that is a popular way to demonizing something we don't agree with -- use the worst case as an example. It expenses a lot of people and companies "caught in the middle." -- Bryan J. Smith b.j.smith at ieee.org --------------------------------------------------------------------- It is mathematically impossible for someone who makes more than you to be anything but richer than you. Any tax rate that penalizes them will also penalize you similarly (to those below you, and then below them). Linear algebra, let alone differential calculus or even ele- mentary concepts of limits, is mutually exclusive with US journalism. So forget even attempting to explain how tax cuts work. ;-> From rms at 1407.org Sun Jun 12 19:01:09 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Sun, 12 Jun 2005 20:01:09 +0100 Subject: OT: nVidia driver [was: Wish list] -- nVidia doesn't own a lot of the IP In-Reply-To: <1118601321.4411.109.camel@bert64.mobile.smithconcepts.com> References: <20050612160005.544C973926@hormel.redhat.com> <1118601321.4411.109.camel@bert64.mobile.smithconcepts.com> Message-ID: <1118602869.2806.54.camel@roque> On Sun, 2005-06-12 at 13:35 -0500, Bryan J. Smith wrote: > You don't have to support it -- not one finger. But you do have to > understand why others might want it. That's what the term "freedom to > choose" means. Chosing slavery is not a freedom, it's waiving freedom. Likewise, accepting non-Free(dom) terms is not freedom of choice, but subjugation to somebody else's power over you. In the case of 3d binary drivers, they're exploiting your craving for 3D, and providing it at cost of your loss of freedom. It is your choice, in fact, but not much different than the choice a chemically (3D) addicted person has over buying the chemical to the local dealer. You may get the appeasing visions, but in the end you'll eventually suffer, and you seem to like enticing others to do it, which is reprehensible. Rui -- + 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...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.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 seanlkml at sympatico.ca Sun Jun 12 19:53:35 2005 From: seanlkml at sympatico.ca (Sean) Date: Sun, 12 Jun 2005 15:53:35 -0400 (EDT) Subject: OT: nVidia driver [was: Wish list] -- nVidia doesn't own a lot of the IP In-Reply-To: <1118601321.4411.109.camel@bert64.mobile.smithconcepts.com> References: <20050612160005.544C973926@hormel.redhat.com> <1118601321.4411.109.camel@bert64.mobile.smithconcepts.com> Message-ID: <4229.10.10.10.24.1118606015.squirrel@linux1> On Sun, June 12, 2005 2:35 pm, Bryan J. Smith said: Bryan, I agree with much of what you said; forgive me for focusing on only the things where we differ: > By not taking the time to differentiate Commerceware/Hostageware from > Standardware/Sourceware, you're going the same thing in reverse. There > is this absolutist radicalism on _both_ sides. People who understand the distinctions you draw, may still conclude that their own best interest is served by focusing on open-source, and rejecting the rest of your categories. This does not make them radical or narrow minded. > And *I* will decide that for myself. We should let others do the same. But you're advocating for what others should do too! You're no different than the people who are advocating for open source. You might think your criteria is based on sounder reasoning, however we think ours is based on even more sound reasoning ;o) > Sometimes there is nothing more dangerous than someone saying "we know > what's better for you." As much as I may _agree_ with you, I have to > step back and realize that _choice_ much be preserved, even when I don't > agree with Microsoft or others. Yes. But other than the technical arguments against using binary-only drivers, nobody is telling you what is best for you. Only what, in our opinion, is best for the advancement of open source. You're free to use whatever criteria you want in making your own choice. That doesn't mean we should be silenced when suggesting to people that they consider their choice in a broader context. Regards, Sean From riel at redhat.com Sun Jun 12 21:24:29 2005 From: riel at redhat.com (Rik van Riel) Date: Sun, 12 Jun 2005 17:24:29 -0400 (EDT) Subject: OT: nVidia driver [was: Wish list] -- nVidia doesn't own a lot of the IP In-Reply-To: <1118505632.6504.41.camel@bert64.mobile.smithconcepts.com> References: <1118505632.6504.41.camel@bert64.mobile.smithconcepts.com> Message-ID: On Sat, 11 Jun 2005, Bryan J. Smith wrote: > I completely disagree. There are countless, innovative software patents > in many areas -- especially 3D, semiconductor, etc... You can't start > eliminating software patents altogether without throwing away a lot of > innovation. I've seen no evidence that software patents actually promote innovation, and neither have the various studies commissioned by a number of governments. Also, I can't think of a single piece of software that wouldn't have been invented if it weren't for the existance of patents. Not a single one... -- The Theory of Escalating Commitment: "The cost of continuing mistakes is borne by others, while the cost of admitting mistakes is borne by yourself." -- Joseph Stiglitz, Nobel Laureate in Economics From skvidal at phy.duke.edu Sun Jun 12 21:29:39 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 12 Jun 2005 17:29:39 -0400 Subject: OT: nVidia driver [was: Wish list] -- nVidia doesn't own a lot of the IP In-Reply-To: References: <1118505632.6504.41.camel@bert64.mobile.smithconcepts.com> Message-ID: <1118611779.3157.94.camel@cutter> > Also, I can't think of a single piece of software > that wouldn't have been invented if it weren't for > the existance of patents. Not a single one... > I think that's b/c the driving force behind a lot of software creation is 'boy, this would be cool'. -sv From pri.rhl4 at iadonisi.to Sun Jun 12 22:03:54 2005 From: pri.rhl4 at iadonisi.to (Paul Iadonisi) Date: Sun, 12 Jun 2005 18:03:54 -0400 Subject: OT: nVidia driver [was: Wish list] -- nVidia doesn't own a lot of the IP In-Reply-To: References: <1118505632.6504.41.camel@bert64.mobile.smithconcepts.com> Message-ID: <1118613834.4902.7.camel@md.nc.linuxlobbyist.org> On Sun, 2005-06-12 at 17:24 -0400, Rik van Riel wrote: [snip] > I've seen no evidence that software patents actually > promote innovation, and neither have the various > studies commissioned by a number of governments. > > Also, I can't think of a single piece of software > that wouldn't have been invented if it weren't for > the existance of patents. Not a single one... And those who think otherwise seem to hold the view that direct financial gain is the only thing that motivates anyone to produce any ideas of worth. It's a cynical and bogus point of view. For every programmer that insist on patenting his novel software ideas and won't program otherwise, there are many, many who will come along and produce what he wouldn't for the love of 'promoting the progress of science'. Hmm, where have I heard that before. ;-) -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From skvidal at phy.duke.edu Mon Jun 13 06:08:34 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 13 Jun 2005 02:08:34 -0400 Subject: Yum Upgrade Faq Message-ID: <1118642915.19703.52.camel@cutter> I've added a wiki page here: http://fedoraproject.org/wiki/YumUpgradeFaq It's about upgrading from release to release via yum. If you find any other odd gotchas - add them there. -sv From florin at andrei.myip.org Mon Jun 13 06:34:30 2005 From: florin at andrei.myip.org (Florin Andrei) Date: Sun, 12 Jun 2005 23:34:30 -0700 Subject: mtune=nocona In-Reply-To: <604aa79105060907156909a8b2@mail.gmail.com> References: <1118309310.12595.47.camel@neptune.psag.mwg> <604aa79105060907156909a8b2@mail.gmail.com> Message-ID: <1118644470.30296.5.camel@rivendell.home.local> On Thu, 2005-06-09 at 10:15 -0400, Jeff Spaleta wrote: > I highly > doubt Core is ever going to decide its worth the support and > maintainence hassle to distro tuned optimally for just a 64bit amd > chip or just a 64bit intel chip. When you are only going to ship one > version of the distro to cover several chips.. you make choices as to > what performance hits your are going to allow. Also, nothing stops anyone to respin the distro with different compiler options. (nothing besides time and effort) -- Florin Andrei http://florin.myip.org/ From nicolas.mailhot at laposte.net Mon Jun 13 07:47:28 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 13 Jun 2005 09:47:28 +0200 (CEST) Subject: OT: nVidia driver [was: Wish list] -- nVidia doesn't own a lot of the IP In-Reply-To: <1118613834.4902.7.camel@md.nc.linuxlobbyist.org> References: <1118505632.6504.41.camel@bert64.mobile.smithconcepts.com> <1118613834.4902.7.camel@md.nc.linuxlobbyist.org> Message-ID: <58673.192.54.193.37.1118648848.squirrel@rousalka.dyndns.org> On Lun 13 juin 2005 0:03, Paul Iadonisi a ?crit : > On Sun, 2005-06-12 at 17:24 -0400, Rik van Riel wrote: > > [snip] > >> I've seen no evidence that software patents actually >> promote innovation, and neither have the various >> studies commissioned by a number of governments. >> >> Also, I can't think of a single piece of software >> that wouldn't have been invented if it weren't for >> the existance of patents. Not a single one... > > And those who think otherwise seem to hold the view that direct > financial gain is the only thing that motivates anyone to produce any > ideas of worth. It's a cynical and bogus point of view. Bogus because no real programmer will know or want to know how to deal with patents, so they don't figure in his thinking. And people who know how to file patents have historically been more interested in registering the obvious than new ideas (this part would require lawyers and developpers to talk with each other, which is a social impossibility) Regards, -- Nicolas Mailhot From buildsys at redhat.com Mon Jun 13 11:19:03 2005 From: buildsys at redhat.com (Build System) Date: Mon, 13 Jun 2005 07:19:03 -0400 Subject: rawhide report: 20050613 changes Message-ID: <200506131119.j5DBJ3PU016769@porkchop.devel.redhat.com> Updated Packages: (none) From rodd at clarkson.id.au Mon Jun 13 12:18:52 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Mon, 13 Jun 2005 22:18:52 +1000 Subject: rawhide report: 20050610 changes In-Reply-To: <200506101142.j5ABgAA1000595@porkchop.devel.redhat.com> References: <200506101142.j5ABgAA1000595@porkchop.devel.redhat.com> Message-ID: <1118665132.3459.0.camel@localhost.localdomain> On Fri, 2005-06-10 at 07:42 -0400, Build System wrote: > kernel-2.6.11-1.1381_FC5 > ------------------------ > * Thu Jun 09 2005 Dave Jones > - 2.6.12-rc6-git3 > - Temporarily disable the ipw drivers until I sort them out. What's up with these drivers? What's to sort out? R. -- "It's a fine line between denial and faith. It's much better on my side" From mbneto at gmail.com Mon Jun 13 13:16:33 2005 From: mbneto at gmail.com (mbneto) Date: Mon, 13 Jun 2005 09:16:33 -0400 Subject: Where is it ? :) Message-ID: <5cf776b80506130616d16ea9c@mail.gmail.com> Are we going to see fc4 today ? I've been checking slashdot/freshmeat/fedora.redhat.com and no sign of it. From skvidal at phy.duke.edu Mon Jun 13 13:18:50 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 13 Jun 2005 09:18:50 -0400 Subject: Where is it ? :) In-Reply-To: <5cf776b80506130616d16ea9c@mail.gmail.com> References: <5cf776b80506130616d16ea9c@mail.gmail.com> Message-ID: <1118668731.19703.65.camel@cutter> On Mon, 2005-06-13 at 09:16 -0400, mbneto wrote: > Are we going to see fc4 today ? > > I've been checking slashdot/freshmeat/fedora.redhat.com and no sign of it. 10am EST - read the webpage. -sv From mattdm at mattdm.org Mon Jun 13 13:36:34 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 13 Jun 2005 09:36:34 -0400 Subject: Where is it ? :) In-Reply-To: <1118668731.19703.65.camel@cutter> References: <5cf776b80506130616d16ea9c@mail.gmail.com> <1118668731.19703.65.camel@cutter> Message-ID: <20050613133634.GA31210@jadzia.bu.edu> On Mon, Jun 13, 2005 at 09:18:50AM -0400, seth vidal wrote: > > Are we going to see fc4 today ? > > I've been checking slashdot/freshmeat/fedora.redhat.com and no sign of it. > 10am EST - read the webpage. ^ D :) I grew up in Indiana, so I'm sensitive to this. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 82 degrees Fahrenheit. From roozbeh at farsiweb.info Mon Jun 13 13:37:39 2005 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Mon, 13 Jun 2005 18:07:39 +0430 Subject: Where is it ? :) In-Reply-To: <1118668731.19703.65.camel@cutter> References: <5cf776b80506130616d16ea9c@mail.gmail.com> <1118668731.19703.65.camel@cutter> Message-ID: <1118669859.4908.35.camel@tameshk.bamdad.org> On Mon, 2005-06-13 at 09:18 -0400, seth vidal wrote: > On Mon, 2005-06-13 at 09:16 -0400, mbneto wrote: > > Are we going to see fc4 today ? > > > > I've been checking slashdot/freshmeat/fedora.redhat.com and no sign of it. > > 10am EST - read the webpage. Ah, it should be EDT, I guess. And giving times in term of UTC would always be better. So, it's really 14:00 UTC, less than thirty minutes from now. roozbeh From jerone at gmail.com Mon Jun 13 14:20:47 2005 From: jerone at gmail.com (Jerone Young) Date: Mon, 13 Jun 2005 09:20:47 -0500 Subject: Where is it ? :) In-Reply-To: <5cf776b80506130616d16ea9c@mail.gmail.com> References: <5cf776b80506130616d16ea9c@mail.gmail.com> Message-ID: <9f50a7a00506130720397e86e@mail.gmail.com> http://torrent.linux.duke.edu/ On 6/13/05, mbneto wrote: > Are we going to see fc4 today ? > > I've been checking slashdot/freshmeat/fedora.redhat.com and no sign of it. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From skvidal at phy.duke.edu Mon Jun 13 14:22:52 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 13 Jun 2005 10:22:52 -0400 Subject: Where is it ? :) In-Reply-To: <9f50a7a00506130720397e86e@mail.gmail.com> References: <5cf776b80506130616d16ea9c@mail.gmail.com> <9f50a7a00506130720397e86e@mail.gmail.com> Message-ID: <1118672572.19703.76.camel@cutter> On Mon, 2005-06-13 at 09:20 -0500, Jerone Young wrote: > http://torrent.linux.duke.edu/ > Better yet - the 'official' link should be: http://torrent.fedoraproject.org -sv From kewley at gps.caltech.edu Mon Jun 13 14:22:28 2005 From: kewley at gps.caltech.edu (David Kewley) Date: Mon, 13 Jun 2005 07:22:28 -0700 Subject: Where is it ? :) In-Reply-To: <1118669859.4908.35.camel@tameshk.bamdad.org> References: <5cf776b80506130616d16ea9c@mail.gmail.com> <1118668731.19703.65.camel@cutter> <1118669859.4908.35.camel@tameshk.bamdad.org> Message-ID: <200506130722.28500.kewley@gps.caltech.edu> On Monday 13 June 2005 06:37, Roozbeh Pournader wrote: > On Mon, 2005-06-13 at 09:18 -0400, seth vidal wrote: > > On Mon, 2005-06-13 at 09:16 -0400, mbneto wrote: > > > Are we going to see fc4 today ? > > > > > > I've been checking slashdot/freshmeat/fedora.redhat.com and no > > > sign of it. > > > > 10am EST - read the webpage. > > Ah, it should be EDT, I guess. And giving times in term of UTC would > always be better. > > So, it's really 14:00 UTC, less than thirty minutes from now. And now that it should be up, it looks like the updates tree is fubared for yum: http://ftp.ussg.iu.edu/linux/fedora/linux/core/updates/4/x86_64/repodata/repomd.xml: [Errno 4] IOError: HTTP Error 404: Date: Mon, 13 Jun 2005 14:20:11 GMT Server: Apache Content-Length: 258 Content-Type: text/html; charset=iso-8859-1 Trying other mirror. http://linux.admin.uillinois.edu/pub/linux/fedora/linux/core/updates/4/x86_64/repodata/repomd.xml: [Errno 4] IOError: HTTP Error 403: Date: Mon, 13 Jun 2005 14:20:11 GMT Server: Apache/2.0.46 (Red Hat) Content-Length: 360 Connection: close Content-Type: text/html; charset=iso-8859-1 Trying other mirror. http://www.fedora.is/fedora/core/updates/4/x86_64/repodata/repomd.xml: [Errno 4] IOError: HTTP Error 404: Date: Mon, 13 Jun 2005 14:20:13 GMT Server: Apache/2.0.46 (Red Hat) Content-Length: 328 Connection: close Content-Type: text/html; charset=iso-8859-1 Trying other mirror. Etc. for about a dozen mirrors that I let it try. David From skvidal at phy.duke.edu Mon Jun 13 14:25:56 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 13 Jun 2005 10:25:56 -0400 Subject: Where is it ? :) In-Reply-To: <200506130722.28500.kewley@gps.caltech.edu> References: <5cf776b80506130616d16ea9c@mail.gmail.com> <1118668731.19703.65.camel@cutter> <1118669859.4908.35.camel@tameshk.bamdad.org> <200506130722.28500.kewley@gps.caltech.edu> Message-ID: <1118672756.19703.80.camel@cutter> On Mon, 2005-06-13 at 07:22 -0700, David Kewley wrote: > On Monday 13 June 2005 06:37, Roozbeh Pournader wrote: > > On Mon, 2005-06-13 at 09:18 -0400, seth vidal wrote: > > > On Mon, 2005-06-13 at 09:16 -0400, mbneto wrote: > > > > Are we going to see fc4 today ? > > > > > > > > I've been checking slashdot/freshmeat/fedora.redhat.com and no > > > > sign of it. > > > > > > 10am EST - read the webpage. > > > > Ah, it should be EDT, I guess. And giving times in term of UTC would > > always be better. > > > > So, it's really 14:00 UTC, less than thirty minutes from now. > > And now that it should be up, it looks like the updates tree is fubared > for yum: > Etc. for about a dozen mirrors that I let it try. > known - being fixed upstream by pushing out some updates. -sv From pbrobinson at gmail.com Mon Jun 13 14:25:33 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 13 Jun 2005 15:25:33 +0100 Subject: Where is it ? :) In-Reply-To: <200506130722.28500.kewley@gps.caltech.edu> References: <5cf776b80506130616d16ea9c@mail.gmail.com> <1118668731.19703.65.camel@cutter> <1118669859.4908.35.camel@tameshk.bamdad.org> <200506130722.28500.kewley@gps.caltech.edu> Message-ID: <5256d0b050613072558caa5dc@mail.gmail.com> > > Ah, it should be EDT, I guess. And giving times in term of UTC would > > always be better. > > > > So, it's really 14:00 UTC, less than thirty minutes from now. > > And now that it should be up, it looks like the updates tree is fubared > for yum: > > http://ftp.ussg.iu.edu/linux/fedora/linux/core/updates/4/x86_64/repodata/repomd.xml: > [Errno 4] IOError: HTTP Error 404: Date: Mon, 13 Jun 2005 14:20:11 GMT > Server: Apache > Content-Length: 258 > Content-Type: text/html; charset=iso-8859-1 > Trying other mirror. > http://linux.admin.uillinois.edu/pub/linux/fedora/linux/core/updates/4/x86_64/repodata/repomd.xml: > [Errno 4] IOError: HTTP Error 403: Date: Mon, 13 Jun 2005 14:20:11 GMT > Server: Apache/2.0.46 (Red Hat) > Content-Length: 360 > Connection: close > Content-Type: text/html; charset=iso-8859-1 > Trying other mirror. > http://www.fedora.is/fedora/core/updates/4/x86_64/repodata/repomd.xml: > [Errno 4] IOError: HTTP Error 404: Date: Mon, 13 Jun 2005 14:20:13 GMT > Server: Apache/2.0.46 (Red Hat) > Content-Length: 328 > Connection: close > Content-Type: text/html; charset=iso-8859-1 > Trying other mirror. Well I think it needs to allow the mirrors to sync. I can get the isos from the main download.fedora.redhat.com so its out. Pete From mattdm at mattdm.org Mon Jun 13 14:25:52 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 13 Jun 2005 10:25:52 -0400 Subject: Where is it ? :) In-Reply-To: <200506130722.28500.kewley@gps.caltech.edu> References: <5cf776b80506130616d16ea9c@mail.gmail.com> <1118668731.19703.65.camel@cutter> <1118669859.4908.35.camel@tameshk.bamdad.org> <200506130722.28500.kewley@gps.caltech.edu> Message-ID: <20050613142552.GA1466@jadzia.bu.edu> On Mon, Jun 13, 2005 at 07:22:28AM -0700, David Kewley wrote: > And now that it should be up, it looks like the updates tree is fubared > for yum: Yeah -- there's nothing there yet, including no yum metadata files saying 'nothing there', so yum is failing. Hopefully this will be fixed soon, but it'll probably be a day before all of the mirrors have what they need. Oops! -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 82 degrees Fahrenheit. From thebs413 at earthlink.net Mon Jun 13 15:06:24 2005 From: thebs413 at earthlink.net (Bryan J. Smith ) Date: Mon, 13 Jun 2005 10:06:24 -0500 (GMT-05:00) Subject: OT: nVidia driver -- everything but open source is slavery? Message-ID: <14209149.1118675184713.JavaMail.root@wamui-norfolk.atl.sa.earthlink.net> From: Rui Miguel Seabra > Chosing slavery is not a freedom, it's waiving freedom. This is _exactly_ the type of non-sense I'm talking about! By the same definition, you can call "working" as "slavery." Are you entitled to free drivers that are Open Source? Or should you have to _work_ to ensure Freedomware drivers? Either you pay ATI, Matrox, nVidia, etc... for their latest efforts. Or you wait on the efforts of others in the community, possibly helping them as well. You are _not_ entitled to "free money" by not working anymore than you are _not_ entitled to Open Source on every, latest innovation. > Likewise, accepting non-Free(dom) terms is not freedom of choice, but > subjugation to somebody else's power over you. Because you are looking at this as a "Microsoft" type problem -- complete proprietary/unmaintained source/standards. You don't see any middle ground -- you think everything is "slavery." > In the case of 3d binary drivers, they're exploiting your craving for > 3D, and providing it at cost of your loss of freedom. No I'm not. I'm free to choose whatever video solution I want. If I choose nVidia, I am saying that I trust them to continue their outstanding GLX support for Linux. I do the same when I choose Matrox as well, and ATI as of more recent. At any time I can choose another libGL/GLX solution. I'm not tied to choosing nVidia. I choose nVidia because they provide _value_ in a libGL/GLX solution in lieu of an adequate one when necessary. That's the difference when you look at "open" v. "proprietary" _standards_. Yes, open source is typically ideal. I don't dispute that. But this "absolutism" as shown as "slavery" has gotta go! > It is your choice, in fact, but not much different than the choice a > chemically (3D) addicted person has over buying the chemical to the > local dealer. Then engineering firms are all addicts then. This is they type of "radical" non-sense I'm talking about! > You may get the appeasing visions, but in the end you'll eventually > suffer, and you seem to like enticing others to do it, which is > reprehensible. No I won't! I can switch to a Freedomware solution when *I* feel it's viable. nVidia is creating a libGL/GLX solution that offers value over what is available in open source. When I feel it no longer holds value over Open Source, I'm free to switch! From: "Sean" > Bryan, > I agree with much of what you said; forgive me for focusing on only the > things where we differ: I appreciate that. I'm not here advocating that "open standards" are _better_ than "open source." I'm just saying there is a balance sometimes. > People who understand the distinctions you draw, may still conclude that > their own best interest is served by focusing on open-source, and > rejecting the rest of your categories. This does not make them radical > or narrow minded. And I'm one of them. But when I see the "slavery" comments that are clearly based on Commerceware/Hostageware -- that _is_ radical! > But you're advocating for what others should do too! You're no different > than the people who are advocating for open source. You might think your > criteria is based on sounder reasoning, however we think ours is based on > even more sound reasoning ;o) My reasoning is choice. I have praised Red Hat for their choice and hope others follow. But don't go off the "radical deep end" when you do. You don't have to stretch the truth to get people to only use open source. But that's what I saw in the nVidia thread, hence why I entered it. Let's be _factual_. I'm not saying anything but _factual_. But some people still want to make it "absolutism" and that's _wrong_. > Yes. But other than the technical arguments against using binary-only > drivers, nobody is telling you what is best for you. But they are calling those who do a "slave." That's what I'm talking about. It's "us" or "them" and there's only 2-sides, 1-dimension -- non-sense! You either choose to pay for value, or you either help or wait on the community to increase its value. I agree, open source is best! That's why I call it "Freedomware." But sometimes I'm willing to use "Standardware" because it offers values while _not_ making me a slave to some proprietary standard. That's the bane of Commerceware and intentional Hostageware. _Huge_ difference. > Only what, in our opinion, is best for the advancement of open source. I'll take opinions. But what I will _not_ stand for is "guilting" like I'm seeing. That is just wrong, demonizing and is no better than some of the things Microsoft does. It's people "caught in the middle" that get expensed in this absolutism war of non-sense. > You're free to use whatever criteria you want in making your own choice. > That doesn't mean we should be silenced when suggesting to people that > they consider their choice in a broader context. Please do not lecture me on not being "silenced" given some of these comments made by others. Think about it. ;-> From: Rik van Riel > I've seen no evidence that software patents actually > promote innovation, and neither have the various > studies commissioned by a number of governments. > Also, I can't think of a single piece of software > that wouldn't have been invented if it weren't for > the existance of patents. Not a single one... And thus we have the epitome of the argument. ;-> From: seth vidal > I think that's b/c the driving force behind a lot of software creation > is 'boy, this would be cool'. The majority are evolutionary. A very few are innovative. The key is to only allow the very innovative details to be patented. Especially when research and other costs are involved. That was a major reason for the system, to recoup costs. From: Paul Iadonisi > And those who think otherwise seem to hold the view that direct > financial gain is the only thing that motivates anyone to produce any > ideas of worth. It's a cynical and bogus point of view. For every > programmer that insist on patenting his novel software ideas and won't > program otherwise, there are many, many who will come along and produce > what he wouldn't for the love of 'promoting the progress of science'. > Hmm, where have I heard that before. ;-) The key is when there is financial cost involved to innovate. The problem is that the current system fosters "patents on a dime." But that doesn't mean there aren't patents that don't require research. And those costs should be recouped. Again, some people are thinking of "worst case scenarios." I see the same thing when I see comments like "slavery." That seems to be the majority of thought. But no, the whole system should not be brought down. From: "Nicolas Mailhot" > Bogus because no real programmer will know or want to know how to deal > with patents, so they don't figure in his thinking. Wow! That's a nice, broad assertion! More "we know better than anyone else." > And people who know how to file patents have historically been more > interested in registering the obvious than new ideas (this part would > require lawyers and developpers to talk with each other, which is a > social impossibility) Then change the system to discourage that! I've already talked in length on peer review processes and other ways to limit these in many other posts and threads. The problem is that when you have a system that is not working, you don't just tear it down. You fix the problem. That seems to be a recuring trend in the US, possibly elsewhere. It's a radical viewpoint to think that the entire system is flawed when it worked very well before some people starting abusing it. -- Bryan J. Smith mailto:b.j.smith at ieee.org From rms at 1407.org Mon Jun 13 15:17:08 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Mon, 13 Jun 2005 16:17:08 +0100 Subject: OT: nVidia driver -- everything but open source is slavery? In-Reply-To: <14209149.1118675184713.JavaMail.root@wamui-norfolk.atl.sa.earthlink.net> References: <14209149.1118675184713.JavaMail.root@wamui-norfolk.atl.sa.earthlink.net> Message-ID: <1118675828.2790.13.camel@roque> On Mon, 2005-06-13 at 10:06 -0500, Bryan J. Smith wrote: > From: Rui Miguel Seabra > > Chosing slavery is not a freedom, it's waiving freedom. > > This is _exactly_ the type of non-sense I'm talking about! > By the same definition, you can call "working" as "slavery." Under a certain light yes, why should one _have_ to work for a living? I'd rather have time to program Free Software :) > Are you entitled to free drivers that are Open Source? I'm entitled to freedom. Signing my soul away isn't freedom, is accepting subjugation to power. > Either you pay ATI, Matrox, nVidia, etc... for their latest efforts. > Or you wait on the efforts of others in the community, possibly > helping them as well. I don't mind paying, I'm not talking about software obtained for gratis. Hell, I wouldn't mind paying another 100? for Free Software drivers for the GeForce2MX that I don't have anymore instead of having payed another 150? for an Ati Radeon 7500 that has Free Software drivers. > You are _not_ entitled to "free money" by not working anymore No. > than you are _not_ entitled to Open Source on every, latest > innovation. Everyone is entitled to freedom. Choosing convenience in spite of freedom is absurd, advocating this kind of choice is immoral. Rui -- + 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...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.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 symbiont at berlios.de Mon Jun 13 15:18:14 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Mon, 13 Jun 2005 23:18:14 +0800 Subject: Where is it ? :) In-Reply-To: <1118672572.19703.76.camel@cutter> References: <5cf776b80506130616d16ea9c@mail.gmail.com> <9f50a7a00506130720397e86e@mail.gmail.com> <1118672572.19703.76.camel@cutter> Message-ID: <200506132318.14534.symbiont@berlios.de> On Monday 13 June 2005 22:22, seth vidal wrote: > On Mon, 2005-06-13 at 09:20 -0500, Jerone Young wrote: > > http://torrent.linux.duke.edu/ > > Better yet - the 'official' link should be: > http://torrent.fedoraproject.org Kinda sucks to "help" when dl speed = 20 KB/s through torrent; but, a local ftp mirror = 150 KB/s. Can we use local ftp mirrors as distributed copies in bittorrent? I'm not all that conversant with the tool.. -- -jeff From sean.bruno at dsl-only.net Mon Jun 13 15:22:46 2005 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Mon, 13 Jun 2005 08:22:46 -0700 Subject: Where is it ? :) In-Reply-To: <200506132318.14534.symbiont@berlios.de> References: <5cf776b80506130616d16ea9c@mail.gmail.com> <9f50a7a00506130720397e86e@mail.gmail.com> <1118672572.19703.76.camel@cutter> <200506132318.14534.symbiont@berlios.de> Message-ID: <1118676167.3132.2.camel@home-lap> On Mon, 2005-06-13 at 23:18 +0800, Jeff Pitman wrote: > On Monday 13 June 2005 22:22, seth vidal wrote: > > On Mon, 2005-06-13 at 09:20 -0500, Jerone Young wrote: > > > http://torrent.linux.duke.edu/ > > > > Better yet - the 'official' link should be: > > http://torrent.fedoraproject.org > > Kinda sucks to "help" when dl speed = 20 KB/s through torrent; but, a > local ftp mirror = 150 KB/s. Can we use local ftp mirrors as > distributed copies in bittorrent? I'm not all that conversant with the > tool.. > > -- > -jeff > Not to be critical, but my DSL connection(1.544) is maxed out on these torrents. I am seeing close to 190KB/s coming down and I am uploading at close to 30KB/S to the torrent. Maybe you are not waiting long enough for the torrent to really get going? Sean From sopwith at redhat.com Mon Jun 13 15:25:39 2005 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 13 Jun 2005 11:25:39 -0400 (EDT) Subject: Where is it ? :) In-Reply-To: <200506132318.14534.symbiont@berlios.de> References: <5cf776b80506130616d16ea9c@mail.gmail.com> <9f50a7a00506130720397e86e@mail.gmail.com> <1118672572.19703.76.camel@cutter> <200506132318.14534.symbiont@berlios.de> Message-ID: On Mon, 13 Jun 2005, Jeff Pitman wrote: > On Monday 13 June 2005 22:22, seth vidal wrote: > > On Mon, 2005-06-13 at 09:20 -0500, Jerone Young wrote: > > > http://torrent.linux.duke.edu/ > > > > Better yet - the 'official' link should be: > > http://torrent.fedoraproject.org > > Kinda sucks to "help" when dl speed = 20 KB/s through torrent; but, a > local ftp mirror = 150 KB/s. Can we use local ftp mirrors as > distributed copies in bittorrent? I'm not all that conversant with the > tool.. The speed from the torrent goes up as you get farther into the download. It just requires patience. Best, -- Elliot You can accomplish anything you want, so long as you don't care who gets credit for it. From gmaxwell at gmail.com Mon Jun 13 15:30:35 2005 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Mon, 13 Jun 2005 11:30:35 -0400 Subject: Where is it ? :) In-Reply-To: <200506132318.14534.symbiont@berlios.de> References: <5cf776b80506130616d16ea9c@mail.gmail.com> <9f50a7a00506130720397e86e@mail.gmail.com> <1118672572.19703.76.camel@cutter> <200506132318.14534.symbiont@berlios.de> Message-ID: On 6/13/05, Jeff Pitman wrote: > Kinda sucks to "help" when dl speed = 20 KB/s through torrent; but, a > local ftp mirror = 150 KB/s. Can we use local ftp mirrors as > distributed copies in bittorrent? I'm not all that conversant with the > tool.. It will get faster if you have patience, eventually filling your pipe in many cases.. If you don't have patience, you can help by finishing the FTP download, stopping BT, copying the file you got via ftp on top of the file BT was writing and then start up bt again. You will now be a seed helping others. This even works with a partial FTP download. ... and it might even work to take a FC4-test3 DVD and put it in the same place, depending on how much has changed. :) From deisner at gmail.com Mon Jun 13 15:38:08 2005 From: deisner at gmail.com (David Eisner) Date: Mon, 13 Jun 2005 11:38:08 -0400 Subject: Where is it ? :) In-Reply-To: References: <5cf776b80506130616d16ea9c@mail.gmail.com> <9f50a7a00506130720397e86e@mail.gmail.com> <1118672572.19703.76.camel@cutter> <200506132318.14534.symbiont@berlios.de> Message-ID: <5ef8ba410506130838622dfacd@mail.gmail.com> On 6/13/05, Elliot Lee wrote: > The speed from the torrent goes up as you get farther into the > download. It just requires patience. Yep. Just downloaded all 5 images (~ 2.56 GB) in ~ 45 minutes, or roughly 1 MB/sec. Might have done better if I hadn't throttled the upstream (~300 kB/sec). -David From symbiont at berlios.de Mon Jun 13 15:43:49 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Mon, 13 Jun 2005 23:43:49 +0800 Subject: Where is it ? :) In-Reply-To: <1118676167.3132.2.camel@home-lap> References: <5cf776b80506130616d16ea9c@mail.gmail.com> <200506132318.14534.symbiont@berlios.de> <1118676167.3132.2.camel@home-lap> Message-ID: <200506132343.49374.symbiont@berlios.de> On Monday 13 June 2005 23:22, Sean Bruno wrote: > On Mon, 2005-06-13 at 23:18 +0800, Jeff Pitman wrote: > > Kinda sucks to "help" when dl speed = 20 KB/s through torrent; but, > > a local ftp mirror = 150 KB/s. ?Can we use local ftp mirrors as > > distributed copies in bittorrent? ?I'm not all that conversant with > > the tool.. > > Not to be critical, but my DSL connection(1.544) is maxed out on > these torrents. ?I am seeing close to 190KB/s coming down and I am > uploading at close to 30KB/S to the torrent. ?Maybe you are not > waiting long enough for the torrent to really get going? Been running for 33 minutes with an improvement of only 10KB/s since my last email. Does it need to go longer? (I have 8Mb DSL, should be around 500KB/s to max the line) MRTG shows bandwidth spikes on 1: http://symbiont.shacknet.nu/mrtg/ I feel like the pipe is saturated doing something. Not sure what. SSH is slower than dog going out (no QoS setup...). Ftp of unrelated file is down to 16KB/s. Technically, it shouldn't be. I'm noticing this on occasion: error(s):[23:26:33] Traceback (most recent call last): [23:42:55] Traceback (most recent call last): I think the kashmir module is tripping up on assertion where Node != NULL or something. I don't dare restart it at this point... It's still downloading!! -- -jeff From jdesbonnet at gmail.com Mon Jun 13 15:47:51 2005 From: jdesbonnet at gmail.com (Joe Desbonnet) Date: Mon, 13 Jun 2005 16:47:51 +0100 Subject: iso xdeltas FC4-test3 -> FC4 ? Message-ID: <1cef3e9505061308476ec9c7a2@mail.gmail.com> Has anyone got xdeltas patches that can be applied to the test3 release ISOs to make FC4? I suspect they should be quite small. Joe. From symbiont at berlios.de Mon Jun 13 15:58:49 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Mon, 13 Jun 2005 23:58:49 +0800 Subject: iso xdeltas FC4-test3 -> FC4 ? In-Reply-To: <1cef3e9505061308476ec9c7a2@mail.gmail.com> References: <1cef3e9505061308476ec9c7a2@mail.gmail.com> Message-ID: <200506132358.49272.symbiont@berlios.de> On Monday 13 June 2005 23:47, Joe Desbonnet wrote: > Has anyone got xdeltas patches that can be applied to the test3 > release ISOs to make FC4? I suspect they should be quite small. I would be happy to download these too! DVD download not happening in bt. Almost an hour now... gonna bail. -- -jeff From paul at city-fan.org Mon Jun 13 16:02:09 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 13 Jun 2005 17:02:09 +0100 Subject: Where is it ? :) In-Reply-To: <200506132343.49374.symbiont@berlios.de> References: <5cf776b80506130616d16ea9c@mail.gmail.com> <200506132318.14534.symbiont@berlios.de> <1118676167.3132.2.camel@home-lap> <200506132343.49374.symbiont@berlios.de> Message-ID: <42ADAE01.9030601@city-fan.org> Jeff Pitman wrote: > On Monday 13 June 2005 23:22, Sean Bruno wrote: > >>On Mon, 2005-06-13 at 23:18 +0800, Jeff Pitman wrote: >> >>>Kinda sucks to "help" when dl speed = 20 KB/s through torrent; but, >>>a local ftp mirror = 150 KB/s. Can we use local ftp mirrors as >>>distributed copies in bittorrent? I'm not all that conversant with >>>the tool.. >> >>Not to be critical, but my DSL connection(1.544) is maxed out on >>these torrents. I am seeing close to 190KB/s coming down and I am >>uploading at close to 30KB/S to the torrent. Maybe you are not >>waiting long enough for the torrent to really get going? > > > Been running for 33 minutes with an improvement of only 10KB/s since my > last email. Does it need to go longer? (I have 8Mb DSL, should be > around 500KB/s to max the line) > > MRTG shows bandwidth spikes on 1: > > http://symbiont.shacknet.nu/mrtg/ > > I feel like the pipe is saturated doing something. Not sure what. SSH > is slower than dog going out (no QoS setup...). Ftp of unrelated file > is down to 16KB/s. Technically, it shouldn't be. > > I'm noticing this on occasion: > > error(s):[23:26:33] Traceback (most recent call last): > [23:42:55] Traceback (most recent call last): > > I think the kashmir module is tripping up on assertion where Node != > NULL or something. I don't dare restart it at this point... It's > still downloading!! A restart may actually get you a different set of peers and better download speeds. I'd be inclined to try it myself. You'll not be starting the download again, and will just lose the "chunks" (usually 256K in size) that were in progress at the time you stopped. Someone on fedora-list is getting the tracebacks too. Which version of bittorrent are you using, and where did you get it? Paul. From mattdm at mattdm.org Mon Jun 13 16:03:25 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 13 Jun 2005 12:03:25 -0400 Subject: Where is it ? :) In-Reply-To: <200506132343.49374.symbiont@berlios.de> References: <5cf776b80506130616d16ea9c@mail.gmail.com> <200506132318.14534.symbiont@berlios.de> <1118676167.3132.2.camel@home-lap> <200506132343.49374.symbiont@berlios.de> Message-ID: <20050613160325.GA5808@jadzia.bu.edu> On Mon, Jun 13, 2005 at 11:43:49PM +0800, Jeff Pitman wrote: > Been running for 33 minutes with an improvement of only 10KB/s since my > last email. Does it need to go longer? (I have 8Mb DSL, should be > around 500KB/s to max the line) Are you behind a firewall/NAT box? > NULL or something. I don't dare restart it at this point... It's > still downloading!! If you kill it, it'll restart and keep what you've got. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 82 degrees Fahrenheit. From symbiont at berlios.de Mon Jun 13 16:21:43 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Tue, 14 Jun 2005 00:21:43 +0800 Subject: Where is it ? :) In-Reply-To: <20050613160325.GA5808@jadzia.bu.edu> References: <5cf776b80506130616d16ea9c@mail.gmail.com> <200506132343.49374.symbiont@berlios.de> <20050613160325.GA5808@jadzia.bu.edu> Message-ID: <200506140021.44187.symbiont@berlios.de> On Tuesday 14 June 2005 00:03, Matthew Miller wrote: > On Mon, Jun 13, 2005 at 11:43:49PM +0800, Jeff Pitman wrote: > > Been running for 33 minutes with an improvement of only 10KB/s > > since my last email. ?Does it need to go longer? ?(I have 8Mb DSL, > > should be around 500KB/s to max the line) > > Are you behind a firewall/NAT box? > > Ports opened long ago. > > NULL or something. ?I don't dare restart it at this point... ?It's > > still downloading!! > > If you kill it, it'll restart and keep what you've got. I know. 200KB/s from a local mirror is too good to pass up. Maybe I'll just seed the torrent and let it run over night (which is the day time for you guys.) -- -jeff From j.w.r.degoede at hhs.nl Mon Jun 13 16:24:40 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 13 Jun 2005 18:24:40 +0200 Subject: Bad (obsolete) PR/advertisement on fedora website Message-ID: <42ADB348.6030401@hhs.nl> Hi all, I just saw the (great) FC4 announcement / pressrelease on lwn.net. Amongst other things it states: --- One of Fedora Core's main objectives is to serve the needs of community developers, testers, and other technology enthusiasts who wish to participate in and accelerate the technology development process. But you know what? We aren't exclusive. We want you involved, too, whoever you are: http://fedora.redhat.com/participate You might surprise yourself. --- But that webpage is so outdated, it mentions that in the future we will have CVS, but for now all you can really do is file bugs. While Extras is up and running fine except for anaconda & friends intergration. This page (and the whole of fedora.redhat.com) really need updating. We want more volunteers don't we? Regards, Hans From symbiont at berlios.de Mon Jun 13 16:24:06 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Tue, 14 Jun 2005 00:24:06 +0800 Subject: Where is it ? :) In-Reply-To: <42ADAE01.9030601@city-fan.org> References: <5cf776b80506130616d16ea9c@mail.gmail.com> <200506132343.49374.symbiont@berlios.de> <42ADAE01.9030601@city-fan.org> Message-ID: <200506140024.06444.symbiont@berlios.de> On Tuesday 14 June 2005 00:02, Paul Howarth wrote: > Someone on fedora-list is getting the tracebacks too. Which version > of bittorrent are you using, and where did you get it? [jeff at symbiont ~]$ rpm -q python-khashmir python-khashmir-4.1.1-2.1.fc3.rf [jeff at symbiont ~]$ rpm -q bittorrent bittorrent-4.1.1-2.1.fc3.rf Rpmforge aka dag. -- -jeff From sundaram at redhat.com Mon Jun 13 16:28:35 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 13 Jun 2005 21:58:35 +0530 Subject: Bad (obsolete) PR/advertisement on fedora website In-Reply-To: <42ADB348.6030401@hhs.nl> References: <42ADB348.6030401@hhs.nl> Message-ID: <42ADB433.2080203@redhat.com> Hi > > But that webpage is so outdated, it mentions that in the future we > will have CVS, but for now all you can really do is file bugs. > > While Extras is up and running fine except for anaconda & friends > intergration. > > This page (and the whole of fedora.redhat.com) really need updating. > We want more volunteers don't we? > > Regards, > > Hans Yes. There is a need for volunteers to revamp the website design and content too ;-) regards Rahul From paul at city-fan.org Mon Jun 13 16:30:24 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 13 Jun 2005 17:30:24 +0100 Subject: Where is it ? :) In-Reply-To: <200506140024.06444.symbiont@berlios.de> References: <5cf776b80506130616d16ea9c@mail.gmail.com> <200506132343.49374.symbiont@berlios.de> <42ADAE01.9030601@city-fan.org> <200506140024.06444.symbiont@berlios.de> Message-ID: <42ADB4A0.8020709@city-fan.org> Jeff Pitman wrote: > On Tuesday 14 June 2005 00:02, Paul Howarth wrote: > >>Someone on fedora-list is getting the tracebacks too. Which version >>of bittorrent are you using, and where did you get it? > > > [jeff at symbiont ~]$ rpm -q python-khashmir > python-khashmir-4.1.1-2.1.fc3.rf > [jeff at symbiont ~]$ rpm -q bittorrent > bittorrent-4.1.1-2.1.fc3.rf > > Rpmforge aka dag. I have an FC3 package of BitTorrent 4.1.2 at http://www.city-fan.org/ftp/contrib/bittorrent/ which *may* address this issue (I don't know if this is one of the "many" bugs fixed upstream). My packages don't split out python-khashmir so you may need to rpm -e that package if you try mine. I'd be interested to know if this fixed the problem. Paul. From alan at redhat.com Mon Jun 13 16:04:20 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 13 Jun 2005 12:04:20 -0400 Subject: Where is it ? :) In-Reply-To: <200506132318.14534.symbiont@berlios.de> References: <5cf776b80506130616d16ea9c@mail.gmail.com> <9f50a7a00506130720397e86e@mail.gmail.com> <1118672572.19703.76.camel@cutter> <200506132318.14534.symbiont@berlios.de> Message-ID: <20050613160420.GA27310@devserv.devel.redhat.com> On Mon, Jun 13, 2005 at 11:18:14PM +0800, Jeff Pitman wrote: > Kinda sucks to "help" when dl speed = 20 KB/s through torrent; but, a > local ftp mirror = 150 KB/s. Can we use local ftp mirrors as > distributed copies in bittorrent? I'm not all that conversant with the > tool.. If you are an ftp mirror owner then yes, you can join the torrent giving the copy you already have and you'll become an uploader only. Alan From notting at redhat.com Mon Jun 13 16:43:28 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 13 Jun 2005 12:43:28 -0400 Subject: rawhide report: 20050610 changes In-Reply-To: <1118665132.3459.0.camel@localhost.localdomain> References: <200506101142.j5ABgAA1000595@porkchop.devel.redhat.com> <1118665132.3459.0.camel@localhost.localdomain> Message-ID: <20050613164328.GK19700@nostromo.devel.redhat.com> Rodd Clarkson (rodd at clarkson.id.au) said: > > kernel-2.6.11-1.1381_FC5 > > ------------------------ > > * Thu Jun 09 2005 Dave Jones > > - 2.6.12-rc6-git3 > > - Temporarily disable the ipw drivers until I sort them out. > > What's up with these drivers? What's to sort out? Broke with the gcc in the FC5 tree. Bill From b.j.smith at ieee.org Mon Jun 13 16:49:44 2005 From: b.j.smith at ieee.org (Bryan J. Smith) Date: Mon, 13 Jun 2005 11:49:44 -0500 Subject: OT: nVidia driver -- everything but open source is slavery? Message-ID: <1118681384.4422.11.camel@bert64.mobile.smithconcepts.com> Rui Miguel Seabra wrote: > Under a certain light yes, why should one _have_ to work for a living? > I'd rather have time to program Free Software :) But it is still work -- it is an effort that produces something. Whether you pay for it or work to create it, it's the same balance. Freedom isn't free, you pay for it differently than in another way. > I'm entitled to freedom. Signing my soul away isn't freedom, is > accepting subjugation to power. Here we go again, the absolutisms ... "signing my soul away" I am waiting *1* person to tell me how I'm signing my soul away by using _open_standard_ drivers with an example other than their past experience with _proprietary_standard_ drivers which is wholly inapplicable. The problem is that by not differentiating, you are making it a 2-choice, 1-dimension issue which it is not. > I don't mind paying, I'm not talking about software obtained for gratis. > Hell, I wouldn't mind paying another 100? for Free Software drivers for > the GeForce2MX that I don't have anymore instead of having payed another > 150? for an Ati Radeon 7500 that has Free Software drivers. But once you have them, there there go be no restriction on your distribution. Basic economies. Free Software drivers wouldn't cost the same "per unit" cost, but "per open license." I.e., instead of $100 distributed amongst 10,000 people, it's a _flat_ $1M! This basic fact of microeconomics seems to elude so many people in the open source world. Of all people, I would assume those on Red Hat's list would understand the difficulty in competing in an industry where you have to compete with a competitors per-unit cost of ~$100, in volumes of the millions when you don't sell even 1/100th of that. ;-ppp > Everyone is entitled to freedom. Choosing convenience in spite of > freedom is absurd, advocating this kind of choice is immoral. What is one man's convenience is another man's necessity. Who are you to dictate what you see as a convenience but others is a necessity as an "immoral" choice to make? That is the kind of non-sense that leads right down to "force community" and radical ideas. Choice, based on _individual_ perspective. You can_not_ assert what is better for someone else -- that is very, very, very _dangerous_! Now I've shown that my so-called "immoral" selection is _not_ slavery because I am deploying an open _standard_ solution that can be replaced by an open _source_ solution if the former option is no longer available. What you view as "convenience" others view as "necessity," and some would have gone to Windows Hostageware had it not been for nVidia's Standardware (libGL/GLX) solution on Linux. Furthermore, I'm still waiting for *1* example of how I am "enslaved" by temporarily choosing an open _standards_ solution in lieu of a feasible open _source_ solution. No more _proprietary_standard_ examples, I would like to see some _real_ examples. Otherwise, I think I've made my point enough. I became active again on this list to work on the init for FC5, not get into this mess. -- Bryan J. Smith b.j.smith at ieee.org --------------------------------------------------------------------- It is mathematically impossible for someone who makes more than you to be anything but richer than you. Any tax rate that penalizes them will also penalize you similarly (to those below you, and then below them). Linear algebra, let alone differential calculus or even ele- mentary concepts of limits, is mutually exclusive with US journalism. So forget even attempting to explain how tax cuts work. ;-> From mjc at redhat.com Mon Jun 13 16:50:12 2005 From: mjc at redhat.com (Mark J Cox) Date: Mon, 13 Jun 2005 17:50:12 +0100 (BST) Subject: Summary of FC4 vulnerabilities Message-ID: <0506131749340.10509@dell1.moose.awe.com> Quick Summary: For 20030101-20050607 there are a potential 863 CVE named vulnerabilities that could have affected FC4 packages. 759 (88%) of those are fixed because FC4 includes an upstream version that includes a fix, 10 (1%) are still outstanding, and 94 (11%) are fixed with a backported patch. Method: Near the release time of each new distribution the Red Hat security team go through the packages to ensure that everything is up to date with security patches. The method used changed slightly from previous releases, this time for completeness: 1. we went through each CVE name for 2003, 2004, and 2005 (up to date as of 20050612) ignoring those that didn't affect Linux or were in packages not in FC4. 2. Then for each CVE issue left we look to see which upstream version (if any) the vulnerability is fixed in. Sometimes the CVE data gives us this information, but many times it doesn't or it's wrong and we have to investigate for ourselves which upstream verisons fix the issues (and we've reported our many investigations to Mitre for updates to the CVE entries). If we write "at least" we mean that we looked inside the source for that version and checked to see if the fix existed, but it may well have been fixed upstream prior to that version. 3. Where FC4 contains a upstream version greater or equal to the upstream version containing a fix, we mark it as not vulnerable due to "version". 4. Remaining CVE names are checked to see if FC4 contains a backported patch in the package. We trust changelog entries (since these will have already been audited us by use when FC3/2/1 or a RHEL advisory came out). 5. For anything that looked like it wasn't fixed we talked to the package owner to get a fix into FC4 final So this table gives the CVE name, the reason why FC4 isn't vulnerable and optional comments showing the package name, version it was fixed in, or method used to verify the details. This is based on FC4 gold. Corrections or missed issues (ones showing in CVE) appreciated to secalert at redhat.com. We'll keep this up to date - probably on the wiki or somewhere. [content chopped; just over 40kb limit. Full message at http://people.redhat.com/mjc/20050505-fc4 ] From sundaram at redhat.com Mon Jun 13 17:01:57 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 13 Jun 2005 22:31:57 +0530 Subject: Summary of FC4 vulnerabilities In-Reply-To: <0506131749340.10509@dell1.moose.awe.com> References: <0506131749340.10509@dell1.moose.awe.com> Message-ID: <42ADBC05.10504@redhat.com> Mark J Cox wrote: > Quick Summary: > > For 20030101-20050607 there are a potential 863 CVE named > vulnerabilities that could have affected FC4 packages. 759 (88%) of > those are fixed because FC4 includes an upstream version that includes > a fix, 10 (1%) are still outstanding, and 94 (11%) are fixed with a > backported patch. This is very good amount of details. I have created a wiki page with this information at http://fedoraproject.org/wiki/securitystatus. Regards Rahul From fedora at camperquake.de Mon Jun 13 17:19:05 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 13 Jun 2005 19:19:05 +0200 Subject: iso xdeltas FC4-test3 -> FC4 ? In-Reply-To: <1cef3e9505061308476ec9c7a2@mail.gmail.com> References: <1cef3e9505061308476ec9c7a2@mail.gmail.com> Message-ID: <20050613191905.525e72da@nausicaa.camperquake.de> Hi. Joe Desbonnet wrote: > Has anyone got xdeltas patches that can be applied to the test3 > release ISOs to make FC4? I suspect they should be quite small. More importantly (IMVHO): has someone got a script to create the DVD image from the CD images (or vice versa)? -- "Stuff happened. It was cool." Mike, MST3k, "A Black Day" Misting From rms at 1407.org Mon Jun 13 18:00:36 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Mon, 13 Jun 2005 19:00:36 +0100 Subject: OT: nVidia driver -- everything but open source is slavery? In-Reply-To: <1118681384.4422.11.camel@bert64.mobile.smithconcepts.com> References: <1118681384.4422.11.camel@bert64.mobile.smithconcepts.com> Message-ID: <1118685636.2790.15.camel@roque> On Mon, 2005-06-13 at 11:49 -0500, Bryan J. Smith wrote: > Choice, based on _individual_ perspective. You can_not_ assert what is > better for someone else -- that is very, very, very _dangerous_! Apparently you can, though. 'nuff said. Rui -- + 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...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.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 Nicolas.Mailhot at laPoste.net Mon Jun 13 19:09:49 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 13 Jun 2005 21:09:49 +0200 Subject: OT: nVidia driver -- everything but open source is slavery? In-Reply-To: <14209149.1118675184713.JavaMail.root@wamui-norfolk.atl.sa.earthlink.net> References: <14209149.1118675184713.JavaMail.root@wamui-norfolk.atl.sa.earthlink.net> Message-ID: <1118689790.30331.9.camel@rousalka.dyndns.org> Le lundi 13 juin 2005 ? 10:06 -0500, Bryan J. Smith a ?crit : > From: "Nicolas Mailhot" > > Bogus because no real programmer will know or want to know how to > deal > > with patents, so they don't figure in his thinking. > > Wow! That's a nice, broad assertion! > More "we know better than anyone else." Like you perhaps ? In every single pro-software-patent conference I've been to or read about the speaker was an IT lawyer. The problem is - IT lawyers do not write any software code. If they did they wouldn't have any time for law. Anyway I don't see how antagonising as many people on the list as possible is going to help your cause. -- Nicolas Mailhot -------------- 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 mikem at cyber.com.au Mon Jun 13 18:41:35 2005 From: mikem at cyber.com.au (Mike MacCana) Date: Tue, 14 Jun 2005 04:41:35 +1000 Subject: FC5 announcement should use UTC In-Reply-To: <1118669859.4908.35.camel@tameshk.bamdad.org> References: <5cf776b80506130616d16ea9c@mail.gmail.com> <1118668731.19703.65.camel@cutter> <1118669859.4908.35.camel@tameshk.bamdad.org> Message-ID: <42ADD35F.1020904@cyber.com.au> Roozbeh Pournader wrote: >On Mon, 2005-06-13 at 09:18 -0400, seth vidal wrote: > > >>On Mon, 2005-06-13 at 09:16 -0400, mbneto wrote: >> >> >>>Are we going to see fc4 today ? >>> >>>I've been checking slashdot/freshmeat/fedora.redhat.com and no sign of it. >>> >>> >>10am EST - read the webpage. >> >> > >Ah, it should be EDT, I guess. And giving times in term of UTC would >always be better. > > I looked at 10AM EST and it wasn't there. Oh, you didn't mean Australian EST? Spent a bit of time Googling on timezones. There's about two or three definitions of 'EST' and 'EDT' in the US alone. Mike From thebs413 at earthlink.net Mon Jun 13 19:14:45 2005 From: thebs413 at earthlink.net (Bryan J. Smith ) Date: Mon, 13 Jun 2005 14:14:45 -0500 (GMT-05:00) Subject: OT: nVidia driver -- everything but open source is slavery? Message-ID: <28366653.1118690086197.JavaMail.root@wamui-muscovy.atl.sa.earthlink.net> From: Nicolas Mailhot > Like you perhaps ? > In every single pro-software-patent conference I've been to or read > about the speaker was an IT lawyer. > The problem is - IT lawyers do not write any software code. If they did > they wouldn't have any time for law. > Anyway I don't see how antagonising as many people on the list as > possible is going to help your cause. What "cause"? The "cause" that sometimes people have the right to choose? That people do have the right to innovate and be granted patents? As much as I believe in the open source philosophy, and as much as I believe in companies should share their IP, especially the more commodity it is, the reality is that it _must_ be done by "choice." If that's a "radical" idea, then I'm guilty! The "cause" I've seen here by _some_ (not all) is that anything but open source is slavery, immoral or otherwise something that's _never_ an option and people should _not_ have the choice, especially considering that all original thought with regards to software is always commodity and belongs to the world. -- Bryan J. Smith mailto:b.j.smith at ieee.org From pri.rhl4 at iadonisi.to Mon Jun 13 19:25:43 2005 From: pri.rhl4 at iadonisi.to (Paul Iadonisi) Date: Mon, 13 Jun 2005 15:25:43 -0400 Subject: OT: nVidia driver -- everything but open source is slavery? In-Reply-To: <28366653.1118690086197.JavaMail.root@wamui-muscovy.atl.sa.earthlink.net> References: <28366653.1118690086197.JavaMail.root@wamui-muscovy.atl.sa.earthlink.net> Message-ID: <1118690743.11263.9.camel@gitssac.rdu.redhat.com> On Mon, 2005-06-13 at 14:14 -0500, Bryan J. Smith wrote: [snip] > What "cause"? > > The "cause" that sometimes people have the right to choose? > That people do have the right to innovate and be granted patents? The last half of that second sentence is where I don't think you are going to find much support on this list for. And do not be so arrogant as to assume that those of us who disagree with you on this point have not, in fact, looked at all sides of the argument. We've just come to a different conclusion than you. You've posted your points, and I don't think continuing to reiterated them is going to win over many, if *any* people on this list. At the risk of being accused of trying to 'silence' you, I'm now politely asking that you take this discussion elsewhere...privately if anyone is willing to exchange email with you on the topic. We've wasted enough bandwidth on this already. -- -Paul Iadonisi System Administrator IV Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From thebs413 at earthlink.net Mon Jun 13 20:34:29 2005 From: thebs413 at earthlink.net (Bryan J. Smith ) Date: Mon, 13 Jun 2005 15:34:29 -0500 (GMT-05:00) Subject: OT: nVidia driver -- everything but open source is slavery? Message-ID: <30889292.1118694870370.JavaMail.root@wamui-lapwing.atl.sa.earthlink.net> Paul Iadonisi wrote: > The last half of that second sentence is where I don't think you are > going to find much support on this list for. What, did Microsoft say it or something like it? ;-ppp In hindsight, I probably should have phrased it differently. In a nutshell, I think we agree to disagree between: - People who think developers never want/need to register software patents because there are no innovative ideas left or they shouldn't be anything but disclosed freely (or some variation) - People that think most software patents are common ideas, but believe the answer is a much more strict process of granting patents to those companies that are actually out money to develop new ideas to remove the current "patent on a dime" non-sense. Ultimate the most community-centric approach is to just try to get companies to work together in a common patent pool, which removes the legislative issues altogether. Furthermore, I think I've made my other point that there is a difference between: - open standards - proprietary standards And that not all open standard, but proprietary source is necessarily bad, although typically no where near idea as open soruce. But in the end, we should all have the right to choose, based on what our needs are which may or may not simply be "convenience" but other, critical factors. Lastly, there are the economical factors of not comparing flat open licensing where everyone has the right to redistribute to per-node costs which are not a license to redistribute. > And do not be so arrogant as to assume that those of us who > disagree with you on this point have not, in fact, looked at all sides > of the argument. If it's more than the simple 2 I've seen from some, then yes, I agree. I will concede some people see some things my way, and that everything else is just opinions upon opinions. > We've just come to a different conclusion than you. As long we agree that people can use the nVidia driver, as long as they understand they are "on their own," then I think they can decide the pros/cons for themselves. I would love to see many things GPL'd, but the reality is that it's probably not going to happen for some time. I just wanted to correct some false statements, I guess I took it too far. > You've posted your points, and I don't think continuing to reiterated > them is going to win over many, if *any* people on this list. > At the risk of being accused of trying to 'silence' you, I'm now > politely asking that you take this discussion elsewhere...privately if > anyone is willing to exchange email with you on the topic. We've wasted > enough bandwidth on this already. If anyone still disagrees with my summary above, please contact me off-list. I won't post again on-list, even if someone else responds on-list. Now, who's working on the init for FC5? I've started going through DBUS. -- Bryan J. Smith mailto:b.j.smith at ieee.org From shiva at sewingwitch.com Mon Jun 13 20:48:03 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Mon, 13 Jun 2005 13:48:03 -0700 Subject: Website: CSS file missing In-Reply-To: References: Message-ID: <31100A881CAE8BE80832FD31@[10.0.0.14]> --On Sunday, June 12, 2005 9:02 AM +0200 Aurelien Bompard wrote: > It looks like the CSS file is missing for the custom 404 page at > download.fedora.redhat.com : > http://download.fedora.redhat.com/something_that_doesnt_exist In case the webmaster misses it, you can file a bugzilla against the product "Red Hat Web Site": From notting at redhat.com Mon Jun 13 20:51:55 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 13 Jun 2005 16:51:55 -0400 Subject: Website: CSS file missing In-Reply-To: <31100A881CAE8BE80832FD31@[10.0.0.14]> References: <31100A881CAE8BE80832FD31@[10.0.0.14]> Message-ID: <20050613205155.GA23188@nostromo.devel.redhat.com> Kenneth Porter (shiva at sewingwitch.com) said: > --On Sunday, June 12, 2005 9:02 AM +0200 Aurelien Bompard > wrote: > > >It looks like the CSS file is missing for the custom 404 page at > >download.fedora.redhat.com : > >http://download.fedora.redhat.com/something_that_doesnt_exist > > In case the webmaster misses it, you can file a bugzilla against the > product "Red Hat Web Site": > > Please, do 'Fedora Infrastructure', component 'website' instead. Bill From mfioretti at mclink.it Mon Jun 13 21:45:33 2005 From: mfioretti at mclink.it (M. Fioretti) Date: Mon, 13 Jun 2005 23:45:33 +0200 Subject: Updated RULE installer for FC3 Message-ID: <20050613214533.GH3464@mclink.it> Greetings, due to several problems with the server LAMP setup, the RULE website is *NOT* accessible these days. However, thanks to F. Zahaurek, there is a new version of the slinky installer for FC3. The main characteristics are explained here: http://www.fzk.at/SLINKY/ but please download all the corresponding files from this folder, to not overload Franz's server: http://www.rule-project.org/download/fedora_core_3/slinky/slinky-v0.5.01 Any feedback is welcome. Ciao, Marco F. -- Marco Fioretti mfioretti, at the server mclink.it Fedora Core 3 for low memory http://www.rule-project.org/ If development calls for an ever-growing number of technical experts, even more necessary still is the deep thought and reflection of wise men in search of a new humanism, one which will enable our contemporaries to enjoy the higher values of love and friendship... Paul VI, POPULORUM PROGRESSIO From mbneto at gmail.com Mon Jun 13 21:53:27 2005 From: mbneto at gmail.com (mbneto) Date: Mon, 13 Jun 2005 17:53:27 -0400 Subject: Where is it ? :) In-Reply-To: <20050613160420.GA27310@devserv.devel.redhat.com> References: <5cf776b80506130616d16ea9c@mail.gmail.com> <9f50a7a00506130720397e86e@mail.gmail.com> <1118672572.19703.76.camel@cutter> <200506132318.14534.symbiont@berlios.de> <20050613160420.GA27310@devserv.devel.redhat.com> Message-ID: <5cf776b8050613145313c8d6a7@mail.gmail.com> I am getting errors. Is there a problem with the torrent/the tracks/my machine ? ror(s):[17:52:35] Tracker announce still not complete 119 seconds after starting it | | [17:53:35] Tracker announce still not complete 179 seconds after starting it | | [17:53:44] Problem connecting to tracker - | | [17:55:35] Tracker announce still not complete 60 seconds after starting it | | [17:56:35] Tracker announce still not complete 120 seconds after starting it | | [17:57:35] Tracker announce still not complete 180 seconds after starting it | | [17:57:44] Problem connecting to tracker - From skvidal at phy.duke.edu Mon Jun 13 22:06:33 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 13 Jun 2005 18:06:33 -0400 Subject: Where is it ? :) In-Reply-To: <5cf776b8050613145313c8d6a7@mail.gmail.com> References: <5cf776b80506130616d16ea9c@mail.gmail.com> <9f50a7a00506130720397e86e@mail.gmail.com> <1118672572.19703.76.camel@cutter> <200506132318.14534.symbiont@berlios.de> <20050613160420.GA27310@devserv.devel.redhat.com> <5cf776b8050613145313c8d6a7@mail.gmail.com> Message-ID: <1118700393.24314.26.camel@cutter> On Mon, 2005-06-13 at 17:53 -0400, mbneto wrote: > I am getting errors. Is there a problem with the torrent/the > tracks/my machine ? > almost 8000 people downloading. So no, I don't think there's anything wrong. -sv From rjune at bravegnuworld.com Mon Jun 13 22:13:18 2005 From: rjune at bravegnuworld.com (Richard June) Date: Mon, 13 Jun 2005 17:13:18 -0500 Subject: Where is it ? :) In-Reply-To: <20050613133634.GA31210@jadzia.bu.edu> References: <5cf776b80506130616d16ea9c@mail.gmail.com> <1118668731.19703.65.camel@cutter> <20050613133634.GA31210@jadzia.bu.edu> Message-ID: <200506131713.20634.rjune@bravegnuworld.com> On Monday 13 June 2005 08:36, Matthew Miller wrote: > On Mon, Jun 13, 2005 at 09:18:50AM -0400, seth vidal wrote: > > > Are we going to see fc4 today ? > > > I've been checking slashdot/freshmeat/fedora.redhat.com and no sign of > > > it. > > > > 10am EST - read the webpage. > > ^ > D Unfortunately our new dumbass governer wants us to go to daylight savings -- Public Key available Here: http://www.bravegnuworld.com/~rjune/pubkey.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pp at ee.oulu.fi Mon Jun 13 23:26:13 2005 From: pp at ee.oulu.fi (Pekka Pietikainen) Date: Tue, 14 Jun 2005 02:26:13 +0300 Subject: gnome-vfs not in Rawhide? In-Reply-To: <42A93A6A.6040501@redhat.com> References: <20050407132815.15244.qmail@web8504.mail.in.yahoo.com> <42A93A6A.6040501@redhat.com> Message-ID: <20050613232613.GA18792@ee.oulu.fi> On Fri, Jun 10, 2005 at 08:59:54AM +0200, Harald Hoyer wrote: > Let me show you what "could" be done for the desktop user, who cannot > read terminal output, as he does not use a terminal: > > A small helper app listens on the user's session DBUS for such a message > and presents a gui dialog to the user stating: "Application foo needs > the library bar to run.". It can offer the user to search the rpmdb and > the internet repos for this file and, if found, to install the > appropriate rpm package with all its dependencies. Some friendly soul could also start packaging these and putting them in a yum repo :-) Probably not in the charter of extras, though. You definately don't want to make all this old stuff compile on gcc4, you'll go mad doing that, but some kind of "Works/doesn't conflict with anything in FC4" badge for the rpms would still be nice to have. Easiest way is probably doing nosrc.rpm's what contain some old RH7.3/9/whatnot era library rpm as the source, then extract only the library bits and don't include the conflicting bits that aren't necessary for running apps. With a pointer to the original source, of course. Acceptable trade-off, as one will only need this to run old proprietary crap anyway :-). (Or with FC5 open source code that nobody has fixed to work with NPTL *cough* vdr *cough*) But yea, there's definately a need for a collection of compatibility libraries. The other day I had to run something with a gtk-- 1.2 dependancy. Freshrpms had a rpm for RH9, which worked just fine with FC4 (the software I wanted to run didn't do anything useful, as I had wished, tho :-( ) At some point it's just easier to run an ancient distro in a sandbox making sure it's totally isolated from the outside world so updates aren't that critical. -- Pekka Pietikainen From webmaster at margo.bijoux.nom.br Tue Jun 14 00:14:40 2005 From: webmaster at margo.bijoux.nom.br (Pedro Fernandes Macedo) Date: Mon, 13 Jun 2005 21:14:40 -0300 Subject: iso xdeltas FC4-test3 -> FC4 ? In-Reply-To: <20050613191905.525e72da@nausicaa.camperquake.de> References: <1cef3e9505061308476ec9c7a2@mail.gmail.com> <20050613191905.525e72da@nausicaa.camperquake.de> Message-ID: <42AE2170.6010101@margo.bijoux.nom.br> Ralf Ertzinger wrote: >More importantly (IMVHO): has someone got a script to create the >DVD image from the CD images (or vice versa)? > > > I'm working on making a set of jigdo files , to allow making a DVD/CD from whatever source you have.. I've succesfully made the first jigdo file for the x86_64 dvd (the .jigdo and the .template files were less than 100KB) and the other files will probably be ready tomorrow (right now , I'm using my university connection to download the remaining isos from torrent.. putting that big pipe to a good use ;) ) -- Pedro Macedo From symbiont at berlios.de Tue Jun 14 01:17:42 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Tue, 14 Jun 2005 09:17:42 +0800 Subject: Where is it ? :) In-Reply-To: <42ADB4A0.8020709@city-fan.org> References: <5cf776b80506130616d16ea9c@mail.gmail.com> <200506140024.06444.symbiont@berlios.de> <42ADB4A0.8020709@city-fan.org> Message-ID: <200506140917.42600.symbiont@berlios.de> On Tuesday 14 June 2005 00:30, Paul Howarth wrote: > I'd be interested to know if this fixed > the problem. It appears to have fixed it. I'm not getting the traceback any more. thanks, -- -jeff From florin at andrei.myip.org Tue Jun 14 02:02:59 2005 From: florin at andrei.myip.org (Florin Andrei) Date: Mon, 13 Jun 2005 19:02:59 -0700 Subject: bad practice: services that are automatically re-enabled Message-ID: <1118714579.6098.18.camel@rivendell.home.local> Something that absolutely needs to be fixed in future FC versions is services that "misteriously" re-enable themselves. I'm sure it happened to everyone, so my story is surely not news. I install a fresh system, remove unnecessary packages, disable services that are not used at the moment but will be used after a while. All is good and the system is doing exactly what's supposed to do. But when I verify with chkconfig the list of enabled services a few weeks after that... surprise! Many services somehow managed to re-enable themselves! I suspect there are two causes: 1. When updating certain packages, the service will mark itself enabled, regardless of the current status. That is disgusting. This practice must stop immediately. 2. I think there are certain weekly or monthly crontabs or something like that that have a nasty habit of thinking themselves smarter than the sysadmin and make their own decisions of re-enabling services that were knowingly disabled by the aforementioned sysadmin. This sneaky, surreptitious, nasty habit must disappear. Any script, any piece of software, whatever, should not blindingly re- enable services. The current status of the service (enabled / disabled) should be checked and the script/software/whatever should not change it. This goes for the Fedora Core components proper, the Extras, and all the other independent repositories as well. There should be some guidelines or a policy for building RPM packages that contain system services, or daemons, whatever, with regard to actions taken during install, update and periodic cron jobs - all things that might change the enabled/disabled status of a service. Anyway, I will be very happy to follow said policy, since myself I'm guilty of building RPM packages that do stupid things with chkconfig. I hereby repent and publicly admit my sinful ways, and I ask everyone to work together and come up with a clear, better way of dealing with this class of problems. Otherwise... you know, software that thinks itself smarter than its users - that's so Microsoft. -- Florin Andrei http://florin.myip.org/ From skvidal at phy.duke.edu Tue Jun 14 02:09:02 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 13 Jun 2005 22:09:02 -0400 Subject: bad practice: services that are automatically re-enabled In-Reply-To: <1118714579.6098.18.camel@rivendell.home.local> References: <1118714579.6098.18.camel@rivendell.home.local> Message-ID: <1118714942.28155.10.camel@cutter> On Mon, 2005-06-13 at 19:02 -0700, Florin Andrei wrote: > Something that absolutely needs to be fixed in future FC versions is > services that "misteriously" re-enable themselves. > > Anyway, I will be very happy to follow said policy, since myself I'm > guilty of building RPM packages that do stupid things with chkconfig. I > hereby repent and publicly admit my sinful ways, and I ask everyone to > work together and come up with a clear, better way of dealing with this > class of problems. > Otherwise... you know, software that thinks itself smarter than its > users - that's so Microsoft. could you make a list of the ones you find and file bugs? otherwise we might not know it's causing a problem. thanks -sv From notting at redhat.com Tue Jun 14 02:08:19 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 13 Jun 2005 22:08:19 -0400 Subject: bad practice: services that are automatically re-enabled In-Reply-To: <1118714579.6098.18.camel@rivendell.home.local> References: <1118714579.6098.18.camel@rivendell.home.local> Message-ID: <20050614020819.GA1449@nostromo.devel.redhat.com> Florin Andrei (florin at andrei.myip.org) said: > Something that absolutely needs to be fixed in future FC versions is > services that "misteriously" re-enable themselves. > > I'm sure it happened to everyone, so my story is surely not news. > I install a fresh system, remove unnecessary packages, disable services > that are not used at the moment but will be used after a while. All is > good and the system is doing exactly what's supposed to do. > But when I verify with chkconfig the list of enabled services a few > weeks after that... surprise! Many services somehow managed to re-enable > themselves! Did you run: chkconfig --del (wrong) or chkconfig --level (right) ? What services in particular? Bill From mattdm at mattdm.org Tue Jun 14 02:16:26 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 13 Jun 2005 22:16:26 -0400 Subject: bad practice: services that are automatically re-enabled In-Reply-To: <20050614020819.GA1449@nostromo.devel.redhat.com> References: <1118714579.6098.18.camel@rivendell.home.local> <20050614020819.GA1449@nostromo.devel.redhat.com> Message-ID: <20050614021626.GA28450@jadzia.bu.edu> On Mon, Jun 13, 2005 at 10:08:19PM -0400, Bill Nottingham wrote: > Did you run: > chkconfig --del (wrong) > or > chkconfig --level (right) > ? chkconfig off is also right, right? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 81 degrees Fahrenheit. From thacker at math.cornell.edu Tue Jun 14 02:20:24 2005 From: thacker at math.cornell.edu (John Thacker) Date: Mon, 13 Jun 2005 22:20:24 -0400 Subject: bad practice: services that are automatically re-enabled In-Reply-To: <20050614020819.GA1449@nostromo.devel.redhat.com> References: <1118714579.6098.18.camel@rivendell.home.local> <20050614020819.GA1449@nostromo.devel.redhat.com> Message-ID: <20050614022024.GA7523@thacker.dyndns.org> On Mon, Jun 13, 2005 at 10:08:19PM -0400, Bill Nottingham wrote: > Did you run: > chkconfig --del (wrong) > or > chkconfig --level (right) > ? chkconfig off will also work. It *is* somewhat confusing, though. It's a mistake I made when first using chkconfig; then I saw the problem mentioned, and bothered to actually read the man page more closely. ;) John Thacker -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From shiva at sewingwitch.com Tue Jun 14 02:26:55 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Mon, 13 Jun 2005 19:26:55 -0700 Subject: bad practice: services that are automatically re-enabled In-Reply-To: <1118714942.28155.10.camel@cutter> References: <1118714579.6098.18.camel@rivendell.home.local> <1118714942.28155.10.camel@cutter> Message-ID: <54D7CC9A87F9CBBAF28412CC@[10.169.6.233]> --On Monday, June 13, 2005 10:09 PM -0400 seth vidal wrote: > could you make a list of the ones you find and file bugs? And perhaps post the list here. I'd be interested in knowing which ones do that, and in some cases I can generate patches. I've noticed that this is a common difference between RH packages and those generated from upstream tarballs, with the upstream packages tending to turn things on and the RH spec files tweaked to not do so. From mattdm at mattdm.org Tue Jun 14 02:30:00 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 13 Jun 2005 22:30:00 -0400 Subject: bad practice: services that are automatically re-enabled In-Reply-To: <20050614022024.GA7523@thacker.dyndns.org> References: <1118714579.6098.18.camel@rivendell.home.local> <20050614020819.GA1449@nostromo.devel.redhat.com> <20050614022024.GA7523@thacker.dyndns.org> Message-ID: <20050614023000.GA28902@jadzia.bu.edu> On Mon, Jun 13, 2005 at 10:20:24PM -0400, John Thacker wrote: > > Did you run: > > chkconfig --del (wrong) > > or > > chkconfig --level (right) > > ? > chkconfig off > will also work. It *is* somewhat confusing, though. It's a mistake I > made when first using chkconfig; then I saw the problem mentioned, and > bothered to actually read the man page more closely. ;) I think it's 'cause "--del" and other options are called out in bold as bullet points in the man page but on/off is just mentioned in the text. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 81 degrees Fahrenheit. From notting at redhat.com Tue Jun 14 02:45:17 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 13 Jun 2005 22:45:17 -0400 Subject: bad practice: services that are automatically re-enabled In-Reply-To: <20050614021626.GA28450@jadzia.bu.edu> References: <1118714579.6098.18.camel@rivendell.home.local> <20050614020819.GA1449@nostromo.devel.redhat.com> <20050614021626.GA28450@jadzia.bu.edu> Message-ID: <20050614024517.GA4324@nostromo.devel.redhat.com> Matthew Miller (mattdm at mattdm.org) said: > On Mon, Jun 13, 2005 at 10:08:19PM -0400, Bill Nottingham wrote: > > Did you run: > > chkconfig --del (wrong) > > or > > chkconfig --level (right) > > ? > > chkconfig off > > is also right, right? Yeah, in fact in the example above, there needs to be an off after . Bill From mbneto at gmail.com Tue Jun 14 02:48:18 2005 From: mbneto at gmail.com (mbneto) Date: Mon, 13 Jun 2005 22:48:18 -0400 Subject: Where is it ? :) In-Reply-To: <200506140917.42600.symbiont@berlios.de> References: <5cf776b80506130616d16ea9c@mail.gmail.com> <200506140024.06444.symbiont@berlios.de> <42ADB4A0.8020709@city-fan.org> <200506140917.42600.symbiont@berlios.de> Message-ID: <5cf776b805061319485e0c36f@mail.gmail.com> well, seems that the http download was faster this time... On 6/13/05, Jeff Pitman wrote: > On Tuesday 14 June 2005 00:30, Paul Howarth wrote: > > I'd be interested to know if this fixed > > the problem. > > It appears to have fixed it. I'm not getting the traceback any more. > > thanks, > -- > -jeff > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From florin at andrei.myip.org Tue Jun 14 02:53:07 2005 From: florin at andrei.myip.org (Florin Andrei) Date: Mon, 13 Jun 2005 19:53:07 -0700 Subject: bad practice: services that are automatically re-enabled In-Reply-To: <20050614022024.GA7523@thacker.dyndns.org> References: <1118714579.6098.18.camel@rivendell.home.local> <20050614020819.GA1449@nostromo.devel.redhat.com> <20050614022024.GA7523@thacker.dyndns.org> Message-ID: <1118717587.6098.27.camel@rivendell.home.local> On Mon, 2005-06-13 at 22:20 -0400, John Thacker wrote: > On Mon, Jun 13, 2005 at 10:08:19PM -0400, Bill Nottingham wrote: > > Did you run: > > chkconfig --del (wrong) > > or > > chkconfig --level (right) > > ? > > chkconfig off > will also work. It *is* somewhat confusing, though. It's a mistake I > made when first using chkconfig; then I saw the problem mentioned, and > bothered to actually read the man page more closely. ;) I think that is actually the problem. Why "--del" should be different from "off"? In either case, the package should not change the state of the service, period. It's not like something goes off every once in a blue moon and changes things around - if there's a change, most likely someone made a decision and did it for a reason. The software should respect that decision. Almost always, it's preferable to disable services with "--del", therefore keeping the list shorter and easier to read for the overworked sysadmin. It's kind of hard to scan tons of chkconfig lists on many systems, trying to figure out which ones are on and which are off; those lists are not easy to read at a glance. Yes, I know the service is there, yes, I know I can re-enable it later on, I just want it out of the way for the moment. Packages should not ignore my decision. Any way I look at it, I fail to see the reason why "--del" should imply some kind of weaker decision that "off". If anything, it should be a stronger statement. -- Florin Andrei http://florin.myip.org/ From mattdm at mattdm.org Tue Jun 14 03:09:05 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 13 Jun 2005 23:09:05 -0400 Subject: bad practice: services that are automatically re-enabled In-Reply-To: <1118717587.6098.27.camel@rivendell.home.local> References: <1118714579.6098.18.camel@rivendell.home.local> <20050614020819.GA1449@nostromo.devel.redhat.com> <20050614022024.GA7523@thacker.dyndns.org> <1118717587.6098.27.camel@rivendell.home.local> Message-ID: <20050614030905.GA30522@jadzia.bu.edu> On Mon, Jun 13, 2005 at 07:53:07PM -0700, Florin Andrei wrote: > Why "--del" should be different from "off"? In either case, the package > should not change the state of the service, period. It's not like > something goes off every once in a blue moon and changes things around - > if there's a change, most likely someone made a decision and did it for > a reason. The software should respect that decision. Because "del" removes the state information completely. Then, when the package is updated, it has no idea if it was supposed to be on or off, and has to go with the default. And the default for some of these things (syslog, say) *should* be "on". > Almost always, it's preferable to disable services with "--del", > therefore keeping the list shorter and easier to read for the overworked > sysadmin. It's kind of hard to scan tons of chkconfig lists on many > systems, trying to figure out which ones are on and which are off; those > lists are not easy to read at a glance. chkconfig --list|grep [35]:on -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 81 degrees Fahrenheit. From notting at redhat.com Tue Jun 14 03:09:03 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 13 Jun 2005 23:09:03 -0400 Subject: bad practice: not reading the manpage In-Reply-To: <1118717587.6098.27.camel@rivendell.home.local> References: <1118714579.6098.18.camel@rivendell.home.local> <20050614020819.GA1449@nostromo.devel.redhat.com> <20050614022024.GA7523@thacker.dyndns.org> <1118717587.6098.27.camel@rivendell.home.local> Message-ID: <20050614030903.GA5862@nostromo.devel.redhat.com> Florin Andrei (florin at andrei.myip.org) said: > Why "--del" should be different from "off"? Why are 'rpm -i' and 'rpm -U' different? Why are 'ln -s' and 'ln' different? Because they're different things. 'off' - configure the service to not start 'del' - remove all state for the service entirely > Almost always, it's preferable to disable services with "--del", > therefore keeping the list shorter and easier to read for the overworked > sysadmin. It's kind of hard to scan tons of chkconfig lists on many > systems, trying to figure out which ones are on and which are off; those > lists are not easy to read at a glance. So, misuse of the command to make --list easier to read is worth changing the behavior that's existed since the command was introduced? Bill From florin at andrei.myip.org Tue Jun 14 03:32:23 2005 From: florin at andrei.myip.org (Florin Andrei) Date: Mon, 13 Jun 2005 20:32:23 -0700 Subject: bad practice: not reading the manpage In-Reply-To: <20050614030903.GA5862@nostromo.devel.redhat.com> References: <1118714579.6098.18.camel@rivendell.home.local> <20050614020819.GA1449@nostromo.devel.redhat.com> <20050614022024.GA7523@thacker.dyndns.org> <1118717587.6098.27.camel@rivendell.home.local> <20050614030903.GA5862@nostromo.devel.redhat.com> Message-ID: <1118719943.6098.46.camel@rivendell.home.local> On Mon, 2005-06-13 at 23:09 -0400, Bill Nottingham wrote: > Florin Andrei (florin at andrei.myip.org) said: > > Why "--del" should be different from "off"? > Because they're different things. > > 'off' - configure the service to not start > 'del' - remove all state for the service entirely But that's a state in itself, functionally equivalent to "off on all runlevels". It's unique only in the way that it is not preserved by "rpm -U" > So, misuse of the command to make --list easier to read is worth > changing the behavior that's existed since the command was introduced? Making --list easier to read is actually very valuable. If you have a lot of things to take care of, you don't want to spend "brain cycles" needlessly; plus, which services are on or off is a pretty important issue, you don't want to make mistakes there. I've seen this type of problem many times, when sysadmins and software engineers are looking at the same issue. It's frustrating sometimes to make engineers understand the issue from a real world perspective; what's nice, clean and logical in the lab might be a huge drag in the real world. I understand, "--del" takes the service to a state that's not preserved by rpm. Fine. But who did --del? Most likely the sysadmin. Why should the software disregard a human decision? The system did not end up in that state at random, but by human intervention. The software should not overrule it. Why should --del be different, other than "this is the way our forefathers did it"? This is the core of the problem and I don't think I received a good answer yet. Tradition is fine and all that, but it should change when it's hampering the usability. Maybe I spent too much time lately with the Gnome HIG and stuff like that (not strictly related, I know, but you get the idea), but I think it's the computer semantics that should bend over backwards to adapt to human semantics, not the other way around. -- Florin Andrei http://florin.myip.org/ From notting at redhat.com Tue Jun 14 03:39:54 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 13 Jun 2005 23:39:54 -0400 Subject: bad practice: not reading the manpage In-Reply-To: <1118719943.6098.46.camel@rivendell.home.local> References: <1118714579.6098.18.camel@rivendell.home.local> <20050614020819.GA1449@nostromo.devel.redhat.com> <20050614022024.GA7523@thacker.dyndns.org> <1118717587.6098.27.camel@rivendell.home.local> <20050614030903.GA5862@nostromo.devel.redhat.com> <1118719943.6098.46.camel@rivendell.home.local> Message-ID: <20050614033954.GA9512@nostromo.devel.redhat.com> Florin Andrei (florin at andrei.myip.org) said: > > Because they're different things. > > > > 'off' - configure the service to not start > > 'del' - remove all state for the service entirely > > But that's a state in itself, functionally equivalent to "off on all > runlevels". It's unique only in the way that it is not preserved by "rpm > -U" No, it's a state equivalent to 'no state at all'. > This is the core of the problem and I don't think I received a good > answer yet. Because you don't randomly change established, documented, and expected behavior on a whim. > Tradition is fine and all that, but it should change when it's hampering > the usability. Maybe I spent too much time lately with the Gnome HIG and > stuff like that (not strictly related, I know, but you get the idea), > but I think it's the computer semantics that should bend over backwards > to adapt to human semantics, not the other way around. You want to help usability? Help work on something better. http://fedoraproject.org/wiki/FCNewInit Bill From fedora-devel at tlarson.com Tue Jun 14 03:41:34 2005 From: fedora-devel at tlarson.com (Tyler Larson) Date: Mon, 13 Jun 2005 21:41:34 -0600 Subject: Bad Mirror (mirrors.kernel.org) Message-ID: <42AE51EE.6090602@tlarson.com> I'm getting bad FC4 ISO files from mirrors.kernel.org (via HTTP). Furthermore, I'm consistently getting the *same* bad ISOs, no matter how I download it and which client-side computer I download using. Here's the MD5s of what I get: 00f145389547055096c78ca2fb90d1a2 FC4-i386-disc1.iso 7d5007fbefa0a837471db1c2670be6ac FC4-i386-disc2.iso 7ece895928968de9ff6bf94119b353f4 FC4-i386-disc3.iso 1e4ce0f786abf85f16eee27ceb7260d4 FC4-i386-disc4.iso Does anyone know the cause of this inconsistency? Is it limited to just this one mirror, or is this a more widespread problem? From skvidal at phy.duke.edu Tue Jun 14 03:45:12 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 13 Jun 2005 23:45:12 -0400 Subject: Bad Mirror (mirrors.kernel.org) In-Reply-To: <42AE51EE.6090602@tlarson.com> References: <42AE51EE.6090602@tlarson.com> Message-ID: <1118720712.28155.17.camel@cutter> On Mon, 2005-06-13 at 21:41 -0600, Tyler Larson wrote: > I'm getting bad FC4 ISO files from mirrors.kernel.org (via HTTP). > Furthermore, I'm consistently getting the *same* bad ISOs, no matter how > I download it and which client-side computer I download using. Here's > the MD5s of what I get: > > 00f145389547055096c78ca2fb90d1a2 FC4-i386-disc1.iso > 7d5007fbefa0a837471db1c2670be6ac FC4-i386-disc2.iso > 7ece895928968de9ff6bf94119b353f4 FC4-i386-disc3.iso > 1e4ce0f786abf85f16eee27ceb7260d4 FC4-i386-disc4.iso > > Does anyone know the cause of this inconsistency? Is it limited to just > this one mirror, or is this a more widespread problem? they're not MD5SUMS - they're SHA1SUMS hence the filename. -sv From notting at redhat.com Tue Jun 14 03:45:13 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 13 Jun 2005 23:45:13 -0400 Subject: Bad Mirror (mirrors.kernel.org) In-Reply-To: <42AE51EE.6090602@tlarson.com> References: <42AE51EE.6090602@tlarson.com> Message-ID: <20050614034513.GA10304@nostromo.devel.redhat.com> Tyler Larson (fedora-devel at tlarson.com) said: > I'm getting bad FC4 ISO files from mirrors.kernel.org (via HTTP). > Furthermore, I'm consistently getting the *same* bad ISOs, no matter how > I download it and which client-side computer I download using. Here's > the MD5s of what I get: > > 00f145389547055096c78ca2fb90d1a2 FC4-i386-disc1.iso > 7d5007fbefa0a837471db1c2670be6ac FC4-i386-disc2.iso > 7ece895928968de9ff6bf94119b353f4 FC4-i386-disc3.iso > 1e4ce0f786abf85f16eee27ceb7260d4 FC4-i386-disc4.iso > > Does anyone know the cause of this inconsistency? Is it limited to just > this one mirror, or is this a more widespread problem? Do the sizes, at least, match? Bill From mattdm at mattdm.org Tue Jun 14 04:05:37 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 14 Jun 2005 00:05:37 -0400 Subject: bad practice: not reading the manpage In-Reply-To: <1118719943.6098.46.camel@rivendell.home.local> References: <1118714579.6098.18.camel@rivendell.home.local> <20050614020819.GA1449@nostromo.devel.redhat.com> <20050614022024.GA7523@thacker.dyndns.org> <1118717587.6098.27.camel@rivendell.home.local> <20050614030903.GA5862@nostromo.devel.redhat.com> <1118719943.6098.46.camel@rivendell.home.local> Message-ID: <20050614040537.GA305@jadzia.bu.edu> On Mon, Jun 13, 2005 at 08:32:23PM -0700, Florin Andrei wrote: > > 'off' - configure the service to not start > > 'del' - remove all state for the service entirely > But that's a state in itself, functionally equivalent to "off on all > runlevels". It's unique only in the way that it is not preserved by "rpm > -U" How *could* it be??? That's the _exact_ difference between using "--del" and "off". > Making --list easier to read is actually very valuable. If you have a > lot of things to take care of, you don't want to spend "brain cycles" > needlessly; plus, which services are on or off is a pretty important > issue, you don't want to make mistakes there. This is a different issue than whether state information should be left on the system by a command named "--del". There would be several ways to make the output of this command more readable without mucking with functionality. (Like, dealing with that nasty xinitd kludge.) > I understand, "--del" takes the service to a state that's not preserved > by rpm. Fine. But who did --del? Most likely the sysadmin. Why should > the software disregard a human decision? The system did not end up in > that state at random, but by human intervention. The software should not > overrule it. The sysadmin shouldn't do that, really, without *expecting* it to get reset to the default at some point -- or, at least, going "oh, duh" when it does. > Why should --del be different, other than "this is the way our > forefathers did it"? Um, because *removing state information is what --del does*! There are two possible alteratives: 1) make *no* services (including syslog, crond, keytable, iptables, etc) start by default or 2) have very inconsistant and basically unpredictable behavior between upgrading and installing a package. Personally, I think it's *much* better to leave things working as they are -- and to teach people to use the easier and shorter off/on commands. > This is the core of the problem and I don't think I received a good > answer yet. You have now. :) > Tradition is fine and all that, but it should change when it's hampering > the usability. Maybe I spent too much time lately with the Gnome HIG and > stuff like that (not strictly related, I know, but you get the idea), > but I think it's the computer semantics that should bend over backwards > to adapt to human semantics, not the other way around. Are you seriously suggesting that "--del" is more human-friendly than "off"? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 81 degrees Fahrenheit. From mikem at cyber.com.au Tue Jun 14 04:20:18 2005 From: mikem at cyber.com.au (Mike MacCana) Date: Tue, 14 Jun 2005 14:20:18 +1000 Subject: bad practice: services that are automatically re-enabled In-Reply-To: <20050614030905.GA30522@jadzia.bu.edu> References: <1118714579.6098.18.camel@rivendell.home.local> <20050614020819.GA1449@nostromo.devel.redhat.com> <20050614022024.GA7523@thacker.dyndns.org> <1118717587.6098.27.camel@rivendell.home.local> <20050614030905.GA30522@jadzia.bu.edu> Message-ID: <42AE5B02.9010806@cyber.com.au> My POV: The way FC and RHEL are shipped now, once installed, every service has either an S or K link in eachj runlevel. Extras should continue that behavior, for consistency. chkconfig --add is only for package install scripts. chkconfig --del is only for package uninstall scripts. 'chkconfig foo on' is for users and package install scripts for the very few packages that need to be on by default. 'chkconfig foo off' is for users and package install scripts for most services. Anyone disagree? Mike > > > > From fedora-devel at tlarson.com Tue Jun 14 05:10:47 2005 From: fedora-devel at tlarson.com (Tyler Larson) Date: Mon, 13 Jun 2005 23:10:47 -0600 Subject: Bad Mirror (mirrors.kernel.org) In-Reply-To: <1118720712.28155.17.camel@cutter> References: <42AE51EE.6090602@tlarson.com> <1118720712.28155.17.camel@cutter> Message-ID: <42AE66D7.1040903@tlarson.com> seth vidal wrote: >On Mon, 2005-06-13 at 21:41 -0600, Tyler Larson wrote: > > >>I'm getting bad FC4 ISO files from mirrors.kernel.org (via HTTP). >>Furthermore, I'm consistently getting the *same* bad ISOs, no matter how >>I download it and which client-side computer I download using. Here's >>the MD5s of what I get: >> >>00f145389547055096c78ca2fb90d1a2 FC4-i386-disc1.iso >>7d5007fbefa0a837471db1c2670be6ac FC4-i386-disc2.iso >>7ece895928968de9ff6bf94119b353f4 FC4-i386-disc3.iso >>1e4ce0f786abf85f16eee27ceb7260d4 FC4-i386-disc4.iso >> >>Does anyone know the cause of this inconsistency? Is it limited to just >>this one mirror, or is this a more widespread problem? >> >> > >they're not MD5SUMS - they're SHA1SUMS > >hence the filename. > >-sv > > > > Ah, mea culpa. I just checked and the SHA1 sums match correctly. I wonder if I'm the only one who was confused by that. As a side note, if anyone was wondering what the correct MD5 sums are for the i386 isos, here you go :) From bernie at develer.com Tue Jun 14 07:04:44 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Tue, 14 Jun 2005 09:04:44 +0200 Subject: Audit / Netlink slowness Message-ID: <42AE818C.3010607@develer.com> Hello, on a server running kernel 2.6.11-1.1369_FC4, both ssh and su where taking a longish amount of time (over >1.5 sec.) Running "strace -r 2>strace.out su", I discovered that netlink communication is the major cause of slowdown. "su" connects to a NETLINK_AUDIT socket 3 or 4 times. Each time it does 2 sendto() + recvfrom() operations, with a latency of ~200ms. This adds up to 800ms wasted time. Disabling CONFIG_AUDIT in the kernel makes su and ssh very fast again. Is this behavior to be expected? CONFIG_AUDIT is enabled by default, therefore many people are going to be hit by this problem. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From ghenry at suretecsystems.com Tue Jun 14 07:41:44 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Tue, 14 Jun 2005 08:41:44 +0100 (BST) Subject: perl-DBD-MySQL-2.9007-1.src.rpm rebuild Message-ID: <35185.193.195.148.66.1118734904.squirrel@webmail.suretecsystems.com> Dear guys, I know I should be doing this, but I am rebuilding perl-DBD-MySQL-2.9007-1.src.rpm on RHEL3, and I get a failure: RPM build errors: File must begin with "/": %{perl_vendorarch}/Bundle/ File must begin with "/": %{perl_vendorarch}/DBD/ File must begin with "/": %{perl_vendorarch}/Mysql* File must begin with "/": %{perl_vendorarch}/auto/DBD I am sure it is something easy, but can't figure it out. Thanks. It's for mysql 4.1 which I have rebuilt on RHEL3 from FC4 srpms. I know, I know. Thanks. -- Kind Regards, Gavin Henry. Open Source. Open Solutions(tm). http://www.suretecsystems.com/ From ghenry at suretecsystems.com Tue Jun 14 08:06:20 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Tue, 14 Jun 2005 09:06:20 +0100 (BST) Subject: perl-DBD-MySQL-2.9007-1.src.rpm rebuild In-Reply-To: <1118735730.42ae8d723cdf3@webmail1.kuleuven.be> References: <35185.193.195.148.66.1118734904.squirrel@webmail.suretecsystems.com> <1118735730.42ae8d723cdf3@webmail1.kuleuven.be> Message-ID: <37175.193.195.148.66.1118736380.squirrel@webmail.suretecsystems.com> > Quoting Gavin Henry : > >> Dear guys, >> >> I know I should be doing this, but I am rebuilding >> perl-DBD-MySQL-2.9007-1.src.rpm on RHEL3, and I get a failure: >> >> RPM build errors: >> File must begin with "/": %{perl_vendorarch}/Bundle/ >> File must begin with "/": %{perl_vendorarch}/DBD/ >> File must begin with "/": %{perl_vendorarch}/Mysql* >> File must begin with "/": %{perl_vendorarch}/auto/DBD > > You need to add something like the following at the top of your spec file: > %define perl_vendorlib %(eval "`perl -V:installvendorlib`"; echo > $installvendorlib) > %define perl_vendorarch %(eval "`perl -V:installvendorarch`"; echo > $installvendorarch) > > (it should be 2 lines, not 4) > > An example in another spec file: > http://dries.ulyssis.org/rpm/packages/perl-DBD-CSV/perl-DBD-CSV-spec.html > http://dries.ulyssis.org/rpm/packages/perl-DBD-CSV/info.html > > Then you can compile it also on rhel3 normally. Excellent! Worked a treat. Should I file a bug, or is this RHEL3 specific? Thanks. > > kind regards, > Dries Verachtert > > From web at bis.bg Tue Jun 14 08:13:47 2005 From: web at bis.bg (web at bis.bg) Date: Tue, 14 Jun 2005 11:13:47 +0300 Subject: I wont to help You !!! Message-ID: <20050614081347.3434.qmail@rabbit.biscom.net> Hi ! I wont to help You !!! to TRANSLATE Fedora - Red Hat from Inglish to Bulgarian !!! I know C,C++,HTML ! Now I study Perl & PHP ! Best regards ! Todor Yankov ============================================================ http://bis.bg ???????? ???-??????? ???? ? ???????? From twaugh at redhat.com Tue Jun 14 08:19:05 2005 From: twaugh at redhat.com (Tim Waugh) Date: Tue, 14 Jun 2005 09:19:05 +0100 Subject: bad practice: not reading the manpage In-Reply-To: <20050614040537.GA305@jadzia.bu.edu> References: <1118714579.6098.18.camel@rivendell.home.local> <20050614020819.GA1449@nostromo.devel.redhat.com> <20050614022024.GA7523@thacker.dyndns.org> <1118717587.6098.27.camel@rivendell.home.local> <20050614030903.GA5862@nostromo.devel.redhat.com> <1118719943.6098.46.camel@rivendell.home.local> <20050614040537.GA305@jadzia.bu.edu> Message-ID: <20050614081905.GX8706@redhat.com> On Tue, Jun 14, 2005 at 12:05:37AM -0400, Matthew Miller wrote: > On Mon, Jun 13, 2005 at 08:32:23PM -0700, Florin Andrei wrote: > > > 'off' - configure the service to not start > > > 'del' - remove all state for the service entirely > > But that's a state in itself, functionally equivalent to "off on all > > runlevels". It's unique only in the way that it is not preserved by "rpm > > -U" > > How *could* it be??? That's the _exact_ difference between using "--del" and > "off". Precisely. What the original poster is asking for seems to be equivalent to asking for state to be preserved in this case: chkconfig foo off rpm -e foo rpm -i foo-1-1.rpm However, it does sound to me like there should at least be a warning in the man page that packaged services should be disabled using 'off'... ...although, having actually read it, there already *is* such a warning: --del name The service is removed from chkconfig management, and any symbolic links in /etc/rc[0-6].d which pertain to it are removed. Note that future package installs for this service may run chkconfig --add, which will re-add such links. To disable a service, run chkconfig name off. Perhaps chkconfig should check whether it's running from a tty and ask for confirmation. :-) Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From yuan.bbbush at gmail.com Tue Jun 14 08:24:53 2005 From: yuan.bbbush at gmail.com (Yuan Yijun) Date: Tue, 14 Jun 2005 16:24:53 +0800 Subject: I wont to help You !!! In-Reply-To: <20050614081347.3434.qmail@rabbit.biscom.net> References: <20050614081347.3434.qmail@rabbit.biscom.net> Message-ID: <9792751e05061401243e35cab8@mail.gmail.com> Hi, welcome to fedora-docs-list und fedora-trans-list -- bbbush ^_^ From carljohan at design.chalmers.se Tue Jun 14 09:08:15 2005 From: carljohan at design.chalmers.se (Carl-Johan Kjellander) Date: Tue, 14 Jun 2005 11:08:15 +0200 Subject: stateless-linux problems. Message-ID: <42AE9E7F.8000207@design.chalmers.se> Hi. I'm playing around with stateless-linux which really suits my Company's needs, and it works ok but we've encountered some problems. All machines, both server and diskless clients run FC3. 1. The screen resolution on the diskless machines is 640x480 and not 1400x1050 as we set on the protosystem. Why is that and how can we change it? 2. When logging into Gnome we get the old xkb error: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120858 How can we avoid that? 3. SELinux spews tons of messages at startup, not really a bug but annoying. 4. When trying to reboot the diskless clients the machines get stuck in an infinite loop of RPC-errors, 111 if I remember correctly but I have to recheck. And where should I file bugs in the stateless-linux scripts? /cjk -- begin 644 carljohan_at_kjellander_dot_com.gif Y1TE&.#=A(0`F`(```````/___RP`````(0`F```"@XR/!\N<#U.;+MI`<[U(>\!UGQ9BGT%>'D2I Y*=NX,2 at OUF2&<827ILW;^822C>\7!!Z1,!K'B5(6HQI6:7"A>Y?):D2^*U at NCV RLZYD-_T1U<@3W]A4(^$-W4]A#V")W6#.R"$;IR'@).46BN7$9>5D``#L` -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3296 bytes Desc: S/MIME Cryptographic Signature URL: From huw-l at moving-picture.com Tue Jun 14 09:10:55 2005 From: huw-l at moving-picture.com (Huw Lynes) Date: Tue, 14 Jun 2005 10:10:55 +0100 Subject: Xen x86_64 timescale? Message-ID: <1118740254.3685.3.camel@wingnut.mpc.local> I'm hoping the Red Hat Xen gurus can enlighten me. Is there an ETA on an x86_64 xen appearing in rawhide? If/when it appears is it possible to run both i386 and x86_64 VMs on an x86_64 box? I've been through the xen docs and it appears that you can't but I haven't really got my head around it all yet so I may be mistaken. Thanks, Huw -- | Huw Lynes | The Moving Picture Company | | System Administrator | 127 Wardour Street | |.........................| London, W1F 0NL | From mpeters at mac.com Tue Jun 14 09:33:15 2005 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 14 Jun 2005 02:33:15 -0700 Subject: perl-DBD-MySQL-2.9007-1.src.rpm rebuild In-Reply-To: <37175.193.195.148.66.1118736380.squirrel@webmail.suretecsystems.com> References: <35185.193.195.148.66.1118734904.squirrel@webmail.suretecsystems.com> <1118735730.42ae8d723cdf3@webmail1.kuleuven.be> <37175.193.195.148.66.1118736380.squirrel@webmail.suretecsystems.com> Message-ID: <1118741595.2612.29.camel@laptop.mpeters.local> On Tue, 2005-06-14 at 09:06 +0100, Gavin Henry wrote: > > > > You need to add something like the following at the top of your spec file: > > %define perl_vendorlib %(eval "`perl -V:installvendorlib`"; echo > > $installvendorlib) > > %define perl_vendorarch %(eval "`perl -V:installvendorarch`"; echo > > $installvendorarch) > > > > (it should be 2 lines, not 4) > > > > An example in another spec file: > > http://dries.ulyssis.org/rpm/packages/perl-DBD-CSV/perl-DBD-CSV-spec.html > > http://dries.ulyssis.org/rpm/packages/perl-DBD-CSV/info.html > > > > Then you can compile it also on rhel3 normally. > > Excellent! Worked a treat. > > Should I file a bug, or is this RHEL3 specific? I believe those macros are defined in FC3/FC4 rpm w/o needing to be defined in the spec file itself, so it wouldn't be a bug unless the specfile you are using is suppose to build on RHEL3. From mpeters at mac.com Tue Jun 14 09:40:16 2005 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 14 Jun 2005 02:40:16 -0700 Subject: bad practice: not reading the manpage In-Reply-To: <20050614081905.GX8706@redhat.com> References: <1118714579.6098.18.camel@rivendell.home.local> <20050614020819.GA1449@nostromo.devel.redhat.com> <20050614022024.GA7523@thacker.dyndns.org> <1118717587.6098.27.camel@rivendell.home.local> <20050614030903.GA5862@nostromo.devel.redhat.com> <1118719943.6098.46.camel@rivendell.home.local> <20050614040537.GA305@jadzia.bu.edu> <20050614081905.GX8706@redhat.com> Message-ID: <1118742017.2612.33.camel@laptop.mpeters.local> On Tue, 2005-06-14 at 09:19 +0100, Tim Waugh wrote: > > ...although, having actually read it, there already *is* such a > warning: > > --del name > The service is removed from chkconfig management, and > any symbolic links in /etc/rc[0-6].d which pertain to > it are removed. > > Note that future package installs for this service may > run chkconfig --add, which will re-add such links. To > disable a service, run chkconfig name off. I think that was added to the man page when I had this exact same issue and the man page wasn't clear. imho another solution is to simply have upgrade to absolutely nothing with chkconfig, other than checking to see if the service needs to be restarted. That way if --del was used, it won't --add it again. Install use --add upgrade do nothing (other than restart service if on) From fedora at wir-sind-cool.org Tue Jun 14 10:16:38 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 14 Jun 2005 12:16:38 +0200 Subject: Debugging tipps anyone? Message-ID: <20050614121638.19a386c8.fedora@wir-sind-cool.org> This is the result of last night's attempt at testing whether an updated version of "wesnoth" 0.9.2 (Fedora Extras) would seem to work with FC4. Clicking some buttons in its network related menus or connecting to the official server lead to this fully reproducible crash: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 54066096 (zombie)] 0x00a353a8 in ?? () (gdb) bt #0 0x00a353a8 in ?? () #1 0x0026ab7a in __nptl_deallocate_tsd () from /lib/libpthread.so.0 #2 0x0026bb8e in start_thread () from /lib/libpthread.so.0 #3 0x00c79dee in clone () from /lib/libc.so.6 (gdb) t [Current thread is 4 (Thread 54066096 (zombie))] It's not reproducible with FC3. Backtraces for the threads (attached) don't look suspicious IMO. Adding more debuginfo packages didn't give more detailed output. Two other things I tried last night was to build without -O2 and build SDL with default optflags instead of -O3. No change. Suggestions, ideas, or hints much appreciated. -- Fedora Core release 4 (Stentz) - Linux 2.6.11-1.1369_FC4 loadavg: 1.45 1.33 1.50 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Backtraces2.txt URL: From fedora at camperquake.de Tue Jun 14 11:04:35 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 14 Jun 2005 13:04:35 +0200 Subject: iso xdeltas FC4-test3 -> FC4 ? In-Reply-To: <42AE2170.6010101@margo.bijoux.nom.br> References: <1cef3e9505061308476ec9c7a2@mail.gmail.com> <20050613191905.525e72da@nausicaa.camperquake.de> <42AE2170.6010101@margo.bijoux.nom.br> Message-ID: <20050614130435.510285ce@nausicaa.camperquake.de> Hi. Pedro Fernandes Macedo wrote: > I'm working on making a set of jigdo files , to allow making a DVD/CD > from whatever source you have.. What jigdo version did you use? The current CVS does not really like the GCC4 compiler. -- If the U.S. government has no knowledge of aliens, then why does Title 14, Section 1211 of the Code of Federal Regulations, implemented on July 16, 1969, make it illegal for U.S. citizens to have any contact with extraterrestrials or their vehicles? From buildsys at redhat.com Tue Jun 14 11:20:37 2005 From: buildsys at redhat.com (Build System) Date: Tue, 14 Jun 2005 07:20:37 -0400 Subject: rawhide report: 20050614 changes Message-ID: <200506141120.j5EBKbak003638@porkchop.devel.redhat.com> New package iso-codes ISO code lists and translations New package libpixman Pixel manipulation library Updated Packages: audit-0.9.4-1 ------------- * Sat Jun 11 2005 Steve Grubb 0.9.4-1 - Rule and watch insert no longer automatically dumps list - auditctl rules can now use auid instead of loginuid - Add sighup support for daemon reconfiguration - Move some functions into private.h elinks-0.10.3-3.1 ----------------- * Sat Jun 11 2005 Karel Zak 0.10.3-3.1 - fix #159575 - elinks fails to render entire page epiphany-1.7.1-1 ---------------- * Fri Jun 10 2005 Christopher Aillon - 1.7.1-1 - Update to 1.7.1 fetchmail-6.2.5-9 ----------------- * Sat Jun 11 2005 Miloslav Trmac - 6.2.5-9 - Fix fetchmailconf handling of unspecified server port foomatic-3.0.2-20 ----------------- * Mon Jun 13 2005 Tim Waugh 3.0.2-20 - Updated db-hpijs to 1.5-20050613. - Updated db to 20050613. * Fri Jun 10 2005 Tim Waugh - Add IEEE 1284 ID for Epson Stylus Photo 915 (bug #160030). - Add IEEE 1284 ID for Ricoh Aficio 2228C PS (bug #160036). * Tue Jun 07 2005 Tim Waugh - Add IEEE 1284 ID for Epson Stylus Photo 870 (bug #159719). glib2-2.7.0-1 ------------- * Mon Jun 13 2005 Matthias Clasen - 2.7.0-1 - Update to 2.7.0 jwhois-3.2.2-16 --------------- * Sun Jun 12 2005 Miloslav Trmac - 3.2.2-16 - Remove 'fuzzy' from ru.po header to make charset conversion work (#160165) * Sat Jun 11 2005 Miloslav Trmac - 3.2.2-15 - Update to upstream config as of Jun 11 2005, remove patches accepted upstream patchutils-0.2.31-1 ------------------- * Mon Jun 13 2005 Tim Waugh 0.2.31-1 - 0.2.31. redhat-artwork-0.124-2 ---------------------- * Fri Jun 10 2005 John (J5) Palmieri 0.124-2 - readd a throbbers patch because the uptream tarball missed the Makefile changes rhythmbox-0.8.8-3 ----------------- * Mon Jun 13 2005 Colin Walters - 0.8.8-3 - Add Bluecurve-ized icons from Jeff Schroeder (157716) - Add rhythmbox-0.8.8-cell-renderer.patch to remove use of custom cell renderer for playback icon (no longer necessary) and changes the rating renderer to work with non-b&w icons rp-pppoe-3.5-28 --------------- * Mon Jun 13 2005 Than Ngo 3.5-28 - use iproute2 instead of old ifconfig #134816 selinux-policy-targeted-1.23.18-6 --------------------------------- * Mon Jun 13 2005 Dan Walsh 1.23.18-6 - Further cleanup of user separation patches from Ivan system-config-netboot-0.1.18-1 ------------------------------ * Mon Jun 13 2005 Jason Vas Dias 0.1.18-1 - fix bugs 159490, 159996, 160143 xpdf-1:3.00-20 -------------- * Mon Jun 13 2005 Than Ngo 3.00-20 - urlCommand launches htmlview #160176 - fix gcc4 build problem From enrico.scholz at informatik.tu-chemnitz.de Tue Jun 14 11:43:39 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 14 Jun 2005 13:43:39 +0200 Subject: Debugging tipps anyone? In-Reply-To: <20050614121638.19a386c8.fedora@wir-sind-cool.org> (Michael Schwendt's message of "Tue, 14 Jun 2005 12:16:38 +0200") References: <20050614121638.19a386c8.fedora@wir-sind-cool.org> Message-ID: <873brlrwno.fsf@kosh.bigo.ensc.de> fedora at wir-sind-cool.org (Michael Schwendt) writes: > This is the result of last night's attempt at testing whether an updated > version of "wesnoth" 0.9.2 (Fedora Extras) would seem to work with FC4. > ... > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 54066096 (zombie)] > 0x00a353a8 in ?? () > ... > Suggestions, ideas, or hints much appreciated. 'valgrind --db-attach=yes --tool=memcheck wesnoth' would be my first idea... Enrico From linux_4ever at yahoo.com Tue Jun 14 13:04:12 2005 From: linux_4ever at yahoo.com (Steve G) Date: Tue, 14 Jun 2005 06:04:12 -0700 (PDT) Subject: Audit / Netlink slowness In-Reply-To: <42AE818C.3010607@develer.com> Message-ID: <20050614130412.64768.qmail@web51506.mail.yahoo.com> Hi, >Running "strace -r 2>strace.out su", I discovered that >netlink communication is the major cause of slowdown. netlink in theory should be fast. No routing or collisions. >"su" connects to a NETLINK_AUDIT socket 3 or 4 times. >Each time it does 2 sendto() + recvfrom() operations, It does an audit subsystem status to see if its enabled and if so a send of auditable information. What version of pam, su, audit-libs, kernel are you using? >with a latency of ~200ms. This adds up to 800ms wasted >time. Just out of curiosity, what cpu & clock speed do you have? Are you running UP or SMP kernel? This code path should be entirely cpu bound as no io devices are involved. >Disabling CONFIG_AUDIT in the kernel makes su and ssh >very fast again. You also lose part of your SE Linux avc messages. There was a deadlock condition discovered and reported on the NSA SE Linux mail list. The solution was to move part of the processing to syscall exit audit processing. With audit not compiled in or enabled, you get an abreviated avc message under some conditions. >Is this behavior to be expected? Not exactly. There will be a *some* delay as we've added a lot of new functionality, but 800 ms total delay is excessive. I'll see if we can find the culprit. Thanks, -Steve Grubb __________________________________ Discover Yahoo! Use Yahoo! to plan a weekend, have fun online and more. Check it out! http://discover.yahoo.com/ From abbasmm at cs.vt.edu Tue Jun 14 13:09:51 2005 From: abbasmm at cs.vt.edu (Mohamed Magdi Abbas) Date: Tue, 14 Jun 2005 09:09:51 -0400 Subject: stateless-linux problems. In-Reply-To: <42AE9E7F.8000207@design.chalmers.se> References: <42AE9E7F.8000207@design.chalmers.se> Message-ID: <1118754591.5506.1.camel@localhost.localdomain> On Tue, 2005-06-14 at 11:08 +0200, Carl-Johan Kjellander wrote: > Hi. I'm playing around with stateless-linux which really suits my Company's > needs, and it works ok but we've encountered some problems. All machines, > both server and diskless clients run FC3. > > 1. The screen resolution on the diskless machines is 640x480 and not > 1400x1050 as we set on the protosystem. Why is that and how can we change > it? > > 2. When logging into Gnome we get the old xkb error: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120858 > How can we avoid that? > > 3. SELinux spews tons of messages at startup, not really a bug but > annoying. Make sure you pass the "quiet" parameter to the kernel on bootup via the bootloader. > 4. When trying to reboot the diskless clients the machines get stuck > in an infinite loop of RPC-errors, 111 if I remember correctly but > I have to recheck. > > And where should I file bugs in the stateless-linux scripts? > > /cjk > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Mohamed Magdi Abbas Computer Science Department at Virginia Tech From jerone at gmail.com Tue Jun 14 13:24:51 2005 From: jerone at gmail.com (Jerone Young) Date: Tue, 14 Jun 2005 08:24:51 -0500 Subject: Xen x86_64 timescale? In-Reply-To: <1118740254.3685.3.camel@wingnut.mpc.local> References: <1118740254.3685.3.camel@wingnut.mpc.local> Message-ID: <9f50a7a0050614062466d24221@mail.gmail.com> As one who is working on it, Xen x86_64 will not be ready till Xen 3.0. Right now Xen x86_64 is not even ready for full blown testing. Time schedule is for Xen 3.0 right now. On 6/14/05, Huw Lynes wrote: > I'm hoping the Red Hat Xen gurus can enlighten me. > > Is there an ETA on an x86_64 xen appearing in rawhide? > > If/when it appears is it possible to run both i386 and x86_64 VMs on an > x86_64 box? I've been through the xen docs and it appears that you can't > but I haven't really got my head around it all yet so I may be mistaken. > > Thanks, > Huw > > > -- > | Huw Lynes | The Moving Picture Company | > | System Administrator | 127 Wardour Street | > |.........................| London, W1F 0NL | > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From linux_4ever at yahoo.com Tue Jun 14 13:58:02 2005 From: linux_4ever at yahoo.com (Steve G) Date: Tue, 14 Jun 2005 06:58:02 -0700 (PDT) Subject: Audit / Netlink slowness In-Reply-To: <42AE818C.3010607@develer.com> Message-ID: <20050614135803.95602.qmail@web51509.mail.yahoo.com> >"su" connects to a NETLINK_AUDIT socket 3 or 4 times. >Each time it does 2 sendto() + recvfrom() operations, >with a latency of ~200ms. This adds up to 800ms wasted >time. I see a way to get rid of 1 sendto and put it in the error path. This way people without audit support (which would be rare for this distro) would get the extra sendto. This would solve the common use problem. You really need audit compiled in for SE Linux avc messages to be full and complete. I also see a few *minor* issues in the kernel that might save a couple clock cycles, but no magic bullet. -Steve Grubb __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From carljohan at design.chalmers.se Tue Jun 14 14:24:44 2005 From: carljohan at design.chalmers.se (Carl-Johan Kjellander) Date: Tue, 14 Jun 2005 16:24:44 +0200 Subject: stateless-linux problems. In-Reply-To: <1118754591.5506.1.camel@localhost.localdomain> References: <42AE9E7F.8000207@design.chalmers.se> <1118754591.5506.1.camel@localhost.localdomain> Message-ID: <42AEE8AC.3070400@design.chalmers.se> Mohamed Magdi Abbas wrote: > On Tue, 2005-06-14 at 11:08 +0200, Carl-Johan Kjellander wrote: >>3. SELinux spews tons of messages at startup, not really a bug but >>annoying. > > > Make sure you pass the "quiet" parameter to the kernel on bootup via the > bootloader. Yeah I figured that one out myself. Forgot to add those extra params to the pxe config. /cjk -- begin 644 carljohan_at_kjellander_dot_com.gif Y1TE&.#=A(0`F`(```````/___RP`````(0`F```"@XR/!\N<#U.;+MI`<[U(>\!UGQ9BGT%>'D2I Y*=NX,2 at OUF2&<827ILW;^822C>\7!!Z1,!K'B5(6HQI6:7"A>Y?):D2^*U at NCV RLZYD-_T1U<@3W]A4(^$-W4]A#V")W6#.R"$;IR'@).46BN7$9>5D``#L` From d.lesca at solinos.it Tue Jun 14 15:32:26 2005 From: d.lesca at solinos.it (Dario Lesca) Date: Tue, 14 Jun 2005 17:32:26 +0200 Subject: FC4: matrox MGA video driver corrupting display Message-ID: <1118763146.8947.257.camel@localhost.localdomain> Hi, the FC4 Setup in graphical mode on this machine: [root at ghim ~]# cat /proc/cpuinfo | egrep '(vendor_id|model|cpu MHz)' vendor_id : GenuineIntel model : 2 model name : Intel(R) Pentium(R) 4 CPU 2.00GHz cpu MHz : 2000.572 [root at ghim ~]# lspci 00:00.0 Host bridge: VIA Technologies, Inc. VT8753 [P4X266 AGP] (rev 01) 00:01.0 PCI bridge: VIA Technologies, Inc. VT8633 [Apollo Pro266 AGP] 00:09.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 24) 00:0b.0 Multimedia audio controller: Ensoniq 5880 AudioPCI (rev 02) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8233A ISA Bridge 00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:11.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 23) 00:11.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 23) 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G550 AGP (rev 01) [root at ghim ~]# Does Not work. I must reboot the system 4 or 5 times without turning off the PC just to see a clear graphic interface. The "linux nofb" option passed on boot sequence does not solve the problem. As soon as the setup process is finished I reboot the system and there's a bad X graphic interface, so the o.s. is unusable. After 4 or 6 reboots the graphic interface is loaded correctly and the system work great. I have found on bugzilla for FC4test[23] this Bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=153729 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157556 Is this a known error for FC4 ? there is a bypass or a solution? Many thanks. -- Dario Lesca From jerone at gmail.com Tue Jun 14 15:59:19 2005 From: jerone at gmail.com (Jerone Young) Date: Tue, 14 Jun 2005 10:59:19 -0500 Subject: FC4: matrox MGA video driver corrupting display In-Reply-To: <1118763146.8947.257.camel@localhost.localdomain> References: <1118763146.8947.257.camel@localhost.localdomain> Message-ID: <9f50a7a005061408597fed5c4f@mail.gmail.com> Sadly I would say that Matrox is falling (hard) in the supported area. The problem should be fixed. But, I would save yourself some time and go out a cheap Nvidia or ati card. On 6/14/05, Dario Lesca wrote: > Hi, the FC4 Setup in graphical mode on this machine: > > [root at ghim ~]# cat /proc/cpuinfo | egrep '(vendor_id|model|cpu MHz)' > vendor_id : GenuineIntel > model : 2 > model name : Intel(R) Pentium(R) 4 CPU 2.00GHz > cpu MHz : 2000.572 > [root at ghim ~]# lspci > 00:00.0 Host bridge: VIA Technologies, Inc. VT8753 [P4X266 AGP] (rev 01) > 00:01.0 PCI bridge: VIA Technologies, Inc. VT8633 [Apollo Pro266 AGP] > 00:09.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] > (rev 24) > 00:0b.0 Multimedia audio controller: Ensoniq 5880 AudioPCI (rev 02) > 00:11.0 ISA bridge: VIA Technologies, Inc. VT8233A ISA Bridge > 00:11.1 IDE interface: VIA Technologies, Inc. > VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) > 00:11.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 > Controller (rev 23) > 00:11.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 > Controller (rev 23) > 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G550 AGP > (rev 01) > [root at ghim ~]# > > Does Not work. > > I must reboot the system 4 or 5 times without turning off the PC just to > see a clear graphic interface. > The "linux nofb" option passed on boot sequence does not solve the > problem. > > As soon as the setup process is finished I reboot the system and there's > a bad X graphic interface, so the o.s. is unusable. > > After 4 or 6 reboots the graphic interface is loaded correctly and the > system work great. > > I have found on bugzilla for FC4test[23] this Bug: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=153729 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157556 > > Is this a known error for FC4 ? > there is a bypass or a solution? > > Many thanks. > > -- > Dario Lesca > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From fedora at wir-sind-cool.org Tue Jun 14 16:25:52 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 14 Jun 2005 18:25:52 +0200 Subject: Debugging tipps anyone? In-Reply-To: <873brlrwno.fsf@kosh.bigo.ensc.de> References: <20050614121638.19a386c8.fedora@wir-sind-cool.org> <873brlrwno.fsf@kosh.bigo.ensc.de> Message-ID: <20050614182552.423c1dc0.fedora@wir-sind-cool.org> On Tue, 14 Jun 2005 13:43:39 +0200, Enrico Scholz wrote: > > This is the result of last night's attempt at testing whether an updated > > version of "wesnoth" 0.9.2 (Fedora Extras) would seem to work with FC4. > > ... > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 54066096 (zombie)] > > 0x00a353a8 in ?? () > > ... > > Suggestions, ideas, or hints much appreciated. > > 'valgrind --db-attach=yes --tool=memcheck wesnoth' would be my first > idea... Indicates a similar direction (SDL->pthreads usage)... ==9255== ==9255== Thread 4: ==9255== Jump to the invalid address stated on the next line ==9255== at 0x1BAC23A8: ??? ==9255== by 0x26BB8D: start_thread (in /lib/libpthread-2.3.5.so) ==9255== by 0xC79DED: clone (in /lib/libc-2.3.5.so) ==9255== Address 0x1BAC23A8 is not stack'd, malloc'd or (recently) free'd ==9255== ==9255== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- -- Fedora Core release 4 (Stentz) - Linux 2.6.11-1.1369_FC4 loadavg: 1.26 1.49 2.20 From dhollis at davehollis.com Tue Jun 14 17:00:54 2005 From: dhollis at davehollis.com (David Hollis) Date: Tue, 14 Jun 2005 13:00:54 -0400 Subject: Yum Upgrade Faq In-Reply-To: <1118642915.19703.52.camel@cutter> References: <1118642915.19703.52.camel@cutter> Message-ID: <1118768454.4719.6.camel@dhollis-lnx.sunera.com> On Mon, 2005-06-13 at 02:08 -0400, seth vidal wrote: > I've added a wiki page here: > http://fedoraproject.org/wiki/YumUpgradeFaq > > It's about upgrading from release to release via yum. If you find any > other odd gotchas - add them there. > > -sv I'm finding that even trying to upgrade yum i have problems with openoffice due to the package name changes. I have: libdb_cxx-4.2.so needed by openoffice.org-libs libedataserver.so.3 needed by openoffice.org libebook.so.8 needed by openoffice.org Looks like I'll need to manually install openoffice.org-core to take care of those -- David Hollis -------------- 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 emily at atropine.ath.cx Tue Jun 14 17:08:36 2005 From: emily at atropine.ath.cx (Emily Brantley) Date: Tue, 14 Jun 2005 13:08:36 -0400 Subject: Yum Upgrade Faq In-Reply-To: <1118768454.4719.6.camel@dhollis-lnx.sunera.com> References: <1118642915.19703.52.camel@cutter> <1118768454.4719.6.camel@dhollis-lnx.sunera.com> Message-ID: <42AF0F14.8070104@atropine.ath.cx> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Hollis wrote: > On Mon, 2005-06-13 at 02:08 -0400, seth vidal wrote: > >>I've added a wiki page here: >>http://fedoraproject.org/wiki/YumUpgradeFaq >> >>It's about upgrading from release to release via yum. If you find any >>other odd gotchas - add them there. >> >>-sv > > > > I'm finding that even trying to upgrade yum i have problems with > openoffice due to the package name changes. I have: > > libdb_cxx-4.2.so needed by openoffice.org-libs > libedataserver.so.3 needed by openoffice.org > libebook.so.8 needed by openoffice.org > > Looks like I'll need to manually install openoffice.org-core to take > care of those maybe you should note that on the FAQ wiki so that others can benefit from knowing about it. Em -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCrw8Sl/fI0i0h13cRAkmbAJ9ScvNLBu/ilOAzZ3BxlcwZvW4qpwCcCWLR AEb5Td2e/cVw+lkKpjZ1/kc= =0hTt -----END PGP SIGNATURE----- From skvidal at phy.duke.edu Tue Jun 14 17:11:19 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 14 Jun 2005 13:11:19 -0400 Subject: Yum Upgrade Faq In-Reply-To: <1118768454.4719.6.camel@dhollis-lnx.sunera.com> References: <1118642915.19703.52.camel@cutter> <1118768454.4719.6.camel@dhollis-lnx.sunera.com> Message-ID: <1118769079.31680.10.camel@cutter> On Tue, 2005-06-14 at 13:00 -0400, David Hollis wrote: > On Mon, 2005-06-13 at 02:08 -0400, seth vidal wrote: > > I've added a wiki page here: > > http://fedoraproject.org/wiki/YumUpgradeFaq > > > > It's about upgrading from release to release via yum. If you find any > > other odd gotchas - add them there. > > > > -sv > > > I'm finding that even trying to upgrade yum i have problems with > openoffice due to the package name changes. I have: > > libdb_cxx-4.2.so needed by openoffice.org-libs > libedataserver.so.3 needed by openoffice.org > libebook.so.8 needed by openoffice.org > > Looks like I'll need to manually install openoffice.org-core to take > care of those what're you upgrading FROM? Fc3? -sv From matthew at nocturnal.org Tue Jun 14 17:12:13 2005 From: matthew at nocturnal.org (Matthew Lenz) Date: Tue, 14 Jun 2005 12:12:13 -0500 Subject: What next? In-Reply-To: <1117820621.22965.26.camel@opus.phy.duke.edu> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <1117730130.1674.3.camel@weasel.laiskiainen.org> <429FDACF.20608@rueb.com> <1117780095.3488.32.camel@cutter> <1117809250.8385.11.camel@mlenzdesktop> <1117820621.22965.26.camel@opus.phy.duke.edu> Message-ID: <1118769134.4176.10.camel@mlenzdesktop> On Fri, 2005-06-03 at 13:43 -0400, seth vidal wrote: > > I hate to admit it but I remove all the redhat update stuff as well and > > use yum or apt-get (if i'm feeling impatient). I used ubuntu for awhile > > (but ultimately found fedora to be superior) and found their update > > functionality much more usable. > > > when fc4 comes out with yum 2.3.X in it - I'd like to hear your take on > if yum is still coming out slower than apt for your use. > > some very smart people have made it faster in many different ways. > > -sv > > Seth, took me a bit to find this post again but I wanted to let you know that the newest yum is in fact much faster even the 'yum search' which used to be considerably slower than apt. Thanks! :) From florin at andrei.myip.org Tue Jun 14 17:14:25 2005 From: florin at andrei.myip.org (Florin Andrei) Date: Tue, 14 Jun 2005 10:14:25 -0700 Subject: bad practice: not reading the manpage In-Reply-To: <20050614081905.GX8706@redhat.com> References: <1118714579.6098.18.camel@rivendell.home.local> <20050614020819.GA1449@nostromo.devel.redhat.com> <20050614022024.GA7523@thacker.dyndns.org> <1118717587.6098.27.camel@rivendell.home.local> <20050614030903.GA5862@nostromo.devel.redhat.com> <1118719943.6098.46.camel@rivendell.home.local> <20050614040537.GA305@jadzia.bu.edu> <20050614081905.GX8706@redhat.com> Message-ID: <1118769265.6229.9.camel@stantz.corp.sgi.com> On Tue, 2005-06-14 at 09:19 +0100, Tim Waugh wrote: > Precisely. What the original poster is asking for seems to be > equivalent to asking for state to be preserved in this case: > > chkconfig foo off > rpm -e foo > rpm -i foo-1-1.rpm Actually, I was only thinking about this case: chkconfig --del foo rpm -U foo*.rpm # or "yum update foo" Whatever the state, it is obviously lost across such a sweeping change like "rpm -e foo; rpm -i foo*.rpm". One cannot reasonably ask for the state to be preserved in that case. An upgrade, though, is different. I like Michael's idea. "rpm -i" should run chkconfig and do whatever is appropriate to enable/disable the service on certain runlevels, that's fine and natural. But "rpm -U" should do nothing in that regard. After all (I apologize for repeating it over and over again, but I think it's a crucial point), whatever the situation before the upgrade, it was very likely the result of a decision made and an action carried by the human operator. The software should not treat it lightly. I will also have to verify if it's true that certain cronjobs re-enable services that were deleted with chkconfig. That's potentially another source of issues. -- Florin Andrei http://florin.myip.org/ From jkeating at j2solutions.net Tue Jun 14 17:21:47 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 14 Jun 2005 10:21:47 -0700 Subject: Yum Upgrade Faq In-Reply-To: <1118642915.19703.52.camel@cutter> References: <1118642915.19703.52.camel@cutter> Message-ID: <1118769707.13606.63.camel@localhost.localdomain> On Mon, 2005-06-13 at 02:08 -0400, seth vidal wrote: > I've added a wiki page here: > http://fedoraproject.org/wiki/YumUpgradeFaq > > It's about upgrading from release to release via yum. If you find any > other odd gotchas - add them there. This works for going from FC4test3 to FC4 Final as well, I tested on x86 (with a lot of extras and livna installed, so make sure your repos for extras and livna is updated as well). -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- 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 mattdm at mattdm.org Tue Jun 14 17:40:29 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 14 Jun 2005 13:40:29 -0400 Subject: bad practice: not reading the manpage In-Reply-To: <1118769265.6229.9.camel@stantz.corp.sgi.com> References: <1118714579.6098.18.camel@rivendell.home.local> <20050614020819.GA1449@nostromo.devel.redhat.com> <20050614022024.GA7523@thacker.dyndns.org> <1118717587.6098.27.camel@rivendell.home.local> <20050614030903.GA5862@nostromo.devel.redhat.com> <1118719943.6098.46.camel@rivendell.home.local> <20050614040537.GA305@jadzia.bu.edu> <20050614081905.GX8706@redhat.com> <1118769265.6229.9.camel@stantz.corp.sgi.com> Message-ID: <20050614174029.GA31703@jadzia.bu.edu> On Tue, Jun 14, 2005 at 10:14:25AM -0700, Florin Andrei wrote: > After all (I apologize for repeating it over and over again, but I think > it's a crucial point), whatever the situation before the upgrade, it was > very likely the result of a decision made and an action carried by the > human operator. The software should not treat it lightly. I disagree. This is *exactly* the same case as if the user has done rm -f /bin/ls When you upgrade coreutils, it'll fix this by putting /bin/ls back. (Note the correspondence between rm and del -- pretty much the same thing.) It's more consistent for packages to keep doing what they're doing, and for sysadmins to properly use 'chkconfig off'. You're solving the wrong problem. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 81 degrees Fahrenheit. From thacker at math.cornell.edu Tue Jun 14 17:58:07 2005 From: thacker at math.cornell.edu (John Thacker) Date: Tue, 14 Jun 2005 13:58:07 -0400 Subject: bad practice: not reading the manpage In-Reply-To: <1118769265.6229.9.camel@stantz.corp.sgi.com> References: <1118714579.6098.18.camel@rivendell.home.local> <20050614020819.GA1449@nostromo.devel.redhat.com> <20050614022024.GA7523@thacker.dyndns.org> <1118717587.6098.27.camel@rivendell.home.local> <20050614030903.GA5862@nostromo.devel.redhat.com> <1118719943.6098.46.camel@rivendell.home.local> <20050614040537.GA305@jadzia.bu.edu> <20050614081905.GX8706@redhat.com> <1118769265.6229.9.camel@stantz.corp.sgi.com> Message-ID: <20050614175807.GA27689@thacker.dyndns.org> On Tue, Jun 14, 2005 at 10:14:25AM -0700, Florin Andrei wrote: > I like Michael's idea. "rpm -i" should run chkconfig and do whatever is > appropriate to enable/disable the service on certain runlevels, that's > fine and natural. But "rpm -U" should do nothing in that regard. > After all (I apologize for repeating it over and over again, but I think > it's a crucial point), whatever the situation before the upgrade, it was > very likely the result of a decision made and an action carried by the > human operator. The software should not treat it lightly. This would violate rpm's behavior as described by the manpage: "This upgrades or installs the package currently installed to a newer version. This is the same as install, except all other version(s) of the package are removed after the new package is installed." The current behavior is that "rpm -U" is exactly the same as "rpm -i" if the package is not currently installed. (If you want to not install it if it's not currently installed, then you use "rpm -F".) I really can't agree with changing that behavior. If you mean that it should only be added if it's actually being upgraded, as opposed to whenever "rpm -U" is run, then I still have the other objection mentioned in this thread; i.e., chkconfig --del is quite similar to "rm -f /path/to/file", and you probably don't want "rpm -U" to not re-add files which were deleted by the operator. (Although again you might, I suppose.) John Thacker -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From florin at andrei.myip.org Tue Jun 14 18:00:57 2005 From: florin at andrei.myip.org (Florin Andrei) Date: Tue, 14 Jun 2005 11:00:57 -0700 Subject: bad practice: not reading the manpage In-Reply-To: <20050614174029.GA31703@jadzia.bu.edu> References: <1118714579.6098.18.camel@rivendell.home.local> <20050614020819.GA1449@nostromo.devel.redhat.com> <20050614022024.GA7523@thacker.dyndns.org> <1118717587.6098.27.camel@rivendell.home.local> <20050614030903.GA5862@nostromo.devel.redhat.com> <1118719943.6098.46.camel@rivendell.home.local> <20050614040537.GA305@jadzia.bu.edu> <20050614081905.GX8706@redhat.com> <1118769265.6229.9.camel@stantz.corp.sgi.com> <20050614174029.GA31703@jadzia.bu.edu> Message-ID: <1118772057.6229.23.camel@stantz.corp.sgi.com> On Tue, 2005-06-14 at 13:40 -0400, Matthew Miller wrote: > On Tue, Jun 14, 2005 at 10:14:25AM -0700, Florin Andrei wrote: > > After all (I apologize for repeating it over and over again, but I think > > it's a crucial point), whatever the situation before the upgrade, it was > > very likely the result of a decision made and an action carried by the > > human operator. The software should not treat it lightly. > > I disagree. This is *exactly* the same case as if the user has done > > rm -f /bin/ls > > When you upgrade coreutils, it'll fix this by putting /bin/ls back. Oh, come on, how could that be similar? The example is so wrong, I'm not even sure how to approach it. /bin/ls is part of the coreutils package as a fixed, unchangeable component. "Fixed" with regard to sysadmin's actions. You're not supposed to mangle /bin/ls or similar parts of the package, you are supposed to let RPM deal with that. I.e., don't blindly do a "make; make install" in the coreutils source tree if you have an idea of how to improve the /bin/ls executable, but you're supposed to create a package and do an update "properly". The symlinks in /etc/rc*.d however, those are a different story. You are allowed to make changes. They're similar to config files. The user should normally not make changes to the binary files, executables, libraries, etc. and, if changes are made, the package manager is entitled to fix them, as you correctly point out. However, runlevel symlinks, config files, etc. are supposed to be subject to changes by the user/sysadmin. The package manager should not overrule those changes. Case in point, often the config files are left unchaged after a package upgrade, in order to preserve whatever modifications were made by the user. /etc/rc*.d symlinks are the same, since their state is often the result of actions taken by the sysadmin. To let RPM overrule the sysadmin's decisions w.r.t. those symlinks is like letting RPM blindly overwrite config files during "rpm -U" and not save backups of the old files. -- Florin Andrei http://florin.myip.org/ From wesley at bu.edu Tue Jun 14 18:06:53 2005 From: wesley at bu.edu (Wesley Harrell) Date: Tue, 14 Jun 2005 14:06:53 -0400 Subject: nfs-utils rpcsvcgssd and nfs init script redundancy? Message-ID: <42AF1CBD.5090506@bu.edu> According to the changelog in nfs-utils-1.0.6-52 the developer "Changed the nfs.init script to bring rpc.svcgssd up and down, since rpc.svcgssd is only needed with the NFS server is running." However the rpcsvcgssd init script is still added via chkconfig during install *and* is started before nfs. Is this a mistake, or is there a reason the rpcsvcgssd continues to be started through its own init script? From mattdm at mattdm.org Tue Jun 14 18:15:55 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 14 Jun 2005 14:15:55 -0400 Subject: bad practice: not reading the manpage In-Reply-To: <1118772057.6229.23.camel@stantz.corp.sgi.com> References: <20050614020819.GA1449@nostromo.devel.redhat.com> <20050614022024.GA7523@thacker.dyndns.org> <1118717587.6098.27.camel@rivendell.home.local> <20050614030903.GA5862@nostromo.devel.redhat.com> <1118719943.6098.46.camel@rivendell.home.local> <20050614040537.GA305@jadzia.bu.edu> <20050614081905.GX8706@redhat.com> <1118769265.6229.9.camel@stantz.corp.sgi.com> <20050614174029.GA31703@jadzia.bu.edu> <1118772057.6229.23.camel@stantz.corp.sgi.com> Message-ID: <20050614181555.GA1081@jadzia.bu.edu> On Tue, Jun 14, 2005 at 11:00:57AM -0700, Florin Andrei wrote: > /bin/ls is part of the coreutils package as a fixed, unchangeable > component. "Fixed" with regard to sysadmin's actions. You're not > supposed to mangle /bin/ls or similar parts of the package, you are > supposed to let RPM deal with that. And you're not supposed to run chkconfig --del either. (Just 'cause you *can* doesn't mean you *should*.) > The symlinks in /etc/rc*.d however, those are a different story. You are > allowed to make changes. They're similar to config files. Sure. Maybe /bin/ls is bad example, so let's pick another: If I delete /etc/prelink.conf, I'd expect it to come back when I did an upgrade. > To let RPM overrule the sysadmin's decisions w.r.t. those symlinks is > like letting RPM blindly overwrite config files during "rpm -U" and not > save backups of the old files. And, if I modify /etc/prelink.conf, I *do* get a backup. In fact, I get an .rpmnew file. That's the proper behavior. Likewise, if I properly use chkconfig off instead of deleting the configuration information completely, my configuration is preserved. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 81 degrees Fahrenheit. From kas11 at tampabay.rr.com Tue Jun 14 18:42:36 2005 From: kas11 at tampabay.rr.com (kas) Date: Tue, 14 Jun 2005 14:42:36 -0400 Subject: FC4: matrox MGA video driver corrupting display In-Reply-To: <1118763146.8947.257.camel@localhost.localdomain> References: <1118763146.8947.257.camel@localhost.localdomain> Message-ID: <1118774556.30236.7.camel@neptune> On Tue, 2005-06-14 at 17:32 +0200, Dario Lesca wrote: > As soon as the setup process is finished I reboot the system and there's > a bad X graphic interface, so the o.s. is unusable. > > After 4 or 6 reboots the graphic interface is loaded correctly and the > system work great. > > I have found on bugzilla for FC4test[23] this Bug: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=153729 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157556 > > Is this a known error for FC4 ? > there is a bypass or a solution? > The workaround suggested by mharris in 157556 above worked here as shown in the comments. Karen From ivazquez at ivazquez.net Tue Jun 14 18:50:07 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 14 Jun 2005 14:50:07 -0400 Subject: FC4/FE4 feeds Message-ID: <1118775007.31315.1.camel@ignacio.ignacio.lan> I was looking in Liferea today when I noticed that I saw FC3/FE3 and Rawhide stuff, but not FC4/FE4. When will the feeds for those be in place? -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 phy.duke.edu Tue Jun 14 19:34:44 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 14 Jun 2005 15:34:44 -0400 Subject: FC4/FE4 feeds In-Reply-To: <1118775007.31315.1.camel@ignacio.ignacio.lan> References: <1118775007.31315.1.camel@ignacio.ignacio.lan> Message-ID: <1118777684.31680.25.camel@cutter> On Tue, 2005-06-14 at 14:50 -0400, Ignacio Vazquez-Abrams wrote: > I was looking in Liferea today when I noticed that I saw FC3/FE3 and > Rawhide stuff, but not FC4/FE4. When will the feeds for those be in > place? > when I remember to do them ;) thanks for the reminder :) -sv From dhollis at davehollis.com Tue Jun 14 19:56:27 2005 From: dhollis at davehollis.com (David Hollis) Date: Tue, 14 Jun 2005 15:56:27 -0400 Subject: Yum Upgrade Faq In-Reply-To: <1118769079.31680.10.camel@cutter> References: <1118642915.19703.52.camel@cutter> <1118768454.4719.6.camel@dhollis-lnx.sunera.com> <1118769079.31680.10.camel@cutter> Message-ID: <1118778987.4719.11.camel@dhollis-lnx.sunera.com> On Tue, 2005-06-14 at 13:11 -0400, seth vidal wrote: > On Tue, 2005-06-14 at 13:00 -0400, David Hollis wrote: > > On Mon, 2005-06-13 at 02:08 -0400, seth vidal wrote: > > > I've added a wiki page here: > > > http://fedoraproject.org/wiki/YumUpgradeFaq > > > > > > It's about upgrading from release to release via yum. If you find any > > > other odd gotchas - add them there. > > > > > > -sv > > > > > > I'm finding that even trying to upgrade yum i have problems with > > openoffice due to the package name changes. I have: > > > > libdb_cxx-4.2.so needed by openoffice.org-libs > > libedataserver.so.3 needed by openoffice.org > > libebook.so.8 needed by openoffice.org > > > > Looks like I'll need to manually install openoffice.org-core to take > > care of those > > what're you upgrading FROM? Fc3? Yep, FC3. -- David Hollis -------------- 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 phy.duke.edu Tue Jun 14 20:17:53 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 14 Jun 2005 16:17:53 -0400 Subject: What next? In-Reply-To: <1118769134.4176.10.camel@mlenzdesktop> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <1117730130.1674.3.camel@weasel.laiskiainen.org> <429FDACF.20608@rueb.com> <1117780095.3488.32.camel@cutter> <1117809250.8385.11.camel@mlenzdesktop> <1117820621.22965.26.camel@opus.phy.duke.edu> <1118769134.4176.10.camel@mlenzdesktop> Message-ID: <1118780274.31680.35.camel@cutter> > > > > Seth, took me a bit to find this post again but I wanted to let you know > that the newest yum is in fact much faster even the 'yum search' which > used to be considerably slower than apt. Thanks! :) As was pointed out to me - I need to mark down today on my calendar: June 14th - someone on fedora-devel-list said something positive about yum. :) thanks, -sv From skvidal at phy.duke.edu Tue Jun 14 20:03:33 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 14 Jun 2005 16:03:33 -0400 Subject: Yum Upgrade Faq In-Reply-To: <1118778987.4719.11.camel@dhollis-lnx.sunera.com> References: <1118642915.19703.52.camel@cutter> <1118768454.4719.6.camel@dhollis-lnx.sunera.com> <1118769079.31680.10.camel@cutter> <1118778987.4719.11.camel@dhollis-lnx.sunera.com> Message-ID: <1118779413.31680.29.camel@cutter> > > > > what're you upgrading FROM? Fc3? > > Yep, FC3. > what ver of yum were you using to do the upgrade? -sv From dhollis at davehollis.com Tue Jun 14 20:31:08 2005 From: dhollis at davehollis.com (David Hollis) Date: Tue, 14 Jun 2005 16:31:08 -0400 Subject: Yum Upgrade Faq In-Reply-To: <1118778987.4719.11.camel@dhollis-lnx.sunera.com> References: <1118642915.19703.52.camel@cutter> <1118768454.4719.6.camel@dhollis-lnx.sunera.com> <1118769079.31680.10.camel@cutter> <1118778987.4719.11.camel@dhollis-lnx.sunera.com> Message-ID: <1118781068.4719.18.camel@dhollis-lnx.sunera.com> On Tue, 2005-06-14 at 15:56 -0400, David Hollis wrote: > On Tue, 2005-06-14 at 13:11 -0400, seth vidal wrote: > > On Tue, 2005-06-14 at 13:00 -0400, David Hollis wrote: > > > On Mon, 2005-06-13 at 02:08 -0400, seth vidal wrote: > > > > I've added a wiki page here: > > > > http://fedoraproject.org/wiki/YumUpgradeFaq > > > > > > > > It's about upgrading from release to release via yum. If you find any > > > > other odd gotchas - add them there. > > > > > > > > -sv > > > > > > > > > I'm finding that even trying to upgrade yum i have problems with > > > openoffice due to the package name changes. I have: > > > > > > libdb_cxx-4.2.so needed by openoffice.org-libs > > > libedataserver.so.3 needed by openoffice.org > > > libebook.so.8 needed by openoffice.org > > > > > > Looks like I'll need to manually install openoffice.org-core to take > > > care of those > > > > what're you upgrading FROM? Fc3? > > Yep, FC3. And for reference, I had version 1.1.3-11.5.0.fc3 installed. -- David Hollis -------------- 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 kyrre at solution-forge.net Tue Jun 14 20:47:02 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Tue, 14 Jun 2005 22:47:02 +0200 Subject: "I plan to work on..." for FC5 In-Reply-To: References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <1118404276.2934.7.camel@localhost.localdomain> <20050610171354.GE20255@redhat.com> <1118425001.4823.36.camel@localhost.localdomain> Message-ID: <1118782022.4311.22.camel@localhost.localdomain> s?n, 12.06.2005 kl. 08.37 skrev Panu Matilainen: > On Fri, 10 Jun 2005, David Woodhouse wrote: > > > On Fri, 2005-06-10 at 13:13 -0400, Dave Jones wrote: > >> So all I have to do is steal your laptop and phone, and I've got > >> access to all your data ? The auto-login bit scares me a little. > >> Having it lock the screen if you wander off I like the sound of > >> though. > > > > Who runs a password-protected bootloader? You steal my laptop and you've > > got access to all my data anyway. > > That's why people encrypt their laptops, password protected bootloader > wont help at all by itself. > > - Panu - Password protected grub makes sence when you have denied use of boot disks through BIOS, locked the BIOS down, physically locked a machine down so the BIOS can't be reset. Then the grub password makes sure nobody can boot into single user mode or use grub promt to boot removable media. From kas11 at tampabay.rr.com Tue Jun 14 20:57:45 2005 From: kas11 at tampabay.rr.com (kas) Date: Tue, 14 Jun 2005 16:57:45 -0400 Subject: What next? In-Reply-To: <1118780274.31680.35.camel@cutter> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <1117730130.1674.3.camel@weasel.laiskiainen.org> <429FDACF.20608@rueb.com> <1117780095.3488.32.camel@cutter> <1117809250.8385.11.camel@mlenzdesktop> <1117820621.22965.26.camel@opus.phy.duke.edu> <1118769134.4176.10.camel@mlenzdesktop> <1118780274.31680.35.camel@cutter> Message-ID: <1118782665.32499.7.camel@neptune> On Tue, 2005-06-14 at 16:17 -0400, seth vidal wrote: > > As was pointed out to me - I need to mark down today on my calendar: > June 14th - someone on fedora-devel-list said something positive about > yum. > :) > > thanks, > > -sv > I must say that yum has been working magnificently around here lately and on the odd occasion where there was a hickup/operator error, a solution was posted almost immediately. There is no question in my mind that if Fedora is to be the success we all hope it will be, it will be in large part due to the blood, sweat and tears Seth has poured into Yum. Thanks Seth, Karen From skvidal at phy.duke.edu Tue Jun 14 21:06:28 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 14 Jun 2005 17:06:28 -0400 Subject: What next? In-Reply-To: <1118782665.32499.7.camel@neptune> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <1117730130.1674.3.camel@weasel.laiskiainen.org> <429FDACF.20608@rueb.com> <1117780095.3488.32.camel@cutter> <1117809250.8385.11.camel@mlenzdesktop> <1117820621.22965.26.camel@opus.phy.duke.edu> <1118769134.4176.10.camel@mlenzdesktop> <1118780274.31680.35.camel@cutter> <1118782665.32499.7.camel@neptune> Message-ID: <1118783188.31680.39.camel@cutter> On Tue, 2005-06-14 at 16:57 -0400, kas wrote: > On Tue, 2005-06-14 at 16:17 -0400, seth vidal wrote: > > > > > As was pointed out to me - I need to mark down today on my calendar: > > June 14th - someone on fedora-devel-list said something positive about > > yum. > > :) > > > > thanks, > > > > -sv > > > I must say that yum has been working magnificently around here lately and > on the odd occasion where there was a hickup/operator error, a solution > was posted almost immediately. There is no question in my mind that if > Fedora is to be the success we all hope it will be, it will be in large > part due to the blood, sweat and tears Seth has poured into Yum. There lots of folks beyond me working on this now. Take a look at the AUTHORS file in the docs of yum. All of those folks deserve credit. -sv From twells at raleys.com Tue Jun 14 21:09:32 2005 From: twells at raleys.com (Todd Wells) Date: Tue, 14 Jun 2005 14:09:32 -0700 (PDT) Subject: Yum Upgrade Faq In-Reply-To: <1118781068.4719.18.camel@dhollis-lnx.sunera.com> References: <1118642915.19703.52.camel@cutter> <1118768454.4719.6.camel@dhollis-lnx.sunera.com> <1118769079.31680.10.camel@cutter> <1118778987.4719.11.camel@dhollis-lnx.sunera.com> <1118781068.4719.18.camel@dhollis-lnx.sunera.com> Message-ID: Using a similar procedure to the FAQ, which included everything but the yum update yum, I did yum upgrade and get an error - It is looking for libpython, which is installed. #yum upgrade --> Running transaction check --> Processing Dependency: libpython2.3.so.1.0 for package: koffice --> Finished Dependency Resolution Error: Missing Dependency: libpython2.3.so.1.0 is needed by package koffice # rpm -ql python | grep libpython2.3.so.1.0 /usr/lib/libpython2.3.so.1.0 # rpm -q yum yum-2.2.0-0.fc3 I removed koffice, upgraded yum and am trying again. On Tue, 14 Jun 2005, David Hollis wrote: > On Tue, 2005-06-14 at 15:56 -0400, David Hollis wrote: >> On Tue, 2005-06-14 at 13:11 -0400, seth vidal wrote: >>> On Tue, 2005-06-14 at 13:00 -0400, David Hollis wrote: >>>> On Mon, 2005-06-13 at 02:08 -0400, seth vidal wrote: >>>>> I've added a wiki page here: >>>>> http://fedoraproject.org/wiki/YumUpgradeFaq >>>>> >>>>> It's about upgrading from release to release via yum. If you find any >>>>> other odd gotchas - add them there. >>>>> >>>>> -sv >>>> >>>> >>>> I'm finding that even trying to upgrade yum i have problems with >>>> openoffice due to the package name changes. I have: >>>> >>>> libdb_cxx-4.2.so needed by openoffice.org-libs >>>> libedataserver.so.3 needed by openoffice.org >>>> libebook.so.8 needed by openoffice.org >>>> >>>> Looks like I'll need to manually install openoffice.org-core to take >>>> care of those >>> >>> what're you upgrading FROM? Fc3? >> >> Yep, FC3. > > > And for reference, I had version 1.1.3-11.5.0.fc3 installed. > > From skvidal at phy.duke.edu Tue Jun 14 21:15:17 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 14 Jun 2005 17:15:17 -0400 Subject: Yum Upgrade Faq In-Reply-To: References: <1118642915.19703.52.camel@cutter> <1118768454.4719.6.camel@dhollis-lnx.sunera.com> <1118769079.31680.10.camel@cutter> <1118778987.4719.11.camel@dhollis-lnx.sunera.com> <1118781068.4719.18.camel@dhollis-lnx.sunera.com> Message-ID: <1118783717.31680.41.camel@cutter> On Tue, 2005-06-14 at 14:09 -0700, Todd Wells wrote: > Using a similar procedure to the FAQ, which included everything but the yum > update yum, I did yum upgrade and get an error - It is looking for libpython, > which is installed. > > #yum upgrade > --> Running transaction check > --> Processing Dependency: libpython2.3.so.1.0 for package: koffice > --> Finished Dependency Resolution > Error: Missing Dependency: libpython2.3.so.1.0 is needed by package > koffice > # rpm -ql python | grep libpython2.3.so.1.0 > /usr/lib/libpython2.3.so.1.0 > # rpm -q yum > yum-2.2.0-0.fc3 > > I removed koffice, upgraded yum and am trying again. koffice was removed from core and not picked up by anyone else and/or obsoleted so it will need to be removed to upgrade your whole system. -sv From mwiktowy at gmx.net Tue Jun 14 22:57:50 2005 From: mwiktowy at gmx.net (Michael Wiktowy) Date: Tue, 14 Jun 2005 18:57:50 -0400 Subject: What next? In-Reply-To: <1118783188.31680.39.camel@cutter> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <1117730130.1674.3.camel@weasel.laiskiainen.org> <429FDACF.20608@rueb.com> <1117780095.3488.32.camel@cutter> <1117809250.8385.11.camel@mlenzdesktop> <1117820621.22965.26.camel@opus.phy.duke.edu> <1118769134.4176.10.camel@mlenzdesktop> <1118780274.31680.35.camel@cutter> <1118782665.32499.7.camel@neptune> <1118783188.31680.39.camel@cutter> Message-ID: <42AF60EE.1030606@gmx.net> seth vidal wrote: >On Tue, 2005-06-14 at 16:57 -0400, kas wrote: > > >>On Tue, 2005-06-14 at 16:17 -0400, seth vidal wrote: >> >> >> >>>As was pointed out to me - I need to mark down today on my calendar: >>>June 14th - someone on fedora-devel-list said something positive about >>>yum. >>>:) >>> >>>thanks, >>> >>>-sv >>> >>> >>> >>I must say that yum has been working magnificently around here lately and >>on the odd occasion where there was a hickup/operator error, a solution >>was posted almost immediately. There is no question in my mind that if >>Fedora is to be the success we all hope it will be, it will be in large >>part due to the blood, sweat and tears Seth has poured into Yum. >> >> > >There lots of folks beyond me working on this now. >Take a look at the AUTHORS file in the docs of yum. >All of those folks deserve credit. > >-sv > > Cheer *3 for the yum authors (and the FOSS developers in general). While these lists always seem so negative since they are typically used for hashing out problems, I suspect there is a silent happy majority out there very appreciative of all the work contributed for the greater good. Keep up the great work. /Mike From manolo at miconexion.com Tue Jun 14 23:09:33 2005 From: manolo at miconexion.com (Manuel Moreno) Date: Wed, 15 Jun 2005 00:09:33 +0100 Subject: What next? In-Reply-To: <1118783188.31680.39.camel@cutter> References: <1117660299.31018.61.camel@cutter> <1117662248.5219.15.camel@localhost.localdomain> <604aa791050601162840b05c06@mail.gmail.com> <1117730130.1674.3.camel@weasel.laiskiainen.org> <429FDACF.20608@rueb.com> <1117780095.3488.32.camel@cutter> <1117809250.8385.11.camel@mlenzdesktop> <1117820621.22965.26.camel@opus.phy.duke.edu> <1118769134.4176.10.camel@mlenzdesktop> <1118780274.31680.35.camel@cutter> <1118782665.32499.7.camel@neptune> <1118783188.31680.39.camel@cutter> Message-ID: <42AF63AD.3030106@miconexion.com> seth vidal wrote: >On Tue, 2005-06-14 at 16:57 -0400, kas wrote: > > >>On Tue, 2005-06-14 at 16:17 -0400, seth vidal wrote: >> >> >> >>>As was pointed out to me - I need to mark down today on my calendar: >>>June 14th - someone on fedora-devel-list said something positive about >>>yum. >>>:) >>> >>>thanks, >>> >>>-sv >>> >>> >>> >>I must say that yum has been working magnificently around here lately and >>on the odd occasion where there was a hickup/operator error, a solution >>was posted almost immediately. There is no question in my mind that if >>Fedora is to be the success we all hope it will be, it will be in large >>part due to the blood, sweat and tears Seth has poured into Yum. >> >> > >There lots of folks beyond me working on this now. >Take a look at the AUTHORS file in the docs of yum. >All of those folks deserve credit. > >-sv > > > > I'm using yum in a bi-arch environment and I have no complaints. Well indeed it works like a charm. -- Manuel Moreno manolo at miconexion.com From webmaster at margo.bijoux.nom.br Tue Jun 14 23:25:24 2005 From: webmaster at margo.bijoux.nom.br (Pedro Fernandes Macedo) Date: Tue, 14 Jun 2005 20:25:24 -0300 Subject: iso xdeltas FC4-test3 -> FC4 ? In-Reply-To: <20050614130435.510285ce@nausicaa.camperquake.de> References: <1cef3e9505061308476ec9c7a2@mail.gmail.com> <20050613191905.525e72da@nausicaa.camperquake.de> <42AE2170.6010101@margo.bijoux.nom.br> <20050614130435.510285ce@nausicaa.camperquake.de> Message-ID: <42AF6764.5000703@margo.bijoux.nom.br> Ralf Ertzinger wrote: >Hi. > > >What jigdo version did you use? The current CVS does not really like >the GCC4 compiler. > > > I was using the FC3 version , since I hadnt installed FC4 yet. Will have a look into this later, but first need to install FC4 on my work machine and report some problems I had on my work machine.. -- Pedro Macedo From dhollis at davehollis.com Wed Jun 15 01:04:16 2005 From: dhollis at davehollis.com (David Hollis) Date: Tue, 14 Jun 2005 21:04:16 -0400 Subject: Yum Upgrade Faq In-Reply-To: <1118779413.31680.29.camel@cutter> References: <1118642915.19703.52.camel@cutter> <1118768454.4719.6.camel@dhollis-lnx.sunera.com> <1118769079.31680.10.camel@cutter> <1118778987.4719.11.camel@dhollis-lnx.sunera.com> <1118779413.31680.29.camel@cutter> Message-ID: <1118797456.5618.1.camel@dhollis-lnx.sunera.com> On Tue, 2005-06-14 at 16:03 -0400, seth vidal wrote: > > > > > > what're you upgrading FROM? Fc3? > > > > Yep, FC3. > > > > what ver of yum were you using to do the upgrade? > > -sv > > yum-2.2.0-0.fc3 is what I was starting with. After pulling down the new fedora-release and installing it, I tried to yum -y update yum. It wanted to pull in a large amount of stuff which led to the openoffice problem. -- David Hollis -------------- 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 TQMcube.com Wed Jun 15 02:07:28 2005 From: Fedora at TQMcube.com (David Cary Hart) Date: Tue, 14 Jun 2005 22:07:28 -0400 Subject: Yum Upgrade Faq In-Reply-To: <1118797456.5618.1.camel@dhollis-lnx.sunera.com> References: <1118642915.19703.52.camel@cutter> <1118768454.4719.6.camel@dhollis-lnx.sunera.com> <1118769079.31680.10.camel@cutter> <1118778987.4719.11.camel@dhollis-lnx.sunera.com> <1118779413.31680.29.camel@cutter> <1118797456.5618.1.camel@dhollis-lnx.sunera.com> Message-ID: <1118801248.9299.53.camel@dch.TQMcube.com> On Tue, 2005-06-14 at 21:04 -0400, David Hollis wrote: > > > > yum-2.2.0-0.fc3 is what I was starting with. After pulling down the > new fedora-release and installing it, I tried to yum -y update yum. It > wanted to pull in a large amount of stuff which led to the openoffice > problem. > Is there a listing somewhere of known issues. FC4 breaks yumex which is no big deal. Moreover, I was unable to install madwifi on my laptop. On the other hand, I'm concerned about things like leafnode. I'm testing rbldnsd on a workstation and it seems to be fine. I'm thinking that I should wait a few weeks before updating the primary server. -- * Eliminate Spam: http://www.TQMcube.com/spam_trap.htm * RBLDNSD HowTo: http://www.TQMcube.com/rbldnsd.htm * Multi-RBL Check: http://www.TQMcube.com/rblcheck.htm From mattdm at mattdm.org Wed Jun 15 02:43:30 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 14 Jun 2005 22:43:30 -0400 Subject: Yum Upgrade Faq In-Reply-To: <1118801248.9299.53.camel@dch.TQMcube.com> References: <1118642915.19703.52.camel@cutter> <1118768454.4719.6.camel@dhollis-lnx.sunera.com> <1118769079.31680.10.camel@cutter> <1118778987.4719.11.camel@dhollis-lnx.sunera.com> <1118779413.31680.29.camel@cutter> <1118797456.5618.1.camel@dhollis-lnx.sunera.com> <1118801248.9299.53.camel@dch.TQMcube.com> Message-ID: <20050615024330.GA23495@jadzia.bu.edu> On Tue, Jun 14, 2005 at 10:07:28PM -0400, David Cary Hart wrote: > Is there a listing somewhere of known issues. FC4 breaks yumex which is > no big deal. Moreover, I was unable to install madwifi on my laptop. On For yumex: have you tried this: -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 81 degrees Fahrenheit. From skvidal at phy.duke.edu Wed Jun 15 07:07:52 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 15 Jun 2005 03:07:52 -0400 Subject: Yum Upgrade Faq In-Reply-To: <1118797456.5618.1.camel@dhollis-lnx.sunera.com> References: <1118642915.19703.52.camel@cutter> <1118768454.4719.6.camel@dhollis-lnx.sunera.com> <1118769079.31680.10.camel@cutter> <1118778987.4719.11.camel@dhollis-lnx.sunera.com> <1118779413.31680.29.camel@cutter> <1118797456.5618.1.camel@dhollis-lnx.sunera.com> Message-ID: <1118819272.3032.84.camel@cutter> > yum-2.2.0-0.fc3 is what I was starting with. After pulling down the > new fedora-release and installing it, I tried to yum -y update yum. It > wanted to pull in a large amount of stuff which led to the openoffice > problem. okay - just run: yum upgrade and see what it does. -sv From buildsys at redhat.com Wed Jun 15 11:20:56 2005 From: buildsys at redhat.com (Build System) Date: Wed, 15 Jun 2005 07:20:56 -0400 Subject: rawhide report: 20050615 changes Message-ID: <200506151120.j5FBKu9f002628@porkchop.devel.redhat.com> New package cairo A vector graphics library Updated Packages: 4Suite-1.0-9.b1 --------------- * Sun Jun 12 2005 Miloslav Trmac - 1.0-9.b1 - Ship COPYRIGHT file - Use bdist_install like upstream does, instead of patching the build scripts audit-0.9.5-1 ------------- * Tue Jun 14 2005 Steve Grubb 0.9.5-1 - interpret socketcall & ipc based on a0 in ausearch - change call sequence to make user space messages faster - update return val for auditctl device-mapper-1.01.03-1.0 ------------------------- * Mon Jun 13 2005 Alasdair Kergon - 1.01.03-1.0 - Reinstate selinux support. doxygen-1:1.4.3-1 ----------------- * Tue Jun 14 2005 Than Ngo 1.4.3-1 - 1.4.3 hplip-0.9.3-4 ------------- * Tue Jun 14 2005 Tim Waugh 0.9.3-4 - Conflicts: hpijs from before this package provided it. - Conflicts: system-config-printer < 0.6.132 (i.e. before HPLIP support was added) jakarta-commons-collections-0:3.1-2jpp_1fc ------------------------------------------ * Tue Jun 14 2005 Gary Benson - 0:3.1-2jpp_1fc - Remove jarfiles from the tarball. * Wed May 25 2005 Gary Benson - 0:3.1-2jpp - Do not fetch stuff from sun.com during javadoc generation. - Add build dependency on ant-junit. jakarta-commons-el-0:1.0-4jpp_1fc --------------------------------- * Tue Jun 14 2005 Gary Benson - 0:1.0-4jpp_1fc - Remove build-depencency on log4j. * Thu May 26 2005 Gary Benson - 0:1.0-4jpp - Don't bundle servletapi sources (which weren't used anyway). kdebase-6:3.4.1-0.fc4.1 ----------------------- * Mon Jun 13 2005 Than Ngo 3.4.1-0.fc4.1 - 3.4.1 - update pam configuration for the new audit system #159333 * Tue May 03 2005 Than Ngo 6:3.4.0-7 - fix broken kde-essential.menu * Tue Apr 19 2005 Than Ngo 6:3.4.0-6 - apply kdebase-3.4.0rc1-konsole-keymap.patch to change backspace key to ASCII-DEL, thanks to j.w.r.degoede at hhs.nl libsoup-2.2.3-4 --------------- * Tue Jun 14 2005 David Malcolm - 2.2.3-4 - add patch for NTLM domains (#160071) * Sun Apr 24 2005 Florian La Roche - rebuild for new gnutls lvm2-2.01.12-1.0 ---------------- * Tue Jun 14 2005 Alasdair Kergon - 2.01.12-1.0 - New version upstream with a lot of fixes and enhancements. * Wed Apr 27 2005 Alasdair Kergon - 2.01.08-2.1 - Add /etc/lvm * Wed Apr 27 2005 Alasdair Kergon - 2.01.08-2.0 - No longer abort read operations if archive/backup directories aren't there. - Add runtime directories and file to the package. lvm2-cluster-2.01.09-5.0 ------------------------ * Tue Jun 14 2005 Alasdair Kergon - 2.01.09-5.0 - Couple of fixes to clvmd file descriptor closing. - Fix potential spin loop in clvmd. - Add lvmconf binary to enable/disable clustering. m2crypto-0.13-5 --------------- * Tue Jun 14 2005 Miloslav Trmac - 0.13-5 - Better fix for #159898, by Dan Williams openoffice.org-1:1.9.109-5.2.0.fc5 ---------------------------------- * Tue Jun 14 2005 Caolan McNamara - 1:1.9.109-5 - drop unnecessary openoffice.org-1.9.103.oooXXXXX.installation.disable-epm.fix.patch - add simple crash report output, not that there are any crashs you understand * Tue Jun 14 2005 Caolan McNamara - 1:1.9.109-4 - add Bengali langpack - make a stable /usr/lib/openoffice.org2.0 dir - make openoffice.org-1.9.108.ooo9290.goodies.epstoepdf.patch paranoid - enable failure on rpmbuild test for executable stack - drop integrated openoffice.org-1.9.89.ooo46912.setjmpoutsidenamespace.binfilter.patch * Tue Jun 14 2005 Caolan McNamara - 1:1.9.109-3 - add openoffice.org-1.9.108.oooXXXXX.pyuno.pushrpath.patch - rejig build to use current splashscreen - readd openoffice.org-1.9.88.NONE.gcc3gcj4.patch - add openoffice.org-1.9.108.ooo9290.goodies.epstoepdf.patch for rh#142535# qt-1:3.3.4-15 ------------- * Tue May 24 2005 Than Ngo 1:3.3.4-15 - add better fix for #156977, thanks to trolltech - apply patch to fix keyReleaseEvent problem #156572 regexp-0:1.3-2jpp_2fc --------------------- * Tue Jun 14 2005 Gary Benson 0:1.3-2jpp_2fc - Remove jarfile from the tarball. selinux-policy-strict-1.23.18-6 ------------------------------- * Mon Jun 13 2005 Dan Walsh 1.23.18-6 - Further cleanup of user separation patches from Ivan sysreport-1.4.1-3 ----------------- * Tue Jun 14 2005 Than Ngo 1.4.1-3 - don't include sensitive data #159502 - collect exim/nis/cluster/inittab/maillog/shell/ipcs/nscd/udev From dimi at lattica.com Wed Jun 15 11:48:04 2005 From: dimi at lattica.com (Dimi Paun) Date: Wed, 15 Jun 2005 07:48:04 -0400 Subject: Yum Upgrade Faq In-Reply-To: <1118819272.3032.84.camel@cutter> References: <1118642915.19703.52.camel@cutter> <1118768454.4719.6.camel@dhollis-lnx.sunera.com> <1118769079.31680.10.camel@cutter> <1118778987.4719.11.camel@dhollis-lnx.sunera.com> <1118779413.31680.29.camel@cutter> <1118797456.5618.1.camel@dhollis-lnx.sunera.com> <1118819272.3032.84.camel@cutter> Message-ID: <1118836084.4994.15.camel@dimi> On Wed, 2005-06-15 at 03:07 -0400, seth vidal wrote: > okay - just run: > yum upgrade > > and see what it does. I'm having a bit of a problem too: [root at dimi ~]# rpm -e kernel-utils --> Processing Dependency: kernel-utils for package: kernel-smp --> Processing Dependency: kernel-utils for package: kernel --> Processing Dependency: kernel-utils for package: kernel --> Finished Dependency Resolution Error: Missing Dependency: kernel-utils is needed by package kernel Error: Missing Dependency: kernel-utils is needed by package kernel-smp Here are the details: [root at dimi ~]# rpm -q kernel-utils kernel-utils-2.4-13.1.49_FC3 [root at dimi ~]# rpm -e kernel-utils-2.4-13.1.49_FC3 error: Failed dependencies: kernel-utils is needed by (installed) lm_sensors-2.8.7-2.i386 kernel-utils is needed by (installed) kernel-2.6.11-1.14_FC3.i686 kernel-utils is needed by (installed) kernel-smp-2.6.11-1.27_FC3.i686 kernel-utils is needed by (installed) kernel-2.6.11-1.27_FC3.i686 Why is kernel-2.6.11 dependent on kernel-utils-2.4.13 I don't know... -- Dimi Paun Lattica, Inc. From sundaram at redhat.com Wed Jun 15 11:53:18 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 15 Jun 2005 17:23:18 +0530 Subject: Yum Upgrade Faq In-Reply-To: <1118836084.4994.15.camel@dimi> References: <1118642915.19703.52.camel@cutter> <1118768454.4719.6.camel@dhollis-lnx.sunera.com> <1118769079.31680.10.camel@cutter> <1118778987.4719.11.camel@dhollis-lnx.sunera.com> <1118779413.31680.29.camel@cutter> <1118797456.5618.1.camel@dhollis-lnx.sunera.com> <1118819272.3032.84.camel@cutter> <1118836084.4994.15.camel@dimi> Message-ID: <42B016AE.4030103@redhat.com> Dimi Paun wrote: >On Wed, 2005-06-15 at 03:07 -0400, seth vidal wrote: > > >>okay - just run: >>yum upgrade >> >>and see what it does. >> >> > >I'm having a bit of a problem too: > >[root at dimi ~]# rpm -e kernel-utils >--> Processing Dependency: kernel-utils for package: kernel-smp >--> Processing Dependency: kernel-utils for package: kernel >--> Processing Dependency: kernel-utils for package: kernel >--> Finished Dependency Resolution >Error: Missing Dependency: kernel-utils is needed by package kernel >Error: Missing Dependency: kernel-utils is needed by package kernel-smp > >Here are the details: > >[root at dimi ~]# rpm -q kernel-utils >kernel-utils-2.4-13.1.49_FC3 >[root at dimi ~]# rpm -e kernel-utils-2.4-13.1.49_FC3 >error: Failed dependencies: > kernel-utils is needed by (installed) lm_sensors-2.8.7-2.i386 > kernel-utils is needed by (installed) kernel-2.6.11-1.14_FC3.i686 > kernel-utils is needed by (installed) kernel-smp-2.6.11-1.27_FC3.i686 > kernel-utils is needed by (installed) kernel-2.6.11-1.27_FC3.i686 > >Why is kernel-2.6.11 dependent on kernel-utils-2.4.13 I don't know... > > > Its documented well in http://fedoraproject.org/wiki/YumUpgradeFaq regards Rahul From dhollis at davehollis.com Wed Jun 15 12:06:49 2005 From: dhollis at davehollis.com (David Hollis) Date: Wed, 15 Jun 2005 08:06:49 -0400 Subject: Yum Upgrade Faq In-Reply-To: <1118819272.3032.84.camel@cutter> References: <1118642915.19703.52.camel@cutter> <1118768454.4719.6.camel@dhollis-lnx.sunera.com> <1118769079.31680.10.camel@cutter> <1118778987.4719.11.camel@dhollis-lnx.sunera.com> <1118779413.31680.29.camel@cutter> <1118797456.5618.1.camel@dhollis-lnx.sunera.com> <1118819272.3032.84.camel@cutter> Message-ID: <1118837209.5618.8.camel@dhollis-lnx.sunera.com> On Wed, 2005-06-15 at 03:07 -0400, seth vidal wrote: > > yum-2.2.0-0.fc3 is what I was starting with. After pulling down the > > new fedora-release and installing it, I tried to yum -y update yum. It > > wanted to pull in a large amount of stuff which led to the openoffice > > problem. > > okay - just run: > yum upgrade > > and see what it does. > > -sv Unfortunately, I just pulled out OO and the upgrade went fine. My next question, though really not yum related, is: What is the proper, recommended, cleanest, easiest, safest way to upgrade PostgreSQL since we've gone from 7.4.x to 8.0.x? This certainly is something that can bite a lot of folks that don't know that it won't start after the upgrade. -- David Hollis -------------- 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 dwmw2 at infradead.org Wed Jun 15 12:34:17 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 15 Jun 2005 13:34:17 +0100 Subject: "I plan to work on..." for FC5 In-Reply-To: <200506110905.00788.symbiont@berlios.de> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <200506102359.36554.symbiont@berlios.de> <20050610233226.GH18279@devserv.devel.redhat.com> <200506110905.00788.symbiont@berlios.de> Message-ID: <1118838857.22181.79.camel@hades.cambridge.redhat.com> On Sat, 2005-06-11 at 09:05 +0800, Jeff Pitman wrote: > When I nuke the modules out, I get the above response. I have this > in /etc/modprobe.conf: > > alias net-pf-31 bluez # modprobe net-pf-31 FATAL: Module bluez not found. It should be 'bluetooth' not 'bluez'. -- dwmw2 From skvidal at phy.duke.edu Wed Jun 15 12:56:22 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 15 Jun 2005 08:56:22 -0400 Subject: Yum Upgrade Faq In-Reply-To: <1118837209.5618.8.camel@dhollis-lnx.sunera.com> References: <1118642915.19703.52.camel@cutter> <1118768454.4719.6.camel@dhollis-lnx.sunera.com> <1118769079.31680.10.camel@cutter> <1118778987.4719.11.camel@dhollis-lnx.sunera.com> <1118779413.31680.29.camel@cutter> <1118797456.5618.1.camel@dhollis-lnx.sunera.com> <1118819272.3032.84.camel@cutter> <1118837209.5618.8.camel@dhollis-lnx.sunera.com> Message-ID: <1118840182.3032.89.camel@cutter> > Unfortunately, I just pulled out OO and the upgrade went fine. My next > question, though really not yum related, is: What is the proper, > recommended, cleanest, easiest, safest way to upgrade PostgreSQL since > we've gone from 7.4.x to 8.0.x? This certainly is something that can > bite a lot of folks that don't know that it won't start after the > upgrade. > I'm afraid I don't have much experience with postgresql upgrades. anyone else know? -sv From huw-l at moving-picture.com Wed Jun 15 13:37:46 2005 From: huw-l at moving-picture.com (Huw Lynes) Date: Wed, 15 Jun 2005 14:37:46 +0100 Subject: Xen x86_64 timescale? In-Reply-To: <9f50a7a0050614062466d24221@mail.gmail.com> References: <1118740254.3685.3.camel@wingnut.mpc.local> <9f50a7a0050614062466d24221@mail.gmail.com> Message-ID: <1118842666.3685.31.camel@wingnut.mpc.local> On Tue, 2005-06-14 at 14:24, Jerone Young wrote: > As one who is working on it, Xen x86_64 will not be ready till Xen > 3.0. Right now Xen x86_64 is not even ready for full blown testing. > Time schedule is for Xen 3.0 right now. > Thanks, I guess we'll persevere with UML for the moment. -- | Huw Lynes | The Moving Picture Company | | System Administrator | 127 Wardour Street | |.........................| London, W1F 0NL | From glandvador at yahoo.com Wed Jun 15 13:28:30 2005 From: glandvador at yahoo.com (Gland Vador) Date: Wed, 15 Jun 2005 15:28:30 +0200 Subject: Upgrade through network Message-ID: Hello, Some thoughts about installing/upgrading the fedora distribution. This morning (before going to work) I want to launch the upgrade of my fc3 to the newest and greatest. So well, in order to minimize my download I want to do it through the net. I burned the rescue CD and boot on it. I then choose the ftp method, the mirror address and then, well then I wait in front of my screen 25 minutes reading "retrieving stage2.img". After that, some screens later, I was stuck with the message "reading packages list". After waiting 5 minutes, I left for work. Definitely, there should be some progress meters, just to tell how much time it will take. Also, there should be an ISO image, something like the rescue CD, containing all this informations, to not wait so much time, pressing "next", just to start real upgrading. Real upgrading, I don't care, because I don't need to be here. Edd. From matthew at nocturnal.org Wed Jun 15 14:53:04 2005 From: matthew at nocturnal.org (Matthew Lenz) Date: Wed, 15 Jun 2005 09:53:04 -0500 Subject: updates list? Message-ID: <1118847184.17027.5.camel@mlenzdesktop> Is there a list were updates to fedora are detailed when they are released? For example, where is the information about why xorg was updated for fc4, etc. From sundaram at redhat.com Wed Jun 15 15:04:16 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 15 Jun 2005 20:34:16 +0530 Subject: updates list? In-Reply-To: <1118847184.17027.5.camel@mlenzdesktop> References: <1118847184.17027.5.camel@mlenzdesktop> Message-ID: <42B04370.6000504@redhat.com> Matthew Lenz wrote: >Is there a list were updates to fedora are detailed when they are >released? For example, where is the information about why xorg was >updated for fc4, etc. > > If you are talking about the list of package changes see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160211 If you are looking for rationale for all package changes then I will work on it for the next release. Any help is most welcome regards Rahul From dr at cluenet.de Wed Jun 15 15:18:34 2005 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 15 Jun 2005 17:18:34 +0200 Subject: What next? In-Reply-To: References: Message-ID: <20050615151834.GA10464@srv01.cluenet.de> On Wed, Jun 01, 2005 at 01:59:19PM -0400, Elliot Lee wrote: > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > Extras 5 - what major features are you willing to put effort into? - Ability to fully configure IPv6 networking in Anaconda (static IP, stateless autoconfig, DHCPv6, listen to RAs or static default route, etc.pp) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From os at sumu.org Wed Jun 15 15:20:43 2005 From: os at sumu.org (Oskari Saarenmaa) Date: Wed, 15 Jun 2005 18:20:43 +0300 Subject: Yum Upgrade Faq In-Reply-To: <1118840182.3032.89.camel@cutter> References: <1118642915.19703.52.camel@cutter> <1118768454.4719.6.camel@dhollis-lnx.sunera.com> <1118769079.31680.10.camel@cutter> <1118778987.4719.11.camel@dhollis-lnx.sunera.com> <1118779413.31680.29.camel@cutter> <1118797456.5618.1.camel@dhollis-lnx.sunera.com> <1118819272.3032.84.camel@cutter> <1118837209.5618.8.camel@dhollis-lnx.sunera.com> <1118840182.3032.89.camel@cutter> Message-ID: <20050615152043.GA1903@shadow.sumu.org> On Wed, Jun 15, 2005 at 08:56:22AM -0400, seth vidal wrote: > > Unfortunately, I just pulled out OO and the upgrade went fine. My next > > question, though really not yum related, is: What is the proper, > > recommended, cleanest, easiest, safest way to upgrade PostgreSQL since > > we've gone from 7.4.x to 8.0.x? This certainly is something that can > > bite a lot of folks that don't know that it won't start after the > > upgrade. > > > > I'm afraid I don't have much experience with postgresql upgrades. > > anyone else know? Here are the steps I have usually used to upgrade my PostgreSQL installations: first dump the old database, upgrade the system and create a fresh database, and finally reload the old data in the new database. # su postgres -c "pg_dumpall" > /var/lib/pgsql/backups/pg-data-7.4.dump # service postgresql stop # mv /var/lib/pgsql/data /var/lib/pgsql/backups/pg-data-7.4 # yum update # service postgresql start # su postgres -c "psql -U postgres template1" < /var/lib/pgsql/backups/pg-data-7.4.dump Note that you will have to manually update the *.conf files in /var/lib/pgsql/data as the old version's configuration files are not neccessarily compatible with the new version. I am not sure if 7.4 config files can be used with 8.0, but at least version 7.3's configs weren't usable in a 7.4 installation. Also some of the SQL in your table defaults or custom functions might have changed its meaning, so you should check your upgraded database to make sure that things are as expected. For example in 7.3 or 7.4 update the meaning of 'now' as a column default changed to mean now() at the table creation time instead of row creation time, and the fix was to default to now() instead of 'now'. So I don't think there really is a totally safe way to upgrade a PostgreSQL installation, and I guess that's why the RPM doesn't do it automatically. Cheers, Oskari From matthew at nocturnal.org Wed Jun 15 15:25:32 2005 From: matthew at nocturnal.org (Matthew Lenz) Date: Wed, 15 Jun 2005 10:25:32 -0500 Subject: updates list? In-Reply-To: <42B04370.6000504@redhat.com> References: <1118847184.17027.5.camel@mlenzdesktop> <42B04370.6000504@redhat.com> Message-ID: <1118849132.17027.22.camel@mlenzdesktop> On Wed, 2005-06-15 at 20:34 +0530, Rahul Sundaram wrote: > Matthew Lenz wrote: > > >Is there a list were updates to fedora are detailed when they are > >released? For example, where is the information about why xorg was > >updated for fc4, etc. > > > > > If you are talking about the list of package changes see > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160211 > > If you are looking for rationale for all package changes then I will > work on it for the next release. Any help is most welcome > > > regards > Rahul > I'm referring to updates-released. I remember the errata that used to be on redhat's website in the pre-fedora days. It was nice to know why something was being updated. From sundaram at redhat.com Wed Jun 15 15:28:27 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 15 Jun 2005 20:58:27 +0530 Subject: updates list? In-Reply-To: <1118849132.17027.22.camel@mlenzdesktop> References: <1118847184.17027.5.camel@mlenzdesktop> <42B04370.6000504@redhat.com> <1118849132.17027.22.camel@mlenzdesktop> Message-ID: <42B0491B.8000605@redhat.com> Hi >I'm referring to updates-released. I remember the errata that used to >be on redhat's website in the pre-fedora days. It was nice to know why >something was being updated. > > You can read the fedora announcement list or fedoranews.org or check the rpm changelog regards Rahul From matthew at nocturnal.org Wed Jun 15 15:41:14 2005 From: matthew at nocturnal.org (Matthew Lenz) Date: Wed, 15 Jun 2005 10:41:14 -0500 Subject: updates list? In-Reply-To: <42B0491B.8000605@redhat.com> References: <1118847184.17027.5.camel@mlenzdesktop> <42B04370.6000504@redhat.com> <1118849132.17027.22.camel@mlenzdesktop> <42B0491B.8000605@redhat.com> Message-ID: <1118850074.17027.24.camel@mlenzdesktop> None of those lists have ever announced any of the FC4 changes thus far. Atleast according to the mailman archives and MARC. Is there anyway to read the changelog without downloading the updates first? On Wed, 2005-06-15 at 20:58 +0530, Rahul Sundaram wrote: > Hi > > >I'm referring to updates-released. I remember the errata that used to > >be on redhat's website in the pre-fedora days. It was nice to know why > >something was being updated. > > > > > You can read the fedora announcement list or fedoranews.org or check > the rpm changelog > > regards > Rahul > From jspaleta at gmail.com Wed Jun 15 15:46:13 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 15 Jun 2005 11:46:13 -0400 Subject: updates list? In-Reply-To: <1118847184.17027.5.camel@mlenzdesktop> References: <1118847184.17027.5.camel@mlenzdesktop> Message-ID: <604aa79105061508467ee26f15@mail.gmail.com> On 6/15/05, Matthew Lenz wrote: > Is there a list were updates to fedora are detailed when they are > released? For example, where is the information about why xorg was > updated for fc4, etc. there SHOULD be annoucements in fedora-annouce-list for each 'set' of packages in updates-released. Unfortunately the creation of annoucement text is not automated and maintainers have to remember to provide the annoucement text and that doesn't always happen. The annoucement text can lag the release of the packages. If an update goes without an annoucement for a few days its appropriate to file a bug report in an effort to remind the maintainer to produce the annoucement text. Long term i think everyone agrees that some sort of infrastructure and client tools that expose notification text to users is a good idea, but i don't think its an immediate priority considering other issue. -jef From dhollis at davehollis.com Wed Jun 15 17:32:50 2005 From: dhollis at davehollis.com (David Hollis) Date: Wed, 15 Jun 2005 13:32:50 -0400 Subject: Yum Upgrade Faq In-Reply-To: <20050615152043.GA1903@shadow.sumu.org> References: <1118642915.19703.52.camel@cutter> <1118768454.4719.6.camel@dhollis-lnx.sunera.com> <1118769079.31680.10.camel@cutter> <1118778987.4719.11.camel@dhollis-lnx.sunera.com> <1118779413.31680.29.camel@cutter> <1118797456.5618.1.camel@dhollis-lnx.sunera.com> <1118819272.3032.84.camel@cutter> <1118837209.5618.8.camel@dhollis-lnx.sunera.com> <1118840182.3032.89.camel@cutter> <20050615152043.GA1903@shadow.sumu.org> Message-ID: <1118856771.5057.3.camel@dhollis-lnx.sunera.com> On Wed, 2005-06-15 at 18:20 +0300, Oskari Saarenmaa wrote: > > Note that you will have to manually update the *.conf files in > /var/lib/pgsql/data as the old version's configuration files are not > neccessarily compatible with the new version. I am not sure if 7.4 config > files can be used with 8.0, but at least version 7.3's configs weren't > usable in a 7.4 installation. > > Also some of the SQL in your table defaults or custom functions might have > changed its meaning, so you should check your upgraded database to make sure > that things are as expected. For example in 7.3 or 7.4 update the meaning > of 'now' as a column default changed to mean now() at the table creation > time instead of row creation time, and the fix was to default to now() > instead of 'now'. > > So I don't think there really is a totally safe way to upgrade a PostgreSQL > installation, and I guess that's why the RPM doesn't do it automatically. > This is pretty good stuff and should probably be included on the Wiki. I can only imagine how many folks are going to be bitten by the PG upgrade. -- David Hollis -------------- 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 wir-sind-cool.org Wed Jun 15 17:41:27 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 15 Jun 2005 19:41:27 +0200 Subject: Debugging tipps anyone? In-Reply-To: <20050614121638.19a386c8.fedora@wir-sind-cool.org> References: <20050614121638.19a386c8.fedora@wir-sind-cool.org> Message-ID: <20050615194127.42eff28f.fedora@wir-sind-cool.org> On Tue, 14 Jun 2005 12:16:38 +0200, Michael Schwendt wrote: > This is the result of last night's attempt at testing whether an updated > version of "wesnoth" 0.9.2 (Fedora Extras) would seem to work with FC4. > Clicking some buttons in its network related menus or connecting to the > official server lead to this fully reproducible crash: > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 54066096 (zombie)] > 0x00a353a8 in ?? () > (gdb) bt > #0 0x00a353a8 in ?? () > #1 0x0026ab7a in __nptl_deallocate_tsd () from /lib/libpthread.so.0 > #2 0x0026bb8e in start_thread () from /lib/libpthread.so.0 > #3 0x00c79dee in clone () from /lib/libc.so.6 > (gdb) t > [Current thread is 4 (Thread 54066096 (zombie))] > > It's not reproducible with FC3. > > Backtraces for the threads (attached) don't look suspicious IMO. Adding > more debuginfo packages didn't give more detailed output. Two other things > I tried last night was to build without -O2 and build SDL with default optflags > instead of -O3. No change. > > Suggestions, ideas, or hints much appreciated. It appears that the first version of wesnoth (0.8.6), which introduced SDL based threads for networking functions, and all newer versions cause segfaults on FC4. When a thread function is asked to return (e.g. prior to SDL_ThreadWait), a crash as above is the result as soon as it terminates. A simple SDL thread test does not show such symptoms. Something's special in the context of wesnoth. -- Fedora Core release 4 (Stentz) - Linux 2.6.11-1.1369_FC4 loadavg: 2.72 2.46 2.33 From rdieter at math.unl.edu Wed Jun 15 17:55:54 2005 From: rdieter at math.unl.edu (news.gmane.org) Date: Wed, 15 Jun 2005 12:55:54 -0500 Subject: nfs-utils rpcsvcgssd and nfs init script redundancy? In-Reply-To: <42AF1CBD.5090506@bu.edu> References: <42AF1CBD.5090506@bu.edu> Message-ID: Wesley Harrell wrote: > According to the changelog in nfs-utils-1.0.6-52 the developer > "Changed the nfs.init script to bring rpc.svcgssd up and down, > since rpc.svcgssd is only needed with the NFS server is running." > > However the rpcsvcgssd init script is still added via chkconfig during install > *and* is started before nfs. Is this a mistake, or is there a reason the > rpcsvcgssd continues to be started through its own init script? So does the fc4 nfs.init really do rpc.svcgssd too? If so, I'd suggest reporting the packaging error: http://bugzilla.redhat.com/ -- Rex From kewley at gps.caltech.edu Wed Jun 15 18:17:57 2005 From: kewley at gps.caltech.edu (David Kewley) Date: Wed, 15 Jun 2005 11:17:57 -0700 Subject: rawhide report: 20050615 changes In-Reply-To: <200506151120.j5FBKu9f002628@porkchop.devel.redhat.com> References: <200506151120.j5FBKu9f002628@porkchop.devel.redhat.com> Message-ID: <200506151117.58014.kewley@gps.caltech.edu> On Wednesday 15 June 2005 04:20, Build System wrote: > kdebase-6:3.4.1-0.fc4.1 > ----------------------- Will KDE 3.4.1 be provided as an update to FC4 when it's ready? There are lots of little but highly annoying bugs in KDE 3.4. :) David From steve at silug.org Wed Jun 15 22:58:18 2005 From: steve at silug.org (Steven Pritchard) Date: Wed, 15 Jun 2005 17:58:18 -0500 Subject: Yum Upgrade Faq In-Reply-To: <1118856771.5057.3.camel@dhollis-lnx.sunera.com> References: <1118768454.4719.6.camel@dhollis-lnx.sunera.com> <1118769079.31680.10.camel@cutter> <1118778987.4719.11.camel@dhollis-lnx.sunera.com> <1118779413.31680.29.camel@cutter> <1118797456.5618.1.camel@dhollis-lnx.sunera.com> <1118819272.3032.84.camel@cutter> <1118837209.5618.8.camel@dhollis-lnx.sunera.com> <1118840182.3032.89.camel@cutter> <20050615152043.GA1903@shadow.sumu.org> <1118856771.5057.3.camel@dhollis-lnx.sunera.com> Message-ID: <20050615225818.GA4903@osiris.silug.org> On Wed, Jun 15, 2005 at 01:32:50PM -0400, David Hollis wrote: > I can only imagine how many folks are going to be bitten by the PG > upgrade. On a similar note, I upgraded a client's box running openldap, and after the upgrade (via anaconda) slapd wouldn't start. Apparently db4 4.3 won't open db4 4.2 files. :-/ (Luckily I had my FC3 notebook handy so I could just copy /etc/openldap and /var/lib/ldap over to it to run slapcat.) If there isn't going to be an automatic backup script for things like this (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=148972), perhaps Extras should include an openldap-snapshot rpm that just includes the cron job. (I was thinking the other day that postgresql-snapshot, mysql-snapshot, etc. would be good ideas too.) Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From Curtis at GreenKey.net Thu Jun 16 01:23:49 2005 From: Curtis at GreenKey.net (Curtis Doty) Date: Wed, 15 Jun 2005 18:23:49 -0700 Subject: rpmdb-fedora Message-ID: <42B0D4A5.8070304@GreenKey.net> I must have been sleeping when rpmdb-fedora got removed. But what was the reasoning? ../C From skvidal at phy.duke.edu Thu Jun 16 01:58:08 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 15 Jun 2005 21:58:08 -0400 Subject: rpmdb-fedora In-Reply-To: <42B0D4A5.8070304@GreenKey.net> References: <42B0D4A5.8070304@GreenKey.net> Message-ID: <1118887088.11389.2.camel@cutter> On Wed, 2005-06-15 at 18:23 -0700, Curtis Doty wrote: > I must have been sleeping when rpmdb-fedora got removed. But what was > the reasoning? > not really needed anymore and it ate up room on the cds. do this: yum install yum-utils run repoquery and check out what it can do. it's like what you could do with rpm and an installed rpmdb-fedora but with updated information. -sv From bernie at develer.com Thu Jun 16 01:56:40 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Thu, 16 Jun 2005 03:56:40 +0200 Subject: Audit / Netlink slowness In-Reply-To: <20050614130412.64768.qmail@web51506.mail.yahoo.com> References: <20050614130412.64768.qmail@web51506.mail.yahoo.com> Message-ID: <42B0DC58.3090101@develer.com> Steve G wrote: >>Running "strace -r 2>strace.out su", I discovered that >>netlink communication is the major cause of slowdown. > > netlink in theory should be fast. No routing or collisions. I suppose so, but I don't know any other netlink user I could compare with to make sure it's really a problem specific to audit. >>"su" connects to a NETLINK_AUDIT socket 3 or 4 times. >>Each time it does 2 sendto() + recvfrom() operations, > > It does an audit subsystem status to see if its enabled and if so a send of > auditable information. What version of pam, su, audit-libs, kernel are you using? pam-0.79-10 audit-libs-0.9.3-1 coreutils-5.2.1-31 kernel-2.6.11-1.1240_FC4 SELinux is disabled. The kernel is a custom build with several drivers removed and some debugging options turned off. Should perform better than stock kernels. >>with a latency of ~200ms. This adds up to 800ms wasted >>time. > > Just out of curiosity, what cpu & clock speed do you have? It's an Athlon 2500 (3547.13 bogomips) > Are you running UP or SMP kernel? UP, with preemption disabled. > This code path should be entirely cpu bound as no io devices are > involved. Does the audit socket communication talk synchronously with auditd? If so, the problem could be there too. >>Disabling CONFIG_AUDIT in the kernel makes su and ssh >>very fast again. > > > You also lose part of your SE Linux avc messages. There was a deadlock condition > discovered and reported on the NSA SE Linux mail list. The solution was to move > part of the processing to syscall exit audit processing. With audit not compiled > in or enabled, you get an abreviated avc message under some conditions. I also disabled SELinux, mainly because I wasn't willing to fix all my services to run properly with the strict policy that was initially shipped with FC2. Then I just didn't find the time/motivation to turn it on again. Yes, lame me :-) >>Is this behavior to be expected? > > Not exactly. There will be a *some* delay as we've added a lot of new > functionality, but 800 ms total delay is excessive. I'll see if we can find the > culprit. Could you please also try an "strace -r" to make sure I'm not the only one seeing this? -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From bernie at develer.com Thu Jun 16 02:02:31 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Thu, 16 Jun 2005 04:02:31 +0200 Subject: Audit / Netlink slowness In-Reply-To: <20050614135803.95602.qmail@web51509.mail.yahoo.com> References: <20050614135803.95602.qmail@web51509.mail.yahoo.com> Message-ID: <42B0DDB7.3050703@develer.com> Steve G wrote: >>"su" connects to a NETLINK_AUDIT socket 3 or 4 times. >>Each time it does 2 sendto() + recvfrom() operations, >>with a latency of ~200ms. This adds up to 800ms wasted >>time. > > > I see a way to get rid of 1 sendto and put it in the error path. This way people > without audit support (which would be rare for this distro) would get the extra > sendto. This would solve the common use problem. You really need audit compiled > in for SE Linux avc messages to be full and complete. > > I also see a few *minor* issues in the kernel that might save a couple clock > cycles, but no magic bullet. I could use this issue as an excuse to finally learn how oprofile works. Hopefully I'll be able to provide a useful clue... -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From rodd at clarkson.id.au Thu Jun 16 02:33:13 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Thu, 16 Jun 2005 12:33:13 +1000 Subject: rawhide report: 20050615 changes In-Reply-To: <200506151117.58014.kewley@gps.caltech.edu> References: <200506151120.j5FBKu9f002628@porkchop.devel.redhat.com> <200506151117.58014.kewley@gps.caltech.edu> Message-ID: <1118889193.3364.15.camel@jellyfish.redfishdemo.com> On Wed, 2005-06-15 at 11:17 -0700, David Kewley wrote: > On Wednesday 15 June 2005 04:20, Build System wrote: > > kdebase-6:3.4.1-0.fc4.1 > > ----------------------- > > Will KDE 3.4.1 be provided as an update to FC4 when it's ready? There > are lots of little but highly annoying bugs in KDE 3.4. :) At a guess, the FC4 on the end suggests that this is likely. Stuff that's truely targeted at FC5 will have fc5 on the end. This is just a guess. R. -- "It's a fine line between denial and faith. It's much better on my side" From symbiont at berlios.de Thu Jun 16 04:25:35 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Thu, 16 Jun 2005 12:25:35 +0800 Subject: "I plan to work on..." for FC5 In-Reply-To: <1118838857.22181.79.camel@hades.cambridge.redhat.com> References: <20050605225757.GA3080@amilo.kolej.mff.cuni.cz> <200506110905.00788.symbiont@berlios.de> <1118838857.22181.79.camel@hades.cambridge.redhat.com> Message-ID: <200506161225.35345.symbiont@berlios.de> On Wednesday 15 June 2005 20:34, David Woodhouse wrote: > It should be 'bluetooth' not 'bluez'. thanks! -- -jeff From walters at redhat.com Thu Jun 16 04:46:26 2005 From: walters at redhat.com (Colin Walters) Date: Thu, 16 Jun 2005 00:46:26 -0400 Subject: Audit / Netlink slowness In-Reply-To: <42B0DC58.3090101@develer.com> References: <20050614130412.64768.qmail@web51506.mail.yahoo.com> <42B0DC58.3090101@develer.com> Message-ID: <1118897186.3581.10.camel@nexus.verbum.private> On Thu, 2005-06-16 at 03:56 +0200, Bernardo Innocenti wrote: > I also disabled SELinux, mainly because I wasn't willing to > fix all my services to run properly with the strict policy that > was initially shipped with FC2. Then I just didn't find the > time/motivation to turn it on again. Yes, lame me :-) You are aware things have massively changed since FC2? It's pretty easy to reenable, nowadays just run system-config-securitylevel then reboot. From pnasrat at redhat.com Thu Jun 16 10:59:05 2005 From: pnasrat at redhat.com (Paul Nasrat) Date: Thu, 16 Jun 2005 06:59:05 -0400 Subject: rpmdb-fedora In-Reply-To: <1118887088.11389.2.camel@cutter> References: <42B0D4A5.8070304@GreenKey.net> <1118887088.11389.2.camel@cutter> Message-ID: <1118919545.3131.23.camel@enki.eridu> On Wed, 2005-06-15 at 21:58 -0400, seth vidal wrote: > On Wed, 2005-06-15 at 18:23 -0700, Curtis Doty wrote: > > I must have been sleeping when rpmdb-fedora got removed. But what was > > the reasoning? > > > > not really needed anymore and it ate up room on the cds. > > do this: > > yum install yum-utils > > run repoquery and check out what it can do. > > it's like what you could do with rpm and an installed rpmdb-fedora but > with updated information. To get rpm --redhatprovides like behaviour you can drop this in ~/.popt to make rpm --fedoraprovides use repoquery. Paul -------------- next part -------------- rpm exec --fedoraprovides /usr/bin/repoquery --whatprovides rpm exec --fedorarequires /usr/bin/repoquery --whatrequires From harald at redhat.com Thu Jun 16 11:16:15 2005 From: harald at redhat.com (Harald Hoyer) Date: Thu, 16 Jun 2005 13:16:15 +0200 Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ - Python test scripts for Proof of Concept Message-ID: <42B15F7F.90803@redhat.com> For testing purposes and proof of concept, I have written some python scripts as an "rc" replacement. I've done this, because I haven't seen any code from others (where is the code of SystemServices??) and because I want to experiment with some concepts, before something is set to stone. See: http://people.redhat.com/harald/ServiceManager/ The python script ServiceManager.py reads all /etc/init.d/* scripts and creates DBUS "Service" objects. These parse the chkconfig and LSB-style comments of their script and provide a DBUS interface to retrieve information and control them. Note: I am new to DBUS, so forgive me, if I haven't understood the concept of objects, interfaces and busses correctly, yet. To use the glib main_loop from python without the need of gtk (import gtk needs a working X11 DISPLAY), I patched the dbus python bindings to provide dbus.main_loop(): dbus-0.33-glib-mainloop.patch dbus-0.33-99.hh.1.src.rpm etc_dbus-1_system.d_rc.conf has to be placed to /etc/dbus-1/system.d/rc.conf ServiceTestClient.py is a small client test app, which queries all available services. As you can see, ServiceManager.py was just started and is not ready yet, but release early, release often. Stay tuned. Maybe someone is interested and wants to help, or it maybe inspires others to develop a completly other implementation. Next steps I want to do: - replace rc functionality for complete backwards compatibility - implement the depends/requires mechanism (also with dynamic requirements and dependencies) - patch all initscripts to conform to LSB - convert prefdm to an initscript which requires $authentication and $local_dir - create an initscript, which provides $authentication and depends on $network, if network auth is needed. - convert /etc/init.d/functions and /sbin/service to use the DBUS interface Have fun! Harald -- Code, code, give me some open source code! From buildsys at redhat.com Thu Jun 16 11:36:14 2005 From: buildsys at redhat.com (Build System) Date: Thu, 16 Jun 2005 07:36:14 -0400 Subject: rawhide report: 20050616 changes Message-ID: <200506161136.j5GBaEvV030108@porkchop.devel.redhat.com> New package bsf Bean Scripting Framework New package concurrent Utility classes for concurrent Java programming New package geronimo-specs Geronimo J2EE server J2EE specifications New package jacorb Free Java implementation of OMG's CORBA standard New package jakarta-commons-codec Jakarta Commons Codec Package New package jakarta-commons-discovery Jakarta Commons Discovery New package jakarta-commons-httpclient Jakarta Commons HTTPClient Package New package jdom Java alternative to DOM and SAX New package jonathan-rmi Subset of javax.rmi for building against New package jrefactory JRefactory and Pretty Print New package mockobjects Java MockObjects package New package tanukiwrapper Java Service Wrapper New package velocity Java-based template engine New package werken.xpath XPath implementation using JDOM New package xdoclet XDoclet Attribute Orientated Programming Framework New package xjavadoc The XJavaDoc engine Updated Packages: NetworkManager-0.4-30.cvs20050615 --------------------------------- * Wed Jun 15 2005 Dan Williams - 0.4-30.cvs20050615 - Update to latest CVS ant-0:1.6.2-3jpp_10fc --------------------- * Wed Jun 15 2005 Gary Benson 0:1.6.2-3jpp_10fc - Add the bsf subpackage since we now ship bsf. - Remove gcj workaround (not correct, so assume not necessary). - Remove jarfiles from the tarball. * Mon Jun 06 2005 Gary Benson - Make the javah task fall back to executing javah if com.sun.tools.javah.Main cannot be found. curl-7.14.0-1 ------------- * Thu Jun 16 2005 Ivana Varekova 7.14.0-1 - rebuild new version hplip-0.9.3-5 ------------- * Wed Jun 15 2005 Tim Waugh 0.9.3-5 - Use static IP ports (for SELinux policy). kdepim-6:3.4.1-0.fc4.1 ---------------------- * Tue Jun 14 2005 Than Ngo 3.4.1-0.fc4.1 - update to 3.4.1 - remove kdepim-3.4.0-long.patch, it's included in new upstream kernel-2.6.11-1.1383_FC5 ------------------------ * Mon Jun 13 2005 Peter Jones - Reenable fixed ipw drivers. * Mon Jun 13 2005 Dave Jones - 2.6.12-rc6-git5 libgsf-1.12.1-1 --------------- * Wed Jun 15 2005 Caolan McNamara 1.12.1-1 - bump to latest version openoffice.org-1:1.9.109-6.2.0.fc5 ---------------------------------- * Tue Jun 14 2005 Caolan McNamara - 1:1.9.109-6 - drop unnecessary Require - rh#160302# skip fontconfig for symbol font processing pilot-link-1:0.12.0-0.pre4.1 ---------------------------- * Wed Jun 15 2005 Than Ngo 0.12.0-0.pre4.1 - 0.12.0-pre4 - remove pilot-link-0.12.0-pre3-buffer.patch, it's included in new upstream selinux-policy-strict-1.23.18-7 ------------------------------- * Wed Jun 15 2005 Dan Walsh 1.23.18-7 - Fixed for new cups domain hplip struts-0:1.2.4-2jpp_1fc ----------------------- * Wed Jun 15 2005 Gary Benson - 0:1.2.4-2jpp_1fc - Make workaround for #157205 specific to libgcj. * Tue Jun 14 2005 Gary Benson - Remove jars, wars and classes from the tarball. * Fri May 27 2005 Gary Benson - 0:1.2.4-2jpp - Build with servletapi5. - Add build dependency on ant-nodeps. system-config-netboot-0.1.20-1 ------------------------------ * Wed Jun 15 2005 Jason Vas Dias 0.1.20-1 - fix addendum to bugs 149000/135411: updateDiskless: Do not create SELinux xattr labels in the initrd filesystem xalan-j2-0:2.6.0-3jpp_1fc ------------------------- * Wed Jun 15 2005 Gary Benson 0:2.6.0-3jpp_1fc - Remove jarfiles from the tarball. * Fri May 27 2005 Gary Benson 0:2.6.0-3jpp - Add NOTICE file as per Apache License version 2.0. - Build with servletapi5. xerces-j2-0:2.6.2-5jpp_1fc -------------------------- * Wed Jun 15 2005 Gary Benson 0:2.6.2-5jpp_1fc - Upgrade to 2.6.2-5jpp. * Tue Jun 14 2005 Gary Benson 0:2.6.2-5jpp - Remove the tools tarball, and build xjavac from source. - Patch xjavac to fix the classpath under libgcj too. xml-commons-0:1.0-0.b2.7jpp_2fc ------------------------------- * Wed Jun 15 2005 Gary Benson - 0:1.0-0.b2.7jpp_2fc - Remove all prebuilt stuff from the tarball. yum-2.3.3-1 ----------- * Wed Jun 15 2005 Jeremy Katz - 2.3.3-1 - update to 2.3.3 From vonbrand at inf.utfsm.cl Thu Jun 16 00:10:31 2005 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Wed, 15 Jun 2005 20:10:31 -0400 Subject: rawhide report: 20050610 changes In-Reply-To: Message from Bill Nottingham of "Mon, 13 Jun 2005 12:43:28 -0400." <20050613164328.GK19700@nostromo.devel.redhat.com> Message-ID: <200506160010.j5G0AV88003865@laptop11.inf.utfsm.cl> Bill Nottingham wrote: > Rodd Clarkson (rodd at clarkson.id.au) said: > > > kernel-2.6.11-1.1381_FC5 > > > ------------------------ > > > * Thu Jun 09 2005 Dave Jones > > > - 2.6.12-rc6-git3 > > > - Temporarily disable the ipw drivers until I sort them out. > > What's up with these drivers? What's to sort out? > Broke with the gcc in the FC5 tree. I've been compiling 1.0.4 against Linus' git tree almost daily on FC4t3 onwards. No problems seen up to here (but no fancy setup either). -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From pbrobinson at gmail.com Thu Jun 16 13:26:24 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 16 Jun 2005 14:26:24 +0100 Subject: rawhide report: 20050610 changes In-Reply-To: <200506160010.j5G0AV88003865@laptop11.inf.utfsm.cl> References: <20050613164328.GK19700@nostromo.devel.redhat.com> <200506160010.j5G0AV88003865@laptop11.inf.utfsm.cl> Message-ID: <5256d0b050616062639391ada@mail.gmail.com> On 6/16/05, Horst von Brand wrote: > Bill Nottingham wrote: > > Rodd Clarkson (rodd at clarkson.id.au) said: > > > > kernel-2.6.11-1.1381_FC5 > > > > ------------------------ > > > > * Thu Jun 09 2005 Dave Jones > > > > - 2.6.12-rc6-git3 > > > > - Temporarily disable the ipw drivers until I sort them out. > > > > What's up with these drivers? What's to sort out? > > > Broke with the gcc in the FC5 tree. > > I've been compiling 1.0.4 against Linus' git tree almost daily on FC4t3 > onwards. No problems seen up to here (but no fancy setup either). According to the build report from today they are now back in the FC5 kernel. Peter From linux_4ever at yahoo.com Thu Jun 16 13:41:41 2005 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 16 Jun 2005 06:41:41 -0700 (PDT) Subject: Audit / Netlink slowness In-Reply-To: <42B0DC58.3090101@develer.com> Message-ID: <20050616134142.32720.qmail@web51503.mail.yahoo.com> >> netlink in theory should be fast. No routing or collisions. > >I suppose so, but I don't know any other netlink user >I could compare with to make sure it's really a problem >specific to audit. It works very similar to any other netlink app, except its unicast, synchronous, and needs the netlink ack flag. This is because CAPP demands that if an event is not able to be audited, use of the system should be denied. From pam's perspective all that its concerned with is to send the audit event and see that the kernel has taken custody of the event. At that point its free to continue. >>>"su" connects to a NETLINK_AUDIT socket 3 or 4 times. >>>Each time it does 2 sendto() + recvfrom() operations, >> >> It does an audit subsystem status to see if its enabled and if so >> a send of auditable information. What version of pam, su, audit-libs, >> kernel are you using? > > pam-0.79-10 > audit-libs-0.9.3-1 > coreutils-5.2.1-31 > kernel-2.6.11-1.1240_FC4 These are all good. I released a new audit package that has 2 syscalls removed. You should see a performance improvement with audit-libs-0.9.5. >> Just out of curiosity, what cpu & clock speed do you have? > >It's an Athlon 2500 (3547.13 bogomips) Good thanks. This is useful info. >> This code path should be entirely cpu bound as no io devices are >> involved. > >Does the audit socket communication talk synchronously with >auditd? If so, the problem could be there too. Yes. It also waits for the ack flag. It has absolutely got to know that the kernel has the message. I did a review of the critical path in the kernel and found a few minor improvements. I'm still looking at it and may have some more improvements - but there's no big delay that I can see. >>>Is this behavior to be expected? >> >> Not exactly. There will be a *some* delay as we've added a lot >> of new functionality, but 800 ms total delay is excessive. I'll >> see if we can find the culprit. > >Could you please also try an "strace -r" to make sure I'm >not the only one seeing this? I don't doubt your claims. I have made improvements with the assumption that your results are reproducable. audit-libs-0.9.5 should behave better for you. I will also release 0.9.6 today and see if I can get some timing information. I am using a special kernel that has all the audit patches applied so my results may not hold for a FC4 kernel. Thanks for bringing this performance issue up. -Steve Grubb __________________________________ Discover Yahoo! Stay in touch with email, IM, photo sharing and more. Check it out! http://discover.yahoo.com/stayintouch.html From kaboom at oobleck.net Thu Jun 16 13:56:39 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Thu, 16 Jun 2005 09:56:39 -0400 (EDT) Subject: rawhide report: 20050616 changes In-Reply-To: <200506161136.j5GBaEvV030108@porkchop.devel.redhat.com> References: <200506161136.j5GBaEvV030108@porkchop.devel.redhat.com> Message-ID: On Thu, 16 Jun 2005, Build System wrote: > New package bsf > Bean Scripting Framework > > New package concurrent > Utility classes for concurrent Java programming > > New package geronimo-specs > Geronimo J2EE server J2EE specifications > > New package jacorb > Free Java implementation of OMG's CORBA standard > > New package jakarta-commons-codec > Jakarta Commons Codec Package > > New package jakarta-commons-discovery > Jakarta Commons Discovery > > New package jakarta-commons-httpclient > Jakarta Commons HTTPClient Package > > New package jdom > Java alternative to DOM and SAX > > New package jonathan-rmi > Subset of javax.rmi for building against > > New package jrefactory > JRefactory and Pretty Print > > New package mockobjects > Java MockObjects package > > New package tanukiwrapper > Java Service Wrapper > > New package velocity > Java-based template engine > > New package werken.xpath > XPath implementation using JDOM > > New package xdoclet > XDoclet Attribute Orientated Programming Framework > > New package xjavadoc > The XJavaDoc engine Does all this really need to be in Core? Not in Extras? later, chris From rdieter at math.unl.edu Thu Jun 16 13:55:21 2005 From: rdieter at math.unl.edu (news.gmane.org) Date: Thu, 16 Jun 2005 08:55:21 -0500 Subject: rawhide report: 20050615 changes In-Reply-To: <200506151117.58014.kewley@gps.caltech.edu> References: <200506151120.j5FBKu9f002628@porkchop.devel.redhat.com> <200506151117.58014.kewley@gps.caltech.edu> Message-ID: David Kewley wrote: > On Wednesday 15 June 2005 04:20, Build System wrote: >>kdebase-6:3.4.1-0.fc4.1 >>----------------------- > Will KDE 3.4.1 be provided as an update to FC4 when it's ready? There > are lots of little but highly annoying bugs in KDE 3.4. :) FYI, a few of rawhide's kde-3.4.0 packages are actually cvs snapshots (post kde-3.4.0 but pre kde-3.4.1 code), which probably includes fixes for a few of those annoying stock kde-3.4.0 bugs. -- Rex From dr at cluenet.de Thu Jun 16 14:18:23 2005 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 16 Jun 2005 16:18:23 +0200 Subject: What next? In-Reply-To: <20050615151834.GA10464@srv01.cluenet.de> References: <20050615151834.GA10464@srv01.cluenet.de> Message-ID: <20050616141823.GA28446@srv01.cluenet.de> On Wed, Jun 15, 2005 at 05:18:34PM +0200, Daniel Roesen wrote: > On Wed, Jun 01, 2005 at 01:59:19PM -0400, Elliot Lee wrote: > > Maybe it's time to start the brainstorming for Fedora Core 5 and Fedora > > Extras 5 - what major features are you willing to put effort into? > > - Ability to fully configure IPv6 networking in Anaconda > > (static IP, stateless autoconfig, DHCPv6, listen to RAs or static > default route, etc.pp) FWIW, this is now https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160661 Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From fedora-devel at tlarson.com Thu Jun 16 14:44:18 2005 From: fedora-devel at tlarson.com (Tyler Larson) Date: Thu, 16 Jun 2005 08:44:18 -0600 Subject: Audit / Netlink slowness In-Reply-To: <42B0DC58.3090101@develer.com> References: <20050614130412.64768.qmail@web51506.mail.yahoo.com> <42B0DC58.3090101@develer.com> Message-ID: <42B19042.3090508@tlarson.com> >>>Is this behavior to be expected? >> >>Not exactly. There will be a *some* delay as we've added a lot of new >>functionality, but 800 ms total delay is excessive. I'll see if we can find the >>culprit. > > > Could you please also try an "strace -r" to make sure I'm > not the only one seeing this? > Here's one of the relevant parts of my strace -r (FC4, 1GHZ athalon). What stands out to me is that is that the sendto() and recvfrom() operations aren't taking very long at all (remember, the relative time stamps are *between* system calls, not *elapsed* during system calls). And since recvfrom() is called with MSG_DONTWAIT, it's not going to block waiting for data. Instead, there's a 100ms sleep before each recvfrom() that really racks up the wait time. In total, I counted 9 places where su sleeps for 100ms before a recvfrom() -- so that's almost 1 sec killed just sleeping. I haven't dug through the code yet (which package is it in, anyway?), but I can only imagine that the motivation for programming the thing like this (with nanosleep + recvfrom w/ MSG_DONTWAIT) is to limit the amount of time spent waiting for a reply. Obviously the reply takes *some* time to arrive, and calling recvfrom() without MSG_DONTWAIT wouldn't be a viable option--you might block forever. Hence, sleep long enough to give up a timeslice and hopefully let the reply be generated, then check to see if its there. A more reasonable solution (assuming it's possible with NETLINK sockets--I don't know much about them) would be a select() with a maximum timeout of 100ms. That gives you worst-case performance equal to what we see now, with the potential of much better. Am I way off-base here, or does that sound like a good idea? -------------- 0.000100 bind(3, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0 0.000543 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 0.000289 readlink("/proc/self/exe", "/bin/su", 4095) = 7 0.000495 sendto(3, "\20\0\0\0\350\3\5\0\5\0\0\0\0\0\0\0", 16, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 16 0.000371 nanosleep({0, 100000000}, NULL) = 0 0.101499 recvfrom(3, "0\0\0\0\350\3\0\0\5\0\0\0Ey\0\0\0\0\0\0\1\0\0\0\1\0\0\0"..., 1216, MSG_PEEK|MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=00000000}, [12]) = 48 0.000428 nanosleep({0, 100000000}, NULL) = 0 0.101554 recvfrom(3, "0\0\0\0\350\3\0\0\5\0\0\0Ey\0\0\0\0\0\0\1\0\0\0\1\0\0\0"..., 1216, MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=00000000}, [12]) = 48 0.000438 sendto(3, "l\0\0\0\355\3\5\0\6\0\0\0\0\0\0\0PAM session open"..., 108, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 108 0.000600 nanosleep({0, 100000000}, NULL) = 0 0.101949 recvfrom(3, "$\0\0\0\2\0\0\0\5\0\0\0Ey\0\0\0\0\0\0\20\0\0\0\350\3\5"..., 1216, MSG_PEEK|MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=00000000}, [12]) = 36 0.000444 recvfrom(3, "$\0\0\0\2\0\0\0\5\0\0\0Ey\0\0\0\0\0\0\20\0\0\0\350\3\5"..., 1216, MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=00000000}, [12]) = 36 0.000442 close(3) = 0 From mikem at cyber.com.au Thu Jun 16 15:03:11 2005 From: mikem at cyber.com.au (Mike MacCana) Date: Fri, 17 Jun 2005 01:03:11 +1000 Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ - Python test scripts for Proof of Concept In-Reply-To: <42B15F7F.90803@redhat.com> References: <42B15F7F.90803@redhat.com> Message-ID: <42B194AF.3030401@cyber.com.au> Harald Hoyer wrote: > For testing purposes and proof of concept, I have written some python > scripts as an "rc" replacement. I've done this, because I haven't seen > any code from others (where is the code of SystemServices??) and > because I want to experiment with some concepts, before something is > set to stone. sweet! Harald, have you spoken to J5 about this? He's been talking about a DBUS init for a while now... Mike > From bernie at develer.com Thu Jun 16 15:49:52 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Thu, 16 Jun 2005 17:49:52 +0200 Subject: Audit / Netlink slowness In-Reply-To: <1118897186.3581.10.camel@nexus.verbum.private> References: <20050614130412.64768.qmail@web51506.mail.yahoo.com> <42B0DC58.3090101@develer.com> <1118897186.3581.10.camel@nexus.verbum.private> Message-ID: <42B19FA0.9060809@develer.com> Colin Walters wrote: > On Thu, 2005-06-16 at 03:56 +0200, Bernardo Innocenti wrote: > > >>I also disabled SELinux, mainly because I wasn't willing to >>fix all my services to run properly with the strict policy that >>was initially shipped with FC2. Then I just didn't find the >>time/motivation to turn it on again. Yes, lame me :-) > > > You are aware things have massively changed since FC2? It's > pretty easy to reenable, nowadays just run system-config-securitylevel > then reboot. Yes, I do... but that's quite a complex server, with some custom stuff installed in /usr/local, so I'm afraid I'd have to fiddle with the policy. Some time ago I bought O'Reilly's SELinux book and read through it, but the underlying complexity of SELinux scared me off somewhat. I'm sure I can get it to work properly with my setup, but I'm also afraid it would take too much headaches for initial setup *and* some additional effort when I install new stuff. That said, I'd recommend SELinux for most sites, expecially when they are very popular. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From linux_4ever at yahoo.com Thu Jun 16 17:21:29 2005 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 16 Jun 2005 10:21:29 -0700 (PDT) Subject: Audit / Netlink slowness In-Reply-To: <42B19042.3090508@tlarson.com> Message-ID: <20050616172129.31301.qmail@web51502.mail.yahoo.com> >Am I way off-base here, or does that sound like a good idea? Exactly right on. We can't wait forever in case kernel discards netlink packet during a memory crunch or something else unforseen happens. The select loop will work. It'll be in 0.9.7 later today. Thanks, -Steve Grubb __________________________________ Discover Yahoo! Find restaurants, movies, travel and more fun for the weekend. Check it out! http://discover.yahoo.com/weekend.html From notting at redhat.com Thu Jun 16 17:33:50 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 16 Jun 2005 13:33:50 -0400 Subject: rawhide report: 20050616 changes In-Reply-To: References: <200506161136.j5GBaEvV030108@porkchop.devel.redhat.com> Message-ID: <20050616173350.GB12173@nostromo.devel.redhat.com> Chris Ricker (kaboom at oobleck.net) said: > Does all this really need to be in Core? Not in Extras? It's part of a JONAS App server. For FC5, I expect many things to be shifted to Extras, but we'd like to get some of the work on making CD images/splitting CDs based on groups/etc. to work first, then having good discussions on what can be made an Extras 'component' as opposed to just a package or two can happen. Bill From notting at redhat.com Thu Jun 16 17:36:24 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 16 Jun 2005 13:36:24 -0400 Subject: rawhide report: 20050615 changes In-Reply-To: <200506151117.58014.kewley@gps.caltech.edu> References: <200506151120.j5FBKu9f002628@porkchop.devel.redhat.com> <200506151117.58014.kewley@gps.caltech.edu> Message-ID: <20050616173624.GC12173@nostromo.devel.redhat.com> David Kewley (kewley at gps.caltech.edu) said: > On Wednesday 15 June 2005 04:20, Build System wrote: > > kdebase-6:3.4.1-0.fc4.1 > > ----------------------- > > Will KDE 3.4.1 be provided as an update to FC4 when it's ready? There > are lots of little but highly annoying bugs in KDE 3.4. :) Yes, an update is being prepped. Bill From notting at redhat.com Thu Jun 16 17:37:19 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 16 Jun 2005 13:37:19 -0400 Subject: rpmdb-fedora In-Reply-To: <1118919545.3131.23.camel@enki.eridu> References: <42B0D4A5.8070304@GreenKey.net> <1118887088.11389.2.camel@cutter> <1118919545.3131.23.camel@enki.eridu> Message-ID: <20050616173719.GD12173@nostromo.devel.redhat.com> Paul Nasrat (pnasrat at redhat.com) said: > > run repoquery and check out what it can do. > > > > it's like what you could do with rpm and an installed rpmdb-fedora but > > with updated information. > > To get rpm --redhatprovides like behaviour you can drop this in ~/.popt > to make rpm --fedoraprovides use repoquery. Shouldn't that be shipped with yum-utils? Bill From skvidal at phy.duke.edu Thu Jun 16 17:41:28 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 16 Jun 2005 13:41:28 -0400 Subject: rpmdb-fedora In-Reply-To: <20050616173719.GD12173@nostromo.devel.redhat.com> References: <42B0D4A5.8070304@GreenKey.net> <1118887088.11389.2.camel@cutter> <1118919545.3131.23.camel@enki.eridu> <20050616173719.GD12173@nostromo.devel.redhat.com> Message-ID: <1118943688.16412.21.camel@cutter> On Thu, 2005-06-16 at 13:37 -0400, Bill Nottingham wrote: > Paul Nasrat (pnasrat at redhat.com) said: > > > run repoquery and check out what it can do. > > > > > > it's like what you could do with rpm and an installed rpmdb-fedora but > > > with updated information. > > > > To get rpm --redhatprovides like behaviour you can drop this in ~/.popt > > to make rpm --fedoraprovides use repoquery. > > Shouldn't that be shipped with yum-utils? > do we really want to legacy this along forever? I think not. -sv From usernamenumber at gmail.com Fri Jun 17 00:04:05 2005 From: usernamenumber at gmail.com (Brad Smith) Date: Thu, 16 Jun 2005 17:04:05 -0700 Subject: bad practice: services that are automatically re-enabled In-Reply-To: <42AE5B02.9010806@cyber.com.au> References: <1118714579.6098.18.camel@rivendell.home.local> <20050614020819.GA1449@nostromo.devel.redhat.com> <20050614022024.GA7523@thacker.dyndns.org> <1118717587.6098.27.camel@rivendell.home.local> <20050614030905.GA30522@jadzia.bu.edu> <42AE5B02.9010806@cyber.com.au> Message-ID: > 'chkconfig foo off' is for users and package install scripts for most > services. > > Anyone disagree? AFAIK 'off' and 'on' should never be necessary in an install script. The "#chkconfig:" comment at the top of each service's init script specifies which runlevels it is on-by-default in (or '-' if it is always off-by-default). On a related note, to check on the current behavior of FC scripts, I pulled all of the FC4 (no extras or third-party) install/uninstall scripts out of the fedoratracker.org database and did some grepping. There are lots of --add and --del instances, but no 'on' or 'off' commands, so I think FC already complies with a reasonable standard. I'm guessing, then, that the OP is either using --del when 'off' would be more appropriate or using third-party RPMs that do things they oughtn't in the scripts. --Brad From s.mako at gmx.net Fri Jun 17 09:28:55 2005 From: s.mako at gmx.net (Zoltan Kota) Date: Fri, 17 Jun 2005 11:28:55 +0200 (CEST) Subject: FC4 and G5 Message-ID: Hi, Is there anybody using FC4 final on an iMac G5? I have problems that I didn't have with test3 (as much as I can say after a short test period). I could install FC4, but within some minutes of using, the system doesn't respond and I get the following messages on the console: ata1: command 0x35 timeout, stat 0x50 host_stat 0x4 hda: lost interrupt mpic_enable_irq timeout ata1: command 0x35 timeout, stat 0x50 host_stat 0x4 Moreover, pushing the TAB button (tab completion in shell at the console) results in a scrolling screen and the above error at once. What's this? Zoltan From sundaram at redhat.com Fri Jun 17 11:30:19 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 17 Jun 2005 17:00:19 +0530 Subject: FC4 and G5 In-Reply-To: References: Message-ID: <42B2B44B.9050809@redhat.com> Zoltan Kota wrote: >Hi, > >Is there anybody using FC4 final on an iMac G5? >I have problems that I didn't have with test3 (as much as I can say after >a short test period). > >I could install FC4, but within some >minutes of using, the system doesn't respond and I get the following >messages on the console: > > ata1: command 0x35 timeout, stat 0x50 host_stat 0x4 > hda: lost interrupt > mpic_enable_irq timeout > ata1: command 0x35 timeout, stat 0x50 host_stat 0x4 > >Moreover, pushing the TAB button (tab completion in shell at the console) >results in a scrolling screen and the above error at once. >What's this? > >Zoltan > > > There seems to be a few regressions in the final release which was working better in FC4test3 for the PPC architecture. This is probably one of them. Put them in bugzilla as you come across these regards Rahul From buildsys at redhat.com Fri Jun 17 11:35:18 2005 From: buildsys at redhat.com (Build System) Date: Fri, 17 Jun 2005 07:35:18 -0400 Subject: rawhide report: 20050617 changes Message-ID: <200506171135.j5HBZILw030776@porkchop.devel.redhat.com> New package adaptx AdaptX New package bsh Lightweight Scripting for Java New package carol CAROL: Common Architecture for RMI ObjectWeb Layer New package castor An open source data binding framework for Java New package gif89encoder Java class library for encoding GIFs New package gnu.regexp Java NFA regular expression engine implementation New package howl-logger High speed ObjectWeb logger New package hsqldb Hsqldb Database Engine New package jakarta-commons-cli Jakarta Commons CLI, a Command Line Interface for Java New package jgroups Toolkit for reliable multicast communication. New package jonathan-core Distributed Object Platform (DOP) written entirely in Java New package jonathan-jeremie Distributed Object Platform (DOP) written entirely in Java New package joram JORAM: Java (TM) Open Reliable Asynchronous Messaging New package jotm JOTM : A Java Open Transaction Manager New package monolog API for monitoring and logging New package nanoxml NanoXML is a small XML parser for Java New package objectweb-anttask ObjectWeb Ant task New package oldkilim A generic configuration framework for Java New package p6spy Database statement interceptor for Java New package wsdl4j Web Services Description Language Toolkit for Java Updated Packages: NetworkManager-0.4-31.cvs20050616 --------------------------------- * Thu Jun 16 2005 Dan Williams - 0.4-31.cvs20050616 - Update to latest CVS o Clean up wording in Wireless Network Discovery menu o Robert Love's applet beautify patch alsa-utils-1.0.9rf-2 -------------------- * Thu Jun 16 2005 Martin Stransky 1.0.9-2 - New upstream version * Mon May 30 2005 Martin Stransky 1.0.9-1 - New upstream version. - moved alsacard utility from alsa-lib to alsa-tools audit-0.9.7-1 ------------- * Thu Jun 16 2005 Steve Grubb 0.9.7-1 - fixed bug in send_user_message which errored on pam logins - Change nanosleeps over to select loops - Change the 'e' option to auditctl -p to 'x' * Thu Jun 16 2005 Steve Grubb 0.9.6-1 - fix bug in incremental flush where is wrongly reported an error - ausearch should not do uid check for -if option - adjust ipc interpretation to not use ipc.h coreutils-5.2.1-51 ------------------ * Fri Jun 17 2005 Tim Waugh 5.2.1-51 - Use upstream hostid fix. * Thu Jun 16 2005 Tim Waugh 5.2.1-50 - Don't display the sign-extended part of the host id (bug #160078). * Tue May 31 2005 Dan Walsh 5.2.1-49 - Eliminate bogus "can not preserve context" message when moving files. cryptsetup-luks-1.0-2 --------------------- * Thu Jun 16 2005 Bill Nottingham 1.0-2 - add patch for 32/64 bit compatibility (#160445, ) cups-1:1.1.23-16 ---------------- * Thu Jun 16 2005 Tim Waugh 1:1.1.23-16 - Make DeletePrinterFromClass faster (bug #160620). eclipse-1:3.1.0_fc-0.M7.9 ------------------------- * Tue Jun 14 2005 Andrew Overholt 3.1.0_fc-0.M7.9 - Add tomcat5 patch and symlinks. * Thu May 26 2005 Andrew Overholt 3.1.0_fc-0.M7.8 - Fix ant jar removal (gbenson). * Wed May 25 2005 Andrew Overholt 3.1.0_fc-0.M7.7 - Fix ecj symlink in /usr/share/java (rh#158734). gcc-4.0.0-12 ------------ * Thu Jun 16 2005 Jakub Jelinek 4.0.0-12 - update from CVS - PRs fortran/22038, libfortran/20930, libfortran/21950, rtl-opt/21528, target/20301, target/21889, tree-opt/19768, tree-optimization/21171, tree-optimization/21847, tree-optimization/22043 - further fixes for Fortran FORALL, also use less temporary memory for masks - make libltdl aware of */lib64 paths (#156005) - cast of vector to integral type fix (PR middle-end/21850) - libstdc++.so symbol versioning fixes (Benjamin Kosnik) iiimf-1:12.2-5 -------------- * Fri Jun 10 2005 Akira TAGOH - 1:12.2-5 - Fixed the compiler warnings. (#159392) - xiiimp-xft.patch: updated to fix use of uninitialized variable. - EIMIL-fix-uninitialized-value.patch: likewise. * Mon Jun 06 2005 Akira TAGOH - iiimgcf-fix-memory-leak-r2660.patch: fixed a memory leak. - xiiimp-fix-infinite-loop-property-notify-event-r2661.patch: fixed the infinite loop of PropertyNotify event that it causes eating more CPUs and memory at iiimd. (#158254) * Thu Jun 02 2005 Akira TAGOH - added a simple wrapper for iiimd to avoid iiimd running as root when it needs to be run at the terminal for debugging purpose. - ensure the directory owner of /var/run/iiim is iiimd. kdemultimedia-6:3.4.1-0.fc4.1 ----------------------------- * Thu Jun 16 2005 Than Ngo 3.4.1-0.fc4.1 - 3.4.1 * Tue May 03 2005 Than Ngo 6:3.4.0-3 - fix kde-multimedia-music.menu kdesdk-3.4.1-0.fc4.1 -------------------- * Thu Jun 16 2005 Than Ngo 3.4.1-0.fc4.1 - 3.4.1 mod_auth_mysql-1:2.9.0-1 ------------------------ * Thu Jun 16 2005 Joe Orton 1:2.9.0-1 - update to 2.9.0 (#160239) netatalk-4:2.0.3-1 ------------------ * Thu Jun 16 2005 Jason Vas Dias - Upgrade to upstream version 2.0.3 - fix bug 160486: use netatalk's initscript redhat-rpm-config-8.0.36-1 -------------------------- * Thu Jun 16 2005 Elliot Lee - 8.0.36-1 - Fix the fix * Wed Apr 06 2005 Elliot Lee - 8.0.35-1 - Fix #129025 (enable python byte compilation) ruby-1.8.2-8 ------------ * Thu Jun 16 2005 Akira TAGOH - 1.8.2-8 - ruby-1.8.2-tcltk-multilib.patch: applied to get tcltklib.so built. (#160194) selinux-policy-strict-1.23.18-11 -------------------------------- * Thu Jun 16 2005 Dan Walsh 1.23.18-11 - Fix NetworkManager dhcpd communications - Fix hotplug * Thu Jun 16 2005 Dan Walsh 1.23.18-9 - Update Ivan trusted/untrusted patch - add texrel_shlib_t to targeted selinux-policy-targeted-1.23.18-11 ---------------------------------- * Thu Jun 16 2005 Dan Walsh 1.23.18-11 - Fix NetworkManager dhcpd communications - Fix hotplug * Thu Jun 16 2005 Dan Walsh 1.23.18-9 - Update Ivan trusted/untrusted patch - add texrel_shlib_t to targeted * Wed Jun 15 2005 Dan Walsh 1.23.18-7 - Fixed for new cups domain hplip shared-mime-info-0.16-4 ----------------------- * Fri Jun 17 2005 David Zeuthen - 0.16-4 - Add MIME-types for .pcf Cisco VPN settings files (fdo #3560) system-config-printer-0.6.134-1 ------------------------------- * Thu Jun 16 2005 Tim Waugh - Updated file manifest to include glob patterns for python byte compilation. - 0.6.134: - No code changes. Rebuilt for python byte compilation. * Thu Jun 16 2005 Tim Waugh 0.6.133-1 - 0.6.133: - No code changes. Rebuilt for python byte compilation. util-linux-2.12p-10 ------------------- * Thu Jun 16 2005 Karel Zak 2.12p-10 - fix #157656 ??? CRM 546998: Possible bug in vipw, changes permissions of /etc/shadow and /etc/gshadow - fix #159339 - util-linux updates for new audit system (pam_loginuid.so added to util-linux-selinux.pamd) - fix #159418 - sfdisk unusable - crashes immediately on invocation - fix #157674 ??? sync option on VFAT mount destroys flash drives - fix .spec file /usr/sbin/{hwclock,clock} symlinks xorg-x11-6.8.2-38 ----------------- * Thu Jun 09 2005 Mike A. Harris 6.8.2-38 - Removed unused legacy with_new_savage_driver macro and conditional spec file code. - Added xorg-x11-6.8.2-ati-radeon-7000-disable-dri.patch to disable DRI on Radeon 7000/VE hardware to test patch in rawhide prior to inclusion in RHEL4U2. (#150174) * Mon Jun 06 2005 Mike A. Harris - Removed with_libs_data macro as it is no longer useful. - Updated "Obsoletes: xorg-x11-libs-data" line to remove versioning * Mon May 30 2005 Mike A. Harris 6.8.2-37 - Implemented xorg-x11-6.8.2-redhat-kt.patch new kernel tainting diagnostics patch to aide in troubleshooting reported issues. - Removed older redhat-custom patch as the kt patch above replaces it now. - s/XFree86CustomVersion/XorgCustomVersion/ in host.def - Build for FC5 development. From dhollis at davehollis.com Fri Jun 17 11:47:08 2005 From: dhollis at davehollis.com (David Hollis) Date: Fri, 17 Jun 2005 07:47:08 -0400 Subject: Yum Upgrade Faq In-Reply-To: <1118642915.19703.52.camel@cutter> References: <1118642915.19703.52.camel@cutter> Message-ID: <1119008828.9273.0.camel@dhollis-lnx.sunera.com> On Mon, 2005-06-13 at 02:08 -0400, seth vidal wrote: > I've added a wiki page here: > http://fedoraproject.org/wiki/YumUpgradeFaq > > It's about upgrading from release to release via yum. If you find any > other odd gotchas - add them there. > A new problem that has popped up twice is that after getting 'yum upgrade yum' to work, yum no longer works! It says that it can't find it's libraries to run. The fix is to upgrade rpm-* (which leads me to believe that rpm-python is the culprit) and all is well again. -- David Hollis -------------- 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 dan.track at gmail.com Fri Jun 17 12:10:29 2005 From: dan.track at gmail.com (Dan Track) Date: Fri, 17 Jun 2005 13:10:29 +0100 Subject: Boot up problem in xen Message-ID: <9d5ddd1f0506170510c52aef3@mail.gmail.com> Hi I installed rhel 3 using a cdrom in the normal way but without installing the bootloader. The problem is that it won't boot up. Below is the bootup messages, as you can see it only goes as far as freeing unused memory, then it stops. Any ideas on this? xen_blk: Initialising virtual block device driver xen_net: Initialising virtual ethernet driver. md: md driver 0.90.1 MAX_MD_DEVS=256, MD_SB_DISKS=27 NET: Registered protocol family 2 IP: routing cache hash table of 256 buckets, 4Kbytes TCP established hash table entries: 4096 (order: 4, 65536 bytes) TCP bind hash table entries: 4096 (order: 3, 49152 bytes) TCP: Hash tables configured (established 4096 bind 4096) Initializing IPsec netlink socket NET: Registered protocol family 1 NET: Registered protocol family 17 md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: 156k freed Thanks Dan From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jun 17 12:46:40 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 17 Jun 2005 14:46:40 +0200 Subject: rawhide report: 20050617 changes In-Reply-To: <200506171135.j5HBZILw030776@porkchop.devel.redhat.com> References: <200506171135.j5HBZILw030776@porkchop.devel.redhat.com> Message-ID: <20050617144640.4fcf55bb@python2> Build System wrote : > New package adaptx > AdaptX > > New package bsh > Lightweight Scripting for Java > > New package carol > CAROL: Common Architecture for RMI ObjectWeb Layer > > New package castor > An open source data binding framework for Java > > New package gif89encoder > Java class library for encoding GIFs > > New package gnu.regexp > Java NFA regular expression engine implementation > > New package howl-logger > High speed ObjectWeb logger > > New package hsqldb > Hsqldb Database Engine > > New package jakarta-commons-cli > Jakarta Commons CLI, a Command Line Interface for Java > > New package jgroups > Toolkit for reliable multicast communication. > > New package jonathan-core > Distributed Object Platform (DOP) written entirely in Java > > New package jonathan-jeremie > Distributed Object Platform (DOP) written entirely in Java > > New package joram > JORAM: Java (TM) Open Reliable Asynchronous Messaging > > New package jotm > JOTM : A Java Open Transaction Manager > > New package monolog > API for monitoring and logging > > New package nanoxml > NanoXML is a small XML parser for Java > > New package objectweb-anttask > ObjectWeb Ant task > > New package oldkilim > A generic configuration framework for Java > > New package p6spy > Database statement interceptor for Java > > New package wsdl4j > Web Services Description Language Toolkit for Java Wow, another bunch :-/ Am I the only one that it kind of bothers to not see java stuff using a dedicated namespace for the package names? Things like "gnu.regexp" seem totally wrong... not to mention the dot in the name for that particular one. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.11-1.27_FC3 Load : 0.05 0.63 1.33 From jspaleta at gmail.com Fri Jun 17 12:51:29 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 17 Jun 2005 08:51:29 -0400 Subject: rawhide report: 20050617 changes In-Reply-To: <20050617144640.4fcf55bb@python2> References: <200506171135.j5HBZILw030776@porkchop.devel.redhat.com> <20050617144640.4fcf55bb@python2> Message-ID: <604aa7910506170551254efc2f@mail.gmail.com> On 6/17/05, Matthias Saou > Am I the only one that it kind of bothers to not see java stuff using a > dedicated namespace for the package names? Things like "gnu.regexp" seem > totally wrong... not to mention the dot in the name for that particular > one. Luckily its rawhide... so there is still hope to get the namespace issues worked out. Is this an issue that needs to be brought up to the packaging list to create some usable guidelines for the java space? From linux_4ever at yahoo.com Fri Jun 17 13:20:19 2005 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 17 Jun 2005 06:20:19 -0700 (PDT) Subject: Audit / Netlink slowness In-Reply-To: <42B19042.3090508@tlarson.com> Message-ID: <20050617132019.65107.qmail@web51502.mail.yahoo.com> >A more reasonable solution would be a select() with a maximum timeout of >100ms. This has been implemented. It should be noticably faster. I put the new package (0.9.7) in rawhide. Anyone interested in this problem should try it out. I will probably push out a new audit package for FC4 next week after some testing feedback. Thanks, -Steve Grubb __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail From harald at redhat.com Fri Jun 17 14:59:53 2005 From: harald at redhat.com (Harald Hoyer) Date: Fri, 17 Jun 2005 16:59:53 +0200 Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ - Python test scripts for Proof of Concept In-Reply-To: <42B15F7F.90803@redhat.com> References: <42B15F7F.90803@redhat.com> Message-ID: <42B2E569.3030100@redhat.com> Harald Hoyer wrote: > Next steps I want to do: > - replace rc functionality for complete backwards compatibility Done > - implement the depends/requires mechanism (also with dynamic > requirements and dependencies) Done > - patch all initscripts to conform to LSB Todo > - convert prefdm to an initscript which requires $authentication and > $local_dir + and use gdm-early-login, gdm-allow-login > - create an initscript, which provides $authentication and depends on > $network, if network auth is needed. Todo > - convert /etc/init.d/functions and /sbin/service to use the DBUS interface Todo - use gobject.MainLoop() instead of patching the dbus python bindings Done See: http://people.redhat.com/harald/ServiceManager/ Harald -- Code, code, give me some open source code! From overholt at redhat.com Fri Jun 17 15:34:52 2005 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 17 Jun 2005 11:34:52 -0400 Subject: rawhide report: 20050617 changes In-Reply-To: <20050617144640.4fcf55bb@python2> References: <200506171135.j5HBZILw030776@porkchop.devel.redhat.com> <20050617144640.4fcf55bb@python2> Message-ID: <1119022492.12460.0.camel@tofu.toronto.redhat.com> On Fri, 2005-06-17 at 14:46 +0200, Matthias Saou wrote: > Am I the only one that it kind of bothers to not see java stuff using a > dedicated namespace for the package names? Things like "gnu.regexp" seem > totally wrong... not to mention the dot in the name for that particular > one. If you want, bring this up with the JPackage folk since that's where the names are coming from. Andrew From bclark at redhat.com Fri Jun 17 15:33:58 2005 From: bclark at redhat.com (Bryan Clark) Date: Fri, 17 Jun 2005 11:33:58 -0400 Subject: Boot up problem in xen In-Reply-To: <9d5ddd1f0506170510c52aef3@mail.gmail.com> References: <9d5ddd1f0506170510c52aef3@mail.gmail.com> Message-ID: <1119022438.2741.2.camel@rhbw.boston.redhat.com> On Fri, 2005-06-17 at 13:10 +0100, Dan Track wrote: > Hi > > I installed rhel 3 using a cdrom in the normal way but without > installing the bootloader. The problem is that it won't boot up. Below > is the bootup messages, as you can see it only goes as far as freeing > unused memory, then it stops. Any ideas on this? Make sure you do this first. http://wiki.xensource.com/xenwiki/XenFaq#head-ea8b39d71e49cc16d287257de4c482f99d883097 ~ Bryan From Matt_Domsch at dell.com Fri Jun 17 17:13:38 2005 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 17 Jun 2005 12:13:38 -0500 Subject: [PATCH] initscripts for OpenIPMI Message-ID: <20050617171338.GA23789@lists.us.dell.com> More progress on the initscripts to automatically load the IPMI device drivers. initscript and config file included in this patch. Please review and incorporate into the OpenIPMI package. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com --- /dev/null Thu Apr 11 09:25:15 2002 +++ ipmi/ipmi.init Fri Jun 17 12:10:09 2005 @@ -0,0 +1,248 @@ +#!/bin/sh +############################################################################# +# +# ipmi: OpenIPMI Driver init script +# +# Authors: Matt Domsch +# Chris Poblete +# +# chkconfig: 2345 04 96 +# description: OpenIPMI Driver init script +# +### BEGIN INIT INFO +# Provides: ipmidrv +# Required-Start: $localfs $remotefs $syslog +# Required-Stop: $localfs $remotefs $syslog +# Default-Start: 2 3 4 5 +# Default-Stop: +# Short-Description: OpenIPMI Driver init script +# Description: OpenIPMI Driver init script +### END INIT INFO +# +############################################################################# +# for log_success_msg and friends +[ -r /lib/lsb/init-functions ] && . /lib/lsb/init-functions +# source config info +[ -r /etc/sysconfig/ipmi ] && . /etc/sysconfig/ipmi + +############################################################################# +# GLOBALS +############################################################################# +MODULE_NAME="ipmi" +INTF_NUM=0 + +IPMI_SMB_MODULE_NAME="ipmi_smb" +IPMI_SI_MODULE_NAME="ipmi_si" +kernel=`uname -r | cut -d. -f1-2` +if [ "${kernel}" == "2.4" ]; then + IPMI_SMB_MODULE_NAME="ipmi_smb_intf" + IPMI_SI_MODULE_NAME="ipmi_si_drv" +fi + +MODULES_INTERFACES="ipmi_imb ipmi_devintf" +MODULES_FEATURES="ipmi_watchdog ipmi_poweroff" +MODULES_HW="${IPMI_SMB_MODULE_NAME} ${IPMI_SI_MODULE_NAME}" +MODULES_BASE="ipmi_msghandler" +MODULES="${MODULES_INTERFACES} ${MODULES_FEATURES} ${MODULES_HW} ${MODULES_BASE}" + + +RETVAL=0 +LOCKFILE=/var/lock/subsys/ipmi + + +############################################################################# +load_si() +{ + if [ "${IPMI_SI}" = "1" ]; then + modprobe ${IPMI_SI_MODULE_NAME} || RETVAL=1 + fi +} + +load_smb() +{ + if [ "${IPMI_SMB}" = "1" ]; then + modprobe ${IPMI_SMB_MODULE_NAME} || RETVAL=1 + fi +} + +load_hw_modules() +{ + load_si + load_smb +} + +start_watchdog() +{ + if [ "${IPMI_WATCHDOG}" = "1" ]; then + load_hw_modules + modprobe ipmi_watchdog ${IPMI_WATCHDOG_OPTIONS} || RETVAL=2 + if [ ! -x /sbin/udev -a ! -e /dev/watchdog ]; then + mknod -m 0600 /dev/watchdog 10 130 || RETVAL=2 + fi + fi +} + +stop_watchdog() +{ + modprobe -q -r ipmi_watchdog + [ ! -x /sbin/udev ] && rm /dev/watchdog +} + +start_powercontrol() +{ + local poweroff_opts="" + if [ "${IPMI_POWEROFF}" = "1" ]; then + load_hw_modules + [ "${IPMI_POWERCYCLE}" == "1" ] && poweroff_opts="poweroff_control=2" + modprobe ipmi_poweroff "${poweroff_opts}" || RETVAL=2 + fi +} + +stop_powercontrol() +{ + modprobe -q -r ipmi_poweroff +} + +############################################################################# +unload_all_ipmi_modules() +{ + [ ! -x /sbin/udev ] && rm -f "/dev/ipmi${INTF_NUM}" + stop_watchdog + for m in ${MODULES}; do + modprobe -q -r ${m} + done +} + +unload_ipmi_modules_leave_features() +{ + [ ! -x /sbin/udev ] && rm -f "/dev/ipmi${INTF_NUM}" + for m in ${MODULES_INTERFACES}; do + modprobe -q -r ${m} + done + lsmod | egrep -q "ipmi_poweroff|ipmi_watchdog" + if [ "$?" -ne "0" ]; then + stop_watchdog + for m in ${MODULES}; do + modprobe -q -r ${m} + done + fi +} + + +############################################################################# +load_ipmi_modules () +{ + modprobe ipmi_msghandler || RETVAL=1 + load_hw_modules + [ "${RETVAL}" = "1" ] && unload_all_ipmi_modules && return + + start_watchdog + start_powercontrol + + if [ "${DEV_IPMI}" = "1" ]; then + modprobe ipmi_devintf || RETVAL=2 + if [ "${RETVAL}" != "2" ]; then + if [ ! -x /sbin/udev ]; then + DEVMAJOR=`cat /proc/devices | awk '/ipmidev/{print $1}'` + mknod -m 0600 /dev/ipmi${INTF_NUM} c ${DEVMAJOR} 0 || RETVAL=2 + fi + fi + fi + + if [ "${IPMI_IMB}" = "1" ]; then + modprobe ipmi_imb || RETVAL=2 + if [ "${RETVAL}" != "2" ]; then + DEVMAJOR=`cat /proc/devices | awk '/imb/{print $1}'` + mknod -m 0600 /dev/imb c ${DEVMAJOR} 0 || RETVAL=2 + fi + fi + + # Per Corey Minyard, essentially no one uses ipmi_radisys + # and we don't want to encourage its further use + # so it won't be handled here. + return +} + +############################################################################# +start() +{ + echo -n $"Starting ${MODULE_NAME} drivers: " + load_ipmi_modules + [ "${RETVAL}" = "1" ] && log_failure_msg && return + [ "${RETVAL}" = "2" ] && touch ${LOCKFILE} && log_warning_msg + [ "${RETVAL}" = "0" ] && touch ${LOCKFILE} && log_success_msg +} + +############################################################################# +stop() +{ + echo -n $"Stopping ${MODULE_NAME} drivers: " + unload_ipmi_modules_leave_features + rm -f ${LOCKFILE} + log_success_msg +} + +stop_all() +{ + echo -n $"Stopping ${MODULE_NAME} drivers: " + unload_all_ipmi_modules + rm -f ${LOCKFILE} + log_success_msg +} + +############################################################################# +restart() +{ + stop_all + start +} + +############################################################################# +status () +{ + for m in ${MODULES}; do + if /sbin/lsmod | grep $m >/dev/null 2>&1 ; then + echo "$m module loaded" + else + echo "$m module not loaded" + fi + done +} + +usage () +{ + echo $"Usage: $0 {start|stop|status|restart|condrestart|" 1>&2 + echo $" start-watchdog|stop-watchdog|" 1>&2 + echo $" start-powercontrol|stop-powercontrol|" 1>&2 + echo $" stop-all}" 1>&2 + RETVAL=1 +} + +condrestart () +{ + [ -e ${LOCKFILE} ] && restart +} + +############################################################################# +# MAIN +############################################################################# +case "$1" in + start) start ;; + stop) stop ;; + restart) restart ;; + status) status ;; + condrestart) condrestart ;; + start-watchdog) start_watchdog ;; + stop-watchdog) stop_watchdog ;; + start-powercontrol) start_powercontrol ;; + stop-powercontrol) stop_powercontrol ;; + stop-all) stop_all ;; + *) usage ;; +esac + +exit ${RETVAL} + +############################################################################# +# end of file +############################################################################# + --- /dev/null Thu Apr 11 09:25:15 2002 +++ ipmi/ipmi.sysconf Fri Jun 17 12:10:15 2005 @@ -0,0 +1,36 @@ +# Enable standard hardware interfaces (KCS, BT, SMIC) +# You probably want this enabled. +IPMI_SI=1 + +# Enable nonstandard interfaces (SMB via i2c) +# IPMI_SMB=1 + +# Enable /dev/ipmi0 interface, used by ipmitool, ipmicmd, +# and other userspace IPMI-using applications. +# You probably want this enabled. +DEV_IPMI=1 + +# Enable IPMI_WATCHDOG if you want the IPMI watchdog +# to reboot the system if it hangs +# IPMI_WATCHDOG=1 +# +# Watchdog options - modinfo ipmi_watchdog for details +# watchdog timeout value in seconds +# as there is no userspace ping application that runs during shutdown, +# be sure to give it enough time for any device drivers to +# do their cleanup (e.g. megaraid cache flushes) +# without the watchdog triggering prematurely +IPMI_WATCHDOG_OPTIONS="timeout=60" + +# Enable IPMI_POWEROFF if you want the IPMI +# poweroff module to be loaded. +# IPMI_POWEROFF=1 + +# Enable IPMI_POWERCYCLE if you want the system to be power-cycled (power +# down, delay briefly, power on) rather than power off, on systems +# that support such. IPMI_POWEROFF=1 is also required. +# IPMI_POWERCYCLE=1 + +# Enable "legacy" interfaces for applications +# Intel IMB driver interface +# IPMI_IMB=1 From ziga.mahkovec at klika.si Fri Jun 17 19:50:31 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Fri, 17 Jun 2005 21:50:31 +0200 Subject: rawhide report: 20050617 changes In-Reply-To: <200506171135.j5HBZILw030776@porkchop.devel.redhat.com> References: <200506171135.j5HBZILw030776@porkchop.devel.redhat.com> Message-ID: <1119037832.3377.17.camel@localhost> On Fri, 2005-06-17 at 07:35 -0400, Build System wrote: > [...] > > New package gnu.regexp > Java NFA regular expression engine implementation I was wondering why gnu.regexp was included, given that it's already part of libgcj? -- Ziga From overholt at redhat.com Fri Jun 17 20:29:36 2005 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 17 Jun 2005 16:29:36 -0400 Subject: rawhide report: 20050617 changes In-Reply-To: <1119037832.3377.17.camel@localhost> References: <200506171135.j5HBZILw030776@porkchop.devel.redhat.com> <1119037832.3377.17.camel@localhost> Message-ID: <20050617202935.GB25848@redhat.com> * Ziga Mahkovec [2005-06-17 15:51]: > On Fri, 2005-06-17 at 07:35 -0400, Build System wrote: > > [...] > > > > New package gnu.regexp > > Java NFA regular expression engine implementation > > I was wondering why gnu.regexp was included, given that it's already > part of libgcj? I'm not sure. Gary? Andrew From pmatilai at laiskiainen.org Fri Jun 17 20:53:17 2005 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Fri, 17 Jun 2005 23:53:17 +0300 Subject: rawhide report: 20050617 changes In-Reply-To: <1119022492.12460.0.camel@tofu.toronto.redhat.com> References: <200506171135.j5HBZILw030776@porkchop.devel.redhat.com> <20050617144640.4fcf55bb@python2> <1119022492.12460.0.camel@tofu.toronto.redhat.com> Message-ID: <1119041598.12551.14.camel@localhost.localdomain> On Fri, 2005-06-17 at 11:34 -0400, Andrew Overholt wrote: > On Fri, 2005-06-17 at 14:46 +0200, Matthias Saou wrote: > > Am I the only one that it kind of bothers to not see java stuff using a > > dedicated namespace for the package names? Things like "gnu.regexp" seem > > totally wrong... not to mention the dot in the name for that particular > > one. No you're not alone in that Matthias... > > If you want, bring this up with the JPackage folk since that's where the > names are coming from. Since when did FC start to follow whatever somebody else does? It's not any different for java, "gnu.regexp" is simply a bad name for a java-only library (or whatever they're called in the java-land). Just imagine all the perl-modules in FC without perl-prefix: - XML-SAX - TimeDate - HTML-Parser ... etc. I think you get the idea. - Panu - From skvidal at phy.duke.edu Fri Jun 17 20:56:41 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 17 Jun 2005 16:56:41 -0400 Subject: rawhide report: 20050617 changes In-Reply-To: <1119041598.12551.14.camel@localhost.localdomain> References: <200506171135.j5HBZILw030776@porkchop.devel.redhat.com> <20050617144640.4fcf55bb@python2> <1119022492.12460.0.camel@tofu.toronto.redhat.com> <1119041598.12551.14.camel@localhost.localdomain> Message-ID: <1119041801.2440.21.camel@cutter> > Just imagine all the perl-modules in FC without perl-prefix: Please, I'd rather not imagine that. /me shudders -sv From mikem at cyber.com.au Sat Jun 18 03:07:47 2005 From: mikem at cyber.com.au (Mike MacCana) Date: Sat, 18 Jun 2005 13:07:47 +1000 Subject: YourUpsteamsVeryImportantPackage In-Reply-To: <42B2E569.3030100@redhat.com> References: <42B15F7F.90803@redhat.com> <42B2E569.3030100@redhat.com> Message-ID: <42B39003.2050503@cyber.com.au> Thanks very much for your work Harald, I'm looking forward to using it. Harald Hoyer wrote: > See: http://people.redhat.com/harald/ServiceManager/ Please, please, lowercase. 99% of all other packages, and 99% of all other services are lowercase. NetworkManager and HelixPlayer and MyPackageWhichIsAlsoVeryImportantAndThereforeNeedsToBreakConventionUnnecessarily are a hassle. Since FC packages what the upstream does, and you're the upstream on this one, could it be lowercase? Mike From bernie at develer.com Sat Jun 18 04:52:06 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Sat, 18 Jun 2005 06:52:06 +0200 Subject: Audit / Netlink slowness In-Reply-To: <20050616134142.32720.qmail@web51503.mail.yahoo.com> References: <20050616134142.32720.qmail@web51503.mail.yahoo.com> Message-ID: <42B3A876.7020406@develer.com> Steve G wrote: >>pam-0.79-10 >>audit-libs-0.9.3-1 >>coreutils-5.2.1-31 >>kernel-2.6.11-1.1240_FC4 > > These are all good. I released a new audit package that has 2 syscalls removed. > You should see a performance improvement with audit-libs-0.9.5. > > [...snip...] > > I don't doubt your claims. I have made improvements with the assumption that your > results are reproducable. audit-libs-0.9.5 should behave better for you. I will > also release 0.9.6 today and see if I can get some timing information. I am using > a special kernel that has all the audit patches applied so my results may not > hold for a FC4 kernel. I'm testing again with latest audit-libs (0.9.7-1) and a newer kernel (2.6.11-1.1383_FC5). I'm happy to report that the strange delays I reported are gone. Commands like su and ssh are very fast now. However, this is not the same machine I tested with the first time. It's an x86_64... and I also noticed that I've compiled the kernel without CONFIG_AUDITSYSCALL. I'm not sure if it may be important, but I can't reboot right now, so I'll retest later. > Thanks for bringing this performance issue up. Thanks to *you* for fixing it! -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From bernie at develer.com Sat Jun 18 05:26:47 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Sat, 18 Jun 2005 07:26:47 +0200 Subject: Single sign-on infrastructure (FC5 wish) Message-ID: <42B3B097.7060109@develer.com> Hello, I realize it's a bit late for posting more FC5 wish-list entries, but I'll try any way in case Santa is still listening. I've been researching Linux user-management and authentication in enterprise environments for a few months. I'm quite disappointed by the lack of integration between the various components, which effectively makes it very hard to provide a single authentication for intranet users. This isn't specific to Fedora: no Linux distro I know of provides a decent solution to this very common problem (at least, common to any site with 10 or more users). My current environment looks roughly like this: - OpenLDAP to store user's information and authentication data; - nss_ldap to let all clients share user information; - Samba with LDAP backend; - Heimdal's KDC, configured with the LDAP backend. Heimdal can use NT password hashes as kerberos authentication info. (MIT's kerberos does not yet come with it, but I've read Novell contributed code some time ago); - pam_krb5 to obtain Kerberos tickets at login time; - mod_auth_kerb to perform SPNEGO with Apache; - hacked Firefox configuration on all clients to enable negotiate-auth for https; What works: - Use intranet pages with Konqueror and Firefox from Fedora and Gentoo clients. - I can manually request a ticket on MacOS X and use it with Firefox. Safari is supposed to work, but it doesn't, for reasons I can't explain. What's missing: - I can't get anything to work for Windows 2000 and XP clients. That would require more integration between Samba and Heimdal, and perhaps full ADS support. Hopefully Samba 4 will solve this. - Some web applications want their own user database (notably Bugzilla, Mailman and MoinMoin); - Most web applications use their own cookie-based authentication method (SquirrelMail, Bugzilla, Mailman...); - I couldn't get password-less IMAP to work with courier-imap because of limited SASL support. Maybe I'd be more lucky with cyrus-imap, but it doesn't support Maildirs, so I can't switch; - NFSv4 with GSSAPI authentication. Many patches from CITI are still missing in the kernel and in userland. I found it extremely difficult to get reliable NFS operation with NFSv4 (but it was two months ago, the situation may have improved in the meantime); - Integrated management tools. I've currently settled with a combination of phpLdapAdmin, ldapvi and smb-ldaptools, all of which arn't exactly as simple and quick as traditional UNIX tools (useradd, passwd, vipw...); Oh, Santa, please bring me an FC5 with single-signon out of the box! I promise I'll be a good boy and help fixing bugs. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From mikem at cyber.com.au Sat Jun 18 06:56:40 2005 From: mikem at cyber.com.au (Mike MacCana) Date: Sat, 18 Jun 2005 16:56:40 +1000 Subject: Single sign-on infrastructure (FC5 wish) In-Reply-To: <42B3B097.7060109@develer.com> References: <42B3B097.7060109@develer.com> Message-ID: <42B3C5A8.7080309@cyber.com.au> Bernardo Innocenti wrote: > - Heimdal's KDC, configured with the LDAP backend. > Heimdal can use NT password hashes as kerberos > authentication info. > > As of right now, krb5_workstation can authenticate Linux against AD in exactly the same manner as Windows 2000, XP and 2003 clients - using Kerberos over TCP for long requests, and weird MS specific encryption types. All the stuff that MS did to Kerberos is now doable on Unix. > - hacked Firefox configuration on all clients to > enable negotiate-auth for https; > > Surprised firefox doesn't support kerberos through GSSAPI or similar as is. I thought the version in RHEL 4 did - there was a big Kerberos push for RHEL 4 - are you sure? > - I can't get anything to work for Windows 2000 and XP > clients. That would require more integration between > Samba and Heimdal, and perhaps full ADS support. > Hopefully Samba 4 will solve this. > > Yep. > - Some web applications want their own user database > (notably Bugzilla, Mailman and MoinMoin); > > A krb5 authing, LDAP using Bugzilla would be great. > - Most web applications use their own cookie-based > authentication method (SquirrelMail, Bugzilla, > Mailman...); > > > - I couldn't get password-less IMAP to work with > courier-imap because of limited SASL support. > > Dovecot supports krb5 IIRC. > - NFSv4 with GSSAPI authentication. Many patches from > CITI are still missing in the kernel and in userland. > I found it extremely difficult to get reliable NFS > operation with NFSv4 (but it was two months ago, the > situation may have improved in the meantime); > > Haven't played with this. Have you tried AFS? It's a neater protocol and has a few large implementations (eg, CSFB) using it on Red Hat like systems. > - Integrated management tools. I've currently settled > with a combination of phpLdapAdmin, ldapvi and > smb-ldaptools, all of which arn't exactly as simple > and quick as traditional UNIX tools (useradd, passwd, > vipw...); > > jXplorer from CA is Open Source, good, and may well build on a free java stack. It's already on the FC5future area of the wiki. Mike From dwmw2 at infradead.org Sat Jun 18 07:10:23 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 18 Jun 2005 08:10:23 +0100 Subject: Single sign-on infrastructure (FC5 wish) In-Reply-To: <42B3B097.7060109@develer.com> References: <42B3B097.7060109@develer.com> Message-ID: <1119078623.24842.26.camel@localhost.localdomain> On Sat, 2005-06-18 at 07:26 +0200, Bernardo Innocenti wrote: > - I couldn't get password-less IMAP to work with > courier-imap because of limited SASL support. > Maybe I'd be more lucky with cyrus-imap, but it > doesn't support Maildirs, so I can't switch; Passwordless IMAP works for me. Try invoking courier or dovecot over an SSH login. Evolution and mutt at least can run 'ssh $server exec imapd' instead of trying to make a TCP connection to the imap server and then authenticating to it. -- dwmw2 From bernie at develer.com Sat Jun 18 07:44:32 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Sat, 18 Jun 2005 09:44:32 +0200 Subject: Single sign-on infrastructure (FC5 wish) In-Reply-To: <42B3C5A8.7080309@cyber.com.au> References: <42B3B097.7060109@develer.com> <42B3C5A8.7080309@cyber.com.au> Message-ID: <42B3D0E0.5020700@develer.com> Mike MacCana wrote: > Bernardo Innocenti wrote: > >> - Heimdal's KDC, configured with the LDAP backend. >> Heimdal can use NT password hashes as kerberos >> authentication info. >> >> > As of right now, krb5_workstation can authenticate Linux against AD in > exactly the same manner as Windows 2000, XP and 2003 clients - using > Kerberos over TCP for long requests, and weird MS specific encryption > types. All the stuff that MS did to Kerberos is now doable on Unix. The thing is, Samba does not yet support acting as an ADS DC, and I don't have (or want) a W2K domain controller in my network :-) Being able to use sambaSamAccount information in Heimdal is very useful: otherwise I'd have to create separate krb5 principals for all users and using hacky scripts to keep passwords in sync between POSIX, Samba and Kerberos. >> - hacked Firefox configuration on all clients to >> enable negotiate-auth for https; >> > Surprised firefox doesn't support kerberos through GSSAPI or similar as > is. I thought the version in RHEL 4 did - there was a big Kerberos push > for RHEL 4 - are you sure? I didn't rebuild Firefox, I just hacked prefs.js to set: user_pref("network.negotiate-auth.delegation-uris", "http://, https://"); user_pref("network.negotiate-auth.trusted-uris", "http://, https://"); IIRC, Mozilla shipped with FC3 doesn't support it. Only Firefox does. But who's still using Mozilla anyway? >> - I can't get anything to work for Windows 2000 and XP >> clients. That would require more integration between >> Samba and Heimdal, and perhaps full ADS support. >> Hopefully Samba 4 will solve this. >> > Yep. Well, I fear Samba 4 will try to act as an LDAP + KDC to fulfill AD requirements, but without actually using the real LDAP and Kerberos servers as backends. >> - Some web applications want their own user database >> (notably Bugzilla, Mailman and MoinMoin); >> >> > A krb5 authing, LDAP using Bugzilla would be great. New versions of Bugzilla can use LDAP for authentication, but users must still be created in the MySQL database. (BTW, it doesn't even work automatically once LDAP is enabled). >> - I couldn't get password-less IMAP to work with >> courier-imap because of limited SASL support. >> >> > Dovecot supports krb5 IIRC. Last time I checked it, Dovecot was very simple and lacked many features I needed. I shall try it again, thanks! >> - NFSv4 with GSSAPI authentication. Many patches from >> CITI are still missing in the kernel and in userland. >> I found it extremely difficult to get reliable NFS >> operation with NFSv4 (but it was two months ago, the >> situation may have improved in the meantime); >> >> > Haven't played with this. Have you tried AFS? It's a neater protocol and > has a few large implementations (eg, CSFB) using it on Red Hat like > systems. I've played with Arla, but got scared by the apparent complexity of the server-side installation. A kernel-based server is also missing, which could make it too slow as an NFS replacement. These are, of course, just my assumpions. Reality may differ :-) >> - Integrated management tools. I've currently settled >> with a combination of phpLdapAdmin, ldapvi and >> smb-ldaptools, all of which arn't exactly as simple >> and quick as traditional UNIX tools (useradd, passwd, >> vipw...); >> > jXplorer from CA is Open Source, good, and may well build on a free java > stack. It's already on the FC5future area of the wiki. Thank you! Right now I can't get the installer to work with neither GCJ's VM and Sun's Java 1.5.1 for x86_64. I'll try harder because I badly needed a GUI replacement for phpLdapAdmin. Using web interfaces is always very slow and uncomfortable, even when they did every effort to make them more usable. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From bernie at develer.com Sat Jun 18 07:48:49 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Sat, 18 Jun 2005 09:48:49 +0200 Subject: Single sign-on infrastructure (FC5 wish) In-Reply-To: <1119078623.24842.26.camel@localhost.localdomain> References: <42B3B097.7060109@develer.com> <1119078623.24842.26.camel@localhost.localdomain> Message-ID: <42B3D1E1.6030501@develer.com> David Woodhouse wrote: > On Sat, 2005-06-18 at 07:26 +0200, Bernardo Innocenti wrote: > >> - I couldn't get password-less IMAP to work with >> courier-imap because of limited SASL support. >> Maybe I'd be more lucky with cyrus-imap, but it >> doesn't support Maildirs, so I can't switch; > > Passwordless IMAP works for me. Try invoking courier or dovecot over an > SSH login. Evolution and mutt at least can run 'ssh $server exec imapd' > instead of trying to make a TCP connection to the imap server and then > authenticating to it. Nice hack! I'm afraid neither Thunderbird and KMail can't do that. By the way, does Thunderbird even support anything besides password logins? I'd prefer not to force users to switch to another MUA, expecially on Windows clients. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From caillon at redhat.com Sat Jun 18 09:29:12 2005 From: caillon at redhat.com (Christopher Aillon) Date: Sat, 18 Jun 2005 05:29:12 -0400 Subject: Single sign-on infrastructure (FC5 wish) In-Reply-To: <42B3B097.7060109@develer.com> References: <42B3B097.7060109@develer.com> Message-ID: <42B3E968.2000106@redhat.com> On 06/18/2005 01:26 AM, Bernardo Innocenti wrote: > - hacked Firefox configuration on all clients to > enable negotiate-auth for https; Firefox already ships with this support. However, you must whitelist the sites you wish to authenticate with. See https://bugzilla.mozilla.org/show_bug.cgi?id=237586#c24 for the details and reasoning. From caillon at redhat.com Sat Jun 18 09:42:15 2005 From: caillon at redhat.com (Christopher Aillon) Date: Sat, 18 Jun 2005 05:42:15 -0400 Subject: Single sign-on infrastructure (FC5 wish) In-Reply-To: <42B3D0E0.5020700@develer.com> References: <42B3B097.7060109@develer.com> <42B3C5A8.7080309@cyber.com.au> <42B3D0E0.5020700@develer.com> Message-ID: <42B3EC77.10501@redhat.com> On 06/18/2005 03:44 AM, Bernardo Innocenti wrote: >>>- hacked Firefox configuration on all clients to >>> enable negotiate-auth for https; >>> >> >>Surprised firefox doesn't support kerberos through GSSAPI or similar as >>is. I thought the version in RHEL 4 did - there was a big Kerberos push >>for RHEL 4 - are you sure? > > > I didn't rebuild Firefox, I just hacked prefs.js to set: > > user_pref("network.negotiate-auth.delegation-uris", "http://, https://"); > user_pref("network.negotiate-auth.trusted-uris", "http://, https://"); > > IIRC, Mozilla shipped with FC3 doesn't support it. > Only Firefox does. But who's still using Mozilla anyway? Mozilla had this support far longer than Firefox did. They share the exact same code here really. Who's still using Mozilla? Anyone using Epiphany ;-) From felipe.alfaro at gmail.com Sat Jun 18 11:25:55 2005 From: felipe.alfaro at gmail.com (Felipe Alfaro Solana) Date: Sat, 18 Jun 2005 13:25:55 +0200 Subject: Single sign-on infrastructure (FC5 wish) In-Reply-To: <42B3D0E0.5020700@develer.com> References: <42B3B097.7060109@develer.com> <42B3C5A8.7080309@cyber.com.au> <42B3D0E0.5020700@develer.com> Message-ID: <6f6293f1050618042518ad1181@mail.gmail.com> > >> - I couldn't get password-less IMAP to work with > >> courier-imap because of limited SASL support. > >> > >> > > Dovecot supports krb5 IIRC. > > Last time I checked it, Dovecot was very simple > and lacked many features I needed. I shall try > it again, thanks! There's also Cyrus-IMAP which support GSSAPI auth and is pretty powerful. From seandarcy2 at gmail.com Sat Jun 18 20:37:16 2005 From: seandarcy2 at gmail.com (sean) Date: Sat, 18 Jun 2005 16:37:16 -0400 Subject: gcj-dbtool xerces scriptlet fails Message-ID: Cleanup : xerces-j2 ####################### [50/57] gcj-dbtool: Manipulate gcj map database files Usage: gcj-dbtool -n file.gcjdb [size] - Create a new gcj map database gcj-dbtool -a file.gcjdb file.jar file.so - Add the contents of file.jar to a gcj map database gcj-dbtool -f file.gcjdb file.jar file.so - Add the contents of file.jar to a gcj map database gcj-dbtool -t file.gcjdb - Test a gcj map database gcj-dbtool -l file.gcjdb - List a gcj map database gcj-dbtool [-][-0] -m dest.gcjdb [source.gcjdb]... - Merge gcj map databases into dest Replaces dest To add to dest, include dest in the list of sources If the first arg is -, read the list from stdin If the first arg is -0, filenames separated by nul gcj-dbtool -p [LIBDIR] - Print default database name error: %postun(xerces-j2-2.6.2-4jpp_7fc.x86_64) scriptlet failed, exit status 123 sean From i at stingr.net Sun Jun 19 09:33:04 2005 From: i at stingr.net (Paul P Komkoff Jr) Date: Sun, 19 Jun 2005 13:33:04 +0400 Subject: Any way to run UML kernel under FC4? Message-ID: <20050619093304.GB3302@stingr.stingr.net> Hi. Never thought I'll need that, but ... Is there any way to run UML kernels on an unmodified fedora system (with standard kernel rpms)? Or, if it isn't which patch/config option/whatever prevents from doing this? (I could do some search myself but maybe someone know what's the culprit). Thanks in advance. -- Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key This message represents the official view of the voices in my head From dwmw2 at infradead.org Sun Jun 19 10:26:22 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 19 Jun 2005 11:26:22 +0100 Subject: Single sign-on infrastructure (FC5 wish) In-Reply-To: <42B3D1E1.6030501@develer.com> References: <42B3B097.7060109@develer.com> <1119078623.24842.26.camel@localhost.localdomain> <42B3D1E1.6030501@develer.com> Message-ID: <1119176784.24842.70.camel@localhost.localdomain> On Sat, 2005-06-18 at 09:48 +0200, Bernardo Innocenti wrote: > Nice hack! I'm afraid neither Thunderbird and KMail > can't do that. It shouldn't be hard to fix them. You just create a socketpair and spawn SSH instead of connecting with TCP directly. -- dwmw2 From ivazquez at ivazquez.net Sun Jun 19 11:12:19 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sun, 19 Jun 2005 07:12:19 -0400 Subject: Any way to run UML kernel under FC4? In-Reply-To: <20050619093304.GB3302@stingr.stingr.net> References: <20050619093304.GB3302@stingr.stingr.net> Message-ID: <1119179539.11934.8.camel@ignacio.ignacio.lan> On Sun, 2005-06-19 at 13:33 +0400, Paul P Komkoff Jr wrote: > Never thought I'll need that, but ... Is there any way to run UML > kernels on an unmodified fedora system (with standard kernel rpms)? Why would you want to when you can run Xen? http://www.fedoraproject.org/wiki/FedoraXenQuickstart -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 Sun Jun 19 15:35:07 2005 From: ndbecker2 at gmail.com (Neal Becker) Date: Sun, 19 Jun 2005 11:35:07 -0400 Subject: Build 2.6.12 on FC4? Message-ID: My wireless worked on FC3, but stopped working on FC4. I want to try a stock 2.6.12 kernel. It doesn't compile the current FC4 gcc. I grabbed the patch linux-2.6.11-compile-fixes.patch, and it compiles. But after make, make modules; make modules_install; make install; it doesn't boot. Just says can't open console (/dev/console IIRC). Any hints? Oh, this is x86_64. From arjanv at redhat.com Sun Jun 19 15:42:36 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Sun, 19 Jun 2005 11:42:36 -0400 Subject: Build 2.6.12 on FC4? In-Reply-To: References: Message-ID: <1119195756.5827.19.camel@localhost.localdomain> On Sun, 2005-06-19 at 11:35 -0400, Neal Becker wrote: > My wireless worked on FC3, but stopped working on FC4. I want to try a > stock 2.6.12 kernel. It doesn't compile the current FC4 gcc. I grabbed > the patch linux-2.6.11-compile-fixes.patch, and it compiles. But after > make, make modules; make modules_install; make install; it doesn't boot. > Just says can't open console (/dev/console IIRC). I suspect you forgot to make an initrd... from the kernel source tree it's easiest to just use "make install", that will make an initrd for you as well as adding the kernel to grub etc etc -------------- 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 Sun Jun 19 15:36:52 2005 From: ndbecker2 at gmail.com (Neal Becker) Date: Sun, 19 Jun 2005 11:36:52 -0400 Subject: Build 2.6.12 on FC4? References: Message-ID: Neal Becker wrote: > My wireless worked on FC3, but stopped working on FC4. I want to try a > stock 2.6.12 kernel. It doesn't compile the current FC4 gcc. I grabbed > the patch linux-2.6.11-compile-fixes.patch, and it compiles. But after > make, make modules; make modules_install; make install; it doesn't boot. > Just says can't open console (/dev/console IIRC). > > Any hints? > > Oh, this is x86_64. > > Oh, should have mentioned, I copied my current .config and did make oldconfig. From enrico.scholz at informatik.tu-chemnitz.de Sun Jun 19 16:16:52 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sun, 19 Jun 2005 18:16:52 +0200 Subject: Build 2.6.12 on FC4? In-Reply-To: (Neal Becker's message of "Sun, 19 Jun 2005 11:35:07 -0400") References: Message-ID: <87oea25nkb.fsf@kosh.bigo.ensc.de> ndbecker2 at gmail.com (Neal Becker) writes: > My wireless worked on FC3, but stopped working on FC4. I want to try > a stock 2.6.12 kernel. It doesn't compile the current FC4 gcc. I > grabbed the patch linux-2.6.11-compile-fixes.patch, and it compiles. > But after make, make modules; make modules_install; make install; it > doesn't boot. Just says can't open console (/dev/console IIRC). Without initrd, /dev/console and other entries will be missing. This can be fixed by | mount --bind / /mnt | /sbin/MAKEDEV -x -d /mnt/dev console zero random urandom null tty tty{0,1,2,3,4,5,6,7,8,9} | umount /mnt Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From mbneto at gmail.com Sun Jun 19 17:06:40 2005 From: mbneto at gmail.com (mbneto) Date: Sun, 19 Jun 2005 13:06:40 -0400 Subject: Grub problem after FC4 (xfs) install ? Message-ID: <5cf776b805061910065a3aca12@mail.gmail.com> Hi, I was wondering if anyone has a solution for a problem where after installing fc4 (with xfs partition) grub fails to install. In my case since it is a dual boot machine it simply enters directly in the "primary" OS. From Fedora at TQMcube.com Sun Jun 19 18:21:37 2005 From: Fedora at TQMcube.com (David Cary Hart) Date: Sun, 19 Jun 2005 14:21:37 -0400 Subject: Build 2.6.12 on FC4? In-Reply-To: References: Message-ID: <1119205297.3245.2.camel@dch.TQMcube.com> On Sun, 2005-06-19 at 11:35 -0400, Neal Becker wrote: > My wireless worked on FC3, but stopped working on FC4. I want to try a > stock 2.6.12 kernel. It doesn't compile the current FC4 gcc. I grabbed > the patch linux-2.6.11-compile-fixes.patch, and it compiles. But after > make, make modules; make modules_install; make install; it doesn't boot. > Just says can't open console (/dev/console IIRC). > Compiles just fine and works for me without patches (p4). I get a bunch of "signedness" warnings. The only problem is that you cannot backspace in make menuconfig. -- * Eliminate Spam: http://www.TQMcube.com/spam_trap.htm * RBLDNSD HowTo: http://www.TQMcube.com/rbldnsd.htm * Multi-RBL Check: http://www.TQMcube.com/rblcheck.htm From jerone at gmail.com Sun Jun 19 20:34:02 2005 From: jerone at gmail.com (Jerone Young) Date: Sun, 19 Jun 2005 15:34:02 -0500 Subject: Grub problem after FC4 (xfs) install ? In-Reply-To: <5cf776b805061910065a3aca12@mail.gmail.com> References: <5cf776b805061910065a3aca12@mail.gmail.com> Message-ID: <9f50a7a0050619133465f61d7e@mail.gmail.com> I could be wrong but I don't think grub works with xfs. What I would do if no one comes with an answer is to just make a 100mb "/boot" partion that is ext3. On 6/19/05, mbneto wrote: > Hi, > > I was wondering if anyone has a solution for a problem where after > installing fc4 (with xfs partition) grub fails to install. > > In my case since it is a dual boot machine it simply enters directly > in the "primary" OS. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From buildsys at redhat.com Sun Jun 19 21:39:15 2005 From: buildsys at redhat.com (Build System) Date: Sun, 19 Jun 2005 17:39:15 -0400 Subject: rawhide report: 20050619 changes Message-ID: <200506192139.j5JLdFov032075@porkchop.devel.redhat.com> Updated Packages: selinux-policy-strict-1.23.18-14 -------------------------------- * Sat Jun 18 2005 Dan Walsh 1.23.18-14 - Add Russell's patch for net_contexts selinux-policy-targeted-1.23.18-14 ---------------------------------- * Sat Jun 18 2005 Dan Walsh 1.23.18-14 - Add Russell's patch for net_contexts From webmaster at margo.bijoux.nom.br Sun Jun 19 23:35:33 2005 From: webmaster at margo.bijoux.nom.br (Pedro Fernandes Macedo) Date: Sun, 19 Jun 2005 20:35:33 -0300 Subject: Grub problem after FC4 (xfs) install ? In-Reply-To: <5cf776b805061910065a3aca12@mail.gmail.com> References: <5cf776b805061910065a3aca12@mail.gmail.com> Message-ID: <42B60145.2030805@margo.bijoux.nom.br> mbneto wrote: >Hi, > >I was wondering if anyone has a solution for a problem where after >installing fc4 (with xfs partition) grub fails to install. > >In my case since it is a dual boot machine it simply enters directly >in the "primary" OS. > > First , this isnt the right list. You should had posted this to fedora-list. Second , I gave up and installed FC4 using a ext3 /boot partition and using XFS only on / and /home . I also had to remove the LABEL=/ options from fstab and grub, since it looks like the / partition doesnt have a label ( /home works perfectly , but it was created during FC3 install). -- Pedro Macedo From ellson at research.att.com Mon Jun 20 01:28:39 2005 From: ellson at research.att.com (John Ellson) Date: Sun, 19 Jun 2005 21:28:39 -0400 Subject: rawhide report: 20050619 changes In-Reply-To: <200506192139.j5JLdFov032075@porkchop.devel.redhat.com> References: <200506192139.j5JLdFov032075@porkchop.devel.redhat.com> Message-ID: <42B61BC7.8090205@research.att.com> Build System wrote: > > > >Updated Packages: > >selinux-policy-strict-1.23.18-14 >-------------------------------- >* Sat Jun 18 2005 Dan Walsh 1.23.18-14 >- Add Russell's patch for net_contexts > >selinux-policy-targeted-1.23.18-14 >---------------------------------- >* Sat Jun 18 2005 Dan Walsh 1.23.18-14 >- Add Russell's patch for net_contexts > > > Seems smple enough, but why did all the remaining i386.rpm get added to the x86_64/Fedora/RPMS directory today? John From gbenson at redhat.com Mon Jun 20 08:21:18 2005 From: gbenson at redhat.com (Gary Benson) Date: Mon, 20 Jun 2005 09:21:18 +0100 Subject: rawhide report: 20050617 changes In-Reply-To: <20050617202935.GB25848@redhat.com> References: <200506171135.j5HBZILw030776@porkchop.devel.redhat.com> <1119037832.3377.17.camel@localhost> <20050617202935.GB25848@redhat.com> Message-ID: <20050620082117.GA7793@redhat.com> Andrew Overholt wrote: > * Ziga Mahkovec [2005-06-17 15:51]: > > On Fri, 2005-06-17 at 07:35 -0400, Build System wrote: > > > [...] > > > > > > New package gnu.regexp > > > Java NFA regular expression engine implementation > > > > I was wondering why gnu.regexp was included, given that it's > > already part of libgcj? > > I'm not sure. Gary? Er, one of the jonas packages required it, so I added it. I'll see if it can be removed. It might be that we have to cause java-gcj-compat to Provides: gnu.regexp to make it seamless. We also ship gnu.getopt; is that removable too, do you know? Please Cc me in replies -- I don't read this list... Cheers, Gary From d.lesca at solinos.it Mon Jun 20 09:14:30 2005 From: d.lesca at solinos.it (Dario Lesca) Date: Mon, 20 Jun 2005 11:14:30 +0200 Subject: Grub problem after FC4 (xfs) install ? In-Reply-To: <9f50a7a0050619133465f61d7e@mail.gmail.com> References: <5cf776b805061910065a3aca12@mail.gmail.com> <9f50a7a0050619133465f61d7e@mail.gmail.com> Message-ID: <1119258870.5289.321.camel@localhost.localdomain> Il giorno dom, 19-06-2005 alle 15:34 -0500, Jerone Young ha scritto: > I could be wrong but I don't think grub works with xfs. On fc1,fc2,fc3 grub with xfs always work. After install, when the "install boot loader" loops :-(, switch on C+A +F2, killall grub, chroot /mnt/sysimages, and grub-install /dev/hdX. On fc4 grub some time not work. The previous procedure crash when do grub-install, when the grub read the stage1 files. I have solved (without reinstall all) replace /boot filesystem whit ext3 and rerun grub-install. Someone is interested to get more details? I known that xfs it is not 100% supported ... but it is a great fs! Many thanks -- Dario Lesca From harald at redhat.com Mon Jun 20 08:18:07 2005 From: harald at redhat.com (Harald Hoyer) Date: Mon, 20 Jun 2005 10:18:07 +0200 Subject: YourUpsteamsVeryImportantPackage In-Reply-To: <42B39003.2050503@cyber.com.au> References: <42B15F7F.90803@redhat.com> <42B2E569.3030100@redhat.com> <42B39003.2050503@cyber.com.au> Message-ID: <42B67BBF.9000203@redhat.com> Mike MacCana wrote: > Thanks very much for your work Harald, I'm looking forward to using it. > > Harald Hoyer wrote: > >> See: http://people.redhat.com/harald/ServiceManager/ > > > Please, please, lowercase. 99% of all other packages, and 99% of all > other services are lowercase. > > NetworkManager and HelixPlayer and > MyPackageWhichIsAlsoVeryImportantAndThereforeNeedsToBreakConventionUnnecessarily > are a hassle. > > Since FC packages what the upstream does, and you're the upstream on > this one, could it be lowercase? > > Mike > :-) Don't worry. This is not the final name. It's only the py-filename. It will be reimplemented in C, if the interface is clear and the approach is useful, and maybe called /sbin/rc :) From dhollis at davehollis.com Mon Jun 20 13:54:41 2005 From: dhollis at davehollis.com (David Hollis) Date: Mon, 20 Jun 2005 09:54:41 -0400 Subject: YourUpsteamsVeryImportantPackage In-Reply-To: <42B67BBF.9000203@redhat.com> References: <42B15F7F.90803@redhat.com> <42B2E569.3030100@redhat.com> <42B39003.2050503@cyber.com.au> <42B67BBF.9000203@redhat.com> Message-ID: <1119275681.19570.13.camel@dhollis-lnx.sunera.com> On Mon, 2005-06-20 at 10:18 +0200, Harald Hoyer wrote: > Mike MacCana wrote: > > Thanks very much for your work Harald, I'm looking forward to using it. > > > > Harald Hoyer wrote: > > > >> See: http://people.redhat.com/harald/ServiceManager/ > > > > > > Please, please, lowercase. 99% of all other packages, and 99% of all > > other services are lowercase. > > > > NetworkManager and HelixPlayer and > > MyPackageWhichIsAlsoVeryImportantAndThereforeNeedsToBreakConventionUnnecessarily > > are a hassle. > > > > Since FC packages what the upstream does, and you're the upstream on > > this one, could it be lowercase? > > > > Mike > > > > :-) Don't worry. This is not the final name. It's only the py-filename. > It will be reimplemented in C, if the interface is clear and the > approach is useful, and maybe called /sbin/rc :) Let's just hope that the RPM isn't called "/sbin/rc-1.0A-Gold.i386.rpm"! -- David Hollis -------------- 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 janina at rednote.net Mon Jun 20 14:12:05 2005 From: janina at rednote.net (Janina Sajka) Date: Mon, 20 Jun 2005 10:12:05 -0400 Subject: Yum Not Excluding Message-ID: <20050620141205.GA5848@rednote.net> This morning I noticed my yum updates weren't taking because of two obscure (to me) packages' missing dependencies. I tried to issue --exclude=wl-xemacs --exclude=gda-postgres but this had no effect. I had to rpm -e these two packages to get my 700Mb update rolling on my x86_64 box. From skvidal at phy.duke.edu Mon Jun 20 14:18:52 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 20 Jun 2005 10:18:52 -0400 Subject: Yum Not Excluding In-Reply-To: <20050620141205.GA5848@rednote.net> References: <20050620141205.GA5848@rednote.net> Message-ID: <1119277132.7160.187.camel@cutter> On Mon, 2005-06-20 at 10:12 -0400, Janina Sajka wrote: > This morning I noticed my yum updates weren't taking because of two > obscure (to me) packages' missing dependencies. I tried to issue > --exclude=wl-xemacs --exclude=gda-postgres but this had no effect. I had > to rpm -e these two packages to get my 700Mb update rolling on my x86_64 > box. yum's --exclude doesn't work on packages in your local rpmdb. Do you still have the actual error messages you were seeing? -sv From ziga.mahkovec at klika.si Mon Jun 20 14:21:35 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Mon, 20 Jun 2005 16:21:35 +0200 Subject: rawhide report: 20050617 changes In-Reply-To: <20050620082117.GA7793@redhat.com> References: <200506171135.j5HBZILw030776@porkchop.devel.redhat.com> <1119037832.3377.17.camel@localhost> <20050617202935.GB25848@redhat.com> <20050620082117.GA7793@redhat.com> Message-ID: <1119277296.6226.25.camel@localhost> On Mon, 2005-06-20 at 09:21 +0100, Gary Benson wrote: > Andrew Overholt wrote: > > * Ziga Mahkovec [2005-06-17 15:51]: > > > I was wondering why gnu.regexp was included, given that it's > > > already part of libgcj? > > > > I'm not sure. Gary? > > Er, one of the jonas packages required it, so I added it. I'll see if > it can be removed. It might be that we have to cause java-gcj-compat > to Provides: gnu.regexp to make it seamless. I see; this was just a heads-up -- having two slightly different versions of the same library in classpath could cause trouble. On the other hand, there are some discussions about replacing gnu.regexp with jregex in GNU Classpath (for performance reasons), so it's possible you'd have to add it back in later :/ > We also ship gnu.getopt; is that removable too, do you know? It's not part of Classpath/libgcj. And a quick scan with repoquery suggests no other package provides it. -- Ziga From jspaleta at gmail.com Mon Jun 20 14:25:06 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 20 Jun 2005 10:25:06 -0400 Subject: Yum Not Excluding In-Reply-To: <20050620141205.GA5848@rednote.net> References: <20050620141205.GA5848@rednote.net> Message-ID: <604aa79105062007255c3d3677@mail.gmail.com> On 6/20/05, Janina Sajka wrote: > This morning I noticed my yum updates weren't taking because of two > obscure (to me) packages' missing dependencies. I tried to issue > --exclude=wl-xemacs --exclude=gda-postgres but this had no effect. I had > to rpm -e these two packages to get my 700Mb update rolling on my x86_64 > box. yum is excluding for me as expected. Perhaps you were misinterpreting the yum output. Perhaps in the case of gda-postgres the problem was with a pending update of the postgresql-libs package providing libpq.so.4 and no longer providing the libpq.so.3 library that your installed version of gda-postgres required. In a case like that.. excluding gda-postgres doesn't do anything useful because its not gda-postgres that is trying to be updated. -jef From gbenson at redhat.com Mon Jun 20 14:33:40 2005 From: gbenson at redhat.com (Gary Benson) Date: Mon, 20 Jun 2005 15:33:40 +0100 Subject: rawhide report: 20050617 changes In-Reply-To: <1119277296.6226.25.camel@localhost> References: <200506171135.j5HBZILw030776@porkchop.devel.redhat.com> <20050617202935.GB25848@redhat.com> <20050620082117.GA7793@redhat.com> <1119277296.6226.25.camel@localhost> Message-ID: <20050620143339.GF7793@redhat.com> Ziga Mahkovec wrote: > On Mon, 2005-06-20 at 09:21 +0100, Gary Benson wrote: > > Andrew Overholt wrote: > > > * Ziga Mahkovec [2005-06-17 15:51]: > > > > I was wondering why gnu.regexp was included, given that it's > > > > already part of libgcj? > > > > > > I'm not sure. Gary? > > > > Er, one of the jonas packages required it, so I added it. I'll see > > if it can be removed. It might be that we have to cause > > java-gcj-compat to Provides: gnu.regexp to make it seamless. > > I see; this was just a heads-up -- having two slightly different > versions of the same library in classpath could cause trouble. As far as I'm concerned having two separate versions of the same package is something to avoid at all costs. Thank you for spotting it and for letting me know. Cheers, Gary From janina at rednote.net Mon Jun 20 14:37:45 2005 From: janina at rednote.net (Janina Sajka) Date: Mon, 20 Jun 2005 10:37:45 -0400 Subject: Yum Not Excluding In-Reply-To: <1119277132.7160.187.camel@cutter> References: <20050620141205.GA5848@rednote.net> <1119277132.7160.187.camel@cutter> Message-ID: <20050620143745.GC5848@rednote.net> seth vidal writes: > On Mon, 2005-06-20 at 10:12 -0400, Janina Sajka wrote: > > This morning I noticed my yum updates weren't taking because of two > > obscure (to me) packages' missing dependencies. I tried to issue > > --exclude=wl-xemacs --exclude=gda-postgres but this had no effect. I had > > to rpm -e these two packages to get my 700Mb update rolling on my x86_64 > > box. > > yum's --exclude doesn't work on packages in your local rpmdb. > Sorry. Silly me wasn't thinking thoroughly and didn't clipboard them. Will try to reproduce when the update finishes. > Do you still have the actual error messages you were seeing? > > -sv > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Chair, Accessibility Workgroup Free Standards Group (FSG) janina at freestandards.org http://a11y.org Janina Sajka Phone: +1.202.494.7040 Partner, Capital Accessibility LLC http://www.CapitalAccessibility.Com Bringing the Owasys 22C screenless cell phone to the U.S. and Canada. Go to http://www.ScreenlessPhone.Com to learn more. From janina at rednote.net Mon Jun 20 14:43:56 2005 From: janina at rednote.net (Janina Sajka) Date: Mon, 20 Jun 2005 10:43:56 -0400 Subject: Yum Not Excluding In-Reply-To: <604aa79105062007255c3d3677@mail.gmail.com> References: <20050620141205.GA5848@rednote.net> <604aa79105062007255c3d3677@mail.gmail.com> Message-ID: <20050620144356.GD5848@rednote.net> Jeff Spaleta writes: > On 6/20/05, Janina Sajka wrote: > > This morning I noticed my yum updates weren't taking because of two > > obscure (to me) packages' missing dependencies. I tried to issue > > --exclude=wl-xemacs --exclude=gda-postgres but this had no effect. I had > > to rpm -e these two packages to get my 700Mb update rolling on my x86_64 > > box. > > > yum is excluding for me as expected. Perhaps you were misinterpreting > the yum output. > Perhaps in the case of gda-postgres the problem was with a pending update > of the postgresql-libs package providing libpq.so.4 and no longer > providing the libpq.so.3 library that your installed version of > gda-postgres required. In a case like that.. excluding gda-postgres > doesn't do anything useful because its not gda-postgres that is trying > to be updated. > This looks like what I saw. It is indeed possible I transposed in my mind. I've been known to do that. > -jef > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Chair, Accessibility Workgroup Free Standards Group (FSG) janina at freestandards.org http://a11y.org Janina Sajka Phone: +1.202.494.7040 Partner, Capital Accessibility LLC http://www.CapitalAccessibility.Com Bringing the Owasys 22C screenless cell phone to the U.S. and Canada. Go to http://www.ScreenlessPhone.Com to learn more. From fitzsim at redhat.com Mon Jun 20 15:39:52 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Mon, 20 Jun 2005 11:39:52 -0400 Subject: rawhide report: 20050617 changes In-Reply-To: <1119277296.6226.25.camel@localhost> References: <200506171135.j5HBZILw030776@porkchop.devel.redhat.com> <1119037832.3377.17.camel@localhost> <20050617202935.GB25848@redhat.com> <20050620082117.GA7793@redhat.com> <1119277296.6226.25.camel@localhost> Message-ID: <1119281992.26628.55.camel@tortoise.toronto.redhat.com> On Mon, 2005-06-20 at 16:21 +0200, Ziga Mahkovec wrote: > On Mon, 2005-06-20 at 09:21 +0100, Gary Benson wrote: > > Andrew Overholt wrote: > > > * Ziga Mahkovec [2005-06-17 15:51]: > > > > I was wondering why gnu.regexp was included, given that it's > > > > already part of libgcj? > > > > > > I'm not sure. Gary? > > > > Er, one of the jonas packages required it, so I added it. I'll see if > > it can be removed. It might be that we have to cause java-gcj-compat > > to Provides: gnu.regexp to make it seamless. > > I see; this was just a heads-up -- having two slightly different > versions of the same library in classpath could cause trouble. > > On the other hand, there are some discussions about replacing gnu.regexp > with jregex in GNU Classpath (for performance reasons), so it's possible > you'd have to add it back in later :/ > > > We also ship gnu.getopt; is that removable too, do you know? I would like to see gnu.getopt merged into GNU Classpath. Tom > > It's not part of Classpath/libgcj. And a quick scan with repoquery > suggests no other package provides it. > > -- > Ziga > From bernd.bartmann at gmail.com Mon Jun 20 17:02:45 2005 From: bernd.bartmann at gmail.com (Bernd Bartmann) Date: Mon, 20 Jun 2005 19:02:45 +0200 Subject: Yet again: several missing update announcements Message-ID: <6c18a4f050620100273fbb9ee@mail.gmail.com> Hi, yet again several updates have appeared for FC3/4 on the download mirrors, but some of them were never announced on fedora-announce-list. Even more confusing is that "Fedora Weekly News Issue #1" lists some of the missing announcements but not all. As FC4 is out now I've also created a bugzilla tracking bug for the missing announcements. So here is the list of what's currently missing: FC4: #161106 pilot-link-0.12.0-0.pre3.0.fc4.1, released 2005-06-17, #161118 NetworkManager-0.4-18.FC4, released 2005-06-17, #161117 jpilot-0.99.8-0.pre9.fc4.1, released 2005-06-16, #161115 xorg-x11-6.8.2-37, released 2005-06-14, #161114 gamin-0.1.1-1.FC4, released 2005-06-14, #161113 gedit-2.10.2-4, released 2005-06-13, #161111 FC3: #141256 gzip-1.3.3-14.fc3, released 2005-06-17, #161110 ncpfs-2.2.4-4.FC3.1, released 2005-06-17, #161109 bzip2-1.0.2-13.FC3.1, released 2005-06-16, #161108 gamin-0.1.1-1.FC3, released 2005-06-14, #161107 gedit-2.8.1-2.fc3.1, released 2005-06-08, #160140 bzip2-1.0.2-13.FC3, released 2005-05-19, #158470 devhelp-0.9.2-2.3.4, released 2005-05-17, #158320 epiphany-1.4.4-4.3.4, released 2005-05-17, #158319 devhelp-0.9.2-2.3.3, released 2005-05-17, #158317 epiphany-1.4.4-4.3.3, released 2005-05-17, #158315 firefox-1.0.4-1.3.1, released 2005-05-17, #158314 mozilla-1.7.8-1.3.1, released 2005-05-17, #158313 thunderbird-1.0.2-1.3.3, released 2005-05-17, #158311 logwatch-5.2.2-1.FC3.1, released 2005-04-26, #156367 devhelp-0.9.2-2.3.2, released 2005-04-22, #156017 epiphany-1.4.4-4.3.2, released 2005-04-22, #156016 mozilla-1.7.7-1.3.1, released 2005-04-22, #156015 logwatch-5.2.2-1.FC3, released 2005-04-21, #156014 firefox-1.0.3-1.3.1, released 2005-04-19, #156013 postfix-2.1.5-5, released 2005-03-17, #151588 nfs-utils-1.0.6-52, released 2005-02-19, #149901 Can we please get this problem fixed once and for all if not for the older FC released but at least starting with FC4? Best regards, Bernd. From notting at redhat.com Mon Jun 20 19:36:39 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 20 Jun 2005 15:36:39 -0400 Subject: rawhide report: 20050619 changes In-Reply-To: <42B61BC7.8090205@research.att.com> References: <200506192139.j5JLdFov032075@porkchop.devel.redhat.com> <42B61BC7.8090205@research.att.com> Message-ID: <20050620193639.GB20427@nostromo.devel.redhat.com> John Ellson (ellson at research.att.com) said: > Seems smple enough, but why did all the remaining i386.rpm get added to > the x86_64/Fedora/RPMS directory today? Bug in anaconda that caused all sorts of fun with the tree build. Will be fixed tomorrow-if-not-earlier. Bill From mpaesold at gmx.at Mon Jun 20 20:36:20 2005 From: mpaesold at gmx.at (Michael Paesold) Date: Mon, 20 Jun 2005 22:36:20 +0200 Subject: Bug: xm restore in unstable/FC4 Message-ID: <012001c575d7$b7f71950$0f01a8c0@zaphod> I have tried to do save/restore on FC 4. xm save now works (in the latest development version, where the migrate/ directory is correctly created by the RPM). xm restore does not work, it fails in xc_linux_restore calling xm_domain_create. Error message in xfrd log is "Could not create domain. pfns=65536, 262144KB". Debugging xfrd with gdb gave further information: Inside xm_domain_create no error occurs at all. The result from the do_dom_mem_op(xc_handle, MEMOP_increase_reservation,...) call is the expected value of 65536 (mem_kb/4). This is stored into the variable err, which is then returned. Back in xc_linux_restore, the code now thinks that a result different then 0 is an error, when in fact -1 would indicate an error: This seems to be wrong: /* Create domain on CPU -1 so that it may auto load-balance in future. */ if ( xc_domain_create(xc_handle, nr_pfns * (PAGE_SIZE / 1024), -1, 1, &dom) ) { xcio_error(ioctxt, "Could not create domain. pfns=%d, %dKB", nr_pfns,nr_pfns * (PAGE_SIZE / 1024)); goto out; } This should be probably be changed to xc_domain_create(..) == -1 as condition for an error. Well, I have just looked into the sources in the BitKeeper repository and saw that this code has already changed substantially for some weeks now. Now I don't really understand, what the FC4 package is really built from. It says xen-2-20050530 -- xen 2 -- but booting xen says 3.0 devel. Rik, could you clear this up for me, please? Thanks. Best Regards, Michael Paesold From mpaesold at gmx.at Mon Jun 20 20:45:27 2005 From: mpaesold at gmx.at (Michael Paesold) Date: Mon, 20 Jun 2005 22:45:27 +0200 Subject: xm restore in unstable/FC4 References: <012001c575d7$b7f71950$0f01a8c0@zaphod> Message-ID: <015a01c575d8$ff3f6e60$0f01a8c0@zaphod> Regarding xen I wrote: > This should be probably be changed to xc_domain_create(..) == -1 as > condition for an error. > > Well, I have just looked into the sources in the BitKeeper repository and > saw that this code has already changed substantially for some weeks now. > Now > I don't really understand, what the FC4 package is really built from. > > It says xen-2-20050530 -- xen 2 -- but booting xen says 3.0 devel. > Rik, could you clear this up for me, please? Thanks. Perhaps I should look first and write later. :-) "rpm -q --changelog xen" does give the answer, indeed. The last pull from upstream seems to have happened 20050424, so this predates the code drift (and corrections of this bug). Rik, could you either fix this error with a patch for the rpms in -development or pull in a new snapshot from upstream? Best Regards, Michael Paesold From lmacken at redhat.com Mon Jun 20 20:59:11 2005 From: lmacken at redhat.com (Luke Macken) Date: Mon, 20 Jun 2005 16:59:11 -0400 Subject: Yet again: several missing update announcements In-Reply-To: <6c18a4f050620100273fbb9ee@mail.gmail.com> References: <6c18a4f050620100273fbb9ee@mail.gmail.com> Message-ID: <1119301152.20104.27.camel@dhcp83-32.boston.redhat.com> On Mon, 2005-06-20 at 19:02 +0200, Bernd Bartmann wrote: > Hi, > > yet again several updates have appeared for FC3/4 on the download > mirrors, but some of them were never announced on > fedora-announce-list. Even more confusing is that "Fedora Weekly News > Issue #1" lists some of the missing announcements but not all. As FC4 > is out now I've also created a bugzilla tracking bug for the missing > announcements. So here is the list of what's currently missing: > > FC4: #161106 > pilot-link-0.12.0-0.pre3.0.fc4.1, released 2005-06-17, #161118 > NetworkManager-0.4-18.FC4, released 2005-06-17, #161117 > jpilot-0.99.8-0.pre9.fc4.1, released 2005-06-16, #161115 > xorg-x11-6.8.2-37, released 2005-06-14, #161114 > gamin-0.1.1-1.FC4, released 2005-06-14, #161113 > gedit-2.10.2-4, released 2005-06-13, #161111 > > FC3: #141256 > gzip-1.3.3-14.fc3, released 2005-06-17, #161110 > ncpfs-2.2.4-4.FC3.1, released 2005-06-17, #161109 > bzip2-1.0.2-13.FC3.1, released 2005-06-16, #161108 > gamin-0.1.1-1.FC3, released 2005-06-14, #161107 > gedit-2.8.1-2.fc3.1, released 2005-06-08, #160140 > bzip2-1.0.2-13.FC3, released 2005-05-19, #158470 > devhelp-0.9.2-2.3.4, released 2005-05-17, #158320 > epiphany-1.4.4-4.3.4, released 2005-05-17, #158319 > devhelp-0.9.2-2.3.3, released 2005-05-17, #158317 > epiphany-1.4.4-4.3.3, released 2005-05-17, #158315 > firefox-1.0.4-1.3.1, released 2005-05-17, #158314 > mozilla-1.7.8-1.3.1, released 2005-05-17, #158313 > thunderbird-1.0.2-1.3.3, released 2005-05-17, #158311 > logwatch-5.2.2-1.FC3.1, released 2005-04-26, #156367 > devhelp-0.9.2-2.3.2, released 2005-04-22, #156017 > epiphany-1.4.4-4.3.2, released 2005-04-22, #156016 > mozilla-1.7.7-1.3.1, released 2005-04-22, #156015 > logwatch-5.2.2-1.FC3, released 2005-04-21, #156014 > firefox-1.0.3-1.3.1, released 2005-04-19, #156013 > postfix-2.1.5-5, released 2005-03-17, #151588 > nfs-utils-1.0.6-52, released 2005-02-19, #149901 > > Can we please get this problem fixed once and for all if not for the > older FC released but at least starting with FC4? > > Best regards, > Bernd. Bernd, Thanks for taking the time to wrangle these issues and bring them to our attention. The root of this problem lies in our current update system, which leaves lots of room for error. I'm currently working on the re-design of this system which should be in place shortly. Upon completion, the system will help us automate the majority of these tedious tasks, hopefully preventing issues like these from reoccurring. luke From veillard at redhat.com Mon Jun 20 21:18:01 2005 From: veillard at redhat.com (Daniel Veillard) Date: Mon, 20 Jun 2005 17:18:01 -0400 Subject: Yet again: several missing update announcements In-Reply-To: <6c18a4f050620100273fbb9ee@mail.gmail.com> References: <6c18a4f050620100273fbb9ee@mail.gmail.com> Message-ID: <20050620211801.GP11753@redhat.com> On Mon, Jun 20, 2005 at 07:02:45PM +0200, Bernd Bartmann wrote: > Hi, > > yet again several updates have appeared for FC3/4 on the download > mirrors, but some of them were never announced on > fedora-announce-list. Even more confusing is that "Fedora Weekly News > Issue #1" lists some of the missing announcements but not all. As FC4 > is out now I've also created a bugzilla tracking bug for the missing > announcements. So here is the list of what's currently missing: > gamin-0.1.1-1.FC4, released 2005-06-14, #161113 [...] > Can we please get this problem fixed once and for all if not for the > older FC released but at least starting with FC4? Currently as a maintainer, pushing a fedora update I need step 1/ to build the update in the appropriate channel step 2/ label it with an unique number step 3/ ask and wait for it to be pushed step 4/ once pushed use a very unconvenient script to generate the boilerplate for the announcement step 5/ mail the announcement 1/ 2/ and 3/ are under my control, I do them in batch, then there is an asynchronous mechanism, and then after "some" time I need to do the messy 4/ and 5/ steps. Concusion: Being a lazy computer guy (remember it's a virtue) once 3/ is done I tend to think I have done my part, the bits are out, and I don't feel compelled at all to go to 4/ and 5/ Moreover, getting bug reports about missing announcement just generate frustration, I don't like pushing updates as a result, and if you were among the ones who waited 3 months for a gamin official update on FC3 between 0.0.25 and 0.1.1 you know why now, I just hate pushing updates but the srpms are available on my home page. Now if you want the reason why gamin-0.1.1 was pushed: - on FC3 it fixes the zillion bugs present and found in 0.0.25 - on FC4 it fixes the desktop update on dynamically mounted USB media Writing this mail is way less painful than sending the real announcements. If I hadn't the Damocles sword of those missing update bug reports, I would probably push bug fixes faster. Whether I must be whipped for being lazy, or the tool for pushing announcement need to be changed or missing announcement should not be considered bugs, there is a choice, the current situation does not seems pleasant to you, it's not really for me either. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard at redhat.com Mon Jun 20 21:38:08 2005 From: veillard at redhat.com (Daniel Veillard) Date: Mon, 20 Jun 2005 17:38:08 -0400 Subject: Yet again: several missing update announcements In-Reply-To: <1119301152.20104.27.camel@dhcp83-32.boston.redhat.com> References: <6c18a4f050620100273fbb9ee@mail.gmail.com> <1119301152.20104.27.camel@dhcp83-32.boston.redhat.com> Message-ID: <20050620213808.GR11753@redhat.com> On Mon, Jun 20, 2005 at 04:59:11PM -0400, Luke Macken wrote: > On Mon, 2005-06-20 at 19:02 +0200, Bernd Bartmann wrote: > Thanks for taking the time to wrangle these issues and bring them to our > attention. The root of this problem lies in our current update system, > which leaves lots of room for error. I'm currently working on the > re-design of this system which should be in place shortly. Upon > completion, the system will help us automate the majority of these > tedious tasks, hopefully preventing issues like these from reoccurring. > Thanks in advance ! Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From buildsys at redhat.com Mon Jun 20 22:54:11 2005 From: buildsys at redhat.com (Build System) Date: Mon, 20 Jun 2005 18:54:11 -0400 Subject: rawhide report: 20050620 changes Message-ID: <200506202254.j5KMsB6N024356@porkchop.devel.redhat.com> Updated Packages: (none) From jdesbonnet at gmail.com Tue Jun 21 02:23:08 2005 From: jdesbonnet at gmail.com (Joe Desbonnet) Date: Tue, 21 Jun 2005 03:23:08 +0100 Subject: strange corruption of module config when i try booting with acpi=off Message-ID: <1cef3e950506201923580f1a0f@mail.gmail.com> I apologise in advance for this rather ranty email, but I think its relevant to the dev list because I believe hit on some bug. I (foolishly) try to get FC4 to power manage my laptop (Thinkpad T41p). I don't understand how to do "apm -s" with ACPI (can someone tell me how? -- because I can't find it documented anywhere). So I boot with "acpi=off" boot option so that I can use the more intuitive apm system. On boot system-config-display asks for root password (I've never seen that before). I hit return a few times because I'm not interested in reconfiguring my display (especially at boot time?!). Boot goes bad -- lots of things don't load. In particular pcmcia stuff -- so I don't have networking any more. Oh oh. Ok, no problem I just reboot with default options. No good: my system is still hosed. **Something has reconfigured/corrupted my system setup without my permission.** It has something to do with modues. Nothing unusual has changed in /etc/* at the time of the incident, but all the modules.* files in /lib/modues/2.6.11-1.1369_FC4 now have no data (just the header comment line). Is this a bug, or did I do something incredibly stupid that warranted my system to be rendered unusable? Joe. From bernd.bartmann at gmail.com Tue Jun 21 05:58:53 2005 From: bernd.bartmann at gmail.com (Bernd Bartmann) Date: Tue, 21 Jun 2005 07:58:53 +0200 Subject: Yet again: several missing update announcements In-Reply-To: <1119301152.20104.27.camel@dhcp83-32.boston.redhat.com> References: <6c18a4f050620100273fbb9ee@mail.gmail.com> <1119301152.20104.27.camel@dhcp83-32.boston.redhat.com> Message-ID: <6c18a4f0506202258121e3b79@mail.gmail.com> On 6/20/05, Luke Macken wrote: > On Mon, 2005-06-20 at 19:02 +0200, Bernd Bartmann wrote: > > Hi, > > > > yet again several updates have appeared for FC3/4 on the download > > mirrors, but some of them were never announced on > > fedora-announce-list. Even more confusing is that "Fedora Weekly News > > Issue #1" lists some of the missing announcements but not all. As FC4 > > is out now I've also created a bugzilla tracking bug for the missing > > announcements. So here is the list of what's currently missing: > > > > FC4: #161106 > > pilot-link-0.12.0-0.pre3.0.fc4.1, released 2005-06-17, #161118 > > NetworkManager-0.4-18.FC4, released 2005-06-17, #161117 > > jpilot-0.99.8-0.pre9.fc4.1, released 2005-06-16, #161115 > > xorg-x11-6.8.2-37, released 2005-06-14, #161114 > > gamin-0.1.1-1.FC4, released 2005-06-14, #161113 > > gedit-2.10.2-4, released 2005-06-13, #161111 > > > > FC3: #141256 > > gzip-1.3.3-14.fc3, released 2005-06-17, #161110 > > ncpfs-2.2.4-4.FC3.1, released 2005-06-17, #161109 > > bzip2-1.0.2-13.FC3.1, released 2005-06-16, #161108 > > gamin-0.1.1-1.FC3, released 2005-06-14, #161107 > > gedit-2.8.1-2.fc3.1, released 2005-06-08, #160140 > > bzip2-1.0.2-13.FC3, released 2005-05-19, #158470 > > devhelp-0.9.2-2.3.4, released 2005-05-17, #158320 > > epiphany-1.4.4-4.3.4, released 2005-05-17, #158319 > > devhelp-0.9.2-2.3.3, released 2005-05-17, #158317 > > epiphany-1.4.4-4.3.3, released 2005-05-17, #158315 > > firefox-1.0.4-1.3.1, released 2005-05-17, #158314 > > mozilla-1.7.8-1.3.1, released 2005-05-17, #158313 > > thunderbird-1.0.2-1.3.3, released 2005-05-17, #158311 > > logwatch-5.2.2-1.FC3.1, released 2005-04-26, #156367 > > devhelp-0.9.2-2.3.2, released 2005-04-22, #156017 > > epiphany-1.4.4-4.3.2, released 2005-04-22, #156016 > > mozilla-1.7.7-1.3.1, released 2005-04-22, #156015 > > logwatch-5.2.2-1.FC3, released 2005-04-21, #156014 > > firefox-1.0.3-1.3.1, released 2005-04-19, #156013 > > postfix-2.1.5-5, released 2005-03-17, #151588 > > nfs-utils-1.0.6-52, released 2005-02-19, #149901 > > > > Can we please get this problem fixed once and for all if not for the > > older FC released but at least starting with FC4? > > > > Best regards, > > Bernd. > > Bernd, > > Thanks for taking the time to wrangle these issues and bring them to our > attention. The root of this problem lies in our current update system, > which leaves lots of room for error. I'm currently working on the > re-design of this system which should be in place shortly. Upon > completion, the system will help us automate the majority of these > tedious tasks, hopefully preventing issues like these from reoccurring. Thanks Luke. Now there is some light at the end of the tunnel... In the meantime I'm still going to monitor for new updates and file bugs for missing announcements. Best regards, Bernd. From mikem at cyber.com.au Mon Jun 20 13:02:53 2005 From: mikem at cyber.com.au (Mike MacCana) Date: Mon, 20 Jun 2005 23:02:53 +1000 Subject: YourUpsteamsVeryImportantPackage In-Reply-To: <42B67BBF.9000203@redhat.com> References: <42B15F7F.90803@redhat.com> <42B2E569.3030100@redhat.com> <42B39003.2050503@cyber.com.au> <42B67BBF.9000203@redhat.com> Message-ID: <1119272573.3027.11.camel@localhost.localdomain> On Mon, 2005-06-20 at 10:18 +0200, Harald Hoyer wrote: > :-) Don't worry. This is not the final name. It's only the py-filename. Yaay. To be honest, I like 'servicemanager'. Or 'startup' or 'start' if it's replacing init. Good non-interactive user apps have simple names - eg, sendmail, syslog, etc. Makes it easy to work out what it is they do. As opposed to say 'kudzu' 'anaconda' etc. rc stands for runcommand IIRC, but hardly anyone remembers that, and the name 'run command' doesn't mean anything that's necessarily to do with startup. Anyone remember the 'starting anaconda, please wait...' message? Now the distro actually puts a description beside it, and says the same thing. Nice (I'm the one that suggested it) but it'd have been better if they called it 'installer' or similar. Mike From abo at kth.se Tue Jun 21 09:58:53 2005 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Tue, 21 Jun 2005 11:58:53 +0200 Subject: Single sign-on infrastructure (FC5 wish) In-Reply-To: <42B3D0E0.5020700@develer.com> References: <42B3B097.7060109@develer.com> <42B3C5A8.7080309@cyber.com.au> <42B3D0E0.5020700@develer.com> Message-ID: <1119347934.3843.71.camel@endor.e.kth.se> l?r 2005-06-18 klockan 09:44 +0200 skrev Bernardo Innocenti: > I've played with Arla, but got scared by the apparent > complexity of the server-side installation. I don't think the Arla AFS server is usable. I suggest you use OpenAFS. :-) /abo From abo at kth.se Tue Jun 21 09:58:53 2005 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Tue, 21 Jun 2005 11:58:53 +0200 Subject: Single sign-on infrastructure (FC5 wish) In-Reply-To: <42B3B097.7060109@develer.com> References: <42B3B097.7060109@develer.com> Message-ID: <1119347933.3843.70.camel@endor.e.kth.se> l?r 2005-06-18 klockan 07:26 +0200 skrev Bernardo Innocenti: > - Heimdal's KDC, I have Heimdal and Arla RPM:s that I've been meaning to try to get into Extras. See http:/ayo.sys.kth.se/kth/linux/4/i386/krbafs/ . (Binaries for RHEL4, but the SRPMS works with FC3 at least.) > configured with the LDAP backend. I don't know how that works but I must say I'm very sceptical, mostly from a security standpoint. What's the advantage of doing it that way? > - I couldn't get password-less IMAP to work with > courier-imap because of limited SASL support. > Maybe I'd be more lucky with cyrus-imap Cyrus-IMAPd + Heimdal and Evolution + MIT-KRB play along nicely. /abo From abo at kth.se Tue Jun 21 10:01:12 2005 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Tue, 21 Jun 2005 12:01:12 +0200 Subject: Single sign-on infrastructure (FC5 wish) In-Reply-To: <1119347933.3843.70.camel@endor.e.kth.se> References: <42B3B097.7060109@develer.com> <1119347933.3843.70.camel@endor.e.kth.se> Message-ID: <1119348072.3843.72.camel@endor.e.kth.se> tis 2005-06-21 klockan 11:58 +0200 skrev Alexander Bostr?m: > l?r 2005-06-18 klockan 07:26 +0200 skrev Bernardo Innocenti: > > > - Heimdal's KDC, > > I have Heimdal and Arla RPM:s that I've been meaning to try to get into > Extras. See http:/ayo.sys.kth.se/kth/linux/4/i386/krbafs/ . (Binaries > for RHEL4, but the SRPMS works with FC3 at least.) Or http://www.stacken.kth.se/projekt/arla/redhat.html /abo From kyrre at solution-forge.net Tue Jun 21 10:12:50 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Tue, 21 Jun 2005 12:12:50 +0200 Subject: strange corruption of module config when i try booting with acpi=off In-Reply-To: <1cef3e950506201923580f1a0f@mail.gmail.com> References: <1cef3e950506201923580f1a0f@mail.gmail.com> Message-ID: <1119348769.3385.4.camel@localhost.localdomain> tir, 21.06.2005 kl. 04.23 skrev Joe Desbonnet: > I apologise in advance for this rather ranty email, but I think its > relevant to the dev list because I believe hit on some bug. > > I (foolishly) try to get FC4 to power manage my laptop (Thinkpad > T41p). I don't understand how to do "apm -s" with ACPI (can someone > tell me how? -- because I can't find it documented anywhere). > echo "3" > /proc/acpi/sleep works for me. But i should probably stick it in a script... > So I boot with "acpi=off" boot option so that I can use the more > intuitive apm system. > > On boot system-config-display asks for root password (I've never seen > that before). I hit return a few times because I'm not interested in > reconfiguring my display (especially at boot time?!). > Thats kudzu. It does that to me every time i run it from the terminal - and if i haven't done "xhost +" first, it tells me i couldn't connect to the display (running as root, from gnome-terminal). Its sortof a bug... I should probably report it. > Boot goes bad -- lots of things don't load. In particular pcmcia stuff > -- so I don't have networking any more. Oh oh. Ok, no problem I just > reboot with default options. No good: my system is still hosed. > **Something has reconfigured/corrupted my system setup without my > permission.** > > It has something to do with modues. Nothing unusual has changed in > /etc/* at the time of the incident, but all the modules.* files in > /lib/modues/2.6.11-1.1369_FC4 now have no data (just the header > comment line). > > Is this a bug, or did I do something incredibly stupid that warranted > my system to be rendered unusable? > > Joe. From carljohan at design.chalmers.se Tue Jun 21 10:28:35 2005 From: carljohan at design.chalmers.se (Carl-Johan Kjellander) Date: Tue, 21 Jun 2005 12:28:35 +0200 Subject: stateless-linux problems, kudzu in particular In-Reply-To: <42AE9E7F.8000207@design.chalmers.se> References: <42AE9E7F.8000207@design.chalmers.se> Message-ID: <42B7EBD3.1000809@design.chalmers.se> Carl-Johan Kjellander wrote: > Hi. I'm playing around with stateless-linux which really suits my Company's > needs, and it works ok but we've encountered some problems. All machines, > both server and diskless clients run FC3. > > 1. The screen resolution on the diskless machines is 640x480 and not > 1400x1050 as we set on the protosystem. Why is that and how can we change > it? I've tracked down the problem to kudzu. Kudzu probes and says "Trying Radeon9800" and promptly overwrites /etc/X11/xorg.conf removing all configurations done to the protosystem. How can I stop kudzu overwriting xorg.conf? It's exactly the same card as the one configured in the protosystem, so what is the need for reconfiguration? Or is it because stateless-linux removes the information that the card already has been configured? If I boot up interactively and select not to run kudzu, X starts at the correct resolution and not 800x600 16 bit. > 2. When logging into Gnome we get the old xkb error: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120858 > How can we avoid that? > 4. When trying to reboot the diskless clients the machines get stuck > in an infinite loop of RPC-errors, 111 if I remember correctly but > I have to recheck. It's error 101, whatever that means. Annoying not to be able to reboot the machines. > And where should I file bugs in the stateless-linux scripts? /cjk -- begin 644 carljohan_at_kjellander_dot_com.gif Y1TE&.#=A(0`F`(```````/___RP`````(0`F```"@XR/!\N<#U.;+MI`<[U(>\!UGQ9BGT%>'D2I Y*=NX,2 at OUF2&<827ILW;^822C>\7!!Z1,!K'B5(6HQI6:7"A>Y?):D2^*U at NCV RLZYD-_T1U<@3W]A4(^$-W4]A#V")W6#.R"$;IR'@).46BN7$9>5D``#L` -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3296 bytes Desc: S/MIME Cryptographic Signature URL: From buildsys at redhat.com Tue Jun 21 11:02:10 2005 From: buildsys at redhat.com (Build System) Date: Tue, 21 Jun 2005 07:02:10 -0400 Subject: rawhide report: 20050621 changes Message-ID: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> Updated Packages: audit-0.9.10-1 -------------- * Sun Jun 19 2005 Steve Grubb 0.9.10-1 - Make sure the bad packet is drained when retrying user messages - Add support for new user and watch filter lists - Interpret flags field in ausearch cairo-0.5.1-1 ------------- * Mon Jun 20 2005 Kristian H??gsberg 0.5.1-1 - Update to cairo 0.5.1. - Remove gtk-doc files, since --disable-gtk-doc doesn't work. - Disable gtk-doc and add freetype and fontconfig BuildRequires. glibc-2.3.5-11 -------------- * Mon Jun 20 2005 Jakub Jelinek 2.3.5-11 - update from CVS - PPC32 -msecure-plt support - support classes keyword in /etc/hesiod.conf (#150350) - add RLIMIT_NICE and RLIMIT_RTPRIO to (#157049) - decrease number of .plt relocations in libc.so - use -laudit in nscd (#159217) - handle big amounts of networking interfaces in getifaddrs/if_nameindex (#159399) - fix pa_IN locale's am_pm (#158715, BZ#622) - fix debugging of PIEs * Mon May 30 2005 Jakub Jelinek 2.3.5-10 - fix LD_ASSUME_KERNEL (since 2.3.5-8 GLRO(dl_osversion) has been always overwritten with the version of currently running kernel) - remove linuxthreads man pages other than those covered in 3p section, as 3p man pages are far better quality and describe POSIX behaviour that NPTL implements (#159084) * Tue May 24 2005 Jakub Jelinek 2.3.5-9 - update from CVS - increase bindresvport's LOWPORT to 512, apparently some broken daemons don't think 0 .. 511 ports are reserved iiimf-1:12.2-6 -------------- * Tue Jun 21 2005 Akira TAGOH - 1:12.2-6 - iiimd-init.d: fixed that service iiim stop didn't work properly. * Thu Jun 16 2005 Akira TAGOH - gimlet-default-icon-r2665-159121.patch: set the default window icon. (#159121) isdn4k-utils-3.2-29 ------------------- * Mon Jun 20 2005 Than Ngo 3.2-29 - workaround for loading isdn module at system startup #160831 kernel-2.6.12-1.1387_FC5 ------------------------ * Mon Jun 20 2005 Dave Jones - 2.6.12-git2 - temporarily disable Tux as the rebase broke it. poppler-0.3.3-1 --------------- * Mon Jun 20 2005 Kristian H??gsberg - 0.3.3-1 - Update to 0.3.3 and change to build cairo backend. squirrelmail-1.4.5-0.rc1 ------------------------ * Mon Jun 20 2005 Warren Togami 1.4.5-0.rc1 - 1.4.5-0.rc1 From tiemann at redhat.com Tue Jun 21 12:18:17 2005 From: tiemann at redhat.com (Michael Tiemann) Date: Tue, 21 Jun 2005 08:18:17 -0400 Subject: Yet again: several missing update announcements In-Reply-To: <20050620211801.GP11753@redhat.com> References: <6c18a4f050620100273fbb9ee@mail.gmail.com> <20050620211801.GP11753@redhat.com> Message-ID: <1119356297.3918.10.camel@localhost.localdomain> Daniel, The talk Eric Raymond gave at FUDCon 1 included information about a pet project of his called "shipper" which is addressed at automating all of steps 1..5. I have no idea if the script will work for you, but its existence shows that You Are Not Alone. M On Mon, 2005-06-20 at 17:18 -0400, Daniel Veillard wrote: > On Mon, Jun 20, 2005 at 07:02:45PM +0200, Bernd Bartmann wrote: > > Hi, > > > > yet again several updates have appeared for FC3/4 on the download > > mirrors, but some of them were never announced on > > fedora-announce-list. Even more confusing is that "Fedora Weekly News > > Issue #1" lists some of the missing announcements but not all. As FC4 > > is out now I've also created a bugzilla tracking bug for the missing > > announcements. So here is the list of what's currently missing: > > > gamin-0.1.1-1.FC4, released 2005-06-14, #161113 > [...] > > Can we please get this problem fixed once and for all if not for the > > older FC released but at least starting with FC4? > > Currently as a maintainer, pushing a fedora update I need > > step 1/ to build the update in the appropriate channel > step 2/ label it with an unique number > step 3/ ask and wait for it to be pushed > step 4/ once pushed use a very unconvenient script to > generate the boilerplate for the announcement > step 5/ mail the announcement > > 1/ 2/ and 3/ are under my control, I do them in batch, then there > is an asynchronous mechanism, and then after "some" time I need to do > the messy 4/ and 5/ steps. > > Concusion: > Being a lazy computer guy (remember it's a virtue) once 3/ is done > I tend to think I have done my part, the bits are out, and I don't > feel compelled at all to go to 4/ and 5/ > Moreover, getting bug reports about missing announcement just generate > frustration, I don't like pushing updates as a result, and if you > were among the ones who waited 3 months for a gamin official update > on FC3 between 0.0.25 and 0.1.1 you know why now, I just hate pushing > updates but the srpms are available on my home page. > > > Now if you want the reason why gamin-0.1.1 was pushed: > - on FC3 it fixes the zillion bugs present and found in 0.0.25 > - on FC4 it fixes the desktop update on dynamically mounted > USB media > > Writing this mail is way less painful than sending the real announcements. > If I hadn't the Damocles sword of those missing update bug reports, I would > probably push bug fixes faster. Whether I must be whipped for being lazy, > or the tool for pushing announcement need to be changed or missing announcement > should not be considered bugs, there is a choice, the current situation > does not seems pleasant to you, it's not really for me either. > > Daniel > > -- > Daniel Veillard | Red Hat Desktop team http://redhat.com/ > veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ > http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ > From ndbecker2 at gmail.com Tue Jun 21 12:45:57 2005 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 21 Jun 2005 08:45:57 -0400 Subject: Kolab 2 Groupware released Message-ID: http://www.kolab.org/news/pr-20050620.html From veillard at redhat.com Tue Jun 21 12:57:34 2005 From: veillard at redhat.com (Daniel Veillard) Date: Tue, 21 Jun 2005 08:57:34 -0400 Subject: Yet again: several missing update announcements In-Reply-To: <1119356297.3918.10.camel@localhost.localdomain> References: <6c18a4f050620100273fbb9ee@mail.gmail.com> <20050620211801.GP11753@redhat.com> <1119356297.3918.10.camel@localhost.localdomain> Message-ID: <20050621125734.GB11753@redhat.com> On Tue, Jun 21, 2005 at 08:18:17AM -0400, Michael Tiemann wrote: > Daniel, > > The talk Eric Raymond gave at FUDCon 1 included information about a pet > project of his called "shipper" which is addressed at automating all of > steps 1..5. I have no idea if the script will work for you, but its > existence shows that You Are Not Alone. Sure :-) My mail wasn't really a complaint, I just tried to explain to the majority of the people outside of Red Hat and who don't deal with our internal system what is happening, and why. The fact that step 4 is asynchronous to me is nearly unavoidable since it requires PGP signing of the packages and "some" centralized manual checking is needed. Swapping 5 and 4 or just integrating the textual description for the update in the build process (which we usually do but informally in the rpm spec file Changelog) would allow a fire and forget mode of operation which will bring the consistency required by at least part of the users community and make us more productive/reactive. I assume it's what Luke is working on :-), and hope the community will understand better what is actually going on ! Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From enrico.scholz at informatik.tu-chemnitz.de Tue Jun 21 12:58:32 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 21 Jun 2005 14:58:32 +0200 Subject: Kolab 2 Groupware released In-Reply-To: (Neal Becker's message of "Tue, 21 Jun 2005 08:45:57 -0400") References: Message-ID: <87y893vpc7.fsf@kosh.bigo.ensc.de> ndbecker2 at gmail.com (Neal Becker) writes: > http://www.kolab.org/news/pr-20050620.html How far are the server components (OpenLDAP, Cyrus-IMAP, Apache, ...) patched? Or are these the default programs which are shipped by FC or FE already? Enrico From fedora at wir-sind-cool.org Tue Jun 21 13:33:05 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 21 Jun 2005 15:33:05 +0200 Subject: Yet again: several missing update announcements In-Reply-To: <1119356297.3918.10.camel@localhost.localdomain> References: <6c18a4f050620100273fbb9ee@mail.gmail.com> <20050620211801.GP11753@redhat.com> <1119356297.3918.10.camel@localhost.localdomain> Message-ID: <20050621153305.1341433b.fedora@wir-sind-cool.org> On Tue, 21 Jun 2005 08:18:17 -0400, Michael Tiemann wrote: > Daniel, > > The talk Eric Raymond gave at FUDCon 1 included information about a pet > project of his called "shipper" which is addressed at automating all of > steps 1..5. I have no idea if the script will work for you, but its > existence shows that You Are Not Alone. The problem addressed by shipper is much simpler. Automated uploading (or submission to a few specific hardcoded backends like freshmeat) of files and/or sending of e-mail announcements. It doesn't handle steps 2 and 3 (wait for somebody to sign and push the packages and then collect the final package MD5 fingerprints for the announcement), if there is no backend that allows for such automation, and if the specific release process is not implemented in shipper anyway. -- Fedora Core release 4 (Stentz) - Linux 2.6.11-1.1369_FC4 loadavg: 1.00 1.03 1.09 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tarjei.knapstad at predichem.com Tue Jun 21 13:40:48 2005 From: tarjei.knapstad at predichem.com (Tarjei Knapstad) Date: Tue, 21 Jun 2005 15:40:48 +0200 Subject: A map of Fedora packages and dependencies Message-ID: <1119361248.27240.92.camel@tarjei.predichem.nett> [Disclaimer: This is probably going to end up as a blurb about dependencies - bear with me :)] Firstly, I was just perusing through the FC4 package description list and was reminded of something I've thought of many times: Would it be possible to map out the package dependencies in Fedora by doing rpm queries and forming a directed graph of the results? (by using graphviz or something like that) I think such a package dependency map would be quite useful to get an overview of the distribution, both for developers and users. "End nodes" in the graph could help identify candidates that could be moved to extras for instance (you might even tag vertices with the package size). >From the users perspective it would get a lot easier to get an overview of the impact of removing a package, or if you want to rebuild a homebrew package for some reason ("I'd really like to just rebuild this package myself to the bleeding edge, but what else would it impact and maybe even break, if anything?"). Secondly I was thinking of a "DependencyLint" kind of tool - a small Python script maybe that would go through every installed RPM on a system and check if the requirements in the .spec files are correct and/or sufficient. Here I'm not quite sure about what the rules are for Fedora however - should absolutely everything that's needed to build a package be in BuildRequires:? Should every package that has C code require glibc? Or is it a goal to be as lax as possible to prevent (hopefully) unnecessary build problems? In any case I was thinking of maybe using a combination of RPM querying and ldd (and possibly other tools). An example (from a FC1 box): 1. Get a list of all the RPM's on the system. 2. For each package, list the files and grep the bin/ and lib/ stuff. For instance 'rpm -ql mutt|grep bin' lists /usr/bin/mutt as one of it's files. 3. Check which dynamic libraries these binaries and libraries depend on using 'ldd'. 'ldd /usr/bin/mutt' lists /usr/lib/libz.so.1 among others. 4. For each of these, check which package provides them. 'rpm -q --whatprovides /usr/lib/libz.so.1' returns 'zlib-1.2.0.7-2' 5. Finally check that the original package depends on zlib. (This step I'm not sure what's the best way to query.) 'rpm -q --requires mutt' does not list zlib and 'rpm -e --test zlib' does not list mutt so we've actually found a missing dependency here. These are just my first thoughts to maybe encourage some discussion. I'm sure this could be done in a better way and could probably also be expanded to do other stuff (I'm not very RPM-savvy). If you run a live testinstall of rawhide for instance such a tool could be run automatically after each update to detect any packaging problems wrt. dependencies. Thoughts? Regards, -- Tarjei From skvidal at phy.duke.edu Tue Jun 21 13:46:12 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 21 Jun 2005 09:46:12 -0400 Subject: A map of Fedora packages and dependencies In-Reply-To: <1119361248.27240.92.camel@tarjei.predichem.nett> References: <1119361248.27240.92.camel@tarjei.predichem.nett> Message-ID: <1119361572.1342.3.camel@cutter> On Tue, 2005-06-21 at 15:40 +0200, Tarjei Knapstad wrote: > [Disclaimer: This is probably going to end up as a blurb about > dependencies - bear with me :)] > > Firstly, I was just perusing through the FC4 package description list > and was reminded of something I've thought of many times: > > Would it be possible to map out the package dependencies in Fedora by > doing rpm queries and forming a directed graph of the results? (by using > graphviz or something like that) > > I think such a package dependency map would be quite useful to get an > overview of the distribution, both for developers and users. "End nodes" > in the graph could help identify candidates that could be moved to > extras for instance (you might even tag vertices with the package size). > >From the users perspective it would get a lot easier to get an overview > of the impact of removing a package, or if you want to rebuild a > homebrew package for some reason ("I'd really like to just rebuild this > package myself to the bleeding edge, but what else would it impact and > maybe even break, if anything?"). > > Secondly I was thinking of a "DependencyLint" kind of tool - a small > Python script maybe that would go through every installed RPM on a > system and check if the requirements in the .spec files are correct > and/or sufficient. Here I'm not quite sure about what the rules are for > Fedora however - should absolutely everything that's needed to build a > package be in BuildRequires:? Should every package that has C code > require glibc? Or is it a goal to be as lax as possible to prevent > (hopefully) unnecessary build problems? > > In any case I was thinking of maybe using a combination of RPM querying > and ldd (and possibly other tools). An example (from a FC1 box): > > 1. Get a list of all the RPM's on the system. > > 2. For each package, list the files and grep the bin/ and lib/ stuff. > For instance 'rpm -ql mutt|grep bin' lists /usr/bin/mutt as one of it's > files. > > 3. Check which dynamic libraries these binaries and libraries depend on > using 'ldd'. 'ldd /usr/bin/mutt' lists /usr/lib/libz.so.1 among others. > > 4. For each of these, check which package provides them. > 'rpm -q --whatprovides /usr/lib/libz.so.1' returns 'zlib-1.2.0.7-2' > > 5. Finally check that the original package depends on zlib. (This step > I'm not sure what's the best way to query.) 'rpm -q --requires mutt' > does not list zlib and 'rpm -e --test zlib' does not list mutt so we've > actually found a missing dependency here. > > These are just my first thoughts to maybe encourage some discussion. I'm > sure this could be done in a better way and could probably also be > expanded to do other stuff (I'm not very RPM-savvy). If you run a live > testinstall of rawhide for instance such a tool could be run > automatically after each update to detect any packaging problems wrt. > dependencies. > 1. Do an everything install of core. 2. install yum-utils 3. run package-cleanup --leaves that'll tell you all the specific leaf nodes. -sv From notting at redhat.com Tue Jun 21 13:45:20 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 21 Jun 2005 09:45:20 -0400 Subject: A map of Fedora packages and dependencies In-Reply-To: <1119361248.27240.92.camel@tarjei.predichem.nett> References: <1119361248.27240.92.camel@tarjei.predichem.nett> Message-ID: <20050621134520.GA7564@nostromo.devel.redhat.com> Tarjei Knapstad (tarjei.knapstad at predichem.com) said: > Would it be possible to map out the package dependencies in Fedora by > doing rpm queries and forming a directed graph of the results? (by using > graphviz or something like that) http://adrian.gimp.org/rpm-graph/ Bill From mattdm at mattdm.org Tue Jun 21 13:49:32 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 21 Jun 2005 09:49:32 -0400 Subject: A map of Fedora packages and dependencies In-Reply-To: <20050621134520.GA7564@nostromo.devel.redhat.com> References: <1119361248.27240.92.camel@tarjei.predichem.nett> <20050621134520.GA7564@nostromo.devel.redhat.com> Message-ID: <20050621134932.GA21012@jadzia.bu.edu> On Tue, Jun 21, 2005 at 09:45:20AM -0400, Bill Nottingham wrote: > Tarjei Knapstad (tarjei.knapstad at predichem.com) said: > > Would it be possible to map out the package dependencies in Fedora by > > doing rpm queries and forming a directed graph of the results? (by using > > graphviz or something like that) > http://adrian.gimp.org/rpm-graph/ That doesn't work with recent rpm python bindings. But I'm glad to see you refer to it, because I feel less dumb for not knowing that an equivalent program, "rpmgraph", is included in the rpm-devel package itself. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 78 degrees Fahrenheit. From nicolas.mailhot at laposte.net Tue Jun 21 13:08:41 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 21 Jun 2005 15:08:41 +0200 (CEST) Subject: rawhide report: 20050617 changes In-Reply-To: <1119041598.12551.14.camel@localhost.localdomain> References: <200506171135.j5HBZILw030776@porkchop.devel.redhat.com> <20050617144640.4fcf55bb@python2> <1119022492.12460.0.camel@tofu.toronto.redhat.com> <1119041598.12551.14.camel@localhost.localdomain> Message-ID: <49719.192.54.193.28.1119359321.squirrel@rousalka.dyndns.org> On Ven 17 juin 2005 22:53, Panu Matilainen a ?crit : > On Fri, 2005-06-17 at 11:34 -0400, Andrew Overholt wrote: >> On Fri, 2005-06-17 at 14:46 +0200, Matthias Saou wrote: >> > Am I the only one that it kind of bothers to not see java stuff using >> a >> > dedicated namespace for the package names? Due to the fragmentation of the java space you have several namespaces. All the jakarta components are filed under jakarta-*, classpath components have their own namespave too, etc All the one-offs not attached to a particular project and that are strange mixes of libs and apps have no prefix, just like yum is not python-yum. >> > Things like "gnu.regexp" >> seem >> > totally wrong... not to mention the dot in the name for that >> particular >> > one. > > No you're not alone in that Matthias... > >> >> If you want, bring this up with the JPackage folk since that's where the >> names are coming from. > > Since when did FC start to follow whatever somebody else does? Since it got for free a thousand of compatible packages. Feel free to rename all of them and rebuild them and check the deps you end up with are still right (there are no autodep macros in java land) > It's not any different for java, "gnu.regexp" is simply a bad name for a > java-only library I agree this one is bad - it should be gnu- or classpath- something instead. Feel free to fix this kind of warts upstream at jpackage, admittance is free and paquage quality is directly proportional to contributer & reviewer numbers. This is a community project. We don't have half the entry barriers of FC or FE because we can not afford to. > (or whatever they're called in the java-land). > Just imagine all the perl-modules in FC without perl-prefix: perl- components all come from a single project CPAN with common guidelines and rules. Java packages that use a cpan-like infrastructure have their own namespaces but a big part of the java space is just fragmented. Adding a blanket namespace for stuff that feels different and behaves different is just stupid. Also apps are not namespaced in fedora. Regards, -- Nicolas Mailhot From tarjei.knapstad at predichem.com Tue Jun 21 14:23:20 2005 From: tarjei.knapstad at predichem.com (Tarjei Knapstad) Date: Tue, 21 Jun 2005 16:23:20 +0200 Subject: A map of Fedora packages and dependencies In-Reply-To: <1119361572.1342.3.camel@cutter> References: <1119361248.27240.92.camel@tarjei.predichem.nett> <1119361572.1342.3.camel@cutter> Message-ID: <1119363799.27240.94.camel@tarjei.predichem.nett> On Tue, 2005-06-21 at 15:46, seth vidal wrote: > On Tue, 2005-06-21 at 15:40 +0200, Tarjei Knapstad wrote: > > These are just my first thoughts to maybe encourage some discussion. I'm > > sure this could be done in a better way and could probably also be > > expanded to do other stuff (I'm not very RPM-savvy). If you run a live > > testinstall of rawhide for instance such a tool could be run > > automatically after each update to detect any packaging problems wrt. > > dependencies. > > > > 1. Do an everything install of core. > 2. install yum-utils > 3. run package-cleanup --leaves > > that'll tell you all the specific leaf nodes. > Excellent, thanks Seth. Cheers, -- Tarjei From tarjei.knapstad at predichem.com Tue Jun 21 14:38:56 2005 From: tarjei.knapstad at predichem.com (Tarjei Knapstad) Date: Tue, 21 Jun 2005 16:38:56 +0200 Subject: A map of Fedora packages and dependencies In-Reply-To: <20050621134932.GA21012@jadzia.bu.edu> References: <1119361248.27240.92.camel@tarjei.predichem.nett> <20050621134520.GA7564@nostromo.devel.redhat.com> <20050621134932.GA21012@jadzia.bu.edu> Message-ID: <1119364736.27240.99.camel@tarjei.predichem.nett> On Tue, 2005-06-21 at 15:49, Matthew Miller wrote: > On Tue, Jun 21, 2005 at 09:45:20AM -0400, Bill Nottingham wrote: > > Tarjei Knapstad (tarjei.knapstad at predichem.com) said: > > > Would it be possible to map out the package dependencies in Fedora by > > > doing rpm queries and forming a directed graph of the results? (by using > > > graphviz or something like that) > > http://adrian.gimp.org/rpm-graph/ > > That doesn't work with recent rpm python bindings. But I'm glad to see you > refer to it, because I feel less dumb for not knowing that an equivalent > program, "rpmgraph", is included in the rpm-devel package itself. > Thanks Bill, Matthew. Looks like rpmgraph only works on a set of available packages though, and not on the local DB of already installed RPM's. In any case, the example graph for RH 7.0 was a lot more of a clutter than I had feared/hoped and pretty much unusable as a reference. Think I'll just forget about this for now... Thanks again, -- Tarjei From ph18 at cornell.edu Tue Jun 21 14:44:43 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Tue, 21 Jun 2005 10:44:43 -0400 Subject: A map of Fedora packages and dependencies In-Reply-To: <1119364736.27240.99.camel@tarjei.predichem.nett> References: <1119361248.27240.92.camel@tarjei.predichem.nett> <20050621134520.GA7564@nostromo.devel.redhat.com> <20050621134932.GA21012@jadzia.bu.edu> <1119364736.27240.99.camel@tarjei.predichem.nett> Message-ID: <42B827DB.1070509@cornell.edu> Tarjei Knapstad wrote: >In any case, the example graph for RH 7.0 was a lot more of a clutter >than I had feared/hoped and pretty much unusable as a reference. Think >I'll just forget about this for now... > >Thanks again, >-- >Tarjei > > You don't need to give up. Graph visualization tools that print out a static image are of limited use, as you've found. There are tools out there for interactive graphing that let you pick out particular nodes and explore the relationships between them, and something like that is worth pursuing. From linux_4ever at yahoo.com Tue Jun 21 14:53:34 2005 From: linux_4ever at yahoo.com (Steve G) Date: Tue, 21 Jun 2005 07:53:34 -0700 (PDT) Subject: A map of Fedora packages and dependencies In-Reply-To: <1119361248.27240.92.camel@tarjei.predichem.nett> Message-ID: <20050621145334.31758.qmail@web51507.mail.yahoo.com> >Would it be possible to map out the package dependencies in Fedora by >doing rpm queries and forming a directed graph of the results? (by using >graphviz or something like that) Yes you can. rpmgraph will give you the "runtime" dependencies. But if you are looking for the build dependencies, the Rookery build system has a tool in it for this purpose. http://www.web-insights.net/rookery/ What you will need to do is setup a repo of all the srpms. Then do the prep for build, and maybe even the check for build. Go into the analyze menu and it can do the whole repo, or just 1 package's dependencies. The 1 package can give you either the dependencies from that package back to nothing, or you can see what depends on that package, or both. This removes the clutter and lets you see the relationships that a particular package has. I have an example for mkinitrd here: http://www.web-insights.net/rookery/mkinitrd.dep.gz and server portion of FC3: http://www.web-insights.net/rookery/fc3.ps.gz I have tools halfway complete to really tighten up the dependencies. Both in terms of build and runtime. I will try to finish these during the FC5 development cycle to get correct dependency information added back to the packages. -Steve Grubb __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From ellson at research.att.com Tue Jun 21 14:55:57 2005 From: ellson at research.att.com (John Ellson) Date: Tue, 21 Jun 2005 10:55:57 -0400 Subject: A map of Fedora packages and dependencies In-Reply-To: <1119364736.27240.99.camel@tarjei.predichem.nett> References: <1119361248.27240.92.camel@tarjei.predichem.nett> <20050621134520.GA7564@nostromo.devel.redhat.com> <20050621134932.GA21012@jadzia.bu.edu> <1119364736.27240.99.camel@tarjei.predichem.nett> Message-ID: <42B82A7D.40304@research.att.com> Tarjei Knapstad wrote: > >In any case, the example graph for RH 7.0 was a lot more of a clutter >than I had feared/hoped and pretty much unusable as a reference. Think >I'll just forget about this for now... > > > Its interesting to me how often the value of a Graphviz rendering is just this, to indicate the unexpected complexity of a system. I suppose it is more interesting to see a picture, but sometimes the output of gc (think wc on graphs) can be used as a measure of complexity with much less rendering time. $ gc redhat-7.0-i386.dot 719 2681 redhat (redhat-7.0-i386.dot) i.e. redhat-7.0-i386.dot contains 719 nodes (packages) and 2681 edges (dependencies). John From tibbs at math.uh.edu Tue Jun 21 15:11:43 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 21 Jun 2005 10:11:43 -0500 Subject: Single sign-on infrastructure (FC5 wish) In-Reply-To: <1119347933.3843.70.camel@endor.e.kth.se> (Alexander =?iso-8859-1?q?Bostr=F6m's?= message of "Tue, 21 Jun 2005 11:58:53 +0200") References: <42B3B097.7060109@develer.com> <1119347933.3843.70.camel@endor.e.kth.se> Message-ID: >>>>> "AB" == Alexander Bostr?m writes: AB> I don't know how that works but I must say I'm very sceptical, AB> mostly from a security standpoint. What's the advantage of doing AB> it that way? A single replication infrastructure. I use the MIT KDC because it's what Red Hat happens to ship, but I'd much rather have everything in LDAP instead of having two separate systems to configure and maintain. - J< From Florin.Malita at Glenayre.com Tue Jun 21 15:43:58 2005 From: Florin.Malita at Glenayre.com (Malita, Florin) Date: Tue, 21 Jun 2005 11:43:58 -0400 Subject: FC4 kernel performance Message-ID: <1119368638.5902.174.camel@scox.glenatl.glenayre.com> I've recently benchmarked the FC4 kernel (2.6.11-1.1369_FC4) against vanilla 2.6.11.12 using UnixBench. I have to confess that the substantial performance gap surprised me (the vanilla kernel showed a hard to ignore 62% performance gain over the Fedora default) so I tried to dig into it and possibly identify the culprit: re-ran the tests with the Fedora kernel recompiled in different configurations. The tests were run on a 1.7GHz P4 and the configuration tags are: * orig: the original kernel as shipped with FC4 * nodebug: kernel debugging options disabled * p4: processor family set to Pentium 4 * nose: NSA SE Linux options disabled * nohm: high memory support turned off * lean: minimal configuration, matching the test hw The complete results (there's an Open Solaris test in there too, feel free to ignore;) : http://lufs.sourceforge.net/unixbench.html The final scores: 1. Linux 2.6.11.12 vanilla (nodebug+p4+nose+nohm+lean): 345.8 2. Linux 2.6.11-1.1369_FC4 (nodebug+p4+nose+nohm+lean): 269.3 3. Linux 2.6.11-1.1369_FC4 (nodebug+p4+nose+ nohm): 253.1 4. Linux 2.6.11-1.1369_FC4 (nodebug+p4): 239.4 5. Linux 2.6.11-1.1369_FC4 (nodebug): 236.7 6: Linux 2.6.11-1.1369_FC4 (orig): 213.2 7: SunOS 5.11 (orig): 122.3 (note that #1 & #2 were built with identical configurations) >From this I can infer 2 overhead components: - one related to the features enabled in the original kernel configuration, which account for the difference 6<->2 - one that seems to be introduced by the FC kernel patch set, responsible for the 2<->1 difference Regarding the configuration component, I can understand why certain features and the overhead associated with them are preferred vs raw kernel performance. OTOH, leaving 62% on the table makes me feel uneasy. Do I really need high mem, SE Linux or a debug-enabled kernel on my desktop? Don't think so. But I do want the kernel preemption enabled... My point is: with so many kernel features, "one size fits all" doesn't hold anymore and maybe we should have a much broader array of kernels to choose from at install time (not just architecture/SMP variants). This should be fairly easy to support as it's just a matter of adding new build configurations in the kernel SRPM/spec. Regarding the second overhead component, there's still a serious performance gap between the FC4 kernel and its vanilla correspondent even when built with identical configurations. This points the finger at the FC4 kernel patches that obviously have a big impact on performance. The system call overhead in particular seems way off, I remember a discussion about exec shield/NX disabling vsyscall and thus hurting P4s big time - is this still the case? Anyway, I wanted to share these results with you and raise awareness on the kernel performance issue. It would be a shame for FC to get a slow/bloated OS reputation just because nobody noticed that feature creep is killing its performance ;). Cheers, Florin From davej at redhat.com Tue Jun 21 15:47:55 2005 From: davej at redhat.com (Dave Jones) Date: Tue, 21 Jun 2005 11:47:55 -0400 Subject: FC4 kernel performance In-Reply-To: <1119368638.5902.174.camel@scox.glenatl.glenayre.com> References: <1119368638.5902.174.camel@scox.glenatl.glenayre.com> Message-ID: <20050621154755.GC21723@redhat.com> On Tue, Jun 21, 2005 at 11:43:58AM -0400, Malita, Florin wrote: > I've recently benchmarked the FC4 kernel (2.6.11-1.1369_FC4) against > vanilla 2.6.11.12 using UnixBench. Which is an apples to oranges comparison. 2.6.11-1.1369_FC4 is actually based on 2.6.12rc6. I'll be interested in seeing results rerun against this kernel. Dave From walters at redhat.com Tue Jun 21 15:54:05 2005 From: walters at redhat.com (Colin Walters) Date: Tue, 21 Jun 2005 11:54:05 -0400 Subject: FC4 kernel performance In-Reply-To: <1119368638.5902.174.camel@scox.glenatl.glenayre.com> References: <1119368638.5902.174.camel@scox.glenatl.glenayre.com> Message-ID: <1119369245.3569.8.camel@nexus.verbum.private> On Tue, 2005-06-21 at 11:43 -0400, Malita, Florin wrote: > Regarding the configuration component, I can understand why certain > features and the overhead associated with them are preferred vs raw > kernel performance. OTOH, leaving 62% on the table makes me feel uneasy. > Do I really need high mem, SE Linux or a debug-enabled kernel on my > desktop? Don't think so. Ah, but is Unixbench a relevant benchmark for a desktop? For example making process creation 15% faster isn't very useful if process creation accounts for .001% of application startup time. A server's a different story, but there e.g. highmem and SELinux are very useful. > But I do want the kernel preemption enabled... The kernel team has that disabled because it's unsafe, IIRC. > My point is: with so many kernel features, "one size fits all" doesn't > hold anymore and maybe we should have a much broader array of kernels to > choose from at install time (not just architecture/SMP variants). This > should be fairly easy to support as it's just a matter of adding new > build configurations in the kernel SRPM/spec. I'm skeptical that (apart from preemption) having e.g. a "desktop" kernel would be useful. We have a lot of optimization we could do (and are doing) in userspace. From matthew at nocturnal.org Tue Jun 21 15:58:27 2005 From: matthew at nocturnal.org (Matthew Lenz) Date: Tue, 21 Jun 2005 10:58:27 -0500 Subject: FC4 kernel performance In-Reply-To: <20050621154755.GC21723@redhat.com> References: <1119368638.5902.174.camel@scox.glenatl.glenayre.com> <20050621154755.GC21723@redhat.com> Message-ID: <1119369507.19988.4.camel@mlenzdesktop> I've noticed a considerable slowdown in performance over FC3 across the board. Applications take longer to launch. I/O seems to have a much more adverse affect on system response. I guess I always just figured its cuz everything was compiled with GCC4 and kinks are being worked out with performance *shrug* On Tue, 2005-06-21 at 11:47 -0400, Dave Jones wrote: > On Tue, Jun 21, 2005 at 11:43:58AM -0400, Malita, Florin wrote: > > I've recently benchmarked the FC4 kernel (2.6.11-1.1369_FC4) against > > vanilla 2.6.11.12 using UnixBench. > > Which is an apples to oranges comparison. 2.6.11-1.1369_FC4 is > actually based on 2.6.12rc6. I'll be interested in seeing results > rerun against this kernel. > > Dave > From seanos at netsoc.itcarlow.ie Tue Jun 21 16:02:59 2005 From: seanos at netsoc.itcarlow.ie (Sean O Sullivan) Date: Tue, 21 Jun 2005 17:02:59 +0100 Subject: FC4 kernel performance In-Reply-To: <1119369507.19988.4.camel@mlenzdesktop> References: <1119368638.5902.174.camel@scox.glenatl.glenayre.com> <20050621154755.GC21723@redhat.com> <1119369507.19988.4.camel@mlenzdesktop> Message-ID: <42B83A33.4030907@netsoc.itcarlow.ie> Matthew Lenz wrote: > I've noticed a considerable slowdown in performance over FC3 across the > board. Applications take longer to launch. I/O seems to have a much > more adverse affect on system response. I guess I always just figured > its cuz everything was compiled with GCC4 and kinks are being worked out > with performance *shrug* Funny, I would have said the opposite - found FC4 a /lot/ faster at booting and general usage. Regards, Sean From pbrobinson at gmail.com Tue Jun 21 16:03:42 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 21 Jun 2005 17:03:42 +0100 Subject: FC4 kernel performance In-Reply-To: <1119369507.19988.4.camel@mlenzdesktop> References: <1119368638.5902.174.camel@scox.glenatl.glenayre.com> <20050621154755.GC21723@redhat.com> <1119369507.19988.4.camel@mlenzdesktop> Message-ID: <5256d0b050621090367a435e0@mail.gmail.com> > I've noticed a considerable slowdown in performance over FC3 across the > board. Applications take longer to launch. I/O seems to have a much > more adverse affect on system response. I guess I always just figured > its cuz everything was compiled with GCC4 and kinks are being worked out > with performance *shrug* When I first upgraded I noticed a general improvement. Although I don't know whether that was ggc or some of the memory improvments that was done with GNOME. Peter From Fedora at TQMcube.com Tue Jun 21 16:08:22 2005 From: Fedora at TQMcube.com (David Cary Hart) Date: Tue, 21 Jun 2005 12:08:22 -0400 Subject: FC4 kernel performance In-Reply-To: <20050621154755.GC21723@redhat.com> References: <1119368638.5902.174.camel@scox.glenatl.glenayre.com> <20050621154755.GC21723@redhat.com> Message-ID: <1119370102.2475.37.camel@dch.TQMcube.com> On Tue, 2005-06-21 at 11:47 -0400, Dave Jones wrote: > On Tue, Jun 21, 2005 at 11:43:58AM -0400, Malita, Florin wrote: > > I've recently benchmarked the FC4 kernel (2.6.11-1.1369_FC4) against > > vanilla 2.6.11.12 using UnixBench. > > Which is an apples to oranges comparison. 2.6.11-1.1369_FC4 is > actually based on 2.6.12rc6. I'll be interested in seeing results > rerun against this kernel. Dave, I still wish that FC would revert to the FC3 src.rpm structure where the spec provided for a source rpm build. I suspect that the number of users who wish to customize their kernel is growing and the FC3 method seems much simpler (at least to me). BTW, vanilla 2.6.12 (anecdotally) provides seemingly far superior ftp, http, rsync download speeds in contrast to the distro kernel. -- * Eliminate Spam: http://www.TQMcube.com/spam_trap.htm * RBLDNSD HowTo: http://www.TQMcube.com/rbldnsd.htm * Multi-RBL Check: http://www.TQMcube.com/rblcheck.htm From matthew at nocturnal.org Tue Jun 21 16:30:55 2005 From: matthew at nocturnal.org (Matthew Lenz) Date: Tue, 21 Jun 2005 11:30:55 -0500 Subject: FC4 kernel performance In-Reply-To: <42B83A33.4030907@netsoc.itcarlow.ie> References: <1119368638.5902.174.camel@scox.glenatl.glenayre.com> <20050621154755.GC21723@redhat.com> <1119369507.19988.4.camel@mlenzdesktop> <42B83A33.4030907@netsoc.itcarlow.ie> Message-ID: <1119371455.19988.7.camel@mlenzdesktop> Booting.. absolutely. But for me, everything else is slower. I'll have to poke around. On Tue, 2005-06-21 at 17:02 +0100, Sean O Sullivan wrote: > Matthew Lenz wrote: > > I've noticed a considerable slowdown in performance over FC3 across the > > board. Applications take longer to launch. I/O seems to have a much > > more adverse affect on system response. I guess I always just figured > > its cuz everything was compiled with GCC4 and kinks are being worked out > > with performance *shrug* > > Funny, I would have said the opposite - found FC4 a /lot/ faster at > booting and general usage. > > Regards, > > Sean > From Florin.Malita at Glenayre.com Tue Jun 21 17:07:49 2005 From: Florin.Malita at Glenayre.com (Malita, Florin) Date: Tue, 21 Jun 2005 13:07:49 -0400 Subject: FC4 kernel performance Message-ID: <1119373669.5902.177.camel@scox.glenatl.glenayre.com> On Tue, 2005-06-21 at 11:47 -0400, Dave Jones wrote: > On Tue, Jun 21, 2005 at 11:43:58AM -0400, Malita, Florin wrote: > > I've recently benchmarked the FC4 kernel (2.6.11-1.1369_FC4) > against > > vanilla 2.6.11.12 using UnixBench. > > Which is an apples to oranges comparison. 2.6.11-1.1369_FC4 is > actually based on 2.6.12rc6. I'll be interested in seeing results > rerun against this kernel. Will do. Is the FC tree public? I was tinkering with the idea of automated/nightly kernel performance tests. From sundaram at redhat.com Tue Jun 21 17:11:51 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Tue, 21 Jun 2005 22:41:51 +0530 Subject: FC4 kernel performance In-Reply-To: <1119373669.5902.177.camel@scox.glenatl.glenayre.com> References: <1119373669.5902.177.camel@scox.glenatl.glenayre.com> Message-ID: <42B84A57.5040000@redhat.com> Malita, Florin wrote: >On Tue, 2005-06-21 at 11:47 -0400, Dave Jones wrote: > > >>On Tue, Jun 21, 2005 at 11:43:58AM -0400, Malita, Florin wrote: >> > I've recently benchmarked the FC4 kernel (2.6.11-1.1369_FC4) >>against >> > vanilla 2.6.11.12 using UnixBench. >> >>Which is an apples to oranges comparison. 2.6.11-1.1369_FC4 is >>actually based on 2.6.12rc6. I'll be interested in seeing results >>rerun against this kernel. >> >> > >Will do. > >Is the FC tree public? I was tinkering with the idea of >automated/nightly kernel performance tests. > > > That would very interesting. http://cvs.fedora.redhat.com for the public tree regards Rahul From Florin.Malita at Glenayre.com Tue Jun 21 17:23:26 2005 From: Florin.Malita at Glenayre.com (Malita, Florin) Date: Tue, 21 Jun 2005 13:23:26 -0400 Subject: FC4 kernel performance Message-ID: <1119374606.5901.191.camel@scox.glenatl.glenayre.com> On Tue, 2005-06-21 at 11:54 -0400, Colin Walters wrote: > Ah, but is Unixbench a relevant benchmark for a desktop? Probably not as relevant as for servers, but I'm sure the kernel does make a difference. I would assume I/O performance affects application startup time a whole lot more than process creation. On a server though, that 62% (taken with a grain of salt until I get the 2.6.12-rc6 results) is really worrying me. > I'm skeptical that (apart from preemption) having e.g. a "desktop" > kernel would be useful. How about the kernel debug options - shouldn't that be a special-purpose kernel? From Florin.Malita at Glenayre.com Tue Jun 21 17:25:46 2005 From: Florin.Malita at Glenayre.com (Malita, Florin) Date: Tue, 21 Jun 2005 13:25:46 -0400 Subject: FC4 kernel performance Message-ID: <1119374746.5902.193.camel@scox.glenatl.glenayre.com> On Tue, 2005-06-21 at 13:11 -0400, Rahul Sundaram wrote: > That would very interesting. http://cvs.fedora.redhat.com for the > public tree Thanks, I'll see if I can set something up in the next days. From mattdm at mattdm.org Tue Jun 21 17:39:32 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 21 Jun 2005 13:39:32 -0400 Subject: FC4 kernel performance In-Reply-To: <1119370102.2475.37.camel@dch.TQMcube.com> References: <1119368638.5902.174.camel@scox.glenatl.glenayre.com> <20050621154755.GC21723@redhat.com> <1119370102.2475.37.camel@dch.TQMcube.com> Message-ID: <20050621173932.GA30669@jadzia.bu.edu> On Tue, Jun 21, 2005 at 12:08:22PM -0400, David Cary Hart wrote: > Dave, I still wish that FC would revert to the FC3 src.rpm structure > where the spec provided for a source rpm build. I suspect that the > number of users who wish to customize their kernel is growing and the > FC3 method seems much simpler (at least to me). This has been rehashed a zillion times, but the short answer is that it's not really any good, since the resulting source tree isn't necessarily "clean" for the build architecture you expect. Tweaking the source rpm is a bit more learning and a tiny bit more work upfront, but it makes management easier (worth sometime) and produces more correct results (priceless). -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 79 degrees Fahrenheit. From Jeffery.Weston at nrl.navy.mil Tue Jun 21 17:43:57 2005 From: Jeffery.Weston at nrl.navy.mil (Jeff Weston) Date: Tue, 21 Jun 2005 13:43:57 -0400 Subject: Enable Default CONFIG_IP6_NF_QUEUE? Message-ID: <200506211746.j5LHk2QB012489@s2.itd.nrl.navy.mil> Userspace queueuing of IPv6 packets (CONFIG_IP6_NF_QUEUE kernel option) has been significantly improved in the 2.6.12 kernel. Userspace queueing is already enabled by default for IPv4 packets, but it does not seem to be enabled for IPv6 packets even in the FC4 release kernel. Would it be possible for future Fedora updates to enable CONFIG_IP6_NF_QUEUE (as a module) by default? I doubt that enabling it as a module would cause any problems, and it would be extremely useful in cases where IPv6 packets need to be modified before being sent out an interface. We would be using it in the immediate future for multicast forwarding/flooding in Mobile Ad-Hoc Networks (MANETs), though it has potential applications in Mobile IPv6 and elsewhere. Thanks for your consideration. -Jeff Weston From Florin.Malita at Glenayre.com Tue Jun 21 18:17:59 2005 From: Florin.Malita at Glenayre.com (Malita, Florin) Date: Tue, 21 Jun 2005 14:17:59 -0400 Subject: FC4 kernel performance Message-ID: <1119377879.5901.206.camel@scox.glenatl.glenayre.com> On Tue, 2005-06-21 at 11:47 -0400, Dave Jones wrote: > Which is an apples to oranges comparison. 2.6.11-1.1369_FC4 is > actually based on 2.6.12rc6. I'll be interested in seeing results > rerun against this kernel. Back with some apples: http://lufs.sourceforge.net/unixbench.html Now I have: 1. Linux 2.6.12-rc6 (nodebug+p4+nose+nohm+lean): 355.7 2. Linux 2.6.11.12 (nodebug+p4+nose+nohm+lean): 345.8 3. Linux 2.6.11-1.1369_FC4 (nodebug+p4+nose+nohm+lean): 269.3 4. Linux 2.6.11-1.1369_FC4 (nodebug+p4+nose+ nohm): 253.1 5. Linux 2.6.11-1.1369_FC4 (nodebug+p4): 239.4 6. Linux 2.6.11-1.1369_FC4 (nodebug): 236.7 7: Linux 2.6.11-1.1369_FC4 (orig): 213.2 8: SunOS 5.11 (orig): 122.3 (1, 2 & 3 here share the same configuration) So 2.6.12-rc6 is slightly better overall than 2.6.11.12 and still a lot faster than FC4 (especially in the syscall overhead & pipe throughput area). Am I correct in assuming the FC kernel doesn't use the vsyscall/sysenter mechanism thus taking a serious performance hit on P4s? Regards, Florin From Fedora at TQMcube.com Tue Jun 21 18:20:36 2005 From: Fedora at TQMcube.com (David Cary Hart) Date: Tue, 21 Jun 2005 14:20:36 -0400 Subject: FC4 kernel performance In-Reply-To: <20050621173932.GA30669@jadzia.bu.edu> References: <1119368638.5902.174.camel@scox.glenatl.glenayre.com> <20050621154755.GC21723@redhat.com> <1119370102.2475.37.camel@dch.TQMcube.com> <20050621173932.GA30669@jadzia.bu.edu> Message-ID: <1119378036.12067.7.camel@dch.TQMcube.com> On Tue, 2005-06-21 at 13:39 -0400, Matthew Miller wrote: > On Tue, Jun 21, 2005 at 12:08:22PM -0400, David Cary Hart wrote: > > Dave, I still wish that FC would revert to the FC3 src.rpm structure > > where the spec provided for a source rpm build. I suspect that the > > number of users who wish to customize their kernel is growing and the > > FC3 method seems much simpler (at least to me). > > This has been rehashed a zillion times, but the short answer is that it's > not really any good, since the resulting source tree isn't necessarily > "clean" for the build architecture you expect. Tweaking the source rpm is a > bit more learning and a tiny bit more work upfront, but it makes management > easier (worth sometime) and produces more correct results (priceless). Nah. The end result is the same. The difference is that making the src.rpm in FC4 creates a source tree that can be moved to /usr/src. Making the src.rpm in FC3 (with only source rpm selected in the spec) creates a source.rpm The issue is portability which is a tarball in FC4 vs an rpm in FC3. I just think that creating an rpm is more consistent with the Fedora approach. -- * Eliminate Spam: http://www.TQMcube.com/spam_trap.htm * RBLDNSD HowTo: http://www.TQMcube.com/rbldnsd.htm * Multi-RBL Check: http://www.TQMcube.com/rblcheck.htm From matthew at nocturnal.org Tue Jun 21 18:37:12 2005 From: matthew at nocturnal.org (Matthew Lenz) Date: Tue, 21 Jun 2005 13:37:12 -0500 Subject: reverted back to old browser start functionality + startup notification rant Message-ID: <1119379032.19988.18.camel@mlenzdesktop> With FC3 the launcher script would check to see if firefox was already running and if so, it would simply open a new window. Now FC4 is back to the old way where it attempts to do startup notification and hijacks the cursor with the 'hour glass' until startup notification times out. I wish I didn't feel like gnome startup notification was a huge hack, but I do (can it just be disabled?). Yet, when I click on a url in gaim, or evo it opens it properly in a new tab or window (according to my tab browser preferences). What gives? I would assume they all execute the same script right? Also is it entirely necessary for startup notification to hijack the cursor with the hourglass just because a program is starting? Is it unreasonable that i'd want to immediately go to the Applications menu and open another application while the other is loading? The 'hour glass' isn't exactly a user friendly pointing device. :) From davej at redhat.com Tue Jun 21 18:42:20 2005 From: davej at redhat.com (Dave Jones) Date: Tue, 21 Jun 2005 14:42:20 -0400 Subject: FC4 kernel performance In-Reply-To: <1119377879.5901.206.camel@scox.glenatl.glenayre.com> References: <1119377879.5901.206.camel@scox.glenatl.glenayre.com> Message-ID: <20050621184219.GA13538@redhat.com> On Tue, Jun 21, 2005 at 02:17:59PM -0400, Malita, Florin wrote: > On Tue, 2005-06-21 at 11:47 -0400, Dave Jones wrote: > > Which is an apples to oranges comparison. 2.6.11-1.1369_FC4 is > > actually based on 2.6.12rc6. I'll be interested in seeing results > > rerun against this kernel. > > Back with some apples: http://lufs.sourceforge.net/unixbench.html > > Now I have: > > 1. Linux 2.6.12-rc6 (nodebug+p4+nose+nohm+lean): 355.7 > 2. Linux 2.6.11.12 (nodebug+p4+nose+nohm+lean): 345.8 > 3. Linux 2.6.11-1.1369_FC4 (nodebug+p4+nose+nohm+lean): 269.3 > 4. Linux 2.6.11-1.1369_FC4 (nodebug+p4+nose+ nohm): 253.1 > 5. Linux 2.6.11-1.1369_FC4 (nodebug+p4): 239.4 > 6. Linux 2.6.11-1.1369_FC4 (nodebug): 236.7 > 7: Linux 2.6.11-1.1369_FC4 (orig): 213.2 > 8: SunOS 5.11 (orig): 122.3 > > (1, 2 & 3 here share the same configuration) > > So 2.6.12-rc6 is slightly better overall than 2.6.11.12 and still a lot > faster than FC4 (especially in the syscall overhead & pipe throughput > area). Thanks, I'll take a look at this later. > Am I correct in assuming the FC kernel doesn't use the vsyscall/sysenter > mechanism thus taking a serious performance hit on P4s? Correct. (Unless you have a CPU with NX). I think we'd also be able to reenable sysenter if we booted with exec_sheild=0, but currently we don't handle that case (we just always disable if no NX present) Dave From davej at redhat.com Tue Jun 21 19:00:16 2005 From: davej at redhat.com (Dave Jones) Date: Tue, 21 Jun 2005 15:00:16 -0400 Subject: Enable Default CONFIG_IP6_NF_QUEUE? In-Reply-To: <200506211746.j5LHk2QB012489@s2.itd.nrl.navy.mil> References: <200506211746.j5LHk2QB012489@s2.itd.nrl.navy.mil> Message-ID: <20050621190016.GB13538@redhat.com> On Tue, Jun 21, 2005 at 01:43:57PM -0400, Jeff Weston wrote: > Userspace queueuing of IPv6 packets (CONFIG_IP6_NF_QUEUE kernel option) has been significantly improved in the 2.6.12 kernel. > Userspace queueing is already enabled by default for IPv4 packets, but it does not seem to be enabled for IPv6 packets even in the > FC4 release kernel. > > Would it be possible for future Fedora updates to enable CONFIG_IP6_NF_QUEUE (as a module) by default? Fixed in CVS, will be in the next updates. thanks, Dave From jspaleta at gmail.com Tue Jun 21 19:05:10 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 21 Jun 2005 15:05:10 -0400 Subject: reverted back to old browser start functionality + startup notification rant In-Reply-To: <1119379032.19988.18.camel@mlenzdesktop> References: <1119379032.19988.18.camel@mlenzdesktop> Message-ID: <604aa79105062112057aad5094@mail.gmail.com> On 6/21/05, Matthew Lenz wrote: > What gives? I would assume they all execute > the same script right? Not...exactly. The menu item calls the htmlview shell script which in turn pulls the name of the executable to run from gconf. Reading over the htmlview script as called from the launcher all it ends up doing is calling firefox with no arguments. When called with no arguments firefox is itself choosing to open a new blank window. and the hourglass timeout happens. When htmlview called with a real url as an argument even from a launcher the firefox follows the tabbing preferences are followed... and no hourglass timeout is seen. whatever is happening is something internal to the /usr/bin/firefox script which differentiates between the case with an argument and without an argument and which is confusing the startup notification process. -jef From matthew at nocturnal.org Tue Jun 21 19:20:37 2005 From: matthew at nocturnal.org (Matthew Lenz) Date: Tue, 21 Jun 2005 14:20:37 -0500 Subject: reverted back to old browser start functionality + startup notification rant In-Reply-To: <604aa79105062112057aad5094@mail.gmail.com> References: <1119379032.19988.18.camel@mlenzdesktop> <604aa79105062112057aad5094@mail.gmail.com> Message-ID: <1119381637.19988.26.camel@mlenzdesktop> On Tue, 2005-06-21 at 15:05 -0400, Jeff Spaleta wrote: > On 6/21/05, Matthew Lenz wrote: > > What gives? I would assume they all execute > > the same script right? > Not...exactly. The menu item calls the htmlview shell script which in > turn pulls the name of the executable to run from gconf. Reading over > the htmlview script as called from the launcher all it ends up doing > is calling firefox with no arguments. > > When called with no arguments firefox is itself choosing to open a new > blank window. > and the hourglass timeout happens. > > When htmlview called with a real url as an argument even from a > launcher the firefox follows the tabbing preferences are followed... > and no hourglass timeout is seen. > > whatever is happening is something internal to the /usr/bin/firefox > script which differentiates > between the case with an argument and without an argument and which is > confusing the startup notification process. > > -jef > That may be the case.. but changing the panel icon to just call the firefox script directly (which is the same script referenced in the application prefercences) results in no startup notification. What any of that means I have no idea. All I know is its pretty unprofessional looking to have something on the desktop, that with a single click, you can expose a weakness in the way that desktop functions. :) From jspaleta at gmail.com Tue Jun 21 19:35:41 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 21 Jun 2005 15:35:41 -0400 Subject: reverted back to old browser start functionality + startup notification rant In-Reply-To: <1119381637.19988.26.camel@mlenzdesktop> References: <1119379032.19988.18.camel@mlenzdesktop> <604aa79105062112057aad5094@mail.gmail.com> <1119381637.19988.26.camel@mlenzdesktop> Message-ID: <604aa79105062112355b7cdbd9@mail.gmail.com> On 6/21/05, Matthew Lenz wrote: > All I know is its pretty unprofessional > looking to have something on the desktop, that with a single click, you > can expose a weakness in the way that desktop functions. :) Luckily its not called Fedora Core 'Professional'.. so we narrowly dodged that bullet in terms of disappointing the paying customers. Maybe on closer examination this can be resolved as an update.. once you figure out exactly what's wrong with the htmlview script. -jef From Jeffery.Weston at nrl.navy.mil Tue Jun 21 20:24:23 2005 From: Jeffery.Weston at nrl.navy.mil (Jeff Weston) Date: Tue, 21 Jun 2005 16:24:23 -0400 Subject: Enable Default CONFIG_IP6_NF_QUEUE? In-Reply-To: <20050621190016.GB13538@redhat.com> Message-ID: <200506212026.j5LKQRQD020388@s2.itd.nrl.navy.mil> Excellent! We will be looking forward to the next kernel update. Out of curiosity, will this affect FC4 only, or will the changes go into FC3 as well? Thanks again! -Jeff Weston > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com > [mailto:fedora-devel-list-bounces at redhat.com] On Behalf Of Dave Jones > Sent: Tuesday, June 21, 2005 3:00 PM > To: Development discussions related to Fedora Core > Subject: Re: Enable Default CONFIG_IP6_NF_QUEUE? > > On Tue, Jun 21, 2005 at 01:43:57PM -0400, Jeff Weston wrote: > > Userspace queueuing of IPv6 packets (CONFIG_IP6_NF_QUEUE > kernel option) has been significantly improved in the 2.6.12 kernel. > > Userspace queueing is already enabled by default for IPv4 > packets, but it does not seem to be enabled for IPv6 packets > even in the > FC4 release kernel. > > > > Would it be possible for future Fedora updates to enable > CONFIG_IP6_NF_QUEUE (as a module) by default? > > Fixed in CVS, will be in the next updates. > > thanks, > > Dave > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From davej at redhat.com Tue Jun 21 20:28:33 2005 From: davej at redhat.com (Dave Jones) Date: Tue, 21 Jun 2005 16:28:33 -0400 Subject: Enable Default CONFIG_IP6_NF_QUEUE? In-Reply-To: <200506212026.j5LKQRQD020388@s2.itd.nrl.navy.mil> References: <20050621190016.GB13538@redhat.com> <200506212026.j5LKQRQD020388@s2.itd.nrl.navy.mil> Message-ID: <20050621202832.GA22541@redhat.com> On Tue, Jun 21, 2005 at 04:24:23PM -0400, Jeff Weston wrote: > Excellent! We will be looking forward to the next kernel update. > > Out of curiosity, will this affect FC4 only, or will the changes go into FC3 as well? Yep, when I do a 2.6.12 update for FC3. (Which I'll do shortly after the FC4 update goes out). There's a few things holding up the 2,6.12 update for FC4 right now (including still being buried alive in email since my vacation last week), but hopefully I'll get something out there pretty soon. Thanks, Dave From rodd at clarkson.id.au Wed Jun 22 00:22:13 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Wed, 22 Jun 2005 10:22:13 +1000 Subject: Kolab 2 Groupware released In-Reply-To: <87y893vpc7.fsf@kosh.bigo.ensc.de> References: <87y893vpc7.fsf@kosh.bigo.ensc.de> Message-ID: <1119399733.3281.9.camel@jellyfish.redfishdemo.com> On Tue, 2005-06-21 at 14:58 +0200, Enrico Scholz wrote: > ndbecker2 at gmail.com (Neal Becker) writes: > > > http://www.kolab.org/news/pr-20050620.html > > How far are the server components (OpenLDAP, Cyrus-IMAP, Apache, ...) > patched? Or are these the default programs which are shipped by FC or FE > already? Oh, and without trying to start (the inevitable ;-]) flame-war is there any likely hood of Kolab supporting evolution (or the other way round depending on how it needs to happen). I couldn't see anything on the Kolab wiki under client support. I would guess that this would be important for Fedora as gnome is the default desktop and evolution is (as such) the default groupware client. I guess this raises the big question - is Fedora looking to include a groupware server as part of the Core packages and if so, what is being considered? Rodd -- "It's a fine line between denial and faith. It's much better on my side" From rodd at clarkson.id.au Wed Jun 22 00:46:16 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Wed, 22 Jun 2005 10:46:16 +1000 Subject: rawhide report: 20050621 changes In-Reply-To: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> Message-ID: <1119401177.3281.11.camel@jellyfish.redfishdemo.com> On Tue, 2005-06-21 at 07:02 -0400, Build System wrote: > cairo-0.5.1-1 > ------------- > * Mon Jun 20 2005 Kristian H?gsberg 0.5.1-1 > - Update to cairo 0.5.1. > - Remove gtk-doc files, since --disable-gtk-doc doesn't work. > - Disable gtk-doc and add freetype and fontconfig BuildRequires. I'm curious to know what cairo means in terms of performance for users. I've read some really good stuff about it, but it all seems to rely on "taking advantage of display hardware acceleration when available (eg. through the X Render Extension or OpenGL)" (to quote from the cairographics.org web site). What does this mean for users without hardware acceleration? What does this mean for users with NVIDIA and ATI cards who don't have support for 3D rendering because current open source drivers aren't offering support for this? Given that gtp+-2.7.x (and beyond) is going to rely on Cairo for rendering, I'd really appreciate it if someone in the know could give a heads up on what this means for all users (since most of the focus (media wise) seems to look at hardware accelerated environments). Any comments? Rodd -- "It's a fine line between denial and faith. It's much better on my side" From yusufg at outblaze.com Wed Jun 22 00:47:56 2005 From: yusufg at outblaze.com (Yusuf Goolamabbas) Date: Wed, 22 Jun 2005 08:47:56 +0800 Subject: FC4 kernel performance In-Reply-To: <1119368638.5902.174.camel@scox.glenatl.glenayre.com> References: <1119368638.5902.174.camel@scox.glenatl.glenayre.com> Message-ID: <20050622004756.GA27285@outblaze.com> > The final scores: > > 1. Linux 2.6.11.12 vanilla (nodebug+p4+nose+nohm+lean): 345.8 > 2. Linux 2.6.11-1.1369_FC4 (nodebug+p4+nose+nohm+lean): 269.3 > 3. Linux 2.6.11-1.1369_FC4 (nodebug+p4+nose+ nohm): 253.1 > 4. Linux 2.6.11-1.1369_FC4 (nodebug+p4): 239.4 > 5. Linux 2.6.11-1.1369_FC4 (nodebug): 236.7 > 6: Linux 2.6.11-1.1369_FC4 (orig): 213.2 > 7: SunOS 5.11 (orig): 122.3 SchillX is likely to default to debug mode if strings /kernel/genunix | grep 'DEBUG enabled' prints "DEBUG enabled" then it is DEBUG Maybe you could compare FC4 with Solaris 10 Express 6/05 or Solaris 10 GA Regards, Yusuf From pri.rhl4 at iadonisi.to Wed Jun 22 03:40:24 2005 From: pri.rhl4 at iadonisi.to (Paul Iadonisi) Date: Tue, 21 Jun 2005 23:40:24 -0400 Subject: Kolab 2 Groupware released In-Reply-To: <1119399733.3281.9.camel@jellyfish.redfishdemo.com> References: <87y893vpc7.fsf@kosh.bigo.ensc.de> <1119399733.3281.9.camel@jellyfish.redfishdemo.com> Message-ID: <1119411624.18680.23.camel@md.nc.linuxlobbyist.org> On Wed, 2005-06-22 at 10:22 +1000, Rodd Clarkson wrote: [snip] > Oh, and without trying to start (the inevitable ;-]) flame-war is there > any likely hood of Kolab supporting evolution (or the other way round > depending on how it needs to happen). > > I couldn't see anything on the Kolab wiki under client support. > > I would guess that this would be important for Fedora as gnome is the > default desktop and evolution is (as such) the default groupware client. > > I guess this raises the big question - is Fedora looking to include a > groupware server as part of the Core packages and if so, what is being > considered? I believe it was discussed some time ago, but no consensus was really reached, though I think there was a slight leaning towards OpenGroupware. One thing I think there *was* a consensus on at the time is the *none* of the FOSS groupware servers were really ready for prime time. Or even for Fedora Core time ;-). The situation may now be different. I don't know, it's been a while since I've looked at any of them. But unless Kolab has moved more towards standardized operation (i.e.: no weird hacked usage of IMAP folders, or something like that, I can't member), then I'd lean heavily away from it. In most cases, I'd say it would be alright to include two suites that do similar things in Extras, but if they are BIG (like OpenGroupware), then I'd hesitate. Still, I wouldn't oppose both (or more?) being included in Extras. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From kewley at gps.caltech.edu Wed Jun 22 04:20:41 2005 From: kewley at gps.caltech.edu (David Kewley) Date: Tue, 21 Jun 2005 21:20:41 -0700 Subject: debuginfo Message-ID: <200506212120.41158.kewley@gps.caltech.edu> Some debuginfo rpms have snuck into updates-released. Sneaky sneakers... Speaking of debuginfo, is the idea of keeping them *out* of repos that if you want to debug, then you need to rebuild & install your own-built debuginfo package? David From byte at aeon.com.my Wed Jun 22 04:22:27 2005 From: byte at aeon.com.my (Colin Charles) Date: Wed, 22 Jun 2005 14:22:27 +1000 Subject: FC4 and G5 In-Reply-To: <42B2B44B.9050809@redhat.com> References: <42B2B44B.9050809@redhat.com> Message-ID: <1119414147.23117.28.camel@arena.soho.bytebot.net> On Fri, 2005-06-17 at 17:00 +0530, Rahul Sundaram wrote: > >Moreover, pushing the TAB button (tab completion in shell at the > console) > >results in a scrolling screen and the above error at once. > >What's this? > > > >Zoltan > > > > > > > There seems to be a few regressions in the final release which was > working better in FC4test3 for the PPC architecture. This is > probably > one of them. Put them in bugzilla as you come across these Best discussed on fedora-ppc at lists.infradead.org (and there's a little archive of discussion about this on the iMac G5) Is the video card a radeon? Bugzilla it, but also try: "linux video=ofonly" or even offb to see if you get much further -- Colin Charles, http://www.bytebot.net/ FUDCon II @ LinuxTag June 24-25, 2005 in Karlsruhe, Germany http://fedoraproject.com/fudcon/ From mpeters at mac.com Wed Jun 22 04:35:42 2005 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 21 Jun 2005 21:35:42 -0700 Subject: debuginfo In-Reply-To: <200506212120.41158.kewley@gps.caltech.edu> References: <200506212120.41158.kewley@gps.caltech.edu> Message-ID: <1119414942.3109.132.camel@locolhost.localdomain> On Tue, 2005-06-21 at 21:20 -0700, David Kewley wrote: > Some debuginfo rpms have snuck into updates-released. Sneaky > sneakers... > > Speaking of debuginfo, is the idea of keeping them *out* of repos that > if you want to debug, then you need to rebuild & install your own-built > debuginfo package? No - I've been specifically asked to install them when reporting a bug. I think the idea is to not have yum have to chew so hard on headers for packages that are only needed when something goes wrong. From skvidal at phy.duke.edu Wed Jun 22 04:40:23 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 22 Jun 2005 00:40:23 -0400 Subject: debuginfo In-Reply-To: <1119414942.3109.132.camel@locolhost.localdomain> References: <200506212120.41158.kewley@gps.caltech.edu> <1119414942.3109.132.camel@locolhost.localdomain> Message-ID: <1119415223.3031.47.camel@cutter> On Tue, 2005-06-21 at 21:35 -0700, Michael A. Peters wrote: > On Tue, 2005-06-21 at 21:20 -0700, David Kewley wrote: > > Some debuginfo rpms have snuck into updates-released. Sneaky > > sneakers... > > > > Speaking of debuginfo, is the idea of keeping them *out* of repos that > > if you want to debug, then you need to rebuild & install your own-built > > debuginfo package? > > No - I've been specifically asked to install them when reporting a bug. > I think the idea is to not have yum have to chew so hard on headers for > packages that are only needed when something goes wrong. yum doesn't read the headers for every package anymore. but by taking the debuginfo packages out and putting them in their own repo we make the xml smaller. -sv From kewley at gps.caltech.edu Wed Jun 22 05:04:11 2005 From: kewley at gps.caltech.edu (David Kewley) Date: Tue, 21 Jun 2005 22:04:11 -0700 Subject: debuginfo In-Reply-To: <1119415223.3031.47.camel@cutter> References: <200506212120.41158.kewley@gps.caltech.edu> <1119414942.3109.132.camel@locolhost.localdomain> <1119415223.3031.47.camel@cutter> Message-ID: <200506212204.11596.kewley@gps.caltech.edu> On Tuesday 21 June 2005 21:40, seth vidal wrote: > On Tue, 2005-06-21 at 21:35 -0700, Michael A. Peters wrote: > > On Tue, 2005-06-21 at 21:20 -0700, David Kewley wrote: > > > Some debuginfo rpms have snuck into updates-released. Sneaky > > > sneakers... > > > > > > Speaking of debuginfo, is the idea of keeping them *out* of repos > > > that if you want to debug, then you need to rebuild & install > > > your own-built debuginfo package? > > > > No - I've been specifically asked to install them when reporting a > > bug. I think the idea is to not have yum have to chew so hard on > > headers for packages that are only needed when something goes > > wrong. > > yum doesn't read the headers for every package anymore. > > but by taking the debuginfo packages out and putting them in their > own repo we make the xml smaller. Aha. Our local mirror doesn't sync the debug/ directory, so I had missed it. (I just looked at download.fedora.redhat.com to see the canonical structure.) It looks like something got out of sync on ourlocal mirror, because yum is reporting some debuginfo packages as being available even though they aren't actually in the repo. Disregard my original complaint about sneakiness -- it's a local mirror problem I believe. David From byte at aeon.com.my Wed Jun 22 06:28:08 2005 From: byte at aeon.com.my (Colin Charles) Date: Wed, 22 Jun 2005 16:28:08 +1000 Subject: Any way to run UML kernel under FC4? In-Reply-To: <1119179539.11934.8.camel@ignacio.ignacio.lan> References: <20050619093304.GB3302@stingr.stingr.net> <1119179539.11934.8.camel@ignacio.ignacio.lan> Message-ID: <1119421688.23117.40.camel@arena.soho.bytebot.net> On Sun, 2005-06-19 at 07:12 -0400, Ignacio Vazquez-Abrams wrote: > > Never thought I'll need that, but ... Is there any way to run UML > > kernels on an unmodified fedora system (with standard kernel rpms)? > > Why would you want to when you can run Xen? > > http://www.fedoraproject.org/wiki/FedoraXenQuickstart Because maybe he runs an x86_64 or a PPC based system ? -- Colin Charles, http://www.bytebot.net/ FUDCon II @ LinuxTag June 24-25, 2005 in Karlsruhe, Germany http://fedoraproject.com/fudcon/ From tarjei.knapstad at predichem.com Wed Jun 22 08:26:11 2005 From: tarjei.knapstad at predichem.com (Tarjei Knapstad) Date: Wed, 22 Jun 2005 10:26:11 +0200 Subject: Cairo [was: rawhide report: 20050621 changes] In-Reply-To: <1119401177.3281.11.camel@jellyfish.redfishdemo.com> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> Message-ID: <1119428771.27240.113.camel@tarjei.predichem.nett> On Wed, 2005-06-22 at 02:46, Rodd Clarkson wrote: > On Tue, 2005-06-21 at 07:02 -0400, Build System wrote: > > > cairo-0.5.1-1 > > ------------- > > * Mon Jun 20 2005 Kristian H?gsberg 0.5.1-1 > > - Update to cairo 0.5.1. > > - Remove gtk-doc files, since --disable-gtk-doc doesn't work. > > - Disable gtk-doc and add freetype and fontconfig BuildRequires. > > I'm curious to know what cairo means in terms of performance for users. > > I've read some really good stuff about it, but it all seems to rely on > "taking advantage of display hardware acceleration when available (eg. > through the X Render Extension or OpenGL)" (to quote from the > cairographics.org web site). > > What does this mean for users without hardware acceleration? > What does this mean for users with NVIDIA and ATI cards who don't have > support for 3D rendering because current open source drivers aren't > offering support for this? > It means you won't get accelerated graphics :) I think the whole point of Cairo is that it's a common graphics framework with multiple backends. If your application renders graphics using Cairo you automatically get support for rendering to: * The X window system * OpenGL * The Win32 API * Postscript * PDF * SVG * etc... So in theory at least it's a graphics portability layer. You can build your application for windows just by selecting Win32 rendering, users will get hardware accelerated output if they have support for it or normal X rendering if not and so forth. Implementing printing and PS/PDF output is also a breeze for the application developer as he/she can just render using these backends. Correct me if I'm wrong, but I think this is what Cairo is meant for - fast vector graphics with multiple backends making life easier for application developers, and life faster for users with hardware accelerated graphics. Those without it shouldn't notice any difference. -- Tarjei From mikem at cyber.com.au Wed Jun 22 08:38:18 2005 From: mikem at cyber.com.au (Mike MacCana) Date: Wed, 22 Jun 2005 18:38:18 +1000 Subject: Attention / Interest / Desire / Action, getfedora.org, or why marketing 'the Fedora project' is a bad idea. In-Reply-To: <1119411871.23117.20.camel@arena.soho.bytebot.net> References: <1119080735.5189.22.camel@localhost.localdomain> <42B40337.3050705@cyber.com.au> <1119096176.7160.70.camel@cutter> <42B412C1.6050002@cyber.com.au> <1119149184.3559.270.camel@arena.soho.bytebot.net> <1119271641.3027.5.camel@localhost.localdomain> <1119411871.23117.20.camel@arena.soho.bytebot.net> Message-ID: <1119429498.2340.12.camel@localhost.localdomain> On Wed, 2005-06-22 at 13:44 +1000, Colin Charles wrote: > On Mon, 2005-06-20 at 22:47 +1000, Mike MacCana wrote: > > > > >Based on the questions I get from folks about how to contribute, > > I'm > > > > >fairly certain you're very wrong. > > > > > > > > > Really? You think more people want to contribute to Fedora than to > > use > > > > it? > > > > > > Yes, they do. > > > > !!! > > > > Could you please explain how? > > > > Do you not believe that there are users who don't contribute? > > Yes, because: My question was confusing, and you didn't answer it correctly. Obviously it's clear that you do believe there are users who don't contribute. And that, hence, there will always be more users than contributors. > > Do you think there are people who contribute but somehow don't use? > > That too. People use Windows during the day, and at night, might have 2 > hours to work with Fedora checking their mail. Then they use Fedora. That they also use Windows or FreeBSD is irrelevant. So the point remains: - There will always be more users than contributors - Getting more users has many benefits, most of which are obvious, including that contributors feel more enthusiastic working on a popular project. Mike From mikem at cyber.com.au Wed Jun 22 08:49:58 2005 From: mikem at cyber.com.au (Mike MacCana) Date: Wed, 22 Jun 2005 18:49:58 +1000 Subject: Single sign-on infrastructure (FC5 wish) In-Reply-To: References: <42B3B097.7060109@develer.com> <1119347933.3843.70.camel@endor.e.kth.se> Message-ID: <1119430199.2340.19.camel@localhost.localdomain> On Tue, 2005-06-21 at 10:11 -0500, Jason L Tibbitts III wrote: > >>>>> "AB" == Alexander Bostr?m writes: > > AB> I don't know how that works but I must say I'm very sceptical, > AB> mostly from a security standpoint. What's the advantage of doing > AB> it that way? > > A single replication infrastructure. I use the MIT KDC because it's > what Red Hat happens to ship, but I'd much rather have everything in > LDAP instead of having two separate systems to configure and maintain. So Heimdal can use an LDAP data store? Sweet. Thanks so much for your post. I've wanted MIT krb5 to do this (in a non hacky way) for ages. Can Heimdal do Kerberos over TCP, and does it support MS specific encryption types, like MIT Kerberos does? Mike From abo at kth.se Wed Jun 22 09:48:24 2005 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Wed, 22 Jun 2005 11:48:24 +0200 Subject: Single sign-on infrastructure (FC5 wish) In-Reply-To: References: <42B3B097.7060109@develer.com> <1119347933.3843.70.camel@endor.e.kth.se> Message-ID: <1119433704.3843.82.camel@endor.e.kth.se> tis 2005-06-21 klockan 10:11 -0500 skrev Jason L Tibbitts III: > A single replication infrastructure. I use the MIT KDC because it's > what Red Hat happens to ship, but I'd much rather have everything in > LDAP instead of having two separate systems to configure and maintain. You'd still need as many servers and services, but add more dependencies between them, right? Anyway, I'm not sure that I'm the right person and this is the right place to discuss this, but lets just say that in the unlikely(?) event that Fedora would actually include Heimdal, enabling the LDAP backend by default should not be done without careful consideration. /abo From tjarls at iee.lu Wed Jun 22 10:13:15 2005 From: tjarls at iee.lu (Charles Lopes) Date: Wed, 22 Jun 2005 12:13:15 +0200 Subject: Single sign-on infrastructure (FC5 wish) In-Reply-To: <1119430199.2340.19.camel@localhost.localdomain> References: <42B3B097.7060109@develer.com> <1119347933.3843.70.camel@endor.e.kth.se> <1119430199.2340.19.camel@localhost.localdomain> Message-ID: <42B939BB.2090603@iee.lu> Mike MacCana wrote: >On Tue, 2005-06-21 at 10:11 -0500, Jason L Tibbitts III wrote: > > >>>>>>>"AB" == Alexander Bostr?m writes: >>>>>>> >>>>>>> >>AB> I don't know how that works but I must say I'm very sceptical, >>AB> mostly from a security standpoint. What's the advantage of doing >>AB> it that way? >> >>A single replication infrastructure. I use the MIT KDC because it's >>what Red Hat happens to ship, but I'd much rather have everything in >>LDAP instead of having two separate systems to configure and maintain. >> >> > >So Heimdal can use an LDAP data store? Sweet. Thanks so much for your >post. > >I've wanted MIT krb5 to do this (in a non hacky way) for ages. > > > A data abstraction layer (DAL) patch that does just that has been just been committed to the cvs of MIT KDC. >Can Heimdal do Kerberos over TCP, and does it support MS specific >encryption types, like MIT Kerberos does? > > Quoted from heimdal.info: >Encryption types >================ > >Windows 2000 supports both the standard DES encryptions (des-cbc-crc and >des-cbc-md5) and its own proprietary encryption that is based on MD4 and >rc4 that is documented in and is supposed to be described in >`draft-brezak-win2k-krb-rc4-hmac-03.txt'. New users will get both MD4 >and DES keys. Users that are converted from a NT4 database, will only >have MD4 passwords and will need a password change to get a DES key. > >Heimdal implements both of these encryption types, but since DES is the >standard and the hmac-code is somewhat newer, it is likely to work >better. > > Also I believe heimdal can (or will be able to) use the LDAP attribute "sambaNTPassword" as a arcfour-hmac-md5 kerberos key. I haven't tried MIT KDC+DAL (or heimdal for that matter) but I guess that the raison d'?tre of DAL being its possible use alongside future versions of samba, it's likely to support the same feature. In a related note, my hardest headache is renewing keys for users that have home directories access via NFS4+krb5. We could not get "gnome-kerberos" or "xscreensaver" to do it, so we keep a terminal window open so that kinit can be run there. Am I missing something? Also is the new kernel keyring facility planned for FC5 inclusion? From m.f.h at web.de Wed Jun 22 11:26:02 2005 From: m.f.h at web.de (Marcus Hartig) Date: Wed, 22 Jun 2005 13:26:02 +0200 Subject: FC4 kernel performance Message-ID: <42B94ACA.5090008@web.de> Matthew Lenz wrote: > I've noticed a considerable slowdown in performance over FC3 across > the board. Applications take longer to launch. I/O seems to have a > much more adverse affect on system response. I?ve noticed this slowdown, too. Very good with hdparm. On my 2 systems a Athlon64 PC and a new Inspiron notebook. That?s why I?m not more using the slower default kernel for months. There are too much unneeded things and too many server features compiled in, which are more for a server and not for my notebook/PC. Which really not needs Debugging, SELinux, RAID, 20 security features,.... No normal desktop user needs it. My girl not, my neighbour not, my best friends not, all are running a Fedora installed from me. And thats the point. One kernel for the desktop and one for all server users, which you select at the installation or later. Is that too much? And we never get these "slow Fedora kernel questions" again... ;) Regards, Marcus From peter.backlund at home.se Wed Jun 22 11:41:37 2005 From: peter.backlund at home.se (Peter Backlund) Date: Wed, 22 Jun 2005 13:41:37 +0200 Subject: FC4 kernel performance In-Reply-To: <42B94ACA.5090008@web.de> References: <42B94ACA.5090008@web.de> Message-ID: <1119440497.5712.54.camel@localhost.localdomain> ons 2005-06-22 klockan 13:26 +0200 skrev Marcus Hartig: > the slower default kernel for months. There are too much unneeded things > and too many server features compiled in, which are more for a server > and not for my notebook/PC. Which really not needs Debugging, SELinux, > RAID, 20 security features,.... The debugging should be taken out of the release kernels, yes. But RAID support is modularized, and I'd imagine that the SELinux overhead is incredibly small when it's turned off. The same goes for exec-shield. I don't really know what the other 19 security features are though :-) > > And thats the point. One kernel for the desktop and one for all server > users, which you select at the installation or later. Is that too much? > And we never get these "slow Fedora kernel questions" again... ;) That means six extra kernels to support, build, debug, and handle external modules for: {i586,i686,ppc} X {UP,SMP}. Take a look at this page: http://apt.bea.ki.se/kernel-desktop/ Some dude builds FC kernels (only 2 and 3 right now) with various desktop tweaks. /Peter Backlund From mattdm at mattdm.org Wed Jun 22 12:23:10 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 22 Jun 2005 08:23:10 -0400 Subject: FC4 kernel performance In-Reply-To: <42B94ACA.5090008@web.de> References: <42B94ACA.5090008@web.de> Message-ID: <20050622122310.GA8691@jadzia.bu.edu> On Wed, Jun 22, 2005 at 01:26:02PM +0200, Marcus Hartig wrote: > and too many server features compiled in, which are more for a server > and not for my notebook/PC. Which really not needs Debugging, SELinux, > RAID, 20 security features,.... No normal desktop user needs it. My girl > not, my neighbour not, my best friends not, all are running a Fedora > installed from me. These people *do* need the security features. You want Linux to end up like Windows, with a virus/spyware infection the *norm*? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 80 degrees Fahrenheit. From shiva at sewingwitch.com Wed Jun 22 12:33:13 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 22 Jun 2005 05:33:13 -0700 Subject: Cairo [was: rawhide report: 20050621 changes] In-Reply-To: <1119428771.27240.113.camel@tarjei.predichem.nett> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> <1119428771.27240.113.camel@tarjei.predichem.nett> Message-ID: <4CCB3B994731CACE3F33B335@[10.0.0.14]> --On Wednesday, June 22, 2005 10:26 AM +0200 Tarjei Knapstad wrote: > I think the whole point of Cairo is that it's a common graphics > framework with multiple backends. If your application renders graphics > using Cairo you automatically get support for rendering to: > > * The X window system > * OpenGL > * The Win32 API > * Postscript > * PDF > * SVG > * etc... This will also be good for rendering within first-person games. Once Mozilla with the Cairo back end is available, we can put web browsers up on walls in the virtual environment. Remember those computer consoles in Doom 3 that had not much more than on/off buttons? Well, now we can make them "real" full-featured consoles! Just render to a chunk of texture memory and then paint it onto the polygon representing the in-game screen. From rodd at clarkson.id.au Wed Jun 22 12:40:32 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Wed, 22 Jun 2005 22:40:32 +1000 Subject: Cairo [was: rawhide report: 20050621 changes] In-Reply-To: <1119428771.27240.113.camel@tarjei.predichem.nett> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> <1119428771.27240.113.camel@tarjei.predichem.nett> Message-ID: <1119444032.3335.14.camel@goose> On Wed, 2005-06-22 at 10:26 +0200, Tarjei Knapstad wrote: > On Wed, 2005-06-22 at 02:46, Rodd Clarkson wrote: > > On Tue, 2005-06-21 at 07:02 -0400, Build System wrote: > > What does this mean for users without hardware acceleration? > > What does this mean for users with NVIDIA and ATI cards who don't have > > support for 3D rendering because current open source drivers aren't > > offering support for this? > It means you won't get accelerated graphics :) > > I think the whole point of Cairo is that it's a common graphics > framework with multiple backends. If your application renders graphics > using Cairo you automatically get support for rendering to: > > * The X window system > * OpenGL > * The Win32 API > * Postscript > * PDF > * SVG > * etc... > > So in theory at least it's a graphics portability layer. You can build > your application for windows just by selecting Win32 rendering, users > will get hardware accelerated output if they have support for it or > normal X rendering if not and so forth. Implementing printing and PS/PDF > output is also a breeze for the application developer as he/she can just > render using these backends. > > Correct me if I'm wrong, but I think this is what Cairo is meant for - > fast vector graphics with multiple backends making life easier for > application developers, and life faster for users with hardware > accelerated graphics. Those without it shouldn't notice any difference. Don't get me wrong (and I'm not sure if you have). I think Cairo is a wonderful idea and I'm really looking forward to seeing what people do with it. What I'm wanting to know is will people without hardware acceleration be worse off. Are non-hw-accelerated users going to end up with a system that runs something like non-hw-accelerated 3D (which really sucks, even with a good processor)? Or will the rendering on non-hw-accelerated systems be quite good, and rendering with hw-accelerated systems will be brilliant? regards R. -- "It's a fine line between denial and faith. It's much better on my side" From jspaleta at gmail.com Wed Jun 22 12:41:42 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 22 Jun 2005 08:41:42 -0400 Subject: Cairo [was: rawhide report: 20050621 changes] In-Reply-To: <1119428771.27240.113.camel@tarjei.predichem.nett> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> <1119428771.27240.113.camel@tarjei.predichem.nett> Message-ID: <604aa791050622054157a6fc07@mail.gmail.com> On 6/22/05, Tarjei Knapstad wrote: > Those without it shouldn't notice any difference. Actually... they might still see a benefit. Right now in rawhide.. cairo is being used by poppler.. which is being used by evince. People without accelerated hardware might see some performance benefits with the new cairo support compared to previous releases of poppler. -jef From ph18 at cornell.edu Wed Jun 22 12:53:10 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Wed, 22 Jun 2005 08:53:10 -0400 Subject: FC4 kernel performance In-Reply-To: <20050622122310.GA8691@jadzia.bu.edu> References: <42B94ACA.5090008@web.de> <20050622122310.GA8691@jadzia.bu.edu> Message-ID: <42B95F36.5010301@cornell.edu> Matthew Miller wrote: > >These people *do* need the security features. You want Linux to end up like >Windows, with a virus/spyware infection the *norm*? > > It's not so clear that SELinux helps much against real attacks. It would take a much tougher security model than the Unix model or even the SELinux model to stop the virus and zombie infections that we're seeing in the Windows world. Things like NX that prevent or complicate buffer overflow attacks may be more useful. If, for instance, I can find a way to execute arbitrary code in Firefox or Thunderbird, I can install something on your computer that runs as you. It can perpetuate itself by putting itself in your .profile or in a cron job. It can make socket connections to anywhere, and accept socket connections, so long as the port number is >1024. This process can send spam, do network scanning, try to infect other machines, install a keystroke logger, let me look through your personal files (and other people's files if the permissions are permissive,) and do plenty of other things. Root access would be nice -- that would let me run a packet sniffer, install a root kit, and generally make it a lot harder to clean up the mess, but modern crackers (who are attacking networks, not individual computers) don't need it. From tiemann at redhat.com Wed Jun 22 12:59:26 2005 From: tiemann at redhat.com (Michael Tiemann) Date: Wed, 22 Jun 2005 08:59:26 -0400 Subject: FC4 kernel performance In-Reply-To: <42B95F36.5010301@cornell.edu> References: <42B94ACA.5090008@web.de> <20050622122310.GA8691@jadzia.bu.edu> <42B95F36.5010301@cornell.edu> Message-ID: <1119445167.9745.4.camel@localhost.localdomain> On Wed, 2005-06-22 at 08:53 -0400, Paul A Houle wrote: [...] > It's not so clear that SELinux helps much against real attacks. It > would take a much tougher security model than the Unix model or even the > SELinux model to stop the virus and zombie infections that we're seeing > in the Windows world. Things like NX that prevent or complicate buffer > overflow attacks may be more useful. > [...] > > Root access would be nice -- that would let me run a packet > sniffer, install a root kit, and generally make it a lot harder to > clean up the mess, but modern crackers (who are attacking networks, > not individual computers) don't need it. Paul, there are several SE Linux machines on the internet that offer you root access. Please be the first to demonstrate that you can crack them. That way we can make them better... M From fedora at camperquake.de Wed Jun 22 12:59:38 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 22 Jun 2005 14:59:38 +0200 Subject: Cairo [was: rawhide report: 20050621 changes] In-Reply-To: <604aa791050622054157a6fc07@mail.gmail.com> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> <1119428771.27240.113.camel@tarjei.predichem.nett> <604aa791050622054157a6fc07@mail.gmail.com> Message-ID: <20050622145938.65d84544@nausicaa.camperquake.de> Hi. Jeff Spaleta wrote: > People without accelerated hardware might see some performance > benefits with the new cairo support compared to previous releases of > poppler. Are you sure you wanted to say that? -- "I propose we leave math to the machines and go play outside." -- Calvin From ph18 at cornell.edu Wed Jun 22 13:01:59 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Wed, 22 Jun 2005 09:01:59 -0400 Subject: FC4 kernel performance In-Reply-To: <1119440497.5712.54.camel@localhost.localdomain> References: <42B94ACA.5090008@web.de> <1119440497.5712.54.camel@localhost.localdomain> Message-ID: <42B96147.8040102@cornell.edu> Peter Backlund wrote: > >The debugging should be taken out of the release kernels, yes. But RAID >support is modularized, and I'd imagine that the SELinux overhead is >incredibly small when it's turned off. The same goes for exec-shield. I >don't really know what the other 19 security features are >though :-) > > > I run RAID 1 on my Linux machines at home. Perhaps Seagate is benefitting from my bad experiences with 1999-2001 vintage Maxtor drives, but it's cheap protection from problems that can waste a lot of time. (As compared to $700 tape backup drive that needs $250 worth of tapes to back up a $100 drive and takes an hour to do it.) RAID 1 speeds up the boot process considerably and helps with random access read I/O, which gives a noticable performance boost for ordinary desktop tasks; I know PC enthusiasts who swear by RAID 0 for pure performance aspects... One of these days I'm going to build a RAID 0+1 machine for database work. From jspaleta at gmail.com Wed Jun 22 13:08:06 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 22 Jun 2005 09:08:06 -0400 Subject: Cairo [was: rawhide report: 20050621 changes] In-Reply-To: <20050622145938.65d84544@nausicaa.camperquake.de> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> <1119428771.27240.113.camel@tarjei.predichem.nett> <604aa791050622054157a6fc07@mail.gmail.com> <20050622145938.65d84544@nausicaa.camperquake.de> Message-ID: <604aa7910506220608654697da@mail.gmail.com> On 6/22/05, Ralf Ertzinger wrote: > Are you sure you wanted to say that? i said "might" ... the point is... all this navel-gazing speculation about what cairo means for people is just wasteful. cairo is being used in the tree. All this hand-wringing about the future is pathetic. The future is NOW! If anyone is really concerned they can try to eek out real performance numbers with evince using 200 meg pathelogical pdfs that were performance problems previously in other applications. I will however burn anyone to the ground who tries to pass off it "feels" faster/slower when I open a 2 page text only pdf.. as a performance measurement that matters at all. I'm personally not that concerned. -jef From nicolas.mailhot at laposte.net Wed Jun 22 13:14:32 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 22 Jun 2005 15:14:32 +0200 (CEST) Subject: FC4 kernel performance In-Reply-To: <42B96147.8040102@cornell.edu> References: <42B94ACA.5090008@web.de> <1119440497.5712.54.camel@localhost.localdomain> <42B96147.8040102@cornell.edu> Message-ID: <64458.192.54.193.35.1119446072.squirrel@rousalka.dyndns.org> On Mer 22 juin 2005 15:01, Paul A Houle wrote: > Peter Backlund wrote: > >> >>The debugging should be taken out of the release kernels, yes. But RAID >>support is modularized, and I'd imagine that the SELinux overhead is >>incredibly small when it's turned off. The same goes for exec-shield. I >>don't really know what the other 19 security features are >>though :-) >> >> >> > I run RAID 1 on my Linux machines at home. Same here - skimming on raid on a linux setup nowadays is plain stupid IMHO, even if you have absolutely no data you wish to preserve just avoiding to reinstall and reconfigure everything when a drive dies is well worth it. -- Nicolas Mailhot From jspaleta at gmail.com Wed Jun 22 13:16:14 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 22 Jun 2005 09:16:14 -0400 Subject: FC4 kernel performance In-Reply-To: <42B95F36.5010301@cornell.edu> References: <42B94ACA.5090008@web.de> <20050622122310.GA8691@jadzia.bu.edu> <42B95F36.5010301@cornell.edu> Message-ID: <604aa791050622061659b43a91@mail.gmail.com> On 6/22/05, Paul A Houle wrote: > It's not so clear that SELinux helps much against real attacks. It > would take a much tougher security model than the Unix model or even the > SELinux model to stop the virus and zombie infections that we're seeing > in the Windows world. Things like NX that prevent or complicate buffer > overflow attacks may be more useful. > > If, for instance, I can find a way to execute arbitrary code in > Firefox or Thunderbird, I can install something on your computer that > runs as you. It can perpetuate itself by putting itself in your > .profile or in a cron job. It can make socket connections to anywhere, > and accept socket connections, so long as the port number is >1024. > This process can send spam, do network scanning, try to infect other > machines, install a keystroke logger, let me look through your > personal files (and other people's files if the permissions are > permissive,) and do plenty of other things. I think there is a misunderstanding as to the full capabilities of selinux can do as compared to the limited set of protections provided in the current default targetted policy. I'm pretty sure that selinux can stop the attack vectors you mention here if selinux policy is constructed accordingly. -jef From sds at tycho.nsa.gov Wed Jun 22 13:16:02 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 22 Jun 2005 09:16:02 -0400 Subject: FC4 kernel performance In-Reply-To: <42B95F36.5010301@cornell.edu> References: <42B94ACA.5090008@web.de> <20050622122310.GA8691@jadzia.bu.edu> <42B95F36.5010301@cornell.edu> Message-ID: <1119446162.13181.29.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2005-06-22 at 08:53 -0400, Paul A Houle wrote: > It's not so clear that SELinux helps much against real attacks. It > would take a much tougher security model than the Unix model or even the > SELinux model to stop the virus and zombie infections that we're seeing > in the Windows world. Things like NX that prevent or complicate buffer > overflow attacks may be more useful. Actually, the SELinux model (or more generally, flexible mandatory access control) is precisely what one needs in order to contain malicious and flawed applications. And SELinux can also help reinforce mehcanisms like exec-shield by providing policy control over what applications can generate runtime code. > If, for instance, I can find a way to execute arbitrary code in > Firefox or Thunderbird, I can install something on your computer that > runs as you. But with SELinux, that application (firefox or thunderbird or whatever) can be placed in its own security domain, with its own set of permissions that are a subset of the user's overall permissions. There is admittedly a lot of work to do to properly secure the desktop (e.g. security-enhanced X, which has been implemented but not yet upstreamed), but mandatory access control is the right mechanism for dealing with this issue. > It can perpetuate itself by putting itself in your > .profile or in a cron job. It can make socket connections to anywhere, > and accept socket connections, so long as the port number is >1024. > This process can send spam, do network scanning, try to infect other > machines, install a keystroke logger, let me look through your > personal files (and other people's files if the permissions are > permissive,) and do plenty of other things. Again, with SELinux, those applications can be limited to accessing no more than what they need for their legitimate purpose, including file accesses, the ability to bind to local ports, the ability to make outbound connections to particular ports, etc. > Root access would be nice -- that would let me run a packet > sniffer, install a root kit, and generally make it a lot harder to > clean up the mess, but modern crackers (who are attacking networks, > not individual computers) don't need it. Yes, Colin Walter's talk at the SELinux Symposium (see selinux-symposium.org) noted that an attacker often just wants access to the user's account and data. But SELinux can be used to counter this threat (with further work in the desktop to extend MAC to appropriate applications). -- Stephen Smalley National Security Agency From peter.backlund at home.se Wed Jun 22 13:27:48 2005 From: peter.backlund at home.se (Peter Backlund) Date: Wed, 22 Jun 2005 15:27:48 +0200 Subject: FC4 kernel performance In-Reply-To: <42B96147.8040102@cornell.edu> References: <42B94ACA.5090008@web.de> <1119440497.5712.54.camel@localhost.localdomain> <42B96147.8040102@cornell.edu> Message-ID: <1119446868.5712.56.camel@localhost.localdomain> ons 2005-06-22 klockan 09:01 -0400 skrev Paul A Houle: > Peter Backlund wrote: > > > > >The debugging should be taken out of the release kernels, yes. But RAID > >support is modularized, and I'd imagine that the SELinux overhead is > >incredibly small when it's turned off. The same goes for exec-shield. I > >don't really know what the other 19 security features are > >though :-) > > > > > > > I run RAID 1 on my Linux machines at home. Perhaps Seagate is > benefitting from my bad experiences with 1999-2001 vintage Maxtor > drives, but it's cheap protection from problems that can waste a lot of > time. (As compared to $700 tape backup drive that needs $250 worth of > tapes to back up a $100 drive and takes an hour to do it.) > > RAID 1 speeds up the boot process considerably and helps with random > access read I/O, which gives a noticable performance boost for ordinary > desktop tasks; I know PC enthusiasts who swear by RAID 0 for pure > performance aspects... One of these days I'm going to build a RAID 0+1 > machine for database work. Hmm...note that I didn't suggest that RAID was not useful for desktop users. I merely stated that RAID support is built as modules, and therefore does not have any effect on kernel performance when they are not loaded. The reply makes more sense to the original posting, but maybe that was the intention? /Peter From jfontain at free.fr Wed Jun 22 13:33:32 2005 From: jfontain at free.fr (jfontain at free.fr) Date: Wed, 22 Jun 2005 15:33:32 +0200 Subject: FC4 network slow? Message-ID: <1119447212.42b968acedbe7@imp3-q.free.fr> Hello, I just need a little advice for debugging this problem: on a rather old laptop with a xircom pcmcia card, network file transfers are extremely slow (via nfs or cifs mounts, top giving more than 90% wait states all the time), whereas the same machine booted on knoppix (3.7, kernel 2.6.9) works just fine. I tried the latest FC4 2.6.11 and FC5 2.6.12 development kernels without success... Any ideas? Many thanks in advance, -- Jean-Luc From gmaxwell at gmail.com Wed Jun 22 13:40:36 2005 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Wed, 22 Jun 2005 09:40:36 -0400 Subject: FC4 kernel performance In-Reply-To: <64458.192.54.193.35.1119446072.squirrel@rousalka.dyndns.org> References: <42B94ACA.5090008@web.de> <1119440497.5712.54.camel@localhost.localdomain> <42B96147.8040102@cornell.edu> <64458.192.54.193.35.1119446072.squirrel@rousalka.dyndns.org> Message-ID: On 6/22/05, Nicolas Mailhot wrote: > Same here - skimming on raid on a linux setup nowadays is plain stupid > IMHO, even if you have absolutely no data you wish to preserve just > avoiding to reinstall and reconfigure everything when a drive dies is well > worth it. This isn't completely true. As it stands linux raid currently lowers the reliability of the system. This is because a single bad sector will take a drive offline. In the process of trying to resync the offlined drive, the other drive(s) will encounter a bad sector and come offline. You end up with the entire array down. Today single sector errors (which are corrected on write via relocation) are more common than whole drive failures. Until we support a more graceful handling of this situation (i.e. resyntheizing the missing block and rewriting it, only failing the disk if the rewrite fails) I can not suggest linux raid to anyone who can't afford hours of downtime while fussing with the array from time to time. Usually this doesn't involve data loss, but only if you know what you're doing... From cmadams at hiwaay.net Wed Jun 22 13:46:14 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 22 Jun 2005 08:46:14 -0500 Subject: FC4 kernel performance In-Reply-To: References: <42B94ACA.5090008@web.de> <1119440497.5712.54.camel@localhost.localdomain> <42B96147.8040102@cornell.edu> <64458.192.54.193.35.1119446072.squirrel@rousalka.dyndns.org> Message-ID: <20050622134614.GB609975@hiwaay.net> Once upon a time, Gregory Maxwell said: > This isn't completely true. As it stands linux raid currently lowers > the reliability of the system. This is because a single bad sector > will take a drive offline. In the process of trying to resync the > offlined drive, the other drive(s) will encounter a bad sector and > come offline. You end up with the entire array down. Just FYI: this is not a problem exclusive to Linux software RAID. I have seen similar behavior out of LSI MegaRAID cards as well (and I think other hardware RAID controllers work in a similar fashion). Most things consider a bad sector a sign of a bad drive. On today's drives, where bad sectors are remapped internally to the drive, by the time you see a bad sector, the drive has remapped a bunch of sectors (and may be out of spare space). Some type of "journalling RAID" would be a possible solution (and would also allow for much faster re-syncs on unclean shutdown, as only the last written blocks would need updating). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From otaylor at redhat.com Wed Jun 22 14:03:24 2005 From: otaylor at redhat.com (Owen Taylor) Date: Wed, 22 Jun 2005 10:03:24 -0400 Subject: rawhide report: 20050621 changes In-Reply-To: <1119401177.3281.11.camel@jellyfish.redfishdemo.com> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> Message-ID: <1119449004.31721.3.camel@localhost.localdomain> On Wed, 2005-06-22 at 10:46 +1000, Rodd Clarkson wrote: > On Tue, 2005-06-21 at 07:02 -0400, Build System wrote: > > > cairo-0.5.1-1 > > ------------- > > * Mon Jun 20 2005 Kristian H?gsberg 0.5.1-1 > > - Update to cairo 0.5.1. > > - Remove gtk-doc files, since --disable-gtk-doc doesn't work. > > - Disable gtk-doc and add freetype and fontconfig BuildRequires. > > I'm curious to know what cairo means in terms of performance for users. > > I've read some really good stuff about it, but it all seems to rely on > "taking advantage of display hardware acceleration when available (eg. > through the X Render Extension or OpenGL)" (to quote from the > cairographics.org web site). > > What does this mean for users without hardware acceleration? > What does this mean for users with NVIDIA and ATI cards who don't have > support for 3D rendering because current open source drivers aren't > offering support for this? > > Given that gtp+-2.7.x (and beyond) is going to rely on Cairo for > rendering, I'd really appreciate it if someone in the know could give a > heads up on what this means for all users (since most of the focus > (media wise) seems to look at hardware accelerated environments). In general, with Cairo, if you render the same things as without Cairo, it goes through the same code path as before. (You can update to rawhide GTK+ and try it out ... it's still early and there is lots of performance work left to do, but my experience is that it isn't hugely slower.) If you have a fancy theme with alpha-transparency, gradients, etc, it will, not surprisingly, be slower than a completely flat and plain theme, at least for now. Eventually, Cairo will allow harnessing more of the capabilities of recent graphics hardware: without Cairo fancy graphics is all software rendering (and different for every app), with Cairo, we have the ability to accelerate in a single code path. Regards, Owen -------------- 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 gmaxwell at gmail.com Wed Jun 22 14:23:22 2005 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Wed, 22 Jun 2005 10:23:22 -0400 Subject: FC4 kernel performance In-Reply-To: <20050622134614.GB609975@hiwaay.net> References: <42B94ACA.5090008@web.de> <1119440497.5712.54.camel@localhost.localdomain> <42B96147.8040102@cornell.edu> <64458.192.54.193.35.1119446072.squirrel@rousalka.dyndns.org> <20050622134614.GB609975@hiwaay.net> Message-ID: On 6/22/05, Chris Adams wrote: > Just FYI: this is not a problem exclusive to Linux software RAID. I > have seen similar behavior out of LSI MegaRAID cards as well (and I > think other hardware RAID controllers work in a similar fashion). > > Most things consider a bad sector a sign of a bad drive. On today's > drives, where bad sectors are remapped internally to the drive, by the > time you see a bad sector, the drive has remapped a bunch of sectors > (and may be out of spare space). Well we need to distinguish between hard read errors and hard write errors. Because of relocation a hard write error is a sign of a failing drive (although with smart it shouldn't be your first clue). A read error can be the result of a sector that has just gone unrecoverable, the drive can't relocate because the data is already lost. Such sectors are displayed by smart as pending relocation and are only relocated after they are rewritten. After the write the drive works fine. I've found that on my large ATA disks that if I perform a weekly smart extensive scan that I don't get pending sectors as often, and when I do I can track them down and write something there before the raid code finds them. I'm not sure if the drive is just detecting weak sectors and rewriting them or if it just relocates (the smart counters don't indicate anything). Still they do happen from time to time, and it's often enough that on an older 6 disk raid 5 that resyncing always kicks out two disks unless I'm careful to make sure that there are no pending sectors. This can be addressed by attempting a rewrite of any unreadable sector... I suspect that's what the 3ware cards do, but I don't have any real evidence of that... they do seem much less likely to kick out drives than the software raid. > Some type of "journalling RAID" would be a possible solution (and would > also allow for much faster re-syncs on unclean shutdown, as only the > last written blocks would need updating). Right that's useful for many reasons, ... it's easier for an uncleanly shutdown software raid to make it's way to a desynced status than the hardware controllers. (though I'm not entirely sure why, we're pretty aggressive about flushing and setting a synced flag).. But this will be less then completely trivial to implement, especially since the journal should be persistent, which probably means a storage format change. From alan at redhat.com Wed Jun 22 14:46:06 2005 From: alan at redhat.com (Alan Cox) Date: Wed, 22 Jun 2005 10:46:06 -0400 Subject: FC4 kernel performance In-Reply-To: <42B95F36.5010301@cornell.edu> References: <42B94ACA.5090008@web.de> <20050622122310.GA8691@jadzia.bu.edu> <42B95F36.5010301@cornell.edu> Message-ID: <20050622144606.GA17600@devserv.devel.redhat.com> On Wed, Jun 22, 2005 at 08:53:10AM -0400, Paul A Houle wrote: > It's not so clear that SELinux helps much against real attacks. It > would take a much tougher security model than the Unix model or even the > SELinux model to stop the virus and zombie infections that we're seeing > in the Windows world. Things like NX that prevent or complicate buffer > overflow attacks may be more useful. They serve very different purposes. NX tries to help protect against certain kinds of code flaw attacks. SELinux models can also try and protect users against themselves. > If, for instance, I can find a way to execute arbitrary code in > Firefox or Thunderbird, I can install something on your computer that > runs as you. It can perpetuate itself by putting itself in your > .profile or in a cron job. It can make socket connections to anywhere, If the SELinux ruleset is right then except for the outgoing connections that isnt clear. Alan From alan at redhat.com Wed Jun 22 14:50:58 2005 From: alan at redhat.com (Alan Cox) Date: Wed, 22 Jun 2005 10:50:58 -0400 Subject: FC4 kernel performance In-Reply-To: <20050622134614.GB609975@hiwaay.net> References: <42B94ACA.5090008@web.de> <1119440497.5712.54.camel@localhost.localdomain> <42B96147.8040102@cornell.edu> <64458.192.54.193.35.1119446072.squirrel@rousalka.dyndns.org> <20050622134614.GB609975@hiwaay.net> Message-ID: <20050622145058.GB17600@devserv.devel.redhat.com> On Wed, Jun 22, 2005 at 08:46:14AM -0500, Chris Adams wrote: > Most things consider a bad sector a sign of a bad drive. On today's > drives, where bad sectors are remapped internally to the drive, by the > time you see a bad sector, the drive has remapped a bunch of sectors > (and may be out of spare space). Bad sector on write yes - that generally means its time to throw the drive away, on read its not neccessarily so bad. Thats one reaosn e2fsck will rewrite inode and other critical blocks that won't read as part of the recovery From caillon at redhat.com Wed Jun 22 15:00:00 2005 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 22 Jun 2005 11:00:00 -0400 Subject: reverted back to old browser start functionality + startup notification rant In-Reply-To: <1119379032.19988.18.camel@mlenzdesktop> References: <1119379032.19988.18.camel@mlenzdesktop> Message-ID: <42B97CF0.9010501@redhat.com> On 06/21/2005 02:37 PM, Matthew Lenz wrote: > With FC3 the launcher script would check to see if firefox was already > running and if so, it would simply open a new window. Now FC4 is back > to the old way where it attempts to do startup notification and hijacks > the cursor with the 'hour glass' until startup notification times out. > I wish I didn't feel like gnome startup notification was a huge hack, > but I do (can it just be disabled?). Yet, when I click on a url in > gaim, or evo it opens it properly in a new tab or window (according to > my tab browser preferences). What gives? I would assume they all execute > the same script right? Also is it entirely necessary for startup > notification to hijack the cursor with the hourglass just because a > program is starting? Is it unreasonable that i'd want to immediately go > to the Applications menu and open another application while the other is > loading? The 'hour glass' isn't exactly a user friendly pointing > device. :) > I keep getting distracted with other priority items -- I want to write the fix for Firefox to handle this properly. The issue now is just finding time to do so! Basically, what needs to happen is we need to hack in a service that xremote can install a DESKTOP_STARTUP_ID to, and then have the new window code properly pass that on to gtk before we paint the window on screen. It's kind of tricky and the codepoints are a little scary at times. I'm at LinuxTag this week and will probably be catching up next week so I won't have time to for a while. I'd love to see this patched though. If someone is interested, please let me know and I'll attempt to get you on your way (only serious inquires, please!) From tarjei.knapstad at predichem.com Wed Jun 22 15:06:14 2005 From: tarjei.knapstad at predichem.com (Tarjei Knapstad) Date: Wed, 22 Jun 2005 17:06:14 +0200 Subject: Cairo [was: rawhide report: 20050621 changes] In-Reply-To: <1119444032.3335.14.camel@goose> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> <1119428771.27240.113.camel@tarjei.predichem.nett> <1119444032.3335.14.camel@goose> Message-ID: <1119452774.27240.140.camel@tarjei.predichem.nett> On Wed, 2005-06-22 at 14:40, Rodd Clarkson wrote: > On Wed, 2005-06-22 at 10:26 +0200, Tarjei Knapstad wrote: > > On Wed, 2005-06-22 at 02:46, Rodd Clarkson wrote: > > > On Tue, 2005-06-21 at 07:02 -0400, Build System wrote: > > > accelerated graphics. Those without it shouldn't notice any difference. > > Don't get me wrong (and I'm not sure if you have). I think it might be the other way around :) (or we're both confused :)) > What I'm wanting to know is will people without hardware acceleration be > worse off. Are non-hw-accelerated users going to end up with a system > that runs something like non-hw-accelerated 3D (which really sucks, even > with a good processor)? Or will the rendering on non-hw-accelerated > systems be quite good, and rendering with hw-accelerated systems will be > brilliant? > What I was trying to say in the last line above was that users without hardware accelerated graphics shouldn't notice any performance hit compared to today. I would be highly surprised if this wasn't a design goal in Cairo given that all hardware accelerated graphics currently require the use of proprietary drivers (99.9% anyway...) which most of the FOSS community seems to bark at. Normal X window rendering should be on par or better than with current vector drawing libraries. I can't imagine that serious performance regressions against earlier vector drawing solutions won't be fixed before Cairo goes live in gtk+ etc. In short, I wouldn't worry too much. -- Tarjei From buildsys at redhat.com Wed Jun 22 16:09:57 2005 From: buildsys at redhat.com (Build System) Date: Wed, 22 Jun 2005 12:09:57 -0400 Subject: rawhide report: 20050622 changes Message-ID: <200506221609.j5MG9vTQ010665@porkchop.devel.redhat.com> Updated Packages: antlr-0:2.7.4-2jpp_2fc ---------------------- * Tue Jun 21 2005 Gary Benson - 0:2.7.4-2jpp_2fc - Remove jarfile from the tarball. - Remove now-unnecessary workaround for #144775. * Tue Jan 11 2005 Gary Benson - 0:2.7.4-2jpp_1fc - Sync with RHAPS. * Mon Nov 15 2004 Fernando Nasser - 0:2.7.4-2jpp_1rh - Merge with upstream for upgrade arts-8:1.4.1-2 -------------- * Tue Jun 21 2005 Than Ngo 8:1.4.1-2 - rebuilt audit-0.9.11-1 -------------- * Tue Jun 21 2005 Steve Grubb 0.9.11-1 - Change packet draining to nonblocking - Interpret id field in ausearch - Add error message if not able to create log - Ignore netlink acks when asking for rule & watch list * Mon Jun 20 2005 Steve Grubb 0.9.10-1 - Make sure the bad packet is drained when retrying user messages - Add support for new user and watch filter lists - Interpret flags field in ausearch * Sun Jun 19 2005 Steve Grubb 0.9.9-1 - Fix user messages for people with older kernels axis-0:1.2.1-1jpp_1fc --------------------- * Tue Jun 21 2005 Gary Benson 0:1.2.1-1jpp_1fc - Upgrade to 1.2.1-1jpp. * Fri Jun 17 2005 Fernando Nasser 0:1.2.1-1jpp - Upgrade to 1.2.1 maintenance release bsf-0:2.3.0-6jpp_2fc -------------------- * Tue Jun 21 2005 Gary Benson 0:2.3.0-6jpp_2fc - Remove classes and tarballs from the tarball too. cairo-0.5.1-2 ------------- * Tue Jun 21 2005 Kristian H??gsberg - 0.5.1-2 - Package gtk docs as part of devel package. - Nuke static library. - Update devel files so /usr/include/cairo is owned by devel package. * Mon Jun 20 2005 Kristian H??gsberg - 0.5.1-1 - Update to cairo 0.5.1. - Remove gtk-doc files, since --disable-gtk-doc doesn't work. - Disable gtk-doc and add freetype and fontconfig BuildRequires. * Tue Jun 14 2005 Kristian H??gsberg - 0.5.0-2 - Add libpixman-devel BuildRequires. - Explicitly disable win32 backend. cryptix-0:3.2.0-4jpp_2fc ------------------------ * Tue Jun 21 2005 Gary Benson 3.2.0-4jpp_2fc - Remove jarfile from the tarball. * Fri Jan 21 2005 Gary Benson 3.2.0-4jpp_1fc - Build into Fedora. * Fri Mar 05 2004 Frank Ch. Eigler 3.2.0-4jpp_1rh - RH vacuuming cryptix-asn1-0:20011119-4jpp_2fc -------------------------------- * Tue Jun 21 2005 Gary Benson 20011119-4jpp_2fc - Remove classes and jarfiles from the tarball. gnu.getopt-0:1.0.9-4jpp_2fc --------------------------- * Tue Jun 21 2005 Gary Benson 0:1.0.9-4jpp_2fc - Remove classes from the tarball. gtk2-2.7.0-1 ------------ * Tue Jun 21 2005 Matthias Clasen - update to 2.7.0 - bump requirements * Tue May 10 2005 Matthias Clasen - remove the openssl prereq again, as it did not fix Florians problem. * Sun May 08 2005 Matthias Clasen - remove debug spew jakarta-commons-dbcp-0:1.2.1-3jpp_2fc ------------------------------------- * Tue Jun 21 2005 Gary Benson - 0:1.2.1-3jpp_2fc - Remove jarfile from the tarball. * Thu Jan 20 2005 Gary Benson - 0:1.2.1-3jpp_1fc - Build into Fedora. * Tue Nov 02 2004 Fernando Nasser 0:1.2.1-0.hjc.3jpp_1rh - Import latest community version jakarta-commons-lang-0:2.0-2jpp_2fc ----------------------------------- * Tue Jun 21 2005 Gary Benson - 0:2.0-2jpp_2fc - Remove jarfile from the tarball. jakarta-commons-pool-0:1.2-2jpp_2fc ----------------------------------- * Tue Jun 21 2005 Gary Benson - 0:1.2-2jpp_2fc - Remove jarfile from the tarball. jakarta-commons-validator-0:1.1.3-1jpp_2fc ------------------------------------------ * Tue Jun 21 2005 Gary Benson - 0:1.1.3-1jpp_2fc - Remove jarfile from the tarball. java_cup-1:0.10-0.k.1jpp_3fc ---------------------------- * Tue Jun 21 2005 Gary Benson 1:0.10-0.k.1jpp_3fc - Remove classes from the tarball. jdepend-0:2.6-2jpp_4fc ---------------------- * Wed Jun 22 2005 Gary Benson 0:2.6-2jpp_4fc - Remove jarfile from the tarball. jdom-0:1.0-1jpp_2fc ------------------- * Wed Jun 22 2005 Gary Benson - 0:1.0-1jpp_2fc - Remove classes from the tarball too. kdelibs-6:3.4.1-2 ----------------- * Tue Jun 21 2005 Than Ngo 6:3.4.1-2 - add devices protocol #160927 kernel-2.6.12-1.1392_FC5 ------------------------ * Tue Jun 21 2005 Dave Jones - 2.6.12-git3 - Welcome back Tux. - Don't disable sysenter if booted with exec_shield=0 - Fix up and reenable Xen. latex2html-2002.2.1-4 --------------------- * Tue Jun 21 2005 Jindrich Novy 2002.2.1-4 - remove '\n' causing that pstoimg generates gray images (#161186, #127010), solution from Julius Smith libmng-1.0.9-2 -------------- * Tue Jun 21 2005 Matthias Clasen 1.0.9-2 - Add missing requires net-tools-1.60-54 ----------------- * Wed Jun 22 2005 Radek Vokal 1.60-54 - fr man pages are back (#159702) netpbm-10.28-2 -------------- * Tue Jun 21 2005 Jindrich Novy 10.28-2 - fix segfault in pbmtolj caused by unchecked assertions caused by definition of NDEBUG (#160429) - drop hunk from .security patch causing dual inclusion of string.h in pbmtolj.c pango-1.9.0-1 ------------- * Tue Jun 21 2005 Matthias Clasen 1.9.0-1 - Update to 1.9.0 - Require cairo ruby-1.8.2-9 ------------ * Tue Jun 21 2005 Akira TAGOH - 1.8.2-9 - ruby-1.8.2-xmlrpc-CAN-2005-1992.patch: fixed the arbitrary command execution on XMLRPC server. (#161096) s390utils-2:1.3.2-5 ------------------- * Tue Jun 21 2005 Phil Knirsch 2:1.3.2-5 - Added src_vipa to s390utils slocate-2.7-24 -------------- * Tue Jun 21 2005 Miloslav Trmac - 2.7-24 - Add missing OOM handling to lazy-mtab.patch sudo-1.6.8p9-1 -------------- * Tue Jun 21 2005 Karel Zak 1.6.8p9-1 - new version 1.6.8p9 (resolve #161116 - CAN-2005-1993 sudo trusted user arbitrary command execution) * Tue May 24 2005 Karel Zak 1.6.8p8-2 - fix #154511 ??? sudo does not use limits.conf * Mon Apr 04 2005 Thomas Woerner 1.6.8p8-1 - new version 1.6.8p8: new sudoedit and sudo_noexec tcpdump-14:3.8.2-14 ------------------- * Tue Jun 21 2005 Martin Stransky - 14:3.8.2-14 - add shadow-utils to Prereq (#160643) vnc-4.1.1-11 ------------ * Tue Jun 21 2005 Tim Waugh 4.1.1-11 - Don't ship vncconfig.py any more. - Enable render by default for further testing. * Mon Jun 20 2005 Tim Waugh - Build requires expat-devel (bug #160982). Broken deps for ppc ---------------------------------------------------------- gnbd-kernel - 2.6.11.2-20050420.133124.FC4.35.ppc requires /lib/modules/2.6.11-1.1369_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.35.ppc requires kernel = 0:2.6.11-1.1369_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.2.ppc requires /lib/modules/2.6.11-1.1369_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.2.ppc requires kernel = 0:2.6.11-1.1369_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.2.ppc requires /lib/modules/2.6.11-1.1369_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.2.ppc requires kernel = 0:2.6.11-1.1369_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.2.ppc requires /lib/modules/2.6.11-1.1369_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.2.ppc requires kernel = 0:2.6.11-1.1369_FC4 Broken deps for x86_64 ---------------------------------------------------------- cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.2.x86_64 requires /lib/modules/2.6.11-1.1369_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.2.x86_64 requires kernel-smp = 0:2.6.11-1.1369_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.2.x86_64 requires /lib/modules/2.6.11-1.1369_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.2.x86_64 requires kernel = 0:2.6.11-1.1369_FC4 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.35.x86_64 requires /lib/modules/2.6.11-1.1369_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.35.x86_64 requires kernel-smp = 0:2.6.11-1.1369_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.2.x86_64 requires /lib/modules/2.6.11-1.1369_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.2.x86_64 requires kernel = 0:2.6.11-1.1369_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.35.x86_64 requires /lib/modules/2.6.11-1.1369_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.35.x86_64 requires kernel = 0:2.6.11-1.1369_FC4 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.2.x86_64 requires /lib/modules/2.6.11-1.1369_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.2.x86_64 requires kernel-smp = 0:2.6.11-1.1369_FC4 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.2.x86_64 requires /lib/modules/2.6.11-1.1369_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.2.x86_64 requires kernel-smp = 0:2.6.11-1.1369_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.2.x86_64 requires /lib/modules/2.6.11-1.1369_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.2.x86_64 requires kernel = 0:2.6.11-1.1369_FC4 Broken deps for i386 ---------------------------------------------------------- gnbd-kernel - 2.6.11.2-20050420.133124.FC4.35.i586 requires /lib/modules/2.6.11-1.1369_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.35.i586 requires kernel = 0:2.6.11-1.1369_FC4 gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.35.i686 requires kernel-xen0 = 0:2.6.11-1.1369_FC4 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.2.i686 requires /lib/modules/2.6.11-1.1369_FC4xenU cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.2.i686 requires kernel-xenU = 0:2.6.11-1.1369_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.2.i686 requires /lib/modules/2.6.11-1.1369_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.2.i686 requires kernel = 0:2.6.11-1.1369_FC4 cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.2.i686 requires kernel-xen0 = 0:2.6.11-1.1369_FC4 dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.2.i686 requires kernel-xen0 = 0:2.6.11-1.1369_FC4 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.2.i686 requires /lib/modules/2.6.11-1.1369_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.2.i686 requires kernel-smp = 0:2.6.11-1.1369_FC4 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.2.i686 requires /lib/modules/2.6.11-1.1369_FC4xenU GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.2.i686 requires kernel-xenU = 0:2.6.11-1.1369_FC4 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.2.i686 requires /lib/modules/2.6.11-1.1369_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.2.i686 requires kernel-smp = 0:2.6.11-1.1369_FC4 GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.2.i686 requires kernel-xen0 = 0:2.6.11-1.1369_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.2.i586 requires /lib/modules/2.6.11-1.1369_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.2.i586 requires kernel = 0:2.6.11-1.1369_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.2.i686 requires /lib/modules/2.6.11-1.1369_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.2.i686 requires kernel = 0:2.6.11-1.1369_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.2.i586 requires /lib/modules/2.6.11-1.1369_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.2.i586 requires kernel = 0:2.6.11-1.1369_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.35.i686 requires /lib/modules/2.6.11-1.1369_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.35.i686 requires kernel = 0:2.6.11-1.1369_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.2.i586 requires /lib/modules/2.6.11-1.1369_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.2.i586 requires kernel = 0:2.6.11-1.1369_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.2.i686 requires /lib/modules/2.6.11-1.1369_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.2.i686 requires kernel = 0:2.6.11-1.1369_FC4 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.2.i686 requires /lib/modules/2.6.11-1.1369_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.2.i686 requires kernel-smp = 0:2.6.11-1.1369_FC4 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.35.i686 requires /lib/modules/2.6.11-1.1369_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.35.i686 requires kernel-smp = 0:2.6.11-1.1369_FC4 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.2.i686 requires /lib/modules/2.6.11-1.1369_FC4xenU dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.2.i686 requires kernel-xenU = 0:2.6.11-1.1369_FC4 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.35.i686 requires /lib/modules/2.6.11-1.1369_FC4xenU gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.35.i686 requires kernel-xenU = 0:2.6.11-1.1369_FC4 Broken deps for ia64 ---------------------------------------------------------- velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging joram - 4.1.5-1jpp_1fc.noarch requires jmxri joram - 4.1.5-1jpp_1fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_1fc.noarch requires jta jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 jessie - 1.0.0-8.noarch requires java >= 0:1.4 jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper wsdl4j - 1.5.1-1jpp_1fc.noarch requires java xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 magma-plugins - 1.0-0.pre16.11.ia64 requires libgulm.so.1.0()(64bit) jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 jonas - 4.3.3-1jpp_1fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_1fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_1fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_1fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_1fc.noarch requires mx4j >= 1:2.1.0 jonas - 4.3.3-1jpp_1fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_1fc.noarch requires jasper5 avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 castor - 0.9.5-1jpp_1fc.noarch requires jta java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj rgmanager - 1.9.31-3.ia64 requires ccs xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging Broken deps for s390x ---------------------------------------------------------- quota - 1:3.12-6.s390x requires kernel >= 0:2.4 xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet dhcp - 10:3.0.2-14.s390x requires kernel >= 0:2.2.18 jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 castor - 0.9.5-1jpp_1fc.noarch requires jta jessie - 1.0.0-8.noarch requires java >= 0:1.4 prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10 jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging libsane-hpaio - 0.9.3-5.s390x requires sane-backends gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2 selinux-policy-strict-sources - 1.23.18-15.noarch requires kernel >= 0:2.6.11-1.1219 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 wsdl4j - 1.5.1-1jpp_1fc.noarch requires java lvm2 - 2.01.12-1.0.s390x requires kernel >= 0:2.6 jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0 sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21 joram - 4.1.5-1jpp_1fc.noarch requires jmxri joram - 4.1.5-1jpp_1fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_1fc.noarch requires jta ecj - 1:3.1-0.M4.9.s390x requires katana >= 0:2.0.0 jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections libpcap - 14:0.8.3-14.s390x requires kernel >= 0:2.2.0 jonas - 4.3.3-1jpp_1fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_1fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_1fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_1fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_1fc.noarch requires mx4j >= 1:2.1.0 jonas - 4.3.3-1jpp_1fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_1fc.noarch requires jasper5 xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging selinux-policy-strict - 1.23.18-15.noarch requires kernel >= 0:2.6.11-1.1219 jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 nfs-utils - 1.0.7-8.s390x requires kernel >= 0:2.2.14 axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java selinux-policy-targeted-sources - 1.23.18-15.noarch requires kernel >= 0:2.6.11-1.1219 avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit) initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6 hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11 arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0 jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 hal - 0.5.2-2.s390x requires kernel >= 0:2.6.11 selinux-policy-targeted - 1.23.18-15.noarch requires kernel >= 0:2.6.11-1.1219 Broken deps for ppc64 ---------------------------------------------------------- jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 jonas - 4.3.3-1jpp_1fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_1fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_1fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_1fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_1fc.noarch requires mx4j >= 1:2.1.0 jonas - 4.3.3-1jpp_1fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_1fc.noarch requires jasper5 ppc64-utils - 0.7-9.ppc64 requires yaboot wsdl4j - 1.5.1-1jpp_1fc.noarch requires java jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging castor - 0.9.5-1jpp_1fc.noarch requires jta gnbd-kernel - 2.6.11.2-20050420.133124.FC4.35.ppc64 requires /lib/modules/2.6.11-1.1369_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.35.ppc64 requires kernel = 0:2.6.11-1.1369_FC4 rhpl - 0.167-1.ppc64 requires pyxf86config >= 0:0.3.2 system-config-mouse - 1.2.11-1.noarch requires pyxf86config jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit) gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit) axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections ecj - 1:3.1-0.M4.9.ppc64 requires katana >= 0:2.0.0 jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet cman-kernel - 2.6.11.5-20050601.152643.FC4.2.ppc64 requires /lib/modules/2.6.11-1.1369_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.2.ppc64 requires kernel = 0:2.6.11-1.1369_FC4 joram - 4.1.5-1jpp_1fc.noarch requires jmxri joram - 4.1.5-1jpp_1fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_1fc.noarch requires jta system-config-display - 1.0.29-1.noarch requires /usr/X11R6/bin/Xorg system-config-display - 1.0.29-1.noarch requires pyxf86config >= 0:0.3.16 jessie - 1.0.0-8.noarch requires java >= 0:1.4 system-config-keyboard - 1.2.6-2.noarch requires pyxf86config dlm-kernel - 2.6.11.5-20050601.152643.FC4.2.ppc64 requires /lib/modules/2.6.11-1.1369_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.2.ppc64 requires kernel = 0:2.6.11-1.1369_FC4 hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging Broken deps for s390 ---------------------------------------------------------- castor - 0.9.5-1jpp_1fc.noarch requires jta selinux-policy-strict - 1.23.18-15.noarch requires kernel >= 0:2.6.11-1.1219 libsane-hpaio - 0.9.3-5.s390 requires sane-backends jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging joram - 4.1.5-1jpp_1fc.noarch requires jmxri joram - 4.1.5-1jpp_1fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_1fc.noarch requires jta jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging selinux-policy-targeted - 1.23.18-15.noarch requires kernel >= 0:2.6.11-1.1219 nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14 jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11 jessie - 1.0.0-8.noarch requires java >= 0:1.4 quota - 1:3.12-6.s390 requires kernel >= 0:2.4 velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21 selinux-policy-targeted-sources - 1.23.18-15.noarch requires kernel >= 0:2.6.11-1.1219 lvm2 - 2.01.12-1.0.s390 requires kernel >= 0:2.6 jonas - 4.3.3-1jpp_1fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_1fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_1fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_1fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_1fc.noarch requires mx4j >= 1:2.1.0 jonas - 4.3.3-1jpp_1fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_1fc.noarch requires jasper5 jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10 gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2 jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 wsdl4j - 1.5.1-1jpp_1fc.noarch requires java libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0 selinux-policy-strict-sources - 1.23.18-15.noarch requires kernel >= 0:2.6.11-1.1219 dhcp - 10:3.0.2-14.s390 requires kernel >= 0:2.2.18 jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet ecj - 1:3.1-0.M4.9.s390 requires katana >= 0:2.0.0 arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0 jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2 initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6 From tjarls at iee.lu Wed Jun 22 17:19:26 2005 From: tjarls at iee.lu (Charles Lopes) Date: Wed, 22 Jun 2005 19:19:26 +0200 Subject: FC4 kernel performance In-Reply-To: <20050622145058.GB17600@devserv.devel.redhat.com> References: <42B94ACA.5090008@web.de> <1119440497.5712.54.camel@localhost.localdomain> <42B96147.8040102@cornell.edu> <64458.192.54.193.35.1119446072.squirrel@rousalka.dyndns.org> <20050622134614.GB609975@hiwaay.net> <20050622145058.GB17600@devserv.devel.redhat.com> Message-ID: <42B99D9E.6000007@iee.lu> Alan Cox wrote: >On Wed, Jun 22, 2005 at 08:46:14AM -0500, Chris Adams wrote: > > >>Most things consider a bad sector a sign of a bad drive. On today's >>drives, where bad sectors are remapped internally to the drive, by the >>time you see a bad sector, the drive has remapped a bunch of sectors >>(and may be out of spare space). >> >> > >Bad sector on write yes - that generally means its time to throw the drive >away, on read its not neccessarily so bad. Thats one reaosn e2fsck will >rewrite inode and other critical blocks that won't read as part of the >recovery > > Isn't what RAID1 does already. My understanding was that in case of read error, it retries the read operation on a working mirror and rewrites the failed block. Can anyone confirm or infirm the RAID1 behaviour? From lamont at gurulabs.com Wed Jun 22 17:28:06 2005 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Wed, 22 Jun 2005 11:28:06 -0600 Subject: FC4 kernel performance In-Reply-To: <1119440497.5712.54.camel@localhost.localdomain> References: <42B94ACA.5090008@web.de> <1119440497.5712.54.camel@localhost.localdomain> Message-ID: <200506221128.12602.lamont@gurulabs.com> On Wednesday 22 June 2005 05:41am, Peter Backlund wrote: [SNIP] > The debugging should be taken out of the release kernels, yes. But RAID > support is modularized, and I'd imagine that the SELinux overhead is > incredibly small when it's turned off. The same goes for exec-shield. I > don't really know what the other 19 security features are > though :-) Even though the RAID support is built as a module, I still always see the kernel trying to close down md (and it takes about 5-10 seconds) every time I shut down my notebook. It should, at least, be more obvious how to get rid of the monitoring daemon and truly remove md support from the running kernel. Better yet, why not unload md in rc.sysinit if there are no devices? > > And thats the point. One kernel for the desktop and one for all server > > users, which you select at the installation or later. Is that too much? > > And we never get these "slow Fedora kernel questions" again... ;) > > That means six extra kernels to support, build, debug, and handle > external modules for: {i586,i686,ppc} X {UP,SMP}. I would assume you meant {i686,AMD64,ppc,ppc64}{up,smp}. Is this not what we have now? I like the idea of a "desktop/laptop" kernel and a server kernel being provided. I would suggest building a "near-vanilla" kernel with all the extra stuff that "Joe User" would never use stripped out. Still build RAID as a module, but do not include anything patches that are not security or disfunctionality fixing. I can always build something extra as an external module RPM, if I want. I guess that means that I am posing another idea; how about building the feature adding patches as separate RPMs? It wouldn't be hard to alter the existing kernel .spec file to build those as "external modules" and package each on it's own. On the topic of debugging, I think others have already stated it well. I would just like to see it be easy to install the debugging (read "install 1 RPM") support when I need it and then rpm -e it out after I'm done. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. http://www.GuruLabs.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From m.f.h at web.de Wed Jun 22 17:31:59 2005 From: m.f.h at web.de (Marcus Hartig) Date: Wed, 22 Jun 2005 19:31:59 +0200 Subject: FC4 kernel performance In-Reply-To: <20050622122310.GA8691@jadzia.bu.edu> References: <42B94ACA.5090008@web.de> <20050622122310.GA8691@jadzia.bu.edu> Message-ID: <42B9A08F.4010806@web.de> Matthew Miller wrote: > These people *do* need the security features. You want Linux to end up like > Windows, with a virus/spyware infection the *norm*? The most viruses or worms I found, are exploiting security holes in the special wintendo virus pack by M$: IE, OE and the XPeriment...often nobody knows that a worm runs for weeks on his/her system. And... I argue that more as 96 % of the win users @ home are using their system as installed my M$ as a sys admin...no wonder. For a private Linux user who uses only a GIMP, firefox, evince, Ooo, thunderbird and some games and with no important data on the disk, there is no need for special security things, RAID and Co. in times of cheap DVD burners to secure data. A good cheap (DSL) router in front, a up2date system with only needed services running, using secure passwords, secure software, working as Luser, is the best medicine. Regards, Marcus From Nicolas.Mailhot at laPoste.net Wed Jun 22 17:41:47 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 22 Jun 2005 19:41:47 +0200 Subject: FC4 kernel performance In-Reply-To: <42B9A08F.4010806@web.de> References: <42B94ACA.5090008@web.de> <20050622122310.GA8691@jadzia.bu.edu> <42B9A08F.4010806@web.de> Message-ID: <1119462107.3295.3.camel@rousalka.dyndns.org> Le mercredi 22 juin 2005 ? 19:31 +0200, Marcus Hartig a ?crit : > For a private Linux user who uses only a GIMP, firefox, evince, Ooo, > thunderbird and some games and with no important data on the disk, there > is no need for special security things, RAID and Co. in times of cheap > DVD burners to secure data. ROFL. You really think your typical user will do regular backups ? Hardware availability means nothing - cd burners proved it. RAID is good because it's painless security (and I know it's not the same thing but at least once it's here it needs no human intervention at all) -- Nicolas Mailhot -------------- 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 jon.nettleton at gmail.com Wed Jun 22 17:44:34 2005 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Wed, 22 Jun 2005 13:44:34 -0400 Subject: Cairo [was: rawhide report: 20050621 changes] In-Reply-To: <1119452774.27240.140.camel@tarjei.predichem.nett> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> <1119428771.27240.113.camel@tarjei.predichem.nett> <1119444032.3335.14.camel@goose> <1119452774.27240.140.camel@tarjei.predichem.nett> Message-ID: <1119462274.10442.4.camel@localhost> On Wed, 2005-06-22 at 17:06 +0200, Tarjei Knapstad wrote: > On Wed, 2005-06-22 at 14:40, Rodd Clarkson wrote: > > On Wed, 2005-06-22 at 10:26 +0200, Tarjei Knapstad wrote: > > > On Wed, 2005-06-22 at 02:46, Rodd Clarkson wrote: > > > > On Tue, 2005-06-21 at 07:02 -0400, Build System wrote: > > > > > > > > accelerated graphics. Those without it shouldn't notice any difference. > > > > Don't get me wrong (and I'm not sure if you have). > > I think it might be the other way around :) (or we're both confused :)) > > > What I'm wanting to know is will people without hardware acceleration be > > worse off. Are non-hw-accelerated users going to end up with a system > > that runs something like non-hw-accelerated 3D (which really sucks, even > > with a good processor)? Or will the rendering on non-hw-accelerated > > systems be quite good, and rendering with hw-accelerated systems will be > > brilliant? > > > > What I was trying to say in the last line above was that users without > hardware accelerated graphics shouldn't notice any performance hit > compared to today. I would be highly surprised if this wasn't a design > goal in Cairo given that all hardware accelerated graphics currently > require the use of proprietary drivers (99.9% anyway...) which most of > the FOSS community seems to bark at. > > Normal X window rendering should be on par or better than with current > vector drawing libraries. I can't imagine that serious performance > regressions against earlier vector drawing solutions won't be fixed > before Cairo goes live in gtk+ etc. > > In short, I wouldn't worry too much. > > -- > Tarjei > If anyone who hasn't upgraded to the newest rawhide ( Unfortunately I jumped the gun before thinking about it ) wants to collect some numbers. I would suggest grabbing gtkperf http://gtkperf.sourceforge.net/index.php?page=testing&id=1 and running a test case, before and after gtk2 with cairo support. I actually think so far the update feels a bit faster, however some definitive numbers would be interesting. Jon From zuirdj at gmail.com Wed Jun 22 17:51:57 2005 From: zuirdj at gmail.com (Zuir DJ) Date: Wed, 22 Jun 2005 13:51:57 -0400 Subject: rawhide report: 20050622 changes In-Reply-To: <200506221609.j5MG9vTQ010665@porkchop.devel.redhat.com> References: <200506221609.j5MG9vTQ010665@porkchop.devel.redhat.com> Message-ID: 2005/6/22, Build System : [snip] > > Broken deps for i386 > [snip] :-O Amazing feature! -- Zuirdj From pmatilai at laiskiainen.org Wed Jun 22 17:59:01 2005 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Wed, 22 Jun 2005 20:59:01 +0300 Subject: rawhide report: 20050622 changes In-Reply-To: References: <200506221609.j5MG9vTQ010665@porkchop.devel.redhat.com> Message-ID: <1119463141.31372.17.camel@localhost.localdomain> On Wed, 2005-06-22 at 13:51 -0400, Zuir DJ wrote: > 2005/6/22, Build System : > [snip] > > > > Broken deps for i386 > > > [snip] > > :-O > > Amazing feature! Check out "repoclosure" command from yum-utils (which is available from Fedora Extras) - that's what you're seeing in action here. - Panu - From m.f.h at web.de Wed Jun 22 18:10:18 2005 From: m.f.h at web.de (Marcus Hartig) Date: Wed, 22 Jun 2005 20:10:18 +0200 Subject: FC4 kernel performance In-Reply-To: <1119462107.3295.3.camel@rousalka.dyndns.org> References: <42B94ACA.5090008@web.de> <20050622122310.GA8691@jadzia.bu.edu> <42B9A08F.4010806@web.de> <1119462107.3295.3.camel@rousalka.dyndns.org> Message-ID: <42B9A98A.1010107@web.de> Nicolas Mailhot wrote: > ROFL. You really think your typical user will do regular backups ? Sure, not all, but I know many ... because "I" have teached them to do this... which burn there docs, holiday pics, bookmarks,... and other files on a CD/DVD, you not? What do you make, if all RAID disks get a error? ;-) > Hardware availability means nothing - cd burners proved it. RAID is good > because it's painless security (and I know it's not the same thing but > at least once it's here it needs no human intervention at all) This is maybe the only point for a (desktop) user, the performance is >= 0. I have no more RAID-0 in use here. I feel no more gain in speed while writing this posting... Regards, Marcus From fedora at camperquake.de Wed Jun 22 18:13:08 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 22 Jun 2005 20:13:08 +0200 Subject: Cairo [was: rawhide report: 20050621 changes] In-Reply-To: <1119462274.10442.4.camel@localhost> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> <1119428771.27240.113.camel@tarjei.predichem.nett> <1119444032.3335.14.camel@goose> <1119452774.27240.140.camel@tarjei.predichem.nett> <1119462274.10442.4.camel@localhost> Message-ID: <20050622201308.73f97fcf@nausicaa.camperquake.de> Hi. Jon Nettleton wrote: > test case, before and after gtk2 with cairo support. I actually think > so far the update feels a bit faster, however some definitive numbers > would be interesting. Apart from that: does it work or does it break all sorts of things? -- Hidden DOS secret: add BUGS=OFF to your CONFIG.SYS From ph18 at cornell.edu Wed Jun 22 18:16:02 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Wed, 22 Jun 2005 14:16:02 -0400 Subject: FC4 kernel performance In-Reply-To: <1119446162.13181.29.camel@moss-spartans.epoch.ncsc.mil> References: <42B94ACA.5090008@web.de> <20050622122310.GA8691@jadzia.bu.edu> <42B95F36.5010301@cornell.edu> <1119446162.13181.29.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <42B9AAE2.2020500@cornell.edu> Stephen Smalley wrote: > >Actually, the SELinux model (or more generally, flexible mandatory >access control) is precisely what one needs in order to contain >malicious and flawed applications. And SELinux can also help reinforce >mehcanisms like exec-shield by providing policy control over what >applications can generate runtime code. > > > Well, I'll believe it after we've had a few years of experience with it. Windows NT has a 'richer' security model than the traditional Unix model, but nobody uses it. Nobody knows how, and more to the point, everything that an application has to work with in Windows NT doesn't use the security features it has, so it's hard for one site or one application to start doing things differently. SELinux is going to require a whole ecosystem of tools that work together, or it's just going to put more of Fedora in the "it just doesn't work" category. For all the limitation of the UNIX model, people understand it. They're afraid of root, and raw fear is a good motivator. I remember VMS having tens of different permissions that a process could have, and people finding privilege escalation attacks all the time. >But with SELinux, that application (firefox or thunderbird or whatever) >can be placed in its own security domain, with its own set of >permissions that are a subset of the user's overall permissions. There >is admittedly a lot of work to do to properly secure the desktop (e.g. >security-enhanced X, which has been implemented but not yet upstreamed), >but mandatory access control is the right mechanism for dealing with >this issue. > > > Yeah, but I want thunderbird to have a lot of access to my files. I want to be able to send an arbitrary file as an attachment, and I'd like to be able to save files from it easily. (Yeah, you might restrict it to 'save to the desktop' but once a lot of apps are restricted the way, everything is on the desktop.) You might block off most network ports, but it still needs to make port 25 connections to the outbound mail server -- which is what it needs to infect other computers. You might lock it down so it can only talk to my official outbound mail server, but then I can't use the GUI to configure my mail application. Multiply this by hundreds of desktop apps which are glitchy enough as it is, and we've got a new slogan for Fedora: "it just doesn't work." It's not enough to have a system which is 'tough', we need a system that's flexible enough that people can do 'the right thing' in a way that isn't painful. If it's painful, or even difficult to understand for average ordinary people, people are just going to configure SELinux in ways that are unsafe so that things 'just work', and we're back where we started, probably worse, because people have a false sense of security. Finding that kind of intersection is difficult -- if you can do it, my hats are off to you. I can SELinux being of interest for specialized applications (desktops at the NSA? server appliances?) but i'll be hard pressed to become an expert on SELinux so I can get my regular work done. From Nicolas.Mailhot at laPoste.net Wed Jun 22 18:20:04 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 22 Jun 2005 20:20:04 +0200 Subject: Cairo [was: rawhide report: 20050621 changes] In-Reply-To: <20050622201308.73f97fcf@nausicaa.camperquake.de> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> <1119428771.27240.113.camel@tarjei.predichem.nett> <1119444032.3335.14.camel@goose> <1119452774.27240.140.camel@tarjei.predichem.nett> <1119462274.10442.4.camel@localhost> <20050622201308.73f97fcf@nausicaa.camperquake.de> Message-ID: <1119464404.9395.2.camel@rousalka.dyndns.org> Le mercredi 22 juin 2005 ? 20:13 +0200, Ralf Ertzinger a ?crit : > Hi. > > Jon Nettleton wrote: > > > test case, before and after gtk2 with cairo support. I actually think > > so far the update feels a bit faster, however some definitive numbers > > would be interesting. > > Apart from that: does it work or does it break all sorts of things? Here this rawhide sync seems to break at least firefox. (no text in gui elements). Not that's I'm not happy to see cairo in rawhide at last. -- Nicolas Mailhot -------------- 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 jon.nettleton at gmail.com Wed Jun 22 18:28:47 2005 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Wed, 22 Jun 2005 14:28:47 -0400 Subject: Cairo [was: rawhide report: 20050621 changes] In-Reply-To: <1119464404.9395.2.camel@rousalka.dyndns.org> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> <1119428771.27240.113.camel@tarjei.predichem.nett> <1119444032.3335.14.camel@goose> <1119452774.27240.140.camel@tarjei.predichem.nett> <1119462274.10442.4.camel@localhost> <20050622201308.73f97fcf@nausicaa.camperquake.de> <1119464404.9395.2.camel@rousalka.dyndns.org> Message-ID: <1119464927.2804.1.camel@localhost> On Wed, 2005-06-22 at 20:20 +0200, Nicolas Mailhot wrote: > Le mercredi 22 juin 2005 ? 20:13 +0200, Ralf Ertzinger a ?crit : > > Hi. > > > > Jon Nettleton wrote: > > > > > test case, before and after gtk2 with cairo support. I actually think > > > so far the update feels a bit faster, however some definitive numbers > > > would be interesting. > > > > Apart from that: does it work or does it break all sorts of things? > > Here this rawhide sync seems to break at least firefox. (no text in gui > elements). Not that's I'm not happy to see cairo in rawhide at last. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list Everything is working great so far. As per an earlier email on this thread you have to go into /usr/bin/firefox and /usr/bin/mozilla and uncomment. MOZ_DISABLE_PANGO=1 export MOZ_DISABLE_PANGO Jon From ph18 at cornell.edu Wed Jun 22 18:32:44 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Wed, 22 Jun 2005 14:32:44 -0400 Subject: FC4 kernel performance In-Reply-To: <1119445167.9745.4.camel@localhost.localdomain> References: <42B94ACA.5090008@web.de> <20050622122310.GA8691@jadzia.bu.edu> <42B95F36.5010301@cornell.edu> <1119445167.9745.4.camel@localhost.localdomain> Message-ID: <42B9AECC.9010100@cornell.edu> Michael Tiemann wrote: >Paul, there are several SE Linux machines on the internet that offer you root access. >Please be the first to demonstrate that you can crack them. That way we can make them >better... > >M > > I'd love to take a look at such a system, although I don't really have the time for a serious attack. From ndbecker2 at gmail.com Wed Jun 22 19:30:40 2005 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 22 Jun 2005 15:30:40 -0400 Subject: pwdutils Message-ID: I have no experience with this project, but the from the description it sounds like an interesting addition to Fedora: http://freshmeat.net/redir/pwdutils/28999/url_homepage/pwdutils From sundaram at redhat.com Wed Jun 22 19:34:33 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 23 Jun 2005 01:04:33 +0530 Subject: pwdutils In-Reply-To: References: Message-ID: <42B9BD49.3080406@redhat.com> Neal Becker wrote: >I have no experience with this project, but the from the description it >sounds like an interesting addition to Fedora: > >http://freshmeat.net/redir/pwdutils/28999/url_homepage/pwdutils > > > The stock answer is to package it for Extras repository. So here you go http://fedoraproject.org/wiki/Extras regards Rahul From mattdm at mattdm.org Wed Jun 22 19:59:09 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 22 Jun 2005 15:59:09 -0400 Subject: pwdutils In-Reply-To: <42B9BD49.3080406@redhat.com> References: <42B9BD49.3080406@redhat.com> Message-ID: <20050622195909.GA29213@jadzia.bu.edu> On Thu, Jun 23, 2005 at 01:04:33AM +0530, Rahul Sundaram wrote: > The stock answer is to package it for Extras repository. So here you go > http://fedoraproject.org/wiki/Extras Kind of hard -- Extras packages aren't supposed to conflict with core, and this appears to be a shadow-utils replacement. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 80 degrees Fahrenheit. From sundaram at redhat.com Wed Jun 22 20:11:58 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 23 Jun 2005 01:41:58 +0530 Subject: pwdutils In-Reply-To: <20050622195909.GA29213@jadzia.bu.edu> References: <42B9BD49.3080406@redhat.com> <20050622195909.GA29213@jadzia.bu.edu> Message-ID: <42B9C60E.6010505@redhat.com> Matthew Miller wrote: >On Thu, Jun 23, 2005 at 01:04:33AM +0530, Rahul Sundaram wrote: > > >>The stock answer is to package it for Extras repository. So here you go >>http://fedoraproject.org/wiki/Extras >> >> > >Kind of hard -- Extras packages aren't supposed to conflict with core, and >this appears to be a shadow-utils replacement. > > > Time to revive Fedora Alternatives perhaps? regards Rahul From jspaleta at gmail.com Wed Jun 22 20:15:21 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 22 Jun 2005 16:15:21 -0400 Subject: pwdutils In-Reply-To: <42B9C60E.6010505@redhat.com> References: <42B9BD49.3080406@redhat.com> <20050622195909.GA29213@jadzia.bu.edu> <42B9C60E.6010505@redhat.com> Message-ID: <604aa791050622131549a87a70@mail.gmail.com> On 6/22/05, Rahul Sundaram wrote: > Time to revive Fedora Alternatives perhaps? technically it would have to have been alive once.. to be re-vived -jef From mattdm at mattdm.org Wed Jun 22 20:26:37 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 22 Jun 2005 16:26:37 -0400 Subject: pwdutils In-Reply-To: <42B9C60E.6010505@redhat.com> References: <42B9BD49.3080406@redhat.com> <20050622195909.GA29213@jadzia.bu.edu> <42B9C60E.6010505@redhat.com> Message-ID: <20050622202637.GA30334@jadzia.bu.edu> On Thu, Jun 23, 2005 at 01:41:58AM +0530, Rahul Sundaram wrote: > Time to revive Fedora Alternatives perhaps? Sure, go ahead. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 80 degrees Fahrenheit. From mpeters at mac.com Wed Jun 22 20:41:45 2005 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 22 Jun 2005 13:41:45 -0700 Subject: pwdutils In-Reply-To: <42B9C60E.6010505@redhat.com> References: <42B9BD49.3080406@redhat.com> <20050622195909.GA29213@jadzia.bu.edu> <42B9C60E.6010505@redhat.com> Message-ID: <1119472905.31557.5.camel@locolhost.localdomain> On Thu, 2005-06-23 at 01:41 +0530, Rahul Sundaram wrote: > Matthew Miller wrote: > > >On Thu, Jun 23, 2005 at 01:04:33AM +0530, Rahul Sundaram wrote: > > > > > >>The stock answer is to package it for Extras repository. So here you go > >>http://fedoraproject.org/wiki/Extras > >> > >> > > > >Kind of hard -- Extras packages aren't supposed to conflict with core, and > >this appears to be a shadow-utils replacement. > > > > > > > Time to revive Fedora Alternatives perhaps? I think so. It's a good place to test potential replacements for technology in core that can't be tested in Extras due to this very reason - conflicts. It also could potentially be used to test some neat ideas that modify core products, such as Elektra (which I think is a good idea ...) The downside is it would require infrastructure which costs money and time and the ROI for Red Hat may not be worth it. From sundaram at redhat.com Wed Jun 22 20:53:23 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 23 Jun 2005 02:23:23 +0530 Subject: pwdutils In-Reply-To: <1119472905.31557.5.camel@locolhost.localdomain> References: <42B9BD49.3080406@redhat.com> <20050622195909.GA29213@jadzia.bu.edu> <42B9C60E.6010505@redhat.com> <1119472905.31557.5.camel@locolhost.localdomain> Message-ID: <42B9CFC3.9060405@redhat.com> Hi >>Time to revive Fedora Alternatives perhaps? >> >> > >I think so. It's a good place to test potential replacements for >technology in core that can't be tested in Extras due to this very >reason - conflicts. > >It also could potentially be used to test some neat ideas that modify >core products, such as Elektra (which I think is a good idea ...) > >The downside is it would require infrastructure which costs money and >time and the ROI for Red Hat may not be worth it. > > Fedora Alternatives if ever happens would definitely be something that happens outside of Red Hat and by the community, since whatever is shipped in Core is the way Red Hat wants it to be. Just as Extras provides a way to compliment Core, Alternatives would a set of potentially disruptive but neverthless good ideas by the community and as such wouldnt have a negative impact in ROI. Ignore me. Talk is cheap ;-) regards Rahul From Nicolas.Mailhot at laPoste.net Wed Jun 22 20:54:36 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 22 Jun 2005 22:54:36 +0200 Subject: Cairo [was: rawhide report: 20050621 changes] In-Reply-To: <1119464927.2804.1.camel@localhost> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> <1119428771.27240.113.camel@tarjei.predichem.nett> <1119444032.3335.14.camel@goose> <1119452774.27240.140.camel@tarjei.predichem.nett> <1119462274.10442.4.camel@localhost> <20050622201308.73f97fcf@nausicaa.camperquake.de> <1119464404.9395.2.camel@rousalka.dyndns.org> <1119464927.2804.1.camel@localhost> Message-ID: <1119473677.10405.47.camel@rousalka.dyndns.org> Le mercredi 22 juin 2005 ? 14:28 -0400, Jon Nettleton a ?crit : > Everything is working great so far. As per an earlier email on this > thread you have to go into /usr/bin/firefox and /usr/bin/mozilla and > uncomment. > > MOZ_DISABLE_PANGO=1 > export MOZ_DISABLE_PANGO Thanks, I had missed this part Regards, -- Nicolas Mailhot -------------- 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 florin.malita at glenayre.com Wed Jun 22 21:27:27 2005 From: florin.malita at glenayre.com (Florin Malita) Date: Wed, 22 Jun 2005 17:27:27 -0400 Subject: FC4 kernel performance In-Reply-To: <20050622004756.GA27285@outblaze.com> References: <20050622004756.GA27285@outblaze.com> Message-ID: <1119475647.5901.253.camel@scox.glenatl.glenayre.com> On Tue, 2005-06-21 at 20:47 -0400, Yusuf Goolamabbas wrote: > SchillX is likely to default to debug mode > > if strings /kernel/genunix | grep 'DEBUG enabled' prints "DEBUG > enabled" then it is DEBUG > > Maybe you could compare FC4 with Solaris 10 Express 6/05 or Solaris 10 > GA The original FC4 kernel has several debug options enabled too. Regards, Florin From bernie at develer.com Thu Jun 23 00:28:43 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Thu, 23 Jun 2005 02:28:43 +0200 Subject: Single sign-on infrastructure (FC5 wish) In-Reply-To: <1119347933.3843.70.camel@endor.e.kth.se> References: <42B3B097.7060109@develer.com> <1119347933.3843.70.camel@endor.e.kth.se> Message-ID: <42BA023B.5060006@develer.com> Alexander Bostr?m wrote: >> - Heimdal's KDC, > > I have Heimdal and Arla RPM:s that I've been meaning to try to get into > Extras. See http:/ayo.sys.kth.se/kth/linux/4/i386/krbafs/ . (Binaries > for RHEL4, but the SRPMS works with FC3 at least.) I tried ARLA's Heimdal binaries before building it from sources, but they were built without the LDAP backend or something like that. By the way, integrating Heimdal in Fedora isn't as trivial as I had guessed. Heimdal's libkrb5 doesn't appear to be binary compatible with the MIT version, and many libraries such as libkrb5support and libgssapi_krb5 don't even exist. Heimdal uses a few encryptations that clients linked against the MIT libraries don't seem to support. Actually, I'm not sure how to fix this as I couldn't find clear documentation about supported encryptation methods and how to configure the server and client side to negotiate a commonly supported method. Maybe I just need to study Kerberos a bit harder. >> configured with the LDAP backend. > > I don't know how that works but I must say I'm very sceptical, mostly > from a security standpoint. What's the advantage of doing it that way? The main advantage is that you can add/remove/edit an user account and its associated security information from a single place. I was also pleased to discover that Heimdal can (ab)use NT hashes stored in sambaSamAccount objects, so I can just use "smbpasswd" or even Windows tools to edit POSIX, Samba and Kerberos passphrases at the same time. Security is just as bad as letting Samba access the LDAP database. I' musing the ldapi:// method with a socket accessible to root only. I prefer this over storing the LDAP manager password in a secret file, although ldapi doesn't allow me to split Samba, LDAP and KDC on different servers. Using SASL GSSAPI wouldn't be an option, as Kerberos can't use itself to authenticate to the LDAP service :-) >> - I couldn't get password-less IMAP to work with >> courier-imap because of limited SASL support. >> Maybe I'd be more lucky with cyrus-imap > > Cyrus-IMAPd + Heimdal and Evolution + MIT-KRB play along nicely. I use qmail as an MTA, and last time I checked cyrus-imapd didn't support Maildir. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From bernie at develer.com Thu Jun 23 00:35:20 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Thu, 23 Jun 2005 02:35:20 +0200 Subject: Single sign-on infrastructure (FC5 wish) In-Reply-To: <1119348072.3843.72.camel@endor.e.kth.se> References: <42B3B097.7060109@develer.com> <1119347933.3843.70.camel@endor.e.kth.se> <1119348072.3843.72.camel@endor.e.kth.se> Message-ID: <42BA03C8.10102@develer.com> Alexander Bostr?m wrote: > tis 2005-06-21 klockan 11:58 +0200 skrev Alexander Bostr?m: > >>l?r 2005-06-18 klockan 07:26 +0200 skrev Bernardo Innocenti: >> >> >>> - Heimdal's KDC, >> >>I have Heimdal and Arla RPM:s that I've been meaning to try to get into >>Extras. See http:/ayo.sys.kth.se/kth/linux/4/i386/krbafs/ . (Binaries >>for RHEL4, but the SRPMS works with FC3 at least.) > > Or http://www.stacken.kth.se/projekt/arla/redhat.html I hope these packages can at least get in extras. I was lucky enough to find them by googling around. SuSE 9.x shipped with Heimdal 0.6.x instead of MIT's Kerberos. Now it seems in SuSE 9.3 they've reverted to MIT. I don't know why they did that, but I'd like to check their RPM source package to see if they added those Novell patches for NT compatibility. I've seen some slides where these enhancements were mentioned as important missing bits towards full ActiveDirectory controller support in Samba. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From bernie at develer.com Thu Jun 23 00:43:43 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Thu, 23 Jun 2005 02:43:43 +0200 Subject: Single sign-on infrastructure (FC5 wish) In-Reply-To: <1119430199.2340.19.camel@localhost.localdomain> References: <42B3B097.7060109@develer.com> <1119347933.3843.70.camel@endor.e.kth.se> <1119430199.2340.19.camel@localhost.localdomain> Message-ID: <42BA05BF.2030900@develer.com> Mike MacCana wrote: > On Tue, 2005-06-21 at 10:11 -0500, Jason L Tibbitts III wrote: > >>A single replication infrastructure. I use the MIT KDC because it's >>what Red Hat happens to ship, but I'd much rather have everything in >>LDAP instead of having two separate systems to configure and maintain. > > So Heimdal can use an LDAP data store? Sweet. Thanks so much for your > post. Works fine here, except Heimdal keeps creating its krb5Principal under the root node instead of folding them into ou=KerberosPrincipals as I told in the config file. > I've wanted MIT krb5 to do this (in a non hacky way) for ages. Novell says they've contributed this to MIT, but I can't see it in their CVS repository yet. > Can Heimdal do Kerberos over TCP, and does it support MS specific > encryption types, like MIT Kerberos does? A quick check with netstat appears to confirm it also listens to TCP ports. MS encryptation support is the main reason I switched to Heimdal. I thought MIT still refused to add Microsoft's "extensions" for ethical reasons... I'm surprised to hear they're now implemented. But what I like the most about Heimdal is that kadmin uses readline for proper history and line editing support. and also uses nicer names for commands :-) -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From bernie at develer.com Thu Jun 23 01:10:29 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Thu, 23 Jun 2005 03:10:29 +0200 Subject: Single sign-on infrastructure (FC5 wish) In-Reply-To: <42B939BB.2090603@iee.lu> References: <42B3B097.7060109@develer.com> <1119347933.3843.70.camel@endor.e.kth.se> <1119430199.2340.19.camel@localhost.localdomain> <42B939BB.2090603@iee.lu> Message-ID: <42BA0C05.3020907@develer.com> Charles Lopes wrote: >> So Heimdal can use an LDAP data store? Sweet. Thanks so much for your >> post. I've wanted MIT krb5 to do this (in a non hacky way) for ages. >> >> > A data abstraction layer (DAL) patch that does just that has been just > been committed to the cvs of MIT KDC. I just did a "cvs update" from MIT's repository and... yes! Now it's there. But where is the LDAP backend? Does one exist yet? Does it work already? Is it compatible is it with Heimdal's hdb.schema? (ok, too many questions :-) > Also I believe heimdal can (or will be able to) use the LDAP attribute > "sambaNTPassword" as a arcfour-hmac-md5 kerberos key. I haven't tried > MIT KDC+DAL (or heimdal for that matter) but I guess that the raison > d'?tre of DAL being its possible use alongside future versions of samba, > it's likely to support the same feature. Looking at Samba 4 sources, and reading around posts by Andrew Tridgell, it seems the focus for Samba isn't to interoperate with OpenLDAP and Heimdal (or MIT). Instead, they're integrating some parts of Heimdal and rewriting a lightweight LDAP server with as much functionality as it's needed for ADS support. Andrew says that 99% of sites just want to get the ActiveDirectory domain controller to work and don't know or care anything about full blown Kerberos and LDAP servers. I think he's basically right, altough I'm one of those 1% users who would be hit by this route of action. > In a related note, my hardest headache is renewing keys for users that > have home directories access via NFS4+krb5. We could not get > "gnome-kerberos" or "xscreensaver" to do it, so we keep a terminal > window open so that kinit can be run there. Am I missing something? So someone actually got NFS4 + GSSAPI to work!!! Could you please elaborate? I went through applying CITI's kernel and userland patches, with very little luck. > Also is the new kernel keyring facility planned for FC5 inclusion? Shouldn't that patch first be submitted to a kernel maintainer? Last time I checked, outstanding NFSv4 patches were (slowly) being included in official kernels through -mm. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From rodd at clarkson.id.au Thu Jun 23 01:33:14 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Thu, 23 Jun 2005 11:33:14 +1000 Subject: Cairo [was: rawhide report: 20050621 changes] In-Reply-To: <1119464927.2804.1.camel@localhost> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> <1119428771.27240.113.camel@tarjei.predichem.nett> <1119444032.3335.14.camel@goose> <1119452774.27240.140.camel@tarjei.predichem.nett> <1119462274.10442.4.camel@localhost> <20050622201308.73f97fcf@nausicaa.camperquake.de> <1119464404.9395.2.camel@rousalka.dyndns.org> <1119464927.2804.1.camel@localhost> Message-ID: <1119490395.3313.5.camel@jellyfish.redfishdemo.com> On Wed, 2005-06-22 at 14:28 -0400, Jon Nettleton wrote: > Everything is working great so far. As per an earlier email on this > thread you have to go into /usr/bin/firefox and /usr/bin/mozilla and > uncomment. > > MOZ_DISABLE_PANGO=1 > export MOZ_DISABLE_PANGO Thanks for the tip Jon, One thing. Could you point me to this 'eariler email' as I can't seem to find it in my email of either fedora-devel or fedora-test. I'm just curious to read the entire message. Rodd -- "It's a fine line between denial and faith. It's much better on my side" From tibbs at math.uh.edu Thu Jun 23 01:35:32 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 22 Jun 2005 20:35:32 -0500 Subject: Single sign-on infrastructure (FC5 wish) In-Reply-To: <42BA0C05.3020907@develer.com> (Bernardo Innocenti's message of "Thu, 23 Jun 2005 03:10:29 +0200") References: <42B3B097.7060109@develer.com> <1119347933.3843.70.camel@endor.e.kth.se> <1119430199.2340.19.camel@localhost.localdomain> <42B939BB.2090603@iee.lu> <42BA0C05.3020907@develer.com> Message-ID: >>>>> "BI" == Bernardo Innocenti writes: [kernel keyring] BI> Shouldn't that patch first be submitted to a kernel maintainer? As far as I know it already has. But Red Hat has many times in the past been known to incorporate locally-developed bits previous to their inclusion in the mainline kernel. - J< From bernie at develer.com Thu Jun 23 01:45:36 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Thu, 23 Jun 2005 03:45:36 +0200 Subject: FC4 kernel performance In-Reply-To: <1119378036.12067.7.camel@dch.TQMcube.com> References: <1119368638.5902.174.camel@scox.glenatl.glenayre.com> <20050621154755.GC21723@redhat.com> <1119370102.2475.37.camel@dch.TQMcube.com> <20050621173932.GA30669@jadzia.bu.edu> <1119378036.12067.7.camel@dch.TQMcube.com> Message-ID: <42BA1440.9090403@develer.com> David Cary Hart wrote: > Nah. The end result is the same. The difference is that making the > src.rpm in FC4 creates a source tree that can be moved to /usr/src. > Making the src.rpm in FC3 (with only source rpm selected in the spec) > creates a source.rpm > > The issue is portability which is a tarball in FC4 vs an rpm in FC3. I > just think that creating an rpm is more consistent with the Fedora > approach. I second this. Building custom kernels from the src rpm is a tedious operation that requires too many steps to be carried out manually. Besides, I also noticed the terrible performance hit of using stock kernels, so I'm forced to build custom kernels at least for server machines. Anecdotal report: my users reported poor NFS and Samba operation over the Gigabit LAN. I measured the ping time between my desktop and the server: ~0.200ms. I rebooted my desktop with a lean custom kernel: ~0.150ms. Then I also built a lean kernel for the server: now I get ping times of ~0.100ms, and NFS throughput is only limited by the speed of the RAID array (~52MB/s) or the buffer cache (~100MB/s). -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From rodd at clarkson.id.au Thu Jun 23 01:46:43 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Thu, 23 Jun 2005 11:46:43 +1000 Subject: Cairo [was: rawhide report: 20050621 changes] In-Reply-To: <1119452774.27240.140.camel@tarjei.predichem.nett> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> <1119428771.27240.113.camel@tarjei.predichem.nett> <1119444032.3335.14.camel@goose> <1119452774.27240.140.camel@tarjei.predichem.nett> Message-ID: <1119491204.3313.17.camel@jellyfish.redfishdemo.com> On Wed, 2005-06-22 at 17:06 +0200, Tarjei Knapstad wrote: > I would be highly surprised if this wasn't a design > goal in Cairo given that all hardware accelerated graphics currently > require the use of proprietary drivers (99.9% anyway...) which most of > the FOSS community seems to bark at. Yeah, this lack of hardware acceleration in non-proprietary drivers is what has got me worried. NVIDIA seem to be doing an okay job with their driver (a lot more could be done) and ATI seem to be struggling to produce a driver too. And both of these are non-free and therefor not able to be included with FEDORA. I'd like to add to the wish list for FC5 at this point. If cairo is going to become a part of FC5, then I'd like to see more work put into producing FOSS drivers to support hardware acceleration out of the box. R. PS. This is a big ask for two reasons. Firstly, I don't code (I contribute time in other ways) so I can't really help out here (except with testing), and secondly, I realize that this is a big ask. - R. -- "It's a fine line between denial and faith. It's much better on my side" From bernie at develer.com Thu Jun 23 01:51:00 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Thu, 23 Jun 2005 03:51:00 +0200 Subject: FC4 kernel performance In-Reply-To: <1119369245.3569.8.camel@nexus.verbum.private> References: <1119368638.5902.174.camel@scox.glenatl.glenayre.com> <1119369245.3569.8.camel@nexus.verbum.private> Message-ID: <42BA1584.6010209@develer.com> Colin Walters wrote: > On Tue, 2005-06-21 at 11:43 -0400, Malita, Florin wrote: > Ah, but is Unixbench a relevant benchmark for a desktop? For example > making process creation 15% faster isn't very useful if process creation > accounts for .001% of application startup time. Depends what you do on your desktop. Running init and cron scripts, building auto-tooled projects, and many other common activities result in several thousands short-lived processes being created. Don't we want to end up like Win32, where they're forced to use a broken threading model just because CreateProcessEx() is damn slow? :-) -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From rodd at clarkson.id.au Thu Jun 23 01:54:34 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Thu, 23 Jun 2005 11:54:34 +1000 Subject: FC4 kernel performance In-Reply-To: <1119462107.3295.3.camel@rousalka.dyndns.org> References: <42B94ACA.5090008@web.de> <20050622122310.GA8691@jadzia.bu.edu> <42B9A08F.4010806@web.de> <1119462107.3295.3.camel@rousalka.dyndns.org> Message-ID: <1119491674.3313.24.camel@jellyfish.redfishdemo.com> On Wed, 2005-06-22 at 19:41 +0200, Nicolas Mailhot wrote: > Le mercredi 22 juin 2005 ? 19:31 +0200, Marcus Hartig a ?crit : > > > For a private Linux user who uses only a GIMP, firefox, evince, Ooo, > > thunderbird and some games and with no important data on the disk, there > > is no need for special security things, RAID and Co. in times of cheap > > DVD burners to secure data. > > ROFL. You really think your typical user will do regular backups ? > Hardware availability means nothing - cd burners proved it. RAID is good > because it's painless security (and I know it's not the same thing but > at least once it's here it needs no human intervention at all) While I agree with you about users not backing up I don't see how raid helps in this situation. I'm assuming you're talking about some sort of redundant raid (for protecting data), and not striped raid (for speed improvements). While this is nice for situations where a HDD might fail, I don't see how this offers security in terms of data damage based on viruses, worms, malware or intrusions. It doesn't matter how many 'redundant' drives you have if they all carry (in essence) the same information. Two buggers copies of the same file are stiff two buggered copies. Rodd -- "It's a fine line between denial and faith. It's much better on my side" From jon.nettleton at gmail.com Thu Jun 23 02:08:18 2005 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Wed, 22 Jun 2005 22:08:18 -0400 Subject: Cairo [was: rawhide report: 20050621 changes] In-Reply-To: <1119490395.3313.5.camel@jellyfish.redfishdemo.com> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> <1119428771.27240.113.camel@tarjei.predichem.nett> <1119444032.3335.14.camel@goose> <1119452774.27240.140.camel@tarjei.predichem.nett> <1119462274.10442.4.camel@localhost> <20050622201308.73f97fcf@nausicaa.camperquake.de> <1119464404.9395.2.camel@rousalka.dyndns.org> <1119464927.2804.1.camel@localhost> <1119490395.3313.5.camel@jellyfish.redfishdemo.com> Message-ID: <1119492498.2859.6.camel@localhost> On Thu, 2005-06-23 at 11:33 +1000, Rodd Clarkson wrote: > On Wed, 2005-06-22 at 14:28 -0400, Jon Nettleton wrote: > > > Everything is working great so far. As per an earlier email on this > > thread you have to go into /usr/bin/firefox and /usr/bin/mozilla and > > uncomment. > > > > MOZ_DISABLE_PANGO=1 > > export MOZ_DISABLE_PANGO > > > Thanks for the tip Jon, > > One thing. Could you point me to this 'eariler email' as I can't seem > to find it in my email of either fedora-devel or fedora-test. > > I'm just curious to read the entire message. > > > Rodd > -- > "It's a fine line between denial and faith. > It's much better on my side" > For the life of me I can't find it either....perhaps it was a moment of divine intervention? I guess I should have done the smart thing and referenced the original email on my first reply. Anyone else out there read the thread that originally gave this tip? Jon From mikem at cyber.com.au Thu Jun 23 03:02:53 2005 From: mikem at cyber.com.au (Mike MacCana) Date: Thu, 23 Jun 2005 13:02:53 +1000 Subject: Cairo [was: rawhide report: 20050621 changes] In-Reply-To: <604aa7910506220608654697da@mail.gmail.com> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> <1119428771.27240.113.camel@tarjei.predichem.nett> <604aa791050622054157a6fc07@mail.gmail.com> <20050622145938.65d84544@nausicaa.camperquake.de> <604aa7910506220608654697da@mail.gmail.com> Message-ID: <1119495774.2316.6.camel@localhost.localdomain> On Wed, 2005-06-22 at 09:08 -0400, Jeff Spaleta wrote: > On 6/22/05, Ralf Ertzinger wrote: > > Are you sure you wanted to say that? > > i said "might" ... Yeah, but more to the point, you said it might be faster 'without' hardware accelerated graphics...that's why he's asking. Mike From m.f.h at web.de Thu Jun 23 04:28:25 2005 From: m.f.h at web.de (Marcus Hartig) Date: Thu, 23 Jun 2005 06:28:25 +0200 Subject: Cairo [was: rawhide report: 20050621 changes] In-Reply-To: <1119491204.3313.17.camel@jellyfish.redfishdemo.com> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> <1119428771.27240.113.camel@tarjei.predichem.nett> <1119444032.3335.14.camel@goose> <1119452774.27240.140.camel@tarjei.predichem.nett> <1119491204.3313.17.camel@jellyfish.redfishdemo.com> Message-ID: <42BA3A69.1010207@web.de> Rodd Clarkson wrote: > I'd like to add to the wish list for FC5 at this point. If cairo is > going to become a part of FC5, then I'd like to see more work put into > producing FOSS drivers to support hardware acceleration out of the box. A dream? And where do you take the specs fropm? nVidia will not and can not release their driver/GPU specs for developing an open source driver with all features. But they make a very good job with their own linux driver. Ati? Regards, Marcus From mattdm at mattdm.org Thu Jun 23 04:35:35 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 23 Jun 2005 00:35:35 -0400 Subject: FC4 kernel performance In-Reply-To: <1119378036.12067.7.camel@dch.TQMcube.com> References: <1119368638.5902.174.camel@scox.glenatl.glenayre.com> <20050621154755.GC21723@redhat.com> <1119370102.2475.37.camel@dch.TQMcube.com> <20050621173932.GA30669@jadzia.bu.edu> <1119378036.12067.7.camel@dch.TQMcube.com> Message-ID: <20050623043535.GA16776@jadzia.bu.edu> On Tue, Jun 21, 2005 at 02:20:36PM -0400, David Cary Hart wrote: > > This has been rehashed a zillion times, but the short answer is that it's > > not really any good, since the resulting source tree isn't necessarily > > "clean" for the build architecture you expect. Tweaking the source rpm is a > > bit more learning and a tiny bit more work upfront, but it makes management > > easier (worth sometime) and produces more correct results (priceless). > Nah. The end result is the same. The difference is that making the Yeah? Which architecture conditionals do you end up with in your source tree? > src.rpm in FC4 creates a source tree that can be moved to /usr/src. > Making the src.rpm in FC3 (with only source rpm selected in the spec) > creates a source.rpm "rpmbuild -bp" if you really need that for some reason. > The issue is portability which is a tarball in FC4 vs an rpm in FC3. I > just think that creating an rpm is more consistent with the Fedora > approach. Yes, and it's not the approach just to inconvenience people. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 80 degrees Fahrenheit. From mattdm at mattdm.org Thu Jun 23 04:35:55 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 23 Jun 2005 00:35:55 -0400 Subject: FC4 kernel performance In-Reply-To: <42BA1440.9090403@develer.com> References: <1119368638.5902.174.camel@scox.glenatl.glenayre.com> <20050621154755.GC21723@redhat.com> <1119370102.2475.37.camel@dch.TQMcube.com> <20050621173932.GA30669@jadzia.bu.edu> <1119378036.12067.7.camel@dch.TQMcube.com> <42BA1440.9090403@develer.com> Message-ID: <20050623043555.GA16636@jadzia.bu.edu> On Thu, Jun 23, 2005 at 03:45:36AM +0200, Bernardo Innocenti wrote: > I second this. Building custom kernels from the src rpm is > a tedious operation that requires too many steps to be carried > out manually. Only if you're doing it wrong. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 80 degrees Fahrenheit. From rodd at clarkson.id.au Thu Jun 23 05:45:17 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Thu, 23 Jun 2005 15:45:17 +1000 Subject: Cairo [was: rawhide report: 20050621 changes] In-Reply-To: <42BA3A69.1010207@web.de> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> <1119428771.27240.113.camel@tarjei.predichem.nett> <1119444032.3335.14.camel@goose> <1119452774.27240.140.camel@tarjei.predichem.nett> <1119491204.3313.17.camel@jellyfish.redfishdemo.com> <42BA3A69.1010207@web.de> Message-ID: <1119505517.3234.29.camel@jellyfish.redfishdemo.com> On Thu, 2005-06-23 at 06:28 +0200, Marcus Hartig wrote: > Rodd Clarkson wrote: > > > I'd like to add to the wish list for FC5 at this point. If cairo is > > going to become a part of FC5, then I'd like to see more work put into > > producing FOSS drivers to support hardware acceleration out of the box. > > A dream? To dream, the impossible dream. To fight the unbeatable foe etc. > And where do you take the specs fropm? nVidia will not and can not > release their driver/GPU specs for developing an open source driver with > all features. > But they make a very good job with their own linux driver. Yeah, there's not denying that this would be a very hard thing to do. I'm well aware of it. I'm pretty sure I mentioned that it was a "big ask" in my email. I don't actually think that NVIDIA do that good a job. If they supplied the same sort of 'enthusiasm' they do to their Linux drivers to their Windows drivers they'd be bankrupt in no time at all. While I won't expect them to be on the bleeding edge, they are usually two or three steps behind. As one example, support for a change in the stacks in the kernel (from 4k to 8k or the other way around) too forever. This was a huge inconvenience for many, and while I don't think the should be following the ebb and flow of each and every distro's development cycle the example above was inevitable regardless of the distro. It would be like them saying we'll wait and see what Microsoft releases before we put out our next driver. (Yeah right). I they wish to treat Linux as a second class citizen then they can, but it doesn't mean that I have to think they are doing a good job. They could certainly do better. > Ati? Same goes for ATI. The recently released driver (as far as I'm aware) doesn't compile of GCC4. Again, this isn't a distro specific thing, it's just an inevitability. So why don't the new drivers support it? On the bright side, there is some moves to produce a open source driver for RADEON cards. http://r300.sourceforge.net/ "This site was created to document our progress in understanding R300 3d acceleration engine. (R300 is a family of cards made by ATI, in particular it includes Radeon 9700 cards and Mobility M10 cards used in notebooks). We are also interested in earlier and later Radeon hardware." I haven't been able to test because it needs a recent version of Xorg from CVS and there is problems getting the patches to apply to current kernels, but the author is reporting good results. So there is some light at the end of the tunnel. Rodd -- "It's a fine line between denial and faith. It's much better on my side" From dwmw2 at infradead.org Thu Jun 23 07:30:07 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 23 Jun 2005 08:30:07 +0100 Subject: FC4 kernel performance In-Reply-To: <20050622134614.GB609975@hiwaay.net> References: <42B94ACA.5090008@web.de> <1119440497.5712.54.camel@localhost.localdomain> <42B96147.8040102@cornell.edu> <64458.192.54.193.35.1119446072.squirrel@rousalka.dyndns.org> <20050622134614.GB609975@hiwaay.net> Message-ID: <1119511808.5580.34.camel@localhost.localdomain> On Wed, 2005-06-22 at 08:46 -0500, Chris Adams wrote: > Some type of "journalling RAID" would be a possible solution (and > would also allow for much faster re-syncs on unclean shutdown, as only > the last written blocks would need updating). This is why RAID is entirely the wrong answer, and redundancy should be implemented in the file system itself, instead of being hacked into the block layer. This isn't DOS. We don't have to shoe-horn RAID into the INT 13h handler so that the FAT file system code can cope with it. -- dwmw2 From nicolas.mailhot at laposte.net Thu Jun 23 07:58:53 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 23 Jun 2005 09:58:53 +0200 (CEST) Subject: FC4 kernel performance In-Reply-To: <1119511808.5580.34.camel@localhost.localdomain> References: <42B94ACA.5090008@web.de> <1119440497.5712.54.camel@localhost.localdomain> <42B96147.8040102@cornell.edu> <64458.192.54.193.35.1119446072.squirrel@rousalka.dyndns.org> <20050622134614.GB609975@hiwaay.net> <1119511808.5580.34.camel@localhost.localdomain> Message-ID: <28701.192.54.193.25.1119513533.squirrel@rousalka.dyndns.org> On Jeu 23 juin 2005 09:30, David Woodhouse wrote: > On Wed, 2005-06-22 at 08:46 -0500, Chris Adams wrote: >> Some type of "journalling RAID" would be a possible solution (and >> would also allow for much faster re-syncs on unclean shutdown, as only >> the last written blocks would need updating). > > This is why RAID is entirely the wrong answer, and redundancy should be > implemented in the file system itself, instead of being hacked into the > block layer. Can't this be done today with something that takes lvm snapshots each night ? Regards, -- Nicolas Mailhot From tjarls at iee.lu Thu Jun 23 10:52:18 2005 From: tjarls at iee.lu (Charles Lopes) Date: Thu, 23 Jun 2005 12:52:18 +0200 Subject: Single sign-on infrastructure (FC5 wish) In-Reply-To: <42BA0C05.3020907@develer.com> References: <42B3B097.7060109@develer.com> <1119347933.3843.70.camel@endor.e.kth.se> <1119430199.2340.19.camel@localhost.localdomain> <42B939BB.2090603@iee.lu> <42BA0C05.3020907@develer.com> Message-ID: <42BA9462.1000307@iee.lu> Bernardo Innocenti wrote: >Charles Lopes wrote: > > > >>>So Heimdal can use an LDAP data store? Sweet. Thanks so much for your >>>post. I've wanted MIT krb5 to do this (in a non hacky way) for ages. >>> >>> >>> >>> >>A data abstraction layer (DAL) patch that does just that has been just >>been committed to the cvs of MIT KDC. >> >> > >I just did a "cvs update" from MIT's repository and... yes! >Now it's there. > >But where is the LDAP backend? Does one exist yet? Does it work >already? Is it compatible is it with Heimdal's hdb.schema? > >(ok, too many questions :-) > > > I checked the cvs and the code imported after the tag trunk-before-novell-dal-merge seems to be about thread support. I guess it's only the first part of the code. > > >>Also I believe heimdal can (or will be able to) use the LDAP attribute >>"sambaNTPassword" as a arcfour-hmac-md5 kerberos key. I haven't tried >>MIT KDC+DAL (or heimdal for that matter) but I guess that the raison >>d'?tre of DAL being its possible use alongside future versions of samba, >>it's likely to support the same feature. >> >> > >Looking at Samba 4 sources, and reading around posts by >Andrew Tridgell, it seems the focus for Samba isn't to >interoperate with OpenLDAP and Heimdal (or MIT). > >Instead, they're integrating some parts of Heimdal and rewriting >a lightweight LDAP server with as much functionality as it's >needed for ADS support. > >Andrew says that 99% of sites just want to get the ActiveDirectory >domain controller to work and don't know or care anything about >full blown Kerberos and LDAP servers. > >I think he's basically right, altough I'm one of those 1% users >who would be hit by this route of action. > > > > I seem to remember some discussion about the fear of forking heimdal and how the import of its code in samba4 was going to be temporary. That position must have changed then. >>In a related note, my hardest headache is renewing keys for users that >>have home directories access via NFS4+krb5. We could not get >>"gnome-kerberos" or "xscreensaver" to do it, so we keep a terminal >>window open so that kinit can be run there. Am I missing something? >> >> > >So someone actually got NFS4 + GSSAPI to work!!! Could you please >elaborate? I went through applying CITI's kernel and userland >patches, with very little luck. > > > I didn't have to apply any patches to get it working, although I had to edit /etc/gssapi_mech.conf and change /usr/lib/libgssapi_krb5.so into /usr/lib/libgssapi_krb5.so.2 (bug #151251). The rest seems to work out of the box if you have the proper keys in /etc/krb5.keytab and SECURE_NFS=y in /etc/sysinit/nfs. It's only recently that I picked up the CITI kernel patches to see if they would fix the frequent rpciod freezes I have been experiencing with kernel 2.6.11-1.1369_FC4. And indeed, they seem to have fixed that problem. Just out of curiousity, are there any further patches for nfs-utils that are not included in FC3/4? If so what do they do? >>Also is the new kernel keyring facility planned for FC5 inclusion? >> >> > >Shouldn't that patch first be submitted to a kernel maintainer? >Last time I checked, outstanding NFSv4 patches were (slowly) >being included in official kernels through -mm. > > Indeed, that's why I was asking. I guess I really meant to ask if anyone knew if it was going to be mature enough to be included upstream before FC5 was out. From hvreddy1110 at gmail.com Thu Jun 23 11:17:10 2005 From: hvreddy1110 at gmail.com (harshavardhanreddy mandeepala) Date: Thu, 23 Jun 2005 16:47:10 +0530 Subject: Problem in Creation of RPM Message-ID: <1dd5960805062304177b24925a@mail.gmail.com> Hi, I am using Linux Fedora Core 3. I have created a RPM file for my Application. But how can i make the files in RPM Should go into specific directory after installing the RPM into the system. For example if my RPM contains files like abc,ghj,jkl,kjh. Then After installing my RPM into Linux system the file abc should store in a apecific directory(/home/guest/),and for jkl,kjh also in some other directory. so if u have a solution plz send it to hvreddy1110 at gmail.com thanks in advance. Regards Harshavardhan reddy M From hvreddy1110 at gmail.com Thu Jun 23 11:46:22 2005 From: hvreddy1110 at gmail.com (harshavardhanreddy mandeepala) Date: Thu, 23 Jun 2005 17:16:22 +0530 Subject: Problem related to RPM creation Message-ID: <1dd59608050623044653a99cbf@mail.gmail.com> Hi, I am using Linux Fedora Core 3. I have created a RPM file for my Application. But how can i make the files in RPM Should go into specific directory after installing the RPM into the system. For example if my RPM contains files like myapp1,myapp2,myapp3.. Then After installing my RPM into Linux system the file myapp1 should store in a apecific directory(/home/guest/),and for myapp2,myapp3 also in some other directory. Any changes we need to make in .spec file to provide path for our required files or any more. so if u have a solution plz send it to hvreddy1110 at gmail.com thanks in advance. Regards Harshavardhan reddy M From mattdm at mattdm.org Thu Jun 23 12:37:08 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 23 Jun 2005 08:37:08 -0400 Subject: Problem in Creation of RPM In-Reply-To: <1dd5960805062304177b24925a@mail.gmail.com> References: <1dd5960805062304177b24925a@mail.gmail.com> Message-ID: <20050623123708.GA27405@jadzia.bu.edu> On Thu, Jun 23, 2005 at 04:47:10PM +0530, harshavardhanreddy mandeepala wrote: > I am using Linux Fedora Core 3. > I have created a RPM file for my Application. > But how can i make the files in RPM Should go into specific directory > after installing the RPM into the system. > For example if my RPM contains files like abc,ghj,jkl,kjh. > Then After installing my RPM into Linux system the file abc should > store in a apecific directory(/home/guest/),and for jkl,kjh also in some other > directory. > so if u have a solution plz send it to hvreddy1110 at gmail.com This isn't a particular puzzle -- it's a basic part of making an RPM. (Although, RPMs shouldn't put files in /home, generally.) Have you read the RPM guide from ? It may help you. PS: no need to post twice. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 80 degrees Fahrenheit. From nutello at sweetness.com Thu Jun 23 12:51:36 2005 From: nutello at sweetness.com (Rudi Chiarito) Date: Thu, 23 Jun 2005 14:51:36 +0200 Subject: Cairo [was: rawhide report: 20050621 changes] In-Reply-To: <20050622201308.73f97fcf@nausicaa.camperquake.de> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> <1119428771.27240.113.camel@tarjei.predichem.nett> <1119444032.3335.14.camel@goose> <1119452774.27240.140.camel@tarjei.predichem.nett> <1119462274.10442.4.camel@localhost> <20050622201308.73f97fcf@nausicaa.camperquake.de> Message-ID: <20050623125135.GA17967@plain.rackshack.net> On Wed, Jun 22, 2005 at 08:13:08PM +0200, Ralf Ertzinger wrote: > Apart from that: does it work or does it break all sorts of things? In addition to the Firefox problem already reported, I noticed differences in font rendering - but then I am one of those whiners that complain about Arial being a cheap imitation of Helvetica. The panel seems to have hinting enabled, even if it's disabled in my preferences. I use non-standard fonts and they look much better if no hints are applied. You can see the same with Bitstream Charter (part of fonts-xorg-base). The second curious thing I noticed is that changes in hinting in the font preferences are not reflected on screen in realtime as they used to. Actually, #2 might be the explanation for #1: is hinting enabled by default, if gconfd is not running yet? It could be that the panel gets started before gconfd and thus gets stuck with whatever are the defaults for font hinting (the font family is right, though). -- Rudi From jspaleta at gmail.com Thu Jun 23 13:15:07 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 23 Jun 2005 09:15:07 -0400 Subject: Cairo [was: rawhide report: 20050621 changes] In-Reply-To: <20050623125135.GA17967@plain.rackshack.net> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> <1119428771.27240.113.camel@tarjei.predichem.nett> <1119444032.3335.14.camel@goose> <1119452774.27240.140.camel@tarjei.predichem.nett> <1119462274.10442.4.camel@localhost> <20050622201308.73f97fcf@nausicaa.camperquake.de> <20050623125135.GA17967@plain.rackshack.net> Message-ID: <604aa79105062306153ae40667@mail.gmail.com> On 6/23/05, Rudi Chiarito wrote: > The panel seems to have hinting enabled, even if it's disabled in my > preferences. I use non-standard fonts and they look much better if no > hints are applied. You can see the same with Bitstream Charter (part of > fonts-xorg-base). > > The second curious thing I noticed is that changes in hinting in the > font preferences are not reflected on screen in realtime as they used > to. Actually, #2 might be the explanation for #1: is hinting enabled by > default, if gconfd is not running yet? It could be that the panel gets > started before gconfd and thus gets stuck with whatever are the defaults > for font hinting (the font family is right, though). I'd love to see a screenshot.. preferable marked up.. showing the pamel problem as compared to the application font hinting. -jef From sds at tycho.nsa.gov Thu Jun 23 13:36:19 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 23 Jun 2005 09:36:19 -0400 Subject: FC4 kernel performance In-Reply-To: <42B9AAE2.2020500@cornell.edu> References: <42B94ACA.5090008@web.de> <20050622122310.GA8691@jadzia.bu.edu> <42B95F36.5010301@cornell.edu> <1119446162.13181.29.camel@moss-spartans.epoch.ncsc.mil> <42B9AAE2.2020500@cornell.edu> Message-ID: <1119533779.28493.67.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2005-06-22 at 14:16 -0400, Paul A Houle wrote: > Well, I'll believe it after we've had a few years of experience > with it. > > Windows NT has a 'richer' security model than the traditional Unix > model, but nobody uses it. Nobody knows how, and more to the point, > everything that an application has to work with in Windows NT doesn't > use the security features it has, so it's hard for one site or one > application to start doing things differently. 'Richer' security model doesn't equate to mandatory access control. The latter is necessary to confine malicious and flawed applications. The former often does just complicate administration with no real benefit in security. > SELinux is going to require a whole ecosystem of tools that work > together, or it's just going to put more of Fedora in the "it just > doesn't work" category. SELinux provides the infrastructure and APIs for security-aware applications, so it provides the right foundation for building such an ecosystem. Too many other kernel security enhancements try to ignore the role of applications in providing overall system security altogether. > For all the limitation of the UNIX model, people understand it. > They're afraid of root, and raw fear is a good motivator. I remember > VMS having tens of different permissions that a process could have, and > people finding privilege escalation attacks all the time. Don't confuse finer-grained security (by itself) with MAC, and don't confuse a privilege mechanism (aka POSIX/Linux capabilities) with MAC. Yes, SELinux provides a way to control the privileges defined by Linux capabilities and bind them to specific programs, but that is only a small part of what MAC enables. > Yeah, but I want thunderbird to have a lot of access to my files. > I want to be able to send an arbitrary file as an attachment, and I'd > like to be able to save files from it easily. (Yeah, you might > restrict it to 'save to the desktop' but once a lot of apps are > restricted the way, everything is on the desktop. You might block off > most network ports, but it still needs to make port 25 connections to > the outbound mail server -- which is what it needs to infect other > computers. You might lock it down so it can only talk to my official > outbound mail server, but then I can't use the GUI to configure my mail > application. Yes, what you can achieve directly via the OS controls may be limited to very coarse-grained distinctions. But you still need those OS-level controls both to even provide those coarse-grained distinctions and to support and protect higher level application security functionality. And you need the proper security labeling of the data so that higher level security functionality can make sensible decisions about how to handle the data. > It's not enough to have a system which is 'tough', we need a system > that's flexible enough that people can do 'the right thing' in a way > that isn't painful. If it's painful, or even difficult to understand > for average ordinary people, people are just going to configure SELinux > in ways that are unsafe so that things 'just work', and we're back > where we started, probably worse, because people have a false sense of > security. SELinux is flexible, and the fact that there are already strict, targeted, and mls policies for it demonstrates that flexibility. As to ease of use for "average ordinary" people, we're not there yet, but we have the right foundation on which to build, and the SELinux community is working toward that goal. > Finding that kind of intersection is difficult -- if you can do it, > my hats are off to you. I can SELinux being of interest for specialized > applications (desktops at the NSA? server appliances?) but i'll be hard > pressed to become an expert on SELinux so I can get my regular work done. And I agree that you shouldn't have to be an expert on SELinux to do your regular work. There is ongoing work to enable SELinux to be effectively deployed and used without such expertise, but we have to walk before we can run. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Thu Jun 23 13:37:33 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 23 Jun 2005 09:37:33 -0400 Subject: FC4 kernel performance In-Reply-To: <42B9AECC.9010100@cornell.edu> References: <42B94ACA.5090008@web.de> <20050622122310.GA8691@jadzia.bu.edu> <42B95F36.5010301@cornell.edu> <1119445167.9745.4.camel@localhost.localdomain> <42B9AECC.9010100@cornell.edu> Message-ID: <1119533853.28493.70.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2005-06-22 at 14:32 -0400, Paul A Houle wrote: > Michael Tiemann wrote: > > >Paul, there are several SE Linux machines on the internet that offer you root access. > >Please be the first to demonstrate that you can crack them. That way we can make them > >better... > > > >M > > > > > I'd love to take a look at such a system, although I don't really > have the time for a serious attack. I have doubts about such play machines except as a learning tool, but if you are interested, Russell Coker has a SELinux play machine available with information at: http://www.coker.com.au/selinux/play.html -- Stephen Smalley National Security Agency From hvreddy1110 at gmail.com Thu Jun 23 13:51:22 2005 From: hvreddy1110 at gmail.com (harshavardhanreddy mandeepala) Date: Thu, 23 Jun 2005 19:21:22 +0530 Subject: how to assign full access rights to guest Message-ID: <1dd5960805062306517908ed77@mail.gmail.com> hi I am using Linux fedora core 3. I want to shutdown the system from .bash_profile file using cd /sbin ./shutdown -g o but when I run the file otherthan a superuser it is giving error message as " to run "shutdown" u must be a root" but i want to execute shutdown command as a non root user (Ex: guest) Even i have used command for changing the ownership as chown "guest" /root -R Still it is giving error. Is there any other way to shutdown other than .bash_profile from user "guest". How can i give full permissions to my user "guest" as equal as "root" ,so that i can run "shutdown" command. From sundaram at redhat.com Thu Jun 23 13:55:20 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 23 Jun 2005 19:25:20 +0530 Subject: how to assign full access rights to guest In-Reply-To: <1dd5960805062306517908ed77@mail.gmail.com> References: <1dd5960805062306517908ed77@mail.gmail.com> Message-ID: <42BABF48.1040403@redhat.com> harshavardhanreddy mandeepala wrote: >hi >I am using Linux fedora core 3. >I want to shutdown the system from .bash_profile file >using >cd /sbin >./shutdown -g o >but when I run the file otherthan a superuser it is giving error message as > " to run "shutdown" u must be a root" > but i want to execute shutdown command as a non root user (Ex: guest) >Even i have used command for changing the ownership as >chown "guest" /root -R Still it is giving error. > >Is there any other way to shutdown other than .bash_profile from user "guest". >How can i give full permissions to my user "guest" as equal as >"root" ,so that i can run "shutdown" command. > > > This is a list for Fedora development. Ask in the users list http://fedoraproject.org/wiki/PostIsOffTopic regards Rahul From hvreddy1110 at gmail.com Thu Jun 23 13:56:11 2005 From: hvreddy1110 at gmail.com (harshavardhanreddy mandeepala) Date: Thu, 23 Jun 2005 19:26:11 +0530 Subject: How can we use shutdown command other than a superuser Message-ID: <1dd5960805062306563b2ea2c7@mail.gmail.com> hi I am using Linux fedora core 3. I want to shutdown the system from .bash_profile file using cd /sbin ./shutdown -g o but when I run the file otherthan a superuser it is giving error message as " to run "shutdown" u must be a root" but i want to execute shutdown command as a non root user (Ex: guest) Even i have used command for changing the ownership as chown "guest" /root -R Still it is giving error. Is there any other way to shutdown other than .bash_profile from user "guest". How can i give full permissions to my user "guest" as equal as "root" ,so that i can run "shutdown" command. Thanks in advance Regards M.Harshavardhan Reddy From pjones at redhat.com Thu Jun 23 14:07:33 2005 From: pjones at redhat.com (Peter Jones) Date: Thu, 23 Jun 2005 10:07:33 -0400 Subject: FC4 kernel performance In-Reply-To: <28701.192.54.193.25.1119513533.squirrel@rousalka.dyndns.org> References: <42B94ACA.5090008@web.de> <1119440497.5712.54.camel@localhost.localdomain> <42B96147.8040102@cornell.edu> <64458.192.54.193.35.1119446072.squirrel@rousalka.dyndns.org> <20050622134614.GB609975@hiwaay.net> <1119511808.5580.34.camel@localhost.localdomain> <28701.192.54.193.25.1119513533.squirrel@rousalka.dyndns.org> Message-ID: <1119535653.3922.2.camel@localhost.localdomain> On Thu, 2005-06-23 at 09:58 +0200, Nicolas Mailhot wrote: > On Jeu 23 juin 2005 09:30, David Woodhouse wrote: > > On Wed, 2005-06-22 at 08:46 -0500, Chris Adams wrote: > >> Some type of "journalling RAID" would be a possible solution (and > >> would also allow for much faster re-syncs on unclean shutdown, as only > >> the last written blocks would need updating). > > > > This is why RAID is entirely the wrong answer, and redundancy should be > > implemented in the file system itself, instead of being hacked into the > > block layer. > > Can't this be done today with something that takes lvm snapshots each night ? lvm snapshots right now don't seem fully baked to me; too many times I've had the kernel run out of memory while fiddling with them. Maybe it's just me... -- Peter From ph18 at cornell.edu Thu Jun 23 15:08:25 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Thu, 23 Jun 2005 11:08:25 -0400 Subject: FC4 kernel performance In-Reply-To: <1119533853.28493.70.camel@moss-spartans.epoch.ncsc.mil> References: <42B94ACA.5090008@web.de> <20050622122310.GA8691@jadzia.bu.edu> <42B95F36.5010301@cornell.edu> <1119445167.9745.4.camel@localhost.localdomain> <42B9AECC.9010100@cornell.edu> <1119533853.28493.70.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <42BAD069.7060505@cornell.edu> > >I have doubts about such play machines except as a learning tool, but if >you are interested, Russell Coker has a SELinux play machine available >with information at: >http://www.coker.com.au/selinux/play.html > > Yeah, I thought about this a lot last night, and realized that even if the SELinux implementation in the kernel was perfect, everything hangs on the userspace implementation. There's a certain emotional reaction that people get from hearing that you can log in as 'root' and it's harmless, but the real threats are attacks on real systems that do real work, not straw men that were set up to be (or not be) knocked down. Two more concerns came up for me with SELinux: (i) scalability on SMP -- I can attest that this is a nice machine: http://www.sun.com/servers/entry/v40z/index.jsp running four single-core processors: this four-socket machine upgrades to an eight-way machine with dual core processors -- this really changes the economics of SMP and is going to push the 'sweet spot' from 2-way towards 4-way and 8-way. System-on-chip is the major path for performance increases in the future, and we might even have 16-way desktop systems in a deade. Linux 2.6 is ready, but is SELinux? (ii) reliability -- Linux 2.6 is a big advance over Linux 2.4, but we had a crash last night. Unlike our struggles with 2.4, we found that the problem had already been reported and fixed in a recent kernel version. It's hard to fix bugs that aren't easily repeatable, and the longer code paths get, the worse things get. From sds at tycho.nsa.gov Thu Jun 23 15:25:45 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 23 Jun 2005 11:25:45 -0400 Subject: FC4 kernel performance In-Reply-To: <42BAD069.7060505@cornell.edu> References: <42B94ACA.5090008@web.de> <20050622122310.GA8691@jadzia.bu.edu> <42B95F36.5010301@cornell.edu> <1119445167.9745.4.camel@localhost.localdomain> <42B9AECC.9010100@cornell.edu> <1119533853.28493.70.camel@moss-spartans.epoch.ncsc.mil> <42BAD069.7060505@cornell.edu> Message-ID: <1119540345.28493.125.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-06-23 at 11:08 -0400, Paul A Houle wrote: > Two more concerns came up for me with SELinux: > > (i) scalability on SMP -- I can attest that this is a nice machine: > > http://www.sun.com/servers/entry/v40z/index.jsp > > running four single-core processors: this four-socket machine upgrades > to an eight-way machine with dual core processors -- this really changes > the economics of SMP and is going to push the 'sweet spot' from 2-way > towards 4-way and 8-way. System-on-chip is the major path for > performance increases in the future, and we might even have 16-way > desktop systems in a deade. Linux 2.6 is ready, but is SELinux? I think so. We used to have a major scalability bottleneck in our access vector cache (AVC) due to use of a global spinlock, but KaiGai Kohei of NEC converted it to RCU, and demonstrated good scalability on a 32-way system, and IBM later reported that those patches also addressed scalability problems they were seeing. There are still known areas where improvement is desirable in baseline performance and network scalability of SELinux, but the AVC was the largest obstacle to scalability. > (ii) reliability -- Linux 2.6 is a big advance over Linux 2.4, but we > had a crash last night. Unlike our struggles with 2.4, we found that > the problem had already been reported and fixed in a recent kernel > version. It's hard to fix bugs that aren't easily repeatable, and the > longer code paths get, the worse things get. Getting SELinux into the mainline kernel and getting it enabled by default in Fedora and RHEL was a big step forward here. We've already seen significant maturing of the code as a result. A set of selinux testcases was also recently added to the LTP, and IBM has been working on expanding that set of testcases. So I think we are on the right track, even though much work remains. -- Stephen Smalley National Security Agency From nutello at sweetness.com Thu Jun 23 15:46:02 2005 From: nutello at sweetness.com (Rudi Chiarito) Date: Thu, 23 Jun 2005 17:46:02 +0200 Subject: FC4 kernel performance In-Reply-To: <42BAD069.7060505@cornell.edu> References: <42B94ACA.5090008@web.de> <20050622122310.GA8691@jadzia.bu.edu> <42B95F36.5010301@cornell.edu> <1119445167.9745.4.camel@localhost.localdomain> <42B9AECC.9010100@cornell.edu> <1119533853.28493.70.camel@moss-spartans.epoch.ncsc.mil> <42BAD069.7060505@cornell.edu> Message-ID: <20050623154601.GA30885@plain.rackshack.net> On Thu, Jun 23, 2005 at 11:08:25AM -0400, Paul A Houle wrote: > desktop systems in a deade. Linux 2.6 is ready, but is SELinux? It depends on what you are doing. With some floating-point intensive code running on a cluster of FC3 dual Opterons, I wasn't able to measure SELinux overhead in a reliable manner. It seemed to be lost in the noise and even less of a factor than differences in compilers. Eventually we decided to keep SELinux enabled, as the cluster is soon going to be running jobs on behalf of users. There's a good chance that the applications will end up using and relying on custom SELinux contexts and policies, especially if we can get rid of the few dependencies on Windows server machines that are left. Code that is more disk- and network-intensive should be of course result in different observations. -- Rudi From ph18 at cornell.edu Thu Jun 23 16:05:41 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Thu, 23 Jun 2005 12:05:41 -0400 Subject: FC4 kernel performance In-Reply-To: <1119491674.3313.24.camel@jellyfish.redfishdemo.com> References: <42B94ACA.5090008@web.de> <20050622122310.GA8691@jadzia.bu.edu> <42B9A08F.4010806@web.de> <1119462107.3295.3.camel@rousalka.dyndns.org> <1119491674.3313.24.camel@jellyfish.redfishdemo.com> Message-ID: <42BADDD5.9060505@cornell.edu> Rodd Clarkson wrote: >I'm assuming you're talking about some sort of redundant raid (for >protecting data), and not striped raid (for speed improvements). While >this is nice for situations where a HDD might fail, I don't see how this >offers security in terms of data damage based on viruses, worms, malware >or intrusions. It doesn't matter how many 'redundant' drives you have >if they all carry (in essence) the same information. Two buggers copies >of the same file are stiff two buggered copies. > > Yeah, but the conventional choices for backup are unacceptable and very few people will do them. My experience with tape is that restore off tape fails half the time. I've had this experiences with 1990-vintage Suntape, those stupid little QIC tapes, and with more modern "enterprise" tape jukebox systems. Backing up onto CD or DVD is a joke: if I've got 80 GB of files, that's a lot of DVDs, and if I burn 80 GB of DVD's, odds are one of them is going to be a coaster. So I have to spend a few hours backing up and then verifying all of them. Incremental backups onto optical disk? Multisession support is glitchy, and it might work 20 times in a row, but you'll get bit by some exceptional event at some point. Disk-based backup ~is~ viable in various forms. For instance, it's quite practical to back up stuff disk to a USB 2.0 or Firewire drive, and it will finish faster than paint dries. I've found that network backup onto disks works too: but anything that's marketed explictly as a product for backup seems to be a scam. From harald at redhat.com Thu Jun 23 16:13:45 2005 From: harald at redhat.com (Harald Hoyer) Date: Thu, 23 Jun 2005 18:13:45 +0200 Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ - Python test scripts for Proof of Concept In-Reply-To: <42B2E569.3030100@redhat.com> References: <42B15F7F.90803@redhat.com> <42B2E569.3030100@redhat.com> Message-ID: <42BADFB9.1090800@redhat.com> The first "C" source can be found in: http://people.redhat.com/harald/ServiceManager/servicemanager.tar.gz All it does for now: It checks all /etc/init.d/* and creates a DBUS "Service" object for each. Works with dbus-0.35 (CVS version). From buildsys at redhat.com Thu Jun 23 16:48:03 2005 From: buildsys at redhat.com (Build System) Date: Thu, 23 Jun 2005 12:48:03 -0400 Subject: rawhide report: 20050623 changes Message-ID: <200506231648.j5NGm2Uq016416@porkchop.devel.redhat.com> Updated Packages: hplip-0.9.3-6 ------------- * Wed Jun 22 2005 Tim Waugh 0.9.3-6 - For libsane-hpaio ExcludeArch: s390 s390x, because it requires sane-backends. hwdata-0.159-1 -------------- * Wed Jun 22 2005 Bill Nottingham - 0.159-1 - pcitable: make branding happy (#160047) - Cards: add required blank line (#157972) - add some monitors - add JVC CD-ROM (#160907, ) - add hisax stuff to blacklist (#154799, #159068) joram-0:4.1.5-1jpp_2fc ---------------------- * Wed Jun 22 2005 Gary Benson 0:4.1.5-1jpp_2fc - Remove warfile from the tarball too. junit-0:3.8.1-3jpp_5fc ---------------------- * Wed Jun 22 2005 Gary Benson 0:3.8.1-3jpp_5fc - Remove classes and jarfiles from the tarball. kernel-2.6.12-1.1395_FC5 ------------------------ * Wed Jun 22 2005 Dave Jones - 2.6.12-git4 - Bring back the IDE fixes from -ac log4j-0:1.2.8-7jpp_5fc ---------------------- * Wed Jun 22 2005 Gary Benson 0:1.2.8-7jpp_5fc - Reenable building of classes that require jms. - Remove classes and jarfiles from the tarball. mockobjects-0:0.09-11jpp_2fc ---------------------------- * Wed Jun 22 2005 Gary Benson 0.09-11jpp_2fc - Remove jarfile from the tarball. monolog-0:1.8.6-1jpp_2fc ------------------------ * Wed Jun 22 2005 Gary Benson 0:1.8.6-1jpp_2fc - Remove zipfiles from the tarball too. nanoxml-0:2.2.3-3jpp_2fc ------------------------ * Wed Jun 22 2005 Gary Benson - 0:2.2.3-3jpp_2fc - Remove jarfile from the tarball. Broken deps for i386 ---------------------------------------------------------- GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.2.i686 requires /lib/modules/2.6.11-1.1369_FC4xenU GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.2.i686 requires kernel-xenU = 0:2.6.11-1.1369_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.2.i686 requires /lib/modules/2.6.11-1.1369_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.2.i686 requires kernel = 0:2.6.11-1.1369_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.2.i586 requires /lib/modules/2.6.11-1.1369_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.2.i586 requires kernel = 0:2.6.11-1.1369_FC4 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.2.i686 requires /lib/modules/2.6.11-1.1369_FC4xenU dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.2.i686 requires kernel-xenU = 0:2.6.11-1.1369_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.35.i686 requires /lib/modules/2.6.11-1.1369_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.35.i686 requires kernel = 0:2.6.11-1.1369_FC4 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.2.i686 requires /lib/modules/2.6.11-1.1369_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.2.i686 requires kernel-smp = 0:2.6.11-1.1369_FC4 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.2.i686 requires /lib/modules/2.6.11-1.1369_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.2.i686 requires kernel-smp = 0:2.6.11-1.1369_FC4 GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.2.i686 requires kernel-xen0 = 0:2.6.11-1.1369_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.2.i586 requires /lib/modules/2.6.11-1.1369_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.2.i586 requires kernel = 0:2.6.11-1.1369_FC4 cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.2.i686 requires kernel-xen0 = 0:2.6.11-1.1369_FC4 gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.35.i686 requires kernel-xen0 = 0:2.6.11-1.1369_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.2.i586 requires /lib/modules/2.6.11-1.1369_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.2.i586 requires kernel = 0:2.6.11-1.1369_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.2.i686 requires /lib/modules/2.6.11-1.1369_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.2.i686 requires kernel = 0:2.6.11-1.1369_FC4 dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.2.i686 requires kernel-xen0 = 0:2.6.11-1.1369_FC4 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.35.i686 requires /lib/modules/2.6.11-1.1369_FC4xenU gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.35.i686 requires kernel-xenU = 0:2.6.11-1.1369_FC4 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.2.i686 requires /lib/modules/2.6.11-1.1369_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.2.i686 requires kernel-smp = 0:2.6.11-1.1369_FC4 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.35.i686 requires /lib/modules/2.6.11-1.1369_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.35.i686 requires kernel-smp = 0:2.6.11-1.1369_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.2.i686 requires /lib/modules/2.6.11-1.1369_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.2.i686 requires kernel = 0:2.6.11-1.1369_FC4 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.2.i686 requires /lib/modules/2.6.11-1.1369_FC4xenU cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.2.i686 requires kernel-xenU = 0:2.6.11-1.1369_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.35.i586 requires /lib/modules/2.6.11-1.1369_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.35.i586 requires kernel = 0:2.6.11-1.1369_FC4 Broken deps for ppc ---------------------------------------------------------- gnbd-kernel - 2.6.11.2-20050420.133124.FC4.35.ppc requires /lib/modules/2.6.11-1.1369_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.35.ppc requires kernel = 0:2.6.11-1.1369_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.2.ppc requires /lib/modules/2.6.11-1.1369_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.2.ppc requires kernel = 0:2.6.11-1.1369_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.2.ppc requires /lib/modules/2.6.11-1.1369_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.2.ppc requires kernel = 0:2.6.11-1.1369_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.2.ppc requires /lib/modules/2.6.11-1.1369_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.2.ppc requires kernel = 0:2.6.11-1.1369_FC4 Broken deps for x86_64 ---------------------------------------------------------- dlm-kernel - 2.6.11.5-20050601.152643.FC4.2.x86_64 requires /lib/modules/2.6.11-1.1369_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.2.x86_64 requires kernel = 0:2.6.11-1.1369_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.2.x86_64 requires /lib/modules/2.6.11-1.1369_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.2.x86_64 requires kernel = 0:2.6.11-1.1369_FC4 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.35.x86_64 requires /lib/modules/2.6.11-1.1369_FC4smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.35.x86_64 requires kernel-smp = 0:2.6.11-1.1369_FC4 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.2.x86_64 requires /lib/modules/2.6.11-1.1369_FC4smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.2.x86_64 requires kernel-smp = 0:2.6.11-1.1369_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.35.x86_64 requires /lib/modules/2.6.11-1.1369_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.35.x86_64 requires kernel = 0:2.6.11-1.1369_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.2.x86_64 requires /lib/modules/2.6.11-1.1369_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.2.x86_64 requires kernel = 0:2.6.11-1.1369_FC4 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.2.x86_64 requires /lib/modules/2.6.11-1.1369_FC4smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.2.x86_64 requires kernel-smp = 0:2.6.11-1.1369_FC4 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.2.x86_64 requires /lib/modules/2.6.11-1.1369_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.2.x86_64 requires kernel-smp = 0:2.6.11-1.1369_FC4 Broken deps for ia64 ---------------------------------------------------------- castor - 0.9.5-1jpp_1fc.noarch requires jta jessie - 1.0.0-8.noarch requires java >= 0:1.4 xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 joram - 4.1.5-1jpp_2fc.noarch requires jmxri joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_2fc.noarch requires jta velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections jonas - 4.3.3-1jpp_1fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_1fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_1fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_1fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_1fc.noarch requires mx4j >= 1:2.1.0 jonas - 4.3.3-1jpp_1fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_1fc.noarch requires jasper5 jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 magma-plugins - 1.0-0.pre16.11.ia64 requires libgulm.so.1.0()(64bit) castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging rgmanager - 1.9.31-3.ia64 requires ccs xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 wsdl4j - 1.5.1-1jpp_1fc.noarch requires java avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging Broken deps for s390x ---------------------------------------------------------- jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10 jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 nfs-utils - 1.0.7-8.s390x requires kernel >= 0:2.2.14 jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 hal - 0.5.2-2.s390x requires kernel >= 0:2.6.11 selinux-policy-targeted - 1.23.18-15.noarch requires kernel >= 0:2.6.11-1.1219 jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_1fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_1fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_1fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_1fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_1fc.noarch requires mx4j >= 1:2.1.0 jonas - 4.3.3-1jpp_1fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_1fc.noarch requires jasper5 xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6 arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0 ecj - 1:3.1-0.M4.9.s390x requires katana >= 0:2.0.0 jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 castor - 0.9.5-1jpp_1fc.noarch requires jta libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0 joram - 4.1.5-1jpp_2fc.noarch requires jmxri joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_2fc.noarch requires jta quota - 1:3.12-6.s390x requires kernel >= 0:2.4 jessie - 1.0.0-8.noarch requires java >= 0:1.4 jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging lvm2 - 2.01.12-1.0.s390x requires kernel >= 0:2.6 selinux-policy-targeted-sources - 1.23.18-15.noarch requires kernel >= 0:2.6.11-1.1219 hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11 dhcp - 10:3.0.2-14.s390x requires kernel >= 0:2.2.18 castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 selinux-policy-strict - 1.23.18-15.noarch requires kernel >= 0:2.6.11-1.1219 sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 libsane-hpaio - 0.9.3-5.s390x requires sane-backends gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2 selinux-policy-strict-sources - 1.23.18-15.noarch requires kernel >= 0:2.6.11-1.1219 sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit) libpcap - 14:0.8.3-14.s390x requires kernel >= 0:2.2.0 wsdl4j - 1.5.1-1jpp_1fc.noarch requires java avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet Broken deps for s390 ---------------------------------------------------------- jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet selinux-policy-targeted-sources - 1.23.18-15.noarch requires kernel >= 0:2.6.11-1.1219 jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21 ecj - 1:3.1-0.M4.9.s390 requires katana >= 0:2.0.0 lvm2 - 2.01.12-1.0.s390 requires kernel >= 0:2.6 sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2 initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6 prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10 axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11 castor - 0.9.5-1jpp_1fc.noarch requires jta xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0 jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections jonas - 4.3.3-1jpp_1fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_1fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_1fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_1fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_1fc.noarch requires mx4j >= 1:2.1.0 jonas - 4.3.3-1jpp_1fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_1fc.noarch requires jasper5 jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 dhcp - 10:3.0.2-14.s390 requires kernel >= 0:2.2.18 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2 selinux-policy-strict-sources - 1.23.18-15.noarch requires kernel >= 0:2.6.11-1.1219 xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet joram - 4.1.5-1jpp_2fc.noarch requires jmxri joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_2fc.noarch requires jta quota - 1:3.12-6.s390 requires kernel >= 0:2.4 jessie - 1.0.0-8.noarch requires java >= 0:1.4 libsane-hpaio - 0.9.3-5.s390 requires sane-backends selinux-policy-strict - 1.23.18-15.noarch requires kernel >= 0:2.6.11-1.1219 jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14 xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging selinux-policy-targeted - 1.23.18-15.noarch requires kernel >= 0:2.6.11-1.1219 castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0 jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 wsdl4j - 1.5.1-1jpp_1fc.noarch requires java Broken deps for ppc64 ---------------------------------------------------------- jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper jessie - 1.0.0-8.noarch requires java >= 0:1.4 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 dlm-kernel - 2.6.11.5-20050601.152643.FC4.2.ppc64 requires /lib/modules/2.6.11-1.1369_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.2.ppc64 requires kernel = 0:2.6.11-1.1369_FC4 jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging castor - 0.9.5-1jpp_1fc.noarch requires jta avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections system-config-keyboard - 1.2.6-2.noarch requires pyxf86config xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging wsdl4j - 1.5.1-1jpp_1fc.noarch requires java gnbd-kernel - 2.6.11.2-20050420.133124.FC4.35.ppc64 requires /lib/modules/2.6.11-1.1369_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.35.ppc64 requires kernel = 0:2.6.11-1.1369_FC4 jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 system-config-mouse - 1.2.11-1.noarch requires pyxf86config jonas - 4.3.3-1jpp_1fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_1fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_1fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_1fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_1fc.noarch requires mx4j >= 1:2.1.0 jonas - 4.3.3-1jpp_1fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_1fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_1fc.noarch requires jasper5 xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit) gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit) ecj - 1:3.1-0.M4.9.ppc64 requires katana >= 0:2.0.0 rhpl - 0.167-1.ppc64 requires pyxf86config >= 0:0.3.2 cman-kernel - 2.6.11.5-20050601.152643.FC4.2.ppc64 requires /lib/modules/2.6.11-1.1369_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.2.ppc64 requires kernel = 0:2.6.11-1.1369_FC4 jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 joram - 4.1.5-1jpp_2fc.noarch requires jmxri joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_2fc.noarch requires jta jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 ppc64-utils - 0.7-9.ppc64 requires yaboot system-config-display - 1.0.29-1.noarch requires /usr/X11R6/bin/Xorg system-config-display - 1.0.29-1.noarch requires pyxf86config >= 0:0.3.16 axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 From shiva at sewingwitch.com Thu Jun 23 17:12:52 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Thu, 23 Jun 2005 10:12:52 -0700 Subject: How can we use shutdown command other than a superuser In-Reply-To: <1dd5960805062306563b2ea2c7@mail.gmail.com> References: <1dd5960805062306563b2ea2c7@mail.gmail.com> Message-ID: <95E4C8B4967CFA637D4EDD8D@[10.169.6.233]> --On Thursday, June 23, 2005 7:26 PM +0530 harshavardhanreddy mandeepala wrote: > Is there any other way to shutdown other than .bash_profile from user > "guest". How can i give full permissions to my user "guest" as equal as > "root" ,so that i can run "shutdown" command. "man sudo" From i.pilcher at comcast.net Thu Jun 23 17:16:52 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Thu, 23 Jun 2005 12:16:52 -0500 Subject: RFC: Add I2C/lm_sensors modules to hotplug blacklist Message-ID: At least on my system (Abit VP6) allowing hotplug to load the I2C drivers can mess things up. Since all required modules should be loaded by the lm_sensors startup script, I don't see a downside to blacklisting them. Comments? Thanks! -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From kmacmillan at tresys.com Thu Jun 23 17:47:52 2005 From: kmacmillan at tresys.com (Karl MacMillan) Date: Thu, 23 Jun 2005 13:47:52 -0400 Subject: FC4 kernel performance In-Reply-To: <42BAD069.7060505@cornell.edu> Message-ID: <200506231747.j5NHlqqc029833@gotham.columbia.tresys.com> > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > bounces at redhat.com] On Behalf Of Paul A Houle > Sent: Thursday, June 23, 2005 11:08 AM > To: Development discussions related to Fedora Core > Subject: Re: FC4 kernel performance > > > > > >I have doubts about such play machines except as a learning tool, but if > >you are interested, Russell Coker has a SELinux play machine available > >with information at: > >http://www.coker.com.au/selinux/play.html > > > > > Yeah, I thought about this a lot last night, and realized that > even if the SELinux implementation in the kernel was perfect, > everything hangs on the userspace implementation. Not certain what you mean here - certainly there are userspace applications that must be correct (any process that authenticates a user and sets their initial context for example) but there are relatively few. Can you explain this a bit more. > There's a certain > emotional reaction that people get from hearing that you can log in as > 'root' and it's harmless, but the real threats are attacks on real > systems that do real work, not straw men that were set up to be (or not > be) knocked down. > Certainly - these machines are just demonstrating that the mechanism works and is flexible. SELinux can thwart these real attacks if properly configured and the applications are appropriately architected. The work now is, I think, utilizing that capability. Karl --- Karl MacMillan Tresys Technology http://www.tresys.com (410) 290-1411 ext 134 > Two more concerns came up for me with SELinux: > > (i) scalability on SMP -- I can attest that this is a nice machine: > > http://www.sun.com/servers/entry/v40z/index.jsp > > running four single-core processors: this four-socket machine upgrades > to an eight-way machine with dual core processors -- this really changes > the economics of SMP and is going to push the 'sweet spot' from 2-way > towards 4-way and 8-way. System-on-chip is the major path for > performance increases in the future, and we might even have 16-way > desktop systems in a deade. Linux 2.6 is ready, but is SELinux? > > (ii) reliability -- Linux 2.6 is a big advance over Linux 2.4, but we > had a crash last night. Unlike our struggles with 2.4, we found that > the problem had already been reported and fixed in a recent kernel > version. It's hard to fix bugs that aren't easily repeatable, and the > longer code paths get, the worse things get. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From otaylor at redhat.com Thu Jun 23 21:29:14 2005 From: otaylor at redhat.com (Owen Taylor) Date: Thu, 23 Jun 2005 17:29:14 -0400 Subject: Cairo [was: rawhide report: 20050621 changes] In-Reply-To: <20050623125135.GA17967@plain.rackshack.net> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> <1119428771.27240.113.camel@tarjei.predichem.nett> <1119444032.3335.14.camel@goose> <1119452774.27240.140.camel@tarjei.predichem.nett> <1119462274.10442.4.camel@localhost> <20050622201308.73f97fcf@nausicaa.camperquake.de> <20050623125135.GA17967@plain.rackshack.net> Message-ID: <1119562154.23067.76.camel@localhost.localdomain> On Thu, 2005-06-23 at 14:51 +0200, Rudi Chiarito wrote: > On Wed, Jun 22, 2005 at 08:13:08PM +0200, Ralf Ertzinger wrote: > > Apart from that: does it work or does it break all sorts of things? > > In addition to the Firefox problem already reported, I noticed > differences in font rendering - but then I am one of those whiners that > complain about Arial being a cheap imitation of Helvetica. > > The panel seems to have hinting enabled, even if it's disabled in my > preferences. I use non-standard fonts and they look much better if no > hints are applied. You can see the same with Bitstream Charter (part of > fonts-xorg-base). > > The second curious thing I noticed is that changes in hinting in the > font preferences are not reflected on screen in realtime as they used > to. Actually, #2 might be the explanation for #1: is hinting enabled by > default, if gconfd is not running yet? It could be that the panel gets > started before gconfd and thus gets stuck with whatever are the defaults > for font hinting (the font family is right, though). Yep, this stuff is all known. "Just a matter of a bit of coding" Regards, Owen -------------- 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 Jun 23 22:00:54 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 23 Jun 2005 16:00:54 -0600 Subject: rpm packages of thunderbird/firefox extensions Message-ID: <42BB3116.2070304@cora.nwra.com> Is it possible to create rpm packages of thunderbird and firefox extensions? I'd like to install some global extensions on each of our machines and I'd prefer to have rpms, but not sure how it would interact with or replace the -install-global-extension option. Perhaps fedora-packaging is a better place to ask? It might be nice for fedora extras to be able to provide extensions as well. From bernie at develer.com Thu Jun 23 23:15:23 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Fri, 24 Jun 2005 01:15:23 +0200 Subject: FC4 kernel performance In-Reply-To: <20050623043555.GA16636@jadzia.bu.edu> References: <1119368638.5902.174.camel@scox.glenatl.glenayre.com> <20050621154755.GC21723@redhat.com> <1119370102.2475.37.camel@dch.TQMcube.com> <20050621173932.GA30669@jadzia.bu.edu> <1119378036.12067.7.camel@dch.TQMcube.com> <42BA1440.9090403@develer.com> <20050623043555.GA16636@jadzia.bu.edu> Message-ID: <42BB428B.8090401@develer.com> Matthew Miller wrote: > On Thu, Jun 23, 2005 at 03:45:36AM +0200, Bernardo Innocenti wrote: > >>I second this. Building custom kernels from the src rpm is >>a tedious operation that requires too many steps to be carried >>out manually. > > > Only if you're doing it wrong. :) That's what I usually do: # rpm -i kernel-2.6.x-nnnn.src.rpm # cd /usr/src/redhat/SPECS/ # rpmbuild -bp --target=x86_64 kernel-2.6.spec [...wait...] # mv /usr/src/redhat/BUILD/kernel-2.6.x/linux-2.6.x /usr/src/kernels/2.6.x-nnnn.bernie # cd /usr/src/kernels/2.6.x-nnnn.bernie # vi Makefile [...set EXTRAVERSION to "-nnnn.bernie"...] # cp ../ References: <42B94ACA.5090008@web.de> <20050622122310.GA8691@jadzia.bu.edu> <42B9A08F.4010806@web.de> <1119462107.3295.3.camel@rousalka.dyndns.org> <1119491674.3313.24.camel@jellyfish.redfishdemo.com> <42BADDD5.9060505@cornell.edu> Message-ID: <42BB4BB0.9070807@develer.com> Paul A Houle wrote: > Disk-based backup ~is~ viable in various forms. For instance, it's > quite practical to back up stuff disk to a USB 2.0 or Firewire drive, > and it will finish faster than paint dries. I've found that network > backup onto disks works too: but anything that's marketed explictly as > a product for backup seems to be a scam. My favourite backup method is rsync'ing to an HD of the same size, mounted on another server in a different room. This way I can run daily, unattended backups and be reasonably protected against fire and robbery. Today, hard disks are larger, faster, more affordable and more reliable than tapes or other removable media. If only I could use a compressed r/w filesystem for the backup disk, I'd save a few bucks. JFFS2 is the only mature filesystem that can do that, but it doesn't appear to be usable with very large partitions. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From alan at redhat.com Fri Jun 24 00:50:29 2005 From: alan at redhat.com (Alan Cox) Date: Thu, 23 Jun 2005 20:50:29 -0400 Subject: FC4 kernel performance In-Reply-To: <42BB4BB0.9070807@develer.com> References: <42B94ACA.5090008@web.de> <20050622122310.GA8691@jadzia.bu.edu> <42B9A08F.4010806@web.de> <1119462107.3295.3.camel@rousalka.dyndns.org> <1119491674.3313.24.camel@jellyfish.redfishdemo.com> <42BADDD5.9060505@cornell.edu> <42BB4BB0.9070807@develer.com> Message-ID: <20050624005029.GF16125@devserv.devel.redhat.com> On Fri, Jun 24, 2005 at 01:54:24AM +0200, Bernardo Innocenti wrote: > If only I could use a compressed r/w filesystem for > the backup disk, I'd save a few bucks. JFFS2 is > the only mature filesystem that can do that, but > it doesn't appear to be usable with very large > partitions. Not generally advisable. Lose a few bits and your compressed backup is rather less than useful. JFFS2 is a special fs for flash so totally unsuitable for disk media. Alan From a.kurtz at hardsun.net Fri Jun 24 01:42:23 2005 From: a.kurtz at hardsun.net (Aaron Kurtz) Date: Thu, 23 Jun 2005 18:42:23 -0700 Subject: rpm packages of thunderbird/firefox extensions In-Reply-To: <42BB3116.2070304@cora.nwra.com> References: <42BB3116.2070304@cora.nwra.com> Message-ID: <1119577344.32129.100.camel@rydia.hardsun.net> On Thu, 2005-06-23 at 16:00 -0600, Orion Poplawski wrote: > Is it possible to create rpm packages of thunderbird and firefox > extensions? I'd like to install some global extensions on each of our > machines and I'd prefer to have rpms, but not sure how it would interact > with or replace the -install-global-extension option. Perhaps > fedora-packaging is a better place to ask? Yes, it's possible. Debian provides extension packages, and ALTLinux http://www.altlinux.com/ provides extension RPMs. I found this page on Debian packaging helpful http://glandium.org/debian/packages/mozilla-firefox/New_scheme_for_extensions/current.html while ALTLinux uses macros available in their firefox-devel package under /etc/rpm/macros.d/ > It might be nice for fedora extras to be able to provide extensions as well. It won't happen until people come forward and offer to do it. Do you have some free time? -- Aaron Kurtz From ellson at research.att.com Fri Jun 24 01:50:07 2005 From: ellson at research.att.com (John Ellson) Date: Thu, 23 Jun 2005 21:50:07 -0400 Subject: Why no compat-gcc-3.4.3-22.fc4.i386.rpm ? Message-ID: <42BB66CF.6090905@research.att.com> Since the latest official update to gcc on FC3 was to gcc-3.4.3-22.fc3.i386.rpm why is there no compat-gcc-3.4.3-22.fc4.i386.rpm for FC4 ? Some colleagues are stuggling with some C++ programs are are not yet ready for gcc-4.0.0, but apparently gcc32 is too old. John From rodd at clarkson.id.au Fri Jun 24 03:20:06 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Fri, 24 Jun 2005 13:20:06 +1000 Subject: FC4 kernel performance In-Reply-To: <42BADDD5.9060505@cornell.edu> References: <42B94ACA.5090008@web.de> <20050622122310.GA8691@jadzia.bu.edu> <42B9A08F.4010806@web.de> <1119462107.3295.3.camel@rousalka.dyndns.org> <1119491674.3313.24.camel@jellyfish.redfishdemo.com> <42BADDD5.9060505@cornell.edu> Message-ID: <1119583206.4703.12.camel@goose> On Thu, 2005-06-23 at 12:05 -0400, Paul A Houle wrote: > Rodd Clarkson wrote: > > >I'm assuming you're talking about some sort of redundant raid (for > >protecting data), and not striped raid (for speed improvements). While > >this is nice for situations where a HDD might fail, I don't see how this > >offers security in terms of data damage based on viruses, worms, malware > >or intrusions. It doesn't matter how many 'redundant' drives you have > >if they all carry (in essence) the same information. Two buggers copies > >of the same file are stiff two buggered copies. > > > > > Yeah, but the conventional choices for backup are unacceptable and > very few people will do them. I'm not suggesting that this isn't a useful method to back up against some sorts of potential data lose. However, the discussion was about data lost resulting for unwanted intrusion into you system including hackers, worms, viruses and that sort of thing. Given that all the disks in a raid setup are part of a 'live' session, it's very unlikely that damage to data will be limited to a single drive. For example, something that makes all your files zero bytes long will affect all the disks in the RAID array. So in this case a RAID array isn't going to help protect your data. RAID has it's advantages in protecting data, but only when a single (redundant) drive fails. My father in law used to back up his data on three disks (ZIPs - don't ask ;-]) and one day he discovered that one of his important files was corrupted. The corruption had occurred some months earlier and what he discovered was he had four copies of the same corrupted file. Same goes for a RAID setup. Corrupt a file, and the file is corrupted on all the disks, not just on one. As such, RAID doesn't protect you against file corruption, only against hardware failure. regards Rodd -- "It's a fine line between denial and faith. It's much better on my side" From dcbw at redhat.com Fri Jun 24 03:20:44 2005 From: dcbw at redhat.com (Dan Williams) Date: Thu, 23 Jun 2005 23:20:44 -0400 (EDT) Subject: Why no compat-gcc-3.4.3-22.fc4.i386.rpm ? In-Reply-To: <42BB66CF.6090905@research.att.com> References: <42BB66CF.6090905@research.att.com> Message-ID: On Thu, 23 Jun 2005, John Ellson wrote: > Since the latest official update to gcc on FC3 was to > gcc-3.4.3-22.fc3.i386.rpm > why is there no compat-gcc-3.4.3-22.fc4.i386.rpm for FC4 ? > > Some colleagues are stuggling with some C++ programs are are not yet > ready for gcc-4.0.0, but > apparently gcc32 is too old. The issue here is one of binary compatibility. gcc 3.2 and gcc 3.3 were not that much different, and gcc 3.4 and gcc 4.0 are not that much different. Where large differences occurred was between 3.3 and 3.4. We can't ship compat versions of every compiler, so we have to pick and choose. I'd note that for OpenOffice.org, which happens to be 7 million lines of C++, there was a _huge_ patch for gcc 3.4 compatibility, but the patch for 4.0 has mostly been naming anonymous enums (ie, instead of "enum {...};" it now has to be "enum foobar {...};"). If we can do OpenOffice.org for gcc 4.0 in a week, others can certainly do their C++ programs which aren't near that size. So the answer here is really "fix your code", since you already did most of the work porting to gcc 3.4. Dan From bernie at develer.com Fri Jun 24 04:55:39 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Fri, 24 Jun 2005 06:55:39 +0200 Subject: FC4 kernel performance In-Reply-To: <20050624005029.GF16125@devserv.devel.redhat.com> References: <42B94ACA.5090008@web.de> <20050622122310.GA8691@jadzia.bu.edu> <42B9A08F.4010806@web.de> <1119462107.3295.3.camel@rousalka.dyndns.org> <1119491674.3313.24.camel@jellyfish.redfishdemo.com> <42BADDD5.9060505@cornell.edu> <42BB4BB0.9070807@develer.com> <20050624005029.GF16125@devserv.devel.redhat.com> Message-ID: <42BB924B.4020509@develer.com> Alan Cox wrote: > On Fri, Jun 24, 2005 at 01:54:24AM +0200, Bernardo Innocenti wrote: > >>If only I could use a compressed r/w filesystem for >>the backup disk, I'd save a few bucks. JFFS2 is >>the only mature filesystem that can do that, but >>it doesn't appear to be usable with very large >>partitions. > > > Not generally advisable. Lose a few bits and your compressed backup is rather > less than useful. JFFS2 is a special fs for flash so totally unsuitable for > disk media. I've used JFFS2 on uClinux, and found it quite robust wrt blocks with checksum errors. But, yes, JFFS2 isn't designed for disk media. I'm ashamed to admit that sometimes I envy NTFS's transparent file compression. Yes, it's very slow for general use, but it would be ideal for backups, old log files, etc. ext2 has had an unsupported "compressed" attribute for years. Perhaps it's extremely difficult to implement, but a very desiderable feature that Linux still lacks. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From gmaxwell at gmail.com Fri Jun 24 05:00:46 2005 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Fri, 24 Jun 2005 01:00:46 -0400 Subject: FC4 kernel performance In-Reply-To: <42BB924B.4020509@develer.com> References: <42B94ACA.5090008@web.de> <20050622122310.GA8691@jadzia.bu.edu> <42B9A08F.4010806@web.de> <1119462107.3295.3.camel@rousalka.dyndns.org> <1119491674.3313.24.camel@jellyfish.redfishdemo.com> <42BADDD5.9060505@cornell.edu> <42BB4BB0.9070807@develer.com> <20050624005029.GF16125@devserv.devel.redhat.com> <42BB924B.4020509@develer.com> Message-ID: On 6/24/05, Bernardo Innocenti wrote: > I'm ashamed to admit that sometimes I envy NTFS's transparent > file compression. Yes, it's very slow for general use, but it > would be ideal for backups, old log files, etc. It's insane that it is slow... unless you modify the file compression should make things faster.. substantially so. The modify part is hard unless you're working with a file system that can solve it as elegantly as reiser4 can... From bernie at develer.com Fri Jun 24 05:29:01 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Fri, 24 Jun 2005 07:29:01 +0200 Subject: FC4 kernel performance In-Reply-To: References: <42B94ACA.5090008@web.de> <20050622122310.GA8691@jadzia.bu.edu> <42B9A08F.4010806@web.de> <1119462107.3295.3.camel@rousalka.dyndns.org> <1119491674.3313.24.camel@jellyfish.redfishdemo.com> <42BADDD5.9060505@cornell.edu> <42BB4BB0.9070807@develer.com> <20050624005029.GF16125@devserv.devel.redhat.com> <42BB924B.4020509@develer.com> Message-ID: <42BB9A1D.7050700@develer.com> Gregory Maxwell wrote: > On 6/24/05, Bernardo Innocenti wrote: > >>I'm ashamed to admit that sometimes I envy NTFS's transparent >>file compression. Yes, it's very slow for general use, but it >>would be ideal for backups, old log files, etc. > > > It's insane that it is slow... unless you modify the file compression > should make things faster.. substantially so. The modify part is hard > unless you're working with a file system that can solve it as > elegantly as reiser4 can... Yes, NTFS compression isn't generally slow when just reading sequentially. Slow operations are seeks, writes and even appends. I know a company who used NTFS compression to store transaction records in a POS application. Tests were done with small data sets. When they went to production, they had to quickly revert installed systems to uncompressed storage. Apparently, appending a transaction to the journal was a linear operation :-) I don't know for sure, but JFFS2 shouldn't suffer from this problem. Using it on a 2MB flash, I can't test it with large files :-) -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From russell at coker.com.au Fri Jun 24 07:19:06 2005 From: russell at coker.com.au (Russell Coker) Date: Fri, 24 Jun 2005 17:19:06 +1000 Subject: FC4 kernel performance In-Reply-To: <42B94ACA.5090008@web.de> References: <42B94ACA.5090008@web.de> Message-ID: <200506241719.11398.russell@coker.com.au> On Wednesday 22 June 2005 21:26, Marcus Hartig wrote: > and not for my notebook/PC. Which really not needs Debugging, SELinux, > RAID, 20 security features,.... No normal desktop user needs it. My girl Lots of people use desktop workstations with RAID-1. If you have two disks then it has the potential to provide some significant advantages. I've avoided data loss in the past by using RAID-1 on workstations. http://www.linuxsecurity.com/content/view/102373/107/ I think that most workstations have dhclient running, it runs as root and the dhcp code base has had security bugs before. Bugs such as the above will be minor issues instead of major issues if you are running SE Linux. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From russell at coker.com.au Fri Jun 24 07:41:04 2005 From: russell at coker.com.au (Russell Coker) Date: Fri, 24 Jun 2005 17:41:04 +1000 Subject: FC4 kernel performance In-Reply-To: <20050623154601.GA30885@plain.rackshack.net> References: <42B94ACA.5090008@web.de> <42BAD069.7060505@cornell.edu> <20050623154601.GA30885@plain.rackshack.net> Message-ID: <200506241741.08108.russell@coker.com.au> On Friday 24 June 2005 01:46, Rudi Chiarito wrote: > On Thu, Jun 23, 2005 at 11:08:25AM -0400, Paul A Houle wrote: > > desktop systems in a deade. Linux 2.6 is ready, but is SELinux? > > It depends on what you are doing. With some floating-point intensive > code running on a cluster of FC3 dual Opterons, I wasn't able to measure > SELinux overhead in a reliable manner. It seemed to be lost in the noise When the CPU is busy executing application code that does not perform any system calls there should not be any SE Linux CPU overhead. So any code that is doing calculations (regardless of whether it's integer or floating point) and nothing else should not be impacted by SE Linux. One area of overhead is in memory use, the SE Linux policy is stored in non-pageable kernel memory. If you have only a small amount of memory on the system (64M or less) then the memory taken by the SE Linux policy can have an impact on performance leading to paging of application data when otherwise it might not page such data or in OOM on machines without a swap space enabled. The "strict" policy (which is not installed by default) will not run on a machine with 64M of RAM unless you do some significant tweaks. The "targeted" policy is less complex, smaller, and uses less RAM. > Code that is more disk- and network-intensive should be of course result > in different observations. Code that is disk intensive should not be an issue either. The shortest time for a seek is about 5ms. The most complex SE Linux access check will not take a fraction of 5ms so the performance impact should not be measurable. Where the SE Linux performance impact is measurable is in network operations and IPC (including pseudo-tty). These are operations that involve SE Linux access checks and have operations occurring much more frequently than any hard disk can sustain. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From russell at coker.com.au Fri Jun 24 07:49:02 2005 From: russell at coker.com.au (Russell Coker) Date: Fri, 24 Jun 2005 17:49:02 +1000 Subject: FC4 kernel performance In-Reply-To: <42BAD069.7060505@cornell.edu> References: <42B94ACA.5090008@web.de> <1119533853.28493.70.camel@moss-spartans.epoch.ncsc.mil> <42BAD069.7060505@cornell.edu> Message-ID: <200506241749.07150.russell@coker.com.au> On Friday 24 June 2005 01:08, Paul A Houle wrote: > >I have doubts about such play machines except as a learning tool, but if > >you are interested, Russell Coker has a SELinux play machine available > >with information at: > >http://www.coker.com.au/selinux/play.html The aims of the SE Linux play machines are to teach people about SE Linux and to test the policy. Quite a number of improvements have been made to the SE Linux policy (including adding the staff_r and support for easily adding more roles) as a result of this. > Yeah, I thought about this a lot last night, and realized that > even if the SELinux implementation in the kernel was perfect, > everything hangs on the userspace implementation. Are you concerned about crond running a cron job as sysadm_r:sysadm_crond_t instead of user_r:user_crond_t? If so then the risk is smaller than the risk of running a job as UID 0 instead of UID 1000 due to the strict controls on creating crontab files and the checks on the context of the crontab files before running the cron jobs. On a machine running the strict SE Linux policy a bug in sshd, crond, unix_chkpwd, or login could be used to crack a system. On a machine not running SE Linux bugs in those programs could be used even more easily than on a SE Linux system, as well as bugs in any SUID program (of which there are many). > There's a certain > emotional reaction that people get from hearing that you can log in as > 'root' and it's harmless, It demonstrates that SE Linux access controls restrict all operations that a program may perform. It's recommended that you plan on using Unix permissions as another layer of defense, but it has been shown that SE Linux controls everything. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From nicolas.mailhot at laposte.net Fri Jun 24 07:49:45 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 24 Jun 2005 09:49:45 +0200 (CEST) Subject: FC4 kernel performance In-Reply-To: <1119583206.4703.12.camel@goose> References: <42B94ACA.5090008@web.de> <20050622122310.GA8691@jadzia.bu.edu> <42B9A08F.4010806@web.de> <1119462107.3295.3.camel@rousalka.dyndns.org> <1119491674.3313.24.camel@jellyfish.redfishdemo.com> <42BADDD5.9060505@cornell.edu> <1119583206.4703.12.camel@goose> Message-ID: <57899.192.54.193.37.1119599385.squirrel@rousalka.dyndns.org> On Ven 24 juin 2005 05:20, Rodd Clarkson wrote: > However, the discussion was about > data lost resulting for unwanted intrusion into you system including > hackers, worms, viruses and that sort of thing. Read again the thread. The discussion was about why your average user would ever need RAID, SE-Linux and other weird server options in his FC kernel. -- Nicolas Mailhot From russell at coker.com.au Fri Jun 24 07:52:12 2005 From: russell at coker.com.au (Russell Coker) Date: Fri, 24 Jun 2005 17:52:12 +1000 Subject: FC4 kernel performance In-Reply-To: <1119377879.5901.206.camel@scox.glenatl.glenayre.com> References: <1119377879.5901.206.camel@scox.glenatl.glenayre.com> Message-ID: <200506241752.16199.russell@coker.com.au> On Wednesday 22 June 2005 04:17, "Malita, Florin" wrote: > 4. Linux 2.6.11-1.1369_FC4 (nodebug+p4+nose+ nohm): 253.1 > 5. Linux 2.6.11-1.1369_FC4 (nodebug+p4): 239.4 I would be interested to see a section 4.5 which has nodebug+p4+nohm. I expect that a large portion of the 5.4% performance loss when enabling SE Linux and high-memory is from high memory. I would be surprised if 2% of that 5.4% was from SE Linux. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From spayne at evolutioncolt.com Fri Jun 24 07:53:40 2005 From: spayne at evolutioncolt.com (Seb Payne) Date: Fri, 24 Jun 2005 08:53:40 +0100 Subject: Request for Fedora Core 4 Next Kernel Release - inotify Message-ID: <1119599620.4416.4.camel@basestation.evolutioncolt.com> I hope this is the right place to ask but I would like to make a request for the Fedora Core Kernel developers. I have been trying rebuild the kernel with inotify enabled (for use with Muine and Beagle). Would it be possible for the patch to be included as standard when the next Kernel is released for Fedora Core 4 (2.6.12 possibly)? It would make running Muine and Beagle easier. The next Ubuntu release will have inotify enabled as standard :-) Thanks Seb (The patches can be found at http://www.kernel.org/pub/linux/kernel/people/rml/inotify/v2.6/0.23/) From caillon at redhat.com Fri Jun 24 08:50:49 2005 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 24 Jun 2005 04:50:49 -0400 Subject: rpm packages of thunderbird/firefox extensions In-Reply-To: <42BB3116.2070304@cora.nwra.com> References: <42BB3116.2070304@cora.nwra.com> Message-ID: <42BBC969.5080406@redhat.com> On 06/23/2005 06:00 PM, Orion Poplawski wrote: > Is it possible to create rpm packages of thunderbird and firefox > extensions? I'd like to install some global extensions on each of our > machines and I'd prefer to have rpms, but not sure how it would interact > with or replace the -install-global-extension option. Perhaps > fedora-packaging is a better place to ask? Is it possible? Yes. Is it easy? Not really, due to the way that the extension manager works in Firefox 1.0 -- the extension manager in Firefox 1.1 is much nicer and works better with Linux. I also don't provide devel packages for either because of some packaging conflict issues with the mozilla package, so it is slightly more difficult as well. I'm actually working on packaging up Deer Park Alpha 1, which is a very early alpha release of Firefox 1.1, which should hit rawhide soon. I will also get preview builds of xulrunner which should help to alleviate this problem. I hope the situation will be much nicer for FC5. > > It might be nice for fedora extras to be able to provide extensions as > well. > Sure, I would hope that once our picture is better, we get a lot of extensions in Extras. From alan at redhat.com Fri Jun 24 10:12:48 2005 From: alan at redhat.com (Alan Cox) Date: Fri, 24 Jun 2005 06:12:48 -0400 Subject: Request for Fedora Core 4 Next Kernel Release - inotify In-Reply-To: <1119599620.4416.4.camel@basestation.evolutioncolt.com> References: <1119599620.4416.4.camel@basestation.evolutioncolt.com> Message-ID: <20050624101248.GB14344@devserv.devel.redhat.com> On Fri, Jun 24, 2005 at 08:53:40AM +0100, Seb Payne wrote: > I hope this is the right place to ask but I would like to make a request > for the Fedora Core Kernel developers. I have been trying rebuild the > kernel with inotify enabled (for use with Muine and Beagle). inotify is still not in the upstream kernel. It seems to be heading that way but it would be bad to include something now which might change entirely at some point in the future > make running Muine and Beagle easier. The next Ubuntu release will have > inotify enabled as standard :-) Fedora tries to keep close to the base kernel. In particular we don't want to have APIs that are not fixed in the base kernel because having to deal with 'ubuntu api', 'upstream api', 'fedora api' all differently would not be good for developers or Linux longer term. From buildsys at redhat.com Fri Jun 24 11:28:57 2005 From: buildsys at redhat.com (Build System) Date: Fri, 24 Jun 2005 07:28:57 -0400 Subject: rawhide report: 20050624 changes Message-ID: <200506241128.j5OBSvui024580@porkchop.devel.redhat.com> Updated Packages: audit-0.9.13-1 -------------- * Thu Jun 23 2005 Steve Grubb 0.9.13-1 - Remove /lib/libaudit.so & .la from audit-libs package - In auditctl, if syscall not given, default to all * Wed Jun 22 2005 Steve Grubb 0.9.12-1 - Add some syslog messages for a couple exits - Add some unlinks of the pid file in a couple error exits - Make some options of auditctl not expect a reply - Update support for user and watch filter lists cairo-0.5.1-3 ------------- * Wed Jun 22 2005 Kristian H??gsberg 0.5.1-3 - Add requirement on libpixman-devel for devel package. cman-kernel-2.6.11.5-20050601.152643.FC4.4 ------------------------------------------ coreutils-5.2.1-52 ------------------ * Wed Jun 22 2005 Tim Waugh 5.2.1-52 - Fixed stale-utmp patch so that 'who -r' and 'who -b' work again (bug #161264). desktop-printing-0.19-1 ----------------------- * Thu Jun 02 2005 Colin Walters - New upstream version - Disable session cupsd - Add evil find+perl command to change namespace back to com.redhat until we adapt Fedora cups patch dlm-kernel-2.6.11.5-20050601.152643.FC4.5 ----------------------------------------- emacs-21.4-6 ------------ * Thu Jun 23 2005 Jens Petersen - 21.4-6 - merge in changes from emacs22.spec conditionally - define emacs21 rpm macro switch to control major version and use it - update tramp to 2.0.49 * Fri Jun 17 2005 Jens Petersen - set arg0 to emacs in wrapper script (Peter Oliver, 149512#3) * Mon May 30 2005 Jens Petersen - move setting of require-final-newline from default.el to a comment in default .emacs (Ralph Loader, 119141) firefox-0:1.0.4-5 ----------------- * Thu Jun 23 2005 Kristian H??gsberg 0:1.0.4-3 - Add firefox-1.0-pango-cairo.patch to get rid of the last few Xft references, fixing the "no fonts" problem. - Copy over changes from FC4 branch. gcc-4.0.0-13 ------------ * Thu Jun 23 2005 Jakub Jelinek 4.0.0-13 - update from CVS - PRs bootstrap/17383, libfortran/16436, libfortran/19216, libstdc++/21726, libstdc++/22111 - fix libltdl fix for */lib64 paths (#156005) - fix ICE on invalid introduced in 4.0.0-10 (PR middle-end/22028) - further libstdc++.so symbol versioning fixes (PR libstdc++/22109) - fix ICE when compiling call with excessive size of arguments passed by value (#160718, PR middle-end/17965) - grmic fix (Archit Shah, #133180) gnbd-kernel-2.6.11.2-20050420.133124.FC4.38 ------------------------------------------- gphoto2-2.1.6-1 --------------- * Thu Jun 23 2005 Tim Waugh 2.1.6-1 - 2.1.6. jonas-0:4.3.3-1jpp_2fc ---------------------- * Thu Jun 23 2005 Gary Benson - 4.3.3-1jpp_2fc - Only compile jeremie stubs, and reenable ejbjars stuff. - Various tweaks to installed classloader repositories. - Various other tweaks (patch renames and the like). * Fri Jun 17 2005 Gary Benson - 4.3.3-1jpp_1fc - Avoid an API hole in libgcj's java.io.OutputStreamWriter. - Don't build IIOP stubs. - Disable anything that needs the (failing) ejbjars task. - Pick up javax.rmi classes from jonathan-rmi. - Remove almost all jarfiles from the tarball. - Build with system axis, mx4j, jacorb, etc. - Build with gif89encoder rather than bundled acme thing. * Wed Mar 09 2005 Fernando Nasser - 4.3.3.1jpp_4rh - Fix catalina links - Update documentation - Add patch to remove stack trace jonathan-rmi-3.1-2 ------------------ kernel-2.6.12-1.1400_FC5 ------------------------ * Thu Jun 23 2005 Dave Jones - 2.6.12-git5 - Revert ipw drivers back to those shipped with FC4 for the time being.. - Make Orinoco driver suck less. (Scanning/Roaming/Ethtool support). libwpd-0.8.2-1 -------------- * Wed Jun 22 2005 Caolan McNamara 0.8.1-2 - bump to latest version logrotate-3.7.1-11 ------------------ * Wed Jun 22 2005 Peter Vrabec 3.7.1-11 - enhance logrotate with "dateext", "maxage" logwatch-6.1.2-1 ---------------- * Thu Jun 23 2005 Ivana Varekova 6.1.2-1 - update to 6.1.2-1 mx4j-1:3.0.1-1jpp_2fc --------------------- * Fri Jun 24 2005 Gary Benson 0:3.0.1-1jpp_2fc - Compile JRMP stubs. thunderbird-0:1.0.2-7 --------------------- * Thu Jun 23 2005 Kristian H??gsberg 1.0.2-7 - Add firefox-1.0-pango-cairo.patch to get rid of the last few Xft references, fixing the "no fonts" problem. vsftpd-2.0.3-4 -------------- * Thu Jun 23 2005 Radek Vokal 2.0.3-4 - fixed requires for pam_loginuid * Wed Jun 01 2005 Radek Vokal 2.0.3-3 - vsftpd update for new audit system (#159223) Broken deps for ia64 ---------------------------------------------------------- axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 castor - 0.9.5-1jpp_1fc.noarch requires jta jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 wsdl4j - 1.5.1-1jpp_1fc.noarch requires java jessie - 1.0.0-8.noarch requires java >= 0:1.4 castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging rgmanager - 1.9.31-3.ia64 requires ccs magma-plugins - 1.0-0.pre16.11.ia64 requires libgulm.so.1.0()(64bit) vsftpd - 2.0.3-4.ia64 requires pam_loginuid.so java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging jonas - 4.3.3-1jpp_2fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_2fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_2fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_2fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_2fc.noarch requires mx4j >= 1:3.0.1 jonas - 4.3.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_2fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_2fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_2fc.noarch requires jasper5 jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper joram - 4.1.5-1jpp_2fc.noarch requires jmxri joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_2fc.noarch requires jta Broken deps for s390 ---------------------------------------------------------- jonas - 4.3.3-1jpp_2fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_2fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_2fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_2fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_2fc.noarch requires mx4j >= 1:3.0.1 jonas - 4.3.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_2fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_2fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_2fc.noarch requires jasper5 axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14 jessie - 1.0.0-8.noarch requires java >= 0:1.4 selinux-policy-targeted - 1.23.18-15.noarch requires kernel >= 0:2.6.11-1.1219 castor - 0.9.5-1jpp_1fc.noarch requires jta geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 selinux-policy-strict-sources - 1.23.18-15.noarch requires kernel >= 0:2.6.11-1.1219 quota - 1:3.12-6.s390 requires kernel >= 0:2.4 gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2 wsdl4j - 1.5.1-1jpp_1fc.noarch requires java avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21 xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0 velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections ecj - 1:3.1-0.M4.9.s390 requires katana >= 0:2.0.0 jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6 sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2 castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 joram - 4.1.5-1jpp_2fc.noarch requires jmxri joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_2fc.noarch requires jta jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0 hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11 jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper lvm2 - 2.01.12-1.0.s390 requires kernel >= 0:2.6 hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10 jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 selinux-policy-strict - 1.23.18-15.noarch requires kernel >= 0:2.6.11-1.1219 jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 selinux-policy-targeted-sources - 1.23.18-15.noarch requires kernel >= 0:2.6.11-1.1219 jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging dhcp - 10:3.0.2-14.s390 requires kernel >= 0:2.2.18 jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 Broken deps for s390x ---------------------------------------------------------- wsdl4j - 1.5.1-1jpp_1fc.noarch requires java jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging dhcp - 10:3.0.2-14.s390x requires kernel >= 0:2.2.18 nfs-utils - 1.0.7-8.s390x requires kernel >= 0:2.2.14 arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0 prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10 castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 selinux-policy-strict - 1.23.18-15.noarch requires kernel >= 0:2.6.11-1.1219 jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 lvm2 - 2.01.12-1.0.s390x requires kernel >= 0:2.6 sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21 gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2 selinux-policy-strict-sources - 1.23.18-15.noarch requires kernel >= 0:2.6.11-1.1219 hal - 0.5.2-2.s390x requires kernel >= 0:2.6.11 jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 castor - 0.9.5-1jpp_1fc.noarch requires jta initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6 joram - 4.1.5-1jpp_2fc.noarch requires jmxri joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_2fc.noarch requires jta ecj - 1:3.1-0.M4.9.s390x requires katana >= 0:2.0.0 jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 jessie - 1.0.0-8.noarch requires java >= 0:1.4 xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0 sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit) libpcap - 14:0.8.3-14.s390x requires kernel >= 0:2.2.0 hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11 jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 jonas - 4.3.3-1jpp_2fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_2fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_2fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_2fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_2fc.noarch requires mx4j >= 1:3.0.1 jonas - 4.3.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_2fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_2fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_2fc.noarch requires jasper5 jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet selinux-policy-targeted-sources - 1.23.18-15.noarch requires kernel >= 0:2.6.11-1.1219 jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 selinux-policy-targeted - 1.23.18-15.noarch requires kernel >= 0:2.6.11-1.1219 quota - 1:3.12-6.s390x requires kernel >= 0:2.4 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper Broken deps for x86_64 ---------------------------------------------------------- dlm-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1395_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel = 0:2.6.12-1.1395_FC5 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.4.x86_64 requires /lib/modules/2.6.12-1.1395_FC5smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.4.x86_64 requires kernel-smp = 0:2.6.12-1.1395_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.2.x86_64 requires /lib/modules/2.6.11-1.1369_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.2.x86_64 requires kernel = 0:2.6.11-1.1369_FC4 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires /lib/modules/2.6.12-1.1395_FC5smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.x86_64 requires kernel-smp = 0:2.6.12-1.1395_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.38.x86_64 requires /lib/modules/2.6.12-1.1395_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.38.x86_64 requires kernel = 0:2.6.12-1.1395_FC5 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.2.x86_64 requires /lib/modules/2.6.11-1.1369_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.2.x86_64 requires kernel-smp = 0:2.6.11-1.1369_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.4.x86_64 requires /lib/modules/2.6.12-1.1395_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.4.x86_64 requires kernel = 0:2.6.12-1.1395_FC5 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.38.x86_64 requires /lib/modules/2.6.12-1.1395_FC5smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.38.x86_64 requires kernel-smp = 0:2.6.12-1.1395_FC5 Broken deps for ppc64 ---------------------------------------------------------- vsftpd - 2.0.3-4.ppc64 requires pam_loginuid.so jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 castor - 0.9.5-1jpp_1fc.noarch requires jta ecj - 1:3.1-0.M4.9.ppc64 requires katana >= 0:2.0.0 axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java jessie - 1.0.0-8.noarch requires java >= 0:1.4 xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet jonas - 4.3.3-1jpp_2fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_2fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_2fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_2fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_2fc.noarch requires mx4j >= 1:3.0.1 jonas - 4.3.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_2fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_2fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_2fc.noarch requires jasper5 jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 cman-kernel - 2.6.11.5-20050601.152643.FC4.4.ppc64 requires /lib/modules/2.6.12-1.1395_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.4.ppc64 requires kernel = 0:2.6.12-1.1395_FC5 jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging system-config-mouse - 1.2.11-1.noarch requires pyxf86config gnbd-kernel - 2.6.11.2-20050420.133124.FC4.38.ppc64 requires /lib/modules/2.6.12-1.1395_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.38.ppc64 requires kernel = 0:2.6.12-1.1395_FC5 jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 rhpl - 0.167-1.ppc64 requires pyxf86config >= 0:0.3.2 xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging system-config-keyboard - 1.2.6-2.noarch requires pyxf86config dlm-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires /lib/modules/2.6.12-1.1395_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc64 requires kernel = 0:2.6.12-1.1395_FC5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 joram - 4.1.5-1jpp_2fc.noarch requires jmxri joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_2fc.noarch requires jta wsdl4j - 1.5.1-1jpp_1fc.noarch requires java jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit) gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit) avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet ppc64-utils - 0.7-9.ppc64 requires yaboot system-config-display - 1.0.29-1.noarch requires /usr/X11R6/bin/Xorg system-config-display - 1.0.29-1.noarch requires pyxf86config >= 0:0.3.16 jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 Broken deps for i386 ---------------------------------------------------------- gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.38.i686 requires kernel-xenU = 0:2.6.12-1.1395_FC5 gnbd-kernel-xenU - 2.6.11.2-20050420.133124.FC4.38.i686 requires /lib/modules/2.6.12-1.1395_FC5xenU GFS-kernel-xen0 - 2.6.11.8-20050601.152643.FC4.2.i686 requires kernel-xen0 = 0:2.6.11-1.1369_FC4 gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.38.i686 requires /lib/modules/2.6.12-1.1395_FC5xen0 gnbd-kernel-xen0 - 2.6.11.2-20050420.133124.FC4.38.i686 requires kernel-xen0 = 0:2.6.12-1.1395_FC5 gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.38.i686 requires /lib/modules/2.6.12-1.1395_FC5smp gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.38.i686 requires kernel-smp = 0:2.6.12-1.1395_FC5 dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1395_FC5smp dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-smp = 0:2.6.12-1.1395_FC5 dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1395_FC5xen0 dlm-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xen0 = 0:2.6.12-1.1395_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires /lib/modules/2.6.12-1.1395_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.5.i586 requires kernel = 0:2.6.12-1.1395_FC5 cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.4.i686 requires /lib/modules/2.6.12-1.1395_FC5xen0 cman-kernel-xen0 - 2.6.11.5-20050601.152643.FC4.4.i686 requires kernel-xen0 = 0:2.6.12-1.1395_FC5 GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.2.i686 requires /lib/modules/2.6.11-1.1369_FC4xenU GFS-kernel-xenU - 2.6.11.8-20050601.152643.FC4.2.i686 requires kernel-xenU = 0:2.6.11-1.1369_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.38.i686 requires /lib/modules/2.6.12-1.1395_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.38.i686 requires kernel = 0:2.6.12-1.1395_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.2.i586 requires /lib/modules/2.6.11-1.1369_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.2.i586 requires kernel = 0:2.6.11-1.1369_FC4 dlm-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1395_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel = 0:2.6.12-1.1395_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.4.i586 requires /lib/modules/2.6.12-1.1395_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.4.i586 requires kernel = 0:2.6.12-1.1395_FC5 cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.4.i686 requires /lib/modules/2.6.12-1.1395_FC5smp cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.4.i686 requires kernel-smp = 0:2.6.12-1.1395_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.4.i686 requires /lib/modules/2.6.12-1.1395_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.4.i686 requires kernel = 0:2.6.12-1.1395_FC5 GFS-kernel - 2.6.11.8-20050601.152643.FC4.2.i686 requires /lib/modules/2.6.11-1.1369_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.2.i686 requires kernel = 0:2.6.11-1.1369_FC4 GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.2.i686 requires /lib/modules/2.6.11-1.1369_FC4smp GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.2.i686 requires kernel-smp = 0:2.6.11-1.1369_FC4 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.38.i586 requires /lib/modules/2.6.12-1.1395_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.38.i586 requires kernel = 0:2.6.12-1.1395_FC5 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.4.i686 requires kernel-xenU = 0:2.6.12-1.1395_FC5 cman-kernel-xenU - 2.6.11.5-20050601.152643.FC4.4.i686 requires /lib/modules/2.6.12-1.1395_FC5xenU dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires kernel-xenU = 0:2.6.12-1.1395_FC5 dlm-kernel-xenU - 2.6.11.5-20050601.152643.FC4.5.i686 requires /lib/modules/2.6.12-1.1395_FC5xenU Broken deps for ppc ---------------------------------------------------------- GFS-kernel - 2.6.11.8-20050601.152643.FC4.2.ppc requires /lib/modules/2.6.11-1.1369_FC4 GFS-kernel - 2.6.11.8-20050601.152643.FC4.2.ppc requires kernel = 0:2.6.11-1.1369_FC4 cman-kernel - 2.6.11.5-20050601.152643.FC4.4.ppc requires /lib/modules/2.6.12-1.1395_FC5 cman-kernel - 2.6.11.5-20050601.152643.FC4.4.ppc requires kernel = 0:2.6.12-1.1395_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires /lib/modules/2.6.12-1.1395_FC5 dlm-kernel - 2.6.11.5-20050601.152643.FC4.5.ppc requires kernel = 0:2.6.12-1.1395_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.38.ppc requires /lib/modules/2.6.12-1.1395_FC5 gnbd-kernel - 2.6.11.2-20050420.133124.FC4.38.ppc requires kernel = 0:2.6.12-1.1395_FC5 From mattdm at mattdm.org Fri Jun 24 12:35:14 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 24 Jun 2005 08:35:14 -0400 Subject: rpm packages of thunderbird/firefox extensions In-Reply-To: <42BBC969.5080406@redhat.com> References: <42BB3116.2070304@cora.nwra.com> <42BBC969.5080406@redhat.com> Message-ID: <20050624123514.GA5888@jadzia.bu.edu> On Fri, Jun 24, 2005 at 04:50:49AM -0400, Christopher Aillon wrote: > Is it possible? Yes. Is it easy? Not really, due to the way that the > extension manager works in Firefox 1.0 -- the extension manager in > Firefox 1.1 is much nicer and works better with Linux. I also don't > provide devel packages for either because of some packaging conflict > issues with the mozilla package, so it is slightly more difficult as well. Hey Christopher -- is the new extension manager going to deal with the updating-per-user-extensions-and-themese issue at all? Or is the idea going to be to break that completely and ask people to install extensions system-wide? Or, is there any way to mix-and-match gracefully? > I'm actually working on packaging up Deer Park Alpha 1, which is a very > early alpha release of Firefox 1.1, which should hit rawhide soon. I > will also get preview builds of xulrunner which should help to alleviate > this problem. I hope the situation will be much nicer for FC5. Me too. :) Oh, on a totally 'nother topic -- I saw some work recently on python bindings for XPCOM. Is that likely to make it into XULRunner in the, like, predicatable future? That would so rock. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 78 degrees Fahrenheit. From pjones at redhat.com Fri Jun 24 14:05:29 2005 From: pjones at redhat.com (Peter Jones) Date: Fri, 24 Jun 2005 10:05:29 -0400 Subject: FC4 kernel performance In-Reply-To: <57899.192.54.193.37.1119599385.squirrel@rousalka.dyndns.org> References: <42B94ACA.5090008@web.de> <20050622122310.GA8691@jadzia.bu.edu> <42B9A08F.4010806@web.de> <1119462107.3295.3.camel@rousalka.dyndns.org> <1119491674.3313.24.camel@jellyfish.redfishdemo.com> <42BADDD5.9060505@cornell.edu> <1119583206.4703.12.camel@goose> <57899.192.54.193.37.1119599385.squirrel@rousalka.dyndns.org> Message-ID: <1119621929.29512.1.camel@localhost.localdomain> On Fri, 2005-06-24 at 09:49 +0200, Nicolas Mailhot wrote: > On Ven 24 juin 2005 05:20, Rodd Clarkson wrote: > > However, the discussion was about > > data lost resulting for unwanted intrusion into you system including > > hackers, worms, viruses and that sort of thing. > > Read again the thread. > The discussion was about why your average user would ever need RAID, > SE-Linux and other weird server options in his FC kernel. And the point here is that SELinux isn't a "weird server option". It's just as important on a desktop box, because it helps contain even successful attacks and limits their potential damage. -- Peter From mmcgrath at iesabroad.org Fri Jun 24 14:54:44 2005 From: mmcgrath at iesabroad.org (Mike McGrath) Date: Fri, 24 Jun 2005 09:54:44 -0500 Subject: FC4 kernel performance Message-ID: > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com > [mailto:fedora-devel-list-bounces at redhat.com] On Behalf Of > Bernardo Innocenti > Sent: Thursday, June 23, 2005 6:54 PM > To: Development discussions related to Fedora Core > Subject: Re: FC4 kernel performance > > Paul A Houle wrote: > > > Disk-based backup ~is~ viable in various forms. For instance, > > it's quite practical to back up stuff disk to a USB 2.0 or Firewire > > drive, and it will finish faster than paint dries. I've found that > > network backup onto disks works too: but anything that's marketed > > explictly as a product for backup seems to be a scam. > > My favourite backup method is rsync'ing to an HD of the same > size, mounted on another server in a different room. > > This way I can run daily, unattended backups and be > reasonably protected against fire and robbery. > > Today, hard disks are larger, faster, more affordable and > more reliable than tapes or other removable media. > > If only I could use a compressed r/w filesystem for the > backup disk, I'd save a few bucks. JFFS2 is the only mature > filesystem that can do that, but it doesn't appear to be > usable with very large partitions. > > -- > // Bernardo Innocenti - Develer S.r.l., R&D dept. > \X/ http://www.develer.com/ > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > > I've run into a similar problem, I've been giving Amanda a try. It supports a backup to disk mode and I stick the backups onto a NAS device, I've had a few problems but not many... 2 cents. -Mike From djotaku1282 at yahoo.com Fri Jun 24 16:16:03 2005 From: djotaku1282 at yahoo.com (The DJ) Date: Fri, 24 Jun 2005 09:16:03 -0700 (PDT) Subject: FC4 Kernel Stack Size Message-ID: <20050624161603.28501.qmail@web50803.mail.yahoo.com> Hey, I'm looking for a reliable answer here. With FC3 I had to get a specially patched kernel to use ndiswrapper because the kernel stack was 4k and a larger stack size was needed. Downloaded a 16k FC3 kernel from Linuxtant and it worked. I was wondering what size the FC4 kernel stack is because I want to upgrade but Linuxtant hasn't yet provided a FC4 kernel. Thanks, __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcbw at redhat.com Fri Jun 24 16:29:14 2005 From: dcbw at redhat.com (Dan Williams) Date: Fri, 24 Jun 2005 12:29:14 -0400 Subject: FC4 Kernel Stack Size In-Reply-To: <20050624161603.28501.qmail@web50803.mail.yahoo.com> References: <20050624161603.28501.qmail@web50803.mail.yahoo.com> Message-ID: <1119630554.30289.14.camel@dcbw.boston.redhat.com> On Fri, 2005-06-24 at 09:16 -0700, The DJ wrote: > Hey, > > I'm looking for a reliable answer here. With FC3 I had to get a > specially patched kernel to use ndiswrapper because the kernel stack > was 4k and a larger stack size was needed. Downloaded a 16k FC3 > kernel from Linuxtant and it worked. I was wondering what size the > FC4 kernel stack is because I want to upgrade but Linuxtant hasn't yet > provided a FC4 kernel. FC4 also uses 4k stacks. Dan From orion at cora.nwra.com Fri Jun 24 16:21:49 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 24 Jun 2005 10:21:49 -0600 Subject: rpm packages of thunderbird/firefox extensions In-Reply-To: <42BBC969.5080406@redhat.com> References: <42BB3116.2070304@cora.nwra.com> <42BBC969.5080406@redhat.com> Message-ID: Christopher Aillon wrote: > I'm actually working on packaging up Deer Park Alpha 1, which is a very > early alpha release of Firefox 1.1, which should hit rawhide soon. I > will also get preview builds of xulrunner which should help to alleviate > this problem. I hope the situation will be much nicer for FC5. Thanks for the info. I'll wait then till FC5 for this. From omniuni at gmail.com Fri Jun 24 17:57:12 2005 From: omniuni at gmail.com (OmniUni) Date: Fri, 24 Jun 2005 13:57:12 -0400 Subject: Fedora Core LT Message-ID: <603d1b6805062410576b69245e@mail.gmail.com> I have worked often on computers that are not the greatest when it comes to the specs. Because of this, I thought that it would be a good idea to have a 2 CD, light-weight version of Fedora Core. I set myself to putting together just such a system, and you will find a list of the packages attached, called package-selection.txt. All toghether, the packages total only 1383 MB. If some packages need to be removed to fit on two CD's, I reccommend removing xmms, Abiword, Gnumeric, kdegraphics, and inkscape first. These packages, along with their dependencies, are nearly 40 MB. It is my hope that this can become a Fedora Core LT branch that will allow many more people to use Fedora Core. Here are some notes on the package list: - A calculator needs to be added - KDE default theme should be changed to Plasik - Available window managers: Fluxbox, XFCE4, KDE - Available office apps: OpenOffice, Abiword, Gnumeric - Available media apps include: GIMP, Inkscape, KolourPaint, KSnapshot, Noatun, XMMS - Available internet apps include: Firefox, Thunderbird, GAIM, Konqueror - Other Apps: yum, K3B, KSysGuard, system-config-display etc. - If it does not fit on two CD's, please try to remove these apps first: inkscape, kdegraphics, abiword, gnumeric, xmms To try this package selection, print out added-yum.txt. Then perform a minimal install and run "yum install [packagecommand]" for each line in the printed added-yum.txt, where [packagecommand] is replaced by each line of the document.Change the default runlevel to 5, and you're ready to go! The list of commands is actually not too long. Good Luck, and I hope that this is useful. Please respond with thoughts, comments, suggestions, whatever... (maybe even some iso's! :D ) Sincerely, OmniUni -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: package-selection.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: added-yum.txt URL: From m.f.h at web.de Fri Jun 24 19:13:50 2005 From: m.f.h at web.de (Marcus Hartig) Date: Fri, 24 Jun 2005 21:13:50 +0200 Subject: FC4 kernel performance In-Reply-To: <200506241719.11398.russell@coker.com.au> References: <42B94ACA.5090008@web.de> <200506241719.11398.russell@coker.com.au> Message-ID: <42BC5B6E.8020306@web.de> Russell Coker wrote: > Lots of people use desktop workstations with RAID-1. If you have two disks > then it has the potential to provide some significant advantages. I've > avoided data loss in the past by using RAID-1 on workstations. I've also used (software) RAID-0/RAID-1 for a longer time, but I have seen no big advantage for my private PC in the end... Regards, Marcus From Nicolas.Mailhot at laPoste.net Fri Jun 24 20:13:28 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Fri, 24 Jun 2005 22:13:28 +0200 Subject: Cairo [was: rawhide report: 20050621 changes] In-Reply-To: <1119473677.10405.47.camel@rousalka.dyndns.org> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> <1119428771.27240.113.camel@tarjei.predichem.nett> <1119444032.3335.14.camel@goose> <1119452774.27240.140.camel@tarjei.predichem.nett> <1119462274.10442.4.camel@localhost> <20050622201308.73f97fcf@nausicaa.camperquake.de> <1119464404.9395.2.camel@rousalka.dyndns.org> <1119464927.2804.1.camel@localhost> <1119473677.10405.47.camel@rousalka.dyndns.org> Message-ID: <1119644008.22219.4.camel@rousalka.dyndns.org> Le mercredi 22 juin 2005 ? 22:54 +0200, Nicolas Mailhot a ?crit : > Le mercredi 22 juin 2005 ? 14:28 -0400, Jon Nettleton a ?crit : > > > Everything is working great so far. As per an earlier email on this > > thread you have to go into /usr/bin/firefox and /usr/bin/mozilla and > > uncomment. > > > > MOZ_DISABLE_PANGO=1 > > export MOZ_DISABLE_PANGO > > Thanks, I had missed this part The new firefox package works as-is BUT it ignores the desktop DPI value. In my case that means all firefox GUI elements have a different text size than in other apps. RHAAA real screens are not limited to 96dpi. Whoever started hardcoding this value everywhere ? la windows did the Unix desktop a great disservice. Regards, -- Nicolas Mailhot -------------- 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 dhollis at davehollis.com Fri Jun 24 20:53:04 2005 From: dhollis at davehollis.com (David Hollis) Date: Fri, 24 Jun 2005 16:53:04 -0400 Subject: Fedora Core LT In-Reply-To: <603d1b6805062410576b69245e@mail.gmail.com> References: <603d1b6805062410576b69245e@mail.gmail.com> Message-ID: <1119646384.5368.15.camel@dhollis-lnx.sunera.com> On Fri, 2005-06-24 at 13:57 -0400, OmniUni wrote: > * A calculator needs to be added > * KDE default theme should be changed to Plasik > * Available window managers: Fluxbox, XFCE4, KDE > * Available office apps: OpenOffice, Abiword, Gnumeric > * Available media apps include: GIMP, Inkscape, KolourPaint, > KSnapshot, Noatun, XMMS > * Available internet apps include: Firefox, Thunderbird, GAIM, > Konqueror > * Other Apps: yum, K3B, KSysGuard, system-config-display etc. > * If it does not fit on two CD's, please try to remove these > apps first: inkscape, kdegraphics, abiword, gnumeric, xmms Not a bad idea to have a thinner, lighter version but it should really follow Fedora's standards more. For example, GNOME should be the UI and if you are shooting for a slimmer profile, why would there be so many redundant packages (3 window managers, 3+ office suites/apps, various graphics apps). Shouldn't it just be a best-of-breed/consistent with the rest style choice? And packages that aren't even included in FC itself shouldn't be included (Gnumeric moved to extras, Inkscape, noatun, etc are not in core). -- David Hollis -------------- 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 ivazquez at ivazquez.net Fri Jun 24 21:03:06 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 24 Jun 2005 17:03:06 -0400 Subject: Fedora Core LT In-Reply-To: <1119646384.5368.15.camel@dhollis-lnx.sunera.com> References: <603d1b6805062410576b69245e@mail.gmail.com> <1119646384.5368.15.camel@dhollis-lnx.sunera.com> Message-ID: <1119646986.3930.36.camel@ignacio.ignacio.lan> On Fri, 2005-06-24 at 16:53 -0400, David Hollis wrote: > And packages that aren't even included in FC > itself shouldn't be included (Gnumeric moved to extras, Inkscape, > noatun, etc are not in core). I would just like to say that putting non-Core packages in it isn't necessarily a bad idea, you just can't call it "Fedora Core" anymore. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 Jun 24 21:11:53 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 24 Jun 2005 17:11:53 -0400 Subject: Fedora Core LT In-Reply-To: <1119646986.3930.36.camel@ignacio.ignacio.lan> References: <603d1b6805062410576b69245e@mail.gmail.com> <1119646384.5368.15.camel@dhollis-lnx.sunera.com> <1119646986.3930.36.camel@ignacio.ignacio.lan> Message-ID: <604aa79105062414117929d46b@mail.gmail.com> On 6/24/05, Ignacio Vazquez-Abrams wrote: > I would just like to say that putting non-Core packages in it isn't > necessarily a bad idea, you just can't call it "Fedora Core" anymore. There is a large number of such 2 disk subsets that could be created like this. I'm pretty uncomfortable with opening the door to every possible re-combination of Extras + Core simply because it can be done. I'm pefectly willing to discuss such re-combinations that have a specific aim in mind. In this case, I'm not sure the package selections make sense for the stated task. Isn't the first 2 disks of the Core set already designed to do a default Desktop install? -jef From markdrago at mail.com Fri Jun 24 21:09:52 2005 From: markdrago at mail.com (Mark Drago) Date: Fri, 24 Jun 2005 17:09:52 -0400 Subject: Fedora Core LT In-Reply-To: <603d1b6805062410576b69245e@mail.gmail.com> References: <603d1b6805062410576b69245e@mail.gmail.com> Message-ID: <1119647392.11288.3.camel@mdrago.bascom.com> On Fri, 2005-06-24 at 13:57 -0400, OmniUni wrote: > I have worked often on computers that are not the greatest when it > comes to the specs. Because of this, I thought that it would be a good > idea to have a 2 CD, light-weight version of Fedora Core. I set myself > to putting together just such a system, and you will find a list of > the packages attached, called package-selection.txt. All toghether, > the packages total only 1383 MB. If some packages need to be removed > to fit on two CD's, I reccommend removing xmms, Abiword, Gnumeric, > kdegraphics, and inkscape first. These packages, along with their > dependencies, are nearly 40 MB. It is my hope that this can become a > Fedora Core LT branch that will allow many more people to use Fedora > Core. Here are some notes on the package list: > > Sincerely, > OmniUni How does this differ from just doing a 'Personal Desktop' install of FC that only requires the first 2 CDs anyway? --Mark. -------------- 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 mike at navi.cx Fri Jun 24 23:04:19 2005 From: mike at navi.cx (Mike Hearn) Date: Sat, 25 Jun 2005 00:04:19 +0100 Subject: C++ compatibility package dropped Message-ID: Hi, It's that time again! Fedora Core 4 no longer installs the compat-libstdc++ package by default, meaning that any users who install or run a C++ app which was built using GCC 3.3 or lower is now greeted with an incomprehensible and unhelpful error (or nothing, if they use the GUI). C++ is used by a lot of games and other commercial apps. Virtually none use the new C++ DSO version. Many never will. The release notes talk repeatedly about the "solid platform" that GCC 4 brings: this must be some new use of the word platform I have not yet encountered as to me the word platform implies some measure stability. This sort of thing crops up with every Fedora release. The message now, as then, is simple: this gratuitous and unnecessary breakage of backwards compatibility must end. If it does not all the work GNOME and the rest of the Fedora desktop team is putting in will be wasted - a usable desktop that falls flat on its face the moment you leave the CD set behind is not usable in the real world at all. Please, save the usual replies. I know some here think any packages not used within the distribution should be dropped. I know some don't care about games (even the open source ones). I don't want to hear it - Fedora is not the universe, and if it wishes to be taken seriously should not pretend to be. thanks -mike From mike at navi.cx Fri Jun 24 23:15:27 2005 From: mike at navi.cx (Mike Hearn) Date: Sat, 25 Jun 2005 00:15:27 +0100 Subject: FC4 kernel performance References: <42B94ACA.5090008@web.de> <20050622122310.GA8691@jadzia.bu.edu> <42B95F36.5010301@cornell.edu> <1119446162.13181.29.camel@moss-spartans.epoch.ncsc.mil> <42B9AAE2.2020500@cornell.edu> Message-ID: On Wed, 22 Jun 2005 14:16:02 -0400, Paul A Houle wrote: > Windows NT has a 'richer' security model than the traditional Unix > model, but nobody uses it. It's still DAC, just horrifically complex and baroque DAC. The reason nobody uses it has nothing to do with peoples interest/abilities in the security field, and everything to do with appalling (and NT specific) API design. thanks -mike From jakub at redhat.com Fri Jun 24 23:19:32 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Fri, 24 Jun 2005 19:19:32 -0400 Subject: C++ compatibility package dropped In-Reply-To: References: Message-ID: <20050624231932.GR22349@devserv.devel.redhat.com> On Sat, Jun 25, 2005 at 12:04:19AM +0100, Mike Hearn wrote: > Hi, > > It's that time again! Fedora Core 4 no longer installs the > compat-libstdc++ package by default, meaning that any users who install > or run a C++ app which was built using GCC 3.3 or lower is now greeted > with an incomprehensible and unhelpful error (or nothing, if they use the > GUI). There is no compat-libstdc++ package in FC4, only compat-libstdc++-296 and compat-libstdc++-33. Both are included in the Legacy Software Support group (which is rather small). Is it really that hard to check that group in if you want to use legacy software? Not everybody uses legacy software, so forcing it for everyone in the base group is a bad idea IMHO. Jakub From jspaleta at gmail.com Fri Jun 24 23:26:24 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 24 Jun 2005 19:26:24 -0400 Subject: C++ compatibility package dropped In-Reply-To: <20050624231932.GR22349@devserv.devel.redhat.com> References: <20050624231932.GR22349@devserv.devel.redhat.com> Message-ID: <604aa79105062416261383d488@mail.gmail.com> On 6/24/05, Jakub Jelinek wrote: > Is it really that hard to check that group in if you want to use > legacy software? Not everybody uses legacy software, so forcing > it for everyone in the base group is a bad idea IMHO. I think... the long term solution to address this issue, is to first find a way to inform users that a library is missing. Launching an app with a missing library from the gnome panel or menu doesn't give you feedback about the missking library. And beyond that hook the notification into a query of the configured repository metadata to make a suggestion as to what to install to get the missing library. -jef From nmiell at comcast.net Sat Jun 25 01:04:30 2005 From: nmiell at comcast.net (Nicholas Miell) Date: Fri, 24 Jun 2005 18:04:30 -0700 Subject: C++ compatibility package dropped In-Reply-To: <604aa79105062416261383d488@mail.gmail.com> References: <20050624231932.GR22349@devserv.devel.redhat.com> <604aa79105062416261383d488@mail.gmail.com> Message-ID: <1119661470.2943.2.camel@localhost.localdomain> On Fri, 2005-06-24 at 19:26 -0400, Jeff Spaleta wrote: > On 6/24/05, Jakub Jelinek wrote: > > Is it really that hard to check that group in if you want to use > > legacy software? Not everybody uses legacy software, so forcing > > it for everyone in the base group is a bad idea IMHO. > > I think... the long term solution to address this issue, is to first > find a way to inform users that a library is missing. Launching an app > with a missing library from the gnome panel or menu doesn't give you > feedback about the missking library. And beyond that hook the > notification into a query of the configured repository metadata to > make a suggestion as to what to install to get the missing library. > > -jef > While I agree with Jef that there needs to be some GUI feedback when dynamic linking fails, another useful long term solution would be to beat the C++ people with a cluebat until they stop breaking the ABI every release. -- Nicholas Miell From dimi at lattica.com Sat Jun 25 04:29:11 2005 From: dimi at lattica.com (Dimi Paun) Date: Sat, 25 Jun 2005 00:29:11 -0400 Subject: C++ compatibility package dropped In-Reply-To: <20050624231932.GR22349@devserv.devel.redhat.com> References: <20050624231932.GR22349@devserv.devel.redhat.com> Message-ID: <1119673751.6953.3.camel@dimi> On Fri, 2005-06-24 at 19:19 -0400, Jakub Jelinek wrote: > Is it really that hard to check that group in if you want to use > legacy software? Not everybody uses legacy software, so forcing > it for everyone in the base group is a bad idea IMHO. Well, it is simply because things will silently break without the user having any clue WTF is wrong. And yeah, 'forcing' it for everyone is not such a bad idea, all they lose is a little HD space. If we start arguing about a few megabytes, this is not the place to save them. And given the virtual zero cost for most people, breaking stuff silently for some is definitely a bad idea. -- Dimi Paun Lattica, Inc. From hvreddy1110 at gmail.com Sat Jun 25 04:59:36 2005 From: hvreddy1110 at gmail.com (harshavardhanreddy mandeepala) Date: Sat, 25 Jun 2005 10:29:36 +0530 Subject: autologin as a superuser Message-ID: <1dd5960805062421593a84af81@mail.gmail.com> hi I am using Linux fedora core 3. How can i autologin as a superuser (root). i am able to autologin as a non-root user but not as a root. i can hande the security issues if i can autologin as a root. so if u know the solution mail me to hvreddy11110 at gmail.com thanks in advance. Regards M.Harshavardhan Reddy From raven at themaw.net Sat Jun 25 04:56:41 2005 From: raven at themaw.net (Ian Kent) Date: Sat, 25 Jun 2005 12:56:41 +0800 (WST) Subject: FC4 Kernel Stack Size In-Reply-To: <20050624161603.28501.qmail@web50803.mail.yahoo.com> References: <20050624161603.28501.qmail@web50803.mail.yahoo.com> Message-ID: On Fri, 24 Jun 2005, The DJ wrote: > Hey, > > I'm looking for a reliable answer here. With FC3 I had to get a specially patched kernel to use ndiswrapper because the kernel stack was 4k and a larger stack size was needed. Downloaded a 16k FC3 kernel from Linuxtant and it worked. I was wondering what size the FC4 kernel stack is because I want to upgrade but Linuxtant hasn't yet provided a FC4 kernel. This modification shouldn't be so hard. I had to do it for an FC3 machine myself. What is more of a concern is that I saw some noise about making 4K stacks only for vanilla kernels. Anyway, 1) Grab the kernel source rpm and install it. 2) Alter the approiate config (eg SOURCE/kernel-2.6.11-i586.config). Find the line "CONFIG_4KSTACKS=y" and change the y to an n. 3) In SPECS/kernel-2.6.spec set the macros to build only what you need. eg. %define buildup 0 %define buildsmp 1 %define includexen 0 %define builddoc 0 4) Build the binary rpm. rpmbuild -bb -target=i686 SPECS/kernel-2.6.spec 5) Install binary package and your done. The --target option seems to be needed these days. I'm not sure why. You can make a source rpm for your kernel with this mod using rpmbuild -bs SPECS/kernel-2.6.spec Well at least this should be close to what you need to do. Oh and clean up using rpmbuild --rmspec --rmsource --clean kernel-2.6.spec Ian From symbiont at berlios.de Sat Jun 25 05:10:55 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Sat, 25 Jun 2005 13:10:55 +0800 Subject: autologin as a superuser In-Reply-To: <1dd5960805062421593a84af81@mail.gmail.com> References: <1dd5960805062421593a84af81@mail.gmail.com> Message-ID: <200506251310.55383.symbiont@berlios.de> On Saturday 25 June 2005 12:59, harshavardhanreddy mandeepala wrote: > so if u know the solution ?mail me ?to ? ? ? ? ? ? ? > hvreddy11110 at gmail.com We don't know how to support very well here. Go here: http://www.redhat.com/mailman/listinfo/fedora-list They'll know the answer. -- -jeff From jakub at redhat.com Sat Jun 25 07:37:59 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Sat, 25 Jun 2005 03:37:59 -0400 Subject: C++ compatibility package dropped In-Reply-To: <1119673751.6953.3.camel@dimi> References: <20050624231932.GR22349@devserv.devel.redhat.com> <1119673751.6953.3.camel@dimi> Message-ID: <20050625073759.GS22349@devserv.devel.redhat.com> On Sat, Jun 25, 2005 at 12:29:11AM -0400, Dimi Paun wrote: > On Fri, 2005-06-24 at 19:19 -0400, Jakub Jelinek wrote: > > Is it really that hard to check that group in if you want to use > > legacy software? Not everybody uses legacy software, so forcing > > it for everyone in the base group is a bad idea IMHO. > > Well, it is simply because things will silently break without > the user having any clue WTF is wrong. And yeah, 'forcing' it As long as the legacy programs people are installing are packaged as rpm, yum or other package managers can handle the dependencies just fine, so I don't see how is that a silent break. If not using a package manager, you take the responsibility of satisfying the dependencies yourself. > for everyone is not such a bad idea, all they lose is a little > HD space. If we start arguing about a few megabytes, this is not > the place to save them. The argument that Core needs to include everything just because some not properly packaged third party software might ever need it would is certainly not going to fly. What is so special about compatibility libstdc++? Jakub From dragoran at feuerpokemon.de Sat Jun 25 11:04:06 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Sat, 25 Jun 2005 13:04:06 +0200 Subject: FC4 kernel performance - debug In-Reply-To: <42BC5B6E.8020306@web.de> References: <42B94ACA.5090008@web.de> <200506241719.11398.russell@coker.com.au> <42BC5B6E.8020306@web.de> Message-ID: <42BD3A26.10104@feuerpokemon.de> why are the debug options are enabled in the stable kernels? they only should be on for rawhide, test releases and packages in updates-testing. From buildsys at redhat.com Sat Jun 25 11:21:33 2005 From: buildsys at redhat.com (Build System) Date: Sat, 25 Jun 2005 07:21:33 -0400 Subject: rawhide report: 20050625 changes Message-ID: <200506251121.j5PBLXTp015127@porkchop.devel.redhat.com> Removed package ecj Updated Packages: GFS-6.1.0-3 ----------- * Fri Jun 17 2005 Chris Feist - Synced to upstream sources. * Tue May 17 2005 Chris Feist - Synced to upstream sources. * Fri May 06 2005 Chris Feist - Cleaned up .spec file and %files section. GFS-kernel-2.6.11.8-20050601.152643.FC4.6 ----------------------------------------- HelixPlayer-1:1.0.5-1 --------------------- * Fri Jun 24 2005 Colin Walters 1:1.0.5-1 - Update to 1.0.5 - Remove some hardcoded 1.0.4 in specfile in favor of version var - New patch HelixPlayer-1.0.5-missing-header.patch audit-0.9.14-1 -------------- * Fri Jun 24 2005 Steve Grubb 0.9.14-1 - make auditctl -s work again - make AUDITD_CLEAN_STOP test in init scripts case insensitive authd-1.4.3-5.devel ------------------- * Fri Jun 24 2005 Martin Stransky - 1.4.3-5.devel - add xinetd to Prereq - fix for #150502 (authd doesn't map IPv6 to IPv4 from xinetd) ccs-1.0.0-1 ----------- cman-1.0.0-1 ------------ * Tue May 17 2005 Chris Feist - Require cman-kernel-modules. * Thu May 05 2005 Chris Feist - Added patch to disable starting up the init scripts. * Mon Dec 20 2004 Chris Feist - Rebuild with new sources. cman-kernel-2.6.11.5-20050601.152643.FC4.5 ------------------------------------------ dlm-1.0.0-3 ----------- * Tue May 17 2005 Chris Feist - Requires dlm-kernel-modules. * Sun May 08 2005 Florian La Roche - fix -devel requires * Fri May 06 2005 Chris Feist - Cleaned up .spec file. dlm-kernel-2.6.11.5-20050601.152643.FC4.7 ----------------------------------------- eclipse-1:3.1.0_fc-0.RC3.3 -------------------------- * Fri Jun 24 2005 Andrew Overholt 3.1.0_fc-0.RC3.3 - Add rcp requirement for platform (rh#161267). - Add un-owned osgi directories to libswt and platform. * Tue Jun 21 2005 Andrew Overholt 3.1.0_fc-0.RC3.2 - Use SWT bundle ID for SWT %files list (determine in %install). * Mon Jun 20 2005 Andrew Overholt 3.1.0_fc-0.RC3.1 - Import 3.1RC3. - Use FileInitializer (e.o#90535) - this should eliminate .sos in ~/.eclipse. - Add eclipse-filenamepatterns.txt ("*.so" currently) for above. - Symlink JNI libraries. fence-1.32.1-1 -------------- gnbd-1.0.0-1 ------------ * Tue May 17 2005 Chris Feist - Require cman-kernel-modules. * Fri May 06 2005 Chris Feist - Cleanup .spec file, don't glob /usr/share/man. * Mon Dec 20 2004 Chris Feist - Rebuild with new sources. gnbd-kernel-2.6.11.2-20050420.133124.FC4.39 ------------------------------------------- gulm-1.0.0-2 ------------ iddev-2.0.0-1 ------------- jonas-0:4.3.3-1jpp_3fc ---------------------- * Fri Jun 24 2005 Gary Benson - 4.3.3-1jpp_3fc - Symlink a copy of axis that slipped through. - Add howl-logger symlinks where required. - Ensure that ow_jonas_bootstrap.jar is on the classpath. - Various dependency fixes. magma-1.0.0-1 ------------- magma-plugins-1.0.0-2 --------------------- mkinitrd-4.2.17-1 ----------------- * Fri Jun 24 2005 Peter Jones - 4.2.17-1 - Don't use udev or udevstart in the initrd; it's trivial to do all that work by looking for directories with "dev" nodes in sysfs and making the device from the dirname using major/minor from "dev" rgmanager-1.9.34-5 ------------------ selinux-policy-strict-1.23.18-16 -------------------------------- * Thu Jun 23 2005 Dan Walsh 1.23.18-16 - Fix postgres to allow it to connect to auth - Change cyrus-imapd to write to /var/spool/imap - Add Russell patches selinux-policy-targeted-1.23.18-16 ---------------------------------- * Thu Jun 23 2005 Dan Walsh 1.23.18-16 - Fix postgres to allow it to connect to auth - Change cyrus-imapd to write to /var/spool/imap - Add Russell patches Broken deps for s390x ---------------------------------------------------------- sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit) nfs-utils - 1.0.7-8.s390x requires kernel >= 0:2.2.14 axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java hal - 0.5.2-2.s390x requires kernel >= 0:2.6.11 libpcap - 14:0.8.3-14.s390x requires kernel >= 0:2.2.0 jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30 jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_3fc.noarch requires jasper5 jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10 xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 selinux-policy-strict - 1.23.18-16.noarch requires kernel >= 0:2.6.11-1.1219 selinux-policy-targeted-sources - 1.23.18-16.noarch requires kernel >= 0:2.6.11-1.1219 wsdl4j - 1.5.1-1jpp_1fc.noarch requires java libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0 castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 jessie - 1.0.0-8.noarch requires java >= 0:1.4 avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj selinux-policy-strict-sources - 1.23.18-16.noarch requires kernel >= 0:2.6.11-1.1219 hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11 jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging lvm2 - 2.01.12-1.0.s390x requires kernel >= 0:2.6 castor - 0.9.5-1jpp_1fc.noarch requires jta sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21 initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6 jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 dhcp - 10:3.0.2-14.s390x requires kernel >= 0:2.2.18 xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2 arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0 joram - 4.1.5-1jpp_2fc.noarch requires jmxri joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_2fc.noarch requires jta selinux-policy-targeted - 1.23.18-16.noarch requires kernel >= 0:2.6.11-1.1219 quota - 1:3.12-6.s390x requires kernel >= 0:2.4 Broken deps for ia64 ---------------------------------------------------------- avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet castor - 0.9.5-1jpp_1fc.noarch requires jta jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30 jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_3fc.noarch requires jasper5 hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 vsftpd - 2.0.3-4.ia64 requires pam_loginuid.so jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging rgmanager - 1.9.31-3.ia64 requires ccs jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 wsdl4j - 1.5.1-1jpp_1fc.noarch requires java castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 jessie - 1.0.0-8.noarch requires java >= 0:1.4 velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper joram - 4.1.5-1jpp_2fc.noarch requires jmxri joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_2fc.noarch requires jta magma-plugins - 1.0-0.pre16.11.ia64 requires libgulm.so.1.0()(64bit) Broken deps for s390 ---------------------------------------------------------- geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 wsdl4j - 1.5.1-1jpp_1fc.noarch requires java hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 selinux-policy-targeted - 1.23.18-16.noarch requires kernel >= 0:2.6.11-1.1219 prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10 selinux-policy-targeted-sources - 1.23.18-16.noarch requires kernel >= 0:2.6.11-1.1219 axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11 sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2 jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 selinux-policy-strict-sources - 1.23.18-16.noarch requires kernel >= 0:2.6.11-1.1219 jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21 jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper selinux-policy-strict - 1.23.18-16.noarch requires kernel >= 0:2.6.11-1.1219 lvm2 - 2.01.12-1.0.s390 requires kernel >= 0:2.6 gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2 jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging castor - 0.9.5-1jpp_1fc.noarch requires jta avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0 castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30 jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_3fc.noarch requires jasper5 quota - 1:3.12-6.s390 requires kernel >= 0:2.4 java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14 jessie - 1.0.0-8.noarch requires java >= 0:1.4 libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0 jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6 jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging joram - 4.1.5-1jpp_2fc.noarch requires jmxri joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_2fc.noarch requires jta velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet dhcp - 10:3.0.2-14.s390 requires kernel >= 0:2.2.18 Broken deps for ppc64 ---------------------------------------------------------- jessie - 1.0.0-8.noarch requires java >= 0:1.4 jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 rhpl - 0.167-1.ppc64 requires pyxf86config >= 0:0.3.2 axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java wsdl4j - 1.5.1-1jpp_1fc.noarch requires java jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30 jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_3fc.noarch requires jasper5 system-config-keyboard - 1.2.6-2.noarch requires pyxf86config velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit) gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit) system-config-display - 1.0.29-1.noarch requires /usr/X11R6/bin/Xorg system-config-display - 1.0.29-1.noarch requires pyxf86config >= 0:0.3.16 vsftpd - 2.0.3-4.ppc64 requires pam_loginuid.so xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet ppc64-utils - 0.7-9.ppc64 requires yaboot xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 castor - 0.9.5-1jpp_1fc.noarch requires jta joram - 4.1.5-1jpp_2fc.noarch requires jmxri joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_2fc.noarch requires jta jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj system-config-mouse - 1.2.11-1.noarch requires pyxf86config avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet From vherva at vianova.fi Sat Jun 25 12:07:22 2005 From: vherva at vianova.fi (Ville Herva) Date: Sat, 25 Jun 2005 15:07:22 +0300 Subject: FC4 kernel performance In-Reply-To: <42BB924B.4020509@develer.com> References: <42B94ACA.5090008@web.de> <20050622122310.GA8691@jadzia.bu.edu> <42B9A08F.4010806@web.de> <1119462107.3295.3.camel@rousalka.dyndns.org> <1119491674.3313.24.camel@jellyfish.redfishdemo.com> <42BADDD5.9060505@cornell.edu> <42BB4BB0.9070807@develer.com> <20050624005029.GF16125@devserv.devel.redhat.com> <42BB924B.4020509@develer.com> Message-ID: <20050625120722.GB21004@viasys.com> On Fri, Jun 24, 2005 at 06:55:39AM +0200, you [Bernardo Innocenti] wrote: > > I'm ashamed to admit that sometimes I envy NTFS's transparent > file compression. Yes, it's very slow for general use, but it > would be ideal for backups, old log files, etc. > > ext2 has had an unsupported "compressed" attribute for years. > Perhaps it's extremely difficult to implement, but a very > desiderable feature that Linux still lacks. I've been running 2.2 kernel with the e2compr patch for years and it is very reliable. There are 2.4 and 2.6 patches, see http://e2compr.sourceforge.net/. The 2.4 patches weren't stable when I tried them years ago, but I understand Tim Southerwood is doing some 2.6 work now. And yes, it is very useful for backups. -- v -- v at iki.fi From hvreddy1110 at gmail.com Sat Jun 25 12:56:08 2005 From: hvreddy1110 at gmail.com (harshavardhanreddy mandeepala) Date: Sat, 25 Jun 2005 18:26:08 +0530 Subject: how to make a non-root user as superuser Message-ID: <1dd596080506250556576ec268@mail.gmail.com> hi I am using Linux fedora core 3. how can i make a non root user as a superuser. when ever i enter into system as a non root user by login ,the user must be super user. if u have a solution plz mail me to hvreddy1110 at gmail.com thanks in advance Regards M.Harshavardhan Reddy From otaylor at redhat.com Sat Jun 25 13:02:18 2005 From: otaylor at redhat.com (Owen Taylor) Date: Sat, 25 Jun 2005 09:02:18 -0400 Subject: Cairo [was: rawhide report: 20050621 changes] In-Reply-To: <1119644008.22219.4.camel@rousalka.dyndns.org> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> <1119428771.27240.113.camel@tarjei.predichem.nett> <1119444032.3335.14.camel@goose> <1119452774.27240.140.camel@tarjei.predichem.nett> <1119462274.10442.4.camel@localhost> <20050622201308.73f97fcf@nausicaa.camperquake.de> <1119464404.9395.2.camel@rousalka.dyndns.org> <1119464927.2804.1.camel@localhost> <1119473677.10405.47.camel@rousalka.dyndns.org> <1119644008.22219.4.camel@rousalka.dyndns.org> Message-ID: <1119704538.31707.4.camel@localhost.localdomain> On Fri, 2005-06-24 at 22:13 +0200, Nicolas Mailhot wrote: > Le mercredi 22 juin 2005 ? 22:54 +0200, Nicolas Mailhot a ?crit : > > Le mercredi 22 juin 2005 ? 14:28 -0400, Jon Nettleton a ?crit : > > > > > Everything is working great so far. As per an earlier email on this > > > thread you have to go into /usr/bin/firefox and /usr/bin/mozilla and > > > uncomment. > > > > > > MOZ_DISABLE_PANGO=1 > > > export MOZ_DISABLE_PANGO > > > > Thanks, I had missed this part > > The new firefox package works as-is BUT it ignores the desktop DPI > value. In my case that means all firefox GUI elements have a different > text size than in other apps. > > RHAAA real screens are not limited to 96dpi. Whoever started hardcoding > this value everywhere ? la windows did the Unix desktop a great > disservice. If firefox is ignoring the DPI setting, that isn't a reason for whining, that's a reason for filing a bug. But, actually, are you sure that firefox isn't *paying attention* to your DPI value while everything else is ignoring it? The DPI setting from gnome-font-properties isn't currently honored by GTK+ at the moment: it's part of the same set of stuff that needs to be hooked back up as hinting settings, etc. In terms of whether the DPI for font size specification to pixel sizes should be equal to the physical DPI of the screen: that's been discussed a lot elsewhere so I'm not going to get into it here. Regards, Owen -------------- 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 ivazquez at ivazquez.net Sat Jun 25 13:40:34 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sat, 25 Jun 2005 09:40:34 -0400 Subject: how to make a non-root user as superuser In-Reply-To: <1dd596080506250556576ec268@mail.gmail.com> References: <1dd596080506250556576ec268@mail.gmail.com> Message-ID: <1119706834.9012.1.camel@ignacio.ignacio.lan> Which part of "THIS IS NOT AN END-USER SUPPORT RESOURCE" are you having trouble with? -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 Jun 25 15:22:04 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 25 Jun 2005 17:22:04 +0200 Subject: Cairo [was: rawhide report: 20050621 changes] In-Reply-To: <1119452774.27240.140.camel@tarjei.predichem.nett> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> <1119428771.27240.113.camel@tarjei.predichem.nett> <1119444032.3335.14.camel@goose> <1119452774.27240.140.camel@tarjei.predichem.nett> Message-ID: <20050625172204.112c4525@nausicaa.camperquake.de> Hi. Tarjei Knapstad wrote: > Normal X window rendering should be on par or better than with current > vector drawing libraries. I can't imagine that serious performance > regressions against earlier vector drawing solutions won't be fixed > before Cairo goes live in gtk+ etc. Which rendering backend does gtk+ 2.7 use though cairo? glx if available? Always glx? Always "plain" X rendering? -- "Here's a warning for all motorists travelling West on the M4. You're heading towards Wales!" From otaylor at redhat.com Sat Jun 25 16:15:40 2005 From: otaylor at redhat.com (Owen Taylor) Date: Sat, 25 Jun 2005 12:15:40 -0400 Subject: Cairo [was: rawhide report: 20050621 changes] In-Reply-To: <20050625172204.112c4525@nausicaa.camperquake.de> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> <1119428771.27240.113.camel@tarjei.predichem.nett> <1119444032.3335.14.camel@goose> <1119452774.27240.140.camel@tarjei.predichem.nett> <20050625172204.112c4525@nausicaa.camperquake.de> Message-ID: <1119716140.31707.17.camel@localhost.localdomain> On Sat, 2005-06-25 at 17:22 +0200, Ralf Ertzinger wrote: > Hi. > > Tarjei Knapstad wrote: > > > Normal X window rendering should be on par or better than with current > > vector drawing libraries. I can't imagine that serious performance > > regressions against earlier vector drawing solutions won't be fixed > > before Cairo goes live in gtk+ etc. > > Which rendering backend does gtk+ 2.7 use though cairo? > glx if available? Always glx? Always "plain" X rendering? http://mail.gnome.org/archives/gtk-devel-list/2005-June/msg00166.html Regards, Owen -------------- 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 Nicolas.Mailhot at laPoste.net Sat Jun 25 16:51:28 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 25 Jun 2005 18:51:28 +0200 Subject: Cairo [was: rawhide report: 20050621 changes] In-Reply-To: <1119704538.31707.4.camel@localhost.localdomain> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> <1119428771.27240.113.camel@tarjei.predichem.nett> <1119444032.3335.14.camel@goose> <1119452774.27240.140.camel@tarjei.predichem.nett> <1119462274.10442.4.camel@localhost> <20050622201308.73f97fcf@nausicaa.camperquake.de> <1119464404.9395.2.camel@rousalka.dyndns.org> <1119464927.2804.1.camel@localhost> <1119473677.10405.47.camel@rousalka.dyndns.org> <1119644008.22219.4.camel@rousalka.dyndns.org> <1119704538.31707.4.camel@localhost.localdomain> Message-ID: <1119718289.9914.13.camel@rousalka.dyndns.org> Le samedi 25 juin 2005 ? 09:02 -0400, Owen Taylor a ?crit : > On Fri, 2005-06-24 at 22:13 +0200, Nicolas Mailhot wrote: > > Le mercredi 22 juin 2005 ? 22:54 +0200, Nicolas Mailhot a ?crit : > > > Le mercredi 22 juin 2005 ? 14:28 -0400, Jon Nettleton a ?crit : > > > > > > > Everything is working great so far. As per an earlier email on this > > > > thread you have to go into /usr/bin/firefox and /usr/bin/mozilla and > > > > uncomment. > > > > > > > > MOZ_DISABLE_PANGO=1 > > > > export MOZ_DISABLE_PANGO > > > > > > Thanks, I had missed this part > > > > The new firefox package works as-is BUT it ignores the desktop DPI > > value. In my case that means all firefox GUI elements have a different > > text size than in other apps. > > > > RHAAA real screens are not limited to 96dpi. Whoever started hardcoding > > this value everywhere ? la windows did the Unix desktop a great > > disservice. > > If firefox is ignoring the DPI setting, that isn't a reason for whining, > that's a reason for filing a bug. > > But, actually, are you sure that firefox isn't *paying attention* to > your DPI value while everything else is ignoring it? The DPI setting > from gnome-font-properties isn't currently honored by GTK+ at the > moment: it's part of the same set of stuff that needs to be hooked back > up as hinting settings, etc. I honestly don't know which one it's ignoring. I spent quite a long time hunting the 96dpi references last year, and firefox still finds a way to use a different size of the rest of the desktop, so it's ignoring all the changes I made at the time ALL GUI APPS SHOULD USE THE DPI VALUE REPORTED BY X I'm sick to death of searching for all the tuneables various apps writers put all over the place to override this value. Alternatively, let's all the bright people that decided individually this value was not good enough for them agree where they should fetch it from so I have a _single_ place to sync it with xdpyinfo manually. And I'm not whining, I'm reporting a problem, because most of the developers I know only use 96dpi so they won't see this (1. X is reporting a bad dpi value/I don't knwo how to read the X dpi value - let's add a tuneable to override it ! (instead of fixing X) 2. app 2 now looks different than app #1 - let's add another tuneable in app #2 ... 99. we have dpi settings all over the place - too much work to fix it, everyone should use 96dpi anyway) Sorry if I'm undiplomatic - this has been broken for so long a time I'm not finding it the least funny anymore. -- Nicolas Mailhot -------------- 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 otaylor at redhat.com Sat Jun 25 18:09:21 2005 From: otaylor at redhat.com (Owen Taylor) Date: Sat, 25 Jun 2005 14:09:21 -0400 Subject: Cairo [was: rawhide report: 20050621 changes] In-Reply-To: <1119718289.9914.13.camel@rousalka.dyndns.org> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> <1119428771.27240.113.camel@tarjei.predichem.nett> <1119444032.3335.14.camel@goose> <1119452774.27240.140.camel@tarjei.predichem.nett> <1119462274.10442.4.camel@localhost> <20050622201308.73f97fcf@nausicaa.camperquake.de> <1119464404.9395.2.camel@rousalka.dyndns.org> <1119464927.2804.1.camel@localhost> <1119473677.10405.47.camel@rousalka.dyndns.org> <1119644008.22219.4.camel@rousalka.dyndns.org> <1119704538.31707.4.camel@localhost.localdomain> <1119718289.9914.13.camel@rousalka.dyndns.org> Message-ID: <1119722961.31707.48.camel@localhost.localdomain> On Sat, 2005-06-25 at 18:51 +0200, Nicolas Mailhot wrote: > I honestly don't know which one it's ignoring. > I spent quite a long time hunting the 96dpi references last year, and > firefox still finds a way to use a different size of the rest of the > desktop, so it's ignoring all the changes I made at the time We completely replaced the entire font rendering path on the desktop (and most of the rest of the rendering), and there's some bugs in honoring the DPI values. The horror! The horror! I guess we should take it as a complement that these are the things that people are complaining about :-) Regards, Owen -------------- 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 Nicolas.Mailhot at laPoste.net Sat Jun 25 18:49:50 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 25 Jun 2005 20:49:50 +0200 Subject: Cairo [was: rawhide report: 20050621 changes] In-Reply-To: <1119722961.31707.48.camel@localhost.localdomain> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> <1119428771.27240.113.camel@tarjei.predichem.nett> <1119444032.3335.14.camel@goose> <1119452774.27240.140.camel@tarjei.predichem.nett> <1119462274.10442.4.camel@localhost> <20050622201308.73f97fcf@nausicaa.camperquake.de> <1119464404.9395.2.camel@rousalka.dyndns.org> <1119464927.2804.1.camel@localhost> <1119473677.10405.47.camel@rousalka.dyndns.org> <1119644008.22219.4.camel@rousalka.dyndns.org> <1119704538.31707.4.camel@localhost.localdomain> <1119718289.9914.13.camel@rousalka.dyndns.org> <1119722961.31707.48.camel@localhost.localdomain> Message-ID: <1119725391.10557.11.camel@rousalka.dyndns.org> Le samedi 25 juin 2005 ? 14:09 -0400, Owen Taylor a ?crit : > On Sat, 2005-06-25 at 18:51 +0200, Nicolas Mailhot wrote: > > > I honestly don't know which one it's ignoring. > > I spent quite a long time hunting the 96dpi references last year, and > > firefox still finds a way to use a different size of the rest of the > > desktop, so it's ignoring all the changes I made at the time > > We completely replaced the entire font rendering path on the desktop > (and most of the rest of the rendering), and there's some bugs in > honoring the DPI values. The horror! The horror! Well, I'd accept a behaviour change if it used the X server settings instead of fishing values from somewhere unknown. > I guess we should take it as a complement that these are the things > that people are complaining about :-) It's kind of sad that the Gnome project chooses to piss off a great part of its users every release for stuff no one really cares about (except could we have some behaviour stability please) but all its grand plans still do not seem to include a working font setup. I've seen the future desktop demos and I'm ready to accept tiger strips will change my life, but could we fix core stuff like font size before ? You know, the thing text consoles got right 30 years ago. I don't care if it works in 80% of the cases, I still spend most of my computer time reading text so 80% is not bloody good enough. That being said I'll go back to bed nurse my fever. Hope you find this funny. -- Nicolas Mailhot -------------- 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 walters at redhat.com Sat Jun 25 19:09:36 2005 From: walters at redhat.com (Colin Walters) Date: Sat, 25 Jun 2005 15:09:36 -0400 Subject: Cairo [was: rawhide report: 20050621 changes] In-Reply-To: <1119725391.10557.11.camel@rousalka.dyndns.org> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> <1119428771.27240.113.camel@tarjei.predichem.nett> <1119444032.3335.14.camel@goose> <1119452774.27240.140.camel@tarjei.predichem.nett> <1119462274.10442.4.camel@localhost> <20050622201308.73f97fcf@nausicaa.camperquake.de> <1119464404.9395.2.camel@rousalka.dyndns.org> <1119464927.2804.1.camel@localhost> <1119473677.10405.47.camel@rousalka.dyndns.org> <1119644008.22219.4.camel@rousalka.dyndns.org> <1119704538.31707.4.camel@localhost.localdomain> <1119718289.9914.13.camel@rousalka.dyndns.org> <1119722961.31707.48.camel@localhost.localdomain> <1119725391.10557.11.camel@rousalka.dyndns.org> Message-ID: <1119726577.3922.11.camel@nexus.verbum.private> On Sat, 2005-06-25 at 20:49 +0200, Nicolas Mailhot wrote: > It's kind of sad that the Gnome project chooses to piss off a great part > of its users every release for stuff no one really cares about (except > could we have some behaviour stability please) but all its grand plans > still do not seem to include a working font setup. Nicolas, this is *rawhide*. It's under development. There will be bugs. Flaming the developers does not help. Reporting useful, informative bugs in Bugzilla does. From Nicolas.Mailhot at laPoste.net Sat Jun 25 19:42:31 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 25 Jun 2005 21:42:31 +0200 Subject: Cairo [was: rawhide report: 20050621 changes] In-Reply-To: <1119726577.3922.11.camel@nexus.verbum.private> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> <1119428771.27240.113.camel@tarjei.predichem.nett> <1119444032.3335.14.camel@goose> <1119452774.27240.140.camel@tarjei.predichem.nett> <1119462274.10442.4.camel@localhost> <20050622201308.73f97fcf@nausicaa.camperquake.de> <1119464404.9395.2.camel@rousalka.dyndns.org> <1119464927.2804.1.camel@localhost> <1119473677.10405.47.camel@rousalka.dyndns.org> <1119644008.22219.4.camel@rousalka.dyndns.org> <1119704538.31707.4.camel@localhost.localdomain> <1119718289.9914.13.camel@rousalka.dyndns.org> <1119722961.31707.48.camel@localhost.localdomain> <1119725391.10557.11.camel@rousalka.dyndns.org> <1119726577.3922.11.camel@nexus.verbum.private> Message-ID: <1119728552.10880.9.camel@rousalka.dyndns.org> Le samedi 25 juin 2005 ? 15:09 -0400, Colin Walters a ?crit : > On Sat, 2005-06-25 at 20:49 +0200, Nicolas Mailhot wrote: > > > It's kind of sad that the Gnome project chooses to piss off a great part > > of its users every release for stuff no one really cares about (except > > could we have some behaviour stability please) but all its grand plans > > still do not seem to include a working font setup. > > Nicolas, this is *rawhide*. It's under development. There will be > bugs. Flaming the developers does not help. Reporting useful, > informative bugs in Bugzilla does. I know there are and will be bugs (after more than 7 years of rawhide desktop I think I know what to expect). However at some point in time rawhide was declared to be "dogfoodable". Font rendering is part of my small must-work private perimeter. It's pretty sad that after Keith provided us a top-notch font subsystem app writers still to not take advantage of it properly. But somehow managing this properly is always pretty low on the todo list. I'm starting to feel we'll be plagued by text rendering problems till it's made a release priority like UTF-8 was. Seems not sexy enough for people to fix it otherwise. -- Nicolas Mailhot -------------- 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 walters at redhat.com Sat Jun 25 20:22:30 2005 From: walters at redhat.com (Colin Walters) Date: Sat, 25 Jun 2005 16:22:30 -0400 Subject: Cairo [was: rawhide report: 20050621 changes] In-Reply-To: <1119728552.10880.9.camel@rousalka.dyndns.org> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> <1119428771.27240.113.camel@tarjei.predichem.nett> <1119444032.3335.14.camel@goose> <1119452774.27240.140.camel@tarjei.predichem.nett> <1119462274.10442.4.camel@localhost> <20050622201308.73f97fcf@nausicaa.camperquake.de> <1119464404.9395.2.camel@rousalka.dyndns.org> <1119464927.2804.1.camel@localhost> <1119473677.10405.47.camel@rousalka.dyndns.org> <1119644008.22219.4.camel@rousalka.dyndns.org> <1119704538.31707.4.camel@localhost.localdomain> <1119718289.9914.13.camel@rousalka.dyndns.org> <1119722961.31707.48.camel@localhost.localdomain> <1119725391.10557.11.camel@rousalka.dyndns.org> <1119726577.3922.11.camel@nexus.verbum.private> <1119728552.10880.9.camel@rousalka.dyndns.org> Message-ID: <1119730951.3922.20.camel@nexus.verbum.private> On Sat, 2005-06-25 at 21:42 +0200, Nicolas Mailhot wrote: > Le samedi 25 juin 2005 ? 15:09 -0400, Colin Walters a ?crit : > > On Sat, 2005-06-25 at 20:49 +0200, Nicolas Mailhot wrote: > > > > > It's kind of sad that the Gnome project chooses to piss off a great part > > > of its users every release for stuff no one really cares about (except > > > could we have some behaviour stability please) but all its grand plans > > > still do not seem to include a working font setup. > > > > Nicolas, this is *rawhide*. It's under development. There will be > > bugs. Flaming the developers does not help. Reporting useful, > > informative bugs in Bugzilla does. > > I know there are and will be bugs (after more than 7 years of rawhide > desktop I think I know what to expect). However at some point in time > rawhide was declared to be "dogfoodable". Font rendering is part of my > small must-work private perimeter. I agree, it should be dogfoodable. And I think that right now, it is. As annoying as this DPI bug probably is for you, it doesn't affect everyone. That said, I've hit bugs myself, like this one: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161653 But these issues are just bugs; they'll be fixed. And they'll be fixed faster if the developers don't have to spend time responding to mailing list complaints and instead get informative Bugzilla reports. From mike at navi.cx Sat Jun 25 20:41:46 2005 From: mike at navi.cx (Mike Hearn) Date: Sat, 25 Jun 2005 21:41:46 +0100 Subject: C++ compatibility package dropped References: <20050624231932.GR22349@devserv.devel.redhat.com> Message-ID: On Fri, 24 Jun 2005 19:19:32 -0400, Jakub Jelinek wrote: > There is no compat-libstdc++ package in FC4, only compat-libstdc++-296 and > compat-libstdc++-33. Yes, sorry, I was referring to the compat-libstdc++-33 package. > Both are included in the Legacy Software Support group (which is rather small). > Is it really that hard to check that group in if you want to use legacy > software? Not everybody uses legacy software, so forcing it for everyone > in the base group is a bad idea IMHO. Well, nobody knows whether they need it until they choose some random software and find that it's considered "legacy". In particular new software is often compiled against older DSO versions so the binaries work on more distributions, so this distinction is quite subtle. I don't think installing it by default really costs anything. It's, what, 3mb? If it's not installed by default then many users who just choose the Personal/Workstation install won't get it. Then they post tech support requests to my forums asking why they get this strange error they don't understand. This is the GNOME philosophy of "Just Works" defaults again - nobody suffers if the package is installed but not used, but people do suffer is the package is not installed and used. As to whether RPM should take care of this or not, well, there are many programs that are not in any repository. Maybe in an ideal world where every Linux user used Fedora and so every program was in some repository, then maybe ... but that isn't the current world so we can't assume people use RPM for everything. thanks -mike From otaylor at redhat.com Sat Jun 25 20:49:53 2005 From: otaylor at redhat.com (Owen Taylor) Date: Sat, 25 Jun 2005 16:49:53 -0400 Subject: Cairo [was: rawhide report: 20050621 changes] In-Reply-To: <1119728552.10880.9.camel@rousalka.dyndns.org> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> <1119428771.27240.113.camel@tarjei.predichem.nett> <1119444032.3335.14.camel@goose> <1119452774.27240.140.camel@tarjei.predichem.nett> <1119462274.10442.4.camel@localhost> <20050622201308.73f97fcf@nausicaa.camperquake.de> <1119464404.9395.2.camel@rousalka.dyndns.org> <1119464927.2804.1.camel@localhost> <1119473677.10405.47.camel@rousalka.dyndns.org> <1119644008.22219.4.camel@rousalka.dyndns.org> <1119704538.31707.4.camel@localhost.localdomain> <1119718289.9914.13.camel@rousalka.dyndns.org> <1119722961.31707.48.camel@localhost.localdomain> <1119725391.10557.11.camel@rousalka.dyndns.org> <1119726577.3922.11.camel@nexus.verbum.private> <1119728552.10880.9.camel@rousalka.dyndns.org> Message-ID: <1119732593.31707.53.camel@localhost.localdomain> On Sat, 2005-06-25 at 21:42 +0200, Nicolas Mailhot wrote: > Le samedi 25 juin 2005 ? 15:09 -0400, Colin Walters a ?crit : > > On Sat, 2005-06-25 at 20:49 +0200, Nicolas Mailhot wrote: > > > > > It's kind of sad that the Gnome project chooses to piss off a great part > > > of its users every release for stuff no one really cares about (except > > > could we have some behaviour stability please) but all its grand plans > > > still do not seem to include a working font setup. > > > > Nicolas, this is *rawhide*. It's under development. There will be > > bugs. Flaming the developers does not help. Reporting useful, > > informative bugs in Bugzilla does. > > I know there are and will be bugs (after more than 7 years of rawhide > desktop I think I know what to expect). However at some point in time > rawhide was declared to be "dogfoodable". Font rendering is part of my > small must-work private perimeter. It's "dogfoodable" not "gourmet dinnerable". The fact that your fonts are somewhat the wrong size is a not a drop-everything situation. And if it was? Well, actually, it was what I was working on this morning (Saturday morning), and I had the DPI setting working again on my system before I saw your email. It should be in Rawhide within the next week ... next time we push new Cairo, Pango, and GTK+ snapshots. > It's pretty sad that after Keith provided us a top-notch font subsystem > app writers still to not take advantage of it properly. But somehow > managing this properly is always pretty low on the todo list. > > I'm starting to feel we'll be plagued by text rendering problems till > it's made a release priority like UTF-8 was. Seems not sexy enough for > people to fix it otherwise. I don't think this debate is worth continuing further :-) Regards, Owen -------------- 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 Nicolas.Mailhot at laPoste.net Sat Jun 25 21:43:15 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 25 Jun 2005 23:43:15 +0200 Subject: Cairo [was: rawhide report: 20050621 changes] In-Reply-To: <1119732593.31707.53.camel@localhost.localdomain> References: <200506211102.j5LB2A69007309@porkchop.devel.redhat.com> <1119401177.3281.11.camel@jellyfish.redfishdemo.com> <1119428771.27240.113.camel@tarjei.predichem.nett> <1119444032.3335.14.camel@goose> <1119452774.27240.140.camel@tarjei.predichem.nett> <1119462274.10442.4.camel@localhost> <20050622201308.73f97fcf@nausicaa.camperquake.de> <1119464404.9395.2.camel@rousalka.dyndns.org> <1119464927.2804.1.camel@localhost> <1119473677.10405.47.camel@rousalka.dyndns.org> <1119644008.22219.4.camel@rousalka.dyndns.org> <1119704538.31707.4.camel@localhost.localdomain> <1119718289.9914.13.camel@rousalka.dyndns.org> <1119722961.31707.48.camel@localhost.localdomain> <1119725391.10557.11.camel@rousalka.dyndns.org> <1119726577.3922.11.camel@nexus.verbum.private> <1119728552.10880.9.camel@rousalka.dyndns.org> <1119732593.31707.53.camel@localhost.localdomain> Message-ID: <1119735795.11400.6.camel@rousalka.dyndns.org> > I don't think this debate is worth continuing further :-) Right, sorry, your answer just hit too many of my private buttons at a time I was not thinking straight. But at least now you know some people care about this ;). (and it'd be nice if it were not the first thing to break every time the infrastructure is overhauled) -- Nicolas Mailhot -------------- 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 wbeebe at gmail.com Sat Jun 25 23:53:58 2005 From: wbeebe at gmail.com (William Beebe) Date: Sat, 25 Jun 2005 19:53:58 -0400 Subject: how to make a non-root user as superuser In-Reply-To: <1119706834.9012.1.camel@ignacio.ignacio.lan> References: <1dd596080506250556576ec268@mail.gmail.com> <1119706834.9012.1.camel@ignacio.ignacio.lan> Message-ID: How about a more polite "this is not an end user support area..." as well as an equally polite pointer to where he can get support? Or is that too much for you to handle? On 6/25/05, Ignacio Vazquez-Abrams wrote: > Which part of "THIS IS NOT AN END-USER SUPPORT RESOURCE" are you having > trouble with? > > -- > Ignacio Vazquez-Abrams > http://fedora.ivazquez.net/ > > gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 > > > BodyID:41203188.2.n.logpart (stored separately) > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > > From fedora at wir-sind-cool.org Sun Jun 26 00:29:10 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sun, 26 Jun 2005 02:29:10 +0200 Subject: how to make a non-root user as superuser In-Reply-To: References: <1dd596080506250556576ec268@mail.gmail.com> <1119706834.9012.1.camel@ignacio.ignacio.lan> Message-ID: <20050626022910.1859ba36.fedora@wir-sind-cool.org> On Sat, 25 Jun 2005 19:53:58 -0400, William Beebe wrote: > How about a more polite "this is not an end user support area..." as > well as an equally polite pointer to where he can get support? Or is > that too much for you to handle? > > On 6/25/05, Ignacio Vazquez-Abrams wrote: > > Which part of "THIS IS NOT AN END-USER SUPPORT RESOURCE" are you having > > trouble with? William, see: http://www.redhat.com/mailman/listinfo/fedora-devel-list -- Michael Schwendt Fedora Core release 4 (Stentz) - Linux 2.6.11-1.1369_FC4 loadavg: 2.39 2.34 2.37 From omniuni at gmail.com Sun Jun 26 00:53:28 2005 From: omniuni at gmail.com (OmniUni) Date: Sat, 25 Jun 2005 17:53:28 -0700 Subject: Fedora Core LT Message-ID: <603d1b6805062517536ed1452e@mail.gmail.com> Linux and Open Source are about choice. Fedora Core LT would be about lightness. GNOME is without a doubt the heaviest window manager available on Linux. OpenOffice is not a light office suite. OpenOffice is included because it is almost a must. There are so many formats that it handles, and so much better than Abiword and Gnumeric, that it pretty much had to be included. These two apps are there because of their lightness. They could, however, be easily changed to KOffice. The original package set that I made included only two window managers, fluxbox and XFCE. They are very different, and though XFCE is my personal choice, fluxbox was a very small package to include, and provides the choice of window managers for even very slow computers. Why KDE? I could easily have chosen GNOME instead but I did not. There are two reasons. First, GNOME is much heavier than KDE. In recent releases, KDE is surprisingly fast for such a multi-talented WM. Also, including KDE allowed me to use some of the fantastic apps that come with it. For example, kdegraphics is less than 8 megabytes, but adds such programs as KView, KolourPaint, KIconEditor, and more. kdemultimedia is the same. Also, including KDE makes the distro suitable for even new users on older machines. It is my hope that as FC-LT would develop, that it would gain such attributes at it's own lighter kernel, a more refined package selection. I hope that this answers some of your questions. If you have any more- just send!! Sincerely, OmniUni Oh, and btw, all packages are in either Fedora Core Base or Extras. Fedora Core packages would all be compatable with FC-LT. Therefore, it can certainly be called a Fedora Core. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora at camperquake.de Sun Jun 26 00:56:11 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 26 Jun 2005 02:56:11 +0200 Subject: Fedora Core LT In-Reply-To: <603d1b6805062517536ed1452e@mail.gmail.com> References: <603d1b6805062517536ed1452e@mail.gmail.com> Message-ID: <20050626025611.234b4d0e@nausicaa.camperquake.de> Hi. OmniUni wrote: > Oh, and btw, all packages are in either Fedora Core Base or Extras. > Fedora Core packages would all be compatable with FC-LT. Therefore, it > can certainly be called a Fedora Core. Fedora Core is what Redhat provides. That and nothing else. -- of course it doesn't work, but look how fast it is. -- FvL (allegedly) From loony at loonybin.org Sun Jun 26 01:00:05 2005 From: loony at loonybin.org (Peter Arremann) Date: Sat, 25 Jun 2005 21:00:05 -0400 Subject: Fedora Core LT In-Reply-To: <603d1b6805062517536ed1452e@mail.gmail.com> References: <603d1b6805062517536ed1452e@mail.gmail.com> Message-ID: <200506252100.05632.loony@loonybin.org> On Saturday 25 June 2005 20:53, OmniUni wrote: > Oh, and btw, all packages are in either Fedora Core Base or Extras. Fedora > Core packages would all be compatable with FC-LT. Therefore, it can > certainly be called a Fedora Core. FC is not just about rpms. Its about the installer, about the Gnome interface and so on as well. Its the user experience... If you go KDE instead of Gnome you change the user experience - therefore calling it Fedora Core isn't real apropriate in my opinion. Peter. From alan at redhat.com Sun Jun 26 01:02:24 2005 From: alan at redhat.com (Alan Cox) Date: Sat, 25 Jun 2005 21:02:24 -0400 Subject: Fedora Core LT In-Reply-To: <200506252100.05632.loony@loonybin.org> References: <603d1b6805062517536ed1452e@mail.gmail.com> <200506252100.05632.loony@loonybin.org> Message-ID: <20050626010224.GA26625@devserv.devel.redhat.com> On Sat, Jun 25, 2005 at 09:00:05PM -0400, Peter Arremann wrote: > FC is not just about rpms. Its about the installer, about the Gnome interface > and so on as well. Its the user experience... If you go KDE instead of Gnome > you change the user experience - therefore calling it Fedora Core > isn't real apropriate in my opinion. >From the trademark perspective and from expectations I agree. It's Fedora based and what to do about naming "xyz's take on Fedora package selection" is a good question for discussion but probably on fedora-list. From wbeebe at gmail.com Sun Jun 26 06:39:18 2005 From: wbeebe at gmail.com (William Beebe) Date: Sun, 26 Jun 2005 02:39:18 -0400 Subject: how to make a non-root user as superuser In-Reply-To: <20050626022910.1859ba36.fedora@wir-sind-cool.org> References: <1dd596080506250556576ec268@mail.gmail.com> <1119706834.9012.1.camel@ignacio.ignacio.lan> <20050626022910.1859ba36.fedora@wir-sind-cool.org> Message-ID: Thank you, I was aware of that page. But it would have been more appropriate to address your response it to harshavardhanreddy mandeepala at the start of this thread when it would have really done some good. My comments were of a "rhetorical" nature, addressed to Ignacio Vazquez-Abrams. On 6/25/05, Michael Schwendt wrote: > On Sat, 25 Jun 2005 19:53:58 -0400, William Beebe wrote: > > > How about a more polite "this is not an end user support area..." as > > well as an equally polite pointer to where he can get support? Or is > > that too much for you to handle? > > > > On 6/25/05, Ignacio Vazquez-Abrams wrote: > > > Which part of "THIS IS NOT AN END-USER SUPPORT RESOURCE" are you having > > > trouble with? > > William, see: > http://www.redhat.com/mailman/listinfo/fedora-devel-list > > -- > Michael Schwendt > Fedora Core release 4 (Stentz) - Linux 2.6.11-1.1369_FC4 > loadavg: 2.39 2.34 2.37 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From ivazquez at ivazquez.net Sun Jun 26 10:14:24 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sun, 26 Jun 2005 06:14:24 -0400 Subject: how to make a non-root user as superuser In-Reply-To: References: <1dd596080506250556576ec268@mail.gmail.com> <1119706834.9012.1.camel@ignacio.ignacio.lan> Message-ID: <1119780864.4427.0.camel@ignacio.ignacio.lan> On Sat, 2005-06-25 at 19:53 -0400, William Beebe wrote: > How about a more polite "this is not an end user support area..." as > well as an equally polite pointer to where he can get support? Or is > that too much for you to handle? That idea has been tried twice already, with no success. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 carljohan at design.chalmers.se Sun Jun 26 10:58:49 2005 From: carljohan at design.chalmers.se (Carl-Johan Kjellander) Date: Sun, 26 Jun 2005 12:58:49 +0200 Subject: C++ compatibility package dropped In-Reply-To: <20050625073759.GS22349@devserv.devel.redhat.com> References: <20050624231932.GR22349@devserv.devel.redhat.com> <1119673751.6953.3.camel@dimi> <20050625073759.GS22349@devserv.devel.redhat.com> Message-ID: <42BE8A69.3020403@design.chalmers.se> Jakub Jelinek wrote: > As long as the legacy programs people are installing are packaged > as rpm, yum or other package managers can handle the dependencies > just fine, so I don't see how is that a silent break. > If not using a package manager, you take the responsibility > of satisfying the dependencies yourself. Won't the ones making those rpms have to look into the future and require that compat-libstdc++-XX is installed, even though that package doesn't exist yet for the current FC version? Otherwise I can't see how you can make yum do the right thing for an old app, maybe less than 6 months old even. /cjk -- begin 644 carljohan_at_kjellander_dot_com.gif Y1TE&.#=A(0`F`(```````/___RP`````(0`F```"@XR/!\N<#U.;+MI`<[U(>\!UGQ9BGT%>'D2I Y*=NX,2 at OUF2&<827ILW;^822C>\7!!Z1,!K'B5(6HQI6:7"A>Y?):D2^*U at NCV RLZYD-_T1U<@3W]A4(^$-W4]A#V")W6#.R"$;IR'@).46BN7$9>5D``#L` From arjanv at redhat.com Sun Jun 26 11:05:14 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Sun, 26 Jun 2005 13:05:14 +0200 Subject: C++ compatibility package dropped In-Reply-To: <42BE8A69.3020403@design.chalmers.se> References: <20050624231932.GR22349@devserv.devel.redhat.com> <1119673751.6953.3.camel@dimi> <20050625073759.GS22349@devserv.devel.redhat.com> <42BE8A69.3020403@design.chalmers.se> Message-ID: <1119783915.3215.25.camel@laptopd505.fenrus.org> On Sun, 2005-06-26 at 12:58 +0200, Carl-Johan Kjellander wrote: > Jakub Jelinek wrote: > > As long as the legacy programs people are installing are packaged > > as rpm, yum or other package managers can handle the dependencies > > just fine, so I don't see how is that a silent break. > > If not using a package manager, you take the responsibility > > of satisfying the dependencies yourself. > > Won't the ones making those rpms have to look into the future and > require that compat-libstdc++-XX is installed, even though that > package doesn't exist yet for the current FC version? nope rpm makes it a nice automatic versioned library dependency; there is no need to depend on any package name directly. -------------- 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 ivazquez at ivazquez.net Sun Jun 26 11:06:27 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sun, 26 Jun 2005 07:06:27 -0400 Subject: C++ compatibility package dropped In-Reply-To: <42BE8A69.3020403@design.chalmers.se> References: <20050624231932.GR22349@devserv.devel.redhat.com> <1119673751.6953.3.camel@dimi> <20050625073759.GS22349@devserv.devel.redhat.com> <42BE8A69.3020403@design.chalmers.se> Message-ID: <1119783987.4427.5.camel@ignacio.ignacio.lan> On Sun, 2005-06-26 at 12:58 +0200, Carl-Johan Kjellander wrote: > Jakub Jelinek wrote: > > As long as the legacy programs people are installing are packaged > > as rpm, yum or other package managers can handle the dependencies > > just fine, so I don't see how is that a silent break. > > If not using a package manager, you take the responsibility > > of satisfying the dependencies yourself. > > Won't the ones making those rpms have to look into the future and > require that compat-libstdc++-XX is installed, even though that > package doesn't exist yet for the current FC version? No. rpmbuild will pick up the library dep, and yum will fulfill it. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 buildsys at redhat.com Sun Jun 26 11:18:51 2005 From: buildsys at redhat.com (Build System) Date: Sun, 26 Jun 2005 07:18:51 -0400 Subject: rawhide report: 20050626 changes Message-ID: <200506261118.j5QBIpB1006868@porkchop.devel.redhat.com> Updated Packages: selinux-policy-strict-1.23.18-19 -------------------------------- * Mon Jun 27 2005 Dan Walsh 1.23.18-19 - Fix /opt * Mon Jun 27 2005 Dan Walsh 1.23.18-18 - Add passwd policy to targeted to maintain context on shadow file selinux-policy-targeted-1.23.18-19 ---------------------------------- * Mon Jun 27 2005 Dan Walsh 1.23.18-19 - Fix /opt * Mon Jun 27 2005 Dan Walsh 1.23.18-18 - Add passwd policy to targeted to maintain context on shadow file Broken deps for ia64 ---------------------------------------------------------- castor - 0.9.5-1jpp_1fc.noarch requires jta jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 magma-plugins - 1.0-0.pre16.11.ia64 requires libgulm.so.1.0()(64bit) jessie - 1.0.0-8.noarch requires java >= 0:1.4 rgmanager - 1.9.31-3.ia64 requires ccs jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 vsftpd - 2.0.3-4.ia64 requires pam_loginuid.so joram - 4.1.5-1jpp_2fc.noarch requires jmxri joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_2fc.noarch requires jta xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 wsdl4j - 1.5.1-1jpp_1fc.noarch requires java jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30 jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_3fc.noarch requires jasper5 avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 Broken deps for ppc64 ---------------------------------------------------------- jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java castor - 0.9.5-1jpp_1fc.noarch requires jta xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 system-config-display - 1.0.29-1.noarch requires /usr/X11R6/bin/Xorg system-config-display - 1.0.29-1.noarch requires pyxf86config >= 0:0.3.16 ppc64-utils - 0.7-9.ppc64 requires yaboot jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30 jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_3fc.noarch requires jasper5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet wsdl4j - 1.5.1-1jpp_1fc.noarch requires java jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 vsftpd - 2.0.3-4.ppc64 requires pam_loginuid.so rhpl - 0.167-1.ppc64 requires pyxf86config >= 0:0.3.2 jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections jessie - 1.0.0-8.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_2fc.noarch requires jmxri joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_2fc.noarch requires jta jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 system-config-keyboard - 1.2.6-2.noarch requires pyxf86config jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit) gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit) system-config-mouse - 1.2.11-1.noarch requires pyxf86config castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 Broken deps for s390 ---------------------------------------------------------- jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 selinux-policy-strict-sources - 1.23.18-19.noarch requires kernel >= 0:2.6.11-1.1219 xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging jessie - 1.0.0-8.noarch requires java >= 0:1.4 jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30 jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_3fc.noarch requires jasper5 java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0 castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java quota - 1:3.12-6.s390 requires kernel >= 0:2.4 prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10 jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2 selinux-policy-targeted - 1.23.18-19.noarch requires kernel >= 0:2.6.11-1.1219 xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging joram - 4.1.5-1jpp_2fc.noarch requires jmxri joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_2fc.noarch requires jta jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0 lvm2 - 2.01.12-1.0.s390 requires kernel >= 0:2.6 avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11 wsdl4j - 1.5.1-1jpp_1fc.noarch requires java sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21 selinux-policy-targeted-sources - 1.23.18-19.noarch requires kernel >= 0:2.6.11-1.1219 jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper selinux-policy-strict - 1.23.18-19.noarch requires kernel >= 0:2.6.11-1.1219 gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2 jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14 dhcp - 10:3.0.2-14.s390 requires kernel >= 0:2.2.18 castor - 0.9.5-1jpp_1fc.noarch requires jta initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6 Broken deps for s390x ---------------------------------------------------------- wsdl4j - 1.5.1-1jpp_1fc.noarch requires java arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0 prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10 selinux-policy-strict-sources - 1.23.18-19.noarch requires kernel >= 0:2.6.11-1.1219 castor - 0.9.5-1jpp_1fc.noarch requires jta jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2 hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11 sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit) xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet lvm2 - 2.01.12-1.0.s390x requires kernel >= 0:2.6 selinux-policy-strict - 1.23.18-19.noarch requires kernel >= 0:2.6.11-1.1219 nfs-utils - 1.0.7-8.s390x requires kernel >= 0:2.2.14 jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging joram - 4.1.5-1jpp_2fc.noarch requires jmxri joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_2fc.noarch requires jta quota - 1:3.12-6.s390x requires kernel >= 0:2.4 xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging libpcap - 14:0.8.3-14.s390x requires kernel >= 0:2.2.0 jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30 jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_3fc.noarch requires jasper5 hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6 jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper selinux-policy-targeted-sources - 1.23.18-19.noarch requires kernel >= 0:2.6.11-1.1219 selinux-policy-targeted - 1.23.18-19.noarch requires kernel >= 0:2.6.11-1.1219 jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java jessie - 1.0.0-8.noarch requires java >= 0:1.4 libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0 avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet dhcp - 10:3.0.2-14.s390x requires kernel >= 0:2.2.18 java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj hal - 0.5.2-2.s390x requires kernel >= 0:2.6.11 velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21 From omniuni at gmail.com Sun Jun 26 19:35:39 2005 From: omniuni at gmail.com (OmniUni) Date: Sun, 26 Jun 2005 12:35:39 -0700 Subject: XFCE Message-ID: <603d1b68050626123571efc908@mail.gmail.com> In case you all haven't noticed, if you wanted to create a similar interface to gnome on my FC-LT package selection, all you need to do is configure XFCE. Like GNOME, XFCE is gtk based, and there is already a great Bluecurve theme. Anaconda, the RPM's, the appearance, would all be like Fedora Core, but you have to remember that in order to create a release that is appropriate for lower end computers, there need to be changes. No one would expect a LT distro to be everything that a regular distro is. If the KDE apps can run w/o the desktop environment, feel free to remove it. If you can find apps that are as capable and small as the kde ones, feel free to remove them too. If you want to switch GNOME back to the version distributed in RedHat 7.3, that would be light enough for a FC-LT. If you want to re-write GNOME to make it faster and lighter, you can try that too, it might be light enough for FC-LT. My idea is not so much about making a 2 CD version of Fedora Core as it is about putting together a light linux distro that has many of the benefits of Fedora Core, including compatability, anaconda, bluecurve where possible, system-config-* utilities, and a fast release cycle. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora at camperquake.de Sun Jun 26 19:48:09 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 26 Jun 2005 21:48:09 +0200 Subject: XFCE In-Reply-To: <603d1b68050626123571efc908@mail.gmail.com> References: <603d1b68050626123571efc908@mail.gmail.com> Message-ID: <20050626194809.GA7455@ryoko.camperquake.de> On Sun, Jun 26, 2005 at 12:35:39PM -0700, OmniUni wrote: > My idea is not so much about making a 2 CD version of Fedora Core as it is > about putting together a light linux distro that has many of the benefits of > Fedora Core, including compatability, anaconda, bluecurve where possible, > system-config-* utilities, and a fast release cycle. Of course you are free to do that, there may even be people here interested in that and willing to help. You just can not call it "Fedora Core ". Ra - "Das alles, und noch viel mehr, wuerd' ich machen, wenn ich Koenig von Deutschland waer'." - lf From mike at navi.cx Sun Jun 26 20:11:30 2005 From: mike at navi.cx (Mike Hearn) Date: Sun, 26 Jun 2005 21:11:30 +0100 Subject: C++ compatibility package dropped References: <20050624231932.GR22349@devserv.devel.redhat.com> <1119673751.6953.3.camel@dimi> <20050625073759.GS22349@devserv.devel.redhat.com> <42BE8A69.3020403@design.chalmers.se> Message-ID: On Sun, 26 Jun 2005 12:58:49 +0200, Carl-Johan Kjellander wrote: > Won't the ones making those rpms have to look into the future and require > that compat-libstdc++-XX is installed, even though that package doesn't > exist yet for the current FC version? The problem is that: a) This requires every RPM to be in a yum repository. Usually if they aren't in Extras, FreshRPMs, Dag or somesuch then they are just an RPM on a download page. Then automatic dep resolution doesn't work. b) As the package is considered legacy, at some point it'll probably disappear entirely like NPTL is going to do (argh). So apart from shipping a private copy of the standard library there isn't really anything you can do here, except try and become a part of the "in crowd" by getting into Fedora Extras which puts you at the whim of Red Hat legal (and obviously doesn't work at all for commercial/free-as-in-beer software like RealPlayer). I know Real have got the same problem with libstdc++.so.5 disappearing, tech support requests are starting to appear. thanks -mike From subsolar at subsolar.com Sun Jun 26 20:38:10 2005 From: subsolar at subsolar.com (Paul) Date: Sun, 26 Jun 2005 15:38:10 -0500 Subject: C++ compatibility package dropped In-Reply-To: <42BE8A69.3020403@design.chalmers.se> References: <20050624231932.GR22349@devserv.devel.redhat.com> <1119673751.6953.3.camel@dimi> <20050625073759.GS22349@devserv.devel.redhat.com> <42BE8A69.3020403@design.chalmers.se> Message-ID: <1119818291.4774.4.camel@localhost> On Sun, 2005-06-26 at 12:58 +0200, Carl-Johan Kjellander wrote: > Jakub Jelinek wrote: > > As long as the legacy programs people are installing are packaged > > as rpm, yum or other package managers can handle the dependencies > > just fine, so I don't see how is that a silent break. > > If not using a package manager, you take the responsibility > > of satisfying the dependencies yourself. > > Won't the ones making those rpms have to look into the future and > require that compat-libstdc++-XX is installed, even though that > package doesn't exist yet for the current FC version? > > Otherwise I can't see how you can make yum do the right thing for an old > app, maybe less than 6 months old even. Commercial apps probably have the biggest trouble, since they usually don't use RPMs and the installer is not usually smart enough to recommend installing a certain package. A few I've run into are smart enough to check and at least stop the install saying you need libraries foo & bar installed. Paul Berger From marco_meyerhofer at freesurf.ch Sun Jun 26 20:14:03 2005 From: marco_meyerhofer at freesurf.ch (Marco Meyerhofer) Date: Sun, 26 Jun 2005 22:14:03 +0200 Subject: Desktop search tool using lucene Message-ID: <1119816843.5057.26.camel@rechner1.localdomain> Hello, Today desktop search tools are killer-apps, the hype about Beagle or Spotlight is really big. I think that Fedora needs a search tool to be competitive. As you might know Beagle uses a C# port of lucene (http://lucene.apache.org/). Lucene is a open source search engine written in java. It runs with gcj but was also ported to other languages like C++ or Python. There is allready a search tool based on lucene called regain (http://regain.sourceforge.net/). But I think it doesn't run with a free java implementation, also there is no live-indexing and no application integration, for example with evolution. It shouldn't be to hard to wright a tool based on lucene or a port of it. The hard things are live indexing (gamin??) and application integration. It would be great to see a desktop search tool in Fedora. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From jspaleta at gmail.com Sun Jun 26 20:52:52 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 26 Jun 2005 16:52:52 -0400 Subject: Desktop search tool using lucene In-Reply-To: <1119816843.5057.26.camel@rechner1.localdomain> References: <1119816843.5057.26.camel@rechner1.localdomain> Message-ID: <604aa791050626135236068e1a@mail.gmail.com> On 6/26/05, Marco Meyerhofer wrote: > It would be great to see a desktop search tool in Fedora. You might want to touch base with Mr. Tromey about this issue who has commented on this in his blog: http://www.peakpeak.com/~tromey/blog/2005/06/22#regain -jef" as seen on http://fedora.linux.duke.edu/fedorapeople/ "spaleta From vonbrand at inf.utfsm.cl Sun Jun 26 20:52:04 2005 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Sun, 26 Jun 2005 16:52:04 -0400 Subject: Desktop search tool using lucene In-Reply-To: Your message of "Sun, 26 Jun 2005 22:14:03 +0200." <1119816843.5057.26.camel@rechner1.localdomain> Message-ID: <200506262052.j5QKq4w4029659@laptop11.inf.utfsm.cl> Marco Meyerhofer wrote: > Today desktop search tools are killer-apps, the hype about Beagle or > Spotlight is really big. I think that Fedora needs a search tool to be > competitive. If you say so... [...] > It shouldn't be to hard to wright a tool based on lucene or a port of > it. The hard things are live indexing (gamin??) and application > integration. > It would be great to see a desktop search tool in Fedora. Congratulations! You've just found your very own open source project to work on. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From pri.rhl4 at iadonisi.to Sun Jun 26 21:56:59 2005 From: pri.rhl4 at iadonisi.to (Paul Iadonisi) Date: Sun, 26 Jun 2005 17:56:59 -0400 Subject: C++ compatibility package dropped In-Reply-To: References: Message-ID: <1119823019.13523.18.camel@md.nc.linuxlobbyist.org> On Sat, 2005-06-25 at 00:04 +0100, Mike Hearn wrote: [snip] > Please, save the usual replies. I know some here think any packages not > used within the distribution should be dropped. I know some don't care > about games (even the open source ones). I don't want to hear it - > Fedora is not the universe, and if it wishes to be taken seriously should > not pretend to be. Let me get this straight. You post your usual complaint about Fedora Core making it difficult for proprietary apps and open source developers who don't want to package their apps as rpms and submit them to *some* yum repo (or set up their own), and then don't want to hear the usually response? Yup, you're absolutely right. Fedora is NOT the universe. And anyone who expects Fedora to take the universe into consideration is going to be profoundly disappointed. I, for one, prefer Fedora to move forward, getting rid of old, crufty compat-* packages giving low priority to those who don't want to adapt their apps to Fedora's fast moving pace. *You* may not take Fedora seriously. I don't need backwards compat cruft for *me* to take it seriously. Even with being considered for the 'hobbyist, enthusiast, developer.' You want something that moves slower? Buy RHEL, or grab a copy of CentOS. Otherwise, take up the mantle and initiate the Fedora Compat project to scratch your own itch. You don't want to be beholden to Red Hat legal? Then don't call it that. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From fherrera at gmail.com Sun Jun 26 22:17:10 2005 From: fherrera at gmail.com (Fernando Herrera) Date: Mon, 27 Jun 2005 00:17:10 +0200 Subject: C++ compatibility package dropped In-Reply-To: <1119823019.13523.18.camel@md.nc.linuxlobbyist.org> References: <1119823019.13523.18.camel@md.nc.linuxlobbyist.org> Message-ID: <58d389c2050626151753ddfe6d@mail.gmail.com> On 6/26/05, Paul Iadonisi wrote: [...] > I, for one, prefer Fedora to move forward, getting rid of old, crufty > compat-* packages giving low priority to those who don't want to adapt > their apps to Fedora's fast moving pace. *You* may not take Fedora > seriously. I don't need backwards compat cruft for *me* to take it > seriously. Even with being considered for the 'hobbyist, enthusiast, > developer.' Is gcc 3.3 old and crutfy? Wow. 1 year ago?. Well, this compat breaking from gcc people plus non "old and crutfy" support on distros is making C++ (and gtkmm) a non possible platform for ISV's making software for Linux. And ISV don't have resources to package their application for every Linux distro, setting up repositories, etc... They just want to put a package and allow people to download it and install it easily. We have very few ISV making software for linux now, because we have very few desktop share, but this is changing... Salu2 From nmiell at comcast.net Sun Jun 26 22:35:20 2005 From: nmiell at comcast.net (Nicholas Miell) Date: Sun, 26 Jun 2005 15:35:20 -0700 Subject: C++ compatibility package dropped In-Reply-To: <58d389c2050626151753ddfe6d@mail.gmail.com> References: <1119823019.13523.18.camel@md.nc.linuxlobbyist.org> <58d389c2050626151753ddfe6d@mail.gmail.com> Message-ID: <1119825320.2946.2.camel@localhost.localdomain> On Mon, 2005-06-27 at 00:17 +0200, Fernando Herrera wrote: > On 6/26/05, Paul Iadonisi wrote: > [...] > > I, for one, prefer Fedora to move forward, getting rid of old, crufty > > compat-* packages giving low priority to those who don't want to adapt > > their apps to Fedora's fast moving pace. *You* may not take Fedora > > seriously. I don't need backwards compat cruft for *me* to take it > > seriously. Even with being considered for the 'hobbyist, enthusiast, > > developer.' > > Is gcc 3.3 old and crutfy? Wow. 1 year ago?. Well, this compat > breaking from gcc people plus non "old and crutfy" support on distros > is making C++ (and gtkmm) a non possible platform for ISV's making > software for Linux. This wouldn't be a problem if the C++ people stopped breaking the C++ ABI every single release. > And ISV don't have resources to package their > application for every Linux distro, setting up repositories, etc... > They just want to put a package and allow people to download it and > install it easily. > > We have very few ISV making software for linux now, because we have > very few desktop share, but this is changing... -- Nicholas Miell From mike at plan99.net Sun Jun 26 22:30:34 2005 From: mike at plan99.net (Mike Hearn) Date: Sun, 26 Jun 2005 23:30:34 +0100 Subject: C++ compatibility package dropped References: <1119823019.13523.18.camel@md.nc.linuxlobbyist.org> Message-ID: On Sun, 26 Jun 2005 17:56:59 -0400, Paul Iadonisi wrote: > Yup, you're absolutely right. Fedora is NOT the universe. And anyone > who expects Fedora to take the universe into consideration is going to be > profoundly disappointed. I don't think you work for Red Hat, but regardless it says on the Fedora about page: "The goal of The Fedora Project is to work with the Linux community to build a complete, general purpose operating system" which by definition means it needs to take the universe into consideration. If it doesn't then it's not, by any widely accepted definition of the word, an operating system. One of the goals is: "Create a complete general-purpose operating system with capabilities equivalent to competing operating systems" Windows and MacOS have good backwards compatibility, and that's a capability. So we need to match it. Another goal is: "Provide a robust development platform for building software, particularly open source software." But a platform that constantly shifts, changes, and in which parts disappear at a moments notice is not robust. Yet another goal is: "Emphasize usability and a "just works" philosophy in selecting default configuration and designing features." But dropping GCC 3.3 C++ support from the default configuration makes it less Just Works and more like the Linux we know from the old days: requires fiddling and expertise to make it work. I think you see my point. thanks -mike From caillon at redhat.com Sun Jun 26 22:49:22 2005 From: caillon at redhat.com (Christopher Aillon) Date: Sun, 26 Jun 2005 18:49:22 -0400 Subject: rpm packages of thunderbird/firefox extensions In-Reply-To: <20050624123514.GA5888@jadzia.bu.edu> References: <42BB3116.2070304@cora.nwra.com> <42BBC969.5080406@redhat.com> <20050624123514.GA5888@jadzia.bu.edu> Message-ID: <42BF30F2.40008@redhat.com> On 06/24/2005 08:35 AM, Matthew Miller wrote: > Oh, on a totally 'nother topic -- I saw some work recently on python > bindings for XPCOM. Is that likely to make it into XULRunner in the, like, > predicatable future? That would so rock. I'm hoping to make that the case. http://live.gnome.org/Epiphany_2fEphyPython_2fPyXPCOM for more. From pri.rhl4 at iadonisi.to Sun Jun 26 22:51:39 2005 From: pri.rhl4 at iadonisi.to (Paul Iadonisi) Date: Sun, 26 Jun 2005 18:51:39 -0400 Subject: C++ compatibility package dropped In-Reply-To: <58d389c2050626151753ddfe6d@mail.gmail.com> References: <1119823019.13523.18.camel@md.nc.linuxlobbyist.org> <58d389c2050626151753ddfe6d@mail.gmail.com> Message-ID: <1119826299.13523.43.camel@md.nc.linuxlobbyist.org> On Mon, 2005-06-27 at 00:17 +0200, Fernando Herrera wrote: [snip] > Is gcc 3.3 old and crutfy? Wow. 1 year ago?. Bad example. Read Dan William's post to this list titled "Re: Why no compat-gcc-3.4.3-22.fc4.i386.rpm ?" and dated "Thu, 23 Jun 2005 23:20:44 -0400 (EDT)". Gcc32 (compat-gcc-32-3.2.3-47) and GCC4 (gcc-4.0.0-8) are included which cover enough of the bases. > Well, this compat > breaking from gcc people plus non "old and crutfy" support on distros > is making C++ (and gtkmm) a non possible platform for ISV's making > software for Linux. You're really blowing this out of proportion. They can do what VMware does, for example, by including a copy of gtk2 2.4.0. Even including it as an optional component (for older or newer OS releases) would work and not increase the size of their package for the OS releases they target. > And ISV don't have resources to package their > application for every Linux distro, setting up repositories, etc... > They just want to put a package and allow people to download it and > install it easily. Then put it in a tarball, provide a short doc with known dependencies, and allow third parties to submit patches and/or spec files and/or whatever-it-is-debian-uses-to-build-packages. Sure, I'd rather see VMware always released in an rpm package for the latest and greatest Fedora Core release. But if they complain, I'd say just externalize *more* of their costs and let others either package it or provide an easy way to package it. (And as a side note, don't have a license that prohibits this type of activity.) > We have very few ISV making software for linux now, because we have > very few desktop share, but this is changing... And it will continue to change. Despite the ISVs. Make it difficult for the ISVs for the sake of making it difficult for them? No, that would be silly. But for the sake of forward movement and doing things better, I don't think we should be bending over backwards to provide backward compatibility for them. If C++ developers in particular want to complain, they need to direct at the GCC C++ team for breaking binary compatibility. Fedora Core 4 has the compromise of 3.2.3 and 4.0.0. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From pri.rhl4 at iadonisi.to Sun Jun 26 23:29:21 2005 From: pri.rhl4 at iadonisi.to (Paul Iadonisi) Date: Sun, 26 Jun 2005 19:29:21 -0400 Subject: C++ compatibility package dropped In-Reply-To: References: <1119823019.13523.18.camel@md.nc.linuxlobbyist.org> Message-ID: <1119828561.13523.74.camel@md.nc.linuxlobbyist.org> On Sun, 2005-06-26 at 23:30 +0100, Mike Hearn wrote: [snip] > I don't think you work for Red Hat, but regardless it says on the Fedora > about page: Well, I'm not sure if it has anything to do with the rest of your message, but I guess I'm now outed. ;-) As of about a month ago, I do work for Red Hat. But certainly not in development and likely don't have any more direct influence than anyone else on this list as a result of my employment. > "The goal of The Fedora Project is to work with the Linux community to > build a complete, general purpose operating system" > > which by definition means it needs to take the universe into > consideration. That's quite a leap. By whose definition? > If it doesn't then it's not, by any widely accepted > definition of the word, an operating system. So VxWorks is not an operating system? SymbianOS (sp?)? PalmOS? QNX? None of those are what I would call general purpose, but they sure are operating systems. > One of the goals is: > > "Create a complete general-purpose operating system with capabilities > equivalent to competing operating systems" > > Windows and MacOS have good backwards compatibility, and that's a > capability. Depends. Personally, I wouldn't call backwards compatibility a 'capability', per se. It's preserving old capability, so in that sense, yes. > So we need to match it. No, we don't. But if someone wants, they are free to set up a Fedora Compat repo, complete with kernels without nptl (if that's possible) and gcc/glibc packages that provide older compat-* pieces to allow older apps to run. > Another goal is: > > "Provide a robust development platform for building software, > particularly open source software." > > But a platform that constantly shifts, changes, and in which parts > disappear at a moments notice is not robust. For the particular issue you bring up in the beginning of this thread, all that is required is to package your product according to Fedora standards and provide a yum repo. > Yet another goal is: > > "Emphasize usability and a "just works" philosophy in selecting default > configuration and designing features." > > But dropping GCC 3.3 C++ support from the default configuration makes it > less Just Works and more like the Linux we know from the old days: > requires fiddling and expertise to make it work. A mime type entry to bring up a little usermode enabled applet when a '.repo' file into /etc/yum.repos.d/ would be a nice addition to the distro. For those who want their apps to Just Work with Fedora Core, provide an rpm, a yum repo, and an app.repo file. Or, take submissions from your users who care and are capable to provide it. I interpret Just Works somewhat different than you. And that is that everything *within the distro (and extras)* should Just Work. > I think you see my point. Oh, I do. I just don't agree. And on top of that, I believe you picked and chose what you like out of that list of objectives. I see nothing in there specifically about backward compatibility, and there's a glaring absence of mention of anything to do with proprietary software in particular. That wasn't an oversight. And there are a number of statements like "exclusively from open source software" and "leading edge of open source technology, by adopting and helping develop new features and version upgrades" and "encouragement and support exists for third party packaging" that, to me, imply that those who crafted these objectives were deliberate in not mentioning backward compatibility or proprietary software or software not properly packaged. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From jspaleta at gmail.com Sun Jun 26 23:47:53 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 26 Jun 2005 19:47:53 -0400 Subject: C++ compatibility package dropped In-Reply-To: References: <1119823019.13523.18.camel@md.nc.linuxlobbyist.org> Message-ID: <604aa791050626164735ecd46@mail.gmail.com> On 6/26/05, Mike Hearn wrote: > Windows and MacOS have good backwards compatibility, and that's a > capability. So we need to match it. Apple garuntees very limited backwards compatibility for c++ dso STARTING with the introduction of gcc 4.0 http://developer.apple.com/documentation/DeveloperTools/Conceptual/CppRuntimeEnv/index.html quoting http://developer.apple.com/documentation/DeveloperTools/Conceptual/CppRuntimeEnv/index.html "Apple guarantees ABI stability only for core language features. It does not guarantee stability for library classes, including std::string, std::map, and std::ostream among others." quoting http://developer.apple.com/documentation/DeveloperTools/Conceptual/CppRuntimeEnv/index.html "If your application must support versions of Mac OS X prior to 10.3.9, you must continue to link statically to libstdc++.a. You should also not use the GCC 4.0 compiler to create C++ programs for systems prior to 10.3.9" How about we not make over-reaching claims about what other operating systems do about backwards compatibility. If ALL application writers in the universe were linking statically to libsdc++ like Apple demanded before the release 10.3.9 would there be much to talk about in this thread? Do not confuse the objective list for Fedora as a set of garuntees for any Fedora Core release. Those objectives are long term goals that the project is working towards. If the upstream project developers stability of the exposed interfaces... 3rd party vendors should absolutely be aware of that before they decide to link dynamically to the library. Holding the downstream distributor responsible for the lack of stability is a bit.. short-sighted. -jef From jspaleta at gmail.com Sun Jun 26 23:50:31 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 26 Jun 2005 19:50:31 -0400 Subject: C++ compatibility package dropped In-Reply-To: <604aa791050626164735ecd46@mail.gmail.com> References: <1119823019.13523.18.camel@md.nc.linuxlobbyist.org> <604aa791050626164735ecd46@mail.gmail.com> Message-ID: <604aa7910506261650c7843c@mail.gmail.com> On 6/26/05, Jeff Spaleta wrote: > If the upstream project developers > stability of the exposed interfaces... that should read: If the upstream project developers do not promise stability of the exposed interfaces -jef From toshio at tiki-lounge.com Mon Jun 27 00:19:57 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Sun, 26 Jun 2005 20:19:57 -0400 Subject: XFCE In-Reply-To: <20050626194809.GA7455@ryoko.camperquake.de> References: <603d1b68050626123571efc908@mail.gmail.com> <20050626194809.GA7455@ryoko.camperquake.de> Message-ID: <1119831598.3061.8.camel@localhost> On Sun, 2005-06-26 at 21:48 +0200, Ralf Ertzinger wrote: > On Sun, Jun 26, 2005 at 12:35:39PM -0700, OmniUni wrote: > > > My idea is not so much about making a 2 CD version of Fedora Core as it is > > about putting together a light linux distro that has many of the benefits of > > Fedora Core, including compatability, anaconda, bluecurve where possible, > > system-config-* utilities, and a fast release cycle. > > Of course you are free to do that, there may even be people here > interested in that and willing to help. > > You just can not call it "Fedora Core ". > What kind of requirements might there be to calling it Fedora Lite? In one of the many proposals before Fedora Extras came out, there was the idea that alternate and associated distributions could be spun out of the FC+FE combination. That's not an official goal right now, but it seems it's possible (and desirous to some :-) to do. Open questions: - What infrastructure beyond the existing would these other respinnings of Fedora need? - What communications with current FE and FC packagers? - Are we willing to "bless" some with Fedora XXX names? Under what conditions? -Toshio -------------- 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 tiemann at redhat.com Mon Jun 27 00:36:31 2005 From: tiemann at redhat.com (Michael Tiemann) Date: Sun, 26 Jun 2005 20:36:31 -0400 Subject: XFCE In-Reply-To: <1119831598.3061.8.camel@localhost> References: <603d1b68050626123571efc908@mail.gmail.com> <20050626194809.GA7455@ryoko.camperquake.de> <1119831598.3061.8.camel@localhost> Message-ID: <1119832591.3710.15.camel@localhost.localdomain> On Sun, 2005-06-26 at 20:19, Toshio Kuratomi wrote: > On Sun, 2005-06-26 at 21:48 +0200, Ralf Ertzinger wrote: > > On Sun, Jun 26, 2005 at 12:35:39PM -0700, OmniUni wrote: > > > > > My idea is not so much about making a 2 CD version of Fedora Core as it is > > > about putting together a light linux distro that has many of the benefits of > > > Fedora Core, including compatability, anaconda, bluecurve where possible, > > > system-config-* utilities, and a fast release cycle. > > > > Of course you are free to do that, there may even be people here > > interested in that and willing to help. > > > > You just can not call it "Fedora Core ". > > > What kind of requirements might there be to calling it Fedora Lite? IANAL, but in every discussion I've had with people inside and outside of Red Hat, the assumption is that if it meets the Fedora contribution guidelines (i.e., 100% free and/or open source software) then you can call it Fedora Whatever as long as it doesn't step on anybody's toes. Now, calling something Fedora Core Whatever steps on Fedora Core, so that's a no-no. But IMHO, Fedora Live and Fedora Mini are two great names just waiting to become stand-alone distributions of the Fedora family. (Fedora Live would be something that boots as a Live CD and has the property that once booted, there is some /trivial/ way to say "Go ahead--make my day" and transform the live instance into a Fedora Core installation. Fedora Mini sounds like what you are trying to do: establish some minimal set of packages that can provide a decent experience in limited size environments. Again, it would be a bonus feature if there was a non-conflicting way of "updating" Fedora Mini to become Fedora Core plus some Fedora Extras packages. I think that having packages in Mini that are not in Extras would lead to all sorts of pain.) > In > one of the many proposals before Fedora Extras came out, there was the > idea that alternate and associated distributions could be spun out of > the FC+FE combination. That's not an official goal right now, but it > seems it's possible (and desirous to some :-) to do. Agreed. > Open questions: > - What infrastructure beyond the existing would these other respinnings > of Fedora need? See above...I think that anything that makes it natural to get to Fedora Core for any installation that is missing Core packages is one good design characteristic. The second, and perhaps more important is that any purpose-specific set of packages be composed of packages that are represented in Extras. If Fedora Foo has packages not in Extras, then it's a bit like working w/o regard to upstream. Since so much of Fedora is designed around a process of working with upstream, breaking the link to Extras is likely to break other things when you (or your users) least expect it. > - What communications with current FE and FC packagers? If Fedora Whatever is just a special combo of Extras + Core, then not a whole lot of special communication is needed--just pay attention to what's upstream and make clear how you are trying to make your combination of requirements work using whatever composition of packages you need. > - Are we willing to "bless" some with Fedora XXX names? Under what > conditions? It's up to the Steering Committee, but I would certainly lobby for this. I would really like to see Fedora GIS (a rich GRASS-based environment with all the bells and whistles of Postgis, R, Java, etc), Fedora 3D (a rich Blender-based environment with all sorts of rendering, scripting, paint, image processing, gphoto, and other tools), and a Fedora AV (a rich environment for audio synthesis, sequencing, editing, mixing, publishing, plus video import, editing, compositing, publishing, all 100% open source based around...what?). M > -Toshio > > ______________________________________________________________________ > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From skvidal at phy.duke.edu Mon Jun 27 01:47:38 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 26 Jun 2005 21:47:38 -0400 Subject: XFCE In-Reply-To: <1119832591.3710.15.camel@localhost.localdomain> References: <603d1b68050626123571efc908@mail.gmail.com> <20050626194809.GA7455@ryoko.camperquake.de> <1119831598.3061.8.camel@localhost> <1119832591.3710.15.camel@localhost.localdomain> Message-ID: <1119836858.4982.51.camel@cutter> > Fedora Mini sounds like what you are trying to do: 1. I think Fedora mini sounds like a red and black small car ;) > establish some minimal set of packages that can provide a decent > experience in limited size environments. Again, it would be a bonus > feature if there was a non-conflicting way of "updating" Fedora Mini to > become Fedora Core plus some Fedora Extras packages. I think that > having packages in Mini that are not in Extras would lead to all sorts > of pain.) > 2. What I would encourage folks to do in this situation is to try making a workable set of packages INSIDE a Xen install using only the repos in a default fedora core 4 install.(core, updates, extras) Then once you're happy with it - dump the packages out using: rpm -qa --qf "%{name}\n" and assemble those into a comps.xml file. Then if you want others to test it simply make a repository like this: mkdir myrepo cp mycomps.xml myrepo/mycomps.xml createrepo -g mycomps.xml myrepo then post the url to myrepo. Users can put that repo in their /etc/yum.repos.d/ dir and try it out. Moreover if you have a minimum install and you think it would fit well in core then post it up and give a list of 'features' available in that minimal install. Remember 'Core' in the comps.xml will always be installed, by default, on anaconda installs. -sv From pri.rhl4 at iadonisi.to Mon Jun 27 01:46:20 2005 From: pri.rhl4 at iadonisi.to (Paul Iadonisi) Date: Sun, 26 Jun 2005 21:46:20 -0400 Subject: C++ compatibility package dropped In-Reply-To: <1119828561.13523.74.camel@md.nc.linuxlobbyist.org> References: <1119823019.13523.18.camel@md.nc.linuxlobbyist.org> <1119828561.13523.74.camel@md.nc.linuxlobbyist.org> Message-ID: <1119836781.20558.1.camel@md.nc.linuxlobbyist.org> On Sun, 2005-06-26 at 19:29 -0400, Paul Iadonisi wrote: [snip] > A mime type entry to bring up a little usermode enabled applet when a > '.repo' file into /etc/yum.repos.d/ would be a nice addition to the > distro. argh. That should read: "A mime type entry to bring up a little usermode enabled applet when a '.repo' file is clicked on that will drop it into /etc/yum.repos.d/ would be a nice addition to the distro." -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From nmiell at comcast.net Mon Jun 27 02:06:14 2005 From: nmiell at comcast.net (Nicholas Miell) Date: Sun, 26 Jun 2005 19:06:14 -0700 Subject: C++ compatibility package dropped In-Reply-To: <1119836781.20558.1.camel@md.nc.linuxlobbyist.org> References: <1119823019.13523.18.camel@md.nc.linuxlobbyist.org> <1119828561.13523.74.camel@md.nc.linuxlobbyist.org> <1119836781.20558.1.camel@md.nc.linuxlobbyist.org> Message-ID: <1119837974.2946.4.camel@localhost.localdomain> On Sun, 2005-06-26 at 21:46 -0400, Paul Iadonisi wrote: > On Sun, 2005-06-26 at 19:29 -0400, Paul Iadonisi wrote: > > [snip] > > > A mime type entry to bring up a little usermode enabled applet when a > > '.repo' file into /etc/yum.repos.d/ would be a nice addition to the > > distro. > > argh. That should read: > > "A mime type entry to bring up a little usermode enabled applet when a > '.repo' file is clicked on that will drop it into /etc/yum.repos.d/ > would be a nice addition to the distro." Stuff that /etc/yum.repos.d/blah.repo into a RPM and you're done. FreshRPMs and (iirc) Livna do this right now. -- Nicholas Miell From skvidal at phy.duke.edu Mon Jun 27 02:10:47 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 26 Jun 2005 22:10:47 -0400 Subject: C++ compatibility package dropped In-Reply-To: <1119837974.2946.4.camel@localhost.localdomain> References: <1119823019.13523.18.camel@md.nc.linuxlobbyist.org> <1119828561.13523.74.camel@md.nc.linuxlobbyist.org> <1119836781.20558.1.camel@md.nc.linuxlobbyist.org> <1119837974.2946.4.camel@localhost.localdomain> Message-ID: <1119838247.4982.65.camel@cutter> > Stuff that /etc/yum.repos.d/blah.repo into a RPM and you're done. > FreshRPMs and (iirc) Livna do this right now. > livna now has a livna-release package. download that, install it, you're done. -sv From b.j.smith at ieee.org Mon Jun 27 02:37:28 2005 From: b.j.smith at ieee.org (Bryan J. Smith) Date: Sun, 26 Jun 2005 21:37:28 -0500 Subject: Fedora Core LT -- Cobind Linux ... In-Reply-To: <20050626005728.7474C73442@hormel.redhat.com> References: <20050626005728.7474C73442@hormel.redhat.com> Message-ID: <1119839848.5863.30.camel@bert64.mobile.smithconcepts.com> From: OmniUni > Linux and Open Source are about choice. > Fedora Core LT would be about lightness. > ... First, I would direct your interest to the Cobind Project: http://www.cobind.com/ Those gentlemen have done an excellent job, especially supporting more legacy hardware. > Oh, and btw, all packages are in either Fedora Core Base or Extras. Fedora > Core packages would all be compatable with FC-LT. Therefore, it can > certainly be called a Fedora Core. Secondly, no, I would not re-introduce the whole trademark issues again. It was bad enough that people got "Red Hat Linux" that was _not_ "Red Hat(R) Linux" (e.g., Cobalt, Sun, etc...), and I don't want to see that again with "Fedora(TM) Core." Call it something else. Or just hook up with the Cobind guys/gals. -- Bryan J. Smith b.j.smith at ieee.org --------------------------------------------------------------------- It is mathematically impossible for someone who makes more than you to be anything but richer than you. Any tax rate that penalizes them will also penalize you similarly (to those below you, and then below them). Linear algebra, let alone differential calculus or even ele- mentary concepts of limits, is mutually exclusive with US journalism. So forget even attempting to explain how tax cuts work. ;-> From mmitu at bitdefender.com Mon Jun 27 04:01:26 2005 From: mmitu at bitdefender.com (Mircea MITU) Date: Mon, 27 Jun 2005 07:01:26 +0300 Subject: ISV approach on C++ compatibility (was Re: C++ compatibility package dropped) In-Reply-To: References: Message-ID: <1119844887.14936.16.camel@localhost.localdomain> On Sat, 2005-06-25 at 00:04 +0100, Mike Hearn wrote: > It's that time again! Fedora Core 4 no longer installs the > compat-libstdc++ package by default, meaning that any users who > install > or run a C++ app which was built using GCC 3.3 or lower is now greeted > with an incomprehensible and unhelpful error (or nothing, if they use > the > GUI). > > C++ is used by a lot of games and other commercial apps. As an ISV, our approach was to document this issue in our Knowledge Base and product documentation, to show relevant error messages at install time and to explain this behavior to our users. So far, nobody cried and all BitDefender users were able to install the proper compat-libstdc package, with or without our help. >From an ISV point of view, this is a minor issue. -- This message was scanned for spam and viruses by BitDefender. For more information please visit http://linux.bitdefender.com/ From nigel.metheringham at dev.intechnology.co.uk Mon Jun 27 09:26:10 2005 From: nigel.metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Mon, 27 Jun 2005 10:26:10 +0100 Subject: Yet again: several missing update announcements In-Reply-To: <20050621125734.GB11753@redhat.com> References: <6c18a4f050620100273fbb9ee@mail.gmail.com> <20050620211801.GP11753@redhat.com> <1119356297.3918.10.camel@localhost.localdomain> <20050621125734.GB11753@redhat.com> Message-ID: <1119864370.3695.11.camel@angua.localnet> On Tue, 2005-06-21 at 08:57 -0400, Daniel Veillard wrote: > Sure :-) My mail wasn't really a complaint, I just tried to explain > to the majority of the people outside of Red Hat and who don't deal with > our internal system what is happening, and why. The fact that step 4 > is asynchronous to me is nearly unavoidable since it requires PGP signing > of the packages and "some" centralized manual checking is needed. Is there no way that the announcement (stage 4) be written ahead of time - ie with the push into stage 3 - with replaceable blocks for the information that will change (MD5s and the like). An automatic process would then fill in the blanks. Nigel. From mike at plan99.net Mon Jun 27 11:11:24 2005 From: mike at plan99.net (Mike Hearn) Date: Mon, 27 Jun 2005 12:11:24 +0100 Subject: ISV approach on C++ compatibility (was Re: C++ compatibility package dropped) References: <1119844887.14936.16.camel@localhost.localdomain> Message-ID: On Mon, 27 Jun 2005 07:01:26 +0300, Mircea MITU wrote: > As an ISV, our approach was to document this issue in our Knowledge Base > and product documentation, to show relevant error messages at install time > and to explain this behavior to our users. So far, nobody cried and all > BitDefender users were able to install the proper compat-libstdc package, > with or without our help. BitDefenders userbase is probably more towards the technical side of the population. Judging from your download page, which provides gcc29x and gcc3x packages with no explanation they have to be if only to figure out which of the 6 downloads they need to get. That's a far cry from your average non-technical gamer/web surfer/IM user. thanks -mike From buildsys at redhat.com Mon Jun 27 11:12:12 2005 From: buildsys at redhat.com (Build System) Date: Mon, 27 Jun 2005 07:12:12 -0400 Subject: rawhide report: 20050627 changes Message-ID: <200506271112.j5RBCCGN023757@porkchop.devel.redhat.com> Updated Packages: selinux-policy-strict-1.23.18-20 -------------------------------- * Sun Jun 26 2005 Dan Walsh 1.23.18-20 - Fix hplip for cups * Sat Jun 25 2005 Dan Walsh 1.23.18-19 - Fix /opt * Sat Jun 25 2005 Dan Walsh 1.23.18-18 - Add passwd policy to targeted to maintain context on shadow file selinux-policy-targeted-1.23.18-20 ---------------------------------- * Sun Jun 26 2005 Dan Walsh 1.23.18-20 - Fix hplip for cups * Sat Jun 25 2005 Dan Walsh 1.23.18-19 - Fix /opt * Sat Jun 25 2005 Dan Walsh 1.23.18-18 - Add passwd policy to targeted to maintain context on shadow file Broken deps for s390x ---------------------------------------------------------- jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 wsdl4j - 1.5.1-1jpp_1fc.noarch requires java joram - 4.1.5-1jpp_2fc.noarch requires jmxri joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_2fc.noarch requires jta quota - 1:3.12-6.s390x requires kernel >= 0:2.4 lvm2 - 2.01.12-1.0.s390x requires kernel >= 0:2.6 jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2 initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6 xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging selinux-policy-strict - 1.23.18-20.noarch requires kernel >= 0:2.6.11-1.1219 hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10 arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0 hal - 0.5.2-2.s390x requires kernel >= 0:2.6.11 jessie - 1.0.0-8.noarch requires java >= 0:1.4 jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging dhcp - 10:3.0.2-14.s390x requires kernel >= 0:2.2.18 sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit) jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper selinux-policy-strict-sources - 1.23.18-20.noarch requires kernel >= 0:2.6.11-1.1219 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30 jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_3fc.noarch requires jasper5 jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 selinux-policy-targeted - 1.23.18-20.noarch requires kernel >= 0:2.6.11-1.1219 nfs-utils - 1.0.7-8.s390x requires kernel >= 0:2.2.14 jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging castor - 0.9.5-1jpp_1fc.noarch requires jta sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21 libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0 xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections libpcap - 14:0.8.3-14.s390x requires kernel >= 0:2.2.0 selinux-policy-targeted-sources - 1.23.18-20.noarch requires kernel >= 0:2.6.11-1.1219 axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 Broken deps for s390 ---------------------------------------------------------- quota - 1:3.12-6.s390 requires kernel >= 0:2.4 jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2 selinux-policy-targeted - 1.23.18-20.noarch requires kernel >= 0:2.6.11-1.1219 xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet dhcp - 10:3.0.2-14.s390 requires kernel >= 0:2.2.18 java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 selinux-policy-targeted-sources - 1.23.18-20.noarch requires kernel >= 0:2.6.11-1.1219 wsdl4j - 1.5.1-1jpp_1fc.noarch requires java gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2 prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10 sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21 jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 selinux-policy-strict - 1.23.18-20.noarch requires kernel >= 0:2.6.11-1.1219 jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11 joram - 4.1.5-1jpp_2fc.noarch requires jmxri joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_2fc.noarch requires jta castor - 0.9.5-1jpp_1fc.noarch requires jta velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0 jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 lvm2 - 2.01.12-1.0.s390 requires kernel >= 0:2.6 jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30 jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_3fc.noarch requires jasper5 nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14 avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 selinux-policy-strict-sources - 1.23.18-20.noarch requires kernel >= 0:2.6.11-1.1219 jessie - 1.0.0-8.noarch requires java >= 0:1.4 Broken deps for ppc64 ---------------------------------------------------------- joram - 4.1.5-1jpp_2fc.noarch requires jmxri joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_2fc.noarch requires jta jessie - 1.0.0-8.noarch requires java >= 0:1.4 vsftpd - 2.0.3-4.ppc64 requires pam_loginuid.so hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 system-config-mouse - 1.2.11-1.noarch requires pyxf86config rhpl - 0.167-1.ppc64 requires pyxf86config >= 0:0.3.2 jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 ppc64-utils - 0.7-9.ppc64 requires yaboot axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging system-config-display - 1.0.29-1.noarch requires /usr/X11R6/bin/Xorg system-config-display - 1.0.29-1.noarch requires pyxf86config >= 0:0.3.16 xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit) gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit) jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 castor - 0.9.5-1jpp_1fc.noarch requires jta castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 wsdl4j - 1.5.1-1jpp_1fc.noarch requires java system-config-keyboard - 1.2.6-2.noarch requires pyxf86config jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30 jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_3fc.noarch requires jasper5 velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet Broken deps for ia64 ---------------------------------------------------------- java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 magma-plugins - 1.0-0.pre16.11.ia64 requires libgulm.so.1.0()(64bit) jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30 jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_3fc.noarch requires jasper5 jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 vsftpd - 2.0.3-4.ia64 requires pam_loginuid.so jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 castor - 0.9.5-1jpp_1fc.noarch requires jta rgmanager - 1.9.31-3.ia64 requires ccs avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java joram - 4.1.5-1jpp_2fc.noarch requires jmxri joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_2fc.noarch requires jta wsdl4j - 1.5.1-1jpp_1fc.noarch requires java jessie - 1.0.0-8.noarch requires java >= 0:1.4 From mike at plan99.net Mon Jun 27 11:15:30 2005 From: mike at plan99.net (Mike Hearn) Date: Mon, 27 Jun 2005 12:15:30 +0100 Subject: C++ compatibility package dropped References: <1119823019.13523.18.camel@md.nc.linuxlobbyist.org> <604aa791050626164735ecd46@mail.gmail.com> Message-ID: On Sun, 26 Jun 2005 19:47:53 -0400, Jeff Spaleta wrote: > about we not make over-reaching claims about what other operating > systems do about backwards compatibility. If ALL application writers in > the universe were linking statically to libsdc++ like Apple demanded > before the release 10.3.9 would there be much to talk about in this > thread? Nope, probably not, and bundling private libstdc++.so versions is likely to be the route we'll take. That's a shame because it's 3mb of overhead most apps don't want, but if there's no other way then so be it. > Holding the downstream distributor responsible for the lack of stability > is a bit.. short-sighted. Well, the whole point of soname versioning and renaming the library when it changes its exported interface is so they can be parallel installed. I don't think it's too much to ask that it's installed by default which is definitely a downstream decision. thanks -mike From sundaram at redhat.com Mon Jun 27 11:24:47 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 27 Jun 2005 16:54:47 +0530 Subject: C++ compatibility package dropped In-Reply-To: References: <1119823019.13523.18.camel@md.nc.linuxlobbyist.org> <604aa791050626164735ecd46@mail.gmail.com> Message-ID: <42BFE1FF.1090205@redhat.com> Hi >Well, the whole point of soname versioning and renaming the library when >it changes its exported interface is so they can be parallel installed. I >don't think it's too much to ask that it's installed by default which is >definitely a downstream decision. > >thanks -mike > > > It doesnt have to be part of the base installation. Would it be possible to have the compatibility libraries within the legacy group selected by default. Users who do not require it can explicitly deselect it during the installation or do a yum groupremove easily. Others get more compatibility and external packages working better until a more automated message using dbus or something is designed to cover such cases better regards Rahul From lists at arctur.us Mon Jun 27 11:44:28 2005 From: lists at arctur.us (Mitch Skinner) Date: Mon, 27 Jun 2005 04:44:28 -0700 Subject: C++ compatibility package dropped In-Reply-To: References: <20050624231932.GR22349@devserv.devel.redhat.com> <1119673751.6953.3.camel@dimi> <20050625073759.GS22349@devserv.devel.redhat.com> <42BE8A69.3020403@design.chalmers.se> Message-ID: <1119872669.14017.8.camel@firebolt> On Sun, 2005-06-26 at 21:11 +0100, Mike Hearn wrote: > The problem is that: > > a) This requires every RPM to be in a yum repository. Usually if they > aren't in Extras, FreshRPMs, Dag or somesuch then they are just an RPM on > a download page. Then automatic dep resolution doesn't work. With system-install-packages apparently moving toward a yum backend (or with whatever yum GUI we end up with), it ought to be fairly straightforward to try and resolve deps from configured repositories even when installing non-repo RPMs. In the FC4 case, that would fix your issue a) above for compat-libstdc++-33, right? Mitch From paul at city-fan.org Mon Jun 27 12:03:53 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 27 Jun 2005 13:03:53 +0100 Subject: C++ compatibility package dropped In-Reply-To: <1119872669.14017.8.camel@firebolt> References: <20050624231932.GR22349@devserv.devel.redhat.com> <1119673751.6953.3.camel@dimi> <20050625073759.GS22349@devserv.devel.redhat.com> <42BE8A69.3020403@design.chalmers.se> <1119872669.14017.8.camel@firebolt> Message-ID: <42BFEB29.2010908@city-fan.org> Mitch Skinner wrote: > On Sun, 2005-06-26 at 21:11 +0100, Mike Hearn wrote: > >>The problem is that: >> >>a) This requires every RPM to be in a yum repository. Usually if they >> aren't in Extras, FreshRPMs, Dag or somesuch then they are just an RPM on >> a download page. Then automatic dep resolution doesn't work. > > > With system-install-packages apparently moving toward a yum backend (or > with whatever yum GUI we end up with), it ought to be fairly > straightforward to try and resolve deps from configured repositories > even when installing non-repo RPMs. In the FC4 case, that would fix > your issue a) above for compat-libstdc++-33, right? This can already be addressed in FC4 using: # yum localinstall some-package.rpm where yum will go off and get any required dependencies for the rpm to be installed. Pau. From pri.rhl4 at iadonisi.to Mon Jun 27 12:04:46 2005 From: pri.rhl4 at iadonisi.to (Paul Iadonisi) Date: Mon, 27 Jun 2005 08:04:46 -0400 Subject: C++ compatibility package dropped In-Reply-To: References: <1119823019.13523.18.camel@md.nc.linuxlobbyist.org> <604aa791050626164735ecd46@mail.gmail.com> Message-ID: <1119873886.32029.5.camel@md.nc.linuxlobbyist.org> On Mon, 2005-06-27 at 12:15 +0100, Mike Hearn wrote: [snip] > I > don't think it's too much to ask that it's installed by default which is > definitely a downstream decision. It is when you consider that it is making up for developers of what I would call 'problem' apps being unwilling to cooperate and provide that rather simple procedure of yumifying their ftp site with their rpms. As far as those who don't package their apps as rpms or take contributions from their community of users to create a package from their tarball...well, there we have a bigger problem. The only thing Fedora should do in those cases is encourage and instruct them in building rpms. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From omniuni at gmail.com Mon Jun 27 12:06:13 2005 From: omniuni at gmail.com (OmniUni) Date: Mon, 27 Jun 2005 08:06:13 -0400 Subject: TM Message-ID: <603d1b6805062705066196e81d@mail.gmail.com> I see the trademark difficulty. Perhaps "Lite Hat Linux" or something similar would work better? Either way, I feel that in order to assure such features as compatability, being up to date, and consistant quality, it is important that whatever the project be called, it be closely developed with fedora core. Though Cobind seems neat, and I will probably try it, the combination of Nautilus+XFCE makes me somewhat nervous. I have used gnome-panel with KDE, and Kicker with XFCE, but upon lauching nautilus while working on my FC-LT package selection, I ended with such a mess that it took no less than 20 minutes to sort out, and I promptly "rpm -e"'d nautilus. Also note: I attempted to run GNOME on my dad's p3, 128MB/RAM, computer last night. Kernel had to kill all processes to free up memory. KDE was slow, but at least the kernel didn't have to get involved. I'm afraid GNOME is definately not suited for lower end computers, at least not yet. Also, I like the idea of having other "brands" of "fedora" distros, but due to Trademarks, perhaps we should take the *** Hat Linux (Audio Hat Linux? GraphiHat Linux?) naming convention to show the connection w/o infringing upon trademarks. Just an idea. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan at redhat.com Mon Jun 27 12:20:32 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 27 Jun 2005 08:20:32 -0400 Subject: TM In-Reply-To: <603d1b6805062705066196e81d@mail.gmail.com> References: <603d1b6805062705066196e81d@mail.gmail.com> Message-ID: <20050627122032.GA30535@devserv.devel.redhat.com> On Mon, Jun 27, 2005 at 08:06:13AM -0400, OmniUni wrote: > called, it be closely developed with fedora core. Though Cobind seems neat, > and I will probably try it, the combination of Nautilus+XFCE makes me > somewhat nervous. I have used gnome-panel with KDE, and Kicker with XFCE, Nautilus + XFce works remarkably well and it gives you a desktop running entirely on the same library set. > to Trademarks, perhaps we should take the *** Hat Linux (Audio Hat Linux? Various other *** Hat's already exist and are other people's marks btw (eg Hard Hat) > GraphiHat Linux?) naming convention to show the connection w/o infringing > upon trademarks. Just an idea. Personally I'm in favour of Fedora Light/Lite providing its a "light" Fedora that has the same packages but different default set (ie its 100% compatible) and that there is a community around it not just one persons view From i.pilcher at comcast.net Mon Jun 27 13:27:35 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Mon, 27 Jun 2005 08:27:35 -0500 Subject: C++ compatibility package dropped In-Reply-To: <42BFE1FF.1090205@redhat.com> References: <1119823019.13523.18.camel@md.nc.linuxlobbyist.org> <604aa791050626164735ecd46@mail.gmail.com> <42BFE1FF.1090205@redhat.com> Message-ID: Rahul Sundaram wrote: > It doesnt have to be part of the base installation. Would it be possible > to have the compatibility libraries within the legacy group selected by > default. Users who do not require it can explicitly deselect it during > the installation or do a yum groupremove easily. Others get more > compatibility and external packages working better until a more > automated message using dbus or something is designed to cover such > cases better IIRC, the compatibility libraries are down in the "Development" section. Moving them to a more prominent (and accurate) location might be some- thing that everyone can agree on? Hope springs eternal. -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From jspaleta at gmail.com Mon Jun 27 13:42:37 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 27 Jun 2005 09:42:37 -0400 Subject: C++ compatibility package dropped In-Reply-To: References: <1119823019.13523.18.camel@md.nc.linuxlobbyist.org> <604aa791050626164735ecd46@mail.gmail.com> Message-ID: <604aa79105062706423d87533c@mail.gmail.com> On 6/27/05, Mike Hearn wrote: > Nope, probably not, and bundling private libstdc++.so versions is likely > to be the route we'll take. That's a shame because it's 3mb of overhead > most apps don't want, but if there's no other way then so be it. I find that argument about statically linking... satisifyingly ironic... considering part of you argument for installing it by default is that users don't really caring about a a few 3 mb compatibility packages on the system here or there. I think you should probably avoid arguments reference when 'most' 3rd party vendors or 'most' users want. I think 'most' of the people watching the conversation probably agree that neither of us is in a good position to know the desires of 'most' of either population. > Well, the whole point of soname versioning and renaming the library when > it changes its exported interface is so they can be parallel installed. I > don't think it's too much to ask that it's installed by default which is > definitely a downstream decision. We disagree. Some libraries are unstable, and I think software vendors should be responsible for doing their own due diligence about what to expect in terms of promised stability of the interface BEFORE they decide to link dynamically to a library. Since this whole 'platform' idea seems to be your cup of tea, perhaps you can make a summary list of which libraries have a commitment by the upstream project for ABI and API stability as a guide to 3rd party software vendors to use to make decisions about what to dynamically link against. -jef From dimi at lattica.com Mon Jun 27 13:44:04 2005 From: dimi at lattica.com (Dimi Paun) Date: Mon, 27 Jun 2005 09:44:04 -0400 Subject: C++ compatibility package dropped References: <1119823019.13523.18.camel@md.nc.linuxlobbyist.org><604aa791050626164735ecd46@mail.gmail.com> Message-ID: <01c101c57b1e$48b16db0$b6491b31@td612671> From: "Mike Hearn" > Nope, probably not, and bundling private libstdc++.so versions is likely > to be the route we'll take. That's a shame because it's 3mb of overhead > most apps don't want, but if there's no other way then so be it. Not to mention that this means the system will not be able to share the lib if more than one C++ app runs at the same time. So we're trading about 3MB of disk space (approx. $0.001) for 3MB * N of RAM (where N is the number of apps, which is > $0.12 even for N=1). Smart. And did I mention the time, effort, and _frustration_ of users to get the system running again? What if they didn't install via RPM? Screw them, they deserve what they get, no? (in which case they have a snowball's chance in hell of fixing the breakage without going through hell and back). -- Dimi Paun Lattica, Inc. From alan at redhat.com Mon Jun 27 13:48:18 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 27 Jun 2005 09:48:18 -0400 Subject: XFCE In-Reply-To: <1119831598.3061.8.camel@localhost> References: <603d1b68050626123571efc908@mail.gmail.com> <20050626194809.GA7455@ryoko.camperquake.de> <1119831598.3061.8.camel@localhost> Message-ID: <20050627134818.GB1706@devserv.devel.redhat.com> On Sun, Jun 26, 2005 at 08:19:57PM -0400, Toshio Kuratomi wrote: > Open questions: > - What infrastructure beyond the existing would these other respinnings > of Fedora need? None that I can think of. Disk space on mirrors would be the big one > - What communications with current FE and FC packagers? Do you need to alter dependencies or build alternative versions of packages, that would be the "hard" cases here I can think of. From dimi at lattica.com Mon Jun 27 13:48:41 2005 From: dimi at lattica.com (Dimi Paun) Date: Mon, 27 Jun 2005 09:48:41 -0400 Subject: C++ compatibility package dropped References: <20050624231932.GR22349@devserv.devel.redhat.com> <1119673751.6953.3.camel@dimi> <20050625073759.GS22349@devserv.devel.redhat.com> Message-ID: <01d801c57b1e$ed97c8b0$b6491b31@td612671> From: "Jakub Jelinek" > As long as the legacy programs people are installing are packaged > as rpm, yum or other package managers can handle the dependencies > just fine, so I don't see how is that a silent break. > If not using a package manager, you take the responsibility > of satisfying the dependencies yourself. That doesn't mean breaking things on purpose. Pissing off customers is not The Right Thing (TM), last time I've checked. Waiting a few more years before yanking system libs from under people's feet would be the more prudent thing to do. And it costs so little, it's not even funny that it's not being considered. -- Dimi Paun Lattica, Inc. From kmaraas at broadpark.no Mon Jun 27 15:10:52 2005 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Mon, 27 Jun 2005 17:10:52 +0200 Subject: Desktop memory consumption was: Re: TM In-Reply-To: <603d1b6805062705066196e81d@mail.gmail.com> References: <603d1b6805062705066196e81d@mail.gmail.com> Message-ID: <1119885056.2983.10.camel@localhost.localdomain> man, 27,.06.2005 kl. 08.06 -0400, skrev OmniUni: > I see the trademark difficulty. > > Perhaps "Lite Hat Linux" or something similar would work better? > Either way, I feel that in order to assure such features as > compatability, being up to date, and consistant quality, it is > important that whatever the project be called, it be closely developed > with fedora core. Though Cobind seems neat, and I will probably try > it, the combination of Nautilus+XFCE makes me somewhat nervous. I have > used gnome-panel with KDE, and Kicker with XFCE, but upon lauching > nautilus while working on my FC-LT package selection, I ended with > such a mess that it took no less than 20 minutes to sort out, and I > promptly "rpm -e"'d nautilus. > > Also note: I attempted to run GNOME on my dad's p3, 128MB/RAM, > computer last night. Kernel had to kill all processes to free up > memory. KDE was slow, but at least the kernel didn't have to get > involved. I'm afraid GNOME is definately not suited for lower end > computers, at least not yet. > Please be more specific with regards to what "attempted to run GNOME" really means. I'm writing this from Evolution with a 3 GB local mailstore and while not hugely pleasant it works at least. I've also got a terminal running and xchat along with the normal panel and nautilus. Applets: - cpu frequency monitor - battery monitor - gnome-dictionary - volume control - clock applet - Network Manager applet - tasklist - workspace switcher - notification area [kmaraas at localhost ~]$ free total used free shared buffers cached Mem: 125792 123460 2332 0 484 14304 -/+ buffers/cache: 108672 17120 Swap: 1048568 178912 869656 I guess I could easily free up some more memory if I went with a non-translucent panel and a fixed color background instead of this huge image I have there now. That and a slimmer evolution would make things absolutely workable IMO. All in all I was pleasantly surprised by this. I had expected much worse behaviour after reading your message ;-) Cheers Kjartan From alan at redhat.com Mon Jun 27 15:22:58 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 27 Jun 2005 11:22:58 -0400 Subject: Desktop memory consumption was: Re: TM In-Reply-To: <1119885056.2983.10.camel@localhost.localdomain> References: <603d1b6805062705066196e81d@mail.gmail.com> <1119885056.2983.10.camel@localhost.localdomain> Message-ID: <20050627152258.GB11006@devserv.devel.redhat.com> On Mon, Jun 27, 2005 at 05:10:52PM +0200, Kjartan Maraas wrote: > non-translucent panel and a fixed color background instead of this huge > image I have there now. That and a slimmer evolution would make things > absolutely workable IMO. Its called "sylpheed" ;) From kyrre at solution-forge.net Mon Jun 27 15:37:34 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Mon, 27 Jun 2005 17:37:34 +0200 Subject: TM In-Reply-To: <20050627122032.GA30535@devserv.devel.redhat.com> References: <603d1b6805062705066196e81d@mail.gmail.com> <20050627122032.GA30535@devserv.devel.redhat.com> Message-ID: <1119886654.31256.7.camel@localhost.localdomain> man, 27.06.2005 kl. 14.20 skrev Alan Cox: > On Mon, Jun 27, 2005 at 08:06:13AM -0400, OmniUni wrote: > > called, it be closely developed with fedora core. Though Cobind seems neat, > > and I will probably try it, the combination of Nautilus+XFCE makes me > > somewhat nervous. I have used gnome-panel with KDE, and Kicker with XFCE, > > Nautilus + XFce works remarkably well and it gives you a desktop running > entirely on the same library set. > > > to Trademarks, perhaps we should take the *** Hat Linux (Audio Hat Linux? > > Various other *** Hat's already exist and are other people's marks btw (eg > Hard Hat) > > > GraphiHat Linux?) naming convention to show the connection w/o infringing > > upon trademarks. Just an idea. > > Personally I'm in favour of Fedora Light/Lite providing its a "light" Fedora > that has the same packages but different default set (ie its 100% compatible) > and that there is a community around it not just one persons view Yes - Fedora LT migth probably be OK? Would be practical if it wasn just "fedora-like", but really *was* fedora - just a different install set with different CD's - or even better, for fc5, when there should exist extras CD's: A new choice in Anaconda as with "desktop" "workstation" "server" etc. Now: Any hints for freeing up some memory on a 128 MB laptop without sacryfising to much functionality? Getting rid of SElinux perhaps? From P at draigBrady.com Mon Jun 27 15:38:04 2005 From: P at draigBrady.com (P at draigBrady.com) Date: Mon, 27 Jun 2005 16:38:04 +0100 Subject: weird representation for FFFD In-Reply-To: <1119882800.5260.141.camel@localhost.localdomain> References: <42C00042.3010307@draigBrady.com> <1119882800.5260.141.camel@localhost.localdomain> Message-ID: <42C01D5C.6030107@draigBrady.com> Simos Xenitellis wrote: > ???? 27/????/2005, ????? ??????? ??? ??? 14:33, ?/? P at draigBrady.com > ??????: > >>On my fedora core 3 gnome desktop, >>I get a weird representation for U+FFFD. >>Here's what it looks like for you [?]. >> >>It's the "REPLACEMENT CHARACTER", and according >>to the following should be question mark enclosed >>in a solid diamond: http://www.unicode.org/charts/PDF/UFFF0.pdf >>I've been told that this is also the representation >>on windows and OSX. >> >>However I'm getting a weird comma like thing, which >>Markus Kuhn _has_ made reference to here I think: >>http://www.w3.org/2001/06/utf-8-wrong/UTF-8-test.html >>In the gnome charmap applet it seems to be the nimbus >>and schoolbook (sans and serif) fallback fonts that have >>this weird representation. The (Misc) Fixed fonts >>do have the question mark as expected. >> >>So why this weird representation? >>I'm writing an app where I would like to display >>characters that are invalid in the current encoding, >>and the comma like thing it totally confusing for users. > > > Hi, > On my system (FC2), gucharmap says it's FreeSans. > Doesn't FC3 have FreeSans/FreeSerif/FreeMono? Right so bitstream-vera doesn't even have the FFFD char, and the fallback nimbus has this weird comma like thing. I don't think freefont is part of fedora. I installed FreeSans manually and it has a beautiful question mark respresentation as described above. But that's not going to work for my app unless I install a font with it, but I really don't want to start that messing. > Ubuntu and other distributions come with "freefont" by default, covering > a good range of the Unicode space. > If FC4 does not install by default freefont, you should file a bug > report. Right, I'mm cc'ing fedora-devel as I've found no bugs mentioning dejavu or freefont etc. Extending bitstream was mentioned in this thread: http://www.redhat.com/archives/fedora-devel-list/2003-December/msg00830.html Perhaps making freefont the default might be a better approach? What do people think? -- P?draig Brady - http://www.pixelbeat.org -- From sundaram at redhat.com Mon Jun 27 15:40:56 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 27 Jun 2005 21:10:56 +0530 Subject: TM In-Reply-To: <1119886654.31256.7.camel@localhost.localdomain> References: <603d1b6805062705066196e81d@mail.gmail.com> <20050627122032.GA30535@devserv.devel.redhat.com> <1119886654.31256.7.camel@localhost.localdomain> Message-ID: <42C01E08.7080008@redhat.com> Hi >Now: Any hints for freeing up some memory on a 128 MB laptop without >sacryfising to much functionality? Getting rid of SElinux perhaps? > > > How would getting rid of SElinux free up sufficient memory to enable Fedora to run on a 128 MB system.?. you are better off running something like Rule Project instead or work on optimising the system where it really counts regards Rahul From mattdm at mattdm.org Mon Jun 27 15:59:41 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 27 Jun 2005 11:59:41 -0400 Subject: TM In-Reply-To: <1119886654.31256.7.camel@localhost.localdomain> References: <603d1b6805062705066196e81d@mail.gmail.com> <20050627122032.GA30535@devserv.devel.redhat.com> <1119886654.31256.7.camel@localhost.localdomain> Message-ID: <20050627155940.GA19247@jadzia.bu.edu> On Mon, Jun 27, 2005 at 05:37:34PM +0200, Kyrre Ness Sjobak wrote: > Yes - Fedora LT migth probably be OK? Would be practical if it wasn just > "fedora-like", but really *was* fedora - just a different install set with > different CD's - or even better, for fc5, when there should exist extras > CD's: A new choice in Anaconda as with "desktop" "workstation" "server" > etc. I think this is really the way to go. It's easy to add install classes to Anaconda, and I think a lot of people would appreciate seeing a "lite" choice there. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 87 degrees Fahrenheit. From jkeating at j2solutions.net Mon Jun 27 16:31:55 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 27 Jun 2005 09:31:55 -0700 Subject: Desktop memory consumption was: Re: TM In-Reply-To: <20050627152258.GB11006@devserv.devel.redhat.com> References: <603d1b6805062705066196e81d@mail.gmail.com> <1119885056.2983.10.camel@localhost.localdomain> <20050627152258.GB11006@devserv.devel.redhat.com> Message-ID: <1119889915.29523.2.camel@localhost.localdomain> On Mon, 2005-06-27 at 11:22 -0400, Alan Cox wrote: > Its called "sylpheed" ;) Is sylpheed gtk2 yet? I stopped using it a few releases ago because it was really crashy and really slow on my imap system where I regularly have 5~10K messages in a folder. -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- 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 Mon Jun 27 16:37:15 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 27 Jun 2005 18:37:15 +0200 Subject: Desktop memory consumption was: Re: TM In-Reply-To: <1119889915.29523.2.camel@localhost.localdomain> References: <603d1b6805062705066196e81d@mail.gmail.com> <1119885056.2983.10.camel@localhost.localdomain> <20050627152258.GB11006@devserv.devel.redhat.com> <1119889915.29523.2.camel@localhost.localdomain> Message-ID: <20050627183715.275ff544@nausicaa.camperquake.de> Hi. Jesse Keating wrote: > Is sylpheed gtk2 yet? claws at least is. > I stopped using it a few releases ago because it > was really crashy and really slow on my imap system where I regularly > have 5~10K messages in a folder. IMAP still sucks, IMHO. Especially as there is no way to disable local caching. -- "Hey Beavis, this fridge here, like, it's really cool.. huh-huhh huh.." "Yeah Butt-head.. this vacuum cleaner sucks.. heh-heh hehh heh-heh.." From alan at redhat.com Mon Jun 27 16:56:05 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 27 Jun 2005 12:56:05 -0400 Subject: TM In-Reply-To: <42C01E08.7080008@redhat.com> References: <603d1b6805062705066196e81d@mail.gmail.com> <20050627122032.GA30535@devserv.devel.redhat.com> <1119886654.31256.7.camel@localhost.localdomain> <42C01E08.7080008@redhat.com> Message-ID: <20050627165605.GA7764@devserv.devel.redhat.com> On Mon, Jun 27, 2005 at 09:10:56PM +0530, Rahul Sundaram wrote: > How would getting rid of SElinux free up sufficient memory to enable > Fedora to run on a 128 MB system.?. you are better off running something > like Rule Project instead or work on optimising the system where it > really counts SELinux does use a measurable amount of memory. The things I tend to do on a small box are: run xfce run sylpheed avoid any Qt apps (just to avoid both library sets being in memory) It is mostly about application choices. Big desktop backgrounds do also have a small impact especially with modern 32bit 1600x1200 displays. From hughsient at gmail.com Mon Jun 27 17:15:39 2005 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 27 Jun 2005 18:15:39 +0100 Subject: gnome-pilot patches need applying Message-ID: <1119892539.3377.7.camel@localhost.localdomain> Hi, Hope this is the right list for this problem. For FC4, there are loads of people trying to get their Palm PDA's syncing with the shipped gnome-pilot, but with no success. I've spent about 4 hours researching the problem, and agree with Mark Adams, unpatched, the Fedora "version" of gnome-pilot will not work for udev-created /dev/ttyUSBx based connections due to many problems: Please see: http://bugzilla.gnome.org/show_bug.cgi?id=274032#c24 and: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=116025 It would be a shame to have a FC3 vmware image just to sync my Palm! Can we spin a new rawhide version with the patches applied? Thanks, Richard Hughes -------------- 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 Mon Jun 27 17:18:01 2005 From: dmalcolm at redhat.com (David Malcolm) Date: Mon, 27 Jun 2005 13:18:01 -0400 Subject: gnome-pilot patches need applying In-Reply-To: <1119892539.3377.7.camel@localhost.localdomain> References: <1119892539.3377.7.camel@localhost.localdomain> Message-ID: <1119892681.3030.77.camel@cassandra.boston.redhat.com> On Mon, 2005-06-27 at 18:15 +0100, Richard Hughes wrote: > Hi, Hope this is the right list for this problem. > > For FC4, there are loads of people trying to get their Palm PDA's > syncing with the shipped gnome-pilot, but with no success. > > I've spent about 4 hours researching the problem, and agree with Mark > Adams, unpatched, the Fedora "version" of gnome-pilot will not work for > udev-created /dev/ttyUSBx based connections due to many problems: > > Please see: > http://bugzilla.gnome.org/show_bug.cgi?id=274032#c24 > and: > https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=116025 > > It would be a shame to have a FC3 vmware image just to sync my Palm! > > Can we spin a new rawhide version with the patches applied? I'm on it. From hughsient at gmail.com Mon Jun 27 17:21:58 2005 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 27 Jun 2005 18:21:58 +0100 Subject: gnome-pilot patches need applying In-Reply-To: <1119892681.3030.77.camel@cassandra.boston.redhat.com> References: <1119892539.3377.7.camel@localhost.localdomain> <1119892681.3030.77.camel@cassandra.boston.redhat.com> Message-ID: <1119892918.4185.0.camel@localhost.localdomain> On Mon, 2005-06-27 at 13:18 -0400, David Malcolm wrote: > > Can we spin a new rawhide version with the patches applied? > > I'm on it. Wow, what a response! Thanks. -------------- 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 wir-sind-cool.org Mon Jun 27 18:12:46 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 27 Jun 2005 20:12:46 +0200 Subject: Desktop memory consumption was: Re: TM In-Reply-To: <20050627183715.275ff544@nausicaa.camperquake.de> References: <603d1b6805062705066196e81d@mail.gmail.com> <1119885056.2983.10.camel@localhost.localdomain> <20050627152258.GB11006@devserv.devel.redhat.com> <1119889915.29523.2.camel@localhost.localdomain> <20050627183715.275ff544@nausicaa.camperquake.de> Message-ID: <20050627201246.67abc3cf.fedora@wir-sind-cool.org> On Mon, 27 Jun 2005 18:37:15 +0200, Ralf Ertzinger wrote: > > > Is sylpheed gtk2 yet? > > claws at least is. Sylpheed is, too, see Fedora Extras Development. -- Michael Schwendt Fedora Core release 4 (Stentz) - Linux 2.6.11-1.1369_FC4 loadavg: 1.05 1.13 0.71 From ph18 at cornell.edu Mon Jun 27 19:58:00 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Mon, 27 Jun 2005 15:58:00 -0400 Subject: iSCSI stack in Fedora? Message-ID: <42C05A48.6090203@cornell.edu> Are any plans to ship an iSCSI stack in Fedora Core? I'm trying to set up an iSCSI server on my home network for several reasons: the plan is to create a GFS filesystem, but have the machine mount it locally so that lesser computers can access it via NFS. I'd be happy to make rpms for the necessary software. From jkeating at j2solutions.net Mon Jun 27 20:08:04 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 27 Jun 2005 13:08:04 -0700 Subject: iSCSI stack in Fedora? In-Reply-To: <42C05A48.6090203@cornell.edu> References: <42C05A48.6090203@cornell.edu> Message-ID: <1119902884.29523.17.camel@localhost.localdomain> On Mon, 2005-06-27 at 15:58 -0400, Paul A Houle wrote: > > Are any plans to ship an iSCSI stack in Fedora Core? > > I'm trying to set up an iSCSI server on my home network for > several > reasons: the plan is to create a GFS filesystem, but have the > machine > mount it locally so that lesser computers can access it via NFS. > > I'd be happy to make rpms for the necessary software. iSCSI stack would have to be in upstream kernel. -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating -------------- 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 marco_meyerhofer at freesurf.ch Mon Jun 27 20:08:21 2005 From: marco_meyerhofer at freesurf.ch (Marco Meyerhofer) Date: Mon, 27 Jun 2005 22:08:21 +0200 Subject: Desktop search tool using lucene In-Reply-To: <200506262052.j5QKq4w4029659@laptop11.inf.utfsm.cl> References: <200506262052.j5QKq4w4029659@laptop11.inf.utfsm.cl> Message-ID: <1119902901.4981.6.camel@rechner1.localdomain> > Congratulations! You've just found your very own open source project to > work on. I can't program, but I could do testing, write documentation and translate to german. I will look what Mr. Tromey does and try to help there. From jdesbonnet at gmail.com Tue Jun 28 00:10:24 2005 From: jdesbonnet at gmail.com (Joe Desbonnet) Date: Tue, 28 Jun 2005 01:10:24 +0100 Subject: Desktop search tool using lucene In-Reply-To: <604aa791050626135236068e1a@mail.gmail.com> References: <1119816843.5057.26.camel@rechner1.localdomain> <604aa791050626135236068e1a@mail.gmail.com> Message-ID: <1cef3e95050627171076a5ce63@mail.gmail.com> Seems to me the reason why gcj is a problem is the UI and not the underlying engine. It amazes me how much effort is wasted in producing substandard UIs to otherwise excellent software. I'm biased because of what I'm used to (and not used to), but IMHO developing web based UIs is much, much easier than the same thing in C++ or Swing. Traditionally web based UIs were limited, but nowadays most of the limitations have been removed thanks to CSS styling and 'AJAX' techniques (example: gmail). How about writing this software as a process serving HTTP requests to a local web browser? Joe. On 6/26/05, Jeff Spaleta wrote: > On 6/26/05, Marco Meyerhofer wrote: > > It would be great to see a desktop search tool in Fedora. > You might want to touch base with Mr. Tromey about this issue who has > commented on this in his blog: > http://www.peakpeak.com/~tromey/blog/2005/06/22#regain > > -jef" as seen on http://fedora.linux.duke.edu/fedorapeople/ "spaleta > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From mikem at cyber.com.au Mon Jun 27 05:58:29 2005 From: mikem at cyber.com.au (Mike MacCana) Date: Mon, 27 Jun 2005 15:58:29 +1000 Subject: Desktop search tool using lucene In-Reply-To: <200506262052.j5QKq4w4029659@laptop11.inf.utfsm.cl> References: <200506262052.j5QKq4w4029659@laptop11.inf.utfsm.cl> Message-ID: <1119851909.2949.1.camel@localhost.localdomain> On Sun, 2005-06-26 at 16:52 -0400, Horst von Brand wrote: > Marco Meyerhofer wrote: > > Today desktop search tools are killer-apps, the hype about Beagle or > > Spotlight is really big. I think that Fedora needs a search tool to be > > competitive. They (meaning engineers at redhat) are discussing this. The solution won't use Lucene, as Lucene treats all fine content as equal - ie, it doesn't know about headings being different from body text and so on. Mike From nigel.metheringham at dev.intechnology.co.uk Tue Jun 28 08:27:01 2005 From: nigel.metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Tue, 28 Jun 2005 09:27:01 +0100 Subject: gnome-pilot patches need applying In-Reply-To: <1119892918.4185.0.camel@localhost.localdomain> References: <1119892539.3377.7.camel@localhost.localdomain> <1119892681.3030.77.camel@cassandra.boston.redhat.com> <1119892918.4185.0.camel@localhost.localdomain> Message-ID: <1119947221.3720.2.camel@angua.localnet> Palm support seems to be especially cursed in FC4. There are some really low level problems - something that appears to be kernel/udev/hotplug (or quite likely a timing related bug in that set) that prevents even the command line pilot-xfer tools working in many cases (which completely destroys the possibility of gnome-pilot working). Then gnome-pilot has a batch of bugs including timing related on ttyUSB, broken API wrt to pilot-link (which it links to), broken conduits and broken evolution integration. Someone really really doesn't like this stuff :-/ Nigel. From dragoran at feuerpokemon.de Tue Jun 28 08:43:32 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 28 Jun 2005 10:43:32 +0200 Subject: strange hal problem Message-ID: <42C10DB4.5020008@feuerpokemon.de> Hello. I am running FC4 final and: hal-0.5.2-2 udev-058-1 hotplug-2004_09_23-7 kernel-2.6.11-1.1369_FC4 dbus-0.33-3 nautilus and the gtkfileselector shows: d> ;" as label for the volume (fat32) on my second harddisk (hdb) everything else works fine. bugzilla entry: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161781 If someone has any hint how to fix this or at least can explain what might be causing this .. please reply. thx From alexl at users.sourceforge.net Tue Jun 28 10:14:36 2005 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Tue, 28 Jun 2005 03:14:36 -0700 Subject: gnome-pilot patches need applying In-Reply-To: <1119947221.3720.2.camel@angua.localnet> (Nigel Metheringham's message of "Tue, 28 Jun 2005 09:27:01 +0100") References: <1119892539.3377.7.camel@localhost.localdomain> <1119892681.3030.77.camel@cassandra.boston.redhat.com> <1119892918.4185.0.camel@localhost.localdomain> <1119947221.3720.2.camel@angua.localnet> Message-ID: >>>>> "NM" == Nigel Metheringham writes: NM> Palm support seems to be especially cursed in FC4. There are some NM> really low level problems - something that appears to be NM> kernel/udev/hotplug (or quite likely a timing related bug in that NM> set) that prevents even the command line pilot-xfer tools working NM> in many cases (which completely destroys the possibility of NM> gnome-pilot working). NM> Then gnome-pilot has a batch of bugs including timing related on NM> ttyUSB, broken API wrt to pilot-link (which it links to), broken NM> conduits and broken evolution integration. NM> Someone really really doesn't like this stuff :-/ I downgraded to using pilot-link-0.11.8 on FC4 for this reason (I don't even try gnome-pilot let alone evolution integration), and seems to be working OK. I'll file some bugs on bugzilla.redhat.com on the current pilot-link-0.12.0-0.pre3.0.fc4.1 included in FC4 when I get time. Interestingly, the pilot-link maintainer, David Desrosiers, has specifically admonished distributions not to include any of pilot-link 0.12 pre-test versions and wait until the official 0.12.0 release: See the first announcement of pilot-link-0.12-pre1: http://www.pilot-link.org/node/129 and a recent posting here: http://mail.gnome.org/archives/gnome-pilot-list/2005-June/msg00011.html I know Fedora is supposed to be bleeding edge, but is it wise to include a version in the distro that it's maintainer specifically suggests not to? I'm curious to know the reasoning behind including this version in FC4. Alex From nigel.metheringham at dev.intechnology.co.uk Tue Jun 28 10:27:12 2005 From: nigel.metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Tue, 28 Jun 2005 11:27:12 +0100 Subject: gnome-pilot patches need applying In-Reply-To: References: <1119892539.3377.7.camel@localhost.localdomain> <1119892681.3030.77.camel@cassandra.boston.redhat.com> <1119892918.4185.0.camel@localhost.localdomain> <1119947221.3720.2.camel@angua.localnet> Message-ID: <1119954432.6235.10.camel@angua.localnet> On Tue, 2005-06-28 at 03:14 -0700, Alex Lancaster wrote: > I downgraded to using pilot-link-0.11.8 on FC4 for this reason (I > don't even try gnome-pilot let alone evolution integration), and seems > to be working OK. I'll file some bugs on bugzilla.redhat.com on the > current pilot-link-0.12.0-0.pre3.0.fc4.1 included in FC4 when I get > time. Actualy that doesn't work for me either - see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161058 It basically looks like being a problem down to the udev/hotplug mechanism taking so long to get around to build the devices (on a 2 year old laptop with reasonable memory load) that the palm has got bored and stopped sending initiation messages by the time you can connect to the new devices. By putting a static device in place I can make this stuff work reliably. Not tried venturing near gnome-pilot yet - I know that stuff is broken. Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From alexl at users.sourceforge.net Tue Jun 28 10:55:43 2005 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Tue, 28 Jun 2005 03:55:43 -0700 Subject: gnome-pilot patches need applying In-Reply-To: <1119954432.6235.10.camel@angua.localnet> (Nigel Metheringham's message of "Tue, 28 Jun 2005 11:27:12 +0100") References: <1119892539.3377.7.camel@localhost.localdomain> <1119892681.3030.77.camel@cassandra.boston.redhat.com> <1119892918.4185.0.camel@localhost.localdomain> <1119947221.3720.2.camel@angua.localnet> <1119954432.6235.10.camel@angua.localnet> Message-ID: >>>>> "NM" == Nigel Metheringham writes: [...] NM> Actualy that doesn't work for me either - see NM> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161058 NM> It basically looks like being a problem down to the udev/hotplug NM> mechanism taking so long to get around to build the devices (on a NM> 2 year old laptop with reasonable memory load) that the palm has NM> got bored and stopped sending initiation messages by the time you NM> can connect to the new devices. NM> By putting a static device in place I can make this stuff work NM> reliably. Not tried venturing near gnome-pilot yet - I know that NM> stuff is broken. Interesting, I notice the greater latency you mention on FC4 compared with FC3, but for some reason the older pilot-link is more tolerant of the increased delay. I am using a locally built-from-SRPM on FC4 version of pilot-link-0.11.8-3 which has a patch to enable the Perl bindings (which I need for SyncBBDB). Have you tried rebuilding the earlier binaries from the last FC3 SRPM on your new FC4 installation and using them? If this gets too off-topic, I'll followup on the Bugzilla entry. Alex From nigel.metheringham at dev.intechnology.co.uk Tue Jun 28 11:09:21 2005 From: nigel.metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Tue, 28 Jun 2005 12:09:21 +0100 Subject: gnome-pilot patches need applying In-Reply-To: References: <1119892539.3377.7.camel@localhost.localdomain> <1119892681.3030.77.camel@cassandra.boston.redhat.com> <1119892918.4185.0.camel@localhost.localdomain> <1119947221.3720.2.camel@angua.localnet> <1119954432.6235.10.camel@angua.localnet> Message-ID: <1119956961.6235.21.camel@angua.localnet> On Tue, 2005-06-28 at 03:55 -0700, Alex Lancaster wrote: > Interesting, I notice the greater latency you mention on FC4 compared > with FC3, but for some reason the older pilot-link is more tolerant of > the increased delay. I am using a locally built-from-SRPM on FC4 > version of pilot-link-0.11.8-3 which has a patch to enable the Perl > bindings (which I need for SyncBBDB). Have you tried rebuilding the > earlier binaries from the last FC3 SRPM on your new FC4 installation > and using them? Yes. Also using the FC3 binary rpm directly, and using a static linked FC3 pilot-xfer. There is a narrow window which I can hit now I know I am aiming for getting to /dev/ttyUSB1 as early as possible with any of those. I have only been attempting to get it working at all so just using the list function - rather than seriously using pilot-xfer to do work. Personally I think that we should just drop everything back down to a 0.11.x pilot-tools release and use a tool chain which basically works throughout - although it will be painful to release a down-reved update due to packaging side effects. Maybe I should open a bug against udev/hotplug to see why things are so damn slow now. Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From buildsys at redhat.com Tue Jun 28 11:15:46 2005 From: buildsys at redhat.com (Build System) Date: Tue, 28 Jun 2005 07:15:46 -0400 Subject: rawhide report: 20050628 changes Message-ID: <200506281115.j5SBFkAf020187@porkchop.devel.redhat.com> New package lucene High-performance, full-featured text search engine Updated Packages: OpenIPMI-1.4.14-1 ----------------- * Mon Jun 27 2005 Phil Knirsch 1.4.14-2 - Updated to OpenIPMI-1.4.14 - Split the main package into normal and libs package for multilib support - Added impitool-1.8.2 to OpenIPMI and put it in tools package - Added sysconf and initscript (#158270) - Fixed oob subscripts (#149142) cairo-0.5.1-4 ------------- * Sun Jun 26 2005 Kristian H??gsberg - 0.5.1-4 - Add more missing devel package requires (libpng-devel and xorg-x11-devel) (#161688) - Add Owens patch (cairo-0.5.1-bitmap-fonts.patch) to make bitmap fonts work with cairo (#161653). carol-0:1.8.9.3-1jpp_2fc ------------------------ * Mon Jun 27 2005 Gary Benson 0:1.8.9.3-1jpp_2fc - BC-compile the combined jarfile. evolution-2.2.2-9.fc5 --------------------- * Mon Jun 27 2005 David Malcolm - 2.2.2-9.fc5 - Replaced patch to port conduits to pilot-link-0.12 with Mark G Adams's version of same (#161817) - Added Mark G Adams's memory leak fix (patch 801) evolution-data-server-1.2.2-4.fc5 --------------------------------- * Mon Jun 27 2005 David Malcolm - 1.2.2-4.fc5 - Added leak fixes for GNOME bug 309079 provided by Mark G. Adams fedora-release-4-rawhide ------------------------ geronimo-specs-0:1.0-0.M2.2jpp_2fc ---------------------------------- * Mon Jun 27 2005 Gary Benson 0:1.0-0.M2.2jpp_2fc - BC-compile. gnome-panel-2.10.1-11 --------------------- * Mon Jun 27 2005 Mark McLoughlin 2.10.1-11 - Fix "panel doesn't notice new screen size" issue (bug #160439) gnome-pilot-2.0.13-4.fc5 ------------------------ * Mon Jun 27 2005 David Malcolm - 2.0.13-4.fc5 - Introduce pilot-link-version macro; use to bump version to 1:0.12.0-0.pre2.0 - Update gnome-pilot-2.0.12-port-to-pilot-link-0.12.patch to use version by Mark G Adams (#161824; patch 11) In addition to the correct port to 0.12, this contains three patches in GNOME bugzilla bug 274032 (error handling, not closing socket on connection, fixed DB reading loop) - Renabled backup conduit (was patch 12), applying two patches by Mark G Adams (#161799; patch 18 and patch 19) - Applied patch by Mark G Adams to fix some issues identified using valgrind in the backup conduit (gnome bug 209130, patch 17) - Applied patch by Mark G Adams to fix some cleanup of XML handling (gnome bug 309077, patch 16) - Patched to fix a missing #include (patch 20) - Remove test conduit grep-2.5.1-49 ------------- * Mon Jun 27 2005 Tim Waugh 2.5.1-49 - Fix 'grep -Fw' for encodings other than UTF-8 (bug #161700). * Wed Apr 13 2005 Tim Waugh - Build requires recent pcre-devel (bug #154626). jacorb-0:2.2-3jpp_2fc --------------------- * Mon Jun 27 2005 Gary Benson 0:2.2-3jpp_1fc - BC-compile the main jarfile. jonathan-rmi-3.1-3 ------------------ * Mon Jun 27 2005 Gary Benson 3.1-3 - BC-compile. kdebase-6:3.4.1-2 ----------------- * Mon Jun 27 2005 Than Ngo 3.4.1-2 - fix gcc4 build problem * Mon Jun 06 2005 Than Ngo 3.4.1-1 - 3.4.1 - update pam configuration for the new audit system #159333 * Tue May 03 2005 Than Ngo 6:3.4.0-7 - fix broken kde-essential.menu lam-2:7.1.1-5 ------------- * Mon Jun 27 2005 Tom "spot" Callaway - 2:7.1.1-5 - enable shared libraries - don't list /usr/share/* in files * Sun May 22 2005 Jeremy Katz - 2:7.1.1-4 - use -fPIC on x86_64 (reported by spot to get things building for Extras) mx4j-1:3.0.1-1jpp_3fc --------------------- * Mon Jun 27 2005 Gary Benson 0:3.0.1-1jpp_3fc - Also BC-compile the combined remote jarfile. netpbm-10.28-3 -------------- * Mon Jun 27 2005 Jindrich Novy 10.28-3 - create symlink pnmtopnm -> pamtopnm, this works now in netpbm-10.28 (#161436) oldkilim-0:1.1.3-2jpp_2fc ------------------------- * Mon Jun 27 2005 Gary Benson 0:1.1.3-2jpp_2fc - BC-compile the main jarfile. qt-1:3.3.4-16 ------------- * Mon Jun 27 2005 Than Ngo 1:3.3.4-15 - apply patch to fix Rendering for Punjabii, thanks to Trolltech #156504 quagga-0:0.98.4-2 ----------------- * Mon Jun 27 2005 Jay Fenlason 0.98.4-2 - New upstream version. tn5250-0.16.5-6 --------------- * Mon Jun 27 2005 Karsten Hopp 0.16.5-6 - add buildrequires ncurses-devel (#160985) vnc-4.1.1-12 ------------ * Mon Jun 27 2005 Tim Waugh 4.1.1-12 - Fixed vncpasswd crash (bug #160471). * Wed Jun 22 2005 Tim Waugh - Updated URL in vncservers file (bug #161334). vsftpd-2.0.3-5 -------------- * Mon Jun 27 2005 Radek Vokal 2.0.3-5 - fixed requires for 64bit libs zsh-4.2.5-1 ----------- * Mon Mar 14 2005 Colin Walters - 4.2.5-1 - New upstream version - Fix Doc html includes; looks like texinfo changed incompatibly * Mon Mar 14 2005 Colin Walters - 4.2.1-3 - Rebuild for GCC4 Broken deps for ia64 ---------------------------------------------------------- xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30 jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_3fc.noarch requires jasper5 jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet wsdl4j - 1.5.1-1jpp_1fc.noarch requires java java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 joram - 4.1.5-1jpp_2fc.noarch requires jmxri joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_2fc.noarch requires jta jessie - 1.0.0-8.noarch requires java >= 0:1.4 jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging rgmanager - 1.9.31-3.ia64 requires ccs castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 magma-plugins - 1.0-0.pre16.11.ia64 requires libgulm.so.1.0()(64bit) jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 castor - 0.9.5-1jpp_1fc.noarch requires jta Broken deps for s390 ---------------------------------------------------------- libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0 sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21 selinux-policy-strict - 1.23.18-20.noarch requires kernel >= 0:2.6.11-1.1219 selinux-policy-targeted-sources - 1.23.18-20.noarch requires kernel >= 0:2.6.11-1.1219 dhcp - 10:3.0.2-14.s390 requires kernel >= 0:2.2.18 jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 selinux-policy-strict-sources - 1.23.18-20.noarch requires kernel >= 0:2.6.11-1.1219 jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 jessie - 1.0.0-8.noarch requires java >= 0:1.4 sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2 wsdl4j - 1.5.1-1jpp_1fc.noarch requires java nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14 xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0 hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11 xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2 velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections lvm2 - 2.01.12-1.0.s390 requires kernel >= 0:2.6 castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10 avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30 jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_3fc.noarch requires jasper5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj joram - 4.1.5-1jpp_2fc.noarch requires jmxri joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_2fc.noarch requires jta initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6 quota - 1:3.12-6.s390 requires kernel >= 0:2.4 axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java castor - 0.9.5-1jpp_1fc.noarch requires jta jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 selinux-policy-targeted - 1.23.18-20.noarch requires kernel >= 0:2.6.11-1.1219 Broken deps for ppc64 ---------------------------------------------------------- java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet system-config-display - 1.0.29-1.noarch requires /usr/X11R6/bin/Xorg system-config-display - 1.0.29-1.noarch requires pyxf86config >= 0:0.3.16 gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit) gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit) jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 rhpl - 0.167-1.ppc64 requires pyxf86config >= 0:0.3.2 jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging wsdl4j - 1.5.1-1jpp_1fc.noarch requires java jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 joram - 4.1.5-1jpp_2fc.noarch requires jmxri joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_2fc.noarch requires jta jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging castor - 0.9.5-1jpp_1fc.noarch requires jta jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30 jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_3fc.noarch requires jasper5 jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper system-config-mouse - 1.2.11-1.noarch requires pyxf86config hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet ppc64-utils - 0.7-9.ppc64 requires yaboot jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging jessie - 1.0.0-8.noarch requires java >= 0:1.4 system-config-keyboard - 1.2.6-2.noarch requires pyxf86config xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 Broken deps for s390x ---------------------------------------------------------- xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10 dhcp - 10:3.0.2-14.s390x requires kernel >= 0:2.2.18 velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections nfs-utils - 1.0.7-8.s390x requires kernel >= 0:2.2.14 java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21 jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 joram - 4.1.5-1jpp_2fc.noarch requires jmxri joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_2fc.noarch requires jta quota - 1:3.12-6.s390x requires kernel >= 0:2.4 jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11 sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit) jessie - 1.0.0-8.noarch requires java >= 0:1.4 jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 hal - 0.5.2-2.s390x requires kernel >= 0:2.6.11 gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2 libpcap - 14:0.8.3-14.s390x requires kernel >= 0:2.2.0 avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 castor - 0.9.5-1jpp_1fc.noarch requires jta lvm2 - 2.01.12-1.0.s390x requires kernel >= 0:2.6 libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0 jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 wsdl4j - 1.5.1-1jpp_1fc.noarch requires java hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 selinux-policy-targeted-sources - 1.23.18-20.noarch requires kernel >= 0:2.6.11-1.1219 jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6 axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 selinux-policy-targeted - 1.23.18-20.noarch requires kernel >= 0:2.6.11-1.1219 arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0 xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging selinux-policy-strict - 1.23.18-20.noarch requires kernel >= 0:2.6.11-1.1219 selinux-policy-strict-sources - 1.23.18-20.noarch requires kernel >= 0:2.6.11-1.1219 jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30 jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_3fc.noarch requires jasper5 From alexl at users.sourceforge.net Tue Jun 28 11:22:15 2005 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Tue, 28 Jun 2005 04:22:15 -0700 Subject: gnome-pilot patches need applying In-Reply-To: <1119956961.6235.21.camel@angua.localnet> (Nigel Metheringham's message of "Tue, 28 Jun 2005 12:09:21 +0100") References: <1119892539.3377.7.camel@localhost.localdomain> <1119892681.3030.77.camel@cassandra.boston.redhat.com> <1119892918.4185.0.camel@localhost.localdomain> <1119947221.3720.2.camel@angua.localnet> <1119954432.6235.10.camel@angua.localnet> <1119956961.6235.21.camel@angua.localnet> Message-ID: >>>>> "NM" == Nigel Metheringham writes: NM> On Tue, 2005-06-28 at 03:55 -0700, Alex Lancaster wrote: >> Interesting, I notice the greater latency you mention on FC4 >> compared with FC3, but for some reason the older pilot-link is more >> tolerant of the increased delay. I am using a locally >> built-from-SRPM on FC4 version of pilot-link-0.11.8-3 which has a >> patch to enable the Perl bindings (which I need for SyncBBDB). >> Have you tried rebuilding the earlier binaries from the last FC3 >> SRPM on your new FC4 installation and using them? NM> Yes. Also using the FC3 binary rpm directly, and using a static NM> linked FC3 pilot-xfer. NM> There is a narrow window which I can hit now I know I am aiming NM> for getting to /dev/ttyUSB1 as early as possible with any of NM> those. [...] Yes, I have the same problem, this little bash script wrapper ~/bin/pilot-link does the trick (most of the time) without having to manually hit the HotSync button in the exact window: #!/bin/sh echo "Waiting for hotsync button" until [ -e /dev/pilot ]; do sleep 1; done exec /usr/bin/pilot-xfer "$@" I use the udev facility for creating the symlink to /dev/pilot in /etc/udev/rules.d/ (Last post on this issue, I'll followup on http://bugzilla.redhat.com/161058) Alex From harald at redhat.com Tue Jun 28 12:55:55 2005 From: harald at redhat.com (Harald Hoyer) Date: Tue, 28 Jun 2005 14:55:55 +0200 Subject: Fedora Goals -- LSB-compliant/ideal init for FC5+ - Python test scripts for Proof of Concept In-Reply-To: <42BADFB9.1090800@redhat.com> References: <42B15F7F.90803@redhat.com> <42B2E569.3030100@redhat.com> <42BADFB9.1090800@redhat.com> Message-ID: <42C148DB.8020205@redhat.com> Harald Hoyer wrote: > The first "C" source can be found in: > http://people.redhat.com/harald/ServiceManager/servicemanager.tar.gz > > All it does for now: > It checks all /etc/init.d/* and creates a DBUS "Service" object for each. > > Works with dbus-0.35 (CVS version). > Now in CVS: $ unset CVS_RSH $ export CVSROOT=:pserver:anonymous at rhlinux.redhat.com:/usr/local/CVS $ cvs -z3 login $ cvs co servicemanager From ph18 at cornell.edu Tue Jun 28 14:04:53 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Tue, 28 Jun 2005 10:04:53 -0400 Subject: Desktop search tool using lucene In-Reply-To: <1119851909.2949.1.camel@localhost.localdomain> References: <200506262052.j5QKq4w4029659@laptop11.inf.utfsm.cl> <1119851909.2949.1.camel@localhost.localdomain> Message-ID: <42C15905.2090001@cornell.edu> Mike MacCana wrote: >>. >>They (meaning engineers at redhat) are discussing this. The solution >>won't use Lucene, as Lucene treats all fine content as equal - ie, it >>doesn't know about headings being different from body text and so on. >> >>Mike >> >> Also, Lucene suffers from the Java UCS-16 scandal: they chose a character encoding which is good for Japanese, but bulks up european languages by a factor of two and doesn't support enough characters to do a good job with Chinese. Because of this, Lucene loses a factor of two in performance compared to C++ competitors such as Xapian, which is a minus for those who care about performance on computers that aren't monster servers with 8 megs of RAM and Ultra 320 disks. (Funny enough, we're not all that happy with Lucene performance on such a machine... But we've got a lot of text...) From ph18 at cornell.edu Tue Jun 28 14:12:22 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Tue, 28 Jun 2005 10:12:22 -0400 Subject: Desktop search tool using lucene In-Reply-To: <1cef3e95050627171076a5ce63@mail.gmail.com> References: <1119816843.5057.26.camel@rechner1.localdomain> <604aa791050626135236068e1a@mail.gmail.com> <1cef3e95050627171076a5ce63@mail.gmail.com> Message-ID: <42C15AC6.7010606@cornell.edu> Joe Desbonnet wrote: >Traditionally web based UIs were limited, but nowadays most of the >limitations have been removed thanks to CSS styling and 'AJAX' >techniques (example: gmail). > > Yeah, until you actually try it. When I do javascript projects I spend about 30% of the time getting the app working and then the other 70% worrying about browser compatibility and workarounds for funkiness in the browser. For instance, if you're doing a drag-and-drop interface in Mozilla, you don't get notification when the cursor leaves the browser window, and mouse move events don't tell you if the buttons are down, so you can't really 'do the right thing' in these cases. The best thing I've figured is to extrapolate the motion of the mouse, and assume that the mouse went out of the window if it was heading for the edge of the window and we don't see any mouse events after a time delay. Like GUI applications, it's easy to make an AJAX application work 80% of the time (like the GUI crapplets that come with Fedora) but getting right behavior the rest of the time takes a big investment of time and energy, something most open source authors, never mind commercial entities, aren't willing to do. From jspaleta at gmail.com Tue Jun 28 14:53:14 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 28 Jun 2005 10:53:14 -0400 Subject: strange hal problem In-Reply-To: <42C10DB4.5020008@feuerpokemon.de> References: <42C10DB4.5020008@feuerpokemon.de> Message-ID: <604aa791050628075320b15d26@mail.gmail.com> On 6/28/05, dragoran wrote: > If someone has any hint how to fix this or at least can explain what > might be causing this .. please reply. Most likely the volume label on that vfat filesystem is non-ascii you can forcible reset the volume label of a vfat partition using mkfs.vfat -n "11-charname" you can fire up gnome-device-manager or lshal and see what hal things the "volume.string" is for that partition if you want to make sure that's the problem. -jef From mike at plan99.net Tue Jun 28 15:03:14 2005 From: mike at plan99.net (Mike Hearn) Date: Tue, 28 Jun 2005 16:03:14 +0100 Subject: C++ compatibility package dropped References: <20050624231932.GR22349@devserv.devel.redhat.com> <1119673751.6953.3.camel@dimi> <20050625073759.GS22349@devserv.devel.redhat.com> <42BE8A69.3020403@design.chalmers.se> <1119872669.14017.8.camel@firebolt> Message-ID: On Mon, 27 Jun 2005 04:44:28 -0700, Mitch Skinner wrote: > In the FC4 case, that would fix your issue a) above for > compat-libstdc++-33, right? Not really, my issue is that I'm distributing software that doesn't use RPMs (because doing so is not really practical or sensible). Any solution that involves the user understanding yum or RPM doesn't work. thanks -mike From mike at plan99.net Tue Jun 28 15:04:10 2005 From: mike at plan99.net (Mike Hearn) Date: Tue, 28 Jun 2005 16:04:10 +0100 Subject: C++ compatibility package dropped References: <1119823019.13523.18.camel@md.nc.linuxlobbyist.org> <604aa791050626164735ecd46@mail.gmail.com> <604aa79105062706423d87533c@mail.gmail.com> Message-ID: On Mon, 27 Jun 2005 09:42:37 -0400, Jeff Spaleta wrote: > find that argument about statically linking... satisifyingly ironic... > considering part of you argument for installing it by default is that > users don't really caring about a a few 3 mb compatibility packages on > the system here or there. It's not about disk space, it's memory usage and download sizes. thanks -mike From shahms at shahms.com Tue Jun 28 15:10:56 2005 From: shahms at shahms.com (Shahms King) Date: Tue, 28 Jun 2005 08:10:56 -0700 Subject: default rpm query format on x86_64 Message-ID: <42C16880.8030706@shahms.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The default rpm query format of %{name}-%{version}-%{release} is less than optimal on x86_64 where the x86_64 and i386 versions of some packages are installed. I've modified my local rpm macros by creating "/etc/rpm/macros.local" with: %_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch} which solves the problem on my computer, but has any thought been given to making this the default, at least on x86_64 (or other multi-lib archs)? - -- Shahms E. King Multnomah ESD Public Key: http://shahms.mesd.k12.or.us/~sking/shahms.asc Fingerprint: 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCwWiA/qs2NkWy11sRAmKEAJwN/PHi7oPdlh128aM7K7pR4h1c9wCgqBi+ Hr/szsLDtNOnXRgdfWBaoIc= =0FI4 -----END PGP SIGNATURE----- From skvidal at phy.duke.edu Tue Jun 28 15:14:43 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 28 Jun 2005 11:14:43 -0400 Subject: default rpm query format on x86_64 In-Reply-To: <42C16880.8030706@shahms.com> References: <42C16880.8030706@shahms.com> Message-ID: <1119971683.3274.0.camel@cutter> On Tue, 2005-06-28 at 08:10 -0700, Shahms King wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > The default rpm query format of %{name}-%{version}-%{release} is less > than optimal on x86_64 where the x86_64 and i386 versions of some > packages are installed. I've modified my local rpm macros by creating > "/etc/rpm/macros.local" with: > %_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch} > > which solves the problem on my computer, but has any thought been given > to making this the default, at least on x86_64 (or other multi-lib archs)? > will break A LOT of scripts and other items if you do. -sv From mls at suse.de Tue Jun 28 15:15:47 2005 From: mls at suse.de (Michael Schroeder) Date: Tue, 28 Jun 2005 17:15:47 +0200 Subject: default rpm query format on x86_64 In-Reply-To: <42C16880.8030706@shahms.com> References: <42C16880.8030706@shahms.com> Message-ID: <20050628151547.GA20812@suse.de> On Tue, Jun 28, 2005 at 08:10:56AM -0700, Shahms King wrote: > The default rpm query format of %{name}-%{version}-%{release} is less > than optimal on x86_64 where the x86_64 and i386 versions of some > packages are installed. I've modified my local rpm macros by creating > "/etc/rpm/macros.local" with: > %_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch} > > which solves the problem on my computer, but has any thought been given > to making this the default, at least on x86_64 (or other multi-lib archs)? Well, SuSE uses a different package name for the i386 version, e.g. glibc and glibc-32bit. Makes things a lot easier. Cheers, Michael. -- Michael Schroeder mls at suse.de main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} From vonbrand at inf.utfsm.cl Tue Jun 28 14:22:53 2005 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Tue, 28 Jun 2005 10:22:53 -0400 Subject: C++ compatibility package dropped In-Reply-To: Your message of "Mon, 27 Jun 2005 09:48:41 -0400." <01d801c57b1e$ed97c8b0$b6491b31@td612671> Message-ID: <200506281422.j5SEMr3e004036@laptop11.inf.utfsm.cl> Dimi Paun wrote: > From: "Jakub Jelinek" > > As long as the legacy programs people are installing are packaged > > as rpm, yum or other package managers can handle the dependencies > > just fine, so I don't see how is that a silent break. > > If not using a package manager, you take the responsibility > > of satisfying the dependencies yourself. > That doesn't mean breaking things on purpose. Isn't, AFAICS. > Pissing off customers is not The Right Thing (TM), > last time I've checked. Right. > Waiting a few more years before yanking system libs > from under people's feet would be the more prudent > thing to do. And it costs so little, it's not even > funny that it's not being considered. This is /Fedora/, commited to being bleeding edge (or thereabouts). So the "have everybody retain libraries for some years for nostalgia's sake" doesn't belong here. Sure, perhaps making a group of "legacy libraries, needed for some third party software" stand out when installing might be a good idea. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From lamont at gurulabs.com Tue Jun 28 15:17:19 2005 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Tue, 28 Jun 2005 09:17:19 -0600 Subject: default rpm query format on x86_64 In-Reply-To: <1119971683.3274.0.camel@cutter> References: <42C16880.8030706@shahms.com> <1119971683.3274.0.camel@cutter> Message-ID: <200506280917.24091.lamont@gurulabs.com> On Tuesday 28 June 2005 09:14am, seth vidal wrote: > On Tue, 2005-06-28 at 08:10 -0700, Shahms King wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > The default rpm query format of %{name}-%{version}-%{release} is less > > than optimal on x86_64 where the x86_64 and i386 versions of some > > packages are installed. I've modified my local rpm macros by creating > > "/etc/rpm/macros.local" with: > > %_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch} > > > > which solves the problem on my computer, but has any thought been given > > to making this the default, at least on x86_64 (or other multi-lib > > archs)? > > will break A LOT of scripts and other items if you do. Care to elaborate? -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. http://www.GuruLabs.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From shahms at shahms.com Tue Jun 28 15:17:54 2005 From: shahms at shahms.com (Shahms King) Date: Tue, 28 Jun 2005 08:17:54 -0700 Subject: default rpm query format on x86_64 In-Reply-To: <1119971683.3274.0.camel@cutter> References: <42C16880.8030706@shahms.com> <1119971683.3274.0.camel@cutter> Message-ID: <42C16A22.6040605@shahms.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 seth vidal wrote: | On Tue, 2005-06-28 at 08:10 -0700, Shahms King wrote: | |>-----BEGIN PGP SIGNED MESSAGE----- |>Hash: SHA1 |> |>The default rpm query format of %{name}-%{version}-%{release} is less |>than optimal on x86_64 where the x86_64 and i386 versions of some |>packages are installed. I've modified my local rpm macros by creating |>"/etc/rpm/macros.local" with: |>%_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch} |> |>which solves the problem on my computer, but has any thought been given |>to making this the default, at least on x86_64 (or other multi-lib archs)? |> | | | will break A LOT of scripts and other items if you do. | | -sv Duh. I knew I was missing something. Thanks. It's not terribly difficult to manually specify the query format in the infrequent event that it's necessary. - -- Shahms E. King Multnomah ESD Public Key: http://shahms.mesd.k12.or.us/~sking/shahms.asc Fingerprint: 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFCwWoi/qs2NkWy11sRAuJ2AJ97CIV2CfUdjwDtpbGu3IfT8PaN8ACeJKJ0 ur6Ugb5+l1Dky0V5tSpOcxo= =LpuN -----END PGP SIGNATURE----- From jakub at redhat.com Tue Jun 28 15:23:00 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 28 Jun 2005 11:23:00 -0400 Subject: C++ compatibility package dropped In-Reply-To: <200506281422.j5SEMr3e004036@laptop11.inf.utfsm.cl> References: <01d801c57b1e$ed97c8b0$b6491b31@td612671> <200506281422.j5SEMr3e004036@laptop11.inf.utfsm.cl> Message-ID: <20050628152300.GM15087@devserv.devel.redhat.com> On Tue, Jun 28, 2005 at 10:22:53AM -0400, Horst von Brand wrote: > This is /Fedora/, commited to being bleeding edge (or thereabouts). So the > "have everybody retain libraries for some years for nostalgia's sake" > doesn't belong here. Sure, perhaps making a group of "legacy libraries, > needed for some third party software" stand out when installing might be a > good idea. Such group exists and the libraries we are talking about are in that group. The disagreement is whether it ought to be installed by default or not, and the choice Fedora is making is not installing that group by default, and you need to click one checkbox to change that. As the majority of people don't need those and even for those that need it the majority will use rpm where yum localinstall etc. can handle the dependencies automatically, IMHO that's the right default choice. Jakub From alan at redhat.com Tue Jun 28 16:18:52 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 28 Jun 2005 12:18:52 -0400 Subject: Desktop search tool using lucene In-Reply-To: <1119851909.2949.1.camel@localhost.localdomain> References: <200506262052.j5QKq4w4029659@laptop11.inf.utfsm.cl> <1119851909.2949.1.camel@localhost.localdomain> Message-ID: <20050628161852.GA8866@devserv.devel.redhat.com> On Mon, Jun 27, 2005 at 03:58:29PM +1000, Mike MacCana wrote: > They (meaning engineers at redhat) are discussing this. The solution > won't use Lucene, as Lucene treats all fine content as equal - ie, it > doesn't know about headings being different from body text and so on. One possibility is the muscat engine - thats open source could probably do the job well. It's a little weak on revoking content from the index without a rebuild. From sjansen at gurulabs.com Tue Jun 28 16:55:18 2005 From: sjansen at gurulabs.com (Stuart Jansen) Date: Tue, 28 Jun 2005 10:55:18 -0600 Subject: C++ compatibility package dropped In-Reply-To: References: <1119823019.13523.18.camel@md.nc.linuxlobbyist.org> <604aa791050626164735ecd46@mail.gmail.com> <604aa79105062706423d87533c@mail.gmail.com> Message-ID: <1119977719.9285.5.camel@localhost.localdomain> On Tue, 2005-06-28 at 16:04 +0100, Mike Hearn wrote: > On Mon, 27 Jun 2005 09:42:37 -0400, Jeff Spaleta wrote: > > find that argument about statically linking... satisifyingly ironic... > > considering part of you argument for installing it by default is that > > users don't really caring about a a few 3 mb compatibility packages on > > the system here or there. > > It's not about disk space, it's memory usage and download sizes. And security. Remember all the applications that had to be updated because they statically linked zlib instead of benefiting from a updating a single dynamically linked library? There a good reasons for the mess of interdependencies in Linux. That said, the Windows world has been shipping OS libraries with applications for some time. Sure it's ugly, but you make your choices and you live with their consequences. Anyone using proprietary software on Linux should expect some bumps. As for F/OSS, try tapping the user community to find someone willing to do the integration. If there's enough demand, someone will eventually step forward. -- Stuart Jansen Guru Labs, L.C. -------------- 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 sjansen at gurulabs.com Tue Jun 28 17:11:14 2005 From: sjansen at gurulabs.com (Stuart Jansen) Date: Tue, 28 Jun 2005 11:11:14 -0600 Subject: C++ compatibility package dropped In-Reply-To: <01c101c57b1e$48b16db0$b6491b31@td612671> References: <1119823019.13523.18.camel@md.nc.linuxlobbyist.org> <604aa791050626164735ecd46@mail.gmail.com> <01c101c57b1e$48b16db0$b6491b31@td612671> Message-ID: <1119978674.9285.20.camel@localhost.localdomain> On Mon, 2005-06-27 at 09:44 -0400, Dimi Paun wrote: > And did I mention the time, effort, and _frustration_ of users to > get the system running again? What if they didn't install via RPM? > Screw them, they deserve what they get, no? (in which case they > have a snowball's chance in hell of fixing the breakage without > going through hell and back). I'd choose to place the onus on the developers. If they want their users to have a good experience, let them do the leg work. Right now, I'd argue that Windows is the gold standard of backwards compatibility. Partly because Microsoft tries hard to keep things compatible, but mostly because behind the scenes there are individual application developers bleeding, sweating, crying, and cursing. If you're going to use proprietary software, don't expect anything better better support than you had in the propriety world. If you use F/OSS and the community isn't large enough to support itself yet, start contributing or pay someone else to do it. There Ain't No Such Thing As a Free Lunch. I'm personally in favor of installing compat libs by default as long as someone it taking responsibility for handling security maintenance. I would also love to see good technical suggestions. A few interesting ideas have been suggested. But complaining isn't helpful. Arguing that Fedora or any F/OSS developer is morally obliged to bend over backwards to please users for free is repugnant. (BTW, if you think my attack and characterization is unfair, so was yours.) -- Stuart Jansen Guru Labs, L.C. -------------- 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 dimi at lattica.com Tue Jun 28 17:28:39 2005 From: dimi at lattica.com (Dimi Paun) Date: Tue, 28 Jun 2005 13:28:39 -0400 Subject: C++ compatibility package dropped References: <1119823019.13523.18.camel@md.nc.linuxlobbyist.org><604aa791050626164735ecd46@mail.gmail.com><01c101c57b1e$48b16db0$b6491b31@td612671> <1119978674.9285.20.camel@localhost.localdomain> Message-ID: <010f01c57c06$d3285150$b6491b31@td612671> From: "Stuart Jansen" > ideas have been suggested. But complaining isn't helpful. Arguing that > Fedora or any F/OSS developer is morally obliged to bend over backwards > to please users for free is repugnant. (BTW, if you think my attack and > characterization is unfair, so was yours.) Yes, it is an unfair attack. I didn't attack anybody, I just argued against the choice of not including relevant compatibility libraries. This doesn't amount to arguing for any bending acrobatics -- just that we could make life easier for everybody if we are more careful with some of these backwards compatibility issues. And complaining (within limits) is helpful -- how else will the Fedora project get feedback from the comunity? Isn't this the purpose of the project? I think it's harmful to kill such feedback with "shut up, it's free" sort of attitude. -- Dimi Paun Lattica, Inc. From sundaram at redhat.com Tue Jun 28 17:34:58 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Tue, 28 Jun 2005 23:04:58 +0530 Subject: C++ compatibility package dropped In-Reply-To: <010f01c57c06$d3285150$b6491b31@td612671> References: <1119823019.13523.18.camel@md.nc.linuxlobbyist.org><604aa791050626164735ecd46@mail.gmail.com><01c101c57b1e$48b16db0$b6491b31@td612671> <1119978674.9285.20.camel@localhost.localdomain> <010f01c57c06$d3285150$b6491b31@td612671> Message-ID: <42C18A42.4010003@redhat.com> Hi >And complaining (within limits) is helpful -- how else will the Fedora >project get feedback from the comunity? Isn't this the purpose of the >project? > > Sure. Just file a enhancement against anaconda that the legacy group should be in the default list. regards Rahul From pmatilai at laiskiainen.org Tue Jun 28 18:39:06 2005 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Tue, 28 Jun 2005 21:39:06 +0300 Subject: default rpm query format on x86_64 In-Reply-To: <1119971683.3274.0.camel@cutter> References: <42C16880.8030706@shahms.com> <1119971683.3274.0.camel@cutter> Message-ID: <1119983946.20091.3.camel@weasel> On Tue, 2005-06-28 at 11:14 -0400, seth vidal wrote: > On Tue, 2005-06-28 at 08:10 -0700, Shahms King wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > The default rpm query format of %{name}-%{version}-%{release} is less > > than optimal on x86_64 where the x86_64 and i386 versions of some > > packages are installed. I've modified my local rpm macros by creating > > "/etc/rpm/macros.local" with: > > %_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch} > > > > which solves the problem on my computer, but has any thought been given > > to making this the default, at least on x86_64 (or other multi-lib archs)? > > > > will break A LOT of scripts and other items if you do. Sure it'll break a lot of things, but that breakage is trivial to fix in scripts by specifying alternative queryformat. Dunno if there are commercial non-OSS applications parsing rpm default output but frankly I don't care if they break. OTOH, . - Panu - From dragoran at feuerpokemon.de Tue Jun 28 18:14:31 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 28 Jun 2005 20:14:31 +0200 Subject: strange hal problem In-Reply-To: <604aa791050628075320b15d26@mail.gmail.com> References: <42C10DB4.5020008@feuerpokemon.de> <604aa791050628075320b15d26@mail.gmail.com> Message-ID: <42C19387.3050809@feuerpokemon.de> Jeff Spaleta wrote: >On 6/28/05, dragoran wrote: > > >>If someone has any hint how to fix this or at least can explain what >>might be causing this .. please reply. >> >> > >Most likely the volume label on that vfat filesystem is non-ascii >you can forcible reset the volume label of a vfat partition using >mkfs.vfat -n "11-charname" > >you can fire up gnome-device-manager or lshal and see what hal things >the "volume.string" is for that partition if you want to make sure >that's the problem. > >-jef > > > there is no volume.string. this is everything that lshal writes about it: udi = '/org/freedesktop/Hal/devices/volume_uuid_8266_20DC' volume.policy.desired_mount_point = 'd> ";' (string) volume.policy.mount_filesystem = 'vfat' (string) volume.policy.should_mount = true (bool) info.udi = '/org/freedesktop/Hal/devices/volume_uuid_8266_20DC' (string) volume.partition.msdos_part_table_type = 12 (0xc) (int) info.product = 'd> ";' (string) volume.size = 40007729664 (0x950a58200) (uint64) volume.num_blocks = 78140097 (0x4a852c1) (int) volume.block_size = 512 (0x200) (int) volume.partition.number = 1 (0x1) (int) info.capabilities = {'volume', 'block'} (string list) info.category = 'volume' (string) volume.is_partition = true (bool) volume.is_disc = false (bool) volume.is_mounted = true (bool) volume.mount_point = '/mnt/hdb' (string) volume.label = 'd> ";' (string) volume.uuid = '8266-20DC' (string) volume.fsversion = 'FAT32' (string) volume.fsusage = 'filesystem' (string) volume.fstype = 'vfat' (string) block.storage_device = '/org/freedesktop/Hal/devices/storage_serial_6EF0CAAP' (string) block.is_volume = true (bool) block.minor = 65 (0x41) (int) block.major = 3 (0x3) (int) block.device = '/dev/hdb1' (string) linux.hotplug_type = 3 (0x3) (int) info.parent = '/org/freedesktop/Hal/devices/storage_serial_6EF0CAAP' (string) linux.sysfs_path_device = '/sys/block/hdb/hdb1' (string) linux.sysfs_path = '/sys/block/hdb/hdb1' (string) mkfs.vat does format the volume... this would mean that I would loose all data stored on it. can I change it without recreate the fs? From jspaleta at gmail.com Tue Jun 28 18:45:42 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 28 Jun 2005 14:45:42 -0400 Subject: default rpm query format on x86_64 In-Reply-To: <1119983946.20091.3.camel@weasel> References: <42C16880.8030706@shahms.com> <1119971683.3274.0.camel@cutter> <1119983946.20091.3.camel@weasel> Message-ID: <604aa7910506281145401b4b86@mail.gmail.com> On 6/28/05, Panu Matilainen wrote: > > will break A LOT of scripts and other items if you do. > > Sure it'll break a lot of things, but that breakage is trivial to fix in > scripts by specifying alternative queryformat. Dunno if there are > commercial non-OSS applications parsing rpm default output but frankly I > don't care if they break. OTOH, . I think the idea here that there are potentially many many many homebrew sysadmin scripts out in the wild that are relying on the default format. Not sure you'd call the mountain of steaming shell-scriptage 'applications' but they do keep the world from exploding. -jef From hughsient at gmail.com Tue Jun 28 18:58:30 2005 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 28 Jun 2005 19:58:30 +0100 Subject: gnome-pilot patches need applying In-Reply-To: References: <1119892539.3377.7.camel@localhost.localdomain> <1119892681.3030.77.camel@cassandra.boston.redhat.com> <1119892918.4185.0.camel@localhost.localdomain> <1119947221.3720.2.camel@angua.localnet> Message-ID: <1119985110.3138.4.camel@localhost.localdomain> On Tue, 2005-06-28 at 03:14 -0700, Alex Lancaster wrote: > I downgraded to using pilot-link-0.11.8 on FC4 for this reason (I > don't even try gnome-pilot let alone evolution integration), and seems > to be working OK. I'll file some bugs on bugzilla.redhat.com on the > current pilot-link-0.12.0-0.pre3.0.fc4.1 included in FC4 when I get > time. Interestingly, the pilot-link maintainer, David Desrosiers, has > specifically admonished distributions not to include any of pilot-link > 0.12 pre-test versions and wait until the official 0.12.0 release: I was talking to him last night in #gnome, and he's not happy what fedora are doing - he's getting loads of bugreports that are specific to FC4, and not present in the main release. Is there a specific reason we went so bleeding edge? > See the first announcement of pilot-link-0.12-pre1: > > http://www.pilot-link.org/node/129 > > and a recent posting here: > > http://mail.gnome.org/archives/gnome-pilot-list/2005-June/msg00011.html > > I know Fedora is supposed to be bleeding edge, but is it wise to > include a version in the distro that it's maintainer specifically > suggests not to? I'm curious to know the reasoning behind including > this version in FC4. Similar. The rawhide patches allow me to sync my palm using gnome-pilot (thanks!) but also delete all my contacts and todo's on my palm! Just a warning for all those of you who don't believe in backups! Richard -------------- 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 redhat.com Tue Jun 28 19:13:09 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 29 Jun 2005 00:43:09 +0530 Subject: gnome-pilot patches need applying In-Reply-To: <1119985110.3138.4.camel@localhost.localdomain> References: <1119892539.3377.7.camel@localhost.localdomain> <1119892681.3030.77.camel@cassandra.boston.redhat.com> <1119892918.4185.0.camel@localhost.localdomain> <1119947221.3720.2.camel@angua.localnet> <1119985110.3138.4.camel@localhost.localdomain> Message-ID: <42C1A145.4040204@redhat.com> Hi >Similar. The rawhide patches allow me to sync my palm using gnome-pilot >(thanks!) but also delete all my contacts and todo's on my palm! Just a >warning for all those of you who don't believe in backups! > >Richard > > Kindly file a bug report on this. regards Rahul From hughsient at gmail.com Tue Jun 28 19:29:04 2005 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 28 Jun 2005 20:29:04 +0100 Subject: gnome-pilot patches need applying In-Reply-To: <42C1A145.4040204@redhat.com> References: <1119892539.3377.7.camel@localhost.localdomain> <1119892681.3030.77.camel@cassandra.boston.redhat.com> <1119892918.4185.0.camel@localhost.localdomain> <1119947221.3720.2.camel@angua.localnet> <1119985110.3138.4.camel@localhost.localdomain> <42C1A145.4040204@redhat.com> Message-ID: <1119986944.3138.6.camel@localhost.localdomain> On Wed, 2005-06-29 at 00:43 +0530, Rahul Sundaram wrote: > Hi > > >Similar. The rawhide patches allow me to sync my palm using gnome-pilot > >(thanks!) but also delete all my contacts and todo's on my palm! Just a > >warning for all those of you who don't believe in backups! > > > >Richard > > > > > Kindly file a bug report on this. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161963 Richard -------------- 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 nmiell at comcast.net Tue Jun 28 22:06:25 2005 From: nmiell at comcast.net (Nicholas Miell) Date: Tue, 28 Jun 2005 15:06:25 -0700 Subject: default rpm query format on x86_64 In-Reply-To: <42C16880.8030706@shahms.com> References: <42C16880.8030706@shahms.com> Message-ID: <1119996385.2943.1.camel@localhost.localdomain> On Tue, 2005-06-28 at 08:10 -0700, Shahms King wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > The default rpm query format of %{name}-%{version}-%{release} is less > than optimal on x86_64 where the x86_64 and i386 versions of some > packages are installed. I've modified my local rpm macros by creating > "/etc/rpm/macros.local" with: > %_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch} > > which solves the problem on my computer, but has any thought been given > to making this the default, at least on x86_64 (or other multi-lib archs)? Add the following to ~/.popt rpm alias --nvra --qf "%{n}-%{v}-%{r}.%{arch}\n" and then rpm -q --nvra will do what you want, without breaking random scripts. -- Nicholas Miell From paul at all-the-johnsons.co.uk Tue Jun 28 23:00:44 2005 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 29 Jun 2005 00:00:44 +0100 Subject: Opportunity to promote FC4 Message-ID: <1119999644.25367.35.camel@localhost> Hi, Other than testing rawhide, I also edit an international programmers magazine from the Association of C and C++ Users called C Vu. Why am I posting? Simple. Would anyone involved with the development of the distro care to document the process of creating the distro, QC etc for the next edition of C Vu? The magazine is read throughout the world, so it won't be some fiddly little thing! If anyone is interested, please let me know. TTFN Paul email : cvu at accu.org -- "The city of Washington was built on a stagnant swamp some 200 years ago and very little has changed; it stank then and it stinks now. Only today, it is the fetid stench of corruption that hangs in the air" - Simpson, L. Mr Lisa Goes to Washington (1991) Fox. 8F01 (Sep). -------------- 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 redhat.com Tue Jun 28 23:09:17 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 29 Jun 2005 04:39:17 +0530 Subject: Opportunity to promote FC4 In-Reply-To: <1119999644.25367.35.camel@localhost> References: <1119999644.25367.35.camel@localhost> Message-ID: <42C1D89D.9050700@redhat.com> Paul wrote: >Hi, > >Other than testing rawhide, I also edit an international programmers >magazine from the Association of C and C++ Users called C Vu. Why am I >posting? Simple. > >Would anyone involved with the development of the distro care to >document the process of creating the distro, QC etc for the next edition >of C Vu? The magazine is read throughout the world, so it won't be some >fiddly little thing! > Ok. This would be a good thing for me to get into. Contact me off list. Specific questions would be better I think regards Rahul From ottohaliburton at comcast.net Tue Jun 28 23:21:16 2005 From: ottohaliburton at comcast.net (Otto Haliburton) Date: Tue, 28 Jun 2005 18:21:16 -0500 Subject: gnome-pilot patches need applying In-Reply-To: <42C1A145.4040204@redhat.com> Message-ID: <004b01c57c38$162fa080$4801a8c0@C515816A> > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > bounces at redhat.com] On Behalf Of Rahul Sundaram > Sent: Tuesday, June 28, 2005 2:13 PM > To: Development discussions related to Fedora Core > Subject: Re: gnome-pilot patches need applying > > Hi > > >Similar. The rawhide patches allow me to sync my palm using gnome-pilot > >(thanks!) but also delete all my contacts and todo's on my palm! Just a > >warning for all those of you who don't believe in backups! > > > >Richard > > > > > Kindly file a bug report on this. > > regards > Rahul > I am not sure this is a error, did you check the settings for your syncing, whether it was set computer to pda, or pda to computer, it makes a difference, if it is computer overwrites pda and this is the first time of use then all data on the pda will be erased with whatever data is on the pc, the first use should be pda overwrites computer. So there needs to be more info on what you did. But, having said that it could also be a bug so you probably need to explain what you did. From dmalcolm at redhat.com Wed Jun 29 00:02:55 2005 From: dmalcolm at redhat.com (David Malcolm) Date: Tue, 28 Jun 2005 20:02:55 -0400 Subject: gnome-pilot patches need applying In-Reply-To: References: <1119892539.3377.7.camel@localhost.localdomain> <1119892681.3030.77.camel@cassandra.boston.redhat.com> <1119892918.4185.0.camel@localhost.localdomain> <1119947221.3720.2.camel@angua.localnet> Message-ID: <1120003375.31459.10.camel@cassandra.boston.redhat.com> On Tue, 2005-06-28 at 03:14 -0700, Alex Lancaster wrote: > >>>>> "NM" == Nigel Metheringham writes: > > NM> Palm support seems to be especially cursed in FC4. There are some > NM> really low level problems - something that appears to be > NM> kernel/udev/hotplug (or quite likely a timing related bug in that > NM> set) that prevents even the command line pilot-xfer tools working > NM> in many cases (which completely destroys the possibility of > NM> gnome-pilot working). > > NM> Then gnome-pilot has a batch of bugs including timing related on > NM> ttyUSB, broken API wrt to pilot-link (which it links to), broken > NM> conduits and broken evolution integration. > > NM> Someone really really doesn't like this stuff :-/ > > I downgraded to using pilot-link-0.11.8 on FC4 for this reason (I > don't even try gnome-pilot let alone evolution integration), and seems > to be working OK. I'll file some bugs on bugzilla.redhat.com on the > current pilot-link-0.12.0-0.pre3.0.fc4.1 included in FC4 when I get > time. Interestingly, the pilot-link maintainer, David Desrosiers, has > specifically admonished distributions not to include any of pilot-link > 0.12 pre-test versions and wait until the official 0.12.0 release: > > See the first announcement of pilot-link-0.12-pre1: > > http://www.pilot-link.org/node/129 > > and a recent posting here: > > http://mail.gnome.org/archives/gnome-pilot-list/2005-June/msg00011.html > > I know Fedora is supposed to be bleeding edge, but is it wise to > include a version in the distro that it's maintainer specifically > suggests not to? I'm curious to know the reasoning behind including > this version in FC4. I think we made a mistake with this. I'm sorry for the pain this is causing everybody. I've been attempting to fix gnome-pilot (and evolution's conduits); tomorrow's rawhide should have a much better version of both packages, including numerous patches by Mark G Adams, who is currently my hero. I'll report back when I've got more information From bernie at develer.com Wed Jun 29 00:28:23 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Wed, 29 Jun 2005 02:28:23 +0200 Subject: default rpm query format on x86_64 In-Reply-To: <604aa7910506281145401b4b86@mail.gmail.com> References: <42C16880.8030706@shahms.com> <1119971683.3274.0.camel@cutter> <1119983946.20091.3.camel@weasel> <604aa7910506281145401b4b86@mail.gmail.com> Message-ID: <42C1EB27.8040904@develer.com> Jeff Spaleta wrote: > On 6/28/05, Panu Matilainen wrote: > >>>will break A LOT of scripts and other items if you do. >> >>Sure it'll break a lot of things, but that breakage is trivial to fix in >>scripts by specifying alternative queryformat. Dunno if there are >>commercial non-OSS applications parsing rpm default output but frankly I >>don't care if they break. OTOH, . > > > I think the idea here that there are potentially many many many > homebrew sysadmin scripts out in the wild that are relying on the > default format. Not sure you'd call the mountain of steaming > shell-scriptage 'applications' but they do keep the world from > exploding. This quick Perl hack by me would have broken: http://freshmeat.net/projects/newrpms/ This program was broken already on multiarch platforms because it would consider an i386 package a candidate for upgrading an x86_64 package. I've now teached it to consider architectures instead of stripping them away. BTW, I missed the architecture part in rpm -qa too. My fix was adding this simple alias to the global profile: rpmqa() { rpm -qa --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' | sort } -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From perbj at stanford.edu Wed Jun 29 01:29:03 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Tue, 28 Jun 2005 18:29:03 -0700 Subject: Desktop search tool using lucene In-Reply-To: <20050628161852.GA8866@devserv.devel.redhat.com> References: <200506262052.j5QKq4w4029659@laptop11.inf.utfsm.cl> <1119851909.2949.1.camel@localhost.localdomain> <20050628161852.GA8866@devserv.devel.redhat.com> Message-ID: <1120008544.2829.8.camel@localhost.localdomain> On Tue, 2005-06-28 at 12:18 -0400, Alan Cox wrote: > On Mon, Jun 27, 2005 at 03:58:29PM +1000, Mike MacCana wrote: > > They (meaning engineers at redhat) are discussing this. The solution > > won't use Lucene, as Lucene treats all fine content as equal - ie, it > > doesn't know about headings being different from body text and so on. > > One possibility is the muscat engine - thats open source could probably do the > job well. It's a little weak on revoking content from the index without a > rebuild. I think it's the Xapian engine you're talking about? http://xapian.org/ GPL, written in C++. Apparently it's being tried out for use as the Gmane search engine. /Per From chrism at plope.com Wed Jun 29 04:39:56 2005 From: chrism at plope.com (Chris McDonough) Date: Wed, 29 Jun 2005 00:39:56 -0400 Subject: Desktop search tool using lucene In-Reply-To: <1120008544.2829.8.camel@localhost.localdomain> References: <200506262052.j5QKq4w4029659@laptop11.inf.utfsm.cl> <1119851909.2949.1.camel@localhost.localdomain> <20050628161852.GA8866@devserv.devel.redhat.com> <1120008544.2829.8.camel@localhost.localdomain> Message-ID: <1120019997.6606.32.camel@plope.dyndns.org> Not that it's terribly fast, but it is pretty easy to use and it's written in Python: http://svn.zope.org/Zope3/trunk/src/zope/app/catalog/ The indexing code that this employs has been in use within Zope for many years. Interesting code examples include: http://svn.zope.org/Zope3/trunk/src/zope/index/text/textindex.txt?rev=28610&view=markup http://svn.zope.org/Zope3/trunk/src/zope/index/text/tests/mhindex.py?rev=29703&view=markup - C On Tue, 2005-06-28 at 18:29 -0700, Per Bjornsson wrote: > On Tue, 2005-06-28 at 12:18 -0400, Alan Cox wrote: > > On Mon, Jun 27, 2005 at 03:58:29PM +1000, Mike MacCana wrote: > > > They (meaning engineers at redhat) are discussing this. The solution > > > won't use Lucene, as Lucene treats all fine content as equal - ie, it > > > doesn't know about headings being different from body text and so on. > > > > One possibility is the muscat engine - thats open source could probably do the > > job well. It's a little weak on revoking content from the index without a > > rebuild. > > I think it's the Xapian engine you're talking about? > http://xapian.org/ > GPL, written in C++. Apparently it's being tried out for use as the > Gmane search engine. > > /Per > > From buildsys at redhat.com Wed Jun 29 11:21:49 2005 From: buildsys at redhat.com (Build System) Date: Wed, 29 Jun 2005 07:21:49 -0400 Subject: rawhide report: 20050629 changes Message-ID: <200506291121.j5TBLnps025512@porkchop.devel.redhat.com> Updated Packages: at-spi-1.6.4-1 -------------- * Tue Jun 28 2005 Matthias Clasen 1.6.4-1 - Update to 1.6.4 atk-1.10.1-1 ------------ * Tue Jun 28 2005 Matthias Clasen - 1.10.1-1 - Update to 1.10.1 audit-0.9.15-1 -------------- * Mon Jun 27 2005 Steve Grubb 0.9.15-1 - Update log rotation handling to be more robust carol-0:1.8.9.3-1jpp_4fc ------------------------ * Mon Jun 27 2005 Gary Benson 0:1.8.9.3-1jpp_4fc - 'And do it again until you get it right!' * Mon Jun 27 2005 Gary Benson 0:1.8.9.3-1jpp_3fc - Build the gcj classmap correctly. dbus-0.34-1 ----------- * Tue Jun 28 2005 John (J5) Palmieri - 0.34-1 - Upgrade to dbus-0.34 - added dbus-0.34-kill-babysitter.patch - added dbus-0.34-python-threadsync.patch - remove dbus-0.32-print_child_pid.patch - remove dbus-0.32-deadlock-fix.patch - remove dbus-0.33-types.patch evolution-2.2.2-11.fc5 ---------------------- * Tue Jun 28 2005 David Malcolm - 2.2.2-11.fc5 - Remove GNOME_COMPILE_WARNINGS from configure.in (since gnome-common might not be available when we rerun the autotools; patch 803) * Tue Jun 28 2005 David Malcolm - 2.2.2-10.fc5 - Moved .conduit files to libdir/gnome-pilot/conduits, rather than beneath datadir, to match gnome-pilot (patch 802) freeradius-1.0.4-1 ------------------ * Tue Jun 28 2005 Thomas Woerner 1.0.4-1 - new version 1.0.4 - droppend radrelay patch (fixed upstream) gnome-mag-0.12.1-1 ------------------ * Tue Jun 28 2005 Matthias Clasen 0.12.1-1 - Update to 0.12.1 gnome-pilot-2.0.13-6.fc5 ------------------------ * Tue Jun 28 2005 David Malcolm - 2.0.13-6.fc5 - Regenerate patch 18 with a fix for a crash in the backup conduit (would crash whenever no modifications had occurred since the last sync) * Tue Jun 28 2005 David Malcolm - 2.0.13-5.fc5 - Fixed gnome-pilot-2.0.12-move-conduits-autotools.patch to set GNOME_PILOT_CONDUIT_SEARCH_PATH to libdir/gnome-pilot/conduits rather than share/gnome-pilot/conduits; should be able to find conduits now. - Finished removing test conduit gnome-themes-2.11.3-1 --------------------- * Tue Jun 28 2005 Matthias Clasen - 2.11.3-1 - Update to 2.11.3 and Clearlooks 0.6.1 gnopernicus-0.11.2-1 -------------------- * Tue Jun 28 2005 Matthias Clasen 0.11.2-1 - Update to 0.11.2 - Update filelist gnu-crypto-0:2.0.1-1jpp_6fc --------------------------- * Tue Jun 28 2005 Gary Benson - 0:2.0.1-1jpp_6fc - BC-compile. gok-1.0.5-1 ----------- * Tue Jun 28 2005 Matthias Clasen 1.0.5-1 - Update to 1.0.5 grep-2.5.1-50 ------------- * Tue Jun 28 2005 Tim Waugh 2.5.1-50 - Futher fixing for bug #161700. gtk2-engines-2.6.3-3 -------------------- * Tue Jun 28 2005 Matthias Clasen 2.6.3-3 - Update Clearlooks to 0.6.1 howl-logger-0:0.1.8-1jpp_2fc ---------------------------- * Tue Jun 28 2005 Gary Benson 0:0.1.8-1jpp_2fc - BC-compile. java_cup-1:0.10-0.k.1jpp_4fc ---------------------------- * Tue Jun 28 2005 Gary Benson 1:0.10-0.k.1jpp_4fc - BC-compile. jonathan-core-0:4.1-1jpp_3fc ---------------------------- * Tue Jun 28 2005 Gary Benson 0:4.1-1jpp_3fc - BC-compile. jonathan-jeremie-0:4.2-1jpp_3fc ------------------------------- * Tue Jun 28 2005 Gary Benson 0:4.2-1jpp_3fc - BC-compile. joram-0:4.1.5-1jpp_3fc ---------------------- * Tue Jun 28 2005 Gary Benson 0:4.1.5-1jpp_3fc - BC-compile. jotm-0:2.0.5-1jpp_2fc --------------------- * Tue Jun 28 2005 Gary Benson 0:2.0.5-1jpp_2fc - BC-compile. kdeaccessibility-1:3.4.1-1 -------------------------- * Tue Jun 28 2005 Than Ngo 1:3.4.1-1 - 3.4.1 - fix gcc4 build problem * Wed Mar 16 2005 Than Ngo 1:3.4.0-1 - KDE 3.4.0 final * Sun Feb 27 2005 Than Ngo 1:3.4.0-0.rc1.1 - KDE 3.4.0 rc1 kdeaddons-3.4.1-1 ----------------- * Tue Jun 28 2005 Than Ngo 3.4.1-1 - 3.4.1 * Tue Apr 05 2005 Than Ngo 3.4.0-2 - xmms is removed in fc4, rebuild without xmms support * Thu Mar 17 2005 Than Ngo 3.4.0-1 - 3.4.0 release kdeadmin-7:3.4.1-1 ------------------ * Tue Jun 28 2005 Than Ngo 7:3.4.1-1 - 3.4.1 * Fri Mar 18 2005 Than Ngo 7:3.4.0-1 - 3.4.0 * Fri Mar 04 2005 Than Ngo 7:3.4.0-0.rc1.2 - rebuilt against gcc-4.0.0-0.31 kdeartwork-3.4.1-1 ------------------ * Tue Jun 28 2005 Than Ngo 3.4.1-1 - 3.4.1 * Fri Mar 18 2005 Than Ngo 3.4.0-1 - 3.4.0 * Fri Mar 04 2005 Than Ngo 3.4.0-0.rc1.2 - rebuilt against gcc-4.0.0-0.31 kdebindings-3.4.1-1 ------------------- * Tue Jun 28 2005 Than Ngo 3.4.1-1 - 3.4.1 * Fri Mar 18 2005 Than Ngo 3.4.0-1 - 3.4.0 * Sat Mar 05 2005 Than Ngo 3.4.0-0.rc1.2 - fix gcc4 build problem kdeedu-3.4.1-1 -------------- * Tue Jun 28 2005 Than Ngo 3.4.1-1 - 3.4.1 - fix gcc4 build problem * Fri Mar 18 2005 Than Ngo 3.4.0-1 - 3.4.0 * Fri Mar 04 2005 Than Ngo 3.4.0-0.rc1.2 - rebuilt against gcc-4.0.0-0.31 kdegames-6:3.4.1-1 ------------------ * Tue Jun 28 2005 Than Ngo 6:3.4.1-1 - 3.4.1 * Fri Mar 18 2005 Than Ngo 6:3.4.0-1 - 3.4.0 * Fri Mar 04 2005 Than Ngo 6:3.4.0-0.rc1.2 - rebuilt against gcc-4.0.0-0.31 kdegraphics-7:3.4.1-1 --------------------- * Tue Jun 28 2005 Than Ngo 7:3.4.1-1 - 3.4.1 - fix gcc4 build problem * Wed Mar 30 2005 Florian La Roche - try rebuilding * Fri Mar 18 2005 Than Ngo 7:3.4.0-1 - 3.4.0 kdemultimedia-6:3.4.1-1 ----------------------- * Tue Jun 28 2005 Than Ngo 6:3.4.1-1 - 3.4.1 * Tue May 03 2005 Than Ngo 6:3.4.0-3 - fix kde-multimedia-music.menu * Wed Mar 30 2005 Than Ngo 6:3.4.0-2 - buildrequires libmusicbrainz, libtunepimp if Juk enable kdenetwork-7:3.4.1-1 -------------------- * Tue Jun 28 2005 Than Ngo 7:3.4.1-1 - 3.4.1 * Tue Apr 05 2005 Than Ngo 7:3.4.0-3 - xmms is removed in fc4, rebuild without xmms support * Wed Mar 23 2005 Than Ngo 7:3.4.0-2 - 3_4_BRANCH CVS fixes kdepim-6:3.4.1-1 ---------------- * Mon Jun 27 2005 Than Ngo 6:3.4.1-1 - add kdepim-kpilot-fix.diff - update to 3.4.1 - remove kdepim-3.4.0-long.patch, it's included in new upstream * Wed Mar 23 2005 Than Ngo 6:3.4.0-4 - add lockdev support patch in kandy from Peter Rockai #84143 - add missing kandy icons #141165 * Mon Mar 21 2005 Than Ngo 6:3.4.0-3 - cleanup build dependencies #151673 kdesdk-3.4.1-1 -------------- * Tue Jun 28 2005 Than Ngo 2:3.4.1-1 - 3.4.1 * Wed Apr 20 2005 Than Ngo 2:3.4.0-3 - fix dependency issue * Tue Apr 19 2005 Than Ngo 2:3.4.0-2 - buildrequires cleanup libgnomecanvas-2.11.1-1 ----------------------- * Tue Jun 28 2005 Matthias Clasen - 2.11.1-1 - Update to 2.11.1 libwpd-0.8.2-2.fc5 ------------------ * Tue Jun 28 2005 Caolan McNamara 0.8.2-2.fc5 - export to other formats twiddle * Wed Jun 22 2005 Caolan McNamara 0.8.2-1 - bump to latest version * Fri Apr 29 2005 Caolan McNamara 0.8.1-1 - bump to latest version kudos Fridrich Strba - drop integrated patch monolog-0:1.8.6-1jpp_3fc ------------------------ * Tue Jun 28 2005 Gary Benson 0:1.8.6-1jpp_3fc - Don't ship the test jarfile. - BC-compile. openoffice.org-1:1.9.112-1.2.0.fc5 ---------------------------------- * Mon Jun 27 2005 Caolan McNamara - 1:1.9.112-1 - bump to next version - add openoffice.org-1.9.112.ooo50875.gtkslowunderkde.vcl.patch for rh#157158# * Tue Jun 21 2005 Caolan McNamara - 1:1.9.111-1 - bump to next version - drop integrated openoffice.org-1.9.87.ooo50575.fragments.patch - add openoffice.org-1.9.111.ooo51091.exportgcjsymbolname.jvmaccess.patch to export differently named symbols under gcj - try to workaround hsqldb problems with itself and with gcj * Thu Jun 16 2005 Caolan McNamara - 1:1.9.110-1 - bump to next version - drop integrated workspace.gcc4fwdecl.patch - need a openoffice.org-1.9.110.oooXXXXX.psprintfriend.patch oro-0:2.0.8-1jpp_3fc -------------------- * Tue Jun 28 2005 Gary Benson 2.0.8-1jpp_3fc - Remove classes and jarfiles from the tarball. p6spy-0:1.3-2jpp_2fc -------------------- * Tue Jun 28 2005 Gary Benson 0:1.3-2jpp_2fc - BC-compile. perl-DBD-Pg-1.43-1 ------------------ * Tue Jun 28 2005 Jose Pedro Oliveira - 1.43-1 - Update to 1.43 (corrects #156840). pilot-link-1:0.12.0-0.pre4.2 ---------------------------- * Tue Jun 28 2005 Than Ngo 0.12.0-0.pre4.2 - fix c++ build problem xalan-j2-0:2.6.0-3jpp_2fc ------------------------- * Tue Jun 28 2005 Gary Benson 0:2.6.0-3jpp_2fc - Remove a tarball from the tarball too. - Fix demo subpackage's dependencies. xchat-1:2.4.4-1 --------------- * Sun Jun 26 2005 Christopher Aillon 1:2.4.4-1 - Update to xchat-2.4.4 xml-commons-resolver-0:1.1-1jpp_5fc ----------------------------------- * Tue Jun 28 2005 Gary Benson 0:1.1-1jpp_5fc - Remove jarfile from the tarball. Broken deps for s390 ---------------------------------------------------------- axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper selinux-policy-strict-sources - 1.23.18-20.noarch requires kernel >= 0:2.6.11-1.1219 sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2 lvm2 - 2.01.12-1.0.s390 requires kernel >= 0:2.6 velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 selinux-policy-targeted-sources - 1.23.18-20.noarch requires kernel >= 0:2.6.11-1.1219 jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 selinux-policy-targeted - 1.23.18-20.noarch requires kernel >= 0:2.6.11-1.1219 xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2 jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 wsdl4j - 1.5.1-1jpp_1fc.noarch requires java castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 jessie - 1.0.0-8.noarch requires java >= 0:1.4 xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging selinux-policy-strict - 1.23.18-20.noarch requires kernel >= 0:2.6.11-1.1219 jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10 initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6 nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14 java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging castor - 0.9.5-1jpp_1fc.noarch requires jta sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21 jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 dhcp - 10:3.0.2-14.s390 requires kernel >= 0:2.2.18 xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0 jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_3fc.noarch requires carol = 0:1.8.9.3 jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30 jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_3fc.noarch requires jasper5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 quota - 1:3.12-6.s390 requires kernel >= 0:2.4 hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11 joram - 4.1.5-1jpp_2fc.noarch requires jmxri joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_2fc.noarch requires jta arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0 Broken deps for ppc64 ---------------------------------------------------------- jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 system-config-mouse - 1.2.11-1.noarch requires pyxf86config jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 joram - 4.1.5-1jpp_2fc.noarch requires jmxri joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_2fc.noarch requires jta jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging wsdl4j - 1.5.1-1jpp_1fc.noarch requires java jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 system-config-display - 1.0.29-1.noarch requires /usr/X11R6/bin/Xorg system-config-display - 1.0.29-1.noarch requires pyxf86config >= 0:0.3.16 castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java castor - 0.9.5-1jpp_1fc.noarch requires jta jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging rhpl - 0.167-1.ppc64 requires pyxf86config >= 0:0.3.2 gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit) gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit) jessie - 1.0.0-8.noarch requires java >= 0:1.4 system-config-keyboard - 1.2.6-2.noarch requires pyxf86config jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_3fc.noarch requires carol = 0:1.8.9.3 jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30 jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_3fc.noarch requires jasper5 ppc64-utils - 0.7-9.ppc64 requires yaboot xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 Broken deps for ia64 ---------------------------------------------------------- magma-plugins - 1.0-0.pre16.11.ia64 requires libgulm.so.1.0()(64bit) jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_3fc.noarch requires carol = 0:1.8.9.3 jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30 jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_3fc.noarch requires jasper5 jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging wsdl4j - 1.5.1-1jpp_1fc.noarch requires java jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging jessie - 1.0.0-8.noarch requires java >= 0:1.4 xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 castor - 0.9.5-1jpp_1fc.noarch requires jta xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 rgmanager - 1.9.31-3.ia64 requires ccs joram - 4.1.5-1jpp_2fc.noarch requires jmxri joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_2fc.noarch requires jta jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper Broken deps for s390x ---------------------------------------------------------- jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 wsdl4j - 1.5.1-1jpp_1fc.noarch requires java sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21 libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0 joram - 4.1.5-1jpp_2fc.noarch requires jmxri joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_2fc.noarch requires jta hal - 0.5.2-2.s390x requires kernel >= 0:2.6.11 selinux-policy-strict-sources - 1.23.18-20.noarch requires kernel >= 0:2.6.11-1.1219 sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit) jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper selinux-policy-strict - 1.23.18-20.noarch requires kernel >= 0:2.6.11-1.1219 hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11 hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet nfs-utils - 1.0.7-8.s390x requires kernel >= 0:2.2.14 dhcp - 10:3.0.2-14.s390x requires kernel >= 0:2.2.18 xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_3fc.noarch requires carol = 0:1.8.9.3 jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30 jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_3fc.noarch requires jasper5 selinux-policy-targeted-sources - 1.23.18-20.noarch requires kernel >= 0:2.6.11-1.1219 initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6 velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2 castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 selinux-policy-targeted - 1.23.18-20.noarch requires kernel >= 0:2.6.11-1.1219 arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0 libpcap - 14:0.8.3-14.s390x requires kernel >= 0:2.2.0 axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 castor - 0.9.5-1jpp_1fc.noarch requires jta jessie - 1.0.0-8.noarch requires java >= 0:1.4 jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 quota - 1:3.12-6.s390x requires kernel >= 0:2.4 prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10 lvm2 - 2.01.12-1.0.s390x requires kernel >= 0:2.6 java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj From alan at redhat.com Wed Jun 29 14:24:26 2005 From: alan at redhat.com (Alan Cox) Date: Wed, 29 Jun 2005 10:24:26 -0400 Subject: Desktop search tool using lucene In-Reply-To: <1120008544.2829.8.camel@localhost.localdomain> References: <200506262052.j5QKq4w4029659@laptop11.inf.utfsm.cl> <1119851909.2949.1.camel@localhost.localdomain> <20050628161852.GA8866@devserv.devel.redhat.com> <1120008544.2829.8.camel@localhost.localdomain> Message-ID: <20050629142426.GD29657@devserv.devel.redhat.com> On Tue, Jun 28, 2005 at 06:29:03PM -0700, Per Bjornsson wrote: > I think it's the Xapian engine you're talking about? Yes > http://xapian.org/ > GPL, written in C++. Apparently it's being tried out for use as the > Gmane search engine. Cool From dragoran at feuerpokemon.de Wed Jun 29 16:29:33 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Wed, 29 Jun 2005 18:29:33 +0200 Subject: strange hal problem In-Reply-To: <42C19387.3050809@feuerpokemon.de> References: <42C10DB4.5020008@feuerpokemon.de> <604aa791050628075320b15d26@mail.gmail.com> <42C19387.3050809@feuerpokemon.de> Message-ID: <42C2CC6D.4070006@feuerpokemon.de> dragoran wrote: > Jeff Spaleta wrote: > >> On 6/28/05, dragoran wrote: >> >> >>> If someone has any hint how to fix this or at least can explain what >>> might be causing this .. please reply. >>> >> >> >> Most likely the volume label on that vfat filesystem is non-ascii you >> can forcible reset the volume label of a vfat partition using >> mkfs.vfat -n "11-charname" >> >> you can fire up gnome-device-manager or lshal and see what hal things >> the "volume.string" is for that partition if you want to make sure >> that's the problem. >> >> -jef >> >> >> > there is no volume.string. > this is everything that lshal writes about it: > udi = '/org/freedesktop/Hal/devices/volume_uuid_8266_20DC' > volume.policy.desired_mount_point = 'd> > > ";' (string) > volume.policy.mount_filesystem = 'vfat' (string) > volume.policy.should_mount = true (bool) > info.udi = '/org/freedesktop/Hal/devices/volume_uuid_8266_20DC' > (string) > volume.partition.msdos_part_table_type = 12 (0xc) (int) > info.product = 'd> > > ";' (string) > volume.size = 40007729664 (0x950a58200) (uint64) > volume.num_blocks = 78140097 (0x4a852c1) (int) > volume.block_size = 512 (0x200) (int) > volume.partition.number = 1 (0x1) (int) > info.capabilities = {'volume', 'block'} (string list) > info.category = 'volume' (string) > volume.is_partition = true (bool) > volume.is_disc = false (bool) > volume.is_mounted = true (bool) > volume.mount_point = '/mnt/hdb' (string) > volume.label = 'd> > > ";' (string) > volume.uuid = '8266-20DC' (string) > volume.fsversion = 'FAT32' (string) > volume.fsusage = 'filesystem' (string) > volume.fstype = 'vfat' (string) > block.storage_device = > '/org/freedesktop/Hal/devices/storage_serial_6EF0CAAP' (string) > block.is_volume = true (bool) > block.minor = 65 (0x41) (int) > block.major = 3 (0x3) (int) > block.device = '/dev/hdb1' (string) > linux.hotplug_type = 3 (0x3) (int) > info.parent = '/org/freedesktop/Hal/devices/storage_serial_6EF0CAAP' > (string) > linux.sysfs_path_device = '/sys/block/hdb/hdb1' (string) > linux.sysfs_path = '/sys/block/hdb/hdb1' (string) > mkfs.vat does format the volume... this would mean that I would loose > all data stored on it. > can I change it without recreate the fs? > seems to be solved after creating backup deleting hdb1 and recreate it... now I am coping back the data... From mike at plan99.net Wed Jun 29 17:07:10 2005 From: mike at plan99.net (Mike Hearn) Date: Wed, 29 Jun 2005 18:07:10 +0100 Subject: C++ compatibility package dropped References: <1119823019.13523.18.camel@md.nc.linuxlobbyist.org> <604aa791050626164735ecd46@mail.gmail.com> <01c101c57b1e$48b16db0$b6491b31@td612671> <1119978674.9285.20.camel@localhost.localdomain> <010f01c57c06$d3285150$b6491b31@td612671> <42C18A42.4010003@redhat.com> Message-ID: On Tue, 28 Jun 2005 23:04:58 +0530, Rahul Sundaram wrote: > Sure. Just file a enhancement against anaconda that the legacy group > should be in the default list. Done: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162069 From hughsient at gmail.com Wed Jun 29 19:53:31 2005 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 29 Jun 2005 20:53:31 +0100 Subject: gnome-pilot patches need applying In-Reply-To: <004b01c57c38$162fa080$4801a8c0@C515816A> References: <004b01c57c38$162fa080$4801a8c0@C515816A> Message-ID: <1120074811.6623.1.camel@localhost.localdomain> On Tue, 2005-06-28 at 18:21 -0500, Otto Haliburton wrote: > > > -----Original Message----- > > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > > bounces at redhat.com] On Behalf Of Rahul Sundaram > > Sent: Tuesday, June 28, 2005 2:13 PM > > To: Development discussions related to Fedora Core > > Subject: Re: gnome-pilot patches need applying > > > > Hi > > > > >Similar. The rawhide patches allow me to sync my palm using gnome-pilot > > >(thanks!) but also delete all my contacts and todo's on my palm! Just a > > >warning for all those of you who don't believe in backups! > > > > > >Richard > > > > > > > > Kindly file a bug report on this. > > > > regards > > Rahul > > > I am not sure this is a error, did you check the settings for your syncing, > whether it was set computer to pda, or pda to computer, it makes a > difference, if it is computer overwrites pda and this is the first time of > use then all data on the pda will be erased with whatever data is on the pc, > the first use should be pda overwrites computer. So there needs to be more > info on what you did. But, having said that it could also be a bug so you > probably need to explain what you did. > Yes, I've tried everything from deleting the pilot stuff in ~/.evolution, hard-reseting the palm, and trying all the different conduit options. There's more info in the bugzilla. Richard. From hughsient at gmail.com Wed Jun 29 19:57:40 2005 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 29 Jun 2005 20:57:40 +0100 Subject: gnome-pilot patches need applying In-Reply-To: <1120003375.31459.10.camel@cassandra.boston.redhat.com> References: <1119892539.3377.7.camel@localhost.localdomain> <1119892681.3030.77.camel@cassandra.boston.redhat.com> <1119892918.4185.0.camel@localhost.localdomain> <1119947221.3720.2.camel@angua.localnet> <1120003375.31459.10.camel@cassandra.boston.redhat.com> Message-ID: <1120075061.6623.7.camel@localhost.localdomain> On Tue, 2005-06-28 at 20:02 -0400, David Malcolm wrote: > I think we made a mistake with this. I'm sorry for the pain this is > causing everybody. n/p :-) > I've been attempting to fix gnome-pilot (and evolution's conduits); > tomorrow's rawhide should have a much better version of both packages, > including numerous patches by Mark G Adams, who is currently my hero. I've just installed: evolution-data-server-1.2.2-4.fc5 evolution-2.2.2-11.fc5 evolution-webcal-2.2.0-1 pilot-link-0.12.0-0.pre4.2 gnome-pilot-conduits-2.0.13-1 gnome-pilot-2.0.13-6.fc5 (i.e. todays rawhide) and I have lots of funnies in gnome-pilot: In the Devices tab I just get the following: Name Port Speed Type USB USB USB USB And similar sort of thing for the Conduit Tab. Not added to bugzilla yet, as you've probably got the same yourself! > I'll report back when I've got more information Cheers! Richard -------------- 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-devel at tlarson.com Wed Jun 29 20:06:46 2005 From: fedora-devel at tlarson.com (Tyler Larson) Date: Wed, 29 Jun 2005 14:06:46 -0600 Subject: default rpm query format on x86_64 In-Reply-To: <42C1EB27.8040904@develer.com> References: <42C16880.8030706@shahms.com> <1119971683.3274.0.camel@cutter> <1119983946.20091.3.camel@weasel> <604aa7910506281145401b4b86@mail.gmail.com> <42C1EB27.8040904@develer.com> Message-ID: <42C2FF56.6040900@tlarson.com> Bernardo Innocenti wrote: > This program was broken already on multiarch platforms because > it would consider an i386 package a candidate for upgrading > an x86_64 package. I've now teached it to consider architectures > instead of stripping them away. Which brings up a good point-- x86_64 systems (and perhaps other multiarch platforms) are becoming much more common, and the trend will only increase. By keeping the arch out of the default query format, we're only encouraging script developers to ignore package architectures. That's bad. It is quite possible that changing the default is the Right Thing to do, and would lead to fewer problems altogether down the road--even though it may force developers to modify their scripts. Perhaps in the process these developers will take a moment to think about how their process would work on a multiarch system. RedHat has a proud history of breaking backward compatibility when the circumstances demand. The negative impact of such this change would probably be minimal and short-lived, and overall I think it would be worth it. However, this sort of change should be made as part of a new release. Best to wait till FC5. From dmalcolm at redhat.com Wed Jun 29 20:07:08 2005 From: dmalcolm at redhat.com (David Malcolm) Date: Wed, 29 Jun 2005 16:07:08 -0400 Subject: gnome-pilot patches need applying In-Reply-To: <1120075061.6623.7.camel@localhost.localdomain> References: <1119892539.3377.7.camel@localhost.localdomain> <1119892681.3030.77.camel@cassandra.boston.redhat.com> <1119892918.4185.0.camel@localhost.localdomain> <1119947221.3720.2.camel@angua.localnet> <1120003375.31459.10.camel@cassandra.boston.redhat.com> <1120075061.6623.7.camel@localhost.localdomain> Message-ID: <1120075629.1824.21.camel@cassandra.boston.redhat.com> On Wed, 2005-06-29 at 20:57 +0100, Richard Hughes wrote: > On Tue, 2005-06-28 at 20:02 -0400, David Malcolm wrote: > > I think we made a mistake with this. I'm sorry for the pain this is > > causing everybody. > > n/p :-) > > > I've been attempting to fix gnome-pilot (and evolution's conduits); > > tomorrow's rawhide should have a much better version of both packages, > > including numerous patches by Mark G Adams, who is currently my hero. > > I've just installed: > > evolution-data-server-1.2.2-4.fc5 > evolution-2.2.2-11.fc5 > evolution-webcal-2.2.0-1 > pilot-link-0.12.0-0.pre4.2 > gnome-pilot-conduits-2.0.13-1 > gnome-pilot-2.0.13-6.fc5 > > (i.e. todays rawhide) and I have lots of funnies in gnome-pilot: > > In the Devices tab I just get the following: > Name Port Speed Type > USB USB USB USB > > And similar sort of thing for the Conduit Tab. Thanks. I'm not seeing that, I'm seeing sane column content. What you report is vaguely reminiscent of this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162001 In particular, see this screenshot: https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=116098 In both cases, every column is being displayed with the final column's content. So I'm wondering if this is a separate, lower level issue with the GtkTreeView... are tree views working for you? Are you seeing the same behaviour as in that bug? From hughsient at gmail.com Wed Jun 29 20:12:47 2005 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 29 Jun 2005 21:12:47 +0100 Subject: gnome-pilot patches need applying In-Reply-To: <1120075629.1824.21.camel@cassandra.boston.redhat.com> References: <1119892539.3377.7.camel@localhost.localdomain> <1119892681.3030.77.camel@cassandra.boston.redhat.com> <1119892918.4185.0.camel@localhost.localdomain> <1119947221.3720.2.camel@angua.localnet> <1120003375.31459.10.camel@cassandra.boston.redhat.com> <1120075061.6623.7.camel@localhost.localdomain> <1120075629.1824.21.camel@cassandra.boston.redhat.com> Message-ID: <1120075967.6623.20.camel@localhost.localdomain> On Wed, 2005-06-29 at 16:07 -0400, David Malcolm wrote: > On Wed, 2005-06-29 at 20:57 +0100, Richard Hughes wrote: > > On Tue, 2005-06-28 at 20:02 -0400, David Malcolm wrote: > > > I think we made a mistake with this. I'm sorry for the pain this is > > > causing everybody. > > > > n/p :-) > > > > > I've been attempting to fix gnome-pilot (and evolution's conduits); > > > tomorrow's rawhide should have a much better version of both packages, > > > including numerous patches by Mark G Adams, who is currently my hero. > > > > I've just installed: > > > > evolution-data-server-1.2.2-4.fc5 > > evolution-2.2.2-11.fc5 > > evolution-webcal-2.2.0-1 > > pilot-link-0.12.0-0.pre4.2 > > gnome-pilot-conduits-2.0.13-1 > > gnome-pilot-2.0.13-6.fc5 > > > > (i.e. todays rawhide) and I have lots of funnies in gnome-pilot: > > > > In the Devices tab I just get the following: > > Name Port Speed Type > > USB USB USB USB > > > > And similar sort of thing for the Conduit Tab. > > Thanks. I'm not seeing that, I'm seeing sane column content. What you > report is vaguely reminiscent of this bug: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162001 > > In particular, see this screenshot: > https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=116098 > > In both cases, every column is being displayed with the final column's > content. > > So I'm wondering if this is a separate, lower level issue with the > GtkTreeView... are tree views working for you? Are you seeing the same > behaviour as in that bug? > Yep, you're right, sorry for the noise. It's in all TreeViews, not just gpilot. Richard. -------------- 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 Wed Jun 29 20:24:40 2005 From: dmalcolm at redhat.com (David Malcolm) Date: Wed, 29 Jun 2005 16:24:40 -0400 Subject: gnome-pilot patches need applying In-Reply-To: <1120075967.6623.20.camel@localhost.localdomain> References: <1119892539.3377.7.camel@localhost.localdomain> <1119892681.3030.77.camel@cassandra.boston.redhat.com> <1119892918.4185.0.camel@localhost.localdomain> <1119947221.3720.2.camel@angua.localnet> <1120003375.31459.10.camel@cassandra.boston.redhat.com> <1120075061.6623.7.camel@localhost.localdomain> <1120075629.1824.21.camel@cassandra.boston.redhat.com> <1120075967.6623.20.camel@localhost.localdomain> Message-ID: <1120076680.1824.29.camel@cassandra.boston.redhat.com> On Wed, 2005-06-29 at 21:12 +0100, Richard Hughes wrote: > On Wed, 2005-06-29 at 16:07 -0400, David Malcolm wrote: > > On Wed, 2005-06-29 at 20:57 +0100, Richard Hughes wrote: > > > On Tue, 2005-06-28 at 20:02 -0400, David Malcolm wrote: > > > > I think we made a mistake with this. I'm sorry for the pain this is > > > > causing everybody. > > > > > > n/p :-) > > > > > > > I've been attempting to fix gnome-pilot (and evolution's conduits); > > > > tomorrow's rawhide should have a much better version of both packages, > > > > including numerous patches by Mark G Adams, who is currently my hero. > > > > > > I've just installed: > > > > > > evolution-data-server-1.2.2-4.fc5 > > > evolution-2.2.2-11.fc5 > > > evolution-webcal-2.2.0-1 > > > pilot-link-0.12.0-0.pre4.2 > > > gnome-pilot-conduits-2.0.13-1 > > > gnome-pilot-2.0.13-6.fc5 > > > > > > (i.e. todays rawhide) and I have lots of funnies in gnome-pilot: > > > > > > In the Devices tab I just get the following: > > > Name Port Speed Type > > > USB USB USB USB > > > > > > And similar sort of thing for the Conduit Tab. > > > > Thanks. I'm not seeing that, I'm seeing sane column content. What you > > report is vaguely reminiscent of this bug: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162001 > > > > In particular, see this screenshot: > > https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=116098 > > > > In both cases, every column is being displayed with the final column's > > content. > > > > So I'm wondering if this is a separate, lower level issue with the > > GtkTreeView... are tree views working for you? Are you seeing the same > > behaviour as in that bug? > > > > Yep, you're right, sorry for the noise. It's in all TreeViews, not just > gpilot. > Thanks - that's useful information. I've commented on and changed the component of that bug to gtk2 accordingly. So apart from that problem, how well is rawhide gnome-pilot working for you? For me, with a USB pilot it picks up on a sync about 50% of the time (possibly the timing issues suggested by Nigel Metheringham), and when it does, the UI appears and appears to run the conduits correctly. Backing up appears to work, but synchronization doesn't seem to be actually synchronizing - only calendars seem to sync OK. From hughsient at gmail.com Wed Jun 29 21:17:31 2005 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 29 Jun 2005 22:17:31 +0100 Subject: gnome-pilot patches need applying In-Reply-To: <1120076680.1824.29.camel@cassandra.boston.redhat.com> References: <1119892539.3377.7.camel@localhost.localdomain> <1119892681.3030.77.camel@cassandra.boston.redhat.com> <1119892918.4185.0.camel@localhost.localdomain> <1119947221.3720.2.camel@angua.localnet> <1120003375.31459.10.camel@cassandra.boston.redhat.com> <1120075061.6623.7.camel@localhost.localdomain> <1120075629.1824.21.camel@cassandra.boston.redhat.com> <1120075967.6623.20.camel@localhost.localdomain> <1120076680.1824.29.camel@cassandra.boston.redhat.com> Message-ID: <1120079851.5427.4.camel@localhost.localdomain> On Wed, 2005-06-29 at 16:24 -0400, David Malcolm wrote: > > Yep, you're right, sorry for the noise. It's in all TreeViews, not just > > gpilot. > > > > Thanks - that's useful information. I've commented on and changed the > component of that bug to gtk2 accordingly. > > So apart from that problem, how well is rawhide gnome-pilot working for > you? For me, with a USB pilot it picks up on a sync about 50% of the > time (possibly the timing issues suggested by Nigel Metheringham), and > when it does, the UI appears and appears to run the conduits correctly. > Backing up appears to work, but synchronization doesn't seem to be > actually synchronizing - only calendars seem to sync OK. Well, it gets to sync's pretty much every time - except it seems to delete all the data on my palm, i.e. it seems to /move/ the data to evolution as a one way transfer! Using pilot-link directly seems to work okay, but I think some of the API porting has broken jpilot, as that doesn't seem to work anymore. Anyway, gpilotd seems much happier (i.e. it does something, but I think we need to nail the deleting issue) before an updates-released is released. What about putting versions in updates-testing so that less-brave-than-rawhide people can try out gnome-pilot? Richard. -------------- 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 bernie at develer.com Wed Jun 29 22:54:12 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Thu, 30 Jun 2005 00:54:12 +0200 Subject: default rpm query format on x86_64 In-Reply-To: <42C2FF56.6040900@tlarson.com> References: <42C16880.8030706@shahms.com> <1119971683.3274.0.camel@cutter> <1119983946.20091.3.camel@weasel> <604aa7910506281145401b4b86@mail.gmail.com> <42C1EB27.8040904@develer.com> <42C2FF56.6040900@tlarson.com> Message-ID: <42C32694.40404@develer.com> Tyler Larson wrote: > Bernardo Innocenti wrote: > >> This program was broken already on multiarch platforms because >> it would consider an i386 package a candidate for upgrading >> an x86_64 package. I've now teached it to consider architectures >> instead of stripping them away. > > > Which brings up a good point-- > x86_64 systems (and perhaps other multiarch platforms) are becoming much > more common, and the trend will only increase. By keeping the arch out > of the default query format, we're only encouraging script developers to > ignore package architectures. That's bad. Agreed. > It is quite possible that changing the default is the Right Thing to do, > and would lead to fewer problems altogether down the road--even though > it may force developers to modify their scripts. Perhaps in the process > these developers will take a moment to think about how their process > would work on a multiarch system. The easy fix requires a one-line change to specify the query format. My script required more work because it really needed to consider the architecture when comparing packages. > RedHat has a proud history of breaking backward compatibility when the > circumstances demand. The negative impact of such this change would > probably be minimal and short-lived, and overall I think it would be > worth it. However, this sort of change should be made as part of a new > release. Best to wait till FC5. I also hope FC5 will introduce the ability to upgrade an i386 system to x86_64. I did it manually for my workstation and it required just a single reboot to install the 64bit kernel. Everything else I could do by forcing RPM to do what I meant despite I was apparently breaking dependencies and installing conflicting files. Now my migration to 64bit is 90% complete. I sometimes find yet another i386 package I forgot to upgrade. Finding them all is difficult because they still work fine :-) -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From rodd at clarkson.id.au Thu Jun 30 01:42:03 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Thu, 30 Jun 2005 11:42:03 +1000 Subject: gnome-pilot patches need applying In-Reply-To: <1120076680.1824.29.camel@cassandra.boston.redhat.com> References: <1119892539.3377.7.camel@localhost.localdomain> <1119892681.3030.77.camel@cassandra.boston.redhat.com> <1119892918.4185.0.camel@localhost.localdomain> <1119947221.3720.2.camel@angua.localnet> <1120003375.31459.10.camel@cassandra.boston.redhat.com> <1120075061.6623.7.camel@localhost.localdomain> <1120075629.1824.21.camel@cassandra.boston.redhat.com> <1120075967.6623.20.camel@localhost.localdomain> <1120076680.1824.29.camel@cassandra.boston.redhat.com> Message-ID: <1120095724.3295.14.camel@jellyfish.redfishdemo.com> > > > So I'm wondering if this is a separate, lower level issue with the > > > GtkTreeView... are tree views working for you? Are you seeing the same > > > behaviour as in that bug? > > > > > > > Yep, you're right, sorry for the noise. It's in all TreeViews, not just > > gpilot. > > > > Thanks - that's useful information. I've commented on and changed the > component of that bug to gtk2 accordingly. See also: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162001 Rodd -- "It's a fine line between denial and faith. It's much better on my side" From shiva at sewingwitch.com Thu Jun 30 04:23:19 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Wed, 29 Jun 2005 21:23:19 -0700 Subject: Packaging kernel modules Message-ID: <4820AB25719EA12BF80DD8DC@[10.169.6.233]> I'm figuring out how to install nosy, a Firewire sniffer, and it involves installing a kernel module. I'd like to wrap up what I learn in an RPM. I've packaged apps before but not kernel modules. Can anyone point me to an example that shows the preferred way to do it? The Makefile is already set up for building outside the kernel tree, and accepts a prefix for /usr. Will that work fine for building within an RPM_BUILD_ROOT? (Ie. does the kernel build system tolerate logical installation directories?) Do I invoke depmod in %post as I would ldconfig when installing a userspace library? From dan.track at gmail.com Thu Jun 30 08:43:41 2005 From: dan.track at gmail.com (Dan Track) Date: Thu, 30 Jun 2005 09:43:41 +0100 Subject: domu boot up issue Message-ID: <9d5ddd1f0506300143354d21e3@mail.gmail.com> I'm getting the following error message in when booting rhel 3 es (similar to redhat 9) as a domu under fc4 as a dom0. can anyone please help me to figure it out? Total HugeTLB memory allocated, 0 VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) SELinux: Registering netfilter hooks Initializing Cryptographic API ksign: Installing public key data Loading keyring - Added public key 42BD35A990375F72 - User ID: Red Hat, Inc. (Kernel Module GPG key) vesafb: abort, cannot reserve video memory at 0x0 vesafb: abort, cannot ioremap video memory 0x0 @ 0x0 Trying to free nonexistent resource <00000000-ffffffff> vesafb: probe of vesafb.0 failed with error -5 isapnp: Scanning for PnP cards... isapnp: No Plug & Play device found Failed to obtain physical IRQ 8 Real Time Clock Driver v1.12 Linux agpgart interface v0.101 (c) Dave Jones PNP: No PS/2 controller found. Probing ports directly. i8042.c: No controller found. Unable to handle kernel NULL pointer dereference at virtual address 00000078 printing eip: c01aed96 *pde = ma 00000000 pa 55555000 [] force_evtchn_callback+0xa/0x10 [] module_remove_driver+0x1f/0x30 [] bus_remove_driver+0x7f/0xc0 [] driver_unregister+0x10/0x20 [] i8042_pnp_exit+0x3c/0x40 [] i8042_init+0x18c/0x1c0 [] serio_init+0x6 My config is: kernel ="/boot/vmlinuz-2.6.11-1.1369_FC4xen0" memory = 400 name = "rhel-3-es" nics = 1 disk = ['phy:cciss/c0d0p2,sda1,w'] root = "/dev/sda1 ro and my /etc/fstab in the domu is: /dev/sda1 / ext3 defaults 1 1 none /dev/pts devpts gid=5,mode=620 0 0 none /proc proc defaults 0 0 none /dev/shm tmpfs defaults 0 0 /dev/cciss/c0d0p6 swap swap defaults 0 0 Thanks Dan From rodd at clarkson.id.au Thu Jun 30 10:26:44 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Thu, 30 Jun 2005 20:26:44 +1000 Subject: gnome-pilot patches need applying In-Reply-To: <1120095724.3295.14.camel@jellyfish.redfishdemo.com> References: <1119892539.3377.7.camel@localhost.localdomain> <1119892681.3030.77.camel@cassandra.boston.redhat.com> <1119892918.4185.0.camel@localhost.localdomain> <1119947221.3720.2.camel@angua.localnet> <1120003375.31459.10.camel@cassandra.boston.redhat.com> <1120075061.6623.7.camel@localhost.localdomain> <1120075629.1824.21.camel@cassandra.boston.redhat.com> <1120075967.6623.20.camel@localhost.localdomain> <1120076680.1824.29.camel@cassandra.boston.redhat.com> <1120095724.3295.14.camel@jellyfish.redfishdemo.com> Message-ID: <1120127205.3307.1.camel@goose> > See also: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162001 > > > Rodd Damn, do I feel stupid, that's the same bug report that was mentioned earlier in my thread. Rodd -- "It's a fine line between denial and faith. It's much better on my side" From buildsys at redhat.com Thu Jun 30 11:25:56 2005 From: buildsys at redhat.com (Build System) Date: Thu, 30 Jun 2005 07:25:56 -0400 Subject: rawhide report: 20050630 changes Message-ID: <200506301125.j5UBPuJ0024242@porkchop.devel.redhat.com> New package dtdparser A Java DTD Parser New package objectweb-deploysched ObjectWeb scheduling framework Updated Packages: NetworkManager-0.4-33.cvs20050629 --------------------------------- * Wed Jun 29 2005 David Zeuthen - 0.4-33.cvs20050629 - Update to latest CVS to get latest VPN interface settings to satisfy BuildReq for NetworkManager-vpnc in Fedora Extras Development - Latest CVS also contains various bug- and UI-fixes * Fri Jun 17 2005 Dan Williams - 0.4-32.cvs20050617 - Update to latest CVS o VPN connection import/export capability o Fix up some menu item names - Move nm-vpn-properties.glade to the gnome subpackage * Thu Jun 16 2005 Dan Williams - 0.4-31.cvs20050616 - Update to latest CVS o Clean up wording in Wireless Network Discovery menu o Robert Love's applet beautify patch anaconda-10.3.0.3-1 ------------------- * Wed Jun 29 2005 Chris Lumens 10.3.0.3-1 - Mount "auto" filesystems on upgrade (#160986). - Add cairo for new pango/gtk (katzj). - Delete labels on swap and ext3 partitions before formatting. - Remove langsupport keyword from kickstart. binutils-2.15.94.0.2.2-2.1 -------------------------- * Wed Jun 29 2005 Jakub Jelinek 2.15.94.0.2.2-2.1 - further bfd, readelf and binutils robustification (CAN-2005-1704, #158680) gail-1.8.4-1 ------------ * Tue Jun 28 2005 Matthias Clasen 1.8.4-1 - Update to 1.8.4 geronimo-specs-0:1.0-0.M2.2jpp_3fc ---------------------------------- * Wed Jun 29 2005 Gary Benson 0:1.0-0.M2.2jpp_3fc - Add dependency on the main package to the compatibility subpackage. hplip-0.9.3-7 ------------- * Thu Jun 30 2005 Tim Waugh 0.9.3-7 - Rebuild to get Python modules precompiled. kde-i18n-1:3.4.1-1 ------------------ * Wed Jun 29 2005 Than Ngo 1:3.4.1-1 - 3.4.1 * Thu Mar 03 2005 Than Ngo 1:3.4.0-0.rc1.2 - fix build problem * Tue Mar 01 2005 Than Ngo 1:3.4.0-0.rc1.1 - 3.4.0 rc1 kdeutils-6:3.4.1-1 ------------------ * Thu Jun 16 2005 Than Ngo 6:3.4.1-1 - 3.4.1 * Fri Mar 18 2005 Than Ngo 6:3.4.0-1 - 3.4.0 * Fri Mar 04 2005 Than Ngo 6:3.4.0-0.rc1.2 - rebuilt against gcc-4.0.0-0.31 kdevelop-9:3.2.1-1 ------------------ * Wed Jun 29 2005 Than Ngo 9:3.2.1-1 - 3.2.1 - fix gcc4 build problem * Wed Apr 13 2005 Than Ngo 9:3.2.0-2 - fix wrong qtdoc path * Fri Mar 18 2005 Than Ngo 9:3.2.0-1 - 3.2.0 kdewebdev-6:3.4.1-1 ------------------- * Wed Jun 29 2005 Than Ngo 6:3.4.1-1 - 3.4.1 - fix gcc4 build problem * Wed May 04 2005 Than Ngo 6:3.4.0-3 - apply patch to fix CAN-2005-0754, Kommander untrusted code execution, thanks to KDE security team * Tue Apr 19 2005 Than Ngo 6:3.4.0-2 - add kdesdk in buildrequires #155054 lftp-3.2.1-1 ------------ * Thu Jun 30 2005 Warren Togami 3.2.1-1 - 3.2.1 libselinux-1.24.1-1 ------------------- * Wed Jun 29 2005 Dan Walsh 1.24.1-1 - Update from NSA * Merged security_setupns() from Chad Sellers. - fix selinuxenabled man page libsepol-1.6-1 -------------- * Wed Jun 29 2005 Dan Walsh 1.6-1 - Upgrade to latest from NSA * Updated version for release. libtiff-3.7.2-1 --------------- * Wed Jun 29 2005 Matthias Clasen - 3.7.2-1 - Update to 3.7.2 - Drop upstreamed patches logwatch-6.1.2-2 ---------------- * Wed Jun 29 2005 Ivana Varekova 6.1.2-2 - fix bug 161973 - The logwatch yum service doesn't properly show removed entries - used patch created by Dean Earley (patch5) monolog-0:1.8.6-1jpp_4fc ------------------------ * Wed Jun 29 2005 Gary Benson 0:1.8.6-1jpp_4fc - Also build ow_util_io.jar, as required by medor. nautilus-cd-burner-2.8.3-6 -------------------------- * Wed Oct 20 2004 Alexander Larsson - 2.8.3-6 - Make user own the dirs in burn:/// (#135151) * Tue Oct 12 2004 Alexander Larsson - 2.8.3-5 - Make unmount patch slighly better * Fri Oct 08 2004 Alexander Larsson - 2.8.3-4 - Add patch to unmount if needed (#107544) openoffice.org-1:1.9.112-2.2.0.fc5 ---------------------------------- * Wed Jun 29 2005 Caolan McNamara - 1:1.9.112-2 - wrong userdir - allow fallbacks for translations with partial support file coverage - rh#160301# tweak fontconfig patch to ignore opensymbol/starsymbol openssh-4.1p1-3 --------------- * Wed Jun 29 2005 Tomas Mraz 4.1p1-3 - fix small regression caused by the nologin patch (#161956) - fix race in getpeername error checking (mindrot #1054) policycoreutils-1.24-1 ---------------------- * Wed Jun 29 2005 Dan Walsh 1.24-1 - Update to match NSA * Updated version for release. * Tue Jun 14 2005 Dan Walsh 1.23.11-4 - Fix Ivan's patch for user role changes rdesktop-1.4.1-1.fc5 -------------------- * Thu Jun 30 2005 Warren Togami - 1.4.1-1 - 1.4.1 selinux-policy-strict-1.24-1 ---------------------------- * Wed Jun 29 2005 Dan Walsh 1.24-1 - Upgrade from NSA * Updated version for release. * Mon Jun 27 2005 Dan Walsh 1.23.18-22 - Add additional http ports - Force make reload when sourses installed selinux-policy-targeted-1.24-1 ------------------------------ * Wed Jun 29 2005 Dan Walsh 1.24-1 - Upgrade from NSA * Updated version for release. * Mon Jun 27 2005 Dan Walsh 1.23.18-22 - Add additional http ports - Force make reload when sourses installed setarch-1.8-1 ------------- * Thu Jun 30 2005 Jindrich Novy 1.8-1 - fix possible segfault when parsing unknown arguments (#161975) - print wanings when unknown arguments are passed - add FDPIC_FUNCPTRS personality system-config-display-1.0.30-2 ------------------------------ * Wed Jun 29 2005 Soren Sandmann 1.0.30-2 - Build * Mon Jun 27 2005 Soren Sandmann 1.0.30-1 - Add ppc64 to ExcludeArchs totem-1.1.2-1 ------------- * Wed Jun 29 2005 John (J5) Palmieri - 1.1.2-1 - Update to upstream version 1.1.2 vsftpd-2.0.3-6 -------------- * Thu Jun 30 2005 Radek Vokal 2.0.3-6 - start in background as default, init script changed (#158714) Broken deps for ia64 ---------------------------------------------------------- xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 p6spy - 1.3-2jpp_1fc.noarch requires regexp geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper bcel - 5.1-1jpp_4fc.noarch requires regexp jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging rgmanager - 1.9.31-3.ia64 requires ccs jonas - 4.3.3-1jpp_3fc.noarch requires xerces-j2 >= 0:2.6.2 jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_3fc.noarch requires carol = 0:1.8.9.3 jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30 jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-el jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_3fc.noarch requires xml-commons-apis >= 0:1.0 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_3fc.noarch requires jasper5 jonas - 4.3.3-1jpp_3fc.noarch requires regexp xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet xml-commons-resolver - 1.1-1jpp_5fc.noarch requires jaxp_parser_impl xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis log4j - 1.2.8-7jpp_5fc.noarch requires jaxp_parser_impl velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 jgroups - 2.2.6-1jpp_1fc.noarch requires jaxp_parser_impl jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 xalan-j2 - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging joram - 4.1.5-1jpp_2fc.noarch requires jmxri joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2 joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_2fc.noarch requires regexp joram - 4.1.5-1jpp_2fc.noarch requires jta jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 wsdl4j - 1.5.1-1jpp_1fc.noarch requires jaxp_parser_impl wsdl4j - 1.5.1-1jpp_1fc.noarch requires java avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis jessie - 1.0.0-8.noarch requires java >= 0:1.4 castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2 castor - 0.9.5-1jpp_1fc.noarch requires regexp castor - 0.9.5-1jpp_1fc.noarch requires jta Broken deps for s390 ---------------------------------------------------------- castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2 castor - 0.9.5-1jpp_1fc.noarch requires regexp castor - 0.9.5-1jpp_1fc.noarch requires jta hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11 selinux-policy-targeted-sources - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219 velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections jessie - 1.0.0-8.noarch requires java >= 0:1.4 jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390 requires libnautilus-burn.so.1 quota - 1:3.12-6.s390 requires kernel >= 0:2.4 jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 jgroups - 2.2.6-1jpp_1fc.noarch requires jaxp_parser_impl jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging initscripts - 8.11.1-1.s390 requires kernel >= 0:2.6 java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj xml-commons-resolver - 1.1-1jpp_5fc.noarch requires jaxp_parser_impl xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging prelink - 0.3.5-1.s390 requires kernel >= 0:2.4.10 bcel - 5.1-1jpp_4fc.noarch requires regexp jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 selinux-policy-strict-sources - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219 axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis log4j - 1.2.8-7jpp_5fc.noarch requires jaxp_parser_impl avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet joram - 4.1.5-1jpp_2fc.noarch requires jmxri joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2 joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_2fc.noarch requires regexp joram - 4.1.5-1jpp_2fc.noarch requires jta nautilus-cd-burner - 2.8.3-6.s390 requires libdbus-1.so.0 nautilus-cd-burner - 2.8.3-6.s390 requires libhal.so.0 libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0 lvm2 - 2.01.12-1.0.s390 requires kernel >= 0:2.6 jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging nfs-utils - 1.0.7-8.s390 requires kernel >= 0:2.2.14 xalan-j2 - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl p6spy - 1.3-2jpp_1fc.noarch requires regexp dhcp - 10:3.0.2-14.s390 requires kernel >= 0:2.2.18 xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 sound-juicer - 0.5.14-1.FC3.0.s390 requires libdbus-1.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libhal.so.0 sound-juicer - 0.5.14-1.FC3.0.s390 requires libmusicbrainz.so.2 xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 sysstat - 5.0.5-10.fc.s390 requires kernel >= 0:2.2.16-21 wsdl4j - 1.5.1-1jpp_1fc.noarch requires jaxp_parser_impl wsdl4j - 1.5.1-1jpp_1fc.noarch requires java selinux-policy-strict - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219 jonas - 4.3.3-1jpp_3fc.noarch requires xerces-j2 >= 0:2.6.2 jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_3fc.noarch requires carol = 0:1.8.9.3 jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30 jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-el jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_3fc.noarch requires xml-commons-apis >= 0:1.0 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_3fc.noarch requires jasper5 jonas - 4.3.3-1jpp_3fc.noarch requires regexp gkrellm - 2.2.7-1.s390 requires kernel >= 0:2.6.2 xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging selinux-policy-targeted - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219 arptables_jf - 0.0.8-5.s390 requires kernel >= 0:2.4.0 Broken deps for s390x ---------------------------------------------------------- joram - 4.1.5-1jpp_2fc.noarch requires jmxri joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2 joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_2fc.noarch requires regexp joram - 4.1.5-1jpp_2fc.noarch requires jta p6spy - 1.3-2jpp_1fc.noarch requires regexp jgroups - 2.2.6-1jpp_1fc.noarch requires jaxp_parser_impl jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 hal - 0.5.2-2.s390x requires kernel >= 0:2.6.11 sysstat - 5.0.5-10.fc.s390x requires kernel >= 0:2.2.16-21 selinux-policy-strict - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219 bcel - 5.1-1jpp_4fc.noarch requires regexp jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper hal - 0.5.2-2.s390 requires kernel >= 0:2.6.11 jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis gkrellm - 2.2.7-1.s390x requires kernel >= 0:2.6.2 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 lvm2 - 2.01.12-1.0.s390x requires kernel >= 0:2.6 initscripts - 8.11.1-1.s390x requires kernel >= 0:2.6 selinux-policy-targeted - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219 avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet jessie - 1.0.0-8.noarch requires java >= 0:1.4 axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java libpcap - 14:0.8.3-14.s390x requires kernel >= 0:2.2.0 castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2 castor - 0.9.5-1jpp_1fc.noarch requires regexp castor - 0.9.5-1jpp_1fc.noarch requires jta sound-juicer - 0.5.14-1.FC3.0.s390x requires libdbus-1.so.0()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libmusicbrainz.so.2()(64bit) sound-juicer - 0.5.14-1.FC3.0.s390x requires libhal.so.0()(64bit) selinux-policy-strict-sources - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219 xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet jonas - 4.3.3-1jpp_3fc.noarch requires xerces-j2 >= 0:2.6.2 jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_3fc.noarch requires carol = 0:1.8.9.3 jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30 jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-el jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_3fc.noarch requires xml-commons-apis >= 0:1.0 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_3fc.noarch requires jasper5 jonas - 4.3.3-1jpp_3fc.noarch requires regexp xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging nfs-utils - 1.0.7-8.s390x requires kernel >= 0:2.2.14 libpcap - 14:0.8.3-14.s390 requires kernel >= 0:2.2.0 xml-commons-resolver - 1.1-1jpp_5fc.noarch requires jaxp_parser_impl xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis log4j - 1.2.8-7jpp_5fc.noarch requires jaxp_parser_impl prelink - 0.3.5-1.s390x requires kernel >= 0:2.4.10 xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 nautilus-cd-burner - 2.8.3-6.s390x requires libdbus-1.so.0()(64bit) nautilus-cd-burner - 2.8.3-6.s390x requires libhal.so.0()(64bit) gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires nautilus-cd-burner >= 0:2.9.4 gnome-python2-nautilus-cd-burner - 2.10.0-2.1.s390x requires libnautilus-burn.so.1()(64bit) arptables_jf - 0.0.8-5.s390x requires kernel >= 0:2.4.0 xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 quota - 1:3.12-6.s390x requires kernel >= 0:2.4 selinux-policy-targeted-sources - 1.24-1.noarch requires kernel >= 0:2.6.11-1.1219 dhcp - 10:3.0.2-14.s390x requires kernel >= 0:2.2.18 xalan-j2 - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl wsdl4j - 1.5.1-1jpp_1fc.noarch requires jaxp_parser_impl wsdl4j - 1.5.1-1jpp_1fc.noarch requires java java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj Broken deps for ppc64 ---------------------------------------------------------- jonas - 4.3.3-1jpp_3fc.noarch requires xerces-j2 >= 0:2.6.2 jonas - 4.3.3-1jpp_3fc.noarch requires ant >= 0:1.6.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-beanutils >= 0:1.7.0 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-logging >= 0:1.0.4 jonas - 4.3.3-1jpp_3fc.noarch requires servletapi5 jonas - 4.3.3-1jpp_3fc.noarch requires carol = 0:1.8.9.3 jonas - 4.3.3-1jpp_3fc.noarch requires jta >= 0:1.0.1 jonas - 4.3.3-1jpp_3fc.noarch requires struts >= 0:1.2.4 jonas - 4.3.3-1jpp_3fc.noarch requires tomcat5 >= 0:5.0.30 jonas - 4.3.3-1jpp_3fc.noarch requires mx4j >= 1:3.0.1-1jpp_2fc jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-el jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-digester >= 0:1.6 jonas - 4.3.3-1jpp_3fc.noarch requires xml-commons-apis >= 0:1.0 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-collections >= 0:3.1 jonas - 4.3.3-1jpp_3fc.noarch requires java >= 0:1.4.2 jonas - 4.3.3-1jpp_3fc.noarch requires jakarta-commons-modeler >= 0:1.1 jonas - 4.3.3-1jpp_3fc.noarch requires jasper5 jonas - 4.3.3-1jpp_3fc.noarch requires regexp xml-commons-resolver - 1.1-1jpp_5fc.noarch requires jaxp_parser_impl xml-commons-resolver - 1.1-1jpp_5fc.noarch requires xml-commons-apis xalan-j2-demo - 2.6.0-2jpp_1fc.noarch requires servlet geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires servletapi5 geronimo-specs - 1.0-0.M2.2jpp_1fc.noarch requires mx4j >= 0:2.0.1 bcel - 5.1-1jpp_4fc.noarch requires regexp castor-demo - 0.9.5-1jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires servletapi5 velocity - 1.4-3jpp_1fc.noarch requires jakarta-commons-collections axis - 1.2.1-1jpp_1fc.noarch requires jakarta-commons-logging axis - 1.2.1-1jpp_1fc.noarch requires java avalon-framework - 4.1.4-2jpp_5fc.noarch requires xml-commons-apis jakarta-commons-pool - 1.2-2jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 rhpl - 0.167-1.ppc64 requires pyxf86config >= 0:0.3.2 xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-collections xjavadoc - 1.1-1jpp_1fc.noarch requires xml-commons-apis xjavadoc - 1.1-1jpp_1fc.noarch requires jakarta-commons-logging joram - 4.1.5-1jpp_2fc.noarch requires jmxri joram - 4.1.5-1jpp_2fc.noarch requires xerces-j2 joram - 4.1.5-1jpp_2fc.noarch requires java >= 0:1.4 joram - 4.1.5-1jpp_2fc.noarch requires regexp joram - 4.1.5-1jpp_2fc.noarch requires jta wsdl4j - 1.5.1-1jpp_1fc.noarch requires jaxp_parser_impl wsdl4j - 1.5.1-1jpp_1fc.noarch requires java ppc64-utils - 0.7-9.ppc64 requires yaboot system-config-mouse - 1.2.11-1.noarch requires pyxf86config system-config-keyboard - 1.2.6-2.noarch requires pyxf86config jakarta-commons-dbcp - 1.2.1-3jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.0 jakarta-commons-cli - 1.0-6jpp_1fc.noarch requires jakarta-commons-logging firstboot - 1.3.42-1.noarch requires system-config-display avalon-logkit - 1.2-2jpp_4fc.noarch requires servlet gnomemeeting - 1.0.2-8.ppc64 requires libpt.so.1.6.5()(64bit) gnomemeeting - 1.0.2-8.ppc64 requires libh323_linux_ppc64_r.so.1.13.4()(64bit) jakarta-commons-fileupload - 1:1.0-3jpp_1fc.noarch requires servletapi5 log4j - 1.2.8-7jpp_5fc.noarch requires xml-commons-apis log4j - 1.2.8-7jpp_5fc.noarch requires jaxp_parser_impl xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl xalan-j2-xsltc - 2.6.0-2jpp_1fc.noarch requires regexp jakarta-commons-discovery - 1:0.3-1jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.1 java-1.4.2-gcj-compat-devel - 1.4.2.0-11jpp.noarch requires ecj jakarta-commons-httpclient - 1:3.0-0.rc2.0jpp_1fc.noarch requires jakarta-commons-logging >= 0:1.0.3 p6spy - 1.3-2jpp_1fc.noarch requires regexp hsqldb - 1.73.0-2jpp_1fc.noarch requires servletapi5 xdoclet - 1.2.2-2jpp_1fc.noarch requires xml-commons-apis xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-collections xdoclet - 1.2.2-2jpp_1fc.noarch requires jakarta-commons-logging jessie - 1.0.0-8.noarch requires java >= 0:1.4 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-logging >= 0:1.0.2 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires xml-commons-apis jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-beanutils >= 0:1.5 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-collections >= 0:2.1 jakarta-commons-validator - 1.1.3-1jpp_2fc.noarch requires jakarta-commons-digester >= 0:1.3 xalan-j2 - 2.6.0-2jpp_1fc.noarch requires jaxp_parser_impl jakarta-taglibs-standard - 1.1.1-4jpp_1fc.noarch requires servletapi5 >= 0:5.0.16 jgroups - 2.2.6-1jpp_1fc.noarch requires jaxp_parser_impl jgroups - 2.2.6-1jpp_1fc.noarch requires jakarta-commons-logging castor - 0.9.5-1jpp_1fc.noarch requires xerces-j2 castor - 0.9.5-1jpp_1fc.noarch requires regexp castor - 0.9.5-1jpp_1fc.noarch requires jta jacorb - 2.2-3jpp_1fc.noarch requires tanukiwrapper From j.w.r.degoede at hhs.nl Thu Jun 30 12:23:45 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 30 Jun 2005 14:23:45 +0200 Subject: motherboard autodetect and autoconfig of motherbord specific stuff Message-ID: <42C3E451.5040505@hhs.nl> Hi all, Lately I've run into some stuff wich needs tweaking to get it 100% which is motherboard dependend. Things which (may need) motherboard specific tweaks are: -lm_sensors -xorg.conf for mainbords with builtin graphics (Option "VBERestore" "true" for i810 for example) So now I'm thinking about creating somekinda hwautodetect and autoconfig architecture and program for this. Questions: -good/bad idea? -anyone willing to help? -how can one detect the exact mainboard (Producer, type, rev)? Ideas: -memmap the bios, checksum it -memmap the bios get identifier string, match to a regex -combine the above with PCI id matching for chipset (extra check) -which motherboardspecific settings can be benefitial? So far I have: -lm_sensors -xorg.conf for mainbords with builtin graphics (Option "VBERestore" "true" for i810 for example) -onboard sound tweaks?? -what database backend to use? preferably one which is already required by the core of most distros (This is primarily targeted at Fedora, but I would like to make it distro independent if possible) -what is a good implementation language for this? I'm thinking about a C-python mix, C for the detection, python for the rest. Regards, Hans From terry1 at beam.ltd.uk Thu Jun 30 12:59:37 2005 From: terry1 at beam.ltd.uk (Terry Barnaby) Date: Thu, 30 Jun 2005 13:59:37 +0100 Subject: Problem with busybox based initrd: umount of initrd hangs system Message-ID: <42C3ECB9.30409@beam.ltd.uk> Hi, I am building a custom initrd for booting a Fedora 3 based system. In general all is working fine, except that when I try an umount the initrd after boot has suceeded the system hangs with no error messages. I have created a cpio based initrd using busybox. A simplified version of the "init" script is attched. This finishes with running /bin/sh on the hard disk mounted file system. If I try and run "umount /initrd1" the system hangs. The system is booted using PXE based network boot using pxelinux 3.0.9. I am using busybox-1.00. The kernel is Fedora3's version 2.6.11-1.35_FC3smp. Any Ideas ?? Terry -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: init URL: From dan.track at gmail.com Thu Jun 30 14:38:43 2005 From: dan.track at gmail.com (Dan Track) Date: Thu, 30 Jun 2005 15:38:43 +0100 Subject: Has anyone got rhel3 running under fc4 as a domu Message-ID: <9d5ddd1f05063007381ffee524@mail.gmail.com> Hi, I'm looking for someone who can help me get rhel3 running under fc4 as a domU. Can someone help me please. Thanks, Dan From bob.deblier at telenet.be Thu Jun 30 14:48:07 2005 From: bob.deblier at telenet.be (Bob Deblier) Date: Thu, 30 Jun 2005 16:48:07 +0200 Subject: Has anyone got rhel3 running under fc4 as a domu In-Reply-To: <9d5ddd1f05063007381ffee524@mail.gmail.com> References: <9d5ddd1f05063007381ffee524@mail.gmail.com> Message-ID: <1120142887.10079.6.camel@orion> On Thu, 2005-06-30 at 15:38 +0100, Dan Track wrote: > Hi, > > I'm looking for someone who can help me get rhel3 running under fc4 as a domU. Since nobody seems to answering: I'm not a Xen expert, but I recall that you need a specially compiled kernel, which plays nice with the hypervisor. Are you using a vanilla rhel3 kernel, or a version modified to work with Xen? Bob From dan.track at gmail.com Thu Jun 30 15:01:46 2005 From: dan.track at gmail.com (Dan Track) Date: Thu, 30 Jun 2005 16:01:46 +0100 Subject: Has anyone got rhel3 running under fc4 as a domu In-Reply-To: <1120142887.10079.6.camel@orion> References: <9d5ddd1f05063007381ffee524@mail.gmail.com> <1120142887.10079.6.camel@orion> Message-ID: <9d5ddd1f0506300801312c2d04@mail.gmail.com> Hi Thanks for the reply. I've been banging my head againstg this for two days now. I'm using FC4 kernel: 2.6.11-1.1369_FC4xen0 rhel3 is the standard kernel available on redhat. I had all this working under fc4_test1 without any problems. When FC4 came out I couldn't get it to work. I've tried all of the MAKEDEV commands but it still doesn't work. The strange thing is that rhel4 does work under FC4 as a domU. Any ideas. I'm really desparate for some. Many Thanks Dan On 6/30/05, Bob Deblier wrote: > On Thu, 2005-06-30 at 15:38 +0100, Dan Track wrote: > > Hi, > > > > I'm looking for someone who can help me get rhel3 running under fc4 as a domU. > > Since nobody seems to answering: I'm not a Xen expert, but I recall that > you need a specially compiled kernel, which plays nice with the > hypervisor. > > Are you using a vanilla rhel3 kernel, or a version modified to work with > Xen? > > Bob > > > From veillard at redhat.com Thu Jun 30 16:01:56 2005 From: veillard at redhat.com (Daniel Veillard) Date: Thu, 30 Jun 2005 12:01:56 -0400 Subject: Has anyone got rhel3 running under fc4 as a domu In-Reply-To: <9d5ddd1f0506300801312c2d04@mail.gmail.com> References: <9d5ddd1f05063007381ffee524@mail.gmail.com> <1120142887.10079.6.camel@orion> <9d5ddd1f0506300801312c2d04@mail.gmail.com> Message-ID: <20050630160155.GP14660@redhat.com> On Thu, Jun 30, 2005 at 04:01:46PM +0100, Dan Track wrote: > Hi > > Thanks for the reply. > > I've been banging my head againstg this for two days now. > > I'm using FC4 kernel: 2.6.11-1.1369_FC4xen0 > > rhel3 is the standard kernel available on redhat. I had all this > working under fc4_test1 without any problems. When FC4 came out I > couldn't get it to work. I've tried all of the MAKEDEV commands but it > still doesn't work. > > The strange thing is that rhel4 does work under FC4 as a domU. > > Any ideas. I'm really desparate for some. RHEL3 uses a 2.4 kernel. You're trying to boot it up with a 2.6 kernel, so yeah having troubles is not surprizing. On the other hand RHEL4/FC4 use 2.6, the gap between expected kernel and the one provided by Xen is small in comparison, and that just works. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From fedora at camperquake.de Thu Jun 30 18:11:32 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 30 Jun 2005 20:11:32 +0200 Subject: Things to do for FC5: init stuff Message-ID: <20050630201132.032b1895@nausicaa.camperquake.de> Hi. While we (you) are ripping apart the init system: how about tagging those init scripts that do not need special handling duting system shutdown, i.e. those that will be caught by hte "sending all processes the TERM signal" stage anyway? This was discussed during FC4 development but not implemented. -- "Opera is when a guy gets stabbed in the back and instead of bleeding, he sings." -- Ed Gardner From hhoffman at ip-solutions.net Thu Jun 30 18:16:18 2005 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Thu, 30 Jun 2005 14:16:18 -0400 (EDT) Subject: FC4, Xen bridging not working Message-ID: <20050630141230.J57984@surf.gcrc.upenn.edu> hi, just got fc4 and xen working. i'm in dom0 and can see the bridge setup and ifconfig shows it's up. trying pinging across to the default gateway and I get nothing (echo reply is not blocked) stop iptables to make sure that's not it and run into the same thing. restarted switch in case it was an arp cache issue, no dice. changed xend-config.sxp from bridging to routing, reboot, still no network connectivity. reboot to standard kernel all works well. any ideas? TIA, Harry From dmc_mandrake at hotmail.com Thu Jun 30 19:11:11 2005 From: dmc_mandrake at hotmail.com (DMC Mandrake) Date: Thu, 30 Jun 2005 19:11:11 +0000 Subject: Fedora Core 5 Idea Message-ID: Hello 1: Please replace clearlooks by bluecurve, its the offcial artwork and i like it ! 2: make a new version of system-config-boot, is not too many configurable 3: Make new wallpaper, splashscreen, and GDM theme, in Blue its really good 4: Make a Graphic Shutdown Thanks !! _________________________________________________________________ MSN Search : des r?ponses ? tous vos besoins ! http://www.imagine-msn.com/hotmail/default.aspx?locale=fr-FR From sundaram at redhat.com Thu Jun 30 19:17:29 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 01 Jul 2005 00:47:29 +0530 Subject: Fedora Core 5 Idea In-Reply-To: References: Message-ID: <42C44549.8060706@redhat.com> DMC Mandrake wrote: > Hello > > 1: Please replace clearlooks by bluecurve, its the offcial artwork and > i like it ! If you like it, you can use it. It still exists. Themes are a subjective taste and clear looks is the default now for GNOME. > 2: make a new version of system-config-boot, is not too many configurable File the enhancement requests in bugzilla.redhat.com > 3: Make new wallpaper, splashscreen, and GDM theme, in Blue its really > good Ideas are cooking up in fedora-marketing list. You are welcome to participate and let us know your ideas on it > 4: Make a Graphic Shutdown Already in the wish list. http://fedoraproject.org/wiki/Wishlist. Personally I like the idea of doing something similar to the early GDM login and new init script to make bootup faster to apply to shutdown too so that it not slow enough to add graphics to make the wait look better regards Rahul From njonesy at gmail.com Thu Jun 30 13:24:31 2005 From: njonesy at gmail.com (Nick Jones) Date: Thu, 30 Jun 2005 13:24:31 +0000 Subject: Fedora Core 5 Idea In-Reply-To: <42C50F61.2090806@linux360.ro> References: <42C44549.8060706@redhat.com> <42C50F61.2090806@linux360.ro> Message-ID: <42C3F28F.8040505@gmail.com> > And that won't work with the NVIDIA binary drivers either. I think this, > as well as rhgb, are a waste of developers' time. Hmm ... I have the latest NVIDIA drivers installed and rhgb works without any problems. Nick From stelian.iancu at gmx.net Thu Jun 30 17:00:25 2005 From: stelian.iancu at gmx.net (Stelian Iancu) Date: Thu, 30 Jun 2005 17:00:25 +0000 Subject: Fedora Core 5 Idea In-Reply-To: <20050701134123.7812dc03@nausicaa.camperquake.de> References: <42C44549.8060706@redhat.com> <42C50F61.2090806@linux360.ro> <42C518A6.3000000@redhat.com> <42C51CBA.9010507@linux360.ro> <20050701134123.7812dc03@nausicaa.camperquake.de> Message-ID: <42C42529.6000806@gmx.net> > FE) and more importantly a KDE theme is unfortunate. A KDE theme is not that important anyway. Everybody switched to Plastik :-) S. From jkeating at j2solutions.net Thu Jun 30 15:29:28 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 30 Jun 2005 08:29:28 -0700 Subject: Fedora Core 5 Idea In-Reply-To: <42C50F61.2090806@linux360.ro> References: <42C44549.8060706@redhat.com> <42C50F61.2090806@linux360.ro> Message-ID: <1120145368.3304.10.camel@yoda.loki.me> On Fri, 2005-07-01 at 12:39 +0300, Ovidiu Lixandru wrote: > > As if BlueCurve were the default theme for GNOME in the RH8 -> FC3 > era. > Your argument doesn't stand. One of the Goals of the Fedora project is to stay closer to upstream. This holds true for the kernel as well as the Desktop. Hence the "new" panel arrangement and the default theme. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating